Bug#1070012: keyutils: testsuite wrongly assumes that user 0 always exists
Source: keyutils Version: 1.6.3-3 Severity: important Tags: patch upstream ftbfs X-Debbugs-Cc: debian-wb-team@lists.debian.org Usertags: unshare Dear maintainer, keyutils fails to build from source when built inside a container: | === /<>/tests/keyctl/newring/bad-args/test.out === | ./runtest.sh: line 13: [: 4096: unary operator expected | +++ CHECK MAXLEN DESC FAILS WITH EDQUOT | FAILED | FAILED | +++ CHECK OVERLONG DESC | +++ CHECK EMPTY KEYRING NAME | +++ CHECK BAD KEY ID | make[3]: *** [Makefile:41: run] Error 1 | make[3]: Leaving directory '/<>/tests' | make[2]: *** [Makefile:253: test] Error 2 | make[2]: Leaving directory '/<>' | dh_auto_test: error: make -j4 test PATH=/<>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LD_LIBRARY_PATH=/<> SKIPROOTREQ=yes SKIPINSTALLREQ=yes returned exit code 2 | make[1]: *** [debian/rules:25: override_dh_auto_test] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:10: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 The "unary operator expected" issue is because maxsquota is undefined. Indeed it is defined by looking at /proc/key-users for user 0 (root), however this user does necessary not exists in a container. In addition as the testsuite is run as non-root (contrary to what upstream recommends), I believe the returned values are incorrect. At least on my system they are quite different between root and normal users. This simple one-liner fixes the issue, and should still work fine with the testsuite run as root: --- keyutils-1.6.3.orig/tests/toolbox.inc.sh +++ keyutils-1.6.3/tests/toolbox.inc.sh @@ -45,7 +45,7 @@ fi maxcall=$fullpage -maxsquota=`grep '^ *0': /proc/key-users | sed s@.*/@@` +maxsquota=`grep "^ *$UID": /proc/key-users | sed s@.*/@@` key_gc_delay_file="/proc/sys/kernel/keys/gc_delay" if [ -f $key_gc_delay_file ]; then Regards Aurelien
Re: emboss and python-biopython stuck in Building state
Hi, On 2024-04-23 21:38, Étienne Mollier wrote: > Hi Wanna Build Team, > > Just in case this flown below the radar in the past week, you > might want to be aware of the below packages stuck in Building > state on various arm-arm-* buildd: > > Étienne Mollier, on 2024-04-23: > > Andrius Merkys, on 2024-04-23: > > > Five days ago I have uploaded emboss and python-biopython. Both are stuck > > > in > > > "Building" state since then, emboss on arm64 and python-biopython on > > > armel. > > > This is strange to me, as normally long builds timeout after periods of > > > inactivity (no output). I have successfully rebuilt emboss on amdahl.d.o > > > in > > > a couple of minutes. > > > > > > Has anybody experienced similar issues lately? > > > > r-cran-hunspell looks also affected on armel: > > > > r-cran-hunspell (6d 7h 31m, arm-arm-01) > > python-biopython (6d 5h 16m, arm-arm-03) > > > > also pyresample on arm64: > > > > emboss (6d 7h 49m, arm-arm-01) > > pyresample (6d 7h 9m, arm-arm-04) > > > > and on armhf: > > > > pyresample (6d 7h 10m, arm-arm-01) > > > > none of which look to need that long to build. > > > > It could be that something went off with some Arm (ltd) runners. There are firewall issues on those buildds, the packages have been built, but they can't be marked as such nor uploaded. Anyway they have been given-back and rebuilt. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: Coordinate response to xz-utils (DSA 5649-1)
Hi, On 2024-03-29 23:59, Ansgar wrote: > Hi, > > how should we react to the compromised xz-utils upload? > > Ubuntu is reverting their amd64 binaries to pre-Feb 25 and rebuilding > stuff. > > On Debian side AFAIU currently amd64 buildds are paused and pending > reinstall (plus rotation of key material, both OpenPGP and SSH). All the 8 existing VMs at csail, conova, grnet and ubc have been shutdown, and their GPG key have been removed on the dak side. Their SSH key is managed by puppet, so are still enabled at this time, but their restricted command has been disabled as they are not allowed to build any architecture. 2 new VMs have been created, x86-grnet-03 and x86-grnet-04. Currently they only build buster, bullseye and bookworm and the associated security suites. I didn't enable backports, as it probably needs to be audited for the builds after Feb 25, like it was done for the security suites using reproducible builds. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: unexpected riscv64 build success on buildd / NaN payload
Hi, On 2024-02-27 10:59, René Engelhard wrote: > Is rv-osuosl-05 hardware which supports this? (db.debian.org/machines.cgi > doesn't really shed any light here; they all say "Hifive Unmatched"). > > Just running a build on my machine again, too. All riscv64 buildds and porterbox, including rv-osuosl-05, are using Hifive Unmatched boards as the LDAP says: https://www.sifive.com/boards/hifive-unmatched Nothing has changed recently on the hardware side. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: logs.php?pkg=... is not displaying build log data
Hi, On 2024-01-03 15:29, James McCoy wrote: > Hi, > > When trying to view historical build logs, I just see a "No build logs > found for () in the database" message. For example, > https://buildd.debian.org/status/logs.php?pkg=vim > > This was working in the past couple weeks, so something seems to have > changed recently. This is a side effect of the arc architecture removal from wanna-build, I forgot to remove one entry. That should be fixed now, sorry about that. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: gcc-mingw-w64 FTBFS on s390x due to diskspace(?) issues
Hi, On 2024-01-01 19:40, Paul Gevers wrote: > Hi, > > On 2023-09-27 20:49, Aurelien Jarno wrote: > > On 2023-09-25 17:08, Adrian Bunk wrote: > > > https://buildd.debian.org/status/logs.php?pkg=gcc-mingw-w64=26.1=s390x=sid > > > > > > The way the logs are cut might indicate that zani has 37 GB > > > diskspace that are exhausted? > > > > No there is no disk space issue on zani. The build partition is > > empty between builds, and the partition holding /home still has > > space available. > > > > I've failed the package for now, please verify whether this is really > > > a diskspace issue and then either fix it on the buildd or submit an > > > RC bug against the package. > > > > It's not clear what happens. sbuild exits successfully. However the > > resulting changes file is also not signed, and thus the upload > > fails, that's why the package is given back. > Did anybody look into this further? gcc-mingw-w64 is blocked on this for > months now (bug #1054336). Is it maybe worth a retry? I have just given it back, let's see what happens. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: Debian buildd environment
Hi, On 2023-10-02 22:08, Ileana Dumitrescu wrote: > Hello, > > I am an uploader for the package giac and have noticed an arm64 build on the > Debian buildd status page was failing [1]. However, I have been able to > build successfully with arm64 using pbuilder locally. In the last upload to > unstable, I disabled the tests on arm64 since I was unable to reproduce the > failing test locally. > > I was hoping to test locally using the same or a similar build process that > the Debian buildd process uses to try to reproduce the failing test. I think > my pbuilder chroot may be set up differently. I have looked over the buildd > log, but I don't think I have enough information to reproduce the test > failure. Would someone be able to provide a list of initial commands to set > up the build environment? The build daemons use sbuild through schroot and not pbuilder. You can create a sid chroot similar to the one on the build daemons using sbuild-createchroot. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: gcc-mingw-w64 FTBFS on s390x due to diskspace(?) issues
Hi, On 2023-09-25 17:08, Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=gcc-mingw-w64=26.1=s390x=sid > > The way the logs are cut might indicate that zani has 37 GB diskspace > that are exhausted? No there is no disk space issue on zani. The build partition is empty between builds, and the partition holding /home still has space available. > I've failed the package for now, please verify whether this is really a > diskspace issue and then either fix it on the buildd or submit an RC bug > against the package. It's not clear what happens. sbuild exits successfully. However the resulting changes file is also not signed, and thus the upload fails, that's why the package is given back. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Bug#1043114: Please remove mipsel port from testing and sid
Hi Ansgar, On 2023-08-27 08:32, Ansgar wrote: > Hi, > > On Sun, 2023-08-06 at 16:50 +0800, YunQiang Su wrote: > > Since the Y2038 problem, 2G user space memory limit, > > and some lack of manpower, It's time for us to drop mipsel support > > from the list of official release architectures. > > > > Note: please keep mips64el for now. > > Please stop building packages for mipsel for unstable/experimental so > we can proceed here. That should be done now. Now new packages will be built for unstable or experimental, and I think I have killed all the running ones. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: incoming.d.o is *very* slow or even times out
Hi, incoming.d.o is not really the area of the wb-team, but let me answer you with my DSA hat. On 2023-08-13 16:41, Adrian Bunk wrote: > Hi, > > a problem that has already happend in recent days but is exceptionally > frequent today are buildd timeouts from incoming.d.o, e.g.[1] > Could not connect to incoming.debian.org:443 (2603:400a::bb8::801f:3e), > connection timed out Could not connect to incoming.debian.org:443 > (128.31.0.62), connection timed out > > I can reproduce timeouts and very slow responses from my desktop: > > $ date; lynx -dump https://incoming.debian.org/ >/dev/null; date > Sun 13 Aug 16:31:17 EEST 2023 > Sun 13 Aug 16:32:25 EEST 2023 > $ date; lynx -dump http://incoming.debian.org/ >/dev/null; date > Sun 13 Aug 16:35:29 EEST 2023 > Sun 13 Aug 16:35:49 EEST 2023 > $ date; lynx -dump http://incoming.debian.org/ >/dev/null; date > Sun 13 Aug 16:36:26 EEST 2023 > > Looking up incoming.debian.org > Making HTTP connection to incoming.debian.org > Alert!: Unable to connect to remote host. > > lynx: Can't access startfile http://incoming.debian.org/ > Sun 13 Aug 16:38:37 EEST 2023 > $ static.d.o is currently DOSed by IPs from DigitalOcean. We are trying to blacklist them as fast are new ones are used, but so far the load on the mirrors doesn't go down. > A side-effect of this issue is that dep-wait might not ensure a recent > enough version is actually used during the build. Should we temporarily disable incoming.d.o on the buildds? Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: tzdata >= 2023c-9 on buildds
Hi, On 2023-08-12 11:58, Sebastiaan Couwenberg wrote: > tzdata (2023c-8) is installed on the buildds which contains breaking changes > that were reverted in 2023c-9 & 2023c-10. tzdata (2023c-10) is installed > state for over two days, but is not yet used in the buildd chroots. > > How do we get tzdata upgraded in the buildd chroots? The chroots are regenerated on Wednesdays and Sundays at 22:13 UTC. So it's just a few hours from now. > The postgis builds in experimental need to be given back once tzdata is > upgrade to fix the FTBFS due to test failures. I have seen that you have specified a dependency on tzdata (>= 2023c-9) on the latest upload and that it has been successful. You can probably drop that in the next upload. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: trixie is not being built
Hi, On 2023-07-01 13:03, Adrian Bunk wrote: > https://buildd.debian.org/status/package.php?p=r-cran-sf=trixie > https://buildd.debian.org/status/package.php?p=r-cran-terra=trixie > https://buildd.debian.org/status/package.php?p=r-cran-rgdal=trixie > > These are the first binNMUs in trixie, but some configuration for that > seems to be missing. > Hmm that should be fixed. At least one buildd per architecture has been configured at the bookworm release time, but the buildd process needed a restart. that should be fixed now. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Sort "Build-Attempted" by language and priority
Hi, On 2023-06-26 04:35, Jeffrey Walton wrote: > Hi Everyone, > > I'm a fan of PPC and PPC64. I'm interested in helping get some of the > packages to build from > https://buildd.debian.org/status/architecture.php?a=ppc64=sid. If you interest is PPC and PPC64, I would suggest to contact the PowerPC porters on debian-powe...@lists.debian.org. This is were issues specific to the ports are discussed. > My area of expertise is C and C++. > > I'd like to sort the packages by (1) by programming language and then > (2) by Debian priority. Here, priority is the importance that Debian > assigns to the package. > > How do I do that? Unfortunately buildd.debian.org does not provide such a view. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Please create chroots for bookworm-backports
Hi, On 2023-06-21 21:06, Alexander Wirt wrote: > Hi, > > to support bookworm backports we need the correspondending chroots. Could > someone please take > care about it? wanna-build and the buildds already support bookworm-backports since the release of bullseye. So there is nothing to be done on the wb-team side. Sorry for not seeing the mail earlier. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: testing security uploads to bookworm-security
Hi, On 2023-03-10 23:11, Salvatore Bonaccorso wrote: > Hi Aurelien, > > On Fri, Mar 10, 2023 at 05:59:08PM +0100, Aurelien Jarno wrote: > > Hi, > > > > On 2023-03-10 16:55, Salvatore Bonaccorso wrote: > > > Hi, > > > > > > On Thu, Mar 09, 2023 at 11:35:46AM +0100, Salvatore Bonaccorso wrote: > > > > Hi Ansgar, > > > > > > > > [Adding debian-wb-team@lists.debian.org list] > > > > > > > > On Thu, Mar 09, 2023 at 01:16:21AM +0100, Ansgar wrote: > > > > > Hi, > > > > > > > > > > Salvatore Bonaccorso writes: > > > > > > python-cryptography/38.0.4-3~deb12u1 was uploaded to security-master > > > > > > as source only upload, the upload got rejected with: > > > > > > > > > > > > | Source-only uploads to NEW are not allowed. > > > > > > > > > > There were two issues: > > > > > > > > > > - The override sync from ftp-master to security-master was not > > > > > handling > > > > >the fancy new `-security` addition to suite names. > > > > > > > > > > - `bookworm-security` was still configured to not accept any uploads > > > > >(as was done when the suite was created to prevent accidental > > > > >uploads). > > > > > > > > > > Both issues are now solved and the python-cryptography source upload > > > > > was > > > > > processed successfully. > > > > > > > > Thank you for addressing both. I can confirm we have now partially > > > > builds on the embargoed queue. > > > > > > FTR, Steve as well uploaded src:shim to test the code signing > > > involving path, and looks fine AFAICS. To Steve's request we will > > > though not install those packages, so reject them from the embargoed > > > queues. > > > > > > > From what I see there are the mipsel and mips64el builds missing and > > > > according to a quick chat with Adam on IRC it is not that they are yet > > > > just missing because of buildd overloaded. Actually bookworm-security > > > > seems not yet configured to be handled by mipsel and mips64el buildds. > > > > > > > > Wanna-build team, can you have a look and check the mipsel, mips64el > > > > status (and actually if we are setup complete as well on buildd setup > > > > for bookworm-security)? > > > > Sorry to not have looked that earlier. Indeed none of the mips*el > > buildds were configured to build bookworm-security. I have enabled it on > > two buildds for now, but this has to be done for all buildds. We also > > need to check that it is the case for the other architectures. I have no > > time now, I'll keep you updated once done, but in the meantime you > > should be able to do tests with more packages. > > > > > This one would still need to be checked, looping in as well Debian > > > Build Daemon team alias. Buildd admins, chan you have a look? I still > > > would like to install for real python-crytpography, though we have > > > missed the window to do it earlier than the -3 upload migrated to > > > testing. It still should work I think. Otherwise we will do then > > > another test with another package. > > > > python-cryptography has now been uploaded on both mipsel and mips64el. > > Thanks, confirmed the two bulds arrived as well. > > Paul and release team, here is a summary: so I think we can confirm > that the bookworm-security side of things works now (modulo the above > checking by Aurelien). We did: I have checked and updated the buildds config. We now have all bookworm suites enabled consistently across all the buildds. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: testing security uploads to bookworm-security
Hi, On 2023-03-10 16:55, Salvatore Bonaccorso wrote: > Hi, > > On Thu, Mar 09, 2023 at 11:35:46AM +0100, Salvatore Bonaccorso wrote: > > Hi Ansgar, > > > > [Adding debian-wb-team@lists.debian.org list] > > > > On Thu, Mar 09, 2023 at 01:16:21AM +0100, Ansgar wrote: > > > Hi, > > > > > > Salvatore Bonaccorso writes: > > > > python-cryptography/38.0.4-3~deb12u1 was uploaded to security-master > > > > as source only upload, the upload got rejected with: > > > > > > > > | Source-only uploads to NEW are not allowed. > > > > > > There were two issues: > > > > > > - The override sync from ftp-master to security-master was not handling > > >the fancy new `-security` addition to suite names. > > > > > > - `bookworm-security` was still configured to not accept any uploads > > >(as was done when the suite was created to prevent accidental > > >uploads). > > > > > > Both issues are now solved and the python-cryptography source upload was > > > processed successfully. > > > > Thank you for addressing both. I can confirm we have now partially > > builds on the embargoed queue. > > FTR, Steve as well uploaded src:shim to test the code signing > involving path, and looks fine AFAICS. To Steve's request we will > though not install those packages, so reject them from the embargoed > queues. > > > From what I see there are the mipsel and mips64el builds missing and > > according to a quick chat with Adam on IRC it is not that they are yet > > just missing because of buildd overloaded. Actually bookworm-security > > seems not yet configured to be handled by mipsel and mips64el buildds. > > > > Wanna-build team, can you have a look and check the mipsel, mips64el > > status (and actually if we are setup complete as well on buildd setup > > for bookworm-security)? Sorry to not have looked that earlier. Indeed none of the mips*el buildds were configured to build bookworm-security. I have enabled it on two buildds for now, but this has to be done for all buildds. We also need to check that it is the case for the other architectures. I have no time now, I'll keep you updated once done, but in the meantime you should be able to do tests with more packages. > This one would still need to be checked, looping in as well Debian > Build Daemon team alias. Buildd admins, chan you have a look? I still > would like to install for real python-crytpography, though we have > missed the window to do it earlier than the -3 upload migrated to > testing. It still should work I think. Otherwise we will do then > another test with another package. python-cryptography has now been uploaded on both mipsel and mips64el. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi Guillem, On 2022-11-13 11:04, Aurelien Jarno wrote: > Hi, > > On 2022-11-13 02:00, Guillem Jover wrote: > > Hi! > > > > On Sun, 2022-11-13 at 00:17:36 +0100, Aurelien Jarno wrote: > > > On 2022-11-12 22:28, Guillem Jover wrote: > > > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo > > > > wrote: > > > > > Package: dpkg > > > > > Version: 1.21.9 > > > > > Severity: normal > > > > > X-Debbugs-Cc: m...@debian.org, debian-wb-team@lists.debian.org > > > > > > > > > After some investigation by aurel32 and myself, this was traced back > > > > > to the > > > > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > > > > calculation of > > > > > the memory that can be used, to determine the number of threads to > > > > > use, was > > > > > changed from half of the physical mem to be based on the memory > > > > > available. > > > > > > > > Ah, thanks for tracking this down! I think the problem is the usual > > > > "available" memory does not really mean what people think it means. :/ > > > > And I unfortunately missed that (even thought I was aware of it) when > > > > reviewing the patch. > > > > > > > > Attached is something I just quickly prepared, which I'll clean up and > > > > merge for the upcoming 1.21.10. Let me know if that solves the issue > > > > for you, otherwise we'd need to look for further changes. > > > > > > Thanks for providing a patch. I have not been able yet to try it for the > > > case where we have found the issue, i.e. building linux. However I have > > > tried to setup a similar environment: > > > > > - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and > > > very few > > > things running on it. > > > - I filled the tmpfs with 4 GB of random data, which means that after > > > moving the content of the tmpfs to the swap, 4 GB could still be used > > > without issue. > > > - I ended up with the following /proc/meminfo: > > > MemTotal:3951508 kB > > > MemFree: 130976 kB > > > MemAvailable: 10584 kB > > > Buffers:2448 kB > > > Cached: 3694676 kB > > > SwapCached:12936 kB > > > Active: 3111920 kB > > > Inactive: 610376 kB > > > Active(anon):3102668 kB > > > Inactive(anon): 606952 kB > > > Active(file): 9252 kB > > > Inactive(file): 3424 kB > > > Unevictable: 0 kB > > > Mlocked: 0 kB > > > SwapTotal: 4194300 kB > > > SwapFree:3777400 kB > > > Zswap: 0 kB > > > Zswapped: 0 kB > > > Dirty: 0 kB > > > Writeback: 0 kB > > > AnonPages: 12960 kB > > > Mapped: 6700 kB > > > Shmem: 3684416 kB > > > KReclaimable: 27616 kB > > > Slab: 54652 kB > > > SReclaimable: 27616 kB > > > SUnreclaim:27036 kB > > > KernelStack:2496 kB > > > PageTables: 1516 kB > > > NFS_Unstable: 0 kB > > > Bounce:0 kB > > > WritebackTmp: 0 kB > > > CommitLimit: 6170052 kB > > > Committed_AS:4212940 kB > > > VmallocTotal: 34359738367 kB > > > VmallocUsed: 16116 kB > > > VmallocChunk: 0 kB > > > Percpu: 2288 kB > > > HardwareCorrupted: 0 kB > > > AnonHugePages: 0 kB > > > ShmemHugePages:0 kB > > > ShmemPmdMapped:0 kB > > > FileHugePages: 0 kB > > > FilePmdMapped: 0 kB > > > HugePages_Total: 0 > > > HugePages_Free:0 > > > HugePages_Rsvd:0 > > > HugePages_Surp:0 > > > Hugepagesize: 2048 kB > > > Hugetlb: 0 kB > > > DirectMap4k: 110452 kB > > > DirectMap2M: 5132288 kB > > > DirectMap1G: 5242880 kB > > > > > With the current version of dpkg, it means it consider 10584 kB are > > > available > > > (not however that there is 130976 kB of unused physical RAM). With your > > > patch, > > > it's a bit better, as it would be 123408 kB. Still far less that one the > > > VM is > > > capable of. > > > > Err sorry, the patch was computing the used memory and not the truly > > available one! The updated patch should do better. :) > > Thanks for the updated patch. Computing the available memory manually > from the above values sounds like it should work, so I'll give it a try. I have run a build of the linux package on a buildd with your patch, and I confirm it fixes the issue. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On 2022-11-13 02:00, Guillem Jover wrote: > Hi! > > On Sun, 2022-11-13 at 00:17:36 +0100, Aurelien Jarno wrote: > > On 2022-11-12 22:28, Guillem Jover wrote: > > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo wrote: > > > > Package: dpkg > > > > Version: 1.21.9 > > > > Severity: normal > > > > X-Debbugs-Cc: m...@debian.org, debian-wb-team@lists.debian.org > > > > > > > After some investigation by aurel32 and myself, this was traced back to > > > > the > > > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > > > calculation of > > > > the memory that can be used, to determine the number of threads to use, > > > > was > > > > changed from half of the physical mem to be based on the memory > > > > available. > > > > > > Ah, thanks for tracking this down! I think the problem is the usual > > > "available" memory does not really mean what people think it means. :/ > > > And I unfortunately missed that (even thought I was aware of it) when > > > reviewing the patch. > > > > > > Attached is something I just quickly prepared, which I'll clean up and > > > merge for the upcoming 1.21.10. Let me know if that solves the issue > > > for you, otherwise we'd need to look for further changes. > > > > Thanks for providing a patch. I have not been able yet to try it for the > > case where we have found the issue, i.e. building linux. However I have > > tried to setup a similar environment: > > > - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and very > > few > > things running on it. > > - I filled the tmpfs with 4 GB of random data, which means that after > > moving the content of the tmpfs to the swap, 4 GB could still be used > > without issue. > > - I ended up with the following /proc/meminfo: > > MemTotal:3951508 kB > > MemFree: 130976 kB > > MemAvailable: 10584 kB > > Buffers:2448 kB > > Cached: 3694676 kB > > SwapCached:12936 kB > > Active: 3111920 kB > > Inactive: 610376 kB > > Active(anon):3102668 kB > > Inactive(anon): 606952 kB > > Active(file): 9252 kB > > Inactive(file): 3424 kB > > Unevictable: 0 kB > > Mlocked: 0 kB > > SwapTotal: 4194300 kB > > SwapFree:3777400 kB > > Zswap: 0 kB > > Zswapped: 0 kB > > Dirty: 0 kB > > Writeback: 0 kB > > AnonPages: 12960 kB > > Mapped: 6700 kB > > Shmem: 3684416 kB > > KReclaimable: 27616 kB > > Slab: 54652 kB > > SReclaimable: 27616 kB > > SUnreclaim:27036 kB > > KernelStack:2496 kB > > PageTables: 1516 kB > > NFS_Unstable: 0 kB > > Bounce:0 kB > > WritebackTmp: 0 kB > > CommitLimit: 6170052 kB > > Committed_AS:4212940 kB > > VmallocTotal: 34359738367 kB > > VmallocUsed: 16116 kB > > VmallocChunk: 0 kB > > Percpu: 2288 kB > > HardwareCorrupted: 0 kB > > AnonHugePages: 0 kB > > ShmemHugePages:0 kB > > ShmemPmdMapped:0 kB > > FileHugePages: 0 kB > > FilePmdMapped: 0 kB > > HugePages_Total: 0 > > HugePages_Free:0 > > HugePages_Rsvd:0 > > HugePages_Surp:0 > > Hugepagesize: 2048 kB > > Hugetlb: 0 kB > > DirectMap4k: 110452 kB > > DirectMap2M: 5132288 kB > > DirectMap1G: 5242880 kB > > > With the current version of dpkg, it means it consider 10584 kB are > > available > > (not however that there is 130976 kB of unused physical RAM). With your > > patch, > > it's a bit better, as it would be 123408 kB. Still far less that one the VM > > is > > capable of. > > Err sorry, the patch was computing the used memory and not the truly > available one! The updated patch should do better. :) Thanks for the updated patch. Computing the available memory manually from the above values sounds like it should work, so I'll give it a try. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On 2022-11-12 22:28, Guillem Jover wrote: > Hi! > > On Fri, 2022-11-11 at 19:15:59 +0100, Manuel A. Fernandez Montecelo wrote: > > Package: dpkg > > Version: 1.21.9 > > Severity: normal > > X-Debbugs-Cc: m...@debian.org, debian-wb-team@lists.debian.org > > > After some investigation by aurel32 and myself, this was traced back to the > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > calculation of > > the memory that can be used, to determine the number of threads to use, was > > changed from half of the physical mem to be based on the memory available. > > Ah, thanks for tracking this down! I think the problem is the usual > "available" memory does not really mean what people think it means. :/ > And I unfortunately missed that (even thought I was aware of it) when > reviewing the patch. > > Attached is something I just quickly prepared, which I'll clean up and > merge for the upcoming 1.21.10. Let me know if that solves the issue > for you, otherwise we'd need to look for further changes. Thanks for providing a patch. I have not been able yet to try it for the case where we have found the issue, i.e. building linux. However I have tried to setup a similar environment: - I took a just booted VM with 4 GB RAM, 4 GB swap and 4 GB tmpfs, and very few things running on it. - I filled the tmpfs with 4 GB of random data, which means that after moving the content of the tmpfs to the swap, 4 GB could still be used without issue. - I ended up with the following /proc/meminfo: MemTotal:3951508 kB MemFree: 130976 kB MemAvailable: 10584 kB Buffers:2448 kB Cached: 3694676 kB SwapCached:12936 kB Active: 3111920 kB Inactive: 610376 kB Active(anon):3102668 kB Inactive(anon): 606952 kB Active(file): 9252 kB Inactive(file): 3424 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 4194300 kB SwapFree:3777400 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 12960 kB Mapped: 6700 kB Shmem: 3684416 kB KReclaimable: 27616 kB Slab: 54652 kB SReclaimable: 27616 kB SUnreclaim:27036 kB KernelStack:2496 kB PageTables: 1516 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit: 6170052 kB Committed_AS:4212940 kB VmallocTotal: 34359738367 kB VmallocUsed: 16116 kB VmallocChunk: 0 kB Percpu: 2288 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 110452 kB DirectMap2M: 5132288 kB DirectMap1G: 5242880 kB With the current version of dpkg, it means it consider 10584 kB are available (not however that there is 130976 kB of unused physical RAM). With your patch, it's a bit better, as it would be 123408 kB. Still far less that one the VM is capable of. For our use case, I wonder if the memory contained in Shmem (which in that case maps to the memory used for the tmpfs) should be considered as available, as it could be moved to the swap easily. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#1023870: dpkg: Problems in buildds due to slow compression
Hi, On 2022-11-12 23:04, Adrian Bunk wrote: > On Fri, Nov 11, 2022 at 07:15:59PM +0100, Manuel A. Fernandez Montecelo wrote: > >... > > The origins of this bug report are because there are sometimes problems > > building > > packages in buildds, the compression phase is very slow and sometimes the > > build > > is aborted due to inactivity: > > > > E: Build killed with signal TERM after 300 minutes of inactivity [1] > > > > After some investigation by aurel32 and myself, this was traced back to the > > commit f8d254943051e085040367d689048c00f31514c3 [2], in which the > > calculation of > > the memory that can be used, to determine the number of threads to use, was > > changed from half of the physical mem to be based on the memory available. > > > > For example in buildds with not-so-large amount of RAM, using part of it for > > tempfs (which is how buildds are set-up), the reported available memory > > maybe is > > not very large. For example it could be MemAvailable=2GB for 16GB of > > physical > > RAM in the machine. In the dpkg code, for the purposes of the calculation > > of > > how much memory can be used, the result appears to be to be half of the > > MemAvailable [3], so only 1GB. > > > > According to the tables in xz man page, for compression the algorithm can > > use > > 674MB. So as a result, dpkg-deb uses single-threaded compression, even if > > it > > could easily use 2-3 threads and still use only RAM; or use the full number > > of > > threads in the machine (e.g. 4 or 8) even if it means swapping out some of > > the > > content of tempfs -- which is not a problem in most cases for buildds, > > specially > > if using fast disks. > > I don't see src:linux changing the compression from the default level 6, > so that should be < 100 MB per core. > > I am wondering whether these buildds are for some reason running into > the 128 MiB default at the bottom of the commit when the reading from > /proc fails for some reason. No the problem they have is that the build is done in a 80GB tmpfs, with 100GB swap. This works because the kernel is slowly moving things to swap when there is no RAM available. However for packages needing more build space than the physical RAM, the kernel seems to start moving data to the swap when MemAvailable is in the order of 100MB to 200MB. dpkg therefore considers there are no memory available, that said after moving a bit more data from the tmpfs to the swap, plenty of memory would be available for dpkg to do the parallel compression. To make a comparison, if GCC need 4GB of RAM, it just allocate them, and the kernel takes care of moving things to swap. In the worst case the OOM killer just kill GCC. On the other hand dpkg look how much memory available without moving things to the swap, and only uses that. > > As a result of all this, it is taking upwards of 600 mins of CPU time to > > compress recent linux-image-*-dbg packages in the buildds of riscv64 > > architecture at the moment, so when using 2 threads of less, it's > > guaranteed to > > be aborted. > > > > But this also affects other arches and other packages in other ways, at > > least by > > making the build needlessly slow in many cases. > > There is an even more worrysome issue, from xz(1): > If the specified memory usage limit is exceeded when decompressing, xz > will display an error and decompressing the file will fail. If the > limit is exceeded when compressing, xz will try to scale the settings > down so that the limit is no longer exceeded > > Different compression of packages in the archive based on what is in > /proc on the buildd is not desirable. A *very* quick look at the xz source seems to show it looks at the physical memory here, so we're good. > > It's not very clear what could be the solution for this, as the default > > could be > > OK for desktops and many machines in which there's plenty of available RAM, > > but > > this is not the case of all of our buildds. It might not be possible to > > detect > > which is the best from within dpkg. > >... > > Sebastian, was there any real-world problem motivating your commit, > or did it just sound more correct? > > With default settings there should be < 100 MB/core RAM usage, > and even with "xz -9"[1] RAM usage should be < 700 MB/core. I think the use case there, is for the desktop. It's preferable to use 2 threads only on a 4 core processor than sending Firefox to the swap. That said that heuristics is not necessary the best for the build daemon. > These numbers shouldn't be a problem on buildds that successfully > manage to build packages large enough that multithreaded compression > is even possible. Yep, we always have at least 1GB per core on all our buildds. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: gcc-12/mips64el FTBFS during sbuild chown
Hi, On 2022-10-28 20:04, Aurelien Jarno wrote: > Hi, > > On 2022-10-28 08:59, Adrian Bunk wrote: > > On Thu, Oct 27, 2022 at 07:50:17PM +0800, YunQiang Su wrote: > > > YunQiang Su 于2022年10月26日周三 01:56写道： > > > > > > > > Adrian Bunk 于2022年10月25日周二 21:50写道： > > > > > > > > > > https://buildd.debian.org/status/logs.php?pkg=gcc-12=mips64el > > > > > > > > > > ... > > > > > Finished > > > > > > > > > > > > > > > I: Built successfully > > > > > chmod: cannot access > > > > > '/<>/build/mips64el-linux-gnuabi64/libstdc++-v3/testsuite/normal3/filesystem-test.FSLTZS-last_write_time': > > > > > Value too large for defined data type > > > > > chmod: cannot access > > > > > '/<>/build/mips64el-linux-gnuabi64/libstdc++-v3/testsuite/normal2/filesystem-test.5zDnmX-last_write_time': > > > > > Value too large for defined data type > > > > > > I cannot reproduce this problem on my local machines. > > > Can you help to try to reproduce this problem on buildd nodes? > > >... > > > > Not from me, if I had a way to reproduce I would have debugged further > > from that. > > I have been able to reproduce by building gcc-12 on the eller.d.o > porterbox. It can be reduced to this simple test: > > (sid_mips64el-dchroot)aurel32@eller:~$ touch -d 20390101 t > (sid_mips64el-dchroot)aurel32@eller:~$ chmod +x t > chmod: cannot access 't': Value too large for defined data type > (sid_mips64el-dchroot)aurel32@eller:~$ > > It seems related to the y2038 support in either coreutils or glibc. This is a glibc issue introduced in 2.35, that has been triggered by the new coreutils version. I have opened #1022991 to track the issue. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: gcc-12/mips64el FTBFS during sbuild chown
Hi, On 2022-10-28 08:59, Adrian Bunk wrote: > On Thu, Oct 27, 2022 at 07:50:17PM +0800, YunQiang Su wrote: > > YunQiang Su 于2022年10月26日周三 01:56写道： > > > > > > Adrian Bunk 于2022年10月25日周二 21:50写道： > > > > > > > > https://buildd.debian.org/status/logs.php?pkg=gcc-12=mips64el > > > > > > > > ... > > > > Finished > > > > > > > > > > > > I: Built successfully > > > > chmod: cannot access > > > > '/<>/build/mips64el-linux-gnuabi64/libstdc++-v3/testsuite/normal3/filesystem-test.FSLTZS-last_write_time': > > > > Value too large for defined data type > > > > chmod: cannot access > > > > '/<>/build/mips64el-linux-gnuabi64/libstdc++-v3/testsuite/normal2/filesystem-test.5zDnmX-last_write_time': > > > > Value too large for defined data type > > > > I cannot reproduce this problem on my local machines. > > Can you help to try to reproduce this problem on buildd nodes? > >... > > Not from me, if I had a way to reproduce I would have debugged further > from that. I have been able to reproduce by building gcc-12 on the eller.d.o porterbox. It can be reduced to this simple test: (sid_mips64el-dchroot)aurel32@eller:~$ touch -d 20390101 t (sid_mips64el-dchroot)aurel32@eller:~$ chmod +x t chmod: cannot access 't': Value too large for defined data type (sid_mips64el-dchroot)aurel32@eller:~$ It seems related to the y2038 support in either coreutils or glibc. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Extend build time for package
Hi, On 2022-10-13 16:25, Scott Talbert wrote: > On Thu, 13 Oct 2022, Aurelien Jarno wrote: > > > Hi, > > > > On 2022-10-12 11:34, Scott Talbert wrote: > > > Hi, > > > > > > I sent this to ar...@buildd.debian.org, but received a bounce message, so > > > sending it here too. > > > > > > Is it possible to extend a package's build timeout? I'm trying to build > > > haskell-what4 on armhf and it is hitting the 150 minute timeout. The > > > particular > > > file that it is compiling when timing out takes a VERY LONG TIME to > > > compile. > > > > Do you have an explanation why this package didn't hit the 150 minutes > > timeout on armel, on the exact same buildd? armel is supposed to be > > slower. > > > > So for now I given back the package to really see if this is an issue. > > No idea. :( Probably something to do with different performance of the > compiler (ghc) on armhf vs armel? > > In any event, it looks like the giveback build succeeded, so I guess we're > OK. For future reference, is the 150 minutes timeout adjustable? Technically it is adjustable, but we don't want to have to handle a per package list of timeout, so in practice it's not. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Extend build time for package
Hi, On 2022-10-12 11:34, Scott Talbert wrote: > Hi, > > I sent this to ar...@buildd.debian.org, but received a bounce message, so > sending it here too. > > Is it possible to extend a package's build timeout? I'm trying to build > haskell-what4 on armhf and it is hitting the 150 minute timeout. The > particular > file that it is compiling when timing out takes a VERY LONG TIME to compile. Do you have an explanation why this package didn't hit the 150 minutes timeout on armel, on the exact same buildd? armel is supposed to be slower. So for now I given back the package to really see if this is an issue. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[p-a-s/sid] remove libcap-ng
[Debian bug #1013140] --- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 493291f..aa69ebe 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -57,6 +57,5 @@ fdflush: alpha amd64 i386 # amd64/i3 # linux specific %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 -- 2.20.1
Re: Bug#985556: flatpak/1.2.5-0+deb10u4 FTBFS on i386
On 2021-03-21 12:15, Philipp Kern wrote: > On 20.03.21 13:32, Simon McVittie wrote: > > On Sat, 20 Mar 2021 at 09:16:45 +0100, Salvatore Bonaccorso wrote: > >> On Sat, Mar 20, 2021 at 12:12:39AM +, Simon McVittie wrote: > >>> Could x86-conova-01.debian.org be an IPv6-only buildd? > > ... > >>> Or, if not that, could it be the case that this buildd is firewalled or > >>> otherwise restricted such that connections from the build to a test > >>> server listening on an arbitrary high port number on the loopback > >>> interface will fail? > >> > >> JFTR, this might indeed be the case. I gave it back a couple of times > >> and building on x86-conova-01.debian.org failed. The last one got > >> picked on buildd-x86-grnet-01 which now seems to have built. > > > > If we now have buildds that are more restrictive or limited than > > the buildds that were used at the time stable was frozen, then > > it would probably be good if it was possible to arrange for only > > testing/unstable/experimental packages to be built on those buildds, > > with stable updates built on buildds that more closely resemble the ones > > they were originally tested on - otherwise we'll get random build > > regressions. > > The buildd is IPv6-only. I'm somewhat torn given that we have enough > buildd coverage that a give-back would likely solve the problem. At the > same time you can't avoid a particular buildd either. So I concur, as > much as it hurts me in this day and age, that we should at least > temporarily disable stable/oldstable builds on the IPv6-only buildds. > > I have commented out stretch and buster (and their corresponding > security and backports suites) on x86-conova-01 for now. I'll definitely > leave bullseye on, though. Not sure if there's another IPv6-only buildd > lingering around. Thanks for doing that change that fully makes sense. I have done the same change on arm-conova-03 which is also IPv6-only. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[p-a-s/sid] Drop prctl, requested by Adrian Bunk
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 68c1b4e..493291f 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -23,7 +23,6 @@ fdflush: alpha amd64 i386 # amd64/i386/alpha specific %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] -%prctl: hppa ia64 alpha powerpc # ANAIS based on syscall availability # xorg stuff %xf86-input-multitouch: !s390x -- 2.20.1
[p-a-s/sid] drop yforth again
Commit 038c775d08c6 ("drop yforth") removed yforth from P-a-S, but this
has been wrongly reverted by commit fcdb c12049a6 ("Revert "vpb-driver:
blacklist from s390 and s390x""). Let's drop it again.
---
Packages-arch-specific | 1 -
1 file changed, 1 deletion(-)
diff --git a/Packages-arch-specific b/Packages-arch-specific
index a02ab83..68c1b4e 100644
--- a/Packages-arch-specific
+++ b/Packages-arch-specific
@@ -24,7 +24,6 @@ fdflush: alpha amd64 i386
# amd64/i3
%libgcr410: i386 amd64 # [ANAIS]
%linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS
[?]
%prctl: hppa ia64 alpha powerpc #
ANAIS based on syscall availability
-yforth: i386 m68k armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler
# xorg stuff
%xf86-input-multitouch: !s390x
--
2.20.1
Re: Making stretch-security build logs public
Hi,
On 2020-08-02 23:54, Emilio Pozuelo Monfort wrote:
> Hi,
>
> I was wondering if we could make old stretch-security build logs public. I
> suppose there's nothing private there anymore (no more embargoed updates in
> stretch) and it can help in debugging issues with updates (e.g. I just
> uploaded
> a new thunderbird version there and I've noticed that the previous versions
> failed to build on arm{hf,64} and I wanted to refresh my memory on why.
Unfortunately I don't think this is something doable. The build logs for
non-public security builds are not kept on the wanna-build side. They
are sent to the security team. If someone in the team has kept them, we
can arrange to reinject them.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
[p-a-s/sid] Update from Adrian Bunk
< bunk> tvtime I have QA uploaded, entry can be removed. < bunk> mz entry should be removed, this is just a normal bug (#573810) and after upstream died in 2011 the tool was moved to netsniff-ng (#961969). < bunk> ntp entry should be removed, after looking at #418913 < bunk> gpart entry should be removed, this is based on a 1999 bug regarding endianness and other portability issues. There is at some endian handling in the current version, and the current architecture list is very arbitrary. < bunk> ocamlgsl entry should be removed, it will just run into the same #error on armel as it already does on armhf and mipsel. --- Packages-arch-specific | 5 - 1 file changed, 5 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 89dae59..a02ab83 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -21,11 +21,8 @@ # PACKAGE: [SOURCE PACKAGE] [REASON] fdflush: alpha amd64 i386 # amd64/i386/alpha specific -%gpart: i386 hurd-i386 ia64 alpha armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] -%ntp: !hurd-i386 # does not have the needed system calls. -%ocamlgsl: !armel !hppa # [ANAIS] upstream and alignment issues (ARCH_ALIGN_DOUBLE) %prctl: hppa ia64 alpha powerpc # ANAIS based on syscall availability yforth: i386 m68k armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler @@ -64,6 +61,4 @@ yforth: i386 m68k armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%mz: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%tvtime: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 -- 2.20.1
[p-a-s/sid] Drop aboot, it now has multiple binary packages, some of them being arch:any
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index f3bf258..89dae59 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -20,7 +20,6 @@ # PACKAGE: [SOURCE PACKAGE] [REASON] -aboot: alpha # alpha boot loader fdflush: alpha amd64 i386 # amd64/i386/alpha specific %gpart: i386 hurd-i386 ia64 alpha armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] -- 2.20.1
[p-a-s/sid] Drop s390 architecture
It does not exist anymore in sid (not even on debian-ports) --- Packages-arch-specific | 52 +- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index efff641..f3bf258 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -31,34 +31,34 @@ fdflush: alpha amd64 i386 # amd64/i3 yforth: i386 m68k armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler # xorg stuff -%xf86-input-multitouch: !s390 !s390x -%xf86-input-wacom: !s390 !s390x -%xserver-xorg-input-acecad: !s390 !s390x -%xserver-xorg-input-aiptek: !s390 !s390x -%xserver-xorg-input-elographics: !s390 !s390x -%xserver-xorg-input-joystick: !s390 !s390x -%xserver-xorg-input-keyboard: !s390 !s390x -%xserver-xorg-input-mouse: !s390 !s390x -%xserver-xorg-input-mutouch: !s390 !s390x -%xserver-xorg-input-synaptics: !s390 !s390x -%xserver-xorg-video-ati: !s390 !s390x -%xserver-xorg-video-cirrus: !s390 !s390x -%xserver-xorg-video-fbdev: !s390 !s390x -%xserver-xorg-video-glide: !s390 !s390x -%xserver-xorg-video-mach64: !s390 !s390x -%xserver-xorg-video-mga: !s390 !s390x -%xserver-xorg-video-neomagic: !s390 !s390x -%xserver-xorg-video-nouveau: !s390 !s390x -%xserver-xorg-video-r128: !s390 !s390x -%xserver-xorg-video-savage: !s390 !s390x -%xserver-xorg-video-siliconmotion: !s390 !s390x -%xserver-xorg-video-sisusb: !s390 !s390x -%xserver-xorg-video-tdfx: !s390 !s390x -%xserver-xorg-video-trident: !s390 !s390x -%xserver-xorg-video-vesa: !s390 !s390x +%xf86-input-multitouch: !s390x +%xf86-input-wacom: !s390x +%xserver-xorg-input-acecad: !s390x +%xserver-xorg-input-aiptek: !s390x +%xserver-xorg-input-elographics: !s390x +%xserver-xorg-input-joystick: !s390x +%xserver-xorg-input-keyboard: !s390x +%xserver-xorg-input-mouse: !s390x +%xserver-xorg-input-mutouch: !s390x +%xserver-xorg-input-synaptics: !s390x +%xserver-xorg-video-ati: !s390x +%xserver-xorg-video-cirrus: !s390x +%xserver-xorg-video-fbdev: !s390x +%xserver-xorg-video-glide: !s390x +%xserver-xorg-video-mach64: !s390x +%xserver-xorg-video-mga: !s390x +%xserver-xorg-video-neomagic: !s390x +%xserver-xorg-video-nouveau: !s390x +%xserver-xorg-video-r128: !s390x +%xserver-xorg-video-savage: !s390x +%xserver-xorg-video-siliconmotion: !s390x +%xserver-xorg-video-sisusb: !s390x +%xserver-xorg-video-tdfx: !s390x +%xserver-xorg-video-trident: !s390x +%xserver-xorg-video-vesa: !s390x # graphical -%rootskel-gtk: !s390 !s390x +%rootskel-gtk: !s390x # linux specific %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -- 2.20.1
[p-a-s/sid] Drop arm, lpia and sparc architectures
They do not exist anymore in sid (not even on debian-ports) --- Packages-arch-specific | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 9839d87..efff641 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -22,13 +22,13 @@ aboot: alpha # alpha boot loader fdflush: alpha amd64 i386 # amd64/i386/alpha specific -%gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific +%gpart: i386 hurd-i386 ia64 alpha armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] -%linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # ANAIS [?] +%linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] %ntp: !hurd-i386 # does not have the needed system calls. -%ocamlgsl: !armel !hppa !sparc # [ANAIS] upstream and alignment issues (ARCH_ALIGN_DOUBLE) +%ocamlgsl: !armel !hppa # [ANAIS] upstream and alignment issues (ARCH_ALIGN_DOUBLE) %prctl: hppa ia64 alpha powerpc # ANAIS based on syscall availability -yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler +yforth: i386 m68k armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler # xorg stuff %xf86-input-multitouch: !s390 !s390x -- 2.20.1
[p-a-s/sid 9/9] open-iscsi has an explicit Architecture: list
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index fda3b09..3812487 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -67,6 +67,5 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %mz: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%open-iscsi: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %tvtime: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 -- 2.20.1
[p-a-s/sid 7/9] libibverbs has been removed from the archive
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index f94d104..5b1f2ab 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -65,7 +65,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%libibverbs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %mdadm: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %mz: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -- 2.20.1
[p-a-s/sid 1/9] me-tv has been removed from the archive
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 39f4e3e..54be9b8 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -73,7 +73,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %libibverbs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %mdadm: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%me-tv: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %mz: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %open-iscsi: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %tvtime: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -- 2.20.1
[p-a-s/sid 8/9] mdadm has an explicit Architecture: list
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 5b1f2ab..fda3b09 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -66,7 +66,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%mdadm: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %mz: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %open-iscsi: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %tvtime: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -- 2.20.1
[p-a-s/sid 4/9] inotifyx has been removed from the archive
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 179c1c9..bf6ea60 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -65,7 +65,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%inotifyx: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %iscsitarget: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %klibc: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %libibverbs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -- 2.20.1
[p-a-s/sid 5/9] iscsitarget has been removed from the archive
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index bf6ea60..4717f04 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -65,7 +65,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%iscsitarget: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %klibc: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %libibverbs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -- 2.20.1
[p-a-s/sid 2/9] Drop autofs, the package has an explicit Architecture: list
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 54be9b8..69d664e 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -62,7 +62,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %rootskel-gtk: !s390 !s390x # linux specific -%autofs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %readahead-fedora: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -- 2.20.1
[p-a-s/sid 6/9] klibc has an explicit Architecture: list
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 4717f04..f94d104 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -65,7 +65,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -%klibc: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %libibverbs: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %mdadm: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -- 2.20.1
[p-a-s/sid 3/9] readahead-fedora has been removed from the archive
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 69d664e..179c1c9 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -63,7 +63,6 @@ yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compile # linux specific %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%readahead-fedora: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %libcap-ng: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 %inotifyx: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 -- 2.20.1
[p-a-s/sid 3/3] Drop purelibc, the package has an explicit Architecture: list
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index b4bda7f..39f4e3e 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -28,7 +28,6 @@ fdflush: alpha amd64 i386 # amd64/i3 %ntp: !hurd-i386 # does not have the needed system calls. %ocamlgsl: !armel !hppa !sparc # [ANAIS] upstream and alignment issues (ARCH_ALIGN_DOUBLE) %prctl: hppa ia64 alpha powerpc # ANAIS based on syscall availability -%purelibc: i386 amd64 powerpc ppc64 # [ANAIS] no upstream support %uclibc: none# Currently no arch specific package on any debian arch yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # compiler -- 2.20.1
[p-a-s/sid 2/3] Drop duplicated entry
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 8db9d4b..b4bda7f 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -25,7 +25,6 @@ fdflush: alpha amd64 i386 # amd64/i3 %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # ANAIS [?] -%gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific %ntp: !hurd-i386 # does not have the needed system calls. %ocamlgsl: !armel !hppa !sparc # [ANAIS] upstream and alignment issues (ARCH_ALIGN_DOUBLE) %prctl: hppa ia64 alpha powerpc # ANAIS based on syscall availability -- 2.20.1
[p-a-s/sid 1/3] msrtool has been removed from the archive
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index fcba3d5..8db9d4b 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -25,7 +25,6 @@ fdflush: alpha amd64 i386 # amd64/i3 %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # ANAIS [?] -%msrtool: amd64 i386 kfreebsd-i386 kfreebsd-amd64 hurd-i386 # x86-specific %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific %ntp: !hurd-i386 # does not have the needed system calls. %ocamlgsl: !armel !hppa !sparc # [ANAIS] upstream and alignment issues (ARCH_ALIGN_DOUBLE) -- 2.20.1
[p-a-s/sid] Drop aboot, mips is not supported in sid anymore
--- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 164a3a3..fcba3d5 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -21,7 +21,6 @@ # PACKAGE: [SOURCE PACKAGE] [REASON] aboot: alpha # alpha boot loader -%arcboot: mips # mips boot loader fdflush: alpha amd64 i386 # amd64/i386/alpha specific %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] -- 2.20.1
[p-a-s/sid] Allow fdflush to build on amd64
--- Packages-arch-specific | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 126dfe2..164a3a3 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -22,7 +22,7 @@ aboot: alpha # alpha boot loader %arcboot: mips # mips boot loader -fdflush: alpha i386 # i386/alpha specific +fdflush: alpha amd64 i386 # amd64/i386/alpha specific %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # ANAIS [?] -- 2.20.1
Bug#948013: ftp.debian.org: please remove long expired keys from the buildd keyrings
Package: ftp.debian.org Severity: normal The buildd keyrings still contain buildd-alpha-keyring.gpg with the following long expire keys: | pub rsa4096 2012-03-02 [SC] [expired: 2013-03-02] | 34B00B428D69AE7B204816CFD3654A0DF4A26536 | uid [ expired] buildd autosigning key goedel | | pub rsa4096 2012-03-02 [SC] [expired: 2013-03-02] | A94E581D0235AC22CBF9958AA8562D3BC0C0867E | uid [ expired] buildd autosigning key goetz Would it be possible to remove them? The same way the import keys for the armhf, ppc64el, arm64 and mips64el architectures are still in the corresponding keyrings: | pub rsa4096 2011-11-22 [SC] [expired: 2011-12-31] | 8653BF2B44BF17DDCB181C5E7EF63E5F38360647 | uid [ expired] armhf initial import key | | pub rsa4096 2014-08-17 [SC] [expired: 2014-12-15] | B2AB3FDD8427A6CFFB84AE01CF6AB78A75A792BE | uid [ expired] ppc64el initial import key | | pub rsa4096 2014-08-02 [SC] [expired: 2015-01-29] | EFD10F302F6DCA027E2EA4E05F4CD30A93EE9E49 | uid [ expired] Debian arm64 initial import temporary signing key | | pub rsa4096 2015-08-20 [SC] [expired: 2016-02-16] | 7890F2B458A1C440542B958770B8893FB71826BA | uid [ expired] mips64el initial import key I doubt they are still useful, as all the packages signed with these keys have been rebuilt years ago. I guess we can just remove them.
buildd.debian.org maintenance (moving the VM from BM to UBC)
Hi folks, We will move the wuiet.d.o VM (aka buildd.d.o) from Bytemark to UBC today 2019-09-16 starting at 1900 UTC. The visible downtime is not known and will mostly depends on the I/O available on the Bytemark cluster. We expect things to be finished by the morning though. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Please give back golang-golang-x-tools (1:0.0~git20190809.6d4652c+ds-1) on mipsel
On 2019-08-12 12:28, Anthony Fok wrote: > Hello, > > Please give back the latest golang-golang-x-tools > (1:0.0~git20190809.6d4652c+ds-1) on mipsel which ended up building fine > on mipsel porterbox eller.debian.org, so hopefully the build failure on buildd > was a temporary glitch. > > gb golang-golang-x-tools_1:0.0~git20190809.6d4652c+ds-1 . mipsel Done. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [buildd] giveback h5py 2.9.0-3 on mips64el
On 2019-08-13 12:14, Drew Parsons wrote: > mipsel-sil-01 seems to have had a brain fart building h5py 2.9.0-3 for > mips64el. Please ask the mips buildds to try again. > > gb h5py_2.9.0-3 . mips64el > Done. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Please give back ros-ros-comm
On 2019-08-12 17:59, Jochen Sprickerhof wrote: > Hello, > > There was a change in libclass-loader-dev that caused ros-ros-comm to FTBFS on > amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x hppa sh4. > Please give it back: > > gb ros-ros-comm_1.14.3+ds1-5+b1 . amd64 arm64 armel armhf i386 mips mips64el > mipsel ppc64el s390x hppa sh4 Done. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
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: Bug#846970: Patch to document Build-Indep-Architecture field
On 2018-06-15 19:05, Sean Whitton wrote:
> control: tag -1 -patch
>
> [CCing those involved in the original discussion, and wanna-build team,
> in case they object to my proposal below to just close this bug]
>
> Hello,
>
> On Fri, Jun 15 2018, Ian Jackson wrote:
>
> > Sean Whitton writes ("Bug#846970: Patch to document
> > Build-Indep-Architecture field"):
> >> > +``Build-Indep-Architecture``
> >> > +
> >> > +
> >> > +Specification of architectures on which the architecture-independent
> >> > +binary packages are known to be buildable and/or not buildable. If
> >> > +this field is not specified, it defaults to ``any``, matching all
> >> > +Debian machine architectures. If specified, it should be either
> >> > +
> >> > +- A unique single word identifying a Debian machine architecture as
> >> > + described in :ref:`s-arch-spec`.
> >> > +
> >> > +- An architecture wildcard identifying a set of Debian machine
> >> > + architectures, see :ref:`s-arch-wildcard-spec`.
> >> > +
> >> > +This header is useful in the rare case where architecture-independent
> >> > +packages cannot be built on all architectures for reasons outside the
> >> > +maintainer's control.
> >> > +
> >> > +Although the syntax of the field permits it, you should avoid
> >> > +specifying that the package can be built on only a single
> >> > +architecture. This provides flexibility to the administrators of
> >> > +autobuilder infrastructure.
> >
> > I'm afraid I don't understand this.
> >
> > AFAICT from reading s-arch-spec and s-arch-wildcard-spec and looking
> > at the output of dpkg-architecture -L, the above syntax specification
> > permits, with our current arch list, only Build-Indep-Architecture
> > field contents of the following four forms:
> >
> > amd64 (FSVO amd64) doc says don't do this
> > kfreebsd-any (FSVO kfreebsd) useful but niche
> > kfreebsd-amd64 (FSVO kfreebsd & amd64) doc says don't do this
> > any-amd64 (FSVO amd64 not very useful
> > any the default
> >
> > So there is no good use for this field.
>
> Thank you for this analysis.
>
> My original expectation was that the most common use of the field would
> be of the form
>
> Build-Indep-Architecture: !amd64
>
> but this is not actually permitted by my patch. Negating architecture
> names is described only under the Depends field. I think that Mattia
> had realised this mistake, but I mustn't have read his e-mail carefully
> enough, so sorry, all, for being a bit careless.
>
> We can fix my patch in a few different ways:
>
> 1. add "an exclamation mark followed by a unique single word identifying
>a Debian machine architecture ..." as one of the possible values
>
> 2. add the ability to specify a list of architectures and/or
>architecture wildcards, separated by commas
>
> 3. both of the above, (1) and (2)
>
> 4. drop the 'should' requirement that the field specify at least two
>architectures.
>
> The main problem with (1), (2) and (3) is that it means a new parser has
> to be written for this field, as we will be departing from the syntax of
> the Architecture field.
>
> The main problem with (4) has already been discussed: we don't want to
> encourage people to just type `Build-Indep-Architecture:
> my-laptops-arch` whenever their arch:all package FTBFSs on another arch.
>
> Zooming out a bit:
>
> We do not normally add fields to Policy until they are already in use in
> the archive.
>
> Looking at codesearch.debian.net reveals that only a single package is
> actually using this field at present. I haven't checked, but presumably
> the field is not supported by the Debian autobuilders.
I confirm this is not currently supported by the autobuilders. If it
gets added, we'll add support to respect this field, i.e. not try to
build the package on an autobuilder with a different architecture than
the specified one. That said, we do not plan to add support for
non-amd64 based arch:all autobuilder at this point.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same
On 2018-04-12 19:41, Holger Levsen wrote: > control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy > no-change-except-d/changelog-uploads" > # I hope this is correct, realistic and accurate ;) > # if not, please fixup? > #thanks That can't be done on the wanna-build side, uploads to the archive needs to be signed. Time to reassign this bug to ftp.debian.org? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: XDG_RUNTIME_DIR points to non-existing path
Hi, On 2018-03-19 12:31, Sandro Knauß wrote: > Hey, > > I am currently packaging kdepim for Debian and unfortunately test failing for > many archs, because XDG_RUNTIME_DIR is pointing to non-existing path. If I > understand the documentation from freedesktop [1] correctly, it is in the > responsibility of the system to provide a valid path: > > "XDG_RUNTIME_DIR defines the base directory relative to which user-specific > non-essential runtime files and other file objects (such as sockets, named > pipes, ...) should be stored. The directory MUST be owned by the user, and he > MUST be the only one having read and write access to it. Its Unix access mode > MUST be 0700. > > The lifetime of the directory MUST be bound to the user being logged in. It > MUST be created when the user first logs in and if the user fully logs out > the > directory MUST be removed. If the user logs in more than once he should get > pointed to the same directory, and it is mandatory that the directory > continues to exist from his first login to his last logout on the system, and > not removed in between. Files in the directory MUST not survive reboot or a > full logout/login cycle. " You actually pointed to the problem there, the buildd user never login in the chroot, so it never gets created. > Currently the tests failing for kdav [2]: > QWARN : DavItemFetchJobTest::runSuccessfullTest() QStandardPaths: > XDG_RUNTIME_DIR points to non-existing path '/run/user/2952', please create > it > with 0700 permissions. > > Several archs show the same behaviour: arm64, armel,armhf, i386, mips, > mips64el, mipsel, ppc64el and s390x. Maybe also amd64 but as I uploaded amd64 > packages and the buildds haven't build them. See [3] version 17.12.2-1. They all use the same software so that's normal they fail the same way. That kind of issue should probably be fixed directly in the sbuild package, which is used by the build daemons. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Python buildd (was Re: let me help you with progressing bikesheds)
Hi, On 2018-03-07 12:08, Hector Oron wrote: > Hello, > > 2018-03-07 12:01 GMT+01:00 Philipp Kern <pk...@debian.org>: > > Has it been tested? Well, lightly. Unfortunately I'm not really allowed to > > touch the buildds as root so it's kinda hard to replace the existing ones > > given that stuff is enforced by Puppet. So I did a few builds on zemlinsky. > > Should it be tested on one or two? Yes. In theory it should work. :) > > > >>> There were concerns about how DSA wanted this to be packaged (essentially > >>> not at all). > >> > >> > >> Sorry I missed those concerns, could you expand on them or link to > >> discussion? > > > > > > I mostly worked on this with Aurelien and the concern seems to have been > > that DSA would prefer user-based services with linger rather than packages. > > There are two ways to deploy it: > 1. Get the code in buildd via DSA puppet. > 2. Create Debian package, upload it, make a backport. Then it can be > deployed via backport. Can we move forward on that issue? Discussions on IRC suggested that using apt.buildd.debian.org, like it's done for the current packages is not the right choice. The suggested way to run things would be to just deploy things in ~buildd. As pybuildd uses systemd services, it means we need to enable lingering on buildds. Is it fine? The alternative as suggested by Hector is to use the package from backports. This means less flexibility if we need to update the code, as it will take at minimum 5 days following the policy. To do more tests I agree that we should deploy it on more buildds. For *this phase*, I believe enabling lingering and deploying it by hand is the best. Is it something acceptable? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Issue with m...@buildd.debian.org + giveback rrdtool on m68k + questions on vs92
On 2018-02-15 20:33, Jean-Michel Vourgère wrote: > Hi > > On Thursday, 15 February 2018 19:15:12 CET Aurelien Jarno wrote: > > > My email to m...@buildd.debian.org bounced, see bellow. > > Your email was to m68k-bu...@nocrew.org, not to m...@buildd.debian.org. > > I should have warned you, the To: was changed in the bounced notification. > > Attached is the email I sent (to: m...@buildd.debian.org), undeliverable. Ok. It appears that there was a rewrite (and not an alias) directly in the exim4.conf file that has been there for 10 years or more. I just removed it, so the problem should be fixed now. Sorry about that. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Issue with m...@buildd.debian.org + giveback rrdtool on m68k + questions on vs92
On 2018-02-15 14:47, Jean-Michel Vourgère wrote: > Hi > > My email to m...@buildd.debian.org bounced, see bellow. Your email was to m68k-bu...@nocrew.org, not to m...@buildd.debian.org. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#840104: Encrypted uploads to the security archive
On 2018-02-01 22:17, Ansgar Burchardt wrote: > Philipp Kern writes: > > On 01.02.2018 10:30, Ansgar Burchardt wrote: > [...] > >> There is already a `buildd-uploader` role account on the upload hosts > >> both main and security archive, a `rsync-ssh-wrap` script, and someone > >> also set up authorized_keys. > >> > >> I'm just not sure if it is already in use for security uploads? I > >> believe it was used for uploads to the main archive already (not sure if > >> it currently is?). > > > > Indeed, it uses rsync over SSH through dupload. For security it uses > > FTP. Interestingly an rsync-security dupload.conf entry exists, but it > > doesn't seem to be used[1]. > > Hmm, maybe we should try if it does the right thing? The wrapper script > should ignore the `chmod` call I mentioned in #876900, so the uploaded > files shouldn't even be readable by other DDs. The problem there is that rsync when used with dupload forces the uploaded file to be world readable, until the package is moved out from the upload directory by dupload. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: buildd chroot creation: who should get notified of failures?
On 2017-12-21 12:54, Héctor Orón Martínez wrote: > Hello Paul, > > On Thu, Dec 21, 2017 at 3:45 AM, Paul Wise <p...@debian.org> wrote: > > Hi folks, > > > > Occasionally the buildd (and porterboxen) fail to debootstrap updated > > chroots. Sometimes these are Internet problems, sometimes local network > > problems, sometimes mirror problems, sometimes archive problems. These > > mails go to DSA but as far as I can tell, we always ignore them, I > > certainly do. I have included below a sample of the error messages > > since September so folks can get an idea of the errors. > > > > Should they go to the buildd admins? > > I think so, if buildd admins are responsible for buildds, that > includes chroots, so if those are broken, they should be able to fix > them. The script to generate chroots is provided by DSA, and DSA don't really leave a way for buildd admins to fix it. So at least in case of a broken mirror or network issues, which appears to be most of the failures, I think it should be DSA responsibility to fix that. With my DSA hat, I personally have failed to do that. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: blacklisting util-linux on ARM Ltd hosted buildds
On 2017-08-21 10:11, Andreas Henriksson wrote: > Hello! > > The util-linux test-suite detects (intermittent) problems when running > on buildds hosted at ARM Ltd. The issue has been investigated and > also discussed with responsible people via #debian-arm. Unfortunately > no solution in sight (as it seems the responsible people lost interest > in investigating what's happening at their end). > > I'm thus asking you to please blacklist all ARM Ltd hosted buildds > (for all (arm*) architectures) for building the util-linux package. This is not something acceptable for armel and armhf at least given the corresponding build daemons are only in two locations, at arm and YNIC. Blacklisting one location means we don't have build redundancy anymore for this package. This is especially true given we don't have OOB access at all to the buildds in YNIC. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#867104: wanna-build issue with src:perl versioned Provides
On 2017-08-01 08:17, Ralf Treinen wrote: > Hello, > > On Mon, Jul 31, 2017 at 07:30:22PM +0300, Niko Tyni wrote: > > On Mon, Jul 31, 2017 at 04:16:25PM +0200, Mattia Rizzolo wrote: > > > On Thu, Jul 27, 2017 at 03:15:14PM +0200, Aurelien Jarno wrote: > > > > > 1. upload to stretch, upgrade wuiet to stretch > > > > > > > > I plan to upgrade wuiet to stretch during debconf, but not before. Note > > > > anyway that going through stretch means waiting for the next point > > > > release. > > > > > > I don't believe waiting for the next point release would be so bad > > > anyway. It probably means less than 2 months, this change waited for > > > quite longer… > > > Also, couldn't you install it from stretch-pu? > > > > > > > > 3. upload to stretch-bpo, upgrade wuiet to stretch > > > > > > > > That also works and might be faster. It means we need to try to keep as > > > > much as possible the interface unchanged to not get any breakage. > > > > > > That, and it would need be kept up to date in backports to comply with > > > backport's rules. > > > > > > > > > Overall I think that 1 is the best choice for everything, but then it > > > comes down to Ralf's willingness to take out the fixing commit and to a > > > stable update (and RM acceptance of it), and pkg-perl's willingness to > > > wait for the next point release. > > > > Oh, we aren't in any particular hurry though I'd obviously like it to > > happen early enough for buster :) There's also #867081 to fix before we > > can reinstate the versioned Provides in perl anyway. > > OK, I will go for the next stretch point release. Cheers -Ralf. Ok, thanks. For the record, wuiet.d.o the machine behind buildd.d.o now runs stretch. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Please give back golang-golang-x-tools (1:0.0~git20170707.0.bce9606b+ds-1) on s390x
On 2017-07-08 04:44, Anthony Fok wrote: > Hello, > > Seeing the latest build log at: > > > https://buildd.debian.org/status/logs.php?pkg=golang-golang-x-tools=s390x > > It seems that golang-golang-x-tools is experiencing "SIGILL: illegal > instruction" during the "go test" run on s390x on zemlinsky, even it > is using the supposedly z10-compatible gccgo-7. > > The same tests ran perfectly when I tested the package on zelenka > s390x porterbox. > > gb golang-golang-x-tools_1:0.0~git20170707.0.bce9606b+ds-1 . s390x > > Many thanks! > > Side discussion: I don't know if it is an isolated incident or not, > and whether it is easy to patch/workaround, but if gccgo-7 and beyond > are not backward compatible with z10 CPU instructions, perhaps we > should eventually switch back to using the golang-go as default for > s390x? It's due to a gratuitous -march=z196 added in gccgo. That should be fixed in the next upload of gcc-7 [1]. Aurelien [1] https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/patches/libgo-s390x-default-isa.diff?revision=9581=markup -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[p-a-s/sid] remove haskell-debian
[Debian bug #866184] --- Packages-arch-specific | 1 - 1 file changed, 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index b7fc0c9..126dfe2 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -24,7 +24,6 @@ aboot: alpha # alpha boot loader %arcboot: mips # mips boot loader fdflush: alpha i386 # i386/alpha specific %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific -%haskell-debian: all amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc # Requires threaded Haskell runtime %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # ANAIS [?] %msrtool: amd64 i386 kfreebsd-i386 kfreebsd-amd64 hurd-i386 # x86-specific -- 2.1.4
Re: Please give back golang-1.8 (1.8.3-1) on s390x
On 2017-06-24 11:15, Anthony Fok wrote: > Hello, > > There seems to be a hiccup when golang-1.8 (1.8.3-1) was last built > for s390x on zemlinsky. > > Seeing the logs at > > https://buildd.debian.org/status/logs.php?pkg=golang-1.8=s390x > > It seems that zemlinsky fails consistently "Illegal Instruction" early > in the build, > while both zandonai and zani consistently succeed. > > gb golang-1.8_1.8.3-1 . s390x Done. > Perhaps it is too much to ask, but would it be possible to set some > kind of automatic give-back whenever golang-1.8 (or future golang-1.9) > fails on zemlinsky? Automatic give back no, but we can blacklist the package on this build daemon. This is only a workaround for the problem below. > Or, better yet, is there a way to find out what went wrong on > zemlinsky? Is it an older machine with an older CPU that does not > support some newer CPU instructions? (Sorry, I know nothing about > s390x and I am likely completely wrong.) That is actually the problem. On s390x golang requires a higher ISA than the one Debian targets. I have started to patch golang-1.7 to avoid these new instructions a few months ago, but upstream is not interested by supporting older CPUs and keep adding more usage of new instructions. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [wanna-build] [PATCH] Switch from /org to /srv in comment and documentation
On 2017-06-17 14:43, Paul Wise wrote: > /org has been obsoleted by /srv for many years on debian.org hosts. > --- > etc/cron/crontab | 2 +- > schema/README| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Thanks, applied. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Please give back sra-sdk on i386
On 2017-04-02 10:56, Graham Inggs wrote: > Hi Wanna-Build Team > > Please give back sra-sdk on i386. I should have mentioned in #859261 > to wait for ngs-sdk and ncbi-vdb, and Andreas was so efficient in > uploading. :) > > gb sra-sdk . i386 Done. Aurélien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Please give back firefox/experimental on i386
On 2017-04-02 11:42, Mike Hommey wrote: > Hi, > > For the second time in a few weeks, the firefox build failed on i386 > with a crash of ld. Please give it back. > > gb firefox_53.0~b8-1 . i386 Done. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
source-only uploads and arch:all buildds for stretch?
Dear release team, Before too many people ask the w-b team about that, do we want to allow source-only uploads and therefore arch:all buildds for stretch? If so we'll enable the all/stretch architecture in wanna-build, configure the arch:all autobuilders accordingly. I guess the ftp-masters team can then enable source-only uploads for stretch. Aurelien (with his w-b team hat) -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [pgstatus] [PATCH 1/3] Allow the raw parameter to fetch.php to be 0
On 2016-12-21 20:40, Paul Wise wrote: > This makes the chosen value more explicit in the URL. Thanks I have merged these patches. I had to fix a small typo (extra comma) for the last patch. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Please give back julia on i386
On 2017-01-03 00:09, Peter Colberg wrote: > Hi, > > During the build of julia on i386 the test suite was aborted [1]. > Since the previous version built fine on i386 and the new version > is merely a cosmetic change, this is likely a transient failure. > > gb julia_0.4.7-4 . i386 Done. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[p-a-s/sid] haskell-debian now has an arch:all package
Signed-off-by: Aurelien Jarno <aurel...@aurel32.net> --- Packages-arch-specific | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 1aab9b4..b7fc0c9 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -24,7 +24,7 @@ aboot: alpha # alpha boot loader %arcboot: mips # mips boot loader fdflush: alpha i386 # i386/alpha specific %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little endian specific -%haskell-debian: amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc # Requires threaded Haskell runtime +%haskell-debian: all amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc # Requires threaded Haskell runtime %libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # ANAIS [?] %msrtool: amd64 i386 kfreebsd-i386 kfreebsd-amd64 hurd-i386 # x86-specific -- 2.1.4
Re: misleading timestamps in binnmus
On 2016-11-10 11:33, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson <ijack...@chiark.greenend.org.uk> (2016-11-09):
> > > What version of sbuild do buildds run ? Ie, supposing that this is
> > > fixed in sbuild in stretch, will this be fixed on the buildds ? Or do
> > > we need to update jessie, or what ?
> >
> > sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> > going to summarize. The base version is close to what's in jessie (see the
> > first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
> ...
> > Repository seems to live under:
> > https://apt.buildd.debian.org/
>
> Thanks. When Johannes has decided exactly what the sbuild patch looks
> like in sid, I will take a look at the repo there and backport the
> change. In what form should I supply mhy update ? As an source+all
When it's done, just ping us with the commit number, we will backport it
in our branch and we will deploy it on the build daemons.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: Please give back mash_1.1.1-1 on ppc64el
On 2016-09-09 16:56, Sascha Steinbiss wrote: > Hi, > > please give back mash_1.1.1-1 on ppc64el. The latest build on ppc64el > was failing [1] due to unknown reasons I was unable to reproduce in a > clean sid chroot on a ppc64el porterbox (plummer.debian.org), where the > build succeeded without problems. > > gb mash_1.1.1-1 . ppc64el Done, it built successfully. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Give back atlas on powerpc
On 2016-08-10 15:16, Sébastien Villemot wrote: > Dear Wanna-build team, > > Please give back atlas on powerpc: > > gb atlas_3.10.3-1 . powerpc > > The failure on praetorius is known (see #770632), so another buildd should be > used. Done, given back. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On 2016-07-28 14:36, Peter Green wrote: > > Fixed package is in sid (5.0-3) since Fri, 15 Jul > > I have installed this on the main raspbian server and I can confirm it works > for us with wanna-build. > > Note1: I had to update wanna-build, the version of wanna-build I had (which > was not bang up to date but not all that old either) wouldn't work with the > new dose. Not exactly sure why. The only dose related change I see seems to > be related to display postprocessing and claims to target the > jessie-bacports version not the sid version. Yes, dose changed its output format, so we had to add a compatibility layer. The commits talks about jessie-backports, but it has the same upstream version as the one in sid, so in practice it applies to both. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Builds taking far too long
On 2016-07-24 22:29, Christian Seiler wrote: > On 07/24/2016 10:26 PM, Aurelien Jarno wrote: > > The binNMU message included some yaml reserved signs, which are not > > properly escaped by the current code, so the builds actually fail to > > start after they have been taken to build. > > Sorry, didn't know that. Which symbols are problematic, so I can > avoid them in the future and not cause these kinds of problems? In that case it was the ':', that I replaced it by ','. It something we have to fix at some point, but we got no time for that. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Builds taking far too long (was: Re: Bug#832123: nmu: mksh util-vserver)
On 2016-07-24 14:42, Cyril Brulebois wrote: > Hi, > > Christian Seiler <christ...@iwakd.de> (2016-07-23): > > On 07/23/2016 11:05 AM, Emilio Pozuelo Monfort wrote: > > > On 22/07/16 16:50, Christian Seiler wrote: > > >> nmu mksh_52c-2 . ALL . -m "Security: rebuild against newest dietlibc" > > >> nmu mksh_52c-2exp3 . ALL . experimental . -m "Security: rebuild against > > >> newest dietlibc" > > >> nmu util-vserver_0.30.216-pre3120-1.1 . ALL . -m "Security: rebuild > > >> against newest dietlibc" > > > > > > Scheduled. > > > > These packages have been building on _all_ architectures for a > > very long time now (nearly 2 hours on some), while they typically > > only have a build time of a couple of minutes (depending on the > > architecture). Could you please take a look? I think there's > > something wrong here and buildd resources are being wasted. > > > > (I just rechecked and the source packages of these binNMUs do > > build fine in a clean pbuilder env, so I don't really know what > > the problem could be though.) > > mksh seems installed now, various logs show: > Build needed 00:02:29, 16240k disc space > Build needed 00:02:37, 13340k disc space > Build needed 00:04:14, 17736k disc space > > Those builds started past 20:00 UTC, so I suspect whatever happened at > the time was fixed or so, and mksh built normally afterwards. The binNMU message included some yaml reserved signs, which are not properly escaped by the current code, so the builds actually fail to start after they have been taken to build. I have changed the message around that time yesterday, that's why it built so late. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Disabling SH4 buildds hosted in Japan
Hi Nobuhiro, I have been requested by John Paul Adrian Glaubitz to revoke the wanna-build access for the SH4 build daemons you host in Japan, namely the following buildds: - akagi - amagi - baruna - musashi - huso - kongou - nagato - yamashiro - yamato It seems that they crash regularly due to a kernel issue, and thus cause harm to the port. He contacted you repeatedly without success. As the original porter behind the SH4 port and as the owner of the above build daemons, I think it's fair to give you a last chance to fix the issues. Without answer within a reasonable time frame (let's say one week), I'll proceed with Adrian's request. He will provide and host new build daemons to replace the disabled ones. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: give-back ant, proj on kfreebsd
On 2016-07-10 22:47, Andreas Beckmann wrote: > Please give-back > > gb ant_1.9.7-3 . kfreebsd-amd64 kfreebsd-i386 > gb proj_4.9.2-3 . kfreebsd-amd64 kfreebsd-i386 > > the FTBFS should have been fixed in openjdk-8. Done, thanks. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On 2016-07-05 14:36, Aurelien Jarno wrote: > On 2016-07-02 22:03, Anton Gladky wrote: > > Dear all, > > > > I have just uploaded dose3_5.0-1~bpo8+1 into jessie-backports. > > > > Thanks a lot, I have installed it on wuiet. It seems to work fine at a > first glance. Unfortunately I had to revert it to the jessie version has it doesn't correctly compute the dependencies. It looks like something has changed in the command line interface, and I have no time to investigate now. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On 2016-07-02 22:03, Anton Gladky wrote: > Dear all, > > I have just uploaded dose3_5.0-1~bpo8+1 into jessie-backports. > Thanks a lot, I have installed it on wuiet. It seems to work fine at a first glance. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: [Stretch] Status for architecture qualification
Hi, Here is a small update about mips64el (and mips). On 2016-06-16 10:25, Aurelien Jarno wrote: > On 2016-06-16 02:12, Hector Oron wrote: > > > * mips64el (NEW) > > >- No DSA buildd (RT blocker) > > > > As far as I can see mips64el is using shared builds with mipsel port > > hardware, those machines are DSA. > > We also have the confirmation that the UTM-8 machines sent by > Imagination Technologies have arrived at MAN-DA and SIL about one month > ago. They still need to be racked and installed. The machines at SIL have been racked and installed: - mips-sil-01.debian.org building mips (it has an FPU) - mipsel-sil-01.debian.org building mips64el and then mipsel Also we have changed mipsel-manda-02 so that it builds first mips64el and then mipsel. This means we should have enough DSAed buildds for mips64el. When MAN-DA machines are installed we'll get more redundancy. > > >- Rebuild after import not complete (RT Blocker) > > > > Is there a list of packages that should be rebuilt? > > It is available here: > > https://ftp-master.debian.org/users/mhy/mipsel64import.txt > > There is only a single package: db5.3. It is currently not buildable as > the ecj package doesn't build. The ecj java bytecode is not executed > correctly by gij. We have made some progress on this recently with a > simple reproducer not involving ecj. Matthew Fortune from Imagination > Technologies is currently working on that currently and has already > found that it is due to a sign extension issue at the JIT'd/FFI layer. > I therefore expect a solution a solution soon. There has been some progress there too, a patch has been sent upstream: https://gcc.gnu.org/ml/java-patches/2016-q2/msg00020.html Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [Stretch] Status for architecture qualification
On 2016-06-16 02:12, Hector Oron wrote: > > * mips64el (NEW) > >- No DSA buildd (RT blocker) > > As far as I can see mips64el is using shared builds with mipsel port > hardware, those machines are DSA. We also have the confirmation that the UTM-8 machines sent by Imagination Technologies have arrived at MAN-DA and SIL about one month ago. They still need to be racked and installed. > >- Rebuild after import not complete (RT Blocker) > > Is there a list of packages that should be rebuilt? It is available here: https://ftp-master.debian.org/users/mhy/mipsel64import.txt There is only a single package: db5.3. It is currently not buildable as the ecj package doesn't build. The ecj java bytecode is not executed correctly by gij. We have made some progress on this recently with a simple reproducer not involving ecj. Matthew Fortune from Imagination Technologies is currently working on that currently and has already found that it is due to a sign extension issue at the JIT'd/FFI layer. I therefore expect a solution a solution soon. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Wrong info on protobuf package
On 2016-05-04 00:46, Santiago Vila wrote: > On Wed, May 04, 2016 at 12:31:43AM +0200, Aurelien Jarno wrote: > > On 2016-05-04 00:13, Santiago Vila wrote: > > > > > This page > > > > > > https://buildd.debian.org/status/package.php?p=protobuf > > > > > > makes me to believe that the Arch: all autobuilder successfully built > > > the protobuf package, but if I click in the link I see this: > > > > It actually says that the package has been installed in the archive. It > > has been built manually and uploaded into the archive by a person, not > > and autobuilder. > > So just put the word "Install" without any link, as it happens with > uploads which include source and binaries, for example: > > https://buildd.debian.org/status/package.php?p=gzip > > The link, when it's present, is supposed to match the actual build > which happened for the installed binaries. If they do not match it > would be better not to have a link at all. We don't have any way to match the actual build with the binary in the archive. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Wrong info on protobuf package
On 2016-05-04 00:13, Santiago Vila wrote: > Hello. Hi, > This page > > https://buildd.debian.org/status/package.php?p=protobuf > > makes me to believe that the Arch: all autobuilder successfully built > the protobuf package, but if I click in the link I see this: It actually says that the package has been installed in the archive. It has been built manually and uploaded into the archive by a person, not and autobuilder. > https://buildd.debian.org/status/fetch.php?pkg=protobuf=all=2.6.1-1.3=1440630189 > > which is not a successful build. True. > So it seems there is a bug somewhere. It might depend how you read the page. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: give-back kdiff3
On 2016-04-30 11:33, Andreas Beckmann wrote: > Hi, > > please > > gb kdiff3_0.9.98-2 . i386 armhf armel > > I could not reproduce the > > make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by > 'src-QT4/kdiff3'. Stop. > > problem in a local i386 build. Done. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#818579: ftp.debian.org: experimental Sources missing the Files: header
On 2016-03-18 10:45, Samuel Thibault wrote: > Samuel Thibault, on Fri 18 Mar 2016 10:40:21 +0100, wrote: > > FWIW, it seems the sid version also requires the Files: header, > > actually. > > I'm currently trying the attached patch. It doesn't seem like a proper > long-term solution, though. I think the problem has already been fixed on the master branch with this commit: | commit cdf124142b70df446af938a5d19fc13cc01d36fa | Author: Johannes 'josch' Schauer <jo...@mister-muffin.de> | Date: Tue Jan 26 08:30:26 2016 +0100 | | Allow to build by only passing source package name without version (closes: #693928) We probably want to backport part of it (the cleanup part, not the feature part). Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Please give back php-sabre-dav-2.1 on all
On 2016-03-02 14:42, David Prévot wrote: > Hi, > > Please, retry building php-sabre-dav-2.1 now that a “fixed” phpunit is > in. > > gb php-sabre-dav-2.1_2.1.9-2 . all > Done. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Additional wanna-build permissions for Helge Deller
On 2015-11-08 12:52, John Paul Adrian Glaubitz wrote: > Hi Aurelien! > > Could you give Helge wanna-build permissions for the following > architectures: > > * m68k Done. > * sh4 Nobuhiro, Helge Deller would like to get access to wanna-build for sh4. Are you fine with that? > * sparc64 Done. > * x32 Daniel, Helge Deller would like to get access to wanna-build for x32. Are you fine with that? > > Helge has access to my buildds as well and he is helping me a lot > fixing the build queues. It would be great if he also had access > for wb for these architectures so he doesn't always have to ask > me for give-backs or binnmus. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Adding sparc to Debian Ports
On 2015-10-19 11:39, Jose E. Marchesi wrote: > > > Plus, Oracle is still actively maintaining the Linux SPARC > > port [4], so I think we have the ideal prerequisites for > > reviving the port. > > The webpage you link says "Linux for SPARC is a pure 64-bit operating > system and can only work on a 64-bit SPARC CPU". It is clearly a way to > improve the Debian sparc64 port, but not really a way to improve the > sparc one. > > To clarify: the Linux for SPARC released by Oracle is a sparc64 distro > with multilib support to build and execute V8PLUS 32 bit binaries. Thanks for the clarification. It's therefore just like the Debian sparc64 port. It default to 64-bit binaries, but the toolchain is available to build 32-bit binaries. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Adding sparc to Debian Ports
On 2015-10-13 14:41, John Paul Adrian Glaubitz wrote: > Dear FTP team and dear buildd team! Hi, > As discussed at DebConf15, I would like to ask you to add 'sparc' > (SPARC 32-bit port)to Debian Ports after it was previously removed from > the release architecture. Speaking with my debian-ports hat on (added it in Cc:), note that the Debian FTP Masters do not maintain (at least yet) the architectures on debian-ports. That said there is been discussions to move them on a dak based archived maintained by the Debian FTP Masters. This requires some development though, and I don't know how far they are so far. It would be a pity to do the work on debian-ports and to have to handle its move to another archive just after. > After a fruitful discussion on the debian-sparc mailing list [1], > we have come to the conclusion that there are enough people willing > to invest time, effort and resources in resurrecting the sparc > ports of Debian. Dropping my debian-ports hat, I can clearly see in this thread interest in reviving a sparc port, but I have not really identified persons who actually plan to do the work. In that way the situation hasn't really changed for the last years, and that's the reason why the port has been removed from the main archive. Who is actually planning to do the work? > While we already have sparc64 in ports, sparc (32) > runs on more hardware and has more packages which are actually > ported to sparc. Does it means that you plan to change the ISA when reviving the port? The Debian SPARC port targets the SPARCV8PLUS ISA since Lenny, which in turns requires a SPARC v9 processor just like the Debian sparc64 port. Also note that 32-bit ports are getting slowly into danger [1], so I am not sure it's going in the right direction. > For example, mozjs builds fine on sparc32 but > FTBFS on sparc64. That's not really a random example. This package has architecture specific code, that needs to be tweak for every recent architecture in the archive. Have you actually tried to port it? Fixing this probably requires a lot less than rebootstrapping and maintaining a port. > Moreover, several people [2-3] have also offered fast SPARC machines > as buildds which they are hosting themselves so we are not > dependent on any of the older, half-broken Debian SPARC > machines. So hardware won't be an issue. Ok. Note that you still need to depend on old hardware, as newer hardware like the OpenSPARC T1 machines that Debian owns are not stable due to (at least) kernel bugs. However the situation is basically the same for both SPARC and SPARC64, so that's indeed not an issue. > Plus, Oracle is still actively maintaining the Linux SPARC > port [4], so I think we have the ideal prerequisites for > reviving the port. The webpage you link says "Linux for SPARC is a pure 64-bit operating system and can only work on a 64-bit SPARC CPU". It is clearly a way to improve the Debian sparc64 port, but not really a way to improve the sparc one. > I will take care of setting up the buildds and all, I just need > to have 'sparc' added on the FTP servers as well in wanna-build. > > Please let me know if there is anything I can do to help in > the process. I am still in doubt this is the right thing to do, now if there is an actual team wanting to do the work, I guess we'll just add the sparc port to debian-ports. Aurelien [1] https://lists.debian.org/debian-devel/2015/08/msg00331.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Please give back mono on powerpc
On 2015-09-07 19:01, Jo Shields wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > I am trying to track down issues with Mono FTBFS on PowerPC, which may > be related to CPU optimizations on specific models of PowerPC. Please > do whatever magic is required to allow Mono to only build on > porpora.debian.org, poulenc.debian.org or praetorius.debian.org, then > give-back Mono 4.0.4.1+dfsg-1 in Experimental. > > gb mono_4.0.4.1+dfsg-1 . powerpc . experimental The magic is to blacklist mono on powerpc-osuosl-01 and powerpc-unicamp-01, something we don't want as they are the machines which will stay in the long term. I have therefore arranged for the package to be picked up by porpora, but it's only for one time, it will be random again for the next upload. Please make sure it works everywhere. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: [buildd-tools-devel] [GIT] sbuild branch buildd-0.65 updated. debian/sbuild-0.65.2-1+buildd2-3-gef7774f
On 2015-09-04 14:38, Hector Oron wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "sbuild". > > The branch, buildd-0.65 has been updated >via ef7774feeff9557b2957c34cd3e9f4753b8abb96 (commit) >via 8981650ad7aab0c21460f4011e101586a0ec4303 (commit) > from dd15b466930b99ec5fa366a24732f2f8813d1a47 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log - > commit ef7774feeff9557b2957c34cd3e9f4753b8abb96 > Author: Héctor Orón Martínez <zu...@debian.org> > Date: Fri Sep 4 16:29:22 2015 +0200 > > Release Debian version 0.65.2-1+buildd3 > > Signed-off-by: Héctor Orón Martínez <zu...@debian.org> > > commit 8981650ad7aab0c21460f4011e101586a0ec4303 > Author: Johannes 'josch' Schauer <jo...@mister-muffin.de> > Date: Thu Sep 3 08:59:37 2015 +0200 > > add aspcud based resolver I have just changed the resolver for experimental to aspcud on the wanna-build side. A few haskell packages have been built successfully, so that's quite a good start. Now we probably want to wait a bit to aspcud behaves wrt haskell, but also other packages that used to build fine. At the same time, I explicitly set the resolver for distributions not using aptitude to apt instead of letting sbuild choosing the default. That gives the following setting: distribution | build_dep_resolver --+ experimental | aspcud jessie | apt jessie-backports | aptitude jessie-kfreebsd | apt jessie-kfreebsd-security | apt jessie-security | apt sid | apt sid-rebuild | apt squeeze | apt squeeze-backports| aptitude squeeze-backports-sloppy | aptitude squeeze-lts | apt squeeze-security | apt stretch | apt stretch-security | apt wheezy | apt wheezy-backports | aptitude wheezy-backports-sloppy | aptitude wheezy-security | apt For the -backports distributions, I guess aspcud in squeeze and wheezy is too old to handle that, I don't know the status in jessie. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: experimental does not like Haskell
On 2015-08-25 16:31, Joachim Breitner wrote: Hi, there are a few packages that do not build on experimental due to missing dependencies, although wanna-build believes that they can be built: https://buildd.debian.org/status/fetch.php?pkg=pandocarch=i386ver=1.15.0.6~dfsg-1stamp=1440511365 It seems that the aptitude dependency resolver is not able to find the solution (which presumably exists). More than not finding a solution, std::bad_alloc means the aptitude process has exhausted all the memory, which on some machines with 32GB of memory can take a few hours. On some others it get instead killed by the kernel OOM. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: experimental does not like Haskell
On 2015-08-26 08:55, Gianfranco Costamagna wrote: Hi Hohannes, Did you try to join the team? https://alioth.debian.org/project/memberlist.php?group_id=30471 you might want to join and ask directly to contribute on the git. Since it is a team maintained package, joining the team might be your best option. In practice it's not maintained anymore. We are only a few people from the wb-team making some commits to the stable branch to fix immediate issues. Any fresh blood is welcome. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Pinning haskell-src-exts to the larger buildds?
On 2015-08-16 14:15, Joachim Breitner wrote: Hi, Am Sonntag, den 16.08.2015, 14:05 +0200 schrieb Aurelien Jarno: Either chance or maybe depending on the toolchain. If there is no easy way to reduce the memory usage, the best is probably to just disable or not care about it on mips 32-bit. As this comes up again and again, disabling it on mips would probably the best. What would be the “correct” way to disable it? Not-for-us, or the source’s architecture field? I don't think not-for-us is the best, but so far it's probably the best way to do that. I have just marked it as non-for-us on both mips and mipsel. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Pinning haskell-src-exts to the larger buildds?
On 2015-08-16 14:02, Joachim Breitner wrote: Hi, Am Sonntag, den 16.08.2015, 13:38 +0200 schrieb Aurelien Jarno: On 2015-08-16 12:57, Joachim Breitner wrote: Hi, it seems that haskell-src-exts builds on mips only on certain buildds: https://buildd.debian.org/tmp/~nomeata/pgstatus/logs.php?pkg=haskell-src-extsarch=mipssuite=sid https://buildd.debian.org/tmp/~nomeata/pgstatus/logs.php?pkg=haskell-src-extsarch=mipselsuite=sid There is a way to prevent packages from being attempted at certain buildds. Maybe it would be good to do that here? Unfortunately I don't think the issue is the memory on the buildds. The ones where it fails to build have 4 or 8GB of RAM. The problem is that on MIPS32, the virtual memory space is limited to 2GB (hence the virtual memory exhausted message. That's why on the reason why we want the mips64el port. so you think it is just chance whether the build goes through or not, because it is just close to the 2GB limit? In that case, should we simply disable this package on mips, or keep retrying? Either chance or maybe depending on the toolchain. If there is no easy way to reduce the memory usage, the best is probably to just disable or not care about it on mips 32-bit. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Pinning haskell-src-exts to the larger buildds?
On 2015-08-16 12:57, Joachim Breitner wrote: Hi, it seems that haskell-src-exts builds on mips only on certain buildds: https://buildd.debian.org/tmp/~nomeata/pgstatus/logs.php?pkg=haskell-src-extsarch=mipssuite=sid https://buildd.debian.org/tmp/~nomeata/pgstatus/logs.php?pkg=haskell-src-extsarch=mipselsuite=sid There is a way to prevent packages from being attempted at certain buildds. Maybe it would be good to do that here? Unfortunately I don't think the issue is the memory on the buildds. The ones where it fails to build have 4 or 8GB of RAM. The problem is that on MIPS32, the virtual memory space is limited to 2GB (hence the virtual memory exhausted message. That's why on the reason why we want the mips64el port. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
