IRC channel logs
2025-04-04.log
back to list of logs
<lechner>ieure / i've got it working, I think. just need the Android udev rules. Why Graphene? <lechner>It's hard to beat Nick's street cred <nomike>I;'m having issues with contributing my first package to guix. <nomike>So I ended up cloning guix from git, running `guix shell -D guix --pure` and within that shell I ran `./configure && make`. I then copied the existing package definition of "joe" in `gnu/packages/text-editors.scm`, named it `jupp`, saved the file, ran `make` again. <nomike>That recompiled text-editors.go. But when I now run `guix package --list-available=jupp` it doesn´t find the package. <vagrantc>otherwise it just uses the guix command fro PATH <vagrantc>nomike: also, if you just copied the package definition, it might still have the name "joe" <nomike>Ah yes. Sure. Thanks, I knew that, but just forgot. Thanks a lot. <nomike>vagrantc, and I adapted the package definition of course. <lechner>Hi, can the udev-rules-service be specified multiple times? <identity>lechner: from skimming the manual (info "(guix) Base Services") it looks like that is the entire point of udev-rules-service <sturm>anyone else find that Icedove's "Date" column doesn't repect the Guix system timezone? <kabouik_>After running Guix on a GPD Pocket 3 and a GPD Mini, and also Guix package manager on a qwerty slider phone, I guess it could only get weirder at this point. <keinflue>Hi everyone, I am trying to set up a GUIX installation without substitutes from a Debian Live system in pre-inst-env. I may be doing something wrong with that, but in the process I noticed multiple packages with seemingly broken tests, in particular the shepherd package. They seem to make wrong assumptions about the priority of EACCESS/ENOENT over <keinflue>EROFS from syscalls. For example the shepherd test case pid-file.sh attempts to delete a file /does-not-exist and catches ENOENT, but not EROFS. If / is mounted read-only (which I guess it should be in the build container), then unlinkat will return EROFS, not ENOENT. I am wondering how these tests succeed normally or whether something is wrong <keinflue>Btw. unlinkat is supposed to return ENOENT in this case (as far as I can tell) according to POSIX, but Linux doesn't do this. Coreutils for example has workarounds implemented for this in rm. There was a fix added to Linux in 3.2, but it seems to have regressed in 3.6. <lechner>Hi, what's a good indicator that someone is using Guix home when both ~/.guix-profile and ~/.guix-home/profile exist? <yelninei>janneke: I managed to reconfigure a very minimal system + childhurd on core-packages-team (+22 commits) but it did not help with the gnulib test failures and bison segfault <yelninei>interestingly in findutils-boot0 the test-symlink test passes but in the final findutils it fails with ENOTDIR and i am confused why <janneke>yelninei: i would suggest we just accept the gnulib test failures for now and disable the failing tests everywhere. bison segfaulting is a lot more serious, do you have any idea what may be causing that, bison wasn't upgraded right? <yelninei>janneke: is there a way i can keep the offloaded build somehow to rerun the thing under gdb? when i add -K it does not offload anymore <janneke>yelninei: what i usually do, is start the (offloading) build, ^C once it started, log into the offload server and: nohup guix build <package>.drv & <janneke>err, to keep the build, with --keep-failed, of course <yelninei>also similar to the gnulib tests the flex/bison that are build during the bootstrap dont have any issues and only the "final" ones are problematic <yelninei>findutil-boot0/bison-boot0 are built with the gcc-bootstap-0 and glibc-bootstrap-0 so i guess it makes sense that these are behaving like before <yelninei>janneke: managed to do the --keep-failed thing with GUIX_DAEMON_SOCKET and an ssh uri which is a bit more convenient (youd need to do the offloading once first to have all the inputs transferred over) <yelninei>janneke: after not stripping the bison that is used for flex the entire backtrace is just 0x00000000 in ?? () and no further info, i guess i have to step through line for line <yelninei>janneke: something with signals and the m4 subprocess ("create_pipe_bidi "at "src/output.c:785"). This tries to "block_fatal_signals()" at "lib/spawn-pipe.c:475" and then the call to "init_fatal_signal_set" at "lib/fatal_signal.c:322" is the last thing before another step causes the crash <janneke>yelninei: can you post this observation in #hurd? there's always a chance that it rings a bell? (possibly "wait" until youpi is present, or send an email to the bug-hurd mailing list?) <xiews>I have many entries for my guix in Grub menu. How could I delete some of them safely? <yelninei>janneke: i think ill send a bug later because it is easier to include more context. I want try something else first but getting to this state takes like half a day of watching progess bars <bjoli>Does the regular installer install uefi if it detects support? I am having to enable legacy boot just to get it started, which has me concerned <Rutherther>bjoli: It should. But you need to boot through uefi, otherwise it cant detect it. So there is something wrong if you had to boot to legacy <bjoli>Rutherther: and the standard image boots with uefi? <bjoli>Nope. Can't get them to show up. I have to enable compatibility mode. Weird. <sneek>nckx, efraim says: your substitute server seems to be down <nckx>efraim: Thanks, it was. The VPS is old and the host is becoming unreliable, but the newer ones are less powerful for the price. I'm not sure what to do. It's up for now. <nckx>lechner: I think if you more precisely define ‘using’ for yourself the answer might present itself. I guess my definition would be (1) are either/both in $PATH at this moment, then they are being ‘used’ (2, maybe) even if ~/.guix-profile is in $PATH, does it contain anything? However, I'd also try to avoid a situation in which I had to sniff out the user's preference in the first place. It can easily change or be more complex. <zilti>When I do a system reconfigure, at the very end, I get `/builder for `/gnu/store/q8b4b7wcg6x2wwmc57ia4rsbcxvprvf4-acl.drv' failed with exit code 1`. Dry run succeeds. Does that ring a bell for anyone? What could it be? <Rutherther>You need to check the error in the log. That dry run succeeds is expected as this is a build error <lechner>nckx / Hi there, I'd like to patch xinit to be more useful, but taking my own version as a template realized that it still said ~/.guix-profile instead of ~/.guix-home/profile! For three years, I was running an old Xorg? Either way, I am not sure both folders should exist and, second, adding both to PATH etc seems an error, especially because the older ~/.guix-profile is listed first https://bpa.st/V2XQ <lechner>As an aside, the variable values shown by 'env' seem to have been set with desperate vigor <lechner>zilti / you have to show us your config file <zilti>lechner: well, it is either that, or have the page down completely because of the scraping AI asshole companies <lechner>zilti / what's the most recent change you made? <zilti>lechner: I added the "groups" block and the "plugdev" line in the user. Removing those changes nothing, though... <lechner>what's the diff to the last working version, please? <lechner>zilti / also, please post the contents of the file that starts with this /gnu/store/56bpv7449q72lgikiks7l04snhx <zilti>lechner: I do think I have found the culprit though, last thing I added before that was "qtwayland". Removing that makes it work. Very bizarre. <PotentialUser-21>Hi Guix. I read, that at some point the free secure network systems group at the TU Munich helped out Guix in the past. Does the contacts still exist? <zilti>lechner: I've put qtwayland back in, and it still works. Very weird. Well, thanks for being my rubber duck, I guess :) <Rutherther>It is not bizarre, acl is probably dependency of qt wayland, and it seems it is broken <zilti>Rutherther: but now, the config works *with* qtwayland. <lechner>glad to hear it. thanks for using guix! <lechner>sometimes all it takes is a little help from your friends <apteryx>hm, make check TESTS=tests/guix-refresh.sh seems to hang for me <apteryx>running 'sh tests/guix-refresh.sh' is OK <apteryx>odd, I ran another test, and now it's happy again <apteryx>ok, guix-refresh.sh appears to be network dependent, can hang on 'guix refresh --list-updaters' apparently <apteryx>lilyp: './pre-inst-env guix refresh -u -m etc/teams/gnome/gnome-manifest.scm --target-version=46' appears to have its use <apteryx>it's a ping slow poking every GNOME package for missing releases, but it works. Currently we can't tell it to not downgrade, so care must be taken to drop these hunks after. <nckx>PotentialUser-21: Do you have any more information? (I searched my mailbox for ‘tum.de’ just in case but no luck.) <nckx>You might have more luck with sending a mail to help-guix@. The odds that the right people are around just now to see your message here are small. <nckx>lechner: You know me & Guix Home, total strangers, but I always ass-u-me'd that using it *alongside* ‘guix package’ was fully supported. Is it not? If it is, both being in PATH would be normal, and one does not obsolete the other. Or I misunderstand your point. <ieure>Anyone run Guix on a ThinkPad T14s with ARM CPU? <ieure>Seems like it's mostly workable on other Linuxen, Ubuntu seems to have the best support for it. <ieure>There's one on local CL for... not exactly cheap, but cheap enough to make me consider it. <lechner>sneek / later tell nckx / Should people choose between Guix Home and 'guix package'? <Rutherther>ieure: I have gen4 and I think it's fine. I shared a stacktrace that I have been getting from spontaneous crashes that I get for past ~two weeks (you've seen it), but that could be completely unrelated to the general support <lechner>Hi, how may I use a scheme-file object in a string-append, i.e. how may I convert the file object to a string, please? <Rutherther>(of course the builtin gpu and wifi don't support free firmware) <ieure>Rutherther, I'm specifically asking about the Snapdragon ARM model, is that what you have? <ieure>lechner, $600 asking price, I'd attempt a haggle. <ieure>Rutherther, Ah, nope. I have an AMD ThinkPad, it works pretty good. <lechner>i guess that is a good deal. it's a brand new device <ieure>lechner, Yes. Gen 6 is the current model, and it's like new. It's ~$1700 new. <lechner>yeah i saw. seems expensive for something that can get stolen easily or that you might sit on. <lechner>it's a personal bias though. i repurpose mostly old hardware <Rutherther>lechner: it depends where you're using the scheme-file, usually by ungexping it (have to be in a gexp for that to work of course) <ieure>lechner, It's less the money -- I'm fortunate enough to be making tech-startup salary -- but I don't want to spend it on something that won't run Guix. <Rutherther>lechner: by making a gexp that ungexps the individual elements <lechner>ieure / just make sure the person didn't work on it (like open the case) <lechner>Rutherther / okay, thanks! I'll do that too <Rutherther>(it then makes a computed-file from the gexp builder) <ieure>lechner, I think they upgraded the SSD. I'm not worried about that, ThinkPads are very easy to work on. I've torn down and rebuilt several. <ieure>Well, it's sold as working, so I don't think that's likely. <lechner>how is the performance of those chips now (and how is power consumption) <lechner>ieure / at that price it could be stolen. make sure you boot without network the first time and disable computrace etc. what's the os? <lechner>I'm not sure I could buy anything from Qualcomm <ieure>lechner, Hmmm, possibly. I think it's more likely they bought it, found it couldn't run the software they wanted, and are dumping. <ieure>lechner, It's running Windows of some sort. Not sure Computrace works on ARM, and it only works on Windows (it has some wacky DLL injection thing). <ieure>I mean, any corpo CPU is not great these days. <ieure>I would like RISC-V to succeed, hardware isn't there yet. <lechner>Well, by converting a Winblows computer to Linux you'd be doing a good deed <ieure>lechner, Battery life according to notebookcheck is ~22 hours. But with modern devices, a lot of that is software, and Guix does worse than Debian on this, in my experience. <ieure>Specifically, my Guix laptops all drain the battery dead flat if they suspend for 2-3 days. <ieure>Debian also drains battery when sleeping, but much less. <Rutherther>ACTION wondering how can different distribution have effect battery usage during sleep <ieure>Rutherther, For one, Debian can hibernate after being in suspend for a while. I've never gotten hibernate to work in Guix. <ieure>There are several software/kernel things that have to be set up right for sleep to work well, I think Debian just has a larger userbase so tends to have more eyes / louder users about that kind of thing. <ieure>Guix does a lot better about this if you use tlp and powertop services. I contributed the powertop-service-type. <ieure>Rutherther, BTW, I saw you mentioned my autofs service in the config I shared for the no unmount on reboot bug. You don't have to remove that stuff, it mounts dynamically when you access the path, so you not being able to reach my NFS server won't cause problems. <Rutherther>ieure: I know how it works. But I would like to replicte your exact fs setup, if I won't have a fs that you can mount, I can never know if that is the issue <ieure>Rutherther, The problem replicates without using any NFS mounts. <ieure>I tried to experiment a bit, but didn't get a handle on what exactly is causing it. I dropped back to a very minimal config and it changed to fscking only after I `sudo guix system reconfigure'd. My full config always fscks on reboot. <ieure>Annoying, since it makes the Guix boot even slower. <Rutherther>could you also clarify what you exactly see after booting? you see the whole progress bar of fsck, is that right? <ieure>Rutherther, Yes, it takes ~2 minutes to fsck the root filesystem. I could take a photograph or video of the screen and send it, if you like. <ieure>I get the fsck "recovering journal" message and a whole filesystem fsck with progress bar. <Rutherther>nono, that's not needed at all, I know exactly what you mean by that, I just wanted to make sure. <Rutherther>nono, that's not needed at all, I know exactly what you mean by that, I just wanted to make sure. <ieure>Okay, cool. Happy to if it helps. <Rutherther>yeah, I was getting the same in the VM on older guix commits (and only after reconfigure) <lechner>Hi, what's the command in the Guix REPL again that writes a *-file to the store and returns the resulting path, please? <lechner>it's so weird i have to type ,use (guix) in order to use that <nckx>(when (equal? (module-name (current-module)) '(guix-user)) <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, lechner says: / Should people choose between Guix Home and 'guix package'? <nckx> (use-modules (gnu) (guix))) <nckx>It's what I have in my ~/.guile and it also fixes an unrelated bug where the Guix REPL is missing custom channels. <nckx>lechner: Are you asking my opinion or…? No, they should not be forced to choose. Guix Home should not break ‘guix package’ any more than Guix System does. <lechner>sneek / later ask nckx / What's the use case for 'guix package' alongside Guix Home? Or, in other words, why would someone uptight enough to use Guix Home ever want to install anything via 'guix package'? <Rutherther>I don't think using guix home means the person is uptight enough. Home has services, guix package doesn't have that. So it's perfectly possible there would be a person using guix home just for services, like pipewire, and for installing packages they would use guix package <Rutherther>also, I use both, to first test new stuff with guix package, to know if I will even use it enough in the first place <dariqq>ACTION has papirus-icons installed via 'guix package' to save on inodes <dariqq>Rutherther: Thank you for trying to solve this problem <Rutherther>don't thank just me, it's a group effort, I didn't even know about the problem until someone reported it on Guix matrix and proposed a solution :) <lechner>sneek / later ask nckx / Hi, thanks for the ~/.guile recommendations! Do I also have to load (gnu packages) in order to sidestep Bug#61343