bug#50945: Guix home: No such file or directory: "/run/user/1003/on-first-login-executed"
On 2021-10-01 17:46, Jan Nieuwenhuizen wrote: > Hi, > > When using su or sudo to enter an account managed by guix home, I get > this error > > --8<---cut here---start->8--- > Backtrace: >2 (primitive-load "/home/guix/.guix-home/on-first-login") > In ice-9/ports.scm: >461:11 1 (call-with-output-file "/run/user/1003/on-first-login-…" …) > In unknown file: >0 (open-file "/run/user/1003/on-first-login-executed" "w" …) > > ERROR: In procedure open-file: > In procedure open-file: No such file or directory: > "/run/user/1003/on-first-login-executed" > --8<---cut here---end--->8--- > > Upon a console login or ssh login, /var/run/1003 is created and all is fine. > > See below for the scenario, home-minimal.scm is attached. > > Greetings, > Janneke > > > $ ssh guix@localhost -p > guix@localhost's password: > Last login: Tue Jun 23 11:45:08 2020 from 2001:980:1b4f:1:216:d3ff:fe29:7cdb > guix@dundal ~$ guix home reconfigure home-minimal.scm > /gnu/store/fgxpmf1iwjp9f8dfyaf7wxqa8105lq3w-home > Cleaning up symlinks from previous home-environment. > > Skipping /home/guix/.config/fontconfig (not an empty directory)... done > Skipping /home/guix/.config (not an empty directory)... done > Cleanup finished. > > New symlinks to home-environment will be created soon. > All conflicting files will go to > /home/guix/1633101995-guix-home-legacy-configs-backup. > > Skipping /home/guix/.config (directory already exists)... done > Creating /home/guix/.config/fontconfig... done > Symlinking /home/guix/.config/fontconfig/fonts.conf -> > /gnu/store/phj2z2iiqdhryfy7mqral0b9qz3hlva6-fonts.conf... done > Symlinking /home/guix/.config/test.conf -> > /gnu/store/bdixb09v30bvhpgi2f6ndiq25wzb9l74-tmp-file.txt... done > Symlinking /home/guix/.bash_profile -> > /gnu/store/j3vhlswj46psxicapnq8c9p1jrwd55rk-bash_profile... done > Symlinking /home/guix/.profile -> > /gnu/store/fxbppk3pqzdi3zzy0xl5vg1ir6c5jzq5-shell-profile... done > Symlinking /home/guix/.bashrc -> > /gnu/store/513j2xkszmcmv7fiawh59mr0i1fmin55-bashrc... done > done > Finished updating symlinks. > > Comparing > /gnu/store/fgxpmf1iwjp9f8dfyaf7wxqa8105lq3w-home/profile/share/fonts and > > /gnu/store/fgxpmf1iwjp9f8dfyaf7wxqa8105lq3w-home/profile/share/fonts... done > (same) > Evaling on-change gexps. > > On-change gexps evaluation finished. > > guix@dundal ~$ guix home list-generations > ]8;;file://dundal/var/guix/profiles/per-user/guix/guix-home-1-link\Generation > 1 Oct 01 2021 12:19:16]8;;\ (current) > file name: /var/guix/profiles/per-user/guix/guix-home-1-link > canonical file name: /gnu/store/fgxpmf1iwjp9f8dfyaf7wxqa8105lq3w-home > channels: > guix: > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: > ]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=56b10709efc4eb35df66f52a20ce3cb7fab4fee6\56b10709efc4eb35df66f52a20ce3cb7fab4fee6]8;;\ > configuration file: > ]8;;file://dundal/gnu/store/kjha5z8mck0pa9jrgx2266rq1lvlb3ji-configuration.scm\/gnu/store/kjha5z8mck0pa9jrgx2266rq1lvlb3ji-configuration.scm]8;;\ > guix@dundal ~$ logout > Connection to localhost closed. > 17:26:49 janneke@dundal:~ > $ sudo -i -u guix > Password: > Backtrace: >2 (primitive-load "/home/guix/.guix-home/on-first-login") > In ice-9/ports.scm: >461:11 1 (call-with-output-file "/run/user/1003/on-first-login-…" …) > In unknown file: >0 (open-file "/run/user/1003/on-first-login-executed" "w" …) > > ERROR: In procedure open-file: > In procedure open-file: No such file or directory: > "/run/user/1003/on-first-login-executed" > guix@dundal ~$ ls -ltrF /run/user > total 0 > drwx-- 7 gdm gdm 160 Oct 1 12:16 971/ > drwx-- 13 janneke janneke 260 Oct 1 13:07 1000/ > guix@dundal ~$ logout > 17:29:34 janneke@dundal:~ > $ su - guix > Password: > Backtrace: >2 (primitive-load "/home/guix/.guix-home/on-first-login") > In ice-9/ports.scm: >461:11 1 (call-with-output-file "/run/user/1003/on-first-login-…" …) > In unknown file: >0 (open-file "/run/user/1003/on-first-login-executed" "w" …) > > ERROR: In procedure open-file: > In procedure open-file: No such file or directory: > "/run/user/1003/on-first-login-executed" > 17:37:33 janneke@dundal:~ > $ ssh guix@localhost -p > guix@localhost's password: > Last login: Fri Oct 1 17:23:35 2021 from 127.0.0.1 > guix@dundal ~$ Thank you for a very detailed report. pam_elogind doesn't create a session, when the login shell spawned by sudo or su => XDG_RUNTIME_DIR not get created => this message appears. I think we can omit execution of any processes by on-first-login script in case session wasn't created. Added the check: From aab6df0298963fe91a6ebfd1dadbc1530eceeff7 Mon Sep 17 00:00:00 2001 From: Andrew Tropin Date: Thu, 7 Oct 2021 08:12:04 +0300 Subject: [PATCH] home-services:
bug#50941: I can confirm this bug too
On Sun, 03 Oct 2021 15:45:34 +0300 Efraim Flashner wrote: > On Sat, Oct 02, 2021 at 03:01:52AM -0400, jgart via Bug reports for GNU Guix > wrote: > > I was going to report this today but Pascal beat me to it. > > > > I get the same error when running `guix home reconfigure file.scm`. > > > > `guix home build file.scm` builds fine without errors. > > Can you try setting XDG_RUNTIME_DIR to someplace that you have writable > and then running reconfigure again? I have to warn you though I don't > have a good answer for what to do if it works this time and doesn't work > if you log out and log back in again. That fixed it for me. Specifically `export XDG_RUNTIME_DIR=$HOME/tmp` like Maxime mentioned. I think this should be documented for guix home users on a foreign distro so they don't get frustrated with this detail of getting set up. WDYT? Or is there another way that this configuration should be managed on a foreign distro? all best, jgart
bug#51035: Failure: guix pull
Hi, On Tue, 5 Oct 2021 at 16:04, Dale Mellor wrote: > guix pull: error: You found a bug: the program > '/gnu/store/dxfmlkrv92073p3vb2hf9bwczcnk0ss2-compute-guix- > derivation' > failed to compute the derivation for Guix (version: > "b54bf075c577b9f78041362035383dbbfb456617"; system: "x86_64- > linux"; > host version: "20bc9ecc204a610a0d5fa8b88c74421f57dbaf3b"; pull- > version: 1). I cannot reproduce with this: guix time-machine --commit=20bc9ecc204a610a0d5fa8b88c74421f57dbaf3b \ -- time-machine --commit=b54bf075c577b9f78041362035383dbbfb456617 \ -- help If '/gnu/store/dxfmlkrv92073p3vb2hf9bwczcnk0ss2-compute-guix-derivation' is produced, could you send it? All the best, simon
bug#51058: xdg-open wrong path in qt based applications (links wont be open)
I have an issue with opening the links in Qt based applications, like `lxqt-panel`, `qterminal` and I think all of the Qt based application. I mean, I can't open the `file:///home/hamzeh/` in these applications. I get the following error: ``` Launch failed (/gnu/store/bi4m86lripz4fhhi4c34ylg5ckxsrqzs-xdg-utils-1.1.3/bin/xdg-open ) ``` As you can see, it wants to run `xdg-open` from `/gnu/store/bi4m86lripz4fhhi4c34ylg5ckxsrqzs-xdg-utils-1.1.3/` path and this path isn't available. This `xdg-open` path has patched here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm?id=f868ed2a75b55400107b80fcc1e41dcfb6b3c28c#n447 So all of the application that are using `QDesktopServices::openUrl()` have this issue, since this path has filled with wrong value in the `qtbase` package. Also the `xdg-utils` is installed but in the different path, the correct and current installed path is: ``` /gnu/store/0zdclmgw5gnpifwb7jyrmplrk13wp0yz-xdg-utils-1.1.3/ ``` The workaround is installing the `xdg-utils` manually, but it's a temporary solution since after running the `guix gc`, again I'll face with this issue. Some details: 1. In the fresh install I have the `xdg-utils` in the store at this path: ``` $ ll /gnu/store/ | grep xdg-utils dr-xr-xr-x4 root root 4096 Jan 1 1970 0zdclmgw5gnpifwb7jyrmplrk13wp0yz-xdg-utils-1.1.3/ ``` and I can't open the links in Qt applications. 2. After installing the `xdg-utils` manually, two `xdg-utils` paths were added to store: ``` $ ll /gnu/store/ | grep xdg-utils dr-xr-xr-x4 root root 4096 Jan 1 1970 0zdclmgw5gnpifwb7jyrmplrk13wp0yz-xdg-utils-1.1.3/ -r--r--r--2 root root 1120 Jan 1 1970 35m23zhgbc4rrjrf36dag9abx7r6fnji-xdg-utils-1.1.3-guile-builder dr-xr-xr-x4 root root 4096 Jan 1 1970 3g26il93p23p4fcg1hfn797n4blqh0f6-xdg-utils-1.1.3/ dr-xr-xr-x4 root root 4096 Jan 1 1970 bi4m86lripz4fhhi4c34ylg5ckxsrqzs-xdg-utils-1.1.3/ -r--r--r--2 root root 3739 Jan 1 1970 makz45834k44dg1x1h1v91nqib41wd91-xdg-utils-1.1.3.drv -r--r--r--2 root root 5706 Jan 1 1970 mix35kkjk3prj2kwi96qx74biwqbmxx7-xdg-utils-1.1.3-guile-builder -r--r--r--2 root root 1269 Jan 1 1970 sz8s218fxvq8hr1ikn4m8g1z3ydbprbs-xdg-utils-1.1.3.drv -r--r--r--2 root root 909 Jan 1 1970 zbvwka7a27baz22w8k78jyjkrqaxcc4v-xdg-utils-1.1.3.tar.gz.drv ``` there is no issue with opening the links at this state. 3. After running the `guix gc` the `xdg-utils` path are: ``` $ ll /gnu/store/ | grep xdg-utils dr-xr-xr-x4 root root 4096 Jan 1 1970 0zdclmgw5gnpifwb7jyrmplrk13wp0yz-xdg-utils-1.1.3/ -r--r--r--2 root root 1120 Jan 1 1970 35m23zhgbc4rrjrf36dag9abx7r6fnji-xdg-utils-1.1.3-guile-builder dr-xr-xr-x4 root root 4096 Jan 1 1970 3g26il93p23p4fcg1hfn797n4blqh0f6-xdg-utils-1.1.3/ -r--r--r--2 root root 3739 Jan 1 1970 makz45834k44dg1x1h1v91nqib41wd91-xdg-utils-1.1.3.drv -r--r--r--2 root root 5706 Jan 1 1970 mix35kkjk3prj2kwi96qx74biwqbmxx7-xdg-utils-1.1.3-guile-builder -r--r--r--2 root root 1269 Jan 1 1970 sz8s218fxvq8hr1ikn4m8g1z3ydbprbs-xdg-utils-1.1.3.drv -r--r--r--2 root root 909 Jan 1 1970 zbvwka7a27baz22w8k78jyjkrqaxcc4v-xdg-utils-1.1.3.tar.gz.drv ``` And in this state, again, there is an issue with opening the links: ``` Launch failed (/gnu/store/bi4m86lripz4fhhi4c34ylg5ckxsrqzs-xdg-utils-1.1.3/bin/xdg-open ) ``` And again I can install `xdg-utils`, it cause to adding `bi4m86lripz4fhhi4c34ylg5ckxsrqzs-xdg-utils-1.1.3/` to store and the issue will be fixed but after each `guix gc`, again I have the issue. (1). I need to fix the issue permanently and also without installing `xdg-utils` manually. How? (2). Seems that `qtbase` are referring to a wrong path (`bi4m86lripz4fhhi4c34ylg5ckxsrqzs-xdg-utils-1.1.3/`) here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm?id=f868ed2a75b55400107b80fcc1e41dcfb6b3c28c#n447 Why? and where does this wrong path come from? (3) Why after installing the `xdg-utils` I have those new paths in my store? And why after `guix gc` they will be deleted? Regards, -- Hamzeh Nasajpour PantherX Team
bug#51055: [cuirass] Missing dependencies.
Mathieu Othacehe schreef op wo 06-10-2021 om 08:53 [+]: > [...] > Cuirass uses the derivation file names to determine the dependencies and > is thus tricked by this mismatch. > > There are two things that are a bit unclear to me: > > 1. What causes those derivation differences while the output is identical? I'd presume changing the source URL of some package (while keeping the hash intact). That changes fixed-output derivations but keeps the output intact, IIUC. This hypothesis can be tested by replacing %mirrors by '() in (guix download) and comparing the derivation and output path of a package using a mirror:// url before and after. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
bug#51055: [cuirass] Missing dependencies.
Hello, I noticed that some builds were missing dependencies in the Cuirass web interface. For instance, compare those two builds of python-git-review: https://ci.guix.gnu.org/build/89691/details https://ci.guix.gnu.org/build/135/details When looking closer to one dependency, python-pysocks for the build 100035, this command reports the corresponding derivation: --8<---cut here---start->8--- guix time-machine --commit=79fbbe5e4a7cd79613d49c0dda51872f2492cc76 -C ~/.config/guix/channels-default.scm -- build --no-grafts python-pysocks -d /gnu/store/49bprfjvzlfm893622fkmi4jb6msyg2j-python-pysocks-1.7.1.drv --8<---cut here---end--->8--- On the other hand, in the Cuirass database, we have: --8<---cut here---start->8--- cuirass=# select derivation from jobs left join builds on jobs.build = builds.id where jobs.evaluation = 27768 and name = 'python-pysocks.x86_64-linux'; /gnu/store/pm576s0gi7b8n9bpllmj3kdin0r6dj22-python-pysocks-1.7.1.drv --8<---cut here---end--->8--- There are two different derivations which explains why python-pysocks is not listed as dependency of the build 100035. While those derivations are different, they have the same output: --8<---cut here---start->8--- guix time-machine --commit=79fbbe5e4a7cd79613d49c0dda51872f2492cc76 -C ~/.config/guix/channels-default.scm -- build --no-grafts python-pysocks /gnu/store/x76mk7rx4hyqk6hngflpx182rvmb-python-pysocks-1.7.1 --8<---cut here---end--->8--- and --8<---cut here---start->8--- cuirass=# select path from jobs left join builds on jobs.build = builds.id left join outputs on builds.derivation = outputs.derivation where jobs.evaluation = 27768 and jobs.name = 'python-pysocks.x86_64-linux'; /gnu/store/x76mk7rx4hyqk6hngflpx182rvmb-python-pysocks-1.7.1 --8<---cut here---end--->8--- So, when Cuirass tried to register the /gnu/store/49bprfjvzlfm893622fkmi4jb6msyg2j-python-pysocks-1.7.1.drv, it skipped it because another build with the same output already existed. Cuirass uses the derivation file names to determine the dependencies and is thus tricked by this mismatch. There are two things that are a bit unclear to me: 1. What causes those derivation differences while the output is identical? 2. How we could work-around this issue to have Cuirass list all dependencies? Thanks, Mathieu
bug#51048: No license in crate - guix import
Michael Zappa schreef op di 05-10-2021 om 18:31 [-0400]: > Hello all, > I have been playing around with the 'guix import' tools to > see how easily I can get some package definitions. In the process of > trying to package https://github.com/Spotifyd/spotifyd with 'guix import > crate spotifyd -r' I found that one of the nested dependencies, > libpulse-sys@0.0.0 did not work with the automatic importer because it > does not have a license in its crate > https://crates.io/crates/libpulse-sys/0.0.0. > > Obviously it would be ideal to get whoever is using this out-of-date > library in their package to update their dependencies so this is > entirely avoided, but short of that has there ever been discussion on > how to handle 'license-less' packages? I haven't seen any in my short > time lurking on this list. It seems to be a rigid requirement for the > crate importer. I don't now if there has been a discussion, but other importers (at least the minetest importer) set the license field to #f if no license information was unavailable. Modifying such that 'license' is set to #f if it has 'null' as value in the JSON might be sufficient I think? Greetings, Maxime signature.asc Description: This is a digitally signed message part
