IRC channel logs

2021-03-18.log

back to list of logs

<Whyvn>what is term-auto? it never starts its service.
<nckx> http://logs.guix.gnu.org/guix/2021-03-17.log#225932 :)
<nckx>Good night Guix.
<raghavgururajan>cbaines, this could go in cpp.scm right? https://www.codesynthesis.com/projects/libcutl/
<cdegroot>Am I missing something obvious? I want to hack on guix, so I add `use guix guix` to my `.envrc`, `direnv allow`, stuff happens, `./bootstrap` and then `./configure` - which complains that guild isn't there, but direnv added the store with guile (including guild) neatly at the front of my path etc.
<cdegroot>Hmm... adding --pure solves it. I wonder why less software makes configure find more...
<flatwhatson>Maybe it's calling system pkg-config, which is finding system guile? I'm reasonably sure it doesn't use PATH to find guile.
<cdegroot>Ah, good one. I'm closely "strangling" my Ubuntu host, removing dev tools, but I keep missing stuff :)
<cdegroot>Yup. Guess what - "nvidia-settings" on Ubuntu pulls in "pkg-config". No clue why. Good riddance of both. Next.
<flatwhatson>Though `guix environment guix` prefers guix's pkg-config and sets PKG_CONFIG_PATH for me...
<flatwhatson>I've had a much easier time just using pure environments for development anyway. Using a manifest to create the environment gives you a place to define any unpackaged deps, and gives a lot of flexibility for testing different dependency versions, not to mention eliminating host system leakage.
<cdegroot>Yeah, I just need to figure out what I need extra in a pure env (with Emacs wanting external tools like ripgrep). I'll get there - thanks for pointing me in the right direction.
<pkill9>i like guix, but it's a problem that it requires an internet connection just to roll back the system
<cdegroot>I'm on rural WISP. I know the internet connection pain :P
<flatwhatson>cdegroot: I run emacs from outside the environment, and use the envrc package so each buffer gets the proper environment.
<cdegroot>(ah... what tripped up configure was the guile package on the system; without it it works better)
<cdegroot>Yeah, with direnv Emacs (which I start from the Gnome shell) seems to not find ripgrep, for example. Project-wide search with ripgrep is nice.
<flatwhatson> https://github.com/purcell/envrc
<cdegroot>Yup, that's what Doom uses if you enable direnv.
<raghavgururajan>When I try to build this (https://paste.debian.net/plain/1189789), I get this error (https://paste.debian.net/plain/1189792).
<raghavgururajan>Patching the string build-0.3 to build also doesn't work.
<raghavgururajan>Any ideas?
<flatwhatson>cdegroot: Right, but what I'm saying is you don't need to install ripgrep in the pure environment. Launch emacs outside the pure environment (where it can find your regular ripgrep), then envrc-mode will load the pure environment *per buffer*, and you get the best of both.
<cdegroot>I hoped that that would happen, but apparently not. Oh well... Stuff's working "impure" now I apt-removed guile.
<cdegroot>Heh. Wanted to see what's needed to add mDNS discovery of my local substitute servers, just learned that guix-daemon is C++. Probably gonna be a bit more tricky than I thought.
<flatwhatson>cdegroot: Ah, right, I can reproduce your problem. Guess I don't use 'SPC s p' much so didn't notice!
<flatwhatson>Likewise for magit without git in the environment. Hmm.
***yong_ is now known as Iacob
<cdegroot>flatwhatson glad I'm not crazy ;-)
<cdegroot>totally different question - one of the packages I want to hammer under Guix control is .NET Core 3.1. Is that considered free software? IOW, in the unlikely case that I manage to define a package, should I submit it to Guix? Don't ask why I want it, please :P
***iyzsong-- is now known as iyzsong-w
***sneek_ is now known as sneek
<flatwhatson>Looks like it's released under MIT, so yes.
<cdegroot>Now if i only can get it to build. Apparently it's using the dotnet git library, which is an old one that wants OpenSSL 1.0, to pull more deps. Nice puzzle but I'm giving up for the night lol.
<lle-bout>hello marusich! :-D
<sneek>Welcome back lle-bout, you have 2 messages!
<sneek>lle-bout, flatwhatson says: I've heard minor rumblings about guix vs tramp paths, but don't use it myself and haven't had any proper reports. Happy to help investigate, either here or as a github issue. It's possibly a regression of guix vs master, not specifically related to native-comp.
<sneek>lle-bout, Noisytoot says: According to https://www.sqlite.org/versionnumbers.html, the first part will change if the format changes, and the second part will change if a new feature is added
<marusich>hello lle-bout
<lle-bout>Noisytoot: so it means basically it stays ABI compatible if it's just new features so safe to upgrade/
<lle-bout>marusich: are we ready to merge PowerPC 64-bit you think?
<lle-bout>marusich: I'm not exactly sure why some derivations change in this link: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=341dfe7eda4972af0a027357015ea595314438b0&target_commit=4757434caeac0077f67583701653a7b89a335e61&system=x86_64-linux&target=none&build_change=&after_name=&limit_results=&all_results=on
<marusich>I have a suspicion, but I do not think it is worth worrying too much about, personally.
<lle-bout>cbaines: hello! :-D - is the list all changed derivations why would they change?
<lle-bout>marusich: yes probably, as long as not >300
<marusich>I suspect that changes to syscalls.scm may have somehow propagated into the output of the module-import-compiled derivations, which I believe build the compiled .go files that make various modules (like (guix build syscalls)) available to guile builders when executing other derivations.
<lle-bout>marusich: ohh..
<marusich>It's just a guess
<marusich>I don't know for sure
<marusich>It appears to be about 500 packages, based on cbaines' output, so it doesn't seem egregious. I would argue that it is better to merge this for the relase and rebuild those ~500 packages, than to postpone making it easier for people to hop in and try out / help out with the powerpc64le-linux port.
<marusich>I have to run, but that's something to consider.
<lle-bout>marusich: agree!
<lle-bout>marusich: see you soon :-)
<phossil>ive been wanting to switch to guix from void for a while and couldnt help but notice nushell is in the repos while the ion shell is not
<lle-bout>phossil: maybe you can package it and we can try to help :-)
<phossil>ill probably get to it at some point if i can figure out how to install with f2fs as the root filesystem
<lle-bout>phossil: there's "guix import crate" which will help here
<lle-bout>phossil: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a889e6a9bfb35641ef66950df414145bb92fa938 - seems F2FS as root is supported by the configuration system
<lle-bout>You just have to choose it during the guided installer probably?
<phossil>i didnt see it while using the guided installer
<phossil>is there a place that has nightly images
<lle-bout>phossil: yes here: https://guix.gnu.org/en/download/latest/
<phossil>my bad, i just saw that. i should probably head to bed now
<lle-bout>phossil: hope to see you on GNU Guix soon :-)
<lle-bout>good night!
<phossil>good night to you too :>
<FossGuy[m]>Why is adb so outdated in guix?
<lle-bout>FossGuy[m]: two hypothesis: because no one could put the energy to update it (likely), or freedom issue on more recent versions pending solve
<lle-bout>FossGuy[m]: needless to say, Android eco-system isnt a big focus for GNU in general but someone just has to work on it
<FossGuy[m]>Oh, I've to switch to nix then
<FossGuy[m]>SOme useful packages missing :(
<lle-bout>FossGuy[m]: A GNU/Linux distribution is what you make it, Nix needs contributors like GNU Guix :-) - If nothing's keeping you to GNU Guix, then go to Nix that's OK, there's even a nix-service-type in GNU Guix.
<lle-bout>FossGuy[m]: and adb is not *missing*, it's there just not latest
<lle-bout>It's been working with my Android phone quite fine
<FossGuy[m]>Yes, but I need latest pkgs and and pkgs like element-desktop and kde apps are missing sadly
<FossGuy[m]>I like gux so far, but these are holding me back
<FossGuy[m]> * I like guix so far, but these are holding me back
<lle-bout>FossGuy[m]: learn GNU Guix and make these areas better, only way you have here, making packages is not really complicated it just needs time and testing, KDE desktop is coming as well in the wip-kde-plasma branch (https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-kde-plasma), so join efforts, show your interest and help by testing that's enough even
<lle-bout>FossGuy[m]: element-desktop, it depends on Electron and the JavaScript eco-system, Nix basically retrofits binaries into their distribution to provide it so not a real packaging here. Over at GNU Guix we don't make such fake packages.
<lle-bout>However, Element can be used on a web browser so, it's no real blocker here
***apteryx is now known as Guest64152
***apteryx_ is now known as apteryx
<rekado_>roptat: ping latency is not all that interesting, I think. I asked for ICMP to be enabled, because it is also used to negotiate packet size and a failure to accomplish that can lead to packet loss and reduced bandwidth
<rekado_>roptat: so I’m really interested to see if *download speed* has improved.
***DiffieHellman_ is now known as DiffieHellman
<efraim>There's also the option of using the nix service or flatpaks
<lle-bout>how can we efficiently apply a single patch series with a particular version?
<lle-bout>civodul: Good morning! :-D
<civodul>Hello Guix!
<civodul>hey lle-bout
<lle-bout>civodul: trying to make use of generic-html updater, I am thinking we might need some extensibility like provide an actual function in properties to match the URL of the new version, for the sqlite case it doesnt use normal version numbers in the tarball name
<lle-bout> https://sqlite.org/2021/sqlite-autoconf-3350200.tar.gz - this is the URL for 3.35.2
<lle-bout>also the year changes, 2020 -> 2021
<lle-bout>civodul: another thing, a git_tag updater might cover lots of remaining cases (with varying reliability?
<civodul>lle-bout: re sqlite, would the release-monitoring-url property help?
<civodul>(see the hwloc pakcage)
<civodul>re git-tag, why not, though i think most Git-backed packages are already handled by the github updater or similar
<lle-bout>civodul: I tried, it seems not
<lle-bout>civodul: yes they are, but there are non-gitlab/github forges
<lle-bout>all in all, tags is the way ALL forges base their release mechanism on
<lle-bout>so it's more generic
<civodul>yup
<lle-bout>civodul: https://issues.guix.gnu.org/47217 - see for sqlite release monitoring
<civodul>great, i'll take a look
<civodul>thanks for reporting it!
<lle-bout>civodul: only downside I see is maybe it requires fetching too much in the repo to check for git-tags but I also hope it's possible to fetch *only* tas
<lle-bout>atgs *
<lle-bout>tags * oops..
<civodul>yup, fetching entire repos is not an option
<lle-bout>civodul: This command seems to do it without cloning: git ls-remote --sort='version:refname' --tags https://github.com/git/git.git
*lle-bout creates an issue
<lle-bout>civodul: we may actually want to replace forge-specific updaters with that..
<maxxcan>good morning
<lle-bout>hello :-)
<maxxcan>do everyone use bitlbee on guixsd?
<efraim>I'm trying to use autoconf-wrapper with autoconf-2.13 but having a hard time with the syntax ((@@ (gnu packages autoconf) make-autoconf-wrapper) autoconf-2.13))
<efraim>yay typos. it's in autotools, not autoconf
<lle-bout>civodul: does adding the release-monitoring-url property automatically turns the generic-html updater on? I have a case where the generic-html updater should clearly work and it does not
<thorwil>hi! inkscape fails to start with: `gnu/store/g75q5v1gqi4x08qcf1ydfl9xhp4slmxy-inkscape-1.0.2/bin/.inkscape-real: error while loading shared libraries: libMagickCore-6.Q16.so.6: cannot open shared object file: No such file or directory`
<thorwil>is there room for some local issue, or must there be something wrong with packagaing?
<rekado_>thorwil: is LD_LIBRARY_PATH set, perhaps?
<thorwil>rekado_: no, empty
<rekado_>my hammer is called ‘strace’. This looks like a nail.
<thorwil>strace inkscape -> https://pastebin.com/raw/w42T9QEB
<rekado_>I wonder if this is due to grafting.
<rekado_>because I see that this exist: /gnu/store/l0asah1mggmgli85sp673bnp2yc71g0j-imagemagick-6.9.12-2g/lib/libMagickCore-6.Q16.so.7
<lle-bout>ImageMagick was grafted yes..
<rekado_>yet inkscape tries to get libMagickCore-6.Q16.so.6
<rekado_>perhaps the graft needs to be redone to ensure that .6 is installed, not .7
<lle-bout>So there's ABI breaks in minor ImageMagick?
<rekado_>not necessarily ABI break
<rekado_>just the .so version name has been changed when it shouldnt’
<rekado_>*shouldn’t
<lle-bout>rekado_: I don't quite get why it doesnt install them all .x versions
<lle-bout>rekado_: do you think it just didnt install it?
<lle-bout>but it compiled it?
<lle-bout>It looks like it's the C++ library
<lle-bout>That's why
<lle-bout>no?
<lle-bout>rekado_: MAGICK_ABI_SUFFIX the variable is
<lle-bout>rekado_: is this an ImageMagick specific mechanism? I can't see anywhere it being defined
<lle-bout>rekado_: the only way I see here is backporting patches for each and every CVE which is sizeable work for ImageMagick here, so the solution would be ungrafting
<rekado_>lle-bout: how about cheating?
<lle-bout>rekado_: Making SONAME 6?
<rekado_>if we can assume that the ABI is the same can we just provide .6 by renaming .7?
<lle-bout>I don't see where it is defined yet :-S
<lle-bout>After compilation maybe we can do that
<rekado_>I mean *really* cheating
<rekado_>yeah, just a build phase
<lle-bout>Okay, I'll try
<rekado_>thanks!
<thorwil>thank you rekado and lle-bout for looking into this!
<Ikosit>Hello! I'm trying to submit a few packages, but when I try to build them on another architechture with qemu, I get the following error: „while setting up the build environment: executing `/gnu/store/…-guile-2.0.14/bin/guile': No such file or directory“
<Ikosit>It doesn't matter if i use the installed guix or guix of my repo with ./pre-inst-env
<rekado_>Ikosit: are you using the qemu-binfmt-service-type to emulate other architectures?
<Ikosit>Yes, building the package hello works.
<Ikosit>And the qemu service is already in /run/current-system/configuration.scm
<lle-bout>rekado_: look good to you? https://bpa.st/raw/3N7Q
<lle-bout>it actually doesnt work.. let me fix
<rekado_>Ikosit: can you check that the guix-daemon command line looks really long? E.g. with pgrep -fa guix-daemon
<rekado_>it should have a whole lot of directories on the command line
<Ikosit>It hasn't
<Ikosit>So, do i have to execute `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild` ?
<rekado_>Ikosit: have you rebooted or restarted the daemon since you reconfigured to use the qemu-binfmt-service-type service?
<rekado_>you don’t have to run the daemon manually
<rekado_>simply restarting it after reconfiguring should suffice
<Ikosit>No, i didn't
<Ikosit>Ok, thanks
*Ikosit does very rarely reboot
<axbrt>Hi. Does Guix 1.2.0 support LVM?
<lle-bout>thorwil: hey, did inkscape not work at all before?
<thorwil>lle-bout: it worked until now. last time maybe a few days ago
<lle-bout>thorwil: yes that sounds logical since we made security updates on imagemagick and didnt check the soname changing
<lle-bout>thorwil: more recently it didnt run at all? that's what I mean
<lle-bout>thorwil: it's not when you use some feature?
<lle-bout>thorwil: got my answer, it doesnt run at all
<lle-bout>thorwil: just pushed a fix as 2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd, run "guix pull"!
<lle-bout>rekado_: also see fix, it works fine (tested)
<lle-bout>rekado_: I am thinking we should add an automatic test for this
<lle-bout>rekado_: check if all grafted binaries are not broken by running ldd/objdump -x on them
<lle-bout>rekado_: https://issues.guix.gnu.org/47228
<thorwil>lle-bout: done, inkscape works again, thank you very much!
<lle-bout>thorwil: in the future may similar issue happen after reporting to us if it takes some time to fix then you can use --no-grafts in the mean time at install time
<lle-bout>beware though it may expose to security issues since that's the main reason we graft for
<thorwil>ok
<PurpleSym>For the curious, these are the reasons ImageMagick’s SONAME got bumped: https://github.com/ImageMagick/ImageMagick6/commit/8b4078682b9fd4988ea44d077cf77eecb8f836d8
<PurpleSym>And https://github.com/ImageMagick/ImageMagick6/commit/0b97c07909c8d87e47d6c8dd963481f46a58a704
<PurpleSym>The first one looks innocent, since we don’t support that arch. Can’t find a reason for the second one, which is a red flag for grafting imo.
<lle-bout>PurpleSym: thanks for digging the commits couldnt find where the soname was defined, the grafting may fail but since it's temporary and we have no other viable alternative for fixing the security issues promptly..
<lle-bout>We will ungraft as soon as possible
<PurpleSym>The reason for number two seems to be this: https://github.com/ImageMagick/ImageMagick6/issues/133
<lle-bout>thorwil: let us know if Inkscape fails to work in any way
<lle-bout>PurpleSym: I found that yes, but it doesnt say reason
<lle-bout>It seems they have kind of bad practice for changing soname
<lle-bout>in non-major releases
<lle-bout>It would be possible to maintain ABI without doing that
<PurpleSym>Well, “no reason” means it’s not safe to graft, because we don’t know for sure the ABI is still the same. Especially given their sloppy commit messages and version management.
<lle-bout>PurpleSym: but we must fix the security issues somehow so if not grafting I'm open to other solutions but not fixing the security issue does not sound good to me
<lle-bout>We have another option here: backport each fix to each security fix to the version we have, but that's lots of work since we have lots of different CVEs on this particular one, and most certainly I wont be able to do it with all the other work I would have to do, plus I don't think we should ever do that, not viable unless we have more people committed to creating such patches
<lle-bout>For now, even with SONAME changing, it doesnt seem to break backwards compat (maybe only forward compat), so it would work fine
<lle-bout>Let's see if thorwil comes back with some Inkscape issues
<thorwil>lle-bout: so far it works as before. stable, unless one does certain things with gradient meshes, but that’s an entirely different story :)
<lle-bout>thorwil: gradient meshes is that related to ImageMagick here or not?
<PurpleSym>lle-bout: See lfam’s mail on guix-devel regarding patching security issues vs. stability: https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00308.html
<lle-bout>PurpleSym: They werent talking about grafting, but I do not agree leaving known security issues unpatched when we can do it
<thorwil>lle-bout: no, i assume it’s an entirely inkscape-internal issue
<lle-bout>thorwil: it had the same behavior before like few weeks ago when you used it?
<thorwil>lle-bout: yes
<lle-bout>thorwil: alright, glad to know it works fine!
<lle-bout>PurpleSym: I say, let's keep it to actual reported issues on this ImageMagick thing, plus it's temporary until we can ungraft
<lle-bout>PurpleSym: when we can't do it at all like GNOME it requires massive upgrade nobody is going to upgrade everything braindead
<lle-bout>If we must come to the realization that we don't have the ressources to keep GNU Guix and GNU Guix System secure then I may uninstall and move to another distro
<lle-bout>I use GNU Guix System every day so I of course care about stability and my system's been running very stable
<lle-bout>I say we can find unstability issues and patch them faster with more automated/human testing of things, like Fedora does, that improves stability a lot
<lle-bout>PurpleSym: and see my earlier answer here: https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00324.html
<lle-bout>I try to do it the best I can, I may cut some corners because I don't feel like we can do it otherwise but I wont break anything blatently that's never been the case, I try to do rigorous testing of any graft I make
<lle-bout>+ request reviews when things are hard or non-trivial
<lle-bout>reviews/help
<lle-bout>And the more tooling we have, the more testing I can do
<lle-bout>e.g. https://issues.guix.gnu.org/47228
<lle-bout>We also don't have tooling to graft dependencies of a package then build it to run the test suite
<pkill9>does anyone use wpa-supplicant/ifconfig/dhcpcd directly on their laptop instead of via networkmanager?
<pkill9>if it's simple enough to do then i may switch to that because it may be more reliable than networkmanager, alternatively my problems may be fixed by upgrading the kernel
<lle-bout>pkill9: what's your networkmanager bug exactly?
*lle-bout needs to run
<pkill9>it just randomly disconnects, including one time on ethernet, while omy phone worked on wifi
<lle-bout>pkill9: any bizarre kernel logs in /var/log/messages or dmesg?
<lle-bout>pkill9: what driver?
<pkill9>i'll need to check, how do i search for them?
<pkill9>well it happened over ethernet
<lle-bout>pkill9: post your system config etc.. will help
<lle-bout>can't help now though.. need to run ..
<pkill9>so whatever driver for that is
<pkill9>ok
<pkill9>thanks
<lle-bout>pkill9: ethernet drivers arent same for everything, you can use ethtool to find out
<lle-bout>in the kernel logs, there's driver name before log line
<lle-bout>pkill9: try stable kernel release series also, 5.4, 5.10, 4.19
<pkill9>yea, probably would be best
<PurpleSym>lle-bout: If you value security above everything else then yes, maybe a commercial distro with more resources is better for your use-case.
<lle-bout>PurpleSym: not above everything else but it's important to me, but I don't intend on moving away from GNU Guix but try to improve things in it rather
<lle-bout>As zimoun said I am convinced we also may need some kind of change in the process of getting code to actual users.
<lle-bout>different combination of branches
<pkill9>why do you need that?
<pkill9>is it related to security?
<lle-bout>pkill9: need what? different kind of branches?
<pkill9>yea
<lle-bout>instead of core-updates, master, staging, etc?
<pkill9>and change in process of getitng code to users, in general
<lle-bout>pkill9: yes security, well the real problem now is making changes to core packages.. or grafts.. but if we can somehow pre-buffer changes so substitutes can be made and then push them to users once substitutes are available and deprecate the idea that frequent rebuilds should be avoided for non-substitute users (be it official substitute servers or unofficial), when IPFS/GnuNet substitute sharing and better reproducibility comes to play
<lle-bout>it may be less of a problem
<lle-bout>I also value building everything from source so it's not easy but I also think concerns that require building everything from source yourself can be mitigated by better reproducibility and distributed substitutes sharing.
<pkill9>yea
<lle-bout>Not everyone would need to build from source but at least you can have several people doing it and choose the ones you trust
<lle-bout>Also they could check each other for reproducibility
<pkill9>well the build server would act as metadata server for the build, which would be distributed via ipfs
<lle-bout>pkill9: but if things are reproducible then people can build same nars independently and they would still verify against ci.guix.gnu.org's key
<pkill9>ah i see yea
<pkill9>so multiple people can build it independently and compare the results
<pkill9>assumign that the bulid is bit-for-bit reproducible
<nckx>Morning Guix. o/
<lle-bout>Either way, this will hurt the slow Internet / limited bandwidth use case
<lle-bout>So it's not viable really as-is
<lle-bout>Maybe there's other things to do
<lle-bout>nckx: hello! :-D - Need to run so see you later!
<nckx>Hello, good-bye.
<lle-bout>Everyone update your guix-daemons
<nckx>I can't even face mine. Why?
<lle-bout>See: https://issues.guix.gnu.org/47229
<nckx>Thanx.
<lle-bout>We should probably request a CVE
<nckx>Oh, that.
*nckx shrugs.
<lle-bout>Debian wont patch otherwise
<nckx>Someone might do so if they want.
<lle-bout>sneek later tell vagrantc: see https://issues.guix.gnu.org/47229 and patching Debian
<sneek>Will do.
<nckx>Sounds like a flaw in Debian. Thanks for the info.
<lle-bout>maybe the : will bug sneek
<nckx>No.
<nckx>That's the syntax I always use.
<lle-bout>OK!
<lle-bout>Well see you!! Thanks again for fancy lint CVE! Still can't make it work aaa
<pkill9>what features might i be missing with linux kernel 4.4 longterm?
*nckx requests a CVE.
<rhou[m]>is there a possibility to define ad-hoc dependencies in a manifest file?
<Ikosit>rekado_: Shouldn't `guix system reconfigure` automaticllay restart guix-daemon?
<Ikosit>Btw, it works now :D
<nckx>Ikosit: It shouldn't restart any running services.
<nckx>Define ad hoc dependencies.
<Ikosit>Oh yes, of course
<nckx>;)
<nckx>‘Package transformation options’?
<nckx>If yes: manifests are just package objects. They aren't lists of names, even though that's how they're most conveniently used. You can define your own packages in-line, including (package (inherit foo) ... (inputs `((...) ,@(package ))).
<nckx>*just lists of
<nckx>rhou[m]: ☝
<nckx>That should be (package (inherit foo) ... (inputs `((...) ,@(package-inputs foo))).
<rhou[m]><nckx "If yes: manifests are just packa"> you mean inside the manifest file?
*nckx does not excel at pentatasking.
<nckx>rhou[m]: Yes. They are just Scheme files that must evaluate to (‘return’) a list of package objects. You can do whatever you want to get there. (use-modules), (define stuff), run your own crazy procedures, ....
<rhou[m]>or asked in another question: what is a sensible way to structure a development environment inside a manifest file to commited to git?
<civodul>heads-up! https://guix.gnu.org/en/blog/2021/risk-of-local-privilege-escalation-via-guix-daemon/
<civodul>nckx: thanks for requesting the CVE
<nckx>First time, too. Let's see how well I did.
<nckx>rhou[m]: Not ignoring you, just can't say.
<rhou[m]><nckx "rhou: Not ignoring you, just can"> 😄 no worries
<i1l>sneek: later tell raghavgururajan i heard that Fedora keeps some captured (literal) Gnomes to work on Gnome. need to run, or Gnomes will catch me.. be careful. your packaging attempts have had drawn their attention..
<sneek>Will do.
<nckx>None of my development environments are remotely sane.
<efraim>how can I use the substitute regex to find everything except files ending in .ogg?
<civodul>nckx: let us know how it goes and we can update the web page when we have a number
<civodul>lfam has also prepare a message for info-guix
<cybersyn>has anyone tried to host a haunt website on hurd? thinking about making a little project of it where i document the process as a tutorial
<nckx>efraim: Substitute* or find-files?
<nckx>If you mean a list of file names in, e.g., a Makefile, it would depend on if/how they're quoted (or you ‘know’ they won't contain tricky characters).
<nckx>Otherwise, here's a hack: (find-files "." "([^g]g?|[^o]gg)$")
<nckx>I think that's right...
*bone-baboon finshed the Rust bootstrap chain after days of building from source.
<bone-baboon>So when there is a new version of Rust can the previously built Rust bootstrap chain be used or does the entire bootstrap chain need to be rebuilt?
<civodul>cybersyn: not to my knowledge but that sounds like a fun project!
*civodul seems to have done "something" that turns off ERC notifications for this channel
<cybersyn>sweet, this weekend will be my first session diggin into hurd. amazing how simple guix makes all of this (at least after you've been using it for a few months)
<efraim>nckx: you're right, find-files. which I Was using in substitute
<jlicht>hello guix!
<nckx>efraim: I just noticed that the second argument to find-files needn't be a regex; it can be a procedure, so all that's moot ☺ Just write a readable λ instead.
<nckx>Hi jlicht.
<efraim>nckx: good idea
<zzappie>hello guix!
<zzappie>I think I just wrapped my head arround monads/gexps business
<zzappie>I used to write things like (define (do-stuff) ...) (operating-system ... #~(... #$(do-stuff)) ...) and yell at the repl when it didn't work
*nckx .oO that doesn't work?
<zzappie>It should?
<nckx>You must not be yelling loud enough.
<nckx>(No.)
<zzappie>But it would be nice to have function gexp compiler so it will doo all scheme-file/with-extensions/with-imported-modules/source-module-closure dance
***FossGuy[m] is now known as FOSSGuy[m]
<apteryx>bone-baboon: the existing chain can be used if it`s just a new rust to add at the end of it
<apteryx>civodul: the --with-latest is fun :-) thanky ou
<apteryx>thank you*
<nckx>bone-baboon: However, if a [transitive] input of one link changes, such as mrustc's zlib, then it and all subsequent ones will be rebuilt. Your chain won't last a year, and probably not half one either (if core-updates ever gets merged ☺).
<notcomputernotsc>hello
<notcomputernotsc>I have a question about package transformations from a git url
***notcomputernotsc is now known as notcompnotsci
<nckx>notcompnotsci: Welcome! This is the right place for those (although I'm not the right person to answer).
<bone-baboon>apteryx: nckx: Thanks
<notcompnotsci>okay cool. Well I guess my question is as simple as, what does a valid transformation from a git url look like for a package (I just get errors replicating the docs)? Then does that flag override the hash in the .scm file (since you are cloning from a different repo)?
<nckx>I can answer the last bit: yes, it must, because Guix sources are content-addressed.
<notcompnotsci>okay, next step is me trying to figure out why I have an "invalid Git URL replacement specification"
<nckx>notcompnotsci: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/transformations.scm#n301
<nckx>What does your command actually look like?
<nckx>That's a pretty ‘surface-level’ error, nothing subtle.
<nckx>If you copy-pasted something from the manual and it returned that, it's definitely a bug we need to fix.
<notcompnotsci>nckx: can you message me direct?
<terpri_>notcompnotsci, that error appears if the argument doesn't conform to the --with-git-url=PACKAGE=URL syntax (in particular, if there aren't the correct number of equals signs)
<nckx>If you're using a private URL or something you don't want to share, sure. Otherwise I'd rather keep it here.
<notcompnotsci>it is private yeah
<nckx>NP. I'll respond here though: you're indeed missing a package specification before the URL. The format is --with-git-url=PACKAGE=https://...
<nckx>Most package transformations are.
<charles`>Does anyone else have trouble running out of disk space with guix?
<nckx>I did back when I had a mere 128G SSD and presumed to store ‘personal data’ and ‘my own files’ (imagine!) on it.
<nckx>It's one of the trade-offs of how Guix (and Nix) are designed.
<charles`>I'm on 40Gb virtual machine and `guix gc` freed up 10Gb, but then things were broken, so `guix pull`ed
<nckx>40GB total is... very little for Guix. Is this a hard limit? I dislike the ‘disc space is cheep’ crowd muchly, but it is *worth* the advantages.
<charles`>I could go a bit more, but I only have so much space since it is a virtal machine on my main system
<nckx>Consider using at least btrfs with zstd compression. Free free space, unless your CPU is a potato.
<nckx>(Inside the VM.)
<charles`>I will try that next time.
*nckx AFK.
<charles`>If I am planning to add this configure option upstream, I should add it to the documentation too, correct?
<pinoaffe>charles`: I used to have issues back when I had a 240G ssd filled with 110G music, 10G of photographs, 5G of books, etc
<pinoaffe>but I recently upgraded to a 480G ssd, that should take a while to fill up
<charles`>I know previous genereations can be deleted, but how can previous system configurations be deleted?
<terpri_>charles`, with "guix system delete-generations [PATTERN]" (same PATTERN as "guix package --delete-generations", e.g. 1m; the default is all previous generations), followed by "guix gc"
<charles`>terpri_ that will delete the previous system configurations I see in grub?
<terpri_>yes
<terpri_>in fact it updates grub when you run it, according to the docs
<vagrantc>pinoaffe: maybe you underestimate the gravitational pull of unused storage capacity
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, lle-bout says: see https://issues.guix.gnu.org/47229 and patching Debian
<vagrantc>thanks for the heads-up
<Whyvn>I cant guix pull anymore, would anyone know hwy I get this error? http://paste.debian.net/1189873/ this is with --fallback http://paste.debian.net/1189874/
<raghavgururajan>Hello Guix!
<sneek>raghavgururajan, you have 1 message!
<sneek>raghavgururajan, i1l says: i heard that Fedora keeps some captured (literal) Gnomes to work on Gnome. need to run, or Gnomes will catch me.. be careful. your packaging attempts have had drawn their attention..
<raghavgururajan>i1l: Pardon?
<tracerte>Is anyone having issues with unlocking luks devices as of a recent guix system update? On second prompting for my password during boot I receive a "No key available with this passphrase" response. If I rollback to my 3/10/21 no problem exists. http://paste.debian.net/1189875/
<civodul>Whyvn: it may be a bug recently introduced and then fixed in the daemon: https://issues.guix.gnu.org/47157
<civodul>could you try upgrading your daemon? https://guix.gnu.org/manual/en/html_node/Upgrading-Guix.html
<charles`>Hello raghavgururajan it has been a while. I successfully built and installed your wip-desktop branch. but It isn't on wayland
*vagrantc wonders how often "upgrade guix-daemon" is a way to fix important issues
<vagrantc>that could bode badly for the debian-packaged guix
<raghavgururajan>charles`: Thanks for letting me know. Yes, I still have to work on enabling wayland in gdm.
<raghavgururajan>Folks! When I try to build this (https://paste.debian.net/plain/1189789), I get this error (https://paste.debian.net/plain/1189792). Any ideas?
<charles`>Let me know if there is anything else I can do. In the mean time, I will try to make the wayland experience with gnome+sddm better
<raghavgururajan>charles`: Awesome! Will let you know. :-)
<raghavgururajan>> raghavgururajan‎: Folks! When I try to build this (https://paste.debian.net/plain/1189789), I get this error (https://paste.debian.net/plain/1189792). Any ideas?
<raghavgururajan>Also, someone mentioned about porting to build2.
<nckx>vagrantc: ...why?
<Whyvn>civodul: thank you for the information, I did guix system reconfigure /etc/config followed by herd restart guix-daemon and then guix pull and I still get the error.
<nckx>Well, you'd need to pull to get the updated ‘guix’ package definition..
<Whyvn>nckx: hrm, then I seem to not be able to guix pull to get the new package definitions. It fails every time.
*nckx makes whatever sound an egg makes.
<raghavgururajan>> Folks! When I try to build this (https://paste.debian.net/plain/1189789), I get this error (https://paste.debian.net/plain/1189792). Any ideas?
<raghavgururajan>Also, I tried patching the string "build-0.3" to "build", got an error about having to many files open.
<nckx>raghavgururajan: Posting the same question within 7 minutes is too much. Also, I'm actually looking at it.
<raghavgururajan>nckx: Oh sorry, I did the 'quote and reply' thing. Just wanted to add more information to the context.
*raghavgururajan does this often <-- apologies
<vagrantc>nckx: it means i'll need to backport all security and important patches to guix 1.2.0 for the debian package ... the security updates could happen in a timely manner, but non-security things happen with less frequency
<vagrantc>hopefully any high severity patches remain reasonably backportable
<nckx>raghavgururajan: Oh, mail-style. I'm not sure that works on IRC. We tend to write ‘<shortest unambigious extract of line so much shorter than this stupid example> Lol never mind.’, on one line.
<nckx>It was mainly the multi-line thing that triggered my spamdar, sorry.
<vagrantc>guix's rolling release nature is a bit at odds with debian's workflow ... i had assumed guix-daemon wouldn't need to be patched regularly
<nckx>This particular fix should be easy to backport.
<nckx>But noted.
<raghavgururajan>nckx: Yeah, the ">" appears when I quote, like in email. I should not do this in IRC.
<nckx>(I'd hope Debian has robust processes for ‘security updates [...] in a timely matter’!)
<vagrantc>a lot depends on the maintainer ...
*vagrantc hides
<vagrantc>though the guix community seems helpful enough i'm not too worried :)
<nckx>raghavgururajan: This package's ‘too many open files’ is Guix's ‘imma chomp all your ram for 5 minutes and die’: bootstrap.make:include $(build)/bootstrap.make
<nckx>i.e. infinite recursion.
<nckx>(I think.)
<raghavgururajan>I see.
<raghavgururajan>What's the work around for the initial error?
<Whyvn>I was finally able to succesfully guix pull --fallback, guix package -u, and then guix system reconfigure
<nckx>I think you need to actually provide ‘build’ (the package), which the libxsd build system expects to find in ./build-0.3, and has nothing to do with the existing ‘build’ directory which is just their own build script.
<nckx>I.e. ./build is not the bundled copy of build-0.3 you think it is.
<nckx>(Again, ‘I think’, because I'm resisting this one's gravitational pull and not diving in. Baroque NIH build systems FTW. \o/ )
<raghavgururajan>Just a sec.
<raghavgururajan>nckx, https://codesynthesis.com/pipermail/libxsd-frontend-users/2017-December/000050.html
<raghavgururajan>What's build2?
<raghavgururajan>Oh wait
<raghavgururajan>build and build2 is another projects by CodeSynthesis.
<raghavgururajan>So I need to package them first.
<raghavgururajan>nckx: Here is that missing build-0.3, https://codesynthesis.com/projects/build/
<nckx>Yes.
<nckx>Sorry, I was on that page but assumed you knew.
<nckx>Since you mentioned build2 earlier.
<raghavgururajan>No worries!
<raghavgururajan>Which module should 'build' go to?
<nckx>build-tools 😉
<raghavgururajan>I guess build-tools.scm?
<raghavgururajan>Damn
<raghavgururajan>just received that message.
<raghavgururajan>Thanks!
<muradm>looking at java packages and have some issues with understanding, in java.scm there is for instance openjdk11-jdk and openjdk11 packages. then one with -jdk suffix is private, so it can't be used. but openjdk11 simply does not expose javac (i.e. java compiler). what is the intension of java packages, are they JRE (java runtime env) or JDK but packed incorrectly?
<sneek>muradm, you have 1 message!
<sneek>muradm, rekado_ says: Do “guix install openjdk:jdk” to install the “jdk” output of the “openjdk” package.
<muradm>lol, i had an answer in my inbox :)) use "openjdk:jdk" :)
<Ikosit>Is it normal, that it takes decades (slight exaggeration) to build a package with qemu on the armhf-linux architechture?
<nckx>sneek is psychic, but only after you ask.
<nckx>Ikosit: You're building something on top of a qemu emulator running on armhf-linux hardware?
<nckx>Sounds about right, unfortunately.
<Ikosit>:(
<Ikosit>Yes
<muradm>rekado_: how one can use openjdk11:jdk in (packages->manifest ...)?
<nckx>All armhf hardware I've heard of is slow to begin with. Does it even have some form of virtualisation acceleration? ‘Real’ emulation is slow on its own.
<charles`>Is it possible to configure a package the the same way services are configurable?
<nckx>That's slow² already.
<Ikosit>It seems like the check phase is especially slow
<nckx>charles`: ‘the same way’: no (maybe ‘not yet’, maybe some day), but packages are already infinitely customisable using ‘inherit’ & adding your own tweaks.
<charles`>I'm reffering to programs that have .conf files
<nckx>Not unless you add a default one in a phase. Maybe ‘guix home’ is interesting to you; maybe not. <https://framagit.org/tyreunom/guix-home-manager>
<charles`>I don't think that is that I am thinking. I just want to configure the .conf file in my /etc/config.scm, but it happens to be a .conf file for a package rather than a service
<nckx>Where is the final file stored?
<nckx>If it's a default configuration in the same output directory as the package (I don't know if that's a great practice, but it happens), use a phase to add/patch it during build. If it's in /etc, you're describing a service. And guix-home-manager manages ~. What's left? :)
<nckx>(Not just /etc, of course, all ‘system’ locations besides /gnu/store.)
<charles`>it is where the package is installed so /gnu/store/jibjab/...
*nckx → dinner.
<muradm>what is the diffrence between (inputs .. ("openjdk11" ,openjdk11)) and (inputs ... ("openjdk11:jdk" ,openjdk11 "jdk"))?
<muradm>can't figure out "openjdk11 "jdk"" form..
<jx96>I'm trying to update rust-cargo-c to 0.7.3, but it wants the cargo 0.51 crate as cargo-input. I wonder if this is provided by rust:cargo (rust:cargo provides version 1.50, but rust-cargo-c needs 0.51 and version 0.51 is newer than 1.50 for some reason)? https://crates.io/crates/cargo-c/0.7.3+cargo-0.51/dependencies https://crates.io/crates/cargo/0.51.0
<leoprikler>rust:cargo is not a crate
<leoprikler>I have no idea, how rust handles this internally
<muradm>openjdk11 should be package with multiple outputs
<muradm>how to use in (packages->manifest ...) specific output of package with multiple output?
<leoprikler>("openjdk" ,openjdk) is the same as ("openjdk" ,openjdk "out")
<leoprikler>instead of <package> write (list <package> <output>)
<muradm>leoprikler: that does not work if there are other packages.. (packages->manifest (list curl openjdk11 "jdk"))?
<muradm>this does not compile
<muradm>(packages->manifest (list curl (openjdk11 "jdk"))) this also does not compile
<leoprikler>(list curl (list openjdk11 "jdk"))
<leoprikler>or `(,curl (,openjdk11 "jdk"))
<muradm>leoprikler: oh.. i see now, thanks!
<lfam>Hey nckx
<jx96>leoprikler: In that case, I need to create a new package for the cargo crate?
<lfam>lle-bout: Regarding ImageMagick, it's less easy to test grafts since it is often used via a "command-line API". That is, not as a dynamically loaded library. This is also the main reason we haven't updated to the new release series, because it's really not easy to test.
<lfam>The series we use is fully supported upstream, but it would be nice to eventually update
<lfam>It wasn't very long ago that ImageMagick could be changed directly on our master branch, without grafting. I guess it grew some more dependents
<lfam>We might see about reducing the number of dependents, if some of them don't absolutely require imagemagick. It's a program that should only be used with untrusted input when the user is sure
<charles``>I made an iso image but when I made a virtual machine out of it, it didn't install guix. How to debug?
<lfam>charles``: Can you clarify what you mean?
<raghavgururajan>nckx: Kinda related. While building 'cli' in the following diff, I get -fpermissive errors. Any ideas?
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/f7d30fd6-bd64-47c3-9eac-0c62f71ebeb3/codesynthesis.diff
<lambdanon>Hi, I decided to change over from guix SD to debian on my laptop, and I've found that, even when I add the relevant guix profile sourcing to /etc/profile.d, xfce4-whiskermenu-plugin still didn't see my guix config
<roptat>trying to reconfigure after the vuln was published, and I get "no more space on device" at the grafting stage of a python variant... ungrafting is important!
<roptat>:)
<roptat>bah, just ran gc and tried again, but of course gc keeps collecting stuff that haven't been installed in a generation yet...
<lfam>I've been there!
<lfam>I usually delete some old pull / package profile generations before a big GC
<g_bor[m]>Yeah, same method here :)
<roptat>right, I did that too, and even limited the amount of gc, but I have a small disk, so it collected stuff it just downloaded too
<g_bor[m]>Hello
<roptat>hello .)
<roptat>it worked \o/
***zimoun` is now known as zimoun
<roptat>and I probably have enough space for a few more generations now
<roptat>now, I just need to wait one or two days for guix pull to finish on my armhf server :p
<apteryx>roptat: perhaps Btrfs+zstd could be of help if you aren't making use of it yet
<lfam>Maybe lzo if it is armhf
<lfam>At least, I would benchmark the different algorithms if the computer is very slow
<roptat>the armhf server has no space issue
<lfam>Ah
<roptat>the one that has issues is an x86_64
<roptat>the armhf is just taking days to update because of the lack of substitutes
<lfam>Terrible
<roptat>and because some packages fail to build, so I have to work around that
<lfam>We may need to hurry if we want to get some more ARM hardware for the build farm. It maybe that workstation / home server type hardware will stop being available for a couple years
<lfam>But I think that low-power SBCs will still be in use, so there will be demand for substitutes
<raghavgururajan>nckx: Never mind! The upstream has a patch for it.
<nckx>Hi lfam.
<nckx>raghavgururajan: Excellence.
<lfam>Howdy. I pinged you because I needed help sending that message via info-guix, but another maintainer handle it
<lfam>handled it
<nckx>Been there.
<lfam>Done that
<nckx>It led to an enjoyable half hour of fighting GPG with civodul, and giving up by deciding to share credentials through our berlin home directories 👍
<nckx>Just GPG User Stories.
*lfam searches for "mind boggling" emoji
<nckx>🤯
<lfam>IMO, that one has too positive a connotation
<nckx>Good point.
<nckx>Anyway, consider yourself boggled.
<lambdanon>Currently trying to get my guix installed programs to show up in xfce-popup-whiskermenu. When I use the embedded command line in XFCE, and echo GUIX_PROFILE, it looks right, but whisker menu doesn't see any of the apps I installed through guix
<roptat>lambdanon, probably because it doesn't share the environment with the shell ;)
<roptat>there's a possibility that the program doesn't have a .desktop file too
<roptat>or that you need to reload the menu / the window manager
<roptat>basically, sourcing etc/profile in the shell only affects that shell, nothing outside of it
<lambdanon>I thought as much.... Just need to find how to to configure xfce's environment.
<lambdanon>I would've assumed that xfce's environment would've sourced /etc/profile
<roptat>first, I'd check that the program actually has a .desktop
<lambdanon>It does. It's emacs
<roptat>yes, it should
<roptat>I mean, xfce should source its environment from /etc/profile or ~/.profile I think
<lambdanon>That's what I find strange. On my mint box, I have Guix installed, and it recognized emacs just fine
<roptat>now if you just installed emacs, maybe you need e restart
<lambdanon>On my debian laptop, I have guix installed in the same way, I installed guix the same way, but xfce doesn't see it
***daniel is now known as Guest209
<lambdanon>The difference is that, on my debian laptop, I installed emacs through a dedicated manifest and profile, I added the boilerplate loop for sourcing the profiles in /etc/profile
<roptat>oh, so xfce must be loading its environment from somewhere else
***j is now known as jess
<lambdanon>Looked it up. Apparently you can add some code into /etc/X11/Xsession.d
<Ikosit>Nomad doesn't build on my system :/
<Ikosit>I get the error that autoconf is missing even though autoconf is a native input
<nckx>🤯
<nckx>Ikosit: Which architecture are you on, and are you just doing something boring like ‘guix install|build|... nomad’?
<nckx>Actually, there was a commit today or yesterday that touched autoconf-wrapper inputs, replacing them with autoconf...
*nckx pulls guix.
<Ikosit>I have a normal 64 bit system and yes i just wanted to try to intall it
<nckx>s/normal/Intel/ da.
<nckx>./autogen.sh: line 2: autoreconf: command not found
<nckx>I bet that's it.
<nckx>No, I think it's commit 475c3278df4f9dc1bc708e1092e8c93d0618711a.
<pkill9>wait, there's nomad *and* nyxt? *two* scheme-based web browsers?
<Ikosit>Which branch fits a patch, that removes a package?
<Ikosit>nyxt is clisp based
<pkill9>ohh yea
<nckx>Ikosit: < I get the error that autoconf is missing even though autoconf is a native input> I don't see that. Where?
<lfam>Ikosit: You mean, on which Git branch would we remove packages from Guix?
<nckx>I'm looking at https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile-xyz.scm#n3293
<nckx>Ikosit: master.
<nckx>Assuming it's unused 😛
<Ikosit>nckx: I meant "./autogen.sh: line 2: autoreconf: command not found"
<Ikosit>lfam: yes
<nckx>I mean <even though autoconf is a native input>.
<lfam>Ikosit: Like nckx said, we typically do it on the master branch
<nckx>I'm looking at the emacsy-minimal package on master and it's not, nor is it to emacsy.
<lambdanon>roptat Adding some code to source /etc/profile in /etc/Xsessions.d worked a treat. All is good
<nckx>Ikosit: ☝
<roptat>great!
<Ikosit>nckx: Oh, your right
*Ikosit slaps himself in the face
<nckx>🐟
<Ikosit>I looked at the definition of nomad, not at the one of emacsy-minimal
<nckx>No problem, I thought I was confused :)
<Ikosit>:D
<nckx>Anyway, Ikosit, this <https://git.savannah.gnu.org/cgit/guix.git/commit/gnu?id=475c3278df4f9dc1bc708e1092e8c93d0618711a> removed autoconf but implies that re-adding it is probably not going to magically fix everything.
<nckx>Still, I'll give it a go.
<nckx>Oh, look at that.
<nckx>It magically fixed everything.
<nckx>Ikosit: Please pull and retry.
<lfam>I've pushed the documentation change from #47111 (removing inactive committers)
<lfam>I can start putting it into practice now
<lfam>Shall I email a notification to each of the committer, CC-ing guix-maintainers?
<nckx>Oh... ‘Exploitation is more difficult, but not impossible, on machines [with protected_hardlinks].’ I'd like to push a parallel change to (etc news) to reflect that unfortunate fact, but is it safe (not to mention moral) to retroactively do so?
<nckx>civodul: ☝
<nckx>lfam: Sounds good.
<lfam>Yeah, whatever you think is appropriate nckx
<nckx>I'm out of opinion for once.
<lfam>I think it's not a huge deal since the changes in guix-daemon do close the vulnerability, with or without protected hardlinks
<nckx>We explicitly say such systems are ‘unaffected’. That's not acceptable, I'm just unsure about how to handle the change.
<lfam>We could push a news update that says something like "In XXX news update, we said YYY, but that was not exactly correct. In fact, ZZZ is the case"
<nckx>Yes.
<roptat>nckx, I think it's safe, guix will simply ignore the update since it applies to the same commit
<Ikosit>nckx: It builds! :)
<raghavgururajan>Are `.l` files part of libraries?
<roptat>after all, we do that for translations
<nckx>lfam: That's what I was going to suggest, it just looks horrible. Too late now.
<lfam>It's not ideal, but it's always a good look to recognize our mistakes and try to fix them
<nckx>roptat: We do it for typoes, not for things that change the meaning of things. I'm going to write a new news item.
<nckx>We'll look silly, we'll live.
<roptat>right :)
<lfam>Protected hardlinks changes the vulnerability from "dead simple to exploit" to "has to win a race"
<nckx>roptat: Guix not re-showing the news as if it's, well, new would be bad in this case.
<roptat>I'm getting a significant speedup between fedora's python3 and our python3 when I apply all the flags, maybe because it's not the same version, but still
<nckx>Cool!
<roptat>I want to collect statistics for our current python and I'll send everything tonight
<roptat>mh... something must be wrong, our current python is just as fast as fedora's according to my numbers
<roptat>well, preliminary*
<roptat>I guess I'll re-run fedora's test too, maybe running them first actually added some overhead where python was compiling the benchmarks
<nckx>Oh, and Ikosit: Great! Does it work, too? It seemed to.
<Ikosit>Yes, i guess
<pinoaffe>vagrantc: yes that gravitational pull is quite strong, but I think I should be fine for a while, especially because most of the data I store doesn't need to be on my laptop's SSD
<pinoaffe>my university structurally throws out decent HDDS with storage capacities ranging from 500GB-8TB, so I use a couple of those for long-term storage
<civodul>nckx: yes, you can change news.scm, it's designed to be changeable :-)
<nckx>pinoaffe: Could you ask them to throw some harder, in this direction.
<nckx>civodul: And Guix will present it again (as new) on the next pull?
<civodul>nckx: for the blog post, maybe you can add an "UPDATE:" marker if you think it's useful
<nckx>Didn't do so in my quick test.
<civodul>nckx: no, it won't become new again, but those who get it later will get the new text
<pinoaffe>nckx: lol, I'm not sure you'd want disks that have been thrown that hard :)
<nckx>We can't say ‘foo is unaffected’ then silently change it to ‘foo is affected a bit’ for people who've already pulled.
<civodul>lfam, nckx: should we email oss-sec? perhaps when we get the CVE ID?
<lfam>Sure, we could even email them now and follow up with the ID later
<nckx>That's just not right, and I'm writing a news.
<lfam>nckx: Well, nobody is affected after they pull
<civodul>nckx: right
<civodul>nckx: i mean, lfam is right
<civodul>news.scm is different from the blog post in that regard
<lfam>The mistake is in describing the past, not the current reality
<lfam>But yes, we could also amend the blog post to make it clear that we updated it
<nckx>pinoaffe: I'll set up a parabolic reflector made of old mattresses (student town; these things are cheap).
<nckx>Well, cheaper than hard drives.
<civodul>yes, update the blog post + bug report
<nckx>‘Well, nobody is affected after they pull’ - That's not true either.
<pinoaffe>nckx: if you're in a student town digging through that university's ewaste might be worthwhile
<nckx>They aren't affected after they reconfigure.
<Ikosit>Is it possible to use a layout from kbd with the operating systems keyboard-layout field?
<nckx>lfam: <The mistake is in describing the past, not the current reality> Not necessarily.
<pinoaffe>nckx: the physics, astronomy and chemistry departments o'er here (leiden, the netherlands) throw out some great stuff, from hard drives and thermal cameras to consumer electronics, entire test setups and on one occasion even a mass spectrometer
<lfam>Right, s/pull/reconfigure
<nckx>That changes the meaning of everything above, and my original point stands.
<lfam>And by "past" and "present" I'm referring to the "current" state of the Guix source code
<lfam>Not what people have on their systems
<lfam>I'm not sure what your point is or what we are disagreeing about...
<lfam>I agree that we should clarify the advisories
<nckx>lfam: I don't know either; I don't see how ‘The mistake is in describing the past, not the current reality’ addresses my point at all (that updating news potentially marked as read is bad).
<lfam>I never said it was bad...
<nckx>I did.
<lfam>Anyways, I'm agreeing that we should fix it
<lfam>I can send the message to oss-sec. Will someone else update the news.scm and the blog post?
<Ikosit>Would it be possible to let the keyboard-layout field of the os record recognize a string or an keyboard-layout specification? In the first case it would use a keyboard layout from kbd and in the second it would convert a layout from xkeyboard-config. Or would that complicate the record too much?
<pineapples>o/
<pineapples>I had a few bad reponse errors within the last minutes, which has led to "Git error: the index is locked". How do I proceed with this?
<civodul>nckx: can you update news.scm and keep-failed.md?
<civodul>lfam: could you email https://issues.guix.gnu.org/47229 BTW?
<lfam>About the clarification, civodul
<lfam>?
<civodul>yes
<civodul>i'm not sure why protected hardlinks won't help actually
<lfam>Sure
<civodul>you wouldn't be able to "ln /etc/shadow /tmp/guix-build-foo.drv-0/bar" as an unprivileged user, would you?
<lfam>I believe you're correct about that
<lfam>There are more complicated race-y attack vectors with the old guix-daemon code
<lfam>I can't say I have a good handle on them
<civodul>ok
<civodul>pineapples: could you paste what you got exactly?
<nckx>civodul: I already updated news.scm as I'd said I'd do before all the nonsense above started. What's keep-failed.md? The blog post? I always forget which repo those are in, sec...
<pineapples>Of course
<lfam>They are in guix-artwork.git, nckx
<lfam>Sorry you thought our conversation was nonsense
<nckx>Ta.
<civodul>pineapples: does it look like https://issues.guix.gnu.org/47157 ?
<nckx>Well, it wasn't much of a conversation, so whatever it was I'm glad it's over :)
<civodul>hmm
<lfam>It's not that easy to have a normal conversation in chat. It's easy to talk past each other and misinterpret each other
<pineapples>civodul: https://paste.debian.net/1189916/
<nckx>Is there a mail (presumably from the reporter? I dunnactuallyknow) detailing the details? (Beyond what you've said here, which gave a pretty good idea.)
<lfam>Detailing which details?
<nckx>Of the race, leaving aside for now whether it actually exists.
<nckx>lfam: Amen to that.
<pineapples>Pardon me for not including the backtrace. I'll create another paste with it, if you need me to
<lfam>I forwarded some of their messages to guix-security, nckx
<civodul>pineapples: the bad-response issue sounds like the bug above
<nckx>lfam: For context, I only happened to notice your push of ‘website: keep-failed bug blog post: Clarify the impact of protected hardlinks.’, I know nothing more.
<nckx>OK, thanks.
<lfam>It might not be enough to satisfy, I'm not sure
<pineapples>It has been becoming more and more frequent. I can't guix pull or reconfigure my system without at least getting this error twice.
<lfam>I think that, with the old guix-daemon code, it's not possible to enumerate all the ways one could race the code to do bad stuff
<nckx>:)
<lfam>It turns out that Unix does not have one program to do this particular thing well
<pineapples>Either way, how do I proceed with this? Is there a lock file of some sorts I need to delete, civodul? I'd like to update my system, as I'm vulnerable to that privelige escalation thing
<lfam>(Changing ownership, that is)
<nckx>Hmm, last guix-security mail in my box is Mark's.
*nckx .oO Is mu buggered again...
<lfam>I checked and you are still subscribed
<lfam>I'm going to collate the rest of my correspondence with the researcher and send it there, soon-ish
<civodul>pineapples: was there no other guix process running, as the Git error says?
<civodul>i would just say "try guix pull again" as the bad-response issue is transient
<nckx>lfam: Was this recently, lfam? I've gone so far as to ssh into my mail server (just a regular day on Unix! barf) to check, but nothing there yet.
<lfam>The messages are dated March 16
<pineapples>civodul: There was two, one of which was the child of the other one. I terminated the former, and there's only the parent remaining now, but it won't allow me to run guix pull, regardless
*nckx meanwhile nukes their mu db just for something to do.
<pineapples>Am I supposed to kill all guix-build processes?
<pineapples>guix-daemon*
*pineapples reboots
<nckx>Eh, pasted an http:// URL into the vulnerability news item. Feels fitting. Still, I'll fix it.
<PotentialUser-52>hmm somewhere between 266d55d and 45695cc broke ... when using sysctl service, guix system reconfigure exits saying "guix system: error: service 'sysctl' provided more than once"
<pineapples>I'm back
<pineapples>I've rebooted the machine and am still getting that error..
<lfam>PotentialUser-52: That's correct. See this commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=898489f48e436e45e86e1ba0fcdb6df5cd5a051a
<lfam>It's not considered a breakage, but rather an improvement that people who are using sysctl-service-type will have to adjust to
<PotentialUser-52>maybe ive missed something but that seems quite obscure .. thanks though :)
<lfam>Do you need help adjusting?
<lfam>The commit includes documentation changes that explain what you need to do
<PotentialUser-52>nah i think i'll manage
*vagrantc wonders how hard it would be to enable an o1rk cross-toolchain
<lfam>PotentialUser-52: In the interest of understanding how people use Guix, can you clarify what you thought was obscure? The change? Or how one needs to adjust to it?
<lfam>The way we implemented this change was kind of contentious. I'd hoped to avoid anyone experiencing what you did, but doing it this way was considered more correct.
<raghavgururajan>How to unpack and view .drv.bz2 logs in a single command?
<pineapples>oh yes!..
<pineapples>I can feel you, raghavgururajan
<lfam>bzcat?
<raghavgururajan>bzcat file | less ??
<lfam>Vim works
<pineapples>lfam, this is the best thing since sliced bread
<pineapples>thank you
<lfam>Cheers
<raghavgururajan>Nice! bzcat works
<raghavgururajan>thanks lfam
<cbaines>bzless is also a thing
<vagrantc>emacs also works :)
<nckx>raghavgururajan: Most compressors include their own equivalent: {z,xz,zstd,...}{cat,grep,less}. ‘atool’ provides an automatic front-end (‘acat’ etc.) but I don't know if it's still maintained.
<clone11>Does anyone know what %desktop-service is making my laptop screen turn off when idle? I tried elogind-inhibit with an infinite loop but it still turned off after a while.
<lfam>It could be happening at the kernel level clone11
<lfam>For example, in my kernel-arguments, I have "consoleblank=120", which turns off the display after 2 minutes idle
<lfam>I don't think this is enabled by default, however
<raghavgururajan>nckx: I see.
<nckx>lfam: Does that work even in graphical modes?
<lfam>I don't know. It's a non-graphical laptop
<nckx>Wow.
<raghavgururajan>what is exit code 2?
<raghavgururajan>*status 2
<raghavgururajan>command "make" "-j" "2" "install_prefix=/gnu/store/rdsi8ydj7a3ms9zzz9if5vr2mg3dx82s-xsd-4.0.0" failed with status 2
<raghavgururajan>Thats all it says in the logs, at the very end.
<PotentialUser-52>lfam: I didn't notice a breaking change incoming. Maybe I just did not see it in the news items where I would have expected it (even though I thought I've read everything). Or maybe it was announced way back when I didn't yet use guix. I now changed my config accordingly and it says "guix system: error: more than one target service of type 'udev'"
<PotentialUser-52>I guess I missed something else then.
<lfam>PotentialUser-52: Sorry, we should have made a news entry for it, so you'd be notified on `guix pull`
<lfam>Regarding udev, that's totally unrelated to sysctl, so I don't know what's up there
<raghavgururajan>nckx: This is the last codesynthesis package that I am stuck with. The build of 'xsd' stops without any error message. Any ideas? (diff is in the below link)
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/8c813672-f7e4-4721-b56b-3edc4a081c98/codesynthesis.diff
<PotentialUser-52>I only get that udev error when I use the new way of doing sysctl-config.
<civodul>vagrantc: hey! do you plan to patch the Debian package?
<vagrantc>civodul: was planning on looking into it
<vagrantc>hopefully it's not too invasive
<vagrantc>civodul: someone fled a security bug in debian about it already :)
<nckx>vagrantc: The daemon's very, er, ‘mature’. I'd be shocked if that short patch didn't apply at all.
<nckx>raghavgururajan: Building, but I will not remain up for long.
<raghavgururajan>nckx: No worries! Thanks for looking into it.
<lfam>I sent the advisory to oss-sec a while ago. It's waiting for moderation, I suppose
<nckx>lfam: Any idea how long CVE delivery usually takes?
<lfam>How did we apply for it?
<nckx>Er, ‘nckx threw things into a Web form until the submit button worked’.
<raghavgururajan>nckx: Info: I tried replacing 'build with (invoke "make"), the build finishes. But isn't that what gnu-build system does?
<lfam>Ah, the MITRE web form, nckx?
<nckx>Nah, I was all diligent & shit, but it's still my first time.
<nckx>Yes, that thing.
<lfam>I don't have a lot of direct experience with it, but my impression is "days to never"
<lfam>If I didn't know better, I'd say that MITRE was trying to destroy the CVE method of tracking vulnerabilities
<nckx>raghavgururajan: More like (apply "make" "-j" (parallel-job-count) make-flags) but very similar, yes.
<nckx>Oh, OK, eh, wow.
<nckx>:(
<lfam>If they don't reply in a week, I would suggest find a friendly CNA and using that: https://cve.mitre.org/cve/cna.html
<lfam>Yeah, since they stopped assigning them based on oss-sec mails, it's been total chaos
<lfam>Let's see!
<lfam>Maybe it will work
*nckx takes down the ‘welcome home first CVE’ sign and balloons.
<raghavgururajan>nckx: I see. So should be setting #:parallel-build? #f
<lfam>It's just that I've noticed several messages on oss-sec that mentioned they applied that way and never got a reply. And then someone with "connections" replies with a number
<nckx>raghavgururajan: I didn't mean that specifically, but the difference must be somewhere. And some packages do fail with -j N>1, it's worth a try.
<raghavgururajan>nckx: Thanks!
<nckx>lfam: Thanks for the reality check.
<lfam>It's a shame :/ The old method using oss-sec was super easy
<lfam>I never figured out why they stopped doing that
<nckx>I feel naive for thinking ‘oh, perhaps we might've had a CVE by now & I could have put it in the follow-up news item’ earlier.
<lfam>MITRE is technically not part of the US government, but barely
<nckx>raghavgururajan: ‘make: *** No rule to make target '-lnsl', needed by '/tmp/guix-build-xsd-4.0.0.drv-0/xsd-4.0.0/examples/cxx/tree/order/element/driver'. Stop.’
<nckx>That's what some parallelism bugs look like.
<lfam> https://cve.mitre.org/data/board/archives/2015-11/msg00023.html
<nckx>Thanks for digging that up.
<raghavgururajan>Gotcha!
<lfam>I'm trying to find the date when oss-sec stopped being a place for assignment, but that's a description of some difficulties with the new process
<lfam>Here it was: https://seclists.org/oss-sec/2017/q1/351
<lfam>So, after that other message
<lfam>Nevertheless, it's chaotic
<lfam>I think that we just have to be patient
<Ikosit>How can i use a local guix repositoy with guix pull?
<Ikosit>Because I can't authenticate my commits, can I?
<nckx>Ikosit: For a one-off pull, use --url=file:///home/... [--allow-downgrades] [--disable-authentication]
<nckx>To make the URL permanent, write your own channel.scm.
<Ikosit>thanks
<nckx>Yes, good point, I forgot about that. I don't think there's a way to make --disable-authentication permanent apart from writing your own wrapper script/shell function.
<nckx>It would be a somewhat scary feature to support IMO.
<nckx>Or at least iffy.
<nckx>raghavgururajan: No, it still happens with #:parallel-build? #f. It's a real bug boy. Congratulations. :(
*nckx needs sleep. o/
<raghavgururajan>o/
***link2xt[nm] is now known as link2xt