Re: the mangling of ‘va_list’ has changed in GCC 4.4
On Wed, Jan 27, 2010 at 11:11 PM, Riku Voipio riku.voi...@iki.fi wrote: Interesting. Do you have a example on howto do that? http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/patches/92_armel_gcc43_valist_compat.diff;h=1db7aa33b73193a8ac0ff563f7a81bff40bfab61;hb=b3e8073df9201386aa420d5f4cab839615a0c6c5 cheers, Fathi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has changed in GCC 4.4
Hello,
On ketvirtadienis 28 Sausis 2010 10:23:20 Fathi Boudra wrote:
On Wed, Jan 27, 2010 at 11:11 PM, Riku Voipio riku.voi...@iki.fi wrote:
Interesting. Do you have a example on howto do that?
http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/patches/92_arm
el_gcc43_valist_compat.diff;h=1db7aa33b73193a8ac0ff563f7a81bff40bfab61;hb=b
3e8073df9201386aa420d5f4cab839615a0c6c5
I have recently came across .symver directive [1][2] that is more
straightforward way to achieve the same thing. In that case, only source file
(.cpp) needs to be changed. For example:
---
$ cat test.h
void myprint(const char* fmt, va_list list);
$ cat libtest.cpp
#include cstdarg
#include test.h
void myprint(const char* fmt, va_list list) {
}
// va_list mangling has been changed in g++ 4.4
// Add ABI = g++-4.3 compatibility hack
#if defined __ARM_EABI__ defined __GNUC__ (__GNUC__ 4 || __GNUC__ == 4
__GNUC_MINOR__ = 4)
__asm__(.symver _Z7myprintPKcSt9__va_list, _Z7myprintPKcPv@@);
#endif
---
_Z7myprintPKcSt9__va_list ( myprint(char const*, std::__va_list) )
here is the new mangling while _Z7myprintPKcPv ( myprint(char const*, void*)
) is the old mangling. When this code is built under g++-4.4, the resulting
binary will have both symbols with _Z7myprintPKcPv and
'_Z7myprintPKcSt9__va_list' referring to the same address:
$ objdump -T libtest.so | grep _Z7myprint
06d8 gDF .text 0058 Base_Z7myprintPKcSt9__va_list
06d8 gDF .text 0058 Base_Z7myprintPKcPv
1. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-
assembler/symver.html
2. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-
linker/version.html
--
Modestas Vainius modes...@vainius.eu
signature.asc
Description: This is a digitally signed message part.
Re: Bug#548035: /usr/bin/users-admin: users-admin sets su's path to /home/root
Am 28.01.2010 10:18, schrieb Josselin Mouette: Le jeudi 28 janvier 2010 à 09:06 +0100, Fabian Greffrath a écrit : This bug is already fixed in unstable, but the lenny version is still affected. I guess its seriousness mandates a stable upload. Yes, please fix this ASAP. It's really breaking peoples's systems out there. It’s already fixed in proposed-updates. Please bring any further complaints to the SRMs :) Dear SRMs, please accept gnome-system-tools 2.22.0-4 in stable ASAP to fix #548035. - Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#548035: /usr/bin/users-admin: users-admin sets su's path to /home/root
Fabian Greffrath wrote: Dear SRMs, please accept gnome-system-tools 2.22.0-4 in stable ASAP to fix #548035. It's already been accepted, or it wouldn't have made it to proposed-updates at all. Packages only move from proposed-updates to stable during point releases, which are generally every couple of months; as previously announced, the next point release for stable is scheduled for tomorrow evening. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming potential haskell breakage in testing
Hi, Am Mittwoch, den 27.01.2010, 22:51 + schrieb Adam D. Barratt: The upcoming lenny point release includes a fix to ghc6 to resolve a deadlock issue on 64-bit architectures, together with a number of binNMUs for affected packages on those architectures. ghc6 has not managed to build on ia64 since the release of lenny and the package has therefore not managed to migrate to testing in that time; many of the affected packages have also not had a source upload in the same period. As a result, in order to maintain the property that ver(stable) = ver(testing) = ver(unstable) for any given package on any given architecture, a side-effect of the point release will be that the new ghc6 source package and many of the binNMUs will be pushed in to testing from stable; in some cases, the binNMUs will also be propagated to unstable. A list of the affected packages can be found at http://release.debian.org/~adsb/haskell_testing.txt and http://release.debian.org/~adsb/haskell_unstable.txt thanks for the heads up. From my POV, I can see no issues with these uploads. Binaries built from Haskell sources are independent from haskell-libraries and such, therefore, no breakage should occur. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: the mangling of ‘va_lis t’ has changed in GCC 4.4
* Matthias Klose d...@debian.org, 2010-01-27, 23:25: IMO the major work is to identify affected libraries. if this is done, you can decide if binNMUs or manual creation of aliases is the bigger pain. On some other architectures (like amd64) std::va_list is already mangled to something easily greppable. This is how (more or less) I made my list of affected packages. -- Jakub Wilk signature.asc Description: Digital signature
Re: Ongoing Python Transition: related FTBFSes
Scott Kitterman deb...@kitterman.com (17/12/2009): I believe that we are getting close to uploading Python 2.6 to Unstable and dropping Python 2.4 as a supported Python version. If we finish preparations in the next week, are there any ongoing transitions a python2.6/python- defaults upload would entangle that would cause the release team to want the uploads to be delayed? Hi, I'm not sure it's the proper thread to mention this, but from a quick look, it sounds like related. FWIW, here are some FTBFSes I've reported lately, which look due to this transition: #567220: qscintilla2 #567222: python-qt3 #567224: python-qt4 #567226: pysvn #567227: pyqwt3d #567228: pyqwt5 #567231: gammu #567302: babel python-qt* FTBFSes are likely responsible for some others, so interested people may want to look into those first. P.S. Please cc me on any replies as I am not subscribed to the list. Done. I've also added -python@ in the loop. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#548035: /usr/bin/users-admin: users-admin sets su's path to /home/root
Am 28.01.2010 12:16, schrieb Adam D. Barratt: It's already been accepted, or it wouldn't have made it to proposed-updates at all. Adam, thanks for clarifying. - Fabian -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Introducing symbol versioning in FFmpeg
On Mi, Jan 27, 2010 at 19:52:35 (CET), Adam D. Barratt wrote: On Wed, 2010-01-27 at 07:54 +, Adam D. Barratt wrote: http://release.debian.org/~adsb/ffmpeg_binNMUs.txt is what I believe to be the list of packages potentially needing binNMUs. Excluding those packages which have either had sourceful uploads in the past day or so (e.g. vtk) or have already scheduled or completed binNMUs for python2.6 (e.g. picard) would be useful to avoid duplicated work and builds. The list has now been updated to remove those packages which have had rebuilds since the ffmpeg upload or have outstanding python2.6 binNMUs scheduled for them (and in one case to include a binNMU for one architecture where the python2.6 binNMU completed shortly before ffmpeg was available on that architecture). I guess you are already on it: ffmpeg has transitioned now to testing, so the binNMUs can be scheduled now. In the other news this means that we can now (finally) upload updated ffmpeg snapshots to experimental! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs update for lenny
Adam D. Barratt a...@adam-barratt.org.uk writes: Hi, On Tue, 2010-01-26 at 15:42 +0100, Goswin von Brederlow wrote: I've prepared an ia32-libs update for lenny and Frederik Schueler will sponsor the upload soon. The upload brings ia32-libs back in sync with the packages contained in stable, stable security and stable-proposed-updates. The only other change to the binaries is fixing a broken symlink so ia32-libs works on ia64 at all (#563402). I notice that it's now been uploaded. Unfortunately, it's too late for 5.0.4 so will get reviewed after the point release. Regards, Adam That really sucks. Mark Hymers promised he would (co)maintain ia32-libs and do stable/security updates but no sign of them for 6 month now. Should have given up earlier and do it myself I guess. And I guess I don't have to hurry with ia32-libs-gtk then eigther. Given the number of security fixes and their severity should I send this over to the security team so they will be available before the next point release? Or would they want something that only updates packages with security flaws? MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs update for lenny
On Thu, Jan 28, 2010 at 01:10:28PM +0100, Goswin von Brederlow wrote: That really sucks. Mark Hymers promised he would (co)maintain ia32-libs and do stable/security updates but no sign of them for 6 month now. Should have given up earlier and do it myself I guess. And I guess I don't have to hurry with ia32-libs-gtk then eigther. We do have to do a cut somewhere. Having a fixed package available in p-u could already help. Given the number of security fixes and their severity should I send this over to the security team so they will be available before the next point release? Or would they want something that only updates packages with security flaws? I'd try, however it's up to them to decide. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Ongoing Python Transition: related FTBFSes
On Thu, 28 Jan 2010 at 12:50:24 +0100, Cyril Brulebois wrote: FWIW, here are some FTBFSes I've reported lately, which look due to this transition: [...] ... and for those who care about FTBFSs, the binNMUs of pygtk are also all failing (either due to #548211 or not waiting for python2.6-gobject to be available), which could stall this transition fairly badly. I'm sure the GNOME team would appreciate help with that. S -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ongoing Python Transition: related FTBFSes
Scott Kitterman deb...@kitterman.com (17/12/2009): I believe that we are getting close to uploading Python 2.6 to Unstable and dropping Python 2.4 as a supported Python version. If we finish preparations in the next week, are there any ongoing transitions a python2.6/python- defaults upload would entangle that would cause the release team to want the uploads to be delayed? Hi, I'm not sure it's the proper thread to mention this, but from a quick look, it sounds like related. FWIW, here are some FTBFSes I've reported lately, which look due to this transition: #567220: qscintilla2 #567222: python-qt3 #567224: python-qt4 #567226: pysvn #567227: pyqwt3d #567228: pyqwt5 #567231: gammu #567302: babel python-qt* FTBFSes are likely responsible for some others, so interested people may want to look into those first. P.S. Please cc me on any replies as I am not subscribed to the list. Done. I've also added -python@ in the loop. The solution for python-qt* is a bit complicated, but is in progress. I saw uploads to Experimental that include new tools to better deal with python-sip changes. Scott K -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming potential haskell breakage in testing
Hi, Joachim Breitner wrote, Thu, 28 Jan 2010 12:29:05 +0100 Am Mittwoch, den 27.01.2010, 22:51 + schrieb Adam D. Barratt: The upcoming lenny point release includes a fix to ghc6 to resolve a deadlock issue on 64-bit architectures, together with a number of binNMUs for affected packages on those architectures. [...] a side-effect of the point release will be that the new ghc6 source package and many of the binNMUs will be pushed in to testing from stable; in some cases, the binNMUs will also be propagated to unstable. [...] thanks for the heads up. From my POV, I can see no issues with these uploads. Binaries built from Haskell sources are independent from haskell-libraries and such, therefore, no breakage should occur. Unfortunately, I appear to have missed a few packages from the unstable pov. The extra packages which will also end up being propogated to unstable are: dfsbuild 1.0.2.0+b1 alpha hat 2.05+rerolled-7+b1 alpha hat 2.05+rerolled-7+b1 amd64 hat 2.05+rerolled-7+b1 ia64 helium 1.6-4+b1 ia64 hmake 3.13-0.1+b1 alpha hmake 3.13-0.1+b1 amd64 hmake 3.13-0.1+b1 ia64 libghc6-hat-dev 2.05+rerolled-7+b1 alpha libghc6-hat-dev 2.05+rerolled-7+b1 amd64 libghc6-hat-dev 2.05+rerolled-7+b1 ia64 uuagc 0.9.6-1+b1 alpha uuagc 0.9.6-1+b1 amd64 uuagc 0.9.6-1+b1 ia64 Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On Thursday 28 January 2010, Matthias Klose wrote: On 27.01.2010 23:26, Frans Pop wrote: On Wednesday 27 January 2010, Matthias Klose wrote: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. no, that's wrong. this is only required if the upstream tarball changes, and this is easily discovered by looking at the build dependencies. Right. That reduces the problem a bit. It would mean that migrations of gcc could be blocked until a new gcc-udeb source package is uploaded. That would not be the case if the udebs are built from gcc. I'm still not convinced that the (IMO minor) disadvantages of having a udeb in gcc are sufficient to treat gcc different from all other packages that provide udebs. I would appreciate input from the Release team on this. Could someone please comment? See http://bugs.debian.org/567182#10 and later for most relevant info. Comments from others in the D-I team would also be welcome. Cheers, FJP -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ongoing Python Transition: related FTBFSes
On 28.01.2010 12:50, Cyril Brulebois wrote: Scott Kittermandeb...@kitterman.com (17/12/2009): I believe that we are getting close to uploading Python 2.6 to Unstable and dropping Python 2.4 as a supported Python version. If we finish preparations in the next week, are there any ongoing transitions a python2.6/python- defaults upload would entangle that would cause the release team to want the uploads to be delayed? Hi, I'm not sure it's the proper thread to mention this, but from a quick look, it sounds like related. FWIW, here are some FTBFSes I've reported lately, which look due to this transition: #567226: pysvn that's a wrong report, pycxx needs binNMUed, then the package does build. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
binNMUs for switch in MPI implementations (mpi-defaults)
Dear release team, there were several discussions on debian-science@ about the status of MPI implementations in Debian, the latest starting at [1]. The consensus was that we'd like to get rid of LAM/MPI and MPICH1 in Squeeze+1 since they are no longer cared for upstream and better alternatives exist. We'd like to have them in Squeeze nevertheless, so people have time to switch their applications over. One big step in this effort is to change the mpi-defaults package to no longer use LAM/MPI. We (as in: debian-science) agreed to use MPICH2 on the architectures were Open MPI does not build currently. This would need a binNMU of all packages build-depending on mpi-default-dev, which I'd ask you to do. The mpi-defaults packages is updated in it's Git repository and just needs to be uploaded. I have no clue if this collides with other transitions. I checked [2] but that page was not updated for a long time and I do not know of a different place to get this information. We would very much appreciate if you could schedule the binNMUs, even though the freeze is not too far away. Thanks in advance! Best regards Manuel [1] http://lists.debian.org/debian-science/2009/11/msg00010.html [2] https://buildd.debian.org/transitions/summary.html P.S.: Please keep d-s-m@ or me in the loop. (I'm subscribed on d-...@.) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#564142: RM: rails/2.2.3-1
Moritz Muehlenhoff wrote: On Fri, Jan 08, 2010 at 07:43:11AM +0100, Luk Claes wrote: Moritz Muehlenhoff wrote: Please remove rails. It has open security issues, which haven't been acknowledged for six weeks. removal hint added. It has a few rdeps, which prevent the removal: Indeed, what is the plan? Did you contact these maintainers and do they all agree with removal? Cheers Luk Checking reverse dependencies... # Broken Depends: activeldap: libactiveldap-ruby1.8 camping: camping libbarby-ruby: libbarby-ruby1.8 libfeedtools-ruby: libfeedtools-ruby1.8 librqrcode-ruby: librqrcode-ruby1.8 librqrcode-ruby1.9 libwill-paginate-ruby: libwill-paginate-ruby1.8 redmine: redmine Dependency problem found. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has ch anged in GCC 4.4
Modestas Vainius wrote:
I have recently came across .symver directive [1][2] that is more
straightforward way to achieve the same thing. In that case, only source file
(.cpp) needs to be changed.
Brilliant! This shall be the plan then:
1) identify affected libraries (Jakubs list as base?)
2) provide patches for the libraries and submit them to BTS
3) give maintainers X days to MU the libraries, after that proceed to
NMU them
4) binNMU any packages using the functions with va_list parameters
5) release squeeze ;)
6) tell maintainers they are free to drop the symbol alias
Sounds ok to everyone?
For example:
---
$ cat test.h
void myprint(const char* fmt, va_list list);
$ cat libtest.cpp
#include cstdarg
#include test.h
void myprint(const char* fmt, va_list list) {
}
// va_list mangling has been changed in g++ 4.4
// Add ABI = g++-4.3 compatibility hack
#if defined __ARM_EABI__ defined __GNUC__ (__GNUC__ 4 || __GNUC__ == 4
__GNUC_MINOR__ = 4)
__asm__(.symver _Z7myprintPKcSt9__va_list, _Z7myprintPKcPv@@);
#endif
---
_Z7myprintPKcSt9__va_list ( myprint(char const*, std::__va_list) )
here is the new mangling while _Z7myprintPKcPv ( myprint(char const*, void*)
) is the old mangling. When this code is built under g++-4.4, the resulting
binary will have both symbols with _Z7myprintPKcPv and
'_Z7myprintPKcSt9__va_list' referring to the same address:
$ objdump -T libtest.so | grep _Z7myprint
06d8 gDF .text 0058 Base_Z7myprintPKcSt9__va_list
06d8 gDF .text 0058 Base_Z7myprintPKcPv
1. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-
assembler/symver.html
2. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-
linker/version.html
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Ongoing Python Transition: related FTBFSes
Matthias Klose wrote: On 28.01.2010 12:50, Cyril Brulebois wrote: Scott Kittermandeb...@kitterman.com (17/12/2009): I believe that we are getting close to uploading Python 2.6 to Unstable and dropping Python 2.4 as a supported Python version. If we finish preparations in the next week, are there any ongoing transitions a python2.6/python- defaults upload would entangle that would cause the release team to want the uploads to be delayed? Hi, I'm not sure it's the proper thread to mention this, but from a quick look, it sounds like related. FWIW, here are some FTBFSes I've reported lately, which look due to this transition: #567226: pysvn that's a wrong report, pycxx needs binNMUed, then the package does build. pycxx is an Architecture: all package and cannot be binNMUed as such, so a sourceful upload is required. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564142: RM: rails/2.2.3-1
On Fri, Jan 08, 2010 at 07:43:11AM +0100, Luk Claes wrote: Moritz Muehlenhoff wrote: Please remove rails. It has open security issues, which haven't been acknowledged for six weeks. removal hint added. It has a few rdeps, which prevent the removal: Checking reverse dependencies... # Broken Depends: activeldap: libactiveldap-ruby1.8 camping: camping libbarby-ruby: libbarby-ruby1.8 libfeedtools-ruby: libfeedtools-ruby1.8 librqrcode-ruby: librqrcode-ruby1.8 librqrcode-ruby1.9 libwill-paginate-ruby: libwill-paginate-ruby1.8 redmine: redmine Dependency problem found. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the mangling of ‘va_list’ has changed in GCC 4.4
Hello, On ketvirtadienis 28 Sausis 2010 21:37:15 Riku Voipio wrote: Brilliant! This shall be the plan then: 1) identify affected libraries (Jakubs list as base?) 2) provide patches for the libraries and submit them to BTS 3) give maintainers X days to MU the libraries, after that proceed to NMU them 4) binNMU any packages using the functions with va_list parameters 5) release squeeze ;) 6) tell maintainers they are free to drop the symbol alias 1. Step 4 is optional and can be skipped. 2. WRT step 6, I don't think it is correct. Maintainer may only drop the alias when changing the name of the affected library package (most likely due to soname change). This step is not related to squeeze release. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Re: binNMUs for switch in MPI implementations (mpi-defaults)
Manuel Prinz wrote: One big step in this effort is to change the mpi-defaults package to no longer use LAM/MPI. We (as in: debian-science) agreed to use MPICH2 on the architectures were Open MPI does not build currently. Is there some work ongoing to make Open MPI more portable or add the atomic asm instructions for more archs? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Uploading linux-2.6
On Mon, 2010-01-25 at 20:19 +0100, Andreas Barth wrote: * Ben Hutchings (b...@decadent.org.uk) [100125 20:14]: On Mon, Jan 25, 2010 at 08:02:31PM +0100, Andreas Barth wrote: * Julien Cristau (jcris...@debian.org) [100125 19:27]: On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote: I guess this means that the next version is no candidate for the release unless it gets a stable ABI (versioning) and should block the kernel from migrating for the time being? The 2.6.30 kernel and the current 2.6.32 one aren't candidates either, so I'm not sure what difference blocking the next one makes. That our testing users don't have to life with strange error messages they wouldn't get if the abi would be bumped properly. OK, maybe we should start numbering ABIs with this next version. I'd appreciate that very much. There has been some argument over whether we should do this or not. Bastian and Max seem to think that many more ABI-changing config changes will still be needed and do not want to start numbering yet. I'm not convinced that changing the ABI number repeatedly in testing/unstable will even hurt that much since we no longer have to worry about dependent module packages in the archive. It may add to cruft on users' systems but this can be fixed after a reboot with 'apt-get autoremove'. I do want to see this argument resolved before building and uploading, but I also don't want to hold back security and stability fixes. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part
Re: Uploading linux-2.6
On Thu, Jan 28, 2010 at 10:50:16PM +, Ben Hutchings wrote: On Mon, 2010-01-25 at 20:19 +0100, Andreas Barth wrote: * Ben Hutchings (b...@decadent.org.uk) [100125 20:14]: On Mon, Jan 25, 2010 at 08:02:31PM +0100, Andreas Barth wrote: * Julien Cristau (jcris...@debian.org) [100125 19:27]: On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote: I guess this means that the next version is no candidate for the release unless it gets a stable ABI (versioning) and should block the kernel from migrating for the time being? The 2.6.30 kernel and the current 2.6.32 one aren't candidates either, so I'm not sure what difference blocking the next one makes. That our testing users don't have to life with strange error messages they wouldn't get if the abi would be bumped properly. OK, maybe we should start numbering ABIs with this next version. I'd appreciate that very much. There has been some argument over whether we should do this or not. Bastian and Max seem to think that many more ABI-changing config changes will still be needed seems likely and do not want to start numbering yet. I'm not convinced that changing the ABI number repeatedly in testing/unstable will even hurt that much since we no longer have to worry about dependent module packages in the archive. It may add to cruft on users' systems but this can be fixed after a reboot with 'apt-get autoremove'. yeah, i think people running sid/testing who do use oot modules shouldn't have much problem w/ frequent module rebuilds - esp if the abi is silently changing and they may really need to rebuild anyway. [Like with a module on my mythbox recently :)] I do want to see this argument resolved before building and uploading, but I also don't want to hold back security and stability fixes. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
