bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.
Hi there, I recently hit this issue, and was able work around it by: 1. Get root shell (via sudo or otherwise) 2. Disable dbus-system: 'herd stop guix-system' 3. Update guix: 'guix system reconfigure ...' 4. Reboot Thought I would note it just in case its useful to someone else. Kind regards, -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
bug#62672: Unexpected interaction between gobject-introspection and grafts
Thanks Josselin. I haven't looked at this in some time, so I'm closing to avoid clutter. -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur
Excellent! Confirmed latest version 1.2.0-2.7bcd3d0 solves the issue. Also, fwiw I was not on a foreign distro. Also, thanks for noting that cuirass also is a channel, so in the future I could simply use it directly for upstream changes. Best wishes! On 15 Jan 2024 at 10:40, Ludovic Courtès wrote: > Hi, > > Ludovic Courtès skribis: > >> Cuirass commits 10a5117936bb51c54a362172b6e53ef5150ab909 and >> b8ee2486ce877e42a3f910610d3efa8274e2603f appear to fix issues when >> building in local build mode that most likely explain what you were >> observing. > > If you run ‘guix pull’ now, you’ll get version 1.2.0-2.7bcd3d0 of the > ‘cuirass’ package, which includes the fixes above. > > I’m tentatively closing this issue but please do let me know if you > notice any problems. > > Thanks, > Ludo’. -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
bug#68264: awscli@2.2.0 downloads and runs a docker container from a large american corporation
One thing I deeply appreciate about Gnu Guix is the fact that I have assurance that I have installed and am using software that respects my fundamental software freedoms. My understanding based on Guix's packaging guidelines (https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html) is that a package should include all necessary software, libraries and resources necessary for the program to function; either directly or via dependencies. However, it appears that awscli@2.2.0 (and all former versions of the v2 variant of awscli) download a docker image and run it. This is evident by the following, where guix shell is used to run awscli@2.2.0 in a container, but docker and its daemon are not present. --8<---cut here---start->8--- ➜ guix shell -C awscli@2.2.0 -- awsv2 --version 2.2.0 AWS CLI v2 command: docker run -i --rm -v /home/collin/.aws:/root/.aws -v /home/collin:/aws amazon/aws-cli 14:45:09 - awscliv2 - ERROR - Executable not found: docker --8<---cut here---end--->8--- I propose awscli@2.2.0 be removed immediately from guix. Kind regards PS: I have a packaged version of awscliv2 (2.15.6) available https://git.rekahsoft.ca/rekahsoft/rekahsoft-guix/src/branch/master/rekahsoft-gnu/packages/python-xyz.scm#L244-L329 It is still in need of some cleanup, and awscli is in an odd place (given the dependencies they vendor and fork), but it does work, and it depends on sources. This also follows closely to what nix does (see https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/admin/awscli2/default.nix). -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur
After updating cuirass (details below), my cuirass instance no longer builds anything! It continues to poll channels, run evaluations and queue builds, but none of the builds ever run. --8<---cut here---start->8--- Before: Cuirass 1.1.0-13.1341725 (guix checkout c4cca9cb5d3e93ef146acb930a95da9d2da6fb06) After: Cuirass 1.2.0-1.bdc1f9f (guix checkout 25b83bd9e4ceb77f08c0caee3ecdc48263b53a46) --8<---cut here---end--->8--- After a bit of investigation, I noticed numerous instances of this in the logs following the update: --8<---cut here---start->8--- /var/log/guix-daemon.log-2024-01-03 10:08:22 SIGPOLL /var/log/guix-daemon.log:2024-01-03 10:08:22 unexpected build daemon error: interrupted by the user --8<---cut here---end--->8--- It may be worth noting that I am running cuirass with substitutes on. Any help appreciated. -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
bug#63546: nix-channel error: opening pseudoterminal master: No such device
For What Its Worth (fwiw): I found that restarting the nix-daemon shepherd service makes this issue go away for me. Not sure what is the underlying cause, but thought I'd mention it for others. Kind regards, -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
bug#62672: Unexpected interaction between gobject-introspection and grafts
Hi John, Thanks for taking the time to chime in, much appreciated! > https://gitlab.com/podiki/guix-pod/-/blob/main/taffybar.scm I took a look at your repo and found that our definition of ghc-gi-gdk is almost exactly the same (sans some historical differences (eg, using gtk (v4) vs gtk+)). > On the gobject-introspection front, I do remember needing some tinkering > there for cairo, and ended up using what was suggested here: > https://issues.guix.gnu.org/49122#4 Interesting! Sadly I rediscovered this and provided a very similar solution in the first message of this bug report (with the help of a similar issue in nix). imho we should adjust the goject-introspection package to include working cairo typelib files. > Checking now taffybar does not build (some dependent package failing, > looks like needs an input change) but ghc-gi-gdk does. This should be > the bulk of the work you need beyond polishing (linting, license checks, > all that). It is a lot of packages, many are the autogenerated > haskell-gi packages as I'm sure you are familiar. I'll take a closer look this evening whether or not there is some other difference that could be causing the reported build failure. > but hopefully this is helpful Definitely useful insight, thanks again John! > Let me know if you need help parsing this early and rough packaging I > did, though I think it shouldn't take much to get it to build again > (famous last words, I know). I don't foresee any issues with understanding whats going on (similarly, famous last works ) but if I have any questions I'll let you know in this thread. On 05 Apr 2023 at 19:55, John Kehayias wrote: > Hi Collin and Josselin, > > I haven't fully read this thread but wanted to chime in with work I did > but never finalized to upstream here. In short, I did get taffybar to > build and run if I recall. There was a lot of fussing with versions, > some Haskell packages that were broken/undergoing some breaking changes > at the time...I don't remember the details, sorry. > > https://gitlab.com/podiki/guix-pod/-/blob/main/taffybar.scm > > Checking now taffybar does not build (some dependent package failing, > looks like needs an input change) but ghc-gi-gdk does. This should be > the bulk of the work you need beyond polishing (linting, license checks, > all that). It is a lot of packages, many are the autogenerated > haskell-gi packages as I'm sure you are familiar. > > On the gobject-introspection front, I do remember needing some tinkering > there for cairo, and ended up using what was suggested here: > https://issues.guix.gnu.org/49122#4 > > I haven't used Taffybar much since I went back to my lisp land (StumpWM) > but hopefully this is helpful. Some Haskell experts can chime in with > other details or polishing once it builds. > > Let me know if you need help parsing this early and rough packaging I > did, though I think it shouldn't take much to get it to build again > (famous last words, I know). > > John -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca
bug#62672: Unexpected interaction between gobject-introspection and grafts
ibffi.so.7 (0x7f005739c000) libdl.so.2 => /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libdl.so.2 (0x7f0057397000) libpcre.so.1 => /gnu/store/di5bqb45hi5lvp2q08hlxqjdcl9phjb1-pcre-8.45/lib/libpcre.so.1 (0x7f005731d000) libz.so.1 => /gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11/lib/libz.so.1 (0x7f005730) libmount.so.1 => /gnu/store/5583c2za2jsn9g6az79rnksgvigwnsk7-util-linux-2.37.2-lib/lib/libmount.so.1 (0x7f00572a3000) libresolv.so.2 => /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libresolv.so.2 (0x7f005728a000) libthai.so.0 => /gnu/store/2zlx5p93icsrqvc0w3lzgkc6dd3wd4jl-libthai-0.1.28/lib/libthai.so.0 (0x7f005727c000) libfreetype.so.6 => /gnu/store/ak70pk2hjks17cx7zjdmdmzpcpiy9gpi-freetype-2.10.4/lib/libfreetype.so.6 (0x7f00571cc000) libgraphite2.so.3 => /gnu/store/z6d288h1g876vypda400nhh224yz49im-graphite2-1.3.13/lib/libgraphite2.so.3 (0x7f00571a9000) libgcc_s.so.1 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x7f005718f000) libpixman-1.so.0 => /gnu/store/j8x167zaka2h6pxk7wiq5zkg67hzf8a2-pixman-0.40.0/lib/libpixman-1.so.0 (0x7f00570e5000) libxcb-shm.so.0 => /gnu/store/v8raqm2shh9azkl71107p53j55hir306-libxcb-1.14/lib/libxcb-shm.so.0 (0x7f00570e) libxcb.so.1 => /gnu/store/v8raqm2shh9azkl71107p53j55hir306-libxcb-1.14/lib/libxcb.so.1 (0x7f00570b7000) libxcb-render.so.0 => /gnu/store/v8raqm2shh9azkl71107p53j55hir306-libxcb-1.14/lib/libxcb-render.so.0 (0x7f00570a7000) libXrender.so.1 => /gnu/store/jh778dla5w316bsfc63q8fnhn87j81lw-libxrender-0.9.10/lib/libXrender.so.1 (0x7f0057098000) libbz2.so.1.0 => /gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/lib/libbz2.so.1.0 (0x7f0057085000) libexpat.so.1 => /gnu/store/iwcw80p8lkqsqbvchjvypvl06qlbjc3d-expat-2.4.1/lib/libexpat.so.1 (0x7f0057054000) /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33/lib/ld-linux-x86-64.so.2 (0x7f0058ba) libXau.so.6 => /gnu/store/9k6slxs8ynz46h85bcy3zk2mx0nn8rpf-libxau-1.0.9/lib/libXau.so.6 (0x7f005704d000) libXdmcp.so.6 => /gnu/store/dfzp4rhkzqqagx3djn2kcnaflz1m8446-libxdmcp-1.1.3/lib/libXdmcp.so.6 (0x7f0057045000) libbsd.so.0 => /gnu/store/7b5qsjh2cbhwnqbdicvl81496k7b0g0j-libbsd-0.10.0/lib/libbsd.so.0 (0x7f005702c000) libicuuc.so.69 => /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1/lib/libicuuc.so.69 (0x7f0056e3b000) libicui18n.so.69 => /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1/lib/libicui18n.so.69 (0x7f0056a0) libjson-glib-1.0.so.0 => /gnu/store/vp510k7i9lqan4d61nddlhhgdigbcx14-json-glib-1.6.2/lib/libjson-glib-1.0.so.0 (0x7f0056e0c000) libxml2.so.2 => /gnu/store/g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12/lib/libxml2.so.2 (0x7f0056892000) libsqlite3.so.0 => /gnu/store/xmzx5mzv4863yw9kmr2ykndgp37p8if0-sqlite-3.36.0/lib/libsqlite3.so.0 (0x7f0056757000) liblzma.so.5 => /gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/lib/liblzma.so.5 (0x7f0056de3000) libblkid.so.1 => /gnu/store/5583c2za2jsn9g6az79rnksgvigwnsk7-util-linux-2.37.2-lib/lib/libblkid.so.1 (0x7f0056d8e000) libdatrie.so.1 => /gnu/store/qlz21x91bs9n3f8nangfsk6g5rfqxvaz-libdatrie-0.2.13/lib/libdatrie.so.1 (0x7f0056d84000) libicudata.so.69 => /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1/lib/libicudata.so.69 (0x7f0054a0) libstdc++.so.6 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x7f0056582000) --8<---cut here---end--->8--- You'll noticed linux-vdso.so.1 doesn't reference a file but afaik this is expected as its a virtual library provided by the kernel. > These errors can also be caused by dependent libraries not being found, > or linker errors, etc. I would suggest to run `ldd` on the .so itself > (from glibc), and see what the output is. This doesn't appear to be the case. Did I miss something? > Grafts are applied after all packages have been built, so it is normal > that the build environment would see and use the ungrafted gtk. Yes, but that makes the error all the more confusing; the original error says that it can't find "/gnu/store/91ar3zh59n19rdn00png5r9hxp3k0y13-gtk-4.8.1/lib/libgtk-4.so.1", however this is the ungrafted gtk package, so it SHOULD (afaik) exist throughout the build. Further, when I enter a simulated build environment, the file does indeed exist. Thanks again for you ongoing help and support! On 05 Apr 2023 at 10:11, Josselin Poiret wrote: > [[PGP Signed Part:Undecided]] > Hi Collin, > > "Collin J. Doering" via Bug reports for GNU Guix > writes: > >> Hi team Guix! >> >> I was working on packaging taffybar (https://github.com/taffybar/taffybar), >> which depends >> on haskell-gi (http
bug#62672: Unexpected interaction between gobject-introspection and grafts
-phases %standard-phases
(add-before 'configure 'patch-cairo-gir
(lambda* (#:key inputs outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(cairo (assoc-ref inputs "cairo")))
(substitute* '("gir/cairo-1.0.gir.in")
(("@CAIRO_SHARED_LIBRARY@")
(string-append cairo "/lib/@CAIRO_SHARED_LIBRARY@")))
#t
--8<---cut here-----------end--->8---
Note: this adjustment to gobject-introspection should likely make it upstream
(and was inspired by a similar change to nix (described
https://github.com/NixOS/nixpkgs/pull/34081)).
--
Collin J. Doering
http://rekahsoft.ca
http://blog.rekahsoft.ca
http://git.rekahsoft.ca
bug#54631: Unable to determine system origin when configuration stored in guix channel
Hi Liliana, Thank you for your response :) > Alternatively, Guix could take the expression specified via -e and > write it to disk. I think this would be the best way to resolve this issue. Also, thanks for your explanation. > LOAD_PATH tweaking should be considered harmful and void your > provenance, at least w.r.t. channels. There's no sane way for guix to > check whether the load paths you added still exist after > reconfiguration, other than placing the entire directory in the store. I agree! However, I think it would be nice if `guix system describe`, `guix system list-generations`, `guix home list-generations`, etc.. indicated when a generation was created with the `-L|--load-path` argument specified. As you said, it 'voids you provenance', so I think its something that should be visually indicated to the user. Regards -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca
bug#54631: Unable to determine system origin when configuration stored in guix channel
Hi, I recently converted my guix configuration to be stored in a channel, primarily to allow me to reference files in the repository but yet still have a self-contained configuration. It also allows me to easily build packages and images from my local guix instance. I also like how the specification of my system (or home) is precisely defined by a set of channels, and an expression which evaluates to the operating-system (or home-configuration) that I'm deploying. As per the guix manual: --8<---cut here---start->8--- If you want configuration.scm to be self-contained, we recommend that modules or files it refers to be part of a channel. --8<---cut here---end--->8--- This all being said, I noticed an issue in that I'm unable to determine the provenance of a system when my configuration is stored in a guix channel. Specifically, if I have a guix channel that contains two modules, each of which exports a %system variable of type operating-system, I cannot tell which one was used to instantiate the system. This is due to two issues. The first is because when `-e|--expression` arguments are used, `configuration-file` is set to `#f` in the generations provenance file but the expression itself is not stored in the provenance file, and is not listed in `guix system describe`, `guix system list-generations`, etc.. commands. --8<---cut here---start->8--- sudo -i guix system reconfigure -e '(@ (my config system-a) %system)' --8<---cut here---end--->8--- --8<---cut here---start->8--- ➜ guix system describe Generation 30 Mar 28 2022 22:50:55(current) file name: /var/guix/profiles/system-30-link canonical file name: /gnu/store/886xwflic0dnf86d460yf7n5wg3jng7w-system label: GNU with Linux 5.16.16 bootloader: grub-efi root device: label: "root" kernel: /gnu/store/44hi9qg3mrp6c6cb1rqwx47xhg1663d9-linux-5.16.16/bzImage channels: guix: repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e584a093f943be216fdc93895281fde835836b8d my-config-channel: repository URL: https://not-yet-on-the-internet.com branch: master commit: 918a3bf799038a019c7394cda480ee67db8a0009 --8<---cut here---end--->8--- Change the system to 'system-b': --8<---cut here---start->8--- sudo -i guix system reconfigure -e '(@ (my config system-b) %system)' --8<---cut here---end--->8--- --8<---cut here---start->8--- ➜ guix system describe Generation 31 Mar 28 2022 23:10:01(current) file name: /var/guix/profiles/system-31-link canonical file name: /gnu/store/jpkxxyh6zi3gh8pbml3r9l1iccibw5mk-system label: GNU with Linux 5.16.16 bootloader: grub-efi root device: label: "root" kernel: /gnu/store/jpkxxyh6zi3gh8pbml3r9l1iccibw5mk-linux-5.16.16/bzImage channels: guix: repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e584a093f943be216fdc93895281fde835836b8d my-config-channel: repository URL: https://not-yet-on-the-internet.com branch: master commit: 918a3bf799038a019c7394cda480ee67db8a0009 --8<---cut here---end--->8--- Notice how there is no way to see which configuration was used to create the system. The second issue is that when `-L|--load-path` is used along with either a file or expression to specify the operating-system or home-configuration, it essentially 'tarnishes' the provenance of the system, in that the following deployment is not differentiable from the preceding one/s, despite them being different. --8<---cut here---start->8--- sudo -i guix system reconfigure -L my-local-channel-but-with-changes -e '(@ (my config system-a) %system)' --8<---cut here---end--->8--- --8<---cut here---start->8--- ➜ guix system describe Generation 32 Mar 28 2022 23:10:01(current) file name: /var/guix/profiles/system-32-link canonical file name: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-system label: GNU with Linux 5.16.16 bootloader: grub-efi root device: label: "root" kernel: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-linux-5.16.16/bzImage channels: guix: repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e584a093f943be216fdc93895281fde835836b8d my-config-channel: repository URL: https://not-yet-on-the-internet.com branch: master commit: 918a3bf799038a019c7394cda480ee67db8
bug#37348: Force https redirect missing from ci, workflow and workflows guix.info sub-domains
Hi all, Not sure where the best place to report this, however today I noticed that ci.guix.info, workflow.guix.info and workflows.guix.info do not redirect http to https, though its also served over https. Kind regards, -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
