<leoprikler>w.r.t. rust inverting inherit trees, it normally makes sense to inherit newer package versions from older ones
<leoprikler>but rust crates are special and do it the other way round, no idea why
<raghavgururajan>It seemed newer versions inheriting older versions odd to me. Older versions are likely to get removed/deprecated and we have to remove inherticance to newer versions. If vice-versa, just knock the older version out and newer version stays untouched.
<brendyn>I think I may have just done it: ((lambda* (#:key tests? #:allow-other-keys) (if tests? "-DBUILD_TESTING=ON" "-DBUILD_TESTING=OFF")))
<apteryx>but you could wrap the whole arguments in a (let ((your-shared-variable ...)) ...)
<brendyn>So I have #:configure-flags `("..." ,((lambda* (#:key tests? #:allow-other-keys) ... )))
<dhruvin>bricewge: To make sure sourcehut's builder's home directory exists before creating a gitconfig for it, I created a shepherd service that requires "user-processes". It worked without any issues. Let me know if that was the right thing to do.
<bricewge>dhruvin: Nice! That's what I would have done too.
<dhruvin>Update: sourcehut's build image for guix is ready, well almost. The only thing left to do is to provide right initrd modules. I believe default ones are okay. Let me know if there are any suggestions.
<attila_lendvai>lilyp, what i want, ideally, is to only include that directory, and preferrably without a subdir. i'm adding a snippet to delete everything else, and a chdir... but i really wished there was a better idiom for this. it comes up often.
<lilyp>dhruvin: given that restriction, what about - repositories: - channels: <paste channels.scm> - substitutes: <paste substitute acls or whatever>
<attila_lendvai>lilyp, it's e.g. trezor-firmware, that has a fw and a python side that must be more or less in sync, and they sit in the same git repo (which makes sense), and this repo is tagged python/v1.2 and firmware/v2.3 (not sure about this, but i've seen it before multiple times)
<lilyp>Okay, but let's say you have a given trezor-firmware package [firmware side] and then want to generate the corresponding python thingy, can't you just inherit the origin?
<nckx>You wouldn't expect projects to keep distributing a release that was found to include copyright-infringing content (as happened to a Doom clone, I forget which one). They'd probably even nuke the git history. For Linux-Libre, this is morally equivalent.
<nckx>That doesn't mean it doesn't suck for you, and I really appreciate the effort you put into this package.
<lfam>I think that removing old Git history is beyond the pale in this case
<lfam>There's no copyright violation to speak of, in reality
<maximed>is there any particular reason for --no-grafts here?
<civodul>maximed: or "pigx", it's the package with the biggest graph
<dstolfa>alright, i'm preparing another backup in a datacenter. hopefully that'll be enough
<civodul>maximed: depends on what you want to benchmark, but if you want roughly package->derivation, then --no-grafts is what you need
<nckx>Before someone rings up fort Knox or that dodgy datacentre under a nuclear mountain thing, let's remember that tarballs regularly disappear because the author needed space, their $free Web host went tits-up, or they mistyped an rm without backups. Guix is ultimately the place to fix that if it's so important.
<lfam>Yeah it's true, but this is not "just some project". Most projects as foundational as the kernel do tend to get preserved both internally and externally. But linux-libre is kinda niche in general, while being crucial to Guix. So it's less likely that we'd find backups somewhere unless we made them ourselves
<nckx>I agree, and was going to add that but it was long enough already :)
<muradm>root cause is not laying with licensing/free/nonfree etc, it is beyond, these things are really just tiny subset of problem, thus one will always strugle to find workarounds for tiny subset of problem
<muradm>lfam: since i didn't get feedback yet on seatd-greetd-services thing, i'm going to prepare another update with these anyway now https://paste.rs/LVh .. :) one of things is to move seatd into gnu/packages/admin.scm as we discussed, currently no package seems to depend on it, so i suppose it is safe to move the package straight away, right?
<muradm>lfam: another thing is seatd source can build libseat library and seatd daemon in two build commands, or both in one go, i could a) specify multiple outputs b) provide 2 separate packages, i'm for 2, personally. but this will duplicate version and hash twice, adding something function in gnu/packages/admin.scm like (define (make-seatd-source) ...) is fine? rather than copy pasting (source (origin between two packages
<bricewge>I'll do my best to send a a review to the patchset
<nckx>“libglvnd is a vendor-neutral dispatch layer for arbitrating OpenGL API calls between multiple vendors […] and determines which vendor to dispatch each API call to at runtime.” Both ‘vendors’ here scan oddly (you're not sending RPCs to Nvidia's head office) and seem to be mere euphemisms for ‘proprietary driver’. Is that correct?
<muradm>bricewge, if you whish just wait, i'm preparing v6 now, then we can go over it
<muradm>i was using libglvnd when i was on arch, with my integrated intel and nvidia eGPU :)
<nckx>muradm: I don't know if it's retrograding. My very, very early understanding (which may well be wrong) was that Guix had an extra indirection library inserted into its default GL stack only and explicitly to support proprietary ('vendor', winkywink) libraries.
<muradm>if you just have libglvnd as a package, i suppose it would not be enough to just use it
<nckx>What Nix does here might not be relevant; they support non-free software.
<lilyp>I think the question is this: What does libglvnd enable you to do with only free software, that you can't already do with only free software sans libglvnd?
<nckx>There's not always a sharp line of what the right thing is for Guix, but ‘adding code & complexity that is only useful on non-free systems’ always crosses it.
<nckx>But Guix won't provide APIs that are useful only to non-free software.
<nckx>Well, that's probably not true in practice because one of our 20k packages probably does just that, but we won't *knowingly* put *effort* into complexifying Guix and maintaining more code just to enable that.
<muradm>does it mean that providing library that can load non-free library is providing api that support non-free software?
<nckx>But if the graphics stack of Guix is now more prone to breakage because of libglvnd *and* it turns out that libglvnd provides no value to free software users at all, that means all Guix maintainers are wasting effort (core-updates debugging, etc.) maintaining a more complex stack just to support your non-free driver. That's not OK.
<nckx>muradm: Depends on why Mesa won't support it (and why are you then writing your own GL, which is presumably more work)? I'm less interested in hypotheticals that aren't than about the current state of things that are.
<nckx>Conversely, if current or future Mesa makes it almost impossible to build without glvnd support, even if it is purely to support malware, I'm not saying we have to spend excessive effort to undo that. It would just be… unfortunate.
<nckx>Guix maintainers would still be sponsoring non-free software, they'd just not have any choice.
<bricewge>`modify-services` should at least warn the user in such case
<podiki[m]>nckx: catching up on messages here, re: libglvnd, we removed that change for the mesa update
<podiki[m]>it is just a version bump (and there is a patch for core-updates-frozen to go more up to date, mesa moving much faster than our core-updates process)
<minikN>bricewge: Can yuo tell me what the `dbus-configuration` object has to contain? Can't quite figure it out.
<podiki[m]>as per the discussion on those patch threads, probably using libglvnd with mesa will require some minimal changes to dependents that hardcode libgl library locations, and at least then current guix stuff should work the same
<podiki[m]>as for what that gains us in the non-free space, not sure
<podiki[m]>at least one application I think is with multiple graphics cards, where you need different libgl providers
<minikN>bricewge: I tried `(service dbus-root-service-type (dbus-configuration (services (list blueman))))` but I guess this is wrong, giving me: `guix system: error: more than one target service of type 'dbus'`
<bricewge>minikN:Yes you etheir need to modify the dbus-root-service-type or expand it (like the snippet I shared previously)
<podiki[m]>(mesa has also had libglvnd support for ~4 years, don't see why they would require it, but what do I know)
<bricewge>I don't get, it did you to reconfigure your OS?
<bricewge>If so is there any file like “/etc/dbus-1/system-services/org.blueman.*”?
<minikN>After I added your snippet I cd'ed into the folder containing the scms and ran `sudo -E guix system reconfigure -L . ./geekcave.scm`. Contents of `/etc/dbus-1/system-services/`: https://paste.debian.net/1210428/
<bricewge>Ok, the OS configuration is correct since you have blueman files in /etc/dbus now
<minikN>bricewge: Should this be set automatically or did I miss some configuration?
<bricewge>Your window manager should be srated with "dbus-launch " command to get the approriate environment variable
<minikN>bricewge: I'm using sway. I did not add any specific configuration apart from using sddm instead of gdm (because apparently it doesn't work with sway). The exec command in `/gnu/store/qsbdijqvq1wzf65xlflkcb2yj246s1nc-sway-1.5.1/share/wayland-sessions/sway.desktop` is just `Exec=sway`. I reckon this needs to be altered?