On Sun, 16 Oct 2005, Steve Langasek wrote: > So now the segfaults move another step down the chain, to someone else > running a different application that needs net-snmp built against 0.9.7...
Indeed. Until all have transitioned, segfaults would happen. There was no other fix for a openssl without versioned symbols other than transition EVERYTHING as fast as possible. > > The openssl transition is under way, the release team was not clear on what > > we were to do about it, either. I was fully expecting 0.9.8 to be removed > > off the archive immediately until it was properly fixed. No such luck. > > The options for undoing such a thing once it's started are few, and they all > suck. The problem here is comunication, or rather the lack of it, which sucks even more. > Nevertheless, it has been discussed on the pkg-openssl-devel mailing list > and with the release team: If you don't tell others what you are trying to do, do not complain if they take action without taking into account what you have planned to do... > Except that I submitted a patch for your bug less than 24 hours after it was > submitted: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333349;msg=16 > > And the maintainers are considering it. Sorry for not cc:ing you, but all > the same, I don't really see how in the absence of versioned symbols, you > would feel that one-off NMUs of packages would help the transition. One less package needing to transition is always a help, and in this case it was one that was bothering me. I *had* to force-transition it on my local system or I could not work on my packages, and since the work was already done, why not NMU? As far as I know, other openssl rdeps might be uploading new builds soon (unless they HAVE been told to hold all uploads already). > Yes, I'm aware of that. My mail was meant to bring the full situation to > your (and Jochen's) attention, to forestall any further openssl-related > bugs/NMUs at this point. Well, I certainly won't upload/NMU anything. > > May I humbly suggest that from now on, we have weekly d-d-a emails about all > > ongoing transitions and naming all packages that are to be left alone (no > > NMUs, no maintainer uploads without first talking to the release team) ? > > The problem is that it's very difficult to identify all packages affected by > a transition before the transition is near the point of being ready. Such notification DURING transitions would be already a good enough help, you don't need to simulate a transition and notify people of the definite list of packages before it starts, IMO. > Telling people "this is the list of packages not to upload", when we don't > know it's complete, is worse than telling people "this is the transition > going on right now". Even that may not be sustainable given the number of > transitions that are currently in the air for etch. :/ How come we cannot track down whatever is linked to whatever in the archive? Let's fix this, and it becomes easy to track library transitions with 100% accuracy. I trust the C++ transition can be tracked just like a library one due to libstdc++ ? > > Better yet, da-katie could be improved to put a source package on hold for > > manual approval by the release team (after it is approved by the ftp-masters > > or builtin katie policies) to enforce these transitions more smoothly. > > Well, that's an idea, but there are a number of other dak/britney changes > that are of much higher priority... As long as they happen before hell freezes over... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
