Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Sat, Dec 16, 2006 at 11:03:50AM +0100, A Mennucc wrote: > [preface: the following is just for the sake of discussion - I am > satisfied by how we reached an agreement] > Steve Langasek ha scritto: > > On Fri, Dec 15, 2006 at 01:02:55PM +0100, A Mennucc wrote: > >> ffmpeg is developed inside MPlayer ; for that reason, they (correctly) > >> feel free to improve it in any way they like. This is clearly stated in > >> the web pages of ffmpeg: no stable api, sorry. > > I don't see anything correct about this, frankly. I think these comprise > > abysmal maintenance practices on the part of upstream, and if it were my > > decision *personally*, I would likely judge mplayer/ffmpeg too immature to > > be included in a stable release until they did settle on a stable API. > ok, suppose you are right: > we delete ffmpeg from Debian stable, >since it is not really a library yet > we delete mplayer from Debian stable, >since it immaturely links with ffmpeg > then > - your judgement should be applied to all other programs that > ship (*) an internal copy of ffmpeg, and/or > - Moritz request of not having multiple copies > should apply to them Um, I said this would be my conclusion if it were my decision *personally*. I'm not the maintainer of any of these packages, so it's not. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
Steve Langasek ha scritto: > Um, I said this would be my conclusion if it were my decision *personally*. > I'm not the maintainer of any of these packages, so it's not. :) sorry, I failed to understand the meaning of "personally" a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Wed, Dec 13, 2006 at 08:01:58AM +0100, Andreas Barth wrote: > Actually, I think we should refuse dealing with the issue now, because > according to Don (wearing [EMAIL PROTECTED] hat) the decision whether a bug is > RC or not is done by the release team, not the maintainer - and the > release team is just about to make a (first) decision. AFAICS the only release criteria this package potentially violates is: ] (a) Supportable ] Packages in the archive must not be so buggy or out of date we ] refuse to support them. in the sense that Debian as a whole considers the package to be unsupportable due to the complexity of its dependency on ffmpeg. Moritz has expressed significant concern that the security team won't be able to manage that support in the bug log, though according to [0] thinks an exception is appropriate: ] > I've tried it myself and it is indeed not possible to link against ] > libavcodec dynamically currently. Given that mplayer was only accepted ] > into the archive 2.5 months after the current ffmpeg snapshot was made ] > and that mplayer is an important application I do now think we can ] > ignore this RC bug for Etch as a one-time exception. In any case further ] > mplayer maintenance needs to be synchronised with Debian's libav[codec| ] > format], even if it means to not being able to upload the most recent ] > upstream version every week. If that's the case, I think that alone resolves the problem; and I think that it'd be reasonable for the ffmpeg/mplayer maintainers to resolve the problem by volunteering to handle backports of any necessary fixes for the differing ffmpeg variants to be distributed with etch. Uploading dynamically linked ffmpeg/mplayer packages to experimental for inclusion in unstable in the near future seems like a sensible thing to do too. Cheers, aj [0] http://lists.debian.org/debian-devel/2006/12/msg00322.html signature.asc Description: Digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
Anthony Towns ha scritto: > Uploading dynamically linked ffmpeg/mplayer packages to experimental for > inclusion in unstable in the near future seems like a sensible thing to > do too. I actually tried to do that. Even though I did not think 395252 should be a RC bug, nonetheless I tried to address it from the very beginning; so I contacted Sam Hocevar (mantainer of ffmpeg) in Oct; but he was too busy. Since time was running, in mid Nov I packaged a new version of ffmpeg 0.svn6767 ; I then built a version of mplayer 1.0~rc1-5 that is dynamically linked to that; moreover I have built a version of libxine using the above ffmpeg. I installed all my creatures, and tried totem-xine and mplayer on a few files, and they seemed to work. In 27 Nov , in message http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152 I announced this and asked to Sam some help, and/or permission to upload my stuff in experimental; I never received reply. So I never uploaded them into experimental. a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
Anthony Towns ha scritto: > Moritz has expressed significant concern that the security team won't > be able to manage that support in the bug log, though according to [0] > thinks an exception is appropriate: [snip] > > If that's the case, I think that alone resolves the problem; and I think > that it'd be reasonable for the ffmpeg/mplayer maintainers to resolve > the problem by volunteering to handle backports of any necessary fixes > for the differing ffmpeg variants to be distributed with etch. I am volunteering to help in handling security problems in MPlayer (by backports or any other method). The people in MPlayer team with whom I worked in the past where always very receptive and helpful; and I feel pretty sure that, if a security problem emerges in MPlayer, they will help also in the future. a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Wed, Dec 13, 2006 at 09:24:05AM +0100, A Mennucc wrote: > Just for the record: the release team had already expressed his view > (in a sense): in Oct, there was already a (informal) discussion in > #d-release, and the opinion was that this bug 295252 was not RC at all. However, the release team is also almost certainly going to defer to the security team's judgement as to whether a given package is supportable in a stable release, since it's the security team who ultimately has to do the supporting. So in that sense, yes, it would be RC if the security team says it's RC. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
Steve Langasek ha scritto: > On Wed, Dec 13, 2006 at 09:24:05AM +0100, A Mennucc wrote: > >> Just for the record: the release team had already expressed his view >> (in a sense): in Oct, there was already a (informal) discussion in >> #d-release, and the opinion was that this bug 295252 was not RC at all. > > However, the release team is also almost certainly going to defer to the > security team's judgement as to whether a given package is supportable in a > stable release, since it's the security team who ultimately has to do the > supporting. > > So in that sense, yes, it would be RC if the security team says it's RC. hi Steve I think that we are reaching an agreement Moritz said in http://lists.debian.org/debian-devel/2006/12/msg00322.html that he thinks this bug should be RC, but that an exception should be made for Etch If everybody agrees, may someone in release team add a etch-ignore to that bug? a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Tue, Dec 12, 2006 at 09:17:10PM +0100, A Mennucc wrote: > This question is urgent, in the sense that I would like your help about > bug 395252, that as so far stopped mplayer from entering in Etch. > Brief summary of bug: MPlayer contains an embedded copy of FFmpeg > (indeed, they are developed by ~the same people); Aurélien GÉRÔME and > Moritz Muehlenhoff ask that the mplayer package be dynamically linked to > the libraries in the Debian package ffmpeg (instead of statically > linking with the copy shipped in the star of MPlayer); they consider > this bug a RC bug. > I do not think that this bug is "serious" & RC; and, moreover, > I do not think that MPlayer deserves to be kept out of Etch on > the basis of bug 395252. There are multiple levels of ugliness when it comes to handling libraries: - shipping an embedded copy of the library in the source tree. This adds to the number of source packages that need to be patched every time there is a security bug in the lib. - statically linking to the library provided by the separate library source package. This is better for security support than the previous option, because the package needs only a rebuild for the security update, not separate fiddling with the source. - dynamically linking to the shared library. This is optimal for security support, though of course there may be other problems with this (lack of stable ABI; the mentioned performance issues on i386 due to register constraints). Now it's probably not reasonable to require shared linking for mplayer as a release-critical requirement, especially when there are known problems with that approach and this would single out mplayer to an extent that other packages are not. But a) I haven't seen anything to really indicate it's the security team's intention to require this, and b) right now mplayer is at the far end of the spectrum, bundling its own copy of the libs in the source. There is a middle ground here, which is mplayer statically linking against the common ffmpeg package; I think that would be a reasonable compromise, and I'd like to know if there are reasons this too isn't achievable for etch. There may be known reasons, of course -- it's just not clear to me which of the reasons for not dynamically linking also apply to statically linking, and whether the issues with static linking might be surmountable. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
Steve Langasek ha scritto: > There is a middle ground here, which is mplayer statically linking > against the common ffmpeg package; I think that would be a reasonable > compromise, and I'd like to know if there are reasons this too isn't > achievable for etch. There may be known reasons, of course -- it's just not > clear to me which of the reasons for not dynamically linking also apply to > statically linking, and whether the issues with static linking might be > surmountable. "statically linking with external ffmpeg" (StaLEF) is another option I investigated; I did not report my investigation to avoid adding too much other noise to the discussion StaLEF is in principle a very nice compromise : it does not make i386 slower; at the same time , it does relieve the security (who just need a bin-nmu, if ffmpeg is ever changed) the only (small) drawback of StaLEF is that there is no easy 'configure' option to do that: you cannot just './configure --slef && make' - it requires some hacking lets come to today today, the ffmpeg inside Debian is 6 months older then the one in MPlayer; for that reason , DynLEF fails . When I tried it, I also tried 'make -k' , to see if there were few failures that I could fix; but the number of errors is too much . lets investigate why it fails Those errors are due to the fact that , in the older-debian-ffmpeg, headers and code are simply too different . One problem I saw is that many 'defines' are missing. So I should 'backport' all the defines in a special file, and include. And, of course, check that they have the same meaning (or, any meaning at all) in the older ffmpeg. Another problem is that debian-ffmpeg does not package a library for the swscale subtree : so if you try to link mplayer with debian-ffmpeg , you actually are linking the new swscale to the old 'postprocess/libavcoded/libavformat' lib, and this is a complete mess. All of the above will make no difference if you try to StaLEF instead of DynLEF to the older debian-ffmpeg : it is a problem of semantic of the calls, and too many cross > Now it's probably not reasonable to require shared linking for mplayer as a > release-critical requirement, especially when there are known problems with > that approach ffmpeg is developed inside MPlayer ; for that reason, they (correctly) feel free to improve it in any way they like. This is clearly stated in the web pages of ffmpeg: no stable api, sorry. MPlayer people are also free to cross-link the two codes: this is AFAICT why DynLEF does disable some features. For the same reason, though, StaLEF will need some scrutiny : for example, I cannot just go into the configure script and hack a few lines to do DynLEF, but then end with static linking: this would still disables all features aforementioned. --- all of the above, of course, to the best of my today knowledge --- conclusion: StaLEF and DynLEF may be done, but it needs time and help; unfortunately, I had few of the former and I did not get any of the latter > Thanks, thank you for the interest a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Fri, Dec 15, 2006 at 01:02:55PM +0100, A Mennucc wrote: > lets come to today > today, the ffmpeg inside Debian is 6 months older then the one in > MPlayer; for that reason , DynLEF fails . When I tried it, > I also tried 'make -k' , to see if there were few failures that I could > fix; but the number of errors is too much . Right, this is indeed a solid reason for not insisting on use of the packaged ffmpeg lib on such short notice, as long as the security team is willing to support the current situation. > > Now it's probably not reasonable to require shared linking for mplayer as a > > release-critical requirement, especially when there are known problems with > > that approach > ffmpeg is developed inside MPlayer ; for that reason, they (correctly) > feel free to improve it in any way they like. This is clearly stated in > the web pages of ffmpeg: no stable api, sorry. I don't see anything correct about this, frankly. I think these comprise abysmal maintenance practices on the part of upstream, and if it were my decision *personally*, I would likely judge mplayer/ffmpeg too immature to be included in a stable release until they did settle on a stable API. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
[preface: the following is just for the sake of discussion - I am satisfied by how we reached an agreement] Steve Langasek ha scritto: > On Fri, Dec 15, 2006 at 01:02:55PM +0100, A Mennucc wrote: >> ffmpeg is developed inside MPlayer ; for that reason, they (correctly) >> feel free to improve it in any way they like. This is clearly stated in >> the web pages of ffmpeg: no stable api, sorry. > > I don't see anything correct about this, frankly. I think these comprise > abysmal maintenance practices on the part of upstream, and if it were my > decision *personally*, I would likely judge mplayer/ffmpeg too immature to > be included in a stable release until they did settle on a stable API. ok, suppose you are right: we delete ffmpeg from Debian stable, since it is not really a library yet we delete mplayer from Debian stable, since it immaturely links with ffmpeg then - your judgement should be applied to all other programs that ship (*) an internal copy of ffmpeg, and/or - Moritz request of not having multiple copies should apply to them so we also delete ffmpeg from inside: libxine1 , used in totem-xine xine-ui gxine [other 20 programs] gstreamer-ffmpeg , used in totem-gstreamer openoffice.org libgnash0 [flash implementation] gnomebaker geekast-binary bmpx AFAIK, the only remaining player in Debian that is capable of decoding MPEG4 streams is VLC; feel free to correct me if I am wrong... (*) also, mplayer is not the only programs who ships an internal copy of ffmpeg, and messes with it; as Loic reports, the upstream of gst-ffmpeg do modify their internal copy of ffmpeg, and this makes it difficult to DynLEF it as well a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Sat, Dec 16, 2006, A Mennucc wrote: > we delete ffmpeg from Debian stable, >since it is not really a library yet We can also keep ffmpeg (the binary), without its lib. :) > so we also delete ffmpeg from inside: > libxine1 , used in xine-lib builds against Debian's ffmpeg AFAICT, *not* against its internal copy (it build-deps against libavformat-dev, libpostproc-dev, libavcodec-dev). If we did not have a ffmpeg shared library, I suppose we would still be able to build xine-lib without ffmpeg support. > totem-xine > xine-ui > gxine > [other 20 programs] No need to drop xine-lib, not these; only disable ffmpeg. > gstreamer-ffmpeg , used in > totem-gstreamer > openoffice.org > libgnash0 [flash implementation] > gnomebaker > geekast-binary > bmpx (And way more packages.) But please note that gst-ffmpeg is a real fork of ffmpeg which applies stability and functionality fixes around its snapshot in order to fix ffmpeg regressions. This is all wrapped in the GStreamer (stable) API transparently, and the program you mention are still usable without gst-ffmpeg (gst-plugins-base, -ugly, -bad also provide codecs). Now instead of imagining we remove ffmpeg, perhaps you can imagine that ffmpeg moves to offering a stable API, perhaps in a stable branch which is feature frozen but where security fixes can go, we could: - build mplayer, xine-lib, gst-ffmpeg against the ffmpeg shared libs - fix security holes in a single place - upload new ffmpeg versions without breaking mplayer, xine-lib, gst-ffmpeg or requiring a rebuild Doesn't it sound nicer? :) Why is ffmpeg so rapidly API breaking? xine-lib and GStreamer have managed to expose very stable APIs for years, and they solve the same type of problems. -- Loïc Minier <[EMAIL PROTECTED]> "Forget your stupid theme park! I'm gonna make my own! With hookers! And blackjack! In fact, forget the theme park!" -- Bender
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
I am sorry, there were many misunderstanding (my argument was not clear enough - and it was too verbose) Let me be a bit more precise. I repeat my (hypothetical) reasoning. --- Steve said: > if it were my > decision *personally*, I would likely judge mplayer/ffmpeg too immature to > be included in a stable release until they did settle on a stable API. Moritz said that linking with internal ffmpeg is bad for security. Suppose all the above two are to be satisfied, then all programs in Debian stable cannot be linked - nor with a Debian ffmpeg family of library packages - neither with their own internal ffmpeg As a corollary, to satisfy both those requirements , we should disable ffmpeg in all of the programs that either contain a copy, or link to an external copy, or both. That leaves VLC as the only program that could play MPEG4 AFAIK --- All the above argument was to explain to Steve that FFMpeg is a widely used library , even though its API is not mature. --- some other remarks: Loïc Minier ha scritto: > On Sat, Dec 16, 2006, A Mennucc wrote: >> we delete ffmpeg from Debian stable, >>since it is not really a library yet > > We can also keep ffmpeg (the binary), without its lib. :) yeah, I was meaning 'the ffmpeg suite' ... :-) >> so we also delete ffmpeg from inside: >> libxine1 , used in > > xine-lib builds against Debian's ffmpeg AFAICT, *not* against its > internal copy (it build-deps against libavformat-dev, libpostproc-dev, > libavcodec-dev). BTW: after etch is release, you (AFAICR) are willing to update gst-ffmpeg to use DynLEF (as Josselin was proposing). Whereas, I had prepared a version of ffmpeg and mplayer that could be dynamically linked , see in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152 so we should all join forces: you , me, Sam, xine people, totem people... [And, yes I know about xine. I built a version myself , to test with my newer ffmpeg packages .] > If we did not have a ffmpeg shared library, I suppose > we would still be able to build xine-lib without ffmpeg support. I guess so > No need to drop xine-lib, not these; only disable ffmpeg. that was what I meant , sorry for misunderstanding > (And way more packages.) But please note that gst-ffmpeg is a real > fork of ffmpeg which applies stability and functionality fixes around > its snapshot in order to fix ffmpeg regressions. This is all wrapped > in the GStreamer (stable) API transparently, and the program you > mention are still usable without gst-ffmpeg (gst-plugins-base, -ugly, > -bad also provide codecs). forking has pro and con pro: no sudden API changes con: it is more difficult for gstreamer to follow the "upstream" development of ffmpeg for example, in last year ffmpeg people enhanced support for h264, and they claim a +10% in speed ; since neither gst-ffmpeg was updated, not ffmpeg-in-Debian itself, MPlayer-in-Debian-etch will be the only program enjoying those updates. This is another reason why it is a real pity that the work I did in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152 was never followed upon. > Now instead of imagining we remove ffmpeg, perhaps you can imagine that > ffmpeg moves to offering a stable API, perhaps in a stable branch which > is feature frozen but where security fixes can go, we could: > - build mplayer, xine-lib, gst-ffmpeg against the ffmpeg shared libs [this could already be done, as I said above] > - fix security holes in a single place > - upload new ffmpeg versions without breaking mplayer, xine-lib, >gst-ffmpeg or requiring a rebuild > > Doesn't it sound nicer? :) I would love them to do a real release, lets say "ffmpeg 1.0" . My hope is that, by time of lenny release, that will be true. > Why is ffmpeg so rapidly API breaking? xine-lib and GStreamer have > managed to expose very stable APIs for years, and they solve the same > type of problems. maybe because they live on a different level of abstraction xine-lib and gstreamer are "gluing" code: they wrap existing codecs at the same time, xine and gstreamer contains embedded copies (*) of many of the codecs , so they are not broken when the upstream changes so, the get the "pro" but stumble also in the "con".. [(*) then, Debian people try when possible to link to a library package... but this is our choice ; and we do not always do that : e.g. libxine1 contains a copy of libmpeg2 , even if libmpeg2-4 is in Debian ] a. signature.asc Description: OpenPGP digital signature
Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Sat, Dec 16, 2006, A Mennucc wrote: > BTW: after etch is release, you (AFAICR) are willing > to update gst-ffmpeg to use DynLEF (as Josselin was proposing). Yes, but only because it was merged upstream, and with the additional maintenance costs it involves. BTW, an upstream developer already had an issue building against his own local ffmpeg, and upstream also claimed they would close any bug from people using Debian's ffmpeg instead of the copy of ffmpeg in gst-ffmpeg. > so we should all join forces: you , me, Sam, xine people, totem people... I'm a maintainer of totem, but totem isn't affected directly, it's only using xine-lib and gstreamer, not ffmpeg directly in any of the two flavors. > for example, in last year ffmpeg people enhanced support for h264, and > they claim a +10% in speed ; since neither gst-ffmpeg was updated, not > ffmpeg-in-Debian itself, MPlayer-in-Debian-etch will be the only program > enjoying those updates. If ffmpeg's upstream doesn't offer a way to pull stable releases with only bug fixes and performance improvements, I can understand that distributions and forks of ffmpeg are careful not to pull too often from upstream ffmpeg. In other words, the problems come from the fact that ffmpeg does not have bugfix/stable releases. BTW, gst-ffmpeg was updated last week and quite regularly in CVS as well (but not released after each sync given the required amount of QA). I hope you dare not criticize gst-ffmpeg for not releasing updated versions as tarballs given the number of tarball releases of ffmpeg. ;) > This is another reason why it is a real pity that the work I did in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=152 > was never followed upon. Err, who did you expect would followup? > > Now instead of imagining we remove ffmpeg, perhaps you can imagine that > > ffmpeg moves to offering a stable API, perhaps in a stable branch which > > is feature frozen but where security fixes can go, we could: > > - build mplayer, xine-lib, gst-ffmpeg against the ffmpeg shared libs > [this could already be done, as I said above] This was only possible too late in the release cycle. The gst-ffmpeg patch would have been acceptable some 2 months ago, in fact I requested such a patch, and tried an alternate solution on my own. Check #402793 for the parallel ctte discussion on gst-ffmpeg. > > Why is ffmpeg so rapidly API breaking? xine-lib and GStreamer have > > managed to expose very stable APIs for years, and they solve the same > > type of problems. > maybe because they live on a different level of abstraction > xine-lib and gstreamer are "gluing" code: they wrap existing codecs Yes, but the service that ffmpeg libs offer to xine-lib is exactly the service xine-lib offers to totem-xine, and the same applies for ffmpeg / gst-ffmpeg / totem-gstreamer; yet gstreamer and xine-lib APIs are stable and see releases. And this even holds true despite the fact the gstreamer plugins packages wrap dozens of other libraries (~ 50 for gst-plugins0.8) under the same API and ABI! -- Loïc Minier <[EMAIL PROTECTED]> "Forget your stupid theme park! I'm gonna make my own! With hookers! And blackjack! In fact, forget the theme park!" -- Bender
Bug#395252: Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
tags 395252 etch-ignore thanks On Fri, Dec 15, 2006 at 11:58:10AM +0100, A Mennucc wrote: > Steve Langasek ha scritto: > > On Wed, Dec 13, 2006 at 09:24:05AM +0100, A Mennucc wrote: > >> Just for the record: the release team had already expressed his view > >> (in a sense): in Oct, there was already a (informal) discussion in > >> #d-release, and the opinion was that this bug 295252 was not RC at all. > > However, the release team is also almost certainly going to defer to the > > security team's judgement as to whether a given package is supportable in a > > stable release, since it's the security team who ultimately has to do the > > supporting. > > So in that sense, yes, it would be RC if the security team says it's RC. > hi Steve > I think that we are reaching an agreement > Moritz said in > http://lists.debian.org/debian-devel/2006/12/msg00322.html > that he thinks this bug should be RC, but that an exception should be > made for Etch > If everybody agrees, may someone in release team add a etch-ignore to > that bug? Andi and I are agreed that this is a suitable solution given the evident approval of the security team. I'm tagging bug #395252 etch-ignore with this mail (which means solving this *is* regarded as release critical for lenny), which means that, AFAICS, there is no longer a matter for the TC to rule on so I'm also closing that bug. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
