IRC channel logs

<raghavgururajan>Upon TTY, I saw `tlp` binary giving that error, along with other programs. Then when I attempted to login, `login` program throws the same error.

<raghavgururajan>Did a cold reboot and started with previous system generation.

<nckx>And does that one work?

<raghavgururajan>yep

<nckx>IWBN if???from the good system, let's not boot anything else for now :-)???you could reproduce this in a VM created with the latest guix.

<nckx>rekado: What did you have to do to restart goggles-bot?

<raghavgururajan> https://share.raghavgururajan.name/upload/xeG8-whq3UEHsocHNmToPZdI/IMG_20221109_185703.jpg

<raghavgururajan>nckx: ^

<silicius>is there any difference between specifying channel-with-substitutes-available in channels.scm and adding the same substitute server to the guix service in system config?

<nckx>I don't see how they're similar.

<nckx>c-w-s-a holds back the channel HEAD to where the latest substitutes (for Guix only!) are available from the specified server.

<nckx>Adding a server to the guix server just enables substitution from it, assuming you've authorised its key, nothing more.

<nckx>s/server/service/

<nckx>If anything, I think you need both.

<nckx>raghavgururajan: I guess I'll see if I can get those hashes here, and then see if it happens to me. You wouldn't happen to have a ???guix describe??? (or equivalent) and system.scm for the bad system handy?

<nckx>Or guix system describe.

<zimoun>hi!

<nckx>Hey!

<nckx>Heh. A familiar (and still terribly apt) name appears out of context: https://lore.kernel.org/linux-bcachefs/76DQGHJcbeTtk41xRingY4rRWt0ovahY30ltQ9YEnNJxErroN5BftNBBNG5IQ9ym5RyA1lE9vYFguLl3G6A1mHnJ-pf4-LIWjpZjjk26oJI=@protonmail.com/T/#u

<efraim>I wish them luck. I still don't feel capable of reviewing their zfs-root patchset

<lizog>hello guix, may i politely ask if any maintainer would like to have a look at the patch series: https://issues.guix.gnu.org/58617. it would be helpful if we could have up-to-date vulkan packages

<nckx>s/maintainer/one/

<nckx>I'm like efra???im on that one. I don't even know if I can run Vulkan.

<raghavgururajan>nckx: https://paste.sr.ht/~raghavgururajan/8526f97d39e8f47051c522804ca573b45c07b344 | https://git.sr.ht/~raghavgururajan/guix-config/tree/master/item/system/config.scm

<rekado>lizog: the previous https://issues.guix.gnu.org/57297 was merged only to a separate branch

<nckx>lizog: Just out of curiosity, why "-DUSE_ROBIN_HOOD_HASHING=OFF"?

<rekado>but since it broke weston we didn???t merge it to the master branch

<nckx>raghavgururajan: Thankings! To confirm: that's all bad?

<raghavgururajan>Yep!

<nckx>OK. I'll try to reproduce it, but don't wait for me, I don't know what my day will look like.

<rekado>I???m playing around with my stash of injecting plymouth into the boot process; unfortunately tests of evolution-data-server fail, so gdm fails to build, and so gnome-shell fails to build.

<rekado>(I used doc/os-config-lightweight-desktop.texi as a test system)

<lizog>nckx: oops! i'm not the one who actually composed the patch series, just lurking on it hoping to see some progress. i think it's just basically we don't have robinhood hashing packed yet?

<nckx>Ah, OK :)

<abrenon>hey guix

<civodul>o/

<lizog>nckx: mesa has a cpu driver for vulkan, and they have pretty good support even for the latest api. i think we have mesa 22 on core-update?

<nckx>Ah, right, that legendary bump.

<nckx>ACTION is on Ivy Bridge, and read some worrying stuff about it not supporting all of Vulkan, but really has no idea about this stuff. Not being a gam3r will do that to you.

<apteryx>pkill9: about pjproject-jami; since the hash was simply restored to the previous one, with no other changes, the old substitute should be usable? so no need to rebuild?

<nckx>raghavgururajan: I can reproduce this in a VM. That's disconcerting. I'm going to try to whittle it down to a Guix-only (or at least guix+rg-only) reproducer first.

<raghavgururajan>nckx: I see.

<pkill9>apteryx: i don't remember talking about pjproject-jami

<nckx>Yeah :-/

<apteryx>pkill9: ah, you were talking about jami itself

<apteryx>?

<gnucode>(file-exists? 5) -> returns #t

<gnucode>that makes no sense.

<nckx>Should probably be documented, yes.

<nckx>Yeah, the current docs mention only ???file names???.

