IRC channel logs

<Mystified1234>I tried installing a couple of apps, but it was stating I need to make changes first and use "guix pull -u" but when using taht command with the package name eithere before or after the "-u", the command failed

<vivien>Mystified1234, you need to run guix pull -u on its own first

<vivien>Then, run guix install <package>

<vivien>Mmh I see no -u option

<Mystified1234>vagrantc: Thanks for the recommendation, untill I get comfortable with new commands, I think it would be best just to a fresh install, I have the Iso ready to go.

<vivien>So just guix pull

<Mystified1234>vivien: Yes tried that, no luck

<vivien>You can’t run "guix pull"?

<Mystified1234>i learnt that one :(

<Mystified1234>I'll finish my update on my daily driver then retry the install. Then install iceweasel & konversation. It's shame theres no plasma. Tried mate, not much of fan of that so I'll install xfce.

<Mystified1234>then once I have a browser I can then access the manuals

<vivien>You can with "info"

<Mystified1234>my daily driver has a large update in progress 289 pkgs still at 30's i'll come back in inabout 2hrs

<vivien>"info guix"

<Mystified1234>thanks

<brettgilio>Congrats on 1.4.0 you all

<vagrantc>civodul: well, guix system describe after installing from 1.4.0 .iso image still shows in channels: guix: repository URL: /home/ludo/src/guix/+version-1.4.0

<vagrantc>and now, i have some virtual machines to play with testing upgrading guile-ssh to 0.16.0 ...

<mbakke>whoops, I accidentally pushed two commits that I was planning to send to guix-patches

<vagrantc>ACTION wonders how many long-lost guix TODO items are on vagrantc's back-burner

<mbakke>namely, the SeaBIOS version string change and unbundling from QEMU

<mbakke>also wanted to change the displayed SeaBIOS version to (version 1.16.0 (GNU Guix)) instead of (version 1.16.0/GNU Guix) and ask for community feedback, but meh :-)

<mbakke>ACTION starts hacking on unbundling iPXE instead

<vagrantc>mbakke: should they be reverted?

<mbakke>vagrantc: dunno, they pass my own quality standards, but happy to take a post-merge review

<mbakke>ACTION frantically runs a system test to be sure they still work

<mbakke>I'm not sure if QEMU user-mode emulation use anything from --firmwarepath, but it probably does not hurt

<vagrantc>seems unlikely that the user-mode emulation would use firmware...

<mbakke>:-)

<mbakke>also, it's weird to add a native-input that is not actually used during the build, but it makes debugging firmware-related tests much nicer and you have to dig pretty far into the test suite to learn that fact :P

<mbakke>I learned a lot from debians packaging of seabios and QEMU, but I don't understand how Debian deals with the QEMU test failures that occur from purging firmware

<vagrantc>despite having been a packager in debian in the distant past ... it has been over a decade and have nearly no clue what it looks like lately :)

<vagrantc>er, a packager of qemu in debian...

<mbakke>see https://salsa.debian.org/qemu-team/qemu/-/tree/master/debian if you want to relive some memories :-)

<lechner>rekado / hi, have you run Mumi inside the repo recently? For ./pre-inst-env scripts/mumi fetch I get worker error: (system-error open-file ~A: ~S (No such file or directory /usr/local/var/mumi/data/spool/index.db.realtime) (2))

<mbakke>lechner: is /usr/local/var/mumi correct?

<apteryx>lechner: I bet it wants --localstatedir=/var

<apteryx>(at configure time)

<apteryx>like guix does

<lechner>it isn't, but ./pre-inst-env should provide overrides via this mechanism, i think https://git.elephly.net/gitweb.cgi?p=software/mumi.git;a=blob;f=mumi/config.scm.in;h=ed9330a03cc699cbe5614956cbc4ff67afddad3a;hb=HEAD#l64

<lechner>the repo even has ./etc and ./asset subfolders

