IRC channel logs


back to list of logs

<leoprikler>raghavgururajan: session-environment-service-type
<shcv>also, any idea why I get "error: (shepherd-service-type ... #f): source expression failed to match any pattern" when trying to define dummy-networking-service-type as shown in ?
<Whyvn>I am trying to make a package and adding the required dependicies. they are zlib, boost, pthread, and fuse. Would it be under inputs like: (inputs `(("zlib", zlib)("boost", boost)("pthread", pthread)("fuse", fuse))) my main conern is when I do this, it says it cannot find boost, even though I can search it in the package repo. Also i dont see pthread in the package list, only pthread-stubs (unless this is it) and when I only include
<Whyvn>zlib it says "has an invalid input: #<<license> name: "Zlib" uri: "" comment: "">"
<raghavgururajan>leoprikler: Thanks!
<Whyvn>ok, i think i understand, you have to add the location in the define module
<Whyvn>is it possible to move around a directory structure and perform make commands? for example, this package I am trying to make using guix wants locally cd ./packagelib/ make clean then cd ../otherlib cmake . make clean make cd ../ cmake make make install, is it possible to do all this moving around with a package scm script?
<dftxbs3e>the security patching situation with qemu is a nightmare
<dftxbs3e>qemu does not make releases, they disclose vulnerabilities with CVEs all over the place every other day with standalone patches spread over mailing lists
<dftxbs3e>I think the CVEs might be handled that way because they are rather low impact issues, but still, it creates stress
<dftxbs3e>ugh so many cve patches to apply or upgrades to make, feeling overwhelmed and can't keep up, I am tired, good night
<dftxbs3e>(I would really need to know Scheme better so I can create tooling to ease my task)
<dftxbs3e>E.g. automatically update package definition etc. adding patch and create commit compliant with GNU Guix guidelines
<dftxbs3e>also number of security issues to fix increases from day to day I can't ever keep up with the amount of them, need help
<shcv>is it supposed to be one package per patch?
<shcv>(or rather, at most one package per patch)
<shcv>also, it would be great if someone would be willing to walk me through the process once; assigning copyright, formatting patches, emailing them etc.
<shcv>that and/or making a video tutorial on the process would be most helpful
***iyzsong-- is now known as iyzsong-w
<shcv>I'm working on packaging a rust app, and trying to follow the naming conventions
<shcv>it looks like only rust versions are in rust.scm, and everything else is in rust-apps?
<shcv>the crate importer generated the package name "rust-amcl-0.2"; should I be including the version in the package name for others that aren't crates?
<shcv>I'm going to be packaging a lot of crates; doesn't feel like they should be considered "apps"
<pkill9>waypipe is awesome
<shcv>maybe a new rust-crates.scm? or rust-libs.scm? or to follow python, "rust-xyz.scm" :P
<pkill9>it's just like X forwarding, but for wayland applications, including wayland compositors
<shcv>pkill9: yeah, I'm looking forward to the wayland future
<shcv>though I'm stuck in X for now because about all I use is emacs+EXWM
<shcv>it will be awesome when someone makes emacs-pgtk-native-comp a wayland compositor :D
<Whyvn>hrmm, it seems the /etc/hosts file is read only and gets overwritten on reboot. What is the recommended location for addings hosts entries?
<Whyvn>guess the config.scm file
<lfam>shcv: Crates go in crates-io.scm
<shcv>ah, that makes sense
<shcv>I figured they had to be hiding somewhere
<lfam>Whyvn: Check the manual section "operating-system Reference" for how to use hosts-file
<Whyvn>lfam: thanks, just found it. also with this warning "One should never have to touch files in /etc" still getting used to the config.scm way ><'
<lfam>It's definitely different from everything else, and takes some getting used to. And there are trade-offs between kinds of flexibility
<shcv>it would be cool if the spec could be used to compute a diff from the current and running systems, so that you could e.g. identify dirty files that might need to be saved, or apply the change incrementally instead of rebuilding from scratch
<shcv>can somebody help me with a rust package? I'm only one step into the massive tree of dependencies I need and the build is already failing...
***pmy_ is now known as pmy
<shcv>two rust packages, the first depending on the second but not getting it for some reason:
<lfam>After 50 years, mkdir-p is still not a standard part of Unix
<lfam>How does it fail shcv?
<wdkrnls>is there some way to decrease the priority of the package upgrade so that it doesn't freeze my poor aging laptop?
<wdkrnls>I've figured out I could "offload" building jobs to my desktop computer, but even with that the upgrade freezes my laptop temporarily.
<shcv>lfam: "error: failed to get `amcl` as a dependency of package `milagro_bls v1.4.0..."
<shcv>several 'caused by's
<lfam>wdkrnls: You could limit the Guix compilation to a single core with --cores=1
<lfam>Or, use a tmpfs for building
<lfam>If you figure out what is actually slow (CPU, disk, etc), it's easier to recommend an improvement
<lfam>shcv: Some rust packaging expert will be around eventually. But, I think the cargo.toml file is kind of important. So, you might have problems if it is missing
<shcv>ah, it's a submodule that hasn't been loaded I guess?
<shcv>how do I add those?
<shcv>lfam: any idea how to work with git submodules?
<lfam>Yeah, check the docs on git-reference in here:
<lfam>There is a #recursive? key you can set
<lfam>You're welcome!
<lfam>Don't miss the colon
<shcv>making much more progress now
<shcv>but soooo many deps that need updating
<shcv>question: if a package (imported crate) depends on a newer version, so I import the package, but what's returned is the latest, should I update the inputs to match? Or somehow figure out how to import the exact version?
<lfam>I think the importer can import all the packages in one command
<lfam>Are you using it like that?
<shcv>uh; I've been filling in missing parts of the tree one at a time
<shcv>recursive import would be nice
<lfam>It can work recursively, if I understand correctly
<shcv>I see the option now
<shcv>so much better
<shcv>also, so many recursive deps >.<
<lfam>Rust dependency graphs are really big. Second only to JS from what I've seen
<fossguy[m]11>hlw nckx
<fossguy[m]11>getting this error when installing guix on gentoo:
<fossguy[m]11>can anyone help, plz?
<lfam>What steps are you taking to install it?
<fossguy[m]11>the shell installer script
<lfam>If I were you, I'd install it manually, using these instructions:
<fossguy[m]11>It also recommends to use the script :)
<lfam>I know, but the script isn't working
<fossguy[m]11>It doesn't also contain any instruction for openrc
<lfam>The only other thing I can recommend is to debug the script
<fossguy[m]11>I only need to configure guix with openrc. Only that instruction will be enough.
<lfam>Well you need to make an openrc file (I don't know what they are called) that runs the guix-daemon appropriately
<lfam>This is the file that is supposed to be used to create the openrc script thingy:
<lfam>For @localestatedir@ use '/var'
<shcv>I think I got stuck on a dependency declared as coming from git; it's trying to fetch it but can't
<shcv>anyway, g'night
<fossguy[m]11><lfam "This is the file that is suppose"> Can I copy paste it to that dir which in my case doesn't exist?
<lfam>Which dir?
<fossguy[m]11>lfam: /root/.config/guix/current/etc/openrc/
<lfam>The file is supposed to be copied out of that directory into another
<lfam>So, better to put it where it is supposed to end up
<lfam>That is, /etc/init.d
<shcv>fossguy[m]11: I just looked for an overlay with guix and found this:
<shcv>it was updated 13 days ago
<fossguy[m]11><shcv "FossGuy: I just looked for an ov"> I don't trust overlays.
<shcv>eh, then just use the ebuild directly
<lfam>It seems like this init script stuff is messed up overall
<lfam>Neither the openrc or systemd files are where they are supposed to be
<lfam>Nor the old init.d files
<fossguy[m]11>Let's open an issue
<shcv>also the main guix packages in portage are way out of date
<lfam>fossguy[m]11: Would you like to open it? You can send mail to <>
<fossguy[m]11>how do I download this file?
<shcv>actually, looks like my portage db is just out of date; I think they removed it
<lfam>Click "plain"
<lfam>I downloaded the 1.2.0 binary release. It does include the systemd, init.d, and upstart scripts. But not the openrc scripts. But, somehow, none of them exist in the current-guix profile with current Guix
<fossguy[m]11><lfam "I downloaded the 1.2.0 binary re"> What is this?
<lfam>It's a closed patch ticket
<lfam>I'm gonna open the bug
<fossguy[m]11>Didn't it add openrc support?
<lfam>It appears that was the intention
<lfam>fossguy[m]11: I filed the bug: <>
<lfam>You can chime in by replying to <>
<lfam>Sorry it's not working
<fossguy[m]11>How to install ttf fonts in guix
<leoprikler>sneek: later tell Whyvn you're confusing packages and licenses with the same name. The solution is to ([use-modules ...]((guix licenses) )
<sneek>Got it.
<leoprikler>sneek: ater tell Whyvn you're confusing packages and licenses with the same name. The solution is to ([use-modules ...]((guix licenses) #:prefix license:). Sorry about the typo above.
<sneek>Whyvn, leoprikler says: you're confusing packages and licenses with the same name. The solution is to ([use-modules ...]((guix licenses) #:prefix license:). Sorry about the typo above.
<leoprikler>sneek: later tell Whyvn you're confusing packages and licenses with the same name. The solution is to ([use-modules ...]((guix licenses) #:prefix license:). Sorry about the typo above.
<sneek>Got it.
<mothacehe>hey guix!
***apteryx is now known as Guest98270
***apteryx_1 is now known as apteryx
<zimoun>hey mothacehe! Tricky bug the pointer stuff. :-)
<mothacehe>hey zimoun! Yes, fortunately I found a work around!
<zimoun>yeah guardians, right?
<fossguy[m]11>How to run packages installed with guix
<zimoun>mothacehe: how do you compile “libtest”?
<civodul>Hello Guix!
<mothacehe>hey civodul!
<mothacehe>zimoun: gcc -pthread -shared -o -fPIC gc.c -g -O0
<civodul>fossguy[m]11: hi! check out
<fossguy[m]11>I can't run ungoogled-chromium, though I can other packages
<zimoun>mothacehe: ah, was missing the gc.c part. :-) So in Guile checkout right?
<mothacehe>in this environment: guix environment --ad-hoc guile gcc-toolchain
<fossguy[m]11><civodul "FossGuy: hi! check out https://g"> How to make these packages appear in my start menu?
<civodul>fossguy[m]11: on Guix System, they appear automatically; however on "foreign distros" they don't appear
<civodul>are you on Guix System?
<fossguy[m]11>Any way to make them appear?
<civodul>on foreign distros? i don't know
<zimoun>mothacehe: thanks. Reproduce the crash, I guess.
<zimoun>fossguy[m]11, are you using the Window Manager from Guix or from your foreign distro?
<civodul>mothacehe: i'm testing the simple config:
<civodul>IWBN if we could specify the jobset name :-)
<mothacehe>let me see what can I do :)
<mothacehe>is it working otherwise?
<civodul>looks like it!
<civodul>pretty nice
<civodul>though i can only have one jobset, right?
<mothacehe>I guess like jonsger, you will be interested by the "channel" option
<mothacehe>glad it works!
<civodul>i think i'd like full expressivity, so i can have multiple jobsets etc., while keeping simple things simple
<mothacehe>I'm rewriting Cuirass evaluation, so that there's no need for this "simple-configuration" hack
<civodul>replacing the keyword alists (specs) with records and clarifying the terminology (inputs, etc.) would help a lot
<mothacehe>yes that's my plan!
<civodul>awesome :-)
<mothacehe>also it will directly operate on channels
<mothacehe>instead of inputs
<jonsger>mothacehe: I am :)
<civodul>so we don't need an extra concept
<mothacehe>yes an it stays conceptually close to "guix pull"
<mothacehe>the only part I'm not sure of is the database registration itself. Let say I keep an evaluate process that receives a list of channel instances and evaluates a procedure within the inferior to produce a list of derivations.
<mothacehe>I'd like to be able to directly register the derivation in database from this inferior
<mothacehe>without using a socket hack like in the patch I sent last week
<civodul>in general, you can't assume that you can load your code in the inferior
<civodul>because it could be running a different Guile, a different libc, etc.
<civodul>so i guess you have to keep that process boundary
<mothacehe>hmm I see, thanks. I'll try to propose something soon.
<fnstudio>hi, i was experimenting with something but maybe i was just being naive. i installed guix on a rasberry pi via debian and apt install
<fnstudio>it did install, but my first guix pull seems to never end
<fnstudio>maybe a raspi 3 with 1gb ram is a no-no?
<fnstudio>i think i authorised the gnu substitute server (and i restarted the daemon just in case) - but i'm not even sure that is relevant at all in the pull process?
<fnstudio>it's now saying "building /gnu/store/...guix-packages-base.drv..."
<fnstudio>(which i left running last night and got stuck at some point)
<civodul>fnstudio: unfortunately that part is CPU-intensive; it's okay on modern x86_64, but very slow on armv7
<civodul>i guess you'll have to be patient...
<fnstudio>civodul: ah, no that's fine, i understand, good to know it's the process itself and not necessarily something i'm doing wrong or a broken pi
<fnstudio>excellent, thanks
<ltl2>hello, is guix considered a server/enterprise/production-ready os or is it mostly for testing and development?
<ltl2>and/or desktop users?
<ltl2>sorry if my question is a tiny bit messy
<civodul>ltl2: hi! i guess it's production-ready, as long as it meets your needs in terms of packages and system services
<fossguy[m]11>Why can't I create a folder in ~/.guix-profile/share/ ? It gets deleted in every reboot.
<civodul>ltl2: it's mature and actually safer than "traditional" distros in the sense that you cannot really break your system (you can always roll back, etc.)
<civodul>fossguy[m]11: ~/.guix-profile is a symlink to a read-only place
<ltl2>interesting civodul
<ltl2>i guess you're right - and i like that it is rolling release and has a moden kernel version
<fossguy[m]11><civodul "FossGuy: ~/.guix-profile is a sy"> I placed a folder there with root
<avalenn>cidovul, I will have a bit of time this afternoon to work on
<avalenn>I'd love to have a review from you,
<avalenn>my main concern now is that I don't understand your comment on raise-exception
<avalenn>to be honest I don't understand exceptions in Scheme
<civodul>avalenn: hi! sure, i can take a look hopefully this afternoon
<civodul>avalenn: re raise-exception, you can write (raise (formatted-message (G_ "...") arg1 arg2))
<civodul>where 'raise' is from (srfi srfi-34)
<civodul>that's what we usually do in the rest of the project
<civodul>('raise-exception' is +/- an alias)
<avalenn>Ok. I will try that.
<fossguy[m]11>What should I do to make the results of the following two commands persistent across reboots:
<fossguy[m]11> * What should I do to make the results of the following two commands persistent across reboots:
<fossguy[m]11>. "$GUIX_PROFILE/etc/profile"
<nckx>Good morning, Guix.
<ltl2>Good morning.
<nckx>fossguy[m]11: They should already be, so the answer is ‘debug why they're not’. For example the installer should set up /etc/profile.d/guix (IIRC) that takes care of this. Whatever you do, don't add it to ~/.bashrc or your shell's equivalent.
<fossguy[m]11>Install instruction tells me to add them to ~/.bash_profile
<fossguy[m]11>I didn't install with shell script
<nckx>And that didn't work?
<nckx>Here's what the installer would do, you can adapt that to your desires: <>.
<fossguy[m]11><nckx "Here's what the installer would "> i don't realize it :/
<nckx>Let's back up and ignore that for now. You ask how to make it persistent, point out what the manual says, but don't say how/why that didn't work. What exactly did you do, what did you expect to happen, and what (didn't) happen(ed)?
<nckx>Do you use bash as your log-in shell?
<allana>Help! I am trying to use pre-inst-env to build a package in the guix source tree. For example, "./pre-inst-env guix build hello". I get this error: "./pre-inst-env: line 55: exec: guix: cannot execute: Is a directory"
<allana>I feel silly about this, and I am unsure how I should proceeed.
<brown121407>nckx: Why shouldn't we source "$GUIX_PROFILE/etc/profile" in .bashrc? Are there any weird side effects?
<nckx>I'd say the _effect_ is wrong, full stop. Environment variables are meant to be set at the root of the process tree (your log-in shell, which reads *profile) and inherited, maybe with some tweaking, but not violently reset at every (non-login, that reads *rc) child shell.
<nckx>For example: ‘guix environment’ sets up the right environment variables, then launches a shell, but this shell then proceeds to clobber them by doing too much in .bashrc, and your environment will be ‘weird’ and ‘buggy’ (but really just ‘broken’).
<nckx>The header of my .bashrc might explain it better:
<nckx>That regular shells require a configuration file at all is a persistent myth that causes much pain.
<nckx>At most, .bashrc is for unexported shell-local variables like $HIST_SIZE, your cute wrapper bash functions, shell aliases... Note how that's all shell-specific stuff, meaningless to other processes, even to other shells (bash vs. zsh). Environment variables set by $GUIX_PROFILE/etc/profile (like $PATH) are universal. They should not be set in ‘bash.conf’, which bashrc is.
<nckx>There, that's about 3 different ways to think about the same thing 😛
<nckx>Absent allana: Sounds like scripts/guix doesn't exist, isn't executable, or valid. pre-inst-env sets PATH="$abs_top_builddir/scripts:$abs_top_builddir:$PATH" and line 55 tries to find ‘guix’ there. It fails, but since there's a ‘guix’ directory in $PWD you get that confusing error.
<nckx>Make sure you've bootstrapped and built guix without errors first.
<nckx>(Unfortunately, ‘pre-inst-env’ existing doesn't always mean the build is complete or working.)
<roptat>hi! the certificate for has expired ;)
<nckx>roptat: Done.
<roptat>nckx, thank you!
<nckx>To quote myself: It's hosted on but uses a different configuration (dunno why) that can't work, so it will never auto-renew. Had to shut down the entire Web server.
<nckx>To quote myself elsewhere: Someone™ should fix that 😉
<brown121407>nckx: thanks a lot for the explanation regarding environment variables. So the correct way to reload them whenever Guix tells us to source "$GUIX_PROFILE/etc/profile" would be to log out and in again?
<nckx>It really depends on what you need. Sourcing "$GUIX_PROFILE/etc/profile" by hand isn't wrong, but doing it in (say) a terminal window won't make the changes propagate ‘down’ into the rest of your desktop, only upwards into that window and anything you start from it. For that, yes, you will need to relog in.
<nckx>Maybe there are other solutions (like, I don't know what ‘reloading’ Gnome Shell with ‘r’ actually does).
<brown121407>Yeah, that was what I was interested in -- to have it propagate to the all the programs, not just the ones started from that one shell.
<civodul>nckx: don't we have a certbot hook to do "nginx -s reload"?
<fossguy[m]11><nckx "Here's what the installer would "> Thx a lot, now I also have desktop integration. This should be in the docs
<nckx>civodul: That's not the issue.
<pkill9>civodul: have you seen bug 46861?
<nckx>The issue is that (only) is configured to use the http-01 method, which is bro^Wthe one that spins up a Web server on port 80. It can never work on an actual Web server.
<nckx>I guess it was set up, ‘tested’ (‘yup, that works, now let's restart nginx and log out’) and never checked again. That just needs to be changed.
<alextee[m]>How do I make libraries loaded with dlopen find the fonts they need? I keep having this problem on guix but not other distros
<nckx>I can do so this evening but would be chuffed out of my skull if it were no longer needed by then. ☺
<civodul>pkill9: just replied, roughly the same thing as nckx yesterday :-)
<pkill9>i'll see if a newer revision of guix does the same thing
<civodul>nckx: oh so that's a certbot config issue; could you bring it on guix-sysadmin?
<nckx>fossguy[m]11: That's up to you(sers)! You can open a bug report at bug-guix at, and we can discuss how much hand-holding people who choose a manual process should receive.
<nckx>I did, briefly.
<nckx>civodul: ☝
<civodul>oh great :-)
<civodul>i never fully understood certbot; it's somewhat stateful
<nckx>Not terribly, and it's not to blame here, it does exactly what it's misconfigured to do.
<nckx>Much as it pains me, I need to go back to my spreadsheet. o/
<davidl>I just installed and pulled a fresh guix master on a fresh RedHat. Then I added a channel thats hosted on github and when I run guix pull it fails with: guix pull: error: Git error: SSL error: syscall failure: connection reset by peer, any ideas why this is?
<davidl>I tried installing nss-certs and setting some SSL vars but to no avail.
<pkill9>was guix run on freebsd? i can't remember
<xelxebar>vim-full has been consistently failing to fetch substitutes as well as fail to build for me over the last ~2 weeks of pulls.
<xelxebar>Is this just me?
<aadcg>how do I specify the MIT license in a pkg definition?
<pkill9>aadcg: expat
<davexunit>has anyone been able to successfully use guix deploy lately?
<aadcg>pkill9: thanks
<brown121407>How does one respond to an email from the mailing lists? (Specifically the help-guix list). I'm interested in responding to both the person AND the list.
<roptat>brown121407, "reply all" :)
<roptat>the list will know you're answering with the In-Reply-To header your client will send with the reply
<brown121407>roptat: I don't see any "reply all" button :( I only see "reply via email to $SENDER"
<brown121407>(I'm looking at the mail on the web at
<roptat>you're not subscribed to the list then?
<roptat>I'm not sure what the button does ^^
<brown121407>roptat: Nope, I'm not subscribed, cause I didn't want my inbox to be filled with tens/hundreds of messages per day
<roptat>I don't think you can reply in a way that won't break the thread then
<brown121407>Then I'll try subscribing and set some separate folder for Guix or something. Thanks!
<roptat>well, it's too late for that message anyway
***rekado_ is now known as rekado
<brown121407>roptat: hmm, so it seems there's no easy way to do it from the web interface for an old message then?
<wdkrnls>If I specify --max-jobs=0 and --cores=1 will that really let me offload with all the cores on the build machine while constraining the local machine to using 1 core?
<wdkrnls>It's easy enough for me to give it a shot I suppose.
<roptat>yes, I think offload ignores --cores
<roptat>not sure if it lets you build locally though
<roptat>apart for derivations that cannot be offloaded of course
***emacsen_ is now known as emacsen
<efraim>made it past ice-9/boot-9.go on guile-3.0.3 on powerpc without segfaulting, might've solved it for this version!
<brown121407>Is there any setting for Guix to make it stop writing "downloading from https://VERY_LONG_URL" everytime it's fetching something, and just show the thing's name and the progress bar?
<dftxbs3e>brown121407, I don't thinks o
<stikonas>well, the line is in guix/status.scm
<stikonas>you can remove it and run your own guix build
<zimoun>brown121407: on Emacs «M-x shell», you have guix-prettify-mode which replaces long hashes by …
<fossguy[m]11>hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:
<fossguy[m]11>Why does this keep on appearing?
<nckx>Did you?
<brown121407>zimoun: thanks, but I want it to work outsite Emacs too for those 5 minutes a day I'm not inside it
<brown121407>stikonas: thank you, I'll check and see how I can customize it
<nckx>I'd just write a wrapper script in your favourite language that swallows those lines.
<civodul>brown121407: there's currently no way to customize it
<civodul>thing is, it's useful info when using multiple substitute URLs
<civodul>but mostly useless when using a single substitute URL
<nckx>Guix does not want me to get anything done today.
*nckx installs random packages with ‘cursor’ in name.
<nckx>It is not effective.
<nckx>It seems to be related to running Wayland, let's try something like <>.
<jonsger>nckx: eh yes, wayland is fun...
<raghavgururajan>Hello Guix!
<nckx>.oO ‘fleur’ was a stupid name anyway, good riddance.
<nckx>Hi Raghav.
<raghavgururajan>nckx: I figured out that icon issue with Evince. There has to be dconf in the profile.
<nckx>raghavgururajan: I have both dconf and evince in my user profile and neither icon is good.
<nckx>One is missing the other has wings.
<nckx>Oh FFS.
<nckx>‘gi.repository.GLib.Error: gtk-icon-theme-error-quark: Icon 'dialog-question' not present in theme Adwaita (0)’
<nckx>(after fixing the cursor issue.)
<nckx>Gnome: making software look hard.
<raghavgururajan>nckx: Intresting, in --pure env icons showed correctly for me. Hmm.
<nckx>That said, once past that, it imports my 215GiB video with impressive speed and not-crashing. \o/
<nckx>I'll pull and update my profile.
*jonsger tries to rebase wip-gnome3.36 to master as wip-desktop is just crazy with 300+ commits...
<DisLodge>nckx: I think I am in love with you.
***ChanServ sets mode: +q *!*@**
<jonsger>mothacehe: the good news is that my cuirass server gets regular evaluations through, like 20%...
<mothacehe>jonsger: still sad :(
***ChanServ sets mode: +o nckx
<nckx>DisLodge: It happens.
<raghavgururajan>jonsger: Hey! Are you available to discuss about wip-desktop? :-)
<jonsger>mothacehe: you added support for core dumps, but I guess this is only for remote workers and not the evaluations...
<jonsger>raghavgururajan: not really. tbh honest I do not really want to dig into it. its so monstrous...
<mothacehe>jonsger: it's just to ease the debug of a memory bug in the remote-server indeed
<mothacehe>the evaluations ofter do not crash, they just hang forever
<mothacehe>because of an error in the inferior
<mothacehe>but I'm rewriting all of that, hopefully it will help
<jonsger>oke, nice. I will be patient. I appreciate all your work there :)
<raghavgururajan>jonsger: Okay. :(
<mothacehe>jonsger: thanks :)
<civodul>i got a scary-looking build error for guix-cli.drv:
<mothacehe>yeah I saw it multiple times on
<mothacehe>transient error
<mothacehe>but scary
<civodul>resurrects bad memories
<mothacehe>civodul: here's one:
<civodul>ouch; reported at
<raghavgururajan>jonsger: Danny and I worked hard for months on wip-desktop. Things got stagnated due to breakage of core-updates. Danny offered to re-build stuff on his new powerful system. It would be great if we three could work together on gnome. Please let me know what you think.
<civodul>mothacehe: do you know if it's a recent problem?
<mothacehe>the log I sent is from mid february
<mothacehe>I think there are some older ones
<mothacehe>but I started noticing them working on the CI remote mechanism end of december
*nckx was waaaay too optimistic about video editors.
<dftxbs3e>grub vulns again
<dftxbs3e> - can't take care of it busy now
<dftxbs3e>hello christopher! :-D
<dustyweb>hm, how come mu.scm doesn't seem to end up in the guile path?
<dustyweb>hi dftxbs3e !
<dustyweb>I've installed mu but (use-modules (mu)) doesn't work
<dustyweb>but I can figure out where it is
<pkill9>why nckx
<dustyweb>oh wait
<dustyweb>I have a guess, heh
<dustyweb>guile 3.0 vs 2.2
<dustyweb>yup that's why
<dftxbs3e>nckx, are we subscribed to oss-sec distro-list from openwall?
<dftxbs3e>civodul, nckx:[]=distro - we should get access to this for early security patches
<civodul>dftxbs3e: for distro-list, we need people to commit to helping out
<civodul>we haven't applied so far because we're too few and too overworked
<civodul>IOW, anyone willing to join is more than welcome! :-)
<dftxbs3e>civodul, yes that's true, I am willing and capable to do security work, first step would be tagging individual packages with cpe vendor metadata, can we do it or anything against? similar to metadata for cuirass on build timeouts
<civodul>dftxbs3e: adding CPE metadata would be great!
<dftxbs3e>second would be adding something similar to debian watch file inside GNU Guix:
<civodul>see also:
<civodul>uscan = "guix refresh", no?
<dftxbs3e>civodul, not exactly because guix refresh doesnt have rules for individual packages
<dftxbs3e>debian has rules for each and every package so notifications for updates are reliable
<civodul>well yes, but the goal is the same
<dftxbs3e>civodul, sure, but I don't think we can avoid having to specially add metadata for each package
<civodul>sure, we can do that if needed
<dftxbs3e>things like this:
<civodul>my point is that we already have the infrastructure
<dftxbs3e>I wish I knew Scheme better though but will try hard to do this
<dftxbs3e>Yes we do!
<dftxbs3e>In fact we could even mirror the urscan format so we can just import Debian's rules in most cases
<dftxbs3e>uscan *
<civodul>that i'm not sure :-)
<dftxbs3e>civodul, what are you not sure about ?
<dftxbs3e>and why?
<civodul>anyway, the importer/updater code is orthogonal and rather hackable
<civodul>so we can address things one by one
<jonsger>raghavgururajan: I offer my help if you post like smaller chunks for a review or so. but reviewing and testing of 300+ heavy commits is not really feasable for me
<jonsger>I can work nowadays only in my free time on Guix...
<civodul>maybe someday we'll have
<jonsger>civodul: you talk about jobs as in where you get your money from?
<raghavgururajan>jonsger: I understand. Anyway, I am already in the process of breaking those commits into smaller ones. Once it is ready, I will be sending it to guix-patches, for merge into master or core-updates. Can I CC you on those emails, along with Danny?
<civodul>jonsger: heh yeah, that kind of job :-)
<jonsger>raghavgururajan: you can
<raghavgururajan>jonsger: Thanks!
<jonsger>civodul: I would rather try to get Guix used in my day job, but thats a pretty hard way...
<raghavgururajan>> civodul‎: maybe someday we'll have
<civodul>jonsger: it works sometimes :-)
<lf94>Looks like a lot of use are trying to integrate guix into our day jobs
<jonsger>civodul: it should work, otherwise it gets dark in south-west Germany...
<nckx>dftxbs3e: I think that, whenever it came up in the past, the mandatory (personal) commitment was a problem.
<pkill9>civodul: how do I use build-package from guix/scripts.scm?
<nckx>pkill9: None can handle my 215 GiB uncompressed mkv of doom.
<nckx>That's a general statement but I was talking specifically about video editors here.
<pkill9>except ffmpeg ofcourse
<nckx>Of course.
<nckx>But that's putting the bar dangerously low; someone might trip.
<nckx>That said, it's exactly what I used, with all the fun that entails.
<nckx>Video being something of a visual medium.
<nckx>civodul: Is powerful?
<nckx>Compared to berlin.
<lfam>nckx: Which editors have you tried?
<lfam>Do they fail by running out of RAM?
<civodul>nckx: a 100th of berlin? :-)
<civodul>we should get a better one soonish, though
<lfam>dftxbs3e: Regarding the distros list, it does require a significant personal commitment, if they even choose to accept us
<lfam>They do a lot of work in private that is delegated to the subscribers
<Whyvn>there is a package mu which supposidly is supposed to install mu4e as well. I need to add mu4e to my emacs load path to be able to use that package, but how would I find it on guix system?
<sneek>Whyvn, you have 2 messages!
<sneek>Whyvn, leoprikler says: you're confusing packages and licenses with the same name. The solution is to ([use-modules ...]((guix licenses) )
<sneek>Whyvn, leoprikler says: you're confusing packages and licenses with the same name. The solution is to ([use-modules ...]((guix licenses) #:prefix license:). Sorry about the typo above.
<lfam>And, they only take new subscribers that are vouched for by othe rsubscribers
<dftxbs3e>lfam, alright I understand that, all in all we must keep up with public vulns before trying to reach towards undisclosed vulns
<dftxbs3e>by the way can someone take care of ? GRUB vulns again
<dftxbs3e>I am busy now can't do it
<Whyvn>it is usually stored in /usr/local/share/emacs/site-lisp/mu4e but not on guix
<lfam>dftxbs3e: I agree. If we keep up with public disclosures then we are already doing really good. Better than "established" distros like Debian, tbh
<lfam>There are only a few bugs that go through the private distros list
<lfam>But, somehow they still seem to generate a ton of work behind the scenes, based on periodic public reports of the workload management
<lfam>If you did want to join the list, I would support your application. I have a little experience posting to oss-sec and it might count for something. But, I don't think it's critical for Guix
<lfam>If you want to read more about the application process and workload, search the oss-sec archives for discussion, especially from the person named Solar Designer
<dftxbs3e>lfam, the email you sent about april release has an invalid signature
<lfam>It checks out for me from here...
<lfam>That's weird!
<nckx>dftxbs3e: Not here.
<dftxbs3e>lfam, sent email with error
<lfam>It may be that you are using the wrong key. I'm not sure, but I think that BACA7F08 key is only used for code signing
<lfam>It's a subkey of the same key I used to sign the email
<dftxbs3e>lfam, I imported the keyring from GNU Savannah
<lfam>I don't really know which key was used to sign the email
<nckx>dftxbs3e: What do you mean by ‘invalid signature’? That means something specific.
<lfam>Hm. Maybe the keyring only includes the code-signing key
<lfam>I have to go afk for a bit
<nckx>Not just ‘I don't have that key’.
<nckx>Whyvn: On Guix, it's in $profile/share/emacs/site-lisp (where $profile is e.g. ~/.guix-profile). That's a general pattern.
<dftxbs3e>nckx, also sent you email .. if you are interested
<nckx>That said I just (require 'mu4e) because Guix's emacs does the right thing.
<nckx>< which supposidly is supposed to install mu4e as well> mu4e is part of mu btw.
<nckx>They aren't separate upstream.
<nckx>dftxbs3e: Thanks.
<Whyvn>nckx: thank you for clarification, I noticed it just needed require mu4e too which is nice, but trying to learn where things are stored on guix with respect to other gnu/linux systems
*nckx is currently reindexing their mu DB because mu doesn't grok what .cache means, but will be able to read it shortly.
<zimoun>nckx: about “guix weather” failure, could you try to decrease the argument ’batch-size’ in (guix http-client)? from 1000 to 100 for instance.
<nckx>Whyvn: What you find under the profile directory generally mirrors what you'd find under /usr{,/local} elsewhere. Since it's just a union of store directories, and we set --prefix=/gnu/store/xxxx where other distros set --prefix=/usr.
<nckx>There are some differences (like there being no /mu4e subdirectory on Guix, which there apparently is on your distro) but no more than between any two others I'd think.
<nckx>zimoun: Sure.
<Whyvn>nice, good to know. Havent explored .guix-profile like should have and its all making more sense.
<nckx>- processing mail; processed: 64425; updated/new: 64425, cleaned-up: 0 :-/
<nckx>‘Note: signatures using the SHA1 algorithm are rejected’ -- could that be it?
<zimoun>nckx: I think descreasing the batch-size will force to check the usuability of the open port and reopen if unsuable. Which is not done in the ’loop’. Then it should lead to the ’retry you are asking. :-) Maybe 1000 is too high and 100 is better. I do not know.
<zimoun>Or I could be wrong. :-)
<lfam>dftxbs3e: Can you point out a signed message from me that has a good signature?
<lfam>Or, even from somebody else?
<nckx>dftxbs3e: I think that's it.
<lfam>I can't even figure out how to check the signatures outside of mutt
<nckx>With ‘weak-digest SHA1’: gpg: ‘WARNING: signing subkey 0x2646FA30BACA7F08 has an invalid cross-certification’, without it: ‘gpg: Good signature from "Leo Famulari <>" [unknown]’.
<nckx>Seems to settle it.
<nckx>lfam: Depends on your client, but you'd save the signature(.asc) and text part separately and run ‘gpg --verify signature.asc textpart.text’.
<lfam>I see
<lfam>So what do I need to do
<nckx>I saved the entire e-mail, then removed the other parts in a text editor, keeping only the text between ‘--L2tjDxShQAZMto8k’ (in your case) and snipping the trailing newline.
<nckx>Totally normal thing to do in 2021.
<lfam>I tried that 😭
<lfam>I wish that Git had another way to sign code
<lfam>In 10 years we are going to realize that it never worked, I'm sure
<lfam>Anyways, I need to change something here, right?
<nckx>Well, that's not true. I'm pretty sure it works, like carefully cutting your bread with a chainsaw works. I'm not worried about the bread.
<nckx>The bread is fine.
*nckx 's turn to AFK away.
<civodul>lfam: signing commits doesn't work?... what d'ya mean?
<civodul>nckx makes a very relevant analogy IMO :-)
<lfam>I just mean that I'm not confident that it's as solid as we think
<civodul>OpenPGP is the wrong tool for the job, but "it works"
<civodul>what's solid? OpenPGP? signing Git commits?
<lfam>If PGP could cut off my leg, then I'd like the analogy :)
<civodul>i mean, OpenPGP is a kitchen sinks and it's barely usable by human beings
<civodul>but the subset we use here is okay
<lfam>OpenPGP and the way it is used in Git. I wonder if anybody is really examining how it works and if it provides a strong guarantee of authenticity
<civodul>yes, there's nothing really particular about it
<civodul>it's signing Git commit "signatures" (yes, that's what it's called :-/), which contain SHA1 pointers to the tree and previous commits
<lfam>And, I find myself wishing that Git used something simpler to understand, like signify
<civodul>i agree
<lfam>The use of OpenPGP discourages people from looking closely at things, I think
<dongcarl>Hi all, does anyone know why there's a difference between ~$USER/.config/guix/current and ~$USER/.guix-profile?
<lfam>Yes dongcarl
<dftxbs3e>lfam, as long as it has "git verify-commit" - what's wrong?
<civodul>lfam: it did keep me busy for a while, tho :-)
<lfam>dongcarl: The former is the profile used by `guix pull`, and the latter is the default profile for installing packages
<lfam>You can select either of them for inspection, for example `guix package --profile ~/.config/guix/current --list-generations`
<dongcarl>lfam: I guess my question is: why do they have to be separate?
<lfam>They are different things
<lfam>`guix pull` manages the software called "Guix", while the other profile is packages you install to use
<lfam>Why wouldn't they be separate, is my question? :)
<lfam>dftxbs3e: I don't really understand your question
<dongcarl>Okay but what happens when you do `guix install guix`?
<lfam>It installs Guix using the package installation mechanism, but you aren't supposed to do that
<zimoun>dongcarl: “guix install guix” installs in ~/.guix-profile
<zimoun>then it depends is ~/.guix-profile is first in your PATH
<dongcarl>Okay... I've helped many people set up Guix on their foreign distros and everyone seemed to be confused about this point :-)
<lfam>I see... we should make it so that don't have notice this point
<lfam>It should be invisible
<civodul>dongcarl: i've had the same experience actually
<lfam>I've also had moments of confusion around this situation
<dongcarl>I think the profile.d entry in the install script helps...
<civodul>it just wouldn't work if the two were in the same profile
<dongcarl>But that's not in the manual
<civodul>oh right
<dongcarl>I will collate the hiccups I ran into and post on ML, but here's another one: if you build Guix from source, and `make install`, /var/guix/profiles/per-user/root won't exist yet, but the systemd scripts refer to /var/guix/profiles/per-user/current-guix/bin/guix-daemon.
<dongcarl>In order to make /var/guix/profiles/per-user/root exist, you need a `guix pull`... which requires guix-daemon... which...
<lfam>People should use the installer script. If they are installing manually, and they are new to Guix, I don't consider some confusion to represent a bug
<zimoun>what is subtile about the 2 profile is the <profile>/manifest which is different. One contains ’source’ and the other ’provenance’.
<lfam>The bug is that the installer script doesn't meet their needs
<dongcarl>Not a bug! Just some UX improvements :-)
<lfam>A UX bug :)
<lfam>There's nowhere we recommend `make install`
<lfam>Or at least, last time I checked :)
<lfam>It's hard to tell the difference between UX problems and bugs, from my point of view. They are both problems that require work
<lfam>Also, Guix relies on some finer points of UNIX that are glossed over by other distros. So, installing manually with an expectation of "full understanding" does require a high level of expertise
<lfam>I'm talking about the differences between login, non-login, and interactive shells. And also the fine points of how sudo and su operate
<lfam>Other distros spent a couple decades beating their software into submission so those things don't matter
<dongcarl>Sure! I'm happy to keep documentation elsewhere, just thought it could be useful to flesh out the manual :-)
<lfam>Oh, we should definitely improve it
<dongcarl>The Arch Linux AUR package works around this like so:
<lfam>It's rather advanced to be building from source IMO
<lfam>So, what do they change? It's hard to read the shell script
<lfam>They make it look in /usr/bin?
<dongcarl>Yeah they create guix-daemon.service, and guix-daemon-latest.service, the former one looks in /usr/bin
<lfam>And what goes in /usr/bin? A symlink?
<dongcarl>I think `make install` installs a guix binary in /usr/bin
<lfam>The warranty is void :)
<lfam>That means it never gets updated from `guix pull`?
<dongcarl>lfam: Right, which is why guix-daemon-latest.service exists
<lfam>It's reminiscent of how Guix instruments other package managers like pip
<lfam>It's fine for its purpose, but it's not the same thing as "pip"
<dongcarl>BTW, was guile-avahi removed as a dependency recently?
<lfam>I think it was added as a dependency recently
<dongcarl>Oh, it's optional
<rekado>I can’t tell if this is a joke:
<lfam>It's no joke! $$$$$$$$$$$$$$$$
<OriansJ`>rekado: oracle never jokes around when it can result in them making more money
<lfam>Once you are an Oracle "customer" they never let you leave
<rekado>I actually meant this:
<rekado>it’s even better
<lfam>curl -O | sudo bash
<jonsger>I always wonder how much they pay to RedHat...
<nckx>rekado: what the utter fuck
<nckx>This is gold.
<nckx>Thank you ♥
<lfam>Every little UI bug in GNU / Linux is another million dollars in revenue for Oracle
<nckx>lfam: Experienced?
<dftxbs3e>> run the following as root
<lfam>No, I haven't had the pleasure of having a million dollars to spend on software
<lfam>Apple is there for the rest of us
<nckx>dftxbs3e: DO‌ IT.
<nckx>Start and in two terminals simultaneously and see who wins.
***V is now known as v
***v is now known as V
<lfam>Does anyone know if a umask of 0022 is different from 022?
<nckx>It's not.
<nckx>lfam: I'm not sure what to do about your signature, or even if you need to do something.
<lfam>I'm going to ignore it
<lfam>I think I would need to change configuration in gpg.conf but I prefer to use defaults whenever possible
<Whyvn>is there a reason there are differences in the guix C++ header files definitions and other gnu/linux C++ header files? I am trying to install the irony server for emacs and I get this when it tried to compile. A bunch of naming conflicts. Am I missing a step? Doesnt seem correct.
***Noisytoot is now known as N
***N is now known as Noisytoot
<nckx>lfam: I'd say if action were needed it would be on your key, not your configuration (except, of course, perhaps, whilst actually changing your key).
<civodul>woow, those Oracle folks are exceptional!
<civodul>pushing the limits
<nckx>Whyvn: You assume there are differences; why?
<lfam>nckx: I think one can set a digest-algo option in gpg.conf
<civodul>lfam: so there's a problem with a signature of yours on a commit? i missed the beginning
<nckx>No no.
<lfam>No, no problem with commit signatures
<civodul>pfew :)
<nckx>A mail of lfam's fails to validate on one machine.
<lfam>Somebody disabled SHA1 signatures in their mail client's GPG tooling
<civodul>ah ok
<civodul>(which is reasonable)
<lfam>Idk, I rely on GnuPG upstream to set the defaults
<nckx>However, so ☝ do I and yet mu4e validates the mail just fine. Maybe that's a mu4e bug.
<nckx>lfam: You *like* chainsaws don't you.
<lfam>Using the defaults is easy and means I don't have to remember things
<nckx>When I validate it manually, it fails here too.
<nckx>Whyvn: Looks like you're using an unsupported standard (C++17 by any chance) to me.
<nckx>Try playing around with the -std argument.
<nckx>Or better yet, adding a newer gcc to native-inputs.
<Whyvn>nckx: I just install gcc-toolchain
<nckx>Same applies; you're likely using the wrong standard for the wrong version of GCC, or something like that.
<nckx>If you're using the latest GCC toolchain, try downgrading to an older one.
<nckx>There's nothing wrong with the headers, but you need to find the ones that your source code was written against.
<rekado>civodul, bandali: is there anything we can do to run git hooks on Savannah?
<Whyvn>ok ill try that thanks for answering.
<rekado>it’s not very comfortable under the dangling sword of damocles
<lfam>rekado: We already do, IIUC
<nckx>Whyvn: It's often guesswork... :-/
<nckx>lfam: Didn't you recently push just that?
<lfam>Push what?
<nckx>A hook.
<bandali>rekado, civodul, sure. i don't know if we have a streamlined workflow for it, but you can email one of the savannah lists about it and we'd be happy to set it up
<nckx>A server-side hook.
<lfam>I added an old hook to the maintenance repo, so we don't forget about it. It should have been in use on Savannah for several years now...
<lfam>We could even remove it now, because it doesn't improve the security over the `guix pull` code signing stuff
<lfam>All that it did was check if the commit message contained the string "gpgsig", basically
<lfam>What hook did you have in mind, rekado?
<rekado>I’m confused. Since when do we run hooks on Savannah to prevent pushing of unsigned commits?
<civodul>lfam: that hook is still useful to avoid mistakes
<nckx>Whyvn: Just a guess, but try gcc-toolchain@5.
<civodul>rekado: since 2016 or so
<lfam>Yes, that's a good point civodul
<rekado>ah, that’s great
<nckx>I agree we should keep it.
<lfam>It would be nice if we had a little more visibility into things. I found myself wondering if it was still there
<rekado>all this time I thought we’re living on the edge, just a broken committer’s git configuration away from disaster
<lfam>Well, `guix pull` would not accept the mis-signed commits rekado. And then we could just rewrite history freely
<civodul>we *are* living on the edge
<lfam>I think it would be okay
<civodul>strangely, since authenticated commits are in place, we never had to hard-reset
<civodul>which is almost disappointing
<lfam>Do you want me to break it? ;)
*nckx will ‘forget’ to update .guix-authorizations next time.
<rekado>we can break things by signing with a key that’s not in .guix-authorizations, right?
<civodul>it's like when you design a flight recorder and the plane never crashes
<nckx>rekado: For example. The hook just checks for *a* signature IIRC, not an authorised one.
<civodul>rekado: yes, for instance
<rekado>got it
<Whyvn>nckx: gcc-toolchain@9 seemed to work. appreciate the tip
<Whyvn>with those conflicts
<nckx>Whyvn: Oh, that's much better than I expected! Great.
<lfam>It should be very hard to break history for users, however, since `guix pull` should reject the mis-signed history
*rekado adds a pillow on the edge
<nckx>Whyvn: ‘With’ as in it still causes errors?
<lfam>Developers would have to "force pull" but that's okay
<Whyvn>nckx: error adding symbols: DSO missing from command line
<nckx>Now that doesn't ring a bell.
<rekado>lfam: yeah, recovery doesn’t seem excessively dramatic in this case. Ugly for us, but not terrible for “guix pull” users.
<bandali>just checked on the server, i do indeed see a few git hooks already installed for the guix.git repo :-)
<lfam>We could improve the server-side Git hook. The idea was always that we shouldn't *need* to trust the server, but it would still be great to avoid mistakes
<rekado>bandali: thanks for checking :)
<bandali>cheers :-)
<nckx>bandali: Is there a way we could have at-will read access to those?
<nckx>Assuming write access is out of the question; maybe it's not.
<bandali>nckx, as is, i doubt (needs ssh access to the sv vcs server); but ultimately i think it'd be a nice-to-have feature
<nckx>But, e.g., I'm surprised to hear ‘a few’ and that's probably not good. We might get out of sync with reality.
<nckx>OK, thanks. (I agree.)
<bandali>feel free to bring this up in #savannah if you like :-)
<vagrantc>lfam: gpg's defaults sometimes get embedded into the key itself, so even if gpg'
<vagrantc>s defaults improve, you might be stuck with old discouraged stuff
<vagrantc>and gpg has taken stupidly long to deprecate some defaults...
<bandali>nckx, oh; yeah so there's the `update' one which lfam linked, and another post-receive for sending out commit emails i believe
<lfam>I tried checking my key's "preferences" and the interface is completely mystifying
<vagrantc>lfam: if you said anything else, i would assume you had run the wrong commands :)
<lfam>Like, I checked the key's "pref" in the gpg shell, and it's just some list of weird symbols
<vagrantc>there was a openpgp key checker of some kind that checked for common "bad" things and gave recommendations how to fix them...
<nckx>bandali: Ah OK, to nckx-brain ‘a few’ implied more for some reason.
<lfam>I have to insist that it be fixed upstream
<vagrantc>lfam: it might require a rewrite of the openpgp standards to really fix it... is part of the problem
<lfam>I know this, but I don't believe there is a significant openpgp ecosystem to speak of, outside of what distros use it for
<lfam>If this security software requires arcane workarounds to be used safely...
<bandali>nckx, hehe :-) i mean technically there's a "git update-server-info" post-update as well, but yeah. sorry i was vague
<lfam>And there is always the "classic" gpg release series for the old-school users
<nckx>bandali: ...I'm not the only one who uses that gross hack to serve git without git? Sweet.
<lfam>There's no reason for the current gpg releases to have bad defaults, if they are in fact bad
<nckx>bandali: I didn't mean that you were vague, just that I misinterpreted.
<vagrantc>lfam: but even if they're fixed, that doesn't necessarily mean old keys will be fixed
<bandali>nckx, ahaha :-) and cool gotcha
<lfam>So, those keys can stop working
<lfam>There is always the "classic" gpg release series for the old-school users
<pkill9>what hack is that nckx?
<nckx>git update-server-info
<nckx>→ Web server.
<nckx>→ git clients.
<nckx>(The cool and I think upstream-promoted way to do that is to run and proxy a git daemon instead.)
<nckx>git update-server-info is the ‘static Web site’ equivalent to that, and needs to be run on every push.
<nckx>I think it's called the ‘dumb git protocol’.
<lfam>The other thing about SHA1 and gpg is that they only way it can do "authenticated encryption" is with SHA1
<lfam>It's a mess
<lfam>That's the "MDC"
<vagrantc>it's a mess
***jonsger1 is now known as jonsger
<lfam>I'm trying to figure out what those symbols mean but I can't find the reference
<lfam>S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z2 Z3 Z0
<lfam>That kind of thing
<nckx>lfam: How do you get those?
<nckx>I thought you meant showpref but that's not that arcane.
<lfam>I copied that one from a mailing list thread, but you can do `gpg --edit-key $key` and then type pref
<lfam>Those strings don't appear in the GnuPG manual, AFAICT
<vagrantc>showpref is more verbose
<lfam>I see
<nckx>lfam: You're using the low-level command where you should use ‘showpref’.
<lfam>This is how you know it's pgp
<nckx><copied that one from a mailing list thread> is not really GPG's fault.
<lfam>I found it myself, thank you
<nckx> was a quote?
<lfam>I found the mailing list thread while trying to find a reference for what those symbols mean
<lfam>I guess they are not documented at all
<lfam>These are my digests:
<lfam>Digest: SHA256, SHA1, SHA384, SHA512, SHA224
<lfam>I figure it should use SHA256 since that is first in the list
<nckx><I guess they are not documented at all> = ?
<vagrantc>yeah, should...
<lfam>Those symbols don't appear in the gnupg documentation nckx
<lfam>It's too bad my key expires this summer. I've just used up my annual "pgp attention" budget
<nckx>Oh well, 't was nice to have you on board.
<nckx>Who needs CVE fixes anyway.
<lfam>The good thing is that key expiry doesn't affect code-signing
<lfam>(Or anything really)
<lfam>I was actually going to remove the expiration entirely next time around
<lfam>Besides, there's another Leo who is paying attention to security now
<nckx>That's not how Leos work
<nckx>I think.
<dftxbs3e>lfam, heh do you know Scheme by the way?
<dftxbs3e>I mean, know it well
<lfam>I have a very basic knowledge of it
<dftxbs3e>I would really make use of a refresh option that can take a patch as input (one that fixes a CVE for example) and a package name and automatically adds patch to gnu/, to the patches folder and to the package itself then automatically creates a commit from the template
<dftxbs3e>This way I can patch things massively without trouble
<dftxbs3e>The most annoying thing with security patches are these steps
<dftxbs3e>error-prone troublesome ..
<lfam>I've also avoided that level of automation. In my experience, those steps are relatively quick compared to researching the bug, the fix, testing if it works, etc
<dftxbs3e>Seeking for the fix etc. is not error-prone or troublesome
<lfam>If there is a new upstream release to fix bugs, that can be a little more automated. But patching is more risky and difficult to validate
<dftxbs3e>I am trying to eliminate steps where I double check everything because things can go wrong
<dftxbs3e>Things that no tooling checks for me
<lfam>I think that if you see an opportunity for improvement, you should take it
<dftxbs3e>I don't know Scheme :-(
<dftxbs3e>Otherwise I would've improved this already
<lfam>Patches in particular are risky in tricky ways
<lfam>They can be applied but apply to the wrong code
<lfam>For example
<dftxbs3e>I apply my own judgement when doing this as well, just it will help
<lfam>Yeah, like I said, don't hold back from trying to improve it
<dftxbs3e>I can't I don't know Scheme..
<lfam>I know :) But you can learn
<dftxbs3e>> 6 months later
<lfam>Yeah, that's just life, I guess
<dftxbs3e>I already learn
<dftxbs3e>I thought we were here to try collaborate
<lfam>Yes, we are, but I also can't implement the thing you want to do
<dftxbs3e>Not you specially but if anyone can, would appreciate it
<lfam>Yeah, I bet someone will be interested
<ngks>Hey, sorry for breaking in. I had a reconfigure fail with an error that seems to originate in the ice-9 library. Or maybe not, this error was very unexpected.
<ngks>I hadn't changed anything in my config.scm related to bootloader config
<vagrantc>fwiw, apparently not packaged in guix ... i was thinking of "hokey lint" from haskell-hopenpgp-tools
<zimoun>dftxbs3e: well, I am not sure automatic addition by “guix refresh” to gnu/ is good idea. However, check the consitency at “guix lint” step seems doable, I guess.
<lfam>ngks: Can you share your config.scm?
<lfam>And also the results of `guix describe`
<ngks>lfam: both incoming
<dftxbs3e>zimoun, is it possible you think to have a yasnippet take information from staged files in commits?
<dftxbs3e>staged files in git*
<zimoun>give a look at etc/committer.scm for instance
<ngks>hold on, I might have found a stupid typo
<dftxbs3e>zimoun, aa what does it do? looks very interesting!
<zimoun>for example, updating large package set as bioconductor.scm is ~300+ packages, so it is partially automatic
<zimoun>basically, etc/committer.scm takes chunk, find which package is update in it, and them write the commit message.