***jpoiret9 is now known as jpoiret
<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... <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
<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. <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: <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... <avalenn>I hope to find time to work on this but time is a scarce resource. <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>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>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>instead of pretending i have a clue ;-) <civodul>BTW, we've been using a guile-avahi tag for a while <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 git.savannah.gnu.org: 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>guix: environment: command not found <civodul>did you *really* mean "environment"? <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 <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_>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>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>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 <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. <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. <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. <nckx>leoprikler, vivien_: That was my understanding until recently too. <nckx>Well, no, it still is; others merely disagree :) <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. *vagrantc waves to karthik[m] <nckx>raghavgururajan: Grrr. My connection sucks so I'll stick with ‘I agree with leoprikler, focus on gtk@4.’ <jackhill>Weleomc, karthik[m]. GTK-4 stuff will be nice as well raghavgururajan <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. <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. <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 <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 :) <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... <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>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? <pushcx>vagrantc: Thanks for the update. It's awesome to see your progress. <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? <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>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