<lechner>rekado / after touching the missing files index.db.realtime and index.archive.realtime, I get worker error: (numerical-overflow / Numerical overflow #f #f)

<singpolyma>Can I make hg-fetch preserve the .hg directory for use by eg setuptools-scm ?

<omlet[m]><Guest30> "nckx: just for clarity, #59410..." <- The create is AwesomeAdam54321:

<omlet[m]><Guest30> "omlet: if you're still here..." <- The path not is my, but i obly help

<omlet[m]>s/obly/only/

<psycotica0>Hello folks! I'm running into a strange issue when trying to build this fork from git. I've managed to make a distilled version of my problem.

<psycotica0>When I run `guix build -f solo.scm` where solo.scm contains https://pastebin.com/raw/Fedtzvk2 it fails to build because it can't resolve github.com.

<psycotica0>The full log I've pasted here: https://pastebin.com/Pe4ixa5m

<psycotica0>Looking around a bit it seemed like a similar error can occur when something inside the build container is trying to access the network, but I'm not sure why that would be happening in this case. Am I just doing something dumb?

<drakonis>guix spent a good amount of time at lobsters' frontpage

<drakonis>so it got a decent number of eyeballs

<drakonis>probably

<psycotica028>BTW, people should feel free to answer while I'm sleeping, and I'll check the log in the morning.

<psycotica028>Further details, in case someone wonders, I do have /etc/services, it is world-readable, and `sudo -u guixbuilder01 cat /etc/services` works

<psycotica028>And changing the URI to include a manual port didn't appear to make any difference. I mention this because I've seen other issues that appeared to be that, but seem irrelevant to my issue

<acrow>What is better? quasselclient or erc-tls? Can I use both? Should I? Hmmm...

<Noisytoot>acrow: ERC has no SASL support, Quassel does. Why those two options specifically?

<lechner>acrow / outside Emacs, I have used Weechat; inside, Circe

<jts>Hey y'all. I'm running into an issue on my Guix install where sound doesn't seem to work for native applications. It works fine for stuff installed with Flatpak, oddly. Anyone know where I might look to see what's going on? I'm using gnome with the default config except I've enabled Wayland support

<AwesomeAdam54321>jts: Are you using pulseaudio or pipewire? Can you check if the daemon is running?

<acrow>Noisytoot: quassel is nice and guix provides a service for it, nice! But, aside from connections from a mobile client (which I don't need) I can get equivalent value just using screen with emacs. So far, so good...

<acrow>id

<lechner>jts / Hi, i would install alsa-utils and examine the settings with alsamixer. flatpak probably uses ALSA directly. then i would look into the sound daemons like AwesomeAdam54321 suggested

<Fare>I'm trying to install guix under nixos so they can share the same crypt lvm. This requires editing the hell out of guix-install.sh every time it fails after a partial attempt. In the end, I have a weird bug wherein guix dies during guile initialization: it loads srfi/srfi-9, which segfaults before it loads system/base/ck (from guile). Such low-level error just should not occur. I wonder if it's related to the guix tarball containing

<Fare>*both* guile 3.0.7 and guile 3.0.8. The 3.0.8 libraries are being used says strace. I'm not sure which version of guile guix was originally compiled against.

<jts>lechner: AwesomeAdam54321: alsamixer shows pulse; would `herd status` show the daemons?

<acrow>Noisytoot: I don't know what SASL offers that erc-tls does not; I'm curious what you think. Why those two... well, I was just shaking things up and saw that there was a quassel service already available to test out.

<Noisytoot>acrow: SASL is a way of authenticating to your NickServ account before anything else happens (such as joining channels): https://libera.chat/guides/sasl

<acrow>At the end of the day the consistency of emacs everything is very compelling for me. Once in a while I have to remind myself of this.

<acrow>Noisytoot: Yes, I think erc-tls is a specific SASL method. Correct me if I'm wrong.

<acrow>Noisytoot: Errr, TLS.

<lechner>jts / herd does not show it for me. I have to look with 'ps aux' but you are probably using pulse

<lechner>acrow / SASL was invented by a mailserver called Cyrus and is now used everywhere. It's one of the two common ways to connect to IRC. (The other is CertFP.) SASL is a complicated little thing, but it's good to have

<Noisytoot>s/connect to IRC/authenticate to IRC services/

<acrow>lechner: Thanks, I didn't know that.

<Noisytoot>acrow: TLS is the protocol used to encrypt your connection to the IRC server, nothing to do with SASL

<Fare>SASL, the 1972 language developed at St Andrews?

<acrow>Noisytoot: Yeah, I'm also looking into it again. What I would like to know is what value SASL provides beyond the security that TLS, I believe, also provides? In a prior life I think that I used to leverage SASL through kerberos and that also might work here, but I may be mistaken. Might be interesting to try though. Not that I'm dissing quassel; just exploring/discerning options.

<acrow>Fare: Interesting that SASL, the language, influenced modern Haskell.

<acrow>Just perusing the guix 1.4.0 riches -- has anyone played with zile-on-guile? I have not but it does sound intriguing.

<ulfvonbelow>I'm having issues with my laptop not suspending when the lid is closed and there is no external power

<sneek>ulfvonbelow, you have 1 message!

<sneek>ulfvonbelow, nckhexen says: Without chea^Wchecking… I'm going to go with 4, and nice try, trickster. ☺

<ulfvonbelow>it runs xlock just fine, but never suspends. Bad for battery, doncha know

<ulfvonbelow>I know this because when I manually suspend it, the power light slowly blinks, and when I close the lid, it stays on

<ulfvonbelow>elogind includes messages in /var/log/messages acknowledging both the lid close and the lid open

<Gooberpatrol66>maybe elogind-service-type needs to be changed

<jts>update on the sound issue: the problem appears to be related exclusively to a non-GNU package so I will seek support from its packagers. or just deal with it; i don't need it very often and sound is a tertiary concern

<kitty1>Yo, hows it goin yall?

<AwesomeAdam54321>kitty1: Something strange happened to me yesterday

<kitty1>AwesomeAdam54321: What happened?

<rekado>lechner: you are not supposed to touch the files; that just creates empty files that are read as garbage.

<AwesomeAdam54321>I wanted to package a game, but the package got stuck in a circular import loop and reported a confusing error

<AwesomeAdam54321>On the bright side, I found out that webrtc-audio-processing has a new release and needs to be updated

<kitty1>AwesomeAdam54321: If your not careful that error can lead to sentience and the whole guix system will be threatened! /s

<kitty1>that reminds me I've had like two different things I've really been wanting to try to package but my probably unmanaged adhd brain just be like nop lmao

<rekado>lechner: see mumi/config.scm for default locations and how to override them

<SUPERB[m]>Is it available to migrate the desktop to kde plasme?

<SUPERB[m]>s/the desktop//

<SUPERB[m]>s/the desktop//, s/plasme/plasma /

<AwesomeAdam54321>SUPERB[m]: Not yet, but lots of KDE packages were recently upstreamed: https://issues.guix.gnu.org/57608

<civodul>Hello Guix!

<vagrantc>ACTION waves

<vagrantc>civodul: regarding testing updated guile-ssh by guix copy ... do the guix-daemon on both systems need to be running a guix daemon built with guile-ssh 0.16.0 ? ... i pushed a wip-guile-ssh-0.16 branch by it fails to build guix.

<vagrantc>FAIL: tests/guix-package.sh

<itd>(It would be nice to get the cuirass online manual back; the link on https://guix.gnu.org/cuirass/ points to a 404.)

<vagrantc>civodul: oh, apaprently without the guile-ssh updates it fails too

<AwesomeAdam54321>kitty1: You probably shouldn't tell me what those 2 are, or else I'd probably try to package them

<kitty1>AwesomeAdam54321: mostly been eyeing packaging kons-9, don't remember what else right now because my brain is fried from a long day of chaos lmao I need to like, beyond getting some things in my life a bit more in control, definitely need to start practicing packaging things more, because right now anything non-trivial is kinda scaring me off lmao

<kitty1>well

<kitty1>actually not really scaring me off more my mental state not being good, but I digress

<civodul>itd: oops

<civodul>vagrantc: oh

<vagrantc>civodul: followed up to the thread from november about it :/

<civodul>vagrantc: right, i'll take a look!

<civodul>it's weird that it makes tests/packages.scm fail

<vagrantc>soemthing else caused the failure, as i tried on a recent commit from master with the same failure

<civodul>now i have a to catch up on everything i postponed because i had a Good Excuse

<civodul>that's gonna be hard

<civodul>oh

<vagrantc>presuming i'm not botching the process in some other way

<civodul>ACTION tries

<civodul>BTW https://packages.debian.org/search?keywords=guix still says "rc2", how come? :-)

<vagrantc>and it's test/guix-package.sh ... so the log is a but obtuse

<vagrantc>civodul: because of debian's incoming server crashing for a couple days ... nothing new came in on the weekend

<vagrantc> https://buildd.debian.org/status/package.php?p=guix but it is in process :)

<jonsger>civodul: what is the reason that HEAD on version-1.4.0 "gnu: guix: Update to 1.4.0." not the tagged one?

<vagrantc>civodul: i actually uploaded sunday night ... but the infrastructure problems meant it didn't land till mid-day today (UTC-8)

<vagrantc>jonsger: chicken and egg problem

<civodul>vagrantc: glad we're not the only ones to have infrastructure problems :-)

<vagrantc>though honestly, i think guix should "lie" and tag the commit that releases guix

<civodul>jonsger: it would be self-referential, wouldn't it? :-)

<vagrantc>e.g. update guix to the new version, and then tag it with the same version mentioned int he commit

<jonsger>civodul: so you've built the images from the commit one before (the tagged one)

<vagrantc>the images are built with the tagged version, which means it has the older version of guix ...

<vagrantc>it doesn't actually use the tag for the guix version, it just is a commit with a version ...

<vagrantc>maybe i should rebase wip-guile-ssh-0.16 on 1.4.0 just to see that it still works...

<civodul>vagrantc: i'll push a fix shortly for tests/guix-package.sh

<civodul>it's definitely not related to guile-ssh

<vagrantc>civodul: thanks! :)

<vagrantc>then i can rebase against that and hopefully test it :)

<vagrantc>ACTION -> Zzz...

<mekeor[m]>civodul: i don't see any reason why it shouldn't be "self referential"

<mekeor[m]>so, when you boot a 1.4 installation image, does guix --version give 1.4?

<civodul>mekeor[m]: what i mean is that the "tree" a commit points to cannot contain the ID of that commit

<mekeor[m]>ah, i see :)

<nckx>We'll brute-force the sha1 for the next release.

<neox>Hi there, how can I tell my compiler (gcc-toolchain) how to find lib isl ? (I installed gcc-toolchain and isl in my profile)

<AwesomeAdam54321>neox: You can use the -l option. For example, gcc `-lisl foo.c`

<neox>AwesomeAdam54321, lol, not what I mean x)

<neox>I mean in the context of Guix

<neox>I did use -l, but seems isl is not in lib path

<neox>What I have done so far is to put `export LIBRARY_PATH="$(gcc -print-search-dirs | grep bib | cut -d = -f 2):LIBRARY_PATH"` in my bashrc

<neox>And it does not work for isl

<neox>(It does work to find glibc etc)

<lechner>neox / i'm not sure what Guix does with the environment variables, but you may have a relatively easier time when relying on pkg-config files. If present, they contain the entire path

<rekado>neox: Guix sets required variables in the generated etc/profile file in your Guix profile’s directory

<neox>lechner: oh right, I have to check that

<wilcze>hello, what does guix use git for? Is it necessary? It's super slow

<lechner>wilcze / our package definitions are in a giant monorepo. it also contains the code for our package manager and the rest of the OS

