Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
* Steve Langasek ([EMAIL PROTECTED]) [051015 01:39]: On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote: Finally, are there any plans to alleviate testing migration issues for packages held up by this, and if so, how? The way to alleviate testing migration issues is by getting openssl097 and openssl updates into testing ASAP. They will probably have to go into testing together, because of the move of the openssl binary from one source package to the other, which means openssl needs to be reuploaded with symbol versionining support and then both packages need to be allowed to get built on all architectures and settled long enough that we can be comfortable pushing them into testing. AFAICS, openssl097 will go into testing by itself as soon as the -dev-package is rened out, and it is built on ia64 (and of course, old enough). For openssl itself - well, we need of course resolve this RC-bug (i.e. get library versioning working). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
Hello, Now that we have a solution for the ramdisk generation tool mess, we can go ahead, and outline a plan for bringing 2.6.13 to sid, and then go ahead and do the same with 2.6.14 shortly after that, while 2.6.12 is safely in etch. As mentioned in : ... the plan for solving the ramdisk issues is done in three stages, current svn 2.6.13 packages implement stage 1, i have patches for both initrd-tools and initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go ahead and upload those nextly (if it could be in by monday, that would be nice). I will work on the last stage, the kernel-package patch, this WE, and do an NMU since Manoj is unavailable for the next times and asked us to do so. Once the fixed kernel-package is in the archive, we can then follow up and upload 2.6.13-2 to experimental, which will allow us to fine test all this and confirm that it works well, and then after some time, upload -3 to unstable, which will allow for more widespread testing, but see below. On a separate issue, current 2.6.13-1 had some serious build issue, which are not yet all fixed in svn, but the current svn status is : Building : alpha powerpc i386 amd64 sparc Broken but being worked on : s390 m68k Broken but not being worked on yet : hppa ia64 No information : arm Not in the common package : mips mipsel So, an upload of -2 will work on at least 5 arches out of 10, so this is a call for hppa, ia64, arm, s390 and m68k porter to fix these issues, hopefully for the -2 timeframe, but at least for the -3 timeframe. The other issue is that 2.6.14 is scheduled for release in the not so distant future, so we may skip uploading .13-3 to unstable and go for .14-1 directly, depending on status of newly introduced breakage in .14 and such. Ok, so now a tentative timeline for things to happen : Monday, october 17 : last call for upload of fixed yaird, initrd-tools, initramfs-tools, kernel-package. Wednesday, october 19 : last call for the -2 upload, any arches not fixed by then will have to wait for -3. Tuesday, october 25 : upload of -3 into sid, hopefully with all arches fixed, but this will be up to the porters. The alternative track is to drop -3, and start working on .14, and make a .14-1 upload to experimental somewhen in the week 43, the one of monday ocober 24. In any case, we don't intend to move .13 to etch. Comments ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote: the plan for solving the ramdisk issues is done in three stages, current svn 2.6.13 packages implement stage 1, i have patches for both initrd-tools and initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go ahead and upload those nextly (if it could be in by monday, that would be nice). I will work on the last stage, the kernel-package patch, this WE, and do an NMU since Manoj is unavailable for the next times and asked us to do so. initramfs-tools waits for mklibs. Broken but being worked on : s390 Broken gcc or inline assembly, the IBM people expect the later. Hope that I get a fix from them at monday. The other issue is that 2.6.14 is scheduled for release in the not so distant future, so we may skip uploading .13-3 to unstable and go for .14-1 directly, depending on status of newly introduced breakage in .14 and such. I vote for the later. Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, A Taste of Armageddon, stardate 3193.9 signature.asc Description: Digital signature
Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Fri, Oct 14, 2005 at 04:38:53PM -0700, Steve Langasek wrote: On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote: Finally, are there any plans to alleviate testing migration issues for packages held up by this, and if so, how? The way to alleviate testing migration issues is by getting openssl097 and openssl updates into testing ASAP. They will probably have to go into testing together, because of the move of the openssl binary from one source package to the other, which means openssl needs to be reuploaded with symbol versionining support and then both packages need to be allowed to get built on all architectures and settled long enough that we can be comfortable pushing them into testing. What I'm wondering about was the need for a Conflict between libssl0.9.7 and libssl0.9.8. I think we should do it, but it's going to make migration to testing alot harder, but hopefully the last time. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
On Sat, Oct 15, 2005 at 01:07:38PM +0200, Bastian Blank wrote: On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote: the plan for solving the ramdisk issues is done in three stages, current svn 2.6.13 packages implement stage 1, i have patches for both initrd-tools and initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go ahead and upload those nextly (if it could be in by monday, that would be nice). I will work on the last stage, the kernel-package patch, this WE, and do an NMU since Manoj is unavailable for the next times and asked us to do so. initramfs-tools waits for mklibs. Well, we can go ahead with yaird for now, what is the mklibs issue ? Or can mklibs be disabled for now ? Broken but being worked on : s390 Broken gcc or inline assembly, the IBM people expect the later. Hope that I get a fix from them at monday. Ok, as said, if not, it can wait for -3. The other issue is that 2.6.14 is scheduled for release in the not so distant future, so we may skip uploading .13-3 to unstable and go for .14-1 directly, depending on status of newly introduced breakage in .14 and such. I vote for the later. Hehe, but this does suppose we create now another branch and start porting the patches and configs, i see nobody volunteering to do that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
temporary package removals from testing: freqtweak, cheesetracker, fireflier, seq24
Hi Enrique, Wesley, Martin, Guenter, This note is to let you know that the source packages freqtweak, cheesetracker, fireflier, and seq24 are being dropped temporarily from testing in order to split the wxwindows2.4 and libsigc++-1.2 ABI transitions from the Qt and JACK ABI transitions which aren't yet ready for testing. Each of these packages appears to be free of RC bugs in its own right, so they should all get right back into etch as soon as JACK/Qt/KDE are ready. 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/ signature.asc Description: Digital signature
Re: Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
On Sat, Oct 15, 2005 at 01:13:31PM +0200, Sven Luther wrote: On Sat, Oct 15, 2005 at 01:07:38PM +0200, Bastian Blank wrote: On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote: the plan for solving the ramdisk issues is done in three stages, current svn 2.6.13 packages implement stage 1, i have patches for both initrd-tools and initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go ahead and upload those nextly (if it could be in by monday, that would be nice). I will work on the last stage, the kernel-package patch, this WE, and do an NMU since Manoj is unavailable for the next times and asked us to do so. initramfs-tools waits for mklibs. Well, we can go ahead with yaird for now, what is the mklibs issue ? Or can mklibs be disabled for now ? Broken but being worked on : s390 Broken gcc or inline assembly, the IBM people expect the later. Hope that I get a fix from them at monday. Ok, as said, if not, it can wait for -3. The other issue is that 2.6.14 is scheduled for release in the not so distant future, so we may skip uploading .13-3 to unstable and go for .14-1 directly, depending on status of newly introduced breakage in .14 and such. I vote for the later. Hehe, but this does suppose we create now another branch and start porting the patches and configs, i see nobody volunteering to do that. I vote for not creating another breach. I vote for moving to .14 (or some -rc variant thereof). Its unlikelty to make much difference on the initrd front and saves duplication of effort that is inherent in the more branches approach. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Sat, Oct 15, 2005 at 01:11:17PM +0200, Kurt Roeckx wrote: What I'm wondering about was the need for a Conflict between libssl0.9.7 and libssl0.9.8. I think we should do it, but it's going to make migration to testing alot harder, but hopefully the last time. Having talked to with the release team on IRC, we agreed that we should not add a Conflict. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
On Sat, Oct 15, 2005 at 09:00:38PM +0900, Horms wrote: The other issue is that 2.6.14 is scheduled for release in the not so distant future, so we may skip uploading .13-3 to unstable and go for .14-1 directly, depending on status of newly introduced breakage in .14 and such. I vote for the later. Hehe, but this does suppose we create now another branch and start porting the patches and configs, i see nobody volunteering to do that. I vote for not creating another breach. I vote for moving to .14 (or some -rc variant thereof). Its unlikelty to make much difference on the initrd front and saves duplication of effort that is inherent in the more branches approach. Well, but are we really ready to lose the relative stability of the 2.6.13 packages now and redo all the patch triaging and config file fixing ? I am perosnally strongly in favour of going with 2.6.14-rc4 (in a 2.6.13.99-1 package), but we need at least to rework on the patches to do that. I will not be able to do that, except for powerpc, and i see nobody prepared to do it, unless you and waldi just volunteered to do this before monday :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Perl help needed for kernel-package mod ... (Was: Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.)
On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote: Hello, Now that we have a solution for the ramdisk generation tool mess, we can go ahead, and outline a plan for bringing 2.6.13 to sid, and then go ahead and do the same with 2.6.14 shortly after that, while 2.6.12 is safely in etch. Oh well, i had a quick look at the needed code in the postinsts, but i have to admit that i will not be able to do this, perl being like chinese to me :/ The code is : my $ramdisk = '/usr/sbin/mkinitrd'; # Tool to create initial ram fs. $ramdisk = $1 if /ramdisk\s*=\s*(\S+)/ig; my $ret = system($ramdisk . ($mkimage ? -m '$mkimage' : ) . -o $initrd_path.new $modules_base/$version); Well, i understand this, but i don't know how to do what is needed, namely : 1) depending on $version, default to /usr/sbin/mkinitrd (for pre-2.6.13 kernels) or mkinitramfs or yaird. Maybe initramfs for now. 2) parse the ramdisk option and put the space-separated entries in some kind of list. 3) for each element in the list, check if : 3.1) it is an executable binary that exists. 3.2) calling it with --supported-host-version=`uname -r` --supported-target-version=$version and check the return value is 0. and eliminate all entries which don't verify the above. 4) Take the first in the list and use it to build the ramdisk. 5) if the list is empty, fail and inform the user. I would be extremely grateful if someone could take the time and implement this ASAP, as we need this to upload 2.6.13-2 and finish the support. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
Packages built against the unversioned libssl0.9.8 will, when run on a system with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 (wrong) or not find their symbols (segfault). Accordingly, all packages linked against the current libssl0.9.8 are in trouble and will need rebuilds. Correction; I got my versioning rules wrong. They'll work fine if libssl0.9.7 is *not* installed, but will pick up the symbols from it if it is installed. Which is seriously bad. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Sat, Oct 15, 2005 at 03:39:08PM -0400, Nathanael Nerode wrote: Packages built against the unversioned libssl0.9.8 will, when run on a system with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 (wrong) or not find their symbols (segfault). Accordingly, all packages linked against the current libssl0.9.8 are in trouble and will need rebuilds. Correction; I got my versioning rules wrong. They'll work fine if libssl0.9.7 is *not* installed, but will pick up the symbols from it if it is installed. Which is seriously bad. Please note that libssl0.9.7 and libssl0.9.8 have a different SONAME. There can only be a problem when a program (indirectly) links to both of them. In that case, there isn't even an option not to install both of them. If a program is linked to both of them, and it was not linked to a lib with versioned symbols, there really isn't much you can tell about which symbols it's going to pick. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packages to remove for libpng
For libpng. I think this is all that's needed. gdk-pixbuf can't go in in advance of libpng because it has a too-high versioned dependency on some architectures. Anyway, it should give good output. # 207756, 328338, 331082 remove amaya/9.5-1 # dillo's tied up with openssl remove dillo/0.8.3-1.1 # gdk-pixbuf needs an ia64 build, zvbi needs ia64 and hppa urgent imlib/1.9.14-24 urgent zvbi/0.2.17-3 hint imlib/1.9.14-24 libpng/1.2.8rel-5 gdk-pixbuf/0.22.0-10 wxwindows2.4/2.4.4.1.1 -- Nathanael Nerode neroden at gcc.gnu.org Doom! Doom! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packages which may need new uploads after versioned libssl0.9.8
The following packages appear to have been built against openssl 0.9.8 without versioned symbols, and libraries or programs from them will accordingly misbehave if libssl0.9.7 ever ends up linked into the same program as one of them: crypt-ssleay curl newpki-lib sqlrelay cogito fireflier nagios-plugins openipmi tmsnc wget ace courier netkit-ftp-ssl uw-imap bzflag davfs2 hostapd libapache-mod-ssl sendmail apcupsd dillo drivel elfsign encfs medussa mixmaster nagios-nrpe openssh-krb5 openswan siege starttls stunnel stunnel4 epic4 openvpn postgresql-7.4 tcpdump aria balsa dovecot hammerhead jpilot libpam-mount neon0.23 ntop openssh php4 php5 postgresql-8.0 spamassassin webauth lasso libfwbuilder asterisk-oh323 fwbuilder heartbeat-2 kdesdk xmms gambas tellico trustedqsl ntp cl-tclink ...and growing. -- Nathanael Nerode neroden at gcc.gnu.org Doom! Doom! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
[EMAIL PROTECTED] wrote: Please note that libssl0.9.7 and libssl0.9.8 have a different SONAME. There can only be a problem when a program (indirectly) links to both of them. In that case, there isn't even an option not to install both of them. If a program is linked to both of them, and it was not linked to a lib with versioned symbols, there really isn't much you can tell about which symbols it's going to pick. Right. Thanks for being clearer than me. Consider the fate of a binary built against libssl0.9.8 with unversioned symbols, once libssl0.9.8 with versioned symbols is installed. Suppose also that libssl0.9.7 -- with unversioned symbols -- is indirectly linked in (very likely in complicated situations like KDE, and because libssl may be dlopened). The dynamic linker will resolve the unversioned symbols from the binary -- supposed to be, at least in some cases, libssl0.9.8 symbols -- to the unversioned symbols it finds, namely, the ones in libssl0.9.7. This is bad if the ABI has actually changed between 0.9.7 and 0.9.8, as it will lead to tricky-to-track-down bugs at runtime. It would be best, therefore, if nothing were built against libssl0.9.8 until the libssl0.9.8 with versioned symbols is available (after which everything will be hunky-dory). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
