gnat-4.1/gcj-4.1 manual builds needed on alpha, arm, m68k, mips, mipsel, s390, sparc
While having built and uploaded things correctly for experimental, I didn't do the same for unstable, which now needs some manual intervention building gnat-4.1 and gcj-4.1. gnat-4.1 (mips mipsel s390 sparc): - work in a sid chroot - install gnat-4.1-base libgnat-4.1 libgnatprj4.1 libgnatvsn4.1 from etch - fetch gnat-4.1 from etch - dpkg -x gnat-4.1_4.1.1-22_*.deb - rm -rf usr/lib/gcc/*/4.1.3 - tar cf - usr | (cd /; tar xfv -) - ln -sf ../4.1.2/gnat1 /usr/lib/gcc/$arch-linux-gnu/4.1/gnat1 - ln -sf ../4.1.2/adalib /usr/lib/gcc/$arch-linux-gnu/4.1/adalib - ln -sf ../4.1.2/adainclude /usr/lib/gcc/arch-linux-gnu/4.1/adainclude - build with dpkg-buildpackage -b -B -d (ignoring the gnat-4.1 b-d) - undo at least the symlinks in the chroot, or throw away the chroot gcj-4.1 (alpha arm m68k mips mipsel s390 sparc): - needs gcc-4.1_4.1.2 (not yet built on arm and m68k) - work in a sid chroot - install gcj-4.1-base libgcj7-0 libgcj7-jar libgcj7-dev libgcj7-awt gij-4.1 from etch - install other b-d's from sid - build as an extra check, build the package with itself (although this will be done with the next uploads anyway). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GCC 4.2 transition
The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
java status on the ports
Besides m68k hopelessly being behind we do have serious problems on alpha, arm and hppa. - on arm, the bytecode compiler (ecj) doesn't produce correct code. there is currently a workaround to build the package on arm using byte-compiled code built on another architecture. Aurelian has more information on that issue. Afaik not a problem on armel. - on alpha, we do have testsuite failures, leading to a non-working interpreter (see http://bugs.debian.org/464156). We can build gcj-4.3 and ecj, but nothing more (if ecj is built with gcj-4.3). - on hppa, we do see bus errors trying to run the interpreter, plus new testsuite failure (see http://bugs.debian.org/464160). Any help to fix these ports is appreciated, having a replacment for gcj on these archs is fine as well. Test results on all other architectures look fine. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proper way to specify Java build-dep
Adam C Powell IV writes: On Mon, 2008-05-05 at 16:58 +0200, Michael Koch wrote: On Mon, May 05, 2008 at 10:23:41AM -0400, Adam C Powell IV wrote: Greetings, My package babel recently closed bug 477845 by changing a build dependency from java-gcj-compat to default-jdk-builddep. Unfortunately, this made it FTBFS on hppa, s390, arm and alpha, where before it built everywhere except arm. What is the right thing to do in this situation? Do I exclude those architectures from the package build list? Is there a java-works architecture variable which will automatically add arches as their java implementations work? [Please CC me in replies.] These arches currently dont work, rigth. Im testing a solution for this. In general just B-D on default-jdk-builddep is okay. it is only correct if your package doesn't build other architecture dependent packages, which is not the case for babel. the build failure on s390 is unexpected; is it possible to extract a test case? Just curious, what will happen regarding testing transitions in the meantime? And long-term, can I assume that the package will build and transition as soon as the infrastructure is in place, without another upload? the infrastructure is in place; the packages can move to testing once the hppa, arm and alph binaries are not in unstable anymore. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OpenJDK Cacao GCJ Java defaults in unstable
Hi,
openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.
There are two new binary packages offering additional JVMs:
- openjdk-6-jre-zero: built on amd64 and i386. This is the JVM used by
default on the non-hotspot archs (armel, alpha, s390, mips, mipsel,
powerpc, m68k?). Maybe useful for debugging issues with the zero JVM on
archs which are more accessible.
- icedtea-6-jre-cacao: built on alpha, armel, mips, mipsel, s390, i386,
amd64, powerpc). The Cacao JVM and JIT is not yet feature complete
compared to the hotspot JVM, but is much faster than the Zero JVM
and offers an alternative on platforms which don't have the Hotspot
JVM.
The additional JVM's can be called with
java [-cacao|-zero]
or for the java tools with
tool name [-J-cacao|-J-zero]
This is currently a Debian/Ubuntu only option; integration into IcedTea is in
progress.
To make a JVM the default, make it the first one in /etc/java-6-openjdk/jvm.cfg.
GCJ is still the work horse to build and bootstrap OpenJDK. IMO it still does
make sense to keep the '-gcj' packages for software which is known to work with
GCJ. I plan to have a recent GCJ-4.x release for the next Debian release.
Once openjdk-6 moves to testing, I propose to change the default in the
default-{jre,jdk} packages to point to the openjdk-6 packages. This works well,
except for one thing: packages will be built with -source 1.6 by default, which
makes the resulting .class/.jar files unusable with older java versions (1.4 and
1.5). I would like to propose a change in the Debian java policy, that java
packages must be built for the version which is sufficient for a sucessful
build. The changes are trivial; I already did check in changes for ant and ant
build- and runtime dependencies into the debian-java svn.
There is currently work-in-progress to extend the Zero JVM with a JIT (called
shark). This is still experimental work, currently requires llvm-2.4 (unstable
has 2.5). I would welcome feedback from port maintainers about zero/shark.
Please consider to join the IcedTea mailing list.
Matthias
PS: I would appreciate some help with openjdk in Debian; the current maintainer
team is MIA or inactive.
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 18.08.2009 22:43, Jurij Smakov wrote: Hello, I would like to point out that sparc release requalification is currently placing it in at risk position for squeeze release. The most serious problems with the port are lack of developer involvement (there is currently one active porter/developer known to the release team, Bernd Zeimetz) and the fact that current mixed 64-bit kernel with 32-bit userspace setup is not supported upstream (CC'ing doko for comment). The current configuration for a biarch toolchain defaulting to 32-bit isn't that well supported. The 32-bit compiler defaults to v8 hardware which isn't available anymore. The biarch setup tightly couples v9 and newer processor support to 64-bit, so switching to a 64-bit userland would offer better use of current hardware besides targeting a comparable setup as other distributions. Newer projects like llvm don't target 32-bit sparc anymore, while they do for 64-bit. I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. For both variants the toolchain is almost in place. glibc and binutils don't need modifications, gcc needs some libraries be built as biarch on sparc. zlib is already built as biarch on sparc. gmp and mpfr are already built as biarch on other archs, ppl and cloog would be good to have, but we could start without the graphite optimizations as well. I can prepare the changes for gcc, but will not help with any other transition work. [CCing debian-s390, because there are plans for a switch to s390x as well] Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
any objections from port maintainers to make gcc-4.4 the default?
Besides the open license issue, are there any objections from port maintainers to make GCC-4.4 the default? As a first step that would be a change of the default for C, C++, ObjC, ObjC++ and Fortran. I'm not sure about Java, which show some regressions compared to 4.3. Otoh it's not amymore the default java compiler for all architectures except hurd(?), kfreebsd(?) and hppa. hppa already defaults to 4.4, what about the hurd and kfreebsd? Ada will still stay at 4.3 until Ludovic is ready to switch the default to 4.4. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 06.09.2009 16:49, Jurij Smakov wrote: On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote: On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias, can you please make a definite statement on whether you, as a toolchain maintainer, are willing to support the existing 32-bit userland with a 64-bit kernel, or you consider a transition to 64-bit userland a necessary condition for sparc to be released with squeeze. This will be an important factor for the release team to determine what is going the port is currently using 4.3 as the default, I do plan to make 4.4 the default unless port maintainers object [1]. Ubuntu karmic already uses 4.4 as the default, but as a community port sparc doesn't get the same attention as other ports. Please see [2] for current problems with sparc. I do not plan to invest significant time in fixing build issues on sparc for squeeze. I do commit to prepare binutils and gcc-4.4 for a sparc64 port if this should happen for squeeze. Matthias [1] http://lists.debian.org/debian-release/2009/09/msg00239.html [2] http://qa.ubuntuwire.org/ftbfs/ -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 20.08.2009 16:52, Aurelien Jarno wrote: Bastian Blank a écrit : On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. If we are not sure that sparc and s390 (ie 32-bit versions) would be suitable for squeeze, this is almost sure they won't be suitable for squeeze+1. Isn't it the right moment to start a sparc64 and an s390x port, and if they are ready for squeeze release with them? Almost whatever upgrade solution you offer will require to have at least one release with both old and new architecture (like we did for arm - armel). Given that we already have sparc and s390 in the archive and that we also already have 64-bit ports, I don't expect any major problem for those new ports. Also given quite fast hardware exists for those architectures, it can probably be done relatively quickly. this seems to be the way to go, but port maintainers seem to lack enthusiasm or resources. I'm willing to help, if somebody commits to these ports. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
DSO linking changes for wheezy
For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. Thanks, Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ccacf9d.9080...@debian.org
Re: DSO linking changes for wheezy
On 15.11.2010 07:16, Roland McGrath wrote: mattst88 airlied_, does Fedora use --as-needed by default? Fedora 14 too? airlied_ mattst88: yes The naming of the options makes people easily confused. --no-add-needed is the only option Fedora's gcc passes. yes, OpenSuse is using --as-needed, but not --no-add-needed. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1acb3.1090...@debian.org
Re: DSO linking changes for wheezy
On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ccd1.8010...@debian.org
libffi 3.0.10 rc8 test results
Here are some test results for various linux ports, ran on Debian unstable: builds logs (except for mips) can be found at: https://buildd.debian.org/status/package.php?p=libffisuite=experimental i386 and amd64 look ok. arm-unknown-linux-gnueabi: XPASS: libffi.call/cls_longdouble.c -O0 -W -Wall execution test XPASS: libffi.call/cls_longdouble.c -O2 execution test XPASS: libffi.call/cls_longdouble.c -O3 execution test XPASS: libffi.call/cls_longdouble.c -Os execution test XPASS: libffi.call/cls_longdouble.c -O2 -fomit-frame-pointer execution test Running /build/buildd-libffi_3.0.10~rc8-1-armel-3UaGFl/libffi-3.0.10~rc8/testsuite/libffi.special/special.exp ... === libffi Summary === # of expected passes1639 # of unexpected successes 5 # of unsupported tests 15 ia64: === libffi Summary === # of expected passes1644 # of unsupported tests 15 kfreebsd-amd64: === libffi Summary === # of expected passes1644 # of unsupported tests 15 kfreebsd-i386: === libffi Summary === # of expected passes1644 # of unsupported tests 15 powerpc: === libffi Summary === # of expected passes1644 # of unsupported tests 15 s390: Running /build/buildd-libffi_3.0.10~rc8-1-s390-mB6C2g/libffi-3.0.10~rc8/testsuite/libffi.call/call.exp ... FAIL: libffi.call/err_bad_abi.c -O0 -W -Wall execution test FAIL: libffi.call/err_bad_abi.c -O2 execution test FAIL: libffi.call/err_bad_abi.c -O3 execution test FAIL: libffi.call/err_bad_abi.c -Os execution test FAIL: libffi.call/err_bad_abi.c -O2 -fomit-frame-pointer execution test Running /build/buildd-libffi_3.0.10~rc8-1-s390-mB6C2g/libffi-3.0.10~rc8/testsuite/libffi.special/special.exp ... === libffi Summary === # of expected passes1639 # of unexpected failures5 # of unsupported tests 15 sparc: === libffi Summary === # of expected passes1644 # of unsupported tests 15 mips (mipsel should be the same): === libffi Summary === # of expected passes1644 # of unsupported tests 15 however some test fail for mips64 and the new abi: with -mabi=64: FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_double_va.c -Os output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 Running /home/doko/tmp/libffi-3.0.10~rc8/testsuite/libffi.special/special.exp ... === libffi Summary === # of expected passes1634 # of unexpected failures10 # of unsupported tests 15 with -mabi=n32: FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_pointer.c -O0 -W -Wall (test for excess errors) FAIL: libffi.call/cls_pointer_stack.c -O0 -W -Wall (test for excess errors) FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_pointer.c -O2 (test for excess errors) FAIL: libffi.call/cls_pointer_stack.c -O2 (test for excess errors) FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is 0.0 res: 4 7.0 res: 4 , should match 7.0^M? res: 4^M? 7.0^M? res: 4 FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is 0.0 res: 4 7.0 res: 4 ,
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-s390-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: 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-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6eb11.2080...@debian.org
please update patches / investigate build failures for gcc-4.7 snapshot builds
Please have a look at the gcc-4.7 package in experimental, update patches (hurd, kfreebsd, ARM is fixed in svn), and investigate the build failures (currently ia64, but more will appear). Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee7d60.9000...@debian.org
GCC 4.7 is now the default for x86 architectures
GCC 4.7 is now the default for x86 architectures for all frontends except the D frontends, including KFreeBSD and the Hurd. There are still some build failures which need to be addressed. Out of the ~350 bugs filed, more than the half are fixed, another quarter has patches available, and the remaining quarter isn't blocking any other 4.7 build failures. Many thanks to the patch submitters and NMUers, including Cyril Brulebois, Gregor Herrmann, Paul Tagliamonte for the fixes. This will add one more transition for x86 (libobjc3 - libobjc4), which needs starting with uploads of some GNUstep base packages. The D v2 frontend is likely to be updated to 4.7 before the freeze (no build dependencies). Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7ffd8.9010...@debian.org
Re: GCC 4.7 is now the default for x86 architectures
On 07.05.2012 19:35, Thorsten Glaser wrote: Matthias Klose dixit: GCC 4.7 is now the default for x86 architectures for all frontends except the D frontends, including KFreeBSD and the Hurd. How are the plans for other architectures? I don't have plans to change any other architectures. If a port is not a release architectures (and port maintainers don't plan to make it a release architecture), people can change the default at any time from my point of view. As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_ runtime) told me that it dropped support for an old method of doing things while not fulfilling the promise to get the new method of doing it (don’t exactly remember what it was, /msg js on freenode for details) fixed, with the effect that gobjc-4.7 is virtually useless/broken. This is hearsay, but ask him for details, and check them against reality. I didn't rely on hearsay, but did ask the GNUstep maintainers for feedback. Please join the Debian GNUstep package maintainers ML if you want to add something, or review the past discussion. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa80a89.8070...@debian.org
Re: ppl-1.0 tests fail to build on s390/s390x
[CCing the debian s390 porters] Am 29.01.2013 09:32, schrieb Roberto Bagnara: I just hit the wrong button on the administrative interface of the ppl-devel mailing list. So the message has gone forever before I could read it. Please resend it to the list and accept my apologies. Kind regards, P.S. This is the failure, right? https://buildd.debian.org/fetch.cgi?pkg=pplarch=s390xver=1.0-1stamp=1359396092file=log yes, and the one for s390. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5108667c.5050...@debian.org
Re: ppl-1.0 tests fail to build on s390/s390x
Am 30.01.2013 01:17, schrieb Matthias Klose: [CCing the debian s390 porters] Am 29.01.2013 09:32, schrieb Roberto Bagnara: I just hit the wrong button on the administrative interface of the ppl-devel mailing list. So the message has gone forever before I could read it. Please resend it to the list and accept my apologies. Kind regards, P.S. This is the failure, right? https://buildd.debian.org/fetch.cgi?pkg=pplarch=s390xver=1.0-1stamp=1359396092file=log yes, and the one for s390. and apparently on sparc too. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5109a636.8020...@debian.org
Re: [PPL-devel] ppl-1.0 tests fail to build on s390/s390x
Am 31.01.2013 10:11, schrieb Roberto Bagnara:
On 01/31/13 00:01, Matthias Klose wrote:
Am 30.01.2013 01:17, schrieb Matthias Klose:
[CCing the debian s390 porters]
Am 29.01.2013 09:32, schrieb Roberto Bagnara:
I just hit the wrong button on the administrative interface
of the ppl-devel mailing list. So the message has gone
forever before I could read it.
Please resend it to the list and accept my apologies.
Kind regards,
P.S. This is the failure, right?
https://buildd.debian.org/fetch.cgi?pkg=pplarch=s390xver=1.0-1stamp=1359396092file=log
yes, and the one for s390.
and apparently on sparc too.
This patch should fix them all:
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=3822e9ecd0783a5743dd48cda86ae17ba702c468
Please let us know how it goes.
PPL 1.1 will of course contain the fix and should be released
in a couple of months.
seems to work, however there is now a test failure on s390x
/bin/bash: line 5: 15154 Segmentation fault ${dir}$tst
FAIL: memory2
[...]
==
1 of 203 tests failed
Please report to ppl-de...@cs.unipr.it
==
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory
`/build/buildd-ppl_1.0-3-s390x-TUIydR/ppl-1.0/tests/Polyhedron'
make[3]: *** [check-am] Error 2
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511265ff.4070...@debian.org
changing the java default to java7, and dropping java support for some architectures
It's time to change the Java default to java7, and to drop java support on
architectures with non-working java7.
Patches for the transition to Java7 should be available in the BTS, mostly
submitted by James Page. Some may be still lurking around as diffs in Ubuntu
packages, apologies for that. There are a few cases, where Java7 is not yet an
alternative to Java6, so the transition should not be blocked on these missing
bits. However it should be clear that this is an interim solution, and OpenJDK 6
will be removed for jessie.
Currently java bindings/packages are built for all architectures, however some
architectures still use gcj as the (only available) Java implementation, and
some OpenJDK zero ports are non-functional at this point, and Debian porters
usually don't care about that. So the architectures to drop java support would
be
kfreebsd-any, hurd-i386, mips, mipsel, s390, ia64
- kfreebsd may gain java 7 support at some time, however this shouldn't
be relied on yet.
- hurd never had openjdk support, and afaik, nobody is working on that.
- openjdk support for mips and mipsel is currently broken, with several
requests for help on debian-mips left unanswered.
- I fixed openjdk on s390 for the release, however this architecture is
time comsuming to maintain, and again no answers on debian-s390 asking
for help.
- same experience on ia64, however the zero ports seems to work there.
The list of java archs is a bit changing, and to avoid hardcoding this list into
every source package, I propose to something similiar like done for the gcj
architectures (/usr/share/gcj/debian_defaults). Let the packages be still
architecture any, and decide whether to build arch dependent packages on a make
macro java_archs.
Build dependencies would still need hard-coding of the architecture list, so
another idea would be to keep the default-{jre,jdk} packages on all
architectures and only use them if the architecture is found in java_archs.
Matthias
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5187bca6.3010...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 07.05.2013 15:25, schrieb Matthias Klose: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. [...] Information on porting to GCC 4.8 from previous versions of GCC can be found in the porting guide http://gcc.gnu.org/gcc-4.8/porting_to.html It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove 4.4, 4.6 and 4.7 from jessie. GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. The Java and D frontends now default to 4.8 on all architectures, the Go frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b9c05f.8050...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 21:47, schrieb Thorsten Glaser: Matthias Klose dixit: The Java and D frontends now default to 4.8 on all architectures, the Go frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. I’d like to have gcj at 4.6 in gcc-defaults for m68k please, until the 4.8 one stops FTBFSing. please send a patch. From me nothing against switching C/C++ to 4.8 for m68k at this point, but I’d like to hear at least Wouter’s opinion on that, and possibly Mikael since he’s not just doing work upstream on gcc but also using it (for ColdFire) heavily. same as well, please send a patch. For Ada, I’d like to see a successful build of gnat-4.8 (from src:gcc-4.8, if I understand the recent changes right) first; gnat-4.6 mostly works at the moment, but I’m not sure about the upstream situation wrt. patches from Mikael. try it and send a patch please. thanks for your cooperation, Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51baf88c.3080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 16:46, schrieb Steven Chamberlain: Hi, On 13/06/13 13:51, Matthias Klose wrote: GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. I trust these are the architectures that are okay so far: | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386 no, they are probably not ok, and there surely are yet undiscovered regressions, but at least the ARM porters did agree to address these. Same seems to be true for the kfreebsd and hurd porters. They did change GCC defaults usually at the same time as this was done for the x86 linux archs. So the following would be the architectures for which some response is requested urgently from port maintainers, to confirm they are ready for GCC 4.8 as default: Release arches: ia64 mips mipsel powerpc s390 s390x sparc All the above have built gcc-4.8.1-2 or higher. and nobody committing to scan the bts for architecture specific issues, nobody to prepare test cases, nobody to forward these. Other ports: alpha hppa* m68k powerpcspe ppc64 sh4* sparc64* * these ports don't appear to have successfully built GCC 4.8 yet. afaics, alpha, powerpcspe and ppc64 did build. Note that you cannot trust the hppa status, this port is still denied access to ports.debian.org and is kept in another place. So yes, some of these ports are in better shape than the ports released with wheezy. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bafa9e.5080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 15.06.2013 03:22, schrieb Stephan Schreiber: GCC-4.8 should become the default on ia64 soon; some other changes are desirable: - The transition of gcc-4.8/libgcc1 to libunwind8. - A removal of the libunwind7 dependency of around 4600 packages on ia64 - when they are updated next time after the transition. The libc6.1 should (likely) depend on libunwind8 after that in order to guarantee that libunwind8 is installed. unless some ia64 porter steps up, it doesn't make sense to invest time into the ia64 port. So better drop ia64 now, and don't bother with libunwind on ia64. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bf06cd.3070...@debian.org
status of s390 toolchain maintenance
Hi, yesterday Aurelian Jarno did switch the GCC default to 4.8 in the VCS. However I don't see him in the Debian GCC maintainer list as GCC port maintainer. In the past I only did see s390 contributions and s390 related bug triage from Bastian Blank. Is this change coordinated with Bastian? Please could both of you add the relevant information to the README.Debian (or send me patch), if you are actively involved in GCC maintenance on s390(x)? Also I note that the list of s390 porters on [1] talks in the past tense. Please could you update this list to the list of *current* s390 porters? Plus there is no ports page for s390x at all. I think it would be worthwhile to document who cares about the s390x port, or point to the s390 page if that is the right thing to do. Thanks, Matthias [1] http://www.debian.org/ports/s390/ -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d14f14.7080...@debian.org
Re: Switch default GCC to 4.8 on s390x
Am 23.11.2013 03:33, schrieb Aurelien Jarno: On Mon, Nov 18, 2013 at 09:09:18AM +0100, Matthias Klose wrote: Am 12.11.2013 15:40, schrieb Aurelien Jarno: Hi all, The s390x architecture is still using GCC 4.6 as the default compiler, while most other architectures have already switched to GCC 4.8. It starts to cause problem for building packages: some packages need C11 features to be compiled, while some others assume the default compiler is already GCC 4.8 (in that case they are actually buggy). It would also help having the same default version of GCC than for GCJ, GDC or GFORTRAN. I therefore propose to switch the default compiler on s390x to GCC 4.8 by default. It is already used to build the kernel without any known issue. Any comments or opinion on that? Is this a commitment from Philipp, Bastian or your side to monitor for s390x specific toolchain issues, forward these upstream and feed these back into Debian? It is a commitment from my side, although s390x is well tested upstream and there is therefore not a lot to do. please update debian/README.Debian in gcc-4.8. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529078e4.2010...@debian.org
Bug#732282: stop building java for sparc, sparc64, s390, kfreebsd-any
Package: java-common Version: 0.50 Severity: serious Tags: jessie, sid openjdk-7 currently ftbfs on sparc, sparc64, s390, kfreebsd-any. So please either remove the default-* packages on these archs, or fall back to gcj. - the hotspot port for linux sparc isn't maintained anymore by upstream. If a porter is interested, maybe investigate how to build the zero vm on these architectures. - s390 needs an update of the s390 debian specific patch. Not working on this myself. - the debian kfreebsd patches need an update. I don't think it's feasible to burden the openjdk maintainers or the security team with patch maintenance. I understand that the bsd support is found upstream in openjdk-8, so maybe try that again for the next upstream version. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52aed72a.1070...@debian.org
gcc-4.9 uploaded to experimental
gcc-4.9 is uploaded to experimental, asking the porters to watch for build failures and corresponding patches. See https://buildd.debian.org/status/package.php?p=gcc-4.9suite=experimental These are already fixed in the vcs. - fixed the gospec.c ftbfs on archs without ld.gold - fixed the g++ b-d on armel/armhf Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Re: Roll call for porters of architectures in sid and testing
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar: For mips/mipsel, I - fix toolchain issues together with other developers at ImgTec It is nice to see such a commitment, however in the past I didn't see any such contributions. Matthias -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52de6b8b.2060...@debian.org
preparing for GCC 4.9
With gcc-4.9 now available in testing, it is time to prepare for the change of the default to 4.9, for a subset of architectures or for all (release) architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already point to 4.9 and are used on all architectures. Issue #746805 tracks the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 10.09.2016 09:59, Paul Gevers wrote: > Hi, > > On 10-09-16 00:48, Matthias Klose wrote: >> - fpc not available on powerpc anymore (may have changed recently) > > For whatever it is worth, this was finally fixed this week. It is > missing on mips*, ppc64el and s390x though, while at least some form of > MIPS is supported upstream. the trunk/3.1 works at least for ppc64el too.
The (uncalled for) toolchain maintainers roll call for stretch
While the Debian Release team has some citation about the quality of the toolchain on their status page, it is not one of the release criteria documented by the release team. I'd like to document the status how I do understand it for some of the toolchains available in Debian. I appreciate that the release criteria are somehow "reset" for the stretch release, and not copied from previous release decisions. GNU toolchain (GCC / binutils) -- GCC upstream has the notation of primary and secondary platforms, with the commitment to fix issues on these platforms [1], [2]. Debian architectures within the set of these platforms are: - aarch64-none-linux-gnu (starting with GCC 7) - arm-linux-gnueabi - i686-pc-linux-gnu - powerpc64-unknown-linux-gnu - x86_64-unknown-linux-gnu - s390x-linux-gnu Release architectures missing in the primary and secondary platforms: - armhf - mips* - powerpc - ppc64el As you see with arm64, new architectures become primary or secondary platforms only after a while, so that may explain the absence of powerpc64le-unknown-linux-gnu. The arm-linux-gnueabi is not that well defined, so it may include the hard float variant as well. However Debian default to armv4t, while the default configuration for upstream is armv5. However with the selected defaults Debian's libstdc++::future module is not complete and causes build failures on this architecture (same for sparc). Uncovered by the upstream primary and secondary platforms are the mips* architectures and powerpc. For the uncovered archs I would expect somehow more and pro-active Debian maintenance, however I fail to see this happen. - see the history of ftbfs on the buildd page of the gcc-snapshot package - see the status of the gcc-6 package for the pre-release uploads - see the number of RC issues for binutils which came up with 2.27, some still open. - Toolchain packages are not watched by porters, and I can't track every regression myself, however this is not done well by porters. On the recent Porter's call I didn't see any toolchain support for the powerpc architecture. For the mips* architectures we apparently have five or more active toolchain maintainers. I very much doubt that view. From my point of view these architecture would be perfect candidates for partial architectures, and until then should be removed from the set of the release architectures. For mips* that shouldn't be no news; please see my comments regarding both the toolchain and buildd status since at least DebConf 12 (release meetings during DebConfs). Java/OpenJDK For the stretch release openjdk-8 will be fine as the default java implementation. For buster, gcj (to be removed in GCC 7) won't be available anymore, and we'll end up with architectures without a java implementation. At the same time I'd like to consider to stop providing OpenJDK zero builds, leaving powerpc and mips* without a java implementation as well (currently not building for openjdk-9). armhf (not armel) and s390x have Hotspot ports underway. Other toolchains - clang/llvm not available on armel since 3.8. - fpc not available on powerpc anymore (may have changed recently) - mono not available more on powerpc Being demoted as a release architecture certainly is not a nice thing, and looking at past demotions, these were not done very coordinated, not allowing builds in the ports archive for some months. It would be good to find some middle-ground such that a port's demotion isn't a final thing, and it has a chance to become a release architecture again, maybe even as a partial architecture if we can define the meaning of such a thing. Matthias [1] https://gcc.gnu.org/gcc-6/criteria.html [2] https://gcc.gnu.org/gcc-7/criteria.html
Re: Porter roll call for Debian Stretch
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote: > On 09/20/2016 11:16 PM, Niels Thykier wrote: >>- powerpc: No porter (RM blocker) > > I'd be happy to pick up powerpc to keep it for Stretch. I'm already > maintaining powerpcspe which is very similar to powerpc. No, you are not maintaining powerpcspe as a release architecture, and that's something different than building packages for some of the ports architectures. If you can get powerpcspe accepted as a release architecture, then maybe you gain some credibility to maintain another release architecture ;) Matthias
Re: Enabling PIE by default for Stretch
[CCing porters, please also leave feedback in #835148 for non-release architectures] On 29.09.2016 21:39, Niels Thykier wrote: > Hi, > > As brought up on the meeting last night, I think we should try to go for > PIE by default in Stretch on all release architectures! > * It is a substantial hardening feature > * Upstream has vastly reduced the performance penalty for x86 > * The majority of all porters believe their release architecture is >ready for it. > * We have sufficient time to solve any issues or revert if it turns out >to be too problematic. > > As agreed on during the [meeting], if there are no major concerns to > this proposal in general within a week, I shall file a bug against GCC > requesting PIE by default on all release architectures (with backing > porters). please re-use #835148 > If there are only major concerns with individual architectures, I will > simply exclude said architectures in the "PIE by default" request. > > * Deadline for major concerns: Fri, 7th of October 2016. > > Fall-out > > > There will be some possible fall-out from this change: > > * There will be some FTBFS caused by some packages needing a rebuild >before reverse dependencies can enable PIE. These are a subset of >the bugs filed in the [pie+bindnow] build tests. > > * Some packages may not be ready for PIE. These will have to disable >it per package. A notable case being ghc (#712228), where we can >reuse the patch from Ubuntu to work around the issue. > > * A possible issue from Matthias was that no one has done a large scale >"PIE by default" on "arm* mips*". > > * There was concern about whether the 32bit arm architectures would be >notably affected by the PIE slow down (like x86 used to be). >It is not measured, but two arm porters did mention a possible >slowdown > > * It was questioned whether it made sense to invest time and effort in >enabling PIE for architectures which would not be included in Buster >(armel?). Personally, I do not see an issue, if the porters are >ready to put in the effort required. > > Thanks, > ~Niels > > [meeting]: > http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html > > [pie+bindnow]: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable > > > >
preparing for binutils-2.31
According to [1], binutils 2.31 (currently in experimental) will branch in about a week, and I'll plan to upload the branch version to unstable. Test results are reported to [2], these look reasonable, except for the various mips targets, however as seen in the past, it doesn't make a difference if you wait with the introduction of a new binutils version early or later with the release. These tend to be only fixed as Debian porters report them. Matthias [1] https://sourceware.org/ml/binutils/2018-06/msg00158.html [2] https://sourceware.org/ml/binutils/2018-06/msg00170.html
GCC and binutils updates for buster
GCC 8 is available in testing/unstable, and upstream is approaching the first point release. I am planning to make GCC 8 the default at the end of the week (gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC are already used in the version built from GCC 8, so I don't expect runtime incompatibilities anymore. There is one more transistion involved, bumping the libgfortran version. A pre-release version of binutils 2.31 is in testing now, and the final 2.31 release in unstable. These are the major versions for the upcoming buster release, still planning updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils 2.31.1 release, or doing equivalent updates from the release branches. There are still a bunch of build failures triggered by GCC 8 [1], so fixing these should get some priority now. See [2] for changes in GCC 8, and the porting guide [3]. I'll be at DebCamp for the second half of the week, and at DebConf, so if there is interest for bug squashing sessions, feel free to grab me, and we can schedule such sessions on a short notice. GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as there are upstream kernel and glibc releases which are released after the GCC 8.1.0 release from April. The Debian release team lists toolchain support for our release architectures, and according to [4], the amd64, i386, armel, armhf, arm64 architectures are supported as primary architectures, and s390x is supported as a secondary architectures. Some notes on other candidates for release architectures: - armel: The armv4t default isn't used very much anymore, and we had issues in the past. - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary architecture, I'm told that the arm-linux-armeabi triplet covers the hard float variants as well. - ppc64el: Not documented as primary architecture, but according to the backend maintainers the powerpc64-linux-gnu triplet includes the le variant. - mips*: There is no support for any mips-linux target either as a primary or secondary release architecture (only bare metal), which matches the experience with mips specific issues for the past Debian releases. I understand that port maintainers want to have their port included as a release architecture, however it becomes a burden if neither the upstream nor the Debian port maintainers can keep up with the general upstream development. Maybe we need something in between the alternatives of being a release arch or not, having the benefit of packages in testing/stable, but not being supported in a release. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;users=debian-...@lists.debian.org [2] https://gcc.gnu.org/gcc-8/changes.html [3] https://gcc.gnu.org/gcc-8/porting_to.html [4] https://gcc.gnu.org/gcc-8/criteria.html signature.asc Description: OpenPGP digital signature
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 07.07.18 17:24, YunQiang Su wrote: > Niels Thykier 于2018年6月28日周四 上午4:06写道： >> List of concerns for architectures >> == >> >> The following is a summary from the current architecture qualification >> table. >> >> * Concern for ppc64el and s390x: we are dependent on sponsors for >>hardware. >>(Raised by DSA; carried over from stretch) >> >> * Concern for armel and armhf: only secondary upstream support in GCC >>(Raised by the GCC maintainer; carried over from stretch) I don't think anybody objected about the status for armhf. I didn't follow armel issues too closely. >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) >> > > This is a misunderstanding as MIPS company had some unrest in recent half > year. > Currently we are stable now, and the shape of gcc upstream is also good. This is an optimistic view. While currently not having any RC issues, we still see mips* specific issues popping up more often than on other release architectures. According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux* target listed as either primary or secondary platform. As far as I understand the mips porters argue that this is covered by mipsisa64-elf, a bare metal target. I don't agree with this view, because - testing is missing on mips*-linux-* targets. If you look at the gcc-testresults ML, you see only test reports submitted for the Debian GCC packages, nothing else. - A bare metal target is usually only built/used for C and C++. I doubt that other frontends are tested. - Configurations like libgcjit are not tested/used upstream, and not addressed. See #798710. The Debian bug tracking for the MIPS port could be better, I usually need some pings to the MIPS porters to get things forwarded or addressed. To me it looks sometimes that Debian is used for testing by upstream, and for that the mips architectures don't need to be release architectures. Matthias
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 13.04.19 17:01, Joerg Jaspert wrote: > On 15371 March 1977, Aurelien Jarno wrote: > >>> How is the move to debian-ports supposed to happen? I won't have the >>> time to do anything about it within the 2 weeks. > >> The process to inject all packages to debian-ports is to get all the >> deb, udeb and buildinfo files from the archives (main and debug) and >> associate them with the .changes files that are hosted on coccia. We'll >> also need to fetch all the associated GPG keys used to sign the changes >> files. Then we can inject that in the debian-ports archive. > >> It would be nice to have a bit more than 2 weeks to do all of that. > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this > is on the table already, it doesn't make much difference if its 2 or 8. > Just something thats clear defined and not some random, non-clear > "sometime in the future" point. well, please go back in history to see the same short notice for the hppa removal, and then do the exercise how long it took to integrate that architecture on debian-ports. >
gcc-8 and gcc-9 builds using pgo and lto optimization
The recent gcc-8 and gcc-9 uploads to unstable are now built using pgo and lto optimization. Not on all architectures, see debian/rules.defs. On the plus side the compilers are 7-10% faster, however the build time of the compiler is much longer, adding 10-20 hours. If people feel that this isn't worth the extra build time, please file an issue for the package to disable those optimizations. Matthias
Same procedure as every year: GCC defaults change (GCC 9)
GCC 9 was released earlier this year, it is now available in Debian testing/unstable. I am planning to do the defaults change in mid August, around the time of the expected first GCC 9 point release (9.2.0). There are only soname changes for rather unused shared libraries (libgo) involved, and the gnat defaults change will be handled separately by the Debian Ada maintainers. The fortran module changes look ok according to Alastair McKinstry. The gcc-9 package still ftbfs on kfreebsd-*. We still have local patches for at least the various mips, kfreebsd and hurd targets. Please forward these upstream and make sure that these are applied upstream. powerpcspe support is removed upstream. I will keep pointing the default to GCC 8 for this target. Matthias
GCC and binutils plans for bullseye
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream branch, and binutils based on a binutils package taken from the 2.35 branch. I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available (upstream targets mid July). binutils will be updated before making the GCC switch. The GCC 10 switch involves some minor library transitions for D, gccgo, M2, which should be no-brainers. The gnat transition will be handled separately by the debian Ada maintainers. binutils should be pretty stable until the bullseye release, not planning an update to 2.36. GCC 10 should be updated to 10.3, or close to 10.3 (the release date is not yet known, could be Feb 2021). I'd like to get rid off GCC 8 and GCC 9 for the bullseye release. Matthias
Re: Porter roll call for Debian Bullseye
On 12/1/20 5:02 AM, YunQiang Su wrote: > I am sorry for the later response. >Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Bullseye release (est. end > of 2024): > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
enabling link time optimizations in package builds
Link time optimizations are an optimization that helps with a single digit percent number optimizing both for smaller size, and better speed. These optimizations are available for some time now in GCC. Link time optimizations are also at least turned on in other distros like Fedora, OpenSuse (two years) and Ubuntu (one year). Details at https://wiki.debian.org/ToolChain/LTO The proposal is to turn on LTO by default on most 64bit release architectures. Not proposing to do this on 32bit architectures because of the limited address space at link time, and up to now nobody tested LTO on 32bit archs. In test rebuilds, there were 373 packages (dd-list in the wiki page) found not to build with link time optimizations for various reasons. These range from easily fixable issues in symbols files to some upstream issues. The idea is to fix as many of these as possible, and then change the packaging for the others to just turn off LTO in the package build. To explicitly turn on LTO for a package build: export DEB_BUILD_MAINT_OPTIONS=optimize=+lto to explicitly disable LTO: export DEB_BUILD_MAINT_OPTIONS=optimize=-lto The idea is to file wishlist bug reports for those 373 packages and then see how far we get, and if it's feasible to already turn on LTO for bookworm. If not, it should be turned on by default for the following release. Matthias