<lechner>i also find it slow but have not found a suitable replacement

<nckx>Git?

<lechner>nckx / Hi, I may send this to the pkg-config mailing list. Do you have any thoughts? Thanks! https://paste.debian.net/1264737/

<wilcze>lechner: isn't this a problem solved somehow by other distros?

<wilcze>alpine package manager is mind blowingly fast

<lechner>wilcze / for better or for worse, we are unlike any other distro

<lechner>what do you know about Guix?

<nckx>lechner: Probably a long shot, but no harm in asking, I guess. This won't magically fix upstreams: they have to actually *use* ${prefix}, not just blindly generate prefix=/foo/bar includedir=/foo/bar/include to silence it.

<wilcze>lechner: not much, it would be nice an overview page on how things work behind the scenes.

<wilcze>the reference manual just seems to give you instructions on how to do things

<lechner>wilcze / have you been using Linux for a while?

<wilcze>yes

<lechner>what if you, as a user, could install any software you like (and any version thereof) without superuser approval? your installations would co-exist peacefully with all other users

<wilcze>that's nice, but how does guix achieve these kind of things at a techinal level?

<lechner>for that you have to drink the secret cool aid. you must come back next week

<lechner>this is yoda

<devmsv>apteryx: Did you finally installed Guix System on your raspberry pi?

<lechner>wilcze / equally important, your programs defined their own prerequisites. they never change for the lifetime of that installation. there are no more naked shared library upgrades, no symbol mismatches, and no crashes

<lechner>wilcze / finally, you can transfer one installation to new equipment by copying a single file. it takes three minutes and works every time

<AwesomeAdam54321>wilcze: The guix manual and blog posts are very useful for delving into the technical details

<lechner>wilcze / we also have 'guix deploy' mechanism that will make an entire class of sysadmin tools such as Ansible obsolete. personally, i think it's magical but your mileage may vary.

<wilcze>thanks lechner, AwesomeAdam54321. Maybe the blog posts, I want an overview, I don't want to delve into the manual.

<lechner>wilcze / please do not despair. we will walk you though if you are interested, but it took me half a year, and I am still learning.

<lechner>wilcze / i spent decades with another well-known distro and had to unlearn a lot

<apteryx>devmsv: eh! I was still trying to do so on a ts-7970, haven't yet tried Guix System on rpi, but I'll test at least the bootloader and then a kernel made with guix today

<lechner>Here is another great talk from A. Tropin. Such a genius! https://www.youtube.com/watch?v=7t301joOHlE

<lechner>nckx / thank you for your comments. we'll address the complexities if someone replies. it's the first message on that list in over a year https://lists.freedesktop.org/archives/pkg-config/2022-December/001116.html

<apteryx>my *Geiser Guile REPL* is still borked in Emacs; it seems it doesn't see the prompt anymore

<apteryx>it's annoying

<apteryx>ah, "etc/teams.scm.in" is in the core team; the new 'get-maintainer' command seems to work!

<civodul>jas4711[m]: just replied re guile-gnutls/Gnulib; i hope it makes sense and doesn't look like gratuitous Gnulib bashing (no pun intended) :-)

<lechner>nckx / tollef responded positively; now we have to tell them what we really want

<rekado>fwiw the manual does explain how things work at a technical level

<rekado>don’t fear the manual

<lechner>nckx / actually, maybe he didn't. too many negatives

<civodul>"do not fear the manual", that could be a motto

<civodul>"i'm here to help you, trust me" -- the manual

<apteryx>I worry when I hear "here to help, trust me" in the same sentence ^^

<itd>ACTION goes looking for the manual

<apteryx>if someone is keen on trying patman to keep track of your patches submission and git send-email flags, you might want to look at #60218

