bug#71332: guix gc delete order
On 2024-06-03 15:26, Nicolas Graves via Bug reports for GNU Guix wrote: > On 2024-06-03 09:30, Guillaume Le Vaillant wrote: > >> Hi. >> Is the guix-daemon of your system started with the >> "--gc-keep-derivations=yes" and "--gc-keep-outputs=yes" options? >> It should prevent "guix gc" from deleting the build dependencies of live >> profiles. Didn't know about those options, thank you for sharing! > > Probably not if they have to be added through the extra-options field of > record. I'll try that, thanks! I was suffering from the issue you have. After I updated SSD I just don't do gc, but it would be a good fix for the problem, if it works. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#48692: busctl call fails on elogind 243.7
On 2024-04-19 20:59, Maxim Cournoyer wrote: > Hi, > > Andrew Tropin writes: > >> I try to use busctl to control the brightness of my screen: >> >> $ busctl call org.freedesktop.login1 >> /org/freedesktop/login1/session/auto org.freedesktop.login1.Session >> SetBrightness "ssu" "backlight" "intel_backlight" 24242 >> Call failed: Connection timed out >> >> It worked once, but at the same reported connection timed out, after >> that it doesn't work and report the same connection timed out message. >> After restart the situtation repeats. >> >> I tried to build Guix System with elogind 246.10, the issue with busctl >> is gone and it works fine without timed out message any number of times. > > Since we are now using a newer elogind, I trust this issue is obsolete. > > Closing. Yep, checked it, it works great now. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#69284: guix pull is not reproducible
On 2024-03-10 11:13, Josselin Poiret via Bug reports for GNU Guix wrote:
> Hi Andrew,
>
> Andrew Tropin via Bug reports for GNU Guix writes:
>
>> I don't think that hash of the profile depends on the building process
>> itself. And it seems on the same system it returns the same result on
>> consequent rebuilds. It seems something leaks from the environment.
>
> Yes, it's rather that the .drv themselves are not reproducible
> apparently. Can you compare the derivations building the guixes in the
> different profiles? You can look at them using first `guix gc
> --derivers` on the profile and then analyzing the .drv manually. I
> remember seeing the same thing, but I don't really remember anything
> conclusive.
>
> One thing I can say is that Guix generates the .drv dynamically by
> looking at the check-out. If the checkout is somehow tainted (as it has
> often happened, maybe because of libgit2?), the .drv can end up being
> different. If you retry by first resetting the Guix checkouts in
> ~/.cache/guix/checkouts/ to a pristine state, do you still get a
> discrepancy?
>
> Best,
I spinned up VPSes from scratch, so check-outs are empty.
I did the same thing as in the first message:
--8<---cut here---start->8---
curl https://paste.sr.ht/blob/538fae89d3ee38a803894ec675d78144c8111bb6 >
channels.scm
guix pull -C channels-lock.scm -p tmp
--8<---cut here---end--->8---
but in addition to that I did rebuilds of guix profile with recently
built guix to find a "fixed point".
--8<---cut here---start->8---
tmp/bin/guix pull -C channels-lock.scm -p tmp2
tmp2/bin/guix pull -C channels-lock.scm -p tmp3
--8<---cut here---end--->8---
On both debian and guix machines fixed point was reached on the second
iteration, but they were not the same.
== Guix instance, guix profiles and respective derivations ==
/gnu/store/3xjs43f4x25gjic106q3gcagsxvzr2y6-profile.drv
tmp -> /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile
/gnu/store/jirindb2jrzhap6br5lgs4babxgy7m5z-profile.drv
tmp2 -> /gnu/store/mn55rb4z9s2sriskn5qwbxjbl5na0ah2-profile
/gnu/store/jirindb2jrzhap6br5lgs4babxgy7m5z-profile.drv
tmp3 -> /gnu/store/mn55rb4z9s2sriskn5qwbxjbl5na0ah2-profile
/gnu/store/3xjs43f4x25gjic106q3gcagsxvzr2y6-profile.drv:
--8<---cut here---start->8---
Derive
([("out","/gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile","","")]
,[("/gnu/store/0d4wiyh27zdk96hvm2sdagr30845van1-fonts-dir.drv",["out"])
,("/gnu/store/3k0bmrwhvskpkgy4gkwmrbx55mmhp5z8-ca-certificate-bundle.drv",["out"])
,("/gnu/store/79j21y7hhqdv45z7p5fv9g40cknplvxh-guile-3.0.9.drv",["out"])
,("/gnu/store/7sap6q0xsyjz41wq7bccdh5jj6j94jbz-guix-package-cache.drv",["out"])
,("/gnu/store/a16s8ykjgsjx4xr2m9qicrkrn4kxbwbn-info-dir.drv",["out"])
,("/gnu/store/mijc61yfd18mjagsl2d13sx8ia3xy5gw-emacs-subdirs.drv",["out"])
,("/gnu/store/q33r4jx8gsb1kzjl96zyv6yl30jhilga-rde.drv",["out"])
,("/gnu/store/xhw613vcqq3fj7aj0wdj7jxpcch2ic7q-module-import-compiled.drv",["out"])
,("/gnu/store/yg6mqrnwn1f35dmq9xr8y6rqqd3sjgvw-guix-d264237d5.drv",["out"])
,("/gnu/store/zpai0c66k06ab1hcf10h032xzn5zb382-glibc-utf8-locales-2.35.drv",["out"])]
,["/gnu/store/4jw49s17qv7ppg07sb2ww43vsl9zk9wn-profile-builder","/gnu/store/y545dx7df92al3yz1a9swnf0lhjg9igi-module-import"]
,"x86_64-linux","/gnu/store/354dvnz4pxvqdmx2hjk4qy6h3gkz5s8w-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/y545dx7df92al3yz1a9swnf0lhjg9igi-module-import","-C","/gnu/store/s1s8hxnj7prqafr6ay9994nj11d2wd1w-module-import-compiled","/gnu/store/4jw49s17qv7ppg07sb2ww43vsl9zk9wn-profile-builder"]
,[("GUILE_WARN_DEPRECATED","no")
,("allowSubstitutes","0")
,("guix properties","((type . profile) (profile (count . 2)))")
,("out","/gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile")
,("preferLocalBuild","1")])
--8<---cut here---end--->8---
/gnu/store/jirindb2jrzhap6br5lgs4babxgy7m5z-profile.drv:
--8<---cut here---start->8---
Derive
([("out","/gnu/store/mn55rb4z9s2sriskn5qwbxjbl5na0ah2-profile","","")]
,[("/gnu/store/05vsyxfknr3aqa5ybj39215plc1im06k-rde.drv",["out"])
,("/gnu/store/
bug#69284: guix pull is not reproducible
On 2024-03-07 12:45, Vagrant Cascadian wrote: > On 2024-02-20, Andrew Tropin wrote: >> guix pull -C channels-lock.scm produces different profiles on different >> machines. >> >> I executed the same command on a few different machines. >> channels-lock.scm contains channels list with exact commit specified. >> >> --8<---cut here---start->8--- >> curl https://paste.sr.ht/~abcdw/5f18e9e5cc6cb243c84a3975eb4e6a46ed17d996 > >> channels-lock.scm >> guix pull -C channels-lock.scm -p tmp >> readlink tmp-1-link >> --8<---cut here---end--->8--- >> >> The output log on all machines starts similiar: >> --8<---cut here---start->8--- >> Updating channel 'rde' from Git repository at >> 'https://git.sr.ht/~abcdw/rde'... >> Authenticating channel 'rde', commits 257cebd to 2a0c7e9 (2304 new >> commits)... >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> Authenticating channel 'guix', commits 9edb3f6 to d264237 (69420 new >> commits)... >> Building from these channels: >> guix https://git.savannah.gnu.org/git/guix.git d264237 >> rde https://git.sr.ht/~abcdw/rde2a0c7e9 >> --8<---cut here---end--->8--- >> >> --8<---cut here---start->8--- >> Updating channel 'rde' from Git repository at >> 'https://git.sr.ht/~abcdw/rde'... >> Authenticating channel 'rde', commits 257cebd to 2a0c7e9 (2,304 new >> commits)... >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> Authenticating channel 'guix', commits 9edb3f6 to d264237 (2,382 new >> commits)... >> Building from these channels: >> guix https://git.savannah.gnu.org/git/guix.git d264237 >> rde https://git.sr.ht/~abcdw/rde2a0c7e9 >> --8<---cut here---end--->8--- >> >> but resulting profile is different: >> /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile (local fresh guix system) >> /gnu/store/c2i8iyqkc146ac2hqzy1v6zkqs82xypp-profile (debian 11) >> /gnu/store/svg0is4iwvlg6mgi2rvpkngcccqcvhys-profile (debian 12) >> /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile (remote fresh guix >> system) >> >> The first guix pull takes from 25 to 50 minutes, which is really long >> time. However, due to irreproducibility, building the guix profile on >> CI doesn't help to cut that time to some manageable numbers. > > Does passing --cores=1 help? I have found building guix (and other guile > packages) on Debian had reproducibility issues frequently triggered by > parallelism. I don't think that hash of the profile depends on the building process itself. And it seems on the same system it returns the same result on consequent rebuilds. It seems something leaks from the environment. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#69284: guix pull is not reproducible
guix pull -C channels-lock.scm produces different profiles on different machines. I executed the same command on a few different machines. channels-lock.scm contains channels list with exact commit specified. --8<---cut here---start->8--- curl https://paste.sr.ht/~abcdw/5f18e9e5cc6cb243c84a3975eb4e6a46ed17d996 > channels-lock.scm guix pull -C channels-lock.scm -p tmp readlink tmp-1-link --8<---cut here---end--->8--- The output log on all machines starts similiar: --8<---cut here---start->8--- Updating channel 'rde' from Git repository at 'https://git.sr.ht/~abcdw/rde'... Authenticating channel 'rde', commits 257cebd to 2a0c7e9 (2304 new commits)... Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to d264237 (69420 new commits)... Building from these channels: guix https://git.savannah.gnu.org/git/guix.git d264237 rde https://git.sr.ht/~abcdw/rde2a0c7e9 --8<---cut here---end--->8--- --8<---cut here---start->8--- Updating channel 'rde' from Git repository at 'https://git.sr.ht/~abcdw/rde'... Authenticating channel 'rde', commits 257cebd to 2a0c7e9 (2,304 new commits)... Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to d264237 (2,382 new commits)... Building from these channels: guix https://git.savannah.gnu.org/git/guix.git d264237 rde https://git.sr.ht/~abcdw/rde2a0c7e9 --8<---cut here---end--->8--- but resulting profile is different: /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile (local fresh guix system) /gnu/store/c2i8iyqkc146ac2hqzy1v6zkqs82xypp-profile (debian 11) /gnu/store/svg0is4iwvlg6mgi2rvpkngcccqcvhys-profile (debian 12) /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile (remote fresh guix system) The first guix pull takes from 25 to 50 minutes, which is really long time. However, due to irreproducibility, building the guix profile on CI doesn't help to cut that time to some manageable numbers. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#66227: [bug#66225] [PATCH v3] gnu: emacs-next-minimal: Apply Guix patches.
On 2023-10-08 08:55, Liliana Marie Prikler wrote: > Am Samstag, dem 07.10.2023 um 09:56 +0400 schrieb Andrew Tropin: >> On 2023-10-06 17:58, Liliana Marie Prikler wrote: >> >> > * gnu/packages/patches/emacs-next-native-comp-driver-options.patch: >> > Add file. >> > * gnu/packages/patches/emacs-next-exec-path.patch: Add file. >> > * gnu/local.mk (dist_patch_DATA): Register them here. >> > * gnu/packages/emacs.scm (emacs-next-minimal)[origin](patches): >> > Include the same patches as emacs-minimal, save for the variants >> > specific to emacs-next introduced above. >> > >> > Co-Authored-By: Nicolas Graves >> > Fixes: ‘emacs-next’ is almost unusable <https://bugs.gnu.org/66227> >> > […] >> >> Hi Liliana and Nicolas, the fixes looks good to me. > Thanks for checking. I pushed it now (perhaps a bit too hasty, but > it's been a problem for some while). Cool! Thank you very much, appreciate your work! -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#66227: [bug#66225] [PATCH v3] gnu: emacs-next-minimal: Apply Guix patches.
ns.patch
> @@ -0,0 +1,18 @@
> +We substitute this anyway, so let's make it easier to substitute.
> +
> +--- a/lisp/emacs-lisp/comp.el
> b/lisp/emacs-lisp/comp.el
> +@@ -203,9 +203,7 @@ and above."
> + :type '(repeat string)
> + :version "28.1")
> +
> +-(defcustom native-comp-driver-options
> +- (cond ((eq system-type 'darwin) '("-Wl,-w"))
> +-((eq system-type 'cygwin) '("-Wl,-dynamicbase")))
> ++(defcustom native-comp-driver-options nil
> + "Options passed verbatim to the native compiler's back-end driver.
> + Note that not all options are meaningful; typically only the options
> + affecting the assembler and linker are likely to be useful.
> +--
> +2.38.0
> +
>
> base-commit: e863274e67e2242b970845783172c9f4e49405ca
Hi Liliana and Nicolas, the fixes looks good to me.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#63047: Can't load glib debug symbols in gdb
On 2023-04-25 08:38, Maxim Cournoyer wrote: > Hi Andrew, > > Josselin Poiret via Bug reports for GNU Guix writes: > >> Hi Andrew, >> >> Andrew Tropin writes: >> >>> I try to run emacs in gdb with debug symbols for some libs available, I >>> succeed with gtk+, but it doesn't work for glib and glibc. It looks >>> strange to me, but maybe I am doing something wrong. >>> >>> Reproducer: >>> >>> guix shell gdb emacs-next-pgtk glibc:debug gtk+:debug glib:debug \ >>> --with-debug-info=glibc --with-debug-info=glib --with-debug-info=gtk+ \ >>> --no-grafts -- gdb .emacs-30.0.50-real >> >> At least for glibc, the glibc that is linked against is the one in (gnu >> packages commencement), which is hidden from the user. The one in (gnu >> packages base), which you can refer to with "glibc" is different. You >> can try to find the proper debug output by looking at `guix size` of >> your store path, then finding out the deriver for glibc with `guix gc >> --derivers` and finally looking at the .drv to find out what the debug >> output should be. >> >> For glib, it might be similar, make sure that you're using exactly the >> right store path for it. > > Perhaps try on the core-updates branch, where glibc no longer has its > symbols stripped. Another thing that can cause the debug symbols to not > be found is grafts, as described in #48907, so when debugging I'd > recommend using --no-grafts for now. Thank you for the tips. For future readers: the core-updates merged, it should be fixed, however, I didn't check if it works now. Closing the issue, but feel free to reopen. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#63797: [PATCH 0/2] fix python-matrix-nio build
On 2023-06-11 22:54, Arjan Adriaanse wrote: > This updates python-matrix-nio which fixes the python-h11 dependency > problem. It also requires updating python-aiofiles. Tested by > successfully building dependent packages. > > Arjan Adriaanse (2): > gnu: python-aiofiles: Update to 23.1.0. > gnu: python-matrix-nio: Update to 0.20.2. > > gnu/packages/matrix.scm | 16 > gnu/packages/python-xyz.scm | 4 ++-- > 2 files changed, 10 insertions(+), 10 deletions(-) > > > base-commit: 74443c30f3e20655a046c0d3ea236822ef130968 Hi Arjan, Thank you for the patches, applied, pushed as https://git.savannah.gnu.org/cgit/guix.git/commit/?id=356c0009d4 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#62287: Ungexp inside vector problem
On 2023-03-20 11:45, Josselin Poiret wrote: > Hi Andrew, > > Andrew Tropin writes: > >> I would expect two last expressions return the same result, but the >> former one doesn't do ungexp: >> >> --8<---cut here---start->8--- >> (define a '(3 4)) >> >> (define b `#(1 2 ,a)) >> >> (eval-with-store >> #~(list '(1 2 #$a))) ;; => ((1 2 (3 4))) >> >> (eval-with-store >> #~(list #(1 2 #$a))) ;; => (#(1 2 (ungexp a))) >> >> (eval-with-store >> #~(list #$b)) ;; => (#(1 2 4)) >> --8<---cut here---end--->8--- >> >> Am I doing/expecting something wrong or there is a bug here? > > It's more related to how the guile reader works, and this is such a > corner case that I don't know whether we should fix. Basically, > anything starting with # is a reader extension, and the next character > identifies which extension it is. #( is the reader extension for > vectors, #~ for gexp and #$ for ungexp. > > To simplify, whenever you use #~, guile will insert (gexp ...) instead, > which is a hygienic macro (not just a procedure!), that will look for > ungexps inside the expression. That traversal is only made on cons > cells though, so it doesn't try to go through any piece of syntax that > is not a cons cell! Since #( doesn't expand to a (vector ...) > cons-cell, the subexpression gets ignored for traversal. > > This is in contrast to another reader extension, #' (for syntax), which > does expand to (syntax ...), and is thus further traversed! > > You can find how both of these reader extensions operate in > . > > I guess the immediate fix is to use (vector ...) rather than #(...). We > could also add code to the gexp traversal to also traverse vectors, but > I am not even sure if they go through the gexp->sexp dance unharmed, and > we also should in principle do that for everything that can get into a > gexp, not just vectors (eg. bytevectors). > Thank you very much for extensive explanation! I have a few tasks related to the guile reader extensions, so when I get my hands dirty with it, I'll probably share my new thoughts and opinions on this topic. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#62948: Using home-ssh-agent-configuration on Ubuntu breaks login
On 2023-04-19 18:28, Janneke Nieuwenhuizen wrote: > Hi, > > Using home-openssh-service-type on Ubuntu 22.10 (OpenSSH_9.3p1, OpenSSL > 1.1.1t 7 Feb 2023) always creates an ~/.ssh/authorized_keys that breaks > key-based login. I cannot access the logs and don't know what the > problem might be. > > When, after running `guix home reconfigure', you do something like: > > --8<---cut here---start->8--- > mv .ssh/authorized_keys .ssh/authorized_keys- > cat .ssh/authorized_keys- > .ssh/authorized_keys > chmod 400 .ssh/authorized_keys > --8<---cut here---end--->8--- > > key-based login succeeds. > > A workaround would be to have home-openssh-service-type leave > ~/.ssh/authorized_keys alone. However, when using > > --8<---cut here---start->8--- > (service > home-openssh-service-type > (home-openssh-configuration >(authorized-keys '( > --8<---cut here---end--->8--- > > any existing ~/.ssh/authorized_keys file is removed and replaced by a > symlink to an empty file. I don't see how that is useful, it certainly > breaks key-based login. > > Using > > --8<---cut here---start->8--- > (service > home-openssh-service-type > (home-openssh-configuration >(authorized-keys #f))) > --8<---cut here---end--->8--- > > yields a backtrace. > > The attached patch fixes that and allows using (authorized-keys #f), > also making this the default. > > WDYT? It make perfect sense. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#59474: Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros
a foreign distro this is > going to cause some disruption when a user switches to Guix Home, or > switches away. > > XDG_LOG_HOME is a non-standard variable. The spec suggests that logs > should go in XDG_STATE_HOME. Why not a establish a GUIX_LOG_HOME > variable instead? (if it ever does become a standard XDG variable, its > default may not be the same one picked by Guix Home, causing the same > issue as above). > > Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to do > -- it is the job of whatever logs the user in. > > XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their defaults > unnecessarily. > > I modified my personal config by unsetting XDG_STATE_HOME, XDG_LOG_HOME, > XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME if Guix Home left > them set to their default values (in the case of XDG_STATE_HOME I unset > it unconditionally). XDG_DATA_DIRS behavior seems reasonable, the problem should be reported to Debian. The work on STATE_HOME is happenning in a separate thread. Closing this ticket. Let us know if you have some other thoughts on the topic. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#63047: Can't load glib debug symbols in gdb
0x76512070 0x76a2df5c Yes (*) /gnu/store/0w390zkxhzhkmyp0sns8z97bfmzbr7gz-librsvg-2.50.7/lib/librsvg-2.so.2 0x762cc200 0x76362d11 Yes (*) /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libm.so.6 0x76dd4370 0x76dd8340 Yes (*) /gnu/store/a38k2v29l6l0iz6pmlk4dmzwdbvl10lq-acl-2.3.1/lib/libacl.so.1 0x76dca3f0 0x76dcd1b1 Yes (*) /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/librt.so.1 0x7626dd20 0x762a636a Yes (*) /gnu/store/8zigz7afvz2rjrvrh7zq1d389qbl2684-dbus-1.12.20/lib/libdbus-1.so.3 0x76122bd0 0x762068ce Yes (*) /gnu/store/g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12/lib/libxml2.so.2 0x76097cc0 0x760d13e8 Yes (*) /gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619/lib/libncursesw.so.6 0x76052f80 0x76071dd1 Yes (*) /gnu/store/3hmh0srgky1a621rzaxf98qvr0p9r1dv-libselinux-3.4/lib/libselinux.so.1 0x75fa79c0 0x76018c0d Yes (*) /gnu/store/ak70pk2hjks17cx7zjdmdmzpcpiy9gpi-freetype-2.10.4/lib/libfreetype.so.6 0x75f577a0 0x75f7d05a Yes (*) /gnu/store/3r5sl1l02kjxzw3gicjpjz4kw6v4rgs9-fontconfig-minimal-2.13.94/lib/libfontconfig.so.1 0x75f38230 0x75f49380 Yes (*) /gnu/store/64ic06l5pd78n7blzikqzfnnp0xp5msd-libotf-0.9.16/lib/libotf.so.1 0x75d76940 0x75e89670 Yes (*) /gnu/store/zl9wf0zwq2ka9rpmayp53hnp2mn460xf-gnutls-3.7.2/lib/libgnutls.so.30 0x75d22540 0x75d2fba1 Yes (*) /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0 0x75d17200 0x75d18301 Yes (*) /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libanl.so.1 0x75cc3280 0x75cf9bfa Yes (*) /gnu/store/0dhvl2lvb7gsrbjf5jq5pd7hdvznsazz-lcms-2.12/lib/liblcms2.so.2 0x75cb2130 0x75cb2f31 Yes (*) /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libdl.so.2 0x75c1b830 0x75c8537c Yes (*) /gnu/store/v3hqc5i1jqi0s04zxvi465bihrgb1sq1-elogind-246.10/lib/libelogind.so.0 0x75bfb1f0 0x75c02f2b Yes (*) /gnu/store/nprljhh7a86351vg6h23va3kfdnkwnd4-jansson-2.13.1/lib/libjansson.so.4 0x75b6d440 0x75bde0ab Yes (*) /gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1/lib/libgmp.so.10 0x74219c50 0x7508025e Yes (*) /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0/lib/libgccjit.so.0 0x75b2e8c0 0x75b51e83 Yes (*) /gnu/store/cbviswij2rbqnbsc889166wm7ri5pc2r-tree-sitter-0.20.7/lib/libtree-sitter.so.0 0x73ed5ca0 0x73fc4c36 Yes (*) /gnu/store/xmzx5mzv4863yw9kmr2ykndgp37p8if0-sqlite-3.36.0/lib/libsqlite3.so.0 0x75b12310 0x75b22b1d Yes (*) /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgcc_s.so.1 0x73d25330 0x73e64389 Yes (*) /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6 0x75b09100 0x75b099ec Yes (*) /gnu/store/6h8skg2n4gpbi0bwfmw6qyh03phic6dm-libxinerama-1.1.4/lib/libXinerama.so.1 ... (*): Shared library is missing debugging information. --8<---cut here---end--->8--- My .gdbinit: --8<---cut here---start->8--- # Tell GDB where to look for separate debugging files. guile (use-modules (gdb)) (execute (string-append "set debug-file-directory " (string-join (if (getenv "GDB_DEBUG_FILE_DIRECTORY") (list (getenv "GDB_DEBUG_FILE_DIRECTORY")) '()) ":"))) end # Authorize extensions found in the store, such as the # pretty-printers of libstdc++. set auto-load safe-path / # /gnu/store/*/lib set history filename ~/.cache/gdb_history set history save on --8<---cut here---end--->8--- -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53700: Guix package is hardcoded in guix home
On 2022-03-02 12:06, Ludovic Courtès wrote: > Hi, > > Gordon Quad skribis: > >> guix home uses guix package directly imported from (gnu packages >> package-management) gnu/home/services.scm:22 >> >> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n22 >> >> It looks like for now it is used only here gnu/home/services.scm:283 >> >> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n284 >> >> It is quite unfortunte to see guix home to pull whole extra copy of guix >> only to use few files to do gettext localization init. > > Yes, it’s a bit heavy-handed. > >> If would be nice to be able to customize guix package used there so I >> can make sure guix used by guix home is the same as in my guix daemon. > > I’m not sure I understand. As you write, the ‘guix’ package is used in > (gnu home services) only to get gettext catalogs; AFAICS it’s not used > for anything else. > > Could you clarify what you had in mind? I was hit by this one yesterday as well. I tried to manage just a few config files with Guix Home on foreign distro, but it started to download 46 megabytes of guix package, while I expected it to work completely offline. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#58606: Emacs next pgtk crashes when pasting to other app
On 2022-10-18 10:52, Andrew Tropin wrote: > Recently discovered a problem, which reproduces this way: > - Open a new emacs instance. > - Yank anything with M-w or select with mouse. > - Paste yanked text to chromium/icecat. > > Both browser and emacs are hanging up for a while and after that Emacs > crashes with: > > --8<---cut here---start->8--- > Fatal error 11: Segmentation fault > --8<---cut here---end--->8--- > > sway, emacs-next-pgtk, ungoogled-chromium > > --8<---cut here---start->8--- > Generation 75 Oct 17 2022 15:54:07(current) > rde 05225a3 > repository URL: https://git.sr.ht/~abcdw/rde > branch: master > commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1 > guix 3ab1438 > repository URL: file:///home/bob/work/gnu/guix > branch: master > commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17 > --8<---cut here---end--->8--- Reported to bug-gnu-emacs: https://yhetil.org/emacs-bugs/877cvbiuf9@trop.in/ -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#62287: Ungexp inside vector problem
I would expect two last expressions return the same result, but the former one doesn't do ungexp: --8<---cut here---start->8--- (define a '(3 4)) (define b `#(1 2 ,a)) (eval-with-store #~(list '(1 2 #$a))) ;; => ((1 2 (3 4))) (eval-with-store #~(list #(1 2 #$a))) ;; => (#(1 2 (ungexp a))) (eval-with-store #~(list #$b)) ;; => (#(1 2 4)) --8<---cut here---end--->8--- Am I doing/expecting something wrong or there is a bug here? -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#61343: bug#61574: [PATCH v2] scripts: repl: Extend REPL %load-path with all channels.
On 2023-02-27 15:01, Ludovic Courtès wrote: > Hi Simon, > > Simon Tournier skribis: > >> Fixes <https://bugs.gnu.org/61343>. >> Reported by 宋文武 . >> >> * guix/scripts/repl.scm (define-command): Before starting the REPL, >> run (current-profile) which makes available all channels. > > [...] > >> +++ b/guix/scripts/repl.scm >> @@ -211,6 +211,7 @@ (define script >>((guile) >> (save-module-excursion >> (lambda () >> + (current-profile) ;Run (%package-module-path) as >> explained above. > > I tweaked the comment :-) and applied. > > Thanks! Hi Simon and Ludo! Thank you for the patch, I also faced this problem and it seems this change doesn't fix it. echo '(use-modules (rde features))' | guix repl /dev/stdin still fails on a7763e067d86908210758aab80d33e4f8b815b1c. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#61717: guix home reconfigure on a fresh system fails
On 2023-02-22 16:40, w...@wolfsden.cz wrote: > Hi, > > I'm trying to setup a Guix machine. I did clean install using guix system > init, > I can provide the config, but it does not seem to be relevant. After that I > decided to try the guix home reconfigure command, and it ended with: > > guix home: error: while creating directory > `/var/guix/profiles/per-user/wolf': Permission denied > hint: Please create the `/var/guix/profiles/per-user/wolf' directory, > with you as the owner. > > The workaround I used was to just install any random package: > > guix install coreutils > guix remove coreutils > > After that running > > guix home reconfigure config.scm > > started to work just fine. However that does not seem like proper way, but > more > like a workaround. I was adviced on IRC to report it, so here I am. > > W. This happens because of this call, which can't create a directory in root owned /var/guix/profiles: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/home.scm?h=2c757e8fb4385f889ec91f02b77acdf27143c316#n476 1. Actually, this call is usually unecessary as the creation of directory for per-user profiles handled by daemon. https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/local-store.cc?h=2c757e8fb4385f889ec91f02b77acdf27143c316#n1613 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37744 2. However, in some circumstances (when used custom $GUIX_STATE_DIRECTORY) daemon doesn't handle this properly, so probably because of it this line was added: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0f6a27c2c4 I moved it to a place, where connection to store is already openned, so it work in both scenarios (first one is covered by the daemon, second one by this call). https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e615aaca28 Ideally, it would be cool to fix on the daemon side and remove this call at all. CCed Ludo, Tobias, Oleg. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56669: enhancement: Link guix system and guix home
On 2022-07-26 12:23, Andrew Tropin wrote:
> On 2022-07-21 19:25, Maxime Devos wrote:
>
>> On 21-07-2022 19:13, Andrew Tropin wrote:
>>
>>> The source code is here:
>>> https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9
>>
>> What's the 'guix-home-gc-roots' for? I would expect the reference
>> #$(file-append he "/activate") to be sufficient to keep things from
>> being gc'ed.
>
> It was needed while I was testing manual activation without shepherd
> service, not needed anymore, already removed it locally.
>
>>
>>> +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-23>
>>>
>>> (start #~(make-forkexec-constructor +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-24>
>>>
>>> '(#$(file-append he "/activate")) +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-25>
>>>
>>> #:user #$user +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-26>
>>>
>>> #:environment-variables +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-27>
>>>
>>> (list (string-append "HOME=" (passwd:dir (getpw #$user +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-28>
>>>
>>> #:group (group:name (getgrgid (passwd:gid (getpw #$user))
>> I'm wondering if GUIX_LOCPATH is needed as well. Anyway, if not done
>> already internally by /activate, you could consider doing it in a
>> container to reduce potential irreproducibility, or insecurity on
>> multi-user systems (I'd assume the #:user + #:group to be sufficient for
>> security, especially if it appears sufficient for other system services,
>> but I'm not some expert on what things need to be set).
>>
> It's not set by /activate.
>
>>> +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-20>
>>>
>>> (provision (list (symbol-append 'guix-home- (string->symbol user +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-21>
>>>
>>> (one-shot? #t) +
>>> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-22>
>>>
>>> (auto-start? #f)
>> Wouldn't it then be possible for the user to login via the login manager
>> before initialisation has completed, as gdm etc don't wait for
>> guix-home-... currently?
>
> You are right, the same as the first one, needed for more manual
> approach, changed to #t, thank you.
>
> Three patches for this service to work is on the way on guix-patches.
> In the meantime, will try to build livecd with the home environment
> inside.
>
> P.S. Probably this system service is far from final version of this
> feature, I still think about making home-environment a part of
> user-account. Will evaluate pros and cons, after I get livecd built
> successfully.
Sorry for the long status update, some life moments are happened.
Polished all the things on Guix Home side and I can confirm that the
service works correctly and it's possible to make home-environments a
part of operating-system record.
Current very simple implementation works relatively good. It accepts a
list of ("user" . home-env) pairs and creates a shepherd services, which
activate respective home environments.
https://git.sr.ht/~abcdw/rde/tree/9175c7b37b6861095bae4a696aa1faadf9dc572a/src/gnu/services/home.scm#L1
This is how sway graphical environment activation is implemented in rde-live
image.
http://files.trop.in/rde/
I still find it not completely satisfying because activation happens
when one-shot shepherd service get started and not during system
activation, which leads to the problem mentioned by Maxim: you can login
into user's shell before home-environment activated. I would like to
just extend system activation with calls to home activation scripts, but
it's not that straightforward because we depend on user-homes (which is
a shepherd service).
That said the guix-home system service works fine and you can already
use it, but before merging it to Guix I would like to move home
activations into system activation, which requires some work on
user-homes. It doesn't seem to be a big task, but still require some
dedication and IDK when I get spare time for it. Let me know if this
feature blocks you in some way, otherwise I'll keep working on it in my
own pace.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#58290: guile ssh error on guix deploy
On 2023-01-23 22:50, Ludovic Courtès wrote: > Hi Artyom, > > "Artyom V. Poptsov" skribis: > >> I figured out how to fix Guile-SSH channel "leak", so to say, that lead >> to the OpenSSH "no more sessions" problem. >> >> Please run your tests with this branch and let me know if it works for >> you (including all the edge cases): >> https://github.com/artyom-poptsov/guile-ssh/tree/wip-fix-channel-leak > > It works! Specifically, I ran: > > guix shell guile guile-ssh \ > --with-branch=guile-ssh=wip-fix-channel-leak -- \ > guile ssh-channels.scm > > and the script (same one as before) ran several hundreds of iterations > just fine. Can confirm the same, works on my machine :) Thank you very much. > > I had looked at ‘ptob_close’ and related code but didn’t see this issue; > good catch! > > If you plan to push a new release, we’ll just upgrade in Guix; otherwise > we can apply the patch locally. > > Thank you! > > Ludo’. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#60688: guix: home: environment-variables: Breaking change 73684dc90
yhetil mirror is a little behind and I've not received this email thread yet and thus it's not in my guix-home notmuch search. A few minutes ago I saw you forwarded this thread to me and patches look good, but I already made and pushed similiar changes. Sorry for inconvenience. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#59474: Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros
On 2022-11-22 08:09, Liliana Marie Prikler wrote: > Am Montag, dem 21.11.2022 um 22:02 -0800 schrieb Matt Armstrong: >> The first thing I see is that $HOME/.guix-home/seutp-environment is >> modifying various XDG_ variables incorrectly. It prepends new values >> without honor the variable's default value if it doesn't happen to be >> set already. > This is a known problem with Debian. Unlike Ubuntu, which relies on > Flatpak and Snaps for its basic operations, Debian doesn't and hence > hasn't set up these variables explicitly. Note that this isn't unique > to Guix Home or even just Guix. > >> For example, if XDG_DATA_DIRS is not set its default value is >> "/usr/local/share/:/usr/share/". > None of these directories exist in Guix System. Assuming them would be > a fault. Note that the install script you're meant to use already > initializes these variables since July [1]. > I understand the inconvinience, but not sure that it has to be fixed on Guix Home side. According to the specification it's a fallback value not a default value. --8<---cut here---start->8--- If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used. --8<---cut here---end--->8--- XDG_DATA_DIRS is not empty in our case and hence /usr/local/share and /usr/share doesn't have to be used. If it's critical for operation it should be set before ~/.guix-home/setup-environment called, I would say it looks like a debian bug, not Guix Home. They same thing is true for XDG_CONFIG_DIRS. >> XDG_STATE_HOME is set to a non-standard value. In the current XDG >> Base Directory Specification it defaults to "$HOME/.local/state", but >> Guix Home sets it to "$HOME/.local/var/lib". > This is a genuine bug with Guix Home. > >> XDG_LOG_HOME is a non-standard variable. The spec suggests that logs >> should go in XDG_STATE_HOME. Why not a establish a GUIX_LOG_HOME >> variable instead? (if it ever does become a standard XDG variable, >> its default may not be the same one picked by Guix Home, causing the >> same issue as above). > Another genuine bug with Guix Home, although the variable does predate > our support for XDG_STATE_HOME. I suggest finding all uses of this > variable in Guix Home and replacing them accordingly. > XDG_STATE_HOME and XDG_LOG_HOME apppeared in Guix Home before they were described in xdg base directory specification, so the values was picked to mimic FHS. Probably they should be adjusted to the values defined in specification. >> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to >> do -- it is the job of whatever logs the user in. > I'm unsure about that one. > If it's set by elogind or whatever - cool, we will use value provided, if not we explicitly set it, looks ok to me. >> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their >> defaults unnecessarily. > Explicit is better than implicit. > > Cheers > > > [1] > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=23aafc800c9e678662766440916449ec5bbce830 > > > > -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#58606: Emacs next pgtk crashes when pasting to other app
On 2022-11-16 10:34, Joshua Branson wrote: > Declan Tsien writes: > >> Andrew Tropin writes: >> >>> Recently discovered a problem, which reproduces this way: >>> - Open a new emacs instance. >>> - Yank anything with M-w or select with mouse. >>> - Paste yanked text to chromium/icecat. >>> >>> Both browser and emacs are hanging up for a while and after that Emacs >>> crashes with: >> > > I just discovered today, that I can copy text from emacs and paste that > text into firefox. It seems to no longer be an issue for me. :) I built a latest emacs from master: https://git.sr.ht/~abcdw/rde/commit/b03373920c1cc7d8d4b2d64c96f72eed9bb3651a And it is affected by this issue, so I made a quick and dirty workaround: https://git.sr.ht/~abcdw/rde/commit/b6aef2d8b34d1166f33629b4b3a1a0f5751f90f9 Unfortunately, I don't see an easy way to backport this fix to Guix. Probably, this issues should be reported to bug-gnu-emacs. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#58290: guile ssh error on guix deploy
la sshd[26115]: debug1: channel 9: free: server-session, > nchannels 1 > Nov 3 21:50:28 capella sshd[26115]: debug1: do_cleanup > > I compared this with a successful deploy: > > Nov 3 21:44:22 capella sshd[25842]: debug1: permanently_set_uid: 0/0 > Nov 3 21:46:25 capella sshd[25612]: debug1: Received SIGCHLD. > Nov 3 21:46:25 capella sshd[25612]: debug1: session_by_pid: pid 25842 > Nov 3 21:46:25 capella sshd[25612]: debug1: session_exit_message: session 6 > channel 6 pid 25842 > Nov 3 21:46:25 capella sshd[25612]: debug1: session_exit_message: release > channel 6 > Nov 3 21:46:26 capella sshd[25612]: debug1: server_input_channel_open: ctype > session rchan 65 win 64000 max 32768 > Nov 3 21:46:26 capella sshd[25612]: debug1: input_session_request > Nov 3 21:46:26 capella sshd[25612]: debug1: channel 0: new [server-session] > Nov 3 21:46:26 capella sshd[25612]: debug1: session_new: session 0 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_open: channel 0 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_open: session 0: link > with channel 0 > Nov 3 21:46:26 capella sshd[25612]: debug1: server_input_channel_open: > confirm session > Nov 3 21:46:26 capella sshd[25612]: debug1: server_input_channel_req: > channel 0 request exec reply 1 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_by_channel: session 0 > channel 0 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_input_channel_req: > session 0 req exec > Nov 3 21:46:26 capella sshd[26032]: debug1: PAM: reinitializing credentials > Nov 3 21:46:26 capella sshd[26032]: debug1: permanently_set_uid: 0/0 > Nov 3 21:46:26 capella sshd[25612]: debug1: server_input_channel_open: ctype > session rchan 66 win 64000 max 32768 > Nov 3 21:46:26 capella sshd[25612]: debug1: input_session_request > Nov 3 21:46:26 capella sshd[25612]: debug1: channel 8: new [server-session] > Nov 3 21:46:26 capella sshd[25612]: debug1: session_new: session 8 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_open: channel 8 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_open: session 8: link > with channel 8 > Nov 3 21:46:26 capella sshd[25612]: debug1: server_input_channel_open: > confirm session > Nov 3 21:46:26 capella sshd[25612]: debug1: server_input_channel_req: > channel 8 request exec reply 1 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_by_channel: session 8 > channel 8 > Nov 3 21:46:26 capella sshd[25612]: debug1: session_input_channel_req: > session 8 req exec > Nov 3 21:46:26 capella sshd[26043]: debug1: PAM: reinitializing credentials > Nov 3 21:46:26 capella sshd[26043]: debug1: permanently_set_uid: 0/0 > Nov 3 21:46:28 capella sshd[25612]: debug1: chan_shutdown_extended_read: > channel 8: (i0 o3 sock -1 wfd -1 efd 13 [read]) > Nov 3 21:46:28 capella sshd[25612]: debug1: server_input_channel_open: ctype > session rchan 67 win 64000 max 32768 > Nov 3 21:46:28 capella sshd[25612]: debug1: input_session_request > Nov 3 21:46:28 capella sshd[25612]: debug1: channel 9: new [server-session] > Nov 3 21:46:28 capella sshd[25612]: debug1: session_new: session 9 > [... more channels and stuffs before graceful shutdown ...] > > I believe the two-minute window before SIGCHLD is waiting for some > Shepherd services to time out (long story..!). > > In my current tests the failure always occur at the > very end of deploy: > > building > /gnu/store/19yajyzw4jhnkkz9w0l9gm4az0jxihkc-install-bootloader.scm.drv... > building /gnu/store/m7ngq5gszyswm6sficinz7ghpra30dl4-remote-exp.scm.drv... > ;;; [2022/11/03 21:50:28.892606, 0] [GSSH ERROR] Channel opening failure: > channel 66 error (2) open failed: # 7fdefb015e80> > > What's interesting is that all of the failed deploys fail to open > "channel 10", whereas successful deploys never reach it. All of these > are deploying the exact same configuration and commit, so the SSH > traffic should nearly identical. > > I have attached the transcripts of each session (by grepping the PIDs > from /var/log/debug). Grepping for session_open yields some > inconstencies, but haven't studied them in detail yet. > >>> Due to the number of SSH connections made by deploy and frequent >>> occurence of this problem, I was not able to successfully deploy through >>> many attempts. >> >> Ouch. Normally, thanks to memoization, ‘guix deploy’ opens only one >> session per machine. (I think it works well with the 25 local build >> machines behind berlin; it’s also fine for a small set of machines I >> take care of at work.) > > Have they been rebooted since the switch to inetd-style sshd? It fails > more often than not for me. > >>> I found that removing the memoizing open-machine-ssh-session* in >>> (gnu machine ssh) works around it and can happily deploy again. >>> >>> (that is, just use 'open-machine-ssh-session' instead) >> >> Interesting. That gives us a hint. Could you add a ‘pk’ in >> ‘open-machine-ssh-session*’ to see how many connections it opens? > > Indeed it only opens a single connection. The problem seems to be > with multiple "channels" and "sessions" over a single connection. > Very detailed report, thank you for digging in! CCed Artyom Poptsov, author of Guile-SSH. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#58606: Emacs next pgtk crashes when pasting to other app
On 2022-10-18 10:52, Andrew Tropin wrote: > Recently discovered a problem, which reproduces this way: > - Open a new emacs instance. > - Yank anything with M-w or select with mouse. > - Paste yanked text to chromium/icecat. > > Both browser and emacs are hanging up for a while and after that Emacs > crashes with: > > --8<---cut here---start->8--- > Fatal error 11: Segmentation fault > --8<---cut here---end--->8--- > > sway, emacs-next-pgtk, ungoogled-chromium > > --8<---cut here---start->8--- > Generation 75 Oct 17 2022 15:54:07(current) > rde 05225a3 > repository URL: https://git.sr.ht/~abcdw/rde > branch: master > commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1 > guix 3ab1438 > repository URL: file:///home/bob/work/gnu/guix > branch: master > commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17 > --8<---cut here---end--->8--- A little more info: --8<---cut here---start->8--- Fatal error 11: Segmentation fault Backtrace: /home/bob/.guix-home/profile/bin/emacs[0x530c7e] /home/bob/.guix-home/profile/bin/emacs[0x42645c] /home/bob/.guix-home/profile/bin/emacs[0x42694b] /home/bob/.guix-home/profile/bin/emacs[0x52f1f8] /home/bob/.guix-home/profile/bin/emacs[0x52f269] /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0(+0x11d80)[0x7f7850c45d80] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(+0x27424)[0x7f7857ad4424] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit_valist+0xbeb)[0x7f7857ada21b] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f7857ada722] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(+0x19884)[0x7f7857ac6884] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_object_notify_by_pspec+0xe4)[0x7f7857ac8834] /gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(+0x3afbcd)[0x7f7858470bcd] /gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(+0x3de357)[0x7f785849f357] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_closure_invoke+0x16f)[0x7f7857ac24af] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(+0x269e9)[0x7f7857ad39e9] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x735)[0x7f7857ad9d65] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f7857ada722] /gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(+0x38ac04)[0x7f785844bc04] /gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(gtk_main_do_event+0x6ea)[0x7f785830c37a] /gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgdk-3.so.0(+0x3d3c5)[0x7f7857ff93c5] /gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgdk-3.so.0(+0x9a352)[0x7f7858056352] /gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libglib-2.0.so.0(g_main_context_dispatch+0x23b)[0x7f78579ce4cb] /home/bob/.guix-home/profile/bin/emacs[0x64ade8] /home/bob/.guix-home/profile/bin/emacs[0x518482] /home/bob/.guix-home/profile/bin/emacs[0x5188a5] /home/bob/.guix-home/profile/bin/emacs[0x519758] /home/bob/.guix-home/profile/bin/emacs[0x519c95] /home/bob/.guix-home/profile/bin/emacs[0x519e58] /home/bob/.guix-home/profile/bin/emacs[0x51ebd8] /home/bob/.guix-home/profile/bin/emacs[0x5f5dd8] /home/bob/.guix-home/profile/bin/emacs[0x51a3b6] /home/bob/.guix-home/profile/bin/emacs[0x51fcc3] /home/bob/.guix-home/profile/bin/emacs[0x52200d] /home/bob/.guix-home/profile/bin/emacs[0x523c32] /home/bob/.guix-home/profile/bin/emacs[0x598b07] /home/bob/.guix-home/profile/bin/emacs[0x50fe9a] /home/bob/.guix-home/profile/bin/emacs[0x598a61] /home/bob/.guix-home/profile/bin/emacs[0x50fe3f] /home/bob/.guix-home/profile/bin/emacs[0x516c83] /home/bob/.guix-home/profile/bin/emacs[0x516ffa] /home/bob/.guix-home/profile/bin/emacs[0x42f32a] --8<---cut here---end--->8--- -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#57844: Shepherd fails to start in user session ~50% of the time
On 2022-10-20 23:44, Ludovic Courtès wrote: > Hi, > > Andrew Tropin skribis: > >> Yes, I don't remember if I created a thread on that (probably not) or >> just discussed it in some chat, but when shepherd stops it doesn't clean >> up its socket file, so you can't start shepherd again until manually >> remove socket. > > Right, but in the context of Guix Home, it should be started only once > anyway, right? Right. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#57844: Shepherd fails to start in user session ~50% of the time
On 2022-10-19 18:21, Ludovic Courtès wrote: > Hi, > > Andrew, does the bug report below ring a bell? > Yes, I don't remember if I created a thread on that (probably not) or just discussed it in some chat, but when shepherd stops it doesn't clean up its socket file, so you can't start shepherd again until manually remove socket. Checked it right now: --8<---cut here---start->8--- herd stop root shepherd # fails with Address already in use --8<---cut here---end--->8--- I found it out, when was experimenting with the place, where I start shepherd https://issues.guix.gnu.org/57692. To inherit graphical environment variables I start it by sway compositor, not login shell and if in addition to sway session I login on another tty, elogind won't remove XDG_RUNTIME_DIR => shepherd/socket is not removed => shepherd fails to start after sway restart. > https://issues.guix.gnu.org/57844 > > (I haven’t hit that problem myself.) > > Ludo’. > > Tom Willemse skribis: > >> Hi Guix! >> >> I've been using Guix on Archlinux for a little while now, and ever since >> I've started using Guix Home on my laptop to start up user-level >> services I've been having the issue that about 50% of the time when I >> boot my laptop shepherd fails to start. >> >> My .xsession-errors says: >> >>> shepherd: while opening socket '/run/user/1000/shepherd/socket': bind: >>> Address already in use >> >> and looking at my shepherd log: >> >>> 2022-09-15 11:47:18 Service root has been started. >>> 2022-09-15 11:47:18 Service root has been started. >>> 2022-09-15 11:47:19 Starting services... >>> 2022-09-15 11:47:19 Starting services... >>> 2022-09-15 11:47:19 Exiting shepherd... >>> 2022-09-15 11:47:19 Service dunst has been started. >>> 2022-09-15 11:47:19 Service unclutter has been started. >>> 2022-09-15 11:47:19 Service syncthing has been started. >>> 2022-09-15 11:47:19 Service polybar has been started. >>> 2022-09-15 11:47:19 Service cmst has been started. >>> 2022-09-15 11:47:19 Service kdeconnect has been started. >>> 2022-09-15 11:47:20 Service xbindkeys has been started. >>> 2022-09-15 11:47:20 Service picom has been started. >>> 2022-09-15 11:47:20 Service xmodmap has been started. >>> 2022-09-15 11:47:20 Service redshift has been started. >>> 2022-09-15 11:47:20 Exiting shepherd... >>> 2022-09-15 11:47:20 Service syncthing has been stopped. >>> 2022-09-15 11:47:20 Service xbindkeys has been stopped. >>> 2022-09-15 11:47:20 Service redshift has been stopped. >>> 2022-09-15 11:47:20 Service cmst has been stopped. >>> 2022-09-15 11:47:20 Service kdeconnect has been stopped. >>> 2022-09-15 11:47:20 Service polybar has been stopped. >>> 2022-09-15 11:47:20 Service dunst has been stopped. >>> 2022-09-15 11:47:20 Service picom has been stopped. >>> 2022-09-15 11:47:20 Service unclutter has been stopped. >>> 2022-09-15 11:47:20 Exiting. >> >> It looks like it starts twice and then exits both, but I'm not sure why. >> I'm guessing it's the ~/.guix-home/activate and >> ~/.guix-home/on-first-login that are trying to start it. ~/.guix-home/activate should be launched only by guix home reconfigure, so it shouldn't be touched during startup of the session at all, also they both have a condition, which must prevent the start of shepherd if socket exists. https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=883fb8f41b08a8455f16c736a83fb1ae8a3df0a1#n105 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=883fb8f41b08a8455f16c736a83fb1ae8a3df0a1#n131 Tom, can you show your startup scripts, please (like xsession or whatever you use for starting graphical environment)? Sharing home environment config can be useful as well. Do you use some display/login manager? >> >> I'm not sure what other information I can provide you that will help, so >> please let me know! >> -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#54354: [BUG] guix home: on foreign distro, ~/.bash_profile is not initialized
On 2022-03-20 14:09, florhizome wrote: > Hi Liliana, > > Hm, well it doesn't seem like the exact same issue, but that thread is > helpful. Could systemd/logind be made to use bash for login? Login shell is usually controlled by /etc/passwd, so it shouldn't inerfer with systemd, elogind. > For now I thought maybe I can just write shepherd services to do > that stuff for me, to stay in guix homes framework. But shepherd seems > to have a problem starting up: > > /gnu/store/y85vzni5yc6lcb7qqhmlkifis9nzmm5l-shepherd.conf wird geladen. > herd: Ausnahmefehler während der Ausführung von »load« mit dem Dienst »root«: > In procedure fport_write: Eingabe-/Ausgabefehler > > If you don't speak german, that roughly translates to: > > loading /gnu/store/...-shepherd.conf > herd: exception error during the execution of <> with the service > <>: > In procedure fport_write: i/o error > > I got the same error when reconfiguring with two differing simple > service configurations (just start a program from a package) passed to > shepherd. > In anyway I think it would be good to add to guix home's documentation that > some features might not work > due to the login system of a foreign distro if we are sure of that? > There were a few fixes related to shepherd service, which probably fixes it. Can you confirm this? Or issue is still valid? Is the whole issue 54354 still valid? -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#58606: Emacs next pgtk crashes when pasting to other app
Recently discovered a problem, which reproduces this way: - Open a new emacs instance. - Yank anything with M-w or select with mouse. - Paste yanked text to chromium/icecat. Both browser and emacs are hanging up for a while and after that Emacs crashes with: --8<---cut here---start->8--- Fatal error 11: Segmentation fault --8<---cut here---end--->8--- sway, emacs-next-pgtk, ungoogled-chromium --8<---cut here---start->8--- Generation 75 Oct 17 2022 15:54:07(current) rde 05225a3 repository URL: https://git.sr.ht/~abcdw/rde branch: master commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1 guix 3ab1438 repository URL: file:///home/bob/work/gnu/guix branch: master commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17 --8<---cut here---end--->8--- -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#58290: guile ssh error on guix deploy
On 2022-10-08 14:39, Ludovic Courtès wrote:
> Hi!
>
> Andrew Tropin skribis:
>
>> From time to time I get the following error, the only thing I change is
>> IPv6 config in static-networking service. Sometimes it fails, but after
>> a few more attempts with the same config it deploys sucessfully.
>>
>> -*- mode: compilation; default-directory: "~/work/abcdw/trop.in/" -*-
>> Compilation started at Tue Oct 4 14:19:46
>>
>> make -k deploy-pinky
>> guix deploy ./guix/pinky.scm
>
> [...]
>
>> In guix/ssh.scm:
>> 376:2 7 (send-files # _ # …)
>> 222:5 6 (remote-run (begin (use-modules (guix) (srfi #) # #) …) #)
>> In ssh/popen.scm:
>> 64:4 5 (open-remote-pipe* _ "r+" _ . _)
>> In unknown file:
>>4 (channel-open-session #)
>> In ice-9/boot-9.scm:
>> 1685:16 3 (raise-exception _ #:continuable? _)
>> 1683:16 2 (raise-exception _ #:continuable? _)
>> 1685:16 1 (raise-exception _ #:continuable? _)
>> 1685:16 0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel
>> opening failure: channel 67 error (2) open failed" #> (closed) 7f7d1af9e140> #f)'.
>
> Are there any hints from sshd in the /var/log/messages of that machine
> as to why the connection was closed?
--8<---cut here---start->8---
bob@pinky /var/log$ zcat messages.1.gz | grep "Oct 4" | grep ssh
Oct 4 05:57:09 localhost shepherd[1]: Service sshd-380 has been started.
Oct 4 05:57:11 localhost sshd[15950]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 54710 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:34:17 localhost shepherd[1]: Service sshd-381 has been started.
Oct 4 06:34:19 localhost sshd[15958]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 57064 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:36:55 localhost shepherd[1]: Service sshd-382 has been started.
Oct 4 06:36:57 localhost sshd[15991]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 41088 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:37:30 localhost shepherd[1]: Service sshd-383 has been started.
Oct 4 06:37:33 localhost sshd[16031]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 56148 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:43:39 localhost shepherd[1]: 3 connections still in use after
sshd-382 termination.
Oct 4 06:43:39 localhost shepherd[1]: Service sshd-382 (PID 15991) exited with
255.
Oct 4 06:43:39 localhost shepherd[1]: Service sshd-382 has been disabled.
Oct 4 06:43:39 localhost shepherd[1]: Transient service sshd-382 terminated,
now unregistered.
Oct 4 06:43:41 localhost shepherd[1]: Service sshd-384 has been started.
Oct 4 06:43:42 localhost sshd[16166]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 36040 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:43:49 localhost shepherd[1]: 3 connections still in use after
sshd-384 termination.
Oct 4 06:43:49 localhost shepherd[1]: Service sshd-384 has been disabled.
Oct 4 06:43:49 localhost shepherd[1]: Transient service sshd-384 terminated,
now unregistered.
Oct 4 06:48:58 localhost shepherd[1]: Service sshd-385 has been started.
Oct 4 06:49:00 localhost sshd[16205]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 34134 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:52:05 localhost shepherd[1]: Service sshd-386 has been started.
Oct 4 06:52:06 localhost sshd[16212]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 55922 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:53:02 localhost shepherd[1]: 4 connections still in use after
sshd-386 termination.
Oct 4 06:53:02 localhost shepherd[1]: Service sshd-386 has been disabled.
Oct 4 06:53:02 localhost shepherd[1]: Transient service sshd-386 terminated,
now unregistered.
Oct 4 06:53:03 localhost shepherd[1]: Service sshd-387 has been started.
Oct 4 06:53:04 localhost sshd[16370]: Accepted publickey for bob from
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 50604 ssh2: RSA
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct 4 06:53:11 localhost shepherd[1]: 4 connections still in use after
sshd-387 termination.
Oct 4 06:53:11 localhost shepherd[1]: Service sshd-387 has been disabled.
Oct 4 06:53:11 localhost shepherd[1]: Transient service sshd-387 terminated,
now unregistered.
Oct 4 06:54:25 localhost shepherd[1]: Service ssh-da
bug#58290: guile ssh error on guix deploy
From time to time I get the following error, the only thing I change is
IPv6 config in static-networking service. Sometimes it fails, but after
a few more attempts with the same config it deploys sucessfully.
--8<---cut here---start->8---
-*- mode: compilation; default-directory: "~/work/abcdw/trop.in/" -*-
Compilation started at Tue Oct 4 14:19:46
make -k deploy-pinky
guix deploy ./guix/pinky.scm
The following 1 machine will be deployed:
pinky
guix deploy: deploying to pinky...
guix deploy: sending 0 store items (0 MiB) to '23.137.249.202'...
guix deploy: sending 0 store items (0 MiB) to '23.137.249.202'...
substitute: updating substitutes from 'https://substitutes.nonguix.org'...
100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'http://ci.guix.trop.in'... 100.0%
The following derivations will be built:
/gnu/store/yzilvx4jr4s7174f6azxxbb5c24311xc-remote-exp.scm.drv
/gnu/store/sqlbbg5z19h2ww86p8nzhfbnidsm5sag-switch-to-system.scm.drv
/gnu/store/ayssizgz8i4mnk6p2yhilqgzwim4ql7j-system.drv
/gnu/store/9fxf3gcgi07hg5nmhjvnvlhk6829h304-provenance.drv
/gnu/store/djs7vabv5wr3inz3pva87wfw7ya10ajq-boot.drv
/gnu/store/smmzsd1b9v4qmncvl0pl6f0nrasp39ks-activate.scm.drv
/gnu/store/5hpm7v0xnqqilhj7qdg66cjkf8dvkimx-activate-service.scm.drv
/gnu/store/g62yd6a8wd081w0y4jji83dbcxhiks3i-etc.drv
building /gnu/store/9fxf3gcgi07hg5nmhjvnvlhk6829h304-provenance.drv...
building /gnu/store/g62yd6a8wd081w0y4jji83dbcxhiks3i-etc.drv...
building /gnu/store/5hpm7v0xnqqilhj7qdg66cjkf8dvkimx-activate-service.scm.drv...
building /gnu/store/smmzsd1b9v4qmncvl0pl6f0nrasp39ks-activate.scm.drv...
building /gnu/store/djs7vabv5wr3inz3pva87wfw7ya10ajq-boot.drv...
building /gnu/store/ayssizgz8i4mnk6p2yhilqgzwim4ql7j-system.drv...
building /gnu/store/sqlbbg5z19h2ww86p8nzhfbnidsm5sag-switch-to-system.scm.drv...
building /gnu/store/yzilvx4jr4s7174f6azxxbb5c24311xc-remote-exp.scm.drv...
guix deploy: sending 10 store items (0 MiB) to '23.137.249.202'...
guix deploy: sending 0 store items (0 MiB) to '23.137.249.202'...
guix deploy: sending 0 store items (0 MiB) to '23.137.249.202'...
The following derivations will be built:
/gnu/store/36rmj2xp0sd7lx0ndv8imkyxrh2lmmdy-remote-exp.scm.drv
/gnu/store/823hs0g4wxdmfwmj6nn8smcnrp45a1g7-install-bootloader.scm.drv
/gnu/store/0m7f6gg0d0iq6r99p40rw3m65z52fjiy-grub.cfg.drv
building /gnu/store/0m7f6gg0d0iq6r99p40rw3m65z52fjiy-grub.cfg.drv...
building
/gnu/store/823hs0g4wxdmfwmj6nn8smcnrp45a1g7-install-bootloader.scm.drv...
building /gnu/store/36rmj2xp0sd7lx0ndv8imkyxrh2lmmdy-remote-exp.scm.drv...
;;; [2022/10/04 14:20:23.191118, 0] [GSSH ERROR] Channel opening failure:
channel 67 error (2) open failed: #
Backtrace:
In guix/store.scm:
1402:13 19 (map/accumulate-builds # …)
1377:11 18 (map/accumulate-builds # …)
1295:8 17 (call-with-build-handler # …)
In ice-9/boot-9.scm:
1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/deploy.scm:
168:6 15 (_)
In guix/store.scm:
2165:25 14 (run-with-store # …)
In gnu/machine/ssh.scm:
506:32 13 (_ _)
In ice-9/boot-9.scm:
1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In gnu/machine/ssh.scm:
506:32 11 (_)
In guix/store.scm:
2165:25 10 (run-with-store # …)
In guix/remote.scm:
138:10 9 (_ _)
In guix/store.scm:
2037:38 8 (_ #)
In guix/ssh.scm:
376:2 7 (send-files # _ # …)
222:5 6 (remote-run (begin (use-modules (guix) (srfi #) # #) …) #)
In ssh/popen.scm:
64:4 5 (open-remote-pipe* _ "r+" _ . _)
In unknown file:
4 (channel-open-session #)
In ice-9/boot-9.scm:
1685:16 3 (raise-exception _ #:continuable? _)
1683:16 2 (raise-exception _ #:continuable? _)
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel
opening failure: channel 67 error (2) open failed" # #f)'.
make: *** [Makefile:28: deploy-pinky] Error 1
Compilation exited abnormally with code 2 at Tue Oct 4 14:20:23
--8<---cut here---end--->8---
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#57585: guix gc removed home config
On 2022-09-04 21:17, Julien Lepiller wrote:
> Actually I figured this out:
>
> Generation 16 used an older guix version where guix home added a . at
> the end of file names, so my config looked like this:
>
> (simple-service 'xfce4-terminal home-files-service-type
> `(("config/xfce4/terminal/terminalrc"
> ,(local-file
> "files/xfce4-terminal/terminalrc"
>
> Then, I updated Guix without changing my home configuration, so on
> generation 17, guix home created $HOME/config instead of $HOME/.config.
> So $HOME/.config/xfce4/terminal/terminalrc (and all other config files)
> kept pointing to generation 16's files. After removing the generation
> and "guix gc", these files no longer exist, and I'm in trouble :)
BTW, there is xdg-configuration-files-service-type, which hides away
those details and helps to migrate seamlessly. May be helpful for
future readers:
https://guix.gnu.org/en/manual/devel/en/guix.html#index-home_002dxdg_002dconfiguration_002dfiles_002dservice_002dtype
>
> So, guix home and guix gc are working as intended, but the change to
> no longer adding a "." at the beginning of file names (which makes
> total sense) tripped me up.
>
> Le Sun, 4 Sep 2022 20:32:58 +0200,
> Julien Lepiller a écrit :
>
>> Hi Guix!
>>
>> Today I ran "guix home delete-generations" to remove my old home
>> generations. It removed generations 0 and 17. I'm on generation 18.
>>
>> Then I ran "guix gc" and after I noticed I couldn't run a program from
>> my window manager (its menu is managed from guix home), I tried to
>> look at what was happening. My config files managed by guix home are
>> now symlinks that point to non existent store items. Spooky.
>>
>> Please let me know how I can help diagnose the issue
>>
>>
>>
>
>
>
>
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#57498: bash-completion completion functions not loaded when using guix home
On 2022-08-31 15:35, m...@pkbd.org wrote:
> I don't install bash-completion into my system profile and I use only
> guix home to install user packages. I typically don't guix install any
> packages.
>
> While I do include the bash-completion package in my home configuration
> file, the completion bash functions do not get loaded as needed, the
> resulting user experience is as if bash-completion wasn't installed,
> although .bashrc is edited in the typical way to load the main file
> bash_completion. But, the shell code in bash_completion cannot find and
> load the individual files containing the completion functions for
> individual commands.
>
> The reason is that I don't have a ~/.guix-profile folder, my current
> user profile is linked in ~/.guix-home/profile. The relevant path (in
> my case) is not included in the search path for completion bash functions.
>
> In guix this completion functions search path is defined by the patch found at
> gnu/packages/patches/bash-completion-directories.patch, where you can
> see the path to the guix home user profile is missing.
>
> The patch below is a patch to the patch file I mention above from the
> guix dource tree. It just adds 2 folders to the search path.
>
> I verified that it works for me.
Hi Maze!
That's right, the similiar fix is already applied on core-updates branch
675c5c9bbd28e5e666903aa81efaec25b1573811, unfortunately bash-completion
package update affects a lot of packages that's why it's not on master
branch yet. Thank you for the patch, anyway!
For now, while 1.4 is not released yet, as a temporary fix I can suggest
to install the package providing bash-completion to ~/.guix-profile or
system profile. There are other workarounds, but this one seems to be
the easiest.
>
> ---
>bash-completion: fix loading of completion functions with guix home
>
>* gnu/packages/patches/bash-completion-directories.patch: modified
> ---
> gnu/packages/patches/bash-completion-directories.patch | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/patches/bash-completion-directories.patch
> b/gnu/packages/patches/bash-completion-directories.patch
> index 021e34653b..3c6b3082ea 100644
> --- a/gnu/packages/patches/bash-completion-directories.patch
> +++ b/gnu/packages/patches/bash-completion-directories.patch
> @@ -10,7 +10,7 @@ This is what this patch does.
>
> --- a/bash_completion
> +++ b/bash_completion
> -@@ -2016,7 +2016,13 @@ complete -F _minimal ''
> +@@ -2016,7 +2016,15 @@ complete -F _minimal ''
>
> __load_completion()
> {
> @@ -19,6 +19,8 @@ This is what this patch does.
> +
> ${BASH_COMPLETION_USER_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/bash-completion}/completions
> +"$HOME/.guix-profile/share/bash-completion/completions/$base"
It seems $base not needed anymore, it's a rudiment from an old version
of the patch. I'll remove it.
> +"$HOME/.guix-profile/etc/bash_completion.d/$base"
> ++"$HOME/.guix-home/profile/share/bash-completion/completions/$base"
> ++"$HOME/.guix-home/profile/etc/bash_completion.d/$base"
> +
> "/run/current-system/profile/share/bash-completion/completions/$base"
> +"/run/current-system/profile/etc/bash_completion.d/$base" )
> +
>
> base-commit: 47c11772dfe840a536ed7ec438fe832878f51054
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#56669: enhancement: Link guix system and guix home
On 2022-07-21 19:25, Maxime Devos wrote: > On 21-07-2022 19:13, Andrew Tropin wrote: > >> The source code is here: >> https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9 > > What's the 'guix-home-gc-roots' for? I would expect the reference > #$(file-append he "/activate") to be sufficient to keep things from > being gc'ed. It was needed while I was testing manual activation without shepherd service, not needed anymore, already removed it locally. > >> + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-23> >> >> (start #~(make-forkexec-constructor + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-24> >> >> '(#$(file-append he "/activate")) + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-25> >> >> #:user #$user + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-26> >> >> #:environment-variables + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-27> >> >> (list (string-append "HOME=" (passwd:dir (getpw #$user + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-28> >> >> #:group (group:name (getgrgid (passwd:gid (getpw #$user)) > I'm wondering if GUIX_LOCPATH is needed as well. Anyway, if not done > already internally by /activate, you could consider doing it in a > container to reduce potential irreproducibility, or insecurity on > multi-user systems (I'd assume the #:user + #:group to be sufficient for > security, especially if it appears sufficient for other system services, > but I'm not some expert on what things need to be set). > It's not set by /activate. >> + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-20> >> >> (provision (list (symbol-append 'guix-home- (string->symbol user + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-21> >> >> (one-shot? #t) + >> <https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9#gnu/services/home.scm-1-22> >> >> (auto-start? #f) > Wouldn't it then be possible for the user to login via the login manager > before initialisation has completed, as gdm etc don't wait for > guix-home-... currently? You are right, the same as the first one, needed for more manual approach, changed to #t, thank you. Three patches for this service to work is on the way on guix-patches. In the meantime, will try to build livecd with the home environment inside. P.S. Probably this system service is far from final version of this feature, I still think about making home-environment a part of user-account. Will evaluate pros and cons, after I get livecd built successfully. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SDDM + Mate
On 2022-07-22 12:44, Maxime Devos wrote: > On 22-07-2022 12:24, Maxime Devos wrote: >> retitle 56661 SDDM does not do the equivalent of 'login shell >> --login', unlike other login managers >> thanks >> >> A digged a little, and found that: >> >> For GDM, things work, for SDDM, they don't. >> >> There is a 'xinitrc' procedure in gnu/services/xorg.scm that generates >> a configuration file that has a fallback .xsession that does a >> --login. This is used by gdm-wayland-session-wrapper, >> and slim-shepherd-service. However, nothing >> similar appears to be done for SDDM. So it appears that the SDDM >> service needs to be tweaked to use xinitrc or such. The idea looks good to me. > > It appears that SDDM supports xinitrc files, but it looks for them > (see data/scripts/Xsession) in $HOME/.xsessionrc and > /etc/X11/xinit/xinitrc.d, which do not exist in Guix. There is no > option for overriding the xinitrc. However, it is possible to > override the Xsession script used, so we can give SDDM a modified > Xsession script that uses Guix' xinitrc. I'll give that a try. Just a note: .xsessionrc is debian-specific IIRC -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SLIM + Mate
On 2022-07-22 11:32, Maxime Devos wrote: > On 20-07-2022 19:47, Andrew Tropin wrote: > >> I'm not sure how your login/display manager works, but for X11 session >> sourcing ~/.profile from ~/.xsession should do the trick. > Me neither, and I don't particularly care. > > If this is something that needs to be done, shouldn't _Guix System_ > create that file by default, for the same reason that Guix System > creates a ~/.profile and ~/.bash_profile by default? I don't see why I > would have to do that myself. It's a tricky question, because it's a case on the edge of Home/System. From one point of view it should be handled by some home service, which will create a proper ~/.xsession or extend it and generic mechanism, from some display managers will automatically source it, but on the other hand maybe adjusting system services for other DMs, which doesn't work "out of the box" yet is a way to go. I don't have much experience with X11, and don't see a whole picture, so it's hard to tell which option is better. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56669: enhancement: Link guix system and guix home
On 2022-07-20 20:57, Andrew Tropin wrote: > On 2022-07-20 11:47, Dale Mellor wrote: > >> I would like to be able to create a rescue disk for my system in which >> the admin user's home directory contains a copy of an encrypted key, >> for manually unlocking encrypted disk drives. >> >> Following a short discussion in IRC, it appears the best route to >> achieve this would be to link *guix system* and *guix home* together, >> so that the system configuration file can specify >> >> (user-account >>... >>(configuration (local-file "my-home-config.scm"))) >> >> for example (it should be possible to use either (home-configuration) >> or a file-like object here). >> >> Hopefully this is an easy thing to accomplish, but I don't know... >> > > Hi Dale, > > it's not easy, but doable. > > This topic popups from time to time, but this feature is not implemented > yet. > > https://yhetil.org/guix-devel/20220706112011.77c71...@marvid.fr/ > > I have spare time tomorrow and can try to implement it, however Idk how > much time will it take and if I don't finish tomorrow, there is no > guarantee that I'll finish it anytime soon. I built home environment baked in operating system and sucessfully deployed it with guix deploy. I face some issues with the similiar setup on livecd, but I think I will figure out it soon and will publish results in a few days. The source code is here: https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9 It's drafty and will be rewritten, also there are a few local commits that I haven't sent to guix yet, but it should work without them if elogind is enabled. The usage example: config.scm Description: Binary data -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56669: enhancement: Link guix system and guix home
On 2022-07-20 11:47, Dale Mellor wrote: > I would like to be able to create a rescue disk for my system in which > the admin user's home directory contains a copy of an encrypted key, > for manually unlocking encrypted disk drives. > > Following a short discussion in IRC, it appears the best route to > achieve this would be to link *guix system* and *guix home* together, > so that the system configuration file can specify > > (user-account >... >(configuration (local-file "my-home-config.scm"))) > > for example (it should be possible to use either (home-configuration) > or a file-like object here). > > Hopefully this is an easy thing to accomplish, but I don't know... > Hi Dale, it's not easy, but doable. This topic popups from time to time, but this feature is not implemented yet. https://yhetil.org/guix-devel/20220706112011.77c71...@marvid.fr/ I have spare time tomorrow and can try to implement it, however Idk how much time will it take and if I don't finish tomorrow, there is no guarantee that I'll finish it anytime soon. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SLIM + Mate
On 2022-07-20 14:30, Maxime Devos wrote:
> On 20-07-2022 14:08, Andrew Tropin wrote:
>> Hi Maxime,
>>
>> According to the documentation to get all the environment variables set
>> correctly you either need to manage your login shell with Guix Home or
>> do additional configuration of your shell:
>> https://guix.gnu.org/manual/devel/en/html_node/Configuring-the-Shell.html
>
> I am not using a login shell, though I suppose there might be one under
> the hood somewhere (IIRC, and if it hasn't changed, some login managers
> are wrapped in Guix System to insert a bash --login in-between). Even if
> I am using a (non-login) shell, there's still an issue: if I start an
> application via the graphical things, they don't get all the environment
> variables (I tested this by opening a terminal that starts bash and
> doing "echo $EMACSLOADPATH", but that a shell is used for the test seems
> irrelevant here to me).
>
>> From what I see you manage bash with Guix Home,
> I am not. I just keep the default ~/.bash_profile etc that a fresh Guix
> System install gave me and the only reason bash_profile things appear in
> the home configuration is because "guix home import" generated that. I'm
> not managing anything, just keeping the defaults.
You are ;) Declaring home-bash-service-type in home environment means
that Guix Home will generate and install bash configurations, which
means you are managing bash configurations with Guix Home.
>> so according to the
>> source code your bash_profile should look differently from what you've
>> posted and must contain `source ~/.profile` in it:
>
> ~/.bash_profile does contain that line:
>
> # Set up the system, user profile, and related variables.
> # /etc/profile will be sourced by bash automatically
> # Set up the home environment profile.
> if [ -f ~/.profile ]; then source ~/.profile; fi
>
> # Honor per-interactive-shell startup file
> if [ -f ~/.bashrc ]; then source ~/.bashrc; fi
> # Honor per-interactive-shell startup file
> if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
You can remove your original bash_profile, because it's just duplicates
last two lines, Guix Home adds the same content as skeletons provided
during system installation and a little more.
>
> However, .bash_profile (the one from the local-file) does not:
>
> # Honor per-interactive-shell startup file
> if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
>
>
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shells.scm#n440
>>
>> This line makes your login shell
>
> I am not using a login shell but a graphical environment -- the only
> reason I actually use a shell at all is because I find it more
> convenient to open a terminal and type "emacs" than to look in the
> graphical desktop thingy for the Emacs icon. Also, I'm not finding Emacs
> here even though in the previous installation of Guix System (GDM + Mate
> IIRC, without Guix Home but with "guix install ...". Icedove isn't
> appearing there either, though the browser is.
>
> I recall that it login shells were not necessary on Guix System +
> ~/.guix-profile (without Guix Home), at least for the desktop
> environment combination I used back then, though it was required on my
> Debian system to do "bash --login". I can do "bash --login" on my Guix
> System + Guix Home setup to start a login shell, but that would be a
> regression.
>
I'm not sure how your login/display manager works, but for X11 session
sourcing ~/.profile from ~/.xsession should do the trick.
Put the following content to your ~/.xsession:
--8<---cut here---start->8---
. ~/.profile
--8<---cut here---end--->8---
Or add the following service to your home environment:
--8<---cut here---start->8---
(simple-service
'xsession-init-file
home-files-service-type
`((".xsession" ,(plain-file "xsession" ". ~/.profile"
--8<---cut here---end--->8---
>> source .profile, which sources
>> setup-environment, which sources ~/.guix-home/profile/etc/profile, which
>> sets EMACSLOADPATH.
>>
>> Additionally, I've built the home environment you provided and it
>> contains the code I mentioned above.
>>
>> Make sure that ~/.bash_profile and ~/.guix-home/files/.bash_profile
>> point to the same file in the store.
>
> antipode@antipode ~$ ls -l .bash_profile
> lrwxrwxrwx 1 antipode users 56 19 jul 22:14 .bash_profile ->
> /gnu/store/1cq87qf8zccxlnkjwifcyhawmxvy7wfw-bash_profile
>
> antipode@antipode ~$
bug#56661: EMACSLOADPATH not set when using Guix System + Guix Home + SLIM + Mate
${BASH_LOADABLES_PATH:+:}$BA>
>> export
>> INFOPATH="${GUIX_PROFILE:-/gnu/store/ll0p9k6yp5070svjhwry8dxdm98ipk7d-profile}/share/info${INFOPATH:+:}$INFOPATH"
>> export
>> EMACSLOADPATH="${GUIX_PROFILE:-/gnu/store/ll0p9k6yp5070svjhwry8dxdm98ipk7d-profile}/share/emacs/site-lisp${EMACSLOADPATH:+:}$E>
>> export
>> XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/ll0p9k6yp5070svjhwry8dxdm98ipk7d-profile}/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
>
> (nevermind the >, that's just me not making the terminal wide enough
> before copying)
>
> Weirdly, EMACSLOADPATH is not set (tested in a terminal), but PATH,
> GIT_EXEC_PATH, BASH_LOADABLES_PATH, INFOPATH and XDG_DATA_DIRS are set.
> Also, inside a login shell (bash --login) (started inside the graphical
> environment), EMACSLOADPATH is not set.
>
> Also, if I do "source ~/.guix-home/setup-environment", then
> $EMACSLOADPATH" is set.
>
> TBI ...
>
> Greetings,
> Maxime.
>
>
> -BEGIN PGP PUBLIC KEY BLOCK-
>
> xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
> xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
> ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
> CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
> /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
> LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
> kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
> CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
> ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
> Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
> k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
> AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
> fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA==
> =OVqp
> -END PGP PUBLIC KEY BLOCK-
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#54014: guix home pinentry weirdness
On 2022-07-17 00:44, Zacchaeus Scheffer wrote: > On Mon, Jul 4, 2022 at 1:50 AM Andrew Tropin wrote: > >> On 2022-02-15 13:46, Zacchaeus Scheffer wrote: >> > There seems to be some problem installing password-store + pinentry >> > entirely via guix home. When I have both installed as such, I get the >> > following outputs: >> > >> > $ pinentry >> > OK Pleased to meet you >> > >> > $ gpg --import ... >> > [prompts normally with pinentry, allows me to import] >> > $ pass >> > [my password entries] >> > $ pass [entry name] >> > gpg: decryption failed: No secret key >> > $ guix package -i pinentry >> > $ pass [entry name] >> > [prompts with pinentry and works normally] >> > >> > So pinentry and pass seem to both be available, but don't work together >> > unless I install pinentry via guix package. >> >> I suspect that the problem is that someone at some moment of time >> doesn't have ~/.guix-home/profile/bin in its $PATH and thus it can't >> find a pinentry. Can you show `which gpg`, `which pass`, `which >> pinentry`? >> > Before running "guix package -i pinentry" > $ which -a pinentry > /home/zacchae/.guix-home/profile/bin/pinentry > $ which -a gpg > /home/zacchae/.guix-home/profile/bin/gpg > $ which -a pass > /home/zacchae/.guix-home/profile/bin/pass > After runing "guix package -i pinentry" > $ which -a pinentry > /home/zacchae/.guix-home/profile/bin/pinentry > /home/zacchae/.guix-profile/bin/pinentry > $ which -a gpg > /home/zacchae/.guix-home/profile/bin/gpg > $ which -a pass > /home/zacchae/.guix-home/profile/bin/pass > > I can easily reproduce the behavior by removing or installing pinentry with > guix package. Paths behave as expected. Probably there are some hardcoded PATHs for .guix-profile, but not for .guix-home/profile. One of such examples, which can be unrelated to the current issue: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm?h=7046e777212233b89df68379c270b448c45195ce#n1012 It will require investigation to find all the places, where and at what time PATH (and maybe some other env vars) is/are set for all the participants of the party to trace the root of the problem and properly solve it =) Anyway, there is a workaround, which should help: > > The gnupg home service from rde project goes a slightly other way and >> just sets pinentry-program to absolute path in the store. Such approach >> works with pass well, you can take a look at it for inspiration: >> >> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/gnupg.scm#L127 >> > I don't totally follow what's going on here, but maybe it will make more > sense later. Basically it adds the following content to gpg-agent.conf: --8<---cut here---start->8--- enable-ssh-support pinentry-program /gnu/store/r5j2gmfv8akp8p746l6jqy5qwpz0zkhm-pinentry-qt-1.2.0/bin/pinentry-qt --8<---cut here---end--->8--- You can try to set pinentry-program to /home/zacchae/.guix-home/profile/bin/pinentry Or better directly use gnupg home service. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56610: Guix Home placing dotfiles in wrong directory.
On 2022-07-17 03:07, Raghav Gururajan via Bug reports for wrote:
> Hello Guix,
>
> home-files-service-type is placing configuration files in `~/config/foo`
> instead of `~/.config/foo`.
>
> For example, the following guix-home service should place the git
> configuration in ~/.config/git`. But it creates a new directory
> `~/config/git` and places the file there.
It's intended https://yhetil.org/guix-devel/87v8w2se04@trop.in/
Updates to the documentation is on the way:
https://yhetil.org/guix-patches/87h74abbn6@trop.in/
>
> (simple-service 'git-config
> home-files-service-type
In this case, it's better to use home-xdg-configuration-files instead of
home-files.
> (list
> `("config/git/config"
> ,(local-file
> (string-append (getenv "HOME")
Just a tip for finer reproducibility of the configuration: it's better
to avoid using environment variables, files outside of the project
directory and other thing, which make code impure/dependening on global
state.
> "/dotfiles/git/config")
>
> It started happening recently, so will try to bisect.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#56570: generate-documentation can't handle package fields
Minimal reproducer:
--8<---cut here---start->8---
(use-modules (gnu services configuration)
(gnu packages mail))
(define-configuration/no-serialization home-goimapnotify-configuration
(package
(package go-gitlab.com-shackra-goimapnotify)
"The @code{goimapnotify} package to use."))
(generate-documentation
`((home-goimapnotify-configuration
,home-goimapnotify-configuration-fields))
'home-goimapnotify-configuration)
--8<---cut here---end--->8---
Error:
--8<---cut here---start->8---
(generate-documentation
`((home-goimapnotify-configuration
,home-goimapnotify-configuration-fields))
'home-goimapnotify-configuration)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure symbol->string: Wrong type argument in position 1 (expecting
symbol): #f
[Debugging level: 18]
--8<---cut here---end--->8---
I suspect that problematic code is here:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=6505f727e1824391b888dd0c2c60cf64ec66955a#n308
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#54014: guix home pinentry weirdness
On 2022-02-15 13:46, Zacchaeus Scheffer wrote: > Hi Guix, > > There seems to be some problem installing password-store + pinentry > entirely via guix home. When I have both installed as such, I get the > following outputs: > > $ pinentry > OK Pleased to meet you > > $ gpg --import ... > [prompts normally with pinentry, allows me to import] > $ pass > [my password entries] > $ pass [entry name] > gpg: decryption failed: No secret key > $ guix package -i pinentry > $ pass [entry name] > [prompts with pinentry and works normally] > > So pinentry and pass seem to both be available, but don't work together > unless I install pinentry via guix package. > > My guix install is about two months behind, so sorry if this has already > been patched. > > -Zacchaeus I suspect that the problem is that someone at some moment of time doesn't have ~/.guix-home/profile/bin in its $PATH and thus it can't find a pinentry. Can you show `which gpg`, `which pass`, `which pinentry`? The gnupg home service from rde project goes a slightly other way and just sets pinentry-program to absolute path in the store. Such approach works with pass well, you can take a look at it for inspiration: https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/gnupg.scm#L127 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#51639: The home-environment example on Guix manual has an error
On 2021-11-06 09:50, Luis Henrique Gomes Higino wrote:
> Hi,
>
> the example present in the 11.1 section of the guix manual ((guix)
> Declaring the Home Environment) uses a list of strings in the
> bash-profile field of home-bash-configuration, which is incorrect,
> as it
> expects a list of file-like objects.
>
> The example is as follows:
>
> (use-modules (gnu home)
>(gnu home services)
>(gnu home services shells)
>(gnu services)
>(gnu packages admin)
>(guix gexp))
>
>
> (home-environment
>(packages (list htop))
>(services
> (list
> (service home-bash-service-type
> (home-bash-configuration
>(guix-defaults? #t)
>(bash-profile '("\
> export HISTFILE=$XDG_CACHE_HOME/.bash_history"
>
> (simple-service 'test-config
> home-files-service-type
> (list `("config/test.conf"
> ,(plain-file "tmp-file.txt"
> "the content of
> ~/.config/test.conf")))
>
> Running "guix home build" with a file containing this returns this
> error:
>
> building
> /gnu/store/cvmpzmvb0p73dvbf813rcmpplj6fnbk8-bash_profile.drv...
> Backtrace:
> 8 (primitive-load
> "/gnu/store/w6nikzvdk66d1b8x579ra0vz0wl?")
> In ice-9/ports.scm:
> 463:17 7 (call-with-output-file _ _ #:binary _ #:encoding _)
> In ice-9/eval.scm:
> 159:9 6 (_ #(#(#)
> #))
> 163:9 5 (_ #(#(#)
> #))
> 155:9 4 (_ #(#(#)
> #))
> 159:9 3 (_ #(#(#)
> #))
> In ice-9/boot-9.scm:
> 152:2 2 (with-fluid* _ _ _)
> In ice-9/ports.scm:
> 440:11 1 (call-with-input-file " export
> HISTFILE=$XDG_CACHE?" ?)
> In unknown file:
> 0 (open-file " export
> HISTFILE=$XDG_CACHE_HOME/.bash?" ?)
>
> ERROR: In procedure open-file:
> In procedure open-file: No such file or directory: " export
> HISTFILE=$XDG_CACHE_HOME/.bash_history"
> builder for
> `/gnu/store/cvmpzmvb0p73dvbf813rcmpplj6fnbk8-bash_profile.drv'
> failed with exit code 1
>
> I believe it should be changed to something like this:
>
> (use-modules (gnu home)
>(gnu home services)
>(gnu home services shells)
>(gnu services)
>(gnu packages admin)
>(guix gexp))
>
>
> (home-environment
>(packages (list htop))
>(services
> (list
> (service home-bash-service-type
> (home-bash-configuration
>(guix-defaults? #t)
>(bash-profile (list (plain-file "bash-profile" "\
> export HISTFILE=$XDG_CACHE_HOME/.bash_history")
>
> (simple-service 'test-config
> home-files-service-type
> (list `("config/test.conf"
> ,(plain-file "tmp-file.txt"
> "the content of
> ~/.config/test.conf")))
>
> This manages to build correctly.
>
> Greetings,
> Luis
Hi, you are right! Sorry for long reply.
From b1b448078a5382caf906c84064094f25aef7c689 Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Fri, 10 Jun 2022 10:08:24 +0300
Subject: [PATCH] doc: Update example of a minimalistic home environment.
* doc/he-config-bare-bones.scm: Adujst example according to changes in
bash-service-type and home-files-service-type.
---
doc/he-config-bare-bones.scm | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/doc/he-config-bare-bones.scm b/doc/he-config-bare-bones.scm
index d2e4736e29..f948d85277 100644
--- a/doc/he-config-bare-bones.scm
+++ b/doc/he-config-bare-bones.scm
@@ -13,12 +13,13 @@
(service home-bash-service-type
(home-bash-configuration
(guix-defaults? #t)
- (bash-profile '("\
-export HISTFILE=$XDG_CACHE_HOME/.bash_history"
+ (bash-profile (list (plain-file "bash-profile" "\
+export HISTFILE=$XDG_CACHE_HOME/.bash_history")
(simple-service 'test-config
- home-files-service-type
- (list `("config/test.conf"
+ home-xdg-configuration-files-service-type
+ (list `("test.conf"
,(plain-file "tmp-file.txt"
-"the content of ~/.config/test.conf")))
+"the content of
+ ~/.config/test.conf")))
--
2.36.1
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#55776: maven-core fails to build
On 2022-06-04 15:47, Julien Lepiller wrote:
> Le Sat, 04 Jun 2022 12:25:21 +0200,
> Remco van 't Veer a écrit :
>
>> I did some digging and found this regression is caused by commit:
>>
>> 6068b83b82475566acd4162467bcf54270f338f9
>> "gnu: java-jdom: Update to 2.0.6.1 [fixes CVE-2021-33813]."
>>
>> Apparently the fix for this issue causes jdom to be very strict;
>>
>> > java.io.IOException: Invalid input descriptor for merge:
>> > /tmp/plexus-metadata3957336728290309540xml -->
>> > http://xml.org/sax/features/external-general-entities feature
>> > http://xml.org/sax/features/external-general-entities not supported
>> > for SAX driver org.codehaus.plexus.metadata.merge.Driver
>>
>> Which sound familiar when looking at that CVE
>> (https://github.com/advisories/GHSA-2363-cqg2-863c):
>>
>> > An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to
>> > cause a denial of service via a crafted HTTP request. At this time
>> > there is not released fixed version of JDOM. As a workaround, to
>> > avoid external entities being expanded, one can call
>> > builder.setExpandEntities(false) and they won't be expanded.
>>
>> I dunno how to fix this though, I'm just a curious guixer. Easiest
>> path seems to be to make a new java-jdom-2.0.6 var and use that as a
>> native-input for maven. Would that be an acceptable solution?
>>
>> Cheers,
>> Remco
>>
>
> Like you say, the issue is with the new jdom. Believe it or not, but
> between 2.0.6 and 2.0.6.1 there's some breakage (and > 1 year of
> changes, too)!
>
> So I figured I could fix java-plexus-component-metadata that we use to
> generate some xml files during the build of maven. jdom is one of its
> inputs. Adding another jdom to the native inputs would probably not fix
> the issue.
>
> What I did instead is, since jdom wants to set more features than
> supported in the driver, to add dummy support for all these additional
> features by just not throwing the exception. It's not very satisfying,
> but it works and we don't keep a vulnerable jdom around. With the
> attached patch, I built up to maven.
> From 2523b6c6b3f81f8a86b7c768dfed9dae97978e93 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller
> Date: Sat, 4 Jun 2022 15:41:41 +0200
> Subject: [PATCH] gnu: java-plexus-component-metadata: Fix package.
>
> * gnu/packages/java.scm (java-plexus-component-metadat): Apply fix for
> newer jdom.
> ---
> gnu/packages/java.scm | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index 336e84e3e5..f475f7c270 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -4537,6 +4537,14 @@ (define-public java-plexus-component-metadata-1.7
> (copy-recursively "src/main/resources"
> "build/classes/")
> #t))
> + (add-before 'build 'fix-jdom
> + (lambda _
> + ;; The newer version of jdom now sets multiple features by
> default
> + ;; that are not supported.
> + ;; Skip these features
> + (substitute*
> "src/main/java/org/codehaus/plexus/metadata/merge/MXParser.java"
> + (("throw new XmlPullParserException\\(\"unsupporte feature
> \"\\+name\\);")
> +"// skip"
> (add-before 'check 'fix-test-location
> (lambda _
> (substitute*
> '("src/test/java/org/codehaus/plexus/metadata/DefaultComponentDescriptorWriterTest.java"
Work for me as well. Probably can be merged to master?
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52899: More info on guix home reconfigure behaviour
On 2022-04-26 18:29, Bastien Rivière wrote:
> Hello,
>
> Here is what I got on my end when running guix home:
>
>> Loading /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>> herd: exception caught while executing 'load' on service 'root':
>> In procedure fport_write: Broken pipe
>
> I have same output when running ~herd load root~.
>
>> > herd load root /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf
>> Loading /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>> herd: exception caught while executing 'load' on service 'root':
>> In procedure fport_write: Broken pipe
>
> And the content of sheperd.conf is:
>
>> (begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply
>> register-services (map (lambda (file) (load file)) (quote
>> ("/gnu/store/amvwc8ljsw4v6035q5hi9wlrj5kdi8qv-shepherd-emacs-server.scm"
>> (action (quote root) (quote daemonize)) (format #t "Starting services...~%")
>> (let ((services-to-start (quote (emacs-server (if (defined? (quote
>> start-in-the-background)) (start-in-the-background services-to-start)
>> (for-each start services-to-start)) (redirect-port (open-input-file
>> "/dev/null") (current-input-port
>
> Watching the log of shepherd, I have only this line:
>
>> 2022-04-26 18:27:48 Loading
>> /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>
> Tell me what I can do to help you debug this.
IIRC, it should be fixed already, can you please check if it's still a
problem?
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#54545: [Guix Home] ‘shepherd’ started twice?
On 2022-04-12 20:28, Ludovic Courtès wrote:
> Hi,
>
> Andrew Tropin skribis:
>
>> Prepared a patch series, which fixes the issues and sligthly adjusts the
>> way home shepherd reload configuration logic works, now it happens only
>> if configuration is changed and also it doesn't try to be smart and
>> start a shepherd if it's not started yet.
>>
>> From d2578f8924217451ca20f0b61fd6f9b9d31c930d Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Tue, 12 Apr 2022 11:30:58 +0300
>> Subject: [PATCH 1/3] home: shepherd: Prevent launching the second instance.
>>
>> * gnu/home/services/shepherd.scm: Prevent launching the second instance.
>
> I applied this one with a convention commit log, including a “Fixes”
> line, which is important for traceability. (Please check the ChangeLog
> convention for future patches.)
>
Read it from time to time, but the information about contribution
guidelines is too much spreaded, for example I can't find info about
Fixes line even with search, but maybe I just not very attentive.
https://guix.gnu.org/en/manual/devel/en/guix.html#Sending-a-Patch-Series-1
https://www.gnu.org/prep/standards/standards.html#Change-Logs
>> From 56d16b4cd511f6837329b888dade0c6d6da4d89d Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Tue, 12 Apr 2022 12:19:50 +0300
>> Subject: [PATCH 2/3] home: shepherd: Use run-on-change to reload shepherd
>> config.
>>
>> * gnu/home/services/shepherd.scm: Add shepherd configuration to
>> XDG_CONFIG_HOME and use it instead of full path to the store. It's necessary
>> to use run-on-change service.
>
> [...]
>
>> +++ b/gnu/home/services/shepherd.scm
>> @@ -105,27 +105,30 @@ (define (launch-shepherd-gexp config)
>> (system*
>> #$(file-append shepherd "/bin/shepherd")
>> "--logfile"
>> - (string-append log-dir "/shepherd.log")
>> - "--config"
>> - #$(home-shepherd-configuration-file services shepherd)
>> + (string-append log-dir "/shepherd.log")
>> #~"")))
>>
>> (define (reload-configuration-gexp config)
>>(let* ((shepherd (home-shepherd-configuration-shepherd config))
>> (services (home-shepherd-configuration-services config)))
>> -#~(system*
>> - #$(file-append shepherd "/bin/herd")
>> - "load" "root"
>> - #$(home-shepherd-configuration-file services shepherd
>> +#~(when (file-exists?
>> + (string-append
>> + (or (getenv "XDG_RUNTIME_DIR")
>> + (format #f "/run/user/~a" (getuid)))
>> + "/shepherd/socket"))
>> +(system*
>> + #$(file-append shepherd "/bin/herd")
>> + "load" "root"
>> + #$(home-shepherd-configuration-file services shepherd)
>>
>> -(define (ensure-shepherd-gexp config)
>> - #~(if (file-exists?
>> - (string-append
>> - (or (getenv "XDG_RUNTIME_DIR")
>> - (format #f "/run/user/~a" (getuid)))
>> - "/shepherd/socket"))
>> -#$(reload-configuration-gexp config)
>> -#$(launch-shepherd-gexp config)))
>> +(define (add-shepherd-configuration config)
>> + (let* ((shepherd (home-shepherd-configuration-shepherd config))
>> + (services (home-shepherd-configuration-services config)))
>> +`(("shepherd/init.scm"
>> + ,(home-shepherd-configuration-file services shepherd)
>> +
>> +(define (home-shepherd-run-on-change config)
>> + `(("files/.config/shepherd/init.scm" ,(reload-configuration-gexp
>> config
>
> How does this relate to the bug at hand?
>
> https://issues.guix.gnu.org/54545
>
Almost directly.
During activation if there is no shepherd process we tried to launch a
new one, which was useful back in the days, when I was testing changes
frequently, but can be kinda unexpected for user, if they stopped
Shepherd for some reason, but during activation it started again
automatically. As we discussed earlier:
>>> Probably we need to do config reload using on-change service and also
>>> not trigger on-change stuff if user isn't logged in.
>> Makes sense.
it would be nice to reload configuration only if it's changed. To make
run-on-change work we need to store a config somewhere in
home-environment, to make it possible to compare wit
bug#54545: [Guix Home] ‘shepherd’ started twice?
On 2022-04-04 22:16, Ludovic Courtès wrote: > Hi, > > Andrew Tropin skribis: > >> Activation script tries to load latest shepherd configuration with `herd >> load root ./path/to/config.scm` and it starts a shepherd process. Login >> shell starts the shepherd process as well. Probably we need to do >> config reload using on-change service and also not trigger on-change >> stuff if user isn't logged in. > > Makes sense. > >> I can think on the proper solution and make a patch with a fix later >> this week or beginning of the next week. > > Awesome, thanks for taking a look! > > Ludo’. Prepared a patch series, which fixes the issues and sligthly adjusts the way home shepherd reload configuration logic works, now it happens only if configuration is changed and also it doesn't try to be smart and start a shepherd if it's not started yet. From d2578f8924217451ca20f0b61fd6f9b9d31c930d Mon Sep 17 00:00:00 2001 From: Andrew Tropin Date: Tue, 12 Apr 2022 11:30:58 +0300 Subject: [PATCH 1/3] home: shepherd: Prevent launching the second instance. * gnu/home/services/shepherd.scm: Prevent launching the second instance. --- gnu/home/services/shepherd.scm | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm index 012585fea4..df6bbb30e6 100644 --- a/gnu/home/services/shepherd.scm +++ b/gnu/home/services/shepherd.scm @@ -93,17 +93,21 @@ (define (launch-shepherd-gexp config) (services (home-shepherd-configuration-services config))) (if (home-shepherd-configuration-auto-start? config) (with-imported-modules '((guix build utils)) - #~(let ((log-dir (or (getenv "XDG_LOG_HOME") - (format #f "~a/.local/var/log" (getenv "HOME") - ((@ (guix build utils) mkdir-p) log-dir) - (system* - #$(file-append shepherd "/bin/shepherd") - "--logfile" - (string-append -log-dir -"/shepherd.log") - "--config" - #$(home-shepherd-configuration-file services shepherd + #~(unless (file-exists? + (string-append + (or (getenv "XDG_RUNTIME_DIR") + (format #f "/run/user/~a" (getuid))) + "/shepherd/socket")) + (let ((log-dir (or (getenv "XDG_LOG_HOME") + (format #f "~a/.local/var/log" + (getenv "HOME") +((@ (guix build utils) mkdir-p) log-dir) +(system* + #$(file-append shepherd "/bin/shepherd") + "--logfile" + (string-append log-dir "/shepherd.log") + "--config" + #$(home-shepherd-configuration-file services shepherd) #~""))) (define (reload-configuration-gexp config) -- 2.35.1 From 56d16b4cd511f6837329b888dade0c6d6da4d89d Mon Sep 17 00:00:00 2001 From: Andrew Tropin Date: Tue, 12 Apr 2022 12:19:50 +0300 Subject: [PATCH 2/3] home: shepherd: Use run-on-change to reload shepherd config. * gnu/home/services/shepherd.scm: Add shepherd configuration to XDG_CONFIG_HOME and use it instead of full path to the store. It's necessary to use run-on-change service. --- gnu/home/services/shepherd.scm | 40 +++--- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm index df6bbb30e6..9a99fed2b5 100644 --- a/gnu/home/services/shepherd.scm +++ b/gnu/home/services/shepherd.scm @@ -105,27 +105,30 @@ (define (launch-shepherd-gexp config) (system* #$(file-append shepherd "/bin/shepherd") "--logfile" - (string-append log-dir "/shepherd.log") - "--config" - #$(home-shepherd-configuration-file services shepherd) + (string-append log-dir "/shepherd.log") #~""))) (define (reload-configuration-gexp config) (let* ((shepherd (home-shepherd-configuration-shepherd config)) (services (home-shepherd-configuration-services config))) -#~(system* - #$(file-append shepherd "/bin/herd") - "load" "root" - #$(home-shepherd-configuration-file services shepherd +#~(when (file-exists? + (string-append + (or (getenv "XDG_RUNTIME_DIR") + (format #f "/run/user/~a" (getuid))) +
bug#52808: Guix home should not assume that all targets are dot files
On 2022-04-08 20:18, Ludovic Courtès wrote: > Hi Andrew, > > Andrew Tropin skribis: > >> Those patches introduce a breaking change, but the surface and number of >> people affected should be small if everyone migrated to >> xdg-configuration-files. It removes the special handling of dot files >> in symlink-manager and doesn't add a leading dot automatically. >> >> Please, merge them on April 8. >> >> From 1b556cda9716eba31a8a6dd9d3c263988de26ccf Mon Sep 17 00:00:00 2001 >> From: Andrew Tropin >> Date: Tue, 29 Mar 2022 11:28:30 +0300 >> Subject: [PATCH 1/2] home: symlink-manager: Remove appending of leading dot. >> >> * gnu/home/services.scm (xdg-configuration-files-directory): Add leading dot. >> * gnu/home/services.scm (xdg-configuration-files-service-type): Change name. >> * gnu/home/services/shells.scm (add-shell-profile-file, >> zsh-get-configuration-files, add-zsh-dot-configuration, >> add-zsh-xdg-configuration, add-bash-configuration): Add leading dots. >> * gnu/home/services/symlink-manager.scm (update-symlinks-script): Remove >> leading dot. > > [...] > >> From 5e1f45fa9ea1aca16843dc85d7d21fd46f3cfcb8 Mon Sep 17 00:00:00 2001 >> From: Andrew Tropin >> Date: Tue, 29 Mar 2022 12:47:39 +0300 >> Subject: [PATCH 2/2] home: Add home-xdg-data-files-service-type. >> >> * gnu/home/services.scm (home-xdg-data-files-service-type): New variable. >> * gnu/home/services/symlink-manager.scm (update-symlinks-script): Add a >> proper >> handling for XDG_DATA_HOME value. >> * gnu/home/services/xdg.scm (home-xdg-mime-applications-service-type): Use >> home-xdg-data-files service. > > Pushed as 20645d8467852990413c1ea9cf81cec82d23defd. > > Thanks! > > Ludo’. Hi Ludo, Thank you very much! Can you merge other patches from this thread too, please? -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#54545: [Guix Home] ‘shepherd’ started twice?
On 2022-03-24 15:21, Ludovic Courtès wrote:
> Hi,
>
> From what can be seen in ‘guix home container’, it would seem that
> ‘shepherd’ is started twice, leading to this error while attempting to
> bind(2) the second time (thus it’s actually harmless, but suboptimal):
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix home container /tmp/t.scm
> WARNING: (guile-user): imported module (guix build utils) overrides core
> binding `delete'
> Symlinking /home/ludo/.bash_profile ->
> /gnu/store/flqaxzvgfv2g3415mhmq6c0zbzdzv2k4-bash_profile... done
> Symlinking /home/ludo/.profile ->
> /gnu/store/dann7r1095xll0kji5yl0ql07096rc8j-shell-profile... done
> Symlinking /home/ludo/.bashrc ->
> /gnu/store/g78w0adqg25z3jl8jq71n0n0z32f7dbx-bashrc... done
> Symlinking /home/ludo/.config/fontconfig/fonts.conf ->
> /gnu/store/4261pxafny0g2myhh9yj1771ry7k05lc-fonts.conf... done
> done
> Finished updating symlinks.
>
> Comparing /gnu/store/non-existing-generation/profile/share/fonts and
>
> /gnu/store/vvfrdbvmb0g41k00xxmd9qpgzavkvd32-home/profile/share/fonts... done
> (same)
> Evaluating on-change gexps.
>
> On-change gexps evaluation finished.
>
> Service root has been started.
> WARNING: Use of `load' in declarative module (#{ g56}#). Add #:declarative?
> #f to your define-module invocation.
> Starting services...
> Service mcron has been started.
>
> Service root has been started.
> WARNING: Use of `load' in declarative module (#{ g56}#). Add #:declarative?
> #f to your define-module invocation.
> Starting services...
> Service mcron has been started.
>
> Backtrace:
>4 (primitive-load "/gnu/store/vza48khbaq0fdmcsrn27xj5y5yy?")
> In shepherd.scm:
> ~$316:10 3 (main "--logfile" "/home/ludo/.local/var/log/shepherd.?" ?)
> 56:14 2 (call-with-server-socket "/run/user/1000/shepherd/sock?" ?)
> 49:6 1 (open-server-socket "/run/user/1000/shepherd/socket")
> In unknown file:
>0 (bind # #(1 "/run/user/1000?") #)
>
> ERROR: In procedure bind:
> In procedure bind: Address already in use
> --8<---cut here---end--->8---
>
> I suspect the problem is in activation snippets, but I’m open to other
> hypotheses. :-)
>
> Thoughts?
>
> Ludo’.
>
>
Can confirm.
Activation script tries to load latest shepherd configuration with `herd
load root ./path/to/config.scm` and it starts a shepherd process. Login
shell starts the shepherd process as well. Probably we need to do
config reload using on-change service and also not trigger on-change
stuff if user isn't logged in. I can think on the proper solution and
make a patch with a fix later this week or beginning of the next week.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
On 2022-03-20 22:00, Ludovic Courtès wrote:
> I wrote:
>
>> I finally got around to committing it as
>> 6da2a5a5655668f42ec5b26f875ddbc498e132b6. Thank you!
>
> I hit “close” too quickly: we still need the patch that changes
> ‘home-files-service-type’ and/or symlink-manager.scm to not prepend a
> dot, so reopening! :-)
>
> Ludo’.
Those patches introduce a breaking change, but the surface and number of
people affected should be small if everyone migrated to
xdg-configuration-files. It removes the special handling of dot files
in symlink-manager and doesn't add a leading dot automatically.
Please, merge them on April 8.
From 1b556cda9716eba31a8a6dd9d3c263988de26ccf Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Tue, 29 Mar 2022 11:28:30 +0300
Subject: [PATCH 1/2] home: symlink-manager: Remove appending of leading dot.
* gnu/home/services.scm (xdg-configuration-files-directory): Add leading dot.
* gnu/home/services.scm (xdg-configuration-files-service-type): Change name.
* gnu/home/services/shells.scm (add-shell-profile-file,
zsh-get-configuration-files, add-zsh-dot-configuration,
add-zsh-xdg-configuration, add-bash-configuration): Add leading dots.
* gnu/home/services/symlink-manager.scm (update-symlinks-script): Remove
leading dot.
---
gnu/home/services.scm | 8
gnu/home/services/shells.scm | 20 ++--
gnu/home/services/symlink-manager.scm | 2 +-
gnu/home/services/xdg.scm | 2 +-
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index 2f441eb968..17acfcdb09 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -285,10 +285,10 @@ (define home-files-service-type
(description "Files that will be put in
@file{~~/.guix-home/files}, and further processed during activation.")))
-(define xdg-configuration-files-directory "config")
+(define xdg-configuration-files-directory ".config")
(define (xdg-configuration-files files)
- "Add config/ prefix to each file-path in FILES."
+ "Add .config/ prefix to each file-path in FILES."
(map (match-lambda
((file-path . rest)
(cons (string-append xdg-configuration-files-directory "/" file-path)
@@ -296,7 +296,7 @@ (define (xdg-configuration-files files)
files))
(define home-xdg-configuration-files-service-type
- (service-type (name 'home-files)
+ (service-type (name 'home-xdg-configuration)
(extensions
(list (service-extension home-files-service-type
xdg-configuration-files)))
@@ -304,7 +304,7 @@ (define home-xdg-configuration-files-service-type
(extend append)
(default-value '())
(description "Files that will be put in
-@file{~~/.guix-home/files/config}, and further processed during activation.")))
+@file{~~/.guix-home/files/.config}, and further processed during activation.")))
(define %initialize-gettext
#~(begin
diff --git a/gnu/home/services/shells.scm b/gnu/home/services/shells.scm
index 086fe7d8c4..8389968c96 100644
--- a/gnu/home/services/shells.scm
+++ b/gnu/home/services/shells.scm
@@ -77,7 +77,7 @@ (define-configuration home-shell-profile-configuration
really know what you do."))
(define (add-shell-profile-file config)
- `(("profile"
+ `((".profile"
,(mixed-text-file
"shell-profile"
"\
@@ -211,16 +211,16 @@ (define (zsh-file-by-field config field)
(zsh-serialize-field config field)
(define (zsh-get-configuration-files config)
- `(("zprofile" ,(zsh-file-by-field config 'zprofile)) ;; Always non-empty
+ `((".zprofile" ,(zsh-file-by-field config 'zprofile)) ;; Always non-empty
,@(if (and (zsh-field-not-empty? config 'zshenv)
(zsh-field-not-empty? config 'environment-variables))
- `(("zshenv" ,(zsh-file-by-field config 'zshenv))) '())
+ `((".zshenv" ,(zsh-file-by-field config 'zshenv))) '())
,@(if (zsh-field-not-empty? config 'zshrc)
- `(("zshrc" ,(zsh-file-by-field config 'zshrc))) '())
+ `((".zshrc" ,(zsh-file-by-field config 'zshrc))) '())
,@(if (zsh-field-not-empty? config 'zlogin)
- `(("zlogin" ,(zsh-file-by-field config 'zlogin))) '())
+ `((".zlogin" ,(zsh-file-by-field config 'zlogin))) '())
,@(if (zsh-field-not-empty? config 'zlogout)
- `(("zlogout" ,(zsh-file-by-field config 'zlogout))) '(
+ `((".zlogout" ,(zsh-file-by-field config 'zlogout))) '(
(define (add-zsh-dot-configuration config)
(define zshenv-auxiliary-file
@@ -230,14 +230,14 @@ (define zshenv-auxiliary-file
"[[ -f $ZDOTDI
bug#52808: Guix home should not assume that all targets are dot files
On 2022-03-20 22:00, Ludovic Courtès wrote:
> I wrote:
>
>> I finally got around to committing it as
>> 6da2a5a5655668f42ec5b26f875ddbc498e132b6. Thank you!
>
> I hit “close” too quickly: we still need the patch that changes
> ‘home-files-service-type’ and/or symlink-manager.scm to not prepend a
> dot, so reopening! :-)
>
> Ludo’.
A few more minor fixes:
From 629466d23308e135c4a46951e5ea568677c5ec00 Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Tue, 29 Mar 2022 11:15:56 +0300
Subject: [PATCH 1/2] home: shells: Rename zsh related functions.
* gnu/home/services/shells.scm (home-zsh-service-type): Make zsh related
private functions more consistently named.
---
gnu/home/services/shells.scm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gnu/home/services/shells.scm b/gnu/home/services/shells.scm
index fb728893e3..086fe7d8c4 100644
--- a/gnu/home/services/shells.scm
+++ b/gnu/home/services/shells.scm
@@ -222,7 +222,7 @@ (define (zsh-get-configuration-files config)
,@(if (zsh-field-not-empty? config 'zlogout)
`(("zlogout" ,(zsh-file-by-field config 'zlogout))) '(
-(define (zsh-home-files config)
+(define (add-zsh-dot-configuration config)
(define zshenv-auxiliary-file
(mixed-text-file
"zshenv-auxiliary"
@@ -233,7 +233,7 @@ (define zshenv-auxiliary-file
`(("zshenv" ,zshenv-auxiliary-file))
(zsh-get-configuration-files config)))
-(define (zsh-xdg-configuration-files config)
+(define (add-zsh-xdg-configuration config)
(if (home-zsh-configuration-xdg-flavor? config)
(map
(lambda (lst)
@@ -298,10 +298,10 @@ (define home-zsh-service-type
(extensions
(list (service-extension
home-files-service-type
-zsh-home-files)
+add-zsh-dot-configuration)
(service-extension
home-xdg-configuration-files-service-type
-zsh-xdg-configuration-files)
+add-zsh-xdg-configuration)
(service-extension
home-profile-service-type
add-zsh-packages)))
--
2.34.0
From a71346b059691a982a7dc0c7f4fd708b49566500 Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Tue, 29 Mar 2022 11:56:48 +0300
Subject: [PATCH 2/2] home: symlink-manager: Handle non-existing directory
during cleanup.
* gnu/home/services/symlink-manager.scm (update-symlinks-script): Handle
non-existing directory during cleanup.
---
gnu/home/services/symlink-manager.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/home/services/symlink-manager.scm b/gnu/home/services/symlink-manager.scm
index 3b851229f3..80ca73fed8 100644
--- a/gnu/home/services/symlink-manager.scm
+++ b/gnu/home/services/symlink-manager.scm
@@ -142,6 +142,7 @@ (define (strip file)
#t
(G_ "Skipping ~a (not an empty directory)... done\n")
directory))
+ ((= ENOENT errno) #t)
((= ENOTDIR errno) #t)
(else
(apply throw args)
--
2.34.0
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
On 2022-03-20 22:00, Ludovic Courtès wrote:
> I wrote:
>
>> I finally got around to committing it as
>> 6da2a5a5655668f42ec5b26f875ddbc498e132b6. Thank you!
>
> I hit “close” too quickly: we still need the patch that changes
> ‘home-files-service-type’ and/or symlink-manager.scm to not prepend a
> dot, so reopening! :-)
>
> Ludo’.
Forgot to update fish home service in previous patch series, please
apply this patch as well:
From 7d9cf53ab574c8ab468bfdae2798de65af6c00b5 Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Mon, 28 Mar 2022 12:14:10 +0300
Subject: [PATCH] home: shells: Migrate fish to xdg-configuration-files.
* gnu/home/services.scm (home-fish-service-type): Migrate to
home-xdg-configuration-files-service-type.
---
gnu/home/services/shells.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/home/services/shells.scm b/gnu/home/services/shells.scm
index 7b9769bcf3..fb728893e3 100644
--- a/gnu/home/services/shells.scm
+++ b/gnu/home/services/shells.scm
@@ -586,7 +586,7 @@ (define-configuration home-fish-configuration
serialize-fish-abbreviations))
(define (fish-files-service config)
- `(("config/fish/config.fish"
+ `(("fish/config.fish"
,(mixed-text-file
"fish-config.fish"
#~(string-append "\
@@ -650,7 +650,7 @@ (define home-fish-service-type
(service-type (name 'home-fish)
(extensions
(list (service-extension
-home-files-service-type
+home-xdg-configuration-files-service-type
fish-files-service)
(service-extension
home-profile-service-type
--
2.34.0
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#54372: SVG icons are not rendered in Qt application (qTox)
In qTox some icons inside interaface are not rendered. The log contains a lot of related warnings: --8<---cut here---start->8--- AL lib: (WW) Querying error state on null context (implicitly 0xa004) [10:09:16.339 UTC] nexus.cpp:86 : Debug: Starting up [10:09:16.539 UTC] persistence/profile.cpp:318 : Debug: Self avatar not found, will broadcast empty avatar to friends [10:09:16.577 UTC] :0 : Warning: Could not create pixmap from /home/bob/.local/share/qTox/themes/default/chatForm/callButton.svg [10:09:16.578 UTC] :0 : Warning: Could not create pixmap from /home/bob/.local/share/qTox/themes/default/chatForm/callButton.svg [10:09:16.578 UTC] :0 : Warning: Could not create pixmap from /home/bob/.local/share/qTox/themes/default/chatForm/videoButton.svg --8<---cut here---end--->8--- I copied and used a theme from qtox repository instead of built-in to make sure that files are valid SVGs, but it doesn't matter. Also, built a latest qtox release, same issue here. Reported it to qTox, but it seems the problem is related to qt or qtsvg. https://github.com/qTox/qTox/issues/6555 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
On 2022-03-05 23:44, Ludovic Courtès wrote:
> Hi Andrew,
>
> The patches reached my mailbox around the time I went on vacation and
> then fell through the cracks. Sorry about that!
>
> Andrew Tropin skribis:
>
>> After that patch series is merged we can give a time for users to
>> migrate their self-made home services to xdg-configuration-files and
>> after for example 2 weeks, remove special handling of dots for
>> home-files.
>
> Sounds like a plan!
>
>> From 0cd37bbc724f9c793898c2655bdd1c335045c5f0 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 10:55:01 +0300
>> Subject: [PATCH 1/5] home: Explicitly connect home-file and symlink-manager
>> services.
>>
>> * gnu/home/services.scm (home-files-directory): New variable.
>> * gnu/home/symlink-manager.scm (update-symlinks-script): Use
>> home-files-directory variable from (gnu home services).
>
> [...]
>
>> -(description "Configuration files for programs that
>> -will be put in @file{~/.guix-home/files}.")))
>> +(description (format #f "Files that will be put in
>> +@file{~~/.guix-home/~a}, and further processed during activation."
>> + home-files-directory
>
> This hunk would prevent i18n so I suggest dropping it (you can mention
> ‘home-files-directory’ in a margin comment for good measure).
>
> Otherwise LGTM.
>
Done.
>
>> From 23f7095d60b18b52de0d1aa314c4012cdf55a046 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 11:03:02 +0300
>> Subject: [PATCH 2/5] home: Add home-xdg-configuration-files service.
>>
>> * gnu/home/services.scm (home-xdg-configuration-files): New variable.
>
> [...]
>
>> +(define xdg-configuration-files-subdir "config")
>>
>> +(define (xdg-configuration-files files)
>> + (map (lambda (lst)
>> + (cons (string-append xdg-configuration-files-subdir
>> + "/" (car lst)) (cdr lst)))
>> + files))
>
> I’d just call it “.config” (instead of “config”). That way, there
> wouldn’t be any special treatment. WDYT?
Will be done in next patch series.
>
> Also: s/subdir/directory/, and please use ‘match’ instead of car/cdr
> (info "(guix) Coding Style").
Done, done.
>
>
>> +(description (format #f "Files that will be put in
>> +@file{~~/.guix-home/~a/~a}, and further processed during activation."
>> + home-files-directory
>> + xdg-configuration-files
>
> Same as above: drop ‘format’ and write ~/.guix-home/files/.config.
>
Done.
>
>> From 11f23a48d480a91d6bfba0ff55c1a9831585a4ee Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 15:03:44 +0300
>> Subject: [PATCH 3/5] home: shells: Migrate zsh to xdg-configuration-files.
>>
>> * gnu/home/services.scm (home-zsh-service-type): Additionally extend
>> home-xdg-configuration-files-service-type.
>
> [...]
>
>> From ef4c3bbcc0c8c1a251f4ad6c494f8ed30adf45f2 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 15:34:46 +0300
>> Subject: [PATCH 4/5] home: Migrate fountutils and xdg modules to
>> xdg-configuration-files.
>>
>> * gnu/home/services/fontutils.scm (home-fontconfig-service-type): Migrate to
>> xdg-configuration-files.
>> * gnu/home/services/xdg.scm (home-xdg-user-directories-service-type,
>> home-xdg-mime-applications-service-type): Migrate to xdg-configuration-files.
>
> Neat!
>
>> From 089683bbd301f6e085f00fbd53713f335abac40e Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 16:14:23 +0300
>> Subject: [PATCH 5/5] home: symlink-manager: Respect XDG_CONFIG_HOME during
>> activation.
>>
>> * gnu/home/services/symlink-manager.scm (update-symlinks-script): Respect
>> XDG_CONFIG_HOME during activation.
>
> I propose to postpone this one after
> <https://issues.guix.gnu.org/54180>, and I even offer to rebase it
> myself if you want. :-)
>
> Could you send updated patches?
>
> Thanks in advance, and apologies again for the delay!
>
> Ludo’.
Added two minor patches for symlink-manager.
From 3a6dc64d3366aa37507c83c598cbddb0f0815b6d Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Fri, 11 Mar 2022 08:43:04 +0300
Subject: [PATCH 1/2] home: symlink-manager: Use existing home-directory
symbol.
* gnu/home/services/symlink-manager.scm (update-symlinks-script): Use
existing home-directory sy
bug#52808: Guix home should not assume that all targets are dot files
On 2022-03-05 23:44, Ludovic Courtès wrote:
> Hi Andrew,
>
> The patches reached my mailbox around the time I went on vacation and
> then fell through the cracks. Sorry about that!
No problem, I hope you had a good rest and got some fun!
>
> Andrew Tropin skribis:
>
>> After that patch series is merged we can give a time for users to
>> migrate their self-made home services to xdg-configuration-files and
>> after for example 2 weeks, remove special handling of dots for
>> home-files.
>
> Sounds like a plan!
>
>> From 0cd37bbc724f9c793898c2655bdd1c335045c5f0 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 10:55:01 +0300
>> Subject: [PATCH 1/5] home: Explicitly connect home-file and symlink-manager
>> services.
>>
>> * gnu/home/services.scm (home-files-directory): New variable.
>> * gnu/home/symlink-manager.scm (update-symlinks-script): Use
>> home-files-directory variable from (gnu home services).
>
> [...]
>
>> -(description "Configuration files for programs that
>> -will be put in @file{~/.guix-home/files}.")))
>> +(description (format #f "Files that will be put in
>> +@file{~~/.guix-home/~a}, and further processed during activation."
>> + home-files-directory
>
> This hunk would prevent i18n so I suggest dropping it (you can mention
> ‘home-files-directory’ in a margin comment for good measure).
>
> Otherwise LGTM.
>
Will fix it.
>> From 23f7095d60b18b52de0d1aa314c4012cdf55a046 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 11:03:02 +0300
>> Subject: [PATCH 2/5] home: Add home-xdg-configuration-files service.
>>
>> * gnu/home/services.scm (home-xdg-configuration-files): New variable.
>
> [...]
>
>> +(define xdg-configuration-files-subdir "config")
>>
>> +(define (xdg-configuration-files files)
>> + (map (lambda (lst)
>> + (cons (string-append xdg-configuration-files-subdir
>> + "/" (car lst)) (cdr lst)))
>> + files))
>
> I’d just call it “.config” (instead of “config”). That way, there
> wouldn’t be any special treatment. WDYT?
This is a patch series, which introduces preliminary changes and keeps
backward compatibility, so people, who have their personal home services
will be able to gradually migrate them to home-xdg-configuration-files.
In the next patch series special treatment of the dots will be removed
and this directory will become ".config".
>
> Also: s/subdir/directory/, and please use ‘match’ instead of car/cdr
> (info "(guix) Coding Style").
>
Sure.
>> +(description (format #f "Files that will be put in
>> +@file{~~/.guix-home/~a/~a}, and further processed during activation."
>> + home-files-directory
>> + xdg-configuration-files
>
> Same as above: drop ‘format’ and write ~/.guix-home/files/.config.
>
>> From 11f23a48d480a91d6bfba0ff55c1a9831585a4ee Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 15:03:44 +0300
>> Subject: [PATCH 3/5] home: shells: Migrate zsh to xdg-configuration-files.
>>
>> * gnu/home/services.scm (home-zsh-service-type): Additionally extend
>> home-xdg-configuration-files-service-type.
>
> [...]
>
>> From ef4c3bbcc0c8c1a251f4ad6c494f8ed30adf45f2 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 15:34:46 +0300
>> Subject: [PATCH 4/5] home: Migrate fountutils and xdg modules to
>> xdg-configuration-files.
>>
>> * gnu/home/services/fontutils.scm (home-fontconfig-service-type): Migrate to
>> xdg-configuration-files.
>> * gnu/home/services/xdg.scm (home-xdg-user-directories-service-type,
>> home-xdg-mime-applications-service-type): Migrate to xdg-configuration-files.
>
> Neat!
>
>> From 089683bbd301f6e085f00fbd53713f335abac40e Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin
>> Date: Fri, 11 Feb 2022 16:14:23 +0300
>> Subject: [PATCH 5/5] home: symlink-manager: Respect XDG_CONFIG_HOME during
>> activation.
>>
>> * gnu/home/services/symlink-manager.scm (update-symlinks-script): Respect
>> XDG_CONFIG_HOME during activation.
>
> I propose to postpone this one after
> <https://issues.guix.gnu.org/54180>, and I even offer to rebase it
> myself if you want. :-)
>
> Could you send updated patches?
Sure, I even replied to bug#54180 ticket :) Waiting for the merge, after
that will update patches to address your comments and will rebase them
on top of bug#54180. Also, I need to update the manual as well.
>
> Thanks in advance, and apologies again for the delay!
>
> Ludo’.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
On 2022-02-11 18:52, Andrew Tropin wrote:
> On 2022-02-08 10:46, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Andrew Tropin skribis:
>>
>>>>> You can elaborate more on what you try to achieve and I can try to give
>>>>> you a recommendation how to implement it.
>>>>
>>>> I’d expect ‘home-files-service-type’ to do just that: add files to the
>>>> home directory, without trying to be smart.
>>>>
>>>> Would it make sense to distinguish between ‘home-files’ and (say)
>>>> ‘home-xdg-configuration-files’?
>>>
>>> Yep, I can do that, actually, it will be even better for the purpose I
>>> originally had. I'll make home-files to store files as it is and
>>> symlink manager not to add leading dots and a separate folder for
>>> xdg configs.
>>
>> Neat.
>>
>>> Ludo, Nick, what do you think about following names?
>>> ~/.guix-home/home-dir-files/
>>> ~/.guix-home/xdg-config-dir-files/
>>
>> I’d make it ‘…/home-files’ and ‘…/xdg-configuration-files’, but that’s a
>> detail.
>>
>>>> I’d also suggest removing special handling of HOME/files in
>>>> symlink-manager.scm. Relations between the various components of Guix
>>>> Home should preferably be made explicit via service extensions, and not
>>>> implicit through conventions like this ‘files’ sub-directory.
>>>>
>>>> Thoughts?
>>>
>>> Unfortunatelly, I don't know how to implement polymorphic behavior the
>>> other way with current extension mechanism, so I would prefer to keep
>>> this relation implicit,
>>
>> I’m not sure I follow but maybe I should try by myself to get a better
>> understanding.
>>
>> Thanks for your feedback!
>>
>> Ludo’.
>
> I decided to go one step at a time, and prepared a patch series, which:
>
> 1. Adds an explicit connection between home-files-service-type and
> symlink-manager by introducing a global constant used by both services.
>
> 2. Adds a home-xdg-configuration-files-service-type, which accepts a
> list of files for XDG_CONFIG_DIR, `(("mpv/mpv.conf" ,file-like-here))
>
> 3. Migrates all (gnu home services) to xdg-configuration-files.
>
> 4. Make symlink-manager respect XDG_CONIFG_HOME and
> xdg-configuration-files-subdir.
>
> After that patch series is merged we can give a time for users to
> migrate their self-made home services to xdg-configuration-files and
> after for example 2 weeks, remove special handling of dots for
> home-files.
>
> From 0cd37bbc724f9c793898c2655bdd1c335045c5f0 Mon Sep 17 00:00:00 2001
> From: Andrew Tropin
> Date: Fri, 11 Feb 2022 10:55:01 +0300
> Subject: [PATCH 1/5] home: Explicitly connect home-file and symlink-manager
> services.
>
> * gnu/home/services.scm (home-files-directory): New variable.
> * gnu/home/symlink-manager.scm (update-symlinks-script): Use
> home-files-directory variable from (gnu home services).
> ---
> gnu/home/services.scm | 23 ++-
> gnu/home/services/symlink-manager.scm | 17 +
> 2 files changed, 23 insertions(+), 17 deletions(-)
>
> diff --git a/gnu/home/services.scm b/gnu/home/services.scm
> index 1cd19ce7f9..e4e3717b80 100644
> --- a/gnu/home/services.scm
> +++ b/gnu/home/services.scm
> @@ -43,6 +43,8 @@ (define-module (gnu home services)
> home-run-on-change-service-type
> home-provenance-service-type
>
> +home-files-directory
> +
> fold-home-service-types
> home-provenance
>
> @@ -74,12 +76,11 @@ (define-module (gnu home services)
> ;;; file (details described in the manual).
> ;;;
> ;;; home-files-service-type is similar to etc-service-type, but doesn't
> extend
> -;;; home-activation, because deploy mechanism for config files is pluggable
> and
> -;;; can be different for different home environments: The default one is
> called
> -;;; symlink-manager (will be introudced in a separate patch series), which
> creates
> -;;; links for various dotfiles (like $XDG_CONFIG_HOME/$APP/...) to store,
> but is
> -;;; possible to implement alternative approaches like read-only home from
> Julien's
> -;;; guix-home-manager.
> +;;; home-activation, because deploy mechanism for config files is pluggable
> +;;; and can be different for different home environments: The default one is
> +;;; called symlink-manager, which creates links for various dotfiles and xdg
> +;;; configuration files to store, but is possible to implement alternative
> +;;; approaches like read
bug#52808: Guix home should not assume that all targets are dot files
On 2022-02-08 10:46, Ludovic Courtès wrote:
> Hi,
>
> Andrew Tropin skribis:
>
>>>> You can elaborate more on what you try to achieve and I can try to give
>>>> you a recommendation how to implement it.
>>>
>>> I’d expect ‘home-files-service-type’ to do just that: add files to the
>>> home directory, without trying to be smart.
>>>
>>> Would it make sense to distinguish between ‘home-files’ and (say)
>>> ‘home-xdg-configuration-files’?
>>
>> Yep, I can do that, actually, it will be even better for the purpose I
>> originally had. I'll make home-files to store files as it is and
>> symlink manager not to add leading dots and a separate folder for
>> xdg configs.
>
> Neat.
>
>> Ludo, Nick, what do you think about following names?
>> ~/.guix-home/home-dir-files/
>> ~/.guix-home/xdg-config-dir-files/
>
> I’d make it ‘…/home-files’ and ‘…/xdg-configuration-files’, but that’s a
> detail.
>
>>> I’d also suggest removing special handling of HOME/files in
>>> symlink-manager.scm. Relations between the various components of Guix
>>> Home should preferably be made explicit via service extensions, and not
>>> implicit through conventions like this ‘files’ sub-directory.
>>>
>>> Thoughts?
>>
>> Unfortunatelly, I don't know how to implement polymorphic behavior the
>> other way with current extension mechanism, so I would prefer to keep
>> this relation implicit,
>
> I’m not sure I follow but maybe I should try by myself to get a better
> understanding.
>
> Thanks for your feedback!
>
> Ludo’.
I decided to go one step at a time, and prepared a patch series, which:
1. Adds an explicit connection between home-files-service-type and
symlink-manager by introducing a global constant used by both services.
2. Adds a home-xdg-configuration-files-service-type, which accepts a
list of files for XDG_CONFIG_DIR, `(("mpv/mpv.conf" ,file-like-here))
3. Migrates all (gnu home services) to xdg-configuration-files.
4. Make symlink-manager respect XDG_CONIFG_HOME and
xdg-configuration-files-subdir.
After that patch series is merged we can give a time for users to
migrate their self-made home services to xdg-configuration-files and
after for example 2 weeks, remove special handling of dots for
home-files.
From 0cd37bbc724f9c793898c2655bdd1c335045c5f0 Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Fri, 11 Feb 2022 10:55:01 +0300
Subject: [PATCH 1/5] home: Explicitly connect home-file and symlink-manager
services.
* gnu/home/services.scm (home-files-directory): New variable.
* gnu/home/symlink-manager.scm (update-symlinks-script): Use
home-files-directory variable from (gnu home services).
---
gnu/home/services.scm | 23 ++-
gnu/home/services/symlink-manager.scm | 17 +
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index 1cd19ce7f9..e4e3717b80 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -43,6 +43,8 @@ (define-module (gnu home services)
home-run-on-change-service-type
home-provenance-service-type
+home-files-directory
+
fold-home-service-types
home-provenance
@@ -74,12 +76,11 @@ (define-module (gnu home services)
;;; file (details described in the manual).
;;;
;;; home-files-service-type is similar to etc-service-type, but doesn't extend
-;;; home-activation, because deploy mechanism for config files is pluggable and
-;;; can be different for different home environments: The default one is called
-;;; symlink-manager (will be introudced in a separate patch series), which creates
-;;; links for various dotfiles (like $XDG_CONFIG_HOME/$APP/...) to store, but is
-;;; possible to implement alternative approaches like read-only home from Julien's
-;;; guix-home-manager.
+;;; home-activation, because deploy mechanism for config files is pluggable
+;;; and can be different for different home environments: The default one is
+;;; called symlink-manager, which creates links for various dotfiles and xdg
+;;; configuration files to store, but is possible to implement alternative
+;;; approaches like read-only home from Julien's guix-home-manager.
;;;
;;; home-run-on-first-login-service-type provides an @file{on-first-login} guile
;;; script, which runs provided gexps once, when user makes first login. It can
@@ -262,11 +263,14 @@ (define (assert-no-duplicates files)
(file-union "files" files))
+;; Used by symlink-manager
+(define home-files-directory "files")
+
(define (files-entry files)
"Return an entry for the @file{~/.guix-home/files}
directory containing FILES."
(with-monad %store-mona
bug#52808: Guix home should not assume that all targets are dot files
On 2022-01-30 18:13, Ludovic Courtès wrote:
> Hi Andrew,
>
> Andrew Tropin skribis:
>
>> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>>
>>> The following configuration results in a `~/.run` symlink being
>>> created. My expectation is that a `~/run` symlink is created
>>> instead. (ie. not a dotfile)
>>
>> Some how I missed it and not documented home-files-service-type in the
>> manual, I'll add it soon. Thank you for mentioning it. It should break
>> this expectation :)
>>
>>>> (home-environment
>>>> (services
>>>> (list (service
>>>> home-bash-service-type
>>>> (home-bash-configuration
>>>> (guix-defaults? #t)))
>>>> (simple-service 'my-files
>>>> home-files-service-type
>>>> `(("run" ,(local-file "run")))
>>>
>>> This applies to all other targets. My expectation is that the
>>> configuration should expect the exact target and not make an
>>> assumption that all targets are hidden files, since that allows for
>>> more utility:
>
> I share Nick’s surprise. :-)
>
> [...]
>
>> It's intentional and is a part of a design decision:
>>
>> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
>> chans.scm goes not to ~/.config/guix/channels.scm, but to
>> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
>> from ~/.config, absent dot should partially break this expectation.
>>
>> It's a bad practice to use something without "config/..." prefix and
>> generally it should be avoided, it still possible to use something
>> different in rare use-cases, for example for zsh: ("zshenv"
>> ,zshenv-file-like-here), because it's hard to implement the lookup for
>> initial configuration file other way for shells.
>
> Oh, I see.
>
>> You can elaborate more on what you try to achieve and I can try to give
>> you a recommendation how to implement it.
>
> I’d expect ‘home-files-service-type’ to do just that: add files to the
> home directory, without trying to be smart.
>
> Would it make sense to distinguish between ‘home-files’ and (say)
> ‘home-xdg-configuration-files’?
Yep, I can do that, actually, it will be even better for the purpose I
originally had. I'll make home-files to store files as it is and
symlink manager not to add leading dots and a separate folder for
xdg configs.
Ludo, Nick, what do you think about following names?
~/.guix-home/home-dir-files/
~/.guix-home/xdg-config-dir-files/
>
> The latter would copy files to $XDG_CONFIG_DIR at activation time,
> whereas the former would just copy them to $HOME.
>
>
> I’d also suggest removing special handling of HOME/files in
> symlink-manager.scm. Relations between the various components of Guix
> Home should preferably be made explicit via service extensions, and not
> implicit through conventions like this ‘files’ sub-directory.
>
> Thoughts?
Unfortunatelly, I don't know how to implement polymorphic behavior the
other way with current extension mechanism, so I would prefer to keep
this relation implicit, to make it possible to use a different machinery
instead of symlink manager to implement advanced techniques similar to
read-only home from Julien's guix-home-manager.
It's almost impossible to turn off symlink manager unintentionally, so
it should be ok.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
On 2022-01-28 08:33, Nick Zalutskiy wrote:
> Hi Andrew,
>
> I have files that I consider my "home configuration" that do not go
> into .config or any other dot dir. For example, I place an executable
> shell script to automate some tasks in the home dir of every
> machine. The script is called `run` all I want to do is place it as
> ~/run Placing this file in PATH is not appropriate in my case.
>
> The current design makes this impossible to achieve it seems. I just
> live with `~/.run` now, but it is ergonomically cumbersome for reasons
> that are too obscure to go into.
You can extend activation home service with a script, which will symlink
a necessary executable to ~/run.
>
> Why not, just as an example:
>
> `("$XDG_CONFIG_DIR/guix/channels.scm" ,(local-file "./chans.scm"))`
The $XDG_CONFIG_DIR is not know at build-time, so it won't work.
Creating a literal files/$XDG_CONFIG_DIR directory is possible, but also
not ideal. However the idea sounds not that bad.
>
> Which is explicit and sets the right expectation without any other
> context. The implicit heuristics around how the input is interpreted
> are an unfortunate design decision in my opinion, they make a simple
> tool more difficult to use.
It's partially intentional to force users to stick to XDG specification
for config files and minimize the usage of dotfiles in $HOME. The
binaries are inteded to go to profile/bin or other directory on the
path. But it always possible to bypass this decision by directly
extending home-service-type or home-activation-service-type.
I see what you mean about implicit heuristics and mostly agree.
>
> Having said all that, the documentation helps a lot. Thank you for the
> patch!
Sure ;)
>
> Best,
>
> -Nick
>
> On Fri, Jan 28, 2022, at 5:51 AM, Andrew Tropin wrote:
>> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>>
>>> The following configuration results in a `~/.run` symlink being
>>> created. My expectation is that a `~/run` symlink is created
>>> instead. (ie. not a dotfile)
>>
>> Some how I missed it and not documented home-files-service-type in the
>> manual, I'll add it soon. Thank you for mentioning it. It should break
>> this expectation :)
>>
>>>> (home-environment
>>>> (services
>>>> (list (service
>>>> home-bash-service-type
>>>> (home-bash-configuration
>>>> (guix-defaults? #t)))
>>>> (simple-service 'my-files
>>>> home-files-service-type
>>>> `(("run" ,(local-file "run")))
>>>
>>> This applies to all other targets. My expectation is that the
>>> configuration should expect the exact target and not make an
>>> assumption that all targets are hidden files, since that allows for
>>> more utility:
>>>
>>>> (home-environment
>>>> (services
>>>> (list (service
>>>> home-bash-service-type
>>>> (home-bash-configuration
>>>> (guix-defaults? #t)))
>>>> (simple-service 'config-files
>>>> home-files-service-type
>>>> `(("run" ,(local-file "run"))
>>>> ("README.txt" ,(local-file "README.txt"))
>>>> (".config/guix/channels.scm" ,(local-file "config/guix
>>>> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
>>>> (".vimrc" ,(local-file "vimrc"))
>>>> (".gitconfig" ,(local-file "gitconfig")))
>>>
>>> Thank you,
>>>
>>> -Nick
>>
>> It's intentional and is a part of a design decision:
>>
>> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
>> chans.scm goes not to ~/.config/guix/channels.scm, but to
>> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
>> from ~/.config, absent dot should partially break this expectation.
>>
>> It's a bad practice to use something without "config/..." prefix and
>> generally it should be avoided, it still possible to use something
>> different in rare use-cases, for example for zsh: ("zshenv"
>> ,zshenv-file-like-here), because it's hard to implement the lookup for
>> initial configuration file other way for shells.
>>
>> You can elaborate more on what you try to achieve and I can try to give
>> you a recommendation how to implement it.
>>
>> --
>> Best regards,
>> Andrew Tropin
>>
>> Attachments:
>> * signature.asc
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#52808: Guix home should not assume that all targets are dot files
On 2021-12-26 12:17, Nick Zalutskiy wrote:
> The following configuration results in a `~/.run` symlink being
> created. My expectation is that a `~/run` symlink is created
> instead. (ie. not a dotfile)
Some how I missed it and not documented home-files-service-type in the
manual, I'll add it soon. Thank you for mentioning it. It should break
this expectation :)
>> (home-environment
>> (services
>> (list (service
>> home-bash-service-type
>> (home-bash-configuration
>> (guix-defaults? #t)))
>> (simple-service 'my-files
>> home-files-service-type
>> `(("run" ,(local-file "run")))
>
> This applies to all other targets. My expectation is that the
> configuration should expect the exact target and not make an
> assumption that all targets are hidden files, since that allows for
> more utility:
>
>> (home-environment
>> (services
>> (list (service
>> home-bash-service-type
>> (home-bash-configuration
>> (guix-defaults? #t)))
>> (simple-service 'config-files
>> home-files-service-type
>> `(("run" ,(local-file "run"))
>> ("README.txt" ,(local-file "README.txt"))
>> (".config/guix/channels.scm" ,(local-file "config/guix
>> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
>> (".vimrc" ,(local-file "vimrc"))
>> (".gitconfig" ,(local-file "gitconfig")))
>
> Thank you,
>
> -Nick
It's intentional and is a part of a design decision:
For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
chans.scm goes not to ~/.config/guix/channels.scm, but to
$XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
from ~/.config, absent dot should partially break this expectation.
It's a bad practice to use something without "config/..." prefix and
generally it should be avoided, it still possible to use something
different in rare use-cases, for example for zsh: ("zshenv"
,zshenv-file-like-here), because it's hard to implement the lookup for
initial configuration file other way for shells.
You can elaborate more on what you try to achieve and I can try to give
you a recommendation how to implement it.
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#53230: Disable authentication seems broken
On 2022-01-17 19:12, Ludovic Courtès wrote: > Andrew Tropin skribis: > >> On 2022-01-13 23:15, Ludovic Courtès wrote: >> >>> Andrew Tropin skribis: > > [...] > >>>>1468:0 4 (add-temp-root # >>>> #) >>>> In guix/serialization.scm: >>>>130:20 3 (write-store-path #>>> /gnu/store/pqn1xr6882907b41j6mybvs…> …) >>>> In unknown file: >>>>2 (string->utf8 #>>> /gnu/store/pqn1xr6882907b41j6mybvsg4218…>) >>>> In ice-9/boot-9.scm: >>>> 1685:16 1 (raise-exception _ #:continuable? _) >>>> 1685:16 0 (raise-exception _ #:continuable? _) >>>> >>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >>>> In procedure string->utf8: Wrong type argument in position 1 (expecting >>>> string): #>>> /gnu/store/pqn1xr6882907b41j6mybvsg4218kc0k-profile.drv => >>>> /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> >>> >>> Fixed in b1fc98d6b063a117fe2bcc19a60c8b9a48301593, thanks! > > [...] > >> In guix/scripts/time-machine.scm: >>158:28 2 (_) >> In unknown file: >>1 (string-append #> /gnu/store/18bv09fgcchf1ymxz5x4hq8bc9igsiq2-profile.drv => >> /gnu/store/gqbh9r3v6zba7066k2xbaf5hyqx15d8p-profile 7fc90d4bdd20> "/b…") >> In ice-9/boot-9.scm: >> 1685:16 0 (raise-exception _ #:continuable? _) >> >> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >> In procedure string-append: Wrong type (expecting string): #> /gnu/store/18bv09fgcchf1ymxz5x4hq8bc9igsiq2-profile.drv => >> /gnu/store/gqbh9r3v6zba7066k2xbaf5hyqx15d8p-profile 7fc90d4bdd20> > > My bad, fixed for good in a9cc79d9f3a4448b821ebd8f394a1c7b0004a0ba. Thank you for the fix!) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53230: Disable authentication seems broken
On 2022-01-13 23:15, Ludovic Courtès wrote: > Andrew Tropin skribis: > >> A day ago I found out that I can't pull/time-machine from my local guix >> repo with patches. After running guix time-machine -C ./channels ..., >> guix reported the following: >> >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> guix time-machine: warning: channel authentication disabled >> Computing Guix derivation for 'x86_64-linux'... - >> Backtrace: >> 18 (primitive-load "/home/bob/.config/guix/current/bin/guix") >> In guix/ui.scm: >>2206:7 17 (run-guix . _) >> 2169:10 16 (run-guix-command _ . _) >> In ice-9/boot-9.scm: >> 1752:10 15 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) >> 1747:15 14 (with-exception-handler #> ice-9/boot-9.…> …) >> In guix/store.scm: >> 671:3 13 (_) >> In ice-9/boot-9.scm: >> 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) >> In guix/store.scm: >>658:37 11 (thunk) >> In guix/status.scm: >> 802:4 10 (call-with-status-report _ _) >> In guix/store.scm: >>1320:8 9 (call-with-build-handler _ _) >>1320:8 8 (call-with-build-handler #> guix/ui.scm:…> …) >> 2123:24 7 (run-with-store # _ # _ # >> _ # …) >> In guix/inferior.scm: >>817:16 6 (_ _) >> In guix/store.scm: >> 1995:38 5 (_ #) >>1468:0 4 (add-temp-root # >> #) >> In guix/serialization.scm: >>130:20 3 (write-store-path #> /gnu/store/pqn1xr6882907b41j6mybvs…> …) >> In unknown file: >>2 (string->utf8 #> /gnu/store/pqn1xr6882907b41j6mybvsg4218…>) >> In ice-9/boot-9.scm: >> 1685:16 1 (raise-exception _ #:continuable? _) >> 1685:16 0 (raise-exception _ #:continuable? _) >> >> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >> In procedure string->utf8: Wrong type argument in position 1 (expecting >> string): #> /gnu/store/pqn1xr6882907b41j6mybvsg4218kc0k-profile.drv => >> /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> > > Fixed in b1fc98d6b063a117fe2bcc19a60c8b9a48301593, thanks! > > Ludo’. Oops, guix time-machine --disable-authentication -- describe fails with: --8<---cut here---start->8--- Backtrace: 7 (primitive-load "/home/bob/.config/guix/current/bin/guix") In guix/ui.scm: 2209:7 6 (run-guix . _) 2172:10 5 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 4 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) 1747:15 3 (with-exception-handler # _ #:unwind? _ #:unwind-for-type _) In guix/scripts/time-machine.scm: 158:28 2 (_) In unknown file: 1 (string-append # /gnu/store/gqbh9r3v6zba7066k2xbaf5hyqx15d8p-profile 7fc90d4bdd20> "/b…") In ice-9/boot-9.scm: 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure string-append: Wrong type (expecting string): # /gnu/store/gqbh9r3v6zba7066k2xbaf5hyqx15d8p-profile 7fc90d4bdd20> --8<---cut here---end--->8--- But guix time-machine --commit=bccfcef4 -- time-machine --disable-authentication -- describe works fine. Probably, I forgot to remove a workaround, when I was testing b1fc98d6b063a117fe2bcc19a60c8b9a48301593. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53230: Disable authentication seems broken
On 2022-01-13 23:15, Ludovic Courtès wrote: > Andrew Tropin skribis: > >> A day ago I found out that I can't pull/time-machine from my local guix >> repo with patches. After running guix time-machine -C ./channels ..., >> guix reported the following: >> >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> guix time-machine: warning: channel authentication disabled >> Computing Guix derivation for 'x86_64-linux'... - >> Backtrace: >> 18 (primitive-load "/home/bob/.config/guix/current/bin/guix") >> In guix/ui.scm: >>2206:7 17 (run-guix . _) >> 2169:10 16 (run-guix-command _ . _) >> In ice-9/boot-9.scm: >> 1752:10 15 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) >> 1747:15 14 (with-exception-handler #> ice-9/boot-9.…> …) >> In guix/store.scm: >> 671:3 13 (_) >> In ice-9/boot-9.scm: >> 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) >> In guix/store.scm: >>658:37 11 (thunk) >> In guix/status.scm: >> 802:4 10 (call-with-status-report _ _) >> In guix/store.scm: >>1320:8 9 (call-with-build-handler _ _) >>1320:8 8 (call-with-build-handler #> guix/ui.scm:…> …) >> 2123:24 7 (run-with-store # _ # _ # >> _ # …) >> In guix/inferior.scm: >>817:16 6 (_ _) >> In guix/store.scm: >> 1995:38 5 (_ #) >>1468:0 4 (add-temp-root # >> #) >> In guix/serialization.scm: >>130:20 3 (write-store-path #> /gnu/store/pqn1xr6882907b41j6mybvs…> …) >> In unknown file: >>2 (string->utf8 #> /gnu/store/pqn1xr6882907b41j6mybvsg4218…>) >> In ice-9/boot-9.scm: >> 1685:16 1 (raise-exception _ #:continuable? _) >> 1685:16 0 (raise-exception _ #:continuable? _) >> >> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >> In procedure string->utf8: Wrong type argument in position 1 (expecting >> string): #> /gnu/store/pqn1xr6882907b41j6mybvsg4218kc0k-profile.drv => >> /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> > > Fixed in b1fc98d6b063a117fe2bcc19a60c8b9a48301593, thanks! > Thank you very much! Tested this commit, --disable-authentication works now!) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53230: Acknowledgement (Disable authentication seems broken)
Seems issue appeared after 9f371f23eb. This one fails: guix time-machine --commit=9f371f23ebfa20f70b3bfd55dc459b683f21ba91 -- time-machine --commit=d87d6d6812 --disable-authentication -- describe This one works: guix time-machine --commit=1a0696e0a6dcde342094712957037c586f572efb -- time-machine --commit=d56a29edb7 --disable-authentication -- describe -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53230: Disable authentication seems broken
A day ago I found out that I can't pull/time-machine from my local guix repo with patches. After running guix time-machine -C ./channels ..., guix reported the following: --8<---cut here---start->8--- Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix time-machine: warning: channel authentication disabled Computing Guix derivation for 'x86_64-linux'... - Backtrace: 18 (primitive-load "/home/bob/.config/guix/current/bin/guix") In guix/ui.scm: 2206:7 17 (run-guix . _) 2169:10 16 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 15 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) 1747:15 14 (with-exception-handler # …) In guix/store.scm: 671:3 13 (_) In ice-9/boot-9.scm: 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/store.scm: 658:37 11 (thunk) In guix/status.scm: 802:4 10 (call-with-status-report _ _) In guix/store.scm: 1320:8 9 (call-with-build-handler _ _) 1320:8 8 (call-with-build-handler # …) 2123:24 7 (run-with-store # _ # _ # _ # …) In guix/inferior.scm: 817:16 6 (_ _) In guix/store.scm: 1995:38 5 (_ #) 1468:0 4 (add-temp-root # #) In guix/serialization.scm: 130:20 3 (write-store-path # …) In unknown file: 2 (string->utf8 #) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure string->utf8: Wrong type argument in position 1 (expecting string): # /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> --8<---cut here---end--->8--- Later I discovered, that the problem isn't related to my local changes, it reproduces with main guix channel too, also, other people on their setups reporting the same problem. Way to reproduce: 1. Find any commit you didn't built guix for earlier. For example a79ad5fce5. 2.1 Update guix to the latest version and do describe under time-machine: guix pull && guix time-machine --commit=a79ad5fce5 --disable-authentication -- describe 2.2 or more preciese and less invasive alternative: guix time-machine --commit=0f869287ebf -- time-machine --commit=a79ad5fce5 --disable-authentication -- describe To be sure, I tried it on a separate machine with only guix channel, which wasn't updated for a while. 2.2 failed the same way as described at the beginning, but when I tried just: guix time-machine --commit=a79ad5fce5 --disable-authentication -- describe it worked. Also, I did similiar test like in 2.1 with guix pull and after that guix pull --roll-back, the result is the same. Skimming throught the latest changes didn't bring any results yet. Bisecting and building guix, will let you know, if/when I find more. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#51918: home-bash-service-type adds the defaults and aliases to the end of the file
On 2021-12-19 09:45, Xinglu Chen wrote: > Hi, > > On Wed, Nov 17 2021, Andrew Tropin wrote: > >> Test in guix-home.sh looks correct, but it fails: >> https://git.savannah.gnu.org/cgit/guix.git/tree/tests/guix-home.sh?h=5eb5c0789f34e87ee417a53ddfcfa3b6521bb337#n98 >> >> Seems something changed in home-bash-service-type, for some reason it >> adds the serialized content of aliases field and guix-bashrc variable >> after the content of bashrc field. > > This was changed in commit 2f665d4309053d5a9fe25bc93ee78d55dbc30cb7 > after discussing it with Liliana[1]. I didn’t really have a strong > opinion on the order of the things; do you think that it should be changed? > > [1]: <https://yhetil.org/guix/87k0hs57uu@disroot.org/> Seems Ludovic fixed it in c322d97832081e6e1913c6311616030d1fad4ee2, I just had a slightly outdated local repository, when I was reporting this bug, everything is ok now) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
On 2021-12-03 21:46, Liliana Marie Prikler wrote: > At long last, I'm pushing the patch to keep -pkg.el files as well as to > load them from guix-emacs during package-initialize. I'll hereby be > closing this bug. Andrew, if you wish to write a phase that adds such > a file for the packages currently lacking them, I'm pretty sure we can > do with a new bug number for that :) I implemented this phase in issues.guix.gnu.org/52388, I have it applied to my local guix fork and I didn't notice any issues with it, however, emacs packages built without emacs-build-system will require tweaking. Everyone reading this thread can jump to [1] and check it out =) [1]: The mail thread id is 871r2mrleb@trop.in > > Thanks everyone involved for your help and patience. Cheers > -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
On 2021-12-03 21:46, Liliana Marie Prikler wrote: > At long last, I'm pushing the patch to keep -pkg.el files as well as to > load them from guix-emacs during package-initialize. I'll hereby be > closing this bug. Andrew, if you wish to write a phase that adds such > a file for the packages currently lacking them, I'm pretty sure we can > do with a new bug number for that :) > > Thanks everyone involved for your help and patience. Cheers > Thank you very much for applying this change!) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#51848: `make && make check` fails
On 2021-11-15 17:01, zimoun wrote:
> Hi,
>
> On dim., 14 nov. 2021 at 15:50, Rostislav Svoboda
> wrote:
>
>> FAIL: tests/home-import.scm
>> FAIL: tests/guix-home.sh
>
> I confirm the failures using Guix ce9b9e7cba.
>
>
> --8<---cut here---start->8---
> ;;; (fail (begin (use-modules (gnu home) (gnu packages) (gnu services) (guix
> gexp) (gnu home services shells)) (home-environment (packages (map
> specification->package (list))) (services (list (service
> home-bash-service-type (home-bash-configuration (aliases (quote ())) (bashrc
> (list (local-file "/tmp/guix-config/.bashrc" "bashrc") #f)
> test-name: manifest->code: Bash service
> location: /home/sitour/src/guix/wk/remove-python2/tests/home-import.scm:181
> source:
> + (test-assert
> + "manifest->code: Bash service"
> + (eval-test-with-home-environment
> + '((".bashrc" . "echo 'hello guix'"))
> + (make-manifest '())
> + match-home-environment-bash-service))
> actual-value: #f
> result: FAIL
> --8<---cut here---end--->8---
https://issues.guix.gnu.org/51918 may be related
>
> --8<---cut here---start->8---
> + set -e
> + guix home --version
> guix show (GNU Guix) 1.3.0.8404-ce9b9
> Copyright (C) 2021 the Guix authors
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> ++ guile -c '(use-modules (guix config))(display %storedir)'
> + NIX_STORE_DIR=/gnu/store
> ++ guile -c '(use-modules (guix config))(display %localstatedir)'
> + localstatedir=/var
> + GUIX_DAEMON_SOCKET=/var/guix/daemon-socket/socket
> + export NIX_STORE_DIR GUIX_DAEMON_SOCKET
> + guile -c '(use-modules (guix)) (exit (false-if-exception
> (open-connection)))'
> ++ dirname /gnu/store
> + STORE_PARENT=/gnu
> + export STORE_PARENT
> + test /gnu = /
> ++ mktemp -d
> + test_directory=/tmp/tmp.ScA50H2Z6n
> + trap 'chmod -Rf +w "$test_directory"; rm -rf "$test_directory"' EXIT
> + cd /tmp/tmp.ScA50H2Z6n
> + HOME=/tmp/tmp.ScA50H2Z6n
> + export HOME
> + printf '# dot-bashrc test file for guix home'
> + cat
> + guix home reconfigure /tmp/tmp.ScA50H2Z6n/home.scm
> guix home: error: reference to invalid output 'out' of derivation
> '/gnu/store/a6cwlz5yibi7w3pfm60j26inf434ard2-on-first-login.drv'
This one was fixed in e5d8302b2ce596a0518ea5bd79b338f68a3246eb.
https://issues.guix.gnu.org/51915
> + chmod -Rf +w /tmp/tmp.ScA50H2Z6n
> + rm -rf /tmp/tmp.ScA50H2Z6n
> FAIL tests/guix-home.sh (exit status: 1)
> --8<---cut here---end--->8---
>
>
> Cheers,
> simon
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#51918: home-bash-service-type adds the defaults and aliases to the end of the file
Test in guix-home.sh looks correct, but it fails: https://git.savannah.gnu.org/cgit/guix.git/tree/tests/guix-home.sh?h=5eb5c0789f34e87ee417a53ddfcfa3b6521bb337#n98 Seems something changed in home-bash-service-type, for some reason it adds the serialized content of aliases field and guix-bashrc variable after the content of bashrc field. Original implementation works as expected and adds the content of bashrc to the end of ~/.bashrc. --8<---cut here---start->8--- (list ((@ (gnu services) service) (@ (gnu home-services shells) home-bash-service-type) ((@ (gnu home-services shells) home-bash-configuration) (guix-defaults? #t) (bashrc (list "echo hi" ((@ (gnu services) simple-service) 'test-bash (@ (gnu home-services shells) home-bash-service-type) ((@ (gnu home-services shells) home-bash-extension) (bashrc (list "echo very hi") --8<---cut here---end--->8--- https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/shells.scm -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#50945: Guix home: No such file or directory: "/run/user/1003/on-first-login-executed"
On 2021-11-05 17:58, Xinglu Chen wrote:
> Hi,
>
> On Thu, Oct 07 2021, Andrew Tropin wrote:
>
>> 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---
>>>
>>> [...]
>>
>> 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: on-first-login: Check if XDG_RUNTIME_DIR
>> exists.
>>
>> * gnu/home-services.scm (on-first-login): on-first-login won't execute
>> anything if XDG_RUNTIME_DIR doesn't exists.
>> ---
>> gnu/home-services.scm | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/gnu/home-services.scm b/gnu/home-services.scm
>> index 9f1e986616..0b77a1321d 100644
>> --- a/gnu/home-services.scm
>> +++ b/gnu/home-services.scm
>> @@ -286,8 +286,11 @@ will be put in @file{~/.guix-home/files}.")))
>> ;; XDG_RUNTIME_DIR dissapears on logout, that means such trick
>> ;; allows to launch on-first-login script on first login only
>> ;; after complete logout/reboot.
>> - (when (not (file-exists? flag-file-path))
>> - (begin #$@gexps (touch flag-file-path))
>> + (if (file-exists? xdg-runtime-dir)
>> + (when (not (file-exists? flag-file-path))
>
> Use (unless …) instead of (when (not …)…).
>
>> + (begin #$@gexps (touch flag-file-path)))
>> + (display "XDG_RUNTIME_DIR doesn't exists, the session wasn't
>> +created, on-first-login script won't execute anything.")
>
> It would be good to tell the user how they could manually run the
> script, that way they could manually set/create $XDG_RUNTIME_DIR and run
> the script.
>
> "XDG_RUNTIME_DIR doesn't exist; the 'on-first-login' script won't
> execute anything. You can manually execute the script by running
> '$HOME/.guix-home/on-first-login'
>
> WDYT?
Addressed suggestions, attaching updated patch.
From 8b924b02ab917632047d6653f19d9b16175989bf Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Thu, 7 Oct 2021 08:12:04 +0300
Subject: [PATCH] home-services: on-first-login: Check if XDG_RUNTIME_DIR
exists.
* gnu/home-services.scm (on-first-login): on-first-login won't execute
anything if XDG_RUNTIME_DIR doesn't exists.
---
gnu/home/services.scm | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index 5c9b743f7b..1e295b6afe 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -286,8 +286,13 @@ (define (compute-on-first-login-script _ gexps)
;; XDG_RUNTIME_DIR dissapears on logout, that means such trick
;; allows to launch on-first-login script on first login only
;; after complete logout/reboot.
- (when (not (file-exists? flag-file-path))
- (begin #$@gexps (touch flag-file-path))
+ (if (file-exists? xdg-runtime-dir)
+ (unless (file-exists? flag-file-path)
+ (begin #$@gexps (touch flag-file-path)))
+ (display "XDG_RUNTIME_DIR doesn't exists, on-first-login script
+won't execute anything. You can check if xdg runtime directory exists,
+XDG_RUNTIME_DIR variable is set to apropriate value and manually execute the
+script by running '$HOME/.guix-home/on-first-login'")
(define (on-first-login-script-entry m-on-first-login)
"Return, as a monadic value, an entry for the on-first-login script
--
2.33.0
Also, added a note about elogind/XDG_RUNTIME_DI
bug#51141: guix home reconfigure does not apply changes to shepherd services
On 2021-10-22 02:32, Oleg Pykhalov wrote: > Andrew Tropin writes: > > […] > >> According to what I see in the shepherd tests: >> https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61 >> >> and how it's implemented in home-shepherd: >> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59 >> >> It should work as you expect it. > > It doesn't. > >> Tried to do the following: I updated documentation field for a shepherd >> service, reconfigured and it got loaded after I restarted a service. >> >> ~ $ herd doc state >> Init, update and maybe destroy state. >> ~ $ herd restart state >> Service state has been stopped. >> Service state has been started. >> ~ $ herd doc state >> Really init, update and maybe destroy state. >> >> Didn't check if start action gexp is updated too, but I expect it was. > > The start action is the interest, or configuration record, or service > extension. From the experiment above it's clear that new configuration got loaded and service record get updated after restart (at least one field of it). > > (guix scripts system reconfigure) has a upgrade-shepherd-services > procedure, which was created in 240b57f0ca576708ebf6cfa0dfe2803fa9ff2323 > and discussed in https://issues.guix.gnu.org/22039 The difference with update-shepherd-services is the usage of Shepherd CLI in home service instead of Shepherd API in system service. So the problem can hide somewhere around this part. Automatic unloading in home-service doesn't happens and as I said it's by design to prevent cases of losing unsaved work. However, it can be implemented with an optional separate flag to shepherd configuration record and extension to run-on-change-service or as it done in system shepherd with the list of services, which doesn't have to be unloaded automatically. > > > [ The following text only describes how to reproduce the issue. ] > > > When I tried to write goimapnotify service no changes applied after > modifications in home-goimapnotify-shepherd-service [1] and [2], which > are typical service-type and record. I didn't have similar issues with > self-written system services. > > [1]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/mail.scm#L28-45 > [2]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L40-65 > I'm out of office for next 1.5 week, will check it when I come back. > > Service extension also requires to unload service, e.g. mcron service > extension in [1] and [2]. > > [1]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/modules/home/services/package-management.scm#L16-50 > [2]: > https://gitlab.com/wigust/dotfiles/-/blob/ea2111906233099267f3b581b4aae39ad9645c2d/dotfiles/guixsd/home.scm#L154-161 > > If I remove the guix-delete-generations service from home configuration, > mcron job still exists according to 'herd schedule mcron'. > --8<---cut here---start->8--- > (home-environment > (services > (list (service guix-delete-generations-service-type ;; ... > > --8<---cut here---end--->8--- > > Oleg. BTW, please remove unreviewed changes to interpose function, they are incorrect. https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?id=41492639e0223dc8fc1a357e1f9537577c055db7#n362 The explanation: https://issues.guix.gnu.org/50967#66 The correct version: https://git.sr.ht/~abcdw/rde/commit/4961f47c3f97c21799a39b3e906fa99b2625f331 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#51141: guix home reconfigure does not apply changes to shepherd services
On 2021-10-16 18:06, Oleg Pykhalov wrote: > Hi Andrew, > > Andrew Tropin writes: > >> On 2021-10-12 01:53, Oleg Pykhalov wrote: >> >>> After changing a home shepherd service I tried to reconfigure with 'guix >>> home reconfigure'. >>> >>> Process started by a service did not restart. Assuming home shepherd is >>> like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the >>> process restarted but without changes in a service definition. >> >> It's intentional, only `herd load root new-config.conf` called on >> activation, so existing services are not affected to prevent situations, >> where emacs daemon or other important process killed in the middle of >> unsaved work. > > If I change something inside a system service definition > SERVICE-shepherd-service and then invoke 'guix system reconfigure', the > service will not restart and not produce any effect until I invoke 'sudo > herd restart SERVICE'. > > After herd restart the service will be running with applied changes and > does not require 'herd unload root SERVICE_NAME'. > E.g. nginx-service-type. > > I think this behaviour should be the same for home services. WDYT? Yes, make sense. According to what I see in the shepherd tests: https://git.savannah.gnu.org/cgit/shepherd.git/tree/tests/replacement.sh?h=4c5176f5a7a5a1e7d7f258f585e8ed127a21b99a#n61 and how it's implemented in home-shepherd: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm?h=7c3f28fdc4edc00f66801cd51a5ba08eee44f77f#n59 It should work as you expect it. Tried to do the following: I updated documentation field for a shepherd service, reconfigured and it got loaded after I restarted a service. --8<---cut here---start->8--- ~ $ herd doc state Init, update and maybe destroy state. ~ $ herd restart state Service state has been stopped. Service state has been started. ~ $ herd doc state Really init, update and maybe destroy state. --8<-------cut here---end--->8--- Didn't check if start action gexp is updated too, but I expect it was. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#51141: guix home reconfigure does not apply changes to shepherd services
On 2021-10-12 01:53, Oleg Pykhalov wrote: > After changing a home shepherd service I tried to reconfigure with 'guix > home reconfigure'. > > Process started by a service did not restart. Assuming home shepherd is > like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the > process restarted but without changes in a service definition. It's intentional, only `herd load root new-config.conf` called on activation, so existing services are not affected to prevent situations, where emacs daemon or other important process killed in the middle of unsaved work. You can do `herd unload root SERVICE_NAME` and after that reconfigure will apply the latest configuration and start the service (if auto-start? is true). > > To forcely apply the changes I invoked 'herd stop root' and then ran > 'guix home reconfigure' again which spawned new shepherd with applied > changes. > > Oleg. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
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:
bug#50771: guix system search doesn't show system services from channels
On 2021-09-27 15:27, zimoun wrote: > Hi, > > On Fri, 24 Sept 2021 at 08:59, Andrew Tropin wrote: >> >> Declared system service in (gnu services tmp) in my channel, did guix >> pull with the apropriate channels configuration. >> >> System service from (gnu services tmp) can be used in my >> operating-system record, but not searchable with `guix system search`. >> >> Do anyone know reasons for such behavior? Are there any known good >> solutions for that problem? > > Does it work if, instead of pulling, you run --load-path? > > Cheers, > simon `guix system --load-path=~/work/rde search home` doesn't show the system service I declared :/ I suspect this problem happens due to implementation: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services.scm?h=7aea1c112647381c799ce217df1a083f72aab0ba#n200 signature.asc Description: PGP signature
bug#50856: Unbound variables in Guix Home
On 2021-09-28 00:15, Oleg Pykhalov wrote:
> Hi Guix,
>
> We have unbound variables in some Guix Home files:
> --8<---cut here---start->8---
> gnu/home-services/configuration.scm:56:6: warning: possibly unbound variable
> `formatted-message'
> gnu/home-services/configuration.scm:57:7: warning: possibly unbound variable
> `G_'
> gnu/home-services/xdg.scm:309:43: warning: possibly unbound variable
> `maybe-list'
> gnu/home-services/xdg.scm:330:13: warning: possibly unbound variable
> `list->human-readable-list'
> guix/scripts/home/import.scm:210:18: warning: possibly unbound variable
> `package-version'
> guix/scripts/home/import.scm:210:35: warning: possibly unbound variable
> `find-packages-by-name'
> guix/scripts/home/import.scm:222:23: warning: possibly unbound variable `cut'
> guix/scripts/home/import.scm:222:27: warning: possibly unbound variable
> `version>?'
> guix/scripts/home/import.scm:222:45: warning: possibly unbound variable `<>'
> guix/scripts/home/import.scm:225:16: warning: possibly unbound variable
> `version-unique-prefix'
> --8<---cut here---end--->8---
>
> maybe-list and list->human-readable-list come from
> gnu/home-services-utils.scm in rde project.
>
> Oleg.
My bad) Here it is:
From 634e6cbb7153ea02fb2ace6d39dae4055ed0c73c Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Tue, 28 Sep 2021 12:30:55 +0300
Subject: [PATCH] home-services: Add missing imports and function definition.
* gnu/home-services/configuration.scm: Add missing imports.
* gnu/home-services/utils.scm (list->human-readable-list): Add new function.
* gnu/home-services/configuration.scm: Add missing imports.
* gnu/home-services/xdg.scm: Fix ensure-list function.
* guix/scripts/home/import.scm: Add missing imports.
---
gnu/home-services/configuration.scm | 2 ++
gnu/home-services/utils.scm | 30 -
gnu/home-services/xdg.scm | 12 +++-
guix/scripts/home/import.scm| 4
4 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/gnu/home-services/configuration.scm b/gnu/home-services/configuration.scm
index 3698006c37..e8f4bc77ec 100644
--- a/gnu/home-services/configuration.scm
+++ b/gnu/home-services/configuration.scm
@@ -23,6 +23,8 @@
#:use-module (srfi srfi-1)
#:use-module (ice-9 curried-definitions)
#:use-module (ice-9 match)
+ #:use-module (guix i18n)
+ #:use-module (guix diagnostics)
#:export (filter-configuration-fields
diff --git a/gnu/home-services/utils.scm b/gnu/home-services/utils.scm
index 3e490a0515..f13133a7ae 100644
--- a/gnu/home-services/utils.scm
+++ b/gnu/home-services/utils.scm
@@ -24,7 +24,8 @@
#:export (maybe-object->string
object->snake-case-string
-object->camel-case-string))
+object->camel-case-string
+list->human-readable-list))
(define (maybe-object->string object)
"Like @code{object->string} but don't do anyting if OBJECT already is
@@ -75,3 +76,30 @@ STYLE can be three `@code{lower}', `@code{upper}', defaults to
(cons (first splitted-string)
(map string-capitalize
(cdr splitted-string))
+
+(define* (list->human-readable-list lst
+#:key
+(cumulative? #f)
+(proc identity))
+ "Turn a list LST into a sequence of terms readable by humans.
+If CUMULATIVE? is @code{#t}, use ``and'', otherwise use ``or'' before
+the last term.
+
+PROC is a procedure to apply to each of the elements of a list before
+turning them into a single human readable string.
+
+@example
+(list->human-readable-list '(1 4 9) #:cumulative? #t #:proc sqrt)
+@result{} \"1, 2, and 3\"
+@end example
+
+yields:"
+ (let* ((word (if cumulative? "and " "or "))
+ (init (append (drop-right lst 1
+(format #f "~a" (string-append
+ (string-join
+ (map (compose maybe-object->string proc) init)
+ ", " 'suffix)
+ word
+ (maybe-object->string (proc (last lst)))
+
diff --git a/gnu/home-services/xdg.scm b/gnu/home-services/xdg.scm
index 457ce999a1..94275f3b65 100644
--- a/gnu/home-services/xdg.scm
+++ b/gnu/home-services/xdg.scm
@@ -287,9 +287,9 @@ The value of an XDG MIME entry must be a list, string or symbol, was given ~a")
@example
(merge-duplicates '((key1 . value1)
- (key2 . value2)
- (key1 . value3)
- (key1 . value4)) '())
+(key2 . value2)
+(key1 . value3)
+(key1 . value4)) '()
bug#50771: guix system search doesn't show system services from channels
Declared system service in (gnu services tmp) in my channel, did guix pull with the apropriate channels configuration. System service from (gnu services tmp) can be used in my operating-system record, but not searchable with `guix system search`. Do anyone know reasons for such behavior? Are there any known good solutions for that problem? signature.asc Description: PGP signature
bug#46760: guix deploy doesn't seem to be authorizing the machine that is deploying to the remote
On 2021-02-24 23:56, pkill9 wrote: > I'm using the machine-ssh-configuration, I set `(authorize? #t)` which > the manual states should authorize the deploying machine onto the > remote host, but I get an error: > ``` > guix deploy: error: unauthorized public key: (public-key... > ``` > > So I add to the OS definition: > > ``` > (guix-configuration >(authorized-keys (append `(,(local-file > "/etc/guix/signing-key.pub")) %default-authorized-guix-keys > > ``` > > Which makes the error go away. I'm under the impression however that > the 'authorize? #t' field should be doing this without me needing to > add it to the OS configuration. `(authorize? #t)` seems working, it does `guix archive --authorize < local-key` on remote machine before reconfiguring, but after reconfiguration is finished the value of /etc/guix/acl is reset by guix-service-type and for some reason the error message you mentioned appears. Despite the error message the new generation is created and new configuration is applied. It seems something like copying auxiliary file to remote store happens after reconfiguration is finished. Will try to investigate that, when will have some free time. For now I do the same trick with changing the configuration for guix-service-type: https://diode.zone/w/fJNN6ExYA35NC19BRiHw2L?start=37m5s signature.asc Description: PGP signature
bug#48692: busctl call fails on elogind 243.7
I try to use busctl to control the brightness of my screen: $ busctl call org.freedesktop.login1 /org/freedesktop/login1/session/auto org.freedesktop.login1.Session SetBrightness "ssu" "backlight" "intel_backlight" 24242 Call failed: Connection timed out It worked once, but at the same reported connection timed out, after that it doesn't work and report the same connection timed out message. After restart the situtation repeats. I tried to build Guix System with elogind 246.10, the issue with busctl is gone and it works fine without timed out message any number of times.
bug#48331: [PATCH draft] build-system: emacs: Generate -pkg.el file in case it is missing
--- Thank you for the patches, tested, works for me! The solution is much more precise than mutating package-directory-list variable, good job. I don't see any major problems in the implementation (but I'm not very fluent elisp dev and maybe missing something). I drafted a simple build phase, which generates -pkg.el in case it is missing. There are at least a few problems with this implementation: 1. There is no information about package record available during build, which makes it hard to get package name and package version. I can't use any regexp to obtain this information from name or elpa-name-ver, because package name and version can have arbitrary form: comment-dwim-2-1.0, cyberpunk-2019-theme-20191008-alpha or something like that. 2. It's also not so easy to extract description of the package from somewhere, the first option is to pass package record to build phases somehow, another is to parse PACKAGE-NAME.el file comments section. 3. This one I consider as a minor flaw: there is no generic solution for packages built with build systems other than emacs-build-system. So, this patch is very dirty and I publish it only for future reference. The intuition says that we should split name and version in build phase arguments, also it seems that it will be useful to provide other information about package during build time for cases like this one. I'll learn this area a bit more and probably will make another thread someday. guix/build/emacs-build-system.scm | 60 ++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/guix/build/emacs-build-system.scm b/guix/build/emacs-build-system.scm index f13162d6c4..2bb102b4be 100644 --- a/guix/build/emacs-build-system.scm +++ b/guix/build/emacs-build-system.scm @@ -116,6 +116,63 @@ environment variable\n" source-directory)) (parameterize ((%emacs emacs)) (emacs-byte-compile-directory (elpa-directory out) + +(define* (add-pkg-file-if-missing #:key name outputs #:allow-other-keys + #:rest args) + "Generate simple -pkg.el in case package doesn't have it in source code." + (define (file-contains-nul-char? file) +(call-with-input-file file + (lambda (in) +(let loop ((line (read-line in 'concat))) + (cond + ((eof-object? line) #f) + ((string-index line #\nul) #t) + (else (loop (read-line in 'concat)) + #:binary #t)) + + (let* ((out (assoc-ref outputs "out")) + (el-dir (elpa-directory out)) + (elpa-name-ver (store-directory->elpa-name-version out)) + (el-files (remove file-contains-nul-char? + (find-files (getcwd) "\\.el$"))) + (el-names (map (lambda (x) (basename x ".el")) el-files)) + + (possible-names + (fold (lambda (x acc) + (cons + (string-append +(if (not (null? acc)) (string-append (first acc) "-") "") +x) + acc)) +'() +(string-split elpa-name-ver #\-))) + + (package-names (append-map + (lambda (name) + (let ((m (member name el-names))) + (if m (list (car m)) '( + possible-names)) + + (package-name (if (null? package-names) "" (car package-names))) + (package-version (string-drop elpa-name-ver + (1+ (string-length package-name + (package-description "description should be here") + (pkg-file (string-append el-dir "/" package-name "-pkg.el"))) + +(when (not (file-exists? pkg-file)) + (with-output-to-file pkg-file +(lambda () + (format + #t + "\ +(define-package + ~s + ~s + ~s + nil)" + package-name package-version package-description +#t)) + (define* (patch-el-files #:key outputs #:allow-other-keys) "Substitute the absolute \"/bin/\" directory with the right location in the store in '.el' files." @@ -293,8 +350,9 @@ for libraries following the ELPA convention." (add-after 'make-autoloads 'enable-autoloads-compilation enable-autoloads-compilation) (add-after 'enable-autoloads-compilation 'patch-el-files patch-el-files) +(add-after 'patch-el-files 'add-pkg-file-if-missing add-pkg-file-if-missing) ;; The .el files are byte compiled directly in the store. -(add-after 'patch-el-files 'build build) +(add-after 'add-pkg-file-if-missing 'build build) (add-after 'build 'validate-compiled-autoloads validate-compiled-autoloads) (add-after 'validate-compiled-autoloads 'move-doc move-doc))) -- 2.31.1
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > In other words, no particular thought was given to -pkg.el. It was > > simply dropped along with many other files. So, if consensus is > > reachedthat keeping -pkg.el is a good idea, there is no reason to not > > do that. > Thanks for clearing that up. In that case, I don't have any qualms > about including them either. Cool, seems we can get -pkg.el files back. > Multi-profile Emacs should be supported, but this also breaks on > foreign distros with foreign distro ELPA. Again, hacking variables is > not the solution (and even if it was, it'd be better to patch the emacs > default value, not that this is a good idea either). Yep, the last snippet supports multi-profile Emacs. Installing packages for Emacs via a few different package manager sounds like a very bad practice) I agree that current implementation with updating variables isn't perfect and it doesn't cover the use case, which I expect to be rare (packages from Guix will be listed in list-packages, files from foreign distro PM won't). I can dive into package.el implementation and spend some time next week providing a different workaround. BTW, can you remind me why we do not place packages under site-lisp/elpa/NAME-VERSION? It seems almost the same as site-lisp/NAME-VERSION, but everything related to describe-package and other functions will work out of the box. This way it will work even with a foreign distro use case.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> That looks like it'd mess with people's installed ELPA packages. In > general, hacks based on package-directory-list don't feel very stable. If you talk about ~/.emacs.d/elpa, it won't, because there is a separate package-user-dir variable for that. The problem can arise if we have emacs installed in a few profiles, I'm not sure if it is a good idea to do so, but it is possible, in such a case we will have a few items in the package-directory-list. A fix for that: (setq package-directory-list (mapcar (apply-partially 'string-remove-suffix "/elpa") package-directory-list))) > Also, this seems to rely on us not deleting the -pkg.el, but probably > won't work for packages, that don't ship it, e.g. emacs-howm. It's true, but it seems relatively easy to implement a build phase, which will generate -pgk.el in case it is missing.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
From: Andrew Tropin
Date: Wed, 19 May 2021 20:44:22 +0300
Subject: [PATCH] guix: build: emacs-build-system: Make package.el aware of
guix packages
After updating the package-directory-list variable, functions like
list-packages,
describe-package become aware of packages installed by guix.
---
This code is getting work done, but I'm not a very experienced elisp
developer, so
please review it thoroughly.
gnu/packages/aux-files/emacs/guix-emacs.el | 10 ++
guix/build/emacs-build-system.scm | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
b/gnu/packages/aux-files/emacs/guix-emacs.el
index ca9146c535..4aa4220cda 100644
--- a/gnu/packages/aux-files/emacs/guix-emacs.el
+++ b/gnu/packages/aux-files/emacs/guix-emacs.el
@@ -58,6 +58,16 @@ The files in the list do not have extensions (.el, .elc)."
(load f 'noerror))
autoloads)))
+
+(require 'package)
+
+;; Set `package-directory-list' to the value without elpa/ suffix
+;; to match the structure of site-lisp directory of guix's emacs
+;; build system.
+;;;###autoload
+(setq package-directory-list
+ (list (string-remove-suffix "/elpa" (car package-directory-list
+
(provide 'guix-emacs)
;;; guix-emacs.el ends here
diff --git a/guix/build/emacs-build-system.scm
b/guix/build/emacs-build-system.scm
index e41e9a6595..7565b9a422 100644
--- a/guix/build/emacs-build-system.scm
+++ b/guix/build/emacs-build-system.scm
@@ -53,7 +53,7 @@
;; These are the default inclusion/exclusion regexps for the install phase.
(define %default-include '("^[^/]*\\.el$" "^[^/]*\\.info$" "^doc/.*\\.info$"))
-(define %default-exclude '("^\\.dir-locals\\.el$" "-pkg\\.el$"
+(define %default-exclude '("^\\.dir-locals\\.el$"
"^[^/]*tests?\\.el$"))
(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
--
2.31.1
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > Most other package managers seem to respect "infrastructure" provided > > by package.el. > I don't think that statement is well-supported by the data we have. Agree, that was an incorrect statement. I should have said something like: there are some popular tools like use-package configuration helper, Nix package manager, Spacemacs configuration framework, some elisp archives and probably something else, which utilize and follow package.el. Not all of them use package.el itself, but they follow conventions and describe-package help command and some other work correctly. > Why should we let ELPA dictate our layout? I have not even once tried > customizing package.el for actual use since I got Guix, because the > elpa importer is trivial. We don't have to. Actually, I'm very happy with the new (current) layout we have right now. I would say I find the following use case very confusing for newcomers: - Install emacs package via Guix. - Use built-in help C-h C-h, find C-h P. - Get it to work for built-in packages, but not for packages installed by Guix. - Get frustrated. I think we could avoid this at least in two ways: 1. Use elpa/ subdirectory. 2. Keep current structure, set package-directory-list to .../site-lisp instead of .../site-lisp/elpa by default. > Thus we're not trying to keep in line with any specific package > manager, we just need to make things work "with Emacs" in the sense > that packages installed via Guix should have working autoloads and one > should be able to (require ...) them. Yes, but at the same time I don't see reasons why not to implement one of two options above. We can get both: working autoloads and working built-in help function (+newcommers won't be so frustrated). Personally, I'm quite happy that packages got their own subdirectories and I'm fully satisfied with current state of it, but it would be cool if inexperienced users will be able to use at least built-in help commands for packages out of the box without additional configuration. Hope my original point is a little better worded now. -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > M-x list-packages ;; Doesn't list treemacs > Let me recommend Emacs-Guix (aka. 'guix.el') as a superior alternative. > :-) Sure) Aware of it, cool tool. > I think it's fine that 'package.el' is unaware of Guix-managed software > and vice-versa. Yep, perfectly fine, but why not to make it aware, if it is relatively easy to achieve?)
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> the "-pkg\\.el$" exclude might have existed for a reason > (I don't know which, put perhaps byte compilation). Perhaps it should be ignored during byte compilation, but still installing it seems to be a good idea. Ok, let's wait for Maxim answer. > I know people take package.el for granted nowadays, but alternative > package managers for Emacs have their uses. This is not just a Guix > thing :) Why not take it for granted?) It's built-in since 24(?), elpa/melpa archives respect it format and provide package descriptions in -pkg.el format, AFAIK. Most other package managers seem to respect "infrastructure" provided by package.el. For example you can view a list of packages with `list-packages` even for packages installed with other PMs (Nix for example), BTW they keep "package.el" directory structure. https://0x0.st/-BxL.txt Don't see too many reasons not to follow this format. I mean it's easily fixable with current directory structure just by stripping "/elpa" suffix from package-directory-list, but why we would do that emacs "customization" instead of just placing packages under /elpa subdirectory and make everything work out of the box? > I don't think we want to fake elpa that hard. Two iterations ago it > was .guix.d and people didn't really like it. Do you mean the package installation path was site-lisp/.guix.d/NAME-VERSION? > My subdirs.el patch is also stretching it. Not sure what you mean by this, sorry, I'm not native speaker and automated translation doesn't make sense to me. Rephrase please. I do not insist on any particular directory structure, just curious why not to stick to the widely adopted format. Once again, thank you for placing packages into subdirectories, now the site-lisp structure seems more organized and less polluted + problem with describe-package (C-h P) and list-packages are easily fixable. Appreciate your work!) -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> The problem here is, that Guix does not include the -pkg.el > file, that would typically be generated by package.el. To deal with > this, you have to provide package specs on your own. There already > exists a utility to locate libraries in a package manager agnostic > fashion [1], all you need to do is to feed back that information to > package.el. Yep, I figured it out yesterday and even hacked around a little bit. Patched emacs-build-system to place packages under elpa/NAME-VERSION subdirectory and removed "-pkg\\.el$" from %default-exclude. > I have now published emacs-dpd [2], which does exactly that. To use it > for your Guix Emacs packages, execute > (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) > replacing "$GUIX_PROFILE" with the actual profile, after `package- > initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize-hook'. > I might write a more detailed README later. Most of the packages already have -pkg.el in sources, but yep, pretty cool utility, also thought about implementing something like that yesterday, but luckily I didn't and now I do not need to do it, because now I'm aware of already-existing implementations!) > Neither packed nor dpd are currently packaged in Guix. packed can > easily be imported from melpa-stable, but for dpd you'd have to write > your own guix.scm. I might do that at some point as well. > We already had modifications in emacs-build-system recently, so if you > want to argue, that all Emacs packages should have that - > pkg.el to work with package.el out of the box, I would ask you to wait, > so as to not cause an "Emacs world" rebuild again after only ten days. > I also don't know whether Guix has the same information as package.el > at build time, but that might change with time as well. Particularly, > there will hopefully be a move towards supplying name and version at > build, which would give us the most important information. Very cool, I didn't have the latest changes on my local checkout and didn't see your commits, but now I see, it is exactly what I needed. The only side note: it should be site-lisp/elpa/NAME-VERSION (right now it is site-lisp/NAME-VERSION). Also, on line 137 elpa-directory function can be used. When you will be updating the path, please remove -pkg.el from %default-exclude. Thank you very much for your work! Really appreciate it! -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
describe-package and list-packages do not show emacs packages, installed with guix. Packages themselves work perfectly fine, but not listed in list-packages and can't be accessed with describe-package. Way to reproduce: guix environment --pure --ad-hoc emacs emacs-treemacs emacs -q M-x treemacs ;; Works fine C-h P treemacs ;; Doesn't work M-x list-packages ;; Doesn't list treemacs Played around with it a little bit, still not sure how to solve.
