IRC channel logs


back to list of logs

<ArneBab> erwartete Prüfsumme: 000a9whrjr1cd4pjc23pbl60zwkq3wcb5g61p9qi7fn3hwkp0kyw
<ArneBab> tatsächliche Prüfsumme: 1vl3mrs6c0gv9kn8c49y5xq5j2xc6vabmh1y9z1wdxslwz3hygd0
<ArneBab>hash mismatch for store item '/gnu/store/'
<ArneBab>^ open data seems broken
<Kolev>Guder Owwed un hallicher Grischtdaag, ArneBab!
*Kolev tortures Germans with his Pennsylvanian dialect.
<Kolev>ArneBab: Hope you're familiar with the Paelz.
<mbakke>woah, when did 'guix hash -r' become deprecated, and how do I switch to the new --serializer argument (the help output does not say)?
<jab>Is it possible to run GNU/Hurd Guix System?  Has anyone tried this yet?
<jab>on real hardware?
<jab>I think you would be stuck with using the console only for now...
<Kolev>jab: You would be stuck on 32-bit.
<jab>Kolev  sure.  That makes sense.  I just had not realized that I could run Guix system on the Hurd... that's pretty awesome!
<Kolev>jab: Yes. I like how I can `ls ftp://...`.
<alextee>would having a bash launcher for a binary that sets LD_LIBRARY_PATH cause problems on guix/nixos?
<alextee>also would ldconfig -p provide output for some dependency of the package?
<jab>Kolev if you think that's about a org directory translator?
<Kolev>jab: Huh?
<jab>You set that translator on a directory full or org files.
<jab>The directory magically turns into an org file.
<jab>You can then view the contents of the directory from inside an org file.
<Kolev>jab: Cool.
<podiki[m]>alextee: problem? don't think so, but that would need to point to the store libraries (that's where they live); I don't think we use ld_library_path much
<podiki[m]>ldconfig -p won't show you much I don't think, probably just glibc basics? guix's glibc will read a cache from the store path of the calling binary
<podiki[m]>alextee: may be of interest
<alextee>hmm interesting, thanks
<gabri-el>hey, i'm having the error when i do the guix system reconfigure: guix system: error: symlink: Permission denied: "/var/guix/profiles/", does someone knows something about it?
<gabri-el>should i do guix system reconfigure with root privileges?
<podiki[m]>reconfigure needs to be run as sudo, yes
<podiki[m]>(pretty much the only command I run with sudo on guix is guix system reconfigure)
<gabri-el>sudo -i, right?
<podiki[m]>I don't pass any arguments to sudo, personally
<podiki[m]>just "sudo guix system reconfigure /path/to/config.scm"
<podiki[m]>(you do want to make sure it uses your user's guix and package versions, but pretty sure by default on guix system it passes the relevant environment)
<podiki[m]>(otherwise I think it is sudo -E to make sure environment preserved for the command)
<gabri-el>ok, i will try it
<podiki[m]> in case you haven't seen it
<gabri-el>it worked, thanks. i thought guix reconfigure didnt need sudo because there'snt any mention about it in the manual 'guix system'
***phf-1 is now known as phf-1[afk]
<gnubi3>Merry GNUvidad!
<podiki[m]>sneek later tell gabri-el does say elsewhere but then that should be added to the manual, if you could file a bug report or patch that would be great and thanks for noticing
<sneek>Got it.
***aya is now known as gyara
<rekahsoft>Hi all, I am looking for some clarity regarding how to describe mounting a network file-system (in this case cephfs). I can manually mount the cephfs fs, but the shepherd service does not work. More concerning, when I stop the file-system-/mnt/cephfs service it kills the entire system.
<nckxmas>God Jul and good morning, Guix.
<lfam>Hi nckxmas
<lfam>nckxmas: I'm finishing up #47979, which will touch your work from "installer: Offer the CUPS printing service." 6f13881f1e92
<lfam>Currently that functionality offers all services that are not of certain types to the user, unconditionally
<lfam>I'm adding some new services for the installer (NTP and GPM), but I only want to them to be offered when the user doesn't select a desktop environment
<lfam>However, your 'run-other-services-cbt-page' will offer them, too, because they have a new type that isn't excluded
<lfam>Anyways, I'm thinking of changing the scope of the your checkbox page to just be about printing, for now. So it would only offer 'document' services
<lfam>From the user's point of view, it's similar. They'll still be offered CUPS
<lfam>If we want to offer more services in the future, we can tweak that page again
<nckxmas>Hi lfam.
<nckxmas>This sounds good. So there would be an (explicit or implicit) ‘non-desktop’ service class?
<lfam>Basically, it would do this:
<nckxmas>I think that's as good as it gets with the current not-scalable listy system.
<lfam>It's tricky to decide nckx, at least for NTP. The issue only exists because NTP isn't part of %base-services, but it is part of %desktop-services
<lfam>My patches add NTP and GPM as "administration"-type services
*lfam shrug
<nckxmas>Interesting that this is closer to my first patch (including the ‘document’ nomenclature) than what I ended up submitting.
<nckxmas>Well, low values of interesting.
<lfam>My commit title is misleading. I'm still doing rebase-surgery
<nckxmas>…is it supposed to include a binutils CVE fix?
<lfam>I sent the binutils thing to that ticket by mistake
<lfam>It has it's own ticket now
<lfam>Anyways, I didn't send the latest version of the patch series yet, so what's there doesn't achieve what I'm describing
*nckxmas reads this after having read the series :)
<lfam>Sorry, I should have started with it!
<nckxmas>I think it sounds like an improvement lfam. Thanks. CUPS was the first time I touched that code and it's… OK, but it's not generic, and I think each non-trivial addition will require its own dance around these hard-coded lists.
<lfam>Yeah. Hopefully we don't have to add too much more in this direction
<lfam>I just felt like NTP is essential, and then GPM is a fine "why not"
<lfam>GPM will help people communicate about their problems, I hope
<nckxmas>I agree! They are both essential on all my machines.
<nckxmas>Even nominally headless ones run GPM ‘just in case’.
<lfam>Here's v6: <>
<lfam>I'm building the installer now, and I'm also testing with `guix environment guix -- make check-system TESTS="gui-installed-os`
<lfam>The system test takes a really long time
<lfam>Does GPM make it possible to use the mouse "in the console"? Or "on the console"?
<nckxmas>Bit early for an English quiz but I'd always say ‘on’.
<nckxmas>Are you coding a non-1337 test marionette that uses the mouse? :o)
<lfam>No... I wasn't planning on testing GPM
<nckxmas>LGTM, if I have one nitpick it's the ‘{non-,}graphical system’ dichotomy.
<nckxmas>(if (null? desktop) (offer gpm) …)
<nckxmas>But 🤷 maybe a matter of taste or even beard length.
<lfam>Do you mean, we should always offer it?
<lfam>Like, regardless of what else is configured, we should offer GPM?
<nckxmas>Is that too old-school?
<lfam>We could give these new services types of 'ntp and 'gpm
<lfam>And then it would be simple to move them around
<lfam>Mainly I want to try to get NTP offered (pre-checked, aka "recommended) when people aren't using %desktop-services
<lfam>The rest, I don't really care about
<nckxmas>I'd say it could be useful if your desktop crashes or fails to start but it's 50-50 whether you even get a usable log-in at that point, with our without gpm. Still, that's a separate issue.
<lfam>GPM is definitely *always* useful
<lfam>There's a bug in my v6 patches
<lfam>This is why I didn't mail them yet
<lfam>It's slow to build the ISO images
<nckxmas>If you're using ‘guix system image’ be sure to select the uncompressed-iso9660 type.
*lfam tries it
<lfam>It's already done?
<lfam>I suppose it's nice to have some time to think
<nckxmas>We'll add a mildly-compressed-iso9660 type for you.
<nckxmas>(Yes, it really flies.)
<nckxmas>kreuzberg has some sense of irony:
<nckxmas>Oh, there is a single x86_64 package building after all.
<nckxmas>Ugh. GC.
<nckxmas>With 430G used 440G avail it is very tempting just to kill it again.
<lfam>Do you think any users on berlin have some ooooold profiles keeping old dependency graphs alive?
<nckxmas>It's certainly the kind of thing I'd forget. I'll check.
<nckxmas>If that were a hint.
<lfam>It's something I thought of recently. Worth checking
<nckxmas>So I don't have any forgotten ‘manual’/development roots but there are a ridiculous number of old current & package profile generations.
<nckxmas>I don't think it could hurt to cull those for all users after, say, a month.
<lfam>We should ask first
<lfam>People might have some important weird kludges in place
<nckxmas>Involving the standard current-guix-NNN and guix-profile-NNN links? OK…
<nckxmas>Anyway, deleted mine, too late for this run of course.
<nckxmas>Ooh, that's nasty. I was getting inexplicable OOM errors running the system tests. /tmp (a tmpfs) looks fine at first glance. Check df anyway: 12G used. Turns out Guix left three 3.7 to 4.8 GiB hidden ‘.hash-disk-image-rw’ files there.
<nckxmas>Why even 3; I was running with -j1?
<nckxmas>Shrug emoji going to have a big day today, I can feel it.
<nckxmas>2021-12-26T06:39:40 debug: (ZRjx8bHf): request work.
<nckxmas>2021-12-26T06:39:40 debug: (ZRjx8bHf): no available build.
<nckxmas>(There are thousands of queued builds.)
***ChanServ sets mode: +o nckxmas
***nckxmas sets mode: -b $a:raspbeguy*$#guix-fix-your-connection
***ChanServ sets mode: -o nckxmas
<avp>Hello Guixers. I wonder what 'mirrror://' protocol means in package specifications?
<nckxmas>Hi avp. It's a shorthand for each entry in this list:
<nckxmas>So it's a simple mirror://foo → (foo "" "" …) look-up, with each URL tried in order until one returns 200 (or redirects to it). No geofanciness.
<nckxmas>Or any other fanciness, really.
<avp>Thanks! That makes sence.
<cnx1>i'm trying to install guix sd in a vm, i already `herd start cow-store /mnt` but `guix system init ...` is still eating a lot of memory
<cnx1>fwiw i'm mounting /mnt as tmpfs and /gnu/store,/etc separately as btrfs subvols
<nckxmas>The whole point of cow-store /mnt is to transparently redirect writes to the ‘live’ /gnu/store to /mnt, so pointing it to another tmpfs rather defeats its purpose.
<nckxmas>You should be able to point it to /etc in this scenario, although some of the finer points of your complex set-up might elude me.
<nckxmas>I've said ‘point’ 4 times now. Time for breakfast.
<wehlutyk[m]>Hello Guix!
<wehlutyk[m]>For the past two weeks I've been running into a weird problem when running `guix package -u` (I just have guix package manager on Pop OS, an Ubuntu derivative): `guix package: error: integer expected from stream`
<wehlutyk[m]>I was expecting it to go away on its own with later runs of `guix pull`, but it's still there
<nckxmas>cnx1: I think I see your point: you expected cow-store to write to /mnt/gnu/store, but it doesn't (because that would interfere with the actual guix system init, for one). It creates a hidden directory under /mnt (I think?) which is deleted when you stop the service. So simply making /mnt/gnu/store backed by real storage won't have the effect you thought it would.
<wehlutyk[m]>I didn't find anything in the IRC logs, mailing lists, or issues (though I might have missed something)
<wehlutyk[m]>any hints on how I can fix this?
<nckxmas>I answered two mails about this only this morning. I wonder what's up.
<nckxmas>Could you update your running guix-daemon?
<nckxmas>Maybe the current sorry state of ci.guix makes this more likely somehow…
<wehlutyk[m]>nckxmas: do you mean guix pull and `guix package -u` as root? I'm not sure how I should upgrade just the guix-daemon but not the rest (looking in the manual)
<nckxmas>I'm in turn not very familiar with non-Guix Systems.
<nckxmas>‘On a foreign distro, you can upgrade the build daemon by running: sudo -i guix pull followed by […] systemctl restart guix-daemon.service’
<nckxmas>From ‘Upgrading Guix’.
<wehlutyk[m]>nckxmas: thanks, trying out
*nckxmas has to go; good luck.
<cnx1>nckxmas, the downloads are in /tmp/guix-inst and /tmp is mounted as tmpfs
<bricewge>Hello Guix!
<bricewge>Today I'll try to fix the Nginx Certbot interactions.
<bricewge>It looks like, certbot could extend nginx hosts with an optional include to a file which doesn't exists at initial startup, but will be generated by a certbot hook.
<bricewge>This would allow nginx to start before certbot certificates are generated.
<the_tubular>Which service can I set up using scheme
<the_tubular>I want to practice
<the_tubular>And looking for something useful also
<the_tubular>Also cool, certbot is important :)
<awb99>telegram-desktop is having build problems. Should I file a bug report?
<bricewge>the_tubular: If you want to write a service from scratch, I would say, try the one you are missing on Guix
<the_tubular>My question was pretty much reversed, which service is already written that I can take a look at and try to get an Idea on how it's done
<bricewge>Otherwise there are a certain number of dying patches adding services in the ML
<the_tubular>Got it
<bricewge>sysctl is one of the easiest one
<the_tubular>Ohh, I see Wireguard
<the_tubular>I can try that
<the_tubular>Well in fact, I just didn't know /gnu/services existed it pretty much answer my question ^^
<Kolev>System updates take so long. I should run them in a tmux session.
***phf-1 is now known as phf-1[afk]
<Kolev>This system update has taken days. What is it doing, building everything from source?
<Brandong[m]>Happy Holidays guix folk. :)
<Brandong[m]>I'm trying to package a luajit version of awesome, but guix build --check reveals that my package is not reproducible. I've been trying to bisect for a while now and discover what commit introduced a timestamp or whatever non-determinism, but couldn't find it, and now I've tried guix build --check awesome, just against the package def in guix itself (which I inherit), and it is apparently also not reproducible. I'm wondering if I'm doing
<Brandong[m]>something wrong or if the package just really isn't reproducible.
<jpoiret>Kolev: the weather (aka substitute availability) is pretty bad on master right now
<Brandong[m]>It seems strange because the awesome package in guix specifically has patches to try to eliminate non-determinism in the upstream source.
<lilyp>True, but those patches can be leaky if no one updates them
<lilyp>If you do find out the source (or at least have valuable diffoscope output), send it to bug-guix@
<Kolev>jpoiret: Ah, I see.
<Kolev>Is there a way to get rid of the gray checkered background in GDM? I miss plain black GDM.
<jpoiret>Kolev: is your guix system generation old?
<jpoiret>we have GNOME 40.5 on master, and my GDM has plain black background
<jpoiret>but it is very recent
<Kolev>jpoiret: Hm, maybe I'll get it once this update finally finishes. It's been three days.
<jpoiret>before that, yes, checkered background
<jpoiret>wow, that's a lot
<jpoiret>is it because rust is compiling?
<Kolev>What would need Rust?
<Kolev>building /gnu/store/ps3dl1h6f305411xv3jz6jqqqcx1k957-mutter-41.0.drv...
<nckxmas>But Berlin (ci.guix) has that mutter.
<jpoiret>Kolev: if you are on x86_64, librsvg used by the GTK stack is written in Rust
<Kolev>Oh, goody.
<jpoiret>the worse part is that Rust doesn't bootstrap properly on non-x86_64, so for now an older librsvg is used for other architectures
<nckxmas>Very true, but there's also simply ‘icecat’ in that list.
<jpoiret>that is written in C
<nckxmas>Awesome diff is… weird?
<jpoiret>ah, that's true. I always forget firefox moved to Rust some time ago
<Guest25>lol running `guix size texlive` gives me this:
<Guest25>total: 17592186043379.3 MiB
<Kolev>Forget Emacs. TeX is an OS.
<wehlutyk[m]>> * <> has to go; good luck.
<wehlutyk[m]>nckxmas: Thanks, it worked!
<lilyp>* #awful
<mothacehe>hey guix!
<nckxmas>wehlutyk[m]: Great! I'm glad that the committed fix apparently worked.
<nckxmas>…and now wondering if it's somehow related to texlive being 17 trilliard bytes big.
<nckxmas>Hi mothacehe.
<AIM[m]>If I try to install just ghc-xmonad-contrib will the xmonad and ghc get installed? Like I'm having dependency version issues and I think aome may be due to containerization like thing that guix package manager does...
<nckxmas>mothacehe: If you have the time, could you hazard a guess at the cause for <>?
<mothacehe>nckxmas: I replied to your sysadmin mail this morning :)
<mothacehe>hydra-guix-* are idle because there's no Intel package to build
<nckxmas>My mail server is under maintenance.
<mothacehe>there are 80k ARM packages to build however
<nckxmas>kreuzberg was idle when I sent that.
<nckxmas>I see it's building one job now.
<nckxmas>Should it not be building 2?
<nckxmas>overdrive1 is still idle.
<mothacehe>yup ARM workers are working very badly
<mothacehe>mostly because of:
<nckxmas>Oh, so it's the worker's fault?
<mothacehe>I suspect this is a Guile related issue showing up only on ARM
<nckxmas>Thanks for the link.
<mothacehe>reported on bug-guile, as I'm not familiar at all with Guile internals
<nckxmas>AIM[m]: ghc-xmonad-contrib propagates xmonad ( which means that yes, xmonad will be installed alongside it. Does not appear to be the case for ghc however.
<nckxmas>mothacehe: Me neither, and certainly not on ARM.
<cbaines>mothacehe, I did see which reminded me I had similar problems when wriitng the job processing in the Guix Data Service
<cbaines>I originally tried to fork and then process a job, but I ran in to issues
<cbaines>instead, it now exec's a different Guile script after forking
<mothacehe>cbaines: oh! way is specifically on arm?
<mothacehe>*was it
<cbaines>this wasn't on ARM
<mothacehe>how did you worked around it? spawning processes instead of forking?
<cbaines>I do remember some news articles though saying that ARM has a different concurrency model to x86 though, and that x86 programs might not work on ARM because of that
<cbaines>mothacehe, forking, but then calling exec (execlp specifically)
<paul_j>Good day, and Merry Christmas / happy holidays to one and all!
<cbaines>I guess the other option is just to have one process and a whole bunch of threads
<cbaines>that's what the guix-build-coordinator (and agent) do
<AIM[m]><nckxmas> "AIM: ghc-xmonad-contrib propagat..." <- I thought maybe it may be a little input for the input?
<AIM[m]>Does that work for Guile Scheme?
<AIM[m]>Dependency of a dependency?
<nckxmas>I don't think I understand.
<paul_j>I have a small problem with network privileges which I have failed to find any information on the web. I have the network setup as standard, but for some reason when I try to make a wifi connection, it tells me I have "Insufficient Privileges". This setup was working but at some point is no longer functioning. Since the laptop normally sits in a docking station with an ethernet connection, I am not sure when the problem occurred. Have I
<paul_j>missed something with any of the recent changes? (sorry for the long question)...
<nckxmas>Propagation is transitive, but I still don't see ghc in that graph.
<AIM[m]>The problem seems to be that ghc version for xmonad and ghc-xmonad-contrib seems to be different!
<nckxmas>How are you determining that? ‘guix size ghc-xmonad-contrib’ and ‘guix size xmonad’ both return the exact same GHC here.
<nckxmas>paul_j: I'm not aware of any deliberate changes that would cause that; sounds more like a regression (bug) if it used to work for you.
<nckxmas>I've always had to run nmtui as root here, but don't use a desktop environment. I'd expect the latter to pop up a pretty password prompt at the very least.
<paul_j>nckxmas: thanks for the comments. I am just updating everything to see if there is something untoward there, then will reboot.
<paul_j>In the past I just opened nmtui, and selected a connection. I never needed to use a password. I am using dwm as a desktop manager, but I don't think that has any impact as I haven't updated it my own fork for some months
<paul_j>Activating nmtui as root does work as expected.
<paul_j>Of course I recognise this is an issue with my setup rather than with Guix, otherwise I am sure someone else would have come across the same problem!! :)
<Guest25>is there a way to run git clone on the destination when using `guix system`
<Guest25>i want a way to clone my dotfiles and populate the destination with them when using `guix system image` or `guix system init`
<mroh>How to run tests in gnu/tests/install.scm? `make check-system TESTS="install"` isn't it.
<mothacehe> yes but you have to use the test names specifically
<mothacehe>installed-os, installed-extlinux-os, ..
<mroh>ah, ty!
<nckxmas>paul_j: Specifically, I added nmtui to my operating-system's setuid-programs. If you're positive that it used to work for you without privileges, feel free to open a bug!
<lilyp>Our post commit hooks to send commit notifications are borked
<brown121407>Hi! Is there a (simple-ish) way to run appimages on Guix?
<lilyp>brown121407: crank out patchelf and get to hacking in some runpaths
<brown121407>lilyp: I had hoped the only elves I had to deal with were Santa's... Thanks
<gbrlwck>is there a package to gcc cross-compile from x86_64 host to say riscv64 target in Guix system? for debian there's gcc-riscv64-linux-gnu but i seem to be unable to find something similar for guix
<lilyp>there's the --target argument for packages
<lilyp>as for generating gcc itself, that is done through a function
<lilyp>(with rare aarch exceptions)
<lilyp>as for using Guix on a RISC V system natively, that's currently being bootstrapped
<gbrlwck>hrmmm... i'm working on getting MEScc to output RISC-V M1 (for the full-source bootstrap toolchain) and it would come in really handy if i could get gcc's asm output for riscv architecture on my host machine (since the RISCV one is slowish)
<Kolev>Agh! It's been stuck on “building /gnu/store/ps3dl1h6f305411xv3jz6jqqqcx1k957-mutter-41.0.drv...”!
<ixmpp>Hej, is there a way to modify a package's source/commit inline when using 'environment'
<sneek>Welcome back ixmpp, you have 1 message!
<sneek>ixmpp, abcdw says: We are slightly refactoring Guix Home right now, after that I'll be preparing and moving home services from rde to guix.
<ixmpp>Oh, yes i saw
<lilyp>Kolev: Clear your cache, it ought to be substitutable
<Kolev>lilyp: “guix gc”?
<ixmpp>Fine, alternate question, can i evaluate an scm file as well as list package names in 'guix environment'? Using -l seems to not have the desired effect
<ixmpp>Ah, the ad-hoc thing still applies. Was misled by the help page suggesting -l should come before all packages
<lilyp>Kolev, no ~/.cache/guix
<lilyp>ixmpp: "guix shell" is clearer in the UI here
<lilyp>it's either -f for loading a package (list) or -Df for loading inputs
<Kolev>lilyp: “rm -rf ~/.cache/guix/”?
***caleb_ is now known as Kolev
<Kolev>Woo! I have GNOME 40!
<nckxmas>This seems to come up a lot and while most of us know what's safe to delete it seems to cause some confusion & even anxiety in others. Useful? <>
<constfun>hello all, im messing with `guix home` and am not sure if I'm not doing it right or these are bugs that i should file. my home-configuration file is like so and I'm noticing two undesirable effects 1) the prepending of a dot before every target file is presumptuous, for example the "run" file i have ends up being
<constfun>linked as `~/.run` and not what I expect `~/run` 2) i cannot actually execute the `~/.run` file even though original has the execute bit set. Are these bugs that I should file?
<podiki[m]>nckxmas: that looks useful to me; would there be a need for a confirmation or warning? (I would figure not, but would that require a lot of redownloading at all?)
<nckxmas>No, these are just narinfos, they are tiny.
<Brandong[m]>Is it possible to share data between build phases? I'm in the situation that I would like to patch some env paths set by one phase of a package I'm inheriting from, but when I try to (getenv "FOO") it returns #f.
<nckxmas>Again, it's just a wrapper for rm -rf, but at least it respects XDG_CACHE_HOME and it's a bit friendlier to throw into a chat full of strangers.
<nckxmas>I wrote a commit message so will submit.
<nckxmas>Brandong[m]: Odd, the environment is not at all reset between phases.
<Brandong[m]>nckxmas: Thanks, good to know. I must be registering my phases incorrectly somehow then.
<podiki[m]>nckxmas: sounds good, I think it is good to have
<nckxmas>constfun: I don't use guix home but I'd be ‘surprised’ by both behaviours. Seems worth reporting/asking.
<Brandong[m]>Aha, made it work. :) (add-before 'configure 'set-my-paths <expr>) works, but (add-after 'configure 'their-set-paths <expr>) did not.
<Brandong[m]>er, (add-after 'their-set-paths 'my-set-paths <expr>)*
<nckxmas>Does the original delete the 'configure phase?
<nckxmas>There's a lack of error reporting when you (add-before 'bogus-or-deleted-phase 'foo …) into the void. Or at least there used to be.
<Brandong[m]>No, they simply do (add-before 'configure
<nckxmas>Hm. OK. Anyway, there's no grand environment reset anywhere as far as Guix is concerned.
<Brandong[m]>Thanks for confirming that, got me onto the right track. :) I'm not quite sure why my original add-after didn't work, but I assume calls to add-before run in the order they were executed so this should be just as good.
<efraim>new efl and enlightenment release. That'll be fun to test out before pushing
<constfun>nckxmas: thank you, will do
<efraim>Brandong[m]: unless things have changed recently if you have multiple add-before 'phase calls it will run from bottom to top
<the_tubular>This might be OOS for guix, but is there a way to turn a generation completely read only ?
<podiki[m]>just sent a patch for (run your xinitrc as an xsession from a display manager)
<podiki[m]>handy for those of us that like just a WM but launch from a DM
<lilyp>the_tubular: what parts of a generation are read-write?
***nckxmas is now known as nckx
<nckx>Brandong[m]: Yes. add-after has a ‘backwards’ effect which can be unintuitive at first, but add-before has always done what everyone expects.
<Brandong[m]>efraim: Not sure actually what the execution order ends up being for this, but it compiles the package correctly so it must be right.
<PotentialUser-93>hello!  I just updated guix on a foreign distribution and I'm getting what looks like locale-related problem; the output looks like so on 'guix describe':
<PotentialUser-93>I have glibc-locales installed in my user profile
<jpoiret>PotentialUser-93: if I understand correctly how it works on a foreign distribution, you'd need to `guix pull` and `guix package -u` as root, and restart the guix daemon
<jpoiret>at least that's my understanding of most locale related issues on foreign distros
<PotentialUser-93>I have done so too (went to a root terminal via 'sudo -i', then 'guix pull' and 'guix upgrade')
<PotentialUser-93>I have also restarted guix-daemon via 'systemctl restart guix-daemon'
<PotentialUser-93>still the problem persists, so I'm a bit stumpee
<jpoiret>uhm, actually, aren't those ANSI escape codes?
<jpoiret>do you use an unusual term?
<PotentialUser-93>it's just the default one in gnome (gnome-terminal I think it's called)
<PotentialUser-93>on top of Debian 9
<jpoiret>can you try opening a new terminal instance and rerunning it there?
<PotentialUser-93>yes, it persists even after a reboot
<PotentialUser-93>perhaps it's  because the system's environment is set to French; see the bottom of
<PotentialUser-93>the daemon seems to inherit its environment from the system
<the_tubular>Sorry lilyp, didn't heard that ping. That's a good question I guess, I was reading on Fedora and thinking if we could do the same in guix
<the_tubular>I guess I still don't understand the concept fully, I'd say that my home folder is read-write, but this is probably a stupid answer
<PotentialUser-93>jpoiret I'm not sure if the system's inherited LANG=fr_CA.UTF-8 LANGUAGE=fr_CA:fr variables play along well with the guix-daemon service set LC_ALL=en_US.utf8 one
<PotentialUser-93>jpoiret interesting: I tried 'guix shell xterm' then ran 'guix describe' in it, and the output printed fine
<jpoiret>hmmm, that might be an issue with gnome terminal
<PotentialUser-93>I tried the same in 'guix shell gnome-terminal' and then the problem remained
<PotentialUser-93>so it does seem gnome-terminal related.  Weird.
<jpoiret>I might know why
<jpoiret>those look like hyperlinks, and `guix describe` tries to use hyperlinks if the terminal supports them. Maybe it thinks GNOME Terminal supports them when it doesn't
<lilyp>the_tubular: `guix home' might be what you want
<lilyp>there was previously an even more restrictive home manager, but I don't know about its current state
<PotentialUser-93>jpoiret, do you reproduce the issue on your end?
<PotentialUser-93>(e.g., running 'guix describe' in gnome-terminal?)
<jpoiret>gnome-terminal is a pain to set up (needs to be installed in your profile so that dbus can launch its server)
<jpoiret>but i'm looking at whether it supports them or not
<PotentialUser-93>ah, so in my case given I'm on gnome it must uses the system's (Debian 9) gnome-terminal service, which would already be running
<jpoiret>oh, that might be completely true
<jpoiret> /bin/gnome-terminal is just a simple wrapper that asks DBus to launch the backend
<PotentialUser-93>the gnome-terminal used is 3.22.2, (very old)
<PotentialUser-93>ah, this test reproduces the problem: printf '\e]8;;\e\\This is a link\e]8;;\e\\\n'
<PotentialUser-93>(it prints as: printf '\e]8;;\e\\This is a link\e]8;;\e\\\n'). This means my gnome-terminal doesn't support links.  Weird.
<PotentialUser-93>I think gnome-terminal picked support for it from 3.26
<PotentialUser-93>according to
<jpoiret>although theoretically they should simply ignore those, xfce4-terminal does that for me
<awb99>Is there a wayland tool with which I can view installed fonts? I would like to see how differnet fonts look like.
<PotentialUser-89>oh, interestingly <limit name="auth_timeout">240000</limit> on this Debian 9 box
<PotentialUser-89>we could probably make it in guix to that instead of 60000
<PotentialUser-84>I have two questions. Stallman recommends GUIx. I don't understand linux or gnu. I'm not a programmer either. Is there Turkish in the guix? and does the internet auto-install like Ubuntu?
<PotentialUser-84>is there anyone here?
<PotentialUser-84>Hello guix people helloo
<lispmacs>nope, nobody here
<singpolyma>I am also not here
<lispmacs>I believe Guix has access to many locales - I'm not sure about Turkish speecifically
<lispmacs>I'm not quite sure what you mean by "does the internet auto-install"
<PotentialUser-84>I've been using windows for 30 years. and i hate bill gates. i love stallman so much i want to follow your advice i want to use linux gnu but i don't know what to do and i don't know english either
<PotentialUser-84>Does this OS run photoshop?
<lispmacs>PotentialUser-84: Guix and other free software OSs do not provide proprietary programs like Photoshop, but they have alternative programs available that have similar functionaily
<PotentialUser-84>well I use .psd mockup when I present to my customers. how do i solve this
<PotentialUser-84>And play world of tanks:)
<lispmacs>PotentialUser-84: there is a free software program called GIMP included, which is able to process PSD files, but not to interacte with all of the PSD capabilities
<lispmacs>You could install GIMP on your Windows computer and see if you find it will work for your needs
<PotentialUser-84>I've heard of gimp, I'll try it. thank you. Well, I don't know what to do if other programs I use in windows are needed. You programmers can solve all kinds of things but I'm just a user.
<lispmacs>PotentialUser-84: you will probably not be able to run any of your proprietary Windows games on the GNU OS, though there are some Windows software which is able to run on the "WINE" emulation layer
<PotentialUser-84>how they got us used to it, i hate it.
<lispmacs>WINE is included in GUIX
<singpolyma>PotentialUser-84: if you're used to photoshop you may prefer Krita to GIMP. Both are freedomware
<lispmacs>Krita is also included in Guix
<singpolyma>I would suggest trying out some of these software on your exsting OS first rather than trying to change every part of your life at once
<singpolyma>Krita and GIMP will run fine on your current OS, I believe
<lispmacs>that is a good idea. if you have a spare laptop or something, you could install Guix on that as well, and try it out
<PotentialUser-84>I have work at hand right now I can't take the risk of changing the operating system. I guess it's impossible to try this until I get a new pc. because I need to learn. Unfortunately, I would like to join you, but I do not have the opportunity. Again, thank you for your interest.
<rekahsoft>Hi all, I'm looking for some guidance regarding propagated inputs and profile conflicts, specifically in the context of something like python, where runtime dependencies are propagated. Namely, application A is being packaged and depends on an already existing package dep@v0, however it depends on an odd version, so I package this as dep@v-odd which inherits from dep@v0. This is all good and well in the simple cas
<rekahsoft> however this causes issues, as now users of my package A have to ensure they have no packages that propagate dep@v0 in the same profile as it will conflict with my custom dep@v-odd. In the more complex case, say my package for application A has another dependency X@v0 which is also packaged upsteam. However, X@v0 depends on dep@v0, which results in an issue for my package for application A as dep@v0 and dep@v-odd
<rekahsoft>re propagated which means that my package cannot be installed in a profile. What is the best way to go about resolving such issues?
<lilyp>rekahsoft: "application A is packaged" ← propagation rules mostly govern libraries and stuff that looks like libraries; applications ought to not propagate anything
<ss2>thunar is segfaulting..
<the_tubular>Damn, gotta use dired ;)
<the_tubular>On a more serious note, you compiled it or you got a substitute ?
<ss2>I do actually.
<ss2>I've got it from a substitute.
<ss2>But it isn't segfaulting on another machine.
<the_tubular>Umm ...
<ss2>which are both on the same checkouts.
<ss2>I just tried to run it through gdb, but it complained about missing libraries.
<ss2>have cleared out configs and bookmarks.
<the_tubular>You seem to have covered the basis ... I don't know much after that
<the_tubular>Unless you dig deep with gdb
<rekahsoft>lilyp: that would make a lot more sense, however, looking at the various python applications that are packaged in the guix repo, many of them propagate their dependencies. I assume this is because they are used at runtime after the package is installed?
<ss2>I fired up xfce too, and there thunar quits saying “input/output error”.
<raghavgururajan>Hello Guix!
<lilyp>that'd probably be an oversight on behalf of the packager
<lilyp>though for a python-specific guideline: if it starts with "python-", it is assumed it's a library
<lilyp>for applications like youtube-dl, propagation is a nono and the python-specific paths are wrapped
<ss2>I do see that in thunar-settings that it is not finding gvfs, despite it being in the system profile.
<lilyp>ss2: I fixed a similar issue in tramp (but only the tramp built into emacs, the emacs-tramp package is still borked in that regard); the package was checking for a running process and ignoring the .-real variants
<ss2>no idea. :(
<florhizome[m]><lilyp> "rekahsoft: "application A is..." <- we need some more clear guidance about propagation somewhere in the manual and/or cookbook.
<florhizome[m]>many gtk packages (but also qt, there with cmake) demand library dependencies packages to be installed via pkgconfig and a default with guix packagers seems to be to propagate those. and like this you get wayland indirectly propagated by xfce panel, bc it propagates gtk+ –.–
<rekahsoft>lilyp: Thank you very much for the clarification. Makes a lot more sense now. Another question: say I've installed a python application that is wrapped (so GUIX_PYTHONPATH is set in the wrapper). How does guix guarantee that the packages referred to in the wrapper script will be installed/available?)
<lilyp>florhizome[m]: I already made a suggestion w.r.t. pkg-config :)
<lilyp>rekahsoft: GUIX_PYTHONPATH is added onto PYTHONPATH in guix' python in a way that ensures version compatibility
<lilyp>so even if the package is not "installed", it's visible to the python interpreter
<ss2>then I’ll stick to dired after all.
<opalvaults[m]>nckxmas: sway works like a dream, thanks for helping me get it working
<rekahsoft>lilyp: But couldn't this package be cleaned up via guix gc as it is not explicitly referenced by a profile?
<lilyp>No, guix gc checks for store references, which the wrapper script obviously provides
<opalvaults[m]>lilyp: do you have a link to the repo for the guix cookbook? I'd like to contribute a guide for sway
<rekahsoft>lilyp: makes sense. How does guix gc check for store references?
<opalvaults[m]>I can't seem to figure out where it lies in Savannah :P
<bdju> just hit this TLS error while libreoffice was downloading. just trying to run upgrades again for now in case it was a fluke.
<opalvaults[m]>bdju: i'll see if I can recreate
<opalvaults[m]>Wow I forget how big this package sometimes
<opalvaults[m]>bdju: looks like mine downloaded fine. Might jsut be a fluke?
<Guest25>is there a way to run some commands on the target system after `guix system` is done?
<Guest25>like generating some files that guix doesnt generate itself, like dotfiles etc
<opalvaults[m]>During install Guest25?
<Guest25>after install
<Guest25>whether it be generating an iso using `guix system image` or installing to a drive using `guix system install`
<Guest25>i mean `guix system init` not `guix system install`
<Guest25>wouldnt such a feature be nice?
<Guest25>a post-install script would be a nice option to have
<Guest25>since we cant chroot anyway..
<vivien>Guest25, you can use extra-special-file to add a file to the system
<vivien>(a publicly readable file)
<vivien>Otherwise, I think you should create a service.
<Guest25>hmmm but what if that file i want resides on a github repo
<vivien>You package what’s on the github repo, and use extra-special-file with wile-append, as in (replace coreutils with the package)
<vivien>file-append, not wile-append, sorry
<Guest25>makes sense
<opalvaults[m]>I would even say package it and put it in your own custom channel
<Guest25>ye i think i should create a channel anyway
<Guest25>thanks guys/gals
<Guest25>have a good day
<opalvaults[m]>It'd be easier for these times when you only need a handful of things from this repository or that repository. :
<opalvaults[m]>you too Guest25 :)
<lilyp>opalvaults[m]: same as the manual, it's maintained as part of guix itself
<opalvaults[m]>lilyp: guess it's time for me to learn some latex. :)
<opalvaults[m]>thanks for the info
<ss2>very wierd, thunar began to segfault on ~/.config/user-dirs.dirs, which hasn’t been modified since Jan 2020. It segfaults when $XDG_DESKTOP_DIR="/". problem solved.
<bdju>opalvaults[m]: thanks for checking. I think I got past it now also
<aeka>Having issues building gcc in unpack phase after a guix pull
<aeka>xz: (stdin): Cannot allocate memory
<aeka>/gnu/store/hqysqhh80g7qy8287b8p2gwz0379vh50-tar-1.34/bin/tar: /gnu/store/2xwgc1g15pwfhfvgvk6maqfmb1q5d529-gcc-10.3.0.tar.xz: Wrote only 2048 of 10240 bytes
<aeka>any ideas?
<roptat>hi guix!
<aeka>`guix build --check gcc@10.3.0' runs with no problem, but I suspect that this is not actually the same package (build does build anything..)
<roptat>I almost managed to update my android packages to android 12, but adb is still failing because there are identical headers in the build directory and in one of the dependencies
<roptat>I get an error from clang about the redefinition of an optional argument
<roptat>the headers have #pragma once. I wonder if clang has some option to notice that two files are identical and to only include them once?
<aeka>I'll do one more `guix pull' just to see what happens.
<aeka>as I notice I don't have `guix style'
<florhizome[m]><lilyp> "florhizome: I already made a..." <- nice :)
<aeka>(also why was `guix style' made separate from `guix lint'? seriously)
<lilyp>guix lint is not meant to rewrite files; guix style is not meant to check for issues
<aeka>so add a flag to guix lint
<aeka>make lint do dry runs by default
<aeka>we're splitting hairs too much
<aeka>like with `guix environment' and `guix shell'
<aeka>two awfully similar commands
<singpolyma>aeka: guix environment is deprecated
<lilyp>Well, not yet, but it's growing out of favor
<aeka>but when will it be removed is the question
<lilyp>there will first be a warning to plop up for a c-u iteration I guess
<singpolyma>aeka: is there any benefit to removing it? Just breaks old scripts
<aeka>singpolyma: yes, it confuses less newcomers
<singpolyma>Just don't show it to newcomers
<Kolev>Remove it. Break hard and fast!™
<aeka>I guess that's another option, just bury it
<aeka>but I'd rather get rid of cruft
<florhizome[m]>I would like a single prefix for profiles
<florhizome[m]>There is way too much crammed under package
<florhizome[m]>Get rid of install/upgrade maybe
<aeka>those are just aliases
<florhizome[m]>As they are only aliases
<florhizome[m]>well, that’s the point
<Kolev>guix install : guix package install :: apt install : apt-get install
<Kolev>Keep it.
<aeka>I'm more concerned about giving too many different ways of doing similar things
<Kolev>No. “guix install“ is great.
<florhizome[m]>That’s why I’m for cutting install and upgrade
<aeka>install, uninstall, upgrade, are fine as those just reduce to invokations of `package ...'
<Kolev>guix install : guix package install :: apt install : apt-get install
<lilyp>Kolev: now do guix package -i foo -r bar
<lilyp>without busting out a shell tyvm
<Kolev>lilyp: Oh, it does not work in scripts?
<Kolev>Still, I like the aliases!
<lilyp>Aliases are not subcommands
<lilyp>Subcommands are not aliases
<lilyp>They are different things.
<florhizome[m]>I think there is a lot more room for dealing with profiles better but it makes sense to maybe cut some cruft then.
<Kolev>lilyp: Let‘s not argue about semantics. The point is that “guix install“ → “guix package -i“.
<florhizome[m]>It’s already so expansive
<lilyp>I don't get the point tbh.
<lilyp>Aliases bad because ...?
<lfam>Whatever the difficulties are with our command-line interface, it's widely been praised as superior to Nix's, and a common reason for users to choose Guix over Nix
<lfam>So, it's already pretty good
<lfam>Also, there are real costs to changing it in terms of user experience. It's not always helpful to make "helpful changes"
<lfam>But, sometimes the disruption is worth it
<florhizome[m]>ifam: ok let’s just stop lol
<lfam>It's not easy to make decisions about that, because you can't know in advance if a change is worth the disruption or not
<lfam>We actually added `guix install`, `guix remove`, and `guix upgrade` due to popular demand :)
<florhizome[m]>I think there is a lot of stuff packed into „package“ and I’d guess install and upgrade were aliased to make them more accessible
<lfam>Yeah, exactly
<lfam>And, they are easy to guess
<lfam>Many people would try to use them anyways, so we just added them
<lfam>I've also noticed that 'profiles' as a concept seem hard to grasp
<lfam>It's unfortunate because they are key to advanced use of Guix
<lfam>But, there's no analogue in other operating systems besides Nix
<lilyp>It also doesn't help, that besides the environment/shell pair, there's no really good way of managing profiles other than the main ones.
<florhizome[m]>but if we could get more options for profiles I would rather have a single prefix to deal with profiles
<lfam>Anyways, like I said, sometimes the disruption of change is worth it! Don't let me discourage you from designing improvements. That's why we have begun the transition from `guix environment` to `guix shell`
<lfam>lilyp: `guix package --profile` doesn't work?
<florhizome[m]>yeah if you hide profiles somewhere they are not gonna be understood.
<florhizome[m]>The manual also doesn’t go far with them.
<lilyp>Depends on how you define "work"
<lilyp>If "spam my home folder with meaningless symlinks and have fonts etc. borked" means "work", then sure.
<lfam>There's a lot of room for improvement there
<Kolev>lilyp: You don‘t like loads of symlinks and parentheses?
<florhizome[m]>people do a lot of stuff with profiles that way surpasses what is currently actively promoted by the cli
<lilyp>I like parentheses, but I like my home directory clean
<lilyp>and I especially don't want stuff, that ought to go to /var/guix in there
<florhizome[m]>Ifam: personally, for me we could try other system designs then a „profile“
<lilyp>florhizome[m]: sure, but they have to actively code around its limitations mostly outside of guix
<ss2>florhizome[m]: with emacs-guix profile management is a bliss.
<lfam>New error when pushing to Savannah: <> "remote: ImportError: No module named git_multimail"
<Kolev>I don‘t feel like relearning package management with emacs-guix.
<florhizome[m]>emacs guix currently doesn’t work for me
<florhizome[m]>but I don’t think that’s an argument for not making the cli better
<lfam>Oh, I've reported this error years ago too:
<singpolyma>In prod exclusivly use non-default profiles
<singpolyma>One profile per "app" so I can get rollback on each, etc
<Kolev>florhizome[m]: I hear the CLI is better than Nix.
<florhizome[m]>I would like to do something like „upgrade all (default) profiles)“ or „install .... to profile...“
<lfam>The latter is already supported
<lfam>I don't think there's a command for "upgrade all profiles"
<florhizome[m]>that gets crammed behind package, it’s an UI abomination
<lfam>Have you used other distros? It's hardly an abomination
<florhizome[m]>you can do it from the repl
<singpolyma>Yeah, I never use the package subcommand except for rollback
<lfam>Let's be nice
<lilyp>"guix install -p" is an UI abomination?
<singpolyma>Just using install/remove
<florhizome[m]>lilyp: adding more stuff that deals with profiles there
<lfam>It's a command that *only* deals with profiles. But since nobody knows what a profile is, it is named `guix package`
<lilyp>Btw. who wants to code up "guix package -p p1 -p p2 -i -u -r"
<florhizome[m]>then guix profile would be more accurate maybe?
<lilyp>but also more confusing
<lilyp>Seriously, not every UI needs to satisfy your OCD.
<lilyp>In fact, it is probably better if it does not.
<aeka>I just don't understand this issue
<aeka>xz: (stdin): Cannot allocate memory
<aeka>what causes this to happen in the unpack phase?
<florhizome[m]>well what’s a better split? you can have some crossaliases, but not everything
<lfam>aeka: It sounds like you ran out of memory?
<singpolyma>`puix profiles` and no default profile when using that command might be a nice from-scratch design, but I doubt it's enough of an improvement for the pain
<aeka>lfam: well that's not the issue, both memory and disk are free
<aeka>it's when gcc tries to build
<lfam>Well, then it must be something else
<lfam>But, I still think it's out of memory
<aeka>I wonder if it's ulimits
<lfam>Or a tmpfs that's not big enough
<aeka>tmpfs is 16gb, should be enough?
<lfam>Yeah, for almost every case
<lfam>If you want help, you'll need to provide more details
<lfam>Like, what package are you building?
<lfam>If it's not part of Guix, please share it on <>
<florhizome[m]>a ui should keep certain dimensions at first glance is what I think
<florhizome[m]>guix packs so many different things that it becomes harder to find features, if you just alias stuff for minimal gains
<aeka>lfam: it's just a guix upgrade after a guix pull
<lfam>So, which package does it fail to build?
<aeka>not sure what package is pulling it in..
<lfam>It's building GCC?
<lfam>Is this on x86_64? And do you intend to build every package from source?
<aeka>just fails on the unpack phase with that
<lfam>Please share the entire filename of the derivation that fails
<lfam>It will end in .drv and Guix will have printed it out for you
<aeka>just odd
<lfam>And to be sure, `df -h` reports approximately 16 GB free on your tmp directory?
<aeka>yes, and I watched it while running the command, maxes out at ~800m use before failing
<florhizome[m]>well maybe I shouldn’t care about guix ui, it’s better then nix I heard.
<florhizome[m]>if that’s what matters^^
<lfam>I wonder what package that corresponds to
<lfam>It's not (gnu packages gcc) gcc-10)
<cbaines>aeka, are you running the guix-daemon via systemd?
<florhizome[m]>„we are a bit different from nix“
<lfam>And it's not gcc-final or gcc-boot0
<aeka>cbaines: no, this is on guixSD
<lfam>It definitely matters florhizome[m]
<aeka>florhizome[m]: the UI is up there with our top advantages over nix
<aeka>we don't split thing out into nix, nix-env, nix-deploy.... whatever they have
<aeka>`guix build -e '(@ (gnu packages gcc) gcc-10)'` runs fine which is the funny thing
<aeka>but it doesn't try to build anything?
<florhizome[m]>if you only care about nix, you already lost for the next 5 years in users^^
<lfam>aeka: Right, that's a different package, with a different source tarball
<lfam>aeka: You can do `guix build -e '(@ (gnu packages gcc) gcc-10)' --source --derivation` to check
<lfam>It's --derivations
<aeka>indeed it is different
<lfam>There are other GCC 10 variants in (gnu package commencement)
<lfam>Your derivation is current, since I have it in my store
<roptat>ok, added the guards in a snippet, it works, and now I only have a linker error left...
<ArneBab>Kolev: You mean the Pälzisch? Yes, though it takes a while to read it :-)
<aeka>yes, it's an odd issue
<aeka>I'll do some playing around
<lfam>aeka: Anyways, if you do intend to build everything from source, there are lots of little roadblocks like this
<lfam>It's good to report them so they can be fixed
<florhizome[m]>I can imagine sth like guix–util or so some day but as a separate library, not from guix core (;
<aeka>that's one of the reasons why I do it!
<aeka>other reason is that I'm a recovering gentoo user..
<florhizome[m]>recovering? :D
<lfam>Most of the variants share the source derivation of (gnu packages gcc) gcc-10)). I don't know which package your failing derivation corresponds to
<Kolev>ArneBab: Arrig gut. 😊️
<ss2>I’m just trying to load a modified package into my system profile, that is placed into a, which is properly sourced, but then reconfigure complains at the package being unknown. Are only packages from channels loaded?
<ss2>not that I’m getting too sloppy now and basicaly want to place dodgy package hacks into my profiles.
<Kolev>How much would it cost to pay someone to package Jellyfin for Guix?
<lfam>This thing Kolev? <>
<Kolev>lfam: Yeah.
<lfam>"The entire project consists of a C# core server, a Javascript web client, and a number of other clients written in various languages and frameworks."
<lfam>It might not be trivial, but I'm sure it's doale
<raghavgururajan>How do I expose ublock-origin-chromium variable so that I can add to the packages list?
<raghavgururajan>without map --> specification
<raghavgururajan>error: ublock-origin-chromium: unbound variable
<raghavgururajan>Adding (gnu packages chromium) to use-modules doesn't work.
<ss2>raghavgururajan: it is part of ../gnu/build/chromium-extension: (gnu build chromium-extension), if I got it right.
<raghavgururajan>ss2: I tried (gnu build chromium-extension) too.
<raghavgururajan>I also tried (list foo `(,ublock-origin-chromium) bar) instead of (list foo ublock-origin-chromium bar). No change.
<tex_milan1>Hello Guix! Anyone using nerd-fonts? How did you install it? Can you share your package definition? Thanks!
<singpolyma>raghavgururajan: if you use that module in repl does the var show up?
<raghavgururajan>singpolyma: It appears with `guix edit ublock-origin-chromium`
<gabri-el>in order to boot to a image from 'guix system image config.scm' do i need to particionate the disk and get the respectives uuid?
<sneek>gabri-el, you have 1 message!
<sneek>gabri-el, podiki[m] says: does say elsewhere but then that should be added to the manual, if you could file a bug report or patch that would be great and thanks for noticing
<singpolyma>Right, but if the issue isn't that it's not being exported or imported properly trying in repl could cut down number of possibilities
<raghavgururajan>singpolyma: You're right I think. There is no define-public in (gnu build chromium-extenstion)
<yewscion>Hi All, I'm struggling with an issue related to . I'm having some kind of mental block surrounding setting an environment variable (GUIX_PYTHON_PATH) in a package containing a plugin for another program, and I'm hoping someone can help me understand the most canonical way to do that.
<ss2>Avahi’s service definition doesn’t allow additional additional services to be published?
<raghavgururajan>singpolyma: I've done `(add-to-load-path "/home/rg/guix")` in repl. How do I check what you said?
<singpolyma>I would just (use-modules (the one))
<singpolyma>Then type the name of the var you hope is there
<raghavgururajan>Ah. I did do (use-modules (gnu build chromium-extension)), it ended with /home/rg/guix/guix/packages.scm:346:5: Unknown # object: "#~"
<raghavgururajan>Lemme try the var name
<singpolyma>If just use-modules at the repl gives an error that seems likely to be the issue
<pyrotek45[m]>lmms carla rack doesnt work on guic
<pyrotek45[m]>nor does surge synth appear for the carla rack standalone
<raghavgururajan>singpolyma: I re-ran use-modules. Its compiling the world.
*raghavgururajan can't afford that cpu+memory load at the moment
<jpoiret>raghavgururajan: `ublock-origin/chromium` in (gnu packages browser-extensions)
<raghavgururajan>jpoiret: Thanks so much!
<jpoiret>you shouldn't ever use a (gnu/guix build) module in general
<jpoiret>those are build-side code, to be run in a namespaced environment
<jpoiret>you never know what it might do to your system if it does not run in a jail
<jpoiret>it is weird that that (gnu packages browser-extensions) does use (gnu build chromium-extension)
<raghavgururajan>Extension doesn't appear in settings.
*raghavgururajan *sighs*
<raghavgururajan>Okay, home didn't source the new profile.
<mbakke>jpoiret: I agree, but did not find a better place to put that chromium-extension code... perhaps it could be "inlined" in (gnu packages browser-extensions) ?
<jpoiret>yes, or (gnu packages chromium) maybe
<jpoiret>but now that I think about it, a bunch of other things use (gnu build), for example things in (guix scripts)
<awb99_>I have managed to install sway. but fonts for Chromium and icecat are horrible. very pixely. qt4 apps like quassel.have nice fonts.
<awb99_>i guess the missing fonts ate for GTK apps.
<awb99_>any ideas?
<lfam>To clarify, quassel uses Qt 5
<lfam>You probably need to install some fonts and make them available for Chromium and icecat
<jpoiret>it's possible that IceCat doesn't launch with X11 but rather wayland by default
*mbakke started to remove instances of #$(package-version foo) in favor of #$(package-version (this-package-input "foo")), but just realized that package-arguments are thunked, so perhaps it does not matter?