<apteryx>the tool is documented in info '(u-boot) Patman patch manager' (from the u-boot-documentation package from #60145) or patman -H

<apteryx>it seems helpeful, particularly to produce the right --cc directive (it uses our etc/teams.scm script!)

<efraim>unofficial guix riscv64-linux install binary here: https://flashner.co.il/~efraim/guix-binary.riscv64-linux.1.4.0.tar.xz, with accompanying .sig

<apteryx>efraim: cool!

<efraim>how much of seabios is supposed to be used on non-x86 machines?

<sepi>Is it true that in order to have mysql as a dependency of my service (I want it to be running whenever my service is running) I need to extend it in my service?

<lechner>Hi, the hash in the name of a store item relates solely to its prerequisites and not to the files located in that folder, right? In other words, the same store item might contain different files on different machines, but would then be considered not reproducible. Is that correct? Thanks!

<apteryx>master fails to build, when linking the guix-daemon binary; did someone else encounter that? https://paste.debian.net/1264749/

<civodul>apteryx: nope, works for me!

<AwesomeAdam54321>lechner: Yes, if there's a reproducibility bug please report it

<civodul>apteryx: maybe you pulled in a newer gcc-toolchain or something in your environment?

<lechner>AwesomeAdam54321 / thanks!

<civodul>efraim: re riscv, neat!

<lechner>And is there an common terminology for the hash and the package name portion of a store item, or are those descriptors good enough?

<apteryx>civodul: strange! I don't think anything else outside 'guix' changed (from guix pull). I set the environment with 'guix shell -D guix'

<AwesomeAdam54321>lechner: I'm pretty sure derivation hash is the correct term, as hash is generic

<lechner>AwesomeAdam54321 / thanks so much!

<AwesomeAdam54321>lechner: You're welcome :)

<lechner>Which information is generally used to decide that a store item was not reproduced correctly? Is it an aggregate hash over the folder?

<apteryx>"find libstore/ -name '*.o' -delete" appears to have fixed it

<Kabouik>Hey all, how would I proceed if I am trying to run an Appimage that requires launching my web browser to log in an account? At the moment the button doesn't start my browser or open a tab.

<Kabouik>I guess it would most likely use xdg-open under the hood, but then I don't understand why it doesn't open a tab. xdg-open URL does, in CLI.

<AwesomeAdam54321>lechner: The information used comes from derivations, so it's the result of building the derivation that's not reproducible. I think derivations themselves are reproducible

<lechner>AwesomeAdam54321 / Thanks! The latter part of what you wrote reads a little contradictory to me. Would you please be so kind to rephrase it?

<AwesomeAdam54321>lechner: Derivations are low-level build instructions, and are made from the package definitions in Guix. With the same package collection, the derivation made should be the same. It's when you build the derivation by following its instructions that the result might not be reproducible

<aru>Hi, I'm trying out 1.4.0 and on every guix system reconfigure I'm getting "aborting reconfiguration because commit <hash> of channel guix is not a descendant of <another hash>". I can force the reconfiguration with --allow-downgrades, but that doesn't sound like the right way of going about it. Any suggestions?

<AwesomeAdam54321>lechner: If my explanation is confusing, there's a WIP blog post(not yet posted) for the guix website about derivations

<efraim>mbakke: seabios is i686-linux only https://buildd.debian.org/status/package.php?p=seabios

<efraim>(well, x86_64 can build it, but that's not really the point)

<Fare>my new favorite command while juggling with install disks is lsblk

<GNUtoo>efraim: it's used by qemu at least

<GNUtoo>efraim: though I'm unsure if it compiles for other targets than x86

<efraim>GNUtoo: and qemu-minimal, which we use for images

<GNUtoo>so it'd probably be used with qemu-system-i686/qemu-system-x86_64 for instance

<GNUtoo>*at least

<GNUtoo>btw, how many hours do we have to wait for an acknowledgement from debbugs before resending a patch serie?

<AwesomeAdam54321>GNUtoo: I don't know, I would wait 24 hours

<GNUtoo>ok, thanks

<GNUtoo>efraim: SeaBIOS hardcodes i686 flags: -m32 -march=i386 -mregparm=3 -mpreferred-stack-boundary=2 \

<GNUtoo>That's in COMMONCFLAGS in Makefile

<efraim>GNUtoo: I saw that too. I tried working around it but then i also uses x86 assembly

<GNUtoo>So we could try to see what is covered by that and what isn't

<GNUtoo>ok

<GNUtoo>ah ok most of the code is:

<GNUtoo>$(OUT)%.o: %.c $(OUT)autoconf.h

<GNUtoo> @echo " Compile checking $@"

<GNUtoo> $(Q)$(CC) $(CFLAGS32FLAT) -c $< -o $@

<GNUtoo>And we have:

<GNUtoo>CFLAGS32FLAT := $(COMMONCFLAGS) -DMODE16=0 -DMODESEGMENT=0

<GNUtoo>What is your goal? Use SeaBIOS on a ppc64le/riscv64 computer?

<mbakke>efraim: oh, I guess we should cross-compile it then on other arches?

<mbakke>what firmware does QEMU load on other architectures?

<efraim>I'm not actually sure what it uses on other architectures. I haven't looked too closely yet

<GNUtoo>It depends, on ARM I think that it emulates some SBCs so the target somehow provides u-boot I guess

<GNUtoo>*arm 32bit

<GNUtoo>At some point we probably need to add u-boot for qemu32 / qemu64 targets for arm32/64

<GNUtoo>(qemu_arm64_defconfig and qemu_arm_defconfig)

<GNUtoo>ACTION isn't sure of OVMF supported architectures but it could also support more architectures

<GNUtoo>Though I'm unsure how GOP drivers works then

<rekado>aru: how did you obtain version 1.4.0?

<GNUtoo>There are some qemu-riscv64_defconfig in qemu, so I guess that you can simply ship it in the target image

<aru>rekado: I pulled this iso https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso and installed from it

<mbakke>qemu-system-{arm,aarch64} requires an explicit machine type, -ppc loads OpenBIOS, and -ppc64 does not seem to work

<GNUtoo>There is a powernv machine for ppc64le

<GNUtoo>That might be the easiest one

<mbakke>that gives a display, at least; same as -machine virt for ARM

<GNUtoo>Though I guess that somehow the whole boot stack needs to be built and I've then no idea where it should go (in the host filesystem or in the target rootfs)

<mbakke>*the same display

<mbakke>providing a cross-compiled SeaBIOS is probably the simplest solution

<mbakke>ACTION tries

<GNUtoo>mbakke: what are you trying to do btw?

<GNUtoo>because cross-compiling seaBIOS won't make ARM target work for instance

<GNUtoo>but it can make x86 target work on ARM

<lechner>Hi, are store items immutable?

<GNUtoo>lechner: as far as I understand they are supposed to be unmutable

<mbakke>GNUtoo: replace the bundled SeaBIOS with one from Guix

<mbakke>in a way that works on all guix-supported systems

<GNUtoo>ok, so you need to build it on x86 and cross compile for all other host architectures

<mbakke>we could cross-compile even on x86 :P

<mbakke>just for simplicity

<GNUtoo>So on ARM you'd have an i686 SeaBIOS and it's the way it's intended to work

<GNUtoo>That works too

<GNUtoo>If instead you want to support enable booting ARM targets then adding u-boot with the qemu_arm_defconfig and qemu_arm64_defconfig targets is a good idea, this way users will be able to generate arm rootfs that works fine with qemu

<mbakke>getting the same hashes when cross-compiling, that's great

<GNUtoo>Also note that SeaBIOS also has additional software, so for instance it has an option rom and similar stuff

<GNUtoo>So the best option is probably to find the configuration used to build the builtin SeaBIOS

<mbakke>GNUtoo: that's what we do

<GNUtoo>ok nice

<GNUtoo>hmmm, the seabios package should probably be renamed to take into account the target though, like seabios-qemu, seabios-coreboot, seabios-csm

<efraim>mbakke: I'm working on cross compiling seabios to i686-linux from other architectures. need some time to build the cross toolchains though

<GNUtoo>(though that will probably be relevant only if someone adds something like seabios-coreboot)

<apteryx>the u-boot-nintendo-nes-classic-edition package is broken it seems

<apteryx>cbaines: data.qa.guix.gnu.org is useful

<efraim>ACTION is AFK compiling

<cbaines>that's good to hear, what are you looking at in particular apteryx?

<mbakke>efraim: are you also updating the seabios package definition?

<yarl>Hello guix!

<efraim>mbakke: I have a change that might work for cross building but I need to build the toolxhains first

<apteryx>cbaines: looking at https://data.qa.guix.gnu.org/compare/package-derivations?base_commit=d83eef22b25a8717a62ba9d3432b7a8657b7b50b&target_commit=25fe7885d805fabf28eeca6987ecfba5db7df01b&system=x86_64-linux&target=none

<apteryx>moving make-u-boot-package to gexps caused these breakages

<apteryx>so I'm checking each of the broken one locally, fixing them one by one

<efraim> https://bpa.st/GTTBW

<apteryx>cbaines: on the other side, I don't really see the value of patchwork; what is it supposed to help with?

<cbaines>apteryx, at one point, I was thinking Patchwork might be useful for all the functionality it offers

<apteryx>OK. I should read more on it. From its looks, it seems a simple patch submission aggregator.

<apteryx>perhaps its API is where it shines (invisible to my eyes)

<cbaines>the API is used by qa.guix.gnu.org, as it allows listing patch series

<cbaines>lately though, especially now that Mumi has an API, it might be possible to replace the limited usage of Patchwork with Mumi

<apteryx>OK

<cbaines>if you're interested in Patchwork, I'd suggest registering and signing in as that enables more things

<cbaines>apteryx ^

<cbaines>I might need to give you permissions once you've registered though

<yarl>Hello civodul, may I ask you live about issue 59845, if you are available?

<yarl>I just read your comments.

<mbakke>efraim: should the triplet not be 'i686-linux-gnu'?

<mbakke>i already had a cross-compiler for that target (for some reason), but not 'i686-linux'

<apteryx>cbaines: OK, I'll try that

<apteryx>is there a difference between the bl31.elf and bl31.bin from arm-trusted-firmware-rk3399?

<apteryx>after cross-building u-boot by using #:target instead of adding cross-tools to native-inputs, the cross-built arm-trusted-firmware-rk3399 bl31 binary changed extension from bin to elf

<apteryx>odd

<apteryx>file says the bl31.elf is an 'ELF 64-bit LSB executable, ARM aarch64'

<Keman99>Good evening/morning/day to all

<mekeor[m]>hi Keman99 :)

<Kabouik>Do we have a ntp daemon by default in Guix if nothing ntp-related is configured in config.scm?

<Kabouik>I'm still trying to get that "Log in with browser" button to work in the Shadow appimage (https://0x0.st/o5ai.png), and someone told me it might require that I am ntp synced.

<apteryx>looking at u-boot-sifive-unmatched; it seems to be the only u-boot package whose firmware is taken as an input instead of native-input

<apteryx>which should it be?

<sughosha>Hi there, has anyone considered packaging NVIDIA open source kernel modules which was released recently (https://github.com/NVIDIA/open-gpu-kernel-modules)?

<SUPERB[m]><AwesomeAdam54321> "SUPERB: Not yet, but lots of KDE..." <- I don’t care about the packages. Actually I’m kinda uncomfortable with UI of gnome or xfce

<sughosha>Arch Linux has already packaged it (https://github.com/archlinux/svntogit-packages/blob/packages/nvidia-open/trunk/PKGBUILD).

<AwesomeAdam54321>SUPERB[m]: I think now someone just needs to do the KDE integration work, as it hasn't been done yet

<SUPERB[m]>AwesomeAdam54321: Which one of those DM is the cutest?

<SUPERB[m]>Graphically

<AwesomeAdam54321>SUPERB[m]: SDDM, but other people can probably give a better answer. There are SDDM themes

<GNUtoo>ACTION guesses it's subjective

<AwesomeAdam54321>SUPERB[m]: The sugar-light-sddm-theme sounds like a good option for you from the description

<GNUtoo>Objectively gdm has a Guix logo and SDDM doesn't. With SDDM you can probably manage to easily change the background image.

<apteryx>Kabouik: if you use the %desktop-services yes, else no

<AwesomeAdam54321>GNUtoo: Isn't there the guix-simplyblack-sddm-theme that has the logo?

<SUPERB[m]>I meant among Enlightenment, openbox,awesome,i3,ratpoison and Emacs EXWM

<Keman99>I'd like to throw a short question in: Is the process of building a LEMP stack, including the deployment of the PHP files, possible by only invoking guix install and editting configuration files, or do we have to use the Guix system config as an interface for configuration here as well?

<VesselWave>Hello! How to copy file from source of package to output in the Store via g-expression?

<SUPERB[m]><SUPERB[m]> "I meant among Enlightenment..." <- Is it available to install all of those together and shift and try them one by one after booting up?

<Guest30>Keman99 if you're intending for the stack to deploy on the running system, you would typically use the guix system config (as a running process would be defined in a service, not the package itself). Take a look in the `(gnu services web)` module for the available service definitions

<Guest30>VesselWave: you can get a path handle to the output directory of the current build using `(assoc-ref outputs "out")` or `#$outputs:out`. Once you have the handle you can add a phase to perform the copy of the file you want installed

<Keman99>Guest30: Thank you :-)

<Guest30>Keman99: np hope it helps :-)

<SUPERB[m]>s/DM/WM/

<Guest30>VesselWave: also take a look at the phases in the `(guix build gnu-build-system)` module (specifically `install-license-files`)

<Kabouik>Thanks apteryx

<paul_j>Congratulations and thanks for 1.4.0 release!

<Kabouik>Another thing, unrelated, I installed Steam and my library is set to ~/.local/share/Steam (confirmed in the Steam UI), and games do install so the folder should exist… Yet there is no ~/.local/share/Steam on my machine. I cannot find it, with lower or upper case, it's the same. Is Guix tricking Steam and downloading into another folder somehow?

<oriansj>SUPERB[m]: well some people view Desktop and Window Managers as just a distraction from the activities you want to actually do on your machine and opt for things like dwm, EXWM, stumpwm, etc that let you configure it so that you don't even think about it anymore and you just focus on what you want to do.

<apteryx>Kabouik: you may have more luck asking that question in #nonguix; Steam is off topic for this channel as it's not free software

<Guest30>Kabouik: non-free guix packages are typically discouraged on guix project channels, though I believe the answer in your case is that the package is containerized, check the package def

<Guest30>apteryx: whoops, didn't see your reply

<Kabouik>Oh, you're right, I actually know about that but have been off the channels for some weeks and lost good habits. I'll ask there, thanks.

<VesselWave>Guest30: Thanks, I've installed that h file but it seems that it is still cannot be found by next packge

<VesselWave>Guest30: I've fixed it! It is important to specify *directory* in `install-file` as a second argument not path to file. Thank you a lot!

<paul_j>Is the process of updating to 1.4.0 simply a case of 'guix pull' and the system/home reconfigure? I'm running guix pull at the moment, and it is taking an inordinate amount of time compared to normal.

<paul_j>Also nearly no CPU/memory load...

<paul_j>Nor network bottleneck, at my end in any case.

<argv>paul_j: I also just updated mine and it worked quickly. Maybe its pulling in a lot of commits for you? It will depend on when did you run it the last time.

<nckx>paul_j: It's just a git tag, there's no more upgrade than any other week.

<nckx>paul_j: ‘Nearly’, so there is some?

<paul_j>I updated a couple of weeks back (I've been away working). I think this could be the issue as well, but I am surprised I can't see any evidence on the machine load stats.

<paul_j>Perhaps I should stop and restart it...

<nckx>One would expect load, unless it's waiting for network.

<nckx>Might as well try that, yes.

<paul_j>Actually, based on the information, there are 34 commits to update, so not so many.

<paul_j>Now it is showing the progress bar for receiving objects.

<nckx>Odd.

<paul_j>CPU: 99%; Rx/s 5Mb - that's more as I expected!

<paul_j>and now 786 commits to update :)

<nckx>Guix is a bit picky about nothing whatsoever going wrong over the network, although it's got a bit better.

<paul_j>nckx: "Nearly" = as I would expect for idle system- just a couple of %

<nckx>But from a Guix process?

<paul_j>Top process was compute-guix-derivation, so yes - I guess so!

<paul_j>All good now though, based on the output from the 'guix pull' command

<nckx>Yay.

<nckx>Anyway, 1.4.0 is ‘nothing special’ from Guix's perspective, the significance is purely social.

<nckx>(Human testing + human partying + human news cycle :)

<paul_j>Any excuse for a party is great in my books!

<apteryx>I'd like the review of a cross-compilation knowledgeable folk for #60224, if any are interested/available

<apteryx>it touches the way our u-boot packages are built

<apteryx>more specifically in [bug#60224] [PATCH 3/9] gnu: make-uboot-package: Simplify build.

<apteryx>mumi is sluggish

<apteryx>some crash in fibers: 2022-12-20 19:30:37 In procedure accept: Too many open files

<apteryx>rekado: ^ any clue?

<florhizome[m]>I once had a filter option for guix system delete generations to select generations algorithmically, does someone know how that worked?

<florhizome[m]>Do we have further documentation what a pattern can be

<apteryx>the source will be your next stop, if the manual fails short

<apteryx>s/fails/falls/

<attila_lendvai_>i wonder what are the chances of my match-record extension getting merged: https://issues.guix.gnu.org/60225

<attila_lendvai>i wonder what are the chances of my match-record extension getting merged: https://issues.guix.gnu.org/60225

<attila_lendvai>i'll need to adjust my channel accordingly if the chances are low

<attila_lendvai>ACTION is on a very flaky network, but will read the logs

<Guest30>attila_lendvai: out of curiosity, what is the use case for this change?

<efraim>apteryx: I guess I should take a look. regarding u-boot-sifive-unmatched, I'm not sure it makes a difference for firmware re: input vs native-input

<apteryx>it should for cross-compilation purposes, no?

<GNUtoo>it does for cross compilation

<GNUtoo>native-input is what runs on the host during the build like autoconf, automake for instance

<apteryx>right; build machine vs target machine

<apteryx>if the intention is to combine that firmware with the final binary, I guess it makes sense to be an input

<apteryx>otherwise if it was just used at build time, a native-input would be better (though a firmware used at build time seems unlikely)

<SeerLite[m]>Hi Guix! If I were to move my encrypted SSD with Guix installed to a new laptop (so as to replace it but keeping my installation), what would I need to set up on the new one? Would I have to install grub? How would I go about doing it? What steps would I have to do on the live USB? Thanks:)

<nckx>SeerLite[m]: Is this a UEFI machine?

<SeerLite[m]>Yes, both of them

<nckx>All I'd do would be replace ‘grub-efi-bootloader’ with ‘grub-efi-removable-bootloader’, reconfigure, swap the drives, and expect it to boot…

<nckx>No live USB.

<nckx>Assuming I didn't forget anything & that worked, then removing the ‘removable-’ afterwards would be the (optional) last step.

<SeerLite[m]>Wow, amazing. I'll try and let you know if it worked. Thank you!

<florhizome[m]>I want to run a command via guix shell with elevated privileges

<florhizome[m]>specifically I’m trying to run the ventoy install script

<nckx>Mmm, never tried running it with privileges. Must you truly?

<florhizome[m]>Well ventoy needs it

<nckx>No.

<nckx>Not if you're in the ‘disk’ group.

<nckx>Any reason ‘sudo’ doesn't work?

<florhizome[m]>hm

<rlp10>Hi there, how do I run a program with sudo inside guix shell? Currently I'm running guix shell nethogs -- sudo nethogs, but it complains that it can't find nethogs

<nckx>Are you both pranking me :)