<tricon>i'm still on ye ol' Sandy Bridge for my home "workstation".

<tricon>pretty sure it was the last gen prior to the Intel ME (correct me if wrong).

<nckx>Yep.

<nckx>Mine's neutered (and I trust it to be dead) but not absent.

<tricon>well that's good. did you neuter it yourself, or did you purchase it that way?

<nckx>Both. I didn't redo it myself just because I didn't trust the seller, but it was a nice bonus.

<tricon>nice. i've been curious about the DIY process.

<nckx>Well, I certainly don't recommend learning on an X230T, but it can be done. ????

<tricon>(looks at eBay) those are cheap now. i wouldn't mind replacing my cheap Lenovo Flex 4 (AMD).

<nckx>I have no idea if it's a good replacement.

<tricon>my main reason would be build quality, not performance. my Lenovo Flex 4 is incredibly brittle.

<nckx>It's a strange beast, and the last of its line, which is why I like it, but it's no sleek consumer fliparound, and more fragile than a non-convertible ThinkPad.

<tricon>there are small cracks in the side just from picking it up by the corner.

<nckx>The quality isn't bad! Just more moving parts & trade-offs.

<tricon>very good to know, thank ya.

<nckx>The only truly weak point is the rubber bits that stick up from the keyboard and keep the rotating screen in place. You'll find a lot of second-hand ones have lost them. But otherwise, ThinkPad.

<raghavgururajan>tricon: What chipset is that?

<raghavgururajan>the workstation one without ME.

<tricon>raghavgururajan: I _think_ it's the i7-2600K. i'll have to double check when i get home as it is currently powered off.

<abrenon>faust45: hi ! I guess it means that it's a slightly different version of the package ?

<faust45>abrenon: but how i can avoid this behaviour?

<abrenon>if that's a new definition of the package, I guess it would mean you can't

<faust45>i have already build /gnu/store/sf67y13f80gcpa9dal9q96h86788nnmh-linux-5.19.11/

<kaelyn>Hi #guix! While the patchset isn't mine, I wanted to ask if there are any blockers to https://issues.guix.gnu.org/55231 being committed? I have been making use of the latest iteration (v4) and find it a useful bit of previously-missing functionality (being able to include out-of-tree modules in an initrd).

<faust45>and it trying to build 5.19.11 again

<abrenon>unless you find the exact definition of the linux-5.19 that was used in your current generation, give a name to that and use this name instead of linux-5.19 if linux-5.19 has indeed moved (I have not checked this hypothesis)

<nckx>There's no way for us to tell you exactly what changed, because that's not a Guix package. We don't have the data.

<nckx>You could ???guix size??? both and diff the output.

<nckx>If you map sf67y13f80gcpa??? back to its corresponding .drv, you won't even have to build the new kernel.

<faust45>i have declare this

<faust45>(define linux-5.19

<faust45>?? (corrupt-linux linux-libre-5.19 "5.19.11"?????????????????????? "0wyrwdqm4dypx2jbb7d8c3b7fl7q5j434d6g9x2v6sw01gwx4m2m"))

<jackhill>what's up with the berlin build farm, it looks like most of the builders are idle?

<nckx>That old song again?

<nckx>I've restarted the POWER nodes.

<nckx>jackhill: Are there x86 jobs that should be running?

<nckx>I don't see anything suspicious there. So just aarch64 as seems to be normal now.

<nckx>I think cuirass-remote-worker needs to be restarted after each berlin reboot (or Cuirass* restart, maybe). Not good.

<jackhill>nckx: maybe not. I think yesterday there were, but I can't find stuff now, although there are missing substitutes for e.g. gdm, mutter, evolution-data-server.

<jackhill>but it looks like those builds have just failed on berlin, so???

<nckx>e-d-s has been reported.

<nckx>By civodul I think.

<jackhill>looks like https://ci.guix.gnu.org/build/1688417/details could be restarted (failed because ENOSPACE)

<nckx>What's stupid is, it's built and present.

<lechner>lilyp nckx: Hi, thanks for your opinions on XDG_RUNTIME_DIR yesterday. I concur. Is this the bug in Home? .guix-home/setup-environment:export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$UID}"

<nckx>IMO yes, but I didn't dig in. Are there new bugs when you remove that? Etc.

<nckx>I want to find out before random work-arounds like <https://issues.guix.gnu.org/59132> start getting put in all over the codebase.

<nckx>ACTION offline.

<nckx>ACTION back on-line to add:

<nckx>lechner: It's not that that line is *wrong*, it's that it forces everyone to use elogind. That's not good! If at all avoidable, that should be avoided. If not, guix hame should properly declare that dependency like everything else, not break random applications in mysterious ways.

