Re: Staging branch [substitute availability]
Hey, > The network team asks me to test it now. Could you please give it a > try? I ran a few tests, it seems to work perfectly! It's really impressive how Wireguard is easy to set up. I think it deserves a complete Guix service :). --8<---cut here---start->8--- mathieu@berlin ~$ sudo wg interface: wg0 public key: wOIfhHqQ+JQmskRS2qSvNRgZGh33UxFDi8uuSXOltF0= private key: (hidden) listening port: 51820 peer: hzpKg9X1yqu1axN6iJp0mWf6BZGo8m1wteKwtTmDGF4= endpoint: 91.166.111.102:45266 allowed ips: 10.0.0.2/32 latest handshake: 26 seconds ago transfer: 3.27 KiB received, 3.21 KiB sent --8<---cut here---end--->8--- Anyway, thanks for your support, Mathieu
Re: Staging branch [substitute availability]
Mathieu Othacehe writes: >> Yes, this should be okay. Does this mean that we can get rid of all the >> other ports that we previously requested? > > Yes, the SSH tunnels and the associated open ports shouldn't be useful > anymore, as we'll be able to route all the build nodes traffic through > the VPN. Excellent! >> If you’re sure that it should be UDP port 51820 for incoming connections >> (and outgoing as well?) then I’ll submit the request. > > Yes, UDP 51820 for incoming and outgoing connections would be fine. The network team asks me to test it now. Could you please give it a try? -- Ricardo
Re: Staging branch [substitute availability]
Hello, > Yes, this should be okay. Does this mean that we can get rid of all the > other ports that we previously requested? Yes, the SSH tunnels and the associated open ports shouldn't be useful anymore, as we'll be able to route all the build nodes traffic through the VPN. > If you’re sure that it should be UDP port 51820 for incoming connections > (and outgoing as well?) then I’ll submit the request. Yes, UDP 51820 for incoming and outgoing connections would be fine. > Sorry again for the delay! Feel free to ping me directly in the future. No worries, thanks for your reply! Mathieu
Re: Staging branch [substitute availability]
Hi Mathieu, sorry for missing this message (and all the others). Leo pointed me to this message on IRC. (Thanks!) > The easier way to proceed could be to create a VPN for the remote build > machines that are not on berlin local network. Wireguard could be a good > candidate. That would mean that only one UDP port has to be opened on > berlin. > > Ricardo, do you think that the sysadmins would agree to open traffic on > UDP port 51820 for instance? Yes, this should be okay. Does this mean that we can get rid of all the other ports that we previously requested? If you’re sure that it should be UDP port 51820 for incoming connections (and outgoing as well?) then I’ll submit the request. Sorry again for the delay! Feel free to ping me directly in the future. -- Ricardo
Re: Staging branch [substitute availability]
Hello, > What would it take to connect at least one OverDrive? How can the > admins among us help? I have reconfigured the overdrive1 so that it runs a Cuirass remote worker. Now several ports on berlin and the overdrive1 need to be opened for the remote building mechanism. The easier way to proceed could be to create a VPN for the remote build machines that are not on berlin local network. Wireguard could be a good candidate. That would mean that only one UDP port has to be opened on berlin. Ricardo, do you think that the sysadmins would agree to open traffic on UDP port 51820 for instance? > Fun. Not sure what the correct solution would be; perhaps make one > /api/queue request per system type? Yes, that would already be better. Thanks, Mathieu
Re: Staging branch [substitute availability]
On Tue, Jan 26, 2021 at 06:51:13PM -0500, Leo Famulari wrote: > On Fri, Jan 22, 2021 at 03:46:45PM -0500, Leo Famulari wrote: > > -- > > master branch > > aarch64: 72% > > x86_64: 94% > > i686: 86% > > armhf: 46% > > > > staging branch > > aarch64: 48% > > x86_64: 79% > > i686: 70% > > armhf: 30% > > -- > > Updates since the recent merge of master into staging: > > -- > master branch > aarch64: 72% > x86_64: 94% > i686: 86% > armhf: 46% > > staging branch > aarch64: 51% > x86_64: 73% > i686: 69% > armhf: 27% > -- > > So, minor improvements to aarch64, but x86_64 is actually worse! > Mathieu, I'm curious, are we using the overdrives again? Or still > emulating aarch64? > > `guix weather` said to me that there are *no* queued builds for x86_64 > on staging, but ci.guix.gnu.org web interface shows that there are > queued builds. > > kwayland is definitely broken on x86_64, so wayland users are invited to > fix it: > This is probably me, I was able to enable and run the kwayland tests on my machine but I think this test only fails when the machine is under load. > -- > The following tests FAILED: > 26 - kwayland-testPlasmaWindowModel (Failed) > Errors while running CTest > make: *** [Makefile:112: test] Error 8 > -- > > I've attached the full reports. > > My plan is to wait for feedback for a few days and, if I don't hear > otherwise, then merge the staging branch into master and push. Sounds good! -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Staging branch [substitute availability]
Hi Mathieu, Mathieu Othacehe skribis: > I have not connected the overdrives yet, so the aarch64 builds are still > 100% emulated. Regarding x86_64, I guess it's because it took ~1.5 days > for the CI to catch up, as you can see here: > https://ci.guix.gnu.org/metrics. What would it take to connect at least one OverDrive? How can the admins among us help? Before, when Danny reported issues with emulated builds, we stopped all emulated builds for AArch64/ARMv7 to avoid further breakage. So I guess we should try to get back to that situation. > "guix time-machine --branch=staging -- weather" now reports 82.7% > coverage for x86_64. Nice that it quickly gets better! >> `guix weather` said to me that there are *no* queued builds for x86_64 >> on staging, but ci.guix.gnu.org web interface shows that there are >> queued builds. > > That's because %query-limit is 1000 in (guix ci). It means that "guix > weather" will ask at most for the last 1000 queued builds. If they are > all aarch64 builds, then it will erroneously report that there are no > x86_64 queued builds. Fun. Not sure what the correct solution would be; perhaps make one /api/queue request per system type? Thanks! Ludo’.
Re: Staging branch [substitute availability]
Hey Leo, > So, minor improvements to aarch64, but x86_64 is actually worse! > Mathieu, I'm curious, are we using the overdrives again? Or still > emulating aarch64? I have not connected the overdrives yet, so the aarch64 builds are still 100% emulated. Regarding x86_64, I guess it's because it took ~1.5 days for the CI to catch up, as you can see here: https://ci.guix.gnu.org/metrics. "guix time-machine --branch=staging -- weather" now reports 82.7% coverage for x86_64. > `guix weather` said to me that there are *no* queued builds for x86_64 > on staging, but ci.guix.gnu.org web interface shows that there are > queued builds. That's because %query-limit is 1000 in (guix ci). It means that "guix weather" will ask at most for the last 1000 queued builds. If they are all aarch64 builds, then it will erroneously report that there are no x86_64 queued builds. Thanks, Mathieu
Re: Staging branch [substitute availability]
On Fri, Jan 22, 2021 at 03:46:45PM -0500, Leo Famulari wrote: > -- > master branch > aarch64: 72% > x86_64: 94% > i686: 86% > armhf: 46% > > staging branch > aarch64: 48% > x86_64: 79% > i686: 70% > armhf: 30% > -- Updates since the recent merge of master into staging: -- master branch aarch64: 72% x86_64: 94% i686: 86% armhf: 46% staging branch aarch64: 51% x86_64: 73% i686: 69% armhf: 27% -- So, minor improvements to aarch64, but x86_64 is actually worse! Mathieu, I'm curious, are we using the overdrives again? Or still emulating aarch64? `guix weather` said to me that there are *no* queued builds for x86_64 on staging, but ci.guix.gnu.org web interface shows that there are queued builds. kwayland is definitely broken on x86_64, so wayland users are invited to fix it: -- The following tests FAILED: 26 - kwayland-testPlasmaWindowModel (Failed) Errors while running CTest make: *** [Makefile:112: test] Error 8 -- I've attached the full reports. My plan is to wait for feedback for a few days and, if I don't hear otherwise, then merge the staging branch into master and push. computing 13,328 package derivations for aarch64-linux... http://ci.guix.gnu.org 72.4% substitutes available (10,073 out of 13,907) at least 53,877.7 MiB of nars (compressed) 80,315.8 MiB on disk (uncompressed) 0.002 seconds per request (32.6 seconds in total) 427.1 requests per second 0.0% (1 out of 3,834) of the missing items are queued at least 1,000 queued builds i686-linux: 94 (9.4%) aarch64-linux: 865 (86.5%) i586-gnu: 1 (.1%) x86_64-linux: 40 (4.0%) build rate: 181.65 builds per hour x86_64-linux: 56.68 builds per hour i686-linux: 65.97 builds per hour aarch64-linux: 59.25 builds per hour 1321 packages are missing from 'http://ci.guix.gnu.org' for 'aarch64-linux', among which: 2024 rust@1.21.0 /gnu/store/vwyns4ahdcfzn8nkzrm9airwblxh2805-rust-1.21.0-cargo /gnu/store/zdzyw3xf1cyqly0jsvhddw0l9vkl9d4p-rust-1.21.0-doc /gnu/store/hdv7kzpvnn2hr79rghnl0mchwcz8dg57-rust-1.21.0 835 clisp@2.49-92 /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 811 r-yaml@2.2.1 /gnu/store/d06vsnv4rbkz389g7wrh0xbr3mb37rbk-r-yaml-2.2.1 809 r-highr@0.8 /gnu/store/gjwsyw35p4c6cd7gqrnl4xjpgys6pic7-r-highr-0.8 782 ghc@7.10.2 /gnu/store/20dvxrmwp5p9b5pvb45152wh4sg7abb0-ghc-7.10.2-doc /gnu/store/2kz68x4abq6qz1zqkscqc41lcqhp14xi-ghc-7.10.2 397 elogind@243.7 /gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 246 r-r-cache@0.14.0 /gnu/store/2g3c41lnvir5rr5ppn3svf2acqzs2290-r-r-cache-0.14.0 245 php@7.4.14 /gnu/store/3ik44x007z9wfyi4gnx99hfhdfi5wazx-php-7.4.14 178 elogind@243.7 /gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 170 libpipeline@1.5.3 /gnu/store/6qi0yj1i61py5mhg02vll8b6gbjilngl-libpipeline-1.5.3 170 qgpgme@1.15.1 /gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 165 kwayland@5.70.0 /gnu/store/4cl7xivd43b8jpkbnc3ndmhibgk04skd-kwayland-5.70.0 151 qgpgme@1.15.1 /gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 149 java-testng@6.14.3 /gnu/store/hwdl2805anag91xkysnq8l2c34kyvj4m-java-testng-6.14.3 137 java-commons-lang@2.6 /gnu/store/cbiazsqhim38pvcxj8mxh27r3bgxjqq1-java-commons-lang-2.6-doc /gnu/store/mdx7giwafnprs31ncymzmppn9y3n6ybz-java-commons-lang-2.6 124 java-ops4j-base-monitors@1.5.0 /gnu/store/45g5x60b0n1bcrvvm8a3dfg1d3lg8zpr-java-ops4j-base-monitors-1.5.0 122 java-powermock-core@1.7.3 /gnu/store/m4qjvfxa4gc336h0qzckdmrwzl3jw76a-java-powermock-core-1.7.3 121 java-ops4j-base-util-property@1.5.0 /gnu/store/qxn68hgg1a89c4qqarm4j16i8z22mhyp-java-ops4j-base-util-property-1.5.0 121 java-javax-mail@1.5.6 /gnu/store/pvvqmz350vq6r71abm6fpyyw1g0297js-java-javax-mail-1.5.6 120 java-ops4j-base-spi@1.5.0 /gnu/store/6ddhzanvy5xcclsajqsv5lqhcpfdfaam-java-ops4j-base-spi-1.5.0 89 r-lazyeval@0.2.2 /gnu/store/wvwfx0qj0asssqa9rsjjzfs5j8bq46ds-r-lazyeval-0.2.2 81 qtwebkit@5.212.0-alpha4 /gnu/store/zdk4pbmfmnr0w85h7sky0cwq25yv34a3-qtwebkit-5.212.0-alpha4 81 hwloc@2.2.0 /gnu/store/4pbmc87q6n8zw8bw9wnlnhb1892dngd6-hwloc-2.2.0-debug /gnu/store/y26brf1zcccipqf2q990fhc6mnqjihm0-hwloc-2.2.0-doc /gnu/store/9vil275z0z0p6vy6q7a4ydwak83wk2cr-hwloc-2.2.0-lib /gnu/store/y905fmz3paa1jidinq54dbyag00iy3zr-hwloc-2.2.0 80 emacs-ansi@0.4.1-1.a41d5cc /gnu/store/z3p7rwyn4rhn8h8mvxw38wp7shc04wyg-emacs-ansi-0.4.1-1.a41d5cc 79 emacs-commander@0.7.0 /gnu/store/y3gi03ihd3l799qvb5r6zn51fqqlc43s-emacs-commander-0.7.0 77 r-nnet@7.3-14 /gnu/store/3caabkmnjjkd8wcp14ysqgwx2amijpa3-r-nnet-7.3-14 75 r-sourcetools@0.1.7 /gnu/store/5hiia42k7xvxz4ndxlab44dl4spv4m8j-r-sourcetools-0.1.7 73 r-jpeg@0.1-8.1 /gnu/store/bpyqgcnzby7dmy9cf2lllb3kqa74skq5-r-jpeg-0.1-8.1 69 ucx@1.6.1
Re: Staging branch [substitute availability]
Hi, > Freetype issue is fixed in version 9, but that > has other problems, such as making it impossible to unbundle the dozens > of libraries that we are currently unbundling [...] it is possible to > backport the VTK commits that fix Freetype compatibility, but it will be > a lot of work and a huge patch (it was a major cleanup IIRC)." I'm > CC-ing Ekaitz Zarraga, who has been working on FreeCAD. I'm not sure > what we can do about this problem in the short term. Marius, can you > give more info about the bundling problem? Sorry for the delay in the answer. I have no clue about what we can do. All the work I did with Freecad was related with other inputs and I didn't need to touch freetype. I don't know how I can help. If you have any specific question I'll do my best to try to answer it. Regards, Ekaitz
Re: Staging branch [substitute availability]
On Wed, Jan 13, 2021 at 05:30:53PM -0500, Leo Famulari wrote: > Using `guix weather`, we can check substitute availability for the > staging branch: > > -- > master branch > aarch64: 66% > x86_64: 93% > i686: 85% > armhf: 51% > > staging branch > aarch64: 44% > x86_64: 80% > i686: 60% > armhf: 30% > -- Updates since 9 days ago: -- master branch aarch64: 72% x86_64: 94% i686: 86% armhf: 46% staging branch aarch64: 48% x86_64: 79% i686: 70% armhf: 30% -- Some improvement can be seen. There are still a huge number of failures on CI that can't be reproduced locally, especially for aarch64. Since working around the failure of mesa on i686, that platform shows major improvement. The big failures on x86_64 are all rather niche — Java and OCaml mostly. armhf continues to decline because we are no longer building substitutes for it. There are some failures I think are important, though. For example, the vtk package is broken due to incompatibility with new Freetype, which breaks FreeCAD. On #guix, Marius said "I looked into VTK before the holidays; the Freetype issue is fixed in version 9, but that has other problems, such as making it impossible to unbundle the dozens of libraries that we are currently unbundling [...] it is possible to backport the VTK commits that fix Freetype compatibility, but it will be a lot of work and a huge patch (it was a major cleanup IIRC)." I'm CC-ing Ekaitz Zarraga, who has been working on FreeCAD. I'm not sure what we can do about this problem in the short term. Marius, can you give more info about the bundling problem? Full weather report attached, including failures of packages with at least 10 dependents. Can you identify any outstanding issues? Or are we ready to merge the branch into master? Although the numbers are lower for staging, the high rate of spurious failures and the successful system reconfigurations reported by Guix users makes me think that the situation is fine. computing 13,273 package derivations for aarch64-linux... http://ci.guix.gnu.org 71.7% substitutes available (9,935 out of 13,852) at least 53,537.1 MiB of nars (compressed) 79,971.0 MiB on disk (uncompressed) 0.002 seconds per request (26.9 seconds in total) 515.1 requests per second 0.0% (0 out of 3,917) of the missing items are queued 10 queued builds i586-gnu: 8 (80.0%) armhf-linux: 1 (10.0%) aarch64-linux: 1 (10.0%) build rate: 91.55 builds per hour x86_64-linux: 36.71 builds per hour aarch64-linux: 8.70 builds per hour i686-linux: 46.15 builds per hour 1279 packages are missing from 'http://ci.guix.gnu.org' for 'aarch64-linux', among which: 1989 rust@1.21.0 /gnu/store/vwyns4ahdcfzn8nkzrm9airwblxh2805-rust-1.21.0-cargo /gnu/store/zdzyw3xf1cyqly0jsvhddw0l9vkl9d4p-rust-1.21.0-doc /gnu/store/hdv7kzpvnn2hr79rghnl0mchwcz8dg57-rust-1.21.0 811 r-yaml@2.2.1 /gnu/store/d06vsnv4rbkz389g7wrh0xbr3mb37rbk-r-yaml-2.2.1 809 r-highr@0.8 /gnu/store/gjwsyw35p4c6cd7gqrnl4xjpgys6pic7-r-highr-0.8 807 clisp@2.49-92 /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 782 ghc@7.10.2 /gnu/store/20dvxrmwp5p9b5pvb45152wh4sg7abb0-ghc-7.10.2-doc /gnu/store/2kz68x4abq6qz1zqkscqc41lcqhp14xi-ghc-7.10.2 397 elogind@243.7 /gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 246 r-r-cache@0.14.0 /gnu/store/2g3c41lnvir5rr5ppn3svf2acqzs2290-r-r-cache-0.14.0 245 php@7.4.14 /gnu/store/3ik44x007z9wfyi4gnx99hfhdfi5wazx-php-7.4.14 205 git@2.30.0 /gnu/store/9ryjn5x9as9s6phzbjikvigjif1bdsbv-git-2.30.0-credential-netrc /gnu/store/magms2ibjvsn1l6kb1lps207vha7vyg8-git-2.30.0-gui /gnu/store/dq03y0xjlji1k8qh1l1nzx3lf4ykngb6-git-2.30.0 /gnu/store/y3fghhd8nca08j8zlwvqsvzr9m0nv14r-git-2.30.0-send-email /gnu/store/xn8nnx6b11ks8n4s5x9x6w9y08j92scf-git-2.30.0-subtree /gnu/store/g3yg5ixwwlr9sgkv143prln4czq5xcj7-git-2.30.0-svn 178 elogind@243.7 /gnu/store/6lsrwi88632ybrj14059brb1xcycfq8f-elogind-243.7 170 libpipeline@1.5.3 /gnu/store/6qi0yj1i61py5mhg02vll8b6gbjilngl-libpipeline-1.5.3 170 qgpgme@1.15.1 /gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 165 kwayland@5.70.0 /gnu/store/4cl7xivd43b8jpkbnc3ndmhibgk04skd-kwayland-5.70.0 151 qgpgme@1.15.1 /gnu/store/pdg9g412blki37gk9bhyh3fqhf1qr59m-qgpgme-1.15.1 149 java-testng@6.14.3 /gnu/store/hwdl2805anag91xkysnq8l2c34kyvj4m-java-testng-6.14.3 137 java-commons-lang@2.6 /gnu/store/cbiazsqhim38pvcxj8mxh27r3bgxjqq1-java-commons-lang-2.6-doc /gnu/store/mdx7giwafnprs31ncymzmppn9y3n6ybz-java-commons-lang-2.6 124 java-ops4j-base-monitors@1.5.0 /gnu/store/45g5x60b0n1bcrvvm8a3dfg1d3lg8zpr-java-ops4j-base-monitors-1.5.0 123 python-distlib@0.3.1 /gnu/store/gwrq1fk4rxf9p41i7681xf8vdjhlznda-python-distlib-0.3.1 122 java-powermock-core@1.7.3 /gnu/store/m4qjvfxa4gc336h0qzckdmrwzl3jw76a-java-powermock-core-1.7.3 121
Re: Staging branch [substitute availability i686-linux]
On Wed, Jan 13, 2021 at 07:22:35PM -0500, Leo Famulari wrote: > I've reported this upstream: > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091 Upstream cannot reproduce the test failure. I disabled the test in commit 8b55544212a90b0276df49596a3d373e5c2e8f5c and now mesa has built for i686-linux.
Re: Staging branch [substitute availability armhf-linux]
Sorry, I forgot to attach that config.(use-modules (gnu bootloader)
(gnu bootloader u-boot)
(gnu services base)
(gnu system)
(gnu system image)
(gnu system file-systems)
(guix channels)
(guix inferior)
(srfi srfi-1))
(define wip-pinebook
(list (channel (name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "wip-pinebook-pro")
(introduction
(make-channel-introduction
"47a5442aa7dad8b1904483954e91640c3cac5e90"
(openpgp-fingerprint
"658073613BFCC5C7E2E45D45DC518FC87F9716AA"))
(define inferior-pinebook (inferior-for-channels wip-pinebook))
(operating-system
(host-name "test")
(timezone "US/Eastern")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-pinebook-pro-rk3399-bootloader)
(target "/dev/vda")))
(kernel (first (lookup-inferior-packages inferior-pinebook
"linux-libre-pinebook-pro")))
(kernel-arguments (cons* "video=HDMI-A-1:1920x1080@60"
"video=eDP-1:1920x1080@60"
"vga=current"
%default-kernel-arguments))
(initrd-modules '())
(file-systems (cons (file-system
(device (file-system-label root-label))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "test")
(group "users")
(supplementary-groups '("wheel"))
(password (crypt "test" "$5$ca")))
%base-user-accounts))
(services (cons* (service agetty-service-type
(agetty-configuration
(extra-options '("-L"))
(baud-rate "150")
(term "vt100")
(tty "ttyS2")))
%base-services)))
Re: Staging branch [substitute availability armhf-linux]
Hi, > > LCD output, nothing answering on serial console (@1.5Mbps > > (uboot speed) or 115.2Kbps (kernel speed, I think)). Both kernel and u-boot use 150 baud. > Strange, seems that Caliph did manage to get a serial console. Caliph, > any insight here? A configuration close to the pinebook-pro-barebones-os configuration worked for me software-wise (albiet, without LCD output), but there's a few hardware tweaks that need to be done to get it working. On the mainboard there's two switches: an eMMC disable switch and a serial output switch. The serial output switch needs to be set properly to get serial out through the headphone jack. Nominally you should also disable the internal eMMC if there's anything on it in order to use Guix's u-boot, but I wasn't able to get the switch to work so I just removed the eMMC flash. From the log posted earlier, it does look like that's the case, so it's booting from the factory-default 2017 u-boot with blobs. I just realized that the configuration I used had one (significant) change: agetty needs to be started on /dev/ttyS2, not /dev/ttyS0. I have just submitted a patch to fix this (https://issues.guix.gnu.org/45997). To get the LCD up, I used an inferior with linux-libre-pinebook-pro from the wip-pinebook-pro branch, and included some kernel arguments from janneke that Mathieu told me about, though I'm unsure how necessary they are with the kernel patches. I have also heard that disabling CONFIG_ROCKCHIP_CDN_DP on mainline would work too, but I haven't tested it. I'll attach a config that should work to bring up serial and the LCD. Hope this helps.
Re: Staging branch [substitute availability aarch64-linux]
On Mon, Jan 18, 2021 at 12:19:59PM +0200, Efraim Flashner wrote: > Just finished building llvm, took 14.5 hours and RAM+swap went over > 3.5GB at certain points that I checked. Wow! Thank you very much for checking.
Re: Staging branch [substitute availability aarch64-linux]
Just finished building llvm, took 14.5 hours and RAM+swap went over 3.5GB at certain points that I checked. On Sun, Jan 17, 2021 at 09:50:27PM +0200, Efraim Flashner wrote: > On Wed, Jan 13, 2021 at 06:38:39PM -0500, Leo Famulari wrote: > > For aarch64-linux, the biggest problems are LLVM and Rust, but there are > > other major problems such as nss-certs. > > > > Are LLVM and Rust expected to work on this platform within Guix? What > > about GHC? > > llvm should work, I'll start a build now on my pine64 and see how it > goes. GHC has only ever been supported on x86_64 and i686, those are the > blessed bootstrap downloads we have currently. > > For most of the others on the list I believe I have built them > successfully on my pine64, going down to weather -c 100 or 75. Clisp > definitely built. > > > -- > > 3509 packages are missing from 'https://ci.guix.gnu.org' for > > 'aarch64-linux', among which: > > 2193 llvm@11.0.0 > > /gnu/store/b9mk756wjyrrf51aw2sbjk2cmi6v1xvl-llvm-11.0.0-opt-viewer > > /gnu/store/kn6lssvq2akf7pq36krdxc3w8fir7cwv-llvm-11.0.0 > > 1988 rust@1.21.0 > > /gnu/store/7r6n32fz9cyyr5yv0505nw6c8w93g2mv-rust-1.21.0-cargo > > /gnu/store/04dy3g0dmzhz5djakgd44lm8xnw871l0-rust-1.21.0-doc > > /gnu/store/lf6kyhsdn2l0namvzhn2hm7rmv7zm6h2-rust-1.21.0 > >792 clisp@2.49-92 > > /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 > >781 ghc@7.10.2 > > /gnu/store/gi463h584b8r7krdbp3dzb7hx3nv83fy-ghc-7.10.2-doc > > /gnu/store/y32p7z1569qzmc4z3yx592l3w7x2zcai-ghc-7.10.2 > >682 python-cryptography-vectors@3.3.1 > > /gnu/store/4n2kcsvxlh0n3rvpjgrfvs8pi5nh5b6i-python-cryptography-vectors-3.3.1 > > > >576 nss-certs@3.59 > > /gnu/store/n43chb4cpgn5cwj73d4bywq6vvahiqxa-nss-certs-3.59 > >337 go@1.4-bootstrap-20171003 > > /gnu/store/cxm5py5p7wwgskjlfn6009mwql906884-go-1.4-bootstrap-20171003-doc > > /gnu/store/h5bbkxnad8lxvp2kqpmfz26wbv5w9i6h-go-1.4-bootstrap-20171003 > > /gnu/store/qwr2kwxmmj6zyibgl586qx0gl7vq6hl2-go-1.4-bootstrap-20171003-tests > >244 php@7.4.14 > > /gnu/store/2pzqq029qg9k2ybp0zbkzc9syfj5s1qy-php-7.4.14 > >186 openbox@3.6.1 > > /gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 > >181 kcoreaddons@5.70.0 > > /gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 > > > > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Staging branch [substitute availability aarch64-linux]
On Wed, Jan 13, 2021 at 06:38:39PM -0500, Leo Famulari wrote: > For aarch64-linux, the biggest problems are LLVM and Rust, but there are > other major problems such as nss-certs. > > Are LLVM and Rust expected to work on this platform within Guix? What > about GHC? llvm should work, I'll start a build now on my pine64 and see how it goes. GHC has only ever been supported on x86_64 and i686, those are the blessed bootstrap downloads we have currently. For most of the others on the list I believe I have built them successfully on my pine64, going down to weather -c 100 or 75. Clisp definitely built. > -- > 3509 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', > among which: > 2193llvm@11.0.0 > /gnu/store/b9mk756wjyrrf51aw2sbjk2cmi6v1xvl-llvm-11.0.0-opt-viewer > /gnu/store/kn6lssvq2akf7pq36krdxc3w8fir7cwv-llvm-11.0.0 > 1988rust@1.21.0 > /gnu/store/7r6n32fz9cyyr5yv0505nw6c8w93g2mv-rust-1.21.0-cargo > /gnu/store/04dy3g0dmzhz5djakgd44lm8xnw871l0-rust-1.21.0-doc > /gnu/store/lf6kyhsdn2l0namvzhn2hm7rmv7zm6h2-rust-1.21.0 >792clisp@2.49-92 > /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 >781ghc@7.10.2 > /gnu/store/gi463h584b8r7krdbp3dzb7hx3nv83fy-ghc-7.10.2-doc > /gnu/store/y32p7z1569qzmc4z3yx592l3w7x2zcai-ghc-7.10.2 >682python-cryptography-vectors@3.3.1 > /gnu/store/4n2kcsvxlh0n3rvpjgrfvs8pi5nh5b6i-python-cryptography-vectors-3.3.1 >576nss-certs@3.59 > /gnu/store/n43chb4cpgn5cwj73d4bywq6vvahiqxa-nss-certs-3.59 >337go@1.4-bootstrap-20171003 > /gnu/store/cxm5py5p7wwgskjlfn6009mwql906884-go-1.4-bootstrap-20171003-doc > /gnu/store/h5bbkxnad8lxvp2kqpmfz26wbv5w9i6h-go-1.4-bootstrap-20171003 > /gnu/store/qwr2kwxmmj6zyibgl586qx0gl7vq6hl2-go-1.4-bootstrap-20171003-tests >244php@7.4.14 > /gnu/store/2pzqq029qg9k2ybp0zbkzc9syfj5s1qy-php-7.4.14 >186openbox@3.6.1 > /gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 >181kcoreaddons@5.70.0 > /gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Staging branch [substitute availability armhf-linux]
On Sun, Jan 17, 2021 at 12:01 PM Mathieu Othacehe wrote: > you should be able to download this image. Yep, I DL'ed and got the same result as with my own images, so my building is not be the problem. > Yes looks like the search pagination and ordering is broken, those are > definitely bugs that you can report. Done : https://issues.guix.gnu.org/45936 -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
> That's slightly different than what I have been doing, but > the resulting image has the same problem than mine, no > LCD output, nothing answering on serial console (@1.5Mbps > (uboot speed) or 115.2Kbps (kernel speed, I think)). Strange, seems that Caliph did manage to get a serial console. Caliph, any insight here? > Does cuirass only remove the link after a while after the image has > been gc'ed ? Yes turns out it was a regression due to PostgreSQL switch, this is now solved and you should be able to download this image. Mathieu
Re: Staging branch [substitute availability armhf-linux]
On Sun, Jan 17, 2021 at 11:17 AM Mathieu Othacehe wrote: > --8<---cut here---start->8--- > guix build -f pinebook.scm > --8<---cut here---end--->8--- > > should achieve the same result locally. That's slightly different than what I have been doing, but the resulting image has the same problem than mine, no LCD output, nothing answering on serial console (@1.5Mbps (uboot speed) or 115.2Kbps (kernel speed, I think)). > > That's where I searched, but did not find one with > > the "Build outputs" link like the one you cited. > > > > Why is 190783 different from the 6 other ones returned > > by this search query ? > > Because I just enabled build outputs production for Pinebook Pro images. Does cuirass only remove the link after a while after the image has been gc'ed ? > > BTW, I think there is a problem in the way Cuirass web UI sorts > > its results (apparently by oldest to newest, on the completion > > time column) it looks like it is doing a string comparison, where > > "32 minutes ago" is older than "37 hours ago". The "<< < > >>" > > buttons also act strangely. Do you see such things ? > > Should I report them as bugs ? > > Yes looks like the search pagination and ordering is broken, those are > definitely bugs that you can report. I'll do it later today Thanks -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello, > trying to DL (in browser or with wget) the build output, by using > the "https://ci.guix.gnu.org/download/190783; link, I get: > error "Could not find the request build product." Oh, it's already been garbage collected on Berlin, sorry about that :(. I'll see what I can do. In the meantime, running the attached file this way: --8<---cut here---start->8--- guix build -f pinebook.scm --8<---cut here---end--->8--- should achieve the same result locally. > That's where I searched, but did not find one with > the "Build outputs" link like the one you cited. > > Why is 190783 different from the 6 other ones returned > by this search query ? Because I just enabled build outputs production for Pinebook Pro images. > BTW, I think there is a problem in the way Cuirass web UI sorts > its results (apparently by oldest to newest, on the completion > time column) it looks like it is doing a string comparison, where > "32 minutes ago" is older than "37 hours ago". The "<< < > >>" > buttons also act strangely. Do you see such things ? > Should I report them as bugs ? Yes looks like the search pagination and ordering is broken, those are definitely bugs that you can report. Mathieu pinebook.scm Description: Binary data
Re: Staging branch [substitute availability armhf-linux]
Hello, Thanks On Sun, Jan 17, 2021 at 10:35 AM Mathieu Othacehe wrote: > You can download the latest Pinebook Pro image here: > > https://ci.guix.gnu.org/build/190783/details trying to DL (in browser or with wget) the build output, by using the "https://ci.guix.gnu.org/download/190783; link, I get: error "Could not find the request build product." > to search for the latest images: > > https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro That's where I searched, but did not find one with the "Build outputs" link like the one you cited. Why is 190783 different from the 6 other ones returned by this search query ? BTW, I think there is a problem in the way Cuirass web UI sorts its results (apparently by oldest to newest, on the completion time column) it looks like it is doing a string comparison, where "32 minutes ago" is older than "37 hours ago". The "<< < > >>" buttons also act strangely. Do you see such things ? Should I report them as bugs ? Tchuss -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello Vincent, You can download the latest Pinebook Pro image here: https://ci.guix.gnu.org/build/190783/details to search for the latest images: https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hello, > > I even attempted building the pinebook pro image without success. > > Hm... it's a shame we are building this and it doesn't work. I only tried my locally built one, is there a substitute that I can try ? That would tell if the problem is on my side or not. > Do you also use some armhf (32-bit) hardware? I would like. I tried and failed (I tried to build an image for an orangepi+2e) I have other non-x86 HW that I would like to have guixsd on. I don't ask for susbstitutes, I can build them locally if needed and doable. -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
On Fri, Jan 15, 2021 at 09:27:36AM +0100, Vincent Legoll wrote: > On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote: > > Specifically about armhf, if anybody wants to use it with Guix, I hope > > they will speak up. > > I am interested, I have tried, and failed to get anything (apart from guix > on foreign armbian). But I am more interested in guixsd though. Okay, thanks for letting us know. > I even attempted building the pinebook pro image without success. Hm... it's a shame we are building this and it doesn't work. Do you also use some armhf (32-bit) hardware?
Re: Staging branch [substitute availability]
Mathieu Othacehe writes: > Now, how to move on? > > First, I still need to connect the four overdrives machine to the new > Cuirass remote building mechanism, and I would need some help for that > (asked on guix-sysadmins). But, I'm not sure it will much improve the > situation. > > Longer term, we need to figure out a better solution. It's now > obvious that we do not have the computation power to build all our > branches for 5 different architectures, relying heavily on emulation for > armhf and aarch64. Anyone knows how Nix deals with that? Providing that the more important builds/architectures are prioritised, I don't think it's an all or nothing situation. For build farms providing substitutes, it's more about the time taken to catch up with changes. When I've tried emulation, I've found there are too many errors that only occur when emulating. signature.asc Description: PGP signature
Re: Staging branch [substitute availability armhf-linux]
Hello, On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe wrote: > It seems that Caliph Nomble succeeded to build a Pinebook Pro image and > booted it, without graphics, after a few fixes: > https://issues.guix.gnu.org/45584. > > You may want to try again :). DONE, it's a bit better, this time initrd, kernel & dtb loaded properly. But serial output stopped after "Starting kernel ..." which is probably because of mismatched serial port speed, but I tried to relaunch screen with 57600, 115200 and still go no output. [complete uboot log attached] LCD screen stays black which is probably normal. The image was built like the following: # ./pre-inst-env guix describe Git checkout: repository: /home/vince/dev/repo/guix branch: master commit: c03875b0361f114634caeb54935fe37a9b7b05af # echo "(use-modules (gnu system images pinebook-pro)) pinebook-pro-barebones-os" > /tmp/os.scm # ./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm [...] /gnu/store/5fj3aha8jsyji9mpqzf2krakl08r9zlw-disk-image Next I'll try the hints from: https://issues.guix.gnu.org/45584 > >> There is almost no armhf hardware that is suitable > >> for a build-from-source distro in terms of performance, thermal design > >> and suitable storage (SD cards will not last for unless you pay a huge > >> amount for the absolute highest quality). Binary distros like Trisquel > >> are a much better option for armhf. > > > > The cross buildability *should* be kind of a solution for this. > > Yes we could always decide to stop supporting native ARMv7 substitutes > and only focus on the cross-building to provide ready to use image for > this architecture. Isn't there a way to reconcile the 2 ? At least theoretically cross- or native- compilation should give identical output, though I dunno how far that is from reality (probably not good, or we would be doing just that) > >> All that is not a reason to not support armhf, but if nobody is using > >> it, then we should officially deprecate it, and not leave it in this > >> in-between state. > > > > I'm not using it because I can't make it work. > > Don't hesitate to report the issues you encountered! I've done it a few times already, for armhf, arm64, powerpc64, mipsel. And I'll (re-)try anything if I'm hinted as what to try next. The main problem from my PoV is the scatteredness of the infos. Tchuss -- Vincent Legoll DDR Version 1.20 20190314 In channel 0 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 800MHz 1,0 Channel 0: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 251 SdmmcInit=2 0 BootCapSize=10 UserCapSize=119276MB FwPartOffset=2000 , 10 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=30528MB FwPartOffset=2000 , 0 StorageInit ok = 191888 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 LoadTrust Addr:0x4400 LoadTrust Addr:0x4800 LoadTrust Addr:0x4c00 LoadTrust Addr:0x5000 LoadTrust Addr:0x5400 LoadTrust Addr:0x5800 LoadTrust Addr:0x5c00 Addr:0x4000 No find trust.img! LoadTrustBL error:-3 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail!
Re: Staging branch [substitute availability armhf-linux]
Hello Vincent, > I even attempted building the pinebook pro image without success. It seems that Caliph Nomble succeeded to build a Pinebook Pro image and booted it, without graphics, after a few fixes: https://issues.guix.gnu.org/45584. You may want to try again :). >> There is almost no armhf hardware that is suitable >> for a build-from-source distro in terms of performance, thermal design >> and suitable storage (SD cards will not last for unless you pay a huge >> amount for the absolute highest quality). Binary distros like Trisquel >> are a much better option for armhf. > > The cross buildability *should* be kind of a solution for this. Yes we could always decide to stop supporting native ARMv7 substitutes and only focus on the cross-building to provide ready to use image for this architecture. >> All that is not a reason to not support armhf, but if nobody is using >> it, then we should officially deprecate it, and not leave it in this >> in-between state. > > I'm not using it because I can't make it work. Don't hesitate to report the issues you encountered! Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hey Ludo, > You seem to imply that the issue is the number of architectures, rather > than the small number of ARMv7 build machines (now that we disabled > 32-bit builds on AArch64). Do I get it right? Yes my point is that building three specifications on three architectures, including an emulated one, is already hard for the build farm, so adding more specifications/architectures seems complex. Even if we fix the problem raised by Danny, enabling again ARMv7 transparent emulation, without any additional hardware wouldn't fit. > That was a problem with Cuirass doing ‘build-derivations’ RPCs for > derivations spanning multiple architectures (the RPC would complete once > the slowest architecture is done), but maybe that’s no longer the case > with the new remote builds feature you’ve been working on? Yes, that's solved by the remote building feature. The workers are declaring the architectures they support. When they request work, the remote server picks randomly an architecture and select the most priority build available. This way the queuing happens at the database level and not in the guix-daemon itself. Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hello, On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote: > Specifically about armhf, if anybody wants to use it with Guix, I hope > they will speak up. I am interested, I have tried, and failed to get anything (apart from guix on foreign armbian). But I am more interested in guixsd though. I even attempted building the pinebook pro image without success. > I think we should monitor the volume of substitute requests per platform > and see how big the demand for armhf Guix really is. With the current situation, I'm not sure this would really be representative of the armhf or arm64 demand. > Although there is a huge amount of armhf hardware deployed, Guix seems a > very poor fit for it. In its current state. > There is almost no armhf hardware that is suitable > for a build-from-source distro in terms of performance, thermal design > and suitable storage (SD cards will not last for unless you pay a huge > amount for the absolute highest quality). Binary distros like Trisquel > are a much better option for armhf. The cross buildability *should* be kind of a solution for this. > All that is not a reason to not support armhf, but if nobody is using > it, then we should officially deprecate it, and not leave it in this > in-between state. I'm not using it because I can't make it work. -- Vincent Legoll
Re: Staging branch [substitute availability i686-linux]
On Thu, Jan 14, 2021 at 11:37:39PM +0100, Ricardo Wurmus wrote: > > Leo Famulari writes: > > > For i686-linux: > > > > Should we even be attempting to build Rust on this platform? Has it ever > > worked? What about the ant-bootstrap? > […] > >580 ant-bootstrap@1.8.4 > > /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4 > > This should work on i686 IIRC. Indeed, it appears to have been built. Sorry for the noise.
Re: Staging branch [substitute availability armhf-linux]
On Thu, Jan 14, 2021 at 09:44:17AM +0100, Mathieu Othacehe wrote: > Your weather summary is a great idea, thanks! As I said in my previous > email, the armhf substitutes are not built right now on the CI. It's > really sad but we have to make an impossible choice between: Specifically about armhf, if anybody wants to use it with Guix, I hope they will speak up. I would have expected to hear from users that they were not getting any substitutes. I think we should monitor the volume of substitute requests per platform and see how big the demand for armhf Guix really is. Although there is a huge amount of armhf hardware deployed, Guix seems a very poor fit for it. There is almost no armhf hardware that is suitable for a build-from-source distro in terms of performance, thermal design and suitable storage (SD cards will not last for unless you pay a huge amount for the absolute highest quality). Binary distros like Trisquel are a much better option for armhf. All that is not a reason to not support armhf, but if nobody is using it, then we should officially deprecate it, and not leave it in this in-between state.
Re: Staging branch [substitute availability i686-linux]
Leo Famulari writes: > For i686-linux: > > Should we even be attempting to build Rust on this platform? Has it ever > worked? What about the ant-bootstrap? […] >580 ant-bootstrap@1.8.4 > /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4 This should work on i686 IIRC. -- Ricardo
Re: Staging branch [substitute availability]
Mathieu Othacehe skribis: > Since the introduction of the "wip-offload" branch on Cuirass, the > situation has much improved. The workers are constantly building. For > now we are building three specifications: > > * guix-modular-master > * guix-master > * staging Yay! > for x86_64, i686 and aarch64. If you look at the "Pending builds" chart > here[1], you will see that the CI is barely catching up. That's because > the "aarch64" emulated builds are incredibly slow, and monopolizing all > the build resources. > > I deliberately chose to put armhf aside until I have a clearer view of > the situation. > > Now, how to move on? > > First, I still need to connect the four overdrives machine to the new > Cuirass remote building mechanism, and I would need some help for that > (asked on guix-sysadmins). But, I'm not sure it will much improve the > situation. Oh sorry, I still haven’t caught up from vacation but I’ll take a look if nobody beats me at it. > Longer term, we need to figure out a better solution. It's now > obvious that we do not have the computation power to build all our > branches for 5 different architectures, relying heavily on emulation for > armhf and aarch64. Anyone knows how Nix deals with that? I’m not sure, but I know they rent storage and processing power from a big transnational company, and that may well include AArch64. Note that we disabled emulated builds and ARMv7 builds on AArch64 (!) when Danny discovered the _FILE_OFFSET_BITS issue, which makes things much worse. With the x86_64 machines we have in Berlin, using emulated builds, even if they’re slow, could potentially help noticeably. At this point the biggest issue is ARMv7 because we have too little actual hardware. > I guess that other major distributions provide only cross-compiled > packages for those architectures, but I don't think it's an option for > us, Ludo? Cross-compiled derivations are different derivations, so no, it’s not an option. If people know what hardware to get, and if we can find people to host it, we have enough funds to buy it. On IRC yesterday Leo mentioned a good-looking AArch64 board: https://shop.solid-run.com/product/SRLX216S00D00GE064H07CH/ For ARMv7, there are probably several known-good options like those by Olimex, BeagleBoard (I think?) and the likes. For any such candidate, we need to (1) check it can be used with free software only, (2) check things like provided storage space, whether a case is available, etc., and (3) plan for purchase and hosting. Volunteers needed! Thanks, Ludo’.
Re: Staging branch [substitute availability armhf-linux]
Hi, Mathieu Othacehe skribis: > Your weather summary is a great idea, thanks! As I said in my previous > email, the armhf substitutes are not built right now on the CI. It's > really sad but we have to make an impossible choice between: > > * Trying to build everything on all architecture and have the CI that is > awfully lagging behind. > > * Restrict the number of architecture we want to provide substitutes > for. You seem to imply that the issue is the number of architectures, rather than the small number of ARMv7 build machines (now that we disabled 32-bit builds on AArch64). Do I get it right? That was a problem with Cuirass doing ‘build-derivations’ RPCs for derivations spanning multiple architectures (the RPC would complete once the slowest architecture is done), but maybe that’s no longer the case with the new remote builds feature you’ve been working on? Ludo’.
Re: Staging branch [substitute availability]
Mathieu, Mathieu Othacehe 写道： As I said, the new remote building Cuirass mechanism is not yet deployed on those machines and I would need someone with login access to reconfigure those machines for me. I reconfigured dmitri and have now also restarted guix-daemon. Is there anything more I need to do? Remotely rebooting has proven risky in the past. The situation is worse for x86_64: 96% idleness based on /proc/uptime. Am I misinterpreting? On what machine? All build nodes (141.*). Kind regards, T G-R signature.asc Description: PGP signature
Re: Staging branch [substitute availability]
Hello Jonathan, > I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM > servers for native building. See https://build.opensuse.org/monitor Thanks for sharing, I like very much the design of this page, I might take some ideas from it to improve https://ci.guix.gnu.org/workers. > Some weeks ago i did some research on ARM servers. TL;DR There are some > options, even fast ones, but its not easy to found shops who sell them and > have them in stock... True, you even proposed to contact Linaro to see if they were willing to provide us some aarch64 VM. I think it would be great :). Thanks, Mathieu
Re: Staging branch [substitute availability armhf-linux]
Hi Mathieu, I have not read carefully all the emails on the topic, so I am probably out-of-scope. On Thu, 14 Jan 2021 at 09:44, Mathieu Othacehe wrote: > * Trying to build everything on all architecture and have the CI that is > awfully lagging behind. > > * Restrict the number of architecture we want to provide substitutes > for. Maybe we could use Bayfront and the recent Fosshost donation differently and so use them to cross-compile, removing the x86 builds on them. Cheers, simon
Re: Staging branch [substitute availability]
Hello Tobias, > I don't think it's obvious and I don't think it's true. Well obvious was a poor choice of word. But I've been spending several weeks/months monitoring Berlin and I think I'm starting to have a good overview of the situation. This new page[1] shows what the build machines are doing. There are two workers per machine, and they are always busy as far as I can tell. If you have a look to the "Pending builds" chart here[2], you will see that it took 4 days to absorb the ~7000 builds that were added the 9/10th of January. Building chromium for aarch64 takes more than 24 hours and will take one whole worker down for instance. Now think about Linux, webkitgtk and imagine that we also want to build the core-updates branch and the armhf architecture, I don't see how it could fit without lagging weeks behind. > Only because we don't use the non-emulated hardware. Our (currently 3, one > crashed) Overdrives 1000 sit idle for ~90% of the time. As I said, the new remote building Cuirass mechanism is not yet deployed on those machines and I would need someone with login access to reconfigure those machines for me. > The situation is worse for x86_64: 96% idleness based on /proc/uptime. Am I > misinterpreting? On what machine? If it's on the Berlin main node, it's by design. We don't want the main machine to build things as it interferes too much with the other stuff happening on that machine such as gc'ing a huge store, hosting Cuirass and other services. Thanks, Mathieu [1]: https://ci.guix.gnu.org/workers [2]: https://ci.guix.gnu.org/metrics
Re: Staging branch [substitute availability]
Mathieu! Mathieu Othacehe 写道： Longer term, we need to figure out a better solution. It's now obvious that we do not have the computation power to build all our branches for 5 different architectures I don't think it's obvious and I don't think it's true. relying heavily on emulation for armhf and aarch64. Only because we don't use the non-emulated hardware. Our (currently 3, one crashed) Overdrives 1000 sit idle for ~90% of the time. The situation is worse for x86_64: 96% idleness based on /proc/uptime. Am I misinterpreting? Kind regards, T G-R signature.asc Description: PGP signature
Re: Staging branch [substitute availability]
Am Thu, 14 Jan 2021 09:39:41 +0100, Mathieu Othacehe schrieb: > First, I still need to connect the four overdrives machine to the new > Cuirass remote building mechanism, and I would need some help for that > (asked on guix-sysadmins). But, I'm not sure it will much improve the > situation. > > Longer term, we need to figure out a better solution. It's now > obvious that we do not have the computation power to build all our > branches for 5 different architectures, relying heavily on emulation for > armhf and aarch64. Anyone knows how Nix deals with that? I can not speak for Nix, but openSUSE has around 10 more or less powerful ARM servers for native building. See https://build.opensuse.org/monitor Some weeks ago i did some research on ARM servers. TL;DR There are some options, even fast ones, but its not easy to found shops who sell them and have them in stock... -- Sent from Ubuntu Touch
Re: Staging branch [substitute availability armhf-linux]
> The armhf-linux platform is in the worst shape, both on the master and > staging branches. It's a shame because it's also the least powerful, > with almost no hardware thermally capable of sustained CPU usage, so > users will have the worst experience building packages for it. > > Does anyone want to work on it? Should we just "fix it on the master > branch?" Your weather summary is a great idea, thanks! As I said in my previous email, the armhf substitutes are not built right now on the CI. It's really sad but we have to make an impossible choice between: * Trying to build everything on all architecture and have the CI that is awfully lagging behind. * Restrict the number of architecture we want to provide substitutes for. Thanks, Mathieu
Re: Staging branch [substitute availability]
Hello Leo, > -- > master branch > aarch64: 66% > x86_64: 93% > i686: 85% > armhf: 51% > > staging branch > aarch64: 44% > x86_64: 80% > i686: 60% > armhf: 30% > -- Thanks for the figures. I can comment on some stuff. Until recently it was hard to monitor the build farm status because there were a lot of contention at the main guix-daemon level. Since the introduction of the "wip-offload" branch on Cuirass, the situation has much improved. The workers are constantly building. For now we are building three specifications: * guix-modular-master * guix-master * staging for x86_64, i686 and aarch64. If you look at the "Pending builds" chart here[1], you will see that the CI is barely catching up. That's because the "aarch64" emulated builds are incredibly slow, and monopolizing all the build resources. I deliberately chose to put armhf aside until I have a clearer view of the situation. Now, how to move on? First, I still need to connect the four overdrives machine to the new Cuirass remote building mechanism, and I would need some help for that (asked on guix-sysadmins). But, I'm not sure it will much improve the situation. Longer term, we need to figure out a better solution. It's now obvious that we do not have the computation power to build all our branches for 5 different architectures, relying heavily on emulation for armhf and aarch64. Anyone knows how Nix deals with that? I guess that other major distributions provide only cross-compiled packages for those architectures, but I don't think it's an option for us, Ludo? Thanks, Mathieu [1]: https://ci.guix.gnu.org/metrics
Re: Staging branch [substitute availability aarch64-linux]
I’ve been working on ghc and making some progress. I’d love to have more support for rust but I’m not sure what the issue is.
Re: Staging branch [substitute availability i686-linux]
On Wed, Jan 13, 2021 at 06:33:04PM -0500, Leo Famulari wrote: > The mesa test suite failure is reproducible, and it looks like this: > > -- > 23:07:53 /tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test > --- stdout --- > Running main() from ../mesa-20.2.4/src/gtest/src/gtest_main.cc > [==] Running 2 tests from 1 test suite. > [--] Global test environment set-up. > [--] 2 tests from u_debug_stack_test > [ RUN ] u_debug_stack_test.basics > [ OK ] u_debug_stack_test.basics (0 ms) > [ RUN ] u_debug_stack_test.capture_not_overwritten > ../mesa-20.2.4/src/util/u_debug_stack_test.cpp:108: Failure > Expected: (bt1) != (bt2), actual: > "/tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test() > [0x8072555] > " vs "/tmp/guix-build-mesa-20.2.4.drv-0/build/src/util/u_debug_stack_test() > [0x8072555] > " > [ FAILED ] u_debug_stack_test.capture_not_overwritten (0 ms) I've reported this upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091
Re: Staging branch [substitute availability aarch64-linux]
For aarch64-linux, the biggest problems are LLVM and Rust, but there are other major problems such as nss-certs. Are LLVM and Rust expected to work on this platform within Guix? What about GHC? -- 3509 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', among which: 2193 llvm@11.0.0 /gnu/store/b9mk756wjyrrf51aw2sbjk2cmi6v1xvl-llvm-11.0.0-opt-viewer /gnu/store/kn6lssvq2akf7pq36krdxc3w8fir7cwv-llvm-11.0.0 1988 rust@1.21.0 /gnu/store/7r6n32fz9cyyr5yv0505nw6c8w93g2mv-rust-1.21.0-cargo /gnu/store/04dy3g0dmzhz5djakgd44lm8xnw871l0-rust-1.21.0-doc /gnu/store/lf6kyhsdn2l0namvzhn2hm7rmv7zm6h2-rust-1.21.0 792 clisp@2.49-92 /gnu/store/0xq1g699icg8izrji5pdqn1qfn5yjc6b-clisp-2.49-92 781 ghc@7.10.2 /gnu/store/gi463h584b8r7krdbp3dzb7hx3nv83fy-ghc-7.10.2-doc /gnu/store/y32p7z1569qzmc4z3yx592l3w7x2zcai-ghc-7.10.2 682 python-cryptography-vectors@3.3.1 /gnu/store/4n2kcsvxlh0n3rvpjgrfvs8pi5nh5b6i-python-cryptography-vectors-3.3.1 576 nss-certs@3.59 /gnu/store/n43chb4cpgn5cwj73d4bywq6vvahiqxa-nss-certs-3.59 337 go@1.4-bootstrap-20171003 /gnu/store/cxm5py5p7wwgskjlfn6009mwql906884-go-1.4-bootstrap-20171003-doc /gnu/store/h5bbkxnad8lxvp2kqpmfz26wbv5w9i6h-go-1.4-bootstrap-20171003 /gnu/store/qwr2kwxmmj6zyibgl586qx0gl7vq6hl2-go-1.4-bootstrap-20171003-tests 244 php@7.4.14 /gnu/store/2pzqq029qg9k2ybp0zbkzc9syfj5s1qy-php-7.4.14 186 openbox@3.6.1 /gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 181 kcoreaddons@5.70.0 /gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 180 ki18n@5.70.0 /gnu/store/m5rk1z8kv9blrwfy045zwh4sh8mbflyk-ki18n-5.70.0 179 kconfig@5.70.0 /gnu/store/i5fim2lrykyvnvqszmi40n4lf1bh2rfq-kconfig-5.70.0 178 openbox@3.6.1 /gnu/store/ydsy5zxg6hlp19v4cxyl7m7agkrqxxpa-openbox-3.6.1 178 ki18n@5.70.0 /gnu/store/m5rk1z8kv9blrwfy045zwh4sh8mbflyk-ki18n-5.70.0 178 karchive@5.70.0 /gnu/store/39ln3kibfqnl0p8i9465dmvg1kzdqn6j-karchive-5.70.0 176 kcoreaddons@5.70.0 /gnu/store/jgvqvcyrq02b6bsn7fhbdpsrqmpxczv6-kcoreaddons-5.70.0 176 kwidgetsaddons@5.70.0 /gnu/store/pvljcxdlnhl6311494jxfp27b1z2l16f-kwidgetsaddons-5.70.0 175 kcodecs@5.70.0 /gnu/store/r47szv81m0nf6l4acs12yhzj79i1zrbn-kcodecs-5.70.0 174 karchive@5.70.0 /gnu/store/39ln3kibfqnl0p8i9465dmvg1kzdqn6j-karchive-5.70.0 174 kdbusaddons@5.70.0 /gnu/store/00av6cmj7sfz19if37kivhvrfn4bcm34-kdbusaddons-5.70.0 174 kguiaddons@5.70.0 /gnu/store/xya6mpz330680v72rvs9i85374872r66-kguiaddons-5.70.0 173 kitemviews@5.70.0 /gnu/store/djndnnrl9ih1a0i5d6bxmw5ccl609jiy-kitemviews-5.70.0 171 sonnet@5.70.0 /gnu/store/z70fsxk28qcdlzd91zynykprdpdywkqx-sonnet-5.70.0 170 kconfig@5.70.0 /gnu/store/i5fim2lrykyvnvqszmi40n4lf1bh2rfq-kconfig-5.70.0 170 libpipeline@1.5.3 /gnu/store/6qi0yj1i61py5mhg02vll8b6gbjilngl-libpipeline-1.5.3 170 phonon@4.11.1 /gnu/store/0ilawnnli4l3xxnlc0930yyqfjrbd2z7-phonon-4.11.1 170 attica@5.70.0 /gnu/store/axdap0dmkxdibxz45qvxm91qyqjg4hjw-attica-5.70.0 169 qgpgme@1.15.0 /gnu/store/zrrs3hpqcif5rbw98qkl686lb910wsj2-qgpgme-1.15.0 168 solid@5.70.0 /gnu/store/n37dfll0wmnlzjimx1vwnm2a0d05wkvf-solid-5.70.0 166 kwidgetsaddons@5.70.0 /gnu/store/pvljcxdlnhl6311494jxfp27b1z2l16f-kwidgetsaddons-5.70.0 166 kcodecs@5.70.0 /gnu/store/r47szv81m0nf6l4acs12yhzj79i1zrbn-kcodecs-5.70.0 164 kwayland@5.70.0 /gnu/store/9q7cf9cqdxi733sh44bz9zmqis718xak-kwayland-5.70.0 162 kguiaddons@5.70.0 /gnu/store/xya6mpz330680v72rvs9i85374872r66-kguiaddons-5.70.0 160 kitemviews@5.70.0 /gnu/store/djndnnrl9ih1a0i5d6bxmw5ccl609jiy-kitemviews-5.70.0 154 phonon@4.11.1 /gnu/store/0ilawnnli4l3xxnlc0930yyqfjrbd2z7-phonon-4.11.1 153 sonnet@5.70.0 /gnu/store/z70fsxk28qcdlzd91zynykprdpdywkqx-sonnet-5.70.0 153 r-survival@3.2-7 /gnu/store/ddcrdwp4fvqnnpak2n795lxa8v43swli-r-survival-3.2-7 152 solid@5.70.0 /gnu/store/n37dfll0wmnlzjimx1vwnm2a0d05wkvf-solid-5.70.0 152 attica@5.70.0 /gnu/store/axdap0dmkxdibxz45qvxm91qyqjg4hjw-attica-5.70.0 150 qgpgme@1.15.0 /gnu/store/zrrs3hpqcif5rbw98qkl686lb910wsj2-qgpgme-1.15.0 150 modem-manager@1.12.10 /gnu/store/7qpsk5dc3dzpf7zylhw8gdzi7k1whj2j-modem-manager-1.12.10 127 python-sphinx-rtd-theme@0.2.4 /gnu/store/lxpil9q4mamlz9m1xndy6f9ai31lxh6s-python-sphinx-rtd-theme-0.2.4 123 libwpe@1.6.0 /gnu/store/g2n55ynaq6155hrcqbcb99r6fmmw1f16-libwpe-1.6.0 112 python2-pytz@2020.4 /gnu/store/0fdd13lnfdkr9ryd092qzy2b295izf8q-python2-pytz-2020.4 105 python-xcffib@0.6.0 /gnu/store/w60lrz19jm405qxclk2jj136a8zgk6s3-python-xcffib-0.6.0 96 python-tornado@5.1.1 /gnu/store/45s91xh8widqr96q1zwlp3naj6a37x84-python-tornado-5.1.1 85 ruby-mysql2@0.5.2 /gnu/store/4qzyr50njifdxdllgx8a3pzm78x9wpc0-ruby-mysql2-0.5.2 85 python-numpydoc@0.8.0
Re: Staging branch [substitute availability armhf-linux]
The armhf-linux platform is in the worst shape, both on the master and staging branches. It's a shame because it's also the least powerful, with almost no hardware thermally capable of sustained CPU usage, so users will have the worst experience building packages for it. Does anyone want to work on it? Should we just "fix it on the master branch?" -- 3301 packages are missing from 'https://ci.guix.gnu.org' for 'armhf-linux', among which: 2695 gdk-pixbuf@2.40.0 /gnu/store/xjdgypav5vcl4pyc388cs6gr5hv73fvp-gdk-pixbuf-2.40.0 2277 imagemagick@6.9.11-48 /gnu/store/gjb5j8yf7aynicmfsxwqnwzhjp2sp6i8-imagemagick-6.9.11-48-doc /gnu/store/vnpms2y3g9wrkl550zk0gh5vx9rb5hym-imagemagick-6.9.11-48 2239 elfutils@0.182 /gnu/store/kbdmbs8h83kqya6wqjisjm6snbnjxpff-elfutils-0.182-bin /gnu/store/iy8q5i7fa9c347r34lllrvbqzh6lwrfr-elfutils-0.182 2194 libdrm@2.4.103 /gnu/store/i6ydsdg2ha6k40s5vrqh5c5wqkkhx0i8-libdrm-2.4.103 2188 glslang@10-11.0.0 /gnu/store/xvw9jbfqrjv5pc8d1ckni72y6mwll2ay-glslang-10-11.0.0 1990 rust@1.19.0 /gnu/store/jgbkdpxrf18q3yms4a1apzkawsqhzqkr-rust-1.19.0-cargo /gnu/store/2zmswj21202j7xfli9aizz6a9k6pkfvd-rust-1.19.0 1861 xkbcomp-intermediate@1.4.4 /gnu/store/c61lfs091rv4pa405rxcqzxn9hzvdlyn-xkbcomp-intermediate-1.4.4 1665 tzdata@2020f /gnu/store/ix7dkzsc2g2028xxqirwmjlprdiarhsa-tzdata-2020f 1331 libcap@2.45 /gnu/store/rcx340qk9dcs7lck86xba8fmbwn132vm-libcap-2.45 1093 postgresql@13.1 /gnu/store/bcgry8jrhs9d5z532yhacf2zzzviyzqi-postgresql-13.1 964 mariadb@10.5.8 /gnu/store/3fa29zjsb48279g3qifa5fjlihx6wzvy-mariadb-10.5.8-dev /gnu/store/hxg1mynghbs1frnnwx2vb84ywj912a8j-mariadb-10.5.8-lib /gnu/store/67zkwlflvmj2mia67ifx07rzb3m2vyfn-mariadb-10.5.8 872 xprop@1.2.5 /gnu/store/2yj1m9xpil630qcry3psw6pg5nc7j8gh-xprop-1.2.5 855 libinput-minimal@1.16.4 /gnu/store/zyr2hl2bsqxw63kr67p6nycdpmyng1f9-libinput-minimal-1.16.4 830 vulkan-headers@1.2.164 /gnu/store/41gwjqma4whf6dvfif9d02fmmfa80bdr-vulkan-headers-1.2.164 788 sbcl@2.1.0 /gnu/store/3dvfa85ycrpxbj208yfwikl0n33lavwi-sbcl-2.1.0-doc /gnu/store/1b7qwyv732n28gahwpjagv3xjjlpm2ik-sbcl-2.1.0 784 patchelf@0.11 /gnu/store/ww555zg4njj4acr12qhbl8xjq9dzdg7f-patchelf-0.11 749 python-pytz@2020.4 /gnu/store/lx2iqg2cpyi2ds1qqszav3vrf68hli5i-python-pytz-2020.4 739 python-cffi@1.14.4 /gnu/store/x27rkkrp2dw3j0v0n3izd513kzxha6qp-python-cffi-1.14.4 714 python-iso8601@0.1.13 /gnu/store/68b8mqbgsvdaqnrp3414sxqwymlpn29y-python-iso8601-0.1.13 682 python-cryptography-vectors@3.3.1 /gnu/store/v3jjq6dmsf9l62pbfmz3502wc0fdixbh-python-cryptography-vectors-3.3.1 667 python-certifi@2020.12.5 /gnu/store/rbw7ni2f13s2fgxw825ygd5lpa1j2nw4-python-certifi-2020.12.5 619 gstreamer@1.18.2 /gnu/store/355qdcpy3dnv4yjpgrdxbgwk1hi03fw3-gstreamer-1.18.2 582 classpath@0.93 /gnu/store/5hy2cdkjscq5546ym6jkf048dyick7cd-classpath-0.93 576 nss-certs@3.59 /gnu/store/p131lkj2mhiq5dbl4snlkaachvlivbjy-nss-certs-3.59 511 python-pygments@2.7.3 /gnu/store/4mzgxp6bsx4zk7xylr7hm5l8d7bby1x6-python-pygments-2.7.3 401 shadow@4.8.1 /gnu/store/lxnfvrkijw9awbrw47vx4nmra2dmpa16-shadow-4.8.1 245 git@2.30.0 /gnu/store/xvpmhk29ykscfdpfyjhpyrhahi6rck19-git-2.30.0-credential-netrc /gnu/store/fnyrbmzxhcgbpl300irpycr8fy85dqrs-git-2.30.0-gui /gnu/store/klswflk1cqn723i0hyzxg3vv2wicrb5k-git-2.30.0 /gnu/store/06f3b2igianyqwic7jp2c216lb98w6jb-git-2.30.0-send-email /gnu/store/7i9clx90q28b966aypr8g3yhrvqd1b3z-git-2.30.0-subtree /gnu/store/zlc18bbhbgc7lzjk5xqw5p54a0jrr8l3-git-2.30.0-svn 234 gsasl@1.10.0 /gnu/store/gs1mgdfxd7il90ij78zl9jdfrg2j7dcq-gsasl-1.10.0 227 gdk-pixbuf@2.40.0 /gnu/store/xjdgypav5vcl4pyc388cs6gr5hv73fvp-gdk-pixbuf-2.40.0 222 libdrm@2.4.103 /gnu/store/i6ydsdg2ha6k40s5vrqh5c5wqkkhx0i8-libdrm-2.4.103 221 elfutils@0.182 /gnu/store/kbdmbs8h83kqya6wqjisjm6snbnjxpff-elfutils-0.182-bin /gnu/store/iy8q5i7fa9c347r34lllrvbqzh6lwrfr-elfutils-0.182 218 imagemagick@6.9.11-48 /gnu/store/gjb5j8yf7aynicmfsxwqnwzhjp2sp6i8-imagemagick-6.9.11-48-doc /gnu/store/vnpms2y3g9wrkl550zk0gh5vx9rb5hym-imagemagick-6.9.11-48 217 xkbcomp-intermediate@1.4.4 /gnu/store/c61lfs091rv4pa405rxcqzxn9hzvdlyn-xkbcomp-intermediate-1.4.4 216 libcap@2.45 /gnu/store/rcx340qk9dcs7lck86xba8fmbwn132vm-libcap-2.45 216 tzdata@2020f /gnu/store/ix7dkzsc2g2028xxqirwmjlprdiarhsa-tzdata-2020f 214 xprop@1.2.5 /gnu/store/2yj1m9xpil630qcry3psw6pg5nc7j8gh-xprop-1.2.5 213 postgresql@13.1 /gnu/store/bcgry8jrhs9d5z532yhacf2zzzviyzqi-postgresql-13.1 213 mariadb@10.5.8 /gnu/store/3fa29zjsb48279g3qifa5fjlihx6wzvy-mariadb-10.5.8-dev /gnu/store/hxg1mynghbs1frnnwx2vb84ywj912a8j-mariadb-10.5.8-lib /gnu/store/67zkwlflvmj2mia67ifx07rzb3m2vyfn-mariadb-10.5.8 213 libinput-minimal@1.16.4
Re: Staging branch [substitute availability i686-linux]
For i686-linux: Should we even be attempting to build Rust on this platform? Has it ever worked? What about the ant-bootstrap? The mesa test suite failure is reproducible, and the error messages are found below. -- 2286 packages are missing from 'https://ci.guix.gnu.org' for 'i686-linux', among which: 2179 mesa@20.2.4 /gnu/store/y2pqvr7297q7pkj82qrgwvsvfg2mvbam-mesa-20.2.4-bin /gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4 1990 rust@1.19.0 /gnu/store/cazsr6swdp457h6j2df9slmsrv45bqvq-rust-1.19.0-cargo /gnu/store/p9sj678d8sk9wqp86gqq1ghl5w1alrk4-rust-1.19.0 580 ant-bootstrap@1.8.4 /gnu/store/rb0r3r4vf3gd63bqinpkha9450yzvjm6-ant-bootstrap-1.8.4 220 mesa@20.2.4 /gnu/store/y2pqvr7297q7pkj82qrgwvsvfg2mvbam-mesa-20.2.4-bin /gnu/store/isx9ra95v8gw3fqgrvz62cwrlzl5s5y7-mesa-20.2.4 149 protobuf@3.14.0 /gnu/store/6d54h23b86hs9y8y6528962sbg8qd43n-protobuf-3.14.0 /gnu/store/hfarq203gg3hh2q179zabidh0rlcjbp5-protobuf-3.14.0-static 69 ucx@1.6.1 /gnu/store/rw5qfppz6pjzvxlir7ad67znww6nrc8d-ucx-1.6.1 68 psm2@11.2.86/gnu/store/8cqcmlww41srcihcl30fqllzs0xajw4n-psm2-11.2.86 46 htslib@1.9 /gnu/store/m58c8bc9b4v8ij0w5vd6q2da27rvmx3z-htslib-1.9 44 htslib@1.11 /gnu/store/a9g55dfay50aiwxiwxaw001b9fkcdn1f-htslib-1.11 42 go-gopkg-in-yaml-v2@2.2.2 /gnu/store/7ynxpa5r5j17np17g9d74dkbbjrvi6fb-go-gopkg-in-yaml-v2-2.2.2 40 ruby-ruby-prof@1.4.1 /gnu/store/5j9v7afqi0qhkna8izza5hppg1q7q79d-ruby-ruby-prof-1.4.1 31 python-gevent@20.9.0 /gnu/store/2nl53qjhm429pdj3vf2czlkfq7fg83ir-python-gevent-20.9.0 30 python2-numpydoc@0.8.0 /gnu/store/f9i0psw9kwljfkfprwja53lmn3h7qd5q-python2-numpydoc-0.8.0 28 python2-pympler@0.8 /gnu/store/a6gvqx4876mddscz0a1109fp1qr11lvd-python2-pympler-0.8 28 libgeotiff@1.5.1 /gnu/store/2mk87lgadgclnkzh3fq44qwnrrzd3sg9-libgeotiff-1.5.1 23 python-networkx@2.5 /gnu/store/dq3gld1h74w7a6z5fll2byf19rflr4rs-python-networkx-2.5 21 rakudo@2019.03.1 /gnu/store/l2w4b9bbkg4dwmvyz3c8la8h2i18kl3v-rakudo-2019.03.1 20 python2-twisted@19.7.0 /gnu/store/nzv3qhggqawwpzmj65p2hcg8iqi1j22f-python2-twisted-19.7.0 19 ocaml-migrate-parsetree@1.7.3 /gnu/store/7mkcrkqxs27vxsxvnx0ddd9m8p7ml21s-ocaml-migrate-parsetree-1.7.3 16 python2-zope-testrunner@5.2 /gnu/store/ya3l6fa2cnlsr3kxsxlh1zqxvvq9k4xs-python2-zope-testrunner-5.2 15 r-assertive-base@0.0-7 /gnu/store/z5akvxvl6g3gnlbf7q3jp43gjfxq9vrc-r-assertive-base-0.0-7 14 python-arrow@0.17.0 /gnu/store/3b6fmmsx3bywk4js088kq06vmsg8y1v8-python-arrow-0.17.0 13 mono@4.4.1.0/gnu/store/k84fvwkv58440cmi52yzycl3v56klxmx-mono-4.4.1.0 12 r-webshot@0.5.2 /gnu/store/fqszb150xjm8y516ms8n3my9dy5p1sri-r-webshot-0.5.2 12 r-flowcore@2.2.0 /gnu/store/z1sscs431wg86lgg2iarg7xhqvdysbk7-r-flowcore-2.2.0 12 r-registry@0.5-1 /gnu/store/s4yc8ah2hfw7ir0wyw8iza9m6m07dxsr-r-registry-0.5-1 12 guile@1.8.8 /gnu/store/j6mnhk6iiy77m1ial0ffgjz2zwdc6m4z-guile-1.8.8 11 scalapack@2.0.2 /gnu/store/ayrbfdfcq33r1xmxln6jvkw7x6jis9xn-scalapack-2.0.2 11 hdf5-parallel-openmpi@1.10.7 /gnu/store/a8x6s1d6wh1ga35vjd7z49jh6zr28hmq-hdf5-parallel-openmpi-1.10.7-fortran /gnu/store/a58wsdqhs1gq5sa9cvnwr14i0ydq4xcp-hdf5-parallel-openmpi-1.10.7 11 clang@11.0.0 /gnu/store/lq4jhyjd1027i5nf6kafp3xjxb6fnilb-clang-11.0.0-extra /gnu/store/04hvxidk3rpy8x977nkq9vpa27svny40-clang-11.0.0 11 r-corrplot@0.84 /gnu/store/26izpmf2m5pdf7sq7b30yfw1zagl30wb-r-corrplot-0.84 11 cmake@3.19.2 /gnu/store/v78kmw21l0dnzqrwb3bdfcjhhvqjhbic-cmake-3.19.2-doc /gnu/store/3ll779l3viph275svivhc59krla4byxs-cmake-3.19.2 11 r-sandwich@3.0-0 /gnu/store/qjqjvz4l92dg96fan9z5lv0ssdi30k64-r-sandwich-3.0-0 11 ghc-ieee754@0.8.0 /gnu/store/4lyzys7v1chzy5a64697pazwhdss55gb-ghc-ieee754-0.8.0 /gnu/store/3hnmkxbp5gxxjp0vjw4vp0vqf2spy626-ghc-ieee754-0.8.0-static 10 dune-common@2.7.0 /gnu/store/pfdcjaicifq42b3siwycmry7i969cvrv-dune-common-2.7.0 10 dune-common-openmpi@2.7.0 /gnu/store/6wy9w4crxz2bqvj3c10g5b18n8zj656d-dune-common-openmpi-2.7.0 10 ghc-half@0.3 /gnu/store/q17zfd341rd4yzcvq2fd63g2dr5pd1yd-ghc-half-0.3 /gnu/store/z9qi2sgnbx1s5fzx49809587gd30kdb5-ghc-half-0.3-static 10 r-hdrcde@3.3/gnu/store/m69lkzmxkicpbc6rg1r220bh393izw5v-r-hdrcde-3.3 10 abseil-cpp@20200225.2 /gnu/store/fbx5lzmhjaywqdwx7pxky4nkfpsdjc08-abseil-cpp-20200225.2 10 ghc-bytes@0.15.5 /gnu/store/w8bpqvzjkzcxiccfscmdm6pv869m5n38-ghc-bytes-0.15.5 /gnu/store/m8f9afzgbz6jkz0fpl63vhpl8g7k8asd-ghc-bytes-0.15.5-static 10 r-future-apply@1.6.0 /gnu/store/m103jmmcsijgsh5778hs8s6la62ahlka-r-future-apply-1.6.0 10 r-rsvd@1.0.3/gnu/store/q53slf7d22p12hka5064awn99y36flka-r-rsvd-1.0.3 10 ghc-hashtables@1.2.3.4 /gnu/store/qh86n6f6akzyb5a6x5qj9fig9wb641hq-ghc-hashtables-1.2.3.4
Re: Staging branch [substitute availability x86_64-linux]
Here is the "missing package" report printed by `guix weather --coverage=10` for x86_64-linux. The Java packages at the top of this list are private packages, but substitutes are available for them. Maybe they should be public, but hidden? Overall, I think the staging branch is ready for x86_64-linux. -- 2402 packages are missing from 'https://ci.guix.gnu.org' for 'x86_64-linux', among which: 370 java-org-ow2-parent-pom@1.3 /gnu/store/k7f85jn0g4r3pic9rcjxphm77w94pwqi-java-org-ow2-parent-pom-1.3 162 java-slf4j-parent@1.7.25 /gnu/store/h446mfbngdjxc1fv6xcpl9h9g78csplg-java-slf4j-parent-1.7.25 158 java-guava-parent-pom@20.0 /gnu/store/lz2sahbgyrfwbjfq9ks2z8qww62wll30-java-guava-parent-pom-20.0 154 java-google-parent-pom@5 /gnu/store/ca2xl55bxgzhyn3iw49nvc9smixxcz5z-java-google-parent-pom-5 119 java-snappy@1.1.7.5 /gnu/store/cq9x7m3nqdfw3kyxnzxjbkiy3ab8g75d-java-snappy-1.1.7.5 108 java-geronimo-genesis@2.1 /gnu/store/wx7bffn53f6xfqiqvsqkb5b3zj5k8djk-java-geronimo-genesis-2.1 74 java-plexus-containers-parent-pom@1.7.1 /gnu/store/vqzh225cvjzcjvbzaa6706d6f4j4hb07-java-plexus-containers-parent-pom-1.7.1 52 plexus-components-parent-pom@4.0 /gnu/store/siv9s9rx3n1ccjw4iw98xn6i8y5v27qm-plexus-components-parent-pom-4.0 52 java-sisu-inject-parent-pom@0.3.4 /gnu/store/mbda0iypwjin24r1b4qi5zlangdzpymy-java-sisu-inject-parent-pom-0.3.4 49 java-sisu-plexus-parent-pom@0.3.4 /gnu/store/pkqj1h4dd67snn9fsizkni066kg6b5ix-java-sisu-plexus-parent-pom-0.3.4 45 java-stringtemplate@4.0.6 /gnu/store/1rwvj03224ismgr30y2jq3lcg44kvks9-java-stringtemplate-4.0.6 44 maven-pom@3.6.1 /gnu/store/knlfsdw04aji3nsnd517mrzvgx7a4qfq-maven-pom-3.6.1 41 ocaml4.07-dose3@5.0.1 /gnu/store/pj35fddjlfg2dfhdanc7jdi28dpssfm9-ocaml4.07-dose3-5.0.1 40 maven-resolver-parent-pom@1.3.1 /gnu/store/3fb7x8iq7s4qr8iw5jaqfxb38jwj14yi-maven-resolver-parent-pom-1.3.1 39 cl-unicode@0.1.6 /gnu/store/6pbghy445vqb2ryv4z4gcxq10s8cs22a-cl-unicode-0.1.6 37 python2-cairocffi@1.2.0 /gnu/store/rkw14pvzg9jhk2d0l1idyh4c6hi9kaqg-python2-cairocffi-1.2.0-doc /gnu/store/7nqd9v2mvrdlx0swvwab33g43kpbi6ns-python2-cairocffi-1.2.0 35 java-jaxen-bootstrap@1.1.6 /gnu/store/jigmr6xzqf2gsvaa4nlqydpqr705apg9-java-jaxen-bootstrap-1.1.6 34 java-commons-collections@3.2.2 /gnu/store/ak09a9rz5k73jhai1g7dmzh0skkmkd5f-java-commons-collections-3.2.2 34 java-tunnelvisionlabs-antlr4-runtime@4.7.4 /gnu/store/ax4x9z2z2wv4db4isam6mzhnnhzjv1by-java-tunnelvisionlabs-antlr4-runtime-4.7.4 32 maven-plugin-tools-parent-pom@3.5 /gnu/store/3q1j8z1z0gfs1fxridcb2l6590dnjmd2-maven-plugin-tools-parent-pom-3.5 31 java-xstream@1.4.15 /gnu/store/nz1s1svrszjpd0vkcrdmxay30w2v96as-java-xstream-1.4.15 30 python2-numpydoc@0.8.0 /gnu/store/9jmb5hz8zhqcfn5fl3ys77m1q4ah2rr6-python2-numpydoc-0.8.0 25 maven-pom@3.0 /gnu/store/mk65i8z6z4gvl789il9nv0ghr84adm0x-maven-pom-3.0 20 r-affy@1.68.0 /gnu/store/xrzs85ix0h3mld053j3j3l2ggznp01q8-r-affy-1.68.0 17 cl-symbol-munger@0.0.1-1.97598d4 /gnu/store/cbfrlizlj2lx2z3j4xj9zvrcgbljhk5w-cl-symbol-munger-0.0.1-1.97598d4 16 maven-wagon-provider-api@3.3.4 /gnu/store/78nv8hicg8wywq04767z1nbp88czpg6i-maven-wagon-provider-api-3.3.4 15 python-stevedore@3.2.2 /gnu/store/ypifs3qxw0l5gw8w7l165zpcihi3k669-python-stevedore-3.2.2 15 r-uuid@0.1-4 /gnu/store/s5nxr3jhfp7cdfl1dclc79c8djgwa12d-r-uuid-0.1-4 14 stumpwm@20.11 /gnu/store/9f98ids4s8hg306chy36d3bhk7zmyg9a-stumpwm-20.11-lib /gnu/store/pjfirqc9zxzmk2kap1kph07xib1s1749-stumpwm-20.11 14 cl-syntax@0.0.3 /gnu/store/m7miy4bz0slcib33hi6v1cw2wh3wrd5g-cl-syntax-0.0.3 14 python-arrow@0.17.0 /gnu/store/q9j7snxqyirpq94dqpjl3y9hvjzljynq-python-arrow-0.17.0 13 osinfo-db-tools@1.8.0 /gnu/store/w05va2s51vx70c0akgs73wnc09j2bxws-osinfo-db-tools-1.8.0 12 python-trytond-currency@5.6.0 /gnu/store/8d19alw9wavp94xfka4pvr9gb3bvzahj-python-trytond-currency-5.6.0 12 java-eclipse-jetty-http-test-classes@9.2.22 /gnu/store/3xj4swsbyrnlh8f5awy36qx3i51ah8fl-java-eclipse-jetty-http-test-classes-9.2.22 12 sdl-union@1.2.15 /gnu/store/hkl87qvqvhqvja954hk4b4i9s3a2l69v-sdl-union-1.2.15 11 python-openstackdocstheme@1.18.1 /gnu/store/wshcx7j6ld0gmsd6iikib50b1b423420-python-openstackdocstheme-1.18.1 11 doctest@2.4.4 /gnu/store/84rh11m92a2vmpap4rdppb5l6n6x521h-doctest-2.4.4 10 r-dorng@1.8.2 /gnu/store/i5za4zyldlnqb9vy5aby4s7ff2bm3qj0-r-dorng-1.8.2 10 r-insight@0.11.1 /gnu/store/z2xazlvfq2qpj7wcr3p5is3s4y86q5ps-r-insight-0.11.1 10 libxaw3d@1.6.3 /gnu/store/93yq8qgvjsp6zcxipzvi40g2fvx9vsq7-libxaw3d-1.6.3 10 r-scrime@1.3.5 /gnu/store/kj6gjbdpariqcp6iclkxypm8i4jb53li-r-scrime-1.3.5 10 r-beanplot@1.2 /gnu/store/w3r5vl74m9xklhbsa243gnhnkryicb2s-r-beanplot-1.2
Re: Staging branch [substitute availability]
Using `guix weather`, we can check substitute availability for the staging branch: -- master branch aarch64: 66% x86_64: 93% i686: 85% armhf: 51% staging branch aarch64: 44% x86_64: 80% i686: 60% armhf: 30% -- So, substitute availability is definitely lower on the staging branch. It's not clear if this is the result of "real problems" with the packages or problems with the build farm.
