Bug#991476: redis: insane amount of memory used by the testsuite on s390x
Package: redis Version: 5:6.2.5-1 Severity: serious X-Debbugs-Cc: debian-s390@lists.debian.org Since redis version 5:6.2.5-1, the redis-server process on s390x tries to allocate insane amount of memory, 2560 PiB, causing the build daemon to OOM just to maintain the page tables of such amount of memory: | [59125.870223] Out of memory: Killed process 1142100 (redis-server) total-vm:2814749767178764kB, anon-rss:0kB, file-rss:8kB, shmem-rss:0kB, UID:2952 pgtables:7908616kB oom_score_adj:0 The last message in the build log is: | [ok]: corrupt payload: OOM in rdbGenericLoadStringObject Version 5:6.2.4-1 built fine, so it's likely a regression introduced in the new upstream version.
Re: Problems with the giac package : different failures on buildd and porterbox !?
On 2020-01-23 07:52, Julien Puydt wrote: > Le mercredi 22 janvier 2020 à 21:29 +0100, Julien Puydt a écrit : > > > I wanted to work on it and get meaningful data for upstream, so > > turned > > to zelenka, the porterbox for this architecture. I followed the > > tutorial here https://dsa.debian.org/doc/schroot/ - as I'm already > > used > > to do when I get problems with other packages. But this time, the > > documentation step already fails : > > *** bug in PARI/GP (Segmentation Fault), please report. > > (repeated quite a few times before the compilation dies) > > s390x is a big-endian architecture. The build failure on ppc64 and sparc64 are really similar, so I believe the issue is related to endianness. > The compiled calculator gives strange results: > 0>> 1/2.0-1/3 > 5.46834151467e-304 > // Time 0 > 1>> 1/2.0 > 3.64556100978e-304 > // Time 0 > 2>> 1/3 > 1/3 > // Time 0 > 3>> 1/1. > 3.64556100978e-304 > // Time 0 > 4>> 1. > 3.64556100978e-304 > // Time 0 > > The last example shows that it's not just a computation problem. That behaviour clearly shows that what is displayed is not the result of the computation. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Same procedure as every year: GCC defaults change (GCC 9)
On 2019-07-27 17:28, Matthias Klose wrote: > 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 To be more exhaustive, for release architectures there are also patches concerning the arm target and for other architectures patches concerning the alpha, ia64 and sparc targets. > targets. Please forward these upstream and make sure that these are applied > upstream. The two MIPS libffi patches have been accepted upstream (i.e. in the libffi git repository) 1.5 years ago for one and 4 years ago for the other. I know there hasn't been any recent libffi release, so what can be done to sync the gcc repository? Would it be possible to stop using that outdated embedded copy and use the debian libffi package instead? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019-05-25 13:00, Manuel A. Fernandez Montecelo wrote: > Hi, > > Em sáb, 25 de mai de 2019 às 10:57, Aurelien Jarno > escreveu: > > > > kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As > > hurd-i386 has been moved earlier, it means that all the 3 architectures > > have now been moved. > > Nice :-) > > Not sure who's the admin (I couldn't find the admin address in the > main pages), but they're not registered in the graphs (while > powerpcpse, recently removed, still is). > > https://buildd.debian.org/stats/graph-ports-week-big.png There are still available on the on the main graph: https://buildd.debian.org/stats/graph-week-big.png I'll move hurd and kbsd-* plots from the main one to the ports one, but unless we do not keep the history, it's not a trivial task as it requires migrating the data from one text database to the other database. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Hi, On 2019-04-24 12:34, Joerg Jaspert wrote: > On 15381 March 1977, Aurelien Jarno wrote: > > > > > 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. > > The hurd-i386 architecture has been moved to to debian-ports yesterday. > > I hope it shows the willingness to do that. Please give us at least 4 > > more weeks to do the remaining kfreebsd-*. That will provide some margin > > to account for the non-infinite free time to work on that (especially in > > the freeze period) and possibly to get more disk space for the > > debian-ports machine. > > Thats ok, end of May is a nice point to take. > > Thanks for the work and the timeframe for the rest! kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As hurd-i386 has been moved earlier, it means that all the 3 architectures have now been moved. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019-04-13 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. The hurd-i386 architecture has been moved to to debian-ports yesterday. I hope it shows the willingness to do that. Please give us at least 4 more weeks to do the remaining kfreebsd-*. That will provide some margin to account for the non-infinite free time to work on that (especially in the freeze period) and possibly to get more disk space for the debian-ports machine. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019-04-12 23:01, Samuel Thibault wrote: > Hello, > > Joerg Jaspert, le ven. 12 avril 2019 22:48:42 +0200, a ecrit: > > back in August 2018 we discussed architecture inclusion into > > unstable/experimental. > > > > Today we had our regular FTPMaster meeting and discussed hurd and both > > kfreebsd architecture and decided to remove them from unstable and > > experimental 2 weeks from now. > > Just before the Buster release? That's far from the easiest timing. > > I was hoping to do a non-official relase of Debian Hurd along Buster as > usual, but a change of archive, which means uploading packages, fixing > scripts, etc. will take a lot of time, which I simply just will not have > within the coming two-three months (I am already struggling to find time > to do what I engaged to). Basically, it means no non-official release of > Debian Hurd along Buster. Or at best I could just make that non-official > release now, with all the still pending RC bugs. > > 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. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#890780: release-notes: document that s390x now require at least a z196 CPU
Package: release-notes Severity: normal The s390x baseline ISA has been raised to z196 in buster [1]. This should be mentioned in the release notes. I'll try to work on a patch in the next days. I am filling this bug to make sure I do not forget. [1] https://lists.debian.org/debian-s390/2018/02/msg8.html
s390x ISA raised to z196
Hi all, Following the RFC on this mailing list[1], the baseline ISA of the s390x port has been raised z196. This allows Debian to support packages like rust, go or nodejs, which do not support older ISAs. For now only this packages are affected, but in the future the default ISA in GCC will also be raised, so more and more packages will use the corresponding instructions. As a consequence people should not upgrade to buster or sid if they have and older CPU. The change does not affect Stretch, which will still be supported for a bit more than 2 years. Regards, Aurelien [1] https://lists.debian.org/debian-s390/2018/01/msg00015.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Raising the minimum required s390x CPU to z196?
On 2018-01-31 15:38, Aurelien Jarno wrote: > Hi all, > > The Debian s390x port currently officially defaults to the z900 ISA. > That's what our GCC defaults too, but I wouldn't be surprised if a few > packages use a slightly newer ISA. > > Unfortunately more and more packages require a newer ISA, usually at > least z196. This is the case of at least nodejs, go and rustc. It should > be noted that it's not a question of passing the right flag to GCC, but > rather these packages have their own JIT compiler which has been written > for a z196 ISA minimum. > > For go we currently use gccgo instead of golang, which is not really > an optimal solution and prevents many packages to build. For the same > reason rustc is not available on s390x, which might become problematic > soon (for example rsvg will require it soon). Finally recent versions > of nodejs require at least a z196 CPU, so we have to drop all nodejs > packages if we want to keep the baseline as z900. > > In my opinion we don't really have any other choice than raising the > minimum ISA to z196, even if this CPU is less than 7 years old. The > the only other alternative I can think about would be to have people > committing to maintain patches lowering the minimum ISA for the above > packages. I started to work on that for go a few months ago, but > unfortunately that's a huge work as upstream keeps moving. Note that both hercules and QEMU are able to simulate a z196 CPU, or at least the facilities used by the Linux kernel and user land when built for z196. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Raising the minimum required s390x CPU to z196?
Hi all, The Debian s390x port currently officially defaults to the z900 ISA. That's what our GCC defaults too, but I wouldn't be surprised if a few packages use a slightly newer ISA. Unfortunately more and more packages require a newer ISA, usually at least z196. This is the case of at least nodejs, go and rustc. It should be noted that it's not a question of passing the right flag to GCC, but rather these packages have their own JIT compiler which has been written for a z196 ISA minimum. For go we currently use gccgo instead of golang, which is not really an optimal solution and prevents many packages to build. For the same reason rustc is not available on s390x, which might become problematic soon (for example rsvg will require it soon). Finally recent versions of nodejs require at least a z196 CPU, so we have to drop all nodejs packages if we want to keep the baseline as z900. In my opinion we don't really have any other choice than raising the minimum ISA to z196, even if this CPU is less than 7 years old. The the only other alternative I can think about would be to have people committing to maintain patches lowering the minimum ISA for the above packages. I started to work on that for go a few months ago, but unfortunately that's a huge work as upstream keeps moving. The ISA change would be done in testing/unstable and released for Buster. Stretch would be unchanged in that regard and it will continue to be supported for 2 more years. Note also that it means that we would have to get rid of our older build daemon, zemlinsky.d.o. We would still have 2 buildd daemons in 2 different locations left, which is enough to run the port. However that would be appreciable to get a third one to fully secure the port. Any opinion, or alternative solution? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#886294: transition: nodejs
On 2018-01-24 13:24, Emilio Pozuelo Monfort wrote: > On 23/01/18 19:21, Jérémy Lal wrote: > > cc-ing s390x team to ask (re)building nodejs-8.9.3~dfsg-11 on zemlinsky. > > > > but on s390x you're getting > > illegal instructions on zemlinsky, which is a Z10 mainframe. > > Looks > > like newer > > node possibly bumped the baseline, or just accidentally > > introduced > > instructions > > not supported by our baseline. > > > > > > Starting investigations about that. Hopefully it's a change that > > could > > have been > > backward-compatible. > > > > > > nodejs/v8 somewhat officially support s390x down to z196. > > I removed the added march=z196 flag and uploaded it into > > nodejs-8.9.3~dfsg-11. > > It would be wonderful to build it on zemlinsky to see what happens. > > Still fails: https://buildd.debian.org/status/package.php?p=node-srs=sid I requeued nodejs on zemlinsky and it also failed. After a quick check, it appears that It uses he load/store on condition 1 facility directly, ie not in GCC generated code. The change is therefore intentional. This facility has been introduced with the z196. > Our baseline is z10, and z196 is newer. So if upstream now requires z196, we > have three options: Officially our baseline is still z900. > - Revert / fix that so upstream works with z10 again > - Remove nodejs from s390x > - Bump our baseline > > See go and rustc for similar problems. Bumping the baseline to z196 looks like the easiest way and as you said, it would also fix go, rustc and maybe more software. However we discussed raising the ISA to z10 about one year and a half ago, and the conclusion was that we still have users with older machines. I'll try to restart the discussion again. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu
On 2017-10-19 16:31, Philipp Kern wrote: > On 10/19/2017 03:06 PM, Michael Tokarev wrote: > > Debian has much stricter policy wrt blobs (DFSG), > > and debian builds for more architectures (the firmware, > > if it is part of qemu-system-s390 package, needs to be > > built on all architectures where this binary package > > builts, or it needs to be a separate arch-all package). > > Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu > exists in Debian, although only on i386 and amd64. I don't think there's > a policy today that precludes you from forcing users to build arch:all > on amd64 for technical reasons. Indeed that's one option to build it, that's for example the solution chosen to build slof using gcc-powerpc64-linux-gnu. So far nobody complained it's buildable only on amd64, i386, ppc64el and x32. The other alternative is to build a cross-compiler using binutils-source and gcc-source (that requires that the none or elf os is supported for this architecture). This has the advantage of ignoring all the flags that debhelper tries to push that make a firmware to not build or break. That's the solution chosen for example for openbios. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu
On 2017-10-19 18:15, Dimitri John Ledkov wrote: > On 19 October 2017 at 15:31, Philipp Kern <pk...@debian.org> wrote: > > On 10/19/2017 03:06 PM, Michael Tokarev wrote: > >> Debian has much stricter policy wrt blobs (DFSG), > >> and debian builds for more architectures (the firmware, > >> if it is part of qemu-system-s390 package, needs to be > >> built on all architectures where this binary package > >> builts, or it needs to be a separate arch-all package). > > > > Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu > > exists in Debian, although only on i386 and amd64. I don't think there's > > a policy today that precludes you from forcing users to build arch:all > > on amd64 for technical reasons. > > > > Kind regards > > Philipp Kern > > > > The s390x firmware in question, is built from source, on Ubuntu, on > every src:qemu upload on the s390x architecture and shipped in an > arch:s390x package. > > qemu-system-s390x requires to run on the s390x hardware, as it is > effectively passthrough kvm only, and is not userspace emulated. > (Does not work on non-s390x machines). Maybe because Ubuntu decided to build it only on s390x. Debian ships it built for other architectures and it works perfectly. You can emulate an s390x with qemu-system-s390x on amd64, arm or mips. This firmware works too. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: binutils: s390x: fails to link systemd binaries using LTO
On 2017-06-21 00:21, Michael Biebl wrote:
> Hi Aurelien
>
> Am 20.06.2017 um 23:56 schrieb Aurelien Jarno:
> > Could you please Cc the s390x porters next time? That would make us
> > notice the issue faster.
>
> Hm, when filing the bug report I used X-Debbugs-CC and got this
> confirmation:
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
> debian-s390@lists.debian.org
>
> Did this not reach the correct mailing list?
The mailing list is correct. That said, I don't see any track of the
original email in my mbox nor on the web archive. It might also be a
problem with the BTS.
> > The problem is related to the fact that gold is not available on s390x.
> > It seems gold is less strict than ld in having to link with each used
> > library. The problem can be fully reproduced on amd64 by using ld instead
> > of gold:
> >
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -312,7 +312,7 @@ link_test_c = files('tools/meson-link-test.c')
> > foreach arg : ['-Wl,-z,relro',
> > '-Wl,-z,now',
> > '-pie',
> > - '-Wl,-fuse-ld=gold',
> > + '-Wl,-fuse-ld=ld',
> >]
> >
> > have = run_command(check_compilation_sh,
> >
> >
> > Now to come back to the problem, the test is linked against
> > src/libsystemd/libsystemd.a which uses pthread_sigmask. It looks
> > therefore normal to add -lpthread to link it.
>
> Thanks for having a look. Will forward this issue to systemd upstream
> after verifying that adding -lpthread fixes the issue.
Thanks.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Re: binutils: s390x: fails to link systemd binaries using LTO
On 2017-06-19 23:50, Michael Biebl wrote:
> On Tue, 30 May 2017 22:21:04 +0200 Michael Biebl <bi...@debian.org> wrote:
> > Package: binutils
> > Version: 2.28-5
> > Severity: normal
> > User: debian-s390@lists.debian.org
> > Usertags: s390x
> >
> > Hi,
> >
> > we run into a strange issue when trying to compile systemd git master
> > using meson. The build/link failure is s390x specific so I've CCed the
> > s390x porters mailing list. The problem is easily reproducible on the
> > zelenka porterbox. with the following commands:
> >
> > sessionid=$(schroot -b -c sid)
> > dd-schroot-cmd -c $sessionid apt-get update
> > dd-schroot-cmd -c $sessionid apt-get upgrade -y
> > dd-schroot-cmd -c $sessionid apt-get build-dep systemd -y
> > dd-schroot-cmd -c $sessionid apt-get install meson git -y
> > schroot -r -c $sessionid
> > git clone https://github.com/systemd/systemd
> > cd systemd
> > export LANG=C.UTF-8
> > meson -Db_lto=true -Dlink-udev-shared=false build
> > ninja -C build
> >
> > This will lead to a failure to link the systemd-networkd,
> > test-network-tables and test-network binaries. I've attached the
> > relevant excerpt from the build log.
> >
> > Since this issue seems to be arch specific, this appears to be a problem
> > in the s390x toolchain and not systemd itself.
> >
> > We would appreciate if the s390(x) porters could have a look.
Could you please Cc the s390x porters next time? That would make us
notice the issue faster.
> Any feedback fro the s390 porters?
The problem is related to the fact that gold is not available on s390x.
It seems gold is less strict than ld in having to link with each used
library. The problem can be fully reproduced on amd64 by using ld instead
of gold:
--- a/meson.build
+++ b/meson.build
@@ -312,7 +312,7 @@ link_test_c = files('tools/meson-link-test.c')
foreach arg : ['-Wl,-z,relro',
'-Wl,-z,now',
'-pie',
- '-Wl,-fuse-ld=gold',
+ '-Wl,-fuse-ld=ld',
]
have = run_command(check_compilation_sh,
Now to come back to the problem, the test is linked against
src/libsystemd/libsystemd.a which uses pthread_sigmask. It looks
therefore normal to add -lpthread to link it.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Re: help fixing gitlab-workhorse build failure on s390x
Hi, On 2016-11-04 16:18, Pirate Praveen wrote: > [cc me on replies from s390 list] > > gitlab-workhorse is blocking gitlab 8.12.3 migration to testing for > sometime now. I fixed two issues with powerpc build but this issue seems > hard to crack. > > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843148 for details > > Any help fixing this issue would be great. The problem is that the latest version of go introduce a requirement of a z196 CPU, which is higher than the ISA we use in Debian and for which we only have one build daemon (zandonai). While technically we can force packages to not be built on some build daemons (the list might be quite long for go related packages), we can't really do that practically as it means we won't be able to offer security packages in time if the build daemon is down during a few days. In practice the maximum downtime over the last years has been around one minute, but we can't predict what it will be in the future. I have started to modify the go code to lower the required ISA (removing the use of the DO opcodes), but it's something that takes time. I hope to finish it in the next weeks or months though, so before the freeze. In the meantime maybe we can manually force it to be built on zandonai manually. I also guess we should have a single bug open on the go package with an "affects" on the other packages. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Porter roll call for Debian Stretch
Hi, On 2016-08-17 22:05, ni...@thykier.net wrote: > Hi, > > Like last release, we are doing a roll call for porters of all release > architectures. If you are an active porter behind one of the [release > architectures] for the entire lifetime of Debian Stretch (est. end of > 2020), please respond with a signed email containing the following > before Friday, the 9th of September: Just a short reminder about that, given the deadline is approaching. If I am not mistaken, I am the only one who answered. We need at least 3 porters to have a chance for the s390x port to be released with Stretch. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#821347: libsecret porting for s390x
On 2016-08-28 18:55, Aurelien Jarno wrote: > control: tag -1 + patch > control: tag -1 + upstream > control: tag -1 + fixed-upstream > > On 2016-08-25 14:16, Aurelien Jarno wrote: > > I am therefore cloning this bug and reassigning the clone to pygobject. > > I don't simply reassigning it as the /collection/delete-sync test is > > also failing, though it seems to not be fully reproducible and seems to > > also happen on other architectures (mipsel for example). > > I have difficulties to reproduce the /collection/delete-sync failure. It > seems to happen roughly once every 5 builds, and I have not yet managed > to reproduce the issue when running only this test. I believe there is > some race condition or bug in the mock service, which might not be s390x > specific (it also failed in previous versions on at least armhf, hppa and > mipsel). I have been able to reproduce the issue on amd64 by running test-collection 1000 times in a loop: | $ for i in $(seq 1 1000) ; do dbus-run-session ./test-collection --verbose ; done I ended up with 39 failures. The failures look like: | GTest: run: /collection/delete-sync | (MSG: MESSAGE: Remote error from secret service: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying) | ** Message: Remote error from secret service: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying | (MSG: FATAL-WARNING: couldn't set SecretCollection Label: Message recipient disconnected from message bus without replying) | | ** (test-collection:20959): WARNING **: couldn't set SecretCollection Label: Message recipient disconnected from message bus without replying That said, I haven't been able to reproduce the issue by running only the delete-sync test 1 times with the following command, both on amd64 and s390x: | $ for i in $(seq 1 1) ; do dbus-run-session ./test-collection -p /collection/delete-sync --verbose ; done Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#835413: pygobject: wrong enum to hash conversion on 64-bit big endian
control: tag -1 + patch
On 2016-08-25 14:16, Aurelien Jarno wrote:
> On 2016-08-25 09:15, Aurelien Jarno wrote:
> > I have tried to debug the issue, and I came to the same conclusion. The
> > problem happens in the test-py-lookup.py test when creating a schema
> > with Secret.Schema.new. The schema is defined in python using a
> > dictionary which is then transformed by gobject-introspection into a
> > to a GHashTable in order to call secret_schema_newv. This hash table
> > maps strings to enum (ie a 32-bit value).
> >
> > In practice the hash table stores two gpointers, so the 32-bit value
> > has to be converted first to a pointer using GINT_TO_POINTER and when
> > read again converted with GPOINTER_TO_INT. The latter is correctly done
> > in libsecret, but the former doesn't seems to be done in
> > gobject-introspection. Therefore on a 64-bit little endian system, the
> > lower 32 bits are stored correctly, but the high 32 bits are left
> > unchanged as garbage. It's not a problem as GPOINTER_TO_INT just remove
> > this garbage. On a 64-bit big endian system, the value is stored on the
> > higher 32-bits, and the lower 32 bits are left unchanged as garbage.
> > Therefore GPOINTER_TO_INT just trash the value, just leaving the
> > garbage.
> >
> > By changing the conversion in secret_schema_newv from
> > type = GPOINTER_TO_INT (value);
> > to
> > type = (gint)(((unsigned long) value) >> 32);
> > the testsuite is able to pass.
> >
> > Of course this is not an acceptable patch and now we have to find where
> > in the whole gobject-introspection chain where to add the missing
> > GINT_TO_POINTER conversion.
>
> The problem is actually in pygobject. enums are represented with a
> GI_TYPE_TAG_INTERFACE type, which corresponds to an "extended
> interface object". They are treated by _pygi_arg_to_hash_pointer (in
> gi/pygi-argument.c) as a pointer instead of a 32-bit value. The correct
> way to do that is to pass a GITypeInfo to the function so that it's
> possible to query the subtype of the GI_TYPE_TAG_INTERFACE type.
>
> I am therefore cloning this bug and reassigning the clone to pygobject.
> I don't simply reassigning it as the /collection/delete-sync test is
> also failing, though it seems to not be fully reproducible and seems to
> also happen on other architectures (mipsel for example).
>
> I have a dirty patch that works, I'll work on cleaning it so that it can
> be applied. It might take a few days.
Please find a patch attached. It fixes the test-py-lookup.py test in
libsecret so that it doesn't hang nor fail.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
From 8dde1d4951b71181193ab5278334eff1d6f998cb Mon Sep 17 00:00:00 2001
From: Aurelien Jarno <aurel...@aurel32.net>
Date: Fri, 26 Aug 2016 12:43:51 +0200
Subject: [PATCH] Fix list/hashtable enum <-> hash conversion on 64-bit big
endian
glist and ghashtable objects both store pointers. Complex objects are
stored as pointers to the objects, but simpler objects like an integer
value are stored directly as a pointer, using for example the
GINT_TO_POINTER and GPOINTER_TO_INT macros.
This is done in pygobject with the _pygi_hash_pointer_to_arg and
_pygi_arg_to_hash_pointer functions. These functions handle the various
type of objects. However they consider that an enum, represented with the
GI_TYPE_TAG_INTERFACE type (extended interface object), are always a
pointer. This is wrong as it is often a 32-bit value. Therefore on 64-bit
big endian machines, the value is handle with the 2 32-bit parts swapped.
This patches fixes that by changing the second argument of both functions
from GITypeTag to GITypeInfo. This way the interface can be determined,
and the underlying storage type can also be determined. This currently
only handles enum and flags, leaving other types as pointers.
---
gi/pygi-argument.c | 32
gi/pygi-argument.h | 4 ++--
gi/pygi-hashtable.c | 8
gi/pygi-list.c | 8
4 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/gi/pygi-argument.c b/gi/pygi-argument.c
index e9bfe3b..db82be5 100644
--- a/gi/pygi-argument.c
+++ b/gi/pygi-argument.c
@@ -85,10 +85,32 @@ pygi_argument_to_gssize (GIArgument *arg_in,
}
}
+static GITypeTag
+_pygi_get_storage_type (GITypeInfo *type_info)
+{
+GITypeTag type_tag = g_type_info_get_tag (type_info);
+
+if (type_tag == GI_TYPE_TAG_INTERFACE) {
+GIBaseInfo *interface = g_type_info_get_interface (type_info);
+switch (g_base_info_get_type (interface)) {
+case GI_INFO_TYPE_ENUM:
+case GI_INFO_TYPE_FLAGS:
+type_tag = g_enum_i
Re: Bug#821347: libsecret porting for s390x
clone 821347 -1 reassign -1 pygobject retitle -1 pygobject: wrong enum to hash conversion on 64-bit big endian affects -1 libsecret block 821347 by -1 thanks On 2016-08-25 09:15, Aurelien Jarno wrote: > On 2016-07-27 14:23, Emilio Pozuelo Monfort wrote: > > On 27/07/16 14:16, Aurelien Jarno wrote: > > > On 2016-07-10 21:24, Andreas Henriksson wrote: > > >> Hello Bastian Blank. > > >> > > >> On Sun, Jul 10, 2016 at 12:33:12PM +0200, Bastian Blank wrote: > > >>> On Sun, Jun 26, 2016 at 10:12:31PM +0200, Andreas Henriksson wrote: > > >>>> I'd like to ask for your help with looking at the problems building > > >>>> libsecret on s390x. It's currently the only (release-)architecture > > >>>> not building and blocking testing migration for a long time. :( > > >>> > > >>> What was the result of your manual build on the s390x porter machine? > > >> > > >> Building on a porter box (zelenka) seems to run into the same issue > > >> and build gets stuck after: > > >> PASS: test-collection 27 /collection/search-secrets-async > > >> > > >> Same as in: > > >> https://buildd.debian.org/status/fetch.php?pkg=libsecret=s390x=0.18.5-1=1462961523 > > > > > > Note that it also fails the same way on ppc64 and s390x. It therefore > > > looks like a 64-bit big endian issue. It could be for example a pointer > > > to an int value casted to a pointer to a long value or vice-versa. > > > > I started to look at this the last weekend. I haven't found the cause yet, > > but I > > believe it's a bug in gobject-introspection, indeed related to 32 vs 64 bit > > values. I will try to look at it some more in the next few days. > > I have tried to debug the issue, and I came to the same conclusion. The > problem happens in the test-py-lookup.py test when creating a schema > with Secret.Schema.new. The schema is defined in python using a > dictionary which is then transformed by gobject-introspection into a > to a GHashTable in order to call secret_schema_newv. This hash table > maps strings to enum (ie a 32-bit value). > > In practice the hash table stores two gpointers, so the 32-bit value > has to be converted first to a pointer using GINT_TO_POINTER and when > read again converted with GPOINTER_TO_INT. The latter is correctly done > in libsecret, but the former doesn't seems to be done in > gobject-introspection. Therefore on a 64-bit little endian system, the > lower 32 bits are stored correctly, but the high 32 bits are left > unchanged as garbage. It's not a problem as GPOINTER_TO_INT just remove > this garbage. On a 64-bit big endian system, the value is stored on the > higher 32-bits, and the lower 32 bits are left unchanged as garbage. > Therefore GPOINTER_TO_INT just trash the value, just leaving the > garbage. > > By changing the conversion in secret_schema_newv from > type = GPOINTER_TO_INT (value); > to > type = (gint)(((unsigned long) value) >> 32); > the testsuite is able to pass. > > Of course this is not an acceptable patch and now we have to find where > in the whole gobject-introspection chain where to add the missing > GINT_TO_POINTER conversion. The problem is actually in pygobject. enums are represented with a GI_TYPE_TAG_INTERFACE type, which corresponds to an "extended interface object". They are treated by _pygi_arg_to_hash_pointer (in gi/pygi-argument.c) as a pointer instead of a 32-bit value. The correct way to do that is to pass a GITypeInfo to the function so that it's possible to query the subtype of the GI_TYPE_TAG_INTERFACE type. I am therefore cloning this bug and reassigning the clone to pygobject. I don't simply reassigning it as the /collection/delete-sync test is also failing, though it seems to not be fully reproducible and seems to also happen on other architectures (mipsel for example). I have a dirty patch that works, I'll work on cleaning it so that it can be applied. It might take a few days. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Z3 build on s390x
On 2016-07-21 22:36, Fabian Wolff wrote: > Dear s390x porters, > > recently, I did two NMUs for the z3 package to help resolve some > release-critical bugs and consequently have it enter testing again. > > The latter goal seems to have been obstructed by an unexpected build > failure on s390x [1]. All other release architectures build the > package just fine. > > In fact, the Ubuntu s390x build servers built the exact same package > successfully, too [2], which makes me wonder whether this might be an > issue not with the package itself but with the buildd infrastructure, > especially after finding out libsecret has a very similar problem > [3]. > > Since I am not a DD myself, I do not have access to any porter > machines, which is why I would like to ask for help with identifying > and hopefully fixing the problem. > It build successfully after a give-back, so it's likely a transient issue in the testsuite. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: libsecret porting for s390x
On 2016-07-10 21:24, Andreas Henriksson wrote: > Hello Bastian Blank. > > On Sun, Jul 10, 2016 at 12:33:12PM +0200, Bastian Blank wrote: > > On Sun, Jun 26, 2016 at 10:12:31PM +0200, Andreas Henriksson wrote: > > > I'd like to ask for your help with looking at the problems building > > > libsecret on s390x. It's currently the only (release-)architecture > > > not building and blocking testing migration for a long time. :( > > > > What was the result of your manual build on the s390x porter machine? > > Building on a porter box (zelenka) seems to run into the same issue > and build gets stuck after: > PASS: test-collection 27 /collection/search-secrets-async > > Same as in: > https://buildd.debian.org/status/fetch.php?pkg=libsecret=s390x=0.18.5-1=1462961523 Note that it also fails the same way on ppc64 and s390x. It therefore looks like a 64-bit big endian issue. It could be for example a pointer to an int value casted to a pointer to a long value or vice-versa. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Upgrading the minimum required s390x CPU to z10?
Hi all, The Debian s390x port currently defaults to the z900 instruction set. It appears that an increasing but small number of packages use z10 assembly code, and need to be patched to be built on Debian. I therefore wonder if it is time to switch the default ISA to z10 (which is the maximum we can do with out current build daemons and porterbox). Of course that will be done in testing/unstable, so people using older machines can still use jessie. Any opinion on that? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#669944: fixed in mozjs 1.8.5-1.0.0+dfsg-4.4
On 2015-11-09 00:22, Aurelien Jarno wrote: > On 2015-11-08 19:22, John Paul Adrian Glaubitz wrote: > > Source: mozjs > > Source-Version: 1.8.5-1.0.0+dfsg-4.4 > > > > We believe that the bug you reported is fixed in the latest version of > > mozjs, which is due to be installed in the Debian FTP archive. > > > > A summary of the changes between this version and the previous one is > > attached. > > > > Thank you for reporting the bug, which will now be closed. If you > > have further comments please address them to 669...@bugs.debian.org, > > and the maintainer will reopen the bug report if appropriate. > > > > Debian distribution maintenance software > > pp. > > John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> (supplier of > > updated mozjs package) > > > > (This message was generated automatically at their request; if you > > believe that there is a problem with it please contact the archive > > administrators by mailing ftpmas...@ftp-master.debian.org) > > > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Format: 1.8 > > Date: Sun, 08 Nov 2015 19:30:45 +0100 > > Source: mozjs > > Binary: libmozjs185-1.0 libmozjs185-dev > > Architecture: source amd64 > > Version: 1.8.5-1.0.0+dfsg-4.4 > > Distribution: unstable > > Urgency: medium > > Maintainer: Chris Coulson <chrisccoul...@ubuntu.com> > > Changed-By: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> > > Description: > > libmozjs185-1.0 - Spidermonkey javascript engine > > libmozjs185-dev - Spidermonkey javascript library - development headers > > Closes: 669944 > > Changes: > > mozjs (1.8.5-1.0.0+dfsg-4.4) unstable; urgency=medium > > . > >* Non-maintainer upload. > >* Add disable-nanojit-on-sparc64.patch to disable nanojit on sparc64 > > where it is currently unsupported and needs to be ported first. > >* Update debian/libmozjs185-1.0.symbols for alpha, powerpcspe, ppc64 > > sh4 and sparc64 (Closes: #669944). > > This NMU changed the symbols file for s390x, so it now fails to build > there [1] now. s390x has been changed into s390: > - (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64el > !s390x)_ZN2js10TypedArray14prop_getBufferEP9JSContextP8JSObjectiPNS_5ValueE@Base > 1.8.5-1.0.0+dfsg > lueE@Base 1.8.5-1.0.0+dfsg > + (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 > !ppc64el !s390 > !sparc64)_ZN2js10TypedArray14prop_getBufferEP9JSContextP8JSObjectiPNS_5ValueE@Base > 1.8.5-1.0.0+dfsg > > Could you please do another NMU to fix that? Thanks in advance. Oh, I have just seen you already fixed that. Thanks and sorry for the noise. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#669944: fixed in mozjs 1.8.5-1.0.0+dfsg-4.4
On 2015-11-08 19:22, John Paul Adrian Glaubitz wrote: > Source: mozjs > Source-Version: 1.8.5-1.0.0+dfsg-4.4 > > We believe that the bug you reported is fixed in the latest version of > mozjs, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 669...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> (supplier of updated > mozjs package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sun, 08 Nov 2015 19:30:45 +0100 > Source: mozjs > Binary: libmozjs185-1.0 libmozjs185-dev > Architecture: source amd64 > Version: 1.8.5-1.0.0+dfsg-4.4 > Distribution: unstable > Urgency: medium > Maintainer: Chris Coulson <chrisccoul...@ubuntu.com> > Changed-By: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> > Description: > libmozjs185-1.0 - Spidermonkey javascript engine > libmozjs185-dev - Spidermonkey javascript library - development headers > Closes: 669944 > Changes: > mozjs (1.8.5-1.0.0+dfsg-4.4) unstable; urgency=medium > . >* Non-maintainer upload. >* Add disable-nanojit-on-sparc64.patch to disable nanojit on sparc64 > where it is currently unsupported and needs to be ported first. >* Update debian/libmozjs185-1.0.symbols for alpha, powerpcspe, ppc64 > sh4 and sparc64 (Closes: #669944). This NMU changed the symbols file for s390x, so it now fails to build there [1] now. s390x has been changed into s390: - (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64el !s390x)_ZN2js10TypedArray14prop_getBufferEP9JSContextP8JSObjectiPNS_5ValueE@Base 1.8.5-1.0.0+dfsg lueE@Base 1.8.5-1.0.0+dfsg + (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 !ppc64el !s390 !sparc64)_ZN2js10TypedArray14prop_getBufferEP9JSContextP8JSObjectiPNS_5ValueE@Base 1.8.5-1.0.0+dfsg Could you please do another NMU to fix that? Thanks in advance. Aurelien [1] https://buildd.debian.org/status/fetch.php?pkg=mozjs=s390x=1.8.5-1.0.0%2Bdfsg-4.4=1447011515 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: sh4 missing on packages.debian.org
On Fri, Sep 05, 2014 at 07:04:50PM +0200, John Paul Adrian Glaubitz wrote: Hi Aurelien! Hi, I just noticed that there seems to be something wrong with packages.debian.org regarding sh4. Many packages are not listed there as available even though they are built and installed. For example, src:glibc, has been fully built on sh4, yet: https://packages.debian.org/sid/libc6 It's not there. It's also not installable anymore: yamato:~# apt-cache policy libc6 libc6: Installed: 2.19-9 Candidate: 2.19-9 Version table: *** 2.19-9 0 100 /var/lib/dpkg/status yamato:~# yamato:~# cat /etc/apt/sources.list deb http://ftp.debian-ports.org/debian/ unstable main deb http://ftp.debian-ports.org/debian/ unreleased main yamato:~# Do you know what could be wrong? This morning it seems the Packages list is fine, and that the packages correctly appear on package.d.o. I guess there was a small glitch in the previous install run. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- 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/20140906065849.gd22...@hall.aurel32.net
Re: Bug#759870: gcc-4.9: Compiles zsh endlessly on s390x (maybe sigjmp_buf related)
On Sun, Aug 31, 2014 at 12:39:12AM +0200, Axel Beckert wrote: Control: retitle -1 gcc-4.9: Compiles zsh endlessly with -fstack-protector-strong on s390x Hi, Matthias Klose wrote: if it's just zsh, then it's not serious. I doubt that it's only zsh. Apparently there are some stability issues with some s390 machines, Looks rather like a regression than stability issues to me. It fails _always_ with gcc-4.9 and default buildflags on s390x. But works fine with gcc-4.8: $ debuild -eCC=gcc-4.8 -eDEB_BUILD_MAINT_OPTIONS=hardening=-stackprotectorstrong -uc -us -B (Had to remove stackprotectorstrong as it doesn't seem to be available with gcc-4.8.) CC'ing the s390 porters. JFTR: I already X-Debbugs-Cc'ed them. I was able to to reproduce it in a sid chroot of zelenka, too. gcc-4.9 hangs at this position: […].0.5-dev-2/obj/Src → gcc -c -I. -I../Src -I../../Src -I../../Src/Zle -I../../Src -D_FORTIFY_SOURCE=2 -Q -DHAVE_CONFIG_H -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -o builtin.o ../../Src/builtin.c gnu_dev_major gnu_dev_minor gnu_dev_makedev read pread pread64 readlink readlinkat getcwd getwd confstr getgroups ttyname_r getlogin_r gethostname getdomainname getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked putc_unlocked putchar_unlocked getline feof_unlocked ferror_unlocked sprintf vsprintf snprintf vsnprintf fprintf printf vprintf vfprintf dprintf vdprintf asprintf __asprintf obstack_printf vasprintf obstack_vprintf fgets fread fgets_unlocked fread_unlocked tolower toupper stat lstat fstat fstatat mknod mknodat stat64 lstat64 fstat64 fstatat64 __sigismember __sigaddset __sigdelset atoi atol atoll bsearch atof realpath ptsname_r wctomb mbstowcs wcstombs __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c memcpy memmove mempcpy memset bcopy bzero strcpy stpcpy strncpy stpncpy strcat strncat open open64 openat openat64 btowc wctob mbrlen wmemcpy wmemmove wmempcpy wmemset wcscpy wcpcpy wcsncpy wcpncpy wcscat wcsncat swprintf vswprintf wprintf fwprintf vwprintf vfwprintf fgetws fgetws_unlocked wcrtomb mbsrtowcs wcsrtombs mbsnrtowcs wcsnrtombs createbuiltintable printbuiltinnode freebuiltinnode init_builtins new_optarg execbuiltin bin_enable bin_set bin_pwd bin_dirs set_pwd_env bin_cd cd_get_dest cd_do_chdir cd_able_vars cd_try_chdir cd_new_pwd printdirstack fixdir printqt printif bin_fc fcgetcomm fcsubs fclist fcedit getasg typeset_setbase typeset_setwidth typeset_single bin_typeset eval_autoload listusermathfunc bin_functions mkautofn bin_unset bin_whence bin_hash bin_unhash bin_alias bin_true bin_false bin_print bin_shift bin_getopts bin_break checkjobs zexit bin_dot eval bin_emulate bin_eval bin_read zread testlex bin_test bin_times bin_trap bin_ttyctl bin_let bin_umask bin_notavail Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program profile_estimate devirt cp inline pure-const static-varAssembling functions: bin_true bin_false testlex bin_enable bin_set listusermathfunc bin_dirs bin_unhash fclist bin_unset bin_whence bin_shift bin_let bin_getopts bin_dot eval bin_emulate bin_eval bin_times bin_trap bin_umask printbuiltinnode bin_ttyctl freebuiltinnode bin_pwd typeset_setwidth.isra.4 typeset_setbase.isra.5 fcgetcomm bin_fc typeset_single.isra.7 getasg bin_hash bin_alias bin_print zread bin_read bin_test createbuiltintable init_builtins execbuiltin set_pwd_env cd_able_vars fixdir As waldi noticed, it suffices to replace -fstack-protector-strong by -fstack-protector (which was necessary for compiling with gcc-4.8 anyways) and it does no more go into the endless loop: […].0.5-dev-2/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 -Wformat -Werror=format-security -Wall -g -o builtin.o ../../Src/builtin.c HTH I'll likely use DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotectorstrong to get zsh building on s390x again for now, but I still think endless loops like this one are a bug in the compiler. With this workaround, I'm also ok with the lowered severity as there is a workaround which likely also works for other affected packages. Please note that the problem is fixed in upstream trunk as well as in the gcc-snapshot debian package. I'll try to identify the commit fixing it. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- 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/20140903161335.gg15...@hall.aurel32.net
Re: Handling s390 libc ABI change in Debian
On Tue, Jul 15, 2014 at 09:21:30AM +0200, Philipp Kern wrote: On Tue, Jul 15, 2014 at 07:18:39AM +0200, Aurelien Jarno wrote: I can follow up with a list affected packages, but we are slowly discovering them one by one, so it might takes time. So far we have: * Mixing modules/libraries built with pre-2.19 and 2.19 libc - perl - libpng * Using libc 2.19 without rebuilding anything: - gauche - mono I think it's pretty important for perl to keep working as much as is required for the system to upgrade itself. I'd be a bit less concerned (aside already broken binary compatibility) if the base system keeps working during the upgrade. It might not be easy to ensure the upgrade process works correctly. For example in mono case, as soon as a new libc is installed, mono stops working, and installing/upgrading a mono package would fail as mono is called in the postinst (this is bug#751171). We have to avoid this by using strict dependencies to make sure the packages are installed in the right order, but we can't guarantee to detect and handle all cases. That means some upgrades might break. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- 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/20140715075003.gd32...@hall.aurel32.net
Re: Handling s390 libc ABI change in Debian
On Tue, Jul 15, 2014 at 03:49:04AM -0400, Carlos O'Donell wrote: On Tue, Jul 15, 2014 at 1:18 AM, Aurelien Jarno aure...@debian.org wrote: On Mon, Jul 14, 2014 at 11:14:42PM -0400, Carlos O'Donell wrote: On Mon, Jul 14, 2014 at 4:36 PM, Aurelien Jarno aure...@debian.org wrote: glibc 2.19 has changed the libc ABI on s390, more specifically the setjmp/longjmp functions [1] [2]. Symbol versioning is used to handle some cases, but it doesn't work when a jmp_buf variable is embedded into a structure, as it changes the size of the structure. The result is that mixing programs or libraries built with 2.18 with ones built with 2.19 do not work anymore, usually they end up with a segmentation fault. Some persons from this list have experienced that with perl. That is not true. This is an over generalization of the problem. You can use libraries built with 2.18 and 2.19 and they work just fine. I agree I probably a bit over exaggerated here, but the problem is real, breakages do happen, and some persons on this mailing list have already experienced them. The extent of the problem in correct language is listed here: https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes This seems to minimize the problem, listing only perl. In practice we have seen much more breakages, part of them being due to the change of the __pthread_unwind_buf_t struct. That is a change that nobody reported. You're the first to mention it and that does make it more serious. We have discussed this upstream and I agree that we need more versioning of the interfaces there to support the change fully. We first thought it was limited to a few packages (even if all perl is already more than that), but as time goes more and more issues are found. libpng and gauche are also affected, the issue with mono is also likely due to this ABI change. That is new information, and it is important for distributions to relay this information back upstream where the decision for a SO bump can be made. I can follow up with a list affected packages, but we are slowly discovering them one by one, so it might takes time. So far we have: * Mixing modules/libraries built with pre-2.19 and 2.19 libc - perl - libpng You can never support a mixed-ABI environment with versioning. You must update all of those packages at once. The best we could do is warn the user of the incompatibility at runtime and refuse to load the module via dlopen, or refuse to start the application at startup. For perl we handled that using dependencies in the package manager, and we can probably add some more checks for user modules. That said that do not scale if we discover more and more affected packages. This is my fear so far. * Using libc 2.19 without rebuilding anything: - gauche - mono This we believe to be pthread issues. Yes, this is the pthread issue. It's a huge work for Debian, maybe not for other distribution, as it basically means we have to rebootstrap everything. This includes manual bootstrapping of self-dependent languages (haskell, gnat, ...) and manual handling of some dependencies loop. In addition it's something which hasn't been done since the libc5 transition, so we might discover some unexpected issues. Why do you have to do that? Is it just like for rpm where the packaging system encodes the SONAME as a dependency? We would also need a manual bootstrap in Fedora because of this issue. I assumed that both libc can't be used simultaneously, so that's basically like bootstrapping a new architecture, except the manual bootstrapping of self-dependent languages can be done more easily. Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- 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/20140715083054.gk1...@hall.aurel32.net
Handling s390 libc ABI change in Debian
Hi all, glibc 2.19 has changed the libc ABI on s390, more specifically the setjmp/longjmp functions [1] [2]. Symbol versioning is used to handle some cases, but it doesn't work when a jmp_buf variable is embedded into a structure, as it changes the size of the structure. The result is that mixing programs or libraries built with 2.18 with ones built with 2.19 do not work anymore, usually they end up with a segmentation fault. Some persons from this list have experienced that with perl. We first thought it was limited to a few packages (even if all perl is already more than that), but as time goes more and more issues are found. libpng and gauche are also affected, the issue with mono is also likely due to this ABI change. According to upstream [3], the problem is that Debian doesn't do a mass rebuild, which is the strategy chosen by Red Hat to handle^Wworkaround this issue. This means some programs might segfault during the upgrade, or on partially upgraded systems. Now we have to chose a strategy for Debian. I see multiple options: 1) Ignore the issue and just rebuild (binNMU) the packages that seems affected when we discover them. This means partial upgrades will likely be broken, and that we might discover some broken packages only after the jessie release. 2) Rebuild (binNMU) all packages. This means partial upgrades will likely be broken. 3) Bump the soname of affected packages and rebuild their reverse dependencies. It is the solution that is currently being implemented for perl. It clearly won't scale if more broken packages (and even for libpng) are discovered as it requires a source upload and a transition handled by the release team. It also means breaking the ABI compatibility with other distributions. 4) Bump the libc soname to libc.so.6.1 and do a libc transition. This is probably what upstream should have done instead of breaking the ABI. This is a huge work though, and this also means breaking the ABI compatibility with other distributions. 5) Revert the ABI change. This is likely just postponing the problem as the change is required to support future hardware. This also means breaking the ABI compatibility with other distributions. 6) simply drop the s390x port and tell users to either use an other distribution or use Debian on other hardware. Any opinion? Any other ideas how to handle that? Regards, Aurelien [1] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ee4ec1d7f9bdbdfc87117133478cfb2f6653e65c [2] https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes [3] https://sourceware.org/ml/libc-alpha/2014-07/msg00316.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Fwd: Bug#724469: FTBFS on all big-endian architectures
Hi,
On Thu, Jan 16, 2014 at 06:44:28PM +0100, intrigeri wrote:
Hi,
is it imaginable that a s390x porter gives this issue a try?
Upstream wrote back in October [1] I'll try to get to this soon, but
I'd be more than happy to accept patches, too. Since then, a patch
was proposed that apparently fixes the issue on 32-bit big endian
architectures (attached both to the Debian and upstream bug reports).
This patch apparently needs some more work for 64-bit big endian
architectures, so I thought you might be interested :)
[1] https://rt.cpan.org/Ticket/Display.html?id=89552
Thanks a lot for working on that. The patch improves the things a bit on
s390x, but following the same principle with 32-bit types (see attached
patch), fixes even more issues. The testsuite looks like this
afterwards:
| t/arrays.t (Wstat: 9 Tests: 2 Failed: 1)
| Failed test: 2
| Non-zero wait status: 9
| Parse errors: Bad plan. You planned 29 tests but ran 2.
| t/callbacks.t (Wstat: 1536 Tests: 25 Failed: 6)
| Failed tests: 3, 6, 9, 14, 19, 25
| Non-zero exit status: 6
| t/enums.t (Wstat: 11 Tests: 1 Failed: 0)
| Non-zero wait status: 11
| Parse errors: Bad plan. You planned 4 tests but ran 1.
| t/structs.t (Wstat: 65280 Tests: 4 Failed: 0)
| Non-zero exit status: 255
| Parse errors: Bad plan. You planned 6 tests but ran 4.
While it doesn't fix all the issues the patch looks correct and IMHO can
already be merged, as the other issue will need changes in other parts
of the code.
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--- libglib-object-introspection-perl-0.019.orig/gperl-i11n-invoke-c.c
+++ libglib-object-introspection-perl-0.019/gperl-i11n-invoke-c.c
@@ -180,7 +180,44 @@ invoke_c_code (GICallableInfo *info,
ccroak (Could not prepare a call interface);
}
- ffi_call (cif, func_pointer, return_value, iinfo.args);
+ if(iinfo.return_type_ffi==ffi_type_sint8)
+ {
+ ffi_sarg result;
+ ffi_call (cif, func_pointer, result, iinfo.args);
+ return_value.v_int8=result;
+ }
+ else if(iinfo.return_type_ffi==ffi_type_uint8)
+ {
+ ffi_arg result;
+ ffi_call (cif, func_pointer, result, iinfo.args);
+ return_value.v_uint8=result;
+ }
+ else if(iinfo.return_type_ffi==ffi_type_sint16)
+ {
+ ffi_sarg result;
+ ffi_call (cif, func_pointer, result, iinfo.args);
+ return_value.v_int16=result;
+ }
+ else if(iinfo.return_type_ffi==ffi_type_uint16)
+ {
+ ffi_arg result;
+ ffi_call (cif, func_pointer, result, iinfo.args);
+ return_value.v_uint16=result;
+ }
+ else if(iinfo.return_type_ffi==ffi_type_sint32)
+ {
+ ffi_sarg result;
+ ffi_call (cif, func_pointer, result, iinfo.args);
+ return_value.v_int32=result;
+ }
+ else if(iinfo.return_type_ffi==ffi_type_uint32)
+ {
+ ffi_arg result;
+ ffi_call (cif, func_pointer, result, iinfo.args);
+ return_value.v_uint32=result;
+ }
+else
+ ffi_call (cif, func_pointer, return_value, iinfo.args);
/* free call-scoped data */
_invoke_free_after_call_handlers (iinfo);
Re: Bug#732282: stop building java for sparc, sparc64, s390, kfreebsd-any
On Mon, Dec 16, 2013 at 11:34:18AM +0100, Matthias Klose wrote: 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. There is no point in trying to update an s390 specific patch while this architecture doesn't exist anymore in jessie and sid, replaced by s390x. This patch should just be removed and s390 removed from the architectures handled in java-common. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20131216170205.gw4...@hall.aurel32.net
Re: debian-ports.org getting relatively unstable (hppa)
Hi, On Sun, Dec 15, 2013 at 11:54:43AM +0100, Helge Deller wrote: On 12/15/2013 06:32 AM, Dave Land wrote: Not sure what's up at debian-ports.org, but I've been trying to debootstrap 2 different HPPA machines for the last couple days and have been getting a variety of errors (size mismatches, files not found when they were there 20 minutes before, etc. etc.) Somebody may want to look into this before it gets out of hand. Thanks! :) I maybe should add some more background here, and maybe someone here on the list might have an idea on how to proceed. Background is, that Dave and myself have binmnu-uploaded the necessary packages for hppa so that debootstrap worked. Then we proceeded with the necessary packages for sbuild and schroot, so that I now have a buildd installed which should be able to start building packages. I haven't turned it on yet though for the reasons which I explain in a few seconds... In the meantime we have of course uploaded a few more packages which now currently break debootstrap. This is fixable manually, but I instead of uploading packages manually now, I would prefer to get the buildd going instead... So, Dave Land, please wait a little bit... Now to the reasons why I didn't turned on the buildd yet: We noticed, that when we manually binmnu-upload packages, which are already in the *same version* on debian-ports, then debian-ports ACCEPT those packages, but if we then try to apt-get-update those later on, this leads to a size mismatch error. I do have the feeling, that this is a problem on debian-ports. I noticed for example that reprepro usually doesn't accept packages of the same version which doesn't seem to be the case on debian-ports. This is indeed the case, apt-fptarchive keep the checksums corresponding to first package. That said it hasn't really caused any problem so far. So, I'm anxious, that if I start the buildd, it will happily build and upload packages which we already uploaded to debian-ports. If this happens we will get more size-mismatch errors. Well if you leave the build daemons handling the uploads, they will not build and upload the same package again, and the problem won't happen. A trivial example: On machine buildd.debian-ports.org I run: deller@leda:~$ wb info hello . hppa * hello/hppa | hello: | Package : hello | Version : 2.8-4 | State : Needs-Build | Section : devel | Priority: source | Previous-State : | State-Change: 2013-02-18 00:03:36.782007 | CalculatedPri : 52 | component : main | Distribution: sid | Notes : out-of-date | State-Days : 300 | State-Time : 25958430 So, the package hello would need a rebuild according to the wanna-build database, and that would wb probably tell my buildd who then would start building/uploading it. But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can see, that the hello-package is already uploaded at version 2.8-4 So, if my buildd now uploads the newly created hello package, I'm sure we will run again into the size-mismatch problem. The wanna-build database is not up to date on hppa. I have disabled it to save some very precious cpu cycles given there are no buildds on hppa yet. Now, Aurelien mentioned last week to me, that this size-mismatch error might be because of the apt-ftparchive cache might have been corrupted for hppa. I'm not 100% sure about that. Ok I wasn't aware the same package have been uploaded multiple time, so the corruption comes clearly from there. My question here on the list would be, if you (other arch-porters) do have an idea on how I should proceed. I would say stop doing manual upload and start the build daemons. Best solution would probably be, if the wanna-build database rescans what's in the archive already. Is this possible? Yes, I can re-enable the hppa wanna-build database if it is actually useful. Or, should I just start the buildd and see what's happening? If we then get the size-mismatch errors there is lot of manual work to fix it (unless resetting the apt-ftparchive on debian-ports would solve this). We can rebuild the apt-ftparchive database at some point. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20131215200337.ga2...@hall.aurel32.net
Re: Switch default GCC to 4.8 on s390x
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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Switch default GCC to 4.8 on s390x
On Sat, Nov 23, 2013 at 03:39:52PM +0100, Matthias Klose wrote: 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. s390 is dead and is still only available for squeeze and wheezy, so it doesn't matter for jessie and sid. x86 should be waived. we do have active contributors for kfreebsd, the hurd, m68k, alpha, powerpcspe, mips64, hppa at least. If they have active contributors, I think they should also be noted there, otherwise this file is more than useless. Or we should remove mips and s390x entries. arm* is missing here, but it is usually taken care of by myself. Well then why you don't add yourself there? Note that they are a few worrying bugs on armel like #628063, #697521, #727621 that have not been forwarded upstream yet. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20131123145825.gc20...@hall.aurel32.net
Re: Switch default GCC to 4.8 on s390x
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. Note that I have just done the change in the SVN, it would be nice if you can upload gcc-defaults. Best regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Switch default GCC to 4.8 on s390x
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? Best regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: status of s390 toolchain maintenance
On Mon, Jul 01, 2013 at 09:35:29PM +0200, Bastian Blank wrote: On Mon, Jul 01, 2013 at 11:42:44AM +0200, Matthias Klose wrote: Is this change coordinated with Bastian? I have not been contacted by Aurelian. I've not seen anything on this matter from him. I did discuss that with Philipp Kern, but obviously I forgot to add you in the loop, sorry about that. I have therefore reverted the changes in the SVN. That said I think s390/s390x should not lag too long behind other architectures, as it usually create subtle bugs, and it's better to discover (and fix) toolchain issues early in a release cycle than late. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20130701213849.ga29...@hall.aurel32.net
Re: Current and upcoming toolchain changes for jessie
On Fri, Jun 14, 2013 at 01:12:30PM +0200, Matthias Klose wrote:
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.
I did report a few mips/mipsel issue to upstream binutils and gcc, and
they have all been solved. I am not aware of any reported mips/mipsel
binutils or gcc-4.{6,7,8} problem reported in the debian BTS, except
#710683, which is recent and I haven't investigated it yet (but is likely
an OOM issue on the buildd).
Could you please provide me a few pointers?
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.
hppa porters have ignored my emails during a few years, and then started
to write me during a few more years using an email address that went
to /dev/null, so they never got my answers, and thus never answered me...
This is true that they have recently contacted me through another email
address, but I haven't found time to work on that. Just stay tuned.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
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/20130618220536.ga22...@hall.aurel32.net
Re: status of s390 for jessie and later
Hi, On Wed, May 08, 2013 at 11:40:44AM +0200, Ansgar Burchardt wrote: Hi, the architecture status page for Wheezy[1] mentioned that it would be the last release if s390x comes in. As Wheezy was release with the s390x support, should we now look at removing s390 from both jessie and sid? That was indeed the plan, and I think the s390x release of Wheezy actually reached the goal of being able to replace s390. Unless someone comes with very good arguments in the next days, I think it's the way to go. That said it would be good to get the feedback from other people involved in the s390 port first though. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Bug#666746: FTBFS(s390x): BigPtrArrayUnittest::test_for_some1: assertion failed
On Sun, Apr 01, 2012 at 06:07:22PM +0200, Rene Engelhard wrote: Hi, On Sun, Apr 01, 2012 at 04:16:03PM +0200, Philipp Kern wrote: your package failed to build from source on s390x. A chroot (sid_s390x) does Yeah, known. (3.4.x would have just worked because the tests there wouldn't be run at all - but thankfully that one was stuck in BD-Uninstallable.) exist on the s390 porterbox zelenka. At a casual uneducated glance it looks like it got pretty far into the build. jup. just the unit tests fail. (3.5.1-1 didn't fail in experimental ad test failure wasn't fatal there accidentially). This really looks like a bug in the testsuite, Fedora has written a patch [1]. I am currently testing it. [1] http://permalink.gmane.org/gmane.linux.redhat.fedora.extras.cvs/764768 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20120604110009.ga12...@volta.aurel32.net
Debian s390x port
Hi all, For those not reading planet and blogs, I have started an s390x port, that is with a 64-bit userland. More details can be found on: http://blog.aurel32.net/?p=59 Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20110809215335.gd28...@hall.aurel32.net
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426185104.gb29...@hall.aurel32.net
Re: Sparc release requalification
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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Wed, May 07, 2008 at 11:29:49AM +0200, Bastian Blank wrote: Package: libc6 Version: 2.7-10 Severity: important On Wed, May 07, 2008 at 09:34:12AM +0200, Matthias Klose wrote: the build failure on s390 is unexpected; is it possible to extract a test case? | java: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. So another package failed about that (after mono and libto$bla). It looks like a race condition somewhere in the libpthread. Looking quickly at the code the problem is that LLL_MUTEX_LOCK (mutex) fails to acquire the mutex. It can be a bug in atomic.h or a bug in the futexes implementation of the kernel. It would be nice to have an strace of the problem to see the futex syscall before this assertion. Also a small testcase of the problem would be really helpful to debug it. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 in experimental / GCC for etch
Hi! Matthias Klose a écrit : The GCC (GNU compiler collection) 4.1 release candidate 1 can be found in experimental. Porters, please make sure that the package is built and uploaded (if it's not built by the experimental buildd). Please check that the symbols exported in the 4.1 libraries are a superset of those exported in the 4.0 libraries (these are libgcc1 (except m68k and hppa), libstdc++6, libffi4, libobjc1, libmudflap0). The proposed GCC plan for etch consists of: - uploading GCC 4.0.3 to unstable (this release is expected shortly after the GCC 4.1.0 release), let 4.0.3 migrate to testing. The GCC website seems to be down currently, could you please tell us when the release are expected? - uploading GCC 4.1 to unstable for those architectures which do not have ABI problems (these should be all, but should be validated). Nice! - Once the 4.1 packages are migrated to testing, make 4.1 the default compiler for i386, amd64, powerpc. These are the architectures, which are considred primary (linux) architectures by GCC upstream. For the other Debian architectures, the GCC port maintainers and the Debian port maintainers should make the call, if and when the default GCC is changed. I think you could also make 4.1 the default one for kfreebsd-i386. They are very few differences with the linux version, and the testsuite shows good results. - Make gij-4.1/gcj-4.1 the default for all architectures. - Stop building compiler packages from the GCC 3.3 source; the only packages built will be libstdc++5 (and libgcc1 on hppa/m68k). AFAIK the 2.4 kernels in Debian are built with gcc-3.3. What are the plans wrt to them? - Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 and g++-3.4 (it looks like we can go without g++-3.4 for the etch release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be found anymore in 4.x releases. Currently three architectures are still using gcc 3.4 to build the glibc, namely m68k, hppa and powerpc. For powerpc, it seems we can make the switch to at least gcc 4.0. There is currently a problem of locales, but not sure it is related to gcc-4.0. For hppa, the glibc builds well with gcc 4.0, but create problem with python/perl. It still has to be investigated. For m68k, the glibc does not build, gcc 4.0 segfault on system.c. It looks like gcc 4.1 fixes the problem, but the resulting glibc has not been tested. I think compilers are critical for the glibc, so we will have to coordinate the changes. Aurélien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
