IRC channel logs
2024-01-16.log
back to list of logs
<rebiw>Can guix deploy be used with guix home ? (I have a host with alpine + guix but not a guix system) <ulfvonbelow>it seems that --sources=transitive doesn't delete duplicates <ulfvonbelow>hmmm, or rather perhaps it does, but not for the overall result (for example, if --manifest was given and specifies many packages) <Gooberpatrol66>the environment-variables field in home config is supposed to set environment variables in shells, right? it doesn't seem to do anything <freakingpenguin>Gooberpatrol66: Are you extending home-environment-variables-service-type? Variables are placed in .guix-home/setup-environment, make sure your .profile is sourcing that. <ulfvonbelow>and actually, package-transitive-sources seems to be either broken or mis-specified. What it actually does is gather a package's implicit and explicit inputs, compute the propagated-inputs closure, and get the direct sources for each package in it. So for example, guix build --sources=transitive -e '(@ (gnu packages rust) rust)' includes the source for rust 1.70 and 1.69, but not the 15 or so beneath them <ulfvonbelow>(my local branch is a few months old, rust may have been updated since then) <Gooberpatrol66>freakingpenguin: the config file was auto-generated with environment-variables from my bashrc under home-bash-service-type <Gooberpatrol66>grep doesn't find one of the variables anywhere in the ~/.guix-home directory <Gooberpatrol66>so the variables are being added to .bash_profile, but it's never sourced by anything <mange>.bash_profile should be sourced by a bash login shell, I believe. If you run "bash --login" then you should see the variables set in that shell. Logging out+in should do the same thing. <mange>Although I vaguely remember something where GDM will log in a (maybe only Wayland?) session without running a shell, so without sourcing the .bash_profile file. I can't remember the solution to that. <mange>So you have a file in ~/.bash_profile which is exporting the environment variables, but they're not showing up in a login shell? That's... odd. <mange>Well, that's different to what bash's man page says should happen, so I don't really know what to do with that. It says a login shell will source /etc/profile then the first of ~/.bash_profile, ~/.bash_login, or ~/.profile that it finds. <Gooberpatrol66>i don't understand how it's supposed to work, if it sources profile it won't source bash_profile, and it only puts variables in bash_profile <ulfvonbelow>when you say "sourcing profile", you mean /etc/profile, right? <mange>Are you running it as "bash", or as "sh"? If bash is run as "sh" then it loads ~/.profile instead of ~/.bash_profile. <Gooberpatrol66>idk what guix is doing, but when i run "bash" it loads .profile still <ulfvonbelow>interesting, the manual says it should try ~/.bash_profile first <adanska>Hi, I'm trying to build a package definition im running (wip: https://paste.debian.net/1304246/ with backtrace) and its giving me a really cryptic error (In procedure cdr: Wrong type argument in position 1 (expecting pair): #<gexp (begin (use-modules ((guix build utils)) (guix utils)) (find-files "." (lambda (x) (equal? (file-extension x) "asd")))) <adanska>/home/ada/Projects/Guix/guix/gnu/packages/text-editors.scm:1153:8 7f3b2f4b3d80>) <adanska>I don't know where to even begin. If I understand how to use gexps this should be perfectly legal, right? (im going to manually put in all the asdf files later for better transperancy, this was just a time save i was trying) <ulfvonbelow>well, if we visit guix/build-system/asdf.scm and look in asdf-build, we find that it appears to right off the bat call (cadr asd-systems) <ulfvonbelow>;; FIXME: Find a more reliable way to get the main system name. <ulfvonbelow>and the default value of asd-systems in that procedure is ''() <ulfvonbelow>which suggests to me that they're doing something hackish where they recognize that asd-systems is supposed to be evaluated build-side, but they try to do some cursory analysis on the host-side anyway <efraim>sneek: later tell podiki berlin is up to rust-1.62 on aarch64 and finished building mesa finally <ulfvonbelow>adanska: long story short, yes, a gexp *should* work, but it doesn't, because of a hack in asdf-build-system. <ulfvonbelow>it's assuming that asd-systems has the form of (quote (...)) <ulfvonbelow>and cadr on that produces the list that would be produced when that is evaluated <adanska>thanks for showing me this! i guess ill just list all the files manually.... <ulfvonbelow>I suspect that the hack in asdf-build is trying to glean information from a sort of "common" case, with the understanding that it should gracefully fall back if it can't, but it was probably written before gexps were even a thing <adanska>yeah, i had a look at the build system earlier and noticed that it seemed pretty old <ulfvonbelow>anyway, try replacing your #~ with ' and maybe it'll work? <ulfvonbelow>ah, but scrolling down a little, it looks like asd-systems is actually evaluated in the build-side as an argument to the build-side asdf-build procedure, before any phases (including 'unpack) are run <adanska>oh. well then my little hack wont work at all :/ <ulfvonbelow>well, you could always figure out which phases actually use #:asd-systems and wrap them, but it does seem a bit involved <adanska>might just write a little oneliner to get all the asd file paths and just paste them in <adanska>what is the `lp` procedure in ice-9? <ulfvonbelow>it's some nondescript inner procedure used for tail recursion purposes <ulfvonbelow>but I believe the problem you're encountering is that your '("lem.asd" ...) form is being evaluated twice: once on the host side, and then again on the build side <ulfvonbelow>on the build side it just looks like ("lem.asd" ...) <ulfvonbelow>so it looks like you're trying to use a string as a procedure or macro <adanska>huh... isnt #:asd-systems meant to be a list of pathnames? <ulfvonbelow>it's meant to be something that, once ungexp'ed, will be evaluated in the builder to produce a list of pathnames, but that can't be a gexp itself for contrived reasons <ulfvonbelow>you could either add another quote, making it ''("lem.asd" ...), or you could change it to '(list "lem.asd" ...) <ulfvonbelow>any idea how one would go about doing something like the --sources=transitive option to 'guix build', but for 'guix system'? <efraim>you could try `guix system build ... -d' and then 'guix build /gnu/store/...-.drv --sources=transitive' <ulfvonbelow>does package-transitive-sources even work with derivations? <efraim>not sure, but it wouldn't take long to find out <ulfvonbelow>right, I'm looking at it now, and it seems the first thing it does is call package->bag on its argument, so... probably not <mekeor>hello. i have a custom package (emacs-next-motif) which used to work but now errors with "Server does not allow request for unadvertised object" as if the specified git-commit does not exist on remote while it actually does. what going wrong? https://paste.debian.net/hidden/bcc36b49/ <futurile>anyone using a nitrokey (I'm trying to figure out OpenPGP cards this morning) ? <mekeor>jpoiret: it looks like something is wrong with my package definition. `guix package -i emacs-next --with-commit=emacs-next=774c8ec74c98d69d56b2511a613145f2b69fb2eb` works just fine <jpoiret>mekeor: remember to also use (file-name (git-file-name ...)) when you change the git-reference <jpoiret>does it work if you don't inherit the git-reference but just specify it completely? <jpoiret>there might also be a transient savannah issue <mekeor>jpoiret: thanks for the advice. i'll need some time now to look into those. :) <futurile>nvariani: welcome, how you finding Guix so far? <jpoiret>what do we think about adding patches as simple origins instead of bundling them in Guix? <mekeor>jpoiret: what does "patches as simple origins" mean? <ulfvonbelow>I think it makes sense when the patches originate from outside of guix, but any patches that originate in guix should probably be kept in-tree <jpoiret>most patches we have are backported patches I think <jpoiret>so they originate from outside of guix <ulfvonbelow>for example, it makes sense for patches for de-turdifying browsers that are already published online to be used as origins <jpoiret>ulfvonbelow: do you know if SWH also indexes url-fetch origins? otherwise that might not be a good idea for reproducibility <ulfvonbelow>I do not know; last I heard they only did VCS repositories, but that may have changed <jpoiret>well apparently they can archive non vcs repos, but you can't use an API to request it yourself <ulfvonbelow>unrelated note, but I guess the closest thing to --sources=transitive for derivations would be building the transitive inputs of a derivation, but only the ones that are fixed-output or inputs of a fixed-output one <makx>mhm. I am trying to build a rockpro64 image ( by running: ./guix-soc/bin/guix system image --target=aarch64-linux-gnu -e '(@ (gnu system install) rockpro64-installation-os)'); it errors out while building nspr; the error message appears to be "nsinstall is missing". <makx>since everything on the internet i s terrible: is there some hints as to how I can search whether this is a known problem somehow? <mekeor>in this case, i could not find useful information <Guest9034>Hello, my guix command is broken, I can no longer run guix pull. I get "guix pull: error: unsupported manifest format". <Guest9034>Other guix commands seem to work, but I'm unable to reconfigure anything since it also has lost all memory of the channels I added as well. <rekado>Guest9034: generally, this means that you’re using an older Guix than the one you’ve installed at ~/.config/guix/current <rekado>Guest9034: what does “type guix” tell you? <Guest9034>which guix returns /run/current-system/profile/bin/guix <rekado>does ~/.config/guix/current/bin/guix exist? <Guest9034>Yes, I tried running it now, but it says the same thing, but this time I got some more output as well <rekado>do you get the error on “guix pull” only? <rekado>do you mean that ~/.config/guix/current/bin/guix pull also returns the same error? <Guest9034>Yes, only on pull. And yes, that one returns the same error, only a bit more verbose <Guest9034>My computer died because of empty battery right before this happened, so maybe something became corrupt? <rekado>what does ~/.config/guix/current/manifest look like? <Guest9034>I don't remember what exactly I did when it died, but it was definitely either guix pull or reconfigure or something <Guest9034>Yes, I understand that, but I need to fix my computer <rekado>what you can do is to roll back to a previous version of Guix with “guix pull --roll-back” <rekado>and then use ~/.config/guix/current/bin/guix pull to pull from there <Guest9034>I already tried rolling back both the system and the home, in which way is this different? <Guest9034>guix pull --roll-back fails with the same error <rekado>the problem is with the profile that “guix pull” uses <rekado>you can manually change the symlink of ~/.config/guix/current to point to an older generation of the profile <rekado>pick a generation that has a non-empty manifest file <ulfvonbelow>guix pull --list-generations I think, if it can work <ulfvonbelow>or you could ls /var/guix/profiles/per-user/<youruser> <rekado>ls -lad /var/guix/profiles/per-user/$USER/current-guix* <villageidiot>I'm neck-deep in guix home now and I'm at the point where I want to make sure that *only* the packages I've declared in my home config are available to my user. How do I get rid of the packages that I have installed here and there with `guix install`? <Altadil>villageidiot: with guix remove (autocompletion should show the packages) <Guest9034>I changed the symlink to point to a working generation, but guix pull still fails <villageidiot>Altadil: Thank you, so guix remove cannot remove anything from the guix home config? <Altadil>villageidiot: I believe so, but you can guix home reconfigure afterwards to make sure everything you want is indeed installed. <rekado>Guest9034: is ~/.config/guix/current correct now? And are you using ~/.config/guix/current/bin/guix pull? <Guest9034>I don't know if it is correct, but at least it is now pointing to a generation with a non empty manifest <Guest9034>And I tried several different generations from a wide timespan <Guest9034>It would be very helpful if the error message could say which manifest it thinks has an unsupported format, and what is wrong with it <ulfvonbelow>when I try 'guix system build <config.scm> -d', it starts building a bunch of stuff, which is not what I want, I just want the system profile derivation, and when I add '-n' at the end, it lists 6 or so derivations that would be built and then stops... <rekado>ulfvonbelow: you may want to try “--no-grafts” <rekado>Guest9034: it’s annoying that it doesn’t print more info. It should only attempt to read the manifest file of the profile it is operating on, i.e. ~/.config/guix/current/manifest <rekado>Guest9034: if you want to be sure, you can try using strace, but that’s a bit messy <Guest9034>Can I try to use root's guix to fix it somehow? I think that one might be working <ulfvonbelow>ah, looks like --no-grafts did the trick, thanks rekado. Although does that mean that the derivations for the sources of the replacements won't be present? <rekado>we’ve been trying to do essentially the same thing but with older generations of your own user’s guix <ulfvonbelow>note that you can explicitly specify which profile 'guix pull' acts on using '-p <path>' <Guest9034>So, if I do sudo guix pull, will I do anything? <ulfvonbelow>that will use root's guix to act on root's guix I believe <ulfvonbelow>if not and you're on guix system, it might use the system guix instead <Guest9034>So, then I don't use sudo, but instead run it from an actuakl root shell? <ulfvonbelow>I'd say give '/run/current-system/profile/bin/guix pull' a shot, and maybe try having it pull to a fresh profile, e.g. '/run/current-system/profile/bin/guix pull -p ~/testguixprofile' <Guest9034>sudo guix pull is working, but it was way behind. Need to pull almost 2000 commits <Guest9034>ulfvonbelow: That was the guix I was using first according to "which guix" <Guest9034>So, I succesfully pulled with sudo, but this doesn't seem to have fixed anything for my user <Guest9034>ulfvonbelow: Hey! using a test profile seems to have done it! <Guest9034>So what is the next step now? Can I rebuild ~/.config/guix/current if I simply delete it and pull with the system guix? <ulfvonbelow>~/.config/guix/current is actually just a symlink, so if you readlink it first and record what it was, it should be hard to irreversibly break anything <Guest9034>I deleted the ~/.config/guix/current, but I still get the unsupported manifest. Which manifest can it be talking about now, there shouldn't be one? <Guest9034>Yeah, I've save a backup of the orignal symlink <Guest9034>Do I need to specify a profile when trying to pull now? <ulfvonbelow>hmmm, so the manifest issue occurs specifically when using the default pull profile? <ulfvonbelow>I'm curious what would happen if we add '-p ~/.config/guix/current' <ulfvonbelow>my guess is that it's looking in /var/guix/profiles/per-user/$USER and doing some fiddling around with previous generations of that profile <ulfvonbelow>and one of those previous generations has a bad manifest <Guest9034>it pulled succesfully now, but it still did not fix my normal guix pull <ulfvonbelow>yeah, so the interesting thing there is that the file system corruption has created a highly unusual situation <ulfvonbelow>the profiles themselves are in the store, which is supposed to be immutable <ulfvonbelow>and yet the magic of a power outage has mutated one or more of them <Guest9034>I think it is just the latest one, at least that is the only one with an empty manifest <ulfvonbelow>to keep guix pull from choking on those profiles, I guess the proper thing to do is to delete them <ulfvonbelow>just removing the symlink from the /var/guix/... location should be enough <ulfvonbelow>note that once this is more or less resolved, you may want to run a guix gc --verify=repair,contents <Guest9034>Now I got a different error at least. It says it is migrating profiles .../per-user/..., but fails because the current-guix-1-link exists <ulfvonbelow>maybe just move away all of the current-guix* from there for a bit? <ulfvonbelow>so that hopefully it will act like it's starting from scratch <Guest9034>That seems to have made it a little more happy <Guest9034>I think it is fixed now. guix pull finished succesfully, and I am now able to run both guix home reconfigure and guix system reconfigure. Is there anything else I should ccheck to make sure everything is good again? <ulfvonbelow>that 'guix gc --verify' stuff I mentioned before. Aside from that, nothing comes to mind. <Guest9034>Well, that one is giving a whole bunch of errors and it seems to run forever <ulfvonbelow>it's iterating over the entire store, so I'd expect it to take a long time <Guest9034>It repeats 3 different errors: unexpected hash, cannot repair path, and error parsing derivation. <rekado>these parse errors are likely due to .drv files that are truncated to 0 <rekado>reboot into a recovery system and then repair your file system first <Guest9034>I can do it now. I thought usually fsck was run automatically when needed, but I guess that might have been a systemd thing when I was running other distros <cdo256>Hi Guix, If I'm packaging a package that has a fair number of inputs, should I add the independent libraries first and work my way down the dependency tree, or send a patch in that adds them all at once? <cdo256>Relatedly, should each commit be one package, or is it okay to add more than one package per commit? <rekado>cdo256: one commit for each package addition please <rekado>cdo256: order the commits so that there is never a commit that introduces variables provided by later commits <cdo256>So no mutually recursive packages ;) got it. <graywolf>Hi, does anyone here use debbugs in emacs to respond to debbugs issues? How do you typically do it? r? S w? S v? And on what in the summary? <rekado>cdo256: yes, that wouldn’t work anyway. We “unroll” recursive dependencies by adding -bootstrap variants. <villageidiot>I just installed emacs-doom-modeline which properly pulls in emacs-nerd-icons, but it seems I need to add a Nerd font myself because right now the glyphs are not rendered correctly. The question is: should emacs-nerd-icons pull in some default Nerd font? <villageidiot>Or maybe that's not possible due to licensing or something. I'm just trying to understand if the package could be enhanced. <villageidiot>Guest9034: Thanks, that works. It installs the font for the user, but I was wondering if it would make sense to install the default Nerd Symbols font into the store with emacs-nerd-icons. <Guest9034>I agree. I currently don't manage my emacs packages from guix, but when you are doing that it totally makes sense to have the font included in the package <villageidiot>As a dependency, yes. It could be a licensing issue or something, I didn't find any of the nerd fonts in the guix tree. <civodul>looks like bibtex doesn’t automatically find .bst files <sneek>Welcome back civodul, you have 1 message! <civodul>is there a trick to get bibtex to find .bst files? <Guest9034>I haven't needed to do anything special to make bibtex work, but I don't seem to have any .bst files <civodul>Guest9034: .bst file are BibTeX bibliography styles <Guest9034>Did you add this file yourself or is it generated by something? <rekado>there are a lot of failures on i686 <Guest9034>I use hugepages for virtual machines and for now I have been manually mounting them on each boot, but now I want to add them to my file-systems record <Guest9034>guix doesn't like that there is no device, what can I put into the device field to satisfy it? <Guest9034>Anything I can do with the mount command should also be possible through the guix system config, right? <jpoiret>Guest9034: depends, we use the mount system call, not the mount binary <Guest9034> (options "rw,relatime,pagesize=1G,uid=997,gid=984,mode=0770") <Guest9034>Okay, I see the massive typo on the last line, but I don't think that is the whole problem <Guest9034>after fixing (type "hugetlbfs") and some other unrelated stuff in my config I get a different error: In procedure mount: mount "hugetlbfs" on "///hugepages": Invalid argument <Guest9034>Is there any way I can see the exact mount command it is trying to run? <jpoiret>it's not running a mount command, but the mount system call <jpoiret>I can't seem to find docs for hugetlbfs <Guest9034>What I did previously was this: mount -o rw,relatime,pagesize=1G,uid=997,gid=984,mode=0770 -t hugetlbfs hugetlbfs /hugepages <Guest9034>hugetlbfs is a thing that is built in to the kernel <jpoiret>hm, hugetlbfs should be supported. Are you sure your mount-point exists <Guest9034>I'm using the same mountpoint as in the command I was running manually <Guest9034>As you can see from the command I posted and my file-system record <Guest9034>I removed the options field and now it is working <Guest9034>Something very strange is going on here... I removed the options field and then I was able to reconfigure the system once and have the fs mounted. I then tried adding in one option at a time to see when it would fail. However, subsequent reconfigurations seemed to just ignore any changes to the file-system record. I even unmounted the mount manuaally and now it does not mount it or produce any error no matter what options I add <Guest9034>Oh, I see. The filesystem is a shepherd service and it does not always get restarted on a reconfigure <podiki>efraim: thanks for the status update! <sneek>podiki, efraim says: berlin is up to rust-1.62 on aarch64 and finished building mesa finally <Guest9034>Further testing shows that it works with (options "rw") but if I add any more options, for example "rw,relatime" it gives me invalid argument. The manual shows examples of multiple options comma separated, so it should be correct <Guest9034>Finally figured it out! It was relatime that made the error. If I remove only this option and leave all the others there everything works fine. And the mount also shows that it does get mounted with relatime anyway. <Guest9034>I think this should be considered a bug, right? relatime is a very common mount option, giving invalid argument for this one is bad <podiki>i think it is specified as (flags '(no-atime)) or similar <podiki>i would think you could put it in options as well the ones in flags, but i'm not sure the underlying logic <podiki>or is that just for noatime? not sure now <podiki>isn't relatime part of defaults? <bumble2>hey everyone what is the correct way to close a bug at debbugs as resolved? <janneke>"When a bug is resolved, please close the thread by sending an email to <ISSUE_NUMBER-done@debbugs.gnu.org>." <Guest9034>podiki: relatime seems to be part of the defaults yes, so I did not in fact have to add it. It was simply a part of yh original mount command that I was using before. I would think many people just copy their mount options from elsewhere when creating a file-system record, so it shouldn't fail like that when given a normal correct option <podiki>yes, or some output to letyou know, and/or clearly note in manual <jpoiret>Guest9034: mount the binary has a different calling convention and set of options compared to mount the system call <Guest9034>jpoiret: Okay, but at the very least the output should have said which option that was wrong. It didn't even tell me that the error was in an option at all, it just said "invalid argument" <jpoiret>the mount system call doesn't say which one is I think, it just errors out and sets errno to an error number <jpoiret>that's a common issue with linux system calls, you never know what part is wrong, only the error number <jpoiret>mount the binary is a couple thousands kLOC <Guest9034>btw, this is a very common thing in guix, that the error messages have absolutely zero useful information in them <jpoiret>huh, they even implement some btrfs parsing, wtf <Guest9034>It is very frustrating to spend hours or even days hunting down the cause of an error because the error messages are not even trying to be helpful <jpoiret>what's the consensus on packages that are both user-facing binaries and libraries needing some propagated inputs because of pkg-config? <jpoiret>yay, gnome just built on core-updates <rekado>janneke: or maybe it should be marked as supported only on x86_64…? <janneke>rekado: dunno only one test fails -- but yeah someone would have to put in some work <janneke>wondering what's up with all the failing python tests though <rekado>the test output for samtools is a bit weird <rekado>grepping for “failed” I see many more accurity tests failing <rekado>I’ll update first and see what can be done about this <janneke>ACTION looks an another random (but now python) package <janneke>i wonder how these are doing on debian <efraim>or I'm reading it backwards and tests are ignored on mipsel <efraim>I was reading it backwards, from the changelog: Allow tests to fail on mipsel due to lack of memory <janneke>ah, so we're @1.14 and debian is at 1.16.1 -- that may already fix it... <efraim>they're actually at 1.19 in unstable, 1.16.1 is in their current release <janneke>okay, but if some arches fail it won't make it into testing, iirc <efraim>1.19 built everywhere for them except hurd-amd64 <janneke>(which also used to be the reason that testing was unbearably "old", seems you can never win at this game :) <dariqq>If a program needs additional env vars to enable some functionality should these be added to the program or the service that starts it? <dariqq>it's about the accessibility menu in gdm <PotentialUser73>Hello, is anyone here familiar with running cuirass. What I'd like to have is a main cuirass instance (that is also running guix publish) that use remote workers to distribute the build jobs, similar to how I understand the guix substitute and CI servers work. I think that is all reasonably straightforward to set up based on the manual, however <PotentialUser73>what I didn't see was an explanation of how to submit ad-hoc builds to the cuirass server. I would like to be able to write a new package or specify a manifest of existing packages and then have cuirass handle the build for those package(s). I'm aware that cuirass can be provided a manifest in it's specifications, but I'd like to be able to <PotentialUser73>instruct it to do new builds "on the fly" of packages it hasn't seen before. Is this possible? <redacted>I've got a copy of the guix source and built it, and I've got it in Geiser's load path, but it's not finding definitions when I M-. <redacted>like so: geiser-edit-symbol-at-point: Couldn’t find location for ’operating-system’ <podiki>PotentialUser73: maybe you want offload directly? <redacted>janneke: does that do something that (add-to-list 'geiser-guile-load-path "~/src/guix") doesn't? <redacted>Maybe the GUILE_LOAD_COMPILED_PATH is important, and adding to geiser-guile-load-path doesn't have the same effect? <apteryx>gcc-toolchain doesn't add gcc:lib to the union; should it? <apteryx>I guess not, since GCC seems able to find its things without having to do so <apteryx>it's just weird to run 'find' on a gdc-toolchain package and not find e.g. libgphobos.so <podiki>i think we should add gcc:lib to gcc-toolchain at a minimum <podiki>i don't have any knowledge on the static libraries brought up in that discussion though <jpoiret>dariqq: depends on the env var specifically <janneke>redacted: yes, but then pointing to ~/.config/guix/current/... <dariqq>jpoiret: XDG_DATA_DIRS. The shepherd service for gdm sets it but this causes gdm to not find some stuff to make the accessibility settings work <dariqq>the missing paths are from gnome-settings-daemon (for the icon), dconf (to be able to change the settings) and at-spi2-core (some accessibility dbus services that i do not understand). <dariqq>i am currently adding them to the XDG_DATA_DIRS via the gnome-shell-assets field of gdm-configuration but this feels like a dodgy fix <redacted>janneke: right, but don't I want to load modules from the source directory in ~/guix where I cloned the guix source code? <jpoiret>weary-traveler: have you tried it out? <redacted>(it also doesn't work, setting those variables gives the same error) <podiki>PotentialUser73: i don't know anything about offload, sorry, just linked to the manual; the general idea as far as i know is to be able to always send a build job to another machine <podiki>PotentialUser73: which is different than cuirass and those jobs as far as i know; you can just send a build to another guix machine <jpoiret>dariqq: they're all expected to be there for a working gdm install, right? <jpoiret>if so we should be adding them to the default value for that field <jpoiret>we always have trouble with those kinds of variables for eg. login managers <lilyp>weary-traveler: I know I'm not unbiased enough to be reviewing my own patches, and this one cuts deep <mfg>Hi, i noticed that gcc-cross-avr-toolchain does not contian all files for all mcus, i.e. crtattiny85.o is missing. Is this on purpose or am i missing something? <mfg>i'm inside `guix shell make avrdude gcc-cross-avr-toolchain' <mfg>also: avr-ld can't find -lm and -lc <weary-traveler>jpoiret: not yet. i wasn't sure if there were some known issues and an updated version is being worked on or not <weary-traveler>lilyp: how can i help? i'm fairly experienced with emacs. i'm a relative newbie with guix (submitted <10 patches) <jpoiret>submitting ≥ 1 patch is already being experienced i would say though :p <janneke>redacted: yeah you probably want that <janneke>but we can't set it up to do so for all users on a foreign distro <dariqq>jpoiret: Sure but still this feels like the gdm package should take care of finding the stuff it needs rather than me adding some packages to XDG_DATA_DIRS manually <weary-traveler>yes, the "relative" in "relative newbie" is meaningful. perhaps a "somewhat experienced newbie" <PotentialUser73>podiki: I'm not sure if that's quite what I'm looking for. The whole remote workers thing makes sense but I'd like a way to be able to send a request to cuirass to build a specific package, regardless of whether or not that package was included in cuirass' specification file. <podiki>as I said, I don't know more than what i told you, but someone else probably does if the manual isn't clear <jpoiret>dariqq: unfortunately that's how parts of the gnome ecosystem work, by looking into some "standard" env vars and auto starting stuff. <PotentialUser73>Right no worries, I just wanted to make sure that was clearly stated here in case someone else happens to see it <podiki>how can i make a service that needs to run before another (in this case to set up a docker network before oci-service)? <podiki>should I extend the later service and add some sort of activation action? <jpoiret>podiki: activation actions should be avoided as much as possible, prefer one-shot shepherd services <jpoiret>any reason you can't just use a regular shepherd service though? <podiki>what do you mean regular shepherd service? in this case i want to run "docker network create somenetwork" before oci-container-service runs so that the containers can all be on the same network <podiki>so i need this new service to be before oci-container-service in the dependency tree right? <jpoiret>then a one shot shepherd service is probably what you want. What I meant is that you could've had a long-running service in the background that would basically do nothing until it stopped. <PotentialUser73>Regarding my cuirass question: it sounds like admins are able to add specifications via the web interface, so I think that will work for me <podiki>or is it possible in make-forkexec-constructor to do more than one command essentially? (because then I could just modify the service definition instead or make it handle creating a network if needed) <dariqq>jpoiret: ok then i'll just send a patch extending the manual XDG_DATA_DIR creation. Should I send this as a new issue or send the patch to the bug already opened? <jpoiret>podiki: iirc you can do something like (lambda (the args) (do something) ((make-forkexec-constructor ...) the args)) but I don't remember what the outer lambda's args are supposed to be <jpoiret>you should have a look at the shepherd doc for the format of the start and stop slot <jpoiret>dariqq: you can probably send it to the already opened bug if it resolves it <lilyp>weary-traveler: the status quo is works-for-me™ <podiki>jpoiret: thanks. I looked earlier but now see an example with a lambda (and no args :) ) as you mentioned. so I'll try and modify oci-container-service to handle running an extra docker command and ending with the make-forkexec-constructor..... <podiki>basically what you suggested. will just have to try and see if it works! <jpoiret>lilyp: wasn't there the issue with grafts? <lilyp>that's exactly what the patch aims to fix :) <weary-traveler>lilyp: i see. and if i want to try them out i should install them on the latest emacs-team branch ref? <lilyp>it's a little outdated atm, hope you don't mind traveling back in time a bit <lilyp>I don't recall it being updated on master since the 29.1 bump, but I might be mistaken <weary-traveler>lilyp: for patch v4 i only see 4/5 and 5/5. where's v4 1/5, 2/5, 3/5? <lilyp>probably with v3 still – I swear, if I find out who at Google decided to silently drop mails is a good idea… <weary-traveler>type above, v3 only goes up to 3. should work out if v4 added new patches over v3 instead of reworking anything in it <weary-traveler>lilyp: what's interesting is that andrew's response on the issue mentions v4 1/5. i'm guessing he was cc'd and received it, but somehow got dropped from issue <weary-traveler>at least his response gives a comparable which confirms that v4 1/5 is the same as v3 1/3 <jpoiret>huh, don't we have a problem with pkg-config static linking when the static output is separated? the lib paths in the .pc file are wrong in that case <jpoiret>i don't understand how our current cryptsetup-static could possibly build <apteryx>podiki: interesting; in my case it seems unnecessary though I was confused by the empty :static output of gdc-toolchain and the lack of .so in its /lib directory <apteryx>gdc appears to link to gdc:lib without having to propagate it <apteryx>the main output keeps a reference to its lib output <apteryx>and defeats the "lib" output in this case <apteryx>I'll bring it up to this bug, perhaps we can simply merge "gcc:lib" back into its main output <jpoiret>okay, I *definitely* do not understand how cryptsetup-static builds <jpoiret>on c-u it's trying to link with every single .so file it can, and we don't even have static outputs for some of the libraries! <podiki>apteryx: not sure about those details you mentioned :) only familiar with that bug in relation to things with guix shell and needing libraries that aren't public after move from gcc->gcc-toolchain <podiki>jpoiret: thanks, managed to just add an (invoke ... before make-forkexec-constructor and it worked <podiki>jpoiret: that is, all wrapped in a (lambda _ ... outer form