IRC channel logs

<ham5urg>Can't imagine a world where every application brings in its own service definition in a common language (maybe XML) and can be adapted by Guix automatically.

<rekado>xml is just ugly s-expressions if you squint really hard

<singpolyma>and luckily sxml will do the squinting for you

<ham5urg>I'm fine with sxml. Nevertheless Idk any application which has such descriptions for its service description.

<ham5urg>Guix is offering some. But that should be done by the applications itself.

<singpolyma>ham5urg: the while point of the distro model is we don't necessarily want them to do integration stuff themselves

<ham5urg>If the applications would describe their service with xml/sxml or whatever, that could be used by other too. E.g. Ansible. Or it could be used to read the /etc/whatever.conf in plain style like today.

<argv>Hey, I'm preparing a patch for bumping up Go version. I've installed and ran it for a couple of days locally and the build works. What else should I test before sending it?

<argv>This is my first time preparing a patch so pardon my ignorance

<AwesomeAdam54321>argv: Can you try to build dependent packages and see if the Go version broke compatibility?

<AwesomeAdam54321>s/version/version bump

<argv>got it, so anything with go-build-system would be a dependent right? I'll try to build some packages there

<twopubsolar[m]><ham5urg> "Can't imagine a world where..." <- :blob_thinking:

<argv>AwesomeAdam543: I've tried building a bunch of random packages that use go-build-system. Those are building correctly.

<oriansj>twopubsolar[m]: well people have preferences and that is natural. It is best to assume that other will not agree on the best way of doing things.

<twopubsolar[m]>i mean there are definitions in $prefix/share/dbus-1/services/

<argv>is there a more general way to build all packages that depend on go-build-system? I can leave it overnight i guess

<oriansj>well on debian, I'd just do apt-cache rdepends $package but I don't think Guix has that functionality yet

<oriansj>possibly guix refresh --list-dependent will give you a 1 level of indirection to find that information

<argv>oriansj: it looks like that's only giving me the list of dependencies that i've already build, so in a pure environment that's almost empty

<argv>am i missing something?

<oriansj>argv: yeah, I don't think guix has a way to find that information out of the box. So someone would have to implement it first

<argv>I see, i guess I can just do a grep in the repository and build those then

<apteryx>rekado: re XML, I like your way to put it ^^

<argv>okay found a way to programmatically do it

<argv> https://paste.debian.net/plain/1264430

<oriansj>argv: probably with a few minor tweaks, you could submit that as a patch to guix package and then everyone would benefit

<argv>yeah that's a good idea, but i'll try to get this patch merged first :)

<oriansj>^_^

<argv>build is running with 533 packages, i'll check it tomorrow morning

<apteryx>patman is cool

<apteryx>especially useful for annotating version changes in the series

<sneek>zamfofex: wb!

<zamfofex>sneek: botsnack 🤩

<sneek>:)

<zamfofex>Hello, everyone! I decided to spend some more time investigating the issues I was having regarding updating the Hurd packages, and I think I figured out the issue more accurately now! It seems ‘libpthread’ is not part of ‘libc’ like on Linux, even after glibc 2.34.

<zamfofex>I decided to update my glibc change to implement the TODO in the comments: I made it decide whether a ‘.a’ file is empty by checking the file size, in hopes that it’d end up working better.

<zamfofex>However, it turns out that ‘libpthread.a’ is actually a linker script when cross‐compiling for the Hurd, so that didn’t work either, because linker scripts are moved to the ‘static’ output anyway.

<zamfofex>I tried making sure that these linker scripts are copied instead of moved, but that ended up causing a different error, before the build even gets to the cross‐compilation parts. The error is while building the ‘file’ package (natively) during bootstrapping.

<zamfofex>I continued to investigate, and I concluded that the ‘file’ executable built requires ‘libc’ and ‘libpthread’ (from glibc 2.35) as well as ‘liblzma’. In turn, ‘liblzma’ requires ‘libpthread’ (from ‘glibc-mesboot’ 2.16.0), and when everything gets resolved, the executable’s “glibc 2.35” takes precendence over liblzma’s “glibc 2.16.0”, and there are runtime linking errors due to missing symbols.

<zamfofex>Now, I’m completely mistified, given that when running ‘diff <(ls -l /gnu/store/[old-hash]-glibc-2.35/lib) <(ls -l /gnu/store/[new-hash]-glibc-2.35/lib)’ (where “old” and “new” are before/after my recent changes to glibc to copy rather than move linker scripts), the only difference I see is ‘libm.a’ and ‘librt.a’ being present after my changes.

<zamfofex>And granted, ‘libm.a’ (which is a linker script) currently has broken file names, since it refers to files that were moved to ‘static’, but I feel like that has nothing to do with the errors I’m getting.

<zamfofex>Hold on, imma upload some relevant logs and the changes I made somewhere. Any help would be extremely appreciated! (Though I guess it might make more sense to ask on the mailing list, huh?)

