IRC channel logs
2024-09-12.log
back to list of logs
<PuercoPop>sepeth: why does packaging neovide require multiple sources? It has a single repo afaiu <piethesailor>Hello All! I am not sure what happened.. but I am trying to run 'guix pull' and suddenly almost all of my packages are hold conflicting entries of libraries inside the various packages I have installed <mange>Hmm. I'm not sure exactly what you mean. Is "guix pull" failing? Can you be more specific about the output you're seeing? (Put it in a paste if it's lots of lines.) <piethesailor>guix install: error: profile contains conflicting entries for gstreamer <piethesailor>guix install: error: first entry: gstreamer@1.22.3 /gnu/store/ymnj8h0hbq2gx258am60x7yn3gl700px-gstreamer-1.22.3 <piethesailor>guix install: error: second entry: gstreamer@1.22.3 /gnu/store/0xbi8znjczfqqhr8wfj7hi2gyw0bcmh0-gstreamer-1.22.3 <piethesailor>guix install: error: ... propagated from gst-plugins-ugly@1.22.3 <mange>That looks like it's from "guix install" rather than from "guix pull". Can I assume your "guix pull" command succeeded? <piethesailor>no it also returns this as it wants to upgrade one my other packages. This is happening to all of my packages <piethesailor>oops.. Yes*, however it also returns this as it wants to upgrade one my other packages. This is happening to all of my packages <piethesailor>Oh you know what I am confusing things..I am a mess today. Guix pull does succeed. it is just when I try to run guix upgrade <piethesailor>I think I might have temporarily disconnected there for a second <mange>I was waiting for you to get back. :) <mange>When you're running "guix upgrade", are you limiting the packages which are getting upgraded at all? Or just a bare "guix upgrade"? <mange>The issue you're having is that Guix is trying to upgrade some packages, but not others, and there are conflicts in their propagated inputs. <mange>I can't remember exactly how "guix upgrade" decides what to upgrade, but I think you can resolve the errors like that with "guix install". In the case of your paste, I would expect "guix install ffmpeg mpv" to update them both to a compatible version. <piethesailor>It does that for when I 'guix upgrade' and for individual packages like 'guix package alsa-lib' <piethesailor>guix install: error: profile contains conflicting entries for alsa-lib <piethesailor>guix install: error: first entry: alsa-lib@1.2.11 /gnu/store/86qsca6pr5z51b5s6fsam7n52lg428ph-alsa-lib-1.2.11 <piethesailor>guix install: error: second entry: alsa-lib@1.2.4 /gnu/store/lzl6ajjyf17fmrdra1q5mjrymgwg1xvz-alsa-lib-1.2.4 <mange>Okay, so now add alsa-lib, too. <piethesailor>hint: You cannot have two different versions or variants of `mpv' in the same profile. <mange>Also, this is too many log lines. <mange>Essentially, just follow the messages and keep adding the final "propagated from ..." packages into your "install" command. Presumably there is some way to get "guix upgrade" to do them all, too, but I don't use it. Maybe "guix upgrade ."? <mange>Mmm, unfortunately I don't really understand "guix upgrade". I have run into this issue before, and I started using "guix install" to fix it (in the way I mentioned above), but eventually I moved to using manifests and Guix Home instead. <piethesailor>interesting.. Thanks anyway! I might give these a look, manifests and Guix Home <piethesailor>So I have reduced the list of pacage issues to alsa-lib, ffmpeg, mpv, and all the gst-plugins-*** <piethesailor>I wonder if, as before, instead of guix installing alsa-lib, ffmpeg, and mpv. Could I remove them and reinstall? <piethesailor>I am afraid if I do that, I will not be able to reinstall. and I really like having mpv around <oriansj>piethesailor: guix requires very little; but individual programs will always have their requirements. <piethesailor>yeah that did not work. oriansj: I am not sure what that means <piethesailor>for instance I just guix removed those three packages. Now if I try to guix install them. I am getting an error saying that my profile contains two different versions of ffmpeg which is weird cause I just removed ffmpeg. If I try to remove the oldest of the two ffmpegs it says I it is not found in my profile <piethesailor>despite the fact it does think that I have two in my profile.. :thinking_face: <oriansj>and then do guix package --manifest=$FILENAME <mange>You don't need to be afraid of making changes. You can use "guix package --roll-back" to undo changes to your profile. Whatever you have now you will be able to get back to, if needed. <piethesailor>Okay. Let me make sure I understand. You mean to say I should, say, run $ guix package -I. then take that list and format it the code you pasted, save and then run that command <oriansj>piethesailor: make the file first then run the command <mange>It's important to read the messages that Guix prints carefully. If it's complaining that you have two ffmpegs it should be telling you what is pulling them in. The solution to the problem is to install *those* - ffmpeg is the symptom, but the packages trying to install conflicting versions is the actual problem. <oriansj>and if there is an issue, just use a pastebin to give a copy of the manifest so that people can help you figure out the why. <mange>You can also use "guix package --export-manifest" to generate the manifest contents that oriansj is talking about. <piethesailor>will do oriansj. mange: I hear you, but I guess I am confused by the fact that it is circular. I am following the messages and I get back to where I started <piethesailor>is it worth trying on a subset? (specifications->manifest '("alsa-lib" "mpv" "ffmpeg")) <piethesailor>and say save it to ~/tmp.scm and guix package --manifest=$FILENAME ~/tmp.scm <mange>I think that's about the same as running "guix shell alsa-lib mpv ffmpeg". <piethesailor>ah I see so I ran that command and now I am in a terminal that I presume only has those three loaded <piethesailor>and with this manifest method I need to run this somehow before or in replacement of my profile? <mange>It has added those three, yeah. No error means that those three can coexist in a profile without issue. <mange>The manifest is a declaration of what you want the profile to look like. "guix profile --manifest" updates your profile to match the declaration. <piethesailor>I suppose that might mean then if the pastebin I posted did work, than my profile would be reduced to those three packages? <mange>Hmm. I've just checked ffmpeg, and my Guix only has up to 6.1.1. Where is 7.0.2 coming from? <oriansj>piethesailor: are you specifying that version? <mange>Right, okay. It looks like ffmpeg-7 was added a little while ago, in commit 1ac27c7a66. It left the old ffmpeg value in place, to avoid rebuilding everything. That means that mpv and your profile legitimately use different versions of ffmpeg. <mange>The good news is that you can fix it by specifying "ffmpeg@6". The bad news is that it's annoying. <piethesailor>? also again, by running this method, will my profile be reduced to these three packages? <mange>Yep. It would also work with "guix install ffmpeg@6", but I don't know if that would persist between "guix upgrades" (I think not). <mange>And yes, that manifest will reduce your profile to the three packages specified. <piethesailor>well.. id like to continue using the regular guix pull/install/upgrade cycle if I can <mange>One option is to remove the explicit ffmpeg in your profile. Since mpv is pulling it in anyway, you don't need to include ffmpeg itself. <piethesailor>fair enough. though that still leaves me stuck. I have guix removed ffmpeg, mpv, and alsa-lib <piethesailor>so I dont know how to further get rid of ffmpeg if its gone, but gui install mpv still complains of its existence <piethesailor>Ill do youre advice of guix install mpv gst-plugins-ugly <mange>What do you mean by "is profile a file somewhere?"? <piethesailor>guix remove: error: package 'ffmpeg' not found in profile <piethesailor>like I said it is not in my profile but one of my previous pastebin errors says there is both @6 and @7 <oriansj>piethesailor: well a profile is just a link to a forest of links to programs/libraries; which is why rolling back and forward is cheap <piethesailor>I think I might just do that at this point. I feel like I am really draggin you guys around. <mange>The most recent error you pasted was for mpv and gst-plugins-ugly, and was related to util-linux at the same version but with a different hash. That should be resolved by "guix install mpv gst-plugins-ugly". <mange>Now that one is odd. :/ How do you have two different versions of gst-plugins-ugly explicitly installed in the same profile? Both "propagated from" chains end in "gst-plugins-ugly@1.22.3". <mange>I don't understand how that is possible. <mange>Okay, that's not true - I do understand how it's possible in theory, only by manually crafting a weird manifest file. Not by using the CLI like this. <piethesailor>not to my knowledge. I only know about manifesting from this conversation <mange>Using a manifest file would probably make the issue go away. You could at least do it once to set the profile up how you want it right now. You can generate a manifest from your profile with "guix profile --export-manifest > manifest.scm", then you can instantiate it with "guix profile --manifest=manifest.scm". If that doesn't work, then please put manifest.scm into a paste. <amano>There is no haskell-language-server package on gnu guix. I want to develop haskell softwares with haskell-language-server or something like it on neovim and emacs. Is it even possible to get a haskell development environment on gnu guix? <mange>I often make that mistake, because the "guix package" command is used for manipulating profiles. <piethesailor>I did install the common lisp lem editor by a file somehow some time ago <piethesailor>gnu/packages.scm:551:4: In procedure specification->package+output: <piethesailor>removed that from the manifest file and that seems to execute <jmes`>In the guix graphical installer, can one interject to add a channel introduction at some point? <amano>It seems I will have to use cabal to install haskell-language-server. <amano>How many maintainers are there for guix channel? <AwesomeAdam54321>amano: There are 41 members of various package teams listed in ./etc/teams.scm <bdju>agreed. feel free to bring in some more help ;) <amano>bdju: I think the problem lies in the fact that the core team has to trust more people faster. <amano>It's a problem of expanding trust. There are certainly contributors. <bdju>that's not the roadblock I see, but it could be true I suppose. personally I find both the packaging and contribution processes to be overwhelming and currently I just do the occasional bug report <bdju>half the time I bring up an issue someone asks me if I want to try to fix it or send a patch so I never got the feeling that trust was the blocker <amano>bdju: There are contributors whose patches are ignored for years. <bdju>that is troubling. maybe a dedicated triage person or two could help dig up some of that old stuff <amano>If they were given commit access, everything would go faster. <amano>I think expansion ultimately boils down to third party channels... which are not bottlenecked by core maintainers' inability to trust other people. <amano>Gentoo has many official package repositories and also many third party repositories. The way to expand is to have more official channels. <amano>Perhaps, haskell packages can have a separate channel. <podiki>note that as far as i know everyone is a volunteer doing this when the can/feel like it and we're still quite small <podiki>however many thousands of packages is a lot, across more architectures than others too (to varying degrees of working, but still) <podiki>plenty to work on, but more resources (people and machines) seems like the real bottleneck to me <podiki>if i had funding to do this fulltime i would, and i think even just a few people fulltime would be a huge difference maker <apteryx>does guix-daemon uses (guix script substitute) (the 'substitute' command) from its own package? <efraim>I'm going to guess no, but I've never checked <apteryx>OK, found it; the 'guix' command comes from settings.guixProgram in the guix-daemon sources <apteryx>and it's manually patched to refer to '/var/guix/profiles/per-user/root/current-guix/bin/guix' in the 'guix-daemon' package definition. <apteryx>hm, this file name doesn't exist on my Guix System <apteryx>I've never ran 'guix pull' as 'root' on this system, that's why. What does it use then? <mihec>hi. I'm having quiet a lot of problems with installing guix system on my T480. After instalation last night i did guix pull and then system reconfigure. At first I got some exception and the on second try the pull succeded. But reconfigure hanged for like an hour and then the system froze so I force shut it off. Today guix pull succeds but system reconfigure errors with: error parsing derivation '...': expected string 'Derive([' <mange>See if there's something corrupted in your store? <mihec>I did a gc delete of path that was causing issues. Should now first pull and then reconfigure? <mange>If a delete worked, then I don't think you'll need to re-pull. If "guix describe" looks recent enough (i.e. matches your last pull) then just a reconfigure should be fine. <mange>That said, it might have the same result as last time. Hopefully with some more time you might get substitutes rather than needing to build stuff. <mihec>how do I know from the output when stuff is building and when its just fetching? <mihec>ok now it fails with different derivation...I will just delete all that popup and see how it goes <mange>"guix gc --verify=repair" could help? <mange>I think you could use "guix system build", which prints more verbose output (I think...). Then, when you reconfigure it will be cheap because it's already built/fetched everything. <apteryx>civodul: the change-default-guix phase of the guix-daemon package has no effect; can we remove it? <apteryx>(and if it did have the intended effect it'd break on my system, as there's no /var/guix/profiles/per-user/root/current-guix/bin/guix on my system <apteryx>efraim: so to answer my question, based on my reading of the guix-daemon code, it finds the /guix command relative to its own bindir <civodul>the phase has no effect indeed, so it’s probably safe to remove <civodul>so $GUIX was introduced in 2e3e5d21988fc2cafb2a9eaf4b00976ea425629d (Sep. 2019) <civodul>‘change-default-guix’ was added in 74781c65f3d5294ea7da12366bf0fd22b08b381b (same month) <civodul>i think the goal was to have a good fallback for ‘guixProgram’ for when $GUIX is unset <civodul>but since 765a5bf1677ad6bc77ed65df4f63da9ef77bb55a, ‘guix-daemon’ as installed with ‘guix pull’ always has $GUIX set <civodul>so the fallback value is never used in practice <civodul>so i think it’s safe to remove that phase <civodul>and yes i think we should also update the ‘guix’ package at some point <civodul>so i guess we/you could apply #73000 and then update ‘guix’ <civodul>i talk but the phase has already been removed :-) <civodul>we should have discussed this on the issue tracker <cbaines>hmm, /var/lib/certbot/renew-certificates exists on bayfront, but no longer reflects the system configuration <cbaines>which is confusing, and it also breaks things if it's run <cbaines>it just reflects an older system configuration <cbaines>I noticed this as it's missing git.qa.guix.gnu.org <cbaines>it looks like the script stopped being updated in 023c3e0ac44e7fc35eeebc87535a47df2cd01485 <intermet>Hi there! When write a package definition, how can I specify a branch in git-fetch? <intermet>Oh a commit includes the branch information? I didn't know. Thx <janneke>no, a commit identifies a commit; it can live on several branches, or on not any branch <apteryx>civodul: sorry for being in a hurry, I was hoping to be able te quickly update the 'guix' package, now debugging test suite failures <apteryx>civodul: it's not just not used in practice, the phase didn't actually modify the source :-) <apteryx>so the removal of the phase was a no-op, functionally <apteryx>I put (error #t) in the phase and checked the source; it was like the original <civodul>still useful to know why the phase was added in the first place <apteryx>civodul: yes, thanks for adding the original context. <apteryx>in what kind of scenario were the negative TTL values being felt as too much? <apteryx>in my experience, what I've felt was that pase discovered substitute servers would be kept for too long <apteryx>but it's been a while I've actively used such setup <apteryx>I've rubber stamped #73000, but if you feel like expanding the context in which the current values were problematic, please do! <civodul>apteryx: the negative TTLs are too long for Cuirass/Build Coordinator kind of scenarios, where you might want to retry if a given substitute isn’t available <civodul>by default, you’d have to wait for at least 10mn before effectively retrying <apteryx>ah, I see! that makes a lot of sense <civodul>i replied to that issue with more context <civodul>elpogo: interesting; i guess we could add an option or command to emit a podman ‘containers.conf’ if that proves to be useful <civodul>oh, that’s Giuseppe Scrivano replying there :-) <civodul>(familiar name from GNU/good old days) <elpogo>he seemed nice. is he a Guix dev too? <efraim>this wide-integer failure on aarch64 and riscv64 is fairly vexing <intermet>janneke: therefore I need to give the branch as well? <elpogo>civodul: btw, creating the containers.conf with mounts is the easy part. I'm still investigating why I'm having to set LD_LIBRARY_PATH=/lib for external applications using the guix rootfs as the base. It has something to do with "--emulate-fhs" running "ldconfig -X" but not saving it in the profile I think. Once I figure it out, I would like to add a "-f rootfs" or "-f podman_rootfs" option to "guix pack". Hopefully that'll be my first <elpogo>Also, special thanks to whoever keeps the podman package in Guix so up-to-date these days <apteryx>elpogo: since this post, 'guix pack' has also grown dpkg and rpm output formats :-) <efraim>looks like it also fails on ppc64le but not armhf <civodul>rpm, dpkg, and there’s also squashfs, if that’s something podman can consume <elpogo>Yeah, but not as efficient as bind mounting a profile and its /gnu/store requirements <apteryx>lechner: your guile-pam software looks cool. I look forward to review it (but currently still a bit under water) <apteryx>tests/cran: tar: /home/maxim/src/guix/test-tmp/store/7a7gwdclb3a9zf0dqckl7dnar6kqv71l-My-Example_1.2.3.tar.gz: Cannot open: No such file or directory <apteryx>I guess this cran package archive is gone upstream? <apteryx>oh, nevermind, it's a package we create ourselves <apteryx>ACTION tries blindly changing .gz for .zst <Kabouik>This shows everytime I start Fish shell, or when running commands in shell. <civodul>elpogo: woow, that one looks quite involved <civodul>Kabouik: is ‘LD_LIBRARY_PATH’ set? if so, can you try “unset LD_LIBRARY_PATH”? <civodul>then it’s probably that /run/current-system/profile/lib/gio/modules/libxfconfgsettingsbackend.so is using the previous libc (2.35), but the Xfce program that triggers this is itself using the newer libc (2.39) <civodul>(maybe you ran ‘guix package -u’ but not ‘guix system reconfigure’?) <Kabouik>To be honest I'm not even sure why I have Xfce stuff. I use Sway. Perhaps I installed it as a fallback but never use it. Unfortunately guix package -u is broken too: https://0x0.st/XxWc.txt <Kabouik>civodul: no, no I did run `guix system reconfigure` two days ago and today <apteryx>Kabouik: I've seen this kind of problem as well, usually resolved after a reboot <apteryx>rarely occurs, only when glibc is upgraded <apteryx>not sure if that's supposed to be handled more gracefully, I thought nscd played a role in that <apteryx>weird. changing (match url ...) for (match (pk 'url url) ... in tests/cran.scm resolves the test failure <Kabouik>Rebooting is the first thing I tried sadly apteryx :< <Kabouik>(Because it's the one thing I can handle fairly well.) <apteryx>oh, 'sudo rm -rf test-tmp/' also looks like it fixed that failure <janneke>intermet: the only way to identify a branch would be by naming that branch <janneke>there's no provision for that in git-reference, because why would you want to? <civodul>janneke: hey! no provision for what? <janneke>civodul: hi; intermet wanted to name a branch in git-reference <mgd>Hello all. Sorry for the spam my account created earlier. I had issues connecting with icedove. I'm trying to use a .sec.pgp file. I think the command is gpg --decrypt file.sec.pgp. I'm used to seeing a dialogue window that asks for my passphrase but nothing is coming up. This is on Gnome <janneke>no idea why, they didn't respond to that question :) <apteryx>I think the crate test is failing since 9f44ff2bb47c964d53905cea17c4bda758cce509 <civodul>janneke: oh, ok; that would be ‘git-checkout’ then, which allows you to grab the latest commit of a branch <apteryx>do we still have to use labels on #:cargo-inputs ? <podiki>berlin hasn't built master in 36 hours <nckx>apteryx: Maybe too late, but yes, we do. <nckx>while setting up the build environment: executing `/gnu/store/lgi9x15a0w35mcpd7g1kb9274r6wy4pv-guile-bootstrap-2.0/bin/guile': Exec format error <nckx>file /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash #the interpreter <nckx>/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.30, stripped <zamfofex>Hello, Guix! I have a small piece of feedback to share: A lot of my struggles in Guix have been running existing pre‐compiled blobs. Unfortunate as it may be, that was something I oftentimes wanted to do, and Guix made it fairly difficult. I have recently decided to try using NetBSD (just to see how it might go), and it is somehow better at running existing Linux programs than Guix! (Despite not even being Linux!) <zamfofex>I installed a GNU/Linux base (glibc + some other miscallaneous packages from SUSE) from pkgsrc, then enabled the `compat_linux` kernel module, and I am able to just download plain Linux binaries and run them. <Rutherther>zamfofex the problem is mainly that Gux is not fhs compatible. You can However do a few customizations to make it more fhs friendly. Alternatively you can simulate fhs with containers. Guix shell even has a option for that itself <Rutherther>Apart from that Guix also focuses a lot on bootstrapability so you wont find many tools for packaging pře-made binaries in Guix channel <zamfofex>Yeah, I know that. The problem I was running into is that I needed to keep exposing things to the container, and the command line quickly got quite large. <zamfofex>It also took time to craft a command line that worked well enough for different programs. <zamfofex>Oftentimes I’d resort to using ‘patchelf’ in some way or another, but that also took time. <zamfofex>I think I have shared here before that I wish packages weren’t installed on a global store, but rather on a user‐specific store (so that different users didn’t see each other’s packages). I have always felt like a reasonable thing would be for Guix System to, on login, do some kind of ‘chroot’ magic to set up an FHS‐like root for the user, where they have their own namespace to install/use packages. <zamfofex>Of course, that would be fairly different from how it is today, but it always felt to me like I wish that was the direction taken instead. <ieure>zamfofex, Not sure I follow. You say you want that "so that different users didn’t see each other’s packages" -- I'm not sure I agree that they do. <zamfofex>Well, if I install a package, a different user can see that package on the store too. <ieure>The pool of all packages on the system isn't the same thing as the subset of those packages in users' profiles. <zamfofex>The problem is that in a multi‐user system, a user might prefer to keep their installed packages private from others, so that they don’t know what they are installing. <zamfofex>Specially in a system like Guix, where you can set up your own custom channels and packages that live alongside the official ones. <ieure>The store doesn't say that -- it says that, at some point, some user used that package. use != install, some time != now, some user != a specific user. <Rutherther>You can of course change the path to the store. But you will lose all substitutes <zamfofex>That is fair, but ideally if I install/use/download/build/whatever something I want to keep secretive, I don’t want for others to even have a hint that I might have been the one who had it appear on the store. <ieure>What's an example of a package that should be hidden from other users on the system? <zamfofex>I can’t think of anything specific. Maybe something related to piracy, for example. <ieure>Is there something related to piracy which doesn't also have a legitimate purpose? I regularly, say, download Free Software like Linux installer ISOs with BitTorrent. <zamfofex>(Bold of you to say piracy isn’t a legitimate purpose.) I feel like you might need a bit (but not much) of imagination to figure out why someone might not want for all of the programs they use to be able to be known to others. <zamfofex>Besides, I acknowledge most users will be running a system for only oneself. The most significant actually pragmatic takeaway would be that this new ‘chroot’ root would be more FHS‐friendly (akin to something like GoboLinux), the privacy thing would be a secondary benefit in my mind, simply because it doesn’t matter for how most people use their computers. <ieure>Will just note again that presence in the store *does not* mean a user has it installed. If you run `guix shell some-package -- some-package', that will stay in the store until `guix gc', but isn't installed or actively used by anyone. <zamfofex>I acknowledge that, but an indication that you might have used it can be significant enough. <ieure>Sounds like Tails might be a better match for your paranoia level. Not being glib, that's an honest suggestion. <ieure>The problem with having per-user stores is that it'd bloat disk usage significantly, because you have to store N copies of packages instead of 1 -- and Guix is already disk-hungry by the standards of traditional Linux. <ieure>Also not sure what that'd mean for the daemon architecture; as is, the daemon runs as root and manages the store. If the store is owned by the user, you lose the immutability guarantee of the store. If it's not owned by the user, it'd have to be in like /var/guix/your-pid/store or something. <nckx>These are two separate things: the store doesn't have to be per-user (what would be gained by that? root already sees all), merely not world-readable. The root daemon would do its rooty stuff, but ~magic~ would expose required references to processes/users on an as-needed basis. <nckx>You're already ~magically~ exposing stuff in this model, so why not keep a single store. <nckx>(Not advocating for Guix doing this, just saying it could be done.) <nckx>…I guess then you could get into far-out weeds like timing attacks (guix build rtorrent && returns within 3 seconds && arrest this man) I guess. <podiki>can someone nudge/prod/kindly ask berlin to build again? <nckx>No but I can try kicking it in the shins. <nckx>2024-09-12 19:55:20 evaluating spec 'master' 🤷 <nckx>And it's shown up in the UI too. I don't know what happened. Nothing was logged in an obvious place. <podiki>ain't nobody/no thing like a kick to the shins <nckx>System administration by motorcycle boot. <podiki>last time civodul mentioned some switch or something in mdc sending junk that freezes up cuirass <podiki>IT Crowd's "did you try turning it off and on again?" will never not be applicable, no matter how advanced we get <podiki>(that, and the closely related "is it plugged in and turned on?") <nckx>podiki: If it's on, try turning it off. If it's off, turn it on. Or leave it off, & all your problems will disappear. If they don't, turn off your pager too. <podiki>ieure: i'm not sure, but i also rarely see QA status (either too old or too new), i think it just takes a long time to process and some never make it in time? <ieure>podiki, Is there some way to tell? Or to make it retry? <podiki>submitting a new version of a patch i think gets qa to try again (like for patches that are too old), but i'm not sure of anything else <podiki>i wonder how much is inherent inefficiency in how this has to work (building guix) and just raw resources to throw at it <ieure>These are two and three days old, respectively. <podiki>that's not too old from what i know <podiki>but probably depends on how many patches are submitted <podiki>if you haven't already, you can see previous discussions and progress reports on guix-devel list that will have details i don't remember <podiki>(or yes, ask cbaines directly, the magician doing the hard work here!) <ieure>Being slow/inefficient is one aspect, I'm more annoyed that the process is a black box, so I never have any idea what's going on or what to do about it. <ieure>Mostly, this means I completely ignore QA, because I just get frustrated with the process. <podiki>yeah, i think it is great when it works but it hasn't been able to keep up usually <podiki>i applied for a big grant that i didn't get, and that sort of infrastructure improvement (and governance) were top of my list to do <podiki>i tend to look at smaller patches and just build locally, luckily i have a pretty fast machine <nckx>I can't log into Fedora Weblate, it just hangs and eventually times out. Have I said today that computers? And a grave one at that. <efraim>the adjustment to pass-age removed bash-minimal from the list of inputs <nckx>Does it computer (say) each system separately? <podiki>i don't know the answer, but also observed seeing jobs started before the evaluation is finished <podiki>not sure if it is just that jobs start going out before the full set is ready or what <nckx>Oh, okay, I assumed there was some batching at all but that's indeed not a given. <nckx>s/computer/compute/ but computers gonna computer, poot poot. <podiki>but i also know nothing about cuirass other than a few buttons on the web interface :) <podiki>efraim: things still progressing for mesa-updates on aarch64/others? with some fixes in now x86_64 and almost i686 have good coverage <podiki>powerpc64le is shaping up on berlin as well <podiki>guix refresh says libseat has only 18 dependent packages, but is there anything else to be aware of for updating it? <Franciman>if i do guix home roll-back, ho can i then go ahead in time? <Franciman>sorry, dumb question, i forgot how many times i ran roll-back, so i don't know which generation i'm on currently <Rutherther>just use the list-generations subcommand that will show you which you are on currently, and also the newer ones <Franciman>now i just have to figure out what changed from gen 126 to gen 127 <Franciman>that's where telegram-desktop starts doing sigfaults on startup <nckx>podiki: Indeed, evaluation #1626765 just jumped from 170 to 332 builds, so it is indeed doing useful things in parallel. Thanks for the sanity check. <podiki>anyone know of gotchas for updating libseat and seatd? refresh shows just ~15 dependents which i built locally but maybe i'm missing something? <dariqq>how difficult is it to create a custom variant of a service-type to modify e.g. its shepherd extension (extra environment variables in forkexec-constructor, not autostarting, ...) if the configuration does not expose it <podiki>nckx: really? contributors are people now? what next <nckx>To be fair I meant it mainly in the style of Soylent Green. <nckx>Now I hope it didn't come across as mocking non-native speakers. Was not meant to do. English was more or less designed to be misspoke. <podiki>that/which/who/whom/etc. trip up anyone <mgd>Is there an issue with icedove currenty? I'm not able to install 115.14.0. Getting an error <mgd>error: in phase 'build': uncaught exception: <mgd>%exception #<&invoke-error program: "./mach" arguments: ("build" "langpack-af") exit-status: 1 term-signal: #f stop-signal: #f> <mgd>phase `build' failed after 37.4 seconds <ieure>I mean... sure seems like it? <mgd>well I guess I'd feel better knowing I wasn't the only one <nckx>Self-service betterment. <nckx>I… guess that ‘Config object not found by mach.’ is the error? <meaty>Would a package for a game with a free engine but "freeware" assets/artwork be allowed on the main channel? <dariqq>wrote something terrible to inherit from a service type everything but setting the shepherd auto-start? field to #f. Relatively easy because everything is either a record or list of records. Might not be possible to this with the make-forkexec-constructor gexp and extra environment variables <meaty>specifically I'm thinking about packaging "Dr. Robotnik's Ring Racers" <meaty>the engine is open source and the game is free but the artwork is property of the artists <ieure>meaty, I believe so. For example, gzdoom and ScummVM are in Guix, and I think those are in the same realm of what you're talking about. Fully Free Software engines which are often used with non-free data. <[>ieure: gzdoom doesn't include anything nonfree and can be used with freedoom <nckx>Packaging the engine is fine assuming it's free as described, but packaging the _game_ as a whole (which is how I read your question, meaty) is not. <[>tome4 would be a better example: it's packaged, including nonfree artwork, in Guix. It's allowed in Guix because apparently the nonfree artwork does allow unlimited redistribution (but not modification or use with a modified version), and it counts as "Non-functional data" according to the FSDG. <[>I disagree with this interpretation because game data is not "non-functional" and think tome4 is nonfree and should be removed <nckx>The whole non-functional gambit is… weird, IMO. <nckx>But OK, I didn't know the tome4 situation, so I guess packaging the _game_ is fine by current precedent if not uncontroversial. <[>"All graphical, audio and music assets are granted to use with the Tales of Maj'Eyal game only." Nowhere does this mention distribution <nckx>meaty: I might also be reading ‘property’ more strictly than intended. Do you have a handy link to the actual artwork licence? <[>The FSDG's definition of non-functional data is self-contradictory. It provides game graphics and game world maps as specific examples of non-functional data, despite the fact that they're not non-functional since the game is unusable without them. <nckx>Then it's reasonable to assume that they don't consider that a contradiction. <meaty>is it functional data if the unmodified engine will only work with the right checksum on the assets? <meaty>by "their" definition anyways <[>just patch the check out of the engine, then that's not a problem