Re: [MPlayer-DOCS] letter to distro mplayer packagers?
On Mon, Nov 28, 2005 at 09:46:30AM +0100, Christian Marillat wrote:
Diego Biurrun <diego@biurrun.de> writes:
First off the package is somewhat unwieldy. The patch that gets applied is 268kb compressed, which is massive. Among other things it contains a uuencoded version of the MPlayer default skin, Blue. Why this is done the way it is done remains a mystery to me.
Yes, because gmplayer need a default skin otherwise gmplayer doesn't start.
I know that of course. Let me rephrase my unclear words: Why you include a skin uuencoded in the packaging patch and not create a skin package that the mplayer-gui package depends on remains a mystery to me.
vo=x11,
creates a lot of trouble for the user because this selects the unaccelerated x11 video output driver that does not do scaling by default. Thus people go into fullscreen mode and wonder why the screen is black but an unscaled movie remains in the middle at original size. We get reports about this all the time.
x11 is the only default which work in all cases. I think I'll add "xv,x11" in the next package who is much better.
Better, but leaving it out altogether would do the trick as well.
The defaults MPlayer uses have been carefully chosen, there should be no need to ship more than the default config file where all entries are commented out. To further complicate matters there are multiple copies of the example config file scattered over the packaging patch.
This doesn't work. Here mplayer doesn't start, same for gmplayer.
,---- | ========================================================================== | open: No such file or directory | vo_mga: Couldn't open /dev/mga_vid | open: No such file or directory | vo_mga: Couldn't open /dev/mga_vid | ========================================================================== | VO: [3dfx] 672x288 => 672x288 Planar YV12 | Couldn't open /dev/3dfx `----
This looks like a bug in the 3dfx video output driver. It should fall back on other video output drivers but apparently doesn't. There is an easy solution to this problem: Just don't compile-in the 3dfx video output driver. It has been obsoleted by the tdfxfb and tdfx_vid video output drivers and is not compiled-in by default anyway.
You added quite a few mime-types to the mplayer.desktop file. This is good. I took them all, added a few more and committed everything to CVS. Since the mplayer.desktop file is also hard-coded into the packaging patch, you may not pick this up automatically.
I add nothing. I've simply packaged a desktop file before you and because your changelog is unreadable (the pre8 is more than 130 lines) I've not seen you have added a desktop file in pre4.
Yes, there are a lot of changes. Do you have a suggestion how we could make our changelogs more readable? Please just submit such things to us. We'll let you know whether we already have it or not.
We gladly accept patches from packagers. Unfortunately we have not been getting any from you, Christian. You apply many small patches to your packages, yet AFAICT most of the problems they aim to fix are already resolved in upstream CVS.
I hope you know why I've never send any patches or suggestions to you ?
I have no idea. Are you referring to some old quarrel with Gabucino (and Arpi) maybe? If that should be the case then let us please forget about stories from a few years ago and move on. Diego
Hi, On Tuesday, 29 November 2005 at 01:50, Diego Biurrun wrote:
On Mon, Nov 28, 2005 at 09:46:30AM +0100, Christian Marillat wrote:
Diego Biurrun <diego@biurrun.de> writes:
First off the package is somewhat unwieldy. The patch that gets applied is 268kb compressed, which is massive. Among other things it contains a uuencoded version of the MPlayer default skin, Blue. Why this is done the way it is done remains a mystery to me.
Yes, because gmplayer need a default skin otherwise gmplayer doesn't start.
I know that of course. Let me rephrase my unclear words:
Why you include a skin uuencoded in the packaging patch and not create a skin package that the mplayer-gui package depends on remains a mystery to me.
I don't know about the uuencode part, but including the Blue skin in the gui package isn't a bad idea. I included it in my mplayer-gui RPM recently, after getting tired of users unable to grasp the concept of installing two RPMs at once. It doesn't add much maintenance overhead and saves me a lot of support questions. [...]
x11 is the only default which work in all cases. I think I'll add "xv,x11" in the next package who is much better.
Better, but leaving it out altogether would do the trick as well.
Agreed.
You added quite a few mime-types to the mplayer.desktop file. This is good. I took them all, added a few more and committed everything to CVS. Since the mplayer.desktop file is also hard-coded into the packaging patch, you may not pick this up automatically.
I add nothing. I've simply packaged a desktop file before you and because your changelog is unreadable (the pre8 is more than 130 lines) I've not seen you have added a desktop file in pre4.
Yes, there are a lot of changes. Do you have a suggestion how we could make our changelogs more readable?
I'd like to hear about that, too. Maybe I can use some ideas in my changelogs.
Please just submit such things to us. We'll let you know whether we already have it or not.
Yes, please do.
We gladly accept patches from packagers. Unfortunately we have not been getting any from you, Christian. You apply many small patches to your packages, yet AFAICT most of the problems they aim to fix are already resolved in upstream CVS.
I hope you know why I've never send any patches or suggestions to you ?
I have no idea.
Are you referring to some old quarrel with Gabucino (and Arpi) maybe? If that should be the case then let us please forget about stories from a few years ago and move on.
And if you're referring to my badmouthing, I apologize (again). I promise not to repeat such mistakes in the future. Regards, R. PS. Oh yes, Christian's mail got bounced by my server because his smtp server is on some blacklist. I've whitelisted it so there shouldn't be a problem from now on. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
On Tue, Nov 29, 2005 at 01:50:42AM +0100, Diego Biurrun wrote:
On Mon, Nov 28, 2005 at 09:46:30AM +0100, Christian Marillat wrote:
Diego Biurrun <diego@biurrun.de> writes:
The defaults MPlayer uses have been carefully chosen, there should be no need to ship more than the default config file where all entries are commented out. To further complicate matters there are multiple copies of the example config file scattered over the packaging patch.
This doesn't work. Here mplayer doesn't start, same for gmplayer.
,---- | ========================================================================== | open: No such file or directory | vo_mga: Couldn't open /dev/mga_vid | open: No such file or directory | vo_mga: Couldn't open /dev/mga_vid | ========================================================================== | VO: [3dfx] 672x288 => 672x288 Planar YV12 | Couldn't open /dev/3dfx `----
This looks like a bug in the 3dfx video output driver. It should fall back on other video output drivers but apparently doesn't.
This is fixed in CVS since yesterday, the 3dfx video output driver now has a proper uninit routine and falls back on other video output drivers as it should. Diego
participants (2)
-
Diego Biurrun -
Dominik 'Rathann' Mierzejewski