IRC channel logs


back to list of logs

<AwesomeAdam54321>a12l: There's `guix build --source <package>` to get the source code, but it's not part of `guix shell`
<a12l>AwesomeAdam54321: Thanks! Have I understood it correctly that the workflow for developing a patch for an existing package is to first runt `guix shell -D <package>` to get an development environment for the package; and then run `guix build --source <package>` to get the source downloaded into the store; after that you need to copy the source tarball into the directory where you're to work on the software?
<AwesomeAdam54321>a12l: Yes, maybe in the future this workflow can be automated better
<a12l>And after unpacking the source tarball you cd into the source dir you create a git repo; commit all files to the repo; and then actually begin writing or deleting code. After that you the changes you've made to .patch files with git diff and then apply them to in your config
<a12l>AwesomeAdam54321: Good to know!
<a12l>I did take a look at § 9.6 Build Phases in the ref. manual, and do I understand it correctly that the reason why we can't do it similar to how it's done in Nix is that the phases is fully written in G-expressions?
<a12l>Context for how it's done in Nixpkgs:
<kori>is there anything special about /etc/config.scm being in /etc/config.scm? is anything gonna look for it there? I mean, you gotta specify the path when you reconfigure anyway...
<mirai>kori: it doesn't need to be located there
<kori>mirai, thanks
<lechner>kori / with 'guix deploy', which I find far more comfortable, it is most certainly is a user directory
<lechner>in a user director
<lechner>never mind
<kori>lechner: yeah, I'm moving towards using guix deploy instead
<kori>i'm still learning the ropes of guix...
<lechner>kori / you can separate the 'machine' definition like this
<kori>yep, awesome
<kori>i'm gonna end up with something similar
<AwesomeAdam54321>a12l: Not really, it's because the build phases are run in a reproducible build environment set up by the guix-daemon
<kori>where can I read about the convention to prefix things with % (i.e. %base-packages)
<kori> its not here
<johny-cantwell>I am trying to build guix for pinebook pro.
<johny-cantwell>guix system distk-image pinebook-pro.scm
<johny-cantwell>I then get error
<johny-cantwell>no code for module (guix platforms arm)
<johny-cantwell>I am on an intel cpu running debian. Any advice?
<AwesomeAdam54321>johny-cantwell: It seems the (guix ...) namespace isn't in the load path
<johny-cantwell>What should I do?
<johny-cantwell>I am debian guy but trying to build pinebook image.
<johny-cantwell>I was unable to install guix with apt-src so I just did "apt-get isntall guix" then "guix pull"
<johny-cantwell>oh, I left out full filepatch in my earlier message, it was actually in /gnu/store/(hash-here)-guix-system-source/gnu/system/images/pinebook-pro.scm
<johny-cantwell>Also, it appears the pinebook image from the website lacks uboot
<johny-cantwell>because it will not boot.
<AwesomeAdam54321>How do I use a newer gcc/gcc-toolchain in a package definition for cmake-build-system?
<AwesomeAdam54321>I just had to add a newer gcc to the native-inputs
<apteryx>johny-cantwell: the doc suggests the bootloader u-boot-pinebook-pro-rk3399-bootloader should have been used
<apteryx>installed in the pre-9MiB gap
<apteryx>info '(guix) image-type Reference'
<johny-cantwell>Does anyone know how I can get ability to build for arm on my intel cpu debian laptop? To solve the issue of "no code for module (guix platforms arm) ?
<AwesomeAdam54321>johny-cantwell: You can run it in QEMU
<johny-cantwell>or on another ARM computer that already has an OS on it perhaps
<johny-cantwell>one more quesiton for now, is the build process for pinebook image from  reproducible? Possible for it to be backdoor-ed um-noticed by an adversary? There is no way to validate the output image, no signatures or anything
<johny-cantwell>and correction, I think uboot is working on that image
<apteryx>johny-cantwell: look for qemu-binfmt in the manual, to regitser the right ARM device
<apteryx>for transparent user emulation
<AwesomeAdam54321>johny-cantwell: The Pinebook image can be built yourself and you can compare it to the image there
<AwesomeAdam54321>There's `guix challenge` but I'm not sure if it does system images
<johny-cantwell>You've been helpful
<johny-cantwell>one more question, whole disk encryption on guix possible with luiks?
<AwesomeAdam54321>johny-cantwell: yes
<johny-cantwell>any guides?
<AwesomeAdam54321>There's information in the manual, the installer image can also do it
<AwesomeAdam54321>There's also the Guix Cookbook
<johny-cantwell>and yes, I verified again. the pinebook raw image does not boot, it lacks u-boot
<johny-cantwell>the one for download on guix website
<johny-cantwell>so maybe the pinebook .scm file does not actually work and has not been tested?
<johny-cantwell>that is what the automated build at I believe is using
<johny-cantwell>and pardon my noobishness, I'm still learning.
<rekado>gcc-toolchain 12.2.0 finally built on aarch64
<rekado>the build timed out before
<rekado>we should increase the timeout hints
<rekado>ACTION moves on to the next missing build
<mothacehe>hey guix
<sneek>Welcome back mothacehe, you have 4 messages!
<sneek>mothacehe, nckx says: I've updated & restart cuirass-r-w on both POWER nodes. I'll init your password tomorrow.
<sneek>mothacehe, nckx says: …which is Monday :)
<sneek>mothacehe, nckx says: For symmetry, I've added you (with same password) to and verified that you're able to sudo.
<sneek>mothacehe, nckx says: I've added the public key on berlin.
<mothacehe>thanks nckx! for some reason I have a "Permission denied (publickey)" on (assumed to be
<civodul>Hello Guix!
<cbaines>morning o/
<civodul>hey! so how's Nautilus today? :-)
<cbaines>I haven't checked yet, just pulling now :)
<omlet[m]>Its good ideal make the blog about guix in portuguese and spanish?
<AwesomeAdam54321>omlet[m]: Yes, feel free to do so!
<omlet[m]>My objetive os use the plume or other fediverse alternative for first
<omlet[m]>But WordPress in the future can
<AwesomeAdam54321>Just make sure it doesn't serve up nonfree JavaScript
<omlet[m]>AwesomeAdam54321: But yes, nonfree is only the small tutorials
<omlet[m]>Why i not use nonguix
<omlet[m]>But flatpak yes and appimage in general
<omlet[m]>But i think not is necessary speak about this
<omlet[m]>Is more about guix system
<rekado>on aarch64 vim keeps failing one of its tests
<rekado>okay to disable it?
<rekado>Expected range 0.001 - 0.01, but got 0.018705
<rekado>it’s always just a tad above the expected range
<AwesomeAdam54321>I guess so, since tests should test functionality, not whether it times out or not
<cbaines>rekado, it seems to have built on bordeaux, can you see an obvious difference in the logs?
<cbaines>looking at the recent builds for vim, none seem to have that failure
<rekado>I’ve attempted to build it three times on kreuzberg, and this one test keeps timing out
<rekado>could be dependent on load
<cbaines>what's the exact derivation you're building rekado, I'll try and reproduce?
<rekado> /gnu/store/w63rj256inmn81zhsa4vfyfkmq3gp3js-vim-9.0.0820.drv
<cbaines>thanks, I've submitted a couple of builds for it
<civodul>omlet[m]: the blog posts are are not translatable yet, if that's what you have in mind
<civodul>something we should fix!
<cbaines>rekado, both of those builds have now succeeded
<cbaines>what's the load like on kreuzberg?
<PotentialUser-27>Hello everybody, I'm quite new here and also with guix. Currently I'm playing with GuixSD and needed to install libpthread-stubs as a dependency with a precompiled binary. I tried guix install libpthreads-stubs but libtree an the binary shows that is not picked up. I found the lib on my disk but not as a link in .guix-profile. Can
<PotentialUser-27>you please tell me what I missed to make it work?
<civodul>PotentialUser-27: hi! you need to tell the loader where to look for
<civodul>this is usually done by setting LD_LIBRARY_PATH
<civodul>as in LD_LIBRARY_PATH=$HOME/.guix-profile/lib
<civodul>however, be careful with this: it will lead all binaries to pick .so files from there
<PotentialUser-27>Isn't the leoader configured to look into that profile by default on GuixSD?
<civodul>that will likely prevent binaries from the host distro (assuming you're using Guix on another distro) from running
<civodul>if it's a precompiled binary, it's likely using the loader of the host distro
<PotentialUser-27>I'm currentlky running GuixSD in a VM to see if I'll might switch to GuixSD
<civodul>now, you may want to try "guix shell --container --emulate-fhs" for this use case
<civodul>oh sorry
<civodul>well then yes, you still need LD_LIBRARY_PATH, or "guix shell --emulate-fhs" for this precompiled binary
<civodul>the latter is safer and cleaner
<PotentialUser-27>Hmm, seems that I have to read some more through the docs. But thanks for pointing me to that info!
<civodul>you can read about it here:
<rekado>cbaines: /proc/loadavg says: 16.46 11.77 8.46 20/997 24882
<cbaines>that doesn't seem that high, is it building other things?
<rekado>yes, it’s building other stuff
<rekado>29.16 17.75 11.10 37/1044 7041
<abrenon>hello guix !
<lechner>cbaines / Hi, does the Success/Warning/Fail column here indicate merely whether a patch can be merged, or potentially more? Thanks!
<cbaines>lechner, I wouldn't look at the patchwork checks, I should probably stop creating them. Instead look at
<lechner>cbaines / Wow, thanks! You are a powerhouse. (Btw, there are no colors in text browsers like EWW.)
<cbaines>lechner, haha, this has been years in the making!
<cbaines>lechner, I'll look at switching the patches page back to using CSS for the issue statuses, at that point, it should be easier to add in some symbols that make sense in EWW or similar browsers
<rekado>cbaines: it built fine this time
<rekado>it may be a good idea to relax the test or disable it. Not great that it can fail under expected loads.
<rekado>same with the gcc 12.2 timeouts. We should increase the timeout hints for aarch64.
<cbaines>rekado, sure, at least we're more sure it's load related now
<lechner>cbaines / i can also take a look maybe. Does the site link to a repo?
<cbaines>lechner, it does, on this page
<cbaines>lechner, I should have probably asked before I jumped ahead and did it, but I've added some symbols now, and that seems to work for me in links
<cbaines>there's probably plenty more issues to fix/improve though!
<cbaines>civodul, I was looking to push the qa-frontpage repository to Savannah, so that I'm not the only one who can push to it. I've forgotten how to create new repositories though?
<civodul>cbaines: you have to make a "support request" on Savannah
<civodul>i forgot how to do that though
<cbaines>civodul, thanks, I'll try and figure it out... :)
<civodul>fun: i can't log in on Savannah, i get silently rejected or something
<civodul>no error message, but then i'm just not logged in
<civodul>(i was going to search for a past request so you could see)
<civodul>is it just me?
<cbaines>civodul, I seem to be logged in, I've also found some previous requests
<civodul>ok good
<civodul>kinda weird i can't log in though
<civodul>maybe i got fired?
<cbaines>this isn't (insert billion dollar tech company) :D
<abrenon>have you signed for some "hardcore commitment" though ?
<lechner>cbaines / the symbols look great. thank you!
<lechner>civodul / technology isn't perfect!
<mothacehe>civodul: hey! i saw your changes to Cuirass, thanks! I plan to deploy a new version today on all workers, anything more to add?
<civodul>mothacehe: hi! i think i initially wanted to look at something else but i forgot why
<civodul>so don't wait on me i guess
<civodul>maybe something about inspecting build queues?
<civodul>i thought i had something more concrete in mind
<civodul>go figure
<civodul>i'm told there's a deadline today
<civodul>for the Berliners among us in particular
<civodul>("ich bin ein Berliner!")
<mothacehe>ok, feel free to share if you remember :)
<mothacehe>i created an images-version-1.4.0 specification on Cuirass
<mothacehe>to share installer images
<mothacehe>but your rc1 suggestion is maybe better
<efraim>looks like we're missing a linux-libre-arm64-generic-5.15 kernel. I'll see if it's my OS config and what I can get done with my pinebookpro, but it's getting disheartening
<klm_>On the latest guix (d7ba488d3505ba6), I'm getting a compile error for `guix build dxvk`. Bug, or am I doing something wrong?
<omlet[m]><civodul> "omlet: the blog posts are https:..." <- Make the personal blog about guix
<omlet[m]>Same ubunlog
<omlet[m]>But guix replace ubuntu
<civodul>mothacehe: yeah, an RC would allow us to test the whole process
<omlet[m]>Unofficial guix blog
<civodul>it's more tedious, but closer to what we'll do
<civodul>omlet[m]: ah sure
<cbaines>woo, the texlive-mathdots package here has even been built for the Hurd!
<omlet[m]>How is the best service to host?
<civodul>cbaines: woow, neat!
<cbaines>I'm just making a pass through merging some of the green ones now :)
<ennoausberlin>When I comment issues on it is not listed afterwards . Is this normal behaviour and will someone read it it anyway?  I want to communicate that racket 8.7 is not built for aarch64 due to missing csh. The racket maintainers told me it is supported on aarch64
<cbaines>ennoausberlin, are you using the comment box, or sending an email?
<ennoausberlin>comment box
<cbaines>hmm, sending an email might be more reliable. I'm not sure how the comment box works, or if it's enabled.
<rekado>it sends an email, too
<ennoausberlin>rekado: I am behind a company proxy. Maybe thats a problem.
<rekado>when an issue is archived on the debbugs side I don’t think the comment box works
<ennoausberlin>cbaines: Ok. I will send an email then
<ennoausberlin>rekado: I commented here:
<ennoausberlin>rekado: But it is not visible. I will send an email later this day
<mothacehe>the cuirass database has a very large number of pending builds (268013) which makes all queries super slow.
<mothacehe>i'm trying to cancel them all
<mothacehe>but it takes ages for some reason
<rekado>ennoausberlin: bunch of errors in the logs for mumi.mailer
<mirai>Is the subject prefix value read by machine or is it just for readers convenience? (talking about using 'git send-email' to guix-patches)
<mirai>I'd like to send a "draft" patch
<mirai>would a subject prefix 'PATCH wip' or 'WIP' be ok?
<civodul>mothacehe: ah! would be good to see why they're not being queued
<civodul>mirai: "PATCH WIP" i guess, but please make it clear in your message what's missing or what you'd like people to help you on
<mothacehe>civodul: i think that they we not queued because their workers were hanging due to server going offline, but it should now be fixed
<mothacehe>however that's a very large number of builds for very few workers
<mothacehe>kreuzberg deploy fails due to git-minimal build timeouting on aarch64
<mothacehe>and reconfiguration fails due to guile-gnutls build error
<mothacehe>nckx: i installed cuirass-1.1.0-13.1341725 on guixp9
<rekado>I’m currently building guile-gnutls with “--cores=1” to see if it fixes things
<rekado>(on kreuzberg)
<civodul>mothacehe: maybe we can delete old builds and keep recent ones?
<rekado>tls13-resume-x509 still fails :(
<cbaines>haha, so the comment at the bottom of emacs-xyz.scm seems to be working, I'm not seeing new packages added at the bottom
<cbaines>but instead, they're being added just above the last package :D
<cbaines>so maybe we need a comment there that says "not here either..."
<civodul>rekado: do you have a log?
<rekado>the build log is /var/log/guix/drvs/5s/1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv.gz
<rekado>cbaines: :)
<apteryx>sneek: later tell mirai also, preferably sent WIP patches to guix-devel, not guix-patches, to avoid crowding the queue with non-reviewable work
<sneek>Will do.
<apteryx>(or rather, work not ready for a final review)
<cbaines>apteryx, we already have plenty of blocked stuff on guix-patches, so I'm not sure that matters
<cbaines>my main preference is that patches for things other than guix.git go to guix-devel
<cbaines>(e.g. guix-artwork or guix-maintenance patches to guix-devel)
<rekado>ACTION agrees with cbaines
<apteryx>cbaines: yes, items blocked for a long time (moreinfo) are a problem also
<jgart[m]>* jgart agrees with rekado
<apteryx>ACTION personally wastes time going through non-actionable items on the patches tracker
<cbaines>apteryx, that is a problem, but we need to come up with approaches for that anyway
<cbaines>I've been using the moreinfo tag to mark things that aren't ready to be merged
<cbaines>that factors in to the ordering/status here (the orange ones are often tagged moreinfo)
<apteryx>that's useful, thanks.
<cbaines>I'm not sure we'll ever be able to stop going through non-actionable items, but hopefully we can get to a point where only one person does it, then everyone else can skip on to other hopefully actionable things
<apteryx>I guess we could have a policy for items waiting too long on feedback: close if the changes are too great to pursue, else the changes can be made by the reviewer
<apteryx>cbaines: about ready to be reviewed items, do you think could apply some user tag (with user "guix") to debbugs? such as "ready-to-review" or similar
<cbaines>apteryx, potentially. I think we're getting close enough to having actionable information (e.g. these changes causes this package to fail to build, introduce this lint warning, ...) that we could be sending emails to issues
<yarl>Hello guix!
<gnucode>hello yarl!
<apteryx>I typically gnu-debbugs in Emacs to view items; it'd be nice to have something exposed there
<cbaines>so yeah, maybe along with that there could be some tags relating to what state the changes are in
<jgart[m]>cbaines: here's a longstanding patch by disseminated dissent that I think would be easy to merge
<jgart[m]>If you find the time to review it
<yarl>gnucode: I saw the other day you had some problems to produce latex with org-mode? I do that. Do you still have problems?
<yarl>Try to tell sneek to tell you but he was sleepy.
<jgart[m]>it's from jan 4
<cbaines>jgart[m], if it's still open when I do my next round of patch review, I'll take a look
<cbaines>and thanks for flagging it!
<jgart[m]>no probs, I just happened to come across it
<jgart[m]>and I mentored disseminated dissent on that patch a bit
<jgart[m]>he's was a new contributor and guix user at that time
<apteryx>this should return the list of all element user-tagged in guix-patches, if I understand correctly: (debbugs-gnu '("tagged") '("guix-patches") nil t)
<apteryx>I get only two items returned though, which is suspicious
<yarl>I wonder if it is possible to package or write a system configuration that runs a php application that needs to be in a read-write directory?
<yarl>without manual copying.
<yarl>How one would do that?
<mirai>Exactly which address should I use for multiple patches? The 'Multiple Patches' section mentions '' but the commands are all for '' ?
<sneek>Welcome back mirai, you have 1 message!
<sneek>mirai, apteryx says: also, preferably sent WIP patches to guix-devel, not guix-patches, to avoid crowding the queue with non-reviewable work
<mirai>and involves invoking '$(etc/teams.scm cc-members ...)', which wasn't required for the single-patch case?
<mirai>apteryx: does guix-devel also use debbugs? Do I need to do some special dance with git format-patch/send-email before sending?
<lechner>mirai / i think they want you to use git send-mail
<lechner>mirai / like this
<apteryx>mirai: guix-devel doesn't use debbugs no
<apteryx>mirai: how man commits do you have? you could simply attach them to the email as attachments (after producing them with 'git format-patch')
<mirai>apteryx: It's 1 but it has a "cover mail"
<mirai>so for guix-devel I can just straight away do git send-email?
<mirai>apteryx: thanks
<apteryx>can an operating system declaration in a .scm file accept arguments from the command line? 'guix deploy my-os.scm some-arg'
<apteryx>I guess not.
<lechner>that does not seem very declarative
<apteryx>it's declarative, with bits declared from the command line ;-)
<lechner>apteryx / actually, deploy does not take an operating-system argument. it takes a list of machines. maybe you can refactor that to your need similar (in principle) to this
<mirai>how do I invoke programs that are usually installed to /sbin/ ?
<lechner>mirai / from the shell or from another program (for packaging)?
<mirai>lechner: thing is, guix has no /sbin
<lechner>mirai / it has a thousand. they are on your PATH
<mirai>I can't call ras-mc-ctl
<mirai>and rasdaemon is not only installed but also enabled as a service
<lechner>mirai / you probably have to install it in your profile, too.
<apteryx>lechner: right, I meant s/deploy/system reconfigure/, apologies for the confusion
<mirai>lechner: right, doing it as root did the trick
<mirai>though I get an interesting error
<mirai>bash: /root/.guix-profile/sbin/ras-mc-ctl: /usr/bin/perl: bad interpreter: No such file or directory
<apteryx>has anyone gotten a yubikey nano working in ungoogled-chromium?
<apteryx>mirai: the executable would need their perl shebang to be patch as part of its packaging
<lechner>mirai / you may wish to try something like (string-append package-name "/sbin/ras-mc-ctl") in your config
<lechner>mirai / the Perl thing looks like a packaging error
<mirai>lechner: from the 'root' user perspective, its not enough to have '(rasdaemon-service-type)' under 'services' in the 'operating-system' declaration? Do I also need to add 'rasdaemon' to 'packages'?
<lechner>mirai / that will make it available to everyone. you could also do 'guix pull' as root followed by 'guix install rasdaemon' i think\
<lechner>mirai / the 'packages' approach is probably better
<lechner>mirai / but a truly declarative approach should not require a root user at all (except for halt and reboot)
<civodul>nckx: did you have any success with libreoffice on i686?
<rekado>civodul: looks like kreuzberg’s disk is also about to fail
<rekado>just opened an RMA claim for grunewald’s disk
<civodul>rekado: bah, no luck!
<rekado>smart reports are on in /root
<PotentialUser-30>Hi, asking this forum is like a drug... :-)
<PotentialUser-30>I trty to compile and got: Run-time dependency qt5 (modules: Core, Gui, Qml, Quick) found: NO (tried pkgconfig and config-tool and Program moc-qt5 moc found: NO
<civodul>rekado: i deployed the new /etc/guix/machines.scm on berlin
<civodul>(via reconfigure)
<PotentialUser-30>But i think qt is in the /gnu/store. Any ideas what to add?
<rekado>PotentialUser-30: think of /gnu/store as a garbled cache. You still need to have a pointer into that cache to make sense of it.
<rekado>so when you compile you need to be in an environment that exposes items in /gnu/store to the tools in your environment
<rekado>(via environment variables, usually)
<PotentialUser-30>So i should install qtcore for example?
<rekado>how do you compile?
<rekado>is this a Guix package or a “manual” compilation?
<PotentialUser-30>guix build -K -L /home/joe/guix-pakete/ gst-plugins-good-qt
<rekado>so a Guix package definition
<rekado>a Guix package definition should fully describe the environment in which compilation happens
<PotentialUser-30>A variation of st-plugins-good
<rekado>it is — by design — unimpressed by whatever you may have installed on your system
<PotentialUser-30>But it complains about missing qt...
<unmatched-paren>PotentialUser-30: please show the pkg definition
<PotentialUser-30>Here we go:
<apteryx>PotentialUser-30: there's no qtcore, it's called qtbase
<unmatched-paren>PotentialUser-30: i think you need to add (inputs (modify-inputs (package-inputs gst-plugins-good) (prepend qtbase-5)))
<unmatched-paren>and also #:use-module (gnu packages qt)
<PotentialUser-30>OK. Already tried (gnu packages qt) - that made no difference. But i'll try plus the code above...
<unmatched-paren>#:use-module (gnu packages qt) will not change your package definition...
<unmatched-paren>it's basically like ``from gnu.packages.qt import *''
<PotentialUser-30>OK.Let's see what happens...
<unmatched-paren>PotentialUser-30: your inputs are basically the dependencies of the program
<unmatched-paren>there's propagated-inputs (bad bad bad), native-inputs, and inputs
<PotentialUser-30>Aaah. I pulls qtbase...
<unmatched-paren>the difference between native-inputs and inputs is that when you cross-compile, the inputs are built for the target arch, and the native-inputs are built for the host arch
<PotentialUser-30>OK. This one looks good: Program moc found: YES (/gnu/store/w4rzq607irbr3xn90n8vq0hy3snnkrnc-qtbase-5.15.5/bin/moc
<unmatched-paren>so you need to make sure anything used at runtime is an input, since it'll be used on the target arch
<lechner>unmatched-paren to the rescue!
<PotentialUser-30>But how about that? Could not find: Qml Qt5Qml in /gnu/store/w4rzq607irbr3xn90n8vq0hy3snnkrnc-qtbase-5.15.5/lib  AND Run-time dependency qt5 (modules: Core, Gui, Qml, Quick) found: NO
<unmatched-paren>and anything used at build-time is a native-input, as it needs to be able to run on the arch that the program is being built on, not the one it's being built for
<unmatched-paren>lechner: :D
<unmatched-paren>PotentialUser-30: there are a bunch of other qt packages you'll need to add to that (prepend ...)
<PotentialUser-30>Perhaps the same game. I think i should do little research myself now first...
<unmatched-paren>qtdeclarative-5 might be qml/quick, i think?
<unmatched-paren>add that to prepend
<unmatched-paren>so (prepend qtbase-5 qtdeclarative-5)
<PotentialUser-30>Looks much better now - but Run-time dependency qt5 (modules: X11Extras) found: NO but not sure if really needed. I'll try first...
<unmatched-paren>PotentialUser-30: add qtx11extras-5 then
<PotentialUser-30>qtx11extras-5: unbound variable I think there is a module for this?
<unmatched-paren>PotentialUser-30: ohh, there's no -6 variant, so it's just qtx11extras
<PotentialUser-30>OK. Looks really good now - only wayland missing but i do not want that! So thanks again a lot for today!! :-) You are very kind guys !!
<unmatched-paren>PotentialUser-30: i think if it has an optional wayland dependency you should probably add qtwayland-5
<unmatched-paren>even if you don't personally want to use wayland with it
<lechner>Hi, in the system config, is there way to declare network being up as a prerequisite for an NFS file-system?
<mirai>What does the 'REVISION' parameter stand for in "git send-email -1 -a --base=auto -v REVISION" (from 22.6.2 Sending a Patch Series)
<unmatched-paren>mirai: the version of the patch set
<lechner>should we use that?
<unmatched-paren>e.g. the second revision of the patch set is ``-v 2''
<mirai>lechner: I'm also interested in knowing this, though I am using network-manager
<unmatched-paren>it puts a little v2 in the [PATCH ...] prefix
<lechner>mirai / i am also on network-manager, but in the process of switching to connman
<unmatched-paren>lechner: for connman you need to (1) add the service-type (2) run ``sudo connmanctl'' to run the console
<unmatched-paren>(3) do ``agent on'' (4) run ``enable wifi'' (5) figure out what your network interface is with ``ip link show''
<lechner>unmatched-paren / i haven't tried yet. i am currently reading up on all the changes i am about to make
<unmatched-paren>``ip link show'' is in the regular shell
<lechner>unmatched-paren / do i need to run connmanctl or will it auto-connect eth0 when mii is detected?
<mirai>unmatched-paren: strange, am I missing something?
<unmatched-paren>(6) do ``scan wifi'' in connmanctl (7) do ``services'' to display networks
<unmatched-paren>lechner: oh, for ethernet i'm pretty sure you don't even need connman or wpa-supplicant...
<unmatched-paren>anyway, the big wifi_* thing next to the network is the network code, so do ``connect wifi_*''
<unmatched-paren>then it'll ask you for your password, and it'll be permenantly added to auto-connectable networks
<unmatched-paren>so to add a new network just do ``agent on'', then ``services'', then ``connect SERVICE''
<unmatched-paren>mirai: hmm...
<unmatched-paren>mirai: do you have git:send-email installed?
<mirai>the manpage / git send-email --help has no mention on what this '-v' flag does btw
<unmatched-paren>git format-patch's manpage does
<mirai>hmmm... I did a git commit --amend
<mirai>does that affect things?
<unmatched-paren>that won't affect this
<unmatched-paren>that's just how you squish HEAD and HEAD~1 together
<unmatched-paren>i am confused
<unmatched-paren>-v used to work, i swear
<unmatched-paren>did they remove it for $reason...?
<mirai>?? Look at this output
<mirai>I reordered the argument
<mirai>'-v' vanishes from format-patch
<unmatched-paren>seems to work if i replace -1 with HEAD~
<mirai>do you also experience the same issue?
<unmatched-paren>this is very strange
<unmatched-paren>i ohh
<unmatched-paren>do you have a -1 file in the cwd?
<unmatched-paren>i think the problem here is that you create -1 with that <>
<mirai>that <> is just placeholder for email
<unmatched-paren>so it treats it as a file :D
<mirai>I don't have any '-1' file in cwd
<unmatched-paren>oh, yeah, i still get the same issue
<unmatched-paren>mirai: have you tried -v2 instead of -v 2?
<mirai>-v2 seems to work
<mirai>at least I have an editor now
<mirai>but that shouldn't matter (
<mirai>looks like a bug to me
<mirai>though reporting this to 'git' looks like an obtuse process
<apteryx>hmm, guix has been updating the linux git checkout for 96 minutes (attempting to do kernel bisect tests using git-checkout)
<efraim>follow-up to my comment earlier, looks like my qemu-binfmt-service-type might've been causing me trouble
<apteryx>civodul: seems guile-git/libgit2 is showing their limits on such a massive repository as the linux kernel :-) ^
<PotentialUser-30>unmatched-paren: YESSS. Now i have the wanted * !
<unmatched-paren>PotentialUser-30: nice!
<unmatched-paren>PotentialUser-30: perhaps we could upstream this package
<PotentialUser-30>That would be a pleasure for me !
<unmatched-paren>PotentialUser-30: have a look at
<unmatched-paren>and ask me if you have any questions :)
<PotentialUser-30>Sounds good !
<apteryx>is there an equivalent of --with-source= for an origin? git-checkout is too wasteful/expensive
<PotentialUser-30>unmatched-paren: Should we do an additional nheko-qt or expand the old nheko with the "new" (in case it really works as intended) Perhaps its to much bloat for some people...
<PotentialUser-30>Actual it would be only the "-Dgst-plugins-good:qt5=enabled thing...
<unmatched-paren>PotentialUser-30: i'm not sure exactly what this nheko-qt would do?
<unmatched-paren>doesn't nheko use qt anyway?
<PotentialUser-30>Yes. Thats why i asked. But the maintainer missed the -Dgst-plugins-good:qt5=enabled so there is no video call in nheko...
<efraim>does anyone use the qemu-binfmt-service on aarch64?
<unmatched-paren>you'll probably want to just modify the default nheko
<PotentialUser-30>Thats what i think is the best ! (my unexperienced opinion)
<unmatched-paren>PotentialUser-30: make sure to split "Add gst-plugins-good-qt" and "nheko: Support video calling" into two different commits
<unmatched-paren>PotentialUser-30: like this:
<PotentialUser-30>Ää sorry i was unprecise: We only have to modify the gst-plugins-good with the -Dgst-plugins-good:qt5=enabled and we have nothing to do with nheka as i understand...
<unmatched-paren>PotentialUser-30: problem is that we probably don't want gst-plugins-good to depend on qt by default
<unmatched-paren>so i think it's good to have a -qt variant
<apteryx>it probably already does but that's going to have to be cleaned up at some point
<apteryx>gtk4 depending on qt is ugly
<unmatched-paren>and then you use that in nheko instead of gst-plugins-good
<unmatched-paren>apteryx: where does that dependency actually come from?
<PotentialUser-30>How is the "mechanism" for the user to choose if -qt or not?
<apteryx>gtk4 wants a bunch of gst-plugins-* IIRC
<apteryx>they're "optional" but most distros include them so that would make our own gtk version crippled compared to what's expected
<unmatched-paren>PotentialUser-30: we modify the nheko package to depend on -qt instead of non -qt
<apteryx>it's been a while I looked at it, so you're welcome to have a look for a fresher idea
<unmatched-paren>"break video calling?" should not be a feature flag
<unmatched-paren>apteryx: and the gst-plugins-* want qt?
<apteryx>this is just because we weren't concerned being careful before gtk4 appear. it doesn't have to. some dependencies can have their qt support split into another package, but there were a bunch of them
<apteryx>but funnily, from past investigation currently gtk4 in debian also pulled qt, unless they fixed that
<Fare>Can I somehow use my beefy i686 as a build farm for my aarch64 devices?
<Fare>weird: it looks like I managed to get my yubikey working for all purposes... except using google on chrome!
<sarahjones>What do I need to do to get pinebook pro image from guis website to boot? I have a clear emmc chip and have it disabled. I know the issue is lack of u-boot. Does the image from website not contain u-boot?
<sarahjones>Attempting it from an sd card.
<sarahjones>I also tried other SD cards, SD card is fine.
<sarahjones>former image used to work from guix website. newest one from earlier today is not booting anymore. I also have two pinebook pros I attempted on, in which it was booting yesterday from sd card
<apteryx>podiki[m]: thanks to the hint about yubikey/udev rules. I was able to make it work with libfido2 following your instructions!
<podiki>apteryx: glad it worked! I have to update my config to libfido2 as well (and hello from emacs, my matrix server is feeling unwell at the moment)
<podiki>apteryx: regarding the doc update (which overall looks good to me), did you find plugdev necessary? I have it in the udev rules but not my user for some reason
<omlet[m]>My blog in portuguese
<omlet[m]>After, tutorial about the guix in portuguese
<omlet[m]>I want translate for spanish
<omlet[m]>But no with google
<lechner>sneek: later tell unmatched-paren: Hi, does gvfs require elogind? I saw you have MTP. Do you also have user mounts in your setup? Thanks!
<sneek>Got it.
<lechner>sneek / botsnack
<unmatched-paren>lechner: (1) dunno (2) nope
<sneek>unmatched-paren, you have 1 message!
<sneek>unmatched-paren, lechner says: Hi, does gvfs require elogind? I saw you have MTP. Do you also have user mounts in your setup? Thanks!
<unmatched-paren>ACTION away, \o
<lechner>unmatched-paren / thanks!
<apteryx>podiki: ah! I didn't test without it on my user. I guess if it works for you without it, it must be unncessary.
<podiki>apteryx: I didn't try your chrome test though, I can when I'm back at that computer
<podiki>and is pcsc service then only needed for the gpg key device functions, not for u2f?
<podiki>I'll have to try with libfido2 and no plugdev spec in udev rules (not sure where I got that, if my user isn't in that group anyway...)
<lechner>Hi, do we track prerequisites between services? I see guix deploy: error: failed to deploy lechner-desktop: service 'guix-publish' requires 'avahi-daemon', which is not provided by any service
<unmatched-paren>lechner: you just need to add avahi-service-type
<unmatched-paren>which provides a shepherd service that provides the service symbol 'avahi-daemon
<lechner>unmatched-paren / thanks!
<civodul>mpv broke for me
<apteryx>there's a patch adding libxpresent supposed to fix it
<apteryx>haven't had the chance to test it yet
<civodul>ah good, so no need to report a bug
<apteryx>there's both a bug and a patch, I think
<apteryx>make sure you close both if you get to apply/test it
<civodul>i was thinking i'd wait and pull & retry later :-)
<civodul>but yeah, we'll see
<civodul>ACTION occasionally puts an "end-user" hat on
<apteryx>podiki: haven't dabbled with gpg yet, but I'd guess it's only needed for that, yes
<lechner>unmatched-paren / I did not add wpa-supplicant-service-type, but now see guix deploy: error: failed to deploy lechner-desktop: service 'networking' requires 'wpa-supplicant', which is not provided by any servic
<panosalevro>has anyone installded guix with ventoy?
<apteryx>would someone have a suggestion to bisect linux kernels? I've define some glue in my config file that should be able to use the local checkout, but so far my experiment poiting to the source via git-checkout results in 3 GiB of RAM used and seemingly never-ending processing.
<Fare>If I modify a checkout of guix and/or my channel extension to it, how do I test a package change without making a commit?
<nckx>civodul: Not yet. It took so long to build I couldn't test it then :-( It should be sitting on the server by now, or its failure log is.
<civodul>just to clone the thing with guile-git?
<civodul>nckx: alright, thanks for testing
<apteryx>linux kernel with bot torvalds and stable remotes fetched
<nckx>panosalevro: Should work, bug reports welcome.
<apteryx>civodul: I let it run like 2 hours then got fed up with it and C-c'd
<civodul>apteryx: sounds like something's not right
<nckx>civodul: No, I will actually test, I just haven't yet. Any changes?
<civodul>no idea
<nckx>ACTION fone.
<civodul>apteryx: i'm not surprised it takes times (it's a full clone), but 3G of RAM means something's wrong
<civodul>or it's a serious limitation of libgit2
<rekado>Fare: use ./pre-inst-env
<apteryx>civodul: can you think of a way to use the equivalent of --with-source in place of an origin?
<panosalevro>nckx: i have tried 3 different guix images on ventoy and none of them work. im only using it because my BIOS doesnt seem to detect my usb unless i use ventoy. ive spent quite a few hours trying to install guix today with no luck. ive managed to install guix before without problems so im not sure whats going on
<apteryx>If it could just copy the whole checkout to my store, that's probably going to be faster
<Fare>reka: uh? should my channel have its own copy of pre-inst-env, or should I build guix's ?
<rekado>Fare: for your channel use GUIX_PACKAGE_PATH or use “guix build -L /path/to/your/channel/modules”
<nckx>panosalevro: Oh no. Can you give more details than 'no[ne of them] work'?
<nckx>What actually fails?
<nckx>1.3.0 definitely works.
<panosalevro>nckx: let me try 1.3.0 again
<apteryx>nobody uses a veneable nvidia 8800 GTS with their Guix System?
<a12l>How do I apply a patch on a package that's only intended for myself?
<nckx>The only Ventoy-relevant improvement since 1.3 was, I believe, a longer time-out for buggy USB controllers.
<panosalevro>nckx: ok, so it throws a bunch of ACPI BIOS errors "Failure creating named object", then "#### INIT NOT FOUND ####" and finally "/ventoy/busybox/sh: can't access tty: job control turned off". that's immediately after grub
<panosalevro>any ideas?
<apteryx>ACTION has rebuilt mutter twice today, wonders why
<nckx>panosalevro: No good ones (note that I'm currently without computer, so I can't even grep gud). What's the sha256 of the Guix 1.3 iso on the device?
<apteryx>podiki: for the pscd stuff, we could add another subsection catering to the gpg use case
<apteryx>if what's needed is clear in your mind :-) I'd be interested to try that out too
<podiki>apteryx: I think I only needed pcsc service, I didn't need the udev rules before some months ago (no idea what changed)
<panosalevro>nckx: eb9212f3037.....48eab96d
<podiki>for both gpg card and as u2f/fido device
<nckx>If 'INIT NOT FOUND' is legitimate, it never even makes it to booting Guix. That is not a Guix error.
<Fare>redako: thanks a lot!
<nckx>panosalevro: sus.
<a12l>What's the difference between `guix pull` and `guix upgrade`? Can't find a distinction in the manual
<podiki>apteryx: recently got a yubikey or similar? I use it as my gpg device for pass words, encryption, all that
<panosalevro>nckx: interesting, i downloaded the image from guix website
<panosalevro>nckx: also, ventoy worked when installing artix just fine
<podiki>a12l: pull just updates guix and package definitnions, upgrade upgrades your user packages to the new versions from a guix pull
<a12l>podiki: Aha, thanks! So similar to apt's `apt update` and `apt upgrade`?
<podiki>a12l: been many a year since I apt-ed anything, but I think so?
<nckx>panosalevro: That is expected. Artix wasn't corrupted. 😉
<a12l>This line made me think that it both updated the package descriptions, and installed them
<a12l>"To update that distribution, along with the Guix tools, you must run guix pull: the command downloads the latest Guix source code and package descriptions, and deploys it."
<podiki>apteryx: I'll confirm the plugdev question on my computer later and respond on the patch you submitted. and it's a great idea, it is a FAQ I think
<nckx>Just download the ISO again and check the sha256 before booting.
<nckx>It should match the one I linked to above.
<podiki>a12l: perhaps something to improve then; but guix is also things like guix shell, temporary using packages, etc.; I often pull but only upgrade rarely
<apteryx>podiki: sounds good, thanks!
<a12l>podiki: Wait, why do you upgrade rarely?
<panosalevro>nckx: you're right, ill check the sha256 in my next attempts. but ive downloaded the image so many times and guix's server is so slow the speed caps at 200kbps/s
<panosalevro>nckx: btw the 1.2.0 also has ACPI BIOS errors but results in a kernel panic
<a12l>Can you use an `operating-system` declaration with Guix Home? I'm trying to add a substitution server, but I can only find documentation for how to add it to an `operating-system` declaration.
<nckx>panosalevro: Then the 'errors' probably aren't a problem. They happen on most systems.
<nckx>I have no idea if Ventoy supports 1.2. Not worth debugging IMO, since we know 1.3 should work. (And 1.2 is even more ancient.)
<lechner>when committing to master/staging/core-updates, it sometimes seems that the thresholds should not be fixed package counts but rather be weighted by how likely people are to actually use those dependent packages, and also by the burden incurred at the local level (such as likely compilation time, relatively speaking). the substitute servers might also benefit from such a change.
<apteryx>texinfodocs documentation target applied to the kernel o/
<a12l>Why do I get the message "guix upgrade: warning: nothing to do" when running `guix upgrade`, if `guix pull` don't actually upgrade packages?
<nckx>Missing argument to 'guix upgrade'?
<panosalevro>nckx: ok 1.3.0 it is then. is there a torrent i can use to download its image?
<nckx>It could print a hint that it expects a regexp and that '.' matches all packages, a12l.
<nckx>panosalevro: No idea.
<panosalevro>nckx: thanks anyway :)
<nckx>panosalevro: Try tobias dot gr / guix-system-install-1.3.0.x86_64-linux.iso
<podiki>a12l: well I keep an eye on what is updated and will do a full upgrade (I use multiple profiles) and a system reconfigure, it just is not every day like I have in my past
<a12l>nckx: Should I run `guix upgrade .` if I want to upgrade all my installed packages? If yes, I still get the same message
<apteryx>a12l: or just 'guix upgrade'
<nckx>Hm. Yes you should.
<apteryx>nckx: I don't think '.' is required for 'guix upgrade' at least I've never used it.
<panosalevro>nckx: what link is that? it returns a 404
<a12l>I get "guix upgrade: warning: nothing to do" both when I run `guix upgrade` and `guix upgrade .`
<nckx>Does your user *have* packages installed?
<nckx>If you have no packages there's nothing to do.
<podiki>try a guix package --list-installed to find out
<nckx>Try guix package -I .
<a12l>nckx podiki: Only `glibc-locales` is listed
<nckx>apteryx: No idea. Hence '?'. Good if so!
<nckx>If it's up to date there's nothing to do.
<a12l>But I've a list of around 15--20 packages in my `guix home` config.
<a12l>Which is installed
<nckx>'guix home' is something else.
<nckx>It has its own command, I dunno what it is.
<podiki>probably: (like system reconfigure, to update the home environment)
<nckx>panosalevro: Works here.
<nckx>Just my copy of the ISO.
<a12l>From what I understand I should run `reconfigure` when I want to apply a configuration change from my configuration file, but from what I know updating packages are done outside of that.
<nckx>It's the same thing.
<podiki>sorry, also not a guix home user, so I don't know the details for packages in that sytem
<nckx>It's like 'guix system reconfigure'. Both mean 'build me a new system (using the current guix version) described by this configuration, and switch to it.'
<a12l>nckx: It seems that you're right. Packages are being updated
<podiki>so in this case that would include packages installed in that configuration (just like guix system), to get to a12l's question for upgrading guix home packages I think
<nckx>While 'guix upgrade' sort of emulates an old skool PM, but only in your user profile (well, by default.)
<podiki>yup, so guix system configuration and guix home configuration manage services but can include pages to install
<a12l>Thanks for the help!
<nckx>ACTION is always sometimes right.
<podiki>and as nckx says, you can also install packages to other profiles (like for development environments or for keeping things separate for organizational or other purposes)
<podiki>better always sometimes right or sometimes always right?
<a12l>I'll try to submit patches to the docs that clarifies this when I've more time. The docs didn't make it clear to me at least.
<nckx>panosalevro: Did you delete the spaces and replace the dot? I just don't want spiders fetching a 700M file.
<a12l>Now I understand why you don't run `guix upgrade` so often :)
<nckx>(This chan's log'd.)
<podiki>patches/questions/suggestions from new users on these areas always welcome! if you don't have the full patch process figured out, you can submit what you were confused about at least
<nckx>podiki: Always definitely confused now.
<panosalevro>nckx: it's okay, i found an image with a good signature. lets see
<podiki>a12l: depends what you use, most of what I have now is pretty stable, so I tend to upgrade quickly for things like new browser versions (security)
<podiki>ACTION here not here for a while
<nckx>panosalevro: You should at the very least get a *different* error, but it should really just work.
<panosalevro>nckx: crap. same error
<nckx>The only known bug is that short-ish time-out I mentioned above, which I think I increased on master.
<nckx>Well hm.
<nckx>And the ISO on the USB definitely matches that checksum now?
<panosalevro>nckx: im about to check that
<nckx>I'm repeating myself, sorry, but this means Guix never even gets a chance to boot. The GRUB you mentioned, is it Ventoy's or Guix's?
<nckx>* last GRUB
<panosalevro>nckx: checksum is different again but the signature was good? i dont get it
<panosalevro>nckx: that's a good question, how do i check that?
<nckx>Did you verify the signature of the ISO *on the USB*?
<panosalevro>nckx: yes
<nckx>I frogot to add: after un- and remounting it? If the device is bad, you might just be reading the good cached data in RAM, not what was written.
<nckx>The fact that you keep getting bad csums implies a broken device.
<panosalevro>nckx: hmm. lets try another usb stick then
<nckx>panosalevro: Check the signature? Same way you did it before copying the ISO. But with the file on the USB drive. If that wasn't the question I dudn't understand.
<nckx>ACTION thumbs getting tired :)
<panosalevro>nckx: now i understand what you mean. i checked the signature on my hard drive and the signature was good. now that i tried on the usb, it returns a bad signature
<panosalevro>nckx: i didnt know that can change
<nckx>Ah, you probably meant GRUB. Guix's GRUB has a big honking Guix logo on it.
<Fare>is the Guix logo some devil's horns?
<nckx>panosalevro: Yeah, damaged bits will change the hash (and a signature signs the hash).
<nckx>Fare: Yes.
<panosalevro>nckx: it's definitely the same file and it returns a bad signature on the usb stick. now lets try with a brand new usb stick
<nckx>Oh noes, it still says GuixSD.
<nckx>panosalevro: 🤞
<panosalevro>nckx: is your website?
<Fare>nckx, lol!
<panosalevro>nckx: are you greek?
<nckx>No. It's just a domain hack. My initials are TGR.
<panosalevro>nckx: ah ok :)
<nckx>Are you?
<panosalevro>nckx: yep
<panosalevro>nckx: i've used a .ca domain for similar purposes (i love domain hacks)
<sarahjones>anyone successfully get guix working on pinebook pro? Image from website does not boot, I think it is failing to include u-boot.
<Fare>the best domain hack was
<nckx>panosalevro: I got the 'idea' from Sacha Chua. 'Wait a minute', I thought, big-brainedly, and checked a registrar. I couldn't believe it was free.
<panosalevro>nckx: you .gr for free? that's cool
<nckx>I meant 'available'. But it's cheap.
<panosalevro>nckx: (i realized what you meant after i sent that msg)
<panosalevro>nckx: checksum is good on the new usb stick! crossing fingers...
<nckx>Please just boot please just boot.
<apteryx>nckx: "thruth"
<nckx>I don't remember if that was part of the joke^Wconspiracy, or if I was just in a hurry to post it. It's old.
<panosalevro>nckx: checksum is all good. but i just get kernel panic :/
<pkill9>wow nckx you are onto something, perhaps Guix wasn't bestowed upon us by Prometheus after all, but Baphomet, in an attempt to restore the balance between proprietary and free software
<panosalevro>nckx: and it's definitely guix grub
<nckx>OK, but that's (I know it doesn't feel like it) progress. It's booting Guix's kernel. It didn't before. What's the stated reason for the panic?
<nckx>pkill9: I'm glad someone finally takes it seriously.
<nckx>panosalevro: I have to go be social and shit. Sorry. Good luck 😕
<panosalevro>nckx: "GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread", "GC Warning: Couldn't read /proc/stat" ... "Warning: compilation of /ventoy/init failed" then kernel panic
<panosalevro>nckx: no problem, thanks a bunch! where should i file a bug for this?
<Fare>When does guix transitively rebuild from source vs graft new libraries on existing binaries? How do you control the difference?
<panosalevro>is bug-guile AT gnu . org the correct address to file bugs? or does guix use something else?
<pkill9>I wonder how many more KDE libraries need to be added in order to add the KDE desktop environment
<pkill9>since guix already has a bunch of KDE software, and I noticed plasma bigscreen just got added
<pkill9>oh wow it's been added now
<pkill9> plasma desktop :O
<a12l>How do I apply a patch on a package that I've installed using `guix home`? The patch is only intended for myself.
<apteryx>civodul: guix now at 2.5g processing linux git tree after 30 minutes
<apteryx>it increases slowly
<sarahjones>I recommend removing pinebook image from website due to it not being tested and not working
<sarahjones>so I guess guix users have to stick with the backdoored intel and amd cpus lol
<sarahjones>for laptops at least
<apteryx>sarahjones: did you report a bug about it?
<Fare>sarahjones, you think the ARMs aren't backdoored yet?
<sarahjones>I have not submitted a bug
<sarahjones>I'm going to see if I can build it myself with u-boot.
<sarahjones>the thing with ARM, are there any known backdoors or reason to believe they are unsafe? at least intel and amd is known
<mirai>looks like this was missed:
<sarahjones>I'm still new to pinebooks so this is a learning curve for me. and most documentation is chaotic or incomplete or lacking.
<sarahjones>or very hard to find, trying to learn about how to compile and install u-boot to sd card now
<sarahjones>I must say though, guix does seem promising, if I can ever get it to work. I cringe at the thought of trusting binaries, and so all about eliminating exposure to binaries as much as possible
<sarahjones>reproducible brings trust to binaries though
<sarahjones>and compiling things from source code is usually a large pain or impossible. I suspect most people if any don't even test if common packages actually can be built. even apt-src on Debian is a nightmare to get things to work. guix looks to make building from source easy