IRC channel logs


back to list of logs

***Server sets mode: +cnt
<xqmin>roptat: thanks, that did it
<alextee[m]>hi guix!
***Server sets mode: +cnt
<seepel>Does anyone have experience with yubikeys on Guix System? In particular I'm trying to use aws-google-auth ( And it complains about no U2F device found.
<seepel>ungoogled-chromium doesn't seem to recognize the yubikey either
<roptat>maybe you need some udev rules?
<roptat>I have never used a yubikey before so I might be wrong :)
<seepel>I have absolutely no idea either :D
<seepel>nckx: Thanks! I was just on an Arch Linux wiki page that seemed to imply the same thing, my next question was literally going to be "How can I use these udev rules" :D
<sirgazil>nckx: I sent a patch with new screenshots:
<nckx>Thank you!
<nckx>I mean, opening that page DoSs my IceCat, but I assume they're pretty.
<genghis-sean>do any of you all have experience with guile/guix segfaults?
<genghis-sean>It looks like there's discussion of a seg fault caused by guix pull
<genghis-sean>I guess I'll try rolling back
<genghis-sean>rollback worked so I think mainline is borked ¯\_(ツ)_/¯
<roptat>gah, why is gdm suddenly taking 2.4 GB of ram?
<roptat>even worse than icecat, what is happening?
<lfam>We should put the yubikey instructions in the cookbook
<guix-vits>Hi Guix.
*vagrantc finds yubikey's switch to closed-source a bit concerning
*vagrantc has been using the gnuk for quite some time
*apteryx installs the gnome-desktop-service for the first time -- that's a lot of MiBs to fetch!
<apteryx>vagrantc: eh? why would they do that?
<guix-vits>yubikey -- come out of closed :)
<apteryx>roptat: memory leak?
<vagrantc>apteryx: "because security"
<seepel>I've noticed this across a number of packages, but to take my most recent example, does anyone know why docker-cli wouldn't show up when I guix search docker?
<seepel>Basically it seems like <name>-<something-else> doesn't show up if I only search for <name>
<brendyyn>seepel: please post a bug report
<guix-vits>seepel: `guix search docker | less` ?
<guix-vits>docker-cli, 19.03.7
<seepel>guix-vits: guix search docker only returns 3 results "docker" and two python libraries
<seepel>brendyyn: Do I need to subscribe to bug-guix before filing?
<brendyyn>seepel: no you just send an email
*guix-vits guix pull...
<brendyyn>but i notice it comes up with |lesss too
<seepel>Ohhh weird. It does show up with less
<brendyyn>seepel: You should notice at the bottom of the output hint: Run `guix search ... | less' to view all the results.
<brendyyn>some guix devs decided it was better to have guix truncate results by default
<seepel>I thought it was helping me see results that were at the beginning of the list, not the end
<brendyyn>usually it's convenient because it keeps the top results on the screen, but other times it cuts off what you actually want to find
<seepel>I now feel foolish, but thank you for pointing this out.
<sirgazil>roptat: Maybe this same thing?
<guix-vits>sirgazil: i'd same with Gnome on Fedora, but only with swap on (HDD).
<brendyyn>gnome-maps is playing up again. its this error
<brendyyn>atleast, the first error with defaultsources
<guix-vits>emacs-w3m has great bookmarks page. Pressing E is visiting bookmarks.html file, and it's easy to edit.
<guix-vits>Hi PotentialUser-16.
<sulr70>Hi! How can I switch GuixSD to boot to command line instead of desktop? I know GuixSD does not have the concept of run level on most other GNU/Linux distributions.
<brendyyn>sulr70: yes
<brendyyn>sulr70: you will want to disable the login manager service
<brendyyn>In your operating system specifications there is (services ...) which is likely set to %desktop-services
<sulr70>Thanks, I will try
<guix-vits>sulr70: yesterday there was an example of that on IRC.
<brendyyn>this is what mine looks like although its messy. probably there is a nicer way
<brendyyn>You can see that I remove gdm-service-type
<brendyyn>I mean, the service of that kind
<guix-vits>sulr70: may help you too. (services (cons* (modify-services ...
<sulr70>Many thanks
<sulr70>brendyyn: The file you pasted is global /etc/config.scm or other files?
<guix-vits>global config is a .scm file (one can even use `(define` and the such), so it may even be a module that will be loaded during config.scm evaluation. i'm guess it's a module snippet.
<sulr70>It seems I should learn from zero. It is quite different from other GNU/Linux distributions.
<guix-vits>freshest version of docs
<guix-vits>also check out `guix install sicp`, `info sicp`.
<guix-vits>ask questions there, they frequently get answered: but not be too abstract, tell folks _what_ are you doing too.
<brendyyn>sulr70: it is the part of my config.scm that goes inside (services ...)
<vagrantc>finally figured out why packages weren't recognizing my patches ... my clock was set to 1969 or 1970 or so because RTC isn't working... and so the .go files were newer than the .scm files!
<vagrantc>i need to set up ntp on this system...
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, rlb says: looks like we'll still need --enable-jit=no on some platforms (I cherry-picked your fix in -7 and re-enabled the jit everywhere, including armel):
<vagrantc>civodul: i just learned not to ./pre-inst-env with a clock set to ~1970 :)
<janneke>stardate zero
<sulr70>brendyyn: I added "remove (lambda (service)" section to the "services" in /etc/config.scm and reboot, but it does not work.
<vagrantc>"why doesn't it know about my package, it just worked earlier!"
<civodul>vagrantc: because that triggers auto-compilation of everything?
<janneke>did guile even exist in 1970? ;)
<vagrantc>civodul: because if you edit the .scm file and thus update the timestamp, it uses the old .go files which don't have what you're expecting them to have!
<vagrantc>because the old files are newer!
<vagrantc>timestamps get me every time
<vagrantc>nasty stuff
<guix-vits>sulr70: post your config to
<vagrantc>thought i had a working u-boot-pinebook-rk3399 based off of mainline u-boot... it gets as far as loading a kernel+initrd+dtb but then the kernel never appears to boot ...
<brendyyn>sulr70: you would have got the syntax wrong. can you upload your config to
<janneke>vagrantc: ah, you switched to mainline u-boot; i was using a fork, right? can you determine whether it's u-boot or the kernel?
<brendyyn>i think i realised your use of append is better than my messy use of cons*
<efraim>janneke: if you do actually continue from postfix to mailman I have some package upgrades and the start of some config
<janneke>efraim: you already looked at that, awesome!
<sulr70>brendyyn: The append is come from default setting, I removed the last few service from append and added your setting.
<janneke>i don't have a pressing need for postfix/mailman just yet but i've been anticipating it for quite a while
<vagrantc>janneke: switching back to your u-boot fork fixed it, so it's definitely my not-quite-right mainline u-boot patches
<janneke>vagrantc: +1 for bisecting...
<vagrantc>was hoping for some small patches that i could push to master ...
<vagrantc>haven't seen anything other than the manjaro kernel display to LCD ... but mainline 5.5.x kernel + device-tree patch works with a lot of missing features
<janneke>in my effort to "get something working" i tried to stick close to the debian install that worked...
<janneke> this is all work that i avoided/postponed
<civodul>"the old files are newer"
<vagrantc>hmmm... haven't tested weather linux-libre 5.5.x works with the modular config ... just using the defconfig
<vagrantc>civodul: :)
<civodul>someone new to this channel must be wondering if we've been confined for too long :-)
<civodul>but yeah, i see what you mean, vagrantc!
<vagrantc>i think it's burned me several times now
<vagrantc>i guess most folks aren't used to the clock doing crazy things
<civodul>are you playing with dettrace?
<civodul>they have a funny way to handle the clock
<civodul>one tick each time a syscall is made
<vagrantc>civodul: no, just trying to get the pinebook pro working on a lightly patched linux-libre
<vagrantc>apparently lacks RTC support :)
<vagrantc>arm boards often have an annoying relationship to clocks
<vagrantc>speaking of relationships to clocks ... night all!
*vagrantc waves
<janneke>guix 24/7 support: check
<civodul>rekado_: i looked at the "nfs-server" test yesterday, fixed a couple of minor issues, but it still fails
<civodul>could you take a look?
<davidl>Whats up with ? Im getting a 504 gateway timeout, and for https version Im getting resource not found errors for specific log urls.
<guix-vits>davidl: today it's worked, all i know.
<civodul>davidl: it should be back up now
<kondor[m]>When I want to add a package to Guix distro, do I work from the master branch, or core-updates (which seems to be the default these days) ?
<brendyyn>kondor[m]: i always work on master
<kondor[m]>Yeah, that's what I used to do
<brendyyn>i mean you could test both if there is some reason to believe your program might break when core-updates merges
<civodul>kondor[m]: see item 8 at
<civodul>in short, default to master, and choose another branch for changes that affect lots of packages
<brendarn>... so that's what happens when you restart the udev service
<kondor[m]>thanks ludo
<brendarn>bricewge: I have the udev rules un /run/curre..../rule.d/, but it doesn't set the permissions
<brendarn>. /sys/class/..../brightness is still -rw-r--r-- and root:root
<davidl>civodul: great, thx!
<bricewge>brendarn: Rebooting should set the correct rights.
<bricewge>There is probably a less drastic way to do it though...
<brendarn>its alright ill test it
<brendyyn>bricewge: You're a genius.
<kondor[m]>Is it a biggie if I submit a package for which lint reports "source not archinved on Software Heritage"?
<efraim>that's ok
<brendyyn>kondor[m]: no that's unrelated, but you can go submit a request
<brendyyn>well i wouldn't say it's unrelated. i'd say we'd like to have it archived
<rekado_>civodul: oh, the nfs-server tests fail?
<civodul>rekado_: just the one called "nfs-server"
<civodul>i fixed several system tests lately, but i'm not sure what to do about this one
<rekado_>I’ll take a look
<efraim>i can let everyone know the maven package is working, i'm building jitsi pieces
<janneke>hmm, me encounters some files of stardate +1s; causing warning-trouble -- wtf?
<janneke>1970-01-01 01:00:00.000000000 vs 1970-01-01 01:00:01.000000000
<janneke>must be my scripting somewhere
<brendyyn>janneke: It's Time Gremlins. They're nastier than the regular Gremlins. I suggest submerging you're computer in isopropyl alcohol to cleanse it.
<kondor[m]>brendyyn: are they related to Maxwell's deamons?
<efraim>At first I thought you meant this:
<janneke>brendyyn: ty ;)
<mbakke>civodul: any particular reason shepherd is still on guile 2.2?
<mbakke>I'm not able to build system configurations on core-updates, shepherd-console-font-tty1.go.drv & co fails with "no code for module (shepherd service)"
<mbakke>errh wait shepherd is using guile 3.0, hmm
<brendyyn>kondor[m]: Maxwell's daemons try to defeat Time by reversing entropy. They are Time Gremlin's arch nemesis.
<kondor[m]>brendyyn: but, they tend to isolate themselves in cylinders where the only door is in the barrier between the halves of the cylinder. So, Time Gremlins do not need to worry much about them.
<brendyyn>kondor[m]: That's what you think, but Time Gremlin's are from the future. They don't always remain on friendly terms, hence the inter-space-time daemon wars.
<davidl>I was trying out the new SSH authenticated repositories feature in one of my channels, but it's not working, its just stuck loading. Im running a guix pull from guix commit a063bac618c36658dbb1dbf4a602172cae22975f, on a foreign distro.
<guix-vits>brendyyn, kondor[m]: aren't you're those people who inventing the Ubuntu release names, by chance?
<htgoebel>Hi guix!
<kondor[m]>guix-vits: god forbid!
<guix-vits>hi htgoebel.
<htgoebel>How can I replace the package source with a local directory - for testing the package?
<kondor[m]>htgoebel: guix is busy building chromium
*janneke found the time gremlins
<kondor[m]>htgoebel: I usually do guix build -L path/to/package/def if i want to test if the package builds successfully
<mbakke>htgoebel: just (source "/the/directory") should do the trick
<kondor[m]>which may, or may not have something to do with your question
<htgoebel>kondor[m]: Yeah, but how tell the package definition to use a local directory?
<guix-vits>mbakke: without '(uri'?
<kondor[m]>i guess what mbakke said
<mbakke>guix-vits: yes, it's a little-known feature :-)
*guix-vits -- MUHAHAHA!
<mbakke>htgoebel: does (source "/your/custom/fork") not work for you?
<htgoebel>mbakke: This did the trick.
<mbakke>htgoebel: cool :-)
<htgoebel>mbakke: Is this documented in the manual? I search at "package definiton" and "origin", and there is no hint.
<mbakke>htgoebel: don't think so, should it? it's really only for dirty hacks
<htgoebel>mbakke: Not only for hacks, also for testing IMHO - and this is what I use it for.
<mbakke>htgoebel: it can probably be squeezed into the manual if you find a good spot for it :)
<htgoebel>mbakke: I was afraid if this answer ;-)
<mbakke>htgoebel: maybe a cookbook entry? :)
<brendyyn>Do we want to eventually include firefox extensions as packages.
<guix-vits>brendyyn: without a firefox?
<brendyyn>guix-vits: we have firefox, it's called icecat
<guix-vits>is they're compatible at all (i'd seen both)?
<brendyyn>yes. Icecat is the LTS version of firefox with compatibly modifications
<brendyyn>I use extensions from mozilla. There are many libre addons, but we don't recommend the addon store because it has proprietary ones too
<mbakke>so I guess 'effective-version' actually uses the guile that my guix checkout is configured with, which is why the shepherd derivations are trying to use guile 2.2
<guix-vits>brendyyn: `guix environment --pure --ad-hoc icecat -- icecat` -- no fonts. Bug?
<efraim>htgoebel: here's the guix.scm I use for guix.vim
<brendyyn>guix-vits: dont use --pure
<guix-vits>brendyyn: (?) but audacity and vlc has fonts with --pure too.
<brendyyn>guix-vits: maybe because icecat uses pango and vlc uses fontconfig? not sure about audacity
<guix-vits>brendyyn: ok, idk what pango is, but terminal shows that IceCat can't find some fonts, so i wonder if those fonts need to be in `(inputs`? i'm sorry that my questions not about extensions.
<brendyyn>guix-vits: there is a tool called strace that cant provide more info
<brendyyn>guix environment --ad-hoc --pure icecat strace -- strace icecat
<NieDzejkob>ouch, icecat under strace. RIP your sanity
<brendyyn>maybe best look at how pango works
*guix-vits `guix environment --ad-hoc --pure icecat strace -- strace icecat` C-c
<brendyyn>its the blind leading the blind here lol
<guix-vits> -- is this'll be relevant for future versions of IceCat?
<brendyyn>god damnit mozilla what the hell
<brendyyn>guix-vits: i just ran icecat in a --pure and i get fonts.....
<brendyyn>wait a sec
<brendyyn>nevermind. no fonts
<guix-vits>nevermind: Hi.
<brendyyn>guix-vits:it's because of XDG_DATA_DIRS
<guix-vits>so, no need to add 'DejaVu Sans' to (inputs ?
<brendyyn>guix-vits: I mean, why are you running icecat in a pure environment anyway?
<NieDzejkob>testing in a --pure environment is a good proxy for things working out of the box
<NieDzejkob>currently, fonts do not work out of the box in icecat
<mbakke>guile-gdbm does not seem to work with Guile 3
<guix-vits>brendyyn: recently nckx shown me (but about xdg-open) that:
<guix-vits>so i'm think, as NieDzejkob've told above.
<brendyyn>hmmm. im not sure what the correct answer is.
<brendyyn>i tried adding font-dejavu and that didn't set XDG_DATA_DIRS anyway
<rekado_>civodul: the test doesn’t fail for me; it just seems to wait for something that never happens. Is this what you see as well?
<brendyyn>guix-vits: it seems reasonable to assume a person installs fonts though, doesn't it?
<guix-vits>brendyyn: idk. i'm never installed any fonts in Ubuntu, for example; same for Archlinux, at least for KDE.
<brendyyn>ok, im still figuring out how to make it work in a --pure
<guix-vits>brendyyn: adding ''xdg-utils font-adobe-source-han-sans font-dejavu font-gnu-freefont-ttf font-liberation fontconfig gs-fonts'' didn't helped.
<efraim>how do I refer to a separate output in a gexp?
<civodul>rekado_: yes, exactly
<civodul>efraim: #$foo:bar
<efraim>civodul: thanks
<rekado_>with linux-libre-4.19 I get an actual error “Protocol not supported” (which is also weird)
<rekado_>I’ll try other kernel versions
<rekado_>this looks weird: “rpc.nfsd: knfsd is currently down”
<rekado_>I don’t remember seeing this in my early tests
<efraim>hmm, looks like special-service-file-type isn't a gexp
***link2xt[nm] is now known as link2xt
<NieDzejkob>guix-vits: this is probably because of the fontconfig cache, which is currently stateful
<NieDzejkob>see bug#26877
<civodul>efraim: didn't you submit a patch to make the global fontconfig cache a tmpfs?
<civodul>or was it nckx?
<efraim>sounds like me
<efraim>no, sounds like an idea I had and something I did locally but never submitted
<civodul>ah, maybe we should do that
<efraim>well, I can say it's been working on my machines for months
<efraim>I have another one that's not readonly for /var/guix/temproots
<efraim>I wanted it to get cleared at each reboot
<efraim>or crash
<civodul>stale entries in /var/guix/temproots are deleted upon gc, no?
<civodul>anyway, i suggest adding the /var/cache/fontconfig thing in %desktop-services
<efraim>no idea, but I think I remember if your computer crashes during a build you can run out of builders if it thinks they're all in use
<efraim>ok, I'll add it in a bit, I have to run
*efraim goes afk
<rekado_>wait, this doesn’t look right: “rpc.nfsd: Writing version string to kernel: -2 +3”
<rekado_>perhaps newer kernels are stricter about how NFS versions are requested
<rekado_>this looks like we’re only setting up version 3 and so connecting to version 4 times out.
<guix-vits>NieDzejkob: thanks.
<guix-vits>"fictional, not yet existing, font-build-system..." <3
<rekado_>…there *is* a font-build-system, though
<guix-vits>cool. i'm just about the wording.
<rekado_>I don’t see where this quote is from
<apteryx> hey rekado_, is your relay/bouncer getting disconnected daily by your ISP, causing your nick to become trailed with '_' ?
<apteryx>because if so, I have some bit of config that helps prevent this :-)
<rekado_>ah 2017
<rekado_>apteryx: I don’t know, but I also don’t really care enough to wonder :)
***rekado_ is now known as rekado
<rekado>“/ns regain” after “/ns identify” works
<rekado>apteryx: is this znc config or erc config?
<apteryx>rekado: yes, with weechat I use something like '/set irc.server.freenode.command = "/msg NickServ REGAIN"'
<apteryx>no issues with my nick changing ever since
<jonsger>why is lets encrypt such a fiddling with guix :(
<rekado>is it?
<jonsger>yes it is
<rekado>hmm, we haven’t had major problems with and the many LE certs we use there.
<civodul>jonsger: what do you mean?
<civodul>certbot is cool
<civodul>i mean the cerbot service
<civodul>i've had problems when i forgot to set the nginx deploy hook, though
<civodul>but apart from that, i like it
<jonsger>I'll report a bug. It's a little complicated to explain
<guix-vits>jonsger: (define (bug boom oi ah) ...)))))))
<jonsger>it's maybe not a bug, maybe just me using it wrong
<mbakke>civodul: any idea why 'guix environment guix' on core-updates creates a module-import-compiled.drv that uses Guile 2.2, and subsequently (guix man-db) fails to load (gdbm)?
<rekado>civodul: the nfs-server failure is puzzling. I don’t know what’s wrong.
<rekado>this was sooo difficult to set up in the first place. Not happy that it broke.
<civodul>mbakke: is the manual-database.drv that uses 2.2?
<civodul>that's from (guix profiles)
<mbakke>civodul: manual-database.drv contains both Guile 3 and 2.2
<mbakke>The 'guix' package still had guile 2.2 in native-inputs like some other packages, but I've fixed that locally.
<civodul>mbakke: ok, i just found that i had forgotten gnutls, too
<mbakke>civodul: I think that's fixed, see the recent commits on core-updates.
<civodul>oh wonderful, thanks
<mbakke>still can't figure out why manual-database.drv pulls in Guile 2.2 though
<civodul>yeah, lemme see
<bricewge>sneek: later tell lfam: Sending patch series with `git send-email --no-chain-reply-to` doesn't work unfortunatly, I tried it for #40103 40104. Debbugs is probably processing emails in batches or it received them unordered. Too bad :(
<sneek>Will do.
<civodul>mbakke: i'll push a couple of fixes shortly
<mbakke>civodul: yay :-)
<civodul>on core-updates there are test failures related to gnu-make-test-boot-4.3.drv
<civodul>does that ring a bell? janneke or mbakke maybe?
<civodul>"config.status: error: Something went wrong bootstrapping makefile fragments"
<mbakke>civodul: which test is that?
<civodul>several of them, notably testse/packages.scm
<janneke>haven't seen that yet
<civodul>it's gnu-make-for-tests
<mbakke>uff, probably from the Make 4.3 update
<civodul>could me, lemme see
<mbakke>civodul: the update in commit cdba91486a60bbba727d843707322f98f8286124 had to add "--disable-dependency-tracking" for gnu-make-boot0
<civodul>yes, same here!
<civodul>just found it :-)
<janneke>you both are fast
*janneke : [ 66%] GUILEC gnu/packages/emacs-xyz.go
<janneke>haven't built plain core-updates in a while
<htgoebel>efraim: guix.vim seems to be a cool trick!
<guix-vits>htgoebel: trick is in `(version` ?
<andydarcyjewell>Hi all, I'm having a problem with a conflict between two versions of a package (linux-libre-headers), any advice on sorting it out please?
<sneek>Welcome back andydarcyjewell, you have 1 message!
<sneek>andydarcyjewell, NieDzejkob says: I was under the impression that en_GB defaults to 12-hour time when applications support it
<janneke>mbakke: i have updated my .patch files on wip-hurd; now failed with what i hope to be a guile3 error
<leoprikler>andydarcyjewell: what does your config.scm look like?
<andydarcyjewell>leoprikler: where would I find config.scm?
<leoprikler>Okay, let's start one step earlier, this happens on `guix system reconfigure ...`, right?
<andydarcyjewell>"find ~/ -name config.scm" returns nothing
<leoprikler>Or does it happen on `guix package ...`?
<andydarcyjewell>leoprikler: I can pastebin the output, if that would help?
<leoprikler>andydarcyjewell: that would be nice, but include the command itself
<andydarcyjewell>leoprikler: the output begins with the error from the build script, stating that it can't find linux/errno.h; then is my search for the relevant guix package for the linux headers; then the guix command I tried to use to install it, followed by the error
<leoprikler>you shouldn't install headers in user profiles
<leoprikler>what are you actually trying to achieve here?
<andydarcyjewell>leoprikler: I'm trying to build the Factor language from source, with a view to learning how to package it for guix
<andydarcyjewell>leoprikler: successfully done this on my stock debian m/c without guix
<guix-vits>andydarcyjewell: (offtopic? "did you log-off and log-in after installing clang (i'd same errno.h error, but with gcc-toolchain)?")
<leoprikler>In that case, either start out from a simple package definition, where you only fill in some blanks and of inputs, then do `guix environment -l factor.scm`
<leoprikler>Alternatively, do `guix environment --ad-hoc gcc-toolchain linux-headers-libre-headers ...`
<leoprikler>Then try compiling again, and if you're missing an input adjust your environment.
<apteryx>rekado: about nfs-server-service: thank you for writing it! I started using it just recently, it's nice to have this in Guix!
<leoprikler>I personally tend to just write package definitions and use `guix build` as an oracle
<apteryx>now we just lack a way to mount nfs shares automatically
<mbakke>linux-libre-headers is propagated from glibc and will get pulled in by gcc-toolchain
<andydarcyjewell>I've read the guide on that, but I'm still having trouble understanding it. Too used to "traditional" package managers, I guess.
<leoprikler>mbakke: nice catch, just gcc-toolchain will be fine then
<rekado>apteryx: does it still work for you even with the latest linux-libre-5.4?
<andydarcyjewell>leoprikler: mbakke: > linux-libre-headers is propagated from glibcI - yes, I saw that in the error, but wasn't sure why Factor isn't picking it up
<rekado>I made some local changes to set the supported NFS versions to 4.2, 4.1, 4.0, in addition to the default (+3, -2), but I still can’t get the tests to pass.
<leoprikler>What build system does Factor use? GNU? CMake?
<andydarcyjewell>guix-vits: no, i haven't logged off and on again... sounds very windowsey! will try
<mbakke>andydarcyjewell: it probably has to do with search paths, if you installed the dependencies into your user profile (not recommended!), then you might need to log out and in again for the relevant variables to be configured
<leoprikler>oof they have their own
<mbakke>andydarcyjewell: alternatively, just use 'guix environment --ad-hoc clang-toolchain' to drop into a shell with everything nicely set up
<andydarcyjewell>mbakke: understood. I was looking at profiles/manifests, but couldn't work out how to make a new "blank" one, or what I'd put into a fresh one, other than just filling out the fields.
<andydarcyjewell>leoprikler: it's a shell script that does a few maintenance tasks, like git pulls and so on, and uses make I think... I haven't looked at it in detail.
<rekado>andydarcyjewell: at build time there is no internet access, so all the git stuff has to be done with native-inputs.
<andydarcyjewell>guix-vits: you were right, it's now compiling after a logout/in; must have been lack of search paths.
<andydarcyjewell>rekado: at this stage, I am just trying to get all the dependencies in place so the normal build script works, building up my understanding of guix, and working out how to do it properly as I go
<guix-vits>andydarcyjewell: also, `guix environment --ad-hoc ... -- bash` -- not a best way, but a way to temporarily taste some environment with bash and other listed programs.
<rekado>andydarcyjewell: oh, I misunderstood. I thought you were writing a package definition.
<rekado>guix-vits: you don’t need “-- bash”
<andydarcyjewell>rekado: that's what I'm aiming at, but I don't understand enough to do that yet
<guix-vits>rekado: what do i need, please?
<leoprikler>guix environment $STUFF is fine alone
<leoprikler>it will spawn a shell
<leoprikler>you use -- $COMMAND if that's what you don't wand
<guix-vits>thanks. really i'm do mistake, even remember something like that was in manual.
<leoprikler>-- $SHELL is only helpful if you have to refer to variables inside the environment
<leoprikler>e.g -- sh -c 'tree $GUIX_ENVIRONMENT/bin'
<bavier`>hi guix!
<guix-vits>Hi bavier.
<andydarcyjewell>leoprikler: the compile completed, but the new binary can't find :-(
*guix-vits strange; in kitty terminal emulator, when erasing with Backspace key, cursor is moving forward: in root shell and in `guix environment` shell.
<guix-vits>andydarcyjewell: i hope it'll be solved not with a `patchelf` again :)
<leoprikler>try inside an environment with gtk+@2
<andydarcyjewell>on debian, I'd do "apt install libgtk-x11" for that
<guix-vits>andydarcyjewell: i'm think if you aren't use `--pure`, installing an equivalent in user's profile will work the same way.
<andydarcyjewell>leoprikler: trying that now...
<leoprikler>--pure is nice, but not that nice when you're dealing with GUIs
<andydarcyjewell>Cannot resolve C library function
<andydarcyjewell>that's even with "guix environment gtk+@2"
<civodul>rekado: guile-irc, yay! \o/
<andydarcyjewell>It went and installed a load of packages on the way, however
<leoprikler>try compiling again and add LDFLAGS="-L $GUIX_ENVIRONMENT/lib" to make
<rekado>civodul: I just forked and fixed it.
<rekado>I found this list:
<rekado>many of these seem to have been abandoned
<andydarcyjewell>Ah, on closer inspection, I Factor has *two* makefiles: Nmakefile and GNUmakefile
<civodul>rekado: cool
<civodul>well, not that they've been abandoned
<civodul>maybe they're "finished" rather than "abandoned"? :-)
<rekado>might be fun to package a few more of them
<civodul>until further evidence is available, let's assume they're "finished"
<civodul>good for mood
<leoprikler>andydarcyjewell: GNUMakefile is the correct one on GNU systems
<bavier`>has anyone here had success with our gnome-shell-extension-gsconnect package?
<bavier`>It doesn't seem to work for me, but I haven't done much debugging yet
<andydarcyjewell>leoprikler: rekado: it looks like the factor build script uses gmake on freebsd, and plain "make" on linux, and then selects the relevant *makefile for the version it is using.
<guix-vits>bavier`: do you've "KDE Connect" installed?
<leoprikler>just invoking make on linux with gnu make will read GNUMakefile
<bavier`>guix-vits: I have the app installed on my android system
***jonsger1 is now known as jonsger
<guix-vits>bavier`: but not on guixed machine? "... and will not work with it installed." --
<bavier`>guix-vits: no, I've also installed our gsconnect packages. It renders the new "mobile devices" menu item, but the "settings" dialog does not open, so I cannot pair devices.
<guix-vits>bavier`: is that possible to click that "settings" from `nautilus`? Possible opening it in terminal will show some errors?
<anadon>And today starts Work From Home. I am going to go stir crazy.
<nckx>anadon: Welcome! I already have.
<lispmacs[work]>seems like there is a lot of stuff happening in the Guix repo for the Hurd. Is there like a config file or something I could feed into Guix that will spit out a Gnu/Hurd virtual machine image?
<anadon>On the plus side, I get to use MY machine for linux side project stuff for a bit. So no more `can't be arsed up update` CentOS7 for me :D I'm on Ubuntu 19.10.
<janneke>lispmacs[work]: not yet; see
<janneke>lispmacs[work]: the `wip-hurd' branch allows package builds on the Hurd, as well as cross package builds; next up is a minimal set of packages built needed for a guix system, then creating the system image itself
***Guest6742 is now known as mfg
<anadon>When I pull and update, I can do this multiple times, and each time get the same list of packages claiming to be in need up update, appear to want to update to the same version, and then it claims that everything is up to date. This can't be right.
<NieDzejkob>if a package propagates an input to your profile, an update will be attempted every time
<anadon>I could have never guessed that from the printed output.
<anadon>Is it nessicary to update those packages every time? Seems unnessicary.
<lispmacs[work]>janneke: thank you for the info
<nckx>anadon: It's not, it's just a bug, albeit a harmless one. We have many such harmless bugs (locales, yay).
<nckx>Better than harmful ones, of course, but they tend not to get fixed quickly.
<janneke>lispmacs[work]: yw
<sneek>Welcome back lfam, you have 1 message!
<sneek>lfam, bricewge says: Sending patch series with `git send-email --no-chain-reply-to` doesn't work unfortunatly, I tried it for #40103 40104. Debbugs is probably processing emails in batches or it received them unordered. Too bad :(
<lfam>Too bad bricewge
<lfam>Seems like locales warnings are a daily issue
<lfam>Another person on help-guix
<nckx>Chaos reigns.
<lfam>I think the installer script should handle it
<janneke>something like that, together with failing to get my .profile/.bashrc/.bash_profile just right, drove me in sheer madness from debian+guix to guix system, ~four years ago :) / :/
<nckx>lfam: What, exactly, is the fix?
<lfam>I'm not sure. Maybe glibc-locales should come "pre-installed"
<NieDzejkob>perhaps make it a propagated-input of guix?
<nckx>lfam: Sounds good.
<nckx>NieDzejkob: That would affect everyone, foreign or not.
<nckx>I'd prefer Guix not drop random locales in my environment unless there's no other way.
<lfam>Unfortunately I don't really understand how locales work in a broad sense
<nckx>Join world's largest club.
<lfam>The most recent question was from someone who "installed glibc-locales" but there was nothing in '~/.guix-profile/lib/locale'
<lfam>They manually made a link from that directory to the locales and then it worked
<lfam>So... something is not being communicated, and it's too early in their journey with Guix for them to know what to do
<lfam>I asked them to clarify what they did but it feels like this comes up every day I am working on Guix
<janneke>yes, probably
<nckx>What about just ‘guix install glibc-locales’ at the end of the installation? I know that feels (and is) awfully stateful, but it matches the statefulness of plopping a .service file into /etc that assumes locales exist… in the root profile. Hence why I prefer that to hacking the guix package to propagate stuff for everyone everywhere. Does that make sense?
<nckx>Sorry for that stream of, er, let's call it consciousness.
<janneke>it's often not clear what program prints the error; most often it's the guix-daemon -- how to verify that it gets the correct GUIX_LOCPATH? that's not always easy
<janneke>that makes sense to me
<janneke>a comment in the systemd snippet about that could also help?
<nckx>janneke: What does /var/guix/profiles/per-user/root/guix-profile/lib/locale contain on a foreign distro? It doesn't exist on mine because I run nckx's Guix. If that directory exists and contains ‘stuff’ I'd say it's correct.
<lfam>I use root's Guix so that directory does contain locales for me
<janneke>nckx: i don't have a foreign distro available any more
<lfam>I agree with nckx, the installer should install glibc-locales, or they should come in the binary install tarball
<lfam>I know you didn't suggest the second part
<nckx>No but it's interesting.
<nckx>Would that work? Can we preload /var like that? Hm.
*nckx not looking at the script rn; nckx actually ‘working from home’; nckx sighs.
<janneke>that's also interesting; would that be more alike guix system?
<janneke>this problem will wait for nckx, it's not urgent :)
<lfam>nckx: I mean, we build the /gnu and /var/guix and then tar them up, so we can change that build process
<lfam>Good luck with your work
<nckx>Thanks. Y'all too.
<kondor[m]>Lets say I have two channels of which one is 'guix and both contain a module with the same path. Also, lets say, my not-'guix package comes in the channels list after 'guix. My question is, for the package definitions of the same name, which of those two repositories gets priority?
<kondor[m]>Imagine I'm doing guix package -u
<kondor[m]>for example
<bavier`>I believe the guix definition takes precedence
<anadon>Wouldn't be based on channel order?
<kondor[m]>anadon: my feeling is you could be right
<Blackbeard>Hello :)
<kondor[m]>actually, i tested and new packages that i added to gnu/packages/statistics.scm of the non-guix channel only got pulled in, when i put that modified channel at the end of the channels list
<nckx>I hope it is based on order, that would give users control while remaining predictable. But it should be documented.
<anadon>Is there a test to ensure channel order affects package selection appropriately? Or maybe it should prompt the user to choose in the case of a conflict.
<kondor[m]>i was hoping that somehow guix would use the fresher defs in 'guix channel when, say, updating installed packages and look for my custom packages in the non-guix channel.
<janneke>yes, it should be documented
<kondor[m]>anadon: you clone guix repo, add a few package defs in the cloned repo and add it to the channels list
<kondor[m]>see when the new channel definitions get recognised during guix pull
<kondor[m]>(there is probably a simpler test)
<janneke>i observed some time ago that it is definately depends on order between non-guix channels and when i found that i decided to avoid such shadowing
<nckx>kondor[m]: <i was hoping…> How is that not the case? The way I read that it describes the current behaviour but that's obviously not what you mean.
<kondor[m]>janneke: but don't you depend then on changing module paths? what if you want to have packages from your experimental guix repo available alongside the official packages ?
<nckx>I don't know if there's a sane way to DWIM in all cases, or that it would be a good idea to be too clever about it.
<rekado>kondor[m]: I maintain two channels and I just use my own module names. Reusing module names provides by Guix is a recipe for confusion.
<kondor[m]>nckx: if a channel later in the list has a module path that shadows some path from a channel earlier in the list, then the channel that comes later is the one from which package definitions are taken
<rekado>for variant packages I explicitly declare the variants
<kondor[m]>at least this is how it looks to me
<bavier`>there's module names, but also package names
<rekado>I also use input rewriting where needed.
<kondor[m]>rekado: then, when i need to submit packages to guix i need to rewrite the module paths :)
<nckx>kondor[m]: And you want [I presume] the guix command-line tool to look behind the shadow for a package with a higher version N°?
<kondor[m]>nckx: well, channels is an alist, so each different channel is logically distinguishable
<kondor[m]>but, i guess the limitation comes from how guile resolves modules
<nckx>Having the CLI see a different world than Guile code is just weird.
<nckx>Too weird for me personally.
<kondor[m]>well it's just a minor nuissance
<kondor[m]>i'll figure my way around it, perhaps heeding rekado 's advice
<nckx>That's what everyone I know does.
<janneke>rekado, kondor[m] yes i just use other names; git-foo.scm for example
<lfam>I think that in addition to making the installer script handle installing locales, or ever baking them into the binary tarball's store, we should rename the glibc-utf8-locales package or hide it
<lfam>It's misleading people
<lfam>It's not really a useful package except for US users. I would just hide it
<lfam>I mean, I know there are users from those other countries, but the US is the really big one
<nckx>It's really glibc-locales-for-tests, like we have ‘good-enough’ timezone data etc.
<nckx>Was it ever advised for use in by end-users?
<lfam>The manual suggests it to save space
<lfam>I suppose we will need to go through the process of deprecating it
<nckx>Good thing I never read the manual.
<nckx>I agree that renaming + hiding + deprecating the old name in favour of the full package or creating your own locale set on Guix System is the way.
<kondor[m]>can one remove all the packages from a manigest?
<kondor[m]>guix package -m manifest.scm -r
<nckx>lfam: Just a suggestion: say ‘~root/foo’ instead of ‘root's ~/foo’ in mails. Should work wherever ~s are parsed. This stuff is already (too) confusing & complicated… 🙂
<lfam>Yes, I suppose
<lfam>I feel like the ~user notation is obscure to new Unix users. They often think it's a typo
<lfam>I've seen people treat it like a typo
<lfam>Maybe /root/foo
<nckx>Did these people never visit the academic web.
<lfam>Are there really any systems where /root is not used?
<lfam>The academic web is the only place you see it
<nckx>lfam: If that's the case, /root is probably best. Shame tho'.
<lfam>I mean... I sort of need them to be able to know that root is a user with a home directory and be able to find that directory
<lfam>It's going to be hard to communicate otherwise
<efraim>We could make locales even harder and have it be a build-your-own kind of function
<lfam>That would really reduce the rate of bug reports ;)
<nckx>I'm trying to put aside my annoyance at assuming a person who's trying to help you and giving exact commands ‘probably made a typo lol’. Failing, but trying.
<efraim>Only the locales you care about, plus en_US because computers
<lfam>I mean... I have made typos while trying to help people
<lfam>And ~lfam does look strange even to me
<nckx>I know, but at least wait for the error message.
<lfam>This is why I want to fix this for good
<lfam>We've tried to fix it a few times
<nckx>I think your suggested fix is the obviously correct one. Makes me wonder why it wasn't the first choice, then. Any gotchas I missed?
<lfam>I don't remember know
<lfam>It's been so long
<nckx>If it was just backwards compatibility, please reconsider, abstract imaginary person. Responding to the same question every week is its own hell and it. never. ends.
<lfam>Should I get really annoyed for a day or a little bit annoyed every day forever
<lfam>Time to get really annoyed
<nckx>‘You won't like me when I'm really annoyed.’
<lfam>No, I'll stay friendly. I'll just feel annoyed
<rekado>let me just chime in to say that I really appreciate you discussing how to improve this situation
<rekado>thank you!
<lfam>What's the URL for the latest manual again?
<lfam>Thanks rekado
<lfam>Well, we can't make the binary tarball include locales for all users out of the box because it's based on their username
<lfam>Their profile, that is
<lfam>Unix strikes again
<civodul>it's i think
<kondor[m]>lfam: ~user is obscure to old linux users, too (and i'm both old as in old and old as in linux user [since 2003]) :)
<kondor[m]>~user -> ~root
<lfam>There are multiple URLs for this copy of the manual
<civodul>lfam: re tilde, i think there's a tension between being "friendly" and being accurate
<civodul>the script should definitely use ~root, for example
<civodul>the snippets in the manual should do that too IMO, because they're pretty much a script that people will paste as-is
<kondor[m]>civodul: lfam maybe only a note explaining that ~ actually expands to .../ . this is enough to remove a contextual barrier in understanding [imho]
<kondor[m]>no wait, i'm making no sense
<kondor[m]>i think i should just stop working and typing in here :)
*kondor[m] zips up
<lfam>civodul: I agree it's the right thing for scripts and pastable instructions
*kondor[m] ... while realising this may be understood in a very very different way
<kondor[m]>can someone mute me please :D
<lfam>It's hard for me to find the right way to reply effectively to the more vague bug reports / requests for help
<lfam>I want to do it quickly and efficiently but usually I can't tell the person's level of expertise
<lfam>Especially since questions about the locales warnings tend to come from new users
<lfam>Also because the problems rapidly descend into the finer points of shell startup and environment variables, and these subjects are quite inaccessible to non-experts
<janneke>lfam: i support sharing such feelings, difficulties here -- i can relate to that
<civodul>lfam: yeah, the locales stuff is terrible
<janneke>civodul: i pushed a guile-3 commit to core-updates for guix, which i hope is okay
<janneke>it fixes guile-daemon by using guile-3 for the guix package too; but i found it a bit particular that this would have been overlooked...
<lfam>You mean guix-daemon?
<brendyyn>i mean even on my guixsd i see the locale warning from the daemon every now and then
<sneek>brendyyn, you have 1 message!
<sneek>brendyyn, rekado says: See also
<janneke>lfam: yes!
<civodul>janneke: sounds good!
<lfam>brendyyn: It would be awesome to get a bug report about that
<lfam>It really shouldn't happen
<brendyyn>i wouldn't know how to reproduce it now
<brendyyn>I think at the time I'd updated my profile, but not updated the system configuration in a few months
<lfam>I see. That was probably due to incompatibility between glibc versoins
<lfam>We have a mechanism to work around those transitions but I think you have to manually enable it
<lfam>I still think that's a mess but it's glibc's mess
<Formbi> do you have an idea how to solve this issue in Guix?
<Formbi>(maybe it's simple, but I don't know)
<civodul>hi Formbi
<civodul>Formbi: which issue?
<civodul>ah, that these three env vars need to be set
<Formbi>I get the «ld: cannot find (…)» when trying to build gccemacs via Guix
<civodul>libgccjit inherits gcc's native-search-path, so that should address part of it
<civodul>but it's kinda ugly that one must set all these variables
<civodul>especially for Emacs
<civodul>then your subshells have LD_LIBRARY_PATH set and bad things happen
<Formbi>so how should these vars be set?
<civodul>Formbi: that'll happen automatically in a profile that contains libgccjit + gcc + glibc, i think
<civodul>but for gccemacs, i'd recommend using wrap-program to make sure they're set
<Formbi>but I cannot /build/ it
<civodul>normally LIBRARY_PATH should be set though
<civodul>i'd recommend checking at the beginning of the build log the value of these variables
<Formbi>they do include the libgccjit stuff
<Formbi>what on earth is going on
<lfam>What's the push URL for guix-artwork?
<lfam>Never mind, I figure it out
<lfam>It's 'ssh://'
<lfam>The thing doesn't seem to work for that repo