Re: Help me ask for libssh signing/verifying signatures API
Hi Nicolas, On Tue, Aug 29, 2023 at 12:12 PM Nicolas Graves via wrote: > > For those of you who have a gitlab account, could you hop in and leave a > like or a small support message? I may not use SSH with Gitlab personally, but gave you an enthusiastic thumbs up! Kind regards Felix P.S. I was only the second upvote, so please don't be shy, everyone!
Re: GHC packages' inputs leak in guix shell
> I can’t check right now, but I’m guessing a plain `cabal install` > would also add base64-bytestring to GHC’s visible packages? I tested with cabal-install and it somehow manages to hide the haskell packages that are installed as dependencies. ``` $ guix shell -CN cabal-install coreutils zlib -D ghc-old-time ## Building old-time failed so I added it's inputs. ## Zlib is also required for building the dependency chain. $ cabal update $ env -u GHC_PACKAGE_PATH cabal install --lib esqueleto $ ghci ﬦ import Database.Esqueleto.Experimental -- This works, so the package from cabal-install is visible ﬦ import Data.ByteString.Base64.URL.Lazy : error: Could not load module `Data.ByteString.Base64.URL.Lazy' It is a member of the hidden package `base64-bytestring-1.2.1.0'. You can run `:set -package base64-bytestring' to expose it. (Note: this unloads all the modules in the current scope.) ``` signature.asc Description: PGP signature
Re: LaTeX: Need help with packaging a book in GNU Guix
> It should be fixed on master, if you can guix pull again. The problem is fixed indeed, thank you very much! - avp -- Artyom "avp" Poptsov Home page: https://memory-heap.org/~avp/ CADR Hackerspace co-founder: https://cadrspace.ru/ GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F signature.asc Description: PGP signature
Help me ask for libssh signing/verifying signatures API
Hi Guix, Just a word of context. I've had difficulty in the past with GnuPG so when I learned that signing commits was fine with only openssh (since 8.2 IIRC), I would like to stick with it. I develop regularly for guix and RDE, and for some tasks, I believe a commit access to either can help in some useful cases. For now, the commit access to guix or any guix channel is dependent on GnuPG, and I'm willing to help on the guix part to allow proper signing for maintainers with ssh keys (I can't commit for a timing though). But first we would need 1) to get libssh to implement those procedures that are in the API documentation, but not in the code (see https://github.com/artyom-poptsov/guile-ssh/issues/35 for more detail). 2) to get guile-ssh to implement those functions. The first part could be sped up by some support on the issue https://gitlab.com/libssh/libssh-mirror/-/issues/142 For those of you who have a gitlab account, could you hop in and leave a like or a small support message? Thanks a lot if you can! -- Best regards, Nicolas Graves
Re: LaTeX: Need help with packaging a book in GNU Guix
"Artyom V. Poptsov" writes: > Hello Nicolas! > Thanks, that worked out indeed. I've added other LaTeX packages as > well, searching by the required ".sty" files. Great! > /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: > /gnu/store/05770yhxad3d3p4q7rgw8clh0y1gi5sc-texlive-glossaries-66594/bin/makeglossaries: > /usr/bin/env: bad interpreter: No such file or directory > make: *** [Makefile:77: make_glossary] Error 1 > make: *** Waiting for unfinished jobs > --8<---cut here---end--->8--- > > > It looks like "makeglossaries" cannot find "/usr/bin/env" program. It should be fixed on master, if you can guix pull again. > Strangely enough when I add "texlive" to the inputs, the problem is > gone. This is not strange. `texlive' provides `perl' once in its inputs, and all scripts, such as `makeglossaries', have their shebang line updated. In modular TeX Live, packages are responsible for their own script(s); and need to provide `perl', for example, as an input. This is not obvious when the script has no extension, as it is the case here. Regards,
Re: LaTeX: Need help with packaging a book in GNU Guix
Hello Nicolas! > I then suggest to add `texlive-fontspec' (a few kB) instead of `texlive' > (3 GB) to the inputs. Thanks, that worked out indeed. I've added other LaTeX packages as well, searching by the required ".sty" files. But then, I ran into the following error: --8<---cut here---start->8--- Package rerunfilecheck Info: Checksums for `sparc.out': (rerunfilecheck) Before: (rerunfilecheck) After: 8A9E5CFD2193CCDADFE90D96E3F45333;20690. runsystem(rm sparc.pyg)...executed. ) Here is how much of TeX's memory you used: 66386 strings out of 476682 1790478 string characters out of 5779954 2503753 words of memory out of 500 84784 multiletter control sequences out of 15000+60 516911 words of font info for 97 fonts, out of 800 for 9000 1348 hyphenation exceptions out of 8191 94i,16n,92p,2254b,2061s stack positions out of 1i,1000n,2p,20b,20s Output written on sparc.xdv (133 pages, 2587352 bytes). GLOSSARY sparc INDEX sparc /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: /gnu/store/05770yhxad3d3p4q7rgw8clh0y1gi5sc-texlive-glossaries-66594/bin/makeglossaries: /usr/bin/env: bad interpreter: No such file or directory make: *** [Makefile:77: make_glossary] Error 1 make: *** Waiting for unfinished jobs --8<---cut here---end--->8--- It looks like "makeglossaries" cannot find "/usr/bin/env" program. I checked where "env" can be found inside the builder context: --8<---cut here---start->8--- (arguments (list #:phases #~(modify-phases %standard-phases (add-after 'unpack 'debug (lambda _ (invoke "which" "env"))) --8<---cut here---end--->8--- And the full path is: /gnu/store/yr39rh6wihd1wv6gzf7w4w687dwzf3vb-coreutils-9.1/bin/env But "makeglossaries" script seems to have a wrong path: --8<---cut here---start->8--- $ head -1 /gnu/store/05770yhxad3d3p4q7rgw8clh0y1gi5sc-texlive-glossaries-66594/bin/makeglossaries #!/usr/bin/env perl --8<---cut here---end--->8--- Maybe there should be a symlink to "/bin/env" or something. Strangely enough when I add "texlive" to the inputs, the problem is gone. Any ideas? Thanks! - avp -- Artyom "avp" Poptsov Home page: https://memory-heap.org/~avp/ CADR Hackerspace co-founder: https://cadrspace.ru/ GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F signature.asc Description: PGP signature
Question about native vs regular search paths
Hi, What is the difference, in concrete terms, between SEARCH-PATHS and NATIVE-SEARCH-PATHS; why do they need to be separate, why is SEARCH-PATHS seemingly only used during a build, and why are NATIVE-SEARCH-PATHS only set in cross-compiled builds? I'm asking because I want to understand why has TARGET-INPUTS: --- guix/build-system.scm ;; "Target inputs" are packages that are built natively, but that are used ;; by target programs in a cross-compilation environment. Thus, they act ;; like 'inputs' as far as search paths are concerned. The only example of ;; that is the cross-libc: it is an input of 'cross-gcc', thus built ;; natively; yet, we want it to be considered as a target input for the ;; purposes of $CPATH, $LIBRARY_PATH, etc. (target-inputs bag-target-inputs (default '())) --- This comment explains what happens, but I don't get *why* this has to happen; what's the reason cross-libc has to be built natively, and why does it need to be treated as a target input for SEARCH-PATHS? What does 'being considered as a target input' even mean in that context? Thanks, -- (
Re: Creating a service that runs a user-installed package as root
On 2023-08-15 19:16:11 -0500, heat from fire via wrote:
> Hi all,
>
> First time posting on this forum.
>
> I am trying to set up a service that runs "sudo mullvad-daemon" upon user
> login. The mullvad package is installed through Nix on a user profile.
>
> I've tried creating a user service using Shepherd in a config file at
> "~/.config/shepherd/init.scm", but it doesn't seem possible to run the
> command as root.
> Here's a snippet from the file:
>
> (define mullvad
> (service '(mullvad)
> #:respawn? #t
> #:start (make-forkexec-constructor '("mullvad-daemon" "-v"))
> #:stop (make-kill-destructor)))
>
> I read through here in hopes to find a solution, but to no avail:
> https://www.gnu.org/software/shepherd/manual/shepherd.html#Services
> Perhaps there is a service constructor with an option to run the command as
> root?
I also do not see such option, and since the user shepherd runs under the user,
I do not think it is possible without modifications to the sudoers file.
>
> I know that I can define a Shepherd service in my system config file, which
> runs the command in it as root, but given that it depends on a user-installed
> Nix package, I'm not sure how I'll have to accommodate for that. The command
> is located at /home/user/.nix-profile/bin/mullvad-daemon.
> I also tried creating a regular system service using service-type, but
> couldn't get it to work.
>
> My only other alternative is to run sudo mullvad-daemon in ~/.profile and
> make an exception in the sudoers file to not require a password. This
> solution is messy so I wanna try to avoid it. I could also put the command in
> the Guix equivalent of "/etc/rc.local", but I don't think there is one in
> Guix.
>
> Any ideas on how I can create a service that runs a command installed in a
> user profile as root? Or alternatively, a better way to run a command as root
> without password on user login, after sourcing ~/.profile?
I do not have much experience with shepherd (yet!), but cannot you just use
'("sudo" "mullvad-daemon" "-v")? While still requiring an entry in sudoers
file, I would say it is cleaner than sudo ... in the ~/.profile, and it you
could still start/stop it via the herd command.
>
> Thanks!
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
Re: LaTeX: Need help with packaging a book in GNU Guix
"Artyom V. Poptsov" writes: > When I tried to remove "texlive" from inputs, I ran into the following > error: > > --8<---cut here---start->8--- > ! LaTeX Error: File `fontspec.sty' not found. [...] > As you can see, LaTeX cannot find "fontspec.sty" file. I did some > research and found that the file belongs to "texlive" package. So when > I returned "texlive" to inputs the build process went fine. I then suggest to add `texlive-fontspec' (a few kB) instead of `texlive' (3 GB) to the inputs. If you insist on adding `texlive' to the inputs, you can remove every other "texlive-" input instead; it's one or the other. Regards,
Re: LaTeX: Need help with packaging a book in GNU Guix
Hello Nicolas,
thank you very much for the help! I've changed my "guix.scm" as you
suggested and now it works.
> You can also remove `texlive' and, probably, `texlive-latex-fonts' and
> `texlive-ttf-utils' from your inputs, since you're using XeTeX.
When I tried to remove "texlive" from inputs, I ran into the following
error:
--8<---cut here---start->8---
! LaTeX Error: File `fontspec.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
l.7 \setmainfont
{Liberation Serif}^^M
*** (cannot \read from terminal in nonstop modes)
Here is how much of TeX's memory you used:
1444 strings out of 476682
24786 string characters out of 5779954
1842018 words of memory out of 500
21750 multiletter control sequences out of 15000+60
512295 words of font info for 33 fonts, out of 800 for 9000
1348 hyphenation exceptions out of 8191
40i,0n,52p,180b,100s stack positions out of 1i,1000n,2p,20b,20s
No pages of output.
INDEX sparc
GLOSSARY sparc
make: *** [Makefile:83: make_index] Error 1
make: *** Waiting for unfinished jobs
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh:
/gnu/store/05770yhxad3d3p4q7rgw8clh0y1gi5sc-texlive-glossaries-66594/bin/makeglossaries:
/usr/bin/env: bad interpreter: No such file or directory
make: *** [Makefile:77: make_glossary] Error 1
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "32") exit-status:
2 term-signal: #f stop-signal: #f>
phase `build' failed after 11.1 seconds
command "make" "-j" "32" failed with status 2
builder for `/gnu/store/dnyi529yx6wfb73hwgsylm60ikrrashf-sparc-book-git.drv'
failed with exit code 1
build of /gnu/store/dnyi529yx6wfb73hwgsylm60ikrrashf-sparc-book-git.drv failed
View build log at
'/var/log/guix/drvs/dn/yi529yx6wfb73hwgsylm60ikrrashf-sparc-book-git.drv.gz'.
guix build: error: build of
`/gnu/store/dnyi529yx6wfb73hwgsylm60ikrrashf-sparc-book-git.drv' failed
--8<---cut here---end--->8---
As you can see, LaTeX cannot find "fontspec.sty" file. I did some
research and found that the file belongs to "texlive" package. So when
I returned "texlive" to inputs the build process went fine.
Thanks!
- avp
--
Artyom "avp" Poptsov
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F
signature.asc
Description: PGP signature
Re: LaTeX: Need help with packaging a book in GNU Guix
Hello,
"Artyom V. Poptsov" writes:
> There are lots of examples of LaTeX package definitions in Guix for
> sure, but unfortunately I found no examples of packaged books written in
> LaTeX.
There is `book-faif' in "fsf.scm".
> Then I'm getting errors that "Liberation Serif" font is not found:
>
> --8<---cut here---start->8---
> (/gnu/store/h7iqqr3aajqhjkib2k2g0zipag2ya41s-texlivetexmf-20230313/share/texmf-
> dist/tex/latex/fontspec/fontspec.cfg)))
>
> ! Package fontspec Error: The font "Liberation Serif" cannot be found.
> For immediate help type H .
> ...
>
> l.8 \setmonofont
> {Liberation Mono}
You should add `fontconfig' to native-inputs so Liberation can be found.
You can also remove `texlive' and, probably, `texlive-latex-fonts' and
`texlive-ttf-utils' from your inputs, since you're using XeTeX.
I suggest the following:
--8<---cut here---start->8---
(native-inputs
(list python-pygments
bash-minimal
perl
which
fontconfig))
(inputs
(list font-liberation
git
gnu-make
inkscape
lilypond
texlive-acronym
texlive-adjustbox
texlive-bibtex
texlive-bibtexperllibs
texlive-bigfoot
texlive-circuitikz
texlive-collection-langcyrillic
texlive-glossaries
texlive-lilyglyphs
texlive-minted
texlive-multirow
texlive-pgf
texlive-subfiles
texlive-svg
texlive-t1utils
texlive-textpos
texlive-transparent
texlive-xetex))
--8<---cut here---end--->8---
Note that everything could be moved to native inputs.
Also note that you need un-packaged TeX Live packages, such as `svg'.
I added them just before sending the mail, so you'll need a recent "guix
pull".
> Moreover I see that the build tries to update the font cache but fails
> to do that because the part of the file system it tries to write to is
> read-only:
>
> --8<---cut here---start->8---
> (/gnu/store/h7iqqr3aajqhjkib2k2g0zipag2ya41s-texlivetexmf-20230313/share/texmf-
> dist/tex/latex/base/book.cls
> Document Class: book 2022/07/02 v1.4n Standard LaTeX document class
>
> (/gnu/store/h7iqqr3aajqhjkib2k2g0zipag2ya41s-texlivetexmf-20230313/share/texmf-
> dist/tex/latex/base/bk10.cloFontconfig error: No writable cache directories
> Fontconfig error: No writable cache directories
> ))
> --8<---cut here---end--->8---
This "error" is actually harmless.
Regards,
--
Nicolas Goaziou
Re: documentation in TeX Live collections
Hellon De Andreas Enge le 28/08/2023 à 20:05: > if I understand things correctly, we would like the following behaviour > for propagated inputs in the texlive context: > We have these metapackages with propagated inputs; all of these inputs > have "out" and "doc". Then we would like to automatically create "out" > and "doc" for the metapackage, into which the corresponding "out" and > "doc" of their "ingredients" are propagated. > > Well, more precisely, the metapackages are empty, so it is a bit fuzzy > what I mean by "into which" above. > > We would like the following: > - If a user installs metapackage:out, they get all the ingredient:out > in their profile. > - If a user installs metapackage:doc, they get all the ingredient:doc > in their profile. > I am quite certain this is not how propagated inputs work, and I do not > know whether their behaviour could be changed in this way. Indeed, that is what I imagine. Actually, it does not feel specific to the texlive context and could apply to propagated inputs in general. [...] > See also >https://issues.guix.gnu.org/65550 Interesting! The case of development outputs referred to in this issue suggests similar concerns. > I do not really understand what is happening. All outputs are downloaded, > but only the out outputs are propagated? It does look like that: all outputs of the propagated inputs are downloaded but only the "out" outputs are actually propagated to the profile. And indeed, after guix gc, the other outputs are removed from the store. Is that the intended behaviour? > If this is true, then I think it would make sense to not split into two > outputs, but to always include the documentation in the texlive packages. I'm not sure about that. Splitting the documentation to a different output does make sense in itself (for considerations of space, mostly). This thing about propagating only "out" outputs looks more like an issue with package definitions, or even the package model if propagating other outputs happens to be unsupported. -- Emmanuel
Re: Two linux users, each has different packages available
Hi Richmond, Did the first user 'guix pull' recently? That is also per-user. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
Re: documentation in TeX Live collections
Hi, De Nicolas Goaziou le 28/08/2023 à 20:01: > Nicolas Goaziou writes: > >>> In any case, I suggest to write a proper bug report for this. Hopefully, > >>> someone with better understanding about the implications of GUIX_TEXMF > >>> will be able to solve this. > >> > >> I can do that for the texdoc behaviour. > > By the way, I think I fixed `texdoc' utility. Would you care testing it > after a fresh `guix pull'? It seems to work fine: now texdoc does find all documentation in the various items in GUIX_TEXMF. So there seems to be no need for a texdoc bug report anymore, thanks! The only subtlety is that any call to guix shell with extra texlive packages should also include texlive-bin (directly or not) so that the proper hooks are called, otherwise GUIX_TEXMF is not updated. This goes beyond the point of documentation, of course. -- Emmanuel
Two linux users, each has different packages available
I have two different linux users on my system. (Debian 11 x86). One has icecat 102 installed, the other icecat 78. I cannot upgrade the user with 78. The 102 version doesn't seem to be available. On the first user: guix package -A icecat icecat 78.4.0-guix0-preview1 out gnu/packages/gnuzilla.scm:725:2 On the other user: guix package -A icecat icecat 102.14.0-guix0-preview1 out gnu/packages/gnuzilla.scm:1708:4 icecat-l10n 102.14.0-guix0-preview1 out,ach,af,an,ar,ast,az,be,bg,bn,br,bs,ca,cak,ca-valencia,cs,cy,da,de,dsb,el,en-CA,en-GB,eo,es-AR,es-CL,es-ES,es-MX,et,eu,fa,ff,fi,fr,fy-NL,ga-IE,gd,gl,gn,gu-IN,he,hi-IN,hr,hsb,hu,hy-AM,ia,id,is,it,ja,ja-JP-mac,ka,kab,kk,km,kn,ko,lij,lt,lv,mk,mr,ms,my,nb-NO,ne-NP,nl,nn-NO,oc,pa-IN,pl,pt-BR,pt-PT,rm,ro,ru,sco,si,sk,sl,son,sq,sr,sv-SE,szl,ta,te,th,tl,tr,trs,uk,ur,uz,vi,xh,zh-CN,zh-TW gnu/packages/gnuzilla.scm:1583:4 icecat-minimal 102.14.0-guix0-preview1 out gnu/packages/gnuzilla.scm:694:2 How did this come about? I think I have possibly created an environment by accident. But I don't know how to show it or remove it.
Icecat Firefox Seamonkey Icon mix-up
Since installing icecat using guix on Debian 11, I now find that when I launch Seamonkey or Firefox they appear with the Icecat icon in the panel, and also identify as GNU Icecat in the top bar. I am using Gnome Classic. Why is this icon mix-up occurring?
Setting shepherd log dir
Hello, with 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , my (user) mcron log file changed from ~/.local/state/log/mcron.log to ~/.local/state/shepherd/mcron.log (though strangely this did not seem to take effect until 552d0703776c532f25498d5cb852c3c497cb9252 et. al.). I prefer the old location, and changed it back with home-mcron-configuration (which is missing the documentation for the log-file option, but I found it in the code). However, if I ever use one of the other services utilizing %user-log-dir, it will also log to ~/.local/state/shepherd/ . So I think it would be great to overwrite %user-log-dir, but I haven't found a way to do so. Does anyone have any ideas? Nils
Re: Problem with Shepherd after `guix home reconfigure`
> Tanguy LE CARROUR hat am 22.08.2023 18:56 CEST > geschrieben: > > > Hi Hilton, > > > Quoting Hilton Chain (2023-08-22 17:18:15) > > If you happen to use the system mcron service as well, please pull to > > the latest commit again, my bad :( > > Done! > Reboot and… > > > > > ``` > > > $ guix home reconfigure > > > # […] > > > Loading /gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf. > > > herd: error: exception caught while executing 'load' on service 'root': > > > In procedure fport_write: Input/output error > > > ``` > > > > > > I've just tried something that, as weird as it sounds, I had never done > > > before: > > > `herd stop mcron`! And… it just hangs forever!? I guess it not the > > > expected behaviour?! 🤔 > > > I `ctrl+c`-ed it and, now, `herd status` also hangs forever!? 😞 > > > I'll see if everything goes back to normal after the next reboot… > > > > I don't know much about Shepherd but rebooting seems to be the only > > solution when it hangs... > > I now have a slightly different error message: > > ``` > $ guix home reconfigure > # […] > SSLoading /gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf. > herd: error: exception caught while executing 'load' on service 'root': > In procedure fport_write: Broken pipe > ``` > > ``` > # herd status > Started: > + root > Starting: > ^ mcron > ^ mpd > Stopped: > - tor > - transmission > ``` > > I usually have: > > ``` > # herd status > Started: > + mcron > + mpd > + root > Stopped: > - tor > - transmission > ``` > > Even though `mpd` is reported as "starting" it actually works. > `herd stop mcron` still hangs forever, but `herd status` keeps on > working and reporting "starting" services. > > Thoughts? 🤔 I had a similar issue about 2 months ago. I was using XDG_LOG_HOME in a shepherd service definition, and it was not available anymore. The error message I got was different, but the result was the same - some services shown as "starting" and working, but herd not working for one particular broken service. I suggest to check your /gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf file for the log path of the mcron job. Maybe your XDG_STATE_HOME points to a non-writable directory? > > -- > Tanguy
Icon confusion
Since installing icecat using guix on Debian 11, I now find that when I launch Seamonkey or Firefox they appear with the Icecat icon in the panel, and also identify as GNU Icecat in the top bar. I am using Gnome Classic. Does anyone know why is this icon mix-up occurring?
How do I install libgcc_s in a container?
Hi! I'm trying to follow along with https://guix.gnu.org/en/blog/2023/the-filesystem-hierarchy-standard-comes-to-guix-containers/ But I'm unable to install libgcc_s, as lib is no longer an output of gcc-toolchain, so I can't manage to run any foreign binaries.
Re: problem trying to install python module in python virtual environment on top of Guix
Hi Andy, I think that it may be possible to build the package with a little effort. You'll have to emulate the FHS as Maxim suggested. But you'll also have to expose the standard C/C++ libraries (they are currently hidden, see https://issues.guix.gnu.org/63267). Save the following Scheme code as gcc-unhidden.scm in a directory: (define-module (gcc-unhidden) #:use-module (gnu packages gcc) #:use-module (guix packages) #:use-module (srfi srfi-1)) (define-public gcc-12-unhidden (package (inherit gcc-12) (properties (alist-delete 'hidden? (package-properties gcc-12) That will make the gcc:lib output available. You can use it in a Guix container along with the necessary tools. This is how I'd do it: guix shell --load-path=. --container --emulate-fhs --network \ bash coreutils gcc-toolchain gcc:lib make python You can now create a Python virtual environment inside the Guix container and continue as usual. Kind regards, George
Re: How to delete per-user profiles
У сб, 2023-08-26 у 09:13 +0300, Roman Riabenko пише: > У пт, 2023-08-25 у 17:01 -0300, Jorge пише: > > I have removed (via Gnome Settings) user `jorge-morais' from my > > Gentoo GNU/Linux system, but its Guix profiles remain. > > If you only remove a user from GNOME Settings without removing it > from > the system configuration file, the user will re-appear in GNOME > Settings on reboot or the next time the system is reconfigured and a > home directory will be created for it if it was removed. (Such user > would not appear in the login screen because the user is only re- > created but not activated. The activation can be done in GNOME > Settings.) Instead, to remove a user, you should remove its "user- > account" form from the system configuration file [1] and reconfigure > the system. You have to handle the user files yourself, e.g. remove > the > user's home directory. If you are also adding a user, you would want > to > do that in the configuration file too. > > [1]: > https://guix.gnu.org/en/manual/devel/en/html_node/User-Accounts.html Sorry, I've just noticed that you are on Gentoo, not a Guix System, so you manage the users from Gentoo, not from the guix configuration file. > > How do I remove them, so Guix GC can clean the store? Can I simply > > remove the directory `/var/guix/profiles/per-user/jorge-morais' ? > > Those links are not removed automatically, so that directory needs to > be removed by hand. When the links are removed and eventually you run > "guix gc", it removes the unused profiles in the store. This still applies. Roman signature.asc Description: This is a digitally signed message part
Re: How to delete per-user profiles
У пт, 2023-08-25 у 17:01 -0300, Jorge пише: > I have removed (via Gnome Settings) user `jorge-morais' from my Gentoo GNU/Linux system, but its Guix profiles remain. If you only remove a user from GNOME Settings without removing it from the system configuration file, the user will re-appear in GNOME Settings on reboot or the next time the system is reconfigured and a home directory will be created for it if it was removed. (Such user would not appear in the login screen because the user is only re- created but not activated. The activation can be done in GNOME Settings.) Instead, to remove a user, you should remove its "user- account" form from the system configuration file [1] and reconfigure the system. You have to handle the user files yourself, e.g. remove the user's home directory. If you are also adding a user, you would want to do that in the configuration file too. [1]: https://guix.gnu.org/en/manual/devel/en/html_node/User-Accounts.html > How do I remove them, so Guix GC can clean the store? Can I simply remove the directory `/var/guix/profiles/per-user/jorge-morais' ? Those links are not removed automatically, so that directory needs to be removed by hand. When the links are removed and eventually you run "guix gc", it removes the unused profiles in the store. Roman signature.asc Description: This is a digitally signed message part
Creating a service that runs a user-installed package as root
Hi all,
First time posting on this forum.
I am trying to set up a service that runs "sudo mullvad-daemon" upon user
login. The mullvad package is installed through Nix on a user profile.
I've tried creating a user service using Shepherd in a config file at
"~/.config/shepherd/init.scm", but it doesn't seem possible to run the command
as root.
Here's a snippet from the file:
(define mullvad
(service '(mullvad)
#:respawn? #t
#:start (make-forkexec-constructor '("mullvad-daemon" "-v"))
#:stop (make-kill-destructor)))
I read through here in hopes to find a solution, but to no avail:
https://www.gnu.org/software/shepherd/manual/shepherd.html#Services
Perhaps there is a service constructor with an option to run the command as
root?
I know that I can define a Shepherd service in my system config file, which
runs the command in it as root, but given that it depends on a user-installed
Nix package, I'm not sure how I'll have to accommodate for that. The command is
located at /home/user/.nix-profile/bin/mullvad-daemon.
I also tried creating a regular system service using service-type, but couldn't
get it to work.
My only other alternative is to run sudo mullvad-daemon in ~/.profile and make
an exception in the sudoers file to not require a password. This solution is
messy so I wanna try to avoid it. I could also put the command in the Guix
equivalent of "/etc/rc.local", but I don't think there is one in Guix.
Any ideas on how I can create a service that runs a command installed in a user
profile as root? Or alternatively, a better way to run a command as root
without password on user login, after sourcing ~/.profile?
Thanks!
Re: problem trying to install python module in python virtual environment on top of Guix
Hi Andy, I think that it may be possible to build the package with a little effort. You'll have to emulate the FHS as Maxim suggested. But you'll also have to expose the standard C/C++ libraries (they are currently hidden, see https://issues.guix.gnu.org/63267). Save the following Scheme code as gcc-unhidden.scm in a directory: (define-module (gcc-unhidden) #:use-module (gnu packages gcc) #:use-module (guix packages) #:use-module (srfi srfi-1)) (define-public gcc-12-unhidden (package (inherit gcc-12) (properties (alist-delete 'hidden? (package-properties gcc-12) That will make the gcc:lib output available. You can use it in a Guix container along with the necessary tools. This is how I'd do it: guix shell --load-path=. --container --emulate-fhs --network \ bash coreutils gcc-toolchain gcc:lib make python You can now create a Python virtual environment inside the Guix container and continue as usual. Kind regards, George
Re: GHC packages' inputs leak in guix shell
Hi Simon, > Right? Well, I do not know if it is possible. I guess it is because of > this file: > > --8<---cut here---start->8--- > $ find $(guix build ghc-esqueleto) -type f -print | grep base64 > /gnu/store/zqax59v1v537h26g0kypka6klaaahnqf-ghc-esqueleto-3.5.8.1/lib/ghc-9.2.5/ghc-esqueleto-3.5.8.1.conf.d/base64-bytestring-1.2.1.0-CQYLTs5ShsEFl2lwe4hRrI.conf > --8<---cut here---end--->8--- > > Lars, WDYT? your analysis is correct, but due to the nature of how Haskell builds work we cannot remove that file (because anything depending on ghc-esqueleto would not build any more) or relocate it to a different output (because that would cause a cycle). I can’t check right now, but I’m guessing a plain `cabal install` would also add base64-bytestring to GHC’s visible packages? Cheers, Lars
