Re: Stable update of linux-2.6
* Ben Hutchings b...@decadent.org.uk [2011-03-30 00:11:59]: On Tue, 2011-03-29 at 23:26 +0100, Adam D. Barratt wrote: On Sun, 2011-03-27 at 20:31 +0100, Ben Hutchings wrote: There were a couple of regressions in linux-2.6 version 2.6.32-31 (i.e. Debian 6.0.1) that should be fixed a.s.a.p: [...] Either Dann or I will upload an update to stable-proposed-updates, intended for early release through stable-updates. Unfortunately, the powerpc build reproducibly FTBFS: Introduced by: commit 4d4d502715479044f02ae7464474bbb615b2d158 Author: Michael Neuling mi...@neuling.org Date: Thu May 13 19:40:11 2010 + powerpc/kdump: Fix race in kdump shutdown commit 60adec6226bbcf061d4c2d10944fced209d1847d upstream. The new function crash_kexec_wait_realmode() is only defined if CONFIG_SMP is defined, but is used unconditionally. Of course, this was quickly fixed upstream: commit c2be05481f6125254c45b78f334d4dd09c701c82 Author: Paul E. McKenney paul...@linux.vnet.ibm.com Date: Tue Jun 15 14:48:39 2010 + powerpc: Fix default_machine_crash_shutdown #ifdef botch but that doesn't appear to have been sent to stable. Ben. CC arch/powerpc/kernel/crash.o /build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/source_powerpc_none/arch/powerpc/kernel/crash.c: In function 'default_machine_crash_shutdown': /build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/source_powerpc_none/arch/powerpc/kernel/crash.c:448: error: implicit declaration of function 'crash_kexec_wait_realmode' make[6]: *** [arch/powerpc/kernel/crash.o] Error 1 make[5]: *** [arch/powerpc/kernel] Error 2 make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/build_powerpc_none_powerpc' make[2]: *** [debian/stamps/build_powerpc_none_powerpc_plain] Error 2 make[1]: *** [build_powerpc_none_powerpc_real] Error 2 make[2]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32' make: make[1]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32' *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 snip Thanks for testing, I have added smp=n to my powerpc build test bucket. The upstream commit c2be05481f fixes the issues based upon the upstream commit b3df895aebe0, latter commit is not available in the 2.6.32-stable tree. The patch below introduces only the partial changes introduced by Paul McKenney's patch. Greg can you please pull the patch into 2.6.32-stable. powerpc: Fix default_machine_crash_shutdown #ifdef build failure Introducing #ifdef to fix the build failure caused by crash_kexec_wait_realmode(), with powerpc build with !SMP. Reported-by: Ben Hutchings b...@decadent.org.uk Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com cc: Paul E. McKenney paul...@linux.vnet.ibm.com cc: Michael Neuling mi...@neuling.org cc: Benjamin Herrenschmidt b...@kernel.crashing.org cc: Anton Blanchard an...@samba.org --- arch/powerpc/kernel/crash.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c index fe02e71..6ff7701 100644 --- a/arch/powerpc/kernel/crash.c +++ b/arch/powerpc/kernel/crash.c @@ -445,7 +445,9 @@ void default_machine_crash_shutdown(struct pt_regs *regs) crash_kexec_prepare_cpus(crashing_cpu); cpu_set(crashing_cpu, cpus_in_crash); crash_kexec_stop_spus(); +#ifdef CONFIG_SMP crash_kexec_wait_realmode(crashing_cpu); +#endif if (ppc_md.kexec_cpu_down) ppc_md.kexec_cpu_down(1, 0); } Kamalesh -- 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/20110330084109.ga8...@linux.vnet.ibm.com
Please binNMU gnotime against newer libgtkhtml
Hello, The version of gnotime currently available in the archive was built against an older version of libgtkhml3.14, which makes it not installable with the current (3.32.2-1) version of this library. Thus I'm requesting a binNMU to fix this. nmu gnotime_2.3.1~snapshot20091119-3 . ALL . -m Rebuild against libgtkhml3.14 3.32 (Closes: #618846) Thanks. -- 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/20110330121908.GA32652@miro
Re: Stable update of linux-2.6
On Wed, 2011-03-30 at 14:11 +0530, Kamalesh Babulal wrote: * Ben Hutchings b...@decadent.org.uk [2011-03-30 00:11:59]: On Tue, 2011-03-29 at 23:26 +0100, Adam D. Barratt wrote: On Sun, 2011-03-27 at 20:31 +0100, Ben Hutchings wrote: There were a couple of regressions in linux-2.6 version 2.6.32-31 (i.e. Debian 6.0.1) that should be fixed a.s.a.p: [...] Either Dann or I will upload an update to stable-proposed-updates, intended for early release through stable-updates. Unfortunately, the powerpc build reproducibly FTBFS: Introduced by: commit 4d4d502715479044f02ae7464474bbb615b2d158 Author: Michael Neuling mi...@neuling.org Date: Thu May 13 19:40:11 2010 + powerpc/kdump: Fix race in kdump shutdown commit 60adec6226bbcf061d4c2d10944fced209d1847d upstream. The new function crash_kexec_wait_realmode() is only defined if CONFIG_SMP is defined, but is used unconditionally. [...] Thanks for testing, I have added smp=n to my powerpc build test bucket. [...] Thanks, that will be helpful. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Please binNMU gnotime against newer libgtkhtml
On Wed, Mar 30, 2011 at 12:19:08 +, Goedson Teixeira Paix�o wrote: Hello, The version of gnotime currently available in the archive was built against an older version of libgtkhml3.14, which makes it not installable with the current (3.32.2-1) version of this library. Thus I'm requesting a binNMU to fix this. nmu gnotime_2.3.1~snapshot20091119-3 . ALL . -m Rebuild against libgtkhml3.14 3.32 (Closes: #618846) Err. No. Only amd64 (the package you uploaded) is affected. I'll schedule that one. 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/20110330125318.gm3...@radis.liafa.jussieu.fr
Re: Bug#619990: developers-reference: Update of merkel.d.o URLs
Le Wed, Mar 30, 2011 at 07:55:39AM +0200, Raphael Hertzog a écrit : On Wed, 30 Mar 2011, Charles Plessy wrote: If you want to see more details, you can look it up on -filenamemerkel:/org/ftp-debian-org;/testing/update_out//filename (or -in filenamemerkel:~aba/testing/update_out/filename to see a setup with -a smaller packages file). Via web, it's at ulink +filenameries:/srv/release.debian.org/www/britney/update_output//filename. Please use the web URL (http://ftp-master-host;/testing/update_out/), it's much more stable convenient than this path on a Debian machine. +Via web, it's at ulink url=http://ftp-master-host;/testing/update_out_code/;/ulink. Please drop this link. It's really of no use to point people to britney's code (note it's not the web version of the above link...). Et voilà ! (attached). -- Charles Index: pkgs.dbk === --- pkgs.dbk (révision 8599) +++ pkgs.dbk (copie de travail) @@ -2596,11 +2596,8 @@ before or after this main run, depending on the exact type. /para para -If you want to see more details, you can look it up on -filenamemerkel:/org/ftp-debian-org;/testing/update_out//filename (or -in filenamemerkel:~aba/testing/update_out/filename to see a setup with -a smaller packages file). Via web, it's at ulink -url=http://ftp-master-host;/testing/update_out_code/;/ulink. +If you want to see more details, you can look it up on ulink +url=http://ftp-master-host;/testing/update_output/;/ulink. /para para The hints are available via ulink Index: resources.dbk === --- resources.dbk (révision 8599) +++ resources.dbk (copie de travail) @@ -260,9 +260,6 @@ the Bug Tracking System (BTS). /para para -It is restricted; a mirror is available on literalmerkel/literal. -/para -para If you plan on doing some statistical analysis or processing of Debian bugs, this would be the place to do it. Please describe your plans on email-debian-devel; before implementing anything, however, to @@ -278,7 +275,7 @@ end up on this server, see xref linkend=upload/. /para para -It is restricted; a mirror is available on literalmerkel/literal. +It is restricted; a mirror is available on literalftp-master-mirror;/literal. /para para Problems with the Debian FTP archive generally need to be reported as bugs Index: common.ent === --- common.ent (révision 8599) +++ common.ent (copie de travail) @@ -37,7 +37,7 @@ !ENTITY ftp-upload-host ftp.upload.debian.org !ENTITY ftp-eu-upload-host ftp.eu.upload.debian.org !ENTITY ssh-upload-host ssh.upload.debian.org -!ENTITY ftp-master-mirror merkel.debian.org +!ENTITY ftp-master-mirror ries.debian.org !ENTITY upload-queue /pub/UploadQueue/ !ENTITY url-debian-policy http://www-debian-org;/doc/debian-policy/;
Re: sh4 architecture into Wheezy
On Wed, Mar 30, 2011 at 02:05:52PM +0900, Nobuhiro Iwamatsu wrote: Dear release team. We(sh4 porting team) are now trying to run Debian on Renesas SH(sh4) CPU. http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4 We want to support sh4 by the next release (Wheezy). - Buildd status Currentry, we are finished with build with packages of about 90%. http://buildd.debian-ports.org/stats/sh4.txt http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4priority= - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? If I have say go ahead!, we will start work with DSA, buildd team, security team and ftp-master team. Hi Nobuhiro, A few questions: You say there is many user waiting for port to Debian in the wiki page listed. How many is many? What are the future prospects for sh4? It seems that STM are concentrating on ARM-based cores for future products... -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/20110330131748.go7...@einval.com
Re: Suggestion to include old firewire stack
On Wed, Mar 30, 2011 at 01:26:55 +0600, Евгений Кабиольский wrote: Hi Is it able to include old firewire stack into next kernel release within Squeeze distro? I don't think so. 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/20110330132719.gn3...@radis.liafa.jussieu.fr
Bug#620038: pu: package fcgiwrap/1.0-1+squeeze1
On Tue, 2011-03-29 at 13:54 +0200, Philipp Kern wrote: fcgiwrap doesn't stop properly on squeeze (#602199). I just uploaded 1.0.3-2 with Jordi's fixes that were pending since four months to unstable. I'd like to propose the attached fix for squeeze, too. +fcgiwrap (1.0-1+squeeze1) stable; urgency=low + + * Non-maintainer upload. + * Unquote $pid and $DAEMON on stop_daemon() so it actually stops +(closes: #602199). I'd have been tempted to double-quote them rather than completely removing the quoting; I suppose it's unlikely that either variable will contain spaces or similar though. + * Reduce the wait when just stopping (closes: #602200). How likely is it that the daemon won't have successfully stopped within a second (i.e. the combination of the two sleep $QDIETIMEs calls)? 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/1301490576.12508.2491.ca...@hathi.jungle.funky-badger.org
Bug#620038: pu: package fcgiwrap/1.0-1+squeeze1
On Tue, Mar 29, 2011 at 13:54:10 +0200, Philipp Kern wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Version: fcgiwrap doesn't stop properly on squeeze (#602199). I just uploaded 1.0.3-2 with Jordi's fixes that were pending since four months to unstable. I'd like to propose the attached fix for squeeze, too. ack. 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/20110330132857.go3...@radis.liafa.jussieu.fr
Bug#619117: perl 5.12 transition
On Wed, Feb 23, 2011 at 07:40:26PM +, Dominic Hargreaves wrote: I would like to register an interest in carrying out a perl transition soon. This would be to perl 5.10.1 to 5.12.x (x = 3 currently). This transition has already been in preparation for some time, and I think we are in a good position to schedule this now. This is the first major transition I've been involved in (I've recently become a co-maintainer of the perl package), so please bear with me if I miss anything out. You can see the transition tracking bugs at [1]. One thing that came up is that we need to make sure all sid buildd chroots have debconf-english installed and not debconf-i18n before that happens (debconf-i18n depends on liblocale-gettext-perl, which depends on perlapi-5.10.0). Cc:-ing debian-wb-team so this can be handled before the perl transition. 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/20110330133417.gp3...@radis.liafa.jussieu.fr
Bug#619117: perl 5.12 transition
On Wed, Mar 30, 2011 at 15:42:56 +0200, Cyril Brulebois wrote: Julien Cristau jcris...@debian.org (30/03/2011): One thing that came up is that we need to make sure all sid buildd chroots have debconf-english installed and not debconf-i18n before that happens (debconf-i18n depends on liblocale-gettext-perl, which depends on perlapi-5.10.0). Cc:-ing debian-wb-team so this can be handled before the perl transition. I guess we want to make sure sid chroots have the proper packages, but experimental ones as well (so that test-builds are actually useful, should they be needed), as well as wheezy chroots, for the future t-p-u uploads? Just sid should be enough. Wheezy should never see the combination of perl 5.12 and perl modules built for 5.10 anyway. 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/20110330134617.gq3...@radis.liafa.jussieu.fr
Re: fakechroot bugginess on squeeze
On Tue, 2011-03-29 at 04:00 -0400, Daniel Kahn Gillmor wrote: debootstrap --variant=fakechroot does not currently work on squeeze. It fails with error messages like: W: Failure while unpacking required packages. This will be attempted up to five times. These errors appear to be due to two distinct bugs: #561991 and #588508 It's a shame that neither of those are already resolved in Squeeze, given when the fixes were uploaded. Maybe a targeted patch of these two bugs in fakechroot is a good candidate for the next point release of squeeze? I'm attaching a debdiff against what is currently in stable (2.9-1.1). Please go ahead, with the exception of doing s/unstable/stable/ in the changelog stanza. :-) 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/1301493025.12508.2617.ca...@hathi.jungle.funky-badger.org
Bug#619117: perl 5.12 transition
Julien Cristau jcris...@debian.org (30/03/2011): One thing that came up is that we need to make sure all sid buildd chroots have debconf-english installed and not debconf-i18n before that happens (debconf-i18n depends on liblocale-gettext-perl, which depends on perlapi-5.10.0). Cc:-ing debian-wb-team so this can be handled before the perl transition. I guess we want to make sure sid chroots have the proper packages, but experimental ones as well (so that test-builds are actually useful, should they be needed), as well as wheezy chroots, for the future t-p-u uploads? Just wondering which chroots to check, I'd like to avoid doing grunt work too many times. KiBi. signature.asc Description: Digital signature
NEW changes in proposedupdates
Processing changes file: gdm3_2.30.5-6squeeze2_amd64.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_armel.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_i386.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_ia64.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_kfreebsd-amd64.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_kfreebsd-i386.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_mips.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_mipsel.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_powerpc.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_s390.changes ACCEPT Processing changes file: gdm3_2.30.5-6squeeze2_sparc.changes ACCEPT Processing changes file: q4wine_0.118-5_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/e1q4vsv-00034f...@franck.debian.org
it's Python time now
FYI: I plan to upload python-sphinx, python-defaults (without Python 2.5, with Python 2.7) and python3-defaults (with Python 3.2 instead of Python 3.2) tomorrow. Please report bug against tech-ctte and CC me if you think it's not a good idea. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20110330140256.gg30...@piotro.eu
Re: it's Python time now
On Wed, Mar 30, 2011 at 16:02:56 +0200, Piotr Ożarowski wrote: FYI: I plan to upload python-sphinx, python-defaults (without Python 2.5, with Python 2.7) and python3-defaults (with Python 3.2 instead of Python 3.2) tomorrow. Please report bug against tech-ctte and CC me if you think it's not a good idea. I think it's not a good idea. 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/20110330142256.gs3...@radis.liafa.jussieu.fr
Bug#619974: nmu: qscintilla2_2.4.3-1+b1
On Mon, 2011-03-28 at 12:19 -0700, Ludovico Cavedon wrote: nmu qscintilla2_2.4.3-1+b1 . alpha amd64 sparc64 . -m Package rebuild. (Closes: #619096). sparc64 isn't an official Debian architecture, so we can't schedule binNMUs there; you'd need to talk to the port maintainers. The +b1 binNMUs on alpha and amd64 were scheduled at the same time, and for the same reason, as the +b2s on the other architectures, namely to update the python-sip dependencies; the fact that they're +b1 doesn't imply that they're out-of-date. The real problem appears to be that the python-qt4 libraries break ABI without providing any indication of that fact to reverse-dependencies. That should really be fixed so that the r-deps don't just break with no warning. 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/1301494308.12508.2693.ca...@hathi.jungle.funky-badger.org
Re: it's Python time now
[Julien Cristau, 2011-03-30] On Wed, Mar 30, 2011 at 16:02:56 +0200, Piotr Ożarowski wrote: FYI: I plan to upload python-sphinx, python-defaults (without Python 2.5, with Python 2.7) and python3-defaults (with Python 3.2 instead of Python 3.2) tomorrow. Please report bug against tech-ctte and CC me if s/3.2/3.1/ you think it's not a good idea. I think it's not a good idea. 3 days then (python-defaults didn't migrate to testing yet) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20110330142604.gh30...@piotro.eu
Suggested release goal: /run
(Please keep me in Cc, I'm not subscribed) Proposer: Tollef Fog Heen tfh...@debian.org Seconder: Michael Biebl bi...@debian.org Currently, /lib/init/rw exists as a place for applications that need write access early (before $local_fs) to put their data. In addition, some abuse /dev/shm for this. A couple of years back, /run was suggested, but /lib/init/rw ended up being chosen. However, various upstreams are not using /lib/init/rw, they're more likely to use hidden directories in /dev, like /dev/.udev and /dev/.initramfs. This is both ugly and a violation of the FHS. Various upstreams seem to now unite under the banner of /run and I think it would make sense for us to follow suit, see [1] for Lennart Poettering's mail to the Fedora devel list and [2] for the FHS bug about it. I'm therefore proposing the goal of: - /run should exist as a tmpfs - /var/run should be a symlink or bind mount of/to /run - /var/lock should be a symlink/bind mount to /run/lock - /lib/init/rw should be a symlink/bind mount to /run - applications are free to use /run as they have previously used /var/run. Applications using /lib/init/rw and /dev/shm are to be changed to use /run. /var/run and /var/lock as tmpfs is already reasonably well supported since this has been in use in Ubuntu for a while and it's been a supported (but optional) configuration in Debian for some time. [1]: http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html [2]: http://bugs.freestandards.org/show_bug.cgi?id=718 Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87fwq4tyuv@qurzaw.varnish-software.com
Re: fakechroot bugginess on squeeze
On 03/30/2011 09:50 AM, Adam D. Barratt wrote: Please go ahead, with the exception of doing s/unstable/stable/ in the changelog stanza. :-) OK, i've uploaded, with a correct changelog. Thanks for noticing that! Please let me know if there's anything else that i need to do; i've never put a package into a point release before. Regards, --dkg signature.asc Description: OpenPGP digital signature
Plans for GNOME 3 and GTK 3
Hi, the plans of the GNOME team for GNOME 3 are not entirely complete yet. However there are a number of transitions coming up that you should be aware of. Currently, there is a gobject-introspection transition going on, and the gtk+2.0 / gdk-pixbuf split. These are both prerequisites for gtk+3.0. gtk+3.0 in itself does not create any transition. New libraries that are based on it don’t either, for most of them, since they are co-installable with their gtk2 versions. The problem arises when these libraries cannot, for a reason or another, be in unstable at the same time as the old version. Because of that, it will not be possible to separate the upload of these libraries and transitions involving core GNOME components. One of the problematic libraries is libedataserverui, which will be part of the evolution transition. This one brings gnome-panel, which in turns breaks all existing applets in Debian - and that makes a lot of packages out of the GNOME team control. I will give you a thorough list, with all affected reverse-dependencies, when everything is in experimental. We can then think of strategies to break entanglements if possible. In any case there is no rush, since we don’t know yet whether GNOME 3.0 will be suitable for unstable - I have much better hopes now than a few weeks ago, though. It will probably need some time to be polished enough; if it takes too much time it might be better to wait for GNOME 3.2. So in short, there is no GNOME transition to schedule for now, but it would be nice if you could prepare a big slot for several hairy transitions when we are ready. Thanks, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1301501681.6014.58.camel@pi0307572
Re: sh4 architecture into Wheezy
On 11-03-30 09:17 AM, Steve McIntyre wrote: On Wed, Mar 30, 2011 at 02:05:52PM +0900, Nobuhiro Iwamatsu wrote: Dear release team. We(sh4 porting team) are now trying to run Debian on Renesas SH(sh4) CPU. http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4 We want to support sh4 by the next release (Wheezy). - Buildd status Currentry, we are finished with build with packages of about 90%. http://buildd.debian-ports.org/stats/sh4.txt http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4priority= - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? If I have say go ahead!, we will start work with DSA, buildd team, security team and ftp-master team. Hi Nobuhiro, A few questions: You say there is many user waiting for port to Debian in the wiki page listed. How many is many? I'd assume anyone working internally at Renesas would use it. I know there are 100s of subscribers to the linuxsh-dev mailing list who are potential users. What are the future prospects for sh4? It seems that STM are concentrating on ARM-based cores for future products... Not sure why STMs activities are relevant? Renesas owns the IP and is moving forward with SH4-based cores. -- 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/4d935424.2090...@naoi.ca
Re: sh4 architecture into Wheezy
On Wed, 30, Mar, 2011 at 12:02:44PM -0400, Bill Traynor spoke thus.. Not sure why STMs activities are relevant? Renesas owns the IP and is moving forward with SH4-based cores. Another question which has been brought up relates to buildds. What number of buildds is it estimated would be needed to keep up with the main archive? Also, what sort of maximum build times can we expect for large packages compared to the other architectures (i.e. what's the best class of hardware we can expect for the buildds). Mark -- Mark Hymers mhy at debian dot org I'm so gorgeous, there's a six month waiting list for birds to suddenly appear, every time I am near! Cat, Red Dwarf Series VIII - Back in the Red -- 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/20110330161624.ga18...@hymers.org.uk
Re: Bits from the Release Team - Kicking off Wheezy
Hi Below an update of the release goals I advocated and some thoughts on others. Release Goals - As a first step towards establishing release goals for wheezy, we will be reviewing each of the goals which we had for squeeze [RDO:SGoals] to see which have been achieved and which may no longer be relevant for other reasons. If you are listed as the proponent for a goal in the above list, please feel free to provide a status update on progress towards completing it and whether you believe it is relevant for the wheezy cycle. You can also e-mail us to propose a new goal, including a description of the goal and an indication of how progress on the issues may be tracked (e.g. a pointer to a set of appropriate user-tagged bugs). # bootperformance Advocate: Petter Reinholdsen and Luk Claes State: confirmed Wiki: http://wiki.debian.org/ReleaseGoals/BootPerformance The main part of this goal was achieved, though there are some possible improvements both regarding boot reliability and boot performance that could still be aimed for. Regarding reliability I'm doing some work regarding NFS, though one of the main outstanding issues is the race between availability of the network devices and the end of the network init script AFAICS. It would also not be a bad idea to have a discussion on whether the default init system should change to one that is more suitable to guarantee the reliability of the boot like upstart or systemd. Regarding boot performance there is quite some work done by Ubuntu in different packages, so maybe it would not be bad to have a look at how Ubuntu and Debian could get more in sync on that. # package quality Advocate: Holger Levsen and Luk Claes State: confirmed Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality This is a never ending goal of sustaining our packages quality by improving our tests and following up closely... so needless to say that I would still advocate this one. # remove obsolete libraries Advocate: Barry deFreese and Luk Claes State: confirmed Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs This worked quite well and should continue so we can get rid of obsolete libraries IMHO. One of the main candidates are the old db libraries, though there are also still some old gnome libraries and without doubt others. We're also after new goals! I know that expressions of interest in multiarch and tdebs have already been indicated, but if you have something you would want to see happen for Wheezy, please let us know. The release team itself will be suggesting some as part of the review above. I'm definitely in favour of having multiarch finally happen! For the IPv6 and LFS legacy release goals I think it would be best if we would welcome massive (automatic?) tests to find all of the outstanding issues and get them fixed finally! I would welcome a review of essential, required and standard though I don't know if many would welcome such an initiative which could potentially have quite some impact without much visible gain. Anyway it's something which should happen in the beginning of the cycle (after a discussion with both the involved maintainers as well as the developers body at large) or not at all IMHO. Cheers Luk -- 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/4d936684.2050...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
Le mercredi 30 mars 2011 à 19:21 +0200, Luk Claes a écrit : # remove obsolete libraries Advocate: Barry deFreese and Luk Claes State: confirmed Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs This worked quite well and should continue so we can get rid of obsolete libraries IMHO. One of the main candidates are the old db libraries, though there are also still some old gnome libraries and without doubt others. I fully support this, and I’d like indeed to remove some more obsolete libraries for wheezy. We should start with HAL and gnome-vfs, which are big things. Along the way I’d like to get rid of the least used GTK2 libraries in favor of their GTK3 counterpart. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1301506702.6014.60.camel@pi0307572
Re: Bits from the Release Team - Kicking off Wheezy
Hi all, [...] # package quality Advocate: Holger Levsen and Luk Claes State: confirmed Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality This is a never ending goal of sustaining our packages quality by improving our tests and following up closely... so needless to say that I would still advocate this one. [...] I would advocate the idea behind this goal as well, yet I think as-is this isn't a very useful goal: how would we ever measure its achievement? To this end, I think, we need to give a much more precise definition of how we intend to measure quality. For instance, we could fix lintian version x.y.z and state that we want to have 0 errors at the time of release. Similarly for piuparts. Or a bugs per package ratio. All of these are measurable and can be checked for, although of course they only give a very limited notion of quality. Best regards, Michael pgpokBZLr0Xn4.pgp Description: PGP signature
Bug#619974: nmu: qscintilla2_2.4.3-1+b1
On 03/30/2011 07:11 AM, Adam D. Barratt wrote: On Mon, 2011-03-28 at 12:19 -0700, Ludovico Cavedon wrote: nmu qscintilla2_2.4.3-1+b1 . alpha amd64 sparc64 . -m Package rebuild. (Closes: #619096). sparc64 isn't an official Debian architecture, so we can't schedule binNMUs there; you'd need to talk to the port maintainers. ok The +b1 binNMUs on alpha and amd64 were scheduled at the same time, and for the same reason, as the +b2s on the other architectures, namely to update the python-sip dependencies; the fact that they're +b1 doesn't imply that they're out-of-date. I see. I cannot tell for the alpha build, but the amd64 binary needs to be rebuilt because of the python-qt4 ABI change :( The real problem appears to be that the python-qt4 libraries break ABI without providing any indication of that fact to reverse-dependencies. That should really be fixed so that the r-deps don't just break with no warning. CCing python-qt4 maintainers. Thanks, Ludovico -- 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/4d936b8c.6050...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
Am 30.03.2011 19:21, schrieb Luk Claes: Regarding reliability I'm doing some work regarding NFS, though one of the main outstanding issues is the race between availability of the network devices and the end of the network init script AFAICS. It would also not be a bad idea to have a discussion on whether the default init system should change to one that is more suitable to guarantee the reliability of the boot like upstart or systemd. ... I would welcome a review of essential, required and standard though I don't know if many would welcome such an initiative which could potentially have quite some impact without much visible gain. Anyway it's something which should happen in the beginning of the cycle (after a discussion with both the involved maintainers as well as the developers body at large) or not at all IMHO. One of the steps required to make it possible to test alternative init systems (on a wider scale) is to get the Essential flag removed from sysvinit (and possibly initscripts), so systemd and upstart can be installed without force. This has been on my wishlist for squeeze and we should definitely get the necessary changes into wheezy as early as possible during the development cycle. Dunno if this warrants a separate release goal though. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: sh4 architecture into Wheezy
On 30.03.2011 07:05, Nobuhiro Iwamatsu wrote: - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? Toolchain was supported by CodeSourcery so it's not supported anymore? If this is correct, then this is a no-go for the port. Besides this, who will care about the toolchain for this port within Debian? I'm not keen on having another mips like maintained 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/4d937848.7070...@debian.org
Re: sh4 architecture into Wheezy
On 11-03-30 02:36 PM, Matthias Klose wrote: On 30.03.2011 07:05, Nobuhiro Iwamatsu wrote: - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? Toolchain was supported by CodeSourcery so it's not supported anymore? If this is correct, then this is a no-go for the port. Besides this, who will care about the toolchain for this port within Debian? I'm not keen on having another mips like maintained architecture. I've cleaned up the wiki a bit. The GNU toolchain supports SH4. However, CodeSourcery produces a version of the GNU toolchain as well. This toolchain is obtained separately by the user should they desire to use it. Changes in the CodeSourcery toolchain do eventually get pushed upstream to the FSF GNU toolchain. 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/4d9381b9.6010...@naoi.ca
Re: sh4 architecture into Wheezy
On 30.03.2011 21:17, Bill Traynor wrote: On 11-03-30 02:36 PM, Matthias Klose wrote: On 30.03.2011 07:05, Nobuhiro Iwamatsu wrote: - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? Toolchain was supported by CodeSourcery so it's not supported anymore? If this is correct, then this is a no-go for the port. Besides this, who will care about the toolchain for this port within Debian? I'm not keen on having another mips like maintained architecture. I've cleaned up the wiki a bit. The GNU toolchain supports SH4. However, CodeSourcery produces a version of the GNU toolchain as well. This toolchain is obtained separately by the user should they desire to use it. this is not an option for Debian. Changes in the CodeSourcery toolchain do eventually get pushed upstream to the FSF GNU toolchain. yes, CS does this, but there may be a delay, and in some cases you may only see these changes submitted when the FSF GCC is in stage1. Assuming that GCC 4.6 and binutils 2.22 are targeted for wheezy, who will care about sh4 specific issues in the toolchain for wheezy? 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/4d938926.9070...@debian.org
Re: it's Python time now
[Piotr Ożarowski, 2011-03-30] FYI: I plan to upload python-sphinx, python-defaults (without Python 2.5, with Python 2.7) and python3-defaults (with Python 3.2 instead of Python 3.2) tomorrow. Please report bug against tech-ctte and CC me if you think it's not a good idea. I know I shouldn't send this email, I usually try to wait 24h after writing, didn't do it this time. I already removed myself from python-defaults' Uploaders, though (but still plan to work on dh_python2). -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: sh4 architecture into Wheezy
On 11-03-30 03:48 PM, Matthias Klose wrote: On 30.03.2011 21:17, Bill Traynor wrote: On 11-03-30 02:36 PM, Matthias Klose wrote: On 30.03.2011 07:05, Nobuhiro Iwamatsu wrote: - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? Toolchain was supported by CodeSourcery so it's not supported anymore? If this is correct, then this is a no-go for the port. Besides this, who will care about the toolchain for this port within Debian? I'm not keen on having another mips like maintained architecture. I've cleaned up the wiki a bit. The GNU toolchain supports SH4. However, CodeSourcery produces a version of the GNU toolchain as well. This toolchain is obtained separately by the user should they desire to use it. this is not an option for Debian. I don't mean that the CodeSourcery toolchain should be included in Debian. I'm merely stating that the user can install whatever toolchain post distribution install. I'll just remove the CodeSourcery reference altogether. Changes in the CodeSourcery toolchain do eventually get pushed upstream to the FSF GNU toolchain. yes, CS does this, but there may be a delay, and in some cases you may only see these changes submitted when the FSF GCC is in stage1. Assuming that GCC 4.6 and binutils 2.22 are targeted for wheezy, who will care about sh4 specific issues in the toolchain for wheezy? I'm not sure, but will find out. 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/4d939fba.9090...@naoi.ca
Bug#618871: transition: ocaml
Le 29/03/2011 19:52, Julien Cristau a écrit : The Debian OCaml team is ready for a transition to OCaml 3.12.0. All packages depending on ocaml-base-nox-3.11.2 and ocaml-base-3.11.2 will be affected. I am waiting for the approval from the release team to proceed. Any news on that? Clearly not. Could you give more detail, please? Is there an ongoing transition somehow conflicting and that could use some help? I heard about gmp, but gmp/gmp4 (and why, which had been temporarily removed from testing) just migrated to testing, and I didn't find any open bugs tracking this. I haven't looked at other transitions... but I ask here because you are supposed to be more knowledgeable :-) According to [1], there remains stuff, though, but (on amd64 at least), most of the packages go green after a binNMU. Obvious issues are cheesetracker, gclcvs, genius, guile-1.8, lilypond, netrek-client-cow, strongswan, acl2, hol88, mlgmp [I could probably fix that, but haven't been notified], linbox [not sure], maxima, open-cobol, regina-normal, units-filter [not sure]... is there anyone working on that right now? FTR, we have far less unsolved obvious issues in the planned ocaml transition, and they are documented at [2]. It would be nice if we used the power of our BTS and set blockers for this bug (#618871), so that someone outside the release team (such as me) can see more clearly [than Clearly not.] what is going on. [1] http://release.debian.org/transitions/gmp5.html [2] http://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions Cheers, -- Stéphane -- 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/4d93b180.9090...@debian.org
Re: sh4 architecture into Wheezy
Hi,
2011/3/31 Matthias Klose d...@debian.org:
On 30.03.2011 21:17, Bill Traynor wrote:
On 11-03-30 02:36 PM, Matthias Klose wrote:
On 30.03.2011 07:05, Nobuhiro Iwamatsu wrote:
- ArchiveQualification of sh4
http://wiki.debian.org/ArchiveQualification/sh4
How do you think about including sh4 in the next release?
Toolchain was supported by CodeSourcery
so it's not supported anymore? If this is correct, then this is a no-go for
the
port. Besides this, who will care about the toolchain for this port within
Debian? I'm not keen on having another mips like maintained architecture.
I've cleaned up the wiki a bit. The GNU toolchain supports SH4. However,
CodeSourcery produces a version of the GNU toolchain as well. This
toolchain is
obtained separately by the user should they desire to use it.
this is not an option for Debian.
Changes in the
CodeSourcery toolchain do eventually get pushed upstream to the FSF GNU
toolchain.
yes, CS does this, but there may be a delay, and in some cases you may only
see
these changes submitted when the FSF GCC is in stage1.
Assuming that GCC 4.6 and binutils 2.22 are targeted for wheezy, who will care
about sh4 specific issues in the toolchain for wheezy?
Yohii-san and I mainly.
It is difficult to solve a problem of GCC to me. But gcc/sh maintainer
supported a problem.
There is maintainers of sh4(sh). Kaz kojima and other.
I was helped how many times by them.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/aanlktikzo+dhk3quxoqb1iszxgnpf40h4taturifz...@mail.gmail.com
Re: sh4 architecture into Wheezy
Hi,
2011/3/30 Steve McIntyre st...@einval.com:
On Wed, Mar 30, 2011 at 02:05:52PM +0900, Nobuhiro Iwamatsu wrote:
Dear release team.
We(sh4 porting team) are now trying to run Debian on Renesas SH(sh4) CPU.
http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4
We want to support sh4 by the next release (Wheezy).
- Buildd status
Currentry, we are finished with build with packages of about 90%.
http://buildd.debian-ports.org/stats/sh4.txt
http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4priority=
- ArchiveQualification of sh4
http://wiki.debian.org/ArchiveQualification/sh4
How do you think about including sh4 in the next release?
If I have say go ahead!, we will start work with DSA, buildd
team, security team and ftp-master team.
Hi Nobuhiro,
A few questions:
You say there is many user waiting for port to Debian in the wiki
page listed. How many is many?
Bill is written, but there is the user of SH/Linux all over the world.
Sorry, I do not understand the right value.
There are many BSP and products which used SH4/Linux (Debian).
There is not the user than ARM, but it is sure that there are many users.
What are the future prospects for sh4? It seems that STM are
concentrating on ARM-based cores for future products...
STM has license of SuperH, and they have a board for development of
the sh4 base.
They have original distoribution[0], but there is the user who
replaces this with debian.
I do not yet know whether STM produces the CPU's of the SH4 base.
I will collect more detailed information about this.
Best regards,
Nobuhiro
[0]: http://www.stlinux.com/
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/AANLkTinuwuUiw9yUxYPARnT=r0G=QP=hu+v0paxju...@mail.gmail.com
Re: sh4 architecture into Wheezy
Hi,
2011/3/31 Mark Hymers m...@debian.org:
On Wed, 30, Mar, 2011 at 12:02:44PM -0400, Bill Traynor spoke thus..
Not sure why STMs activities are relevant? Renesas owns the IP and is
moving forward with SH4-based cores.
Another question which has been brought up relates to buildds. What
number of buildds is it estimated would be needed to keep up with the
main archive? Also, what sort of maximum build times can we expect for
large packages compared to the other architectures (i.e. what's the best
class of hardware we can expect for the buildds).
9 buildd works now.
# One of them stops for the trouble of the HDD.
We maintain Buildd with this number now.
The build finished package is equal to or less than 90%, but collects
in build queue for some transition now.
These will be built entirely a few days later.
It is necessary to maintain all in these when We support it in debian.
It is the best thing which used hardware can prepare now now.
Perhaps it will be the latest in the supported architecture now.
The package which time needs most is GCC. GCC takes about 6 days.
Build in itself is over in approximately 3 days, but is more necessary
for a test for 3 days.
I worry about this lateness...
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/AANLkTi=6o924rt_mmcykhzmvwb2rpp-2l94qcjn9s...@mail.gmail.com
Re: sh4 architecture into Wheezy
On Wed, 2011-03-30 at 21:48 +0200, Matthias Klose wrote: On 30.03.2011 21:17, Bill Traynor wrote: On 11-03-30 02:36 PM, Matthias Klose wrote: On 30.03.2011 07:05, Nobuhiro Iwamatsu wrote: - ArchiveQualification of sh4 http://wiki.debian.org/ArchiveQualification/sh4 How do you think about including sh4 in the next release? Toolchain was supported by CodeSourcery so it's not supported anymore? If this is correct, then this is a no-go for the port. Besides this, who will care about the toolchain for this port within Debian? I'm not keen on having another mips like maintained architecture. I've cleaned up the wiki a bit. The GNU toolchain supports SH4. However, CodeSourcery produces a version of the GNU toolchain as well. This toolchain is obtained separately by the user should they desire to use it. this is not an option for Debian. Changes in the CodeSourcery toolchain do eventually get pushed upstream to the FSF GNU toolchain. yes, CS does this, but there may be a delay, and in some cases you may only see these changes submitted when the FSF GCC is in stage1. Assuming that GCC 4.6 and binutils 2.22 are targeted for wheezy, who will care about sh4 specific issues in the toolchain for wheezy? Hi, Kaz Kojima provides regular testresults for GCC on sh4-linux : 4.7: http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02619.html 4.6: http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01500.html He also seems active fixing bugs on this platform, eg: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01213.html He commited about two patch a month on average according to gcc/ChangeLog for 2009-2011. Renesas donated an SH4 board to the GCC Compile Farm project (1). This donation has not been made public yet since I'm waiting for wheezy and full 512MB RAM support (current lenny based release I tested supports only 128MB due to kernel issues), but it should be soon and so the sh4-linux platform will be available for all upstream free software developpers in case the need arises. I will try native GCC bootstrap on it. Note: I'm no SH4 expert and I don't know personally Kaz Kojima, just looking at my inbox archives :). Sincerely, Laurent (1) http://gcc.gnu.org/wiki/CompileFarm -- 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/1301528668.11098.1008.camel@pc2.unassigned-domain
