bug#36777: Guix Inferiors: Curious incorrect derivation output bug
Hi all, I've been working on improving the Guix build support on Bitcoin Core so that it'll be ready to use for official releases. One of the things that I wanted to do was to use a combination of channels and inferiors to have reproducible builds across time. I have most of it set up, but am running into some trouble. Here are the details: I have a Guix channel set up at https://github.com/dongcarl/bitcoin-guix, where I pin the Guix version to 6869b6635afd93872b8f0d9f2db0db4c0d765a86 in the .guix-channel, and declare all my packages in packages.scm. I have my manifest.scm here: https://github.com/dongcarl/bitcoin/blob/2019-06-guix-channels-and-inferiors/contrib/guix/manifest.scm, and it references the aforementioned Guix channel. What I expect to happen is that now when I change my default profile's Guix version by 'guix pull'ing, it won't affect the environment that's generated by the manifest.scm. I've tested this with differing versions of Guix as my default profile, and this seems to work with 7304d5623ab5cc35289cb1535cbd0d8a37691fac and 7f1c69f5d32bee6b8b6b902a9ce445e04aa9d07d being my default profile. However, I tried an older version b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f, and got the following error: ``` guix environment: error: derivation `/gnu/store/r641vpqc9rfjhljf7rzfzwmkmpa642ls-info-dir.drv' has incorrect output `/gnu/store/q9hkdidycz3wq28xxgjq47bzx5s39k52-info-dir', should be `/gnu/store/z5hh2nl0h58b9f6hdxfwm00gjyxfcc3n-info-dir' ``` I remember my previous attempts at integrating channels and inferiors into our workflow yielded a similar result, so I would like to know if this is a bug, and how I might go about fixing this so that I can feel comfortable using inferiors for our builds. Nevertheless, thank you all for your hard work. The fact that we have inferiors at all is marvelous! Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds
Ludovic Courtès writes: > Currently we have an SSH tunnel set up on berlin to connect to each of > these machines via overdrive1.guixsd.org. This setup proved to be > robust in the past (we used it to connect to another build machine), so > I suspect something’s wrong on “your” end of the network. It’s hard to > tell exactly what, though. FWIW by the end of this week we should have the firewall changes implemented so we can do without the SSH tunnel. -- Ricardo
bug#36775: USB sticks can't be accessed on XFCE
No USB flash drive can be mounted on XFCE. Both lsusb and lsblk
correctly show the device, showing that the device is not
malfunctioning.
Fdisk can access and modify the partitions on the device but gparted
will segfault right after it finishes to search for devices. You can
find my config.scm as an attachment.
This is the output of `guix describe`:
Generation 201 Jul 23 2019 21:53:47(current)
guix c42db89
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: c42db89ff992037841e7937059db952571af86fa
(use-modules (gnu))
(use-service-modules desktop nix networking ssh xorg)
(operating-system
(locale "en_US.utf8")
(timezone "Europe/Rome")
(keyboard-layout
(keyboard-layout "it" "nodeadkeys"))
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")
(keyboard-layout keyboard-layout)))
(file-systems
(cons* (file-system
(mount-point "/home")
(device
(uuid "4d4c4af6-28ef-49ae-b08b-211b5648ebfc"
'ext4))
(type "ext4"))
(file-system
(mount-point "/")
(device
(uuid "2125621a-4da2-42b7-88d7-2d0fa16157e1"
'ext4))
(type "ext4"))
(file-system
(mount-point "/boot/efi")
(device (uuid "E7FB-57B4" 'fat32))
(type "vfat"))
%base-file-systems))
(swap-devices '("/dev/sda3"))
(host-name "frastanato")
(users (cons* (user-account
(name "orang3")
(comment "Giacomo Leidi")
(group "users")
(home-directory "/home/orang3")
(supplementary-groups
'("wheel" "netdev" "audio" "video" "kvm")))
%base-user-accounts))
(packages
(append
(list ;; Nix package manager
(specification->package "nix")
;; HTTPS
(specification->package "nss-certs")
;; User mounts
(specification->package "gvfs")
(specification->package "font-dejavu"))
%base-packages))
(services
(append
(list (service xfce-desktop-service-type)
(service tor-service-type)
(service nix-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)))
(extra-special-file "/usr/bin/env"
(file-append coreutils "/bin/env"))
)
%desktop-services)))
bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds (was: New linux-libre failed to build on armhf on Berlin)
I wrote earlier: > I now believe that these failures are related to the newly added armhf > build slaves, and that they have nothing to do with the recent changes > to our linux-libre packages. I should mention that the armhf build slaves are on a private network, and I use my public-facing internet server to forward TCP connections to them, using the following entries in /etc/inetd.conf: --8<---cut here---start->8--- # TCP-level forwards for SSH connections to build machines for the GNU # Guix build farm: 7275stream tcp nowait nobody /bin/nc /bin/nc -w 10 172.19.189.11 7275 7276stream tcp nowait nobody /bin/nc /bin/nc -w 10 172.19.189.12 7276 7274stream tcp nowait nobody /bin/nc /bin/nc -w 10 172.19.189.13 7274 --8<---cut here---end--->8--- It's possible that this arrangement is somehow part of the problem. However, note that nothing has changed here in several years, and it worked fine on hydra.gnu.org. The build slaves were running a *very* old version of Guix though. It seems likely that the new Guile-SSH code doesn't cope well with this setup. Mark
bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds (was: New linux-libre failed to build on armhf on Berlin)
retitle 36754 SSH connections to hydra-slave{1,2,3} fail during builds
thanks
Hi,
I've added Ludovic to the CC list, since he recently added
hydra-slave{1,2,3} to Berlin.
Marius wrote:
> I tried building 5.2.2 'interactively' on Berlin, and got an SSH error:
>
> CC [M] net/openvswitch/vport-geneve.o
> CC [M] net/openvswitch/vport-gre.o
> LD [M] net/openvswitch/openvswitch.o
> ;;; [2019/07/23 05:14:53.501502, 0] read_from_channel_port: [GSSH ERROR]
> Error reading from the channel: #
> Backtrace:
> 16 (apply-smob/1 #)
> In ice-9/boot-9.scm:
> 705:2 15 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8 14 (_ #(#(#)))
> In guix/ui.scm:
> 1747:12 13 (run-guix-command _ . _)
> In guix/scripts/offload.scm:
>781:22 12 (guix-offload . _)
> In ice-9/boot-9.scm:
> 829:9 11 (catch _ _ # …)
> 829:9 10 (catch _ _ # …)
> In guix/scripts/offload.scm:
>580:19 9 (process-request _ _ _ _ #:print-build-trace? _ # _ # _)
> 531:6 8 (call-with-timeout _ _ _)
> 361:2 7 (transfer-and-offload # …)
> In ice-9/boot-9.scm:
> 829:9 6 (catch _ _ # …)
> In guix/scripts/offload.scm:
> 385:6 5 (_)
> In guix/store.scm:
> 1203:15 4 (_ # _ _)
>692:11 3 (process-stderr # _)
> In guix/serialization.scm:
> 87:11 2 (read-int _)
> 73:12 1 (get-bytevector-n* # …)
> In unknown file:
>0 (get-bytevector-n # …)
>
> ERROR: In procedure get-bytevector-n:
> Throw to key `guile-ssh-error' with args `("read_from_channel_port" "Error
> reading from the channel" # #f)'.
> guix build: error: build of
> `/gnu/store/yfns7ga468vmv9jn72snk79b16p8mhfa-linux-libre-5.2.2.drv' failed
>
> real637m24.906s
> user0m6.661s
> sys 0m0.897s
Thank you, this is helpful.
> Unfortunately I failed to record which machine was used and don't know a
> way to find out after the fact.
I believe it was hydra-slave2, one of the three armhf machines that I
host which were formerly part of hydra.gnu.org's build farm and were
recently added to Berlin by Ludovic. I checked hydra-slave{1,2,3} for
build log files corresponding to the derivation above, and found that
all three of them have been attempted recently:
hydra-slave2 attempted to build it on July 23 08:07 UTC.
hydra-slave3 attempted to build it on July 22 16:40 UTC.
hydra-slave1 attempted to build it on July 22 04:44 UTC.
To be precise, each of those dates correspond to the end of the build
attempt. All three build logs are truncated on the build machine as
well, with no error message at the end.
I now believe that these failures are related to the newly added armhf
build slaves, and that they have nothing to do with the recent changes
to our linux-libre packages.
Well, except for the silence timeout that sometimes happens on slower
machines while deblobbing linux-libre. That's a separate issue.
Thanks,
Mark
bug#36754: New linux-libre failed to build on armhf on Berlin
Mark H Weaver writes:
> Hi Ricardo,
>
> Interesting. I distinctly remember that there was no log file when I
> looked last time. Hmm.
>
> Anyway, it seems that now, all of the failed builds have either build
> logs available or else information about which dependency failed. I
> don't remember seeing any of this last time, but I'm glad to see it now.
>
> A pattern has now emerged, but I don't know what it means. All of the
> armhf kernel builds failed except for linux-libre-arm-veyron-5.2.2,
> which succeeded:
>
> https://ci.guix.gnu.org/build/1488502/details (arm-veyron-5.2.2)
>
> Apart from this anomalous success, all of the armhf 5.2.2 and 4.19.60
> have a truncated log file:
>
> https://ci.guix.gnu.org/build/1488517/details (5.2.2)
> https://ci.guix.gnu.org/build/1488503/details (4.19.60)
> https://ci.guix.gnu.org/build/1488513/details (arm-generic-5.2.2)
> https://ci.guix.gnu.org/build/1488519/details (arm-generic-4.19.60)
> https://ci.guix.gnu.org/build/1488504/details (arm-omap2plus-5.2.2)
> https://ci.guix.gnu.org/build/1488501/details (arm-omap2plus-4.19.60)
>
> This pattern seems too regular to be a coincidence. Can we find out
> which build machines were used for these builds?
I tried building 5.2.2 'interactively' on Berlin, and got an SSH error:
CC [M] net/openvswitch/vport-geneve.o
CC [M] net/openvswitch/vport-gre.o
LD [M] net/openvswitch/openvswitch.o
;;; [2019/07/23 05:14:53.501502, 0] read_from_channel_port: [GSSH ERROR] Error
reading from the channel: #
Backtrace:
16 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 15 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 14 (_ #(#(#)))
In guix/ui.scm:
1747:12 13 (run-guix-command _ . _)
In guix/scripts/offload.scm:
781:22 12 (guix-offload . _)
In ice-9/boot-9.scm:
829:9 11 (catch _ _ # …)
829:9 10 (catch _ _ # …)
In guix/scripts/offload.scm:
580:19 9 (process-request _ _ _ _ #:print-build-trace? _ # _ # _)
531:6 8 (call-with-timeout _ _ _)
361:2 7 (transfer-and-offload # …)
In ice-9/boot-9.scm:
829:9 6 (catch _ _ # …)
In guix/scripts/offload.scm:
385:6 5 (_)
In guix/store.scm:
1203:15 4 (_ # _ _)
692:11 3 (process-stderr # _)
In guix/serialization.scm:
87:11 2 (read-int _)
73:12 1 (get-bytevector-n* # …)
In unknown file:
0 (get-bytevector-n # …)
ERROR: In procedure get-bytevector-n:
Throw to key `guile-ssh-error' with args `("read_from_channel_port" "Error
reading from the channel" # #f)'.
guix build: error: build of
`/gnu/store/yfns7ga468vmv9jn72snk79b16p8mhfa-linux-libre-5.2.2.drv' failed
real637m24.906s
user0m6.661s
sys 0m0.897s
Unfortunately I failed to record which machine was used and don't know a
way to find out after the fact.
bug#36772: feature request: checked variant of "substitute*"
> On 23. Jul 2019, at 15:35, Ricardo Wurmus wrote: > > > Hi Robert, > >> I think it would be great to have the following variant of substitute*: >> >> (substitute*-once filename (pattern vars) body) >> >> which acts like the usual substitute-*, except it also asserts that the >> substitution applies to exactly one line in the file, causing a build >> failure otherwise. > > I agree that the effect of substitute* should be checked. I think > substitute* should fail when one of its clauses failed to match > anything. > > Each clause could also accept an optional argument to make them only > match one location. We wouldn’t have to duplicate the macro for that > and it’s a simple extension to failing on zero matches. > > What do you think? That sounds like a good improvement, too. I think the important part is ensuring the substitution matches at all, maybe we could leave out the “at most once” part. (I doubt it would be used a lot if it’s not the default.) Cheers Robert
bug#36772: feature request: checked variant of "substitute*"
Hi Robert, > I think it would be great to have the following variant of substitute*: > > (substitute*-once filename (pattern vars) body) > > which acts like the usual substitute-*, except it also asserts that the > substitution applies to exactly one line in the file, causing a build > failure otherwise. I agree that the effect of substitute* should be checked. I think substitute* should fail when one of its clauses failed to match anything. Each clause could also accept an optional argument to make them only match one location. We wouldn’t have to duplicate the macro for that and it’s a simple extension to failing on zero matches. What do you think? -- Ricardo
bug#36772: feature request: checked variant of "substitute*"
I think it would be great to have the following variant of substitute*: (substitute*-once filename (pattern vars) body) which acts like the usual substitute-*, except it also asserts that the substitution applies to exactly one line in the file, causing a build failure otherwise. In the cases where this is sufficient (I believe most), it would make substitution work quite a bit more reliably, making it both easier to debug substitution when first packaging, and noticing more easily when they need to be adapted on upgrades. (It would be possible to make the signature a bit more flexible and to allow multiple files or patterns as in substitute*, but that would make the meaning of “applies exactly once” a bit unclear, so I’d prefer to not do that. Similarly, I find it cleaner to potentially call substitute*-once several times in a row with different substitutions to make the ordering of effects explicit.) (I’d be happy to supply a patch myself eventually, but the syntax rule business is a bit out of reach at this point.)
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi Mark, Mark H Weaver skribis: > Hi Janneke, > >> I have added a very similar set of two patches to wip-cu-binaries, >> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. >> >> They give the same md5sum for me as the wip-binaries branch that >> branched off of master; so mine are at >> http://lilypond.org/janneke/guix/20190722/ > > I built these, and here are the results: > > mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ > sha256sum * > b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276 > guile-static-stripped-2.2.4-i686-linux.tar.xz > 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a > linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz > 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 > mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz > fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 > mes-minimal-stripped-0.19-i686-linux.tar.xz > 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c > static-binaries-0-i686-linux.tar.xz > > Do these match what you built? We verified things back then: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00046.html This was on commit 4ae7dc7b9af64794081b1913740b97acd89c91bc, which is earlier than the one you’re looking at (commit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f, right?) > For the sake of completeness, I built these by running > > ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux > > from a git checkout at commit 5a6465e41a84b4320940d33709b80d78c1aff9d0. Hmm I don’t have this commit here. I think we should first make sure we’re starting from the right commits. Then, if there are still differences, I suggest a cursory look at the output of ‘diffoscope’ to see if there’s anything obvious (non-determinism in .go files is apparently still a problem, for example.) Thanks for checking! Ludo’.
bug#35424: Gnome terminal doesn't keep current working directory in new tab/window
On 23/07/19 16:40, Ben Sturmfels wrote: >>> Interesting. Is this file installed to /etc/profile.d/vte.sh on other >>> systems? Or is it otherwise sourced? >>> >> >> I can only speak for my own system. I don't have gnome-terminal >> installed, but I do have tilda which uses vte. My >> ~/.guix-profile/etc/profile.d/ only has bash_completion.sh. > > I wonder if it's just a matter of moving vte to the propagated-inputs of > gnome-terminal (and other packages like tilda)? I'll try now and report > back. Ok, moving vte to propagated-inputs for gnome-terminal makes ~/.guix-profile/etc/profile.d/vte.sh show up if installed with `guix package` and /etc/profile.d/vte.sh show up if installed with `guix system`. Neither ~/.guix-profile/etc/profile or /etc/profile source their respective profile.d files though like Trisquel does. Can someone give me a lead on how these profiles are generated? Regards, Ben
bug#35424: Gnome terminal doesn't keep current working directory in new tab/window
On 23/07/19 16:35, Efraim Flashner wrote: >> Interesting. Is this file installed to /etc/profile.d/vte.sh on other >> systems? Or is it otherwise sourced? >> > > I can only speak for my own system. I don't have gnome-terminal > installed, but I do have tilda which uses vte. My > ~/.guix-profile/etc/profile.d/ only has bash_completion.sh. I wonder if it's just a matter of moving vte to the propagated-inputs of gnome-terminal (and other packages like tilda)? I'll try now and report back. Regards, Ben
bug#35424: Gnome terminal doesn't keep current working directory in new tab/window
On Mon, Jul 22, 2019 at 09:09:13PM +0200, Ricardo Wurmus wrote: > > Hi Ben, > > >> Just minor thing, but on other systems I use, when you open subsequent > >> Gnome Terminal tabs, the current working directory is maintained in the > >> new tab. On my Guix System, new tabs start up back at /home/ben. > > > > I've found that sourcing vte.sh fixes the issue, and the working > > directory is retained: > > > > `source /gnu/store/...-vte-0.52.2/etc/profile.d/vte.sh` > > Interesting. Is this file installed to /etc/profile.d/vte.sh on other > systems? Or is it otherwise sourced? > I can only speak for my own system. I don't have gnome-terminal installed, but I do have tilda which uses vte. My ~/.guix-profile/etc/profile.d/ only has bash_completion.sh. -- 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
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Mark H Weaver writes: Hi Mark, >> I have added a very similar set of two patches to wip-cu-binaries, >> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. >> >> They give the same md5sum for me as the wip-binaries branch that >> branched off of master; so mine are at >> http://lilypond.org/janneke/guix/20190722/ > > I built these, and here are the results: > > mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ > sha256sum * > b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276 > guile-static-stripped-2.2.4-i686-linux.tar.xz > 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a > linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz > 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 > mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz > fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 > mes-minimal-stripped-0.19-i686-linux.tar.xz > 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c > static-binaries-0-i686-linux.tar.xz > > Do these match what you built? Well... 08:16:12 janneke@dundal:~/src/guix/wip-cu-binaries [env] $ sha256sum /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/* adce360f68ed0083c7356c267c24271fa4907f8082c9d47db28b603f9da5e763 /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/guile-static-stripped-2.2.4-i686-linux.tar.xz 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/mes-minimal-stripped-0.19-i686-linux.tar.xz c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0/static-binaries-0-i686-linux.tar.xz ...for mescc-tools and mes: yes. I have put them all up here: http://lilypond.org/janneke/guix/20190722 > For the sake of completeness, I built these by running > > ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux > > from a git checkout at commit 5a6465e41a84b4320940d33709b80d78c1aff9d0. /me too >> After this commit should come the update-commit, using them in >> bootstrap.scm. > > Right, except those commits should be applied to the tip of > 'core-updates', and not until we're sure that these new bootstrap > binaries are good. Yes. > Ludovic, what do you think? FWIW, I'm working on a mes-0.20 release that supports Nyacc-0.99.0 (and hopefully 1.0.0) and mescc-tools-0.6 and building on Debian ootb. There's no real reason to update bootstrap tarballs for those versions and I cannot promise a release date yet. Further work on mes-0.21 should bring the Reduced Binary Seed bootstrap to ARM (lots of work still) and replace the `static-binaries' with Gash, reducing the size of our bootstrap binaries once again by ~50%. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
