<nckx>I thought this might be my first ever use case for the fabled ‘package transformation options!’ but it looks like they only allow replacing pre-existing slots with pre-existing packages? Is that really true? That would be strangely limiting.
<nckx>I'd love to tell fnstudio to just ‘guix install bc --with-input=readline’.
<lle-bout>nckx: what about $ guix install bc --edit
<lle-bout>so you can edit a temporary copy of the package definition as you like
<lle-bout>or is it not good to do it like that? because updates?
<nckx>Hum. I'm personally unenthousiastic about encouraging such a workflow in our UI. 😉
<nckx>But indeed, package transformation options are stored, this would not be, which could make things even more confusing.
<lle-bout>nckx: why did you say it was a core-updates patch? bc is a dependency to many other packages?
<nckx>lle-bout, fnstudio: You can do something like guix package -e '(use-modules (guix packages) (gnu packages algebra) (gnu packages readline)) (package (inherit bc) (inputs `(("readline" ,readline))))'
<ryanprior>I'm working on updating it to the 1.30 release right now
<lle-bout>technically, socially maybe the community isnt resilient enough
<lle-bout>nckx: about security patches maintenance burden, is it OK if some packages go unmaintained inside GNU Guix repo without "refresh" handlers?
<nckx>lle-bout: That's fine. A significant portion of packages isn't covered by ‘guix refresh‘ (there is/was a command to list the coverage but I forget what it was). OTOH, I update quite a few packages and never use ‘guix refresh’, so...
<nckx>lle-bout: Oh, the coverage is just part of guix refresh --list-updaters output.
<nckx>So it's not bad but ~1/4 of all packages don't have a refresh ‘handler’.
<guixy>I saw guix publixh can now --advertise. When will that option be configurable for guix-publish-service-type? LIC such an option wasn't documented...
<lle-bout>nckx: how do we do to be reminded of updates then? It's got to be very troublesome to check them all individually
<lfam>I'd say that `refresh` doesn't offer that much help for security updates. The bulk of the work is learning that there is a problem and what the fix is, and usually we'd like to deploy the fix before there is a new release upstream
<nckx>guixy: You'd add ‘--advertise’ to ‘extra-options’. A separate (advertise? #t) switch is pretty but not strictly required to use the feature now.
<nckx>lle-bout: I subscribe to a lot of lists/forge notifications/...
<nckx>I also have some proprietary (because they're embarrassingly bad) bash scripts to help me.
<nckx>One Day™ I'll port them to Guile and dare share.
<lfam>I have organic heirloom shell scripts for updating linux-libre
<lfam>One day it would be nice to let `guix refresh` do it
<nckx>I agree with lfam about CVEs and such. I much rather get a mail from upstream that rely on some opaque tool.
<lfam>Some upstreams are good about issuing new releases in response to security problems, but many of them rely on distros to cherry-pick some patches
<nckx>I want to love guix refresh more than I do, really. But there's no spark and it sits there unused. Sorry, freshy ☹
<lfam>I do feel motivated to add the kernel refresher. I just need to find the energy
<lle-bout>shouldnt we try and add update notification to Guix Data Service? So that it could run ad-hoc scripts even the ugly ones? We don't care after all, they're not the reliable part of the system.
<nckx>First you write a Guile IRC client library to connect to #linux-libre, then sniff out the New Kernel Alerts. Simple.
<mizukota[m]>"guix pull; guix package -u" does update and save from CVEs when updates are packaged, what else do you need?
<lfam>Sorry, I missed the beginning of this discussion so I'm not sure what's really being talked about
<nckx>lle-bout: Guix always updates to the latest version when possible.
<mizukota[m]>wait but what you have to specify in package recipe for checking latest upstream version?
<lle-bout>re metadata packages for guix refresh: Big yes!
<lfam>In general, "security" as a property is not so easy to describe or identify. We assume that every upstream release fixes bugs, and many bugs can be considered security bugs, so every release includes security fixes
<nckx>A known CVE will change some parameters (like do we bother grafting, or will I spend my free evening fixing broken dependents).
<vagrantc>nckx: the biggest check that i find doing manually is having to verify the signatures on upstream tarballs a bit tedious
<ryanprior>I don't know for a fact that it wouldn't, I guessed based on what you were saying about those being completely separate.
<vagrantc>lle-bout: e.g. vX.Y.Z vs. release-X.Y.Z vs. other arbitrary release schemes
<lle-bout>vagrantc: I don't understand what you're referring to exactly
<vagrantc>lle-bout: a generic updater to match against upstream release tags?
<nckx>ryanprior: If you need to run a tool that just happens to be in the package's inputs as well you can just refer to the tool (like 0ad-data does with unzip; unzip might or might not be an input too, I didn't even check, it's irrelevant).
<ryanprior>I snipped out the tiny-bignum vendored source from vlang and then I was going to patch vlang's source right there in the snippet, because it hard-codes the path to the vendored source.
<mizukota[m]>if a manual intervention is still required, why is this needed? You still need to check upstream, its dependencies, tests, sources. Such complex constructions look overengineering if their only use is to update url and hash and to notify about update
<nckx>If it's opportunistic, it shouldn't be part of the package record. Just a list of common regexes hard-coded in the ‘guess’ updater.
<nckx>Most projects don't have tag naming rules in practice, ‘v1.0’ → ‘1.1’ is quite common.
<nckx>So IMO ‘I saw package-foo use a v in the past’ isn't valuable information to add to the package record.
<lle-bout>that and check manually I much prefer that
<nckx>To me it feels like you intuit how many false positives this will generate, and hope to work around it by adding smaller ‘well we've seen format x’ fields for many packages. But these fields will grow over time, the false positives will return, you'll have more false negatives, and the fields will become a maintenance burden themselves.
<nckx>On matching all regexes to all URLs being heavy: I don't think it's computationally significant. I mean, look at how ‘guix refresh --list-updaters’ prints its output: this is not intended to be an instant tool.
<nckx>(The coverage is calculated live, which is cool.)
<nckx>lle-bout: It would be interesting to break down the current distribution by looking at the commit field of all packages with a git-reference source URI. See how many weird schemes there are in the wild.
*nckx ought to go to bed before the clock strikes 4:00... Good night all.
<dissoc>is it possible to add channels to config.scm file rather than ~/.config...?
<slimjim>question about library search path for sqlite extensions; I've installed both sqlite and libspatialite into my default profile. Spatialite is an sql extension module that lets you work with geolocation data, similar to postgis with postgresql
<slimjim>when I launch sqlite3, ".load mod_spatialite.so" fails, but ".load /home/slimjim/.guix-profile/lib/mod_spatialite.so" succeeds
<slimjim>it requires a full path, neither ~/.guix-profile... nor $HOME/.guix-profile work
<slimjim>so does anyone know what it might take to get the sqlite3 guix package to look in the '/lib' directory of the active profile for extension objects by default?
<slimjim>(possibly relevant, this is a foreign distro install on top of ubuntu 18.04)
<slimjim>if I do ```export LD_LIBRARY_PATH=$HOME/.guix-profile/lib``` before launching sqlite3, I can load it by basename only. So I guess question is, can things like sqlite be set up in GUIX to be wrappers that automatically set variables like LD_LIBRARY_PATH before launching the binary?
<mizukota[m]>this builds iso fine, but on boot I get kernel panic about not being able to mount unknown-device block 0,1. As you can see, bootloader and file-systems are exactly same as in default installation-os, image has been built using guix system disk-image --image-type=iso9660 --verbosity=666 ./install2.scm
<mizukota[m]>(and written to usb using dd if=/path/to/iso of=/dev/sdb bs=8M status=progress)
<mizukota[m]>oh i forgot to mention, this install2.scm file should be placed near install.scm of guix git repo (gnu/system/install.scm) and nonguix repo should be installed to ~/.config/guix/channels.scm
<mothacehe>mizukota[m]: that's probably related to the initrd you are using but we cannot discuss it further here as you are using the nonguix repo.
<mizukota[m]>is nonguix repo discussion forbidden in guix channel? How do you install guixsd on real hardware then?
<mizukota[m]><mothacehe "mizukota: yes it is, please read"> I read it and i dont see why dont i have freedom to also use unfree things, especially if I already have hardware that is not open-source and i cant afford new open-source hardware which is not cheap
<mizukota[m]>it only says that guix itself only contains free and opensource things and even deblobs the kernel
<rekado>mizukota[m]: you have the freedom to use whatever software you want, and Guix makes it easy via channels. But we keep nonfree software discussions outside of this official channel.
<mizukota[m]>I understand. So is there some hidden unofficial channel where this discussion can go?
<lle-bout>mizukota[m]: please refer to the projects in question, they may have their own discussion rooms
<civodul>rekado: i'm glad you looked at the ld.so.cache patch
<civodul>probably i'll merge today if there's no more feedback
<lle-bout>kisaja[m], Most drivers probably like the one you are mentioning are included in the linux-libre kernel, however linux-libre does not include nonfree firmware. If something does not work then it's probably the cause. GNU Guix does not endorse proprietary software or firmware and therefore does not include them in the official repository. You will have to look elsewhere.
<kisaja[m]>i bought this usb wifi adapter because of the free driver, i just believed that network-manager would show it as a device, will check the normal way )
<jlicht>kisaja[m]: I've had issues with a similar chipset, where there were several revisions of the exact same dongle that worked, and others' that didn't without nonfree firmware; make sure the ID's in `lsusb` are exactly what you expect to see.
<kisaja[m]>can i convince it that its rtl8192e and not rtl8192eu, to try if it works?
<wehlutyk>I'm looking into updating python-setuptools which is now version 50.3.2 (vs. 41.0.1 in guix), but dropped support for python 2 at version 45. What would be the recommended way of doing this?
<wehlutyk>Keep an older version like python2-setuptools-44 for the packages that rely on python2-setuptools?
<wehlutyk>(This in turn is for fixing python-keyring's way of declaring its version, as described here: http://issues.guix.info/44077#43 . It's simply a matter of including python-setuptools in the native-inputs, but keyring requires setuptools >= 42)
<nckx>lle-bout: All public SMTP submission is either authenticated or broken, so git supports it just fine. Could you share your git configuration?
<lle-bout>nckx: It worked unauthenticated heh but my ISP has odd setup
<halfdann>I somehow ended up with a package that I can't delete. It probably came from an incorrect package definition from myself some time ago: `guix gc --referrers <pkg>` shows it has 1 referrer which is the package itself and `guix gc -D <pkg>` says it's still alive
<halfdann>Any tips how I can go about deleting the package?
<nckx>lle-bout: Try using smtpserverport = 587 instead.
<lle-bout>nckx: filtering unauthenticated SMTP outside of ISP network
<lle-bout>nckx: Port 465 is what my email client uses
<civodul>apteryx: 502 is cached by nginx, so you'll have to try again later
<civodul>it seems to work when talking directly to "guix publish" on berlin
<mbakke>lfam: I'm getting ~12% cpu usage when running 'guix environment --ad-hoc intel-vaapi-driver ungoogled-chromium -- chromium --user-data-dir=/tmp/test --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy' and going to https://meet.jit.si , I guess that would not be possible without some hardware assistance?
<civodul>apteryx: perhaps you tried right when mothacehe restarted the daemon?
<apteryx>Which shepherd service needs to be restarted to have the users provisionned by guix-daemon created?
<guix-vits>mbakke: the end of user? and the user has many ends: left and right arms, legs, ears, and much more. bottom benefits the most, i sure. but from whuom vitory was this benefication grown, from device or the distro? that's is a question (01:04)!
<apteryx>ah, I'm using 'guix deploy' to manage it. I think there was an issue about it not doing the activation.
<lfam>argylelabcoat: It's good to hear this kind of feedback. You should get some advice if you wait a little while
<smithras>I was looking at old forgotten issues after reading zimoun's email and I saw that this bug http://issues.guix.gnu.org/22952#4 is marked as open despite Ludo closing it way back in 2017. Is this a glitch on the website or is is actually still open?
<lfam>smithras: The bug was reopened a couple weeks ago
<pineapples>I have a rather simple request to one of people with the commit access, that I think doesn't deserve a bug report, but I'll open one if I have to. Anyway, two directories must be added to XDG_DATA_DIRS after installing Flatpak to make applications installed by it discoverable OOTB
<zimoun`>smithras: thanks for playing the game. :-) I have not carefully checked the URL about the forgotten bugs provided by issues.guix.gnu.org because I am using emacs-debbugs. ;-) Thanks for the report
<zimoun`>lfam: basically the database Debbugs is plain mbox. IIUC. But corner cases could happen when parsing it.
<argylelabcoat>lfam: you are welcome. I was hacking in Nix for a few months and I'm moving over to Guix since Guix supports armhf and I've got some hardware I need to develop for that falls into that category.
<zimoun`>apteryx: yes, the number of bugs open per day is really larger than the number of bugs closed per day. We should set the rule: you are allowed to open a new report if and only if you first close one. ;-)
<zimoun`>The GNU projects using the Debbugsinstance has created ~5000 entries in ~9months. Almost 18 new bug or patch per day. Hard to tell about Guix only; but I bet the big contributors to these figures are at least Emacs and Guix. :-)
<zimoun`>crap! Because it appears explicitly in some webpage, right?
<zimoun`>well, in this case, yes let remove it and recreate this alias or another one when we need it. WDYT?
<nckx>zimoun`: I have no idea, I've had this address for years with no major spam problems, but somehow guix-days@ managed to make all the shitlists in the world in record time. I wonder why.
<nckx>zimoun`: It would be nice if we could pause it, yes.
<nckx>zimoun`: Can we remove/add such aliases at will without bothering gnu.org every time?
<roptat>dropping a quick idea, to see if that makes any sense: when I debugged some ocaml reproducibility problems, I noticed filesystem ordering issues were hard to diagnose, and it was also hard to see when it was fixed because when it's present, the package usually builds reproducibly on the machine
<civodul>nckx, zimoun`: we can comment it out if you want, we just have to log in to fencepost.gnu.org
<charles`>I tried searching but, it is only used right there
<charles`>I removed the existing (set-xorg-configuration ...)
<zimoun`>civodul, nckx: I have no opinion about guix-days. It is useful for organizing but if it is a spam magnet, let turn it off for now and then reevaluate the position later when required; since it is only an alias on fencepost, IIUC.
<apteryx>mbakke: chromium uses about 11% of my CPU too with your command
<apteryx>(visiting meet.jit.si with video + sound enabled)
<jonsger>apteryx: I guess thats due to missing hardware acceleration from your GPU with the codec used by Jitsi
<apteryx>mbakke: oh wait, this was just the preview
<apteryx>actually joining a test meeting uses much more than that
<kisaja[m]><charles` "I removed the existing (set-xorg"> that fixed it?
<civodul>zimoun`, roptat, nckx: i've now commented out the "guix-days" alias on fencepost
<jonsger>dannym: still don't understand why we want to rebuild the world on master
<nikita`>i wonder if i should just /dev/null all future bug tracker emails. i don't really have follow-up questions to emails i haven't responded to in 3 years, it's a bit very standardized to say "please message to reopen"
<zimoun`>nikita`: what do you mean by “it's a bit very standardized to say "please message to reopen"? Since it is mainly that writes these closing emails. :-)
<nikita`>sorry, german phrasing of mine doesn't transport me being humoured by this in a non-offensive way. what i mean is, people (probably also you) close bug tickets i have opened 3 years or more ago and i have no intention of reopening them
<charles`>roptat It seems that using (remove ...) worked! thank you very much
<dannym>raghavgururajan: It's a *GNOME* update; basically, everything that has a GUI that is not KDE uses it. Also, glib is used by most daemons, too. So yeah, updating those is totally gonna rebuild a lot
<cbaines>The formatting changes add some noise. I just looked in to the "[license]: Modify." change for Wayland, and it does indeed look like the license did change at some point (5 years ago it seems!)
<civodul>dannym: what is the display manager bug you're referring to?
<mbakke>the formatting changes also break 'git blame'
<dannym>civodul: gdm doesn't let you log into the computer anymore. See irc log from a few days ago (of me and of lispuser*)
<mbakke>so they have some tangible cost, and in many cases I think the cosmetic changes are for the worse
<dannym>civodul: gdm login screen would come up, then let you enter username and password, then after you press enter would fake-try logging in and immediately bring you back to the gdm login screen
<cbaines>dannym, I use the GDM on my laptop, and I updated after I saw people were having problems, and it seemed to work for me. Maybe I got lucky somehow with my GDM state?
<mbakke>dannym: also check if you have any state at all in /var/lib/gdm
<raghavgururajan>> cbaines: Out of interest, what was the workflow for creating these "Update package definition" commits? It looks more like rewriting the package definitions from scratch in places?
<raghavgururajan>I am in the process of splitting patches. I think things would be clear after that.
<mbakke>took me about 16 minutes to track down :-)
<nikita`>sneek: later tell zimoun`: I also do not intend to react to bugtickets that old (see icecat localizations one) because I have no means to reproduce it and don't really have the spoons to deal with more than one project this year
<mbakke>it should be possible to write a pre-push hook that does the checks
<mbakke>"pushing these Y commits will cause N rebuilds... are you sure about this?"
<nikita`>i'd really be interested in providing more useful feedback, but between netbsd, working a minimum wage job, fighting bureaucracy to even stay in a flat, finding a new job, learning more languages to find a new job and having some kind of weird social life in these times, i kind of run low on spoons for experimentation.