<zamfofex>There we go, I uploaded some logs and my changes here: <https://gist.github.com/zamfofex/5609dd0cc20f321f9ac82bc3adbad9bc>

<zamfofex>sneek: later tell civodul: Regarding my Hurd endeavors, I feel like I have made a lot of investigative progress. Whenever you have the time, if you wouldn’t mind it, I’d really appreciate some kind of feedback regarding it: <https://logs.guix.gnu.org/guix/2022-12-18.log#021951> Thanks in advance.

<sneek>Okay.

<Spawns_Carpeting>where can i find the gpg keys used to sign the guix git repo?

<Spawns_Carpeting>nevermind i seem to have found it on the security page

<the_tubular>You mean to sign the commits ?

<SUPERB[m]>Since there’s not Q4wine in the repo what shall I install as UI for WineHQ?

<SUPERB[m]>s/WineHQ/Wine/

<lilyp>IIRC most Wine GUIs advertise proprietary software and will thus not be packaged

<lilyp>if Q4wine is not one of those, you could attempt packaging it

<yarl>Hello guix!

<user_oreloznog>o/

<argv>context: ran the builds for all packages that depend on go-build-system.

<argv>There is one package that is failing in check phase because unit test has some vetting issue. This is a problem in upstream itself. How do i go about fixing it, considering other packages depend on this specific version.

<argv>ok i see that some packages have disabled tests in check phase because unit tests fail. I can try that

<argv>i guess this is better, i can just turn the vetting off for tests, going with that for now

<rekado>ACTION builds the linux-libre tarball for arm64-generic manually on ci.guix.gnu.org because the build times out otherwise

<efraim>rekado: can you build the one for rust also for aarch64? I'm not sure that one tries to get built on each build machine for the different rust-* packages

<rekado>efraim: do you have a derivation for that?

<rekado>I’m still having problems with the kernel modules :(

<rekado>finally built linux-libre-arm64-generic, but when building a system with it the kernel modules derivation fails

<rekado>says there’s no “ahci” module

<rekado>and sure enough: there isn’t

<efraim>rekado: it should be /gnu/store/8vagilxnpdgyybljmdfpl99bp7j49dqk-rust-1.60.0.drv

<rekado>are the linux-libre-arm64-generic packages broken?

<rekado>efraim: thanks, I just started the build

<rekado>(with insanely large timeout/max-silent-time)

<efraim>rekado: for aarch64 I'm pretty sure the default for initrd-modules should be an empty list

<rekado>oh

<rekado>is this what you use on your pinebook pro?

<efraim>not as relevant for now, but I'm pretty sure the same for riscv64

<efraim> https://git.sr.ht/~efraim/guix-config/tree/master/item/pinebookpro.scm#L41

<efraim>I'm trying to get the nvme to work also so I've added that module, but I made a note to myself that by default it is empty

<efraim>and then heres what I have for my pine64 https://git.sr.ht/~efraim/guix-config/tree/master/item/pine64.scm#L34 which I've been using successfully for a few months now

<rekado>superb! Thanks

<rekado>the system check tells me I need a rockpro specific module, which I’ll add. Let’s see if that works.

<efraim>it looks like there is a rock64-raw image-type, not sure how different that is from rockpro

<efraim>it looks like you'd want a pinebook-pro-raw image-type since they're both rk3399, and we have (define install-pinebook-pro-rk3399-u-boot install-rockpro64-rk3399-u-boot) in gnu/bootloader/u-boot.scm

<efraim>at least that's my guess

<rekado>I do without the install-rockpro64-rk3399-u-boot procedure. I write the partitions and u-boot to the sd card manually and just install grub-efi-removable-bootloader to the EFI partition on the SSD.

<rekado>it’s easier for me to understand

<Luchadoritos>Hey Guix! Anyone know the right package transformations to make "emacs-next --with-branch=master" work? I get a native comp error (cannot find "as" no such file or directory). Wanted to experiment with the new features while before I go back to work.

<civodul>Luchadoritos: hi! my guess is that when using --with-master, the 3 patches currently applied on emacs-next's origin are discarded

<sneek>civodul, you have 1 message!

<sneek>civodul, zamfofex says: Regarding my Hurd endeavors, I feel like I have made a lot of investigative progress. Whenever you have the time, if you wouldn’t mind it, I’d really appreciate some kind of feedback regarding it: <https://logs.guix.gnu.org/guix/2022-12-18.log#021951> Thanks in advance.

<civodul>and one of them appears to be related

<civodul>so maybe you need to throw an extra --with-patch

<Luchadoritos>civodul: Akamai! I never considered that. I'll try that as soon as I get to my computer. Thank you so much!

<civodul>yw!

<Luchadoritos>I was trying to rewrite the inputs for gcc libggjit and stuff and nothing was working properly. This is a new direction to solve the issue for me. Ty again

<civodul>i'm looking at https://issues.guix.gnu.org/60164

<civodul>anyone has ideas as to why Pango would be using a font that lacks glyphs for some scripts?

<argv>for my go version bump attempt, looks like ipfs is breaking. It might be out of scope for this patch atleast should I split it into two separate patches then? 1. bump ipfs, 2. bump go version

<argv>btw if i want to add support for fish shell in profile where should I look?

<rekado>bleh, still won’t boot. Or maybe it does, but I can’t see any output on HDMI once linux takes over.

<lembrun[m]>Any shepherd expert here? It's hanging sometimes when I try to reboot/shutdown, it's the only process active at shutdown and I need to sigkill it with sysrq to continue the shutdown

<lembrun[m]>I can"t see why exactly, because it occurs after shepherd closes its log : (

<lembrun[m]>but it does not happens on a live usb

<rekado>ACTION does not know

<lembrun[m]>* well shit

<lembrun[m]> * * well shit

<jonsger>civodul: which command gives you those human readable .sig files, e.g. https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.x86_64-linux.iso.sig ?

<nckx>jonsger: ‘Human readable’? Bot detected.

<nckx>I guess you mean --armour?

<nckx>lembrun[m]: You might have more success/audience on the bug tracker/mailing list.

<xd1le>Hi! Say I did a guix build successfully, then I change the source code locally, and now I run guix build again but offline, would it work?

<nckx>Which source code?

<nckx>If you didn't add any new (transitive) inputs, it should.

<xd1le>sorry, of the package

<xd1le>for the source field of the package being built

<xd1le>nckx, ok thanks :)

