IRC channel logs


back to list of logs

***jpoiret9 is now known as jpoiret
<vagrantc>oh fun.
<vagrantc>guix pull: error: could not authenticate commit 9edb3f66fd807b096b48283debdcddccfea34bad: key BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA is missing
<vagrantc>oh, nevermind, my keyring branch was not pointing to the correct place :)
<vagrantc>had accidentally checked out master as keyring, rather than origin/keyring as the keyring branch
<raingloom>am i a fool for forgetting again that package references in gexps don't actually set up any of the pretty damn crucal environment variables that the package needs...
<raingloom>guess i need to use with-extensions...
<raingloom>hmm, nope, no luck
<vagrantc>hrm. no gpu acceleration with linux-libre on pinebook pro ... wonder if that's borked on linux-libre-arm64-generic too
***sneek_ is now known as sneek
***apteryx_ is now known as apteryx
<civodul>Hello Guix!
<sneek>civodul, you have 1 message!
<sneek>civodul, flatwhatson says: I've tested with libgc-7 and confirmed it doesn't have the mmap(PROT_NONE) bug. The difference is that libgc-7 defaults to `--disable-munmap` where libgc-8 defaults to `--enable-munmap=6`. Building with a libgc-8 with `--disable-munmap` doesn't suffer from the bug.
<abralek>Hi Guix
<hoijui>If I start using the pakcage manager on Debian, and say... after a year of usage, when I feel more or less at home, I'd switch to the Guix OS (GuixSD?), could I transition relatively seamlessly? Or say, could I continue using the same configuration, adding some minor things?
<hoijui>start using the *Guix package manage on Debian
<andreas-e>That is a good plan. I started with the package manager, and when all software I used was available in Guix, I switched completely.
<iyzsong-w>hoijui: i think you can also use 'guix system vm' on debian to get Guix System, so yes!
<hoijui>ohhh thanks you two (andreas-e and iyzsong-w), that is even better! So I could start with the Guix package manager on Debian, then switch to a GuixSD VM, getting it all working there, and then install GuixSD with that evolved config on my system.
<iyzsong-w>yeah, now it's called 'Guix System' not 'GuixSD'
<ekaitz>hi all anyone can help packaging a go program? looks like it has many deps and it gets complicated... this is the thread:
<hoijui>ahh nice, that is much better
<ekaitz>I'd do it myself but I don't know how to solve this... :(
<hoijui>i just realized.. when installing on top of debian, I of course would have most my setup.. the debian way, so when switching to the VM, my config would still be minimal.
<hoijui>Is there a way to slowly replace most things in my debian system with Guix packages?
<hoijui>say.. i uninstall inkscape through apt, and install it through Guix? .. and then the next thing, and the next ...
<hoijui>until I get to core system things, at which point I'd move to a Guix system VM
<andreas-e>hoijui: Yes, exactly. Some things tied to the desktop environment may be smoother to use in a Guix system, however.
<avalenn>ekaitz: you hit our current wall with golang packaging. we probably need improvments to go build system for this to work
<ekaitz>avalenn: yeah... I asked just in case anyone was more informed about it than me...
<hoijui>andreas-e, htanks! :-)
<avalenn>I hope to find time to work on this but time is a scarce resource.
<ekaitz>avalenn: yeah...
<rhou[m]>is there a way to spawn another emacs `eshell` when calling `guix environment` in a `eshell`?
***pocketroid_ is now known as pocketroid
<leoprikler>I'm not sure, but I think `guix environment` should call the current $SHELL.
<leoprikler>that said, idk how eshell handles recursive shells
<civodul>apteryx: hello! "make assert-binaries-available" passes now on version-1.3.0!
<apteryx>civodul: great!
<apteryx>Have you had a chance to glance at the spice-vdagent changes I proposed for version-1.3.0? If they look OK, I'd like to push them before generating RC2
<civodul>apteryx: ah no, i thought they were in already :-)
*civodul M-x debbugs-gnu
<civodul>apteryx: i haven't tested yet but LGTM!
<civodul>BTW, the manual has an example of how to use SPICE with QEMU
<civodul>but as always with QEMU, it's a 200-character-long set of flags that you have to pass
<apteryx>civodul: indeed! And it won't even allow you to *use* SPICE, as the QEMU default viewer is not SPICE-capable. What it does it start a spice server (I think?) that you can connect to using something else, like virt-viewer
<apteryx>so if you want to test it, I suggest using virt-manager or GNOME Boxes directly
<civodul>yeah i'll try GNOME Boxes
<civodul>instead of pretending i have a clue ;-)
<civodul>BTW, we've been using a guile-avahi tag for a while
<civodul>er, commit
<civodul>i figure it'd be cleaner to tag it and make it a new version
<civodul>(it shouldn't block anything though)
<jorge[m]>guix pull: error: Error git: failed to resolve address for Fallo temporal en la resolución del nombre
<jorge[m]><jorge[m] "guix pull: error: Error git: fai"> ya listo
***rekado_ is now known as rekado
<avalenn>This one is strange:
<avalenn>guix: environment: command not found
<avalenn>hint: Did you mean `environment'?
<civodul>fun :-)
<civodul>did you *really* mean "environment"?
<civodul>this is from your build tree?
<avalenn>Probably related to crazy GUILE_LOAD_PATH.
<avalenn>Yes. Using pre-inst-env but lacking guile in the environment or something like that. I use direnv to have the necessary dependencies and was executing outside my usual workspace
<avalenn>what does "propagated-inputs" do exactly ? It seems different than Nix propagatedBuildInputs.
<avalenn>The manual does not really help me on this one. I am not sure to understand what "dependencies that automatically get installed along with the required package" means.
<vivien_>Hello, I’m trying to use gnutls in guile for my program. I have gnutls as the propagated inputs, and I have called wrap-program to set up GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH. However, the let’s encrypt certificate of the server is not recognized: I get a tls-certificate-error invalid-certificate. Maybe I should add an input to my package and add some other wrap-program variables, but which ones?
<rekado>avalenn: propagated inputs are installed into the profile alongside the package that propagates them.
<avalenn>and at build time ? guix build creates a profile ?
<avalenn>no, it just add them to the environment.
<avalenn>thank you rekado I see it better now. I just was confused by my analogies with Nix.
<vivien_>OK maybe that’s because my system is broken: I can’t use (web client) directly because of that problem.
<roptat>vivien_, you're probably missing certificates in your environment? (nss-certs and all that)
<vivien_>roptat, I made the mistake of having guile and some packages installed globally
<vivien_>I think it messed up the system quite a bit
<vivien_>I’m cleaning up
<rekado>(also useful: “guix environment --pure”)
<vivien_>rekado, does guix environment --pure also clean up the environment variables set up by nss-certs?
<vivien_>If so, should I add nss-certs as a propagated input, or should I expect anyone using my package in a pure environment to also include nss-certs?
<rekado>generally, nss-certs should not be an input. There may be exceptions.
<vivien_>OK, I’ve repaired my system
<vivien_>Is it possible to pull just one channel with guix pull?
<apteryx>civodul: would you be OK with adding 'wget' to our %base-package-networking list? I think it's convenient to have it out of the box. WDYT?
<apteryx>it adds 2.9 MiB (share/locale) to the system closures (uncompressed)
<apteryx>bare-bones.tmpl before wget: 1162.4 MiB / after: 1165.5 MiB
<apteryx>alternatively we could add it just to the install image
<apteryx>adding git-minimal +wget to our install image would inflat the its size by 48 MiB, from 1491.8 to 1539.8 MiB.
<apteryx>inflate its*
<apteryx>which is about a 3% size increase.
*nckx yawns.
*nckx waves what-ho.
<raghavgururajan>Hello Guix!
<apteryx>OK, so I think this makes sense:
<apteryx>civodul: ^ the above proposes adding wget to our global base packages and git-minimal to our install image. WDYT?
<apteryx>and after that I think I'm satisfied with what we've got for version-1.3.0
<civodul>apteryx: adding wget to %base-packages can be welcome; but why git-minimal on the install image?
<civodul>bare-bones.tmpl is at 1.1G?! ugh, we'll have some work to do :-)
<raghavgururajan>leoprikler and nckx: Will this be okay? [1] Temporarily have the gtkmm patch as-is in c-u [2] package gtk (4) [3] rename gtkmm to gtkmm-3 [4] package gtkmm (4). So at the end of [4], glibmm, cairomm, pangomm, atkmm and gtkmm can exist in same profile without conflicts. WDYT?
<rhou[m]><leoprikler "I'm not sure, but I think `guix "> thanks, will investigate
<leoprikler>imo we ought to rename gtkmm to gtkmm-3 earlier, so as to make no false promises
<leoprikler>but this still won't be reflected on the command line interface
<leoprikler>can we hide the newer atkmm etc. until gtkmm4 is packaged?
*raghavgururajan head spins
<leoprikler>To clarify, the thing we're trying to fix here is the command line behaviour of `guix install`
<leoprikler>as long as you give *any* reasonable configuration, we probably won't care what the variable names look like
<leoprikler>(though for manifests, you should keep those in line also)
<raghavgururajan>What if I start the gtk and gtkmm packaging (v4) right now? I could get it done before next c-u --> master merge.
<leoprikler>I think gtk definitely has priority over gtkmm
<raghavgururajan>But I would need an tentative time of when the merge happens.
<leoprikler>so even if this patch gets held up for a while, packaging gtk4 is probably a good idea
<leoprikler>and once you're done with gtk4 you could write up a better patch
<raghavgururajan>true. if I get the gtk (v4) done, then gtkmm (v4) should be trivial.
<leoprikler>i.e. more or less, sleep on [1], do [2], do [4], then maybe add gtkmm-3 for backwards compat
<raghavgururajan>I see.
<apteryx>civodul: guix-minimal in the installer image would allow people to easily clone their Guix config from their git somewhere (see:
*raghavgururajan goes Woosah! (
<raghavgururajan>karthik[m]: Hey o/
<nckx>Morning Guix. Since licence combinatorics were recently a hot topic: if a source checkout contains gpl2 files but these are not used to build the installed result, only the gpl2+ files are, what do I put in (license ...)? (list gpl2 gpl2+) + comment feels superpedantic.
<raghavgururajan>Morning Toby!
<leoprikler>I would say it's perfectly fine to assign gpl2+ to them, since everything that gets put into the actual program is GPL2+
<vivien_>Every GPL program contains some piece of non-GPL-compatible files in its source code.
<vivien_>Namely, the license itself.
<iskarian>welp, wrong window haha. morning guix
<karthik[m]>raghavgururajan: hello \o
<raghavgururajan>karthik[m]: I am gonna start packaging gtk (v4) and gtkmm (v4). Let me know when your available, we can find a way to co-ordinate.
<karthik[m]>raghavgururajan: Sure!
<nckx>leoprikler, vivien_: That was my understanding until recently too.
<nckx>Well, no, it still is; others merely disagree :)
<nckx>Great, thanks.
<raghavgururajan>Folks, karthik[m] is a maintainer of some packages in debian. They are interested in GNOME40 work and looking forward to make some contribution.
<raghavgururajan>Welcome to Guix, karthik[m] !
*vagrantc waves to karthik[m]
<nckx>raghavgururajan: Grrr. My connection sucks so I'll stick with ‘I agree with leoprikler, focus on gtk@4.’
<nckx>Welcome, karthik[m].
<apteryx>karthik[m]: welcome!
<raghavgururajan>nckx: Cool!
<karthik[m]>Hi all !
<jackhill>Weleomc, karthik[m]. GTK-4 stuff will be nice as well raghavgururajan
<nckx>🤞 for VirtualBox in Guix: <>
<vagrantc>hrm. pinebook pro using "linux-libre" doesn't seem to have accelerated video ... but "linux-libre-arm64-generic" works fine, from what I recall
<vagrantc>unless i'm just missing some libraries or something
<raghavgururajan>andreas-e: `git rebase master` while being in wip-gnome didn't work.
<raghavgururajan>nckx: Any tips on how to rebase wip-gnome with master? That is: Its been a while since I created wip-gnome from based on master. So I want to add newer commits of master to wip-gnome.
<vagrantc>rebasing will require resigning all the commits ... part of why i did merge instead for wip-pinebook-pro
<nckx>raghavgururajan: What do you mean, ‘didn't work’?
<nckx>You'll have to resolve those either way, merge or rebase, and prefer rebase.
<raghavgururajan>nckx: There were conflicts. But I resolved them. After that, in git log, I don't see newer commits from master.
<raghavgururajan>* after rebase, in git log ...
<nckx>Which command did you run? It should look like ‘git rebase upstream/master’, ‘git rebase origin/master’, etc. depending on your name for ‘Guix's Savannah’.
<nckx>And you need to ‘git fetch --all’ first.
<raghavgururajan>vagrantc: I see.
<nckx>vagrantc: What's wrong with that?
*raghavgururajan tries again with --all
<iskarian>The current go, when CC is set to a non-canonical gcc, with CGO_ENABLED=1, still bakes in a runpath to the canonical gcc's lib. Does this seem correct?
<vagrantc>nckx: having to re-sign already signed commits over and over again and resign commits that were done by others ... seemed like more work than i wanted to do
<nckx>Is your machine that slow?
<vagrantc>nckx: i also don't have passphrase caching for signatures
<nckx>Oh jee.
<nckx>That sounds horrible.
<vagrantc>and in the end, the patches that got pushed to mainline were entirely different :)
<vagrantc>but i had planned to only rebase once i wanted to push to mainline
<vagrantc>nckx: admittedly, caching passphrases for signing sounds horrible in a different light :)
<nckx>Not really.
<vagrantc>when i sign something, i want to know what's being signed and at least how many things are being signed ...
<vagrantc>if i expect N signatures, and it prompts me for more...
<raghavgururajan>Worked. Thanks nckx and andreas-e.
<raghavgururajan>nckx: Do I have to do anything before pushing the wip-gnome?
<vagrantc>probably have to delete the old branch
<nckx>Yep, that ☝
<nckx>Delete (e.g., git push origin :wip-gnome) and push anew.
<pushcx>vagrantc: just dropping into the conversation - is the pinebook pro well-supported by guix now?
<raghavgururajan>nckx: So being in wip-gnome worktree, I do [1] git push origin :wip-gnome [2] git push origin wip-gnome?
<nckx>That should work if you have everything set up ‘the expected way’.
<vagrantc>pushcx: getting there
<vagrantc>struggling to figure out the difference between graphics acceleration on linux-libre-arm64-generic vs. linux-libre ...
<vagrantc>the arm64-generic has troubles building some packages
<civodul>apteryx: i think it's ok to expect power users to run "guix install git-minimal" in the image, no?
<vagrantc>pushcx: and sort of related
<pushcx>vagrantc: Thanks for the update. It's awesome to see your progress.
<pineapples>Hello Guix! Have you heard about Nomia?
<vagrantc>hmmm... the lack of accelerated video on pinebook-pro doesn't seem to be a kernel problem, as running the same kernel on another installation works fine
<iskarian>On guix, is ld always ld-linux no matter the arch?
<civodul>iskarian: no, see
<civodul>the loader ( is part of glibc
<iskarian>civodul: thanks. I'm trying to figure out why the go package only overrides the ld location for "/lib(64)?/ld-linux.*\\.so\\.[0-9]"
<civodul>that regexp covers GNU/Linux on the most common architectures
<civodul>it excludes GNU/Linux on POWER9 and GNU/Hurd, for instance
<civodul>(according to glibc-dynamic-linker above)
<iskarian>ah, that would make sense, since gc can't compile for those architectures anyway
<janneke>completion of guix commands (guix package TAB) in an emacs shell is broken for me, does it work for you?
<leoprikler>pineapples: They lost me at "We'll likely do this in Rust"
<civodul>janneke: it's broken for me too but i thought this was due to Emacs-Guix/Geiser misconfiguration on my side
<janneke>civodul: yeah, me too. it's been broken quite a while and I also had (setq guix-directory "~/src/guix/master")
<janneke>i just upgraded everything, removed that setting...but it's still broke
<civodul>janneke: i also set 'guix-directory', that's why i wasn't sure
<civodul>so maybe it's really broken after all
<pineapples>leoprikler: I know a little about functional package management to vocalise my opinion about the implementation, but it like the idea. I'm wondering what everybody else, especially Ludovic, thinks about it
<apteryx>civodul: I think git must be a common requirement enough to offset the 3% size increase cost; but that's just my personal opinion :-)
<civodul>apteryx: i know it's "just" 3%, but it all adds up, and for a use case that's not the main one (not using the guided installer)
<apteryx>I agree that 'guix install git' is not a terribly difficult/expensive thing to do for users already savvy enough to version their config
<civodul>yeah, it's not the end of the world, but if we can avoid this extra space, that's better IMO
<apteryx>ack; I'll keep the wget change and drop the git-minimal one.
<civodul>sounds good!
<civodul>pineapples: i don't really get the Nomia thing; sounds like they're talking about capabilities (as in "object capability"), but i find it a bit fuzzy
*apteryx runs 'make release' with a 1.3.0rc2 tag
<civodul>apteryx: \o/
<pineapples>civodul: Perhaps this forum thread should make it clear what the project tries to achieve: ?