<sughosha>Has anyone tried plymouth in Guix? It is packaged but I don't know how to make it work. <sughosha>If anyone is using Plymouth please let me know how. <mange>Looking around the internet, it sounds like we'd need a system service for Plymouth. Nobody has contributed one, nor have I been able to find anyone who has written one, so I think you might have to write your own service if you'd like to use Plymouth. <AwesomeAdam54321>mange: I made system services for plymouth, but they're shepherd services <mange>Can you link us to what you've got? <AwesomeAdam54321>The ones that are shell scripts grep for certain conditions on /proc/cmdline and then exec into the service <WoC>Idk if this is the right place but the image on the website for the PineBook Pro has some x86-64 packages installed, such as coreutils <PotentialUser-18>Hello,I have a problem with java-openjfx-*, when I build them they dont show up in the java modules ***aya is now known as gyara
***aya is now known as gyara
***aya is now known as gyara
<feng>Hello, how to auto run a command, for exampe "rmmod xxxx", when shutdown computer in guix? <efraim>I suppose you could create a shepherd service that runs insmod xxxx at start and rmmod xxxx at stop, and it'll run the rmmod xxxx command at shutdown <eliza>hello all! i'm curious about guix and i wanted to pop in to say hello. <eliza>ty! i've been slowly losing my sanity trying to migrate my nixos+home manger config to flakes so i thought i'd give guix a chance lol <abrenon>that's great ! I know a (very) little bit about nix but I've never tried flakes so I won't be able to give much feedback on that but enjoy guix <abrenon>do you know there's a home manager in guix too ? <futurile>I'm trying to use `guix refresh` to look for packages that I can update. Is there a way to tell that command to only check a section of the archive? I was hoping that `guix refresh --manifest=gnu/packages/shells.scm` would work but it clearly doesn't like the package definitions as a package manifest. <eliza>abrenon: i've heard vaguely of it, but i'm not sure how it compares <oliverp>Hm so it was true pleasure attending the Guix Online Summit during the weekend :) <oliverp> does anyone has any idea about where the wonderfully updated roadmap was published? <oliverp>Any way can't basically wait to the updated published:) As I think it should promise a good bright future for Guix :) <roptat>still trying to create a working cross-clang... <roptat>I'm almost done, but it it passes the wrong options to ld <cbaines>I had to leave before the end of the last session yesterday, super well done on hosting though \o/ <efraim>roptat: indeed, you did a great job :) <roptat>it passes something like -L<gcc:lib>/lib -lstdc++ but the cross-compiler installs this library in <gcc:lib>/<target>/lib instead <phf-1>Hello Guix! I have a question regarding Cuirass. Let `pkg' be a Guix package. Assume that `pkg' needs a service (e.g. a database) when executing the tests. How to setup the environment and `pkg' so that this service is available when executing the tests? <phf-1>Is it even possible to do so? <mothacehe>Hello phf-1, Cuirass is just a glorified derivation builder. If `pkg' needs a service when running the test, you need to start in manually in the test phase I guess. <sneek>Welcome back mothacehe, you have 2 messages! <sneek>mothacehe, apteryx says: no ETA on rsync, but it's currently at (xfr#32698611, ir-chk=955547/33654336), so it unless it scans and adds yet more directories bumping up the total files, it should be done somewhere about somewhere tomorrow <sneek>mothacehe, civodul says: hi! your talk videos are missing from fosdem.org, perhaps you need to approve them or something? <mothacehe>phf-1: for instance, if you have a look to the cuirass package definition in (gnu packages ci), you will see that ephemeralpg is setup to provide a pg database during the tests. <phf-1>mothacehe, So it's necessary to add e.g. postgres in the inputs field for the tests to run? It will make the package quite large I guess, isn't it? <phf-1>I look at the pkf definition <phf-1>mothacehe, Ok. Looking at "the cuirass package definition in (gnu packages ci)" exactly answers the question, thank you. <phf-1>mothacehe, is there a nice Cuirass toturial somewhere? <phf-1>Ok, just wondering if someone had written a tutorial of some kind... "cuirass for dummies" kind of thing. <phf-1>mothacehe, Will take a look! Thank you! <mothacehe>not that i'm aware of, but the guix service should be relatively easy to setup. if you need some advance features, don't hesitate to ask for help on help-guix or guix-devel. <phf-1>mothacehe, your writing is very nice and clear! Images are missing though (broken link). <phf-1>`flat spec' and `flat evaluation' <sughosha>Hi, I am about to configure `guix home` for the first time. As I read in the manual, the profile would be `~/.guix-home`. Will I be able to delete `~/.guix-profile` if I suceed with the home profile? <abrenon>futurile: (I haven't seen anyone else answer so), no a "manifest" is something else than one of the guile modules defining package <abrenon>it's actually a specific data structure, that can be created for instance by calling the `packages->manifest` on a list of packages ***trip is now known as Guest8168
<futurile>abrenon: OK, so implies there is a way I can go from the package files (gnu/packages/whatever) to a manifest. My guile skills are non-existent but sounds like a place to start <futurile>maybe it's my understanding - perhaps there's some other way that the developers stay aware of packages that need updating. <abrenon>I don't think that need of watching a specific file has ever come up (I haven't updated any package from the core repos yet) <abrenon>I would imagine developers to watch a particular package or set of packages they are familiar with or need for their work, but I don't see why in general that would match a whole package module of guix <abrenon>if there's a way to automatically extract the list of its packages from module in guile, I don't know it, but should I really need it, I suppose I'd write a regex based on the (define-public …) statements <abrenon>there would possibly be a couple special cases to handle, but I guess that's still better than maintaining a separate list of those packages within a text file <acrow>efraim: Thank you for your comments. Changes have been submitted to rhino. :) <phf-1>I guess cuirass should run as a specific user... which one? <tschilptschilp23>Hi Guix! I'm literally unable to update root user's guix, or do not understand the concept. Is it possible that without setting root user's PATH after 'guix pull' it will stay with the initial (?) commit forever?! <gnoo>tschilptschilp23: why not use your user's guix? and no, after doing `guix pull' , it will update the commit but guix package -u will update the packages <podiki[m]>tschilptschilp23: are you on guix system? many (most?) of us don't bother updating root's guix as you just use the user one for everything <gnoo>why doesn't guix have mirrors for packages ? <djeis>gnoo: Like, mirrors of the main substitute servers? <nckx>gnoo: There's one in China. <gnoo>nckx: oh, maybe that'll be faster, what's the url to it? <gnoo>djeis: yes, turns out it does! <nckx>Guix has historically been ‘harder’ to mirror for operators who expect to simply point rsync at a server and be done with it. Some work has been done in that direction, but I think SJTUG uses custom software instead. ‘why doesn't guix have mirrors for packages ?’ is a loaded nonsense question. <tschilptschilp23>podiki, gnoo: yes I'm on guix system, and what you suggest is how I actually work on my machine ;) But -- if I create a vm with 'guix system image [...]' it uses the 'not-updated' root commit (and it does not seem to respect setting root user's guix PATH). This ends up in having a vm booting with the 'new commit' (from the user who created it), but seing an older guix version initially. This is a little frustrating, and therefore I try <tschilptschilp23>to 'update' root user's guix (without setting a PATH), as the commits of that one and the one set in the VM map 1:1. <podiki[m]>that I don't quite know what is best, though people here work with guix vms hopefully can help you <nckx>> without setting a PATH — guix is never updated ‘in place’ unless it's in $HOME. <gnoo>hmm, did you do sudo su - and then guix pull ? (log in as root and then guix pull so that root's guix is updated) <nckx>Still haven't watched your video. Couldn't attend the 'days either so no spoilers. <tschilptschilp23>gnoo: yes, amongst 'su', 'su -' and 'sudo su' :) I think I really don't get it... <podiki[m]>nckx: sadly I couldn't attend most of the sessions (time zone), but did enjoy the talks and discussions I could attend. Lots of good stuff for the future of guix! <nckx>tschilptschilp23: ‘sudo -i guix pull’ should do it right, as should ‘sudo su -’ and running ‘guix pull from the shell it gives you. The problem is that ‘being root’ is a very complex concept. You can have root privileges without ‘being’ root, which is what ‘sudo’ does by default (equivalent to ‘sudo -E’), and things like HOME will still be set to /home/tschilp. <nckx>It's not that complicated. ‘sudo -i COMMAND’ should be equivalent to ‘sudo su -’, ‘COMMAND’. ‘sudo su -’ and ‘su -’ are identical, but the latter is a bit trickier since you'll have to enter root's password instead of your own, and root might not even have one. <podiki[m]>or you always forget root's password because you used it exactly once, when setting it :) <podiki[m]>I've done that to re-set the password (promptly forgotten again, of course) <nckx>podiki[m]: I'm looking forward to catching up :) <nckx>The Q&A parts were also recorded, IIRC? <podiki[m]>they were (or at least ones I was there for), but might be a bit until they are available <podiki[m]>also not sure if they will be posted somewhere or just in the bigbluebutton instance? <tschilptschilp23>nckx, podiki: In my desperation I now did 'su -', 'mv .config something', 'exit', 'sudo -i guix pull'. Now 'sudo -i guix describe' or 'su -' followed by 'guix describe' make me happy. But 'su', followed by 'guix describe' still makes me cry... <podiki[m]>(reminds me of the old "joke" about going to a doctor and saying "doc, it hurts when I do this" ...) <tschilptschilp23>nckx: But a vm created with 'guix system image [...]' will have this 'su' 's commit in 'guix describe' and cannot 'guix pull' therefore,... arghh <nckx>Yeah, it was a bit ‘don't hold it that way’, wasn't it… Still, I wonder why you're using su, only to then say you don't like what it does. Seems like a mild X-Y problem? <tschilptschilp23>I personally don't care about Mr 'su' 's guix commit, I just see that every vm I create with guix system heavily cares about Mr 'su' 's guix commit... <nckx>su is not a user, it's a command, and you're calling it in a way that gives poor results. We're missing why you so sorely want to ‘su’ in the first place. <nckx>‘su’ is not a nice environment compared to ‘su -’. <nckx>And it's certainly not ‘root's environment’. <nckx>It's a hell-mix of… things. Run ‘env’ in both ‘su’ and ‘su -’ and diff the results, or just look at ‘echo $PATH’ in both ‘su’ and ‘su -’ shells to see how badly they differ. <nckx>tschilptschilp23: In (or outside of?) these guix vms, what are you using ‘su’ for and are you sure it's the right tool for the job? <nckx>…and if you don't mind me piling on the questions: why? 😉 <tschilptschilp23>What I'm trying to say -- if I create a qemu-qcow2 disk using 'guix system image' on an updated guix system, and afterwards start this built image with qemu, the 'guix describe' returned to the ssh-d in unpriviledged user (inside) does not point to the commit the 'builder' (outside) sees on his/her profile, but to the one outside only sees after issuing 'su' followed by 'guix describe'. <tschilptschilp23>Why? I want to use this feature because I find it terryfying attractive, but like this I cannot properly use it ;) <roptat>that's because the guix that's in the qemu is the one that's describe in a package definition, so it can't point to your current guix, but only to an earlier revision <roptat>that's something we want to work on though, because it's annoying <nckx>It definitely is (there are/were even cases where there were 2 nesting dolls, and one could get a guix that was 2 updates out of date). <nckx>tschilptschilp23: Isn't that just coincidence? <cwebber>I'm copying a expensive-to-compile derivation from one computer to another <nckx>I think it is. It's expected that the guix you find inside of something you create with guix is a previous version. <cwebber>guix package -i /gnu/store/<this-package-output> <tschilptschilp23>roptat: thanks for the info, so for qemu I'll stick with iso-files for now I guess... <nckx>cwebber: No idea why package -i isn't 100% equivalent to its presumed alias, but ‘guix install’ can do that. <nckx>It feels dirty but can be a life saver. <nckx>Hi abrenon (and belatedly cwebber). <abrenon>roptat: what's the roadmap for creating the subtitles for the videos ? <tschilptschilp23>roptat, nckx: and yes, if I knew the config ahead of time, I wouldn't have to hop into that machine, play around inside and bother you guys with my 'su' problems :) Thanks for your input <abrenon>I'm a bit burried within work this week but I hope to have more time from this weekend on <nckx>tschilptschilp23: Since I do everything from a local ~/guix checkout, what I've done in the past is make a local commit updating the ‘guix’ package to the latest upstream commit, pull, and deploy. It's manual and tedious though. Also benefits from keyring privilege. <nckx>I wonder if there are cases where --with-commit=guix=foo works around that… <nckx>…and doesn't just break. <nckx>abrenon: Hope springs eternal. <nckx>podiki[m]: I never realised pci.ids was a bundled database (by the same author, but still)! I think it makes sense to create an uncompressed pci.ids package on master, make your packages use it, and update pciutils to do the same on c-u. WDYT? <nckx>On ‘modern file systems’, manual .gz compression won't win you much anyway. <abrenon>nckx: : D and so is the time I spend writing this article… <jpoiret>tschilptschilp23, nckx: I've been working on making current-guix work in (hopefully) all cases so that we're able to replace the guix package with it in the default configurations <jpoiret>also, currently, the nested dolls issue happens when you use the installer, since when creating a guix iso you get the N-1 version, and that version when running `guix system init` gives you the N-2 <nckx>jpoiret: That's what I was thinking of, thanks. <podiki[m]>nckx: that make sense, would pciutils then need to keep a specific version of the pci.ids so it doesn't get rebuilt often? pci.ids seems to have a monthly release <nckx>A quick glance at the code didn't turn up an environment variable we could set to bind at run time (which IMO is superior). <nckx>But holy hell, it has DNSBL-like PCI ID query support over DNS. *nckx puts that into the ‘OK then’ file. <podiki[m]>...I don't know what that means but sounds fancy/complicated :) <apteryx>nckx: I was thinking pciutils must offer some API to get at its data? so that whether it's compressed or not is not a concern for its users <podiki[m]>so in that case we'd want to keep a version of pci.ids for pciutils, maybe freezing that on core-updates when it gets frozen in the future? (or whenever CI building starts for it) <podiki[m]>Arch has uncompressed pci.ids for what that's worth; the few packages I have that specifically want that file don't seem to handle the .gz version (did not investigate how exactly it is loaded though) <podiki[m]>apteryx: I need to look, but I think some software wants to grab the pci.ids directly, rather than I would guess parsing lspci or something? just guessing though <nckx>I did not read your mail as ‘use an API nicely’, rather just ‘read the file directly’. <nckx>It's poor practice but shipping 2 copies of the same DB is just shooting ourselves in the foot to spite them. <rekado>I don’t have much time today, unfortunately, and I need to get some sleep, so I can’t stay around for long; but if everything is ready I wouldn’t mind the thrill. *podiki[m] anticipates the play-by-play to be more entertaining than grading... <helaoban>hello guix, I'm running into an issue when trying to adding the global channels file (/etc/guix/channels.scm) declaratively via an etc-service-type service <apteryx>rekado: hmm, I'll feel bad if there's an issue that will forces you to go to the MDC tomorrow :-) we can wait a bit later this week <apteryx>when your energy supply has been replenished a bit! <helaoban>on the latest pull of guix, the /etc/guix directory is already populated with some files. trying to add a file to /etc/guix via etc-service-type errors out with "error: symlink: file exists: "/etc/guix" <helaoban>is adding to an /etc subdir not supported via etc-service-type if that directory already exists? <helaoban>service looks like this: (simple-service 'channels-config etc-service-type (list `("guix/channels" ,(plain-file "channels.scm" <my-channels-config>)))) <acrow>sneek: tell maximed that all is well after removing all the bundled jars in rhino. Associated patch is submitted. <sneek>maximed, acrow says: that all is well after removing all the bundled jars in rhino. Associated patch is submitted. <apteryx>no, I meant it seems suboptimal that etc-service-type breaks like this when a parent directory already exists <apteryx>but perhaps there's actually a better way to accomplish what you're after here? <apteryx>you could try/review that and tag is as reviewed if it works for you! <apteryx>it seems mostly ready to go, already been reviewed by Ludovic, with 3 minor comments outstanding <PotentialUser-95>Hi. I've been playing with guix a while, feeling like the way I set up my shell may benefit from some changes... <PotentialUser-95>Just a general question: what guix-related things have you put in your .bashrc / .zshrc that aren't in the manual, for your own workflows? <helaoban>apteryx: re patch 49610, that's exactly what I'm trying to do. <podiki[m]>PotentialUser-95: I have multiple profile loading in my .profile (as outlined in the cookbook), but not much else that I can think of. I'd like to make my prompt show when I'm in a guix shell environment, but have been lazy <balbi>hi, is it possible to define a package in `guix' which doesn't support a particular architecture? For example, define a package that won't build for aarch64. How can that be done? Thank you <podiki[m]>balbi: yes, there are some examples, use (supported-systems '("x86_64-linux")) for example, so it only is for that <podiki[m]>there's probably an easy way to do the inverse, just what is not supported, but don't have an example handy <PotentialUser-95>Adding something about which profile/environment/etc. to the prompt would be useful, yeah... <podiki[m]>here is one: (supported-systems (delete "riscv64-linux" %supported-systems)) <balbi>podiki[m]: perfect :-) That's exactly what I needed. Thank you very much :) <podiki[m]>there might be some other variables that have handy lists of systems already to use <helaoban>apteryx: thanks for pointing that out, I can wait for the merge. If I have some time I can apply the patch on my end and review. <podiki[m]>re: pci.ids As an example, mangohud directly reads in the pci.ids file expecting plain text. the file is just has lines with hardware-id and then hardware-name basically <podiki[m]>pretty simplistic, I expect other hardware monitoring and such do that as well, rather than running lspci and parsing that (mangohud used to do that for some hardware I see) <rekado>apteryx: okay, sounds good. My toddler just decided that I have other plans tonight anyway… :-/ <apteryx>podiki[m]: lspci is a command; is there no C library to plug with? <apteryx>/gnu/store/dbj1i7q1cprbx6ar3q35z2a9g6hphzgm-pciutils-3.7.0/lib/libpci.so <apteryx>helaoban: testing changes is time intensive; if you have an interest in it, I can only encourage you to apply it locally and trying it, and reporting your success. This will give more confidence to those who have to apply it. <apteryx>or catch problems that need to be resolved beforehand :-) <helaoban>apteryx: np, I can do that. Is a simple reply to that patch thread saying "this works for me" enough or is there a more formal process for that? <apteryx>podiki[m]: can you give a spin to your mangohud package with the new imgui package? <apteryx>podiki[m]: yeah, pciutils provides a library to do lookups, e.g. char *pci_lookup_name(struct pci_access *a, char *buf, int size, int flags, ...) <apteryx>so we could open an issue with mangohud suggesting them they use it instead of reinventing the wheel <podiki[m]>apteryx: I had tried before for mangohud, but needed a change to find the library (it tries with cmake or pkg-config files), so I'll have to see what change is needed, probably just need to tell meson specifically where to find it? <podiki[m]>corectrl is another package that wants just pci.ids (I have a package for it but not submitted yet) <podiki[m]>oh, I think meson you can use find_library with explicit 'dirs' argument <apteryx>helaoban: that'd already be nice :-) <apteryx>there's no formal process, but when we as a reviewer are confident that both the code and behavior is OK (reviewed/tested) we often leave a LGTM to let the author/committer know we trust this to be good to merge to the best in our opinion. <podiki[m]>apteryx: will have to continue the imgui test later, flailing at meson right now, even though I'm sure it is easy to set up (whether it runs is another question) <podiki[m]>anyway, I'll figure that out, and does the pci.ids change from 54069 sound like what we'll do? <podiki[m]>so I can sort out the imgui version/build for mangohud, and then use the new hwdata package proposed if that's what we're thinking (with pciutils change for core updates to use the more up to date pci.ids from hwdata) *podiki[m] off to run (literally) but will continue the hacking later <pranavats>Hello. I really need some help recovering a guix system installation. I think I somehow damaged my luks partition. I had an LVM on Luks partition, with a single encrypted physical volume. I wanted to install devuan on a logical volume I created in the omly volume group on that physical volume. I opened the devuan installer and at the manual partitioning step, I could not find a way to decrypt the luks part <pranavats>ition to choose logical volume as root. I clicked on "configure encrypted volume" option. It asked me if I was satisfied with the current layout before continuing to configure it, and I continued with a "yes". But I never wrote any changes to disk. And aborted the installation. Now cryptsetup errors out with "not a valid luks device" when I try to open it. And obviously grub cannot boot into my guix system <apteryx>hm. if your LUKS partition header was actually damaged, there's not much to do but reinstall unless you had a backup of your LUKS header <apteryx>if it wasn't damaged, then it should still work, whether from Guix or any GNU/Linux live USB you happen to have <pranavats>It does seem like the header is damaged. I had a backup which I cannot seem to find now. <pranavats>I just wanted an opinion on diagnosing the situation before trying to recover (using photorec) the backup of that header from an old flash drive which has since been formatted. <pranavats>apteryx: The partition is still recognized as lvm2 physical volume by gparted. <pranavats>I wonder if there is any way to make a copy of the damaged header. <pranavats>apteryx: Or maybe photorec can recover the header? <pranavats>jpoiret: I wonder if you have any suggestions to help with my situation. <PotentialUser-86>I have a relatively newbie question: what could probably be the reason that my system cannot login with the normal user account. I mean when I try to login from tty or graphical interface, after entering my password, the whole screen "refresh", and I'm being asked for username again. root does not have this problem. roll-back does not help. The <jpoiret>tbh if the header is damaged there's likely no way back <pranavats>If I get the header back, what are my options? <pranavats>I mean, I can lookup how to restore it. I just want to know.if that's what the situation is really. <jpoiret>TIL i learned you can backup luks headers to be on the safe side <jpoiret>if you get the header back, you should be able to simply dd it to the beginning, but cryptsetup has an option for it <jpoiret>luks2 has a duplicated header so it's less likely to be corrupted (although overwriting both of them will still kill your disk) <jpoiret>i'll be going to catch some zzzs now if you'll excuse me. good night guix <ss2>hello, I'm trying to load a module, say a service definition into my repl, but only the definitions made public are available in my repl -- which is kond of obvious. <ss2>But then how would I access the rest of the definitions that are defined in said service? <ss2>alright, they are not destined to be public. Got it. <yewscion>Hello all, what is the canonical way to package a project that uses a custom build script ( `build.sh` in this case) for compilation? <ss2>yewscion: have you looked into Guix' package deklarations? It can be quite helpful finding similar use cases. <yewscion>ss2: Currently trawling over some I might think might have to do something similar; Just wanted to ask in case it was a common thing that I was missing. <ss2>It really depends on how the build.sh is set up. You might find a similar use case, or you read through the INSTALL file from the source and see how you could go from there. <ss2>the source of the project you are packaging. <yewscion>Oh no, I know how to build the software. I am unsure of the syntax used to replace the 'build step in gnu-build-system with a call to `build.sh` instead. <yewscion>Unless You mean I should rebuild the `build.sh` in guile instead of running it? <ss2>You could modify the build phases with, say, (modify-phases %standard ...). The build systems are not cast in stone. They're easily modified. <yewscion>ss2: Thanks for the tip; I was able to find an example of what I needed in the package definition for Java. <apteryx>it'd be nice if 'guix style' would print a rationale of why it did nothing w.r.t. input simplification <apteryx>I'm looking at "./pre-inst-env guix style --input-simplification=always gnunet", for example <feng>Hello, how to avoid input password when run xfpm-power-backlight-helper <shcv[m]>any idea why my wireguard service isn't auto-starting / how to make it auto-start? <shcv[m]>also, how to prevent my guix-sd from going to sleep? <podiki[m]>any meson users here? failing at what should be easy, adding an include path to a package definition (originally it was a subproject, so I'm patching that to use the package input) <tschilptschilp23>PotentialUser-86: if it is a completely new system, it might help to run ~sudo herd start user-homes~. I also experienced this once after a fresh install -- turned out that my user-home had not been created, which led to the effect you describe. <disposabled[m]>when I try to start guix-daemon, I get, "guix-daemon.service: Failed to execute command: Permission denied" <podiki[m]>apteryx: seems the imgui version we have now isn't linking properly for mangohud, I don't think it is the version (I tried with 1.81) but something with how it is built?