<nckx>This is bordering on the tautological, but unless you add something new for Guix to download, it shouldn't have to download anything if the source is in the store.

<xd1le>nckx, haha yes bit of stupid question.. the thought just popped into my head when seeing the "updating subtitutes" lines

<xd1le>after doing a guix build

<jonsger>nckx: thx, thats it :) The resulting file is named .asc but it doesn't look different then Ludos .sig :)

<nckx>xd1le: Not stupid. There are some surprising (at first) cases where Guix will download things you don't expect, e.g., for profile hooks. But that won't affect ‘guix build’.

<nckx>Or for example if you substituted the previous version of X, but Guix needs some more tools (such as git) to actually build X from source.

<nckx>Not exactly surprising, but easy to forget.

<cmack>I'm trying to using fwupdate but I'm receiving a missing file error: failed: /gnu/store/36rfx04cqix5k9fsd123x4lhai5knd3h-fwupd-1.8.3/libexec/fwupd/efi/fwupdx64.efi and /gnu/store/36rfx04cqix5k9fsd123x4lhai5knd3h-fwupd-1.8.3/libexec/fwupd/efi/fwupdx64.efi.signed cannot be found

<cmack>Has anyone experienced this? Did you find a solution?

<nckx>If I'm looking in the right spot (contrib/snap/fwup-efi-signed, an ill-boding name in itself), it tries to download a binary blob at ‘build’ time. More ill-bodement.

<mbakke>so if we replace QEMUs blobs with SeaBIOS ones there is no boot display, but loading the same BIOS with -bios works just fine... ideas?

<oriansj>I believe the phrase from Bryan Cantrill is accurate "We are at war with firmware"

<nckx>cmack: We could try to build it from source, assuming it's reproducible, but I'm not wild about using Guix to distribute Tivoised binaries.

<oriansj>nckx: not much choice as those are Microsoft signatures for UEFI binaries

<oriansj>(unless people can install their own keys and sign for themselves)

<cmack>I was slightly afraid of that :(

<nckx>oriansj: To be clear, my alternative was ‘we don't bother’ and I'm fine with that.

<oriansj>nckx: well nothing wrong with saying "I don't feel like doing this", when it isn't your paid job

<nckx>ACTION .oO Been a while since I've got my Bryan Cantrill rage quotum filled.

<nckx>Does he have a holiday special out.

<oriansj>not yet but he has slowly been foaming more and more aggressively about firmware and honestly I can't blame him

<cmack>Is there some way to message to users about this when they start searching?

<oriansj>it is hard to write software when the hardware repeatedly lies to you

<nckx>Pity that On The Metal petered out.

<nckx>cmack: How so? We could mention it in the description, but I'm not familiar with Guix's fwupd package. Does it do anything well?

<oriansj>nckx: I never got On the Metal to download, so I haven't been able to watch it.

<cmack>I was thinking more along the lines of a wiki or similar. I can't speak to fwupd since this is the first time I'm trying to use it to update EFI. It's just a means to an end with preference of not being force to boot a different OS. But I understand supporting non-free bios is also not in the mission so... I'll adapt other ways.

<nckx>cmack: Still, if you have time, could you file a bug?

<nckx>oriansj: I only ever listened to it, and didn't have to jump through hoops to do so IIRC.

<nckx>ACTION AFK.

<cmack>nckx: That will be a first for me too for GUIX but I'll give it a go, yes

<nckx>Random thing I found that isn't packaged yet: https://github.com/Foxboron/sbctl

<nckx>cmack: Simply send one mail with all info to bug-guix at gnu dot org :)