<rlp10>I only wish I were good enough at using guix to pull a prank on someone :)

<gabber>nckx: that'd be elaborate

<nckx>guix shell nethogs -- sudo nethogs → a nice display of netty hogs. guix shell $stuff -- sudo ./Ventoy2Disk.sh → works too. What's happening.

<nckx>Did something break?

<florhizome[m]>nckx sudo says it Must be owned by uid 0 and have the setuid bit set

<nckx>ACTION upgrades.

<nckx>florhizome[m]: Are you adding sudo to the shell? Don't.

<rlp10>nckx, so you're saying it works for you

<nckx>Yep.

<nckx>florhizome[m]: You want to use your OS's sudo, not one from the store.

<rlp10>Hmm, I wonder what I'm doing wrong. I'll trying doing a guix pull and see if that helps

<nckx>guix shell foo -- sudo foo should work. guix shell sudo foo -- sudo foo should not.

<nckx>rlp10: My Guix is over a week old, maybe it's me.

<florhizome[m]>ok I was using —pure too

<GNUtoo>The one from the store hasn't the right permissions, when using Guix system, guix installs it somehow with the right permission in the system

<florhizome[m]>It still says it can’t access the device

<GNUtoo>(it installs it at /run/setuid-programs/sudo)

<nckx>(‘Somehow’ == the ‘setuid-programs’ service.)

