<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:
<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
<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 ?
<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?  Temporarily have the gtkmm patch as-is in c-u  package gtk (4)  rename gtkmm to gtkmm-3  package gtkmm (4). So at the end of , 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?
<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.
<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.