bug#44519: Qemu fails to start Samba server
Um. Apparently, I was the one failing. I just tried connecting again, and as long as smbd has setuid, the qemu SMB share works as advertised. Sorry for the false alarm.
bug#44428: Graphical Installer window clipping on "small" displays
On Sat, 2020-11-07 at 13:23 +0100, Mathieu Othacehe wrote: > Pushed as 6dcbbcdab7727946cf32e7a4e44e66d151380db2. Great! Thank you! > On QEMU with 800x600 resolution there's no more box overflow. I hope > it will be the same on your hardware that seem to have a slightly higher > resolution. It seems that the qemu testing with restricted resolution is sufficient. `~Eric
bug#44525:
bug#44525: Derivation of computed-file has no outputs
Hi Marius! > Assuming you intended to write (%current-system) to test.txt, you can do > something along these lines: > > (computed-file "test.txt" > #~(call-with-output-file #$output > (lambda (port) > (format port #$(%current-system) Thanks for this solution. > That's expected: this derivation does not produce any outputs. > So I think this is not-a-bug. WDYT? I think I got a bit distracted by the functionality of plain-file and the similar wording of the documentation of computed-file. Thanks, I’ll close this issue. Bye Stefan
bug#44525: Derivation of computed-file has no outputs
Stefan writes: > Hi! > > I try to use a computed-file as an input to a bootloader profile hook > function. Using guix system I get this error message: > > guix system: error: reference to invalid output 'out' of derivation > '/gnu/store/946szbrwn3ja74yjnibbhjisjflvsk73-test.txt.drv' > > This is the simple definition of the computed-file: > > (computed-file "test.txt" (with-imported-modules '((guix utils)) > #~(%current-system))) That's expected: this derivation does not produce any outputs. Assuming you intended to write (%current-system) to test.txt, you can do something along these lines: (computed-file "test.txt" #~(call-with-output-file #$output (lambda (port) (format port #$(%current-system) So I think this is not-a-bug. WDYT? signature.asc Description: PGP signature
bug#44525: Derivation of computed-file has no outputs
Hi!
I try to use a computed-file as an input to a bootloader profile hook function.
Using guix system I get this error message:
guix system: error: reference to invalid output 'out' of derivation
'/gnu/store/946szbrwn3ja74yjnibbhjisjflvsk73-test.txt.drv'
This is the simple definition of the computed-file:
(computed-file "test.txt" (with-imported-modules '((guix utils))
#~(%current-system)))
And this is the content of the generated derivation of it:
Derive([],[("/gnu/store/0hcx4wgpgf1nn4gl3lhnd055vj2y28cj-guile-3.0.2.drv",["out"]),("/gnu/store/2ss1lzy0x0wwayy5n5mvzmsv77dnni39-module-import-compiled.drv",["out"])],["/gnu/store/9lw2pp0hjcjgmq5hx7w6aq92699r6pim-module-import","/gnu/store/plgbvrkkq1ghvph24kf0bdgb4w8glgqb-test.txt-builder"],"aarch64-linux","/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile",["--no-auto-compile","-L","/gnu/store/9lw2pp0hjcjgmq5hx7w6aq92699r6pim-module-import","-C","/gnu/store/3v6bh2hn62i4qp674d1hqg4ca7hpys3a-module-import-compiled","/gnu/store/plgbvrkkq1ghvph24kf0bdgb4w8glgqb-test.txt-builder"],[("preferLocalBuild","1")])
I think the problem is visible already with this call:
scheme@(guile-user)> (derivation-path->output-paths
"/gnu/store/946szbrwn3ja74yjnibbhjisjflvsk73-test.txt.drv")
$5 = ()
Bye
Stefan
bug#44520: Graphical installer issues on 1.2.0.
Hey, I cannot reproduce the partitioning issue which is even more frustrating. I guess it was related to the original partitioning of the USB drive I used. Added some more debug logging with 8c287bb2fb1 in the meantime. > Could it be that these get downloaded due to some “debug” output being > pulled (perhaps unnecessarily so but grafting can do that sometimes)? I'm not sure yet but I'll run more tests tomorrow. >> * The substitutes download speed was sometimes super low (~ 50Kb/s). > > Yes, unfortunately non-offloaded disk image builds (fixed by recent > commits) along with GC running all day long has a terrible impact on > bandwidth. Oh, right. Thanks for your recent patches on this subject. It should definitely help. Having berlin doing nothing much that serving substitutes and coordinating the build machines will solve many issues. I'm working on that topic and will present my progress during Guix Days! Thanks, Mathieu
bug#44520: Graphical installer issues on 1.2.0.
Hi, Mathieu Othacehe skribis: > I tried the 1.2.0 graphical installer at ae0fe28, installing Guix System > from a usb drive to another one. > > I had three issues: > > * The auto partitioning crashed, backtrace as attachment. Argh. > * Using manual partitioning as a work-around, I started the installation > and observed that the installer downloaded "python" sources and then > substitutes for the whole bootstrapping chain (also as attachment). Could it be that these get downloaded due to some “debug” output being pulled (perhaps unnecessarily so but grafting can do that sometimes)? > * The substitutes download speed was sometimes super low (~ 50Kb/s). Yes, unfortunately non-offloaded disk image builds (fixed by recent commits) along with GC running all day long has a terrible impact on bandwidth. It should get a bit better at least now that disk image builds will no longer happen on the head node, but OTOH there’s still a lot of build activity happening and that definitely increases pressure. I look forward to the day where using the Build Coordinator we can better decouple the build farm from the node running ‘guix publish’. Thanks, Ludo’.
bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable
Hi Vagrant,
Vagrant Cascadian skribis:
> If this could be considered for the upcoming 1.2 release, that would be
> appreciated, though I can also carry the patches in Debian...
Yay! It should be doable, let’s see.
> From 36516e767f68dbc2bd3dc186f956c0b0fd7de9f1 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian
> Date: Thu, 5 Nov 2020 17:35:52 -0800
> Subject: [PATCH] tests: Support disabling network tests.
>
> This is needed for packaging GNU Guix in Debian, where packaging policies
> prohibit network access during builds, but may not technically block network
> access during builds.
>
> * guix/tests.scm (network-reachable): Return #f when
> GUIX_DISABLE_NETWORK_TESTS is set.
> * tests/common.sh: New file.
> * tests/guix-build-branch.sh, tests/guix-environment.sh,
> tests/guix-pack.sh, tests/guix-package-net.sh: Use
> network_reachable function from common.sh.
[...]
> --- /dev/null
> +++ b/tests/common.sh
> @@ -0,0 +1,8 @@
> +network_reachable() {
> +if [ -n "$GUIX_DISABLE_NETWORK_TESTS" ]; then
> + exit 77
> +fi
> +if ! guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2>
> /dev/null; then
> +exit 77
> +fi
> +}
Could you add the usual copyright/license header? Also please add this
file to ‘EXTRA_DIST’ in Makefile.am.
Looking at the tests you modified, we need two things:
• a ‘network_reachable’ function that returns true or false, without
exiting;
• a ‘skip_if_network_is_unreachable’ function that does “exit 77” when
network is “unreachable”.
> --- a/tests/guix-environment.sh
> +++ b/tests/guix-environment.sh
> @@ -174,9 +174,9 @@ case "$transformed_drv" in
> *) false;;
> esac
>
> +. $(dirname $0)/common.sh
> +network_reachable
>
> -if guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2> /dev/null
> -then
> # Compute the build environment for the initial GNU Make.
> guix environment --bootstrap --no-substitutes --search-paths --pure \
I think this is the only place where you’d write “if network_reachable”
instead of “skip_if_network_is_unreachable”.
WDYT?
Thanks!
Ludo’.
bug#44053: ‘xdg-mime-database’ profile hook is slow
Hi,
Luis Felipe skribis:
> Compared to grafting, the last step "construyendo perfil con X paquetes..."
> ("building profile with X packages..."), just stays there without change for
> several minutes, so it actually seems slower to me. Initially, I thought that
> guix had frozen.
>
> Also, even though, the "building profile" step has a throbber (| / - \) to
> indicate that something is being done, it frequently stops in one of the
> frames of the sequence and stays there until the end.
Interesting, so we should profile that step and see what can be done. I
suspect it’s I/O-bound, but maybe we can at least improve feedback.
Thanks,
Ludo’.
bug#44519: Qemu fails to start Samba server
Hey Guix, Having trouble getting the Samba directory share in qemu to work as advertised: $ qemu-system-x86_64 -netdev user,id=net0,smb=/share ... Running something like the above with samba installed should spin up `smbd`; however, this doesn't happen. I see no smbd processes started. Qemu does create /tmp/qemu-smb.XX/smb.conf, however. Am I just missing something obvious? Can your reproduce? Digging through the qemu repo[0], it looks like qemu calls out to a samba daemon with an invocation that resolves to this: $ smbd -l /tmp/qemu-smb.XX -s /tmp/qemu-smb.XXX/smb.conf Manually running the above results in silent failure, though. To be clear, running the above with --foreground makes no difference. For good measure, I am attaching the smb.conf that qemu generates, in case you want to directly try the smbd command without spinning up qemu. Note, you may need to edit the 'path=/shared' line to an existing directory on your machine. Throwing strace at the above shows that the daemon is getting EPERM when trying to bind() the priviledged ports 445 and 139. Indeed, running the daemon under sudo works as expected, and I am able to access the shared directory from the guest machine as intended. Given the permission issues, I did try adding /sbin/smbd to my setuid-programs, but that seems to make no difference. Is this a PEBKAC issue or a legitimate bug? [0]:https://github.com/qemu/qemu/blob/7f368aed672117980f7f09933e1eb3e1139caae6/net/slirp.c [global] private dir=/tmp/qemu-smb.2IQ1T0 interfaces=127.0.0.1 bind interfaces only=yes pid directory=/tmp/qemu-smb.2IQ1T0 lock directory=/tmp/qemu-smb.2IQ1T0 state directory=/tmp/qemu-smb.2IQ1T0 cache directory=/tmp/qemu-smb.2IQ1T0 ncalrpc dir=/tmp/qemu-smb.2IQ1T0/ncalrpc log file=/tmp/qemu-smb.2IQ1T0/log.smbd smb passwd file=/tmp/qemu-smb.2IQ1T0/smbpasswd security = user map to guest = Bad User load printers = no printing = bsd disable spoolss = yes usershare max shares = 0 [qemu] path=/share read only=no guest ok=yes force user=x
bug#44508: Found a bug in compute-guix-derivation
It did not repeat, and I'm using it on a hosted system with Ubuntu.
On Sat, Nov 7, 2020 at 4:59 PM Marius Bakke wrote:
> Josh Marshall writes:
>
> > Hello all,
> >
> > When pulling I came across the following which told me to send a report
> in:
> >
> > ```
> > anadon@goodadvicemallard:~$ guix pull
> > Updating channel 'guix' from Git repository at '
> > https://git.savannah.gnu.org/git/guix.git'...
>
> [...]
>
> > substitute: updating substitutes from 'https://ci.guix.gnu.org'...
> 100.0%
> > @ substituter-started
> > /gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2
>
> [...]
>
> > gzip: stdin: unexpected end of file
> > guix substitute: error: corrupt input while restoring
> > '/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2/bin/git'
> > from #{read pipe}#
> > @ substituter-failed
> > /gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2 256
> fetching
> > path `/gnu/store/4kq9k7cvwmg42hvk71m2kihiasz7x9z8-git-minimal-2.29.2'
> > failed with exit code 1
>
> [...]
>
> > ./guix/store.scm:1368:15: ERROR:
> > 1. :
> > message: "some substitutes for the outputs of derivation
> > `/gnu/store/6kd94qkd2hnkri5hc44vfjvh8b0i5ynl-git-minimal-2.29.2.drv'
> failed
> > (usually happens due to networking issues); try `--fallback' to build
> > derivation from source "
>
> Probably this was a transient (network) failure, or is the error
> consistent?
>
> And for something completely different:
>
> >
> /gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute
>
> Consider updating the 'root' user Guix (or reconfigure, if you are on
> Guix System), to get the latest version of guix-daemon.
>
bug#44516: guix build freetype --target=mips64el-linux-gnu produces 32-bit library
As the title says, 'guix build freetype --target=mips64el-linux-gnu' produces a 32-bit library. With this it isn't possible to cross-build grub for mips64el-linux. -- 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#44353: guix system disk-image -t raw fails with grub-efi-bootloader
Hey, > $ time ./pre-inst-env guix system disk-image > gnu/system/examples/lightweight-desktop.tmpl --verbosity=2 --no-offload > > That took 38 minutes on my system and produced /gnu/store/...-disk-image. Strange, only 8 minutes for me. Does it include the time necessary to fetch all substitutes? Are you using a SSD drive? > $ qemu-system-x86_64 -m 1024 -bios $(guix build > ovmf)/share/firmware/ovmf_x64.bin -hda /tmp/lightweight-desktop.img It tries to mount the EFI file-system with UUID "1234-ABCD" and fails. You can remove this one for the lightweight-desktop configuration to obtain a bootable system. > Would break if device was set to #f, as is done in (guix build image)'s > initialize-efi-partition: > > (when bootloader-installer > (display "installing bootloader...\n") > (bootloader-installer bootloader-package #f root)) > > Is my analysis correct? If so, the patch I sent yesterday would fix the > problem more thoroughly. Yes it is probably broken too. However, I would prefer not to introduce bootloader specific stuff in (gnu system image). I think the bootloaders should try to do their best with the DEVICE and MOUNT-POINT arguments passed to bootloader-installer procedure. It means, trying to install themselves using only MOUNT-POINT argument or bailing out. WDYT? Thanks, Mathieu
bug#44428: Graphical Installer window clipping on "small" displays
Hey Ludo, > How do you tell QEMU to use that resolution? --8<---cut here---start->8--- qemu-system-x86_64 -m 1024 -cdrom image.iso -display sdl -vga none -device virtio-vga,xres=800,yres=600 --8<---cut here---end--->8--- > 8338d414b361e4fb961221642c1064e9dc89ba65 looks reasonable though, so I > think you can cherry-pick it in ‘version-1.2.0’. Done :) Thanks, Mathieu
