<lechner>it also appears, with nicer formatting, when you scroll down on the home page
<nate1>Oh I thought you were referring to something on the issue tracker. Doesn't that just mean that nextpnr can't build libtrellis at the same time it's building itself? The Fedora package for example builds them separately, and just copies the whole database source into the prjtrellis database folder during the build step
<rekado>I switched to emacs-next and now I get this on starting emacs: internal-macroexpand-for-load: Eager macro-expansion failure: (file-missing "Cannot open load file" "No such file or directory" "assoc")
<nate1>But I suppose that the right way to do this is just to go through the process of generating the DB manually. I was really hoping to at least test this without having to do that since it's supposedly a very slow process
<rekado>I don’t see any reference to “assoc” in my init.el
<lechner>for Gnus, i think you have to be real hardcore. i find notmuch convenient and fast (but does require a local copyy of your folders) people also say good things about mu4e, as I am sure you are aware
<lechner>mirai / you can also experiment with swaks
<ulfvonbelow>is the shepherd udev requirement broken or something? I have a service with (requirement '(udev)), and yet when it runs the network interface in question is still named eth1, and so it fails
<lechner>ulfvonbelow / the eudev in Guix is defective #63787
<lechner>i have used in production since may 2: enxb8ca3a875f15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
<ulfvonbelow>having only skimmed that issue, does it seem like that could be the problem in this instance? Note that I'm not trying anything fancy, just using the default name eudev assigns to that interface (enp2s0), and it's not getting renamed in time
<ytc>hello. i've realized that i cannot install qt5-webengine or qt6-webengine on parabola gnu/linux but it is available on guix.
<GNUtoo>ytc: it's complicated: qt-webengine depends on chromium and Parabola and Guix don't have the same policies reguarding Chromium (and other things as well)
<fosskers>Question: I've installed Guix on top of my foreign distro. I'm generally having success with specifying packages I want within a `manifest.scm` and then referencing that with `guix package`.
<fosskers>`guix home` seems like the next step though, as it would actually allow me to configure apps in a centralized way as well, and yet in my experiments with it, it seems to be an entirely closed off environment, yeah? Nothing on my system's $PATH or my usual `/home/me/` is visible. Is all that intended?
<apteryx>some cross-origin something something is blocked
<nckx>ulfvonbelow: At least if you build firefox yourself it's pretty easy to customise everything through firefox.js.
<nckx>Everything in about:confic can be preset this way.
<adanska>has anyone tried using the applications menu extension with GNOME? i keep getting a `Requiring GMenu, version none: Typelib file for namespace 'GMenu' (any version) not found` error despite having gnome-menus installed.
<adanska>its strange cos gnome-menus is a propagated input for gnome too. even explicitly installing it to my profile (which shouldn't make a difference, so it doesnt surprise me) doesnt change anything.
<radio>I'm trying to package newsraft, but it's the first time ever I try to package something that requires understanding on build process, could someone here take a look and give me a hint on what is going wrong?
<rekado>radio: I’d start with “guix build -S nomad” to inspect the code. Does configure.ac or Makefile* set “-Werror” anywhere? Does it provide mechanisms to override this (e.g. configure flags or make variables)?
<rekado>and then you can attempt to fix it by either passing configure variables, make flags, or by adding a build phase after 'unpack to patch the use of -Werror
<janneke>civodul: so i guess it should be reverted?
<janneke>and the switch should possibly be made in another way?
<dthompson>has anyone tried to define a channel for a repo hosted by cgit? I've never had an issue cloning such repos but guix throws "guix pull: error: Git error: invalid content-type: 'text/plain; charset=UTF-8'" :(
<janneke>the main problem, of course, was that glibc-2.33 fails to build for the hurd
<civodul>janneke: i’ll try something; there’s another area where we have troubles
<civodul>i think we have to accept that we cannot have two different glibcs depending on the system
<janneke>maybe jpoiret has an idea of how easy it would be to fix building glibc-2.33 for the hurd?
<somenickname>in the past I did it in the same way to use a different one (slim) which worked flawlessly. That is why I am now so surpsised
<ulfvonbelow>only one thing to do now: 'guix repl' and use modify-services interactively
<jpoiret>or just display the service list of your operating-system definition in the repl
<somenickname>Also it says that gnu.org is down but it works for me. I guess they fixed it.
<somenickname>Can you help me with the Guix REPL? Never used it. What do I need to import?
<ulfvonbelow>should bo okay to just (load "/etc/config.scm") or wherever your system config is, but do it like (define config (load "/etc/config.scm")) or else the P in REPL will cause it to print the operating system, and that will spew a lot of stuff
<nckx>Note that by ‘the build environment’ I mean specifically the standard build environment used by all Guix package builds in e.g. ‘guix build foo’, which should differ only in kernel version across machines. So debugging outside of it can save time, or it can introduce red herrings, it's a toss-up.
<nckx>You can ‘guix build guix’ (don't ‘guix install guix’ unless you want unupported pain) but there's also ‘(guix self)’ and well it's complex because of bootstrapping issues.
<euouae>OK I'll keep it in mind. I can't investigate further for now because I don't even know how guix build works, not even superficially.
<nckx>Very superficially, ‘guix build’ sends RPC instructions to the guix-daemon, which is what creates an isolated container with all required inputs (but nothing else) that should be almost constant across all machines, and runs the builder.
<nckx>What I didn't know at the start of this convo: the manual looks fine when Guix is built as a regular package ( guix shell --pure guix info-reader -- info guix*
<nckx>What I didn't know at the start of this convo: the manual looks fine when Guix is built as a regular package (guix shell --pure guix info-reader -- info guix), so this is something specific to the pulled guix, which uses a different build mechanism.
<nckx>I think! None of the above counts as a proper investigation, I'm on my 'phone :)
<somenickname>I deleted gdm service and removed that default xog config you get from the installer iso and if I reconfigure my system I get guix system: error: error parsing derivation `/gnu/store/4jlw5kk8wnn3fx5qpwamvjqg0nr1lmr6-upgrade-shepherd-services.scm.drv': expected string `Derive([' and cat outputs nothing
<radio>Guys, for some reason that's not obvious for me, sh is not on my PATH, when it should be in /run/current-system/profile/bin/sh
<nckx>If so, no idea what went wrong (vague allegations of corruption etc.), but ‘guix gc -D /gnu/store/4jlw5kk8wnn3fx5qpwamvjqg0nr1lmr6-upgrade-shepherd-services.scm.drv’ should clean it up so it can be regenerated.
<nckx>sneek: later tell somenickname I'd say so! Technically you've entered undefined behaviour (because Guix foolishly assumes a perfect file system drivers), so anything goes, but that's a pretty bad failure mode.
<dcunit3d>i'm running the emacs-next-pgtk, it's been crashing fairly regularly. like every few hours. does anyone know if the debug build for the pgtk version is fairly straightforward?
<somenickname>nckx: Hmm, okay it reconfigured it but now my system is in a rebooting loop. The last line is boot program [...] terminated, rebooting
<sneek>Welcome back somenickname, you have 1 message!
<sneek>somenickname, nckx says: I'd say so! Technically you've entered undefined behaviour (because Guix foolishly assumes a perfect file system drivers), so anything goes, but that's a pretty bad failure mode.
<somenickname>I just want to boot in TTY, why does it not want to do that
<nckx>Walking, but: because more (boot) scripts have been truncated, is my guess. I'd boot a Guix installer image, chroot like described in the manual, and run a full guix gc --verify=contents,repair
<nckx>I'd also run a ‘guix system build /etc/your/system.scm’ in that chroot since that's something Guix won't be able to download, and if the .drvs are broken, also not build locally without such a hint.
<dcunit3d>also, i thought it was a pgtk issue, so i switched to wayland (on kde so it was easy), but emacs is pretty much doing the same thing.
<nckx>Now, before I get hit by a bus, I bid you good luck and good-bye.
<somenickname>nckx: Can't I just do that on a generation that is fine?
<bumble>would anyone kindly recommend a wifi dongle for usage with guix?
<lilyp>obviously the RYF ones, but I think we also mention the working drivers in the manual
<somenickname>nckx: Okay it works now. Though it seems that Guix doesn't even support running xinit manually.
<nckx>Nope, I don't think that's trivial, but happy to hear it works.
<somenickname>I just don't understand why it happend in the first place. Isn't this operation transactional which means only on successful operation it applies it?
<nckx>As far as Guix was concerned it was successful. It successfully built and reconfigured the system and wrote everything to disc. Maybe there's a missing fsync() or so somewhere, or some other POSIXy expectation didn't hold.
<nckx>Even if Guix were paranoid and read back every file it wrote just in case, I expect the system would still have lied to it and returned the originally written data for these ‘empty’ files.
<nckx>But without knowing what exactly happened, nobody can say.
<somenickname>Well, at least Guix gives you the tools to recover from it.
<somenickname>Well, I can try it again in a VM with BTRFS and with EXT4 and look if it behaves the same if FS is a concern.
<errous>I'm interested in the result, if you have the time.
<nckx>I've heard of ‘lol’ being used as ‘lots of love’, but ‘lmao’ as cry of sadness is a new one.
<nckx>FTR, I (by far) don't have enought data to implicate btrfs specifically. I think it's more likely that Guix (maybe through the inherited Nix daemon, if ego is a concern) doesn't fsync() in just the right way that POSIX/Linux expect, which then happens to affect some file systems more than others because they made different trade-offs.
<somenickname>errous: Not today anymore but I will tomorrow or in the weekend.
<nckx>Still, hard stress-test data would be neat, somenickname.
<nckx>FWIW I don't think any of those things matter much, but enough on this subject from me.
<somenickname>Well, if it happens in the VM with this setup I know it was not some cosmic ray edge case stuff. If you tell me how, I can still run the tests in the way you need it for figuring out the actual error. I don't have any knowledge what is important or not so I just do a 1:1 to be sure.
<somenickname>Probably should do it in qemu directly and not virtual machine manager :)
<somenickname>What is a good way of learning to contribute to GNU Guix? I am going to read SICP and The Scheme Programming Language. Should I may read additional books or has anyone better recommendations?
<zamfofex>somenickname: I think playing around with local package definitions and your home and/or system configuration to get a grasp of the basics is a good way to start.
<somenickname>zamfofex: I am already doing this. Though I think having good fundamentals is better than looking at those kinds of code snippets. I don't understand much of the advanced ones and the different syntax style of old and new makes it even harder.
<zamfofex>The way I started was by writing my own packages locally. Specially useful if the package is complicated and not just plain.
<somenickname>Yeah but I basically just end up copy/paste stuff but not really understand why it is done like this and why some do it this way and some others. I feel like I will never understand the whole of it.
<somenickname>What I mean with that is, I learned. But I doubt I will fully understand it this way.
<somenickname>zamfofex: You learned this way and now even understand complex packages?
<zamfofex>I think that works well for what you need. (I.e. copying and pasting parts.) But at some point, you’re going to run into a package (or some other feature) that requires you to actually come up with original stuff. Maybe you can copy (or inspire yourself) in existing packages, but they way you compose them might become increasingly unique, and that’s when you start to learn.
<zamfofex>somenickname: Somehow Guile is both simple and complicated, I feel. You don’t understand how everything works internally to begin with, just what is meant to be “exposed to you”. But over time, you learn more about certain things as you keep exploring. I’m definitely no Guile pro. I still don’t have a deep understanding of many features. But I feel like I have enough understanding to play around with Guix!
<janneke>jpoiret: oh my, hoping you find a nice place soon!
<jbnote>Hi, guix --sources=transitive build does not list hidden packages. Is that expected? It's really a nuisance, as it defeats the purpose (I noticed this with cmake-minimal, which is not listed in the dependencies of any build, but required nonetheless)
<euouae>Hello when I do `guix show -L foo bar` I get bar: package not found error
<euouae>Is this a nice error message? If foo doesn't exist, shouldn't that take priority?
<euouae>perhaps not since I just realized -L prepends to the path of loaded modules
<jaeme>How would one build all of the packages of a specific guix channel?