Re: [SRM] dpkg 1.15.8.11 for squeeze
Hi! On Mon, 2011-04-25 at 16:24:28 +0100, Adam D. Barratt wrote: On Sun, 2011-04-17 at 07:38 +0200, Guillem Jover wrote: [ Guillem Jover ] * Do not segfault on “dpkg -i --no-act”. * Add missing semicolon to the vsnprintf() compat declaration. Thanks to Robert Millan. Closes: #612203 * Fix typo in «dpkg-name --overwrite» argument parsing so that it actually works at all. Thanks to Ivan Gagis iga...@gmail.com. LP: #728708 * Fix dpkg-split to not corrupt binary part metadata when generating the split packages on 32-bit systems. [ Raphaël Hertzog ] * Fix a regression in dpkg-divert where using --rename led to a failure when the rename implies crossing file systems. Thanks to Durk Strooisma for spotting it. Assuming that the package has been tested in a Squeeze environment, please go ahead; thanks. Yes it had been tested on squeeze, but just to make sure, I manually tested the changes again and run the functional test-suite on a clean chroot. The packages are being uploaded right now. thanks, guillem -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426073927.ga28...@gaara.hadrons.org
Re: sh4 architecture into Wheezy
On Tue, Apr 26, 2011 at 12:58:24PM +0900, Nobuhiro Iwamatsu wrote: We don't have faster hardware. We think of a too slow thing in a question A test of gcc of sh4 takes time. When there is not a test, a package is done in about two days. How does sh4 become targeted for the release architecture? Can sh4 disable gcc test? I woudn't be particularly happy with that unless the gcc maintainers ok it, and I'm still not sure that two days is also an acceptable timescale. Have you tried a SH4A with a dual core? At the moment, I think that this issue is severe enough that it can't be a release architecture. (Note that if it is solved, there may be other problems, but we can get to those later.) Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426073922.gc7...@feta.halon.org.uk
Updating debian/control at build time
Hi, I have a policy question: I'm working on various PostgreSQL extension packages that all build several postgresql-foo-$version packages (where $version is 8.4 and 9.0 atm). We have infrastructure for that in postgresql-server-dev-all called pg_buildext, but that wasn't used at all until recently. I'm working with the author to fix that :) In /usr/share/postgresql-common/pgxs_debian_control.mk, there is a debian/rules snippet that updates debian/control from debian/control.in. For every version, all packages containing PGVERSION in their name are instantiated; the source stanza and non-PGVERSION packages are not modified. The list of versions is the intersection of debian/pgversions and what /usr/share/postgresql-common/supported-versions outputs. # # produce a debian/control file from a debian/control.in # # In debian/rules, include /usr/share/postgresql-common/pgxs_debian_control.mk # build: debian/control # # Author: Dimitri Fontaine dfonta...@hi-media.com # debian/control: debian/control.in debian/pgversions grep-dctrl -vP PGVERSION $ $@ for v in `pg_buildext supported-versions $(SRCDIR)`; \ do \ grep -q ^$$v debian/pgversions \ grep-dctrl -P PGVERSION $ \ | sed -e s:PGVERSION:$$v: $@; \ done (I think clean: debian/control is the better place to put the dependency, but this doesn't matter for the question.) What happens is: * Once supported-versions drops versions, packages will disappear from debian/control * If debian/pgversion lists versions not yet supported, these packages will appear as soon supported-versions add them. As the set of possible packages is under maintainer control via debian/pgversion, I think this works as intended, namely making adding/removing PG versions binnum'able. As this might cause surprises for buildds suddenly building a different set of packages, it might not be desirable for others. What do the release people think about that? The alternative would be to make the control update a manual step. Christoph (PS: #311724 is similar, but a different section in debian/control.) -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
EXPO Postgrados y MBA - Inscripción gratuita
Este e-mail es solo para recordarte que el último evento exclusivo de Postgrados y MBA en el exterior del año, será el próximo 4 de Mayo. Inscríbete ahora. Inscripción gratuita: http://www.expo-postgrados.com/feria2011 Este evento solo es una vez por año, y es la mejor oportunidad que tienes para conocer personalmente excelentes opciones de Postgrados y MBA en el extranjero. No dejes de visitar la EXPO Posgrados MBA, el próximo 2 de Mayo en México D.F.. Inscríbete ahora. Inscripción gratuita: http://www.expo-postgrados.com/feria2011 Recuerda que la entrada es gratuita y te pedimos que solo te registres si realmente pretendes visitar el evento. Este año la EXPO Posgrados MBA, trae decenas de programas diferentes en varios países. TODOS, Postgrados y Maestrías. No te lo pierdas! Atentamente El equipo de la EXPO Posgrados MBA http://www.expo-postgrados.com/feria2011 Si no quieres recibir mas e-mails de www.expo-postgrados.com, envía un e-mail con asunto ''Remover'' para e...@expo-postgrados.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ntvm26i4w3sgt404cfn3...@ntvm2.valemassa.net
Re: Updating debian/control at build time
On Tue, Apr 26, 2011 at 13:51:53 +0200, Christoph Berg wrote: The alternative would be to make the control update a manual step. That sounds much better to me. You'd need to have an appropriate versioned build-dep on postgresql-server-dev-all anyway, AIUI, which has to be a manual step... Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426134403.gz2...@radis.liafa.jussieu.fr
Re: sh4 architecture into Wheezy
On 04/26/2011 09:39 AM, Neil McGovern wrote: I woudn't be particularly happy with that unless the gcc maintainers ok it, and I'm still not sure that two days is also an acceptable timescale. then please drop mips and mipsel as release architectures. At least sh4 has a workable, accessible developer machine, and people within Debian who care about the architecture. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6d993.3010...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be used for the next Fedora and OpenSuse releases, and a test rebuild of Ubuntu natty doesn't look too bad (mostly adding new easily fixable C++ build failures). A test rebuild of the unstable archive is still outstanding, but these build failures will have to be fixed anyway. From my point of view it's important to expose GCC 4.6 early in the release cycle to fix issues like #617628 (which are issues in the packages itself) now. With GCC 4.6 comes one soname change, bumping the libobjc version from 2 to 3, which is not easily detachable from the GCC version change. However this change only affects GNUstep, which can be dealt with NMU's, or migration to a new GNUstep version. It's unlikely that GCC 4.5 will be released with wheezy, as the Debian Ada and D maintainers are already working on GCC 4.6 support. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6dea5.5010...@debian.org
Re: Updating debian/control at build time
Julien Cristau jcris...@debian.org writes:
On Tue, Apr 26, 2011 at 13:51:53 +0200, Christoph Berg wrote:
The alternative would be to make the control update a manual step.
That sounds much better to me. You'd need to have an appropriate
versioned build-dep on postgresql-server-dev-all anyway, AIUI, which has
to be a manual step...
There's a missing point here, I think.
PostgreSQL upstream project maintains up to 7 back branches at any time,
currently the last updates are 9.0.4, 8.4.8, 8.3.15 and 8.2.21. 8.2
will not be dropped just when 9.1 gets out the door, either, see
http://www.postgresql.org/support/versioning
http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy
The point I'm trying to make is that the choice made by debian to only
support one major version of PostgreSQL in any stable release bears only
little meaning. People using PostgreSQL to support their internal
application architecture will not typically upgrade it when they upgrade
their distribution (say, from lenny to squeeze).
Also, extensions are made so that they can support several major
versions from the same unmodified sources. That's quite easy to do and
very handy for everybody involved.
The conclusion is that we should make it as easy as possible for people
to maintain their own backports of any PostgreSQL extension we include
in debian. That means they should not have to edit the packaging if
that make sense.
Also please consider that I've been volunteering to manage an apt
repository hosted on the PostgreSQL side of things, where all upstream
supported major versions would be maintained as a debian package. I
would of course include PostgreSQL extensions over there. I would like
to have an automated way to handle all of this, of course.
So to build the following binary packages, I would like not to have to
edit anything, but to just run debuild once.
postgresql-8.2-{prefix,preprepare,ip4r,temporal,plproxy,younameit}
postgresql-8.3-{prefix,preprepare,ip4r,temporal,plproxy,younameit}
postgresql-8.4-{prefix,preprepare,ip4r,temporal,plproxy,younameit}
postgresql-9.0-{prefix,preprepare,ip4r,temporal,plproxy,younameit}
postgresql-9.1-{prefix,preprepare,ip4r,temporal,plproxy,younameit}
That's what the pg_buildext tool is all about, with debian/pgversions
containing all upstream releases supported by the extension sources, and
the supported-version script that will only output the debian supported
ones, but will add to the list any version you have installed locally.
Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2liyx6pch@hi-media.com
Re: Updating debian/control at build time
Re: Julien Cristau 2011-04-26 20110426134403.gz2...@radis.liafa.jussieu.fr On Tue, Apr 26, 2011 at 13:51:53 +0200, Christoph Berg wrote: The alternative would be to make the control update a manual step. That sounds much better to me. You'd need to have an appropriate versioned build-dep on postgresql-server-dev-all anyway, AIUI, which has to be a manual step... Sorry, forgot to mention that here: postgresql-server-dev-all should depend on all -version packages too for this to make sense. (I don't see the need for a bumped versioned dependency on postgresql-server-dev-all itself - we don't do that for other binnmus either and just hope the buildds have the most recent version of the lib in question.) Re much better - how cool or evil is the idea? Thinking about it, we could actually put all versions supported into debian/control, and just not build the binaries. That wouldn't help Dimitri's case of build-for-everything (unless we put in 7 versions), but if it makes Debian happy, be it so. I'd still prefer an more or less official answer to the original question :) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: GCC-4.5 as the default for (at least some) architectures
On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? Thanks Konstantinos -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimddKkTaiy1fyka6zMOj0o1YzBS=a...@mail.gmail.com
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote: On 26 April 2011 18:03, Matthias Klosed...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? yes, forgot about that. with GCC 4.6, armhf is built again from the 4.6 fsf branch, and lets us drop the GCC 4.5 Linaro variant. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6eb11.2080...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis mar...@genesi-usa.com wrote: On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package: https://buildd.debian.org/status/package.php?p=vxl but since there is no log I cannot confirm this is the same ICE as on i386/armel thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com
Re: sh4 architecture into Wheezy
On Tue, Apr 26, 2011 at 16:41:23 +0200, Matthias Klose wrote: On 04/26/2011 09:39 AM, Neil McGovern wrote: I woudn't be particularly happy with that unless the gcc maintainers ok it, and I'm still not sure that two days is also an acceptable timescale. then please drop mips and mipsel as release architectures. At least sh4 has a workable, accessible developer machine, and people within Debian who care about the architecture. It turns out the criteria for adding an architecture and those for removing one aren't exactly the same. Which is good, as it means we're not adding and removing an architecture every couple of weeks depending on a couple porters free time or random hardware issues. Not saying mips and mipsel state is good, just that you should stop the nonsense. Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426163359.gb2...@radis.liafa.jussieu.fr
Re: Updating debian/control at build time
Hi, Am Dienstag, den 26.04.2011, 17:41 +0200 schrieb Christoph Berg: I'd still prefer an more or less official answer to the original question :) I’m also interested in that, as we have a lot of duplication across the debian/control files of haskell packages and if there is a chance for policy-compliant automation, I’d like to hear about it. One problem with not hard-coding the names of the built packages in debian/control is that dpkg-buildpackage -S is still supposed to list the names of generated binaries in the .dsc file. 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: This is a digitally signed message part
Re: [SRM] dpkg 1.15.8.11 for squeeze
On Tue, 2011-04-26 at 09:39 +0200, Guillem Jover wrote: Hi! On Mon, 2011-04-25 at 16:24:28 +0100, Adam D. Barratt wrote: Assuming that the package has been tested in a Squeeze environment, please go ahead; thanks. Yes it had been tested on squeeze, but just to make sure, I manually tested the changes again and run the functional test-suite on a clean chroot. The packages are being uploaded right now. I've flagged the upload for acceptance at the next dinstall; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303842446.13581.45.ca...@hathi.jungle.funky-badger.org
Re: Updating debian/control at build time
Hallo Joachim, am Tue, Apr 26, 2011 at 10:24:30PM +0530 hast du folgendes geschrieben: Am Dienstag, den 26.04.2011, 17:41 +0200 schrieb Christoph Berg: I'd still prefer an more or less official answer to the original question :) I’m also interested in that, as we have a lot of duplication across the debian/control files of haskell packages and if there is a chance for policy-compliant automation, I’d like to hear about it. One problem with not hard-coding the names of the built packages in debian/control is that dpkg-buildpackage -S is still supposed to list the names of generated binaries in the .dsc file. preparing a debian/control file with scripts pre dpkg-buildpackage producing a source package is fine. Modifying it during a binary build isn't. 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
Bug#623529: pu: package git/1:1.7.2.5-2
tag 623529 + confirmed thanks On Mon, 2011-04-25 at 12:38 -0500, Jonathan Nieder wrote: Adam D. Barratt wrote: On Wed, 2011-04-20 at 17:58 -0500, Jonathan Nieder wrote: -sv force-stop git-daemon 2/dev/null || : +sv force-shutdown /etc/sv/git-daemon 2/dev/null || : Is the switch from git-daemon to /etc/sv/git-daemon here intentional? Yes, sv will not control a removed service unless passed the full path /etc/sv/git-daemon. Okay; thanks for the explanation. Please feel free to go ahead with the upload. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303842583.13581.56.ca...@hathi.jungle.funky-badger.org
Processed: Re: Bug#623529: pu: package git/1:1.7.2.5-2
Processing commands for cont...@bugs.debian.org: tag 623529 + confirmed Bug #623529 [release.debian.org] pu: package git/1:1.7.2.5-2 Added tag(s) confirmed. thanks Stopping processing here. Please contact me if you need assistance. -- 623529: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623529 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13038425993841.transcr...@bugs.debian.org
Re: sh4 architecture into Wheezy
On Tue, Apr 26, 2011 at 04:41:23PM +0200, Matthias Klose wrote: On 04/26/2011 09:39 AM, Neil McGovern wrote: I woudn't be particularly happy with that unless the gcc maintainers ok it, and I'm still not sure that two days is also an acceptable timescale. then please drop mips and mipsel as release architectures. At least What is your problem about MIPS? Why do you insist about dropping it? At least be fair and don't spread FUD. GCC on mips/mipsel build in less than 2 days on the recent build machines. It's true that the build time is slightly higher than other architectures, but the testsuite is done on 3 different ABIs. This is something that can be tweaked, as suggested for SH4. Here are the average build time for gcc-4.* since the release of Squeeze [1]: | mips | mipsel | +++ gcc-4.3 | 42864 | 141863 | gcc-4.4 | 104400 | 149148 | gcc-4.5 | 123498 | 114435 | gcc-4.6 | 95725 | 167799 | The build time dispersion is explained by the fact we have buildds of different speed, gcc-* is built by default on them (no_weak_autobuild), unless this build daemon is already busy. sh4 has a workable, accessible developer machine, mips also has an accessible developer machine, gabrielli.debian.org. It's true that mipsel doesn't have one (it's being working on), that said, most issues are reproducible on both. People can also ask on debian-mips for help in case it's a mipsel specific issue. and people within Debian who care about the architecture. MIPS also has Debian people who care about the architecture. See for example my recent MIPS work: http://svn.debian.org/wsvn/kernel/?op=compcompare%5B%5D=%2Fdists%2Fsid%2Flinux-2.6%2Fdebian@17159compare%5B%5D=%2Fdists%2Fsid%2Flinux-2.6%2Fdebian@17161 http://svn.debian.org/wsvn/gcccvs/?op=compcompare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.6%2Fdebian@5248compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.6%2Fdebian@5262 http://svn.debian.org/wsvn/gcccvs/?op=compcompare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.5%2Fdebian@5263compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.5%2Fdebian@5267 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623014 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623015 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623162 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623598 http://lists.debian.org/debian-mips/2011/04/msg3.html http://lists.debian.org/debian-mips/2011/04/msg00018.html http://sourceware.org/bugzilla/show_bug.cgi?id=12606 All that said, I agree that mips and mipsel architectures are not in their best shape, but people are working on that. If you consider they don't follow the release criteria, please give objective arguments. Aurelien [1] select package, avg(build_time) from mips.pkg_history where package like 'gcc-4%' and result='successful' and timestamp '2011-02-13' group by package; select package, avg(build_time) from mipsel.pkg_history where package like 'gcc-4%' and result='successful' and timestamp '2011-02-13' group by package; -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426185104.gb29...@hall.aurel32.net
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426192857.ga10...@roeckx.be
Re: GCC-4.5 as the default for (at least some) architectures
Matthias Klose dixit: At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes Porters side, too. I’m okay with keeping gcc-4.4 for a while (kernel?) and switching to gcc-4.6 directly for m68k. I know I’ll probably have to invest some work into the latter, but considering the kernel problem is almost solved, chances are good. (I do want to bring out a new base emulator image first, though, but then…) bye, //mirabilos -- 13:47⎜tobiasu if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org
NEW changes in proposedupdates
Processing changes file: dpkg_1.15.8.11_amd64.changes ACCEPT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qeooh-0002rv...@franck.debian.org
Re: GCC-4.5 as the default for (at least some) architectures
Kurt Roeckx, le Tue 26 Apr 2011 21:28:57 +0200, a écrit : Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? There's no real reason to defer hurd-i386, as it's basically like i386, and the key packages (glibc/hurd/gnumach) already use a fixed version and can be handled independently. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426204147.gs4...@const.famille.thibault.fr
Re: sh4 architecture into Wheezy
On 04/26/2011 08:36 PM, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 04:41:23PM +0200, Matthias Klose wrote: On 04/26/2011 09:39 AM, Neil McGovern wrote: I woudn't be particularly happy with that unless the gcc maintainers ok it, and I'm still not sure that two days is also an acceptable timescale. then please drop mips and mipsel as release architectures. At least What is your problem about MIPS? Why do you insist about dropping it? At least be fair and don't spread FUD. GCC on mips/mipsel build in less than 2 days on the recent build machines. It's true that the build time is slightly higher than other architectures, but the testsuite is done on 3 different ABIs. This is something that can be tweaked, as suggested for SH4. Here are the average build time for gcc-4.* since the release of Squeeze [1]: | mips | mipsel | +++ gcc-4.3 | 42864 | 141863 | gcc-4.4 | 104400 | 149148 | gcc-4.5 | 123498 | 114435 | gcc-4.6 | 95725 | 167799 | gcc-4.6: 167799/3600 = 46.61, and this is with the libstdc++ testsuite already disabled, because it did timeout or fail on the mipsel buildds. So this is *no* FUD. Did you look at the build failures, or some other mips porter, before I did disable the tests? The build time dispersion is explained by the fact we have buildds of different speed, gcc-* is built by default on them (no_weak_autobuild), unless this build daemon is already busy. sh4 has a workable, accessible developer machine, mips also has an accessible developer machine, gabrielli.debian.org. It's true that mipsel doesn't have one (it's being working on), that said, most issues are reproducible on both. People can also ask on debian-mips for help in case it's a mipsel specific issue. and people within Debian who care about the architecture. MIPS also has Debian people who care about the architecture. See for example my recent MIPS work: http://svn.debian.org/wsvn/kernel/?op=compcompare%5B%5D=%2Fdists%2Fsid%2Flinux-2.6%2Fdebian@17159compare%5B%5D=%2Fdists%2Fsid%2Flinux-2.6%2Fdebian@17161 http://svn.debian.org/wsvn/gcccvs/?op=compcompare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.6%2Fdebian@5248compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.6%2Fdebian@5262 http://svn.debian.org/wsvn/gcccvs/?op=compcompare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.5%2Fdebian@5263compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.5%2Fdebian@5267 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623014 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623015 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623162 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623598 http://lists.debian.org/debian-mips/2011/04/msg3.html http://lists.debian.org/debian-mips/2011/04/msg00018.html http://sourceware.org/bugzilla/show_bug.cgi?id=12606 yes, the last one incomplete and only completed by myself. So who else is doing toolchain work on mips in Debian? Thiemo did leave a big gap, and it was an effort of many people to release squeeze with mips. I just see that All that said, I agree that mips and mipsel architectures are not in their best shape, but people are working on that. If you consider they don't follow the release criteria, please give objective arguments. the build time argument was brought up by the debian-release team, so this this seems to be an objective argument. If not, maybe the release criteria for new, current and obsolet ports should be made more transparent. I'm only aware of one table not differentiating new and current ports. yes, other issues are the non-availabilty of a mipsel porter box and the instability of the existing mips porter box. and toolchain maintenance was rather difficult (longsoon, binutils) during the squeeze cycle. Matthias Please note that this thread did start about sh4, and some comments about the sh4 toolchain by some members of the release team, which apply for mips* too, and which are used against the sh4 port. I appreciate your work on mips, but I think a lot more needs to be done to keep it as a release architecture, and that arguments that are overlooked by intent for existing release architectures should not be used against a new port. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db7391c.6040...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 09:28 PM, Kurt Roeckx wrote: On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I don't know, and I will not invest time to check. If you did check, and if you are confident to fix issues on these architectures, then please tell here. At least for other ports this seems to be possible (s390: Bastian Blank, kfreebsd-*: Aurelian, Petr). I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. I will not work on toolchain issues specific to these architectures for the wheezy release, so if nobody steps forward, then at least I will not change the default for these architectures. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db73b0c.4000...@debian.org
