<Ribby>Hello guys, everything's going swimming well for the guix on my client side. I do have a bit of quirks, but they might conflict with GNU standards.
<Ribby>The recent GNOME Web / Epiphany web browser onine, is v41.#?
<Ribby>The stable release of guix have v3.34.4. Even the system server says so.
<Ribby>Flatpak is somewhat different. Is it because it is 64 bit? Maybe the later releases are propertiary?
<Ribby>Can you guys look up for linux malware scanners? I know that people claim the encryption is pretty good, but there's a chance for every action. I see clamav/clamtk as potential sources. qube os is said to be good, but requires 64 bit.
<attila_lendvai>if i write a guix.scm file for a random project, then does that file need to be GPL with the standard guix header? if so, i guess that doesn't introduce constraints on the licencing of the project itself, right?
<civodul>attila_lendvai: the file is effectively GPL (unless you keep it private) because it "links" with Guix
<zimoun_>I have an issue with Emacs. Using qwerty, I use modifier key to get French accent. I works fine with Emacs but fails with emacsclient. So I have no clue how to debug. Any idea?
*attila_lendvai is adding the header then. thanks!
<civodul>attila_lendvai: you can put a license header of your choosing, as long as it says "GPL"
<civodul>that has no impact on the license of the rest of the project
<civodul>zimoun_: is that with Emacs input methods, like latin-9-prefix, or are you using something else?
<civodul>i use Emacs input methods in Emacs, and Xorg dead keys elsewhere
<zimoun_>civodul: thanks. But why is it working with full emacs and not emacsclient?
<civodul>zimoun_: it depends: is that with Emacs input methods, like latin-9-prefix, or are you using something else?
<zimoun_>no, I do not think. I did C-\ and selected latin-9-prefix. But it is the same behaviour: a kind of box pops up with the accent modifier and then the display is incorrect.
<jpoiret>also, there might be an issue because emacs --daemon is forking, and also apparently it's awful.spawn now (from the awesomewm docs i looked at)
<zimoun_>yeah, I know about bashrc. All the config is done in bash_profile and bashrc calls bash_profile.
<jpoiret>but isn't that an issue? that would mean that bash_profile is sourced twice then, no?
<jpoiret>once on login, inherited by everyone, and once for each shell you spawn
<zimoun_>maybe, but that’s not an issue, I guess. Except for M-x shell. Well, it is not related to my issue about accent.
<zimoun_>I suspect that it comes from Debian and X.
<jpoiret>well it could, since it does modify env variables. but i guess here it should give you the same as a fresh interactive shell
<zimoun_>This config worked since 2018, it still works on Ubuntu and Debian 10. Using “env -i $(which bash) --login --noprofile --norc“ then export DISPLAY=:0, then ‘source /home/simon/.bashrc && emacs --daemon’ and it works as expected.
<zimoun_>So the only remaining point is X and Debian. :-)
<allana>Hi guix! Yesterday I began creating a guix service, and it works. Now I am refining things. One thing that I am trying to figure out is how to make sure that inputs are found. For example, I feel that setting an environment variable for LD_LOAD_PATH to find the /lib of an input to be a dark corner of my attempt, and I am wondering how a situation like this might normall be handled. Does anyone know how this is normally done, and if
<jpoiret>you generally shouldn't need to set LD_LOAD_PATH in that case, unless it's only dlopen'd
<jpoiret>what program are we talking about for reference?
<jpoiret>but in any case, you can pass a scheme program to make-forkexec-constructor, that you can write using a g-exp!
<allana>openldap, I'm actually using a variant with other configure flags (--enable-crypt) and an additonal input (libxcrypt -- patch request sent a few days ago), and I am creating a slapd service
<allana>And I am using gexps (I'm a newbie, for sure!), but I wanted to make something a little more elegant. My intention was to search the inputs of "package" (openldap) from the service configuration, and build a path for LD_LIBRARY_PATH for each input that has a /lib
<jpoiret>so you could use (setenv "LD_LOAD_PATH" (string-join (map (lambda (path) (string-append path "/lib")) #$@packages-you-want-to-pass) ":"))
<jpoiret>(yes i did take a long time to write that line)
<allana>Ah, that's almost identical to what I was trying, but probably works
<jpoiret>but really the optional deps shouldn't be in the package inputs, but rather as things in the service configuration
<jpoiret>like, you could have a procedure that takes a configuration and gives you the list of optional packages that are needed for it
<jpoiret>one issue i can see is for inputs that need to be propagated to work, which won't work if you call the executable directly i think
<acrow>jpoiret: Mistakes have been made. How can I, or can I?, remedy them to allow guix to have a xalan library? I see that there is history regarding this package and I'm not sure what is needed to work with it.
<jpoiret>wdym by "there is history"? a quick search of the mailing lists turned up nothing
<acrow>jpoiret: which issue should be amended? Maybe close both and start from scratch. I certainly would be happy to just see what I submitted closed for unsuitability and then I would take a fresh, better shot.
<acrow>jpoiret: I don't mean to pick on you. But I suspect you've seen this sort of thing before and I'm curious what you do.
<acrow>jpoiret: what you added was helpful. thank you. I did mistake you for someone involved in the java work. Please excuse me for that.
<f1refly>how do i tell the cargo-build-system not to package optional dependencies for a crate? currently my build fails in phase "package" because an optional input isn't present
<f1refly>would I have to modify the Cargo.toml for that?
<f1refly>A package fails it's packaging phase because the cargo-build-system seemingly tries to pull in an optional dependency that isn't needed and I don't know how to tell it to refrain from doing so
<f1refly>firstname.lastname@example.org with the optional mint crate
<f1refly>I figured I might have to either modify the generated Cargo.toml to not include the optional dependency or tell the build system no to package it, but I don't know how
<zimoun_>civodul: re setuid, it is the same for any user profile, no? Not only “gix shell”.
<gnucode>f1refly: hmmm. I have not played with rust much honestly. Or packaged anything for guix. Best of luck!
<jpoiret>this might be libc's weird execvp semantics
<jpoiret>"If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.) "
<jpoiret>as well as "If permission is denied for a file (the attempted execve(2) failed with the error EACCES), these functions will continue searching the rest of the search path. If no other file is found, however, they will return with errno set to EACCES. "
<jpoiret>it could be good if slock instead dropped its priviledges to the UID
<nckx>Used by services that shouldn't run as a ‘real’ user. Its use is questionable but let's not get into that now.
<jpoiret>i mean, i don't think there are security holes if you're letting slock run commands as you instead of as nobody (you could even argue that running commands for the user as nobody is pretty stupid)
<jpoiret>ie you wouldn't be able to actually use notify-send in that case i think
<jpoiret>i'd be surprised if `sudo -u nobody notify-send "hello"` works
<nckx>MysteriousSilve4: As an immediate work-around, try adding xset or libnotify (whichever you actually care about) to your system's (packages …) list.
<nckx>It might still not work for the reason jpoiret hypothesises but at least you should get a different error message .
<nckx>jpoiret: Agreed on ‘pretty stupid’, not arguing that 😉
<MysteriousSilve4>Sorry, user anon is not allowed to execute '/home/anon/.guix-profile/bin/notify-send hello' as nobody on guix.
<jpoiret>the group shouldn't matter much but you can take your user's group as well
<nckx>TIL that ‘ssh localhost’ first tries (and thankfully fails) to look up localhost.tobias.gr, probably because of my ‘search tobias.gr’ line in /etc/resolv.conf. This might be expected but it surprised me.
<jpoiret>tbh, never use localhost specifically for this reason
<MysteriousSilve4>along with s/anon/nobody/ i added a transparency patch which works with ~/.guix_profile/bin/slock but not with /run/*/slock
<jpoiret>the setuid from /run/setuid-programs/ comes from the package in your system config, that's where you need to apply the patch
<nckx>It sounds like you ‘guix install’d your custom patched version to you user profile. But you need to add it to your *system configuration* (system profile) to affect the setuid version. They are entirely separate, and keeping two copies around will only confuse you & the system.
<iung>Got tftpd-hpa to work for root on debian, but not on guix. Same file permissions (nobody:nogroup 0755), "in.tftpd -s /srv/tftp" command. "Connection timed out" on Guix after "tftp localhost -c get foo". What may be the problem?
<rovanion>I can't manually find a link in /var/guix/profiles that matches /gnu/store/7yqn4s34wk4dbpq5pd5m8vk4jzvg9gfr-profile, do you happen to have a find-command that can help me?
<acrow>How about cd /var/guix/profile/per-user/<you>; then find . | xargs -- readlink -f | grep 7yqn4s
<acrow>Although I don't understand what would necessitate such a search. Maybe guix package --list-generations would give equivalent actionable information that would help, no?
<mitchell>Hello guix. I am trying to package this archive of info pages for the common lisp. However the unpack phase doesn't seem to be unpacking anything. When i build with -K it leaves behind an empty directory. https://paste.debian.net/1233745/
<rovanion>acrow: The problem is that I can't find what keeps texlive in the store/heap. Neither `guix package --list-generations` nor the find command takes me closer to an answer. The root profiles doesn't contain bin/pdflatex either :/
<acrow>rovanion: if the package is in your profile or a dependency of any of thos packages then the package won't be garbage collected and is available for use. What the same for all users including root, but root isn't special. It is sufficient to have it in your profile without regard to root.
<lfam>And you can't find that linked to from anywhere in /var/guix/gcroots?
<rovanion>lfam: Though you have to use the vocabulary of the user, they are asking "why is this thing still eating up my disk?" and if you use technically correct terms like why-alive then they won't find their way to it without hitting it up on stackoverflow.
<lfam>The reasons that a store item are alive are basically these: 1) it's referred to by a profile 2) it's part of an active (currently being built) derivation 3) it's referred to be an active `guix environment` or `guix shell` session
<lfam>There are also manually created "gcroots". But overall, they should be linked to from /var/guix/gcroots unless I misunderstand the feature
<lfam>So, until we have a better tool for exploring this stuff, you kinda have to poke around and evaluate what's going on
<rovanion>Ah, in /var/guix/gcroots/auto is a reference to the manually created gcroot!