<podiki>graywolf: we don't have any specific package maintainers, but thanks for noticing this. you could submit a bug report or email the security email list; probably we will do a quick graft update just as for the current ones
<podiki>abidiff for libx11 was clean, again as an amateur just doing abidiff on the .so
<mekeor>nckhexen: with "project preference", you mean that this patch forces the guix conventions on all emacs users (who use guix)? personally, i think the .dir-locals.el of the guix repository should suffice for this.
<nckhexen>So you think the current behaviour isn't broken?
<mekeor>nckhexen: i don't know, tbh. but we don't want to fix all upstream bugs. where do we draw the line? personally, i believe, patches should fix problems that arise from packaging the software for guix; not for fixing general problems with the software package itself.
<podiki>nckhexen: i guess we find out who's been playing by the rules for linking with libxpm....
<nckhexen>I think the odds of this being an issue are tiny, and on the other side there's a CVE. Although I didn't check the severity, I think that justifies a test-and-push-and-fix-if-needed approach here.
<nckhexen>Plus I think this bump merely puts us on par with most distroes that don't rebuild the world because a README changed.
<podiki>taking a quick look at curl, seems we are out of date by a major version number (if it matters here). maybe the cve won't affect us?? :) otherwise maybe we should take the week to see if we can/should update curl first
<graywolf>One of those CVEs is over 8000 days old iirc, so let's hope it is the LOW one? :)
<graywolf>Update would likely be good, no idea how much work it involves though; I assume if not much, it would be done already...
<Guest10>what packagers usually do when package makes use of file modification time?
<Guest10>i guess there is no way to set file modification time in /gnu/store?
<arst>Hey everyone! I've been using Linux for several years now, but this is the first time I've used anything like Guix. Guix requires an internet connection to install, which is a problem because I need the nongnu package "rtl8821ce-linux-module" to get that. I've tried doing that using this article here: https://willschenk.com/howto/2019/installing_guix_on_nuc/, but it doesn't work. I created a
<arst>guix image with wsl and booted it, but wasn't able to get wifi even though I put the needed package in "config.scm". Any ideas?
<arst>Also, I don't really know lisp, so it could be a problem with my code, but I copied everything from the article and the Guix Manual, and was able to build the image just fine so idk.
<graywolf>arst: You can also create an install image from that channel that shall not be named (discussing it here is offtopic)
<graywolf>Oh, when I look at the release page for 1.4.0 on that unnamed channel, there even is an install iso
<podiki>lucypoo: i use bluetooth without full DE, let me see...I have bluetooth-service-type and blueman (dbus rules) and probably needed a relogin or restart to get it going
<Kolev>Can I use `guix home` in place of `guix install`?
<ddan>I can't import a guix package after exporting it using archive; I always get the same error on my machine.
<ulfvonbelow>it seems like if one has an offload machine, and a local build hook is waiting on that offload machine's load to come down, and then on the offload machine a bunch of other builds are started that are a superset of the ones being offloaded to it, the local build hook will wait until the load comes back down before noticing that its jobs are already done.
<Kolev>I did guix home reconfigure but new packages are not in PATH.
<Zambyte>Kolev: Did you start a new shell after reconfiguring?
<civodul>did you write down somewhere what you diagnosed?
<civodul>were there many files in there on the build nodes?
<attila_lendvai>rekado, regarding pip trying to download while runnin the test suite of a package, and the use of a _custom-backend to avoid that: isn't there a simpler way to tell pip where the dependencies are? some python env variables?
<lilyp>There is a simpler way: Don't call pip from check, dummy
<efraim>civodul: I'll write it up in an email and send it to guix-sysadmin and then we can figure out where a good spot to document it should be
<attila_lendvai>a related issue is that the is_process_started_by_superserver call in python-daemon returns False in the build daemon. i suspect that this is true for some reason: is_socket_file(sys.__stdin__). could it be the case? it's trying to detect whether it was started by the "internet superserver".
<rekado>civodul: uhm, what’s the problem with kreuzberg?
<cbaines>this is very similar to just emailing XXXXX@debbugs.gnu.org saying this patch looks good to me, except that QA prompts you to email email@example.com as well and tag the patch as reviewed-looks-good
<Guest10>and funnily enough: when you upgrade manually (by going to gnuzilla.gnu.org/mozzarella), it installs the xpi, which comes from addons.mozilla.org (it's a link), and then the so-installed addon upgrades directly through addons.mozilla.org
<Guest10>so gnuzilla.gnu.org/mozzarella is just a fake store
<euouae>cbaines: is there a way to find patches that have not been reviewed?
<cbaines>euouae, if you click through to issues.guix.gnu.org for a particular patch/issue and there's only emails from one person, then it probably hasn't been reviewed
<cbaines>euouae, as for the difference between issues.guix.gnu.org and qa.guix.gnu.org, issues.guix.gnu.org is a bit of software called Mumi, and it's an interface to the Debbugs bug tracking system
<cbaines>as for qa.guix.gnu.org, it's the qa-frontpage which is meant to help with QA things around Guix, including doing some automated testing of patches
<podiki>on ungrafting: i was going to ungraft the libx11 and libxpm with the next mesa update, which should be real soon (technically 23.2.1 is not the first stable release but .2 will be out soon)
<euouae>cbaines: great, thank you. a visual cue that an issue hasn't been reviewed would be nice, right?
<podiki>for convenience I could ungraft more on that branch (mesa-updates), what would make sense?
<euouae>cbaines: perhaps at the least show a visual cue if only the author messages are present
<cbaines>euouae, indeed, I've been thinking that would be a good thing to highlight on the qa.guix.gnu.org list of patches, and I think it's possible to get that information from Mumi/issues.guix.gnu.org which is good
<podiki>a discussion on guix-devel, in light of the onslaught of CVEs this month?
<podiki>non expert on the security side but i generally have time to help coordinate at the least
<podiki>I think we need an expert on guix internals for guix-specific security, and then some people to coordinate/patch/review things like basic security grafts/updates
<podiki>trying to update mangohud which now tries to bundle a specific vulkan-headers version
<theesm>Maybe it'd be a good idea to also have folks on the OSS-Security linux-distros list (don't know how realistic that'll be as I don't know much about the list other than its purpose and that some distors are participating)? I can imagine that it could help reducing research/newstracking overhead for CVEs affecting software packaged for guix
<podiki>since it is only needed for mangohud, better to use a bare origin as input?
<civodul>podiki: help on coordination would be much welcome; and as you write, it’s primarily about security issues in packages
<civodul>for issues in Guix itself, the team can ask core developers
<gabber>Guest10: i sense that your intention is not that easily weldable with the guix sense of how things work. e.g. installing in guix means "adding something to some profile's PATH". that being said: pretty much everything is possible due to Guix's hackability
<Guest10>well i guess that's the difference between "pretty much everything" and "everything"
<ieure>Hold up, the argument that setting the mtime to... the time the file was modified is "a gross abuse of the POSIX specification?" But that setting it to 0 isn't?
<ieure>Or is "version" here some kind of monotonic number, like version 1 = mtime 1, version 2 = mtime 2? I agree that's a gross abuse.
<gabber>ieure: of course it is -- but a necessary one in this case
<ieure>Why is it necessary? It's a content-addressible store, right? Since the mtime is metadata, how does that affect reproducability?
<Guest10>if the version was produced on jan 10 2024, the mtime would be jan 10 2024
<gabber>IIRC in the nix monadic store example the timestamps were factors that needed to be dealt with to ensure reproducibility. systems were bit-by-bit the same - except for the timestamps. so they were set to UTC 0 to ensure reproducibility
<singpolyma>(do not do this) you would need to chattr -i first
<Guest10>but it doesn't make sense to modify them manually, it needs to be done from the package procedure
<old>anyone manage to add filesystem sharing with virt-manager?
<ieure>Okay yeah, was wondering if they had the immutable bit set.
<gabber>for bit-by-bit reproducibility. you have a checkout of a git repo and a package definition (with definitions for all the dependencies). every time you build that package you want to have exactly the same files
<old>I get a: Error starting domain: operation failed: Unable to find a satisfying virtiofsd
<Guest10>yes, but twice a valid mtime would work as well as twice a 0 mtime
<gabber>that is true. but (currently) not the convention being used
<ieure>gabber, The bits of the data are the same no matter what the mtime is. Why does the timestamp matter for reproducibility if the contents are bit-for-bit identical? That's what I'm not getting here.
<gabber>ieure: we do not only do reproducible packages, but also reproducible systems.
<vagrantc>well, most of the time the other timestamps are lies too
<vagrantc>most timestamps are less meaningful than people think ... and most build systems pick poor timestamps
<vagrantc>i'll admit i find setting SOURCE_DATE_EPOCH=0 to be a rather heavy-handed option :)
<vagrantc>in contrast, debian typically picks the last entry from the packaging changelog to set SOURCE_DATE_EPOCH to get a meaningful timestamp ... but i am not sure what meaningful timestamp guix should use for any particular derivation
<gabber>the changelog of the package or the source checkout or ...?
<vagrantc>the git commit that you happen to be building is too variable ... if i build with git commit N and then build with git commit N+1 .... but don't change anything in the package i am actually building ... it should not pick the timestamp from N+1
<vagrantc>because N modified package Y, and N+1 modified package Z, it should not change the results of building package Y
<vagrantc>(and *which* timestamp from git do you use? :)
<vagrantc>e.g. in a given commit, there may be multiple timestamps recorded in git
<gabber>exactly :) so what changelog entry does debian use?
<vagrantc>debian does not have one git repository for the entire distribution, so it can pick a meaningful one
<vagrantc>each package has a distinct changelog entry for that particular version of the package
<vagrantc>guix, for better or worse(in most cases, better, but perhaps not this one), uses a single git repository for all of the packages
<vagrantc>there are a few package definitions where a package will refuse to build with SOURCE_DATE_EPOCH=0 (or some other timestamp thingy) ... and an arbitrary timestamp needs to be picked for those ...
<apteryx>hm, when building core-updates with the merged master, I get errors like: po/doc/guix-manual.fr.po:69580: duplicate message definition...
<apteryx>that's from a pristine tree; anything I could have done wrong?
<apteryx>there were conflicts in the .po files... which I've resolved in favor of master
<apteryx>the errors were not fatal though... prehaps it's the current state of the translations
<Guest10>Kolev: yeah the problem with Guix System is that if things don't work you are kinda stuck. Whereas if you use a foreign distro you often have a backup. I use ubuntu + guix + nix now, it's pretty nice
<Guest10>nix for the things that aren't yet packaged by guix
<Guest10>and it's good to compare, to have an idea of the different features
<Kolev>I can't handle Guix on foreign distros. Fedora deprecated nscd so now it doesn't work as well.
<Guest10>the installation on foreign distros is very easy