<rndd>hi everyone! what does mean "exception syntax-error (value package) (value "missing field initializers " when i'm trying to pack custom script on my channel?
<reepca>so I spy a note in (gnu build linux-container) that says it shouldn't pull in (guix config), but I kinda need that in order to know where to find the helper program to use in eval-with-container... what do?
<cbaines>nckx, bayfront is quite low on space, and I'm not sure substitute availability is that great. I think the situation can be improved, the most impactful change might be to just build master, rather than trying to build staging and core-updates as well
<cbaines>I'm also working on building packages myself, and serving up substitutes, mostly to test the Guix Build Coordinator I've been working on, but also to provide another source of narinfos to compare with bayfront + berlin
<ryanprior>I'm packaging a compiler (v language) which really wants to have "cc" available and has that hard coded in a number of places. I've been patching things to say "gcc" Instead but upstream is recommending that I put a symlink from cc to gcc on my PATH instead. Is that a good idea?
<leoprikler>It's certainly doable inside a build-system but pretty much a pain otherwise
<nckx>ryanprior: It's not a… great sign of things to come, but it's an acceptable fix since you're basically doing the same thing as CC= differently. No need for a symlink: (setenv "PATH" (string-append (getenv …)))
<ryanprior>I mean by generated source code standards it looks pretty good imho, I've spot checked a few places in the source file to scan for things like blobs or giant obfuscated strings & don't see any such.
<leoprikler>where record-type is e.g. package or operating-system
<leoprikler>actually it's not really the "type", but it's the syntax sugar we're using as constructors
<nckx>ryanprior: Some have made the case that we should differentiate between ‘unreadable’ and ‘auditable’ generated code, implying that the latter is good enough to be accepted in Guix. Not convinced, but it's an argument you could try to defend.
<nckx>If the original has been lost it's either that or no V in Guix.
<ZombieChicken>heh. Whoever wrote the guix-install script never ran a Gentoo system.
<leoprikler>Too sad we can't `guix time-machine` back into when ebuilds were still accepted in our source tree :(
<ZombieChicken>nckx: update-rc.d doesn't exist. rc-update $SERVICE default is needed to add it to the default runlevel. After that, I usually start things manually, so I'm not 100% sure what the command after that would be. It might be more portable to simply say "After the install is done, please start the script"
<ZombieChicken>or just dump support for sysv-init, and point to the proper files and let the user handle it. Not sure what would be needed for, say, Void Linux
<leoprikler>the thing is, update-rc.d is the name used by larger distros, such as debian variants
<nckx>Let me peek at guix-install.sh, which I do not in fact know by heart.
<ZombieChicken>leoprikler: Exactly. Once your out of systemd territory, one can't be entirely sure what's up.
<nckx>Well, we, ideally (here it comes) someone™ using Gentoo 😊
<leoprikler>Not me, I transitioned my Gentoo machine this spring.
<ZombieChicken>Just drop sysv support and let nonsystemd/nonupstart users do things theirself
<ZombieChicken>and just assume users of other distros can figure things out
<nckx>That's a valid suggestion but I don't think it's the obviously right thing to do. Or rather, there is a very small subset of users who want to use the magick-me-some-Guix script but care about nobody touching their init.
<ryanprior>nckx: my understanding is the language is pretty new & didn't start checking code into scm until mid-2019, by which time the language was already self-bootstrapping.
<nckx>Installing Guix by hand is very doable. The script is there to do it for you, so it should do as much as possible. But this is absolutely a bug, sure.
<leoprikler>Let's write a self-bootstrapping compiler without versioning, what could go wrong?
<ZombieChicken>nckx: where would said bug report have to go? Right now, probably not; I don't want to sign up to Yet ANother website, and sending email is currently borked on my system for reasons I'm unsure of
<ryanprior>I think it would be neat if a substitute-type function could implicitly create a patch which would be part of the package metadata somehow.
<reepca>huh? I was referring to him saying "there is only one 'Linux distributions withou x' category". That would imply that there wasn't a category for libre distributions, as they are "without nonfree software".
<reepca>I'm not qualified to comment on whether it does or doesn't classify as free software
<ZombieChicken>Hmm. Is there a way to prevent certain software from being installed in a guix system?
<reepca>at the risk of sounding cheeky, "not installing it"?
<rekado>ZombieChicken: you would need custom packages then that don’t include certain inputs.
<reepca>I guess if you're worried about transitive dependencies ("this pulls in WHAT?"), you could inspect the reference graph
<reepca>although the reference graph isn't actually available until it's built... hm...
<reepca>but you could definitely inspect the input graph
<ZombieChicken>Yeah. I was hoping for something like package.mask, where you could say "Under no circustances install this", then I know I'd have to write/patch my own packages to get around that kind of thing
<reepca>that seems doable. Scheme procedures could totally inspect the graph of packages and notify you if it ever finds a certain package.
<ZombieChicken>so, for instance, "guix install icecat" with a mask/ban on 'pulseaudio' would give an error "unable to install due to pulseaudio dependency"
<cantstanya>forcing exclusion of dependencies like that sounds like a bad idea when dealing with binary packages.
<ZombieChicken>cantstanya: It would require one to fall back to building it locally
<ZombieChicken>If one doesn't want a package installed, it's entirely possible it could slip in as a dep somewhere in a possibly massive dep tree
<cantstanya>unless the UI is something like: run command to fetch package, something checks if it and all deps require certain dep, then automatically build local recipe instead if remote package will pull anything that has dep on unwanted dep, then checking for unwanted dep like that seems frivolous compared to just manually rewriting things to build without unwanted dep.
<rekado>some packages, for example, will build just fine without libxml2 but they default to aborting when it isn’t available
<gignomai>hey guys, hope all is well. i'm hitting this issue w/ the guix installer and am wondering if i could get some help in finding where i could download the latest build of the installer that's mentioned here https://issues.guix.info/40682
<rekado>the way to disable certain features differs not only across build systems but may differ from package to package
<cantstanya>yeah and some things require explicit disabling of dependency at build time when it's not available.
<apteryx>gignomai: hello! s/guys/people/ is better form here :-)
<apteryx>gignomai: unless I misread, the image is not yet available from a URL, but a patch is proposed to make this possible.
<cantstanya>rekado: hmm so can manifests handle what ZombieChicken suggests at least? check if package requires dep in the dep tree/chain, then exit with an error that it'll be pulled if the current installation request is processed (for lack of better phrasing)?
<apteryx>if you have access to a 2nd computer where Guix is available, you could generate such image following the procedure detailed in the Guix info manual.
<cantstanya>seems like a yes based on what you previously said
<rekado>you can do “guix package -i $(guix build …)”
<marusich>dftxbs3e_, I'm interested in maybe helping out with the POWER9 port, but I am a little behind on reading the emails. I'm going to check the email lists, but if you have any recent information, I'd love to know. Feel free to email me at firstname.lastname@example.org or message me here.
<rekado>badair: but really, I think “guix package” should just gain a “--system” option.
<raingloom>the project doesn't exactly have the best track record. it's um. i wouldn't say it was run very wisely. it has gotten better, but a lot of people got upset when they realized the main dev's promises didn't come true.
<PotentialUser-72>The Guix docs describe the nix package service. Anyone know of a blog or some such describing how to actually get it to work ? DDG is returning nthing useful.
<ryanprior>raingloom: yeah definitely a lot of chaotic vibes there!
<raingloom>PotentialUser-72: add (service nix-service-type) to your services in your operating system config, install the nix package in your user profile, add some channels, and run source /run/current-system/profile/etc/profile.d/nix.sh to activate it in the current shell.
<raingloom>that's roughly how i remember doing it. but i don't use it a lot.
<raingloom>i'm pretty sure most info was in the info page for Guix.
<raingloom>PotentialUser-72: sudo herd start nix-daemon (you can figure out the service name by looking for "nix" in the output of `sudo herd status`. or there is probably some more official way, but that's how i do it when i can't remember a service name.)
<bhartrihari>Hello, I'm on GuixSD. I reformatted my home partition, which changed its UUID. Now I'm not able to login, and I can't even just update /etc/fstab since the config gets reverted at startup. What are my options? Would it be possible to chroot into the system and reconfigure it using config.scm?
<apteryx>guixy: IIRC native-search-paths is used as the default value of search-paths if unspecified, which makes them pretty much alike but native-search-paths would also cause the values to be expanded in the builder container
<apteryx>it'd be nice to have their effect and intended uses better documented
*apteryx issued 'sudo herd restart guix-daemon' and now the 'guix package -m ...' commands seems to proceed without errors
<nckx>bhartrihari: Be extremely careful but running ‘guix system init’ from the installer on a mounted, existing system will work, yes. It will only touch /mnt/gnu and /mnt/var/guix (which I tend to delete for neatness' sake in such cases).
<bhartrihari>Let me try it again and get specific errors. Thanks.
<nckx>bhartrihari: If you call /chroot/home/you/.config/guix/current/guix system init it really should use all your custom channels.
<nckx>Don't pull in that degraded state. It's not worth it and complicates things badly.
<nckx>The problem is spinning all your plates just right so you're also running a chrooted guix-daemon (so not the one started by the installer; stop that one) and it truly believes that /chroot/gnu is /gnu.
<nckx>I've done this before but I honestly can't walk anyone through it remotely, too many things to remember, sorry :-/
<efraim>bah, calling run-job directly from a shepherd service doesn't seem to work for me
<nckx>This is why ‘guix system init’ is easier, even if it probably will bork up your gcroots. That's not permanent, though, and should take care of itself when you reinstall your user's packages before the next GC.
<bhartrihari>You said that guix init would only touch /mnt/gnu and /mnt/var/guix. Would that update the UUID for the mount point?
<nckx>If you correct it in your system configuration, yes.
<nckx>If you need custom channels you can add a ~/.config/guix/channels.scm in the installer and pull, it's ‘just’ a Guix System.
<bricewge>I'm stuck working an a new kernel-configuration-service-type.
<bricewge>I want to set kernel-arguments from a service.
<bricewge>Is it possible? The only way I managed to come with is to write an essential-service that set the parameters but it looks like to be a can of worms...
<bricewge>Any guidance on how to do something like this?
<bricewge>The current patchset already create 2 of those essential-serivce, am I missing a pattern here or what?
<luis->Hello everyone. I am happily continuing my guixsd voyage. I didn't install any window manager with guix. rn I trying to set up xorg with emacs as the wm. As I was reading the manual on system configuration I see that xorg is a user-service module in config.scm.
<luis->I installed xorg as a user via `guix install xorg-server`. Is a matter of preference whether it should be installed system wide or by an individual user? Or is it something that I should add to config.scm? I installed guixsd so that it doesn't have any window managers.
<raingloom>i heard rumors of a RISC-V GPU, but idk if that'll be open or even have the features necessary for 3D work.
<jonsger>raingloom: thats nothing for the next 3 years
<drakonis>you have to implement the graphical apis required for such work
<sirmacik>I'm working on running cron daemon and my biggest trouble is in creating crontabs for every user, so that while being setup service enumerates system users and creates /var/cron/tabs/user files with user:user ownership
<sirmacik>it'd be easy in config.scm but needs to be done while guix installs package/daemon
<reepca`>agh... apparently calling unshare with CLONE_NEWPID makes it impossible to create new threads in that process. Thanks, linux.
<mbakke>alextee: I'm not able to reproduce the 'guix pack' issue, when testing it locally with './pre-inst-env guix pack -RR -S /opt/zrythm/bin=bin zrythm' and running the unpacked executable I don't see the 'non-grafted' fontconfig (/gnu/store/bf2jmcvrq5qbbnwv8mzxglrkaj2v7232-fontconfig-2.13.1) anywhere
<nckx>apteryx: Weird! Your fix-up commit added a ‘)’ too many but… Guile didn't care.
<nckx>I guess a lower-tech answer to your previous question could've been ‘grep -o '(' etc/news.scm | wc -l; grep -o ')' etc/news.scm | wc -l’ & make sure they're the same, because Guile is becoming sentient.
<reepca`>ryanprior: yeah, computed names is one of those things you can't really do with syntax-rules. You'd have to switch to using syntax-case.
<reepca`>also, note that currently your wrappers are inheriting the hidden property from the things they wrap, so for example "guix build gcc-wrapper" wouldn't find them
<reepca`>that might be fine anyway, since either these should only be used as inputs to packages or they should be wrapping gcc-toolchain instead
<reepca`>also note that currently the wrapper packages require the same inputs as the things they are wrapping, which probably isn't desirable - all they actually need is the package being wrapped.
<mbakke>alextee: were you able to test the new fontconfig?
<mbakke>alextee: you'll need a "myfontpack" variable that computes to a single output containing all the fonts you want (just propagating won't work), and then pass that to the grafted fontconfig
<kamil_>mbakke, how do I get to define a package in a local Guix repository if it is already to be found in /gnu/store??
<kamil_>Whoops, one extra redundant question mark. Sorry!
<alextee[m]>mbakke: nice! i'll try later - not sure i understand 100% but i'll ask if i need help
<mbakke>kamil_: Guix doesn't know how to find things in your store unless you have a derivation that evaluates to that thing. When you used '--with-sources=<new-meson>' earlier, Guix computed a custom Meson derivation on the fly.
<alextee[m]>also another issue i have is with loading external plugins. they need some libs that are only present in the distro (like freetype) and dlopen () fails. a dirty hack is passing LD_LIBRARY_PATH but it seems it doesnt work well everywhere. is there a nice way to accomplish loading external plugins with their dependent .so's?
<alextee[m]>just addding /usr/lib64:/usr/lib somewhere would work on 90% of distros, but im not sure where to specify this
<mbakke>alextee: Guix uses RUNPATHs heavily to cope with that, but I'm not too familiar with how that works with 'guix pack'.
<mbakke>alextee: probably you just need to link the executable with -Wl,-rpath=(string-append (assoc-ref inputs "freetype") "/lib")
<mbakke>though the 'validate-runpaths' phase should have complained if you had any loose freetype.so references
<jonsger>why do I need to build /gnu/store/bydyl62p3lwjhdrd65w2mizpqndlr16c-guix-1.1.0-4.bdc801e.drv? it doesn't even appear on cuirass with this hash
<alextee[m]>mbakke: oh i could try linking with -Wl,-rpath=/usr/lib then. will that also replace the runtime paths that the pack looks in? ideally i want it to look there first
<alextee[m]>i mean i want it to look wherever the pack is already looking for libs (inside gnu/store), and then if not found, look in /usr/lib
<mbakke>alextee: Ideally all libs would already be available, it's one of the big selling points of Guix that everything uses exact versions of all dependencies :-)
<mbakke>alextee: the ld wrapper will not even allow adding /usr/lib on RUNPATH unless you set a special variable ;-)
<kamil_>mbakke, Oh, that makes sense. Well. Where do I start?
<alextee[m]>yeah that doesnt work with external plugins though
<civodul>certainly better than plan F, which itself was an improvement over plan E
<reepca`>I managed to get a working unshare-guile program, but then I found out that unshare(CLONE_NEWPID) didn't do what I thought it did - it just makes it so that the next process it spawns is PID 1 in that namespace, it doesn't make itself PID 1 in the new namespace...
<reepca`>it also prevents the calling process from ever spawning threads
<alextee[m]><civodul "typically dlopening them would f"> would static linking solve this?
<kamil_>civodul, the problem is that I need to build a dependency of a package that I also need to build