<GNUtoo>florhizome[m]: what is ventoy?

<gabber>how do i "explicitly allow non-forward updates" as being told by my unhappy `guix pull`?

<florhizome[m]>What is your $stuff nckx

<rlp10>Still doesn't work :(

<nckx>gabber: --allow-downgrades.

<GNUtoo>Ah ventoy is something to write usb disks

<florhizome[m]>multibootable ones

<nckx>GNUtoo: Yes. It can boot ISO files, so you can have a single (often USB) drive full of ISOs.

<nckx>florhizome[m]: guix shell dosfstools exfatprogs exfat-utils -- ./Ventoy2Disk.sh -i /dev/sdc

<GNUtoo>Apparently it boots from .iso files and such but it probably needs the distribution support for that

<nckx>From my bash ^R; ran it this weekend.

<nckx>GNUtoo: Less than you'd think.

<florhizome[m]>ah I don’t have dosfstools in there

<GNUtoo>nckx: can we boot Guix with it?

<nckx>Yes.

<GNUtoo>wow that's impressive

<nckx> https://www.ventoy.net/en/distro_iso/gnu_guix.html

<GNUtoo>ACTION wonders how it works

<nckx>I'll add 1.4.0 now :)

<GNUtoo>For the GRUB part I get how it works, but once the initramfs is booted, how does it find its rootfs?

<nckx>GNUtoo: injects code into the initrd that does dm-mapper magic that is almost transparent to the final OS.

<GNUtoo>oh ok

<nckx>Uh, device-mapper or dm, not dm-mapper :)

<GNUtoo>Ah I see, maybe it uses two initramfs then, a bit like non-fsdg distributions when they want to update the CPU microcode as soon as possible

<nckx>Yeah it's not the shitty loopback.cfg deal you might have been thinking of.

<florhizome[m]>cool is also that we can use guix to create specific iso images

<GNUtoo>If we can boot from .iso in Guix that'd be awesome

<GNUtoo>*.iso files

<nckx>GNUtoo: Yes and no, but this is getting wonky. Microcode ‘initrds’ aren't valid initrds, but yes, you can boot as many (real) initrds at once as you like.

<GNUtoo>It means that we can ship an OS as 1 file bootable by grub

<GNUtoo>(+ probably a file in /etc/grub.d/)

<GNUtoo>Anyway is there a manual installation for ventoy?

<nckx>WDYM?

<GNUtoo>like dd some stuff to a disk image and then it's all setup?

<GNUtoo>In that case it would workaround the sudo issue mentioned earlier

<nckx>That's what the script does, but it's more involved. It makes two partitions that fill the device, so it can't be static.

<GNUtoo>ok

<nckx>(That said, it's an extremely baroque shell script for my taste, yes.)

<GNUtoo>florhizome[m]: sudo su works at least, right?

<gabber>nckx: ah yes, i got confused because that immediately produced another error :) thanks!

<GNUtoo>florhizome[m]: if so the next step is probably to find how to use sudo to launch graphical applications, sudo -E <command> might work

<nckx>If this is about Ventoy, it's not graphical.

<GNUtoo>ok

<gabber>why do i get a "guix pull: error: open-file: No such file or directory:" with a "~/.cache/guix/checkouts/foo/build-aux/build-self.scm" path?

<davidl>Anyone who knows how to start bluetooth service? I get: localhost shepherd[1]: [bluetoothd] D-Bus setup failed: Connection ":1.2247" is not allowed to own the service "org.bluez" due to security policies in the configuration file

<florhizome[m]>The weird part is sudo doesn’t even query me for my pew

<nckx>florhizome[m]: Does ‘sudo ls’ or whatever work?

<nckx>Or indeed ‘sudo nethogs’, if you want to give rlp10 another data point :)

<florhizome[m]>yup

<nckx>Huh.

<nckx>OK, I guess that's less spooky than sudo being broken. Which error message (if any)?

<gabber>florhizome[m]: you are on a guix system?

<rlp10>florhizome[m]: Does sudo nethogs not work for you either?

<florhizome[m]>I think I’ll just log out for a sec

<nckx>florhizome[m]: …from Ventoy, I mean.

<nckx>Okido.

<florhizome[m]>gabber yup

<florhizome[m]>just that it can’t access

<nckx>Sharing the exact error message(s) rather than paraphrasing can reveal unexpected details.

<florhizome[m]>‘Failed to access /dev/sda, maybe root access is needed!’

<GNUtoo>florhizome[m]: are you using guix shell to get a fhs environment?

<florhizome[m]>no I don’t think a container is needed

<nckx>florhizome[m]: See, that's interesting. It's Ventoy's *interpretation* of the error, not what the OS returned.

<nckx>I guess it swallows the real error? ☹

<GNUtoo>because --emulate-fhs requires a container and so AFAIK you need to somehow export /dev/sda inside the container if I remember well

<nckx>OK, it prints that when ‘dd if="$DISK" of=/dev/null bs=1 count=1’ fails. Try running that directly in the guix shell, I guess.

<lechner>cbaines / Hi, may I somehow submit v2 of bug 58658 to CI? You looked at it previously. Thanks!

<lightbulb>lechner: Bug 58658 in guix-patches "[PATCH] gnu: go-golang-org-x-net: Update to 0.1.0." [Normal, Open] https://issues.guix.gnu.org/58658

<nckx>lightbulb: !help

<lightbulb>nckx: Error: "!help" is not a valid command.

<nckx>What's this.

<lechner>nckx / i asked about it yesterday, but you went to bed a few minutes later

<florhizome[m]>it puts out a log.txt but that one says all tests went through

<nckx>Ah, didn't see that indeed.

<lechner>it's all experimental. would such a bot be welcome here?

<nckx>I had a bad experience with a user-provided bot here once, but that was because it was noisily buggy.

<lechner>well, this one works less often than i had hoped

<nckx>So it depends on how noisy it is :)

<nckx>Test 58658

<nckx>Test #58658

<lechner>see

<nckx>Bug 1

<nckx>Bug 56896

<lightbulb>nckx: Bug 56896 in emacs "29.0.50; [PATCH] Make the bookmark fringe icon look like a bookmark" [Wishlist, Open] https://issues.guix.gnu.org/56896

<nckx>Arbitrary bot!

