***Server sets mode: +cnt
***Server sets mode: +cnt
<seepel>ungoogled-chromium doesn't seem to recognize the yubikey either <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 <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? <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 *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? <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> <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>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. <guix-vits>sirgazil: i'd same with Gnome on Fedora, but only with swap on (HDD). <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. <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: 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 <guix-vits>sulr70: yesterday there was an example of that on IRC. <brendyyn>You can see that I remove gdm-service-type <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>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! <sneek>Welcome back civodul, you have 1 message! <vagrantc>civodul: i just learned not to ./pre-inst-env with a clock set to ~1970 :) <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? <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! <guix-vits>sulr70: post your config to paste.debian.net <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 paste.debian.net <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 <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>yes...so this is all work that i avoided/postponed <vagrantc>hmmm... haven't tested weather linux-libre 5.5.x works with the modular config ... just using the defconfig <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>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>arm boards often have an annoying relationship to clocks <vagrantc>speaking of relationships to clocks ... night all! <civodul>rekado_: i looked at the "nfs-server" test yesterday, fixed a couple of minor issues, but it still fails <davidl>Whats up with logs.guix.gnu.org/guix ? Im getting a 504 gateway timeout, and for https version Im getting resource not found errors for specific log urls. <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>i mean you could test both if there is some reason to believe your program might break when core-updates merges <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 <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 <bricewge>brendarn: Rebooting should set the correct rights. <bricewge>There is probably a less drastic way to do it though... <kondor[m]>Is it a biggie if I submit a package for which lint reports "source not archinved on Software Heritage"? <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 <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 <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? <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>How can I replace the package source with a local directory - for testing the package? *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? <mbakke>guix-vits: yes, it's a little-known feature :-) <mbakke>htgoebel: does (source "/your/custom/fork") not work for you? <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 :) <mbakke>htgoebel: maybe a cookbook entry? :) <brendyyn>Do we want to eventually include firefox extensions as packages. <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? <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 *guix-vits `guix environment --ad-hoc --pure icecat strace -- strace icecat` C-c <brendyyn>its the blind leading the blind here lol <brendyyn>guix-vits: i just ran icecat in a --pure and i get fonts..... <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 <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? <rekado_>with linux-libre-4.19 I get an actual error “Protocol not supported” (which is also weird) <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 <civodul>efraim: didn't you submit a patch to make the global fontconfig cache a tmpfs? <efraim>no, sounds like an idea I had and something I did locally but never submitted <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 <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 <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>"fictional, not yet existing, font-build-system..." <3 <rekado_>…there *is* a font-build-system, though <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_>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>hmm, we haven’t had major problems with ci.guix.gnu.org and the many LE certs we use there. <civodul>i've had problems when i forgot to set the nginx deploy hook, though <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? <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. <mbakke>still can't figure out why manual-database.drv pulls in Guile 2.2 though <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 :( <civodul>mbakke: i'll push a couple of fixes shortly <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" <civodul>several of them, notably testse/packages.scm <mbakke>uff, probably from the Make 4.3 update <mbakke>civodul: the update in commit cdba91486a60bbba727d843707322f98f8286124 had to add "--disable-dependency-tracking" for gnu-make-boot0 *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! <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; ci.guix.info now failed with what i hope to be a guile3 error <leoprikler>andydarcyjewell: what does your config.scm look like? <leoprikler>Okay, let's start one step earlier, this happens on `guix system reconfigure ...`, right? <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 <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 et.al <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. <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 <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 <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 <andydarcyjewell>leoprikler: the compile completed, but the new binary can't find libgtk-x11-2.0.so :-( *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 :) <guix-vits>andydarcyjewell: i'm think if you aren't use `--pure`, installing an equivalent in user's profile will work the same way. <leoprikler>--pure is nice, but not that nice when you're dealing with GUIs <leoprikler>try compiling again and add LDFLAGS="-L $GUIX_ENVIRONMENT/lib" to make <rekado>civodul: I just forked and fixed it. <rekado>many of these seem to have been abandoned <andydarcyjewell>Ah, on closer inspection, I Factor has *two* makefiles: Nmakefile and GNUmakefile <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" <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. <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
<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]: 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. <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. <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>Seems like locales warnings are a daily issue <lfam>Another person on help-guix <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" <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 <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>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 <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? <bavier`>I believe the guix definition takes precedence <anadon>Wouldn't be based on channel order? <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. <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 <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 <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]>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 <nckx>glibc-random-utf8-locale-grab-bag <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? <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>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 <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? <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 <lfam>What's the URL for the latest manual again? <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 <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]) :) <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]>i think i should just stop working and typing in here :) <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 <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... <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! <lfam>brendyyn: It would be awesome to get a bug report about that <lfam>It really shouldn't happen <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>(maybe it's simple, but I don't know) <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>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 <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 <lfam>What's the push URL for guix-artwork? <lfam>Never mind, I figure it out <lfam>It's 'ssh://git.savannah.gnu.org/srv/git/guix/guix-artwork.git' <lfam>The git.sv.gnu.org thing doesn't seem to work for that repo