<cmack>will do. Typing it up now

<sughosha>Hi all, in my Guix system GNOME Music is not able to find any music in my Music folder, just empty. It seems to be some issue with tracker, could anyone confirm if this is a bug or I am missing something in my configuration?

<civodul>lembrun[m]: could you email bug-guix with all the details, including version, architecture, and /var/log/messages excerpt?

<M0rc0[m]>Can I use Hurd on laptop? If not: can I use VM inside GUIX then run GNU/Hurd there?

<SUPERB[m]><lilyp> "IIRC most Wine GUIs advertise..." <- So how can I use wine? Through the terminal?

<AwesomeAdam54321>M0rc0[m]: I don't think the HURD is an option yet in the Guix System installer. You can build/download a Guix System GNU/HURD VM image and run it

<zamfofex>M0rc0[m]: You probably can! Why not? Note that you might not be able to use Wi‐Fi, and some (most?) networking boards aren’t currently supported because netdde is currently broken/missing.

<AwesomeAdam54321>I recommend that you give installing it a try, like zamfofex said

<nckx>SUPERB[m]: Sure. I think that's how the majority of people use it.

<nckx>wine foo.exe && enjoy.

<lilyp>that, plus wine installs a bunch of mime handlers as always

<nckx>(I guess we could do some binfmt magic to make the ‘wine ’ optional, but I'm not aware of that being in Guix.)

<nckx>Right, but then you need a GUI that handles those.

<lilyp>most of them are annoying af, but the exe one is still useful

<nckx>Heh.

<lilyp>well, nautilus respects them and I'm p sure plasma does too

<nckx>You want to make sure that people can open that funny e-card from grandpa.

<nckx>ACTION runs s/GUIX/Guix/g on the backlog again.

<rekado>we have qemu-binfmt-service-type

<nckx>This was about Wine.

<rekado>yes, just mentioning that we have some binfmt magic. Maybe we can add similar magic for wine.

<nckx>Sure.

<lilyp>I do wish we had whatever magic is required to build dxvk

<nckx>Uh oh. ../ffmpeg-3.4.8-single-header.h:615: warning: "INFINITY" redefined

<efraim>there you go, breaking the universe again

<oriansj>:doh: how many times do we have to tell people ${n}/0 is not INFINITY; it is just not defined...

<rekado>so… kernel is booting, but HDMI no longer works and it doesn’t manage to initialize the SATA card.

<rekado>works in grub, though

<nckx>Were you able to serially connect?

<rekado>yes, after compiling u-boot with a different default baud rate

<rekado>(115200 instead of 1500000, which exceeds the max speed of my USB serial adapter)

<rekado>I guess now I just need to play with different kernel configs. Yay.

<yarl>I modified this part of libstm http://paste.debian.net/1264516 to allow for cross-compilation but it fails : (assoc-ref inputs "pkg-config") returns #f, any idea?

<rekado>the old linux-libre-arm64-generic when the default version was 5.15.19 works, at least wrt HDMI

<nckx>Oh, interesting default. I've not seen or used any above 115200. I thought that was the consensus.

<nckx>rekado: I think -generic is the one that is expected to work.

<nckx>It's confusing.

<rekado>with that old kernel I was also able to access the SSDs via the SATA card (though I only booted from USB then)

<civodul>ACTION takes exclusive lock on 'version-1.4.0' + on guixp9 and overdrive1.guix

<yarl>rekado nckx, are you working on rockpro64?

<rekado>I have tested current variants of linux-libre-arm64-generic, as well as -5.10.

<yarl>(1500000)

<rekado>yarl: yes

<nckx>yarl: Use search-input-file native-inputs with pkg-config-for-target.

<yarl>I am currently trying to fix packages that prevent cross building of the installation image.

<nckx>Actually, can't you use (which #$(pkg-config-for-target))?

<nckx>To replace the entire string-append call.

<yarl>nckx: Let me try.

<nckx>Background: ‘pkg-config’ isn't called ‘pkg-config’ when cross-compiling, but ‘pkg-config-$TARGET’.

<yarl>nckx: Apparently it works, thank you. The cross compilation still fails on the same error (couldn't find pkgconfig. I probably misunderstood the problem, will investigate further.

<yarl>nckx: Ah thanks.

<nckx>Perhaps the build system expects a PKG_CONFIG= or so.

<yarl>nckx: I don't know exactly, and it's cmake. I don't know it very much.

<lilyp>isn't it $TARGET-pkg-config just as with gcc?

<nckx>Yes.

<nckx>yarl: Which libstm is this?

<yarl>nckx: What do you mean? I'm in gnu/packages/terminals.scm

<yarl>libtsm

<yarl>sorry

<nckx>Ah!

<nckx>Typofiends unite.

<nckx>Maybe try -DPKG_CONFIG_EXECUTABLE=, although I didn't poke the source.

<nckx>(…with the right value, that is.)

<rekado>ACTION boots working 5.15.19 kernel to compare kernel configs

<yarl>nckx: This (http://paste.debian.net/1264518) worked, thanks. There's another problem for cross building, I'll look into it.

<nckx>civodul: I've tested rc2 on Ventoy, X230T (not really the most demanding hardware platform, true), and some VPSes. Didn't find bugs to report. So sorry. I'll do better.

<nckx>yarl: Cool. We should avoid %build-inputs though (why did which not work?), but focus on getting it working first.

<nckx>I'm a stoop, missed the context.

<yarl>nckx: ?

<nckx>Your previous paste dealt with a phase, and I hadn't noticed that things had moved to #:configure-flags in the last one.

<nckx>Indeed I don't think there's a way to avoid %build-inputs in there, yet. That's a shortcoming.

<yarl>nckx: Yeah, that's because you told me about -D and there's already #:configure-flags. By the way, I am still confused between inputs, %inputs, lambda* (#:key inputs #allow-other-keys), etc

<yarl>I kinda try and keep what's working...

<yarl>That bothers me a lot.

<yarl>Why things are different between #:configure-flags and #:phase?

<yarl>s/things/the context/

<yarl>Did I miss a blog post/talk/something?

<nckx>%build-inputs is a hack, an implementation detail, a global variable of sorts that's too useful to ignore. lambda* (#:key inputs …) is the clean way, as is using this-package-native-inputs. The latter would work if pkg-config weren't an ‘implicit build system input’. So that's another implementation detail kicking you in the shin.

<yarl>ouch.

<lilyp>also, isn't there pkg-config-for-system?

<lilyp>for this very exact reason?

<nckx>?

<nckx>I only know of pkg-config-for-target, suggested above.

<nckx>What's the diff?

<nckx>Mmm, grep says no.

<lilyp>meant target, yes

<nckx> https://paste.debian.net/1264518

<lilyp>no, not like that

<lilyp>"-DPKG_CONFIG_EXECUTABLE=" #$(pkg-config-for-target)

<yarl>lilyp: I will try.

<yarl>lilyp: no. It needs the absolute path I think.

<lilyp>huh, pkg-config-for-target isn't absolute – the more you know

<nckx>Neither is cc-for-target or the rest.

<nckx>I assumed yarl wouldn't use %build-inputs without reason, but joke's on us for thinking CMake would support this new ‘$PATH’ standard.

<lilyp>To be fair, it takes some time to get used to.

<roptat>hi guix!

<nckx>Anyway, ere I forget: *is* there a this-package-native-input variant/alternative that handles implicit ones?

<nckx>o/

<lilyp>I don't think we have (this-package-implicit-input) and enabling it would feel like a very unhygienic hack

<nckx>It would be! But then so is the above.

<nckx>We want a thing that is fundamentally unhygienic, by that definition.

<nckx>‘Refer to an implicit thing before it's injected later.’

<lilyp>isn't it already injected by the time it's captured in %build-inputs, though?

<M0rc0[m]>During guix install, choosing wired, how to set dns during install when ifconfig manually down't work?/only one address allowed for interface 'enp4s0' it says.

<nckx>lilyp: %build-inputs *is* the unhygienic thing I was initially objecting to. Sorry if that wasn't clear.

<nckx>If you mean that this-package-implicit-native-inputs would be even more unhygienic, I admit to not following.

<lilyp>%build-inputs is inside the gexp, but this-package-implicit-native-input would need ungexping

<lilyp>so as far as I'm concerned, the latter would be gnarlier

<yarl>nckx, lilyp I am not following you, while trying. say if it's not an implicit input, could I use :

<yarl>(string-append "-DPKG_CONFIG_EXECUTABLE=" #$(this-package-native-input "foo"))

<lilyp>not quite

<nckx>lilyp: I understand what you mean now, and that would be consistent, but I wasn't actually considering it to be *that* symmetric. You'd write #$(t-p-n-i) and (t-p-i-n-i). Yeah, that might be more confusing than it helps.

<lilyp>you would have to append /bin/foo to get an actual program

<yarl>(string-append "-DPKG_CONFIG_EXECUTABLE=" #$(string-append (this-package-native-input "foo") "/bin/foo"))

<yarl>?

<nckx>lilyp: If it helps, what I meant should better be called (build-system-implicit-inputs). I don't see how that's fundamentally filthy.

<lilyp>yep, that'd work

<nckx>Poor naming on my part but it's what I meant.

<yarl>And why exactly you can't use this-package-native-input on "pkg-config"?

<nckx>yarl: Because it's not in your list of native-inputs; it's injected ‘implicitly’ by the build system. Like GCC et al.

<nckx>t-p-n-i really only operates on your pretty list of native-inputs in the package definition, nothing else.

<yarl>hmm

<nckx>🤷

<nckx>It is what it is.

<lilyp>nckx: can't you use (standard-packages) from the build-system side though?

<mrvdb>I have a derived emacs variant defined: https://dpaste.org/W0sHK The build takes really long, because a shallow git reference cannot be made? Gives msg about server won't give non advertised references. It all works, but takes very long. What should I be doing there?

<lilyp>okay, perhaps we would need to abstract standard-cross-packages a little more to make this work on the #$ side

<nckx>That sounds basically like what I described, so it must be correct.

<lilyp>how is a shallow git reference related to the build time?

<mrvdb>lilyp perhaps not build, but clone time, as it needs a full download i guess

<lilyp>okay, so we're talking just about `guix build -S'?

<mrvdb>i used `guix build emacs-next-lucid -L .' in the directory where the scm file is

<lilyp>also while we're at it, don't call things emacs 30 when 29 isn't even out

<mrvdb>it's what I am getting as version fromm the resulting emacs

<nckx>mrvdb: It's up to the server to support it. You could use a different (mirror) server, or see if the project makes tarballs. This warning has nothing to do with your variant.

<mrvdb>nckx that makes sense, is there a way to find out /which/ refs are advertized by server? i'm not particularly picky about one, as long as it is very recent

<nckx>That I don't know, sorry.

<nckx>I'd guess tags, but even that's a guess.

<mrvdb>yeah, tags and branches would be logicial i guess

<mrvdb>allright, thanks!

<lilyp>indeed the branch appears to have been cut

<mrvdb>i have no idea how those emacs version work, does the .50 or .60 signal anything?

<lilyp>It signals "very much in development"

<mrvdb>heh

<yarl>OK now that's "check" it does not find.

<AwesomeAdam54321>Would it be difficult to break the circular dependency between pkg-config and glib?

<yarl>nckx: Do you know what cmake configure variable should I set? If there is one.

<nckx>For?

<nckx>Oh. Is ‘check’ a command?

<yarl>yeah, it's in libtsm's native-inputs list.

<nckx>Right. But I mean, the ‘check’ package does not provide a ‘check’ binary, only ‘checkmk’.

<yarl>And cmake tries to find it using pkg_check_module.

<yarl> http://paste.debian.net/1264525

<nckx>I'm not at a capabl computer right now.

<nckx>*e

<yarl>nckx: :)

<nckx>But I can say that running a test suite during cross-compilation is probably bogus.

<yarl>nckx: Sure, but it's checking it during configuration.

<yarl>Or I should remove that part from the configuration?

<nckx>Can you patch it not to? (This sounds like a fun package, jeez.)

<yarl>(if cross building)

<yarl>nckx: Probably :'(

<nckx>Arguably an upstream bug, but I can't say for sure from here.

<civodul>ACTION pushes updates to the release blog post: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md

<efraim>almost have a successfully compiling zig-0.10.0, can't make it past the validate-runpath phase, can't find ld-linux :/

<civodul>do we have an illustration for Guix Home?

<civodul>not sure what that could be

<efraim>asciiart of a house square with triangle roof, with the Guix horns

<nckx>Does it have to be ASCII?

<nckx>I was doodling that, but with the Guix logo upside-down as the roof.

<efraim>it'd look better than if I drew it

<nckx>But I have to leave for a while, so I'll rejoin later o/

<civodul>heh, i like that idea :-)

<nckx>Proper horns or inverted roof? I'll share it when I get back.

<M0rc0[m]>During guix gui install, choosing wired, how to set gateway addr. during install, via tty, when setting 'ifconfig or ip route' manually wown't work?//only one address allowed for interface 'enp4s0' it says.

<mekeor[m]>0rc0: maybe share full command and full error message

<user_oreloznog_>M0rc0[m]: 'ifconfig -a' or 'ip a' maybe?

<M0rc0[m]>Sry bout that. I will. I'm doing it over now. DEBLOBBLING something, and that only one addrs can be set. Should I use ip or ifconfig?

<user_oreloznog_>don't really no

<user_oreloznog_>both seem well

<M0rc0[m]>yes both seem to work, but noit when setting dns,gateway

<M0rc0[m]>s/noit/not/

<user_oreloznog_>hmm i'm don't know...

<user_oreloznog_>*I don't know

<M0rc0[m]>error is: ifconfig: only one address allowed for interface'enp4s0

<M0rc0[m]>it's set to automatic obviously, so im trying to set it during install, but at startup it mmentions somewthing about firmware deblobbiing.

<M0rc0[m]>i do this:

<M0rc0[m]># ifconfig -s enp4s0 static 192.168.0.5 255.255.255.0 192.168.0.1 permanent

<lechner>nckx / Hi, inspired by your reference to sbctl, I made an initial attempt to package it but ran out of time. Maybe someone else wants to pick it up? http://paste.debian.net/1264530

<M0rc0[m]>s///, s/#//

<nckx>‘s///’ OK Matrix.

<user_oreloznog_>M0rc0[m]: Maybe someone else here knows solutions, i'm not good enough ;)

<M0rc0[m]>cant stand these types of issues, i know its an ez one too, if it isn't something on hardware/firmware level is desabled by default, and if RTLINK has anything to do with it/even tho im on wired.

<M0rc0[m]>- rly dont want to start with setting up iptables, if thats even possible during install.

<user_oreloznog_>M0rc0[m]: https://guix.gnu.org/fr/manual/devel/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html#Networking ...Perhaps it can help...

<nckx>ACTION doesn't know either.

<M0rc0[m]>mekeor: error msg:

<M0rc0[m]>0000:04:00.0: Missing Free Firmware (non-free firmware loading is disabled)

<M0rc0[m]>r8169 0000:04:00.0: Unable to load firmware -'(DEBLOBBED)*/ (-2)

<Guest95>Hello, does Guix support PipeWire?

<rekado>it has pipewire packages.

<Guest95>So I can use PipeWire instead of PulseAudio?

<nckx>efraim: The inverted horns idea looked like shit. https://www.tobias.gr/hmm.png

<nckx>Or maybe https://www.tobias.gr/hmm2.png

<efraim>what if the horns started at the peak of the building?

<efraim>the second one looks to me like it's about to fly away

<rekado>looks like the opened doors of a DeLorean

<nckx>Time machine logo: also done.

<nckx>Like this? I don't like that at all: https://www.tobias.gr/hmm3.png

<drakonis>that's...

<drakonis>very horny?

<drakonis>it looks like a tv antenna

<nckx>I've never seen the Guix logo as only horns, but as a stylised almost-head, so this looks wrong.

<nckx>Like a giant looming gnu threatening your home.

<drakonis>ha, a gnu.

<drakonis>a true wildebeest there

<nckx>As high as I can raise them horns without it looking weird: https://www.tobias.gr/hmm2b.png

<drakonis>i'll take a couple of these.

<nckx>(I prefer this, even with the lack of colour, it's kleen®.)

<drakonis>harhar

<lechner>btw, "horny" means something else in modern American English. It would be more accurate to observe that the horns look kind of large

<drakonis>yes i'm perfectly aware of what it means.

<drakonis>its part of the joke

<nckx>Guix: feel the horn.

<drakonis>it is very... extra.

<nckx>Which one/

<nckx>*?

<vagrantc>why, pray tell, does guix home need a logo? :)

<vagrantc>oooh, time machine has a logo too?

<nckx>No, that part was a DeLorean joke.

<vagrantc>ACTION finally parses the thread

<nckx>My understanding was that this was just to lighten up the release announcement.

<efraim> https://flashner.co.il/~efraim/gnuhouse.jpeg

<nckx>Uhm.

<nckx>Now that is scary.

<nckx>Is that some Midjourney-generated thing?

<efraim>stablediffusionweb.com

<nckx>I'll give myself a half point.

<drakonis>that's uh

<nckx>It's very uh.

<lilyp>nckx could you make it so that the horns extend more on the side?

<lilyp>i.e. taking the original hmm.png and sliding down the horns

<lilyp>maybe also working on that angle

<nckx>I thought that might help, but it didn't look good.

<nckx>I didn't save it.

<nckx>OK, I have an export but not the SVG, and it's cut off: https://www.tobias.gr/g3398.png

<nckx>Now *these* look like wings.

<PotentialUser-80>i am installing usb gnu guix with rufus. i hope i can install and use it on my computer without any problems.

<nckx>Rufus apparently works, according to a quick Web search. Good luck. Note that Guix does not include any proprietary firmware. Many more recent wireless network adapters & other hardware doesn't support free software anymore.

<nckx>ACTION → 😴💤

<PotentialUser-80>it is very expensive to have a completely free equipped computer :(

<PotentialUser-80>Used computers are very cheap in my country, but i don't have the hardware and knowledge to liberate them.

<PotentialUser-80>For example a thinkpad 500t is only 14 dollars

<mirai>any reason for nginx modules to be installed under #$output/etc/nginx/modules? (rather than say, #$output/usr/share/nginx/modules ?

<mirai>or /usr/lib (as they tend to be .so files)

<mekeor[m]>if i understand correctly, guix does not provide an "emacs" package with files native-compiles ahead-of-time (AOT), right? why not?

<vivien>Deer qt-knowing guix, is it OK to add both qtquickcontrols-5 and qtquickcontrols2-5 as inputs? Asking for musescore: https://issues.guix.gnu.org/60108#3 It seems to work, though.

<rekado>how about a half-timbered house with the diagonal supports replaced with the horns?

<nckx>civodul: I have torn myself from the soft yet oddly muscular arms of daddy Hypnos to high-five you. Thank you for taking care of this, and let's make sure you're the last one to bear this burden alone.

<nckx>ACTION falls back asleep.

<civodul>nckx: heh thanks :-)

<civodul>ACTION is in the upload phase

<civodul>sending announcements tomorrow

<civodul>rekado: sounds like a good idea :-)

<civodul>i just pushed a pretty cool thing to guix-artwork BTW, just sayin'

<dthompson>just checked... that is so cool!

<civodul>yup, i like it too!

<dthompson>I won't spoil it for anyone else... just go check it out!

<ss2>:D

<ss2>Very nice!

<vagrantc>civodul: so i shouldn't need to wait for the announcement to push to debian? :)

<vagrantc>last time i noticed the tarballs, signed tags, etc. but i waited till the announcement...

<civodul>vagrantc: heh, your call :-)

<civodul>uploading the ISOs is what takes the most time

<oriansj>civodul: don't you mean the downloading right?

<oriansj>as you build local and build on a server, upload the signature for the local build which should exactly match the build the server does

<civodul>nope, i meant uploading, but downloading too

<Tecjor[m]>Hi, I am using Xfce 4.16 desktop environment as I upgrade to 4.18. Guix upgrade xfce is not the command.

<oriansj>and then just sanity check the build done on the server against your local to spot any non-reproduciblity/differences done in the build

<vagrantc>civodul: basically, it comes down to ... with you re-release as 1.4.0 at this point with more changes ... or will you bump the version if any important changes come up

<vagrantc>er, will you re-release...

<oriansj>please version bump instead of doing 2 different ISOs with valid signatures for the same name

<vagrantc>oriansj: we are of common mind on this :)

<Luchadoritos>civodul: I did your fix and it worked like a charm! There's a whole host of nice features in later emacs I didn't even know I wanted (like constant tab bar size and faster window resizing). Epic!

<civodul>yay!

<vagrantc>ACTION pushed the tags and whatnot to Debian's guix git branches, so really hopes those tags are final :)

<PotentialUser-39>Hi, I installed GuixSD on my Raspberry Pi 2B, I use it and I like it, but now I would like to install the entire operating system, so all my system will be fully reproducible. I know Guix does not support the ARMv7 architecture, but, it seems that there is a development version for the Pinebook pro, do you know how I could do the same kind of thing

<PotentialUser-39>but for my hardware ?

<vagrantc>there is supprot for armhf, which is armv7

<vagrantc>there were some recently merged patches supporting various raspberrypi boards...

<PotentialUser-39>yes, I know, for the package manager there is support

<PotentialUser-39>but for the entire system(like with Shepard init system etc..) ?

<vagrantc>i don't know that it is well supported, and it has been a while since i have tried it, and the substitute servers tend to be behind ... but ... yes? :)

<vagrantc>i had a couple armv7 systems running Guix System

<PotentialUser-39>vagrantc: oh I didn't know that ? where I can download these ? I only find this tutorial for installing the full system on arm http://www.joyofsource.com/guix-system-on-the-pinebook-pro.html

<PotentialUser-39>vagrantc: ok thanks I will search for this

<vagrantc>all the systems i installed were with "guix system init ..."

<vagrantc>2b kind of lacks enough ram and disk i/o for it to make a lot of sense

<PotentialUser-39>vagrantc: did you use this patch https://issues.guix.gnu.org/48314 ?

<vagrantc>but if you've used it as a package manager, then you'll be aware of those kinds of issues, you'll just have more of them

<vagrantc>PotentialUser-39: that's been merged into guix

<PotentialUser-39>yes no problem. I don't care about speed I just want to have a reproducible system, I could use NixOS, but I don't want to learn another language

<PotentialUser-39>vagrantc: oh it's good then

<PotentialUser-39>so I'm going to try, hope it will work, bye

<vagrantc>from what i recall, guix pull on a system with 1GB of ram sometimes crashed with out of memory issues

<vagrantc>even if you heavily offloaded

<vagrantc>some things still needed to be done locally

<vagrantc>but that was before the switch to guile 3.0 ... so maybe that's better now

<the_tubular>Anyone has experience with guix on arm ? How is it ?

<vagrantc>the_tubular: a little tricky, but if you're familiar with guix and arm you can make it work ... if you have enough ram/disk/etc.

<PotentialUser-39>humm... I only use the tty... I may use Firefox sometime in a Wayland kiosk so I think it will be good

<the_tubular>Not really familiar with arm, I was just looking at lowering my cloud cost :P

<vagrantc>the_tubular: it's doable, but be prepared for some project time

<PotentialUser-39>maybe on my orange pi with 4GB of ram it can work without memory issue I'll also try