Re: Bug#1068473: icinga2: crashes on startup on ppc64el
Hi, On 2024-04-06 14:17, Sebastiaan Couwenberg wrote: > On 4/6/24 1:29 PM, Aurelien Jarno wrote: > > On 2024-04-06 08:01, Sebastiaan Couwenberg wrote: > > > On 4/5/24 9:51 PM, Aurelien Jarno wrote: > > > > For Bookworm given we can not fix the compiler easily, I propose to just > > > > build icinga2 with -O1 on ppc64el. If you are fine with that option, I > > > > can take care of proposing a patch and submitting it to the stable > > > > release team. > > > > > > A patch for this is very welcome. How do you propose to implement that? > > > Something like this maybe? > > > > > > --- a/debian/rules > > > +++ b/debian/rules > > > @@ -9,6 +9,11 @@ include /usr/share/dpkg/architecture.mk > > > > > >export CTEST_OUTPUT_ON_FAILURE=1 > > > > > > +ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el)) > > > + export DEB_CXXFLAGS_STRIP = -O2 > > > + export DEB_CXXFLAGS_MAINT_APPEND = -O1 > > > +endif > > > + > > >ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) > > > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > > > -Wl,--as-needed > > >endif > > > > Yes, something like that works. I even tested without the > > DEB_CXXFLAGS_STRIP, gcc is smart enough to just take the last flag, so > > -O1. > > > > Also it seems that your diff applies to the Trixie/Sid version, while it > > should be applied to Bookworm instead. > > Correct, I did not actually prepare a bookworm branch as you offered to take > care of that. > > Since it's not that much work, I did that now: > > > https://salsa.debian.org/nagios-team/icinga2/-/commits/bookworm?ref_type=heads > > If you can confirm that those changes fix the issue, I can also fix the > bookworm-pu bugreport, or you can do that if you want. Thanks a lot for preparing that. I have just tested it and I confirm it fixes the problem, icinga2 is working nicely with this change. As the maintainer, I would be happy if you send the bookworm-pu bugreport, but in case you lack time or for other reasons, do not hesitate to ask it, and I will do it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: Bug#1068473: icinga2: crashes on startup on ppc64el
On 2024-04-06 08:01, Sebastiaan Couwenberg wrote: > On 4/5/24 9:51 PM, Aurelien Jarno wrote: > > For Bookworm given we can not fix the compiler easily, I propose to just > > build icinga2 with -O1 on ppc64el. If you are fine with that option, I > > can take care of proposing a patch and submitting it to the stable > > release team. > > A patch for this is very welcome. How do you propose to implement that? > Something like this maybe? > > --- a/debian/rules > +++ b/debian/rules > @@ -9,6 +9,11 @@ include /usr/share/dpkg/architecture.mk > > export CTEST_OUTPUT_ON_FAILURE=1 > > +ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el)) > + export DEB_CXXFLAGS_STRIP = -O2 > + export DEB_CXXFLAGS_MAINT_APPEND = -O1 > +endif > + > ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > -Wl,--as-needed > endif Yes, something like that works. I even tested without the DEB_CXXFLAGS_STRIP, gcc is smart enough to just take the last flag, so -O1. Also it seems that your diff applies to the Trixie/Sid version, while it should be applied to Bookworm instead. > Note that we ignore test failures on ppc64el which might have caught this > issue. I don't think so. Tests are not ignored for Bookworm and haven't caught the issue. OTOH they are ignored for Trixie/Sid, while this version works fine. > Upstream doesn't care about those architectures, so we're on our own > to resolve issues on architectures other than amd64/i386/arm64. Pretty much > all packages I maintain don't have actual users on non-amd64 architectures, > so I don't consider it worth the effort to ask the porters for help, they > should spend their time on packages that are actually used. With DSA's use > of icinga2 on porterboxes it's the exception to the norm. Yes, I agree that the upstream situation is not nice. I personally try to get things fixed [1], but it went nowhere. And the issue was not really architecture specific, just that icinga2 testsuite doesn't support page sizes bigger than 4K... Regards Aurelien [1] https://github.com/Icinga/icinga2/issues/9954#issuecomment-1875209616 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: RM: icinga2 [armel mips64el ppc64el riscv64] -- ROM; FTBFS
Hi, On 2023-12-22 15:43, Bas Couwenberg wrote: > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: icin...@packages.debian.org > Control: affects -1 + src:icinga2 > > Please remove icinga2 from armel, mips64el, ppc64el, riscv64 where it FTBFS > to unblock testing migration. What is the reasoning behind the removal, especially for riscv64 which built successfully? Have you asked the porters for help before asking for the removal? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
On 2023-08-28 21:56, Aurelien Jarno wrote: > Hi Niko, > > On 2023-08-27 14:43, Niko Tyni wrote: > > (full quote for the benefit of the Aurelien and other glibc maintainers) > > > > On Sat, Aug 26, 2023 at 09:07:38PM +0300, Niko Tyni wrote: > > > Package: perl > > > Version: 5.36.0-8 > > > Severity: serious > > > X-Debbugs-Cc: debian-powerpc@lists.debian.org > > > Control: affects -1 libfile-fcntllock-perl > > > > > > Hi, > > > > > > debugging an unexpected autopkgtest failure of > > > libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found > > > it's because the old perl binary (5.36.0-7) was built with the fcntl(2) > > > constant F_GETLK == 12, but the new one with F_GETLK == 5 [2]. > > > > > > There are no source or build system changes in perl that would have caused > > > this change. The failure is currently blocking perl testing migration, > > > so filing at 'serious'. > > > > > > Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye > > > this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later > > > F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact > > > change that caused this yet. > > > > > > As can be expected from the above, building libfile-fcntllock-perl on > > > bookworm against perl_5.36.0-7 makes it fail its test suite in a similar > > > way. And rebuilding it on sid against perl_5.36.0-8 makes it pass. > > > > > > On amd64 the constants have stayed equal (== 5) from bullseye to sid, > > > and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el? > > > > > > Copying the powerpc porters list. Could you please look into this? > > > > > > [1] > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz > > > [2] perl -MPOSIX -E 'say F_GETLK' > > > [3] printf '#include \nF_GETLK\nF_GETLK64\n' | cpp > > > -D_FILE_OFFSET_BITS=64 | tail -2 > > Thanks for the details and the investigation. > > > I think the relevant change here is this in libc6-dev_2.36-9+deb12u1 for > > bookworm: > > > > --- libc6-dev_2.36-9/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > > 2023-04-10 09:35:16.0 +0100 > > +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > > 2023-07-13 19:07:47.0 +0100 > > @@ -33,6 +33,12 @@ > > # define __O_LARGEFILE 020 > > #endif > > > > +#if __WORDSIZE == 64 > > +# define F_GETLK 5 > > +# define F_SETLK 6 > > +# define F_SETLKW 7 > > +#endif > > + > > Indeed you are correct that the issue has been introduced by this patch. > It fixes the case *without* -D_FILE_OFFSET_BITS=64, but OTOH breaks the > case *with* it. > > > and a similar one in 2.37-2 for trixie/sid. > > > > The applicable changelog entry is presumably > > > >[ Aurelien Jarno ] > >* debian/patches/git-updates.diff: update from upstream stable branch: > > [...] > > - Not affecting bookworm release architectures: > >- Fix LFS POSIX lock constants for powerpc64. > > > > Aurelien, it seems that there's an oversight as ppc64el is a release > > architecture? > > Yes, sorry about that. When reading the changelog and the diff, I > thought it was only for powerpc64, as ppc64el has a different ABI, but I > was wrong. > > > I can see that this changed for the better, but what should I do with the > > above > > breakage? Rebuild perl and libfcntl-fcntllock-perl and declare some Breaks? > > Do we want to do that for stable too? > > I think it's an ABI breakage that should be fixed, but just reverting > the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check > with upstream and try to get the issue fixed in both testing/sid and > stable. I'll keep you updated. In the meantime feel free to reassign the > bug to the glibc. I have opened a bug upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=30804 And submitted a possible patch: https://sourceware.org/pipermail/libc-alpha/2023-August/151199.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
Hi Niko, On 2023-08-27 14:43, Niko Tyni wrote: > (full quote for the benefit of the Aurelien and other glibc maintainers) > > On Sat, Aug 26, 2023 at 09:07:38PM +0300, Niko Tyni wrote: > > Package: perl > > Version: 5.36.0-8 > > Severity: serious > > X-Debbugs-Cc: debian-powerpc@lists.debian.org > > Control: affects -1 libfile-fcntllock-perl > > > > Hi, > > > > debugging an unexpected autopkgtest failure of > > libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found > > it's because the old perl binary (5.36.0-7) was built with the fcntl(2) > > constant F_GETLK == 12, but the new one with F_GETLK == 5 [2]. > > > > There are no source or build system changes in perl that would have caused > > this change. The failure is currently blocking perl testing migration, > > so filing at 'serious'. > > > > Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye > > this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later > > F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact > > change that caused this yet. > > > > As can be expected from the above, building libfile-fcntllock-perl on > > bookworm against perl_5.36.0-7 makes it fail its test suite in a similar > > way. And rebuilding it on sid against perl_5.36.0-8 makes it pass. > > > > On amd64 the constants have stayed equal (== 5) from bullseye to sid, > > and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el? > > > > Copying the powerpc porters list. Could you please look into this? > > > > [1] > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz > > [2] perl -MPOSIX -E 'say F_GETLK' > > [3] printf '#include \nF_GETLK\nF_GETLK64\n' | cpp > > -D_FILE_OFFSET_BITS=64 | tail -2 Thanks for the details and the investigation. > I think the relevant change here is this in libc6-dev_2.36-9+deb12u1 for > bookworm: > > --- libc6-dev_2.36-9/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > 2023-04-10 09:35:16.0 +0100 > +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > 2023-07-13 19:07:47.0 +0100 > @@ -33,6 +33,12 @@ > # define __O_LARGEFILE 020 > #endif > > +#if __WORDSIZE == 64 > +# define F_GETLK 5 > +# define F_SETLK 6 > +# define F_SETLKW 7 > +#endif > + Indeed you are correct that the issue has been introduced by this patch. It fixes the case *without* -D_FILE_OFFSET_BITS=64, but OTOH breaks the case *with* it. > and a similar one in 2.37-2 for trixie/sid. > > The applicable changelog entry is presumably > >[ Aurelien Jarno ] >* debian/patches/git-updates.diff: update from upstream stable branch: > [...] > - Not affecting bookworm release architectures: >- Fix LFS POSIX lock constants for powerpc64. > > Aurelien, it seems that there's an oversight as ppc64el is a release > architecture? Yes, sorry about that. When reading the changelog and the diff, I thought it was only for powerpc64, as ppc64el has a different ABI, but I was wrong. > I can see that this changed for the better, but what should I do with the > above > breakage? Rebuild perl and libfcntl-fcntllock-perl and declare some Breaks? > Do we want to do that for stable too? I think it's an ABI breakage that should be fixed, but just reverting the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check with upstream and try to get the issue fixed in both testing/sid and stable. I'll keep you updated. In the meantime feel free to reassign the bug to the glibc. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)
On 2022-02-01 16:02, Tulio Magno Quites Machado Filho wrote: > Aurelien Jarno writes: > > > On 2022-01-19 22:08, John Paul Adrian Glaubitz wrote: > >> Hi Aurelien! > >> > >> Unfortunately, glibc no longer builds with this change on powerpc and ppc64 > >> and kernel builds still fails on both targets: > >> > >> > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 > >> > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0 > > > > The ppc64el fix is not the cause for those failures. Previous glibc > > versions also do not build on powerpc and ppc64 following the binutils > > snapshot upload to sid. It's just that more code got broken on powerpc > > and ppc64 than on ppc64el. I have queued the backported fixes from > > upstream for the next upload. > > Are these issues happening when building glibc upstream too? No, upstream built fine, and same now for the 2.33 and 2.34 branches after I backported ee874f44fd55988808a4a162ef21bfa2cc8dc6f7. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)
Hi, On 2022-01-19 22:08, John Paul Adrian Glaubitz wrote: > Hi Aurelien! > > Unfortunately, glibc no longer builds with this change on powerpc and ppc64 > and kernel builds still fails on both targets: > > > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0 > > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0 The ppc64el fix is not the cause for those failures. Previous glibc versions also do not build on powerpc and ppc64 following the binutils snapshot upload to sid. It's just that more code got broken on powerpc and ppc64 than on ppc64el. I have queued the backported fixes from upstream for the next upload. > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0 > > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0 Those failures are completely unrelated to do with glibc. A porter need to fix the kernel code to make it compatible with the new binutils. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
On 2022-01-06 05:36, Rich wrote: > On Thu, Jan 6, 2022 at 5:22 AM Aurelien Jarno wrote: > > > On 2022-01-06 03:36, Rich wrote: > > > Hi Aurelien, > > > It's a VM running in qemu on an amd64 Debian bullseye system, no KVM > > > acceleration to be found here. > > > > Ok, that might be a QEMU issue then. Which CPU do you emulate with QEMU? > > > > I don't explicitly specify a -M or -cpu, so whatever it defaults to, which > according to -M help seems to be "pseries" mapping to pseries-6.1 here. Thanks. That allowed me to reproduce the issue locally. I tracked down it was due to the emulation of a POWER9 CPU, things work fine with a POWER8 CPU. I found that it has been fixed recently in the upstream 2.33 branch: https://sourceware.org/git/?p=glibc.git;a=commit;h=c493f6a0e4dcd6fff22da0df9fb2e52ecf41 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
On 2022-01-06 03:36, Rich wrote: > Hi Aurelien, > It's a VM running in qemu on an amd64 Debian bullseye system, no KVM > acceleration to be found here. Ok, that might be a QEMU issue then. Which CPU do you emulate with QEMU? Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes
control: tag -1 + help control: user debian-powerpc@lists.debian.org control: usertag -1 ppc64 On 2022-01-06 01:45, Rich Ercolani wrote: > Package: libc6 > Version: 2.33-1 > Severity: important > X-Debbugs-Cc: rincebr...@gmail.com > > Dear Maintainer, > > (I marked this as serious because it's "just" ppc64, but the system is > permaneantly unusable if this upgrade is installed.) I have added the powerpc list in Cc: as the ppc64 porters are the people who can help you there. > I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30 packages > in, it died horribly > with Python3 packages erroring out with "Cannot get content of [whatever > package]". Is it a VM running with KVM or is it using QEMU emulation? > Trying to log into a shell over ssh or at a tty after this happens dies with > an error that flashes fast, but > but seems to be "free(): invalid pointer" > > Random applications will now just crash out, in addition to the obvious. (I'm > writing this from a session > spawned before the upgrade, which can still spawn children successfully until > I log out.) > > If I reboot after upgrading, all services fail to start on boot, and it never > spawns a login prompt or rescue > prompt, it just sits forever on a list of failed service starts. > > Anything that would be helpful to debug this? I have a snapshot of the VM > before this began, so I can > just roll it back and repeat the exercise. Ideally a backtrace would help, dmesg outputs can also be useful, however given the state of you system, they might be difficult to get. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: parallel buildd instances in chroots on same host?
On 2019-08-11 10:58, Ryan Tandy wrote: > I'm investigating why openldap failed its tests on powerpc: > > https://buildd.debian.org/status/fetch.php?pkg=openldap=powerpc=2.4.48%2Bdfsg-1=1564255370=0 > > The test001-slapadd failed because ldapsearch returned different data than > expected. The test script is simple, it just imports data into an empty > database (offline) and then starts slapd and tries to read back the same > data using ldapsearch (online). > > It looks like the powerpc and ppc64 builds were running in parallel, on > kapitsa and kapitsa2 respectively. If these builds were running in different > chroots on the same host, then the test failure can be explained by > ldapsearch returning data from a slapd instance started by the other build. > > Am I correct about the two chroots on the single host, and is this a common > setup for Debian buildds? I had assumed builds were typically run in > isolated VMs. This is a correct assumption for official architectures. powerpc and ppc64 are debian-ports architectures, so the setup might be different. Adding powe...@buildd.debian.org and pp...@buildd.debian.org in Cc so that the buildd maintainers can answer more about the setup. -- 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
Re: Git test suite fails on ppc64el-unicamp-01.debian.org: cannot fork
Hi, On 2018-09-12 18:30, Frédéric Bonnard wrote: > Hi, > what are the vm's system specs, also ulimit -a (from the buildd's user shell) > ? The VM has 16 vCPUs and 32GB of RAM. The ulimit are the defaults: | buildd@ppc64el-unicamp-01:~$ ulimit -a | core file size (blocks, -c) 0 | data seg size (kbytes, -d) unlimited | scheduling priority (-e) 0 | file size (blocks, -f) unlimited | pending signals (-i) 130785 | max locked memory (kbytes, -l) 64 | max memory size (kbytes, -m) unlimited | open files (-n) 1024 | pipe size(512 bytes, -p) 8 | POSIX message queues (bytes, -q) 819200 | real-time priority (-r) 0 | stack size (kbytes, -s) 8192 | cpu time (seconds, -t) unlimited | max user processes (-u) 130785 | virtual memory (kbytes, -v) unlimited | file locks (-x) unlimited Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#891249: linux: unstable kernel/data corruption on ppc64el
Source: linux Version: 4.9.82-1+deb9u2 Severity: critical Justification: causes serious data corruption DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the Debian POWER8 machines running ppc64el. While they boot correctly, then programs segfault randomly (apt, sbuild, systemd, etc...). Passing no_rfi_flush to the command line does not change anything. Looking more in details, things looks scarying as some code actually get wrongly executed. Here are some build logs examples: - https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0 - https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0 - https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0 While in the above case the packages fail to build from source, I guess there are also some cases of undetected corruptions. I'll try to run the 4.9.80-2 kernel at some point to narrow down the issue.
Re: diffutils FTBFS on ppc64el
On 2017-01-08 19:56, Santiago Vila wrote: > Hi. > > diffutils FTBFS on ppc64l: > > FAIL: colors > > > diff: standard output: Broken pipe > FAIL colors (exit status: 1) > > > This already happened with previous version 3.5-1. > > Should I worry about it? I gave it back twice, and it ended-up building. But that's probably needs a bit more investigation. I have Cc: debian-powerpc@l.d.o, so that porters can have a look. Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [Debian-ports-devel] wanna-build access for powerpc
On 2016-11-08 08:32, John Paul Adrian Glaubitz wrote: > Hi Aurelien! Hi, > Now that powerpc is de-facto a ports architecture, would it be possible that > you could > give us Debian Ports maintainers wanna-build access so that we can take care > of all the > necessary maintenance work on wb like binNMU, give-backs etc? You might consider powerpc as a ports architecture, but the fact is that it is still hosted on ftp-master.debian.org. Therefore such request should be made to the Debian wb-team [1]. > I suggest again sharing access among Debian Ports maintainers like it's > already being > practiced for the remaining architectures. Can you give the exact list of people who need to get access to it? Aurelien [1] debian-wb-t...@lists.debian.org -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Moving powerpc to Debian Ports
On 2016-11-02 16:49, John Paul Adrian Glaubitz wrote: > On 11/02/2016 03:13 PM, Aurelien Jarno wrote: > >> Well, I don't remember the exact chronology, but I *did* ask a lot of > >> people during DebConf15 to keep it, including you. My request was > >> ignored back then as well. > > > > That's plainly wrong. During Debconf 15, sparc was /already* removed > > from ftp-master, so it was not possible to *keep* it. > > > > What you asked was to create it back on debian-ports, and I explained > > you it was probably a better idea to work on the existing sparc64 port > > instead of rebootstrapping sparc. > > That's why I said, I don't remember the exact chronology. I did not insist > that it happened that exact way. What I said is that we removed something > people were using. It would have been enough to look at Debian Popcon > to see that sparc is something people were/are using. Heck, there are still > around 70 counted installations for sparc despite not being updated anymore > for months. Users are a thing, but then who does the job? You simply can't keep a port that nobody maintains! For the record DSA desperately tried to find help to get the sparc build daemons running without crashing every other day due to kernel issues. We have been even in danger of not being to able to provide security updates for wheezy due to that. > You shouldn't expect users to be present on various Debian mailing lists > and you should not assume no one complaining on any of the lists means > that no one cares about a port being removed. What we should look at > first are popcon numbers and then we should start surveys or something > similar. I expect users who care about a port to be subscribed to the corresponding mailing list. Maybe I am wrong, but what I am sure is that porters must be subscribed to such a list. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Moving powerpc to Debian Ports
On 2016-11-02 09:49, John Paul Adrian Glaubitz wrote: > On 11/02/2016 02:17 AM, Aurelien Jarno wrote: > >> Well, frankly, I'm not sure I'm very confident that this promise will > >> be held up. Both ia64 and sparc were release architectures in Wheezy, > >> dropped in Jessie and consequently removed both from the FTP servers > >> and the buildd infrastructure despite being popular according to > >> popcon. > > > > Nobody asked for ia64 and sparc to be kept, so they have just been > > removed. > > Well, I don't remember the exact chronology, but I *did* ask a lot of > people during DebConf15 to keep it, including you. My request was > ignored back then as well. That's plainly wrong. During Debconf 15, sparc was /already* removed from ftp-master, so it was not possible to *keep* it. What you asked was to create it back on debian-ports, and I explained you it was probably a better idea to work on the existing sparc64 port instead of rebootstrapping sparc. The timeline: - 2015-04-20: ftp-masters announce that sparc will be removed in the next 3 months unless someone opposes. Nobody did except a few "it's sad" emails. No-one step up to do the job. - 2015-07-21: ftp-masters announce that sparc is going to be removed in the next days [2] - 2015-07-27: ftp-masters announce that sparc has been removed from the official archive [3] Aurelien [1] https://lists.debian.org/debian-sparc/2015/04/msg1.html [2] https://lists.debian.org/debian-sparc/2015/07/msg00012.html [3] https://lists.debian.org/debian-sparc/2015/07/msg00023.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: [Debian-ports-devel] Moving powerpc to Debian Ports
On 2016-11-02 00:40, John Paul Adrian Glaubitz wrote: > On 11/01/2016 10:30 PM, Lennart Sorensen wrote: > > On Tue, Nov 01, 2016 at 01:42:50PM +0900, John Paul Adrian Glaubitz wrote: > >> Since Debian powerpc was recently announced to be removed as a release > >> architecture, > >> I would like to formally request to move the port to Debian Ports as there > >> still seems > >> to be quite some demand among users [1]. > > > > It won't be a release arch, but that doesn't imply removal in general from > > debian. > > Both ia64 and sparc were dropped for release after Wheezy and soon after > removed from > the FTP servers and buildd infrastructure altogether. For some reason, this > hasn't > happened to kfreebsd-i386 and kfreebsd-amd64 though, no idea what's the > difference > between ia64/sparc and the kfreebsd ports. Maybe someone interesting in keeping sparc by working on this architecture should have answered this email: https://lists.debian.org/debian-devel/2015/04/msg00284.html Note that hurd-i386 was also supposed to be removed. Hurd porters replied to this email. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Moving powerpc to Debian Ports
On 2016-11-02 00:30, John Paul Adrian Glaubitz wrote: > Hi Aurelien! > > On 11/01/2016 09:00 PM, Aurelien Jarno wrote: > >> Since Debian powerpc was recently announced to be removed as a release > >> architecture, > >> I would like to formally request to move the port to Debian Ports as there > >> still seems > >> to be quite some demand among users [1]. > > > > As stated in the announcement from debian-release, this doesn't mean > > that powerpc is going to be removed from the debian archive. I wonder if > > it is a good idea to rush on that, especially given that you have been > > the one complaining regularly that mini-dak is not so good as dak. > > Well, frankly, I'm not sure I'm very confident that this promise will > be held up. Both ia64 and sparc were release architectures in Wheezy, > dropped in Jessie and consequently removed both from the FTP servers > and the buildd infrastructure despite being popular according to > popcon. Nobody asked for ia64 and sparc to be kept, so they have just been removed. FTR kfreebsd-amd64 and kfreebsd-i386 are still there. There is even a jessie-kfreebsd suite. Maybe talking with ftpmasters is the way to go instead of already considering the outcome, at least it worked for kfreebsd. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Moving powerpc to Debian Ports
On 2016-11-01 13:42, John Paul Adrian Glaubitz wrote: > Hello! Hi, > Since Debian powerpc was recently announced to be removed as a release > architecture, > I would like to formally request to move the port to Debian Ports as there > still seems > to be quite some demand among users [1]. As stated in the announcement from debian-release, this doesn't mean that powerpc is going to be removed from the debian archive. I wonder if it is a good idea to rush on that, especially given that you have been the one complaining regularly that mini-dak is not so good as dak. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: ppc64el porter situation
Hi, On 2016-10-17 22:50, Adrian Bunk wrote: > Disclaimer: > I am not a member of the release team, and I am only speaking for myself. > > > The architecture requalification status for stretch [1] lists the > ppc64el porter situation as green, but there are three reasons why > the situation doesn't look that good to me. > > > First, official status of the porters: > - 1 DD > - 1 DM > - 2 no DD/DM > > Is a DM enough, if the only DD gets killed by a car [2] the day after > the release of stretch? I am actually not sure it makes a lot of difference being DD or DM or even not a DD/DM. What is important is that issues are fixed, that patches are provided. For that you need access to the knowledge and access to the hardware, not upload or vote rights. > Second, all 4 committed porters seem to be employees of IBM. That's true, but they are from two different teams in two different countries. > What happens if for whatever good or bad reason IBM decides in 2018 > or 2019 to go away from ppc64el, and all 4 committed porters get fired? > > The wording of the porter commitment is already limited to "I intend to", > and there is the single point of failure that one business decision > by IBM might reduce the number of porters immediately from 4 to 0. I think it's unlikely to happen, and even if that happens the porters might continue to work on Debian on their personal time. > Third, the skills of the committed porters for post-release work. > > It is extremely valuable when people are doing manual and automated > testing and fix the usual porting issues prior to the release. > > But the most important skills required post-release until end-2020 are > quite different. > > How many of the committed ppc64el porters are personally able to fix > difficult issues that require intimate knowledge of hardware, kernel > and toolchain? The 4 porters have been working on ppc64el for years, they have done the initial bootstrapping outside of Debian, they have done the initial bootstrap in Debian, they have participated in the release of Jessie and they have sent hundred of patches in the BTS. To me it looks like they are really skilled for that job. Do you have actual facts showing the contrary? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: maclhw ?
On 2016-06-21 11:54, Mathieu Malaterre wrote: > Does anyone knows if any of the flavor: powerpc / ppc64 / ppc64el > supports 'maclhw' ? The maclhw family of instruction is specific to the PowerPC 405 CPU. I *think* you can run the powerpc flavour in such a CPU, but clearly not ppc64 or ppc64el. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [Debian-ports-devel] debian-ports archive moved
On 2016-05-28 13:44, Andreas Schwab wrote: > Aurelien Jarno <aure...@debian.org> writes: > > > APT archive > > --- > > The APT archive is now accessible on ftp.ports.debian.org [2], which > > maps to 2 machines, one in The Netherlands and one in the USA. Here > > are the corresponding sources.list line: > > > > deb http://ftp.ports.debian.org/debian unstable main > > deb http://ftp.ports.debian.org/debian unreleased main > > > > and possibly: > > > > deb http://ftp.ports.debian.org/debian experimental main > > 404. Did you mean http://ftp.ports.debian.org/debian-ports? Yes, you are correct, sorry about that. The correct lines for unstable are: deb http://ftp.ports.debian.org/debian-ports unstable main deb http://ftp.ports.debian.org/debian-ports unreleased main and for experimental: deb http://ftp.ports.debian.org/debian-ports experimental main -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
debian-ports archive moved
Dear all, During Debian SunCamp [1] we have moved the debian-ports archive from the old leda.debian.net machine to a DSA administrated machine called porta.debian.org. The software managing the archive, mini-dak, is still the same, however the whole is now better integrated in the debian.org namespace and with the mirror system. You will find the users visible changes below. APT archive --- The APT archive is now accessible on ftp.ports.debian.org [2], which maps to 2 machines, one in The Netherlands and one in the USA. Here are the corresponding sources.list line: deb http://ftp.ports.debian.org/debian unstable main deb http://ftp.ports.debian.org/debian unreleased main and possibly: deb http://ftp.ports.debian.org/debian experimental main Redirections have been setup so that the old URLs still work, but they will not be kept permanently. In addition, given that the number of debian-ports users is relatively small, the mirror network has been dropped in favor of a CDN. It is not yet available, but it should be the case in the next hours or days. Please see the corresponding page for the details [3]. Uploading packages -- People having upload rights should now upload packages to the ports-master.debian.org FTP server in the /incoming directory. CD images - CD images are now available on [4]. Again redirections have been setup. Web site The debian-ports website is now available on [5] using HTTPS, and redirection from the various previous URL have been set up. The links and instructions on the web site have also been update, don't hesitate to report any broken link. We would like to thank to the DSA team and the SunCamp organizers for making that possible. Aurelien on behalf of the debian-ports team [1] https://wiki.debian.org/DebianEvents/Europe/2016/DSC#Events [2] http://ftp.ports.debian.org/debian-ports/ [3] http://deb.debian.org/ [4] http://ftp.ports.debian.org/debian-ports-cd/ [5] https://www.ports.debian.org -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: vdso32 fails to built on ppc64el
On 2015-05-12 15:55, Matthias Klose wrote: that should be fixed on the kernel side by removing this code. there never was a powerpcle userland support. If this is not possible in the short term, then we can re-enable this for unstable for some time. This also seems to break grub2 on ppc64el [1]. I think it's a legitimate use case. [1] https://buildd.debian.org/status/fetch.php?pkg=grub2arch=ppc64elver=2.02~beta2-23stamp=1431706310 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150515214654.ga2...@aurel32.net
Re: Help with the arm64 and ppc64el installation-guides needed
On 2015-04-12 20:22, Samuel Thibault wrote: Hello, Mmm, the following looks like a useless addition: Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit : Index: en/boot-installer/powerpc.xml === --- en/boot-installer/powerpc.xml (Revision 69729) +++ en/boot-installer/powerpc.xml (Arbeitskopie) @@ -283,3 +283,41 @@ /para /sect2 + + sect2 arch=ppc64el titleBooting a ppc64el machine/title +para + +How to boot a ppc64el machine: + +/para + + sect3 titlePetitboot/title +para + +Petitboot is a platform independent bootloader based on the Linux kexec. +Petitboot supports loading kernel, initrd and device tree files from +any Linux mountable filesystem, plus can load files from the network +using the FTP, SFTP, TFTP, NFS, HTTP and HTTPS protocols. Petitboot can +boot any operating system that includes kexec boot support. + +/parapara + +Petitboot looks for bootloader configuration files on mountable devices +in the system, and can also be configured to use boot information from a +DHCP server. + +/para + /sect3 + +!-- comment this out for now, since there is no content + sect3 titleBoot parameters/title +para +Boot parameters for ppc64el + +FIXME: add some useful content here + +/para + /sect3 +-- + + /sect2 Since petitboot runs inside a running linux kernel, that only shifts the problem of booting that linux kernel :) Petitboot is the default bootloader on this machine when configured to run Linux. It's the interface the user see when powering up the machine. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150412200844.go4...@aurel32.net
New debian-ports archive signing key (2014)
Hi, The 2014 debian-ports archive signing key will expire in the next days (sorry for the late change). I've created the 2015 one, uploaded it to the keyservers, and uploaded a new version of the debian-ports-archive-keyring package. This key is already used to sign the archive in addition to the 2014 one, which will be deactivated when expiring. The key is: pub 4096R/C448326E 2015-01-27 [expires: 2016-02-01] Key fingerprint = 1AD7 967B 6A55 FDD7 C074 6577 A53A B45A C448 326E uid Debian Ports Archive Automatic Signing Key (2015) ftpmas...@debian-ports.org It can be found as well on: http://archive.debian-ports.org/archive_2015.key Or attached to this mail. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net archive_2015.key Description: application/pgp-keys signature.asc Description: Digital signature
Re: Adding ppc64el support in debian-cd
On Fri, Oct 03, 2014 at 01:00:04AM +0100, Steve McIntyre wrote: On Fri, Oct 03, 2014 at 12:33:01AM +0200, Aurelien Jarno wrote: Hi Steve, On Sat, Sep 27, 2014 at 10:02:34AM +0200, Aurelien Jarno wrote: On Mon, Sep 22, 2014 at 10:47:10PM +0200, Aurelien Jarno wrote: The tarball should be decompressed in the root of the CD-ROM, while the kernel and initrd should be placed in the /install directory. The ISO image should be generated with the --chrp-boot argument. Beside that the default options of genisoimage should be used, there is no need to specify any strange HFS option like on powerpc (Note: I only tested that on a VM using SLOF, it will be nice if someone with access to bare metal can confirm that). Don't hesitate to ask more details if needed. I will tell you once GRUB is fixed and all these files are in place on d-i.debian.org. GRUB is now fixed, and the latest daily build of d-i does have the CDROM files available: http://d-i.debian.org/daily-images/ppc64el/daily/cdrom/ Please find attached a patch to add ppc64el support to debian-cd. Could you please merge it? Done, and pushed. I've also just added ppc64el to the daily and weekly build config - let's see how well it works! Thanks! It seems the daily build has worked correctly. Unfortunately the d-i's cdrom flavour misses the SCSI modules to access the CD-ROM, so a full installation is not possible. I have fixed that in the d-i git, it has missed the beta2 release, but should be in tomorrow's daily. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003093819.gr3...@hall.aurel32.net
Re: Adding ppc64el support in debian-cd
Hi Steve,
On Sat, Sep 27, 2014 at 10:02:34AM +0200, Aurelien Jarno wrote:
On Mon, Sep 22, 2014 at 10:47:10PM +0200, Aurelien Jarno wrote:
The tarball should be decompressed in the root of the CD-ROM, while the
kernel and initrd should be placed in the /install directory. The ISO
image should be generated with the --chrp-boot argument. Beside that the
default options of genisoimage should be used, there is no need to
specify any strange HFS option like on powerpc (Note: I only tested that
on a VM using SLOF, it will be nice if someone with access to bare metal
can confirm that).
Don't hesitate to ask more details if needed. I will tell you once GRUB
is fixed and all these files are in place on d-i.debian.org.
GRUB is now fixed, and the latest daily build of d-i does have the CDROM
files available:
http://d-i.debian.org/daily-images/ppc64el/daily/cdrom/
Please find attached a patch to add ppc64el support to debian-cd. Could
you please merge it?
Thanks,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
From c7868964f5fb572fccbb7a00fd2f79bf612fadb5 Mon Sep 17 00:00:00 2001
From: Aurelien Jarno aurel...@aurel32.net
Date: Fri, 3 Oct 2014 00:11:47 +0200
Subject: [PATCH] Add initial support for ppc64el
---
build_all.sh | 2 +-
tools/boot/jessie/boot-ppc64el | 65 ++
tools/generate_di+k_list | 9 ++
3 files changed, 75 insertions(+), 1 deletion(-)
create mode 100755 tools/boot/jessie/boot-ppc64el
diff --git a/build_all.sh b/build_all.sh
index 70337ec..87d938d 100755
--- a/build_all.sh
+++ b/build_all.sh
@@ -40,7 +40,7 @@ if [ -z $IMAGETARGET ] ; then
IMAGETARGET=official_images
fi
-for ARCHES in i386 amd64 armel armhf arm64 mips mipsel powerpc s390x kfreebsd-amd64 kfreebsd-i386 source
+for ARCHES in i386 amd64 armel armhf arm64 mips mipsel powerpc ppc64el s390x kfreebsd-amd64 kfreebsd-i386 source
do
export ARCHES
echo Now we're going to build CD for $ARCHES !
diff --git a/tools/boot/jessie/boot-ppc64el b/tools/boot/jessie/boot-ppc64el
new file mode 100755
index 000..0db3163
--- /dev/null
+++ b/tools/boot/jessie/boot-ppc64el
@@ -0,0 +1,65 @@
+#!/bin/bash
+#
+# Do install stuff for ppc64el, including making bootable CDs
+# Works with debian-installer
+#
+# $1 is the CD number
+# $2 is the temporary CD build dir
+
+. $BASEDIR/tools/boot/$DI_CODENAME/common.sh
+
+set -e
+#set -x
+
+N=$1
+CDDIR=$2
+INSTALLDIR=$CDDIR/install
+if [ $DI_WWW_HOME = default ];then
+DI_WWW_HOME=http://d-i.debian.org/daily-images/ppc64el/daily;
+try_di_image_cache
+fi
+
+# Common mkisofs options when creating CDs
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts -J -joliet-long
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts -cache-inodes
+
+# Only disc 1 bootable
+if [ $N != 1 ] ; then exit 0; fi
+
+cd $CDDIR/..
+
+BOOT_IMAGES=cdrom/initrd.gz cdrom/vmlinux cdrom/debian-cd_info.tar.gz
+
+# Download boot images.
+for image in $BOOT_IMAGES; do
+if [ ! -e $image ]; then
+dir=$(dirname $image)
+mkdir -p $dir
+if [ -n $LOCAL -a -f ${LOCALDEBS:-$MIRROR}/dists/$DI_DIST/local/installer-$ARCH/current/images/$image ]; then
+cp ${LOCALDEBS:-$MIRROR}/dists/$DI_DIST/local/installer-$ARCH/current/images/$image $image
+elif [ ! $DI_WWW_HOME ];then
+if [ ! $DI_DIR ];then
+DI_DIR=$MIRROR/dists/$DI_DIST/main/installer-$ARCH/current/images
+fi
+cp $DI_DIR/$image $image
+else
+wget $DI_WWW_HOME/$image -O $image
+fi
+fi
+done
+
+# Boot setup including config and help files comes from d-i.
+mkdir -pv $PWD/CD$N
+cat cdrom/debian-cd_info.tar.gz | (cd CD$N/; tar zx)
+
+# Copy kernel and initrd
+mkdir -p $INSTALLDIR
+cp -lf cdrom/vmlinux $INSTALLDIR/
+cp -lf cdrom/initrd.gz $INSTALLDIR/
+
+# Add CHRP boot header
+if [ -d CD$N/ppc/bootinfo.txt ] ; then
+add_mkisofs_opt $CDDIR/../$N.mkisofs_opts -chrp-boot
+fi
+
+exit 0
diff --git a/tools/generate_di+k_list b/tools/generate_di+k_list
index 7759e4b..2ecea4e 100755
--- a/tools/generate_di+k_list
+++ b/tools/generate_di+k_list
@@ -232,6 +232,15 @@ linux-image-powerpc64
linux-image-prep
#endif
+#ifdef ARCH_ppc64el
+initramfs-tools
+grub-ieee1275
+busybox
+powerpc-utils
+powerpc-ibm-utils
+linux-image-powerpc64el
+#endif
+
#ifdef ARCH_alpha
aboot
#endif
--
2.1.1
signature.asc
Description: Digital signature
Re: Adding ppc64el support in debian-cd
On Mon, Sep 22, 2014 at 10:47:10PM +0200, Aurelien Jarno wrote: On Mon, Sep 22, 2014 at 02:09:29PM +0100, Steve McIntyre wrote: On Mon, Sep 22, 2014 at 09:57:44AM -0300, Mauricio Faria de Oliveira wrote: On 09/22/2014 12:00 AM, Lennart Sorensen wrote: On Sun, Sep 21, 2014 at 06:19:43PM +0100, Steve McIntyre wrote: I'm adding support for new architectures at the moment. powerpc is one of the most awkward existing arches to add boot support for at the moment, due to the mess of older machines. I'm hoping that ppc64el is better, but I don't have much information to go on. What should we be doing to make bootable CD/DVD/USB images for ppc64el, please? Aurelien and Paulo know more about the bootable status/steps than me. I believe that w/ the grub2 and klibc uploads from this last weekend, it's almost there. There's powerpc-utils util-linux coming in from DELAYED in 2 days 5 days. OK, cool. Indeed bootable CD images are done with GRUB on ppc64el, but it is currently broken. debian-installer will provide a kernel, a vmlinux and a file called debian-cd_info.tar.gz containing the grub files. I have put an example of such a directory tree there: http://temp.aurel32.net/ppc64el/d-i/ The tarball should be decompressed in the root of the CD-ROM, while the kernel and initrd should be placed in the /install directory. The ISO image should be generated with the --chrp-boot argument. Beside that the default options of genisoimage should be used, there is no need to specify any strange HFS option like on powerpc (Note: I only tested that on a VM using SLOF, it will be nice if someone with access to bare metal can confirm that). Don't hesitate to ask more details if needed. I will tell you once GRUB is fixed and all these files are in place on d-i.debian.org. GRUB is now fixed, and the latest daily build of d-i does have the CDROM files available: http://d-i.debian.org/daily-images/ppc64el/daily/cdrom/ Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927080234.gc3...@hall.aurel32.net
Re: Adding ppc64el support in debian-cd
On Mon, Sep 22, 2014 at 02:09:29PM +0100, Steve McIntyre wrote: On Mon, Sep 22, 2014 at 09:57:44AM -0300, Mauricio Faria de Oliveira wrote: On 09/22/2014 12:00 AM, Lennart Sorensen wrote: On Sun, Sep 21, 2014 at 06:19:43PM +0100, Steve McIntyre wrote: I'm adding support for new architectures at the moment. powerpc is one of the most awkward existing arches to add boot support for at the moment, due to the mess of older machines. I'm hoping that ppc64el is better, but I don't have much information to go on. What should we be doing to make bootable CD/DVD/USB images for ppc64el, please? Aurelien and Paulo know more about the bootable status/steps than me. I believe that w/ the grub2 and klibc uploads from this last weekend, it's almost there. There's powerpc-utils util-linux coming in from DELAYED in 2 days 5 days. OK, cool. Indeed bootable CD images are done with GRUB on ppc64el, but it is currently broken. debian-installer will provide a kernel, a vmlinux and a file called debian-cd_info.tar.gz containing the grub files. I have put an example of such a directory tree there: http://temp.aurel32.net/ppc64el/d-i/ The tarball should be decompressed in the root of the CD-ROM, while the kernel and initrd should be placed in the /install directory. The ISO image should be generated with the --chrp-boot argument. Beside that the default options of genisoimage should be used, there is no need to specify any strange HFS option like on powerpc (Note: I only tested that on a VM using SLOF, it will be nice if someone with access to bare metal can confirm that). Don't hesitate to ask more details if needed. I will tell you once GRUB is fixed and all these files are in place on d-i.debian.org. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140922204710.gb5...@hall.aurel32.net
Re: Work to be done on ppc64el before the release (or even before)
On Mon, Sep 22, 2014 at 03:26:56PM -0300, Mauricio Faria de Oliveira wrote: On 09/16/2014 12:45 PM, Aurelien Jarno wrote: atlas FTBFS, we don't seem to have a patch for this one bzr #760054 - Not specific to ppc64el gaucheFTBFS, we don't seem to have a patch for this one gccxmlFTBFS, we don't seem to have a patch for this one submitted #762476 grub Patches have been send upstream, one got some comments uploaded; exception during boot being addressed. klibc #749060 - Maintainer said on IRC he will look at the it... uploaded libkolabxml FTBFS, seems to be a problem with boost::math::changesign boost1.55 uploaded waiting for upload w/ updated symbols file scalapack #761317 - I guess we can NMU it in a few days uploaded swi-prolog#761222 - We should probably ping the maintainer uploaded Thanks for you work. Please note that the maintainer of libkolabxml has been pinged on IRC, we expect an upload in the next few days. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140922204810.gc5...@hall.aurel32.net
Work to be done on ppc64el before the release (or even before)
Hi all, The architecture qualification meeting last Sunday has decided that arm64 and ppc64el will be in principle released with Jessie. This means that they will be released providing enough progress is done before the release (and ideally before the freeze). On the hardware side things seems to progress well, though we will have a problem to install Debian on it if we don't have grub ported. On the packages side the status is quite good and a big part of the build failures are for leaf packages that might not fully necessary for the release (and some of them also will not be in Jessie as they have RC bugs). We should still try to fix them if possible. I have tried to identify packages that are important either because of the functionality they provide or because the number of packages which build-depends on them. Here is a first list: atlas FTBFS, we don't seem to have a patch for this one bzr #760054 - Not specific to ppc64el gaucheFTBFS, we don't seem to have a patch for this one gccxmlFTBFS, we don't seem to have a patch for this one grub Patches have been send upstream, one got some comments klibc #749060 - Maintainer said on IRC he will look at the it... libkolabxml FTBFS, seems to be a problem with boost::math::changesign scalapack #761317 - I guess we can NMU it in a few days swi-prolog#761222 - We should probably ping the maintainer In the above list,it looks like atlas and grub are probably the most worrying ones, I guess we can get the other fixed soon. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916154545.gs28...@hall.aurel32.net
Re: Work to be done on ppc64el before the release (or even before)
On Tue, Sep 16, 2014 at 05:45:45PM +0200, Aurelien Jarno wrote:
On the packages side the status is quite good and a big part of the
build failures are for leaf packages that might not fully necessary for
the release (and some of them also will not be in Jessie as they have RC
bugs). We should still try to fix them if possible. I have tried to
identify packages that are important either because of the
functionality they provide or because the number of packages which
build-depends on them. Here is a first list:
libkolabxml FTBFS, seems to be a problem with boost::math::changesign
A quick note about this one. Andi Barth has started to debug that, and
I have continued a bit. The following code doesn't work correctly on
ppc64el, printing twice a positive value.
#include boost/math/special_functions.hpp
#include iostream
int main(int argc, char **argv)
{
const long double a = 12.34;
std::cout a std::endl;
const long double b = (boost::math::changesign)(a);
std::cout b std::endl;
}
I probably won't have time to look at that before the week-end, so don't
hesitate to have a look if you have time.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916154851.gt28...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
On Thu, Sep 11, 2014 at 04:52:04PM -0300, Breno Leitao wrote: Right. This is going to help all those shared-library-issue bugs to be 'solved'. Btw, did you mark all the failed/build-attempted to rebuild, so, we can find what packages are going to benefit from it? Yes, I requeued all the packages from build-attempted, and all packages in failed that were related to an autoconf/libtool issue. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912085806.gf28...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
Hi all,
On Thu, Aug 21, 2014 at 03:55:49PM +0200, Frédéric Bonnard wrote:
Hi all/Aurelien,
I'd like to help fixing issues found during buildd of packages on ppc64el :
https://buildd.debian.org/status/architecture.php?a=ppc64elsuite=sid
I have just found that the autoreconf/libtool issue has been magically
fixed by the following binutils change:
| binutils (2.24.51.20140903-1) unstable; urgency=medium
| .
| * Snapshot, taken from the trunk 20140903.
| * Try to work around binutils-multiarch build failure on sh4 by disabling
| hppa targets for the binutils-multiarch build. Addresses: #758830.
| * Enable powerpc targets for ppc64el. Closes: #760395.
The last line changed the supported emulations from:
| ld: supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim
to
| ld: supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim
elf32ppclinux elf32ppc elf32ppcsim elf64ppc
Older versions of libtool code in configure script do the following:
| case $host in
|x86_64-*linux*)
| LD=${LD-ld} -m elf_x86_64
| ;;
|ppc*-*linux*|powerpc*-*linux*)
| LD=${LD-ld} -m elf64ppc
| ;;
So powerpc64le-linux-gnu is wrongly detected as elf64ppc (instead of
elf64lppc). This value is then passed to ld to check if it supports
shared libraries. The above binutils change make this check to succeed.
This value is not used outside of configure script, so this should be
relatively safe and anyway I think ld would refuse to link ppc64 BE and
LE objects together.
In the short term, that will help to build a few hundred packages,
though I think this bug should still be fixed. That's just less urgent
now.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140911150309.gc28...@hall.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-powerpc-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: Fixing buildd issues on ppc64el
Hi, On Fri, Aug 29, 2014 at 01:53:01PM +0200, Erwan Prioul wrote: On 08/21/2014 04:26 PM, Aurelien Jarno wrote: I have started to put the known failures with a bug number, but if some others can help with matching a build failure with a bug number that would be great. Of course if there is no bug in the BTS, it's a good idea to debug it and report a new bug with a patch. Hi Aurelien, I've generated a list[1] that could help you (I hope so). This list shows the packages that have bugs tagged (tag ppc64el) and appear in the Build-attempted/Failed sections from the buildd status of ppc64el page from Debian[2]. Thanks, I have move the packages with a bug number from Build-attempted to Failed, with the corresponding bug number as a comment. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140905160926.ga22...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
Hi, On Thu, Aug 21, 2014 at 04:26:55PM +0200, Aurelien Jarno wrote: On Thu, Aug 21, 2014 at 03:55:49PM +0200, Frédéric Bonnard wrote: I'd like to help fixing issues found during buildd of packages on ppc64el : https://buildd.debian.org/status/architecture.php?a=ppc64elsuite=sid Thanks, help is welcomed. You might have seen there are two categories, Build-Attempted and Failed. The first one is where packages which fails to build land. It can be moved to Failed by a DD having access to wanna-build with a comment. Now that we have debian-installer working, I have installed a VM with it and tried to determine which packages are still missing to setup a VM with the standard DSA packages using the Debian archive. I therefore tried to install the various meta-packages in order to find which packages are missing in the Debian archive. Here is the list below, based on the source package name, with an explanation why they are not available: bacula #758125 ftbfs (libtool) bzr#760054 ftbfs (non ppc64el specific) #760054 deborphan #735010 ftbfs (libtool) emacs23#749530 build-dep on libotf, which ftbfs (libtool) git#727295 build-dep indirectly on exiv2, which ftbfs (libtool) grub2 need a cross-compiler or patches klibc #749060 some binaries segfault mutt #752831 build-dep on gpgme1.0 which ftbfs (libtool) powerpc-utils #738140 arch not in list subversion #727295 build-dep indirectly on exiv2, which ftbfs (libtool) tcshtestsuite failure ulogd2 #734029 build-dep on libnetfilter-acct, which ftbfs (libtool) It would be a good idea to work on these packages in priority. Thanks, Aurelien [1] http://d-i.debian.org/daily-images/ppc64el/daily/netboot/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140905173300.gb22...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
On Thu, Aug 28, 2014 at 12:49:30PM -0300, Mauricio Faria de Oliveira wrote: Hi Aurelien, A few more failing-packages - bugs: cernlib #720689 (patch; non ppc64el-specific) kbuild #759457 libgssglue #732574 (patch) linux-tools #754213 #747151 mosjz #752415 (patch) mpich2 #744634 ruby-ffi #759550 (pending) Thanks, I marked these as failed in the wanna-build database. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140828171803.gu15...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
On Tue, Aug 26, 2014 at 05:51:20AM +0200, Aurelien Jarno wrote: On Mon, Aug 25, 2014 at 04:12:01PM -0300, Breno Leitao wrote: Aurelien, This is a list of the packages that I just mapped to bugs. Thanks I have imported it. On a slightly related thing, it seems we will need webkitgtk soon, and unfortunately I haven't been able to find a patch for it. I have been able to find an easy way to fix that, and I have opened a bug, so everything is fine now. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826072758.gh15...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
On Mon, Aug 25, 2014 at 04:12:01PM -0300, Breno Leitao wrote: Aurelien, This is a list of the packages that I just mapped to bugs. Thanks I have imported it. On a slightly related thing, it seems we will need webkitgtk soon, and unfortunately I haven't been able to find a patch for it. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826035120.gg15...@hall.aurel32.net
Re: Fixing buildd issues on ppc64el
On Thu, Aug 21, 2014 at 03:55:49PM +0200, Frédéric Bonnard wrote: Hi all/Aurelien, Hi, I'd like to help fixing issues found during buildd of packages on ppc64el : https://buildd.debian.org/status/architecture.php?a=ppc64elsuite=sid Thanks, help is welcomed. You might have seen there are two categories, Build-Attempted and Failed. The first one is where packages which fails to build land. It can be moved to Failed by a DD having access to wanna-build with a comment. I have started to put the known failures with a bug number, but if some others can help with matching a build failure with a bug number that would be great. Of course if there is no bug in the BTS, it's a good idea to debug it and report a new bug with a patch. How should I proceed to setup a similar schroot with same package repo? The schroot can be created from the debian-archive with debootstrap using any of the official mirror. Once the chroot is created, it's also a good idea to add the following entry to /etc/apt/sources.list to get the packages as soon as they get uploaded: deb http://incoming.debian.org/debian-buildd buildd-unstable main At the moment we have a buildd daemon at IBM and I can do that kind of work. Now it'd be nice if I could help on the debian's buildd for ppc64el, that would make more sense. Indeed! Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821142655.gc15...@hall.aurel32.net
New debian-ports archive signing key (2014)
Hi, The 2013 debian-ports archive signing key will expire at the end of the month. I've created the 2014 one, uploaded it to the keyservers, and uploaded a new version of the debian-ports-archive-keyring package. This key is already used to sign the archive in addition to the 2013 one, which will be deactivated at the end of the month. The key is: pub 4096R/623DB0B8 2014-01-16 [expires: 2015-01-31] Key fingerprint = 141C 2C65 6948 C9B2 E5E9 8231 AA65 1E74 623D B0B8 uid Debian Ports Archive Automatic Signing Key (2014) ftpmas...@debian-ports.org It can be found as well on: http://archive.debian-ports.org/archive_2014.key Or attached to this mail. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net archive_2014.key Description: application/pgp-keys signature.asc Description: Digital signature
New debian-ports archive signing key (2014)
[ Sorry for the resend, but I attached the non-armored version of the key to my previous email, and it seems it broke the signature. ] Hi, The 2013 debian-ports archive signing key will expire at the end of the month. I've created the 2014 one, uploaded it to the keyservers, and uploaded a new version of the debian-ports-archive-keyring package. This key is already used to sign the archive in addition to the 2013 one, which will be deactivated at the end of the month. The key is: pub 4096R/623DB0B8 2014-01-16 [expires: 2015-01-31] Key fingerprint = 141C 2C65 6948 C9B2 E5E9 8231 AA65 1E74 623D B0B8 uid Debian Ports Archive Automatic Signing Key (2014) ftpmas...@debian-ports.org It can be found as well on: http://archive.debian-ports.org/archive_2014.key Or attached to this mail. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net archive_2014.key Description: application/pgp-keys signature.asc Description: Digital signature
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-powerpc-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: Bug#731069: gcc-defaults: Please resume considering to change using unified version of gcc
On Wed, Dec 04, 2013 at 01:52:22AM +0100, Matthias Klose wrote: Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto: Hi, I don't know whether it is appropriate that I remark, I have no objection to moving to gcc-4.8 on ppc64, too. this is not a question about any objections, but about a call to the ppc64 porters if they are able to maintain such a port in Debian. There is no response yet. Hiroyuki Yamamoto is the porter behind ppc64, so please consider that as an answer. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131208214322.ga18...@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-powerpc-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
New debian-ports archive signing key (2013)
Hi, The 2012 debian-ports archive signing key will expire at the end of the month. I've created the 2013 one, uploaded it to the keyservers, and uploaded a new version of the debian-ports-archive-keyring package. This key is already used to sign the archive in addition to the 2012 one, which will be deactivated at the end of the month. The key is: pub 4096R/2FF7A9F4 2012-12-30 [expires: 2014-01-31] Key fingerprint = F192 9868 D640 54EF 3E89 6A96 1C46 6F27 2FF7 A9F4 uid Debian Ports Archive Automatic Signing Key (2013) ftpmas...@debian-ports.org It can be found as well on: http://archive.debian-ports.org/archive_2013.key Or attached to this mail. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net archive_2013.key Description: application/pgp-keys signature.asc Description: Digital signature
PowerPCSPE port status
Hi, It seems that the powerpcspe port hasn't seen an upload since the beginning of the year, with the consequence that less than 30% of the packages are now up to date. What is the status of this port? Are there still people working on it? using it? Thanks, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: PowerPCSPE port status
Hi, On Mon, Sep 17, 2012 at 12:18:14PM +0200, Sebastian Andrzej Siewior wrote: On Mon, Sep 17, 2012 at 11:51:33AM +0200, Aurelien Jarno wrote: Hi, Hi Aurelien, It seems that the powerpcspe port hasn't seen an upload since the beginning of the year, with the consequence that less than 30% of the packages are now up to date. What is the status of this port? I tried to keep the port a live in my spare time but gave up because they were too many changes. Are there still people working on it? I am not. Kyle left Boeing and the other people there seem not to continue his work. using it? I am getting mails from time to time how can I help with the port I need new packages or something like that but after I tell what there is to do I don't hear anything anymore. P2020 is still used in new designs and I don't know if still FSL recommends it. The successor CPUs in this category (post P2020 that is P2041, P4xxx, …) have the e500mc core (instead of e500) which supports the normal FPU which can not make use of the port. If you need to space and nobody is stepping up to maintain the port then I guess nobody will complain :) Thanks for your answer. We don't need space or CPU now, but it might be the case at some point. That's why I was asking such questions ;-). Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917103135.gb29...@hall.aurel32.net
Re: PowerPCSPE port status
On Mon, Sep 17, 2012 at 03:21:51PM +0200, Sebastian Andrzej Siewior wrote: On Mon, Sep 17, 2012 at 08:07:25AM -0500, Kumar Gala wrote: Freescale still sells numerous SoCs that would utilize this port. (8548, P2020, P102x, P1010, etc.). So if its not impacting anyone would be useful to keep it around. Ehm yes. I think they guarantee something like 10 years of availability since the announcement. I know there are atleast a dozen libs which didn't make a transition in this port. That means you need some hand crafting until the buildd can take over. So if you look at [0] there are only 51 packeges ready to built and 6983 require some deps which are not yet available. This means only around 27% of the port is complete port and we were once at around 91%. Unless I'm wrong, the archive purges packages _all packages after a few days if new packages arrive which is another problem. So I'm not even sure a complete bootstrap is still possible… Yes, that was it. The plot is available [1]. That means if you read this and you need this port working please step up and do something :) Yes, I don't think the port is available in the current situation. In the long term, it make sense to keep it, if it is actually maintained. Aurelien [1] http://buildd.debian-ports.org/stats/graph-big.png -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917143122.gb3...@ohm.aurel32.net
Re: debian-ports.org migration
On Sat, Apr 30, 2011 at 11:54:56PM +0200, Aurelien Jarno wrote: Hi all, As some of you might already be aware, debian-ports.org is moving to a new machine, which should solve our disk space issues and secure the hosting for the future. This machine is now hosted by Debian and is called leda.debian.net [1]. Thanks to DSA for making that possible. The migration will happen tomorrow, Sunday May 1st, and the various services will be unavailable during a few hours in order to do the final synchronisation between the two machines. DNS will be updated after this, so most people won't notice any change. The migration was finished today around 12:00 UTC, but I waited a bit more for having a full run of all the scripts before announcing everything was fine. The services are now all running, however it happens that the I/O are quite slow on the new machine, archive install taking more than 7 hours instead of less than 1 hour before. Until the problem is understood and fixed, I have changed the crontab to only run 2 archive-install per day instead of 4. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
debian-ports.org migration
Hi all, As some of you might already be aware, debian-ports.org is moving to a new machine, which should solve our disk space issues and secure the hosting for the future. This machine is now hosted by Debian and is called leda.debian.net [1]. Thanks to DSA for making that possible. The migration will happen tomorrow, Sunday May 1st, and the various services will be unavailable during a few hours in order to do the final synchronisation between the two machines. DNS will be updated after this, so most people won't notice any change. However buildds maintainers, as well as people having an account on the machine will see a new host SSH key. Please find below the fingerprint of the new keys: (DSA) 1024 92:81:ff:30:c5:fb:85:92:70:8c:aa:d0:ea:3e:0e:c9 (RSA) 2048 44:ea:d0:12:49:03:7b:e1:ba:80:d3:cd:a4:03:76:2b At the same time, I am also planning to slightly change the DNS entries and the mail setup, so that it's possible to use the name on the service. That should allow easier future migration. As a consequence starting from after the migration, please use the following names instead of simply debian-ports.org for the following services (the old one will be kept for some time): - buildd.debian-ports.org for ssh connection to wanna-build - l...@buildd.debian-ports.org instead of l...@debian-ports.org for build logs. - rsync.debian-ports.org for rsync access. Don't hesitate to report any problem which may arise from this migration, but please first wait until the migration is really finished. Aurelien [1] This is a moon of Jupiter, in the same series as kfreebsd or hurd related machines. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-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: ppc64 port gone?
On Sun, Feb 27, 2011 at 01:02:49PM +, Hector Oron wrote: Hi Hiroyuki, 2011/2/27 Hiroyuki Yamamoto yama1...@gmail.com: Hector Oron wrote: You said so a while back. Is this effort happening at some public site, would not be best try to use debian-ports.org or similar infrastructure? Be careful with patches in BTS, those need to be properly tagged and are likely to bitrot if there is no proper maintainance. I want to use the infrastructure of debian-ports.org, but I was refused because of lacking disk space. http://lists.debian.org/debian-powerpc/2010/10/msg00013.html I think that is not a problem anymore. Only one of the two disks offered by Genesi has been changed, the other didn't work. So it is still a problem. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110227134906.gj24...@hall.aurel32.net
New debian-ports archive signing key (2011)
Hi, The 2010 debian-ports archive signing key will expire at the end of the month. I've created the 2011 one, uploaded it to the keyservers, and uploaded a new version of the debian-ports-archive-keyring package. It's the key that will start to be used in the next few days. The key is: pub 4096R/22261D71 2011-01-11 [expires: 2012-01-31] Key fingerprint = E44C FDE5 0EE9 031D E6D3 5ACC D9B9 37C6 2226 1D71 uid Debian Ports Archive Automatic Signing Key (2011) ftpmas...@debian-ports.org sub 4096R/DAE4D596 2011-01-11 [expires: 2012-01-31] It can be found as well on: http://archive.debian-ports.org/archive_2011.key Or attached to this mail. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net archive_2011.key Description: application/pgp-keys signature.asc Description: Digital signature
Re: I am planning to restart ppc64 ports project.
On Sat, Oct 02, 2010 at 12:12:00PM +0900, Hiroyuki Yamamoto wrote: Hi, Hi, I am planning to restart the ppc64 porting project using the debian-ports project in the near future. I want the ppc64 port to be joined to the official by the time debian will be released. How about this plan? From the debian-ports point of view, we are currently lacking space to add another port. Genesi has been kind enough to offer new hard-drives but they still have to be installed. In other words, it something possible, but not before a few weeks. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004155057.ga27...@hall.aurel32.net
Re: Builds disturbed by the usage of a 64bit kernel.
Charles Plessy a écrit : Dear all, Starting from the observation that a pre-release debian pacakge of root-system and the current xaralx (non-free) pacakge fail to build from source on G5 powerpc machines but not on G4, I started to get worried that that kind of failures would be more widespread. The core of the problem is that the configure scripts sometimes mistake the build system type to be powerpc64-unknown-linux-gnu instead of powerpc-unknown-linux-gnu. I am wondering similar things happen on sparc running a 32-bit userland with a 64-bits kernel, hence the crosspost. Have you tried to use linux32? This is how sparc build daemons are building packages when using a 64-bit kernel. -- .''`. 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]
Test version of the glibc built with gcc-4.0
Hi PowerPC users! I am currently trying to switch the compiler used to build the glibc to gcc 4.0 on all the architectures. PowerPC is one of the architectures still using gcc 3.4. gcc 3.4 is used to workaround some gcc 4.0 bugs, but it seems that now gcc 4.0 is working correctly on PowerPC. I am using a glibc built with it on my system for a week without any problem. However I may have miss some problems, and I am unable to test the 64-bit version of the glibc as my computer does not support it. I am therefore asking for some people to test it. I have put my packages on http://people.debian.org/~aurel32/glibc/powerpc/ . Please report me any problem if you find some. Thanks, Aurelien -- .''`. 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: rebuild for libhdate
Lior Kaplan a écrit : Hi, Can anyone help with triggering a rebuild for libhdate. It previously failed because of another package (fp-compiler), a problem which was solved a while ago. Built and uploaded for both powerpc and sparc. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux 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: Bug#326220: libc6 2.3.5 ldconfig segfaults on powerpc oldworld
Michael Schmitz a écrit : reassign 326220 apt Your system looks older than a testing from April 2005. libc6 version 2.2.5-11.8 is a libc6 from Woody, an Debian does not support direct Woody - Etch upgrade. So please reassign the bug to whatever seems appropriate. Not being able to upgrade from woody to current testing/unstable is what I'd consider a bug in its own right. It's seems you are not aware that Sarge is out and is now the stable version. Debian does not support the upgrade from stable (Woody) to stable + 2 (the future Etch). You have to upgrade to stable + 1 (Sarge) to first. So please upgrade to Sarge first. Besides, what's the proposed fix? etch ldconfig just doesn't work, so what piece am I missing? Update to Sarge first, and also to a Sarge kernel. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux 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]