<lechner>it's limnoria presently, but i am not very happy with it

<nckx>To be clear, I'm glad it doesn't parse random numbers or #ones. Good.

<florhizome[m]>nckx dd can’t find /dev/sda hm

<nckx>lechner: I'm not one of those people who runs ’!list’ in the channel regularly and kicks out all the bots :) As long as nobody complains, I don't mind.

<florhizome[m]>but lsblk can

<nckx>…

<lechner>nckx / i was hoping it might, from time to time, draw in a lurker who has seen something or knows something. service level may vary. i would like to find another bot platform

<florhizome[m]>that’s just weird now

<nckx>'s Much as I like sneek, I don't think it's a superior platform to recommend.

<nckx>sneek: bugsnack

<florhizome[m]>but actually I don’t really mind installing those three programs and removing them afterwards

<attila_lendvai>Guest30, it's for situations when the name of a record field clashes with something in the lexical scope

<florhizome[m]>hmmmmmm

<nckx>lechner: Is this Guix's Limnoria?

<nckx>ACTION noticed the ‘build’ date.

<florhizome[m]>i think

<nckx>If so, cool that it works.

<florhizome[m]>can it have any impact that I’m running this from /tmp

<gabber>florhizome[m]: can you access that path manually?

<gabber>i don't think running anything from /tmp has an influence (but i never used that program in question)

<florhizome[m]>yes

<lechner>yes, but wrapped in my own definition so the dynamically loaded Python module (!) can ping debbugs via SOAP http://paste.debian.net/1264781

<lechner>nckx / ^

<florhizome[m]>but the truth is that dd still doesn’t work

<florhizome[m]>so it’s a dd problem

<nckx>gabber: Well, there are (pretty weird) use cases that would be thwarted by 'nodev and similar options, but I wouldn't expect that to trigger here. That said, I don't have a real device to test with sudo.

<florhizome[m]>What package is dd from?

<nckx>coreutiuls

<nckx>But spelt correctly.

<florhizome[m]>It’s a coreutil huh

<nckx>You're saying that ‘sudo dd if=/dev/sda of=/dev/null bs=1 count=1’ doesn't work? Even (or only?) when privileged?

<nckx>Bizarre if so.

<nckx>(Bizarre assuming /dev/sda is otherwise usable, of course.)

<gabber>florhizome[m]: is the volume mounted? does /var/log/messages say anything regarding that volume?

<attila_lendvai>shouldn't there be a stable branch (on whatever name)

<attila_lendvai>shouldn't there be a 'stable' branch (on whatever name), where it is made sure that cuirass builds every package?

<nckx>Sure.

<attila_lendvai>this branch would receive the commits in batches, every once in a while, and by default guix pull would pull from this branch?

<nckx>Yes.

<lechner>florhizome[m] / sorry, i got a bit confused by the interleaved conversations. which error are you seeing from dd? it's a very basic utility

<nckx>(Apart from the last bit, that's a bit controversial. The rest is considered a good plan.)

<nckx>florhizome[m]: Here too, precise error messages are useful.

<attila_lendvai>i too often find myself staring at packages being built locally

<nckx>attila_lendvai: Yes, it's a regular suggestion.

<florhizome[m]>Ok lol

<nckx>But none of the suggesters seem to do more than suggest it, so it hasn't happened yet.

<attila_lendvai>nckx, is it complicated to implement, or does it have downsides, and it still being pondered upon

<florhizome[m]>I had the usb stick uncounted

<gabber>uncounted?

<florhizome[m]>Previously I had fabricated an error that said I should unmount it

<nckx>attila_lendvai: It's just $work. :) ‘Complicated’ in an organisational sense, more like. IMO.

<florhizome[m]>unmounted

<florhizome[m]>yay

<gabber>does it work now?

<lechner>cute typo

<florhizome[m]>it seems!

<nckx>OK, but Ventoy operates on unmounted devices, and dd doesn't care.

<nckx>Do you mean you somehow ‘ejected’ it using some GUI?

<florhizome[m]>maybe

<florhizome[m]>that’s not the same

<nckx>Yeah.

<florhizome[m]>?

<gabber>isn't ejecting it the same as unmounting? is there anything more the kernel can do?

<lechner>ejecting also removes the device node

<nckx>Ding.

<florhizome[m]>dammit

<florhizome[m]>but lsblk could still see it

<nckx>florhizome[m]: Unmounting a device would not make it inaccessible. It just means the file system is not exposed under /.

<nckx>Yeah, that's a bit weird, but maybe that's some fancy modern udev semantic now.

<elevenkb>hello there is there a `gstreamer-vaapi` package for guix?

<florhizome[m]>Ok should I just get the gparted iso

<florhizome[m]>i just want to create a swap partition to be able to hibernate to disk

<lechner>on the USB stick?

<nckx>elevenkb: I don't know what that is, but gst-plugins-bad has libva as an input.

<florhizome[m]>also still asking for a good algorithm to use with guix system delete-generations ..

<florhizome[m]>lechner yes

<florhizome[m]>well no the swap shouldn’t be on the usb drive

<lechner>with nckx and i here you may not need the Gparted ISO

<lechner>sorry, i should not be jumping in

<nckx>lechner: Maybe I misunderstand you (it's an nckx family tradition), but I'd rather florhizome[m] use a tool they feel familiar with than talk them through a more minimal one over IRC. Too lossy. Plus, we are legally liable if they break their system if we don't type everything in ALL CAPS. It's the law.

<yarl>nckx: May I ask you, you have automatic double spacing after sentences? emacs? how?

<nckx>No I just hit the big button two times.

<yarl>nckx: aw :D

<nckx>Sorry.

<lechner>nckx / okay, sorry

<florhizome[m]>lechner what would you suggest?

<nckx>lechner: Please, don't be.

<florhizome[m]>As I need to resize the guix partition I’m on I need to operate from another drive is what I understand

<florhizome[m]>nckx i mean I’m genuinely interested in other options

<lechner>florhizome[m] / i too would prefer if you use tools you know and like. some file systems may support online resizing, but haven't done reductions in a while. it would be a two step process that requires you to be good at math and perhaps know a thing or two about your disk geometry (if people still use that term today)

<florhizome[m]>afaik btrfs-progs resize command doesn’t work on a mounted partition

<florhizome[m]>I studied maths :D

<florhizome[m]>ok but it sounds complicated

<nckx>I agree that you'd have to boot from another root file system, unless you're using a file system that supports on-line shrinking (resize2fs does not; only growing). But that other system doesn't need to be GParted Live. Could be the Guix you already have, or some other thing, to save you time. Etc. But apart from it being a ‘learning experience’, there aren't that many advantages. GParted does all the maths for you with 0.01% of the risk. There are ti

<nckx>mes to be adventurous and times not to be, IMVHO.

<nckx>The maths involved are not the fun kind, just the boring kind :)

<nckx>Arithsmetics.

<lechner>i agree. just remember that your block size is either 512 or 2048 bytes

<nckx>4096…

<lechner>see, i did it again!

<lechner>we'll keep the differential equations for next time

<nckx>lechner is cunningly trying to prove why you should just use a well-tested friendly GUI. I see through the ruse.

<florhizome[m]>yeah I think so too

<florhizome[m]>gparted is just the easiest address for what i need, I’m aware there are alternatives

<lechner>ACTION likes working in a team

<nckx>florhizome[m]: 👍

<lfam>ACTION is also preparing for the resize dance

<florhizome[m]>Indeed I think it would be pretty cool to spin up repo with a CI/CD service on top of guix that builds dedicated isos

<florhizome[m]>I just saw efraim has a definition for a gparted-fluxbox iso

<nckx>I have a ‘Guix Live’ rescue ISO (although I use it to install more than rescue) but it doesn't have GParted.

<nckx>I think.

<nckx>Never mind, it does. But it uses a blobbered Linux.

<nckx>ACTION AFK. Bye everyone. florhizome[m]: Much luck to you!

<florhizome[m]>ty

<lechner>florhizome[m] / there is also https://www.system-rescue.org/

<florhizome[m]>but not sure I execute today

<florhizome[m]>i have the stick ready anyways now

<florhizome[m]>Lechner: thx.

<florhizome[m]>I need luks support on the iso, right?

<lechner>florhizome[m] / probably, but i have never used LUKS except to encrypt my swap partition

<lfam>Yay for btrfs and LVM online resizing

<lechner>it worked?

<lfam>Yup! No LUKS on that system so it was all online

<lfam>First, shrink the big btrfs filesystem, then shrink the logical volume that contained that filesystem. Then, grow the other logical volume, and finally resize the filesystem it contains

<lfam>The smaller FS was actually ext4. I think it can only grow online, not shrink. And I may have inode exhaustion problems later

<lfam>But I'll cross that bridge eventually

<lechner>inode exhaustion problems?

<lfam>With ext4, the number of inodes is set at the time you create the filesystem. The number of inodes is calculated based on the size of the filesystem. So, if you make a small ext4 filesystem, it will not have many inodes

<lfam>So, you could run out if you have lots of small files, or if you grow the filesystem and fill it with normal sized files

<lfam>One of the big pain points of ext4

<lfam>You can check this with `df -i`

<lfam>Looks like I have only used 11% of inodes, though, so I think I'll be good

<lfam>I set up this system like, maybe 7 years ago. Next time I probably won't use ext4 at all. Just btrfs and / or xfs

<lfam>You can learn more about the inode thing in the man page for mkfs.ext4

<lechner>lfam / thanks for letting me know. i like ext4 and use it all the time for root partitions or CacheFS. never ran out, but it is good to know

<lfam>It's not a very common pitfall, but slightly more common with Guix, if the root filesystem is not very big

<lfam>The Guix store can use up all the inodes

<lfam>So, if you ever see an "out of space" error on that filesystem, but you still have plenty of bytes, check `df -i`

<lechner>Hi, for our reproducible gurus: Is there a standardized method to fingerprint a folder, such as hashing an ordered manifest that contains hashes for anything found inside the folder?

<roptat>lechner, guix hash -rx .

<roptat>-x is for excluding vcs directories such as .git

<lechner>roptat / thanks!

<Kolev>Guix makes my fan spin.

<Keman99>Kolev: Is it a laptop, right?

<Kolev>Keman99: Yes.

<Keman99>Kolev: May we know, which brand or model name?

<Kolev>Keman99: Lenovo ThinkPad X200 Tablet with Libreboot 2016.

<Kolev>Or was it Libreboot 2020?

<Kolev>IDK.

<Keman99>Kolev: Congratulations for the Libreboot ^^ I have a T420 but with normal BIOS..

<lechner>can i get libreboot for my T450s?

<Keman99>Kolev: Might be a concern with Libreboot that the fans are spinning too much.

<Kolev>Keman99: I've never used Guix on a non-Libreboot computer, so I can't say.

<Kolev>Keman99: All I know is other GNU/Linux systems do not do this.

<gabber>Kolev: "makes my fan spin" as in: they just spin or are you `guix pull`ing or reconfiguring your system? do you use the same DE and applications as with other distros?

<Keman99>Probably running cmatrix, like DistroTube on Guix what makes the fans spin.

<Kolev>gabber: Want to add a user to the system? Spin up the fans!

<lechner>Doesn't Lenovo provide a kernel module and some tools for specialized ACPI? Stnadard Guix may not ship it. (I run #nonguix on my T450s but use it rarely)

<gabber>so you are reconfiguring the system -- that is a vastly different operation than on the other distributions

<Kolev>gabber: The simplest system changes require a huge reconfigure.

<gabber>yes, that is by design

<gabber>well, as long as you don't `guix pull` in between it's not a "huge reconfigure", just a small one

<Kolev>gabber: Assuming services are not touched in the configuration, does a reconfigure start/stop servers?

<gabber>i don't think so

<gabber>WDYM by "servers"? web servers?

<Kolev>So reconfiguring to add a user won't grind all the servers to a hault.

<gabber>it shouldn't

<Kolev>gabber: HTTP, IRC, SSH, whatever.

<lechner>Hi, is bordeaux.guix.gnu.org located in France or London?

<GNUtoo>France I think, in probably Bordeaux

<Kolev>I want to say 'service', but that might be confused for a line of Lisp code, not an actual running process.

<gabber>well, that is a somewhat blurred line in Guix :)

