IRC channel logs

2022-11-17.log

back to list of logs

<mekeor[m]>so, i wanted to start developing on a node-application, and instead got into writing a tutorial on how to import mailing list archives into mu4e... great! anyway, g'night guix
<nckx>o/
<nckx>apteryx: Sorry for the blanket 543d971e revert, but the cause wasn't obvious to me.
<apteryx>nckx: no problems, I was trynig to understand what's wrong with the build farm not reconfiguring
<apteryx>I assume was caused by that change too
<apteryx>I thought I had adjusted every reference, but that was some 2 weeks ago
<apteryx>not sure if the change is worth pursuing anymore
<apteryx>ABI compatibility would be nice to migrate painlessly all define-record-type* to define-configuration though
<apteryx>are there tests for guix home that were failing?
<apteryx>nckx: I'm guessing this is the lovely fix: https://paste.debian.net/1260954/
<apteryx>partial though, cause I had problems with berlin's nginx config
<AwesomeAdam54321>What's the policy on packaging shell script wrappers?
<apteryx>wrappers for what?
<AwesomeAdam54321>A wrapper around podman
<apteryx>if it provides some extra features/convenience and has an actual upstream project, why not
<apteryx>(and has a free software license, of course)
<AwesomeAdam54321>Should it use propagated-inputs, or inputs and then substitute references to the program with this-package-input?
<AwesomeAdam54321>Or should it be up to the user to install the programs it wraps around?
<apteryx>the later, or a wrap phase if there's a bazillion of external commands used
<AwesomeAdam54321>apteryx: thanks
<apteryx>that's a best judgement effort; if the program is needed for actual use it must be there
<apteryx>if it's likely the user will want its features, it should be there
<apteryx>if it's an obscure one not likely to be commonly used or would inflate the closure size too much, it can be left for users to install
<mbakke>apteryx: could the legacy-build-shared-libs option of clang-from-llvm be a simple version check instead of an explicit keyword argument? are there cases where it should be #false for versions < 15?
<apteryx>the *DYLIB* LLVM/Clang options were introduced from LLVM 3.8, so we could in theory drop them from later clang
<apteryx>but we'd have to make sure the applications depending on them continue to build
<apteryx>which would likely may be a problem, at least before Clang 10 when most distros were still using BUILD_SHARED_LIBS=ON
<apteryx>mbakke: ^
<mbakke>apteryx: I mean, remove the keyword argument and just do (if (version>=? "15" llvm) '() '("-DCLANG_LINK..."))
<mbakke>btw, I have started a "Nix pills" like series for Guix, maybe of interest for some here: https://gexp.no/blog/guix-drops-part-1-package-transformations.html
<mbakke>(the other posts on that blog are probably not so interesting, more a way to clear my headspace...)
<drakonis>ah, nice.
<the_tubular>Nix pills ?
<drakonis>the_tubular: its some old nix docs that would explain nix in small doses
<mbakke>Nix pills were a series of blog posts (by Domen Ko??ar?) that helped me get started with Nix back in the day ... nowadays they seem to have been subsumed into the Nix manual.
<drakonis>bruno luca actually
<drakonis>luca bruno
<apteryx>mbakke: that would achieve the same for now but is less granular when we want to try and make older versions use DYLIB too (if we ever go there)
<apteryx>if you want to make the change, I'm OK with it, as I suppose we won't ever need 3.7 with DYLIB and 3.8 with BUILD_SHARED_LIBS
<mbakke>OK, I just might, got some motivation to hack on Guix again these days :)
<the_tubular>??Ohh nice, drakonis
<the_tubular>I'll check it out
<apteryx>mbakke: cool :-)
<apteryx>happy to see you around!
<apteryx>nckx: I've fixed the issues reported + another one I spot, so reverted the revert :-). If there are other missed occurences, the fix should be similar (it was very hard to isolate where the failure came from though!)
<apteryx>ACTION punts until tomorrow to push these though. I'll reconfigure berlin as a test.
<apteryx>ACTION zzz
<user___>night guix
<unwox>morning, guix :)
<mekeor[m]>hello guix :)
<xd1le>o/
<AwesomeAdam54321>o/
<civodul>Hello Guix!
<xd1le>o/
<omlet[m]>Guix latest vs guix standard?
<unmatched-paren>omlet[m]: you mean latest vs 1.3.0?
<unmatched-paren>definitely latest
<omlet[m]>unmatched-paren: Yes
<unmatched-paren>when you pull you update to master anyway, but the 1.3.0 installation image is so old it probably shouldn't be used
<omlet[m]>But the latest not is unstable?
<omlet[m]>estou em duvida entre escolher o guix mais recente e o guix 1.3
<unmatched-paren>no, guix is rolling release
<unmatched-paren>which means you always use the latest commit
<omlet[m]>Why the guix 1.4 has not yet arrived
<unmatched-paren>the latest version tag is extremely old
<unmatched-paren>omlet[m]: It's being worked on :)
<unmatched-paren>1.4.0 should come out soon
<unmatched-paren>but even then, the versions are just ceremonial markers
<unmatched-paren>you *always* stick to the latest commit
<unmatched-paren>it's not like debian :)
<omlet[m]>unmatched-paren: is it possible to migrate from gux latest to future gux 1.4 without much complexity?
<unmatched-paren>omlet[m]: the 1.4 is just some random commit that we decide is 1.4
<unmatched-paren>ACTION away
<unmatched-paren>so there's no migration needed
<omlet[m]>Or package?
<omlet[m]>unmatched-paren: Your is guix developer?
<omlet[m]>is it possible to package the distrobox (podman) for the guix?
<omlet[m]>I AM noob, not AM developer but in nixos the distrobox its very good
<omlet[m]>And all free software
<AwesomeAdam54321>omlet[m]: I actually already have a template and it almost works
<omlet[m]>GPL 3
<omlet[m]>AwesomeAdam54321: Good
<omlet[m]>AwesomeAdam54321: When I'm sent to the latest, can you tell me?
<AwesomeAdam54321>sure
<omlet[m]>Why distrobox its very good for use
<omlet[m]>Install debian or fedora without kernel bloatware
<omlet[m]>AwesomeAdam54321: Distrobox its OK
<omlet[m]>But tor-browser i too use in flatpak
<omlet[m]>Native package is good, but
<omlet[m]>a xmpp person said the source code of the browser tor was not totally free software
<rekado>apteryx: I don???t see multipath among the supported types
<allana>mbakke: Is it your blog at gexp.no? I just read your recent post on package transformations. I have enjoyed your previous entires as well. Please keep it going :-)
<civodul>oh, new blog post? kudos mbakke!
<omlet[m]>Guix have a f??rum?
<AwesomeAdam54321>omlet[m]: No, but there's a mailing list
<xd1le>civodul, hope you're feeling better?
<civodul>xd1le: better?
<civodul>not sure what you're referring to, but i'm feeling good :-)
<AwesomeAdam54321>Can someone package gemget? I don't have much experience with Go packages: https://paste.debian.net/plain/1260975
<civodul>AwesomeAdam54321: looks like you did a good job already, you can try pushing it past the finish line
<cbaines>qa.guix.gnu.org has a new colour it can use to describe patches, red! https://qa.guix.gnu.org/patches
<cbaines>unfortunately there are quite a few issues affected by spurious protobuf-2 failures, but at least this makes it easier to see
<kori>when running `guix deploy`, I'm getting `remote command '/run/setuid-programs/sudo -n -- guix repl -t machine' failed with status 1
<kori>`... what am I forgetting? :thinking:
<civodul>the Shepherd 0.9.3 is in the house!
<civodul>cbaines: neat!
<civodul>didn't know the machinery uses protobuf
<xd1le>civodul, sorry was afk, I just meant how you were feeling sick few days ago.
<civodul>kori: hi! does it provide additional info?
<kori>civodul, hello! nope... but I ran the sudo -n command, looks like it's trying to escalate to root without a password?
<civodul>kori: right, i guess it expects to be able to do that when you choose the sudo option
<civodul>the other option is to allow SSH root logins
<jonsger>cbaines: pokerth and protofbuf seem to always changed, I'm a bit confused
<kori>civodul, AH, okay, this is specified in the page... my eyes glossed over that part, my bad.
<jonsger>civodul: nice, so shepherd has 4 release more then Guix this year :P
<civodul>jonsger: yup :-) though it admittedly requires less coordination and there's a couple of orders of magnitude less code in there
<jonsger>yep :)
<kori>civodul, I did it, thanks!!! (and by I did it, I mean... I got a different error :) but that's progress nonetheless)
<kori>maybe I can't debug this one, though...
<kori> https://paste.debian.net/1260988/
<kori>found the issue :) x86_64.linux instead of x86_64-linux
<civodul>kori: oh, it could certainly report the error in a nicer way
<cbaines>jonsger, that's because it does. A gexp leaked in to the builder script, which meant you got a different derivation/builder every time you computed it
<cbaines>it also fails to build, so that's what's led to lots of things showing up as failing
<cbaines>the issue with the package is fixed now, but for comparisons made while it was an issue, it'll show up and confuse the results
<ennoausberlin>Hi. I wonder if the image definition somehow changed recently. I used an definition to create a raspberry pi image before, but now I get an error about missing field identifier (operating-system).
<civodul>ennoausberlin: could you share the image file you're using?
<civodul>funny: these days you can do "herd restart udev" and it just works
<civodul>there was a time where shepherd would just get lost and the system wouldn't come back
<civodul>(before you try this at home, note that it's almost equivalent to rebooting)
<ennoausberlin>civodul: Don't know if it violates the non-free software rule on this channel. It is from pantherx, but I guess the problem is not related to the non-free parts
<civodul>ennoausberlin: at least you can share the exact command and error message that you got
<ennoausberlin>civodul: I sent you a PM with the command and the error was missing field identifier (operating-system)
<civodul>ennoausberlin: right, an 'image' needs an 'operating-system' field: https://guix.gnu.org/manual/devel/en/html_node/image-Reference.html
<rekado>tomorrow there will be an outage
<rekado>what???s missing to get the websites served from bayfront?
<rekado>I suppose we would need to change the DNS records for guix.gnu.org, workflows.guix.info, and ??? others?
<apteryx>civodul: also, udev monitors files such as udev rules under /etc now, so it knows to reload any new/modified ones, so you don't need to reboot or restart udev after adding a new rules file
<apteryx>rekado: I'd symply rsync the content of the site to node 129 and reconfigure the DNS to point there for the web site(s)
<rekado>apteryx: oh, serving from node 129. Yes, that???s an option.
<rekado>the SAN is also connected to 129, but not mounted anywhere
<rekado>re multipath: once SAN maintenance is over I???d like us to test if we can boot from the 10T SAN slice with multipath with node 129.
<rekado>we can install a system to the 10T volume, play with the initrd, and then try to boot with multipath enabled ??? without affecting the 100T volume.
<apteryx>rekado: perhaps it could be mount read-only on node 129, with a bind mount to shadow /srv/http or something?
<apteryx>but I thought the issue is the SAN is going down
<rekado>exactly
<rekado>that won???t work
<rekado>I???m talking about *after* maintenance
<apteryx>ah, ok :-)
<rekado>we need to get multipath enabled soon
<rekado>this won???t be the only maintenance or update of the SAN
<rekado>and with multipath enabled we can simply ignore these downtimes
<apteryx>agreed
<rekado>what I wrote above is a simple plan to get it right without having to reboot ci.guix.gnu.org again and again
<rekado>it???s the same SAN (albeit a different volume), and we???re using pretty much the same hardware
<rekado>so whatever we learn with node 129 should be transferrable.
<apteryx>it is
<apteryx>good idea
<apteryx>that's the original reason node 129 was setup (as staging ground for berlin disruptive changes)
<rekado>right
<rekado>do we have a similarly complex btrfs setup on 129?
<apteryx>it's more complex
<apteryx>it's on a Btrfs RAID
<rekado>I thought we had a btrfs RAID on ci.guix.gnu.org as well?
<apteryx>berlin is plain Btrfs on top of SAN
<rekado>ah, right
<rekado>the RAID thing was only temporary while we used the SSDs
<apteryx>yes, it was used to stitch together the SSDs into a bigger volume
<apteryx>I'll use multi-disk Btrfs again after we move the SSDs to node 129
<civodul>rekado: the only thing missing on bayfront are the certificates, i think
<civodul>and yes, we'd need to change the DNS records
<nckx>Heyo.
<nckx>apteryx: Thank you!
<rekado>civodul: since this is a temp thing for a day we only need to copy the certs; we don???t need to have an answer to the certbot problem.
<nckx>civodul: How are DNS changes managed, and if it's through that file in maintenance, how are they pushed to gnu.org?
<apteryx>ACTION is curious as well
<nckx>Oh, or is this in the ???new??? infra handbook, which I did not check :)
<nckx>I didn't find any dox last time.
<apteryx>I'm afraid not, but it'd be nice to have it, if someone has a clue
<cbaines>I think we run our own DNS thing (knot)
<nckx>I vaguely remember some self-hosting chat, years ago, but that's not what drill guix.gnu.org ns implies.
<nckx>cbaines: Oh?
<cbaines>maybe knot somehow talks to the GNU nameservers?
<cbaines>but I should stop speculating
<nckx>No, that's possible. They could, erm, secondary off of it.
<cbaines>there's definately some configuration that looks like stuff being sent to a GNU nameserver https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm#n990
<nckx>bayfront answers DNS queries so that's probably it.
<nckx>Thanks.
<civodul>nckx: change dns.scm, reconfigure berlin (which hosts the relevant knot instance), and that's it
<civodul>s/berlin/bayfront/
<civodul>gnu.org delegates to bayfront for *.guix.gnu.org
<civodul>rekado: yes, we just need to copy the certs
<civodul>i'm never quite sure which part of /etc/letsencrypt/ is relevant though
<civodul>it's full of symlinks and all, quite scare
<civodul>*scary
<nckx>But why do the serial numbers wildly mismatch then.
<nckx>2021101419 vs. 2022092209.
<nckx>Am I looking at the wrong server?
<cbaines>where are you seeing those numbers?
<nckx>drill guix.gnu.org soa @bayfront.guix.gnu.org
<nckx>Ah, OK, so that's the gnu.org serial.
<nckx>Weird.
<rekado>civodul: I???d copy it all.
<cbaines>as an alternative, I'd suggest just perhaps copying certificate (or the fewest files required for NGinx to work)
<cbaines>and then putting them in a different place to wherever letsencrypt would usually
<apteryx>I just got dropped out of an ssh connection to berlin.guix.gnu.org: "Timeout, server berlin.guix.gnu.org not responding."
<cbaines>issues.guix.gnu.org is also not working for me
<civodul>cbaines: i'm more sympathetic to that option
<civodul>(copying the minimal things)
<civodul>so we need to get that done by tomorrow?
<cbaines>I think/hope getting NGInx working might just require a couple of files, as that's what the config references
<apteryx>berlin went offline, what happened?
<cbaines>that's a copule of files per cert though, and there might be multiple certs to copy
<apteryx>I also can't access hydra-guix-129, so perhaps a network outage at the MDC?
<rekado>yes, just heard of it
<rekado>looks like a broken routing table at the DFN
<mekeor[m]>what are mdc and dfn?
<cbaines>seems to be back now
<rekado>MDC = Max Delbr??ck Center
<rekado>DFN = Deutsches Forschungs-Netzwerk
<rekado>DFN provides and operates networking infrastructure for universities and research institutes in Germany
<rekado>the MDC is a publicly funded research institutes in Berlin, Germany.
<rekado>most of the Guix build farm is located in the MDC???s data center.
<jonsger>ACTION proud tax payer in case of the MDC :)
<rekado>(~25 x86_64 nodes, 3 aarch64 nodes, big storage, etc)
<ennoausberlin>rekado: What aarch64 hardware is running there?
<ennoausberlin>jonsger: Me too :)
<rekado>ennoausberlin: honeycomb lx2
<rekado>one of them is currently sitting on my living room coffee table with a bad SSD, but I???ll bring it back soon.
<mekeor[m]>you can gladly use it as heater, i'm fine with it
<mekeor[m]>ACTION tried to make a joke
<ennoausberlin>rekado:?? 3000$ I can't justify at home. But looks nice
<rekado>less than $3000: https://shop.solid-run.com/product/SRLX216S00D00GE064H09CH/
<rekado>but certainly not cheap
<ennoausberlin>Now we just need to Euro Dollar Ratio from 1985 and I am in :)
<ennoausberlin>*the
<ennoausberlin>rekado: Wow, thank you for the link. Thats a basis for discussion with my wife
<rekado>ennoausberlin: I found that this system is very picky when it comes to the types of SSDs it supports. It???s also picky about RAM.
<rekado>and it has no built-in graphics chip
<rekado>(we???re using the serial-over-USB thing to set them up)
<anschlussy>Quick question: is the "propagated input" aspect of guix missing in other package managers? I feel like I've had to install random packages to get some packages to work on other distributions, but maybe I'm only thinking of when software is packaged in some other weird way, where I need a bunch of deps before configure-make or whatevs
<AwesomeAdam54321>anschlussy: I think you're right that propagated-input aspect is missing in other package managers, but that's because pretty much all package managers don't isolate the build environment
<AwesomeAdam54321>Without doing package management with a functional approach, inputs and propagated-inputs are the same
<nckx>anschlussy: It's more the opposite: other package manages *only* ???propagate???. They know nothing else.
<nckx>On those distros, ???I had to install B to make A work??? would (IME) be considered a bug, and B added as a ???dependency??? of A, et voila.
<anschlussy>ah, i see
<nckx>I think both answers are the same in spirit, just from a different angle.
<gnucode>morning guix!
<nckx>Hello undercover jab.
<ennoausberlin>rekado: I will have a closer look. But my brother owns a hardware store and he can assemble it for sure.
<mekeor[m]>gnucode: good morning
<nckx>I guess that explains why they charge $3000 to turn it into a complete working system???
<mekeor[m]>anschlussy: yea, i guess, some other package managers don't distinguish between "inputs" and "propagated inputs"
<nckx>Some distros I used had ???build dependencies???, but they got treated so sloppily (and globally) that I have a hard time mapping them to anything Guixy.
<nckx>Seems like Gentoo has grown that distinction since I used it.
<yarl>Hello guix :)
<sneek>Welcome back yarl, you have 1 message!
<sneek>yarl, nckx says: Has your mail arrived yet? You wrote 'guix-help' twice, instead of help-guix; that might be the reason.
<nckx>Ehlo.
<yarl>sneek: later tell nckx Yes I think
<sneek>Will do.
<nckx>sneek: botsnack.
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, yarl says: Yes I think
<sneek>:)
<nckx>yarl: OK, good :)
<ennoausberlin>rekado: Does guix run native on the honeycomb or as package manager on a foreign distro?
<yarl>Also, I lost some time understanding why I couldn't "guix import texlive ..." but this is referenced there https://issues.guix.gnu.org/52731
<yarl>I think something should be done about this.
<yarl>At least in the manual.
<yarl>(I had not installed subversion)
<nckx>The perfect sure murdered the good in that discussion.
<yarl>nckx: right :(
<nckx>(But the last reply is still too dismissive, and it's not reviewers' fault the patch stalled.)
<rekado>ennoausberlin: we run Guix System on the honeycomb machines
<rekado>we have a system configuration in the maintenance.git repo.
<rekado> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/honeycomb.scm
<ennoausberlin>rekado: This is like a good task for the new year.
<nckx>Has anyone seen ???Error: (file-error "Doing vfork" "Exec format error")??? show up in their Emacs messages ~recently? There is no further context. It just happened again after an M-x revert-buffer.
<rekado>ennoausberlin: when I read ???hardware store??? above I thought you meant ???Baumarkt??? and imagined a motherboard screwed to a bunch of two by fours.
<civodul>nckx: not me!
<rekado>nckx: haven???t seen that. Could it be related to the jit?
<ennoausberlin>rekado: computer store might be the better term.
<nckx>rekado: I'm not clever enough to know, but I wondered that too.
<nckx>It survived a complete reinstall of /gnu/store, so it's not [likely to be] corruption.
<nckx>Still, I suspected Guix enough to ask here first. I'll take it to #emacs if I can't find the cause.
<morganw>nckx: I've not seen that specific problem, but there is definitely breakage from native compilation being on by default, e.g. EXWM now doesn't work until it is compiled, so I've had to start logging in once with a different window manager
<gnucode>nckx hahah undercover. that was good.
<gnucode>mekeor[m] what's going ok?
<nckx>["/home/nckx/.local/bin/git", "--no-pager", "ls-files", "-c", "-z", "--", "gnu/packages/video.scm"] ??? = -1 ENOEXEC (Exec format error)
<nckx> https://www.tobias.gr/success.jpg
<nckx>Thanks to all who chimed in.
<apteryx>do we have an autoindex module for nginx packaged?
<nckx>apteryx: No.
<nckx>It's built in.
<apteryx>ah, neta
<apteryx>*neat
<apteryx>hm, no docs
<apteryx>nckx: how would I enable such module? the guix way asks of a file-like object
<apteryx>but there's no such object for an autoindex nginx module?
<nckx>Yes docs: links $(guix build nginx-documentation)/en/docs/http/ngx_http_autoindex_module.html
<nckx>I'm afraid I don't understand the file-like object question. Why are you trying to enable a module that doesn't exist?
<nckx>s/doesn't exist/is built-in/ I mean.
<nckx>I'm clearly missing some intermediate goal.
<nckx>Now, I haven't tried any of the fancy features (like XML/XSLT stylin'). Are they broken?
<apteryx>2022-11-17 15:00:00 10948 /gnu/store/m7yih1fnwhsz48aifx4c8ajdb90a8wsz-cleanup-cuirass-roots: running... [...] 2022-11-17 15:00:01 10948 /gnu/store/m7yih1fnwhsz48aifx4c8ajdb90a8wsz-cleanup-cuirass-roots: completed in 0.967s
<apteryx>neat!
<nckx>Whoa.
<apteryx>nckx: I'm just toying with a local instance of nginx, and noticed I couldn't just serve a directory out of the box
<apteryx>so I'm wondering how to enable that builtin autoindex module you speak of
<nckx>That is??? strange.
<nckx>There is nothing to enable.
<nckx>What error do you get?
<apteryx>it's looking for an index.html file
<nckx>Or, what's your nginx.conf?
<nckx>Yes, autoindex is off by default, but it should not need any modules to be enabled.
<nckx>Web dox: https://nginx.org/en/docs/http/ngx_http_autoindex_module.html
<apteryx>pretty spartan: https://paste.debian.net/1261018/
<apteryx>I haven't added any directive for autoindex yet, that explains it
<nckx>Ah.
<nckx>Am I to take this as a hint that Apache or whatever enables it by default?
<nckx>ACTION can always use another reason to be happy they use nginx.
<apteryx>so that goes in a ngnix-location-configuration which goes in the nginx-server-configuration' locations field
<apteryx>nckx: no, just that we have examples on how to enable it for apache
<apteryx>in our info manual
<nckx>apteryx: In the dox you'll see ???Context: http, server, location???, so those are all the valid ???blocks??? that should accept it.
<nckx>Depending on the granularity you want.
<apteryx>OK! thanks for the hint
<nckx>Or you can set it to ???on??? in http, then select specific locations to set to ???off???, etc.
<nckx>nginx .confs are almost intuitive. Almost.
<nckx><we have examples> Oh, didn't know that.
<mprodrigues>Hello. I've been trying to split my installed packages into profiles and loading all the profiles on login, but I've run into a problem. The packages are loaded alright, but it seems that packages from one profile cannot see packages from other profiles, for example I have a profile for my fonts, and not one of my programs in the default profile
<mprodrigues>can use them, also I have a profile with all my emacs packages and emacs was only able to use them when I moved emacs to the same profile. Is this how it is supposed to be, or am I doing something wrong?
<mprodrigues>I basically followed what was in the cookbook to load all my profiles
<AwesomeAdam54321>mprodrigues: It's how it's supposed to be, package profiles are separate
<nckx>mprodrigues: That is expected. search-paths are per-profile.
<nckx>(I'm not familiar with the method in the cookbook.)
<nckx>Layering multiple profiles can be useful, but as you've discovered they can't ???interact???.
<mprodrigues>oh I see, I thought something like that was in play, but that is quite a bummer to me I'd say, thank you for your help.
<nckx>Sorry.
<apteryx>there's an open bug about profile merging
<apteryx>there's another bug about handling search paths transitively
<apteryx>(probably at the bottom of the issue stack)
<apteryx>is tramp broken for everyone, or just me?
<apteryx>e.g. in emacs, C-c C-f /ssh:some-server: -> File not found and directory write-protected
<apteryx>many things have been weird in my emacs though, so it could that I'm due for a reboot
<nckx>Someone else reported that rece???never mind. https://logs.guix.gnu.org/guix/2022-11-13.log#172942
<nckx>What's C-c C-f?
<apteryx>Control+c then Control+f
<nckx>What's it bound to.
<apteryx>M-x find-file
<nckx>Thanks. That's C-x C-f here. For me, hitting return just freezes, even to /ssh:localhost: .
<apteryx>to use tramp you just need to know some prefix, such as "/ssh:" or "/sftp:" or "/sudo:" or whatever it supports; info '(tramp) File name completion'
<apteryx>nckx: ah, that was a typo, apologies :-)
<nckx>You could have told me it was evil mode or whatever and I've had been none the wiser. ????
<apteryx>ACTION uses pretty much vanilla emacs
<apteryx>so, it is broken for you as well
<morganw>It is it actually connecting and it cannot detect the shell type, I think it can hang indefinitely.
<nckx>I have ???tramp-default-method "ssh"??? set, don't know if that matters.
<apteryx>mine is 'scp'
<morganw>I've never set that variable, if that helps.
<nckx>Yeah, ssh is supposedly faster, but then it might also be the default now, I haven't kept up.
<nckx>morganw: So it works for you?
<nckx>apteryx's and my problems are different enough that I'm not sure they're related.
<morganw>Yes, I've never had a problem that wasn't related to the shell type of the completion framework, and in those cases it is fairly obvious that it actually connected
<apteryx>I've updated both my system and user profiles, will reboot and report
<apteryx>ACTION remembers to run 'sudo ~/scripts/standalone-boot.sh' ...
<nckx>I don't use a ???completion framework???.
<nckx>Without any .emacs (ew, menu bars) I still get the same freeze.
<nckx>ACTION AFK for the afternoon.
<SUPERB[m]>Hi
<SUPERB[m]>I tried to install Guix several but all failed cuz of errors while I watched some videos on YouTube and tried to the same as they do. And tried both the standard and the latest versions!
<SUPERB[m]>The errors are about substitutions
<SUPERB[m]>ACTION uploaded an image: (5011KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/awmCRtpeqetEkVZWShzWWcxE/ima_b30206e.jpeg >
<ennoausberlin>SUPERB[m]: Might be a network glitch.
<apteryx>hmm. can't type at the GDM screen.
<SUPERB[m]>ennoausberlin: I???ve tried that like ten times
<fps>SUPERB[m]: yeah, just rerun the command. it should try the same substitute again
<fps>does the error occur on different substitutes?
<SUPERB[m]>Yeah changes every time
<fps>then just slap a while true; do guix system ...; done around it
<fps>until it succeeds ;)
<fps>or fix youur network ;)
<SUPERB[m]>ACTION uploaded an image: (3972KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/XKxQoNUtQsOYuqxYnpFGePbt/ima_4cbad81.jpeg >
<apteryx>has anyone had this problem where you can't input anything at the GDM screen?
<SUPERB[m]>All about substitutions
<ennoausberlin>SUPERB[m]: Can you try the --substitute-urls="https://bordeaux.guix.gnu.org" when pulling?
<ennoausberlin>SUPERB[m]: You use the graphical installer?
<SUPERB[m]>ennoausberlin: Yep
<ennoausberlin>SUPERB[m]: You can probably open another terminal and configure the bordeaux server as alternative, but it is not easy for me or any other newcomer. Better try to install with a reliable network connection. There are also outages of the guix servers from time to time.
<jorge[m]>Hola, por razones de mi libertad de software icecat no me permite usar algunos servicios en la nube, por favor si conocen alguno en software libre.
<SUPERB[m]>ennoausberlin: Ok
<civodul>apteryx: nope (not yet?)
<apteryx>it sucks, I can't login
<civodul>ouch
<apteryx>I don't see anything wrong in the logs, and the system appears otherwise fine
<apteryx>(login graphically -- if I switch to TTY2 I can login)
<civodul>mouse works?
<apteryx>yes, but clicks do not do anything (buttons/menus of GDM don't respond)
<apteryx>it appears frozen
<ennoausberlin>apteryx: Give sddm a try, maybe
<apteryx>yeah that's what I'll have to do (or lightdm or slim) if I can't figure it out quickly
<ennoausberlin>apteryx: gnome terminal-extensions blew my machines login as well a few months ago. I had to delete some .cache or .local files if I remember right
<apteryx>I don't use gnome-terminal or its extension, but that sucks
<apteryx>at least GDM cache itself is on a tmpfs and not persisted anymore
<gnucode>lxterminal works fairly well for me. :)
<ennoausberlin>what happens if you kill gdm from the console
<gnucode>ennoausberlin nuclear fallout...
<apteryx>strace -p on the GDM processes all show the same story: restart_syscall(< resuming from an interrupted read > ...)
<gnucode>ennoausberlin: trust me, you don't want that on your consciousness.
<apteryx>ennoausberlin: I tried 'herd restart xorg-server', it returns to that frozen gdm screen
<ennoausberlin>gnucode: It can't be worse than apt remove python from a running system *ahahaha*
<ennoausberlin>gnucode: non guix system of course
<civodul>apteryx: does ~/.local/share/xorg/Xorg.1.log have anything to say on input devices?
<civodul>cbaines: looks like dover has been unreachable for some time; any idea what's up?
<omlet[m]>ACTION uploaded an image: (96KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/sHkYIljEKRbGGQjIyhPlTndK/20221117_155219_8564706132493958004.jpg >
<omlet[m]>Guix latest
<omlet[m]>Make the downgrade?
<omlet[m]>Or for now no?
<cbaines>civodul, I tried to reconfigure it, and I ran in to some weird error with the bootloader. I tried a reboot, but I'm not sure it's come back. At some point I'll try connecting via the serial console to see what's up.
<apteryx>civodul: looks normal
<apteryx>my keyboard is registered
<omlet[m]>omlet[m]: ?
<gnucode>ennoausberlin: :)
<unmatched-paren>afternoon guix!
<gnucode>unmatched-paren welcome to the party! We were just talking about you. All good things.
<ennoausberlin>omlet[m]: can you tell me what "which guix" gives you as result
<unmatched-paren>gnucode: /me scrolls backwards
<omlet[m]>ennoausberlin: For downgrade the system
<omlet[m]>Why is more actualized than in repository i think
<ennoausberlin>I just want to make sure that you not accidently installed guix into your profile by guix package -i guix
<unmatched-paren>gnucode: /me cannot find :)
<apteryx>civodul: I'm reconfiguring an x200 laptop that uses gdm on latest guix and will reboot to compare with
<ennoausberlin>*afk
<civodul>apteryx: you could check in 'guix system vm', too
<civodul>if the bug shows up in a VM, it's "better"
<civodul>cbaines: alright, lemme know how it goes! would be nice if it could get back to life
<civodul>ACTION sent weekly release update
<cbaines>are we so dependent on ci.guix.gnu.org substitutes for this release since it'll be the first with bordeaux.guix.gnu.org as a default substitute server?
<cbaines>civodul, ^
<cbaines>it's fustrating that bordeaux.guix.gnu.org solving this substitute availability problem isn't helping with the release
<cbaines>although maybe I'm being overly critical there, as I think it's helping indirectly
<civodul>cbaines: it'll be the second with both bordeaux.guix and ci.guix by default, no?
<civodul>but yeah, i share that frustration
<civodul>we need to get our act together though
<civodul>we have a number of "tiny infra issues" to address
<gnucode>unmatched-paren I was just teasing you.
<rekado>ACTION gives up trying to fix the SSD
<unmatched-paren>gnucode: Oh. :)
<rekado>this disk only lasted one year
<rekado>I???ll contact the seller.
<cbaines>civodul, hmm, I'm not sure it made it in to the last release
<cbaines>that reminds me, I think nckx had some changes to the guix-install.sh script to authorise bordeaux, and that should be part of this release
<civodul>rekado: that was a disk behind ci.guix?
<civodul>cbaines: oh you're right, the addition of bordeaux.guix dates back to 4985a4272497bf9ba87a2190353d915da9b55906 (May 2021)
<civodul>i thought it was from before 1.3
<civodul>1.3 is so old :-)
<civodul>cbaines: re guix-install.sh, it evolves independently of releases and i think we can enable it right away
<civodul>s/enable it/enable bordeaux.guix/
<cbaines>civodul, as nckx discovered, I think we need the signing key in the release tarball
<civodul>argh
<cbaines>at least the way it currently works
<civodul>ok
<rekado>civodul: yes, the disk in pankow (the failed aarch64 node)
<rekado>just sent out my RMA claim
<permcu>Hi:) Common Lisp question: How do I load a CL package installed with guix? guix shell sbcl sbcl-cl-str -- sbcl then (asdf:load-system :str) fails because package asdf does not exist. Adding cl-asdf makes no difference.
<civodul>rekado: oh, thanks for taking care of it
<rekado>sure!
<rekado>civodul: congratulations on the shepherd release!
<permcu>Found it out myself: (require "asdf") and then asdf can be used.
<civodul>thanks :-)
<lechner>rekado / which brand was the disk, please?
<civodul>apteryx: re configuration field order, are you confident that there are no issues left?
<civodul>'match' has been used a lot on configuration records
<civodul>i'd be surprised if there's no instance left
<apteryx>so GDM on the x200 laptop works happily
<apteryx>and an older generation on the desktop works fine too
<apteryx>hm, the main thing which seems to have changed is the kernel
<apteryx>it would be nice to have a tool to compare two generations
<apteryx>ACTION runs diff -u /var/guix/profiles/system-{441,442}-link/profile/manifest
<apteryx>hm, the kernel update from 5.19.17 to 6.0.8 seems to be the main change between the two profiles
<apteryx>civodul: all the test passes, berlin reconfigures, my system reconfigures. that's the confidence I have.
<apteryx>note that it only affects matching define-configuration'd records
<lizog>hello guix, when trying to update zig to 0.10, i encountered an error in validate-runpath phase. basically it is 'error: depends on 'ld-linux-x86-64.so.2', which cannot be found in RUNPATH'
<civodul>apteryx: right, but there are quite a few of them, certainly more than used by berlin or one person's machine
<civodul>for example, i wonder if the evaluation failure at https://ci.guix.gnu.org/jobset/tests is connected
<civodul>#<unknown port>:16:148: Unknown # object: "#<"
<civodul>could well be a <location> record finding its way down the road
<lizog>but if i run 'ldd /gnu/store/somehash-zig-0.10.0/bin/zig', there is an entry showing ld-linux-x86-64.so.2
<gnucode>lizog: playing with zig in guix sounds awesome!
<rekado>location record in the wrong place sounds just like this guix home issue.
<civodul>yes, that's what we're discussing
<rekado>oh.
<rekado>ACTION reads more backlog
<civodul>i wouldn't be confident changing record layout like this
<rekado>lechner: Samsung 870 QVO 500 GB
<civodul>we have system tests for most, but not all, system services
<rekado>lechner: we bought three; the other two are still fine.
<civodul>and we have zero tests for Home services
<civodul>so wide-ranging changes like this are tricky
<civodul>"works for me" is not good enough
<mprodrigues>Hello again. I have continued experimenting with profiles and now am a bit confused with the following. If the profiles don't interact, how come my emacs (in a separate profile) correctly finds and loads a custom font installed only in my default-profile?
<apteryx>rekado: there was a problem, and it was fixed
<apteryx>if we find more issues, they should be fixed too. the real problem here is that guix home doesn't have tests
<apteryx>(or too few)
<jackhill>anyone else having issues running gnome-control-center in sway? Mine segfaults without additional console messages. Amusingly, I can run nautalus in sway, but have the oposite failures on another computer with gnome-shell.
<tricon>mprodrigues: that would be due to env vars. env vars aren't cleared unless you utilize `--pure' with the `guix shell' command.
<mprodrigues>I see, makes sense, thanks
<apteryx>I couldn't reproduce my gdm issue in a VM, although it took a lot of time to process the input
<apteryx>civodul: to be clear, I did review the usages of define-configure'd records in the source, not just blindly trusted the tests.
<efraim>vagrantc: have you tried flashing the emmc in the pinebook pro with guix system? I seem to be getting some error about not reading the emmc, after it read the emmc for u-boot
<apteryx>I may have missed a few though, but fixing these once spot should be trivial
<vagrantc>efraim: i've only ever used microsd and nvme ... and it's been a while since i've run guix on it
<efraim>vagrantc: I've run it from the microsd before too. I might just stick the nvme in since I bought the adapter in the end
<vagrantc>efraim: is u-boot still 2022.04 ? i've had issues with newer versions with the pinebookpro
<efraim>vagrantc: yep, still 2022.04
<vagrantc>efraim: and looks like guix is still arm-trusted-firmware 2.6 ... that's my next suspect
<efraim>I think the manjaro one is still 2021.10
<apteryx>ACTION reboots once more
<efraim>I guess I can look through the release notes and see if anything is noted. I'll check the error message again to see if got deblobbed or something
<civodul>apteryx: alright (it's an opportunity to switch those to match-record too)
<civodul>i think we should try harder to avoid breakage on master though
<civodul>(i'm saying this as someone who breaks things often enough)
<omlet[m]>Have portuguese people here?
<madage>omlet[m]: do que precisa?
<omlet[m]><madage> "omlet: do que precisa?" <- Apenas gostaria de organizar a comunidade no que toca a v??rios assuntos como atualizar a documenta????o e criar grupos e blogs sobre o guix em portugu??s
<omlet[m]>Videos tamb??m
<apteryx>ah, gdm "works" if I leave it a really long time on that machine. Not sure why on past generations it's faster...
<apteryx>it's doesn't seem related to the kernel version either
<madage>sugiro criar um canal pr??prio para isto e assim evitar poluir este. Depois que criar, anuncie aqui o endere??o.
<madage>omlet[m]: ^
<madage>acredito que j?? h?? gente trabalhando nesse sentido, procure as refer??ncias de tradu????o no site
<omlet[m]>madage: Bem, vou criar um grupo fora do matrix.org por causa da autentica????o da google
<omlet[m]>E um no xmpp
<omlet[m]><madage> "sugiro criar um canal pr??prio..." <- Se por acaso tens telegram o link ?? este
<omlet[m]>Sorry for speak in portuguese guys
<omlet[m]><madage> "sugiro criar um canal pr??prio..." <- https://t.me/guixOsPtBr
<omlet[m]><madage> "acredito que j?? h?? gente..." <- Yes, i ser in guix manual latest
<kori>what's the proper way to modify guix-service-type to include an (authorized-keys) list
<tricon>kori: one option: http://paste.debian.net/hidden/2c23d416/
<tricon>kori: another option: http://paste.debian.net/hidden/418c6db7/
<Splonk>Quick question. Can I use guix environment to run programs in a sort of jail?
<mekeor[m]>tricon: iiuc, the newlines in (plain-file "foo" "HERE") are not necessary
<mekeor[m]>Splonk: yes
<jonsger>Is it possible to do a `guix shell --file=packages.scm python-youtube-dl` including a self defined package? It fails always with unknown package. packages.scm is this: https://paste.opensuse.org/view/raw/65740640
<mekeor[m]>Splonk: guix shell --container
<Splonk>mekeor[m]: sweet! excited to try guix :)
<mekeor[m]>Splonk: consider the ungoogled-chromium example at https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-shell.html#Invoking-guix-shell
<Splonk>thx, I will have look.
<apteryx>ACTION couldn't make gdm work again on their desktop -- now on lightdm
<mekeor[m]>jonsger: hmmmm, wildly guessing: did you try "guix shell --file=foo.scm" -- i.e. without the package name?
<mekeor[m]>jonsger: ... because thats what the manual suggests
<mekeor[m]>(search for "guix shell -D -f gdb-devel.scm" in https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-shell.html#Invoking-guix-shell)
<jonsger>it says "guix shell: warning: no packages specified; creating an empty environment"
<jonsger>even when using the gdb-devel.scm example file
<jonsger>`guix shell --development --file=gdb-devel.scm python-beautifulsoup4 python-requests python` does bring automake with it, which comes from gdb-devel.scm
<jonsger>while `guix shell --development --file=packages.scm python-beautifulsoup4 python-requests python` has no sign of python-youtube-dl defined in packages.scm :(
<gnucode>does anyone here use org-mode to generate latex documents? what packages do you need to do so?
<gnucode>I've got texlive-base installed.
<gnucode>emacs is complaining that I do not have wrapfig.sty
<gnucode>looking in the help-guix one solution is just to use texlive + all the fonts that guix has available...
<gnucode>yikes.
<rekado>gnucode: if you need wrapfig why don???t you install texlive-wrapfig?
<rekado>texlive-base contains virtually nothing of use
<tribals>Hi, folks
<tribals>I broke guix shell completion somehow... Now when I type guix p<TAB>, I get `bash: _guix_commands: unbound variable`. I understand it mostly shell startup files fault, but I can't understand where to look for
<tribals>May be some ideas?
<user___>your manuallt editted .bashrc?
<user___>manually
<tribals>no, I'm trying to manage that kind of stuff with `guix home` (no so succesfully, though)
<tribals>It regenerates both `.bash_profile` and `.bashrc` each time
<tribals>But yes, I change `guix home` configuration
<tribals>*changed
<tribals>But I only changed a `(home-environment (packages ...))` field. I removed all packages - now there is no this field completely. There was "bash_completion" package in home configuration.
<tribals>Now "bash-completion" in different profile, but it lacks `export BASH_LOADABLES_PATH` - may be it is the case?
<tribals>I tried to revert everything back, but with no luck :_(
<yarl>sneek later tell gnucode I do use org mode to generate latex. What is your problem exactly?
<yarl>sneek: later tell gnucode I do use org mode to generate latex. What is your
<yarl> problem exactly?
<nckx>sneek: botsnack?
<sneek>:)
<nckx>Hm.
<civodul>has anyone looked at the LibreOffice build failure on i686? https://ci.guix.gnu.org/build/1692196/details
<civodul>i think efraim (?) mentioned looking at it before
<civodul>an obscure C++ linker error
<rekado>this looks terrible
<civodul>and the internet isn't very helpful
<civodul>because everyone has C++ link errors, not just LibreOffice
<civodul>(and nobody understands why)
<nckx>ACTION is building it with gcc@12 as a ????
<civodul>ah sure, why not
<civodul>it's weird that it's just on i686
<nckx>Yes, most similar reports *aren't* AFAICT.
<nckx>Which is why I take the claims of ???it's a compiler bug??? with salt.
<civodul>yeah that's rarely plausible
<nckx>Well, people claiming that because they're clueless (and it's easy) are indistinguishable from people claiming that because they are very clever, is the problem.
<nckx>But yes also the raw numbers say no.
<jonsger>do we have any indication if i686 is still used by users?
<nckx>rror: ???FE_TONEAREST??? was not declared in this scope; did you mean ???FP_INT_TONEAREST????
<nckx>That ended quickly, and badly.
<nckx>Ah, it was error: ???fegetround??? is not a member of ???std??? first.
<civodul>ah
<civodul>jonsger: we can tell it's used exclusively by users
<jonsger>hm, I mean apart from Hurd, bootstrapping and for libraries (mostly for non-free software) I don't see many use cases anymore.
<jonsger>when was the last i686 only CPU sold as part of a laptop, PC or a server?
<rekado>elephly.net is powered by an i686 netbook.
<rekado>not saying y???all should waste time on keeping i686 supported on my behalf
<rekado>but there are still good uses for i686 machines
<tricon>rekado: I picture a remotely controllable LEGO Mindstorms Robits kit for "terminal access".
<apteryx>is it me or the pager of 'guix search system info' misses the 1st line?
<rekado>apteryx: I can???t reproduce this
<rekado>(in gnome terminal)
<apteryx>the first line for me is: "version: 5.96.0"
<apteryx>if I move in less with j, then k, the first line is redrawn as "name: kwindowsystem"
<nckx>Nope.
<apteryx>xterm here
<nckx>(foot.)
<nckx>Not on xterm either.
<nckx>You, personally, are cursed.
<apteryx>it's caused by "Enable Auto Wraparound"
<apteryx>which is a reasonable thing to have enabled
<apteryx>nckx: eh
<rekado>I can???t seem to find the last semi-successful build of libreoffice 7.3 on i686-linux
<apteryx>very interestingly it doesn't occur when searching for another thing, e.g. 'guix search xterm'
<rekado>all the previous builds failed before even getting started with the libreoffice build
<rekado>(and many of the logs we can get from cuirass are garbled)
<nckx>apteryx: I can't reproduce it in ???xterm -aw??? either, but I'm not sure I'm testing the same thing as you.
<cbaines>rekado, that is a question you can ask of data.guix.gnu.org https://data.guix.gnu.org/repository/1/branch/master/package/libreoffice/output-history?output=out&system=i686-linux&target=none
<civodul>apteryx: i think the missed line issue can happen is the first line is too long
<civodul>which normally doesn't happen because we wrap lines, but can happen in corner cases like long package names or something
<apteryx>in this case the first line should be just "name: kwindowsystem"
<apteryx>on x200, I can visit the Control+wheel it seems in xterm to enable auto wraparound
<apteryx>is someone else using an x200?
<nckx>printf %b '\033[?7l' # should also do it.
<nckx>What's control + wheel?
<apteryx>scroll wheel click
<apteryx>or middle click
<apteryx>on the x200 there's no actual wheel, but there's a middle button acting as one
<apteryx>(acting as a wheel click)
<jonsger>ACTION found out that his first laptop (Toshiba Satellite Pro 4300) had an 32bit Pentium III processor. Sadly don't have it anymore, as some bought it because it has a floppy drive :)
<nckx>Huh. I read that ???control + middle??? should open a menu but it didn't. I thought it was some option in our xterm package. Now you're saying it depends on laptop model. Oh dear.
<nckx>apteryx: I've never had an x200 but all that sounds & looks almost identical to my x220/x230. This is going in a weird direction.
<nckx>I doubt my hardware is the issue (that it doesn't pop up a menu). I wonder if it's because I use Sway. But that aside, shouldn't ???xterm {+,-}aw??? toggle the same option? Can you try with those?
<nckx>jonsger: I still have a 32-bit laptop under my desk, but it has 256 MiB of RAM. I've read that Guix needs more!
<apteryx>nckx: yeah, I don't get it too, xev says it's the button 2 being pressed, as it should
<nckx>Same here. Sorry, I didn't mean to derail the thread. I'm perfectly happy with my laptop, and don't use xterm, so the ability to conjure an obscure menu is not an issue.
<apteryx>can't trigger it in 'xterm -aw'
<nckx>Also, "Enable Auto Wraparound" is so reasonable it's silly to have it as an option at all, and it's what every single VTE does by default, so that alone breaking less would be odd.
<nckx>apteryx: Muh.
<apteryx>running 'xterm +aw' on my desktop also makes the issue go away
<nckx>???
<apteryx>haha! you also need a special screen width
<mechalain>anyone know if the melpa version of Guix mode for emacs is working?
<nckx>apteryx: Oh! My superior 1366-px hardware does matter? ????
<nckx>apteryx: So probably font too?
<apteryx>yes! now we've captured the phase of the moon and some
<apteryx>ACTION puts the issue in the drawer
<nckx>It sounds like something for less & xterm to fight out, anyway. Even if Guix output triggers it somehow.
<podiki[m]>howdy guix peoples
<nckx>Hullo. Good night.
<apteryx>civodul: thanks for catching & fixing 83c9e00ffb!
<apteryx>I saw that one but didn't thing it was made with 'define-configuration'
<apteryx>interesting, I have a job in mcron that escapes being seen as finished by mcron (there is never any "completed in XXX s ..." message logged to /var/log/mcron.log). I wonder what is different about this job compared to others, that work expectedly.
<apteryx>the job is execl'ing the btrbk command
<podiki[m]>good night!