IRC channel logs


back to list of logs

<rekado>mbakke: you need the (guix gexp) module
<nckhexen>Poor m​bakke.
<twill>hello I was having some difficulties defining a package for Picom
<twill>ive come up with the following
<twill>(define picom
<twill> (make <service>
<twill> #:provides '(picom)
<twill> #:docstring "Excecute Picom compositor"
<twill> #:start (make-forkexec-constructor
<twill> '("picom" "")
<twill> #:log-file (string-append (getenv "HOME")
***ChanServ sets mode: +o litharge
***litharge sets mode: +q *!*@
***litharge sets mode: -o litharge
<lechner>sneek: later tell vagrantc: You listed these as justified false positives, right?
<sneek>Will do.
***ChanServ sets mode: +o litharge
***litharge sets mode: -qo *!*@ litharge
<twill>Should I be running it as a system service?
<twill>that doesn't seem right
<nckhexen>Ey, the bot worked.
<twill>What bot?
<nckhexen>twill: The one that quieted you for flooding :)
<nckhexen>Be sure to use the paste service in the channel topic for multi-line (over, say, 3 lines) messages.
<twill>nckhexen: my bad sorry, have never used IRC before and didn't mean to format my message like that
<nckhexen>No problem, it's not quite a rite of passage but it's close.
<nckhexen>The quiet is not a punishment. I wish there was a way to have litharge explain what happened, but I don't think there is.
<twill>nckhexen: For future reference how does one use the paste service? (and do you happen to know anything about user services lol)
<twill>sorry everyone! My bad
<nckhexen>twill: Just visit and fill in the textarea, submit, then share the link.
<twill>nckhexen: much appreciated
<nckhexen>Re: user services, not really, sorry. But your question might have been cut off. What we saw went from ‘here's a package … should I be running it as a system service?’.
<twill>unsure if im still muted but here is there service for picom properly formatted, it disables as soon as I run it.
<nckhexen>You're not.
<twill>ok thanks again, Im using the user shepherd and have picom run as soon as it starts however it immediately stops and disables.
<nckhexen>You should have seen messages to that effect, but their exact nature probably depends on your client and might have looked incomprehensible to the unfamiliar. Welcome to IRC.
<twill>Seems like a handy resource! I will aim to be less intrusive
<nckhexen>twill: Does your log file also contain ‘picom doesn't accept positional arguments.’?
<nckhexen>Oh. Did I say something wrong?
*nckhexen shrugs.
<nckhexen>sneek: later tell twill: Anyway, if you do return: '("picom" "") → '("picom") or it will be invoked with a single empty argument string; literally ‘picom ""’.
<sneek>Got it.
<winter>does anyone know why i'd be getting this when running `guix system image -t iso9660 gnu/system/install.scm` from the root of a guix checkout on aarch64-linux?
<nckhexen>Is this a very old guix command?
<nckhexen>(gnu system setuid) was added in July 2021. It probably postdates the (ancient) 1.3.0 release. Maybe you're still running that?
<winter>This is a clone from minutes ago.
<winter>And a Guix install from minutes ago
<nckhexen>I'm not talking about the reposotory.
<nckhexen>OK, so ancient Guix.
<winter>wait, how so? i just used the install script from master as the manual suggests
<nckhexen>Have you run ‘guix pull’?
<nckhexen>The script installs the latest release, which is 1.3.0 (luckily not for much longer). You are expected to update it regularly by running ‘guix pull’.
<nckhexen>The script does not fetch latest master.
<winter>Right, guess that was foolish of me to think that it would work like that.
<winter>What does guix pull pull then, master?
<nckhexen>Not foolish, but it's not meant to initialise a cutting-edge Guix, just to get a working installation.
<nckhexen>winter: Yep.
<winter>How would one pull latest stable, if desired, then?
<winter>(I should RTFM before asking, shouldn't I)
<nckhexen>Very roughly, is like downloading the ‘latest’ (and possibly months old) installation ISO of $better_known_distro, and ‘guix pull’ is like running apt update after installing it. :) (Yeah, in practice it probably does that for you, but work with me.)
<nckhexen>winter: …or the script could suggest that (if it doesn't yet, didn't check). RTFM is always a good idea but so is giving users relevant hints at the right time.
<nckhexen>Although on second thought the number of hints it could print is quite large, and would probably turn into a quote from the manual anyway. Hm.
<winter>question: i'm more used to nixpkgs so bear with me, i know barely any of this translates ;P but what is the guix system command doing that makes it so the functions used (in this case, setuid) aren't just inherited from the tree? if that makes sense at all. like, is guix referencing some old internal function list thing?
<winter>(that was probably a horrible explanation)
<nckhexen>Actually, didn't ‘guix system’ print this warning? That's a better time to print it, as then each user (not just root) will see it: <>
<nckhexen>Maybe it triggers only if there's a previous pull profile…
<nckhexen>winter: Yeah, I'm sorry, I'm not quite sure what you mean. What is ‘the tree’ here?
<winter>It did not, nckhexen.
<nckhexen>OK, thanks.
<nckhexen>That can be improved.
<nckhexen>#:autoload (guix describe) (current-profile-date) ; ah no of course it won't.
*nckhexen AFK a bit, but will return.
<winter>nckhexen: So what I mean is when guix system image is running, why isn't it just pulling the definition of gnu setuid from the guix tree, where it's executing everything else from?
<winter>If that makes a bit more sense.
<nckhexen>winter: It does. The short answer is: read the ‘building from Git’ chapter in the manual (sorry :) to actually build your local checkout. Then you can use ‘./pre-inst-env guix system image …’ (or maybe ‘guix system image -L . …’, but I've not actually tried that and it might asplode) to do what you want. But unless you've modified your checkout, the code in it will be identical to what you just ‘guix pull’ed.
<nckhexen>Long answer: so this is one of the ways Guix differs greatly from Nix (and most PMs): there is no ‘package repo’ distinct from the ‘package manager’ binary, like Nix's nixpkgs/nix(-env). Guix is a library that defines packages (just more Scheme code), not a parser for an external dataset. It's not quite a monolithic binary, but it's one coherent package.
<winter>I see.
<winter>(dang, this pull is taking a while... does it do a full clone?)
<nckhexen>The first time, yes.
<nckhexen>One reason it's so slow is that ‘guix pull’ doesn't just pull some data file from the Web. It fetches latest master and *builds* that, guix CLI and package definitions alike, and that new guix replaces your old guix.
<nckhexen>The fact that it's *this* slow is not good, and TODO, but it's expected to do some work, yes. There are other reasons for the first ‘guix pull’ to be even slower, but they are for your (security) benefit.
<winter>is `/gnu/store/ycsjc4a64icyscnn144lzcirya54n9n6-git.scm.drv` a copy of git, or some scheme module (i'm guessing the latter since the .scm suffix but idk)
<winter>that's one of the things it's not substituting, just curious :)
<nckhexen>winter: It's not related to the (C) ‘git’ package, it's some weird fake self-bootstrapping thing:
<nckhexen>It's explicitly marked as non-substitutable because trivial.
<nckhexen>Well, should be :)
<nckhexen>s/thing/Guile module/
<winter>currently waiting on gnutls to build, a thing i did not know existed
<winter>tests are taking a while :/
<winter>Do you know why aarch64 installer images for Guix System don't get built by CI?
<winter>presumably if packages get built for aarch64, there's some other issue that's making that not possible
<nckhexen>Last I checked, there was a huge aarch64 backlog, I don't know why (beyond known machine/connectivity troubles for the past while).
<nckhexen>Oh now what:
<winter>not even an X!
<winter>guix pull: error: You found a bug: the program '/gnu/store/049w7wqg3qap252m2n893izyxhkk9np5-compute-guix-derivation' failed to compute the derivation for Guix (version: "d520fdec3c7a11bc70ab83d0ebc6372389992d04"; system: "aarch64-linux"; host version: "1.3.0"; pull-version: 1).
<winter>i have incredible luck it seems
<nckhexen>Heh. That was literally me (but really, it's Guix known-poor handling of network errors throwing a horribly dramatic fit for what should just be a network error).
<winter>ah yeah i see issues. is down too
<winter>assuming you're restarting things?
<nckhexen>So: ci.guix was serving a 400, now ‘herd restart nginx’ on berlin is hanging, and so is sshd (or at least I can't open a second ssh connection).
<winter>(berlin being a host?)
<lechner>winter: you can use instead
<nckhexen>Well, I was, but this is not just an nginx configuration issue.
<nckhexen>winter: Yes, berlin is the main Guixzone. It hosts the Web site, ci.guix, issues, …
<winter>ah neat
<nckhexen>It's your one-stop-shop for single points of failure! 👍
<winter>maybe i'll use this downtime to start learning scheme, lol, since i have absolutely no clue what i'm doing :D
<nckhexen>I presume the Web services were working for the past few hours or someone would have complained. But can anyone confirm they used issues., ci., or www. then? (Savannah doesn't count, so neither does working).
<nckhexen>winter: I apologise for this. This is our weak spot. It is known, but knowing isn't enough…
<nckhexen>Sigh. I don't think berlin's coming back from this.
*nckhexen puts away the stick of poking; goes to get the stick of whacking.
<the_tubular>Just link something nckhexen
<the_tubular>I'll tell ya
<nckhexen>the_tubular: I don't follow…
<the_tubular>I though you wanted to know if a web service was up
<nckhexen>Yes, but during the past few ours.
<nckhexen>Now, nothing is up, I'm afraid that's a certainty.
<the_tubular>Damn, what's happening ?
<nckhexen>Probably the Shepherd being violently ill again.
<the_tubular>Yeah, I've seen an issue for a memory leak
<Andronikos>Is the Guix website for you down as well?
<nckhexen>Don't make me get out the 🚨.
<the_tubular> /motd
<chloerob[m]>kindly inbox me privately for more information
<nckhexen>OK, this is nuts. I can log in at the console (so Shepherd is not quite dead, just restin'), but it's so thoroughly confused that it's multiplexing a bash prompt and a(nother) agetty login: prompt at the same time, so the shell is useless.
<the_tubular>Yes, Andronikos there's a couple of services that are down
<Andronikos>Ah thanks.
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@2001:470:69fc:105::2:ace3
***chloerob[m] was kicked by litharge (You are banned from this channel (by nckhexen))
***litharge sets mode: -o litharge
<winter>do y'all even bother reporting Matrix bridge spam, curious
<winter>(how often does it even happen?)
<Andronikos>How can I?
<nckhexen>winter: TBH, I stopped.
<winter>yeah that seems to be a common sentiment
<winter>asahi just gave up for example
<nckhexen>Any other day, the bot would have taken care of that but I reconfigured it yesterday and still need to restore that.
<nckhexen>winter: Are you on Matrix?
<nckhexen>I assume it's less work for you. For me, ‘reporting Matrix spam’ is literally poking someone who works there, which is $work.
<nckhexen>*If so,
<Andronikos>Is it possible to create a guix package with guix shell -CF?
***ChanServ sets mode: +o nckhexen
***nckhexen changes topic to 'GNU Guix | 🚨 Some services are down again 🚨 | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckhexen
<winter>I'm not, nckhexen -- there's no [m] next to my nick ;)
<nckhexen>berlin has been hard-reset. Reboot will take ~20 minutes.
<nckhexen>winter: You can opt out of that.
<winter>I use Matrix for NixOS stuff, though, since that's our primary method of comms.
<winter>Ah, neat.
<winter>Forgot that was possible.
<winter><winter> I use Matrix for NixOS stuff, though, since that's our primary method of comms. <-- experience is iffy ime, which isn't fun :/
<lechner>Hi, my software builds manually in 'guix shell' but not in 'guix build'. Is there a way have 'guix build' operate on a local repo?
<Andronikos>Other question I had if someone knows is how I use gnome-keying within a container as of starting the service.
<nckhexen>Oh? Any other time I'd love to discuss this more, since people have been asking me about Matrix a lot recently, and Guix so far has not had any ‘official’ Matrix presence. Mind if I ping you about that some other time?
<nckhexen>winter: ☝
<nckhexen>‘We’ have a Matrix channel (distinct from the bridge), but it's more like we recently inherited it after a terrible train wreck and don't know what to do with it, than anything planned.
<winter>nckhexen: Go for it. I'd be happy to answer what I can, else, direct you to the relevant people :)
<winter>Why does the berlin reboot take so long (20 *minutes*!?), btw?
<nckhexen>100 terabytes of btrfs.
<nckhexen>The next kernel version (or so) should have a fix for exactly that. Exciting.
<nckhexen>I think the fact that we used compress-force until literally today didn't help either, since that fragments extends beyond belief.
<winter>O-oh god.
<nckhexen>Really just waiting for mount to return.
<winter>I want that much storage, damn
<nckhexen>We are very lucky.
<Andronikos>On which OS is that server running?
<nckhexen>Guix System.
<Andronikos>If not that would have triggered me.
<Andronikos>What exactly is the reason it broke? Do you may know that?
<nckhexen>I merely suspect the Shepherd crashed. I have no data (yet).
<nckhexen>It's been leaking memory, that is known, and berlin was rebooted earlier today to work around exactly that.
<nckhexen>I ran ‘herd restart nginx’ and that never returned, and then the machine stopped accepting ssh connections.
<Andronikos>Why btrfs?
<winter>so maybe it was leaking again?
<nckhexen>However, the reason I ran that was because nginx was serving 400 errors, and I have no hypothesis for why that happened (yet).
<nckhexen>winter: It is *definitely* leaking (that planned reboot was to buy time), but that should™ not have caused this.
<nckhexen>This instance will be leaking too, until the bug is found & fixed.
<winter>i assume this leaking is a new thing?
<Andronikos>How do you detected memory leaking?
<nckhexen>That's not the issue. Or shouldn't be.
<nckhexen>OK, nginx is failing because some horribly broken anonip service is, obviously I need to read todays backlog for the story on that…
<Andronikos>if the questions are stupid, I'm just asking to learn
*nckhexen …but first, coffee.
<nckhexen>Andronikos: Not stupid, busy.
<Andronikos>nckhexen: Well I just wanted to be sure. Those questions could be interpreted negatively.
<nckhexen>They were not. :)
<Andronikos>So does that error mean there is a problem with the trust store?
<Andronikos>After some reasearch people say it is because of not serving a certificate or an invalid as well as verify_depth increasing could help as well.
<sneek>Welcome back jamesw, you have 1 message!
<sneek>jamesw, rekado says: guix shell --pure gcc-toolchain glibc glibc:static -- /bin/sh -c 'ld -static -L$LIBRARY_PATH -lc'
***ChanServ sets mode: -o nckhexen
***ChanServ sets mode: +o nckhexen
***nckhexen changes topic to 'GNU Guix | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckhexen
<Andronikos>What was it?
<jamesw>rekado: seem it still can't ld to/ignore libc, the output ==>
<nckhexen>Nothing at all about Shepherd (or anything else relevant) in /var/log/messages.
<nckhexen>This is frustrating.
<jamesw>the issue is pasted here again for rereference :
<nckhexen>Andronikos: The dodgy 400 error is specific to me.
<nckhexen>But just as weird.
<nckhexen>It is supposedly ‘expired’, but is nominally valid well into 2024.
<nckhexen>I didn't debug it.
<winter>so what fixed it?
<nckhexen>Fixed what?
<nckhexen>I fixed nothing, I just restarted the server. We can now restart services again, but who knows for how long.
<nckhexen>Very frustrating.
<winter>I thought Nginx was throwing errors again?
<nckhexen>I have nothing logged to debug.
<winter>(even after the restart)
<nckhexen>winter: Yes, but only in my browser. :)
<winter>okay, unrelated question :)
<winter>why does guix-packages-base take a while to build?
<winter>presumably it's just a bunch of symlinks or something?
<nckhexen>We use client certificates to authenticate to ci.guix. That's what's failing to validate. nginx claims it is expired. It is not. I haven't checked the chain. Hell, I don't remember the chain. Firefox's broken PKCS12 export isn't helping.
<Andronikos>Is nginx more efficient as apache? Most web servers run on it and I am not sure why.
<nckhexen>It's 03:19 here, I'm going to bed. I'll write up a postmortem to the sysadmin list tomorrow, since there's nothing to say and the corpse got up & walked out of the morgue.
<winter>sleep well, nckhexen, thanks for all the help ^^
<nckhexen>Andronikos: Yeah, and (more subjective) a lot more pleasant to admin.
<Andronikos>On my location as well. Good night
<winter><winter> why does guix-packages-base take a while to build? <-- wonder why the same is happening to guix-system
<winter>taking an oddly long amount of time...
<nckhexen>Short answer: it's compiling, it's not just symlinking. And Guile compiles too slowly, and we give it too much to compile (maybe). o/
<winter>noted :-)
<winter>> To address this, Guix implements grafts, a mechanism that allows for fast deployment of critical updates without the costs associated with a whole-distribution rebuild
<winter>god that is so cool
<winter>wow i like the little changelog after guix pull
<Andronikos>First time playing with Guix?
<winter>yup, wanted to see how the other side of the valley is :)
<winter>(coming from a NixOS user/developer)
<Andronikos>Ah, what are you using currently? Had the same experience first time trying it out.
<winter>guess, given my next message ;D
<winter>I use NixOS on servers and Nix on macOS, to be more specific.
<winter>*macOS as a desktop
<Andronikos>I wanted to try out NixOS as package manager but it did not work. Stopped bothering with it.
<winter>FWIW, Nix is to NixOS what Guix is to Guix System.
<winter>*is what
<winter>define "did not work"
<Andronikos>Oh yea right.
<winter>ugh looks like i gotta build the kernel
<winter>not fun
<Andronikos>Well I reported that issue a while ago let me look at it
<winter>got a link?
<jamesw>rekado: It is worked for the 'gcc' version  !  ==> . would you kindly explain more to me? why is your command workable, but mine is failed ? and how to setup software development in guix geernally.  I am newbie of guix. many thanks
<Andronikos>That is not a good first experience. Although funny enough Guix did not work either the first time since the ISO was broken. Guess I am good at finding problems.
<winter>Might be eval memory related like bjorn said.
<winter>If you'd ever want to give it another shot/debug that if you can still repro, feel free to hop over to #nixos :-)
<winter>happy to help with that
<Andronikos>Well he never wrote back so I just deleted the VM. I could create a new one since I want to test it out as well.
<Andronikos>I heard from people that use Nix and Guix that Scheme is better to work with. You think the same?
<winter>I have never touched Scheme in my life.
<winter>It looks... weird.
<winter>But maybe that'll change
<winter>as I learn it
<winter>just need to find a good way to do so
<Andronikos>You use Emacs?
<Andronikos>Ah. This was my first encounted with Lisp. Totally weird but after some time it was just like any other language.
<winter>Yeah, it probably just takes time.
<Andronikos>Can NixOs customize the kernel?
<Andronikos>If I install a package which requires something that the kerel does not include, will it tell me?
<winter>By package, do you mean like... a kernel module? or what
<winter>I don't see how that would be possible otherwise
<winter>Maybe it does with Guix since it's tightly coupled, hrm.
<Andronikos>For example Docker requires ip forwarding. Let's say I did not activate that in the kernel would it tell me by installing Docker?
<winter>No -- packages and NixOS/the kernel are independent.
<winter>it enables ip forwarding if you enable docker
<Andronikos>Ah so it basically makes sure it works without saying anything?
<Andronikos>Ah nice thanks.
<winter>how does that work in Guix?
<winter>does it make you manually enable ip forwarding, but detects it?
<Andronikos>Well I wanted to know that either but nobody answered (kinda new to Guix as well).
<Andronikos>But on the other hand I asked the question at 3 AM so I guess I need to try it at normal times.
<winter>let me take a look at the service for docker, if one exists
<winter>doesn't look like it touches forwarding
<winter>but I don't see why it wouldn't be able to just like NixOS does
<winter>or maybe it was omitted on purpose, not sure
<Andronikos>Well Docker was just an example anyway. Probably works like NixOS but I will ask tomorrow maybe someone knows it.
<winter>well yeah it looks like you enable the docker service
<winter>and it'll install the cli and such
<Andronikos>Does Nix build from source so I need to compile everything?
<winter>no, we have substituters just like guix
<Andronikos>Well I want to try out Nix as a package manager first. 4GB memory was not enough. Will 8 be sufficient?
<winter>I've had success with much, much less.
<winter>So I'm not sure if 4gb was the issue
<winter>How much memory was free at the time, though, who knows.
<Andronikos>Stock Fedora. Gnome takes like 1GB so at least 2GB I would say.
<winter>yeah, should probably work then....
<winter>if you can repro i'd be interested in figuring out if that's the issue :)
<Andronikos>Oh thanks. Currently do not have space but in like two weeks I will play with it again.
<jamesw>rekado: why is there 2 Libary_path in guix ? ==>
<apteryx>yay, I just noticed the logging improvements have finally landed in the mcron tree
<Andronikos>winter: Was nice to chat. I am going offline. Good night.
<winter>lol, of course there's an Emacs IRC client
<winter>why can't i find `guile-static` on CI? i can find `guile-static-stripped-tarball` though 🤔
<winter>hm, successfully built /gnu/store/vpvy8qp502lziv6mpv4g71ygp5kqyxh0-guile-static-stripped-3.0.7.drv -- wonder where `guile-static-3.0.7.drv` went
<winter>or where the tarball one comes from
<winter>since it doesn't look like i built that one
<Fare>Hi. Is there a tutorial for doing most of the guix installation over sshfs ?
<Fare>I managed to boot this computer with a grml usb stick and start ssh on it. I already have guix installed on a server with all the packages I want. Can I do most of the installation from the server using sshfs, then finish with a chroot command on the new machine after all the gnu store was populated?
<Fare>I suppose guix copy --to newmachine can help with the copy part.
*Fare uses guix pull ; guix system build newmachine.scm
<winter>so i built an ISO for aarch64-linux, GRUB loads, and... it says "invalid magic number" and then "must load kernel first"
<winter>after searching around, this seems to be due to corruption, but i verified that the image was transferred correctly from my vm
<winter>should i try rebuilding the ISO with --check (maybe rebuild everything...?), or is it more likely that something else is going on here?
<winter>how would i even debug this?
<Fare>winter: problem with GRUB installation or configuration?
<Fare>do you get a grub prompt?
<Fare>(which device is it?)
<winter>Fare: this is the installation ISO -- I get the GRUB splash, it reads the configuration/splash image, and then shows that
<winter>I can read the store contents successfully from the GRUB console, so that's not an issue either
<winter>so something is... wrong
<winter>just don't know how to figure out what's up, or why it happened
<Fare>which device is it? some UEFI firmware are particular and don't like ISO boot.
<winter>I don't think it would be UEFI here, Fare, since GRUB loads successfully.
<winter>It's a QEMU VM, and I'm not using the qcow2 option since that wants to compile a special gcc build for whatever reason.
<winter>This config has worked fine for other ISOs, like NixOS' and Debian's.
<Fare>then a matter of naming the devices? I had a case that an ISO image could load the kernel but then the kernel wouldn't find the boot device
<winter>what devices are there to name, though? this is an iso -- everything's in memory. plus, i confirmed that GRUB can see everything in the store
<winter>so that's most likely not the issue
<Fare>invalid magic number... (cross)compiled for the wrong architecture?
<winter>This isn't cross, but... I should probably make sure it's not trying to compile for x86_64 or something.
<winter>I know it isn't
<winter>(The derivation is for aarch64-linux, as expected.)
<winter>i do wonder if something like that happened, though, but i have no idea why it would
<winter>(since i didn't pass any --system option and the default behavior is to compile for current platform)
<winter>so... not sure what to do here. if i could find the file GRUB is complaining about that would be helpful, maybe it has debug logs or something
<Fare>can you mount the iso and inspect the kernel file on it?
<Fare>in other news... I see there's an incomplete port of gutenprint for guix. What's the right approach to getting it to work?
<unmatched-paren>winter, Andronikos: it is possible to load kernel modules with services
<unmatched-paren>(morning guix!
<abrenon>hello guix !!
<unmatched-paren>abrenon: hi!
<abrenon>what's up ?
***Dynom_ is now known as Guest5986
<jeko>Yooo Guixters !
<abrenon>hey o/
***wielaard is now known as mjw
<kraai>Hi. Is there a way to embed the operating-system definition file in an image created with `guix system image`?
<kraai>For example, if I run `guix system image --image-type=qcow2 config.scm`, is there a way to make `config.scm` be part of the image as `/etc/config.scm`?
<abrenon>kraai no pre-existant feature to do so that I know of
<abrenon>that said, I think nothing is stopping you from packaging your config.scm for guix (a simple copy-build-system perhaps) and including this package in the generated system
<abrenon>I'm not sure there's a way to make it appear in /etc/config.scm, but I suppose a path such as …/share/guix/config.scm would be acceptable too ?
<kraai>Yes, that would be OK.
<abrenon>great ! I'd be curious to know if you manage to make it appear in /etc, I haven't tried that so far
<kraai>abrenon: I'll try to let you know if I get something to work.
<abrenon>trying to compile a demo maven project from within a (networked, containered) guix shell
<abrenon>not working great so far
<abrenon>any known caveat for compiling maven projects ?
<gabber>wpa-supplicant-configuration has a "config-file" field which expects a file-like object. do i pass a string (representing the path to a file) there? do i pass a (local-file)? do i have to gexp/ungexp some part of that config? i've tried several combinations but don't seem to get it right.
<examors>gabber: local-file should work - that is a file-like object. plain-file should also work if you want to use a string literal rather than an external file
<gabber>so i have something like (local-file "./foo.conf") where foo.conf is in the same directory than the system-config i'm reconfiguring my system with? or do i need absolute paths?
<sash-kan>hi all! is this a bug? if so, in which command - time-machine or repl?
<examors>The local-file path will be relative to the source file it's in, when it's a literal string
<examors>There is some documentation on
<gabber>examors: thanks!
<qzdlns[m]>howdy guix
<sash-kan>hi all! repl launched inside time-machine does not see the channel modules: . is this a bug? if so, in which command - time-machine or repl?
<yarl>Hello guix!
<yarl>I installed guix system. I created a home environment according to the manual.
<yarl>The problem is that now, when I login, I got this message :
<yarl>warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script
<yarl>won't execute anything. You can check if xdg runtime directory exists,
<yarl>XDG_RUNTIME_DIR variable is set to appropriate value and manually execute the
<yarl>script by running '$HOME/.guix-home/on-first-login'
<yarl>I read the note in the manual saying " Make sure the operating system has elogind, systemd, or a
<yarl> similar mechanism to create the XDG run-time directory and has the
<yarl> ‘XDG_RUNTIME_DIR’ variable set. Failing that, the ‘on-first-login’
<yarl> script will not execute anything, and processes like user Shepherd
<yarl> and its descendants will not start.
***ChanServ sets mode: +o litharge
***litharge sets mode: +q $a:yarl
***litharge sets mode: -o litharge
<examors>yarl: Does your operating-system configuration contain %desktop-services or (elogind-service) at all?
***ChanServ sets mode: +o litharge
***litharge sets mode: -qo $a:yarl litharge
<yarl>Was I muted?
<examors>I think so. It's considered impolite to paste multiple lines into IRC
<examors>better to use a pastebin service. There's one linked in the channel topic
<yarl>Right, sorry about that.
<yarl>I said : no (%desktop-services or (elogind-service))! Is that because I installed without desktop environment? (Installation from the downloadable installation image)
<examors>No problem :) Ah, yes, that's probably it. Try adding (elogind-service) to the services list and then `guix system reconfigure`
<yarl>examors: Thank you for your help. I am reading about %desktop-services and elogind-service.
<yarl>examors: all right.
<examors>Yeah, you may not want to use %desktop-services if you're after a more minimal system, but there are a few services you may want to take from it
<yarl>examors: hmm I don't see how to add it. I tried "(service elogind-service)" "(elogind-service)".
<yarl>guix system reconfigure fails
<gnucode>morning guix!
<examors>yarl: what does the "(services ...)" field of the operating-system record look like?
<gnucode>yarl: I personally got tired of trying to use gnome on guix system. Updating the system takes a LONG time. (in my opinion). I prefer to have a very minimal config. I just use sway.
<yarl>gnucode: I want no desktop at all.
<tricon>yarl: how about no colors either.
<yarl>tricon: ?
<tricon>just a black and white console.
<yarl>I want to use this computer as a server.
<yarl> (append
<yarl> (list (service openssh-service-type
<yarl> (openssh-configuration
<yarl> (password-authentication? #f)))
<yarl> (service dhcp-client-service-type))
<yarl> %base-services))
***ChanServ sets mode: +o litharge
***litharge sets mode: +q $a:yarl
***litharge sets mode: -o litharge
<examors>yarl: ok, try changing it to something like You may also need to add 'desktop' to (use-service-modules) at the top of the file.
***ChanServ sets mode: +o litharge
***litharge sets mode: -qo $a:yarl litharge
<Korven[m]>Hello! This is just an introduction message. I am Korven (was here once before), and I'm giving Guix another shot now that I know more about Scheme and Guix substitutes and mirrors. Nice to meet you all!
<nckhexen>Welcome back :)
<gnucode>Korven[m]: welcome! guix is sooo much fun to play with! It's probably been the most stable distro, that I've ever used. Glad to have you on the playground!
<Korven[m]>Well I'm still pretty much what you'd consider a newbie, just trying to make my way around. My first order of business is definitely finding the right substitutes, so I can get some semblence of speed
<gnucode>Korven[m]: I'll send you a link to my config in just a second...I use a very minimal sway configuration, so that my updates are normally pretty quick.
<gnucode>and my config has some substitute servers defined. :)
<Korven[m]>A very welcome surprise
<Korven[m]>Although I'm using it on a foreign distro for now, my main goal is to learn how to configure my home environment, and development shell using Guix and Guix Home
<Korven[m]>once that happens, I'd be much more confident in making the leap to Guix itself as my distro
<gnucode>Korven[m]: I personally do NOT use guix home. :) I probably should try. :)
<Korven[m]>self hosted?
<gnucode>I am just so used to having a .git of my ~/ .
<gnucode>I use guix system. have for years. :)
<Korven[m]>i hope i'll be able to tell people that one day
<gnucode>Korven[m]: Finding proper hardware that will work well with guix system can be tricky. I'm a RFY kind of guy, so I've got a os-booted thinkpad. There are some open newer RYF hardware that you can buy, but I either seen options that are too expensive, or not powerful enough. At least for me.
<Korven[m]>Everything electronic is exppensive in my country so
<gnucode>Korven[m] sorry bro. :(
<apteryx>hmm, some systemd-related warning from udisks: udisks-WARNING **: 08:16:46.114: Failed to setup systemd-based mount point cleanup: Failed to execute child process ?systemd-escape? (No such file or directory)
<apteryx>abrenon: yes, there's no CLASSPATH automatically defined for one thing, so it won't find any deps
<Korven[m]><gnucode> "Korven sorry bro. :(" <- why XD it's not your fault
<Korven[m]>So I did a `guix pull` and got this. Anyone familiar?... (full message at <>)
<Korven[m]> * So I did a `guix pull` and got this. Anyone familiar?... (full message at <>)
<Korven[m]>oh it's an older commit that what I'm currently at
<Kabouik>Anyone using ESS (emacs speaks statistics) with R on Guix?
<Kabouik>Whenever I try to start the R process in an ESS window with M-x R RET, the ESS prompt to confirm the working directory converts accented characters to escaped characters, and I can't confirm with RET unless I change that back to accented characters. I have tried some things advised in #emacs but I feel there may be peculiarities related to emacs itself. $LANG is set to en_GB.utf8, $LC_ALL is not set.
<Kabouik>If I try the emacs daemon with LC_ALL="C.UTF-8" and ignore my .emacs file, then this issue in the prompt is fixed, but I can't see what in my config may cause the problem. And also R throws a warning about the set C.UTF-8 when started this way (and uses just "C").
<Kabouik>I'm feeling it should not be necessary to start the emacs daemon with a prefix env variable anyway, so there may be something guix-specific that I did not set up correctly.
<Korven[m]>What's the difference between `guix package --install` and `guix install`? is the latter just an alias of the former
<tricon>Korven[m]: yes.
<Korven[m]>fair. I installed some fonts using guix but can't seem to get them to show up in `fc-list`. This is on a foreign distro
<Kabouik>fc-cache -fv maybe?
<Korven[m]>nope, doesn't seem to list the directory guix stores fonts in
<examors>Does the $XDG_DATA_DIRS environment variable include it?
<Korven[m]>uh nope
<xd1le>Korvarx[m], might need to add the directory to the fontconfig fonts.conf
<Korven[m]>hm, should I just create the file myself
<xd1le>I think so
<xd1le>well you could use guix home I guess
<xd1le>Korvarx[m], at $XDG_CONFIG_HOME/fontconfig/fonts.conf
<Korven[m]>lmao fixed it
<xd1le>I'm not aware how to get fontconfig to see it without this though
<xd1le>oh nice, how?
<Korven[m]>apparently my .bash_profile was not in effect
<Korven[m]>I have not logged out and in since then
<xd1le>alright cool
<Korven[m]>i should do that
<abrenon>apteryx: thanks ! I hoped maven would be the one handling the classpath : (
<abrenon>I have no idea what I should put in there
<AleQu[m]>Is nautilus broken for anyone else on current GuixSD ? Here it's segfaulting as I open it.
<AleQu[m]>Ok I found this...
<nckhexen>Is that what you're seeing? Launches fine here, but I don't use it nor GNOME and the bug seems to be in the Desktop Integration, not the file manager.
<nckhexen>Why is powerpc64le-linux disabled on CI master?
<AleQu[m]>nckhexen: yeah, that's exactly what I'm seeing.
<nckhexen>AleQu[m]: Does the work-around work, at least?
<nckhexen>apteryx: <Why is powerpc64le-linux disabled on CI master?> Any idea?
<AleQu[m]>Yeah it does, and then I can see the tracker migration message also discussed in the thread.
<jonsger>nckhexen: maybe ?
<nckhexen>Hm, that should probably be reverted too, but I don't think that's it. Thanks though!
<apteryx>abrenon: export CLASSPATH=$GUIX_ENVIRONMENT/lib/m2:$GUIX_ENVIRONMENT/share/java should do it for now
<apteryx>I have a patch for search paths I could share otherwise, but it entails rebuilding a bunch of stuff
<apteryx>nckhexen: I'm not sure; I think the offloading setup was wrong and caused the guix manifest to fail due to lack of powerpc offloading machines
<apteryx>I seem to recall Mathieu fixed the offloading, so we could probably resume building for powerpc64le
<abrenon>ok I'll try it
<nckhexen>But that was over a week ago. powerpc64le-linux, at least for master, was enabled after that.
<apteryx>then I'm clueless
<apteryx>mothacehe: any idea? ^
<nckhexen>It's not like powerpc64le building was broken, so so am I.
<abrenon>doesn't work, still the same message : )
<Korven[m]>Okay so, the fonts are found by `fontconfig`, but when I try to set them in `gnome-tweaks` in my host distro, it can't find them
<abrenon>I wonder what it means by 'module java.base does not "opens java.lang"' ?!
<nckhexen>apteryx: Ah, you recently reconfigured. Maybe that reset something.
<winter><winter> so i built an ISO for aarch64-linux, GRUB loads, and... it says "invalid magic number" and then "must load kernel first" <-- going to debug more later, but does anyone happen to have an idea as to what would cause this? to clarify: this wasn't cross, and GRUB can see the contents of the store on the ISO just fine
<apteryx>nckhexen: rebooted, even
<apteryx>abrenon: hmm. perhaps have a peek into the maven-build-system for clues
<mothacehe>apteryx: yeah the commit pointed out by jonsger introduces a guix-other-arch specification so that the guix specification doesn't fail when aarch64/powerpc guix evaluation fail. As a side effect, the powerpc architecture is removed from the master specification. I think we can restore it.
<nckhexen>apteryx: So did I last night.
<nckhexen>mothacehe: Please do.
<nckhexen>(Or I will, just not right now :)
<winter>the kernel definitely built just fine, so not really sure what could be going on... or how to debug it
<nckhexen>It would be a pity to fall behind on ppc64le again.
<nckhexen>Good to know that changes made via the Web UI are not persisted.
<mothacehe>nckhexen: yes the specifications declared in the configuration are always overriding the web edited ones
<nckhexen>I'll add a warning to the edit page if that's OK with you.
<dsmith-work>Howdy #guix. Yesterday about 11:25 Eastern, the bot had an exception. Anyone have a logs from about that time? Did anyone interact with the bot?
<dsmith-work>The actual backtrace is useless.
<nckhexen>There's (which also logs #guile).
<nckhexen>I have unprocessed logs if you need more.
<dsmith-work>Yes, but no timestamps.
<nckhexen>I'll send mine.
<dsmith-work>Also not JOIN/PART
<dsmith-work>nckhexen: tack
<Sariboo>dsmith-work: 11:25 am or pm?
<mothacehe>nckhexen: apteryx: powerpc support for master restored with: d2f3da8
<nckhexen>Thank you!
<mothacehe>someone needs to reconfigure berlin soon :) ?
<nckhexen>I was just about to do so, I'll fold it in.
<Sariboo>dsmith-work: this is all I have ^^
<nckhexen>I've already sent complete logs.
<Sariboo>(Time is CDT)
<nckhexen>apteryx: mothacehe Sanity check: none of you can log into the Cuirass Web UI, right?
<nckhexen>(You shouldn't be able to!)
<mothacehe>I have a 400 Bad Request atm
<nckhexen>I've asked Ricardo for the ancient keys.
<apteryx>same as mothacehe
<nckhexen>That's good, expiration being honoured.
<nckhexen>The 2019 CA cert expired yesterday.
<nckhexen>That's why I rebooted berlin: ‘sudo herd restart nginx’ froze and the machine stopped responding and accepting new SSH connections. Had to hard-reset. Unfortunately, AFAICT, nothing was logged.
<nckhexen>It's in the IRC logs if anyone cares, but I don't really have anything useful to share with sysadmin@.
<nckhexen>But if anyone noticed: ‘you found a bug’ reports rolling in is still a reliable indicator of berlin being down for half an hour :-/
<abrenon>yeah, I was starting to wonder if packaging the repos with this build-sstem wouldn't be easier than trying to make it work from the command line but I still lack experience with it so ^^
<abrenon>trying my best, anyway
<apteryx>is anyone could at deciphering what this is trying to tell me? (guile backtrace):
***Dynom_ is now known as Guest7629
<dsmith-work>Did anyone leave a "later tell" message for fredg ?
<nckhexen>Wouldn't that be logged? I thought PM ‘later tell’s weren't supported any more. Or at least, they stopped working for me, at one point.
<nckhexen>This assuming they ever did, but I'm pretty sure I didn't imagine it
<dsmith-work>sneek: later tell dsmith Did it work?
<sneek>Will do.
<sneek>Welcome back dsmith, you have 1 message!
<sneek>dsmith, dsmith-work says: Did it work?
<dsmith-work>sneek: later tell fredg Just testing the bot
<nckhexen>Little Freddie Tables strikes again.
<Sariboo>sneek: botsnack
<Kabouik>Any idea why `LC_ALL="en_GB.utf8" emacs` works fine when not connected to a daemon, but `LC_ALL="en_GB.utf8" emacs --bg-daemon` then `emacsclient -c` (or even `LC_ALL="en_GB.utf8" emacsclient -c`) would break accents in prefilled paths in prompts (I have just observed that in the ESS prompt to chose working directory when starting a R process, the prefilled path is broken if it contains accents)?
<Kabouik>I have discussed in #emacs but it is not clear yet if the issue is Guix-related or not. In my Guix config, the locale is set with (operating-system (locale "en_GB.utf8")).
<Kabouik>I only get this issue with daemon/client.
<nckhexen>Do you get it only when forcing LC_ALL like that? (I use en_IE.utf8 system wide and can't reproduce that.)
<Kabouik>No, I started trying to force LC_ALL because I got the issue before prefixing the env var. Actually I should try again with no daemon, see if the issue exists in a non-client emacs and no env var
<nckhexen>(That is, by opening ‘Héllø Señor’ and then reopening the CxCf prompt. I assume that's what you mean by ‘pre-filled’.)
<nckhexen>After learning that sneek's feeding status is kept only in RAM, not saved, these recent ‘crashes’ are clearly just a ploy to score fresh botsnacks.
<Kabouik>I'm lost, I can no longer reproduce the behaviour whereby it would work with a non-client emacs now, with or without the prefix var; meaning it's not working for both daemon mode or single instance mode now.
<Kabouik>nckhexen when you edit a R script with ESS, and hit M-x R RET, it starts a R process in a new emacs window, and offers to set the working dear for that R session. It prefills the path with the path of the R script you're editing in ESS. If that paths contains accents, they're replaced with some escape codes (and I can't hit RET to confirm the path, I have to remove the escape chars and place accented characters where they belong).
<Kabouik>That's what I meant with pre-filled.
<Kabouik>s/working dear/working dir. Leave the poor dear alone.
<nckhexen>Right… that's just a lot of totally alien stuff for me to install/test, so I was hoping to avoid it.
<Kabouik>There are probably ways to reproduce that elsewhere I'm sure, but ESS is the only mode where I observed that issue so far
*nckhexen away.
<Kabouik>I don't get the same issue when opening a file with accents in its path, and then doing CxCf. There the accents are not touched.
<Andronikos>If I customize my kernel and do not have for example IP forwarding activated which is required for Docker. Will Guix tell me that upon installing Docker?
<nckhexen>Kabouik: Is there a persistent R repl(?) process that keeps running, that might explain why your experiments aren't consistent between emacs restarts? (One would expect it to be killed, but who knows. I don't.)
<nckhexen>Andronikos: No.
<Kabouik>I think the R repl gets killed when I close emacs and make sure there's no daemon still running, and i couldn't find R in the running processes after killing emacs.
<nckhexen>That's what I'd expect. I'm just confused by the reported inconsistency.
<Kabouik>This may very well be an emacs-ess issue, but this could also be a Guix issue, and I'm still investigating to find which IRC channel I should pollute (well, as you might have observed, I started polluting both just in case D:).
<nckhexen>Good move.
<Kabouik>By "issue", I mean it could also be something I just failed to set up correctly.
<Kabouik>See, that's what happens on M-x R RET: (and you can see accents working just fine in the buffer, I can also type accents in the prompt (and I need to replace those blue escape sequences by accents, actually, or I can't confirm the path)).
<Kabouik>Ha! If I `emacs /path/to/file/with/accents` and then M-X R RET, no accent issue in the prefilled path when starting R. If I `emacs` then `counsel-buffer-or-recentf`, the accents are borked. Pretty sure the issue is related to how counsel stores the list of recent files (or any other package doing that). Now at least I know a little bit better where to look. That might explain the inconsistency reported above too, nckhexen.
***piyo` is now known as piyo
<lechner>sneek: botsnack
<Korven[m]>anyone know how to setup zsh with guix?
<gnucode>Korven[m]: just use fish. It just works. tm
<Korven[m]>XD bruh
<Korven[m]>Actually this might be a good opportunity to try fish
<nckhexen>Berlin /admin interface access restored.
<Korven[m]><gnucode> "Korven: just use fish. It..." <- I have fish installed, but how do I make it the default shell?
<Korven[m]>okay done, sorry for the unnecessary ping
<nckhexen>That was suspiciously fast and painless… ^_o
<Korven[m]>I manually added the path to fish in my guix profile to the login shell list
<piethesailor>Hello All! Anyone using guix as a package manager on the Librem 5?
<jonsger>nope, not yet :)
<gnucode>Korven[m]: I have a keybinding set up in sway...
<gnucode>that calls "lxterminal -e fish"
<gnucode>that's how I do it.
<Andronikos>How can I run gnome-keyring inside guix shell -FC? If I do something like "guix shell [..] -- dbus-update-activation-environment --all gnome-keyring-daemon --start --components=secrets <program-to-run" dbus yells at me with "dbus-update-activation-environment: error: --all cannot be used with VAR or VAR=VAL arguments".
<Korven[m]>does Guix have nerd-fonts packages?
<Andronikos>But they are easy to install yourself
<jonsger>piethesailor: apart from chatty there are few Librem5/Phosh packages in guix. But some of them lay unmerged somewhere in our bug tracker...
<Andronikos>Korven[m]: I can help you out with that if you need it.
<Korven[m]>Andronikos: Sure, that'd be very appreciated!
<piethesailor>jongser: is there a list of these packages somewhere? My big issue right now is that I am getting a fail message with loading nyxt.
<piethesailor>installing nyxt*
<jonsger> and
<jonsger>can you paste the error message to something like ?#
<piethesailor>One moment
<piethesailor>For now all I can say is the install fails when trying to build /gnu/store/xxxxxxxxxxxxxinkscape.drv. I think it says failed to connect to socket
<piethesailor>Trying to reproduce atm
<piethesailor>Once I get to that point I will post the actual messate
<jonsger>ps aux | grep guix returns what?
<piethesailor>The Librem 5 isnt the Once the error hits, I'll post results and then give the above a try
<Andronikos>My guix shell command is large with all its arguments. Can I place them in the manifest to just call guix shell?
<unmatched-paren>Andronikos: yes, use (specifications->manifest (list "PKG" ...))
<unmatched-paren>and then run guix shell -m manifest.scm
<piethesailor>jonsger, you posted two urls that are the same. is there a second guix thread on the librem 5?\
<Andronikos>unmatched-paren: Oh I meant not packages but --share and --preserve arguments.
<jonsger>piethesailor: sorry, Firefox is bad in marking URLs with middle mouse click :(
<unmatched-paren>Andronikos: Ah. No, you can't, afaik. That would be a nice feature though.
<lechner>Hi, does the Guile's autoconf macro GUILE_SITE_DIR work in Guix? I think it points to the Guild's site directories instead of the "installable" site directories below --prefix, i.e related to my package's output. Is there a better way to determine the directories for installation?
<lechner>sorry about the extra "the"
<Andronikos>unmatched-paren: Alright thanks. Yes it would be a nice feature.
<Korven[m]>anyone using starship on Guix? Do you just build it manually?
<lilyp>lechner: there are various, e.g. or
<lilyp>Korven[m]: starship?
<lechner>lilyp: thanks! is the current setting via pkg-config useful in Guix? I think it should relate to --prefix instead;a=blob;f=meta/guile.m4;h=48642f027f7b002d40658511fe3bb831e83ebdfc;hb=HEAD#l183
<lechner>our configure's --prefix, that is
<Korven[m]>lilyp: aye, it's a prompt for shells
<lechner>lilyp: Could we avoid the confusion if we did not hardcode 'prefix' into the other paths in the pkg-config files we ship. We could then use the pkg-config option --define-variable=prefix=[configure-prefix] to derive the target directories when needed.
<nckhexen>That would be ideal.
***mark_ is now known as mjw
<vagrantc>guix refresh --list-dependents guile-ssh ... outputs guix-daemon@ amoung the outputs that need to be rebuilt ... but "guix build guix-daemon" complains that guix-daemon does not exist
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, lechner says: You listed these as justified false positives, right?
<vagrantc>lechner: yes, i did ... it's a lint checker checking for the same typos, so of course it'll embed the typo it is checking for
<vagrantc>don't have the remaining inscrutible typos, but dealt with the vast majority so ... :)
<lechner>vagrantc: just trying to help, since i once rewrote the check that is now bugging you
<vagrantc>lechner: i suspected that :)
<vagrantc>seems like it does something like This.*packages
<vagrantc>i think i found at least one more false positive that is triggered by it ... e.g. |This something something something search for packages"
<lechner>vagrantc: Last time I checked Lintian parsed the output of 'strings'. Is it looking at *.go for guile modules?
<tribals>Hi, folks!
<vagrantc>e.g. nckhexen found "This EMACS packages" which seems like a positive
<tribals>I'm wondering how to make `guix publish` to listen on all interfaces including ipv6 ones?
<vagrantc>lechner: yeah, it's finding them in all the guile modules ... i've fixed probably over a hundred typos in guix so far that seemed legit, so it's been useful ... 3-5 false positives are no big deal
<tribals>Does mean all interfaces including ipv6 ones?
<piethesailor>Okay.., jonsger: I am simply getting: /gnu/store/xxxxxxxxxxxxx-inkscape-1.1.1.drv 49%[####### ] guix install:error corrupt input while restoring archive from socket
<lechner>tribals: generally speaking i don't think so, but i have the same question for the guix-publish-service-type
<tribals>mine is: tcp LISTEN 0 128* users:(("guix publish",pid=15093,fd=14))
<tribals>That's from `ss`
<tribals>AFAIK, this doesn't mean ipv6
<vagrantc>so... is there some way i can get: guix build --keep-going PKG1 PKG2 ... PKGN ... to report the successes and failures? it seems to end with the last buidl that failed, and builds that suceeded end up lost in scollback
<tribals>lecher: another question is: does `guix publish` support multiple `--listen` option to work-around this?
<lechner>vagrantc: how about This LaTeX packages in texlive-latex-atveryend ?
<euouae>I used the install script but ^C'd it and now if I run it again I get that a guix installation is already found
<tribals>I dont' want to loose it listening on ipv4
<euouae>How can I uninstall guix and re-install it?
<vagrantc>i end up iterating through all the build failures and removing them and trying again, and eventually it produces a list of successful builds, and then i know which failed by which i'm excluding
<tribals>euouae: `rm -r .config/guix`
<tribals>euouae: `rm -r ~/.config/guix`
<euouae>tribals, thank you
<lechner>tribals: I am not sure I care so much about IPv4, but I am super thrilled that it's working!
<vagrantc>lechner: oooh, that looks promsing
<tribals>lechner: it worked, but I (you too, I suppose) need to keep iface IPv6 in config, which is fragile
<tribals>I'll investigate the possibility to add listening on ipv6 to in "all interfaces" mode
<nckhexen>So ‘::’ doesn't work?
<vagrantc>i know it may seem simple to someone competent in guile, but would be nice to update guix lint to detect 'This WORD packages' ... :)
<vagrantc>or maybe regex or globbing or something
<vagrantc>seems to be one more case, though
<nckhexen>tribals, lechner: ☝
<lechner>vagrantc: there is also "This module packages" in perl-moosex-types-datetime
<tribals>nckhexen: I'm trying...
<vagrantc>lechner: good eye.
<vagrantc>not to be confused with 'This modules'
<nckhexen>‘’ is not ‘all interfaces mode’. It should not listen on IPv6.
<lechner>vagrantc: i hunted a lot of those when responding to bug reports guix package --search="This [^ ]* packages"
<nckhexen>lechner: And this is why verbing nouns weirds language.
<vagrantc>lechner: oh, i think This module packages in that case is actually a correct use
<euouae>I'm trying to uninstall guix, so that I can reinstall it. Deleted /root/.config/guix, but I still cannot -- guix installation is detected by the installation scirprt
<vagrantc>gnu/packages/perl.scm: (description "This module packages several Moose::Util::TypeConstraints
<vagrantc>that looks legit
<nckhexen>Is that all you deleted, euouae? That's just a tiny part. Also remove (at least) /gnu and /var/guix.
<lechner>vagrantc: it may be but still seems it could be redundant
<euouae>nckhexen: I can't remove /gnu because there's a lot of read-only filesystems there
<euouae>e.g. rm: cannot remove '/gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2/share/terminfo/z/z-100': Read-only file system
<lechner>rm -f
<nckhexen>sudo umount /gnu/store && sudo rm -rf /gnu
<nckhexen>euouae: ☝
<euouae>-rf doesn't work, same error
<euouae>oh the store
<euouae>Ah neat. What filesystem is the store?
<nckhexen>It is bind-mounted read-only by default. Sounds like you got pretty far into the installation :-/
<nckhexen>It's not a separate file system type.
<vagrantc>lechner: FWIW you can also: guix search "This [^ ]* packages"
<euouae>nckhexen: I did! I answered an option wrong
<vagrantc>i've mostly been using 'git grep' though
<nckhexen>euouae: Which one?
<euouae>I thnk the first one
<tribals>nckhexen: it works
<nckhexen>…oh. euouae: That's odd, you shouldn't have had a read-only store that early? I'm not looking at the script right now, but that's a very late step.
<euouae>"Permit downloading pre-built package binaries from the project's build farm? [Y/n]" <-- I answered as n
<lechner>tribals: "::" works?
<nckhexen>Ah. I'm not sure that's ‘early’ in the execution, I'll have to check.
<euouae>I realized later I didn't want that option nckhexen
<euouae>I might have to log out now, brb
<nckhexen>‘::’ should work for both IPv4 and IPv6 in practice, although strictly speaking it's a (kernel) option.
<tribals>lechner: yes
<lechner>tribals: listening on both?
<nckhexen>Anyway, glad to hear it works. Wanna add it to the manual? ☺
<tribals>lechner: Yes, but I don't understand why.
<lechner>nckhexen: why do you call it a kernel option?
<lechner>tribals: woohoo!
<nckhexen>lechner: Because it is?
<nckhexen>You can enable that, and ‘::’ will no longer be magic.
<tribals>Another question is: I noticed I need to `herd restart` some (all?) services after `guix system reconfigure`. Is this supposed to be this way?
<nckhexen>(‘::’ is to IPv6 what ‘’ is to IPv4, nothing magic. What's magic is Linux defaults to ‘dual stack’ mode, meaning that binding to ‘::’ will automatically bind to ‘’ as well—assuming you don't enable the above option.)
<nckhexen>tribals: Some services can't be safely restarted. Whether the ones you need to restart all fall under that category, or are just TODO, who can say.
<tribals>nckhexen: thanks
*nckhexen tips hat.
<tribals>(should be that)
<mbkamble>Hi. I am lost trying to achieve the following: I want to create a link to in /lib64. exists in lib output of gcc (/gnu/store/blah-gcc-10.3.0-lib/lib/
<mbkamble>I have written this in my system.scm file:
<mbkamble>(services (list (service openssh-service-type) ... (extra-special-file "/lib64/" (file-append gcc "/lib/"))))
<mbkamble>this results in a dangling link because file-append resolves to "out" output for gcc. If I give (file-append gcc:lib "foo"), it gives undefined variable errorn for "gcc:lib"
<mbkamble>I raised this help request yesterday, but had to leave the chat midway, and did not get a solution
<tribals>Another question is: I rolled system back to previous configuration. I can verify config for desired service is updated. But changes did not reflected in herd service at all - it still uses old one. The service I'm configuring is Yggdrasil, to be concrete.
<tribals>May be there is `herd reload` or something similar?
<nckhexen>There is, but support for it is ad hoc and incomplete (that's what my ‘TODO’ above was referring to).
<Andronikos> gives a 504 on my end.
<nckhexen>tribals: But ‘restart’ should *always* imply reloading the configuration you just reconfigured. Otherwise: bug.
<nckhexen>Andronikos: I can't reproduce it so it was probably a fluke, but thanks!
<Andronikos>I get cannot open shared object file: No such file or directory on using vulkaninfo. I have seen some tickets about this. Do I just need till is closed?
<tribals>nckhexen: I've restarted yggdrasil service after switching generation a couple of times already. Changes didn't reflected
<Andronikos>nckhexen: I tried reloading it a couple of times and now it works for me again too. Weird.
<nckhexen>tribals: I don't use or know yggdrasil, but high level, that sounds like a bug. *If* you're certain that the changes were applied.
<nckhexen>Andronikos: Yeah, I didn't mean it's not a problem, and in an ideal world someone would investigate and fix it, but…
<mbkamble>In a guix repl, I exprimented with:
<mbkamble>scheme@(guix-user)> #~(string-append #$gcc:lib "foo")  which prints
<mbkamble>$8 = #<gexp (string-append #<gexp-input #<package gcc@10.3.0 gnu/packages/gcc.scm:659 7fa85c391790>:lib> "fss") 7fa859c264b0>
<mbkamble>so, it seems the output can be specified with string-append, but I don't know how to use that to create the symlink
<nckhexen>Andronikos: That was about the 50x. About mesa: if the only way to fix that is to update mesa, then you'll have to wait for <> to be applied *and* for the core-updates branch to be merged into master.
<tribals>nckhexen: will continue exercises later and report
<tribals>now I'm leaving... ^_^
<nckhexen>mbkamble: Try something like #~(string-append #$gcc:lib "/lib64/…") ; an educated guess, but still a guess.
<nckhexen>This is not something you're supposed to know; it's a limitation of file-append in its current form.
<Andronikos>nckhexen: Thanks. Can I apply those changes locally?
<nckhexen>Andronikos: I can't say without trying myself, so you might as well try yourself :)
<nckhexen>I don't know anything about Vulkan (does my laptop even support it? I don't even know that), or I'd review the patch…
<mbkamble>nckhexen: how do I integrate (ie invoke) the procedure in the system.scm code?
<mbkamble>I don't think this works: (services (list (service openssh-service-type) ... (extra-special-file "/lib64/" #~(string-append #$gcc:lib "/lib/"))))
<Andronikos>Okay thanks. I guess I need to wait to find out if this is the core problem that made so much trouble for me.
<nckhexen>mbkamble: What error do you get?
<vagrantc>is there a way to get "guix refresh --list-dependent" to output all of the packages, not just the top-level dependents?
<nckhexen>Heh, that popped into my head as a nice extra --list-dependent= suboption last night whilst I was falling asleep, and I totally forgot. (No.)
<nckhexen>Guix knows the complete list, then puts some effort into filtering it, but you can't disable that effort from the CLI (yet).
<vagrantc>much refreshing
<vagrantc>guix refresh --list-dependent=please-be-a-bit-more-lazy
<mbkamble>I get this error:
<mbkamble>Wrong type (expecting string): (string-append "/gnu/store/6d0pl5khj08j3c2619jnypc8bznspgx8-gcc-10.3.0-lib" "/lib/")
<mbkamble>(string-append "foo" "bar") is going in as a form to symlink instead of getting evaluated first
<mbkamble>any insight how I can get the string-append can get evaluated to create the string that symlink expects
<lechner>nckhexen: thanks! always learning something new
<nckhexen>mbkamble: Oof. That's bad. Don't forget to roll back if you haven't yet (and this is not a VM), or that will probably break your boot.
<jeko>Yo yo yo !
<mbkamble>The "sudo guix system reconfigure" command bailed out with that error. So I don't think it had created a new generation that warrants a rollback
<nckhexen>I'm not so sure, but OK. I see you already tried this exact approach in the past, sorry I didn't know.
<ardon>Hiya, the script needs 6 X's in `mktemp' for busybox's `mktemp' (the one that Alpine Linux ships with). What would be the best way to go about detecting this in the script?
<vagrantc>ardon: simplest thing would be patch it to use more X's everywhere: tmp_path="$(mktemp -t -d guix.XXXXXX)"
<vagrantc>pretty sure other mktemp support that
<apteryx>emacs command of the day: project-kill-buffers
<vagrantc>ardon: worth filing a bug about it
<ardon>vagrantc: Yup, that should be enought afaict
<vagrantc>or fix busybox :)
<jab>hey guix!
<unmatched-paren>jab: evening!
<lechner>Hi, are mails sent to accessible to the public anywhere?
<Guest60>Hi i can’t boot into encrypted guix on osboot(coreboot fork) after install
<lechner>Guest60: what do you see
<rekado>lechner: no, guix-maintainers is an alias, not an archived mailing list.
<vagrantc>lechner: i thought not, as it is a contact for potentiall sensitive information
<lechner>rekado vagrantc: great, thanks!
<Guest60>I see Failed to boot both deafult and fallback entries, sorry IRC is acting up
<Guest60>I tried booting through seabios
<Guest60>No luck, just guix grub wallpaper after clicking to boot
<lechner>i have no experience with LUKS, but can you get a Grub shell?
<lechner>does 'ls' show anything?
<Guest60>Yes it shoes devices
<lechner>are you using LUKS?
<lechner>how about insmod luks
<ardon>vagrantc: Bug filed!
<Guest60>Yeah almost sure
<vagrantc>ardon: you could even probably propose an actual patch and end up with your name in lights :)
<lechner>Try insmod luks followed by something like cryptomount hd0,msdos5
<lechner>Guest60: ^
<lechner>Guest60: Then insmod lvm and try ls again
<ardon>vagrantc: Ha, let's first see what others have to say about the issue and then I'll consider submitting a patch :D
<Guest60>Output shows the same
<lechner>Guest60: how many entries do you see?
<lechner>Guest60: can you already see inside the LUKS volume, for example something like (lvm/...)
<lechner>Guest60: do you see any entries that look like that?
<Guest60>No, it’s: memdisk proc cbfdisk ahci0 ahci0,gpt2 ahci0,gpt1 usb0 usb0,msdos2 ahci2
<lechner>Guest60: do you know where your kernel is located?
<lechner>you may be able to see that by hitting 'e' on the grub menu entry you would like to start, but the output is kinda long
<Guest60>I see it
<lechner>is it on cbfsdisk?
<lechner>also, you can try ls (cbfsdisk) i think. maybe even without parentheses
<Guest6033>Oh it change my username, whatever
<Guest6033>Oh wait
<Guest6033>Now the ls output is different
<Guest6033>*of ls
<lechner>more is better
<Guest6033>It’s not more, i just enterted grub from seabios
<Guest6033>It has different output than normally
<lechner>on which volume is your kernel, please?
<Guest6033>It says /gnu/store[…] bzimage root=/dev/mapper/cryptroot
<lechner>Guest6033: that's not from Grub, is it?
<lechner>those are mounted paths. we need the actual device, which is something you can see with 'ls'
<Guest6033>Not from payload, that’s from from guix bootloader
<lechner>i have a to leave in a few minutes but will be back in an hour and a half. the general way is
<lechner>unlock your root volume in Grub
<lechner>linux (device)/.../bzImage root=mapped/path/to/root
<podiki[m]>does anyone know off the top of their head a package which propagates glibc?
<lechner>Guest6033: initrd (device)/.../initrd
<lechner>Guest6033: boot
<rekado>podiki[m]: (fold-packages (lambda (pkg res) (if (assoc-ref (package-propagated-inputs pkg) "libc") (cons pkg res) res)) '())
<rekado>podiki[m]: (#<package propeller-toolchain@4.6.1-2.4c46ecbe7 gnu/packages/embedded.scm:822 7f9627b829a0> #<package avr-toolchain@10.3.0 gnu/packages/avr.scm:129 7f9627b77dc0>)
<podiki[m]>great, thank you
<apteryx>ah! define-configuration records are not API-compatible with previously manually-defined ones
<apteryx>so (match (($ <mcron-configuration> mcron jobs log? log-format) ... )) ends up matching %location as mcron...
*apteryx puts the %location field at the end of the record, to make them compatible
<vagrantc>heh. first time i saw larger reproducibility % for i686-linux than x86_64-linux today
<podiki[m]> the --development option for guix shell adds the implicit and explicit inputs for a package, including build system inputs, so that means many would include glib this way, right?
<podiki[m]>tracking down a bug with --emulate-fhs, I think the --development option adding a glib overwrites the glibc-for-fhs that is included, because it comes later in the package list....(I can reverse the list and it changes which glib is there)
<devmsv>hi, I'm trying to build emacs-exwm using my transformed emacs-no-x-toolkit that builds from master but its not working. Log here and package definitions here:
<podiki[m]>to follow up to myself, yes the gnu-build-system includes glibc, see this with something like "guix graph hello --type=bag-emerged | xdot -"
<podiki[m]>hello will just have the gnu-build-system as inputs, so that is a nice way to see that quickly
<jab>so there's a new IPFS implementation...written in rust. I wonder how many dependancies it has...
<jab>geez...I would guess-timate 100+ dependancies...
<podiki[m]>well guix import crate iroh -r only shows iroh itself...
<podiki[m]>oh but maybe it is picking old version that wasn't complete
<podiki[m]>(oh, maybe no real metadata that's why)
<euouae>I should had checked out guix a lot sooner
<euouae>it's very cool
<podiki[m]>welcome to guix euouae :)