IRC channel logs


back to list of logs

<gnutec>My swap file system was disable. What I do? Guix System 1.2.0
<gnutec>gparted say linux-suspend
<gnutec>Ok I got it!
<gnutec>I open my config.scm to see where the swap is, so command "sudo swapon /dev/sda3".
<gnutec>I still don't know why my swap stop, but I did hibernate my system today. I think it is in XFCE.
<Gooberpatrol66>When's the next core-updates rollout?
<jsoo>I asked in #guile but I suppose guix might know, also. I am working on a toml parser in guile and started with nyacc but I would love to describe ranges of characters. I can kinda accomplish this in nyacc but i have to specify every character and my file is now 1 million lines long. Is there a better tool I should be using?
*lfam tests rsync update for core-updates
<lle-bout>hello! is it possible to create a third party channel that overrides some packages included in the official GNU Guix repo?
<jsoo>lle-bout: overrides, maybe not. It is easy to make a different named package or one with a different version. Maybe you would prefer to use a local checkout instead?
<jsoo>lle-bout: what are you trying to do specifically?
<ryanprior>jsoo: a TOML parser is something I've wanted, thank you for working on that. I haven't done any parsing at all in Guile yet, but if I did, I'd start with a PEG grammar
<lle-bout>jsoo: I feel a bit left out in that the bandwidth of GNU Guix committers seems very much full already and I would be looking for a way to offer a way for people to easily test changes to some part of GNU Guix itself or packages
<ryanprior>I've used PEGs in Python, JavaScript, and C++ and typically have a good time
<lle-bout>I feel like maintaining a fork downstream is a huge amount of work since GNU Guix moves so fast
<ryanprior>lle-bout: it sounds to me like you'd want different versions then, no need to override the packages in Guix.
<lle-bout>ryanprior: It's very messy to maintain
<ryanprior>Like, if your testing channel has a newer version of a Gnome package that we haven't had time to test yet, you can just bump the version (even by adding a "-pre1" on the end or something
<ryanprior>What makes it messy?
<ryanprior>I maintain a ton of packages for testing purposes, it's all pretty orderly
<jsoo>lle-bout: I have used a local checkout for a long time. I have about 400 patches that are incubating and it is a little painful admittedly at times. But that's because I have to use rust for work and have patches for rust itself. However it is much easier to submit patches when using a local checkout than with a channel. So I wonder if your goal is
<jsoo>to submit patches eventually or not?
<ryanprior>So if I can understand what's making it messy for you maybe I can help build you some tools to clean up the mess :)
<lle-bout>ryanprior: it's more about core changes.. :-/ - arch porting
<lle-bout>jsoo: I would like to but I am not sure I will be able to meet the upstream requirements..
<lle-bout>e.g. reproducibility
<lle-bout>400 patches is kind of insane
<jsoo>ryanprior: I am a functional programming enthusiast so I really know mostly about parser combinators. Peg seems ok, can you specify a range of characters as a class?
<jsoo>lle-bout: yeah I feel the same way. However, the docs on contributing lay out how to test for reproducibility quite nicely.
<lle-bout>jsoo: testing is ok, fixing reproducibility problems on an arch where no one really ever did that in the eco system is another
<jsoo>however I do think overall I prefer the local checkout to the channel. I've done both
<ryanprior>In every PEG system I've used, you can include regexes as constituent parts of your PEGs
<ryanprior>I also like parser-combinators :)
<jsoo>Yeah. That's not enough. I want to specify predicates on characters in ranges
<jsoo>I think nyacc comes close if I could specify my own tokens in the lexer
<jsoo>Hm. Maybe there's a good way to do a character class in the guile regex library
<jsoo>lle-bout: yeah arch changes can be tough but I'm not sure a channel or a checkout will make too much difference there
<ryanprior>Doing good unicode parsing is hard
<lle-bout>jsoo: is my goal is to upstream changes, upstream changes so often in that regard that I am bound to repeat work very often
<lle-bout>if my goal *
<ison>lle-bout: Maybe you could use package-input-rewriting? It will replace all instances of one dependency with another recursively
<lle-bout>jsoo: in a channel? Oo
<jsoo>what do you want to change lle-bout?
<jsoo>Is there a specific package you want?
<lle-bout>make-bootstrap, glibc, gcc, in a way that it wouldnt break in future GNU Guix releases
<lle-bout>patches break too often
<ryanprior>It sounds to me like what you'd want is to have a whole separate Guix installation
<lle-bout>I felt like language-based "patching" could allow to modify GNU Guix itself with less breakage than raw (not language aware) patches
<jsoo>I see. If the idea is to upstream the patches eventually, I think the checkout is still the best option since you will have to deal with conflicts eventually
<ryanprior>If you're patching things at that low level then having a channel doesn't seem like it would be very helpful
<constfun>Hello everyone, I'm repackaging some ocaml opam packages and am trying to understand the conceptual model of guix dependeny management in this context, I would appreciate any guidance.
<lle-bout>thank you both.. don't know what I'll do
<lle-bout>GNU Guix at many places self-references it's own origins (like the git repo) which makes it not so easy to fork to make a derivative distribution
<lle-bout>if anyone has time to review this and has commit rights it would be nice.. - even if I know there's just *so* many things to review :-|, this should be quite easy to review
<constfun>(complete message) Hello everyone, I'm repackaging some ocaml opam packages and am trying to understand the conceptual model of guix dependeny management in this context, I would appreciate any guidance. I noticed that at some point all the JaneStreet packages were there, for example. Then in a lot of modules were "namespaced" to a specific compiler versi
<constfun> 4.07. Why? Is this a normal thing to do? I see a mix of compiler specific and non-specific versions in the current ocaml.scm for example. I suppose at this juncture I would have to repackage all JaneStreet packages if I were to use a newer compiler?
<constfun>I'm starting to see the pattern This was helpful.
<bdju>does guix have any default DNS stuff that would interfere with router DNS settings? I tried to put OpenNIC DNS servers in my router settings, but I still can't access the sites.
<lispmacs>what was the command again to download a package's source archive from the command line?
<lispmacs>the emacs shortcuts are broken again
<terpri>lispmacs: guix build -S $PACKAGE
<terpri>bdju, i don't think guix does anything unusual with dns settings, it simply uses nscd
<terpri>with '(name-service-switch %mdns-host-lookup-nss)' in my OS declaration (for .local support), nslookup reports that dns lookups are directed to the router, as expected
<bdju>alright, thanks.
<terpri>it can be manually overriden by NetworkManager i think (e.g. DNS settings other than "automatic" for specific wifi networks, maybe similar systemwide network settings somewhere)
<bdju>for some reason Nyxt can get past those cloudflare browser checks, but both qutebrowser and icecat are stuck on them forever. also I can't get opennic sites to work after setting opennic dns in my router
<lispmacs>when I run celestia, I for some reason don't get images of any moons or rings. Is that a problem for others?
<lispmacs>I can select a moon and zoom into it, but it isn't there
<lispmacs>am wondering if some data files got packaged wrong or something
<leoprikler>Anyone working on packaging GTK4 (to be released in 10 days)?
<ryanprior>Possibly raghavgururajan knows
<guix-vits>sneek: botsnack
<divoplade>Hello, on guix system with linux 5.9.12 I cannot create containers: error: cannot create container: unprivileged user cannot create user namespaces, error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"
<divoplade>Is it happening to you too?
<divoplade>The /proc/sys/kernel/... file does not exist
<bdju>which package has the dig command?
***apteryx is now known as Guest72514
***apteryx_ is now known as apteryx
<guix-vits>divoplade: idk, but grep /run/current-system/kernel/.config for USER_NS or so. if it isn't set, u can experiment with a custom kernel (see 'make-linux-libre* in gnu packages linux).
<guix-vits>it accept extra-options to append.
<divoplade>guix-vits, it has CONFIG_USER_NS=y
<divoplade>I'm thinking it's a bug
<divoplade>I tried to reboot
<divoplade>I'll try with linux-5.4
<guix-vits>cool ;)
<civodul>Hello Guix!
<kisaja[m]>what is default nftables ruleset, how do i see what are those rules
<civodul>kisaja[m]: hi! unless you're using nftables-service-type, rules are left unchanged
<safat>Is this good for config Shadowsocks?
<cbaines>safat, if you're having a OpenSSL problem, I'd try using the latest version of the package in Guix
<cbaines>there was a change made very recently
<civodul>cbaines: i think the problem is that shadowsocks does not refer to openssl by absolute file name
<civodul>the solution looks good to me
<civodul>though perhaps there are missing quote around the substitution?
<cbaines>civodul, it was recently changed
<civodul>cbaines: oh great, i stand corrected!
<rockandska>Hi there
<mothacehe>hey guix! trying to understand why guix pull insists on building "guix-packages-base-source" while a substitute is available, I found that the sources differ by a few patches: Does that ring a bell?
<rockandska>Didn't use '' for a long time, and yesterday I discover this :
<safat>Now I have this problem:
<civodul>mothacehe: hi! that's the difference between the substitute and the one built locally? how do you build it?
<civodul>audiofile*.patch were renamed before the release
<rockandska>I always tell to my friends : "install/test guix, it doesn't touch your system at all, and if you don't like it or if it mess for whatever reason, you just need to remove the profile loading from your .bashrc"
<safat>cbaines, civodul
<rockandska>and the documentation always state : "other files on your system, such as /etc, are left untouched. "
<mothacehe>civodul: yes, I build it running guix pull --commit=the-commit-with-substitutes
<cbaines>safat, this doesn't look like a Guix issue: OSError: [Errno 99] Cannot assign requested address
<civodul>mothacehe: argh, so that's a bug, like one of them is picking patches from the wrong place
<jeko>Yo Guixters!
<efraim>I'm getting this error with 'guix pull', any ideas? (exception %exception (non-self-quoting 140737047107200 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>"))
<mothacehe>civodul: ok thanks for confirming, I'll dig in
<civodul>efraim: is the daemon running? (errno 2 = ENOENT)
<mothacehe>efraim: looks like your daemon is not there anymore
<efraim>definately running, I'm building packages on that machine
<mothacehe>hello jeko!
<rockandska>yesterday, a friend had a problem, and wanted to temporarily disable "guix" so i asked him to remove the source of the profile but the profile was still loaded and didn't get it until i found.... /etc/profile.d/
***amfl_ is now known as amfl
<safat>cbaines, How do I fix this?
<cbaines>safat, I don't know, I don't use shadowsocks. Have you double checked the IP addresses and ports you've set in profile.json?
<safat>cbaines, This is the first time I want to use this program, I do not know much about this program.
<safat>cbaines, Does this mean the problem is only related to the profile?
<cbaines>safat, well, this is the error you're getting: OSError: [Errno 99] Cannot assign requested address
<cbaines>I'm guessing the IP address and port are set out in the profile
<mothacehe>civodul: found out why! the guix checkout in ~/.cache is not cleaned up, see:
<mothacehe>guess we need to run "git clean -fd" after checkouting in (guix git)
<civodul>mothacehe: d'oh!
<cbaines>hmm, I don't have any untracked files in cached checkouts
***amfl_ is now known as amfl
<mothacehe>cbaines: because you have a fresh checkout maybe?
<mothacehe>mine is older than 1.2.0, with untracked files removed since then
<civodul>actually my ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/ is clean as well
<civodul>and it definitely predates 1.2
<cbaines>mothacehe, I've just checked the cache used by, it's very old, and also clean
<mothacehe>mmmmh, that's strange
<cbaines>mothacehe, I wonder if interrupting Guix/Git could cause what you're seeing
<cbaines>mothacehe, cleaning out untracked files sounds like a good idea, but it seems like it's more to guard against weridness, than something that's needed all the time
<civodul>right, we already reset --hard
<mothacehe>we are using "git reset --hard"
<civodul>and normally there are no untracked files in there
<cbaines>I don't think that deletes untracked files
<mothacehe>which doesn't remove untracked files apparently
<civodul>but if you don't manually fiddle with ~/.cache/checkouts, there cannot be untracked files
<civodul>unless interrupting the checkout can mess with that
<mothacehe>can't remember messing with it, so it might be interrupting then
<mothacehe>maybe it's a consequence of going back and forth. When pulling to an older commit, then pulling to a new one, git will probably leave those untracked files
<mothacehe>i'll try to reproduce it
<kisaja[m]>how can i add skeleton to "/home/userr/.config/sway/" instead of "/home/userr/"
<efraim>kisaja[m]: checkout the nano example
<efraim>i assume you found gnu/system/shadow.scm
<kisaja[m]>i didn't find it
<efraim> the whole thing is inside default-skeletons, I'm not sure of the easiest way to modify it.
<civodul>mbakke & all: i've pushed an "ungrafting" branch that ungrafts a few things
<civodul>some are still missing, like curl
<civodul>please ungraft what you care about and let's start building it by the end of the day!
<ngz>Are we over yet with #t at the end of phases? I thought so, but I just read a post from cbaines contradicting it.
<mbakke>civodul: sounds good!
<mbakke>ngz: the restriction has been lifted on 'core-updates'
<mbakke>so, "soon"
<ngz>Aaahh, so I'm ahead of time.
<ngz>It will also include snippets, right?
<rockandska>any thoughts about my story with "/etc/profile.d/" on foreign distro ?
<divoplade>Is there an ocaml team in guix? Do you think we could have js_of_ocaml? As far as I can see, the JS runtime is effectively JS source, and the license is OK for everything
<civodul>ngz: yes, also code snippets
<ngz>civodul: OK, thank you.
<civodul>the beginning a joyful era!
<ngz>Guix is now post-#truth
<civodul>that together with the removal of the mandb hook
<civodul>post-#truth :-)
<ngz>The removal of that hook is also an interesting tweak.
<civodul>divoplade: hi! roptat and brettgilio are perhaps the main people taking care of OCaml
<civodul>i agree that having js_of_ocaml (and Occigen?) would be nice
<civodul>and like you write, we'd have the source for that JS code
<civodul>rockandska: re /etc/profile.d/, i agree that the manual should mention it
<civodul>i do think it's a nice improvement though
<divoplade>Especially js_of_ocaml, I think. We don't have that many solutions to write client-side JS code in guix ;-)
<rockandska>civodul: in which way it is an improvement ? if a user want to disable guix it is not easy as it was before
<divoplade>(I wanted to say, client-side applications)
<rockandska>civodul: as a user on foreign distro, i would prefer to have something like source <(guix init-profile) in my .bashrc who does all the pre-requisites than having something in /etc/profile.d/
<divoplade>rockandska, *.bash_profile
<rockandska>divoplade: indeed, .bash_profile instead of .bashrc
<civodul>rockandska: it's an improvement in terms of providing something that works out of the box
<civodul>we got feedback from users who didn't get those bits right, or struggled a bit before they did
<civodul>so it was important to address it
<rockandska>sure, but juste adding a "source ..." in profile is not hard
<civodul>as for ~/.bash_profile vs. /etc/profile, since it's a global installation, i think it makes more sense to fiddle with /etc/profile
<rockandska>now users can't disable guix if they want
<civodul>disable as in "delete", or just remove Guix entries from PATH etc.?
<rockandska>another argument, is that is totally detached from guix, and if you want to update to add other things, you're not able to
<rockandska>disable as not loading profile and expand all vars to just not have guix in a current shell
<rockandska>previously it was easy
<civodul>i'm not sure how to address both needs
<rockandska>;) always
<rockandska>i could understand the "out of the box", but having a command for that and adding it manually would be best in my opinion (and even using this command in /etc/profile.d/ to be able to update it)
<rockandska>you could eventually prompt the user at asking for it ?
<civodul>yes, sounds like a reasonable option
***MidAutumnHotaru3 is now known as MidAutumnHotaru
<rockandska>and all the logic inside /etc/profile.d/ should reside inside guix itslef to be able to be update when you need to
<rockandska>today this file is totally outside from guix
<rockandska>having a unique entrypoint like "guix init-shell" would solve this
<nckx>Morning Guix!
<nckx>rockandska: You can simply delete (or move) /etc/profile.d/ It's still as easy as before, but now it just works for the majority of users.
<nckx>We could make /etc/profile.d/ a symlink to a file managed by Guix instead of a copy-once skeleton. Starting guix just to echo some shell code is a pretty heavy-weight operation; the start-up time is perceptible here.
<divoplade>If I run guix import opam js_of_ocaml, I get: X.509 certificate of '' could not be verified I'm on guix system, with nss-certs installed; if I download the thing with wget it works. Do you know why guix import can't find the certificats?
<rockandska>nckx: to access /etc/profile you need to be root, and if the user who want to disable his profile is not root, he can't without delete guix file ~/
<rockandska>nckx: starting guix to just echo some shell code is heavy but is already the case with `guix package --search-paths=prefix`
<nckx>rockandska: Where is that called? I can't find it in
<rockandska>nckx: it is called and on foreign distro at least ( not sur if it is in guix os ) :
<rockandska>even without /etc/profile.d/ i remember to have to call it in my .bash_profile
<nckx>rockandska: The default /etc/profile.d/guix on foreign distributions does not call guix at all.
<nckx>If yours is older and does, that sounds like a good argument to make it a symlink -- if that's supported everywhere.
<guix-vits>divoplade: roptat did ocaml, if i not mistaken.
<nckx>‘. "$GUIX_PROFILE/etc/profile"’ already takes care of what search-paths would do.
<rockandska>nckx: indeed. i have an old version of guix installed, so there is no more need to have `guix package --search-paths=prefix` in .bash_profile ? I remember it was required some times ago
<nckx>It ‘shouldn't’ be 😉
<nckx>If it still is, please file a bug.
<roptat>divoplade, guix-vits, right, but it works here...
<divoplade>If we're talking about guix import, it works in --pure environments, so that's not really a pb
<roptat>can you check system time, and that you have the three *SSL* variables in your environment?
<divoplade>I have those
<roptat>especially, I think GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt is very important
<divoplade>I have GIT_SSL_CAINFO=/run/current-system/profile/etc/ssl/certs/ca-certificates.crt
<roptat>good enough if you have nss-certs in your system packages
<divoplade>But don't worry
<divoplade>It works in guix environment --ad-hoc --pure guix
<divoplade>There's a strange thing I don't understand: there are two packages, js-of-ocaml, and js-of-ocaml-compiler that have the same source
<divoplade>But different dependencies...
<divoplade>Somehow one of them is lying
<roptat>that's due to how opam works, they have two packages too
<divoplade>But how does guix know which one to build?
<roptat>you can create more than one opam package from the same source repo
<civodul>"guix import opam js_of_ocaml" works for me but... there's a stale pk in there :-)
<divoplade>what's "pk"?
<roptat>whoops, I'll remove it :)
<civodul>divoplade: it's a procedure that prints its argument, used for debugging
<ss2>hah, funny, asking questions in the wrong channel and wondered why I'd get no clear answer.
<ss2>anyway, is it possible to do a guix system reconfigure while the machine is offline?
<ss2>I'd be only fiddling with some settings, and I know that there's no need to check any online repository.
<roptat>most of the time, no, but if you're just changing a few settings and haven't run guix pull since last time, it should be fine
<ss2>The profile can be rebuilt locally. My laptop doesn't always have an internet connection.
<ss2>I haven't pulled, but it always updates the channels.
<roptat>what do you mean? aren't channels only updated when you run guix pull?
<ss2>yes, they are.
<ss2>I'd like to avoid that doing a reconfigure
<ss2>*after I pulled
<civodul>when you just want to make a simple change to the system config, you can run "guix describe" and "guix system describe" to make sure both match
<ss2>they do mach.
<guix-vits>roptat: idk. maybe: guix package -i x
<guix-vits>updating substitutes...
<guix-vits>week later, offline: `reconfigure`, cannot download a graft for mozjs.
<ss2>Has it got to do with that I pinned the kernel version with an inferior-for-channels?
<civodul>ss2: it might have to do with the downgrade detection code
<civodul>namely, if you do "sudo guix system reconfigure ...", it'll look at the checkout in ~root/.cache
<civodul>whereas "guix pull" populate ~ss2/.cache
<civodul>so "sudo guix system reconfigure" can end up re-pulling from the Git repo
<ss2>So I'd have to populate ~root/.cache?
<civodul>no you don't have to, i'm just saying that it's a possible explanation of the need for network access
<civodul>(a bug)
<ss2>caches in ~user and ~root appear to be the same, appart from inferiors.
<civodul>you could test that hypothesis by doing "sudo mv ~root/.cache{,.bak}"
<civodul>ah ok
<ss2>It will still check if I pass --allow-downgrades to reconfigure.
<civodul>well that + "sudo ln -s ~ss2/.cache ~root/.cache" (with care!)
<civodul>if you pass --allow-downgrades the whole thing is bypassed
<civodul>actually no, it still checks but simply prints a warning IIRC
<ss2>I have no warning.
<civodul>well yes, because you're not downgrading :-)
<ss2>sure :)
<ss2>hm, so it could be a bug? I hope not. Could open a ticket still.
<civodul>ss2: yes, that'd be nice; be sure to include a sample session, so we get a clear understanding of what's not working as expected
<ss2>okay, will do.
<civodul>efraim: sorry for the mess with gnutls/fixed; i had the changes locally but forgot to amend before pushing :-/
<civodul>perhaps we should just rewrite the history for clarity?
<civodul>i think it's ok
<civodul>efraim: done!
<civodul>a bit cavalier, but hopefully fine
<efraim>civodul: it's fine :)
<ces>Hey, i have tried to make a package for pulseaudio-ctl, and it works, but the executable is not in path, instead it is in gnu/*pulseaudio-ctl/usr/bin/pulseaudio-ctl
<ces>Works here means that i builds, and that i can run it from the path
<roptat>ces, you probably didn't set --prefix properly
<roptat>it should not be in usr, but in bin directly, as in /gnu/store/...-pulseaudio-ctl/bin/pulseaudio-ctl
<ces>roptat: i do "#:make-flags (list (string-append "prefix=" (assoc-ref %outputs "out"))"
<ces> "CC=gcc" (string-append "DESTDIR=" (assoc-ref %outputs "out")))
<ces>Sorry, didn't mean two do two lines
<roptat>the destdir is not necessary if the prefix works
<roptat>are you sure it's not PREFIX?
<ces>roptat: Now that you say it, i am pretty sure that it needs to be allcaps
<ces>roptat: thanks, that worked!
<civodul>efraim: am i right there are no replacements left now on the ungrafting branch?
<dongcarl>Hey all, stupid question, but how would I print out `%default-substitute-urls` in the command line?
<rekado>dongcarl: echo "(@ (gnu) %default-substitute-urls)" | guix repl -t machine
<dongcarl>Hmm... Getting: `(exception unbound-variable (value "module-lookup") (value "Unbound variable: ~S") (value (%default-substitute-urls)) (value #f))`...
<dongcarl>Is `%default-substitute-urls` somewhat new? Haven't pulled in a while
<nckx>dongcarl: Yep (quite a while, though ;-)
<dongcarl>Ah I see. Gotcha
<rekado>dongcarl: its export location has changed, so maybe you can get it from (guix store) instead
<dongcarl>rekado: Marvelous!
<nckx>Nov 16.
<rekado>would be nice if we could make “guix repl” quiet
<dongcarl>Yeah I wonder if there's a way to have it print in "porcelain" mode for scripting purposes
<nckx>That's what -t machine is supposed to be.
<nckx>But it's not quiet because it expects a client to read its chatter.
<nckx>(REPL-VERSION is pretty important then, I guess.)
<dongcarl>I see I see
<dongcarl>Guile is not terribly hard to parse I guess :-)
<guixy>I'm working on packaging duktape so we can upgrade openrct2. Duktape doesn't have a config system, and instead just has a bunch of makefiles. Is there an existing similar package I can use as a reference?
<nckx>The current workaround for ‘quiet’ operation is ‘echo "(display (@ (gnu) %default-substitute-urls))" | guix repl /dev/stdin’.
<nckx>guixy: (delete 'configure) and setting #:make-flags doesn't cut it?
<nckx>Examples of both are very common.
<guixy>nckx, I asked because I'm not familiar with how to handle these things. I'll try that first.
<PotentialUser-94>anyone knows which package i can find zdump ? is there such a thing ? i just cant find anything
*lfam builds new openssl
<civodul>lfam: oh right it's today
<civodul>we'll have to delay the 'ungrafting' branch presumably
<mbakke>oh good, was just about to start that
<mbakke>hm, apparently we've missed CVE-2020-8231 in cURL:
<mbakke>'guix lint -c cve curl' does not see it
<mbakke>I'll update it on the ungrafting branch, does not look serious enough to warrant a new graft
<lfam>Should the openssl replacement be public? So that would `guix install openssl` would provide the latest?
<civodul>👍 mothacehe :-)
<civodul>mbakke: we should investigate why the cURL CVE isn't caught
<civodul>lfam: "guix install openssl" installs the replacement anyway, unless --no-grafts is passed
<lfam>I see
<DynastyMic>Hi guys, new to guix. Want to start a personal VueJS project on guix.
<DynastyMic>What's the correct way to install npm
<DynastyMic>or should I use environments?
<DynastyMic>what's the guix way?
<bavier[m]>either way is guixy
<bavier[m]>installing npm to your profile ensure it's there all the time.
<lfam>mbakke, civodul: Patch sent
<DynastyMic>Is there a guide on how to do node development on guix?
<bavier[m]>and environment makes it easier to control the exact inputs, and you can do containers, etc
<DynastyMic>would prefer to use environments for novelty sake
<bavier[m]>there are several blog posts about how difficult nodejs packaging is ;)
<lfam>We really need to remove openssl-1.0
<lfam>Or find another upstream
<roptat>DynastyMic, basically, you should install npm from guix, then you can configure and use it as usual; the ideal way would be to use guix packages instead of npm, because guix has many more guarantees, but packaging node.js packages in guix properly is next to impossible
<kozo[m]><civodul ""> Are these options ready to be used?
<DynastyMic>roptat thank you, you saved me a ton of useless research
<mbakke>lfam: oh right, OpenSSL 1.0 is completely unsupported now?
<lfam>mbakke: One must pay for 1.0 support
<lfam>Unfortunately it's not that easy to google for "1.0.2x" since people have been using it as a "placeholder" for years
<mbakke>I wonder how compatible LibreSSL is
<lfam>They do give the Git commit hash of the fix for 1.0.2, but the repo is not public
<mbakke>that's harsh
<lfam>Check the "Fixed in OpenSSL 1.0.2x" line here:
<lfam>I wonder if CentOS has access
<lfam>And here is the relevant info:
<lfam>Anyways, `guix refresh -l` shows quite a few packages that transitively depend on 1.0.2
<mbakke>there are only 21 packages that use OpenSSL 1.0, I'll try to migrate them to LibreSSL
<lfam>Or, we could check if they can use the newer OpenSSL. I just did this for isync
<lfam>I worry that LibreSSL is not going to viable long-term due to licensing problems
<mbakke>lfam: most of those packages are because early Rust compilers depend on OpenSSL 1.0
<lfam>Right mbakke
<lfam>I'm also looking into the vde2 package, which QEMU depends on. It may not use OpenSSL at all anymore
<mbakke>I'm surprised it used OpenSSL at all
<lfam>I don't really know anything about it
<lfam>It's using OpenSSL for... blowfish
<mbakke>right, should be "easy" to find another implementation...
*mbakke was busy on a phone, continuing on that ungrafting branch
<lfam>I wonder if other implementatoins are really going to be better than OpenSSL 1.0
<mbakke>it's surprising that the API changed enough in 1.1 to break it
<lfam>So, recent versions of vde2 use wolfssl instead of OpenSSL but, afaict, they aren't any actual "releases":
<lfam>And the newer version uses ChaCha
<nckx>guixy: Any luck?
<ss2>civodul: well, it turns out that I never let it to complete an offline reconfiguration. The system always checks the repository, then it appears to silently(?) time out. I don't know if this is true though, but it is confusing.
<nckx>Oh, cool, fetching my spam just got cybersecure. Thanks lfam!
*nckx updates.
<lfam>Might as well wait a few minutes for <> to pass review
<guixy>Still debugging. I wish it had a proper config system.
<ces>│19:52:48 lfam | Might as well wait a few minutes for <> to pass review │ cairn
<cairn>Did you.. mean to ping me?
<cairn>Weird. I really can't tell why I was pinged...
<mbakke>hmm.. it's tempting to get Python 3.8.6 while at it (re ungrafting).
<mbakke>thoughts civodul, lfam?
<mbakke>gnu/packages/python.scm:365:2: python@3.8.2: probably vulnerable to CVE-2020-14422, CVE-2020-15523, CVE-2020-26116, CVE-2020-27619, CVE-2019-18348
<guixy>I got duktape working
<lfam>mbakke: It might require some actual work, unlike the ungrafting
<PotentialUser-42>Friends, can you package this app ( for Guix?
<mbakke>lfam: I suppose, if there are packages that rely on bugs in 3.8.2.
<PotentialUser-42>Those who have the ability to package, please package this app ( for Guix.
<mbakke>lfam: what do you make of ?
<lfam>mbakke: I'm not really in the right state of mind to make a judgement about it
<mbakke>PotentialUser-42: I'm sure you can figure out how to package it too. :-)
<guixy>I won't be able to send a patch updating openrct2 until Christmas.
<guixy>Lots of stuff to do :)
<PotentialUser-42>I do it myself
<guixy>I've got some of it working, but now it wants nlohmann-json
<mbakke>guixy: it's named 'json-modern-cxx' in guix
<mbakke>perhaps we should rename it
<guixy>Why didn't it show up when I searched for 'nlohmann'?
<mbakke>guixy: that's...unfortunate. :-)
<guixy>How can I force cmake to include a particular directory for its include search path?
<mbakke>uh, 'ghostscript' fails to build on the ungrafting branch
<lfam>Ghostscript always brings some complication
<civodul>uh, how come?
<mbakke>I think it has to do with the FreeType update.
<mbakke>we likely need this commit:;a=commit;h=41ef9a0bc36b9db7115fbe9623f989bfb47bbade
<mbakke>I discovered it only because I wanted to apply the patch for
<civodul>ah, the patch looks reasonable
<mbakke>civodul: do you have a preference between Python 3.8.6 or adding a new graft post-ungraft? :-)
<mbakke>for reference:
<civodul>mbakke: in principle i think we should stick to well-tested changes
<civodul>a Python upgrade, and an untested one, seems more risky to me
<civodul>(also what do you think warrants a graft for this release?)
<mbakke>civodul: mainly this bug:
<mbakke>the python issue is more descriptive:
<mbakke>people running Python web servers such as myself would want this, I think
<civodul>oh i see, makes sense
<mbakke>but I agree that jumping on 3.8.6 is risky..
<jonsger>rekado: are you fine with pushing this to core-updates? It changes texlive-bin so maybe you have an opinion on it :P
<mbakke>in fact 'python-babel' fails to build with Python 3.8.6
<mbakke>jonsger: LGTM
<mbakke>civodul: I took the upstream commit and added it on the ungrafting branch.
<mbakke>I also added a (high severity) security fix for ghostscript, we might want to graft it on 'master'.
<slimjim>hi #guix, I did a "guix pull" today and am having trouble with python packages in the 'guix environment' command
<mbakke>what kind of troubles slimjim?
<slimjim>example: guix environment --pure python2 python2-cryptography
<slimjim>fails to run with AttributeError: module 'enum' has no attribute 'IntFlag'
<civodul>mbakke: awesome!
<slimjim>actually it looks like it did work, as I'm in a new environment (verified by running env) put it output a lot of error messages
<slimjim>but then in that environment when I launch python2 then try to "import cryptography"
<slimjim>I get "ImportError: No module named cryptography"
<mbakke>slimjim: python-cryptography has deprecated python2 support (it still works, but gives warnings)
<mbakke>slimjim: maybe you forgot --ad-hoc to the 'guix environment' command?
<slimjim>If I do " guix environment --pure --ad-hoc python python-cryptography"
<slimjim>then run "python"
<slimjim>python: command not found
<mbakke>slimjim: yes, you need to run 'python3', or use the 'python-wrapper' package
<mbakke>perhaps it's time to give Python the 'python' executable by default now that Python 2 is officially unsupported (upstream recommended that Python 2 was 'python' since forever)
<slimjim>hm so even though the package is called 'python' you still have to invoke it as python3?
<slimjim>I thought with --ad-hoc and --pure that wouldn't be required
<jonsger>uff pages on our website are written in "guile html", thought it would be easier :P
<mbakke>slimjim: the 'python-wrapper' package provides a Python 3 'python' executable though
<slimjim>mbakke: ok thanks!
<mroh>slimjim: `guix environment --pure --ad-hoc python2 python2-cryptography -- python -c 'import cryptography'` seems to work.
<slimjim>mroh: yes that works for me. With "python python-cryptography" it wasn't, because I didn't realize I had to invoke it as python3
<slimjim>confusing that in a pure/ad-hoc environment with python2, you can invoke python, but in an environment with package python, you have to invoke python3
<mbakke>slimjim: Python upstream always recommended that the 'python' name was reserved for Python 2.
<mbakke>not sure if that has changed now.
<slimjim>so can someone explain why --ad-hoc is necessary to get the import to work?
<slimjim>guix environment --pure python python-cryptography -- python3 -c "import cryptography"
<slimjim>fails without the --ad-hoc
<mbakke>without --ad-hoc, you get an environment with all the build dependencies of python-cryptography, in case you want to hack on it
<mbakke>there have been discussions of reversing that relationship too :)
<slimjim>I see, it isntalls the deps but not the package itself?
<slimjim>ok thanks that clears things up!
<slimjim>BTW I really love guix, thanks for all the hard work. Loved reading the 1.2.0 release notes
<slimjim>and I saw in my last pull that guix publish has the --advertise, and the daemon has --discover now
<slimjim>I'm very excited about that!
<mbakke>these are exciting times, glad you enjoy it! :-)
*mbakke afk
<lfam>I'm using the OpenSSL graft. I'll push it this soonish
<ces>Is there a way to run commands in a build phase, or even better just make a new build system where one can define commands? I can't really figure out how to do this, although there are examples of how some build systems are defined, i can't actually make it work...
<rekado>jonsger: 41162 looks fine to me, thanks!
<lfam>ces: Can you clarify what you are trying to do?
<slimjim>mbakke mroh: slightly different bug with "guix pack" -- if I do: guix pack -RR python python-cryptography bash -S/bin=bin -S/etc=etc; tar xf <PACK PRODUCED BY PREVIOUS COMMAND>; . env/profile; ./bin/python3 -c "import cryptography"
<slimjim>it fails with ModuleNotFoundError: No module named '__future__'
<slimjim>but if I cd into bin and run ./python3 -c "import cryptography"
<slimjim>it works
<slimjim>so whether or not the import works depends on my current working directory when I invoke the python3 command within the pack
<jonsger>rekado: most kudos should go to cbaines, he found it resting in the bug tracker ^^
<slimjim>however it works from either path if I do NOT include "bash" in the pack
<slimjim>originally ran into the issue when trying to get pack -f squashfs to work with singularity, as the documentation says that for singularity, bash always needs to be in the pack
<slimjim>but adding bash into the pack somehow makes the python import path relative to your CWD
<ces>lfam: Install a python program for uni, from uni
<ces>It has it's own script for installing
<civodul>slimjim: did you check how ". env/profile" affects environment variables? do they contain relative file names?
<slimjim>civodul it doesn't appear to, but it will include whatever the existing value of PYTHONPATH was at the end
<slimjim> mentions a lot of weirdness around PYTHONPATH but seems to have been last touched 3 years ago with no apparent resolution
<slimjim>civodul: to remove interference from exiting variables, I tried all of this from within "env -i /bin/sh" to be in a clean environment
<slimjim>so after I source env/profile, I have only have PYTHONPATH=/gnu/store/w1ddkmark0cnsbc1mqpas9wd8yb160xp-profile/lib/python3.8/site-packages
<slimjim>BUT the symlinks created in that direactory ARE relative
<slimjim>for instance, ls -al $PYTHONPATH shows cryptography -> ../../../../psgq5x5fykci1vdyb85ynd8nfg984rjc-python-cryptography-3.1.1R/lib/python3.8/site-packages/cryptography
<jonsger>hm `haunt serve --watch` seems to be broken in guix-artwork/website
<jonsger>I have to run `haunt build` on every change on a file
<slimjim>civodul: the difference seems to be that in the pack that does NOT contain 'bash', the contents of packs' bin directory are direct files
<slimjim>but in the pack that contains 'bash', the files in the pack's extracted bin/ directory are symlinks
<jonsger>fatal: not a git repository (or any parent up to mount point /gnu/store)
<jonsger>Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).