<lfam>There are also different versions of configure, maybe some of them have some speed-ups
<lfam>In general, configure being slow and single-threaded is widely acknowledged and a primary motivator for the development of some other build systems
<genr8_>now that makes more sense. the slower ones were happening more often during the early bootstrap phases
<lfam>It's likely that your VM needed to page things in, assuming you're still starting from scratch every time
<lfam>I doubt there are significant speed differences in the configure scripts themselves (they are shell scripts)
<genr8_>it was like a 100x speed difference. enough to be concerning.
<lfam>That's the kind of benefit the page cache will give
<lfam>There's a nice graphic somewhere that illustrates the difference in data fetching speeds from different parts of the computer. Basically, each level closer to the CPU is an order of magnitude difference in speed
<genr8_>moving on, i would like to report something else
<genr8_> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/features.h:397:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] <--- now i'm getting this during a build of /gnu/store/2l8f4sjw0jbfll4ilp7pzwimrh5kjdgf-swig-4.0.1/
<genr8_>doesnt that seem like a significant oversight ?
<lfam>Most significant C and C++ codebases compile with a large number of warnings
<lfam>I would report it upstream if you are worried about it
<lle-bout>genr8_: we are not at that level in GNU Guix where we can afford paying attention to details like that, it will come when packages in GNU Guix will have matured more and GNU Guix will have matured more in general, also more contributors.
<lfam>In general, in Guix we run the build scripts that upstream distributes
<lle-bout>genr8_: we may start studying enabling hardening compiler options at some point but not done yet
<lfam>The main thing is to make it useful for most people, and not just for one self. Like yesterday somebody wanted to remove the primary GNU mirror because they were using some paid VPN that mis-advertised their location
<genr8_>ok that worked. I think its coming from "subversion"
<marusich>lle-bout, thank you for updating the guix package. and yeah, lfam we couldn't do it during code review because it is awkward to do that on a branch that is going to be rebased frequently. I'm glad it's done now!
<lle-bout>marusich: hello :-) - I am updating my powerpc64le-linux machines with GNU Guix official master :-D
<marusich>I should probably have done it right after merging, but I wasn't sure what the policy was for updating the guix package (e.g., "does the release person want to do it just once before making a release?" I guess the answer is "no")
<lle-bout>Also for the security vuln in guix-daemon
<lle-bout>guix pull has been working fine for me and test suite too so maybe it's your system that's a bit different triggering the failure
<marusich>lle-bout, yeah that's always possible, since I've been building guix manually on debian
<marusich>Gotta love that manual dependency management...
<lle-bout>cbaines: hey by the way my x86_64 VM that runs guix-build-coordinator-agent has been constantly busy for a while now, that's great!
<marusich>What's the process for adding an entry to news.scm? Do I just make a commit like f62633a527a7b54ab2c552b493dce382ab2365e6 in one language (english), and people will later maybe translate it into other languages...?
<genr8_>let me ask something. why would someone use "stable v1.2.0" if the first thing that happens is that guix pull just goes and grabs "latest" and updates all the internals of everything over top of itself again
<genr8_>theres some weird magic going on here with the local function overload reusing the same name, and the autoload
<marusich>Note that reverting the commit fixes it.
<marusich>The problem is probably (?) that (package->code pkg) incorrectly uses url-fetch*; it should be using url-fetch. So I guess the bad change altered this (so previously package->code wrote url-fetch, but now it's writing url-fetch*)
<marusich>I guess it's because, with the bad change, (origin-method source) in guix/import/print.scm procedure evaluates to the url-fetch* procedure (you can add a pk form like (pk (origin-method source)) to see this)
<marusich>presumably it ought to evaluate to url-fetch
<marusich>It invokes (procedure-name method) and gets url-fetch* because that is the name of the method. I wonder how you are supposed to get the "exported" name in the case where (as this change did) the function is exported under a different name?
<marusich>I've sent an email summarizing this; I think we should revert the change if we can, and hopefully Ludo will have some thoughts about how to fix it based on the info I've shared. I'm not sure how to solve it
<clacke>roptat> "[packages are] quite some work sometimes" lle-bout > "they are, but I feel like copyright is the wrong metric to define it, since most of the work is testing"
<apteryx>raghavgururajan: still going through your patches! that bzrtpTest takes time
<marusich>lle-bout, I'll bet the reason why "guix pull" worked, even though "make check" doesn't, is because "guix pull" doesn't use the usual process for building Guix. It kind of reproduces the work, but in scheme (see: guix/self.scm).
<raghavgururajan>apteryx: Thanks so much for talking your time on this. Sorry, that I haven't replied to your emails yet, as I have been pre-occupied with gnome stuff.
<genr8_>i think it would help to fulfill the transparency and auditing mission if the log for everything that goes into a running system is collected at once, instead of leaving it to me to pull one at a time.
<rekado>I don’t understand: why would you trust the logs when you don’t trust the build farm enough to use its binaries?
<abr>so I expected you'd all be knowledgeable about them : )
<efraim>mesa FTBFS on core-updates with gcc-10, the llvm tests fail. Trying again now with gcc-9
<abr>well yes and no : I've never had any difficulties setting up input methods when I had to setup my desktop from scratch, but now I see there's an ibus spawning by itself and, not being able to trace where it comes from is very scary
<cbaines>jemarch, mothacehe has been working on Cuirass recently, but I don't think he's around currently
<jemarch>I was wondering whether we could use cuirass for GNU poke
<nckx>From what I've read so far it seems pretty clear that GNOME handles Ibus itself, not Guix. 2 of the top 3 workarounds in my search results, after ‘disable it in System Settings’ are ‘rename ibus-daemon to ibus-daemon.bak’ and ‘chmod -x ibus-daemon’.
<jemarch>can you define derivations in terms of, say, configure options?
<gagbo[m]>Hello, can I query locally the recipe for a package ? I'd like to check the commit used in the recipe for a package in my current env basically
<vldn>is it possible to split my personal config into different files and can activate options (like extra packages, service configs etc.) via a single flag in my main config?
<vldn>i already have a module defined via add-to-load-path and load it via (use-modules) but how to go further than defining a single package that i can load into my package list?
<pinoaffe>vldn: are you referring to system config or to manifests or something else?
<pinoaffe>anyhow, both are "generated" by evaluating guile scheme code, so if you know a bit of scheme you can make write a script to make the config vary based on a couple of flags
<gagbo[m]><gagbo[m] "Hello, can I query locally the r"> I ended up using `--export-channels` to get the commit and check in the repo using other means. I couldn't know which version of the channel I was using in my `/gnu/store` (had like 5 different ones)
<nckx>Thing is offloading has never worked reliably for me, to whatever server. But if you're still offering...
<lle-bout>nckx: Offloading works great for me, well turns out I can offer SSH access but offloading is insecure unless I create a VM for each so, bayfront seems to be a server that can be used for offload by GNU Guix committers, maybe use that?
<nckx>lle-bout: It might have been fixed or the fix might be on the patch tracker, I just don't have the energy to fight this particular issue now. Some things are fun to debug, networks have never been one of them for me.
<lle-bout>nckx: Sure, but I am also interested in it that's what I was saying, automatic retry policies etc, reliable software, I like this.
<nckx>I don't like puzzles where the answer changes, unless it's a Spooky Thing That Shouldn't Happen, then it's interesting again :) ‘<eof> during the pull backtrace’ isn't that.
<lle-bout>There might be a model where we can design offload based on the idea that real time networking isnt necessary (polling for results)
<nckx>lle-bout: Well, if you can offload reliably, then I don't know what to say to reproduce my suffering...
<lle-bout>I don't get any errors during offloading, I have a pretty reliable network here yep..
<nckx>lle-bout: Nice. I'm not generally a fan of polling, but falling back to it would be an improvement here.
<lle-bout>nckx: if not polling then some backlog buffer that can be sent after reconnecting
<lle-bout>sounds easy to me to remember some log file offset and resume from there on reconnect
<lle-bout>I wonder how we access the live logging feature of Cuirass
<apteryx>raghavgururajan: about ortp, nevermind, I understood
<apteryx>eh, I don't get it. As soon as I import the #:imported (,@%cmake-build-system-modules) build argument, the build system effectively switches to that of gnu-build-system
<paulj>Good thought - I checked the system logs, but not the xorg logs. One moment...
<paulj>Interesting. There is a log where you pointed to, but it was created on the 6th March. There is also a log in /var/log/ with today's date. The former shows the touchpad being recognised and configured, but the latter doesn't. I am not sure what changed around the 6th March to make xorg move the location of the log file. In the old logfile, the touchpad is identified under /dev/input/event8, but in the new logfile, this is shown as
<paulj>"ThinkPad Extra Buttons", and is being configured as a keyboard switch, and is then seems to be removed.
<paulj>Seems like udev is not identifying it properly?
<roptat>if nobody can help here, maybe try to send to help-guix
<paulj>Thanks for responding. Looking through what I can find on the internet, there seems to be issues sometimes with these not being recognised, and there is a parameter which can be set when the module is loaded. What is strange is everything was working fine, but now doesn't without any change to my configuration!!
<roptat>sometimes they change the way configuration is handled
<roptat>or maybe a new version of guix has new defaults that don't play well in your case
<yoctocell>Hi, is there a way to "patch" channels? For example, there is a patch (https://issues.guix.gnu.org/47180) that fixes some problem with Racket but, it hasn't been merged yet. How would I use this patch in my Guix channel?
<mothacehe>although it means trading sexp against huge amounts of js :p
<mothacehe>the service config does a insert-or-update in database
<abcdw>hi again, yoctocell: Probably, there is no way to do it easily. Patches doesn't have commits related to them => you can't use them in channels definition. The obvious option is to clone guix repo and apply patches on top of it and set guix channel to local repo.
<yoctocell>Hi abcdw! Ok, that seems to be only option for now.
<guixnoob>question about backups using guix package manager on foreign distro: is it enough to make sure that /gnu/store and /var are included in the backup? I use Timeshift for system (non-home) backups and Back in Time for home backups. I'm not sure the proper way to ensure that, should I have to reinstall my OS, my guix setup and packages restore as well.
<guixnoob>It seems like the guix stuff is spread across multiple places. /gnu/store, some files in /var, user home .guix-profile, root .guix-profile
<civodul>mothacehe: if i look at the spec via the "edit" web UI, it looks good; but it's still failing (with the "channels" build type now)
<abcdw>guixnoob: You actually do not need to backup guix stuff, if it is declared somewhere. Because of reproducibility it's enough to have only configs to be able to get all the stuff in /gnu/store again. However if you use guix package -i or guix install it's a little trickier. I would suggest to use manifests and later, when it will be finished - `guix home`.
<guixnoob>abcdw: I do use guix install. I've never used manifests and I don't know anything about the `guix home`.
<lle-bout>shouldnt we try to reorganize packages better and make better use of directories
<lle-bout>I think I would prefer if each package had it's own file
<guixnoob>Is there a way to generate a manifest for the current profile, including all the already installed packages?
<abcdw>guixnoob: The really cool thing about guix is that with only two files (configuration/manifest and channels definition) you can reproduce the whole operating system bit for bit (or reproduce profile with packages in your case).
<abcdw>lle-bout: Do you mean to split modules like version-control, video, etc to multiple modules?
<guixnoob>The export-manifest output mentions using `guix describe` to get channel information.
<lle-bout>abcdw: yes, for example with gnome I feel like things are a bit spread out it's not easy
<yoctocell>guixnoob: You can put the output of `guix describe --format=channels` in ~/.config/guix/channels.scm to get the same channel versions.
<abcdw>guixnoob: You can do `guix describe -f channels` and later use it with `guix pull -C` or `guix time-machine -C`, but you need to read manual first to get better understanding of guix features and capabilities.
<mothacehe>zimoun`: nowhere because you don't have the admin access on ci.guix.gnu.org
<guixnoob>So if I save the output of `guix package --export-manifest` to a file somewhere, and save the output of `guix describe --format=channels` to another file somewhere, then I can just backup those two files? Then all I have to do on a new system is install guix, then [do something with the channels file ?], then `guix install -m <manifest file>`?
<zimoun`>yoctocell: guix show <pkg> | recsel -p location
<civodul>oh, new Emacs release; "guix install emacs --with-latest=emacs" anyone?
<guixnoob>Awesome. I have those aliases which save to .config/guix, which gets included in my Back in Time backups, and I have added that directory as a backup directory in my pCloud settings. 3-2-1 rule: achieved. Thanks!
<Raenis-Limenis>hey all, was wondering if I can get some help. I'm trying to use guix system disk-image on a install.scm I currently have on a ubuntu host. This is the error
<Raenis-Limenis>guix system: error: failed to load './install.scm': ice-9/boot-9.scm:3300:6: In procedure resolve-interface: no code for module (nongnu packages linux)
<Raenis-Limenis>the exact line was "guix system disk-image ./install.scm --image-size=10G
<NieDzejkob>looks like that file wants to use the files it was originally distributed with
<yoctocell>zimoun`: `recsel` is not installed on my system (:
<paulj>Mine stopped working completely sometime between the 6th March and today. For some reason the trackpad was no longer recognised. I have got around the problem by removing the blacklisted usbmouse (temporarily at the moment), but it doesn't seem right. I don't know if that has changed recently.
<paulj>My config is _very_ similar to yours, and uses libinput to manage the device
<dongcarl>civodul: I believe this was a `guix` built from source, I will double-check.
<DavidWilson[m]><paulj "Mine stopped working completely "> Interesting, I did a full system update yesterday on one of my machines and the track pad is still working. Does it improve the issue if you stop using libinput?
<paulj>I haven't tried that yet. When I installed Guix everything just worked, and as I had an external mouse attached I never noticed the loss of the trackpad function. I'll do a bit more investigation and see whether I can narrow it down further. Interestingly, I have another X270 running Gentoo and this is also configured to use libinput, and has no issues. I am just updating that machine and will see if there is issue external to the
<lle-bout>raghavgururajan is doing the GNOME 3.38 one in parallel
<acrow>On guix system -- what is the recommended way of managing /etc/hosts? Just stick a (substitute* "/etc/hosts" regex) into the operating-system declaration? Wouldn't shepherd overwrite a manual change?
<maddo>is gnome that reliant on systemd? Shouldn't the fallback session management still be there?
<dongcarl>civodul: I'm happy to dig into what's actually going wrong myself, just wanted some pointers like: is there something wrong on the GUILE_LOAD level, or the bindings level, or libgit2 itself? Things like that :-)
<lle-bout>maddo: it seems lots of functionality depends on systemd and is otherwise disabled yes
<efraim>mbakke: I haven't looked too closely yet. I started trying to get it to build with gcc-9 instead but now llvm-11 is failing during a linking phase. I also tried bumping mesa to 20.3.5 but it had the same error. between the two I'd rather debug mesa
<apteryx>in case a package installs a tester command that runs a self test, in what output should it go? Contenders are 'tester', 'test', something else?
<mbakke>efraim: I've noticed Arch has some GCC patches that fixes a Mesa issue. Possibly unrelated, but hard to tell.
<lle-bout>maddo: I use XFCE, there's also MATE, you can also run MATE over a Wayland compositor that supports layers (like sway or wayfire) but not all applets/.. are ported over to Wayland yet over at MATE's, I pushed patches to enable that for MATE recently.
<lle-bout>I am hoping to use GNOME 40 not because I don't want a tiling wm but because I can't deal with doing the desktop integration myself on top of Sway, I would install pop-os tiling shell probably.
<lfam>lle-bout`: I'm not sure if there is a policy, but we have always preferred to own hardware, and host it somewhere "trusted". What is "trusted" is not easy to define, but we know it when we see it
<lle-bout`>Well to say within a datacenter it's not a trusted place.. I would say it's not the biggest concern, depends what you trust things for
<lfam>However, it has been difficult to do this reliably, especially with ARM. That is because, so far, there has never been any ARM hardware that was simple to install GNU / Linux on, and reliable enough to run fully-loaded 24/7
<lle-bout`>Paris is great to meet people and find your social environment but other than that..
<lle-bout`>Basically it's also that you feel empowered geographically to attend or access many social environments of privilege to have some impact, it's crazy how France media scene is so self-centered around Paris
<lfam>I suppose that everbody always wants what they don't have :)
<lfam>Population density is extremely valuable to human civilization. Everywhere you go, the biggest cities are the most important areas
<ternary>Could someone give me a bit of guidance on how config files for services work? I'm using opensmtpd and want to populate the /etc/mailname file. I figured I could add a mailname field to the opensmtpd-configuration type and have it create the file, but in looking at gnu/services/mail.scm I don't see anywhere that the path for the existing config files is specified and so I'm not really sure how
<roptat>ok, then maybe I need to find a way to integrate spamassassin or similar
<lle-bout`>roptat: it's not packaged AFAICT, but I saw few CVEs on it recently, so package it now latest it's great
<roptat>yeah, now I'm getting ~5 spam messages a day, it's annoying
<dongcarl>vagrantc: Hey hey, is the recommended use of the debian guix package to `guix pull` immediately after the install so that `guix` knows about itself and also to update the systemd service files to point to the right place?
<vagrantc>a counter to the rewrite it in rust meme
<lle-bout`>mothacehe: hey! does Cuirass have some policy to cancel all previous builds that don't apply for HEAD on core-updates?
<nckx>sneek: later tell mothacehe: One of them has a dead hard drive, and the other one dropped off the edge of the Internet just when I'd almost finished reconfiguring it. These things are cursed, but it shouldn't take much work once I can get to it.
<rhou[m]><lle-bout "rhou: can you give more specific"> I tried to compile a simple program with `import Prelude.Compat` (which is listed in `ghc-pkg list`) and failed with the error message `ld: cannot find -lHSbase-compat-0.10.5-FRXoAxOVtbG2qLNIZm1tTr`
<civodul>sneek: later tell mothacehe thanks for the Cuirass fix!
<rhou[m]><lle-bout "rhou: can you give the package d"> sorry for my late answer, look at this repo: https://github.com/rezahousseini/test-ghc-guix there is a log from the compilation (`ghc -v src/Main.hs`) and all gets compiled inside the environment defined by the`manifest.scm` file
<crazazy>question: say i downloaded the guix package manager binary, how well would the package manager work on a chroot? has someone run guix in a chroot before?
<vagrantc>Gooberpatrol66: looks like a well written article
<lfam>After you authorize the "substitution" of binaries, things should work more quickly
<lfam>I don't recall if you have to restart the guix-daemon for the authorization to take effect
<lfam>The idea behind the name "substitutes" is that Guix is actually a build-from-source distro, but we are able to transparently "substitute" binaries, due to the functional model of package management
<lfam>So, we can "substitute" building something with downloading something
<darth-cheney>So basically it was trying to build from source and entire system necessary to run this little hello thing, is that correct?
<lle-bout>efraim: seems you merged the zstd graft to core-updates when core-updates alreayd had 1.4.9 so no graft was needed
<lfam>Right, darth-cheney. From the "bootstrap" of the entire distro, up to the hello package
<raghavgururajan>I don;t know what to do. I was asked to re-work the patches so that they apply cleanly on c-u and accommodate existing changes. So I spent past few days doing that. Now current c-u is changed, containing changes from master. I cannot do the same work all over again.
<raghavgururajan>lle-bout: glib, gtk, atk, cairo, pango .. are immediate dependencies of gnome-core packages like shell, gdm etc. I am updating the former to the lastest. So that gnome-core can be updated to either 3.38 ot 40.
<boomerchad>I'm trying to package DeaDBeeF for guix and I've run into a problem. guix build warns me that 'zlib' and 'imlib2' are imported from two different modules (compression/image and licenses) I assume this means that guix uses the same names zlib and imlib2 to refer to packages, and to their licenses. Is there a way to refer only to the package as I believe this will solve my problem.