bug#36753: The GUI installer throws an error
> However, “failed to build openssh” looks like another failure worth > investigating. Do you have more info as to what happened exactly, > what was printed? Can you reproduce it? It would be great if you > could post a picture of the screen at that point. Sorry for the delay, I had no free hard drive do test installation again. The thing that failed to build was openssl, not openssh. The error message is "build of /gnu/store/long-sum-openssl-1.0.2p.drv failed". What I did during the installation: - whole disk with encryption - tor, mozilla nss - i3, xfce, enlightenment And when the installer asked me if I want to continue without network connection I plugged-in the ethernet cable.
bug#36753: The GUI installer throws an error
Okay I've figured out what causes openssl build to fail - continuing installation without network connection. The installer told me network connection is required to install the system correctly, but I thought only packages will be outdated. Is it a bug?
bug#36753: The GUI installer throws an error
> That you were able to continue without networking looks like a bug. > However, I just tried, and when networking is unavailable, I get the > “Connection error” box that only allows me to go back to the “Checking > connectivity” dialog; there’s no way to skip that AFAICS. Okay, I now know what *probably* have happened. My proprietary motherboard - MSI PC Mate B350 tricked me - after updating the firmware and enabling the "UEFI mode" instead of "UEFI or legacy BIOS" I got a higher resolution and network started to work normally. Before enabling it, the GUI installer couldn't find network connection itself, so I had to manually configure network connection by using ifconfig and dhclient, then I just followed the GUI installer, and it somehow let me continue with or without networking. Tried switching back to BIOS mode, but I can't reproduce the bug anymore. None of this happens on my librebooted machine, tried hard to break the installation :). Guess that's it, thanks for your time. I'm probably going to sell this nonfree machine anyway. Jan
bug#37345: Icecat doesn't display numbers on Guix System
Hi everyone, I've recently installed Icecat on Guix System natively and it doesn't display numbers properly - instead of numbers, there are transparent squares without a black frame - they're just invisible globally, no matter if on a website or in the browser's interface. Tried changing font to GNU unifont (because it supports the whole unicode), reinstalling Icecat (which shouldn't help anyway, because Guix is reproducible, including bugs), guix pulling, system reconfiguration, but nothing helps. I have this issue only on Icecat, because ungoogled chromium and other programs display numbers properly. architecture: x86_64 I saw a similar bug in the database, but it's from 2017 and it was about font issue on other distributions, not on Guix System, so I submitted a new report, hope that's not a problem. Jan Wielkiewicz
bug#37345: Icecat doesn't display numbers on Guix System
On Sun, 08 Sep 2019 15:20:12 -0600
Jesse Gibbons wrote:
> I cannot replicate.
> What commit did you notice this? (guix describe)
Since the beginning, not sure what commit (checked with 'guix system
list-generations'), that was:
"Generation 1 September 01 2019 01:15:51"
Probably a fresh Guix System installation from the ISO image from the
website.
Now I run the following commit:
ba7bd6c62ddaab4d5623fb149b47579e13a9e5f5
And the bug is still present
> Are there any settings different from the default?
I did nothing special to Icecat, just installed a few add-ons: Umatrix,
Ublock Origin and "Dark Background and Light Text", these add-ons don't
cause any problems on Firefox for example, but removed the ".mozilla"
folder just to be sure, also I remember that displaying numbers hadn't
worked since the beginning, even before I installed the add-ons.
As for the system, here's my configuration file:
(use-modules (gnu))
(use-service-modules desktop networking ssh xorg)
(operating-system
(locale "pl_PL.utf8")
(timezone "Europe/Warsaw")
(keyboard-layout (keyboard-layout "pl" "legacy"))
(bootloader
(bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")
(keyboard-layout keyboard-layout)))
(swap-devices (list "/dev/sda3"))
(file-systems
(cons* (file-system
(mount-point "/home")
(device
(uuid "640b9945-4421-403a-93da-02768c28b29b"
'btrfs))
(type "btrfs"))
(file-system
(mount-point "/")
(device
(uuid "55c8dec3-4e68-4441-9d78-a9b55d9fc9bd"
'ext4))
(type "ext4"))
%base-file-systems))
(host-name "navi")
(users (cons* (user-account
(name "user")
(comment "User")
(group "users")
(home-directory "/home/user")
(supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts))
(packages
(append
(map specification->package
'("i3-wm"
"nss-certs"
"icecat"
"ungoogled-chromium"
"libreoffice"
"mpv"
"gimp"
"emacs"
"emacs-paredit"
"emacs-auto-complete"
"gnupg"
"htop"))
%base-packages))
(services
(append
(list (service mate-desktop-service-type)
(service tor-service-type)
(extra-special-file "/usr/bin/env"
(file-append coreutils "/bin/env"))
(extra-special-file "/bin/bash"
(file-append coreutils "/bin/bash"))
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout
%desktop-services)))
bug#37345: Icecat doesn't display numbers on Guix System
Okay, I found some probably more helpful info - I run icecat in a terminal and it throws the following warnings, don't know if they're related to this bug though: (icecat:4612): Gtk-WARNING **: 22:11:57.437: Theme parsing error: :1:34: Expected ')' in color definition (icecat:4612): Gtk-WARNING **: 22:11:57.437: Theme parsing error: :1:77: Expected ')' in color definition 1567980717781 addons.webextension.tortm-browser-button@jeremybenthum WARNPlease specify whether you want browser_style or not in your browser_action options. 1567980717784 addons.webextension.https-everywh...@eff.orgWARNPlease specify whether you want browser_style or not in your browser_action options. (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.541: failed to create cairo scaled font, expect ugly output. the offending font is 'Nimbus Sans L 9.9990234375' (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.541: font_face status is: file not found (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.541: scaled_font status is: file not found (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.541: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='Nimbus Sans L 9.9990234375', text='' (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.546: failed to create cairo scaled font, expect ugly output. the offending font is 'Nimbus Sans L 9.9990234375' (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.546: font_face status is: file not found (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Pango-WARNING **: 22:11:58.546: scaled_font status is: file not found (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-guix1/lib/icecat/.icecat-real:4648): Gtk-WARNING **: 22:11:59.461: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg. This may indicate that pixbuf loaders or the mime database could not be found. JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: TypeError: cache is undefined JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: TypeError: cache is undefined JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: TypeError: cache is undefined JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: TypeError: cache is undefined JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: TypeError: cache is undefined --- Jan Wielkiewicz
bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page
Hi, I'm a new Guix user and I wanted to hack on Guix and update a package, I hadn't known exactly how to do this, so I started following instructions from https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html#Running-Guix-Before-It-Is-Installed and https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/ The situation started to be interesting, when the tutorial told me to run "cd $GUIX_CHECKOUT" and "./pre-inst-env guix package --list-available=ruby" I was confused, because I couldn't find any "./pre-inst-env" file, so I used 'find' to search for it and there were one file with a similar name in $GUIX_CHECKOUT/build-aux - ./pre-inst-env.in (as I'm composing this email now I see that's stupid, but I tried using this file, as I don't know what I was doing (still don't know)) So I started running the following stupid commands: user@machine ~/Prog/repo/guix [env]$ sudo -E ./pre-inst-env.in guix-daemon --build-users-group=guixbuild sudo: /gnu/store/z26h622slm8p61myhk45v3jjg8p7qm8z-profile/bin/sudo must be owned by uid 0 and have the setuid bit set user@machine ~/Prog/repo/guix [env]$ ./pre-inst-env.in bash: ./pre-inst-env.in: No such file or directory user@machine ~/Prog/repo/guix [env]$ cd build-aux/ user@machine ~/Prog/repo/guix/build-aux [env]$ sudo -E ./pre-inst-env.in guix-daemon --build-users-group=guixbuild sudo: /gnu/store/z26h622slm8p61myhk45v3jjg8p7qm8z-profile/bin/sudo must be owned by uid 0 and have the setuid bit set user@machine ~/Prog/repo/guix/build-aux [env]$ exit --- And then: -- user@machine ~/Prog/repo/guix/build-aux$ chmod +x ./pre-inst-env.in user@machine ~/Prog/repo/guix/build-aux$ sudo -E ./pre-inst-env.in guix-daemon --build-users-group=guixbuild Password: ./pre-inst-env.in: line 33: cd: @abs_top_srcdir@: there is no such file or directory ./pre-inst-env.in: line 34: cd: @abs_top_builddir@: there is no such file or directory And after that I couldn't run "guix environment" anymore, it threw an error: guix environment: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused Restarting the computer helps, but doing the same stuff breaks it again, so guess it's reproducible. After doing it I ran the "history" command so you can know what I did exactly (some commands were unfortunately run in an environment and I can't provide them), here it is: 371 git clone --recurse-submodules git://git.savannah.gnu.org/guix.git 372 guix environment guix --pure 373 sudo -E 374 sudo --help 375 guix environment guix --pure 376 guix environment guix --pure --ad-hoc sudo 377 ls 378 cd guix/ 379 ls 380 cd build-aux/ 381 ls 382 . 383 guix environment guix --pure 384 chmod +x ./pre-inst-env.in 385 sudo -E ./pre-inst-env.in guix-daemon --build-users-group=guixbuild 386 ls 387 cd .. 388 ./configure 389 guix environment guix --pure 390 history As stupid and complicated as it is, something is definitely broken here. Sincerely, Jan Wielkiewicz
bug#37345: Icecat doesn't display numbers on Guix System
> Looks like it isn't finding the "Nimbus Sans L" font. Try running > > fc-list | grep "Nimbus Sans L" > > and reply with the output. Here is the output /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019004l.pfb: Nimbus Sans L:style=Bold /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019064l.pfb: Nimbus Sans L:style=Bold Condensed Italic /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019003l.pfb: Nimbus Sans L:style=Regular /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019044l.pfb: Nimbus Sans L:style=Bold Condensed /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019043l.pfb: Nimbus Sans L:style=Regular Condensed /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019063l.pfb: Nimbus Sans L:style=Regular Condensed Italic /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019023l.pfb: Nimbus Sans L:style=Regular Italic /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019024l.pfb: Nimbus Sans L:style=Bold Italic Jan
bug#37345: Icecat doesn't display numbers on Guix System
> I got this too when I first installed icecat. > I am not sure why, but I got no readable presentation > from icecat until I had done > guix install font-dejavu This one helps, thanks a lot! > Jesse's fc-list suggestion indicates that the Nimbus fonts ought to > come in by > guix install gs-fonts > > maybe that would work as well as or better than > guix install font-dejavu > > Idk :) This doesn't help. Anyway shouldn't the font-dejavu package be a dependency of Icecat then? Jan Wielkiewicz
bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page
> Do not run ./configure alone, always specify --localstatedir=/var > unless you plan to run the daemon from the repo too (then it's fine > without the option, but you won't be able to pull or you'll get into > trouble iiuc). Thank you all for advice, after running ./configure --localstatedir=/var the file has been generated. Then to be able to run Guix, I had to do "make check". Now I have Guix available and I would like to update a package, like showed in the manual or the tutorial, but running for example "./pre-inst-env guix refresh opendht" throws the following error: Backtrace: 18 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 17 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 16 (_ #(#(#))) In guix/ui.scm: 1692:12 15 (run-guix-command _ . _) In ice-9/boot-9.scm: 829:9 14 (catch _ _ # ?) 829:9 13 (catch _ _ # ?) In guix/store.scm: 623:10 12 (call-with-store _) 1803:24 11 (run-with-store # _ # _ ?) In guix/scripts/refresh.scm: 541:14 10 (_ _) In srfi/srfi-1.scm: 640:9 9 (for-each # ?) In guix/scripts/refresh.scm: 344:2 8 (check-for-package-update # ?) In guix/import/github.scm: 231:25 7 (latest-release #) 200:22 6 (latest-released-version "https://github.com/savoirfai?"; ?) 163:2 5 (fetch-releases-or-tags _) In ice-9/boot-9.scm: 829:9 4 (catch srfi-34 # ?) In guix/import/json.scm: 41:19 3 (_) In guix/http-client.scm: 88:25 2 (http-fetch _ #:port _ #:text? _ #:buffered? _ # _ # _ # ?) In guix/build/download.scm: 426:4 1 (open-connection-for-uri _ #:timeout _ # _) 313:6 0 (tls-wrap # _ # _) guix/build/download.scm:313:6: In procedure tls-wrap: X.509 certificate of 'api.github.com' could not be verified: signer-not-found invalid Am I missing a dependency in my environment? Running "guix refresh" without ./pre-inst-env and "guix environment guix --pure" works. Jan Wielkiewicz
bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop
Hi. Changing the login service from GDM to SLiM and then back to GDM makes GDM to loop like this: "New session c1 of user gdm." "Removed session c1." "New session c2 of user gdm." "Removed session c2." ... And it continues like this to relatively high numbers like c167. Didn't check how far it could go, but that's not important anyway. Reverting to the previous definition of the system by using "guix system switch-generation" or using grub menu entries doesn't help, changing /etc/config.scm back to the default gdm configuration and running "guix system reconfigure" doesn't help either. There's also one strange thing that have happened before rebooting - when logging off, SLiM was running in a loop too - I couldn't turn off the computer using it, I had to switch to another tty and run "shutdown" manualy. But reverting to a configuration with SLiM works - I can use the system with it, but can't with GDM anymore. --- Jan Wielkiewicz
bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page
Dnia 2019-09-16, o godz. 18:01:04 Ludovic Courtès napisał(a): > Hi Jan, > > Jan skribis: > > > guix/build/download.scm:313:6: In procedure tls-wrap: > > X.509 certificate of 'api.github.com' could not be verified: > > signer-not-found > > invalid > > It looks like X.509 certificates used to authenticate web sites over > HTTPS could not be found. > > Did you set environment variables and all as described at > <https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html>? > > HTH, > Ludo’. I have nss-certs installed as a global package in my config.scm and refreshing only doesn't work in the environment created by "guix environmnet guix --pure" - it works without an environment. Tried using "--ad-hoc nss-certs", but it didn't work. The manual says I have to add certs manually if I'm an unprivileged user or running Guix on a foreign distro, but I'm running Guix natively on my machine. Do I have to define variables like this anyway? --- Jan Wielkiewicz
bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop
On Tue, 17 Sep 2019 00:45:58 -0400 Timothy Sample wrote: > Could this be the same issue as <https://bugs.gnu.org/36508>? In > short, Guix doesn’t guarantee that the “gdm” user will have the same > UID if it gets deleted and recreated (which happens when you remove > the GDM service and add it again). You can fix this by ensuring the > owner of the files under “/var/lib/gdm” is the current “gdm” user. > > > -- Tim Yes, this seems to be the same issue. I'll try the solution, but it needs to be fixed anyway. Hope someone works on that. Thanks for help! --- Jan
bug#37422: Setting keyboard layout with SLiM login manager doesn't work
On Wed, 18 Sep 2019 00:00:27 -0500 quil...@riseup.net wrote: > > PS tried sending this message to > > https://issues.guix.gnu.org/issue/26234 > > but it got lost. Is it an accident, or is sending messages to closed > > issues impossible? > > It is closed. This was the last comment: > > It’s been a while :-), but this is fixed by > 598757e038ab5dea3b59c9c248a2ad860c41fe62, which lets you choose the > Xorg keyboard layout (this was already possible before actually, but > a bit more involved.) > The answer is from March, I ran "guix pull" and "sudo guix system reconfigure /etc/config.scm" today, and the keyboard layout is still unavailable. There's a chance this bug is similar to the bug from the past, but not the same, letting it exist unnoticed. --- Jan Wielkiewicz
bug#37482: Guix fails to build libreoffice
On Sun, 22 Sep 2019 19:45:52 +0200 Tobias Geerinckx-Rice wrote: > 2 GiB of RAM is simply not enough to build many packages these > days. That's the world we live in. There's nothing Guix can do > to change that. Sad, guess I have to buy more RAM. > You can restrict the number of parallel builds and jobs by > respectively passing --max-jobs=1 and --cores=1 to the daemon. > You can make this permanent by setting (extra-options …) in your > system configuration. Cool, didn't know about this option. > Even then, some complex executables will simply fail to link with > so little RAM. > > Your issue is different: the exact same libreoffice might have > built fine if you had 4 GiB of RAM, or 3, or 5, or 2 with swap, > but only if your weren't also running any (Guix or other) builds > at the time, or watching a movie, or had the room thermostat > turned up, or use Gnome 3, all beneath a gibbous moon. All these > things, and many more, will cause builds to fail or succeed > ‘randomly’. I actually have a 10GB sized swap file created on an SSD and defined in the config.scm, but it didn't help. I'm also using Mate, but I can try without any DE. The only two things running in the background were Mate, mate terminal, Guix and %desktop-services. > I personally think the annoyances of ‘helpful’ warnings > (=extremely inaccurate guesses) would far outweigh any purported > benefit. > > Kind regards, > > T G-R Is there a way to skip building libreoffice, if the substitute isn't available? >Or just how quickly it can destroy an SSD. Even more fun... Waiting for a powerful libre computer from from the ground, because running on old ThinkPads forever isn't the right solution. Thanks for explanations and help, Jan Wielkiewicz
bug#37482: Guix fails to build libreoffice
On Thu, 26 Sep 2019 22:04:50 +0200 Ludovic Courtès wrote: > There’s no way to skip it. However, there are a couple of tricks: What about adding an option to only download substitutes for older devices? I saw someone talking about such feature on the mailing list, don't know where exactly though. > • The ‘--dry-run’ option always shows what would be built or > downloaded, so you can run, say, ‘guix upgrade --dry-run’ and see > if libreoffice is among the things that would be built. > > • You can do ‘guix package -u . --do-not-upgrade=libreoffice’ to > upgrade everything but packages whose name contains “libreoffice”. Will use these options next time, thanks for the info. Jan Wielkiewicz
bug#37422: Setting keyboard layout with SLiM login manager doesn't work
On Sun, 29 Sep 2019 14:27:59 +0200 Wiktor Żelazny wrote: > The last thing that comes to my mind is the line: > >(use-service-modules desktop xorg) > > Have you got these in your config.scm? > > WŻ Yes I have. I wouldn't be able to run Mate DE, if I didn't have these two. Jan Wielkiewicz
bug#37694: Problem with guix pull from local repository
On Thu, 10 Oct 2019 20:13:45 +0200 Marius Bakke wrote: > This had nothing to do with your local checkout: it happened to > everyone who tried to 'guix pull' between commits 6c50e1dc0 and > 2d821e4c7. > > Sorry for the breakage! If you rebase your branch, it should work :-) Hello, I'm affected by this too and have no clue how to fix it. Can't switch to previous generations. Could you please tell me how to get it to work again please (I'm a relatively new Guix user)? Jan Wielkiewicz
bug#37694: Problem with guix pull from local repository
On Thu, 10 Oct 2019 21:09:44 +0200 Marius Bakke wrote: > Just 'guix pull' should be sufficient. > > If that does not work, can you paste the error you are getting? Somehow pulling a few times didn't work, but now it works. Strange, don't know what have happened.
bug#37734: Mate doesn't work after guix pull
Hi, After running "guix pull" and "guix system reconfigure" Mate works improperly - when you try to launch an application from the start menu, Mate throws an error "couldn't run gio-launch-desktop (there's not such a file or directory)". Jan Wielkiewicz
bug#38050: Guix fails during downloading a substitute of google-brotli, throws an ugly backtrace
On Sun, 10 Nov 2019 17:24:15 +0100 Ludovic Courtès wrote: > Hi Jan, > > How reproducible is it? 100%? > I tried only two times by now. It doesn't happen when I run "./pre-inst-env guix build google-brotli" though. So reproducibility is equal to 100% with 25% chance for error :) (while building Jami). > > Could you try again, this time stracing the process with: > > ./pre-inst-env strace -o /tmp/log -s 300 guix build jami > > ? Yes, but after I finish compiling all Jami dependencies and this takes some time on core 2 duo. If you didn't know - compiling libreoffice takes 7 hours, llvm - 3h, mariadb - 2h, fun! > Once you’ve reproduced the failure above, could you send /tmp/log (or > the tail of that file)? Okay. > Thanks in advance! > > Ludo’. Jan Wielkiewicz
bug#37757: Kernel panic upon shutdown
Hi, I encountered the same error today. I had ran "sudo herd stop tor" and then "sudo herd stop xorg-server" and it panicked. Jan Wielkiewicz
bug#38135: Mate: missing gio-launch-desktop
Anyone working on this? I have this error for a few months now both on Mate and XFCE. I could try fixing this, but have no clue where to start. Any suggestions? Jan Wielkiewcz
bug#38821: Can't run guix from external drive.
Hi,
I tried running "guix install" from my USB hard drive and that's what I
got:
user@machine /media/user/Backup$
Backtrace:
4 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 3 (call-with-prompt ("prompt") # …)
In ice-9/eval.scm:
619:8 2 (_ #(#(#)))
In ice-9/command-line.scm:
189:23 1 (load/lang "/home/lain/.config/guix/current/bin/guix")
In unknown file:
0 (getcwd)
ERROR: In procedure getcwd:
In procedure getcwd: There's no such a file or directory
Jan Wielkiewicz
bug#38821: Can't run guix from external drive.
On Thu, 02 Jan 2020 19:37:43 +0100 Ludovic Courtès wrote: > > It most likely means that the current working directory, > /media/user/Backup, was unmounted or somehow disappeared in the > meantime. > > Can you confirm that this is the case? > > Thanks, > Ludo’. Yes, it only happens, if the disk is unmounted. Is that normal? If it is, then a message telling what's wrong would be helpful. Jan Wielkiewicz
bug#41196: Xfce panel, exo-open: launching applications not working
Hello, while clicking on icons on Xfce panel, it fails to launch applications and throws "Couldn't run command /gnu/store/*hash*-exo-0.12.6/bin/exo-open --launch *Application name* %u There's no such file or directory". I thought I reported the issue somewhere, but my memory tricked me and I confused the issue with the "gio-launch-desktop" bug, which was recently resolved. If this can be resolved by a simple wrapper, unlike the "gio-launch-desktop" bug, I can try fixing it. By the way, the issue is present for like 7 months already. It seems something failed during making the 1.1.0 release and Guix as a distribution needs better procedures for handling the release process to avoid such bugs in the future. A checklist would be good. Maybe making a "Tests" page in the manual, something with the ability to modify the status of test: * panel: works * setting wallpaper: unknown/not tested yet etc. Jan Wielkiewicz
bug#41650: system-config-printer not working on foreign distribution - Namespace Gdk not available
Hello,
system-config-printer is not working on Devuan ASCII using the latest
Guix release.
Here's the backtrace:
Traceback (most recent call last):
File
"/gnu/store/fz669y4hkryf7gasz5rp2iazi67ibcbd-system-config-printer-1.5.12/share/system-config-printer/system-config-printer.py",
line 40, in gi.require_version('Gdk', '3.0') File
"/gnu/store/27lry9d3ja2jnxhvcp45v3l6pa8fkvqz-python-pygobject-3.34.0/lib/python3.8/site-packages/gi/__init__.py",
line 129, in require_version raise ValueError('Namespace %s not
available' % namespace) ValueError: Namespace Gdk not available
Jan Wielkiewicz
bug#21773: guix package -u "*" fails
I installed guix on my Fedora 23 machine according to https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation. After that, I don't recall installing anything but guile. When I attempt to run the following command, I see a backtrace. # guix package -u "*" warning: failed to install locale: Invalid argument Backtrace: In ice-9/boot-9.scm: 157: 16 [catch #t # ...] In unknown file: ?: 15 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 14 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 13 [eval # #] In ice-9/boot-9.scm: 2401: 12 [save-module-excursion #] 4050: 11 [#] 1724: 10 [%start-stack load-stack ...] 1729: 9 [#] In unknown file: ?: 8 [primitive-load "/gnu/store/85nyj4lz480mxaj5szffli3c1k2rbhfn-guix-0.8.3/bin/.guix-real"] In guix/ui.scm: 1032: 7 [run-guix-command package "-u" "*"] In ice-9/boot-9.scm: 157: 6 [catch srfi-34 # ...] 157: 5 [catch system-error ...] In guix/scripts/package.scm: 995: 4 [#] 854: 3 [process-actions (# # # # ...)] 566: 2 [options->installable (# # # # ...) #< entries: #>] In srfi/srfi-1.scm: 664: 1 [filter-map # ...] In unknown file: ?: 0 [make-regexp "*"] ERROR: In procedure make-regexp: ERROR: In procedure make-regexp: Invalid preceding regular expression # guix --version warning: failed to install locale: Invalid argument guix (GNU Guix) 0.8.3 -- Jan Synáček
bug#21788: Cannot build xz (download returns 403)
I cannot build xz with guix 0.8.3: $ guix build xz ... ERROR: download failed "http://tukaani.org/xz/xz-5.0.4.tar.gz"; 403 "Forbidden" ... I'm not sure if this can be solved by contacting the admin of that web, but I guess that bumping xz version to at least 5.0.8 (I checked it was possible to download this one) could fix this problem. -- Jan Synáček
bug#21974: can't build guix without 'makeinfo'
The build fails with an error if the 'makeinfo' binary is missing on the system. The configure script should check for 'makeinfo' and fail if not found (or maybe warn that the docs won't be built?). -- Jan Synáček
bug#21976: error when building vlc-2.2.1 (sha mismatch of a dependency)
I'm getting the following error: [...] Starting download of /gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz >From http://www.ladspa.org/download/ladspa_sdk_1.13.tgz... ladspa_sdk_1.13.tgz 10.5MiB/s 00:00 | 3KiB transferred output path `/gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz' should have sha256 hash `0srh5n2l63354bc0srcrv58rzjkn4gv8qjqzg8dnq3rs4m7kzvdm', instead has `0dmh3k49yl8ii96bz32vlgc8w1fz99295h93aghfb2q1myx81lqv' cannot build derivation `/gnu/store/ig427gsrfqybnpjmjcb53lh6mfvi7zpk-ladspa-1.13.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/lak2kjr7rf76myk6z0h91r05q6rl09rk-ffmpeg-2.8.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/gh3g0c310b6h1d9145zha9gv1fj3n5dl-vlc-2.2.1.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/10d780zc7bj43f71cf0pl9dl2p4q7s01-profile.drv': 1 dependencies couldn't be built guix package: error: build failed: build of `/gnu/store/10d780zc7bj43f71cf0pl9dl2p4q7s01-profile.drv' failed I'm using guix-0.9.0. -- Jan Synáček
bug#21974: can't build guix without 'makeinfo'
On Sat, Nov 21, 2015 at 9:40 PM, Ludovic Courtès wrote: > Jan Synáček skribis: > >> The build fails with an error if the 'makeinfo' binary is missing on >> the system. The configure script should check for 'makeinfo' and fail >> if not found (or maybe warn that the docs won't be built?). > > ‘makeinfo’ is necessary when building from a checkout or otherwise > modifying the manual, but it’s not necessary when building from a > tarball. See > <https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html>. > > Can you confirm you were building from a checkout? Yes, I was building from a checkout. Maybe it would make sense to make it optional, as 'help2man' is? I was only trying to test the latest version of guix and wasn't really interested in the documentation changes. -- Jan Synáček
bug#21976: error when building vlc-2.2.1 (sha mismatch of a dependency)
On Sat, Nov 21, 2015 at 9:51 PM, Efraim Flashner wrote: > On Sat, 21 Nov 2015 21:36:28 +0100 > Jan Synáček wrote: > >> I'm getting the following error: >> >> [...] >> Starting download of >> /gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz >> From http://www.ladspa.org/download/ladspa_sdk_1.13.tgz... >> ladspa_sdk_1.13.tgz 10.5MiB/s 00:00 | 3KiB >> transferred > ^^^ > download size is way too small >> output path `/gnu/store/c0kix7cn1pvdq5r563r97kxm66ldnf87-ladspa_sdk_1.13.tgz' >> should have sha256 hash >> `0srh5n2l63354bc0srcrv58rzjkn4gv8qjqzg8dnq3rs4m7kzvdm', instead has >> `0dmh3k49yl8ii96bz32vlgc8w1fz99295h93aghfb2q1myx81lqv' > ... >> I'm using guix-0.9.0. >> > > Their website seems to be down atm, which means their downloads are also > down. As a workaround, download from archive.org here: > https://web.archive.org/web/20150427072109/http://www.ladspa.org/download/ladspa_sdk_1.13.tgz > and then do `guix download file:///path/to/file` and that should at least > help for right now. Oh, I didn't notice that the download wasn't complete. The workaround helped. Sorry for the noise, Jan
bug#21991: 'guix download' without arguments produces guile backtrace
I guess it should just print an error or display usage. guix 0.9.0 Cheers, -- Jan Synáček
bug#23697: guix system reconfigure hangs, shows repl in messages
sole-keymap has been started. 2016-06-01 19:55:23 Respawning upower-daemon. 2016-06-01 19:55:23 Service upower-daemon has been started. 2016-06-01 19:55:23 Respawning avahi-daemon. 2016-06-01 19:55:23 Service avahi-daemon has been started. 2016-06-01 19:59:57 Evaluating user expression (register-services (primitive-load "/gn...") #). 2016-06-01 19:59:57 GNU Guile 2.0.11 2016-06-01 19:59:57 Copyright (C) 1995-2014 Free Software Foundation, Inc. 2016-06-01 19:59:57 2016-06-01 19:59:57 Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. 2016-06-01 19:59:57 This program is free software, and you are welcome to redistribute it 2016-06-01 19:59:57 under certain conditions; type `,show c' for details. 2016-06-01 19:59:57 2016-06-01 19:59:57 Enter `,help' for help. Greetings, Jan PS: I booted into Debian, did a new system init into /guix and am running GuixSD now. drakenvlieg.scm Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#24390: VM with postgres service broken in master
Hi! Building a VM with postgres service like so (pg.scm attached) guix system vm pg.scm --expose=$HOME --share=$HOME/tmp=/exchange on master @22 August e8bb433 gnu: Add kmscon. results in run-vm.sh that boots fine doing /gnu/store/0d28hg2ms78wciiwlq1ic1sk1i98vdd8-run-vm.sh -enable-kvm -m 2G -net nic,model=virtio -redir tcp:2223:: -redir -redir tcp:5433::5432 & Creating the same vm with today's master 392a4e1 guix hash: Add --exclude-vcs option. and running it /gnu/store/fikrcvp5bz1f8f152hgrn94lx677s95l-run-vm.sh -enable-kvm -m 2G -net nic,model=virtio -redir tcp:2223:: -redir tcp:5433::5432 & breaks like so (copied manually from graphical qemu box) Adding user guixbuilder10... Adding user postgres... ERROR: In procedure system*: ERROR: Wrong type (expecting string): #t ... In ./gnu/build/activation.scm: ... 152:20 (add-user "postgres" "postgres" #:uid #f #:comment "Po#" #) In unknown file: 0 (system* "useradd" "-g" "postgres" "-c" "PostgresSQL" se#" #) I'm not sure how to debug this further. Greetings, Jan pg.scm Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25442: Emacs compilation buffer segfault
Hi! Running bash crash.nw in an xterm makes Emacs segfault about 4 out of 5 times for me. Greetings, Jan crash.nw Description: Binary data mes.crash Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25442: stacktrace
Find attached. There is no debugging info, is there a package that I can install which includes the debugging symbols? stacktrace Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25442: stacktrace
Ludovic Courtès writes:
> The ‘emacs’ package currently doesn’t have a ‘debug’ output. So you
> would first need to add one:
>
> (outputs '("out" "debug"))
>
> and then install both outputs:
>
> guix package -i emacs emacs:debug
>
> See
> <https://www.gnu.org/software/guix/manual/html_node/Installing-Debugging-Files.html>.
Thank you! Very nice documentation. As discussed on IRC it was needed
to not use grafts to avoid gdb `CRC mismatch'
guix package --no-grafts -i emacs emacs:debug
I also set
~/.gdbinit
set debug-file-directory ~/.guix-profile/lib/debug
and did
guix build --source emacs
tar xf /gnu/store/wqdh5lxyrkzjhxy2rvs7qsbrd07lw89i-emacs-25.1.tar.xz
and set
(gdb) directory ~/src/guix/emacs-25.1/src
Now I have a full backtrace; attached.
I'm not sure how to continue here; I built Emacs from GIT and there the
problem is not present. Looking at the diff from 25.1 until HEAD I do
not see any obvious patches, neither does the git log point me to one.
Greetings,
Jan
bt
Description: Binary data
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25442: stacktrace
Ludovic Courtès writes: >> I'm not sure how to continue here; I built Emacs from GIT and there the >> problem is not present. Looking at the diff from 25.1 until HEAD I do >> not see any obvious patches, neither does the git log point me to one. > > So the question is whether this bug is introduced by our packaging or > whether it’s an upstream bug. Yes. > Perhaps you could build with (warning! this command does not > authenticate the tarball it downloads): > > guix package -i emacs emacs:debug \ > --with-source=ftp://alpha.gnu.org/gnu/emacs/emacs-25.1.91.tar.xz guix package -i emacs emacs:debug \ --with-source=ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-25.1.91.tar.xz inserted /pretest here > I’m afraid that’s all I can suggest now. That's a good suggestion. I have tried this and the bug is also gone here, with our packaging. So apparently it has been fixed upstream. Thanks! Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25782: guile: one test fails on Debian/HURD
Running ./pre-inst-env guix package -i hello on Debian/HURD one test fails when building Guile Running 00-repl-server.test FAIL: 00-repl-server.test: repl-server: simple expression - arguments: (expected-value "scheme@(repl-server)> $1 = 42\n" actual-value "scheme@(repl-server)> While reading expression:\nERROR: In procedure fport_fill_input: Resource temporarily unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In procedure fport_fill_input: Resource temporarily unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In procedure fport_fill_input: Resource temporarily unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In procedure fport_fill_input: Resource temporarily unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In procedure fport_fill_input: Resource temporarily unavailable\n$1 = 42\n") I'm using wip-hurd-native from https://gitlab.com/janneke/guix.git which adds to https://github.com/Phant0mas/guix-on-hurd.git a newer bootstrap guile and a procps-ng patch. --janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25442: stacktrace
Jan Nieuwenhuizen writes: > That's a good suggestion. I have tried this and the bug is also gone > here, with our packaging. So apparently it has been fixed upstream. long fixed, long -done. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#24390: VM with postgres service broken in master
Ludovic Courtès writes: > Sorry for not answering earlier. I cannot reproduce it with > v0.11.0-2111-g85533e2 and with the config you sent. > > Could you check on your side? Sorry for not getting back earlier. I've been running postgres VM's for quite some time now. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Hi!
As reported by laertus on irc[0]: guix pull on 0.13 without substitutes fails
guix pull
Starting download of /tmp/guix-file.3r6cH0
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
….tar.gz 5.7MiB/s 00:02 | 13.6MiB
transferred
unpacking
'/gnu/store/sginfwnrcfqn1far31gmzlaffd8xlxyy-guix-latest.tar.gz'...
Starting download of
/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz
From https://github.com/libgit2/libgit2/archive/v0.25.1.tar.gz...
following redirection to
`https://codeload.github.com/libgit2/libgit2/tar.gz/v0.25.1'...
v0.25.1 6.1MiB/s 00:01 | 4.1MiB
transferred
output path
`/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz' should have
sha256 hash `1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s', instead has
`0ywcxw1mwd56c8qc14hbx31bf198gxck3nja3laxyglv7l57qp26'
cannot build derivation
`/gnu/store/z1ky970mnamnbairnpyxxb72qnc485zq-libgit2-0.25.1.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/rl7ms8rmbywvydy4qf656g1sdfxafb7r-guile-git-0.0-2.06f9fc3.drv': 1
dependencies couldn't be built
guix pull: error: build failed: build of
`/gnu/store/rl7ms8rmbywvydy4qf656g1sdfxafb7r-guile-git-0.0-2.06f9fc3.drv' failed
because the libgit2-0.25.1 content hash does not check out.
I verified this on version-0.13. The same goes for 0.26.0 on master
$ guix build -S libgit2 --no-substitutes
The following derivations will be built:
/gnu/store/5szrmzmfgxk6pylk5fh9bk8apj4x8axf-libgit2-0.26.0.tar.xz.drv
/gnu/store/mgh4yjxkxfyqmc7c61vwq4vs8v837602-libgit2-0.26.0.tar.gz.drv
@ build-started
/gnu/store/mgh4yjxkxfyqmc7c61vwq4vs8v837602-libgit2-0.26.0.tar.gz.drv -
x86_64-linux
/var/log/guix/drvs/mg//h4yjxkxfyqmc7c61vwq4vs8v837602-libgit2-0.26.0.tar.gz.drv.bz2
Starting download of
/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz
From https://github.com/libgit2/libgit2/archive/v0.26.0.tar.gz...
following redirection to
`https://codeload.github.com/libgit2/libgit2/tar.gz/v0.26.0'...
v0.26.0 4.5MiB3.1MiB/s 00:01 []
100.0%
sha256 hash mismatch for output path
`/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz'
expected: 1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa
actual: 1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka
@ build-failed
/gnu/store/mgh4yjxkxfyqmc7c61vwq4vs8v837602-libgit2-0.26.0.tar.gz.drv - 1
sha256 hash mismatch for output path
`/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz'
expected: 1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa
actual: 1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka
cannot build derivation
`/gnu/store/5szrmzmfgxk6pylk5fh9bk8apj4x8axf-libgit2-0.26.0.tar.xz.drv': 1
dependencies couldn't be built
guix build: error: build failed: build of
`/gnu/store/5szrmzmfgxk6pylk5fh9bk8apj4x8axf-libgit2-0.26.0.tar.xz.drv' failed
I found no apparent difference in the content
-r--r--r-- 1 janneke janneke 4252130 Oct 1 09:08
c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz
-rw-r--r-- 1 janneke janneke 4252139 Oct 1 09:09
NEW-c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz
-rw-r--r-- 1 janneke janneke 16363520 Oct 1 09:14
c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar
-rw-r--r-- 1 janneke janneke 16363520 Oct 1 09:14
NEW-c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar
but there's this difference between the tar balls...
12:13:57 janneke@dundal:~/src/guix-0.13
$ cmp -l c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar
NEW-c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar
13122049 0 157
13122050 0 162
13122051 0 151
13122052 0 147
13122053 0 151
13122054 0 156
13122055 0 57
13122490 57 0
13122491 157 0
13122492 162 0
13122493 151 0
13122494 147 0
13122495 151 0
13122496 156 0
13270529 0 157
13270530 0 162
13270531 0 151
13270532 0 147
13270533 0 151
13270534 0 156
13270535 0 57
13270972 57 0
13270973 157 0
13270974 162 0
13270975 151 0
13270976 147 0
13270977 151 0
13270978 156 0
13294081 0 157
13294082 0 162
13294083 0 151
13294084 0 147
13294085 0 151
13294086 0 156
13294087 0 57
13294519 57 0
13294520 157 0
13294521 162 0
13294522 151 0
13294523 147 0
13294524 151 0
13294525 156 0
janneke
[0] https://gnunet.org/bot/log/guix/2017-10-01#T1517584
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Jan Nieuwenhuizen writes: The changing of the libgit-0.26.0 checksum was already reported about 3 weeks ago (github seems to only show relative dates) https://github.com/libgit2/libgit2/issues/4343 and the bug is still open. It seems to be a github thing. As I understand it, currently our options are to update the hash and pray it won't happen again or host libgit2 tarballs ourselves. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Ludovic Courtès writes: > What’s sad here is that we do have the right tarball at: > > > https://mirror.hydra.gnu.org/file/libgit2-0.25.1.tar.gz/sha256/1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s Sad indeed! > The problem is that the hash check is performed by guix-daemon itself, > not by “guix perform-download”. So when guix-daemon diagnoses a hash > mismatch, it’s too late and we cannot try again and use the > content-addressed mirror. Why don't we try our content-addressed mirror first? > A crude but helpful fix would be to have perform-download compute the > hash by itself and act accordingly. It’s crude because that means that > we’d be computing the hash twice: once in ‘guix perform-download’ and a > second time in guix-daemon. For archives below ~20 MiB it’s probably OK > though. > > Thoughts? We may want more guix hackers' viewpoints here, I don't feel very qualified...As this would be a temporary workaround only until we have > In the future, with the daemon written in Guile, it’s one area where we > could achieve better integration and coordination among the various > pieces. ...it might be fine? Do we want/need to bring out a new release for this, e.g. 0.13.1, or even 0.14? I'm not sure how bad it is that --no-substitutes does not work. I think working on guix pull to not compile everything locally may have priority? janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Ludovic Courtès writes: > Right. Jan suggested checking the content-addressed mirrors *before* > the real upstream address. That would address the problem of upstream > sources modified in-place, but at the cost of privacy/self-sufficiency > as you note. (Though it’s not really making “privacy” any worse in this > case: it’s gnu.org vs. github.com.) Yes, that may not preferrable in general without override. > Perhaps we should make content-addressed mirrors configurable in a way > that’s orthogonal to derivations, something similar in spirit to > --substitute-urls? The difficulty is that content-addressed mirrors are > not just URLs; see (guix download). Hmm. I'm not sure what problem we are solving. Should we only do this for github(-like) tarballs? Do we see this problem with other sources, should we prevent it? Possibly github will never do something like this again. Or we could banish github/gitlab(?) auto-generated tarballs and go for git checkouts+commits? janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Maxim Cournoyer writes: > If we can trust the Homebrew list to be extensive, it seems we got > lucky; there's only one affected package that we share which is > yaml-cpp. Here's how it fails on our side: I needed to also use (ice-9 regex) and then I found these to fail antlr3 csound erlang font-google-material-design-icons fritzing libgit2 lxqt-common ogre plexus-interpolation red-eclipse yaml-cpp out of 646 packages it's not many but it includes our core dependency libgit2 which breaks guix pull --no-substitutes; that's hardly being lucky? janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28731: guix weather backtrace on https://mirror.guixsd.org
Running guix weather on latest master* gives me
computing 6,224 package derivations for x86_64-linux...
looking for 6,486 store items on https://mirror.hydra.gnu.org...
updating list of substitutes from 'https://mirror.hydra.gnu.org'...
0.0%Backtrace:
10 (primitive-load "/home/janneke/bin/guix")
In guix/ui.scm:
1375:12 9 (run-guix-command _ . _)
In ice-9/boot-9.scm:
837:9 8 (catch _ _ #
_)
837:9 7 (catch _ _ # …)
In srfi/srfi-1.scm:
640:9 6 (for-each # ("https://mirror.hyd…";))
In guix/scripts/weather.scm:
99:17 5 (call-with-time _ #)
In unknown file:
4 (_ #
# #)
In guix/scripts/substitute.scm:
711:23 3 (lookup-narinfos _ _)
664:23 2 (fetch-narinfos _ _)
567:8 1 (http-multiple-get #< scheme: https userinfo: #f host:
"mirror.hydra.gnu.org" port: #f path…> …)
In unknown file:
0 (put-bytevector # #vu8(71 69 84 32
47 57 48 100 104 50 114 54 107 …) …)
ERROR: In procedure put-bytevector:
ERROR: Throw to key `gnutls-error' with args `(# write_to_session_record_port)'.
My daemon uses substitute-urls "https://mirror.guixsd.org https://hydra.gnu.org
http://guix.oban.verum.com:8181 http://guix2.oban.verum.com:8181
http://janneke.lilypond.org:8080";
*) 3ae76f7f5 gnu: vsearch: Update to 2.5.0.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)
ng0 writes: > ng0 transcribed 2.1K bytes: > … >> Since some of our own dependencies are on github (at the very least >> guile-git), we need to come up with a solution. > … > > Correction: libgit2 is on github, a dependency of guile-git (which is on > gitlab). Sure, see bug#28659 ...possbily this needs to be merged that bug. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28284: GCC 4.7.4 fails to build since April 2017
Mark H Weaver writes: > GCC 4.7.4 fails to build since April 2017: > > https://hydra.gnu.org/job/gnu/master/gcc-4.7.4.x86_64-linux > https://hydra.gnu.org/job/gnu/master/gcc-4.7.4.i686-linux The attached patch should fix this. I tested it on an inherited package like this below, while attempting to create diverse double compilation (define-public repro-gcc-4.7 (package (inherit gcc-4.7-$ORIGIN) (source (origin (inherit (package-source gcc-4.7-$ORIGIN)) (patches (append ((compose origin-patches package-source) gcc-4.7) (search-patches "gcc-5-reproducibility-drop-profile.patch" "gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch" "gcc-4-build-path-prefix-map.patch") (name "repro-gcc") (version "4.7.4") (arguments (substitute-keyword-arguments (package-arguments gcc-4.7-$ORIGIN) ((#:phases original-phases) `(modify-phases ,original-phases (add-before 'configure 'build-prefix-path (lambda* (#:key inputs #:allow-other-keys) (setenv "BUILD_PATH_PREFIX_MAP" (string-append "gcc" "-" ,version "=" (getcwd))) (format (current-error-port) "BUILD_PATH_PREFIX_MAP=~s\n" (getenv "BUILD_PATH_PREFIX_MAP")) Greetings, janneke >From b2fb0adc3e0de7194493a0c5f1f9bbdbcd0a4087 Mon Sep 17 00:00:00 2001 From: Jan Nieuwenhuizen Date: Mon, 6 Nov 2017 22:50:05 +0100 Subject: [PATCH] gnu: gcc-4.7: Resurrect building with gcc-5.4.0. * gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/gcc.scm (gcc-4.7): Use it. --- gnu/local.mk | 1 + gnu/packages/gcc.scm | 3 + ...fns-fix-mismatch-in-gnu_inline-attributes.patch | 65 ++ 3 files changed, 69 insertions(+) create mode 100644 gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch diff --git a/gnu/local.mk b/gnu/local.mk index 5dfcf497b..76aef903a 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -637,6 +637,7 @@ dist_patch_DATA = \ %D%/packages/patches/gcc-cross-environment-variables.patch \ %D%/packages/patches/gcc-libvtv-runpath.patch \ %D%/packages/patches/gcc-strmov-store-file-names.patch \ + %D%/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch \ %D%/packages/patches/gcc-4.6-gnu-inline.patch \ %D%/packages/patches/gcc-4.9.3-mingw-gthr-default.patch \ %D%/packages/patches/gcc-5.0-libvtv-runpath.patch \ diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm index 7870d4513..2991cbd0b 100644 --- a/gnu/packages/gcc.scm +++ b/gnu/packages/gcc.scm @@ -136,6 +136,9 @@ where the OS part is overloaded to denote a specific ABI---into GCC (method url-fetch) (uri (string-append "mirror://gnu/gcc/gcc-" version "/gcc-" version ".tar.bz2")) + (patches +(search-patches + "gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch")) (sha256 (base32 "10k2k71kxgay283ylbbhhs51cl55zn2q38vj5pk4k950qdnirrlj" diff --git a/gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch b/gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch new file mode 100644 index 0..861cd4857 --- /dev/null +++ b/gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch @@ -0,0 +1,65 @@ +Taken from https://gcc.gnu.org/cgi-bin/get-raw-msg?listname=gcc-patches&date=2016-01&msgid=1451802493-17406-1-git-send-email-vapier%40gentoo.org + +Since the 3.0.3 release of gperf (made in May 2007), the generated func +has had the gnu_inline attribute applied to it. The gcc source however +has not been updated to include that which has lead to a mismatch. + +In practice, this hasn't been an issue for two reasons: +(1) Before gcc-5, the default standard was (gnu) C89, and gcc does not +warn or throw an error in this mode. +(2) Starting with gcc-4.8, the compiler driver used to build gcc was +changed to C++, and g++ does not warn or throw an error in this mode. + +This error does show up though when using gcc-5 to build gcc-4.7 or +older as then the default is (gnu) C11 and the C compiler driver is +used. That failure looks like: +In file included from .../gcc-4.7.4/gcc/cp/except.c:990:0: +cfns.gperf: At top level: +cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p' +cfns.gperf:26:14: error: but not here + +Whe
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
guix build guile-emacs fails with checking jerror.h usability... yes checking jerror.h presence... yes checking for jerror.h... yes checking for jpeg_destroy_compress in -ljpeg... yes configure: WARNING: libjpeg found, but not version 6b or later checking for library containing inflateEnd... -lz checking for png... yes checking whether png_longjmp is declared... yes checking tiffio.h usability... yes checking tiffio.h presence... yes checking for tiffio.h... yes checking for TIFFGetVersion in -ltiff... yes checking gif_lib.h usability... yes checking gif_lib.h presence... yes checking for gif_lib.h... yes checking for GifMakeMapObject in -lgif... yes configure: error: The following required libraries were not found: libjpeg Maybe some development libraries/packages are missing? If you don't want to link with them give --with-jpeg=no as options to configure phase `configure' failed after 10.5 seconds Obviously that's fu, because libjpeg-8 is available. I tried several things, previous versions of libjpeg; not sure what's going on here. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
Mark H Weaver writes:
> Can you try building it with --keep-failed, and then look at the
> config.log file in the failed build directory? It should show details
> of what went wrong. Typically these tests try compiling small test
> programs, and likely there was some other error that lead it to the
> erroneous conclusion. config.log will contain the test program and
> error messages.
Thanks for the heads up!
Attached is a patch that fixes this configure problem. However, now the
build fails with a segfault:
EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l
autoload \
--eval "(setq generate-autoload-cookie \"###cal-autoload\")" \
--eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name
\"../../git-checkout/lisp/calendar/cal-loaddefs.el\")))" \
-f batch-update-autoloads ../../git-checkout/lisp/calendar
make[2]: *** [Makefile:466: ../../git-checkout/lisp/calendar/cal-loaddefs.el]
Segmentation fault
Greetings,
janneke
>From c0cecb3e3f39de01c674dadf8949186e94d5fb9b Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Tue, 7 Nov 2017 08:08:21 +0100
Subject: [PATCH] gnu: guile-emacs: Resurrect, fixes #29186.
* gnu/packages/patches/emacs-fix-configure-jpeg.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/emacs.scm (guile-emacs): Use it. Fixes #29186.
---
gnu/local.mk | 2 +
gnu/packages/emacs.scm | 1 +
.../patches/emacs-fix-configure-jpeg.patch | 99 ++
3 files changed, 102 insertions(+)
create mode 100644 gnu/packages/patches/emacs-fix-configure-jpeg.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 90dc7aec1..25082b9ad 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -11,6 +11,7 @@
# Copyright © 2016 Ben Woodcroft
# Copyright © 2016, 2017 Alex Vong
# Copyright © 2016, 2017 Efraim Flashner
+# Copyright © 2016, 2017 Jan Nieuwenhuizen
# Copyright © 2017 Tobias Geerinckx-Rice
# Copyright © 2017 Clément Lassieur
# Copyright © 2017 Mathieu Othacehe
@@ -598,6 +599,7 @@ dist_patch_DATA = \
%D%/packages/patches/elixir-disable-failing-tests.patch \
%D%/packages/patches/einstein-build.patch \
%D%/packages/patches/emacs-exec-path.patch \
+ %D%/packages/patches/emacs-fix-configure-jpeg.patch \
%D%/packages/patches/emacs-fix-scheme-indent-function.patch \
%D%/packages/patches/emacs-scheme-complete-scheme-r5rs-info.patch \
%D%/packages/patches/emacs-source-date-epoch.patch \
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 026b27bf8..e5329b4c5 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -276,6 +276,7 @@ editor (without an X toolkit)" )
(uri (git-reference
(url "git://git.hcoop.net/git/bpt/emacs.git")
(commit "41120e0f595b16387eebfbf731fff70481de1b4b")))
+ (patches (search-patches "emacs-fix-configure-jpeg.patch"))
(sha256
(base32
"0lvcvsz0f4mawj04db35p1dvkffdqkz8pkhc0jzh9j9x2i63kcz6"
diff --git a/gnu/packages/patches/emacs-fix-configure-jpeg.patch b/gnu/packages/patches/emacs-fix-configure-jpeg.patch
new file mode 100644
index 0..5205877af
--- /dev/null
+++ b/gnu/packages/patches/emacs-fix-configure-jpeg.patch
@@ -0,0 +1,99 @@
+Backported from
+
+From fdf532b9c915ad9ba72155646d29d0f530fd72ec Mon Sep 17 00:00:00 2001
+From: Paul Eggert
+Date: Wed, 15 Apr 2015 18:30:01 -0700
+Subject: [PATCH] Port jpeg configuration to Solaris 10 with Sun C
+
+* configure.ac: Check for jpeglib 6b by trying to link it, instead
+of relying on cpp magic that has problems in practice. Check for
+both jpeglib.h and jerror.h features. Remove special case for
+mingw32, which should no longer be needed (and if it were needed,
+should now be addressable by hotwiring emacs_cv_jpeglib).
+Fixes: bug#20332
+
+Fixes: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29186
+
+Upstream status: not yet presented upstream.
+
+--- a/configure.ac 2017-11-07 07:49:49.359550593 +0100
b/configure.ac 2017-11-07 07:50:50.864551155 +0100
+@@ -3014,44 +3014,40 @@ AC_SUBST(LIBXPM)
+ ### mingw32 doesn't use -ljpeg, since it loads the library dynamically.
+ HAVE_JPEG=no
+ LIBJPEG=
+-if test "${opsys}" = "mingw32"; then
+- if test "${with_jpeg}" != "no"; then
+-dnl Checking for jpeglib.h can lose because of a redefinition of
+-dnl HAVE_STDLIB_H.
+-AC_CHECK_HEADER(jerror.h, HAVE_JPEG=yes, HAVE_JPEG=no)
+- fi
+- AH_TEMPLATE(HAVE_JPEG, [Define to 1 if you have the jpeg library (-ljpeg).])dnl
+- if test "${HAVE_JPEG}" = "yes"; then
+-AC_DEFINE(HAVE_JPEG)
+-AC_EGREP_CPP([version= *(6[2-9]|[7-9][0-9])],
+-[#include
bug#28284: GCC 4.7.4 fails to build since April 2017
Ludovic Courtès writes: >> * >> gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch: >> New file. > > Could you use a shorter file name, so we don't hit tar’s limit on file > name length? I chose: gcc-4-compile-with-gcc-5.patch. New patch attached. >> * gnu/local.mk (dist_patch_DATA): Add it. >> * gnu/packages/gcc.scm (gcc-4.7): Use it. > > I think this can actually go to master, though please double-check that > the world isn’t getting rebuilt. :-) Here is what I did 18:25:50 janneke@dundal:~/src/guix-master [env] $ ./pre-inst-env guix refresh -l gcc@4.7.4 No dependents other than itself: gcc@4.7.4 18:25:55 janneke@dundal:~/src/guix-master [env] $ ./pre-inst-env guix build hello /gnu/store/lr8c1yswvrgckkaa6nzdi7q0d618bazs-hello-2.10 18:26:01 janneke@dundal:~/src/guix-master [env] so indeed, it looks fine; and it makes sense. I was working on the $ORIGIN stuff inside (a copy of) the gcc-4.7.4 builder -- that code is of course (re)used by all other gcc packages. Greetings, janneke >From 22d5353991784409e3a8e671611c5ccff3ff7b68 Mon Sep 17 00:00:00 2001 From: Jan Nieuwenhuizen Date: Mon, 6 Nov 2017 22:50:05 +0100 Subject: [PATCH] gnu: gcc-4.7: Resurrect building with gcc-5.4.0. * gnu/packages/patches/gcc-4-compile-with-gcc-5.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/gcc.scm (gcc-4.7): Use it. --- gnu/local.mk | 2 + gnu/packages/gcc.scm | 1 + .../patches/gcc-4-compile-with-gcc-5.patch | 65 ++ 3 files changed, 68 insertions(+) create mode 100644 gnu/packages/patches/gcc-4-compile-with-gcc-5.patch diff --git a/gnu/local.mk b/gnu/local.mk index 630d8187f..c77c4d8ed 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -11,6 +11,7 @@ # Copyright © 2016 Ben Woodcroft # Copyright © 2016, 2017 Alex Vong # Copyright © 2016, 2017 Efraim Flashner +# Copyright © 2016, 2017 Jan Nieuwenhuizen # Copyright © 2017 Tobias Geerinckx-Rice # Copyright © 2017 Clément Lassieur # Copyright © 2017 Mathieu Othacehe @@ -637,6 +638,7 @@ dist_patch_DATA = \ %D%/packages/patches/gcc-cross-environment-variables.patch \ %D%/packages/patches/gcc-libvtv-runpath.patch \ %D%/packages/patches/gcc-strmov-store-file-names.patch \ + %D%/packages/patches/gcc-4-compile-with-gcc-5.patch \ %D%/packages/patches/gcc-4.6-gnu-inline.patch \ %D%/packages/patches/gcc-4.9.3-mingw-gthr-default.patch \ %D%/packages/patches/gcc-5.0-libvtv-runpath.patch \ diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm index 7870d4513..79e159f1a 100644 --- a/gnu/packages/gcc.scm +++ b/gnu/packages/gcc.scm @@ -136,6 +136,7 @@ where the OS part is overloaded to denote a specific ABI---into GCC (method url-fetch) (uri (string-append "mirror://gnu/gcc/gcc-" version "/gcc-" version ".tar.bz2")) + (patches (search-patches "gcc-4-compile-with-gcc-5.patch")) (sha256 (base32 "10k2k71kxgay283ylbbhhs51cl55zn2q38vj5pk4k950qdnirrlj" diff --git a/gnu/packages/patches/gcc-4-compile-with-gcc-5.patch b/gnu/packages/patches/gcc-4-compile-with-gcc-5.patch new file mode 100644 index 0..861cd4857 --- /dev/null +++ b/gnu/packages/patches/gcc-4-compile-with-gcc-5.patch @@ -0,0 +1,65 @@ +Taken from https://gcc.gnu.org/cgi-bin/get-raw-msg?listname=gcc-patches&date=2016-01&msgid=1451802493-17406-1-git-send-email-vapier%40gentoo.org + +Since the 3.0.3 release of gperf (made in May 2007), the generated func +has had the gnu_inline attribute applied to it. The gcc source however +has not been updated to include that which has lead to a mismatch. + +In practice, this hasn't been an issue for two reasons: +(1) Before gcc-5, the default standard was (gnu) C89, and gcc does not +warn or throw an error in this mode. +(2) Starting with gcc-4.8, the compiler driver used to build gcc was +changed to C++, and g++ does not warn or throw an error in this mode. + +This error does show up though when using gcc-5 to build gcc-4.7 or +older as then the default is (gnu) C11 and the C compiler driver is +used. That failure looks like: +In file included from .../gcc-4.7.4/gcc/cp/except.c:990:0: +cfns.gperf: At top level: +cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p' +cfns.gperf:26:14: error: but not here + +Whether the compiler should always emit this error regardless of the +active standard or compiler driver is debatable (I think it should be +consistent -- either always do it or never do it). + +2015-08-06 Mike Frysinger + + * cfns.gperf [__GNUC__, __GNUC_STDC_INLINE__]: Apply the + __gnu_inline__ attribute. + * cfns.h: Regenerated. +--- + gcc/cp/cfns.gperf
bug#29196: upstreaming of reproducibility related patches
ng0 writes: > as I wrote in #29135, we should upstream the patches we > gather for reproducibility. Share with upstream what is > applicable to more software than just Guix included > definitions of the software etc. > We have no list for this so far > We need to share this, to avoid duplicate work elsewhere. What about the reproducible builds list? https://lists.reproducible-builds.org/listinfo/rb-general General discussions about reproducible builds At the reproducible-builds summit last week in Berlin some work has been done on the topic of upstreaming patches. I think some effort has gone (is going?) into a email template that starts by explaining what reproducible-builds is, why it is important and why upstream should consider taking the patch. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
Jan Nieuwenhuizen writes: > However, now the build fails with a segfault: > > EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp > -l autoload \ >--eval "(setq generate-autoload-cookie \"###cal-autoload\")" \ >--eval "(setq generated-autoload-file (expand-file-name > (unmsys--file-name > \"../../git-checkout/lisp/calendar/cal-loaddefs.el\")))" \ >-f batch-update-autoloads ../../git-checkout/lisp/calendar > make[2]: *** [Makefile:466: ../../git-checkout/lisp/calendar/cal-loaddefs.el] > Segmentation fault Attempting to debug this segfault, I configured using CFLAGS=-g ./configure however, now the segfault is gone. Additional patch attached. WDY(all)T? Greetings, janneke >From 2a369f5151e0c7565fc271fb52def543b447477d Mon Sep 17 00:00:00 2001 From: Jan Nieuwenhuizen Date: Tue, 7 Nov 2017 20:02:35 +0100 Subject: [PATCH] gnu: guile-emacs: compile with -g (rather than -O2?) --- gnu/packages/emacs.scm | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index c133c745c..5c33d0874 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -293,6 +293,9 @@ editor (without an X toolkit)" ) ,@(package-arguments emacs)) ((#:phases phases) `(modify-phases ,phases + (add-before 'configure 'setenv + (lambda _ + (setenv "CFLAGS" "-g"))) (add-after 'unpack 'autogen (lambda _ (zero? (system* "sh" "autogen.sh")) -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#28284: GCC 4.7.4 fails to build since April 2017
Ludovic Courtès writes: >> I was working on the $ORIGIN stuff inside (a copy of) the gcc-4.7.4 >> builder -- that code is of course (re)used by all other gcc packages. > > Though the $ORIGIN stuff is separate, right? Will be nice to have. Sure, i figure this will take some time to get in if at all. We'll have to see what the pros and cons are. Different story/thread. >> From 22d5353991784409e3a8e671611c5ccff3ff7b68 Mon Sep 17 00:00:00 2001 >> From: Jan Nieuwenhuizen >> Date: Mon, 6 Nov 2017 22:50:05 +0100 >> Subject: [PATCH] gnu: gcc-4.7: Resurrect building with gcc-5.4.0. >> >> * gnu/packages/patches/gcc-4-compile-with-gcc-5.patch: New file. >> * gnu/local.mk (dist_patch_DATA): Add it. >> * gnu/packages/gcc.scm (gcc-4.7): Use it. > > Go for it! Pushed to master as 625492ee1a5a8e515b97d4b76734584c1b420243 janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
Efraim Flashner writes: > Will it build with libjpeg-turbo or libjpeg-9? I'm not sure how feasable > it is, but I'd like to remove libjpeg-8 (and some other old libraries) > if its possible. As communicated over irc; yes, it build with libjpeg-9. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
Efraim Flashner writes: >> + (add-before 'configure 'setenv >> + (lambda _ >> + (setenv "CFLAGS" "-g"))) >> (add-after 'unpack 'autogen >>(lambda _ >> (zero? (system* "sh" "autogen.sh")) > > Couldn't this be a make-flag or a configure-flag? Yes, as a configure flags also works. However, I tracked down the segfault, backported a patch and and now it builds with -O2. New patch attached. >From f6633adf4c5ceee3a63da9a3909a94c22f55b68a Mon Sep 17 00:00:00 2001 From: Jan Nieuwenhuizen Date: Tue, 7 Nov 2017 08:08:21 +0100 Subject: [PATCH] gnu: guile-emacs: Resurrect, fixes #29186. * gnu/packages/patches/guile-emacs-fix-configure.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/emacs.scm (guile-emacs): Use it. Add workaround for src/deps dir creation. Fixes #29186. --- gnu/local.mk | 1 + gnu/packages/emacs.scm | 7 +- .../patches/guile-emacs-fix-configure.patch| 208 + 3 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/guile-emacs-fix-configure.patch diff --git a/gnu/local.mk b/gnu/local.mk index ecee15b1d..71392d86c 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -712,6 +712,7 @@ dist_patch_DATA = \ %D%/packages/patches/guile-present-coding.patch \ %D%/packages/patches/guile-relocatable.patch \ %D%/packages/patches/guile-rsvg-pkgconfig.patch \ + %D%/packages/patches/guile-emacs-fix-configure.patch \ %D%/packages/patches/gtk2-respect-GUIX_GTK2_PATH.patch \ %D%/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch \ %D%/packages/patches/gtk2-theme-paths.patch \ diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index 45e0635de..502d83b5f 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -276,6 +276,7 @@ editor (without an X toolkit)" ) (uri (git-reference (url "git://git.hcoop.net/git/bpt/emacs.git") (commit "41120e0f595b16387eebfbf731fff70481de1b4b"))) + (patches (search-patches "guile-emacs-fix-configure.patch")) (sha256 (base32 "0lvcvsz0f4mawj04db35p1dvkffdqkz8pkhc0jzh9j9x2i63kcz6" @@ -294,7 +295,11 @@ editor (without an X toolkit)" ) `(modify-phases ,phases (add-after 'unpack 'autogen (lambda _ -(zero? (system* "sh" "autogen.sh")) +(zero? (system* "sh" "autogen.sh" + ;; Build sometimes fails: deps/dispnew.d: No such file or directory + (add-before 'build 'make-deps-dir + (lambda _ + (zero? (system* "mkdir" "-p" "src/deps")) ;;; diff --git a/gnu/packages/patches/guile-emacs-fix-configure.patch b/gnu/packages/patches/guile-emacs-fix-configure.patch new file mode 100644 index 0..374972359 --- /dev/null +++ b/gnu/packages/patches/guile-emacs-fix-configure.patch @@ -0,0 +1,208 @@ +Two patches here backporting fixes from emacs master. + +From dfcb3b6ff318e47b84a28cfc43f50bec42fa3570 Mon Sep 17 00:00:00 2001 +From: Jan Nieuwenhuizen +Date: Tue, 7 Nov 2017 18:48:03 +0100 +Subject: [PATCH 1/2] backport: Port jpeg configuration to Solaris 10 with Sun + C. + +* configure.ac: Check for jpeglib 6b by trying to link it, instead +of relying on cpp magic that has problems in practice. Check for +both jpeglib.h and jerror.h features. Remove special case for +mingw32, which should no longer be needed (and if it were needed, +should now be addressable by hotwiring emacs_cv_jpeglib). +Fixes: bug#20332 + +From fdf532b9c915ad9ba72155646d29d0f530fd72ec Mon Sep 17 00:00:00 2001 +From: Paul Eggert +Date: Wed, 15 Apr 2015 18:30:01 -0700 +Subject: [PATCH] Port jpeg configuration to Solaris 10 with Sun C. + +* configure.ac: Check for jpeglib 6b by trying to link it, instead +of relying on cpp magic that has problems in practice. Check for +both jpeglib.h and jerror.h features. Remove special case for +mingw32, which should no longer be needed (and if it were needed, +should now be addressable by hotwiring emacs_cv_jpeglib). +Fixes: bug#20332 +--- + configure.ac | 72 + 1 file changed, 34 insertions(+), 38 deletions(-) + +diff --git a/configure.ac b/configure.ac +index 2445db4886..36fa8eb390 100644 +--- a/configure.ac b/configure.ac +@@ -3014,44 +3014,40 @@ AC_SUBST(LIBXPM) + ### mingw32 doesn't use -ljpeg, since it loads the library dynamically. + HAVE
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
Ludovic Courtès writes: >> Subject: [PATCH] gnu: guile-emacs: Resurrect, fixes #29186. >> >> * gnu/packages/patches/guile-emacs-fix-configure.patch: New file. > I’m fine with this patch. I’m a bit concerned about the risk of > accumulating patches that should really be in guile-emacs proper, > though. IMO it would be better if this patch were pushed to > guile-emacs, or if an alternate guile-emacs repo were set up if the > current one is inactive. If that’s too cumbersome though, feel free to > push this patch! Meanwhile, I sent this patch 6 days ago to Robin Templeton . They were the most recent committer from where we're pulling. They haven't responded yet. Let me know if you know a better address/can we do better? I can wait a bit more and push if I don't hear anything the coming week. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#29186: building guile-emacs fails: required libaries not found: libjpeg
Ludovic Courtès writes: > I think you can now push the patch in Guix. Thanks, push to master as 68cb962a8d6d384a02e3e8eac23af2582d73c6e7 janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#30537: glibc 2.26 refuses to run on CentOS 6.8
Ricardo Wurmus writes: >> Here’s a patch to graft the glibc to apply the patch to allow the 2.6.32 >> kernel. I’m going to apply this at work now. > > That patch had a couple of problems. Here’s a new version. Sad to hear of your troubles, thanks a lot for posting this. We discovered at Verum that a guix pack would not run on CentOS and took another road in the end. Good to know there's still a way to work around this. Thanks, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#30922: LUKS-encrypted root fails using device numbering, needs luksUUID
Hi!
Following the example in 6.2.4 Mapped Devices
(mapped-device
(source "/dev/sda3")
(target "home")
(type luks-device-mapping))
I chose not to use the UUID alternative for encrypted root; I'm terrible
at memorizing and typing UUIDs. So I used this snippet (full
bare-luks.scm below)
(mapped-device
;; This does not work
(source "/dev/nvme0n1p1")
;; This works (output of cryptsetup luksUUID /dev/nvme0n1p1)
;; (source (uuid "50d96f54-1dbb-48f8-bca5-2f1feb5ff144"))
(target "guix")
(type luks-device-mapping))
For disk partitioning, I did
cryptsetup luksFormat /dev/nvme0n1p1
cryptsetup open --type=luks /dev/nvme0n1p1 guix
mkfs.ext4 -L guix /dev/mapper/guix
then install, something like
mount /dev/mapper/guix /mnt
herd start cow-store /mnt
guix system init /mnt/root/bare-luks.scm /mnt
After booting I get
Device /dev/nvme0n1p1 doesn't exist or access denied
Using the luksUUID, it works. Except for this hurdle a pleasant and
straighforward fresh install :-)
Greetings,
janneke
--8<---cut here---start->8---
;; lsblk.out
;; NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT
;; sda 8:01 14.5G 0 disk
;; ├─sda18:11 1.4G 0 part
;; └─sda28:21 40M 0 part
;; nvme0n1 259:00 477G 0 disk
;; └─nvme0n1p1 259:10 477G 0 part
;; └─guix253:00 477G 0 crypt /mnt
--8<---cut here---end--->8---
--8<---cut here---start->8---
;; bare-luks.scm
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen ssh)
(define %supplementary-groups '("wheel" "netdev" "audio" "video" "lp" "kvm"))
(operating-system
(host-name "dundal")
(timezone "Europe/Amsterdam")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/nvme0n1")))
(mapped-devices
(list (mapped-device
;; This does not work
(source "/dev/nvme0n1p1")
;; This works (output of cryptsetup luksUUID /dev/nvme0n1p1)
;; (source (uuid "50d96f54-1dbb-48f8-bca5-2f1feb5ff144"))
(target "guix")
(type luks-device-mapping
(file-systems
(cons* (file-system (title 'device)
(device "/dev/mapper/guix")
(mount-point "/")
(type "ext4")
(dependencies mapped-devices))
%base-file-systems))
(groups
(cons* (user-group (name "janneke"))
%base-groups))
(users
(cons* (user-account
(name "janneke")
(group "janneke")
(uid 1000)
(supplementary-groups %supplementary-groups)
(home-directory "/home/janneke"))
%base-user-accounts))
(packages (cons* screen openssh wpa-supplicant-minimal %base-packages))
(services (cons* (dhcp-client-service)
(console-keymap-service "dvorak" "ctrl")
(service openssh-service-type
(openssh-configuration
(port-number )
(permit-root-login #t)
(allow-empty-passwords? #f)
(password-authentication? #t)))
%base-services)))
--8<---cut here---end--->8---
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#31956: guix environment: add option to download and unpack source
Danny Milosavljevic writes: >> Not sure what to call it exactly, but something like: >> >> guix environment --with-source hello > > +1 > > Right now, my silly workaround is to add a phase which fails > > (add-after 'unpack 'fail > (lambda _ > (error "stop it"))) > > and then do > > guix build --keep-failed hello > > and then do > > guix environment --pure hello > cd /tmp/guix-build-hello* > > That's... very manual. A very nice recipe...interesting we had a discussion about this today on #guix. What I would really like, is for the --with-source directory be a git archive, so that edits can be made and tested until it works. Attempt a rebuild with new patches/new git commit and repeat. Making repeated patches until a build succeeds is something I find pretty cumbersome. It could be an ad-hoc, new git archive. It would also be nice if Guix could somehow record upstream sources as (shallow?, tarred?) git archives. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#26608: bug#22629: “Stable” branch
Ludovic Courtès writes: > I just had a bright idea (yes!): this can be addressed by writing > something like this in ~/.config/guix/channels.scm: > > (map latest-commit-with-substitutes-available >%default-channels) This is a nice idea and it makes me remember that it would be useful to provide a way to avoid installing something that is cricitally broken, like Debian's apt-listbugs package/facility (https://packages.debian.org/sid/apt-listbugs). janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#32749: package-with-explicit-inputs leaks-in additional inputs
Hi! Rewriting the bootstrap on the wip-bootstrap branch I found additional inputs in packages that use `package-with-explicit-inputs', such as diffutils-boot0. I would expect diffutils-boot0 to list just one extra input in addition to gnu-make-boot0; namely the package gnu-make-boot0; however it has many more. To reproduce this I created a test file with two simple packages gnu-make-explicit-inputs, gnu-make-no-implicit-inputs. Put the attached file in gnu/packages and producing a graph for both test packages --8<---cut here---start->8--- 11:56:03 janneke@dundal:~/src/guix-master $ ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (@@ (gnu packages pawei) gnu-make-no-implicit-inputs))' | wc -l 14 11:56:22 janneke@dundal:~/src/guix-master $ ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (@@ (gnu packages pawei) gnu-make-explicit-inputs))' | wc -l 79 --8<---cut here---end--->8--- Should `package-with-explicit-inputs' behave like I think it does, i.e., should both test packages list the same dependencies, or am I missing something? pawei.scm Description: Binary data make-no-implicit-inputs.dot Description: Binary data make-explicit-inputs.dot Description: Binary data
bug#32749: package-with-explicit-inputs leaks-in additional inputs
Jan Nieuwenhuizen writes:
> Should `package-with-explicit-inputs' behave like I think it does, i.e.,
> should both test packages list the same dependencies, or am I missing
> something?
Printing the packages in the Guix Repl gives this result
--8<---cut here---start->8---
(package-inputs gnu-make-no-implicit-inputs)
$12 = (("libc" #) ("gcc" #) ("binutils" #) ("coreutils&co" #) ("bash" #))
scheme@(gnu packages pawei)> (map car (package-inputs
gnu-make-no-implicit-inputs))
$13 = ("libc" "gcc" "binutils" "coreutils&co" "bash")
scheme@(gnu packages pawei)> (package-native-inputs gnu-make-no-implicit-inputs)
$14 = ()
scheme@(gnu packages pawei)> (package-propagated-inputs
gnu-make-no-implicit-inputs)
$15 = ()
scheme@(gnu packages pawei)> (package-inputs gnu-make-explicit-inputs)
$16 = (("libc" #) ("gcc" #) ("binutils" #) ("coreutils&co" #) ("bash" #) ("guile"
#))
scheme@(gnu packages pawei)>
$17 = (("pkg-config" #))
scheme@(gnu packages pawei)> (package-propagated-inputs
gnu-make-explicit-inputs)
$18 = ()
scheme@(gnu packages pawei)> (package-native-inputs gnu-make-explicit-inputs)
$19 = (("pkg-config" #))
--8<---cut here---end--->8---
which is exactly what I expect to see when I read the Guile code for the
package descriptions; but is still a bit surprising to me: where do all
the extra inputs come from in the graph?
janneke
bug#32749: package-with-explicit-inputs leaks-in additional inputs
Ludovic Courtès writes:
> The difference comes from the fact that ‘gnu-make-explicit-inputs’ has
> Guile in its ‘inputs’:
Ah, I missed that!
> scheme@(gnu packages pawei)> (package-direct-inputs gnu-make-explicit-inputs)
> $5 = (("libc" # 3d216c0>) ("gcc" # 3d21600>) ("binutils" # gnu/packages/bootstrap.scm:150 3d21540>) ("coreutils&co" # bootstrap-binaries@0 gnu/packages/bootstrap.scm:150 3d21480>) ("bash"
> #)
> ("guile" #))
>
> This comes from the fact that the ‘inputs’ field is not overridden,
> unlike in the case of ‘gnu-make-no-implicit-inputs’.
>
> To solve this, the solution is to add this one ‘inputs’ line:
>
> (define gnu-make-explicit-inputs
> (let ((p (package-with-explicit-inputs gnu-make
> (%bootstrap-inputs+toolchain)
> #:guile %bootstrap-guile)))
> (package-with-bootstrap-guile
> (package (inherit p)
> (name "make-explicit-inputs")
> (inputs '());<- HERE
> (arguments (package-arguments p))
>
> Perhaps you hit similar cases on ‘wip-bootstrap’? It’s easy to leave
> out too many inputs…
I tried this! The dependencies look OK, but the package won't build --
there's no tar, make etc.
That can be fixed by repeating the explicit inputs, like this:
--8<---cut here---start->8---
(define gnu-make-explicit-inputs
(let ((p (package-with-explicit-inputs gnu-make
(%bootstrap-inputs+toolchain)
#:guile %bootstrap-guile)))
(package-with-bootstrap-guile
(package (inherit p)
(name "make-explicit-inputs")
(inputs (%bootstrap-inputs+toolchain))
(native-inputs '())
(arguments (package-arguments p))
--8<---cut here---end--->8---
...but that looks a bit strange: if we have to mention the inputs a
second time the advantage over using the `gnu-make-no-implicit-inputs'
package description becomes real small?
I also tried
(inputs (package-inputs p))
but that pulls in gcc-bootstrap-0 again; which lead me to believe
`package-with-explicit-inputs' has no observable effect?
Still a bit puzzled whether to revert the rewrites that removed
`package-with-explicit-inputs' and replace them by this second input
repetition...
janneke
bug#32749: package-with-explicit-inputs leaks-in additional inputs
Ludovic Courtès writes: >> I tried this! The dependencies look OK, but the package won't build -- >> there's no tar, make etc. > > Ah, true! > >> ...but that looks a bit strange: if we have to mention the inputs a >> second time the advantage over using the `gnu-make-no-implicit-inputs' >> package description becomes real small? > > The key thing is that ‘package-with-explicit-inputs’ works recursively: > it adds (it does *not* replace) inputs to the whole package graph. Ah, cool! > Consider this: > > (define x > (let ((p (package-with-explicit-inputs gnu-make >(%bootstrap-inputs+toolchain) >…))) > …)) > > Here ‘%bootstrap-inputs+toolchain’ is called from the top level, when > ‘%current-system’ has its default value. So if you’re on x86_64, you > get the x86_64 inputs. Doh'! The let is at toplevel...yeah that makes sense. > So it’s not a bug per se, but it’s definitely an annoyance. I agree, indeed it's rather a problem of interaction between --system/(%current-system). > I just realized that there’s already a fix for this, which is to pass > ‘package-with-explicit-inputs’ a procedure rather than the input list, > like this: > > (package-with-explicit-inputs gnu-make > %bootstrap-inputs+toolchain > …) > > Does it work for you? Yes! I'm reverting my `...leak' commits and create thunks as input of package-with-explicit-inputs. Thanks! janneke
bug#33496: bug#33500: bug#33496: Guix pull failing to compute derivation
Ludovic Courtès writes: > My bad, I introduced the regression 16 hours ago. This is fixed in > commit 0a9d1c5ab713bf525972f651c3cb63570e8c083d, thanks! Ah, great...there were at least three reports about this. Reading the commit it looks to me that the message and the content do not match. The message says that install-nodist_pkglibexecSCRIPTS is removed, while the patch removes install-nodist_libexecSCRIPTS. Hoping the end result is okay! janneke * gnu/packages/package-management.scm (guix-daemon)[arguments]: In 'install' phase, remove use of "install-nodist_pkglibexecSCRIPTS" target. diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm index d277d81acb..141d0e52f7 100644 --- a/gnu/packages/package-management.scm +++ b/gnu/packages/package-management.scm @@ -345,8 +345,7 @@ the Nix package manager.") (replace 'install (lambda* (#:key outputs #:allow-other-keys) (invoke "make" "install-binPROGRAMS" - "install-nodist_pkglibexecSCRIPTS" - "install-nodist_libexecSCRIPTS") ;guix-authenticate + "install-nodist_pkglibexecSCRIPTS") ;; We need to tell 'guix-daemon' which 'guix' command to use. ;; Here we use a questionable hack where we hard-code root's -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43384: guix pull: backtrace "no route to host"
Hello, I tried running "guix pull" but it gave me a backtrace. guix substitute: error: connect: No route to host @ substituter-failed /gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57 256 fetching path `/gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57' failed with exit code 1 @ substituter-started /gnu/store/s6ha2sssblw06sjpw4zawzx98zwbj5m7-graphviz-2.42.3 substitute killing process 6694 Backtrace: 11 (primitive-load "/gnu/store/lardz9zqi5ypgrdrj6dyfgj9p3bca2ab-compute-guix-derivation") In ice-9/eval.scm: 155:9 10 (_ _) 159:9 9 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ./guix/store.scm: 2042:24 8 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) 1876:8 7 (_ _) In ./guix/gexp.scm: 244:18 6 (_ _) 1064:2 5 (_ _) 924:2 4 (_ _) 785:4 3 (_ _) In ./guix/store.scm: 1924:12 2 (_ #) 1357:5 1 (map/accumulate-builds # _ _) 1368:15 0 (_ # 7fe2f10265f0> _ _) ./guix/store.scm:1368:15: ERROR: 1. &store-protocol-error: message: "some substitutes for the outputs of derivation `/gnu/store/bxw2dzjmdrq7qmv0w1mpzqrkfqs9p7q2-po4a-0.57.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source " status: 1 guix pull: error: You found a bug: the program '/gnu/store/lardz9zqi5ypgrdrj6dyfgj9p3bca2ab-compute-guix-derivation' failed to compute the derivation for Guix (version: "71992a532dd0bb88b39dda285482b332a24dae66"; system: "x86_64-linux"; host version: "1192ae940434808560b3170107e4ce44855816c3"; pull-version: 1). Please report it by email to . Jan Wielkiewicz
bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
Ricardo Wurmus writes:
> The attached patch seems to fix the worst problems.
Ohh...thank you!!! This makes issues at least readable in EWW.
It's a bit annoying to change issues URLs into bugs.gnu.org urls and
this also made me reluctant to share issues URLs -- altough I greatly
appreciate all the work you have been doing here: in heavyweight modern
mouse-shoving-browsers --that I personally try to avoid-- it really
looks beautiful.
> What do you think?
It seems that EWW ignores ’monospace’...
-.message span.line {
+.message div.line {
white-space: pre-wrap;
font-family: monospace;
display: block;
}
... here, or otherwise "eats" spaces; so diffs/patches are still a bit
annoying to read. Ideas?
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43435: bootstrap (bash-mesboot0) and ’make release’ error
zimoun writes:
Hello zimoun!
> Reading the release document [1] and going step by step, so I start from
> a fresh worktree and branch and I tweak a bit (maybe I am doing wrong)
> otherwise it fails:
[..]
> guix-1.0.1.22205-a8360-dirty/gnu/packages/commencement.scm://
> /gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
> error: 'sigprocmask' defined twice
> error: store file names embedded in the distribution
> make[4]: *** [Makefile:6335: assert-no-store-file-names] Error 1
So, this ’assert-no-store-file-names’ check in Makefile.am greps for
-E "$(storedir)/[a-z0-9]{32}-" $(distdir) ;
which is really meant for source code; to catch the use of hardcoded
store file names. Unfortunately, however ...
[..]
> On IRC [2], it rings a bell. :-) The error should come from
> ’bash-mesboot0’ in (gnu packages commencement) at the ’modify-phases’
> [3]:
>
> (add-after 'configure 'configure-fixups
>(lambda _
> (substitute* "config.h"
>(("#define GETCWD_BROKEN 1") "#undef GETCWD_BROKEN"))
> (let ((config.h (open-file "config.h" "a")))
>(display (string-append "
> // tcc: error: undefined symbol 'enable_hostname_completion'
> #define enable_hostname_completion(on_or_off) 0
>
> //
> /gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
> error: 'sigprocmask' defined twice
a commented store file name was added inside a code snippet. Changing
this comment to something like
// /gnu/store/...-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a: error:
'sigprocmask' defined twice
would pass the check, but this triggers a rebuld world. So I am
proposing the attached patch that breaks the comment to pass the check,
and using unquoted string-append to avoid a world rebuild.
Greetings,
Janneke
>From 7256bae0eebbec22c42a482ccfdf12fd8b874188 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Wed, 16 Sep 2020 06:57:51 +0200
Subject: [PATCH] gnu: commencement: bash-mesboot0: Break store file-name in
comment.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
This fixes running ‘make release’.
* gnu/packages/commencement.scm (bash-mesboot0)[arguments]: Break store file
name in commend and add unquoted string-append to silence store file name
check. The store file name check is meant for code, this file name was
unfortunately used is a comment.
---
gnu/packages/commencement.scm | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 565799c611..8a0864f26a 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -788,14 +788,17 @@ $MES -e '(mescc)' module/mescc.scm -- \"$@\"
(substitute* "config.h"
(("#define GETCWD_BROKEN 1") "#undef GETCWD_BROKEN"))
(let ((config.h (open-file "config.h" "a")))
- (display (string-append "
+ (display (string-append
+ ;; XXX TODO: remove nested ,(string-append ...) and
+ ;; store file name on next rebuild cycle
+ ,(string-append "
// tcc: error: undefined symbol 'enable_hostname_completion'
#define enable_hostname_completion(on_or_off) 0
-// /gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a: error: 'sigprocmask' defined twice
+// /gnu/store/" "cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a: error: 'sigprocmask' defined twice
#define HAVE_POSIX_SIGNALS 1
#define endpwent(x) 0
-")
+"))
config.h)
(close config.h))
#t))
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43005: make dist fails: "store file names embedded in the distribution"
Ludovic Courtès writes: Hello, > Jan Nieuwenhuizen skribis: > >> Oops; your patch is fine (see nit-pick) for core-updates; but as you >> noticed, on master we need to add an indirection to avoid rebuilds. >> What about something like >> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm >> index aa30e3fa18..48f9a47c6b 100644 >> --- a/gnu/packages/commencement.scm >> +++ b/gnu/packages/commencement.scm [..] > Well done! Could you push to ‘master’ (with a “Fixes” line in the > commit log)? Pushed to master as b85863f7ce99d05205e57358b36ff50656cca08b. Meanwile we have a duplicate bug: <https://bugs.gnu.org/43435> (it finally rang a bell on IRC...). Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43005: make dist fails: "store file names embedded in the distribution"
Vagrant Cascadian writes: Hi! > On 2020-09-16, Ludovic Courtès wrote: >> Hello! >> >> Jan Nieuwenhuizen skribis: >>> This is the closing parenthesis of a string-append that has only this >>> one big string; what about removing that string-append altogether? >> >> Agreed. >> >> Vagrant, could you push it to core-updates with this change? > > Not in a good position to push anything for a few days; if someone else > could that would be great! Sure. Pushed with minor change (removing encompassing string-append) to core-updates as 7467f9857dc530861735ebffe2c9376c8dfb80b7 Thanks! Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43533: guix-daemon fails to start in Childhurd
Hi! On current master (6feb7a2107000f9ded547543dcda9d64402c6081), the shepherd in a Childhurd fails to start the guix-daemon. It does start when invoked manually, using the same arguments *) The culprit seems to be the usage of fork+exec-command/container: After applying this patch --8<---cut here---start->8--- diff --git a/gnu/services/base.scm b/gnu/services/base.scm index d560ad5a13..98a8d2abca 100644 --- a/gnu/services/base.scm +++ b/gnu/services/base.scm @@ -1570,7 +1570,7 @@ proxy of 'guix-daemon'...~%") ;; the 'set-http-proxy' action. (or (getenv "http_proxy") #$http-proxy)) - (fork+exec-command/container + (fork+exec-command (cons* #$(file-append guix "/bin/guix-daemon") "--build-users-group" #$build-group "--max-silent-time" --8<---cut here---end--->8--- a Hurd VM built with --8<---cut here---start->8--- ./pre-inst-env guix system disk-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl --8<---cut here---end--->8--- has the shepherd starting the guix-daemon fine. I found that the /container bit was added in 8ce6f4dc2879919c12bc76a2f4b01200af97e019 installer: Run the installation inside a container. ...but I don't find the commit message quite clear about its intention to *always* run guix-daemon in a container; it could be read as sugessting to do so only during installation? How to proceed reverting this container feature for the Hurd? Greetings, Janneke *) For the Hurd that currently is something like: GUIX_LOCPATH=/gnu/store/z7a6sbvqzb5zapwpznmjkq2rsxil6i67-glibc-utf8-locales-2.31/lib/locale\ LC_ALL=en_US.utf8\ guix-daemon --build-users-group guixbuild --max-silent-time 0 --timeout 0 --log-compression bzip2 --substitute-urls https://ci.guix.gnu.org --disable-chroot --disable-deduplication -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43533: guix-daemon fails to start in Childhurd
Mathieu Othacehe writes: Hello Mathieu, >> 8ce6f4dc2879919c12bc76a2f4b01200af97e019 >> installer: Run the installation inside a container. >> >> ...but I don't find the commit message quite clear about its intention >> to *always* run guix-daemon in a container; it could be read as >> sugessting to do so only during installation? > > Thanks for the detailed bug report. Yes it's not very clear, I'll try to > improve the comments. The idea is that when you run: > > herd start guix-daemon PID > > then, the guix-daemon joins the given PID namespaces, which is practical > to solve an installation issue. > > If guix-daemon is started normally, outside of the installation process, > then it joins the caller namespaces, which should be a no-op. Of course, > it breaks everything if the operating system does not support > namespaces. > > Fixed with 6453915cf7729203ef9552c13cb4528c6f4ed122. Yay, I can confirm that it works! > Sorry for the breakage, Thanks for the quick fix and explanation, I didn't catch that no-op trick! It's all about context/knowledge I guess; If you know how /ns/ works, I guess that the patch/explanation was clear. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux
Ludovic Courtès writes: Hi! > Ludovic Courtès skribis: > >> It’s no wonder that the GNU/Hurd executable fails to run on GNU/Linux. >> The reason the daemon tries to run it anyway is because of the hack >> introduced in 7bf2a70a4ffd976d50638d3b9f2ec409763157df, in support of >> transparent emulation via binfmt_misc. > > The thing is that x86 GNU/Hurd and GNU/Linux ELF binaries are > indistinguishable AFAICS since they both use ELFOSABI_NONE: > > scheme@(guile-user)> ,use(guix elf) > scheme@(guile-user)> ,use(rnrs io ports) > scheme@(guile-user)> (define e (parse-elf (call-with-input-file > "/gnu/store/vq7zyb4hmlrafflmrcjbqccxp4dsx0s3-bash" get-bytevector-all))) > scheme@(guile-user)> (elf-abi e) > $6 = 0 > scheme@(guile-user)> ELFOSABI_GNU > $7 = 3 > scheme@(guile-user)> (define e2 (parse-elf (call-with-input-file "/bin/sh" > get-bytevector-all))) > scheme@(guile-user)> (elf-abi e2) > $8 = 0 > > (The ‘file’ command does manage to recognize GNU/Hurd binaries, but I > don’t know how it does it.) Looking at the file sources, it uses do_os_note, look: --8<---cut here---start->8--- $ readelf -a $(guix build --target=i586-pc-gnu hello)bin/hello Displaying notes found in: .note.ABI-tag OwnerData sizeDescription GNU 0x0010 NT_GNU_ABI_TAG (ABI version tag) OS: Hurd, ABI: 0.0.0 --8<---cut here---end--->8--- > So I think we can’t count on an ‘execve’ error and thus have to treat > this case (same architecture but different OS kernel) specially, as > shown below. > > Thoughts? If that really doesn't work...then yeah (yuck ;-) Greetigs, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux
Ludovic Courtès writes: Hi! > Jan Nieuwenhuizen skribis: > >>> Ludovic Courtès skribis: >>> >> Displaying notes found in: .note.ABI-tag >> OwnerData size Description >> GNU 0x0010NT_GNU_ABI_TAG (ABI version tag) >> OS: Hurd, ABI: 0.0.0 > > Oh, well done, I browsed ‘file’ but didn’t find it. :-) >>> So I think we can’t count on an ‘execve’ error and thus have to treat >>> this case (same architecture but different OS kernel) specially, as >>> shown below. >>> >>> Thoughts? >> >> If that really doesn't work...then yeah (yuck ;-) > > Yeah, I think we’ll have to do this hack (we’re not going to parse ELF > files and all to determine whether to call ‘execve’.) Ah, we're C++; I was thinking Guile and "we surely have" an ELF library. That's allright then. Let's have this workaround. > (Besides, it would be interesting to understand how the libc/Hurd > startup code ends up segfaulting on GNU/Linux.) Hmm...are you saying something like "it could run until it wants to RCP Mach or Hurd?" Might it "just load" shared libraries... Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#39819: Declarative /etc/guix/acl?
Ludovic Courtès writes: Hello! > For some reason, /etc/guix/acl is not declarative on Guix System: we let > users modify it and assume it’s stateful, which can surprise users as in > <https://issues.guix.gnu.org/39819>. > > Should we make it declarative, just like most of /etc? I think so. Yes, I think so too. However, if you have your own substitute server, you now can run guix archive --authorize < ..., e.g. at bootstrap/install time. For such cases, IWBN to have a --authorized-key argument to guix build / guix system. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#39819: Declarative /etc/guix/acl?
Ludovic Courtès writes: Hello, > Jan Nieuwenhuizen skribis: > >> Ludovic Courtès writes: > >> However, if you have your own substitute server, you now can run guix >> archive --authorize < ..., e.g. at bootstrap/install time. For such >> cases, IWBN to have a --authorized-key argument to guix build / guix >> system. > > There’s already an ‘authorized-keys’ field in ‘guix-configuration’: > > > https://guix.gnu.org/manual/devel/en/html_node/Base-Services.html#index-guix_002dconfiguration > > So you would just list keys there. Is that what you have in mind? > > The option is already there, it’s just non-authoritative. I was thinking about the initial installer scenario; when guix-daemon is already running and you didn't build the guix system yourself. But yeah, I guess this is an exceptional or corner case and you can always build your own installer and add the key there. Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong
Ludovic Courtès writes: Hi, > Ludovic Courtès skribis: > >> The problem is that the ‘cond-expand’ used to define ‘arch32bit?’ is a >> expansion-time thing when (cross-)building Bytestructures itself, so >> it’s incorrect from cross-building from 64-bit to 32-bit. >> >> I believe that changing it to: >> >> (define arch32bit? (memq data-model '(ilp32 lp32))) >> >> would fix it because then the test would happen at run time. > > I confirm that the attached patch for Bytestructures solves the problem > (running ‘guix pull’ in my childhurd :-)). Wow, beautiful! > Let’s see whether it needs to be adapted for inclusion upstream. Yes, sure. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#39819: [PATCH 1/2] services: guix: Make /etc/guix/acl really declarative by default.
Ludovic Courtès writes: Hello, > I went ahead and pushed this as c6ef627c97e5e6a94688baf20892ae3429f86897 > with the changes below, accounting for Vagrant’s comment and for the > fact that childhurds rely on the non-declarative behavior (which hadn’t > occurred to me before), as well as fixing other typos. > > > + ;; By default, the secret service introduces a pre-initialized > + ;; /etc/guix/acl file in the childhurd. Thus, clear > + ;; 'authorize-key?' so that it's not overridden at activation > + ;; time. > + (modify-services %base-services/hurd > + (guix-service-type config => > +(guix-configuration > + (inherit config) > + (authorize-key? #f Ah, good catch! Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#44261: running a daemon with userns in relocateble pack breaks
Hi! As mentioned on IRC, running a daemon from a guix relocatable pack on a foreign distro using the user namespace feature is troublesome: it looks as if the daemon "loses" (its view of) the file-system once the parent process that creates the daemon exits. I'm attatching a package description for a test package "vork". It builds a program "test" that forks the program "daemon". The daemon program reads a character from /dev/urandom, prints it, and sleeps for a second; 10 times. The "test" parent program exits after 5 seconds. When the parent program exits, the daemon crashes. To reproduce, put "vork.scm" in a fresh directory and do something like: --8<---cut here---start->8--- fakeroot tar xf $(GUIX_PACKAGE_PATH=. guix pack --relocatable\ --symlink=/gnu/bin=bin guile shepherd vork --no-offload) guix gc -D $(guix build -f vork.scm) touch /tmp/daemon.log tail -f /tmp/daemon.log & GUILE_LOAD_COMPILED_PATH=$PWD/$(ls -1d gnu/store/*profile)/lib/guile/3.0/ccache\ :$PWD/$(ls -1d gnu/store/*profile)/lib/guile/3.0/site-ccache gnu/bin/test --8<---cut here---end--->8--- this gives something like --8<---cut here---start->8--- .daemon-start daemon: 10 ? .daemon: 9 ? .daemon: 8 T .daemon: 7 ^O .daemon: 6 O exit 20:42:38 janneke@dundal:~/src/guix/master/vork [env] $ 20:42:38 janneke@dundal:~/src/guix/master/vork [env] $ Backtrace: Exception thrown while printing backtrace: In procedure public-lookup: Module named (system repl debug) does not exist --8<---cut here-------end--->8--- Greetings, Janneke vork.scm Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#44261: running a daemon with userns in relocateble pack breaks
Jan Nieuwenhuizen writes: Hi! I tried the hint from Ludovic to use MS_PRIVATE in the attached patch and that works for me; not sure if we want a test and even less sure how to write that... Janneke >From fd3104608c3fa6a2375b6c7df0862e5479976b39 Mon Sep 17 00:00:00 2001 From: "Jan (janneke) Nieuwenhuizen" Date: Tue, 27 Oct 2020 20:55:11 +0100 Subject: [PATCH] pack: Support running of daemons in user namespace-based relocation. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Add relocation via ld.so and fakechroot. Fixes <https://bugs.gnu.org/44261>. * gnu/packages/aux-files/run-in-namespace.c (bind_mount): Add 'MS_PRIVATE' to avoid unmounting the bind mount when parent process exits. Co-authored-by: Ludovic Courtès --- gnu/packages/aux-files/run-in-namespace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gnu/packages/aux-files/run-in-namespace.c b/gnu/packages/aux-files/run-in-namespace.c index 52a16a5362..67cea4fcd5 100644 --- a/gnu/packages/aux-files/run-in-namespace.c +++ b/gnu/packages/aux-files/run-in-namespace.c @@ -1,5 +1,6 @@ /* GNU Guix --- Functional package management for GNU Copyright (C) 2018, 2019, 2020 Ludovic Courtès + Copyright (C) 2020 Jan (janneke) Nieuwenhuizen This file is part of GNU Guix. @@ -138,7 +139,7 @@ bind_mount (const char *source, const struct dirent *entry, close (open (target, O_WRONLY | O_CREAT)); return mount (source, target, "none", - MS_BIND | MS_REC | MS_RDONLY, NULL); + MS_BIND | MS_PRIVATE | MS_REC | MS_RDONLY, NULL); } #if HAVE_EXEC_WITH_LOADER -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#25782: guile: one test fails on Debian/HURD
zimoun writes: Hello zimoun, > On Sat, 18 Feb 2017 at 07:24, Jan Nieuwenhuizen wrote: >> Running >> >> ./pre-inst-env guix package -i hello >> >> on Debian/HURD one test fails when building Guile >> >> Running 00-repl-server.test >> FAIL: 00-repl-server.test: repl-server: simple expression - arguments: [..] > What is the status of this bug [1]? It is done now, right? Yes, I would say so. In the guile package we currently have: ;; Hangs at: "Running 00-repl-server.test" (rename-file "test-suite/tests/00-repl-server.test" "00-repl-server.test") So the guile package build now succeeds, but the "real work" that this patch hints at still needs to be done some time. Anyway, closing; thanks! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#44261: running a daemon with userns in relocateble pack breaks
Ludovic Courtès writes: Hi! > As discussed on IRC, my initial advice about MS_PRIVATE was misguided. > The real issue is the “rm_rf (new_root);” call, which removes the root > directory and thus leaves child processes (the daemon) with nothing. Yes, I'm not entirely sure what I thought to see yesterday; anyway the rm_rf (new_root) is indeed the thing that makes the daemon crash. > The attached patch adds a test loosely based on yours and a fix for > that. The fix (for the “userns” engine) is to make NEW_ROOT a tmpfs, > such that upon completion, all we need to do is to unmount it and remove > it; it lives on as the root file system of child processes. > > In the “fakechroot” case, we have to leave NEW_ROOT behind, which is not > great but acceptable (it’s user-owned, #o700, and it’s under /tmp). The > test only checks the “userns” engine. Yes, I think this is acceptable. > If you confirm that it works for you and looks reasonable, we can apply > it. Yes, this works. The test and also my reproducer now work fine. Thanks a lot! Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#44261: running a daemon with userns in relocateble pack breaks
Ludovic Courtès writes: Hello, > Jan Nieuwenhuizen skribis: > >> Ludovic Courtès writes: > > [...] > >>> If you confirm that it works for you and looks reasonable, we can apply >>> it. >> >> Yes, this works. The test and also my reproducer now work fine. > > Thanks for checking, I pushed the fix as > bfe82fe2f6e9f34c0774fe2114cdc7e937ba8bd2. \o/ Thank you Janneke. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Carl Dong writes: Hello! > Some more information from my debugging: > > 1. This error is reproducible even when I specify --cores=1, which is very > strange > 2. I have attached the full log to this email Diffing this with the build log from --8<---cut here---start->8--- guix build -e '(@@ (gnu packages commencement) binutils-mesboot0)' --log-file wget https://ci.guix.gnu.org/log/jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14 -O jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14.gz gunzip jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14.gz diff -u jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14 2020-10-10-binutils-mesboot0.log [..] @@ -5538,16 +5537,16 @@ checking for i386-unknown-linux-windres... no checking for windres... windres checking whether to enable maintainer-specific portions of Makefiles... no -updating cache ./config.cache +not updating unwritable cache ./config.cache creating ./config.status creating Makefile [..] @@ -5558,7 +5557,7 @@ checking whether the C compiler (tcc -D __GLIBC_MINOR__=6 -g ) works... yes checking whether the C compiler (tcc -D __GLIBC_MINOR__=6 -g ) is a cross-compiler... no checking whether we are using GNU C... no -checking for ranlib... (cached) true +checking for ranlib... true checking for POSIXized ISC... no checking for ANSI C header files... yes checking for working const... yes --8<---cut here---end--->8--- config values do not get cached (why is config.cache unwritable?)...which seems to lead to a misdectected presence of lex: --8<---cut here---start->8--- -@ build-succeeded /gnu/store/bz6xjpzlwf57m4bg3w5ihlq638sscx54-binutils-mesboot0-2.14.drv - -checking for flex... (cached) /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/missing flex -checking for flex... (cached) /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/missing flex -checking for yywrap in -ll... (cached) no -checking lex output file root... (cached) lex.yy [..] +checking for flex... no +checking for lex... no +./configure: line 4417: flex: command not found +checking for flex... lex +checking for yywrap in -ll... no +checking lex output file root... ./configure: line 4505: lex: command not found +configure: error: cannot find output from lex; giving up +make: *** [configure-ld] Error 1 --8<---cut here---end--->8--- What is your build environment/version of guix you're using? It looks like some unreproducible bit is leaking in somewhere?? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45618: development childhurd fails to build: glib@2.62.6: build system `meson'
Hi, We have been using the attached devel-hurd.tmpl (see attched) to add a childhurd service that has a development environment. On current master 395489cdc959c3f3c026bf545c3ed95efc9919f0 gnu: spice-vdagent: Update to 0.20.0. building ./pre-inst-env guix system disk-image --target=i586-pc-gnu gnu/system/examples/devel-hurd.tmpl fail with --8<---cut here---start->8--- guix system: error: gnu/packages/glib.scm:181:2: glib@2.62.6: build system `meson' does not support cross builds --8<---cut here---end--->8--- I guess we are missing a (some?) tests for the Hurd. Anyway, I started a bisecting round last night and it found --8<---cut here---start->8--- 1b0cda6b44 gnu: qemu: Extend I/O test time-outs. --8<---cut here---end--->8--- which was an honest debugging leftover, fixed promptly in --8<---cut here---start->8--- b070e3f810 gnu: qemu: Remove left-over debugging statement. --8<---cut here---end--->8--- Luckily, this fixed commit also builds the childhurd again...so I'm starting a new bisect. This is not funny; it means I either cannot reconfigure, or I'm losing my childhurd...grmbl. Sorry for not noticing this earlier! Greetings, Janneke devel-hurd.tmpl Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45867: hurd-vm: custom disk-size ignored
On current master, setting a bigger disk-size for a childhurd --8<---cut here---start->8--- (service hurd-vm-service-type (hurd-vm-configuration (disk-size (* 12 (expt 2 30))) ;12GiB --8<---cut here---end--->8--- is being ignored. I am suspecting > commit 859b362f81598830d7ff276b96a8724aee3c4db7 > Author: Ludovic Courtès > AuthorDate: Mon Dec 7 12:38:25 2020 +0100 > > services: hurd-vm: Avoid circular dependency with (gnu system images > hurd). > > * gnu/services/virtualization.scm (hurd-vm-disk-image): Use > 'lookup-image-type-by-name' instead of referring to 'hurd-disk-image' > from (gnu system images hurd). > --- > gnu/services/virtualization.scm | 15 ++- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm > index eaf0bbd..f435630 100644 > --- a/gnu/services/virtualization.scm > +++ b/gnu/services/virtualization.scm [..] > @@ -913,14 +912,12 @@ that will be listening to receive secret keys on port > 1004, TCP." > (define (hurd-vm-disk-image config) >"Return a disk-image for the Hurd according to CONFIG. The secret-service > is added to the OS specified in CONFIG." > - (let ((os (secret-service-operating-system (hurd-vm-configuration-os > config))) > -(disk-size (hurd-vm-configuration-disk-size config))) > -(system-image > - (image > - (inherit hurd-disk-image) > - (format 'compressed-qcow2) > - (size disk-size) > - (operating-system os) This system-image included (size disk-size), and here > + (let* ((os(secret-service-operating-system > + (hurd-vm-configuration-os config))) > + (disk-size (hurd-vm-configuration-disk-size config)) > + (type (lookup-image-type-by-name 'hurd-qcow2)) > + (os->image (image-type-constructor type))) > +(system-image (os->image os disk-size goes unused. So we probably need something like diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm index f435630faf..3ede822183 100644 --- a/gnu/services/virtualization.scm +++ b/gnu/services/virtualization.scm @@ -917,7 +917,9 @@ is added to the OS specified in CONFIG." (disk-size (hurd-vm-configuration-disk-size config)) (type (lookup-image-type-by-name 'hurd-qcow2)) (os->image (image-type-constructor type))) -(system-image (os->image os +(system-image + (image (inherit (os->image os)) +(size disk-size) (define (hurd-vm-port config base) "Return the forwarded vm port for this childhurd config." Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45867: hurd-vm: custom disk-size ignored
Jan Nieuwenhuizen writes: > On current master, setting a bigger disk-size for a childhurd > > (service hurd-vm-service-type >(hurd-vm-configuration > (disk-size (* 12 (expt 2 30))) ;12GiB > > > is being ignored. I am suspecting [..] > disk-size goes unused. So we probably need something like > > diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm > index f435630faf..3ede822183 100644 > --- a/gnu/services/virtualization.scm > +++ b/gnu/services/virtualization.scm > @@ -917,7 +917,9 @@ is added to the OS specified in CONFIG." > (disk-size (hurd-vm-configuration-disk-size config)) > (type (lookup-image-type-by-name 'hurd-qcow2)) > (os->image (image-type-constructor type))) > -(system-image (os->image os > +(system-image > + (image (inherit (os->image os)) > +(size disk-size) > > (define (hurd-vm-port config base) >"Return the forwarded vm port for this childhurd config." I can connfirm this works, pushed to master as 5b785b2a62b885a65aeece1399f7e3a732dd1cea. > Greetings, > Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45618: development childhurd fails to build: glib@2.62.6: build system `meson'
Jan Nieuwenhuizen writes: Hello, > On current master > > 395489cdc959c3f3c026bf545c3ed95efc9919f0 > gnu: spice-vdagent: Update to 0.20.0. > > building > > ./pre-inst-env guix system disk-image --target=i586-pc-gnu > gnu/system/examples/devel-hurd.tmpl > > fail with > > guix system: error: gnu/packages/glib.scm:181:2: glib@2.62.6: build system > `meson' does not support cross builds My bad, turns out to be the new guile-avahi dependency that cannot be cross-built. For the archives, find an updated devel-hurd.tmpl attached that removes guile-avahi. Greetings, Janneke devel-hurd.tmpl Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45962: ‘binutils-mesboot0’ includes non-zero timestamps in ar archives
Ludovic Courtès writes: Hello! > Ludovic Courtès skribis: > >> On #bootstrappable, mid-kid reported that ‘binutils-mesboot0’ in >> commencement.scm lacks ‘--enable-deterministic-archives’. So I checked >> if this had an effect by running: > [...] > >> Apparently Binutils 2.14 didn’t have ‘--enable-deterministic-archives’ >> so we’ll have to patch it. > > Sikonas on #bootstrappable provided a patch for that (thanks!) so I went > ahead and gave it a try on ‘core-updates’ (Guix patch attached). Great! > The binutils source gets patched and repacked, but then decompressing it > fails: [..] > Maxime, does that ring a bell? Could it be that this bootstrap ‘xz’ is > less capable, or could it be a Gash-Utils bug? Currently, we avoid using non-bootstrapped binaries in the bootstrap, that includes 'xz'; earlier in the bootstrap that includes also 'patch'. See also gcc-core-mesboot0: it applies the patch in a manual phase. So I'm not sure if we want to start depending on 'xz' an this stage? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45962: ‘binutils-mesboot0’ includes non-zero timestamps in ar archives
Ludovic Courtès writes: Hey Ludo! > Jan Nieuwenhuizen skribis: > > I can think of two possibilities, then: (1) apply the patch in a phase > rather than via the ‘patches’ field, and (2) arrange so that > ‘patch-and-repack’ does not compress the patched code or compresses it > with the bootstrap gzip. Oh, that would be nice: we could remove all these clumsy manual patching stages. Also, we may be able to remove XZ from the bootstrap chain, if no XZ-repackaging happens and only build a final version. > My understanding is that #2 may be doable now thanks to Maxim’s recent > changes. I’ll take a look! Great! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#47055: guix upgrade throws a backtrace
Hello, running guix pull and then guix upgrade gave me this backtrace. The version is: guix (GNU Guix) 6e70211b20537b018e639b0114d3ccddd4924acb Backtrace: In guix/ui.scm: 2164:12 19 (run-guix-command _ . _) In guix/scripts/substitute.scm: 633:2 18 (guix-substitute . _) In unknown file: 17 (with-continuation-barrier #) In ice-9/boot-9.scm: 1736:10 16 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 15 (apply-smob/0 #) In ice-9/boot-9.scm: 1736:10 14 (with-exception-handler _ _ #:unwind? _ # _) 1736:10 13 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 12 (with-exception-handler # …) In guix/scripts/substitute.scm: 682:17 11 (_) 391:7 10 (process-substitution _ "/gnu/store/9iyfc2g1585ps9danh…" …) In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/substitute.scm: 400:9 8 (_) In ice-9/boot-9.scm: 1731:15 7 (with-exception-handler # …) 1669:16 6 (raise-exception _ #:continuable? _) 1667:16 5 (raise-exception _ #:continuable? _) 1669:16 4 (raise-exception _ #:continuable? _) 1764:13 3 (_ #<&compound-exception components: (#<&error> #<&irri…>) 1669:16 2 (raise-exception _ #:continuable? _) 1667:16 1 (raise-exception _ #:continuable? _) V)ï¾ÉDsubstitution of /gnu/store/9iyfc2g1585ps9danh95p0mw56pw8ik5-bison-3.5.3 failed _ #:continuable? _)ð^zܪÅszò guix system: error: corrupt input while restoring archive from # Jan Wielkiewicz
bug#48223: EXWM knows nothing about Guix profiles
> Leo Prikler writes:
Hello again,
>> I think the launcher that we install in the install-xsession does not
>> do sufficient work to set up the environment variables of the session
>> appropriately. In particular, I think it should source /etc/profile
>> prior to running Emacs.
>>
>> WDYT?
>
> I think this is a very good idea.
To follow-up on this: at first glance sourcing /etc/profile seemed to
fix my problem. However, I am calling some scripts from Emacs that need
my ~/.bash_profile to be sourced too.
So this got me wondering, something has definately changed here.
Before, this used to work OOTB. Any ideas what may have changed?
BTW, I only tested with slim
--8<---cut here---start->8---
(service slim-service-type
(slim-configuration
(auto-login? #t)
(allow-empty-passwords? #t)
(default-user "janneke")
;;(auto-login-session (file-append emacs-exwm "/bin/exwm"))
(auto-login-session "/home/janneke/bin/exwm")
(xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(server-arguments '("-listen" "tcp"
--8<---cut here---end--->8---
and now use the attached exwm, which works OK for me.
Greetings,
Janneke
exwm
Description: Binary data
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#33795: Update mes-minimal-stripped-tarball to Mes 0.19 on gnu.org
Hi! The current Mes bootstrap on Guix has a big problem: the bin directory has been stripped from mes-minimal-stripped-tarball; so the bootstrap in core-updates really (accidentally) depends on bootstrap-guile. This has been addressed by Ricardo and me at the R-B summit last week. I also managed to release Mes-0.19, which makes for a much faster bootstrap using Mes, and gives us a richer Mes C library that will allow us to build bash and tar, hopefully. On my core-updates branch at gitlab (https://gitlab.com/janneke/guix, 52c475a606 bootstrap: srfi-43: Remove) I have patches for all the above. Checking out the commit core-updates~4 --8<---cut here---start->8--- ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f bootstrap: Add mes-boot0; decouple mes-boot from Mes. --8<---cut here---end--->8--- I have built a new mes-minimal-stripped-tarball that I would like to put up on gnu.org --8<---cut here---start->8--- 19:26:16 janneke@dundal:~/src/guix/wip-seed $ guix hash /gnu/store/h80vzl6w2ih4hnrpmczs4m7v0qc888m9-mes-minimal-stripped-tarball-0.19/mes-minimal-stripped-0.19-i686-linux.tar.xz 0k7kkl68a6xaadv47ij0nr9jm5ca1ffj38n7f2lg80y72wdkwr9h --8<---cut here---end--->8--- The subsequent commit --8<---cut here---start->8--- 986e982884 bootstrap: bootstrap-mes: Update. --8<---cut here---end--->8--- has, apart from the guix hash update also --8<---cut here---start->8--- - "http://lilypond.org/janneke/guix/20181214/"; - "mes-minimal-stripped-0.18-1.a155a0a-i686-linux.tar.xz")) + "http://lilypond.org/janneke/guix/20181215/"; + "mes-minimal-stripped-0.19-i686-linux.tar.xz")) --8<---cut here---end--->8--- I'd be happy if we can do with a rewrite of the url this commit. Sorry for updating so soon, I sure hope we can keep this Mes-0.19 for quite some time. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#33795: Update mes-minimal-stripped-tarball to Mes 0.19 on gnu.org
Ludovic Courtès writes: Hello Ludo’! >> 19:26:16 janneke@dundal:~/src/guix/wip-seed >> $ guix hash >> /gnu/store/h80vzl6w2ih4hnrpmczs4m7v0qc888m9-mes-minimal-stripped-tarball-0.19/mes-minimal-stripped-0.19-i686-linux.tar.xz >> 0k7kkl68a6xaadv47ij0nr9jm5ca1ffj38n7f2lg80y72wdkwr9h > > I’ve rebuilt it and here’s what I got: > > ludo@ribbon ~/src/guix/+core-updates$ git describe > v0.16.0-178-gef809e3ac0 > ludo@ribbon ~/src/guix/+core-updates$ git log | head -1 > commit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f > ludo@ribbon ~/src/guix/+core-updates$ guix hash > bootstrap-tarballs.x86_64-linux/mes-minimal-stripped-0.19-x86_64-linux.tar.xz > 0k7kkl68a6xaadv47ij0nr9jm5ca1ffj38n7f2lg80y72wdkwr9h > > Match! Great! \o/ > If that’s fine with you, I’ll upload > mes-minimal-stripped-0.19-x86_64-linux.tar.xz to > alpha.gnu.org/gnu/guix/bootstrap/20181020 alongside the other tarballs. > > Sounds good? Beautiful. I'll rewrite the one commit to not introduce the lilypond.org URL and push my core-updates to savannah. > Thank you! Yes, thank you! Then we can inform Eelco on the new, fast bootstrap without %bootstrap-guile. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#33795: Update mes-minimal-stripped-tarball to Mes 0.19 on gnu.org
Jan Nieuwenhuizen writes: >> If that’s fine with you, I’ll upload >> mes-minimal-stripped-0.19-x86_64-linux.tar.xz to >> alpha.gnu.org/gnu/guix/bootstrap/20181020 alongside the other tarballs. >> >> Sounds good? > > Beautiful. I'll rewrite the one commit to not introduce the > lilypond.org URL and push my core-updates to savannah. > >> Thank you! > > Yes, thank you! > > Then we can inform Eelco on the new, fast bootstrap without > %bootstrap-guile. Pushed patch set to core-updates as 03a45a40227d97ccafeb49c4eb0fc7539f4d2127 bootstrap: srfi-43: Remove. Thanks! janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
