IRC channel logs
2023-09-21.log
back to list of logs
<nate1>No, what repo are you looking at? <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 <rekado>does this look familiar to anyone? <lechner>rekado / i might try the mailing list for something like that <janneke>rekado: my emacs says: assoc is a built-in function in ‘C source code’. <janneke>(i realise this doesn't say anything about who might be the client) <lechner>mirai / i also switched to emacs recently. are you using gnus? <mirai>for debbugs yeah but that's because its the default <mirai>actually using gnus proper, no but mostly because I'm getting started and would prefer to get the “essentials” in place first <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 <rekado>I’m a long time emacs user but I never found the groove with Gnus. Used notmuch when it was still young but liked mu4e better. Might go back to notmuch eventually. <mirai>lechner: yeah but message-mode is adding a comment to it as well <mirai>the text within those parentheses is a comment <lechner>you can delete lines manually. with gnus, i often see an extra cc <mirai>thing is, I don't see in-reply-to, even when I toggle all headers <mirai>looks like its generated/inserted after I do C-c C-c <lechner>rekado's message is worth a thought, btw <lechner>i believe the host name header in "Received" was added by postfix <mirai>its emacs smtp client talking to some smtp server over the net <mirai>how come they're seeing my hostname (mind you the contents of /etc/hostname) <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) <ytc>do you know the reason of this conflict? <ytc>GNUtoo: is it because it isn't blocking nonfree js by default? <GNUtoo>As I understand the issue is that Chromium is made of a ton of code source from a lot of repositories, <GNUtoo>so it's hard to check if it's all free or not <GNUtoo>Guix did work on that but as I understand what was lacking in Parabola was someone that would look and validate that work and make sure it was all free <GNUtoo>+ it has practical issues like someone would need to maintain the package <GNUtoo>The only exception for compilers in Guix seems to be for languages like vala where the vala compiler transforms vala in C <GNUtoo>So they accept generated C as source code <GNUtoo>And there are still some small binaries like a lisp interpreter or some C compilers for some less popular architectures <ytc>thank you for your explanation. <GNUtoo>As for blocking nonfree JS I've no idea how distros implement that as I didn't test many browsers <GNUtoo>But they usually try to at least fix firefox-based browsers <GNUtoo>Some propose a choice at the start of the browser but I don't recall which ones. <singpolyma>Lots of guix compilers aren't boitstrapped from the tiny seed, but there is active work to get it more and more bootstrapped all the time <ytc>i've also noticed that ungoogled-chromium package on guix hasn't been updated for a while. is this also related to difficulty of maintaining the chromium code? <GNUtoo>Last time I checked, beside the C compiler, vala, haskell etc reused "C binaries" <GNUtoo>(though before that I assumed that haskell was binary but it was source code translated to C) <GNUtoo>(I was told that during a discussion about adding the ada GNAT compiler) <singpolyma>The most important thing is the compiler bootstrap itself, IMO. Having it bootstrapped easily from another compiler already in guix is a nice to have for certain goals <GNUtoo>Are there long-term-support versions of Chromium? Or are people always supposed to use the latest release? <PotentialUser-61>My nginx service is failing to start. How can I find out why? `herd status nginx` doesn't tell me much, and it's not clear whether Shepherd even keeps logs of the services' output. <user363628>Is there a way to use a package available on a nix channel via guix? Or is the recommended way to install nix and use nix commands to manage it? <ulfvonbelow>PotentialUser-61: depending on when the error occurs, it should either go to /var/log/messages or /var/log/nginx/{access,error}.log <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? <fosskers>If so, is there a middle ground where I can still configure things via Guix, but have access to the underlying system packages, configs, etc.? <ulfvonbelow>lechner: seeing as how it does eventually get renamed as it's supposed to, I would assume so <ulfvonbelow>or is that some mechanism other than udevadm at work? <lechner>fosskers / i use a pure Guix system, but my sense is that having Guix Home (which I do) allows mixing. i think the point is that it is declarative rather using guix install ... <ulfvonbelow>I'm not sure what I should be putting for --name=, I tried --name=eth1 and --name=enp2s0, and both resulted in "device node not found" <fosskers>lechner: I'm still able to avoid `guix install` with a one-off manifest file <ulfvonbelow>I'm just running the default udev service on guix system <lechner>fosskers / Home is manifest on steroids <fosskers>If I were able to configure apps in a manifest too, without Home, then that would be enough for me. <ulfvonbelow>ACTION dreams of being able to declaratively configure icecat with guix home someday <ulfvonbelow>but firefox doesn't seem terribly interested in such things being configurable programmatically <euouae>ulfvonbelow: don't they have a js file for about:config? <lechner>ulfvonbelow / the interface is getting renamed too late? <ulfvonbelow>for my make-br0 shepherd service that has (requirement '(udev)) <ulfvonbelow>I make a bridge device and then use static-networking-service-type to configure it <lechner>i am not sure that's right, but i meant '(udev networking) <ulfvonbelow>no it's the other way around, the static-networking-service-type has (provision '(networking)) and (requirement '(network/br0)) <ulfvonbelow>I don't think there's any special magic in static-networking-service-type to make sure udev has really done whatever renaming it's going to... <ulfvonbelow>ahhh, yep, there it is: (wait-for-link #$(network-address-device address)) <lechner>i am not sure i know enough about Guix <mirai>ulfvonbelow: re icecat, it can be done <mirai>its much harder than its supposed to be but possible in theory <mirai>there's some json files that icecat can read <mirai>I'll try to dig up some resources on this later <bdju>the `rgbds` package is out of date but the latest release commit builds and works fine in case anyone can bump the version on that <apteryx>arg, qmk uses discord for chat and this thing doesn't even accept pastes from icecat <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. <msavoritias>hey what package provides libasound? From a quick search i see that it is supposed to be package libasound <civodul>looks like there’s duplication resulting from an unfinished refactoring between (gnu system vm) and (gnu system image) <civodul>mothacehe: we’re using <virtual-machine> for tests, which uses ‘virtualized-operating-system’ <civodul>i thought ‘guix system vm’ used that as well <civodul>but no: there’s ‘operating-system-for-image’ <civodul>which makes sense, it’s just that i modified the wrong thing :-) <civodul>janneke: do you happen to remember details regarding 18e76f89055f25f015fadb7c999b410f38a88cc6? <janneke>it says the using the new qcow2 image format "breaks the test" <janneke>prolly the default for system image (hurd) changed <janneke>and easiest was to revert to using the previous, non-qcow2 flavor <civodul>i wondered whether we could get rid of it <civodul>i’ve been fiddling with this test and it’s a pain: long feedback cycles, and above all, debugging a vm in a vm non-interactively is hard <civodul>i’m working on “auto-offloading”, which i’d then like to use in non-Hurd contexts as well <janneke>rabbit hole doesn't sound all that great :( <mbakke>speaking of rabbit holes, I'm fixing some Python regressions since the c-u merge, which ultimately lead to a bunch of patches slated for python-team <mbakke>does anyone know the status of that branch? <zimoun>cbaines: Why #66013 created on 2023-09-15 21:27:15.323247 is queued after #64222 created on 2023-09-16 08:22:13.268947? Just to understand. <civodul>mbakke: auto-offloading as in you don’t have to authorize keys and stuff here and there, when offloading to a VM <nckx>All of gnu.org is down, and the admins are asleep (post memes). <nckx>(guix.gnu.org is not part of gnu.org infra, so for once is a beacon of stability.) <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? <lechner>radio / Hi, why do you invoke 'make' manually? <nckx>Ignore the borked indentation, I'm in hostile country. <nckx>Using DESTDIR is almost always a mistake. <radio>lechner: I don't know ;-;, I've just read some examples and the documentation, but found it hard to understand what is happening <lechner>radio / please ask your questions here <radio>I think the point is that I don't understand build systems at all, I had no previous experience with that in other distros <radio>What the CFLAGS=-DCURL_WRITEFUNC_ERROR=0xFFFFFFFF part does? <radio>The 0xFFFFFFFFF specifically <lechner>minus one, a commpn way to indicate an error condition <nckx>It's a definition introduced in curl 7.87. Guix's curl is 7.85, so you get that ‘undefined’ error, so we need to define it ourselves. <radio>No problem, I could have guessed <radio>nckx: aaaaaaaaaaaaah, got it <radio>The build worked :D, I'm so happy <nckx>Guix's curl is ‘old’ because updating curl would rebuild over 20,000 packages. <nckx>I want to explicitly thank you for the way you shared your package, it was perfect. <radio>Could you guys recommend good places to learn about build systems? I'm mostly interested on packaging software in C, maybe some written in Guile and C <rekado>radio: unfortunately the best way is to read the code in guix/build-system and guix/build <rekado>radio: build systems in Guix always consist of a bunch of phases, which are executed in sequence. <rekado>radio: these build steps differ by package type, and they encode common steps to get from the source code to the built artefact. <rekado>we can modify these steps by deleting, replacing, or adding build phases at various points <rekado>and sometimes there will be a large group of packages that would all require so many modifications as to justify encoding these changes in a new build system. <radio>I noticed that the build of the nomad browser is broken, and I have some interest on trying it, do you think it would be a good exercise on packaging? Idk if it's a difficult problem <rekado>radio: this could probably be fixed by overriding -Werror. <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 <radio>Well, seems it doesn't, I know we can substitute lines on files during the build process using substitute*, but is there something to add lines? <civodul>janneke: does “unexpected build daemon error: stoi” ring a bell? (from guix-daemon on the Hurd) <civodul>janneke: continuing my deep dive… f2cfb4a85c82882c571274573fd7ff646d380b63 works only “by chance”, because it depends on the value of the bluids when that module is loaded <ulfvonbelow>today I learned that 'guix system roll-back' may require a network connection <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? <efraim>I would check the rest of the release/2.33 branch for glibc <efraim>or just disable that libc for now <janneke>i also found that guile-avahi fails to build in a childhurd that only has glibc-2.37 lecales... <civodul>or just core-updates the whole thing to 2.37! <jpoiret>Hurd and gnumach have evolved way too much since then and a lot of headers have changed <efraim>ACTION disabled glibc-2.33 for riscv64 for a while to build a system <jpoiret>couldn't %default-locale-definitions be a procedure instead? <jpoiret>i'm not sure where its callsites are though, and if %current-system is correctly set there <civodul>i think the multiple-libc situation is out of reach as things are <civodul>we can make something that kinda works as is the case now, but there are always situations where we pick the wrong one <ulfvonbelow>fascinating, 'guix system roll-back' is currently building binutils-cross-powerpc-linux-gnu. On an x86-64 machine. <ulfvonbelow>I'm just a little bewildered why rolling back my x86-64 system requires manipulating powerpc code is all <ulfvonbelow>not sure what thing I should be passing to 'guix graph --path' to figure this out though <jpoiret>civodul, janneke: seems to me it only has 2 references which could be turned into calls that make sure the system/target variables are properly set <jpoiret>apart from this locale situation, I don't think there are places where we could mistakenly select the wrong libc. But i might be wrong <janneke>afaik, it's only about these default-locales and locale usage in commencement <jpoiret>civodul: can't we have the hurd and the linux ones exported separately, with appropriate supported-systems, and the symbol become a system-dependent procedure? <jpoiret>transparently ofc, with (define/system-dependent ..) <civodul>right before 2d546858b139e5fcf2cbdf9958a17fd98803ac4c there was a trick where ‘glibc’ would be dependent on the system/target <civodul>we’d have to do the same with glibc-utf8-locales and all <jpoiret>yeah (isn't that what define/system-dependent achieves though?) <civodul>anyway, i think we’d be better off with a single libc <jpoiret>I agree, but that the entails 1) updating to glibc 2.37 everywhere 2) not being able to follow upstream that closely <civodul>the ‘stoi’ guix-daemon exception i mentioned above was due to not using the wrong libc data (2.35 instead of 2.37) <jpoiret>2) seems like a showstopper, by lagging behind Debian that much we're guaranteed not to have users <civodul>i guess it’s a tradeoff between two non-ideal options <civodul>perhaps we could upgrade libc more frequently too (regardless of the Hurd) <jpoiret>right, that'd be great in general! But the Hurd's glibc moves faster than point releases <civodul>for instance by having a special branch for that instead of the core-updates shebang <civodul>for years/decades, the glibc for Hurd didn’t change significantly :-) <jpoiret>eg. i remember sergey mentioning that the latest glibc didn't have all the patches needed for x86_64 <civodul>well it’s definitely been moving very fast lately <civodul>(that’s a weird thing to hope for actually) <jpoiret>but I mean I say this, yet I haven't done anything either, so I'm not going to stop anyone doing something different <jpoiret>i'll have some time once i find a place to live :) <civodul>oh indeed, i hope you can sort this out! <civodul>sounds more urgent than locales on the Hurd :-) <somenickname>I have (delete gdm-service-type) and still have GDM. Does it require some replacement? <mirai>somenickname: did you `guix system reconfigure' the system? <mirai>and I presume you're using (delete …) within a (modify-systems %desktop-services …) form? <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 <ulfvonbelow>then (use-modules (gnu system) (gnu services)), then ,pp (map (compose service-type-name service-kind) (operating-system-services config)) <somenickname>Ah, that is still from the days I initially generated the config through the installer. I remove it and try again <jpoiret>yes, looking at the implementation it just adds it <jpoiret>(i mean it adds either gdm or sddm depending on whether your system is x86_64) <jpoiret>ah no it adds an extension to that service, and I guess the extended service is then created by guix automatically? <jpoiret>yeah, instantiate-missing-services does exactly that, it instantiates extended services that don't exist using default values (or errors if there's no default value) <somenickname>Well, it works but kinda to good. At the time the reconfigure command is still running I get just a black output and if I restart to the current generation it reboots the machine <mirai>core-updates is __unbuildable__ <mirai>./pre-inst-env: /home/ika/src/guix/tree-docbook/scripts/guix: /home/ika/src/guix/tree-docbook/guile: bad interpreter: No such file or directory <mirai>./pre-inst-env: line 55: /home/ika/src/guix/tree-docbook/scripts/guix: Success <jpoiret>you probably want to create a new worktree to work on core-updates <user363627>Is there a way to get a Scala environment with guix? <efraim>did you run bootstrap, configure and make on that tree? <PotentialUser-66>Sorry, if the question is dumb, but why is the public name python-cython-3 and the package name python-cython-next? <janneke>oh my, that seemingly-to-be locales issue thread is getting much longer when pulled, so it seems... <ulfvonbelow>looks like something is assuming that a .drv suffix always means it's a derivation, and for some reason you've got something else with a .drv suffix <errous>I "finished" reading HTDP (didn't finish the exercises), and I think I now know enough to read the GUIX MANUAL. <ulfvonbelow>somenickname: are you on the same guix commit you were on for the previous system generation? <ulfvonbelow>if not, it could be that you landed on a weird commit by chance <ulfvonbelow>you could also try looking at the contents of /gnu/store/jbq5x8ad0xkr131cf10hhlyh8cfbq0hh-switch-to-system.scm.drv <somenickname>also i don't know why it shows those two generations at the exact same timestamp <zamfofex>user363627: No, Scala is difficult to bootstrap from source. <user363627>zamfofex: is there a way to use its nix derivation instead? Or is that not possible between nix and guix? I'm new to guix, so thus may be obvious to some. <zamfofex>I don’t think it’s possible. But you can install Nix on Guix System if you’d like. <ulfvonbelow>somenickname: I dunno what to tell ya. Maybe try reconfiguring again? <somenickname>ulfvonbelow: Doesn't work. I always get this. Maybe I need to change the config again for a different hash or guix pull again. Will test later <ulfvonbelow>I'd say try testing again with the changes to the configuration reverted just to rule that out <mirai>efraim: does core-updates “make” succeed for you? <efraim>mirai: it does. I'll clean and run again, to make sure <mirai>I can't get it working here, distclean'd for the second time to be sure <efraim>the nuclear option which will reset your checkout to a squeaky clean slate is 'git clean -dfx'. If you do it make sure you've committed any changes you've made <efraim>I made it through bootstrap and configure, now it's making the documentation <apteryx>I forgot how to do this in emacs: escape a newline in a string (it was complete muscle memory, not useful on a new keyboard) :-) <apteryx>quoted-insert, "useful to insert control characters" <nckx>Dit it also delete the part about layer 2? <apteryx>that's probably pebcak on my part, but the behavior remains <mirai>efraim: ok, looks like I have some garbage in this worktree <mirai>as vanilla core-updates built fine <mirai>for some reason I had to nuke the worktree (aka a clean dxf) <mirai>looks like bootstrap wasn't working with a non-pristine tree <euouae>nckx: When I built guix I got the version strings correct <euouae>without any changes to master. Maybe this is an issue on the build server? <nckx>The servers use the same build environment as anyone else. <euouae>./bootstrap && ./configure --localstatedir=/var && make <euouae>I'm wondering if boostrap is ran? <euouae>There's a comment that the dist-with-updated-version target runs ./bootstrap to get version strings correct for dist in Makefile.am <nckx>…in the build environment? 😛 Yes. Explicitly. <euouae>Did you expect me to get the version strings correct? <nckx>euouae: Outside of the build environment? I didn't think about it, so I didn't have expectations either way, but it's a good data point. <euouae>Yeah I just did `guix shell -D guix git bash` and proceeded with building <euouae>My point is if I can't reproduce it, investigating it is much harder or impossible <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. <euouae>Hm... so you're using guix to build guix? <euouae>Whereas I didn't. Am I understanding this correctly? <nckx>The provenance the ‘guix’ ‘package’ is… complicated, but yes. <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 <radio>Can someone take a look at my system declaration? <nckx>radio: I see that you don't have bash anywhere, and dash doesn't provide …/bin/sh. <nckx>So it's not clear where /run/current-system/profile/bin/sh would even come from. <radio>What would be the proper way to put it on the PATH? <nckx>Is ‘dash’ not on your PATH? <nckx>Well… if you don't install a …/bin/sh, there's no …/bin/sh to put on PATH. <nckx>You could create a wrapper package that symlinks sh to dash. <nckx>somenickname: Is /gnu/store/4jlw5kk8wnn3fx5qpwamvjqg0nr1lmr6-upgrade-shepherd-services.scm.drv an empty file? <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>Right. That's a ‘should not happen’ event that happened outside of the ideal Guix model. <nckx>It's not your configuration's fault. <somenickname>It happend because it removed GDM and crashed the system. Well just because I want to remove GDM I don't mean to it instantly :D <radio>nckx: What can I use to create a symlink during the package build process? <somenickname>This resulted in a generation which doesn't list any channels. Isn't this a bug? <nckx>radio: (symlink FILE LINK). <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? <nckx>If your file system isn't totahosed, sure, I kind of assumed you'd tried. <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. <nckx>Guix could do better, but yes. <somenickname>I guess it is just that it does what is told. I am on a running GDM session with Xorg and I say in the config remove that. Well and it just does that. <somenickname>But maybe it should know that it needs to wait for the next reboot <nckx>Just as a data point with which I will do absolutely nothing further: which file system is /gnu/store? <nckx>Well, I thought it did just that, not restart all services, but I don't use GDM and don't know exactly how Guix decides what to restart. <nckx>Mental counter incremented. <errous>Sad to hear that btrfs might be involved. <janneke>why is that sad, have you seen the code? <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. <errous>Right; it's always an in-situ...ation. <nckx>Crash a VM a thousand times or whatever for each file system. <nckx>I probably read too much into your intentions. <somenickname>I don't even know how such a test would work. I need to be on the same commits and also require my guix home config since I was in EXWM in a vterm buffer that ran the command. <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? <jaeme>Specifically ones own local guix channel. <klm`>What's the reason gcc 13 hasn't been packaged yet? Is it too young? (13.2 came out July this year I think) <klm`>Hehe :-) I'm scared to look into it. I was just surprised nobody has had a need for it and I was wondering if I was missing something. <somenickname>Someone using GDM with nouveau drivers? It doesn't work for me. GDM is in an endless loop with creating new sessions and exiting ones. Therefore I only see flashing cursor. <euouae>Did you turn on debugging somenickname <ulfvonbelow>anyone else noticed that our test harness seems to make errors actually harder to track down <ulfvonbelow>like, you look at the log file, see that there was an exception, and there's no backtrace <ulfvonbelow>it's baffling that a testing mechanism would not print a backtrace when there is an exception <euouae>Isn't it easy to include backtrace with those? <ulfvonbelow>yes, so why on earth do things like test-equal only print what the exception was and not its backtrace <euouae>Good question, it's an oversight IMHO