Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

2019-04-16 Thread Matthias Klose
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.


> 



Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

2018-12-09 Thread Matthias Klose
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



GCC and binutils updates for buster

2018-07-17 Thread Matthias Klose
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


preparing for binutils-2.31

2018-06-15 Thread Matthias Klose
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



Re: Enabling PIE by default for Stretch

2016-09-30 Thread Matthias Klose
[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
> 
> 
> 
> 



Re: Porter roll call for Debian Stretch

2016-09-23 Thread Matthias Klose
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: The (uncalled for) toolchain maintainers roll call for stretch

2016-09-10 Thread Matthias Klose
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

2016-09-09 Thread Matthias Klose
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: Bug#759870: gcc-4.9: Compiles zsh endlessly on s390x (maybe sigjmp_buf related)

2014-08-30 Thread Matthias Klose
Control: severity -1 important
Control: tags -1 + help

if it's just zsh, then it's not serious.  Apparently there are some stability
issues with some s390 machines, as seen with other builds as well. CC'ing the
s390 porters.

Am 30.08.2014 um 21:56 schrieb Axel Beckert:
 Package: gcc-4.9
 Version: 4.9.1-9
 Severity: serious
 Affects: src:zsh
 
 Dear GCC Maintainers,
 
 since 2014-08-18 all zsh builds -- sid binNMUs as well as experimental
 uploads -- fail on s390x upon the first gcc invocation by being killed
 after 150 minutes of inactivity. Previous builds always took less than
 15, sometimes just 5 minutes. See
 
   https://buildd.debian.org/status/logs.php?pkg=zsharch=s390x
 
 One example:
 
   make[3]: Entering directory '/«PKGBUILDDIR»/obj/Src'
   gcc -c -I. -I../Src -I../../Src -I../../Src/Zle -I../../Src 
 -D_FORTIFY_SOURCE=2  -DHAVE_CONFIG_H -g -O2 -fstack-protector-strong -Wformat 
 -Werror=format-security -Wall -g  -o builtin.o ../../Src/builtin.c
   E: Caught signal ‘Terminated’: terminating immediately
   make[3]: *** [builtin.o] Terminated
   make[2]: *** [modobjs] Terminated
   make[1]: *** [all] Terminated
   make: *** [build-arch] Terminated
   Makemod:231: recipe for target 'builtin.o' failed
   Makefile:451: recipe for target 'modobjs' failed
   Makefile:189: recipe for target 'all' failed
   debian/rules:48: recipe for target 'build-arch' failed
   Build killed with signal TERM after 150 minutes of inactivity
 
 Waldi suspects some breakage related to the sigjmp_buf ABI issue. At
 least zsh uses sigjmp_buf. Waldi also said on IRC he can reproduce the
 issue.


-- 
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/54023c6c.4060...@debian.org



preparing for GCC 4.9

2014-05-08 Thread Matthias Klose
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: Roll call for porters of architectures in sid and testing

2014-01-21 Thread Matthias Klose
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



gcc-4.9 uploaded to experimental

2014-01-10 Thread Matthias Klose
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



Bug#732282: stop building java for sparc, sparc64, s390, kfreebsd-any

2013-12-16 Thread Matthias Klose
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



Re: Switch default GCC to 4.8 on s390x

2013-11-23 Thread Matthias Klose
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



Re: Switch default GCC to 4.8 on s390x

2013-11-23 Thread Matthias Klose
Am 23.11.2013 13:52, schrieb Aurelien Jarno:
 On Sat, Nov 23, 2013 at 10:44:04AM +0100, Matthias Klose wrote:
 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.
 
 
 Done. That said I still don't understand why only a limited list of 
 architectures have to do that. I do not believe that architectures not 
 listed there are actually better supported in Debian.

It's the other way around. Every architecture should have an entry. But maybe
it is easier to mention which architectures currently don't have such entries,
namely sparc, s390, ia64, powerpc, ppc64.

x86 should be waived. we do have active contributors for kfreebsd, the hurd,
m68k, alpha, powerpcspe, mips64, hppa at least.  arm* is missing here, but it
is usually taken care of by myself.

  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/5290be38.8000...@debian.org



Re: Switch default GCC to 4.8 on s390x

2013-11-18 Thread Matthias Klose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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?

  Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKJyy4ACgkQStlRaw+TLJwQGQCfd6wETFZutdAdfPZQEnX2KhVa
z9kAmwdkwmbge78wuh+a9Jqb+81Q8AaT
=vzb7
-END PGP SIGNATURE-


-- 
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/5289cb2e.9020...@debian.org



status of s390 toolchain maintenance

2013-07-01 Thread Matthias Klose
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: Current and upcoming toolchain changes for jessie

2013-06-17 Thread Matthias Klose
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



Re: Current and upcoming toolchain changes for jessie

2013-06-14 Thread Matthias Klose
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

2013-06-14 Thread Matthias Klose
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

2013-06-13 Thread Matthias Klose
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



changing the java default to java7, and dropping java support for some architectures

2013-05-06 Thread Matthias Klose
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: [PPL-devel] ppl-1.0 tests fail to build on s390/s390x

2013-02-06 Thread Matthias Klose
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



Re: ppl-1.0 tests fail to build on s390/s390x

2013-01-30 Thread Matthias Klose
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-1.0 tests fail to build on s390/s390x

2013-01-29 Thread 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.


-- 
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



GCC 4.7 is now the default for x86 architectures

2012-05-07 Thread Matthias Klose
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

2012-05-07 Thread Matthias Klose
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



please update patches / investigate build failures for gcc-4.7 snapshot builds

2011-12-18 Thread Matthias Klose
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



Re: GCC-4.5 as the default for (at least some) architectures

2011-04-26 Thread Matthias Klose

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

2011-04-26 Thread Matthias Klose

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



libffi 3.0.10 rc8 test results

2011-04-23 Thread Matthias Klose

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: DSO linking changes for wheezy

2010-11-15 Thread Matthias Klose

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

2010-11-15 Thread Matthias Klose

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



DSO linking changes for wheezy

2010-10-29 Thread Matthias Klose
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



any objections from port maintainers to make gcc-4.4 the default?

2009-09-20 Thread Matthias Klose
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

2009-09-20 Thread Matthias Klose

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

2009-09-20 Thread Matthias Klose

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



Re: Sparc release requalification

2009-08-20 Thread Matthias Klose

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



Re: Sparc release requalification

2009-08-19 Thread Matthias Klose

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

2009-08-19 Thread Matthias Klose

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



OpenJDK Cacao GCJ Java defaults in unstable

2009-03-15 Thread Matthias Klose
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: Proper way to specify Java build-dep

2008-05-07 Thread Matthias Klose
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]



java status on the ports

2008-02-06 Thread Matthias Klose
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]



GCC 4.2 transition

2007-07-20 Thread Matthias Klose
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]



gnat-4.1/gcj-4.1 manual builds needed on alpha, arm, m68k, mips, mipsel, s390, sparc

2007-06-10 Thread Matthias Klose
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]