<gabber>i think Guix tries to restart relevant services, but you get a message on what happens towards the end of your "reconfigure"

<_Mystified>Good morning all. Succesfully installed guix (Xfce), ran " guix pull" trying to install icecat But when I try install pkgbrowser & konversation so I'm able to get to manuals I

<_Mystified>I receive the following message "GUIX_PROFILE='/root.guix-profile"

<_Mystified>"$GUIX_Profile/etc/profile"

<_Mystified>what am I meant to do with this

<gabber>_Mystified: not sure i understand. you are trying to install icecat. do you succeed? if not: what is the exact error message?

<_Mystified>correct, I get that with every package I attempt to install post installation of the os

<_Mystified>"cconsider setting the neccesary enviroments variables by running"

<_Mystified>the above

<gabber>_Mystified: are you on Guix System or using guix on top of another distro/

<_Mystified>bare metal install

<_Mystified>I'm about to chroot into it with another os, so that I'm able to copy & paste the guix messagess

<gabber>i think it's nothing to worry about: but you should probably consider setting the environment variables, as your installation suggests

<_Mystified>how to do that

<_Mystified>btw thanks :) gabber:

<gabber>no problem

<roptat>copy-paste the commands it tells you to use

<roptat>it should silent the message for your current session, and normally you won't see them again on the guix system

<gabber>you can try it out with a simple `GUIX_PROFILE=/path/to/wherever/was/suggested` in your shell (you type only what is in between my ``)

<roptat>and also the command that starts with a .

<roptat>oh and installing icecat as root is not recommended ;)

<gabber>ah no, sorry; you can try that as a prefix to your next `guix install` call. if you want to persist you should write something like `export GUIX_PROFILE=/your/path` into the right profile file... let me look for the relevant section in the manual

<roptat>guix and guix system allow you to install package as root or user, and packages installed as one user (including root) aren't visible to other users (including root)

<roptat>so you should install graphical apps as your user, not root, or in your system configuration file and run "guix system reconfigure <that file>"

<gabber>_Mystified: i think Chapter 5 and 13.2 mention the most relevant parts to your issues

<roptat>anyway, have to go, good luck :)

<Guest7070>33

<apteryx>vagrantc: could you confirm that there's no longer any incompatibility between u-boot and openssl?

<vagrantc>apteryx: it certainly seems ambiguous at best

<apteryx>why?

<apteryx>openssl 3 is now Apache 2.0, which is compatibe with GPL

<vagrantc>GPL-3.0, not GPL-2

<vagrantc>significant parts of u-boot are GPL-2 only

<apteryx>ah!

<apteryx>thank you, just saw that "Please note that this license is not compatible with GPL version 2,", w.r.t. Apache 2.0

<nckx>lechner: <bordeaux, london> OK, I can't resist and must bite 😛 Why?

<rekado>ACTION overhauls mumi CSS

<vagrantc>i think it's only a tiny bit of header files that are included, and in theory wouldn't be hard to switch to another implementation ... but ... a little beyond me

<vagrantc>e.g. a more compatible implementation such as wolfssl or gcrypt or ...

<apteryx>OK!

<apteryx>it'd be cool if they supported GnuTLS out of teh box

<vagrantc>yeah, gnutls...

<vagrantc>ACTION knew there was another potential option

IRC channel logs

2022-12-20.log