<rekado>mbakke: you need the (guix gexp) module <twill>hello I was having some difficulties defining a package for Picom <twill>ive come up with the following <twill> #:docstring "Excecute Picom compositor" <twill> #:start (make-forkexec-constructor <twill> #:log-file (string-append (getenv "HOME") ***ChanServ sets mode: +o litharge
***litharge sets mode: +q *!*@142.115.141.22
***litharge sets mode: -o litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -qo *!*@142.115.141.22 litharge
<twill>Should I be running it as a system service? <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) <nckhexen>twill: Just visit paste.debian.net and fill in the textarea, submit, then share the link. <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>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>sneek: later tell twill: Anyway, if you do return: '("picom" "") → '("picom") or it will be invoked with a single empty argument string; literally ‘picom ""’. <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 <winter>wait, how so? i just used the install script from master as the manual suggests <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. <winter>How would one pull latest stable, if desired, then? <winter>(I should RTFM before asking, shouldn't I) <nckhexen>Very roughly, guix-install.sh 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>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? <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? <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>(dang, this pull is taking a while... does it do a full clone?) <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>It's explicitly marked as non-substitutable because trivial. <winter>currently waiting on gnutls to build, a thing i did not know existed <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). <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). <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). <lechner>winter: you can use debbugs.gnu.org/#XXX 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, … <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 guix-install.sh 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. <nckhexen>Now, nothing is up, I'm afraid that's a certainty. <nckhexen>Probably the Shepherd being violently ill again. <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 ***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?) <winter>yeah that seems to be a common sentiment <nckhexen>Any other day, the bot would have taken care of that but I reconfigured it yesterday and still need to restore that. <nckhexen>I assume it's less work for you. For me, ‘reporting Matrix spam’ is literally poking someone who works there, which is $work. <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 🚨 | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***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. <winter>I use Matrix for NixOS stuff, though, since that's our primary method of comms. <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>‘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>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. <nckhexen>Really just waiting for mount to return. <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. <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? <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. <Andronikos>nckhexen: Well I just wanted to be sure. Those questions could be interpreted negatively. <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 | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckhexen
<nckhexen>Nothing at all about Shepherd (or anything else relevant) in /var/log/messages. <nckhexen>Andronikos: The dodgy 400 error is specific to me. <nckhexen>It is supposedly ‘expired’, but is nominally valid well into 2024. <nckhexen>I fixed nothing, I just restarted the server. We can now restart services again, but who knows for how long. <winter>I thought Nginx was throwing errors again? <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. <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>> 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>wow i like the little changelog after guix pull <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>I use NixOS on servers and Nix on macOS, to be more specific. <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>ugh looks like i gotta build the kernel <Andronikos>Well I reported that issue a while ago let me look at it <jamesw>rekado: It is worked for the 'gcc' version ! ==> https://paste.debian.net/1258523 . 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 :-) <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>just need to find a good way to do so <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>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? <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. <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? <Fare>winter: problem with GRUB installation or configuration? <Fare>do you get a grub prompt? <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>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>(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 ***Dynom_ is now known as Guest5986
***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 ? <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>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? <examors>The local-file path will be relative to the source file it's in, when it's a literal string <sash-kan>hi all! repl launched inside time-machine does not see the channel modules: http://ix.io/4eiU . is this a bug? if so, in which command - time-machine or repl? <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
<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. <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 <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>I want to use this computer as a server. <yarl> (list (service openssh-service-type <yarl> (password-authentication? #f))) <yarl> (service dhcp-client-service-type)) ***ChanServ sets mode: +o litharge
***litharge sets mode: +q $a:yarl
***litharge sets mode: -o litharge
***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! <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]>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. :) <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 <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]>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 <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 <Korven[m]>nope, doesn't seem to list the directory guix stores fonts in <examors>Does the $XDG_DATA_DIRS environment variable include it? <xd1le>Korvarx[m], might need to add the directory to the fontconfig fonts.conf <xd1le>well you could use guix home I guess <xd1le>I'm not aware how to get fontconfig to see it without this though <Korven[m]>apparently my .bash_profile was not in effect <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. <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. <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 <nckhexen>But that was over a week ago. powerpc64le-linux, at least for master, was enabled after that. <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>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. <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? <nckhexen>There's logs.guix.gnu.org (which also logs #guile). <nckhexen>I have unprocessed logs if you need more. <mothacehe>nckhexen: apteryx: powerpc support for master restored with: d2f3da8 <mothacehe>someone needs to reconfigure berlin soon :) ? <nckhexen>I was just about to do so, I'll fold it in. <nckhexen>apteryx: mothacehe Sanity check: none of you can log into the Cuirass Web UI, right? <nckhexen>I've asked Ricardo for the ancient keys. <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 ^^ ***Dynom_ is now known as Guest7629
<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 <sneek>Welcome back dsmith, you have 1 message! <sneek>dsmith, dsmith-work says: Did it work? <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 <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.) <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:). <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: https://0x0.st/o35q.png (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
<gnucode>Korven[m]: just use fish. It just works. tm <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? <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? <gnucode>Korven[m]: I have a keybinding set up in sway... <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". <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>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>The Librem 5 isnt the fastest..lol. 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? <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. <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? <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? <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. https://paste.debian.net/1258625/ ***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! <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>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? <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 0.0.0.0 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 0.0.0.0:80 0.0.0.0:* users:(("guix publish",pid=15093,fd=14)) <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 <lechner>tribals: I am not sure I care so much about IPv4, but I am super thrilled that it's working! <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 <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' ... :) <lechner>vagrantc: there is also "This module packages" in perl-moosex-types-datetime <nckhexen>‘0.0.0.0’ 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 <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 <nckhexen>sudo umount /gnu/store && sudo rm -rf /gnu <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 :-/ <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>…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 <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. <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? <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 ‘0.0.0.0’ is to IPv4, nothing magic. What's magic is Linux defaults to ‘dual stack’ mode, meaning that binding to ‘::’ will automatically bind to ‘0.0.0.0’ 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. <mbkamble>Hi. I am lost trying to achieve the following: I want to create a link to libstdc++.so.6 in /lib64. libstdc+.so.6 exists in lib output of gcc (/gnu/store/blah-gcc-10.3.0-lib/lib/libstdc++.so.6) <mbkamble>I have written this in my system.scm file: <mbkamble>(services (list (service openssh-service-type) ... (extra-special-file "/lib64/libstdc++.so.6" (file-append gcc "/lib/libstdc++.so.6")))) <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). <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 libVkLayer_MESA_device_select.so: 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 https://issues.guix.gnu.org/58251 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>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 <https://issues.guix.gnu.org/58566> to be applied *and* for the core-updates branch to be merged into master. <tribals>nckhexen: will continue exercises later and report <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/libstdc++.so.6" #~(string-append #$gcc:lib "/lib/libstdc++.so.6")))) <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. <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>guix refresh --list-dependent=please-be-a-bit-more-lazy <mbkamble>Wrong type (expecting string): (string-append "/gnu/store/6d0pl5khj08j3c2619jnypc8bznspgx8-gcc-10.3.0-lib" "/lib/libstdc++.so.6") <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. <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 <ardon>Hiya, the guix-install.sh 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)" <apteryx>emacs command of the day: project-kill-buffers <ardon>vagrantc: Yup, that should be enought afaict <lechner>Hi, are mails sent to guix-maintainers@gnu.org accessible to the public anywhere? <Guest60>Hi i can’t boot into encrypted guix on osboot(coreboot fork) after install <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 <Guest60>I see Failed to boot both deafult and fallback entries, sorry IRC is acting up <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? <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: 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 <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 <lechner>also, you can try ls (cbfsdisk) i think. maybe even without parentheses <Guest6033>It’s not more, i just enterted grub from seabios <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>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 <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>) <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]>hrmm...so 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) <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 <euouae>I should had checked out guix a lot sooner 