<lechner>nckx: i am on it

<lechner>nckx: Can I safely run 'gc' with my encrypted home directory, or will the roots to my home profile be deleted, too? https://issues.guix.gnu.org/issue/58640

<lechner>nckx: Guix HOME sets several of those variables. I'll remove just that one line, but it seems a more comprehensive approach might be needed. https://www.pastery.net/xchhgb/

<lechner>nckx: It's a file in the store, and hence read-only.

<jonsger>hm why do I need to build so many packages locally? a lot of gnome, now GIMP...

<jonsger>sh: line 1: export: write error: No space left on device -> sounds a bit like a build farm problem...

<civodul>jonsger: where do you see that message?

<civodul>bayfront is back, BTW \o/

<unmatched-paren>evening guix!

<tricon>unmatched-paren: \o

<unmatched-paren>tricon: heya!

<nckx>All of the reachable build nodes have 150 GiB free.

<nckx>lechner: <Can I safely run 'gc'> I don't use that kind of encryption so I can't confidently say, or test. Opinions seem to be mixed.

<nckx>Sorry, I know that's not a useful answer.

<lechner>nckx: thanks!

<unmatched-paren>could somebody merge <https://issues.guix.gnu.org/59145> to fix magit?

<nckx>How is it broken?

<unmatched-paren>nckx: tests fail

<unmatched-paren>two of them

<unmatched-paren>there's a commit fixing it that i cherry-picked

<nckx>The ???cherry-pick 36059e0??? sounds a bit suspicious.

<unmatched-paren>how so?

<nckx>(That's the version in Guix.)

<nckx>3.3.0-0.36059e0, and no tests fail.

<unmatched-paren>oh

<unmatched-paren>it's been updated independently since i submitted that patch, i see

<nckx>I see this bug is slightly older. Shame.

<nckx>Yes.

<nckx>Sorry.

<unmatched-paren>updating to a commit doesn't seem like an ideal solution, but okay :)

<nckx>I'm not going to get involved :)

<jonsger>civodul: https://ci.guix.gnu.org/build/1688417/details

<jonsger>in its build log

<civodul>thanks!

<Kolev>How do I install GNOME with Guix on a foreign distro?

<mekeor[m]>when editing your system.scm with gnu emacs, do you have completion (e.g. with company or corfu)? that'd be awesome!

<pkill9>i think the gnome-desktop pakcage is a metapackage containing everything required for the guix system gnome desjtop service, however you'll probably have to integrate it with your distro manually sonehow Kolev

<Kolev>pkill9: That sounds like a nightmare.

<pkill9>it depends how many other services gnome uses probably

<Kolev>pkill9: I want to get GNOME 4x on Trisquel.

<pkill9>it might be as simple as adding an xsession link from your foreign disteo's xsession dorectory to the gnome-desktop packagr

<pkill9>but yeh probably more convoluted than that

<mekeor[m]>hmm. i'm trying to install guix system but run into "file system with label ... not found" although that file system exists: https://paste.rs/Iil

<nckx>What's your operating-system?

<mekeor[m]> https://paste.rs/lsa.scm

<mekeor[m]>nckx: ^ ;)

<nckx>Strange.

<mekeor[m]>hm, i'm gonna try umount and closing all partitions, then remount etc

<nckx>An equivalent notation is (device (string-append "/dev/mapper/" decrypted-root-label)), but I don't immediately see what's wrong.

<mekeor[m]>i did "sudo swapoff /mnt/swap" and then i applied the change you suggested, nckx. now it seems to work :)

<nckx>The word ???suggestion??? is a bit strong, but I'm glad it worked.

<nckx>ACTION ??? ????????

<mekeor[m]>sorry, i meant to say "your command", sir

<nckx>Ah! Much better.

<nckx>I never suggest things, that makes me responsible when they end up exploding.

<nckx>Night!

<mekeor[m]>night :)

<lechner>good night

<mekeor[m]>is it possible to "install" a service (via system declaration), but having it turned off by default? so that it needs to be run manually, if needed?

<antipode>I don't think there is currently a way of telling shepherd to initially have a service be 'disabled' instead of 'enabled' (at least with how shepherd is used in Guix).

<antipode>(I'm assuming with "run manually" you mean "manually run herd start whatever / herd enable whatever".)

<mekeor[m]>antipode: i see. maybe i could write a simple service which turns off the other service...

<mekeor[m]>antipode: yes

<antipode>I think it would be simpler to support that directly instead of via an intermediate service, though it may require an initial time investment to modify Guix and/or Shepherd appropriately.

IRC channel logs

2022-11-09.log