IRC channel logs
2024-09-02.log
back to list of logs
<civodul>what’s the story with the “.a” in emacs-* packages version string? <civodul>oops, twas a forgotten hack in my Home config 🤦 <nckx>What an nckx thing to do. <podiki>ACTION builds llvm-for-mesa for the billionth time <nckx>Rutherther: Er, ‘success’, ‘yay’. <nckx>Something, somewhere, got unstuck. Twice. I'll merge them. <nckx>No, I don't know what happened. The bug numbers weren't allocated until now, too. <meaty>what does it mean when `guix pull` seems to be retrieving packages from a channel, but afterwards 'guix describe' is still missing that channel? <mange>After "guix pull" can you confirm that the "guix" you're running is the one in ~/.config/guix/current/bin/guix? <meaty>i may have missed the laset few messages <meaty>mange: aha, yes, the one in that location gives the right 'guix describe' <meaty>mange: how do I set it to properly use that one instead of the 'outdated' one <meaty>oh, its fixed after logging out and back in; but is there a less unwiedly way? <mange>The instructions in "(guix) Getting Started" in the manual talk about the setup. I assume that "hash guix" is what you were missing. Was this your first "guix pull"? If so, I think it will work properly in future runs (because the path won't change). <podiki>and I think guix should give you a hint/warning when things in environment will need to be updated (at least will for search paths, not sure here) <meaty>mange: yeah this was my first lol, and thanks podiki <podiki>welcome. yeah first guix pull can be special <ieure>Since the core-updates merge, I'm having a build fail with "checking for crypt in -lcrypt... no" -- anyone know where this library went? <ieure>It was building (but not running right) prior to the core-updates merge, now it fails to build because it can't link against crypt. I think this was in glibc? <Kolev>ieure: Common Desktop Environment? Cool! <ieure>Kolev, Yeah, I thought it was awesome in the 90s, and it got GPL'd ages ago. <ieure>Looks like libxcrypt is what I want to fix this. <Kolev>ieure: tell me when it works. I'd love to use it. <ieure>Kolev, Some day. Patches welcome if you're interested in helping. I never got up into how it was put together back when I occasionally ran it, so I'm not sure what exactly is broken. Can't start up some of the background services it wants. <ieure>You get a nice Motif error dialog, though. :) <ieure>Back in the dark ages, when I started using Linux, there was no Free desktop environment. I ran fvwm 2.x for ages and pined for the fields of CDE. <ieure>Some company sold it for Linux once it got a bit more popular, I ran a... liberated... version of it for a while, but both KDE and Gnome 1 were out not that much later and I never really daily drove CDE. <ieure>Always thought it looked great, though. <Jdaco>guix system reconfigure is getting stuck at 1% in the check phase of building gtk-4.14.5. Anyone else seen this happen before? <ieure>Kolev, if you even have a theory as to why it's broken, that'd be helpful! <Jdaco>For a few minutes it runs a series of process that I'm assuming are tests, then no more processes, no CPU usage, and it stay at 1% <ieure>Jdaco, I ran into the same thing, I waited until there were some substitutes so I didn't have to build locally. <ieure>Jdaco, It did eventually progress, but took a very long time, even on a relatively fast machine -- 8th gen Core i7 quad w/ 16gb RAM. <Jdaco>How long does it take for substitutes to be available? <ieure>They should be available now, I ran into that a day or two back. <Jdaco>Wouldn't it automatically pull subs if they're available instead of building? <ieure>It should, yes. What does `guix weather gtk' say? <Jdaco>Weird. On this machine both servers say 0% subs available, but another machine says 100% available. <Jdaco>Something weird going on with this machine. Now I know where to look. Thanks <ieure>Jdaco, Try running `guix pull', `hash -r', then check weather again. <mange>Which substitute servers are you using, Jdaco? My machine tells me that ci.guix.gnu.org has substitutes for 4.14.5, but bordeaux.guix.gnu.org doesn't. <Jdaco>Same servers. On my main machine both those say 100% subs available <meaty>will guix pick up where it left off on interrupted build processes? <ieure>Individual package builds are atomic -- they pass or fail. <Jdaco>mange nvm, after a pull I get the same result as you <ieure>Jdaco, Likely one machine was on an older Guix prior to the pull, and builds for those packages were available. <ieure>A thing that's not always entirely obvious is that there can be N different derivations of the same package and version. If its inputs change, it gets rebuilt, even though the package itself didn't change. <ieure>Bordeaux seems like it got very slow, that might be related. That's the latest thing stopping me from reconfiguring. Some day, I'll be able to update. <podiki>can't git send-email: "Need MIME::Base64 and Authen::SASL todo auth at /gnu/store/z542qwhy7nnzq7iyjpfxpib2vcx04j0r-git-2.45.2-send-email/libexec/git-core/.git-send-email-real line 1655." <mange>I also had an issue using git send-email last night, but it complained about an out-of-date SSL library, I think. I had to stop before I could investigate it, and I haven't made it back to trying again. <podiki>i think there was some guile/crypto change from core-updates, but i don't know the details <podiki>i wonder if git:send-email needs the perl authen sasl input or something <podiki>anyway, will have to see tomorrow <podiki>in the meantime i'll push these patches to mesa-updates to see how building goes, to sort out later <podiki>(seems good locally on x86 at least) <apteryx>oh fun; you can use '0.0.0.0/0' in a wireguard peers allowed-ips field to lock you out of the remote machine ^^ <sneek>apteryx, you have 1 message! <sneek>apteryx, nckx says: I'm uselessy late but if you ever need it, I think there was an answer to your question in #grub: absolute file names are relative to "($root)" so you can set root=hd0,1 without typing any brackets. <apteryx>nckx: awesome, thanks for relaying it here, I had totally missed it. I also have a support ticket with OVH asking them why shifted keys don't register correctly in their KVM virtual terminal. <apteryx>weird that 'guix system roll-back' downloads the world; I've deployed a couple configs in the last few minutes <apteryx>(deploy must have sent grafted packages, and the guix machinery needs the ungrafted ones to check if grafts need applying) or something <mange>As long as the peer is set up to route traffic properly, 0.0.0.0/0 can work fine. :) <meaty>ok, so I'm having an issue where I'm trying to build an installation image and one of its dependencies/derivations(?) won't build, specifically `glibc-supported-locales.scm.drv` <meaty>the build log starts with `zstd: cannot exec: no such file or dir` and of course, this being guix, installing zstd itself does not help <meaty>I think I may have found a bug? but I'm not sure how to track down its source and/or workaround/fix it <nckx>apteryx: Sorry for the confusing language, I didn't relay anything. Was just my random idea. <nckx>meaty: I assume 'directory' was written in full? I only ask because 'dir' would be hella custom and relatively easy to pinpoint, vs. one of a million strerror calls. <meaty>nckx: yes, i am paraphrasing <frankie>hi guix fellows, sorry for the silly question: what are the wip-* branches on git intended for? <AwesomeAdam54321>frankie: From what I understand, the wip-* branches are for long-term WIP changes to Guix that need help from multiple people <elevenkb>Hello there, I'm having trouble with locales. I get the message that encourages me to install the glibc-locales package even though I'm running Guix System. <elevenkb>I think it might be because I haven't updated my OS (just my home configuration). Let me do that first. <lynn_sh>hello, im looking to package a rust program. the crates.io is from 4 years ago and is no longer up to date, is there a way to run a guix import on the repositories Cargo.lock instead? I see that OCaml option for guix import has a local repo option. <Rubujeto>I installed Guix 1.4.0 « i686 » on my laptop, which processor is « Intel Pentium T2080 ». After the installation, I taped the command « guix pull » and error happened : <Rubujeto> substitute : […] ice-9/boot-9.scm 1752:10 <Rubujeto>… It seems that I'm on #guix , so I'm in the good channel (sorry, I'am newbie) <mange>That bug is five years old. I would by a bit surprised if it were the same thing. Your truncated error log is not enough to diagnose the issue. Can you put it in a paste (see topic) and post the link here? <nckx>You're in the right channel, but you pasted a wall of text and got quieted by a bot (after ‘I found this bug’). IRC is a line-based protocol, so the bot has no way of knowing whether you were almost done or about to paste 16 screenfuls of text. <nckx>…which would get you booted off the network and possibly temp-banned for spam, so the bot means you no harm. <Rubujeto>Because I was on «tty» on my desktop and I didn't installed « emacs » to manipulate characters, to copy/paste, and send it to this channel. I will try to find a solution to send you the complete error message tonight. <nckx>If you have or can guix install curl, you can use 0x0.st. It also works with wget if you can translate the examples. :) Even easier is wgetpaste, also a Guix package, that ingests stdin or a file and returns an URL of reasonable length. <nckx>With emacs, I use scpaste, but I think it requires some Web hosting of your own. <Rubujeto>Problem is that I just installed Guix as an OS and the documentation asks to tape « guix pull ». So I didn't install yet package <nckx>You can install packages without pulling. You likely won't get the newest version, that's all. <nckx>The ‘guix’ you got out of the box is a fully functional package manager. :o) <Rubujeto>Thank you nckx. I have one last question : « What app do you use to connect to IRC with emacs ? Rcirc, ERC ? Something else ? » <nckx>I tried both ERC and circe some years ago. Circe was all right, but any Emacs IRC client seems to choke on the number of channels I have open by default (>200, I'm a weirdo) + ZNC backlog for each. Clients would hit their *own* time-outs during the initial connection… <nckx>So I (still) use Hexchat. <nckx>In a sense. Minus a few exceptions like #guix, it's only the last few 100 lines of context from ZNC. Older messages aren't saved. Persistent mass logging would be creepy. Weird good, creepy bad. <weary-traveler>i don't disagree. though now i understand things even less. presumably you pay attention to a fair number of these 200 channels, but perhaps i'm overestimating how busy these are <nckx>weary-traveler: You probably do :) <jpoiret>is it just me or was this merge uneventful in the end? haven't seen any complaints yet <jpoiret>I guess not having major updates of other stuff at the same time helps <podiki>can't git send-email: "Need MIME::Base64 and Authen::SASL todo auth at /gnu/store/z542qwhy7nnzq7iyjpfxpib2vcx04j0r-git-2.45.2-send-email/libexec/git-core/.git-send-email-real line 1655." <civodul>guix time-machine -q --commit=6c045f2c9eb7b8efe7c8a1002cda990abaa9be1a -- shell git{,:send-email} -- git send-email 00*.patch <nckx>jpoiret: Heh, don't hide your disappointment ;-) PHP no longer building seem to be the biggest so far. <civodul>jpoiret: at work we’ve been taking care of the fallouts in our guix-hpc channel today, if that’s any consolation :-) <nckx>Now if we truly cared we'd break Rust and npm, but we're fearful cowards. <jpoiret>i'll try to get back in the game by updating agda and coq this week <nckx>s/Rust/Cargo/ to be fair. <civodul>there’s a pending Coq update already <podiki>Is git send-email supposed to use perl-authn-sasl? I recall that coming up in my Internet search but was late last night <podiki>(I'll send the mesa update patches using time machine then, but I did push to see how building goes) <jpoiret>civodul: we're at 8.19 already, with 8.20 coming soon <jpoiret>also add the coq-lsp and ocaml-language-server packages I have locally <fnat>There's a service ('restic-backup-service-type') that runs a command in a cron job. I need to set some environment variables so that the cron job can use them. Do I need to extend the service for that to happen or is there any simpler way? <civodul>jpoiret: yes, but maybe that patch should be reviewed? and perhaps the author is happy to send an updated, as long as we apply it in a timely fashion :-) <ngraves>Hi Guix ! core-updates seems to have broken some packages on my side too (despite them building sucessfully) : python-numpy, python-pandas in particular. The error seems to come from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libm.so.6: version `GLIBC_2.38' not found (required by <ngraves>/gnu/store/3yin60rzckgdixcf088099m9gbxaxbjf-profile/lib/python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-x86_64-linux-gnu.so) <jpoiret>civodul: thing is, I already have them locally since I work with them, it's just a matter of polishing it a bit <jpoiret>ngraves: did you update both your system and package profiles? did you reboot? <Rutherther>If I want to update a patch I made, what should I send as email so debbugs links it to correct issue? <Rutherther>Will muku current and then mumi send-email take care of this automatically? <ngraves>jpoiret: No, still compiling some derivations. These errors should be fixed at reboot then? Thanks! <jpoiret>ngraves: yes, usually glibc updates cause this issue <civodul>jpoiret: neat; i think it makes sense to coordinate with the original poster though, out of respect and perhaps with a look towards creating a team; WDYT? <civodul>ngraves: make sure to ‘unset LD_LIBRARY_PATH’ before going any further <podiki>is berlin gc-ing? see nearly all workers idle <podiki>(i know, something for me to say from the US on Labor Day) <civodul>podiki: almost everything queued is aarch64, and those builders are busy trying to obtain derivations that are no longer available <podiki>civodul: hm. i tried to restart texlive-bin for x86_64 on mesa-updates (build just failed but log showed it just stopped randomly; builds locally) but still shows as "scheduled" <podiki>just built locally and was fine; i think that is a root package of a bunch of failures for mesa-updates, along with a few fails from master <civodul>weird, it should definitely get picked up <podiki>err i mean some fails on mesa-updates are what is failing on master currently <podiki>i guess i can investigate git:send-email... <civodul>ACTION -> ‘herd restart cuirass-remote-server’ <podiki>does that happen more often or when large jobs are being processed? <podiki>civodul: thanks! busy berlin now <elpogo`>I'm going to attempt adding a 'rootfs' format type for guix pack. would it be acceptable for the /gnu/store/...-rtorrent-rootfs-pack/ directory to contain hardlinks to other files in /gnu/store? <civodul>podiki: once every few weeks, a port scanner or something on the MDC network sends garbage to ‘cuirass remote-worker’, and that causes it to crash <civodul>obviously it should be able to handle it gracefully <podiki>well that's not very nice! garbage should be sent to the correct place <sepeth>Hey Guix, a Rust package I added to my channel is not visible to a Rust app also in my channel. During 'build' phase, I get 'no matching package named `flexi_logger` found'. I checked the `guix-vendor` dir, and I don't see the former package there. But I am able to build it via `guix build`. <sepeth>I am trying to add neovide, and it needs flexi_logger, which is not in the guix channel. I added both to my channel, but neovide can't find flexi_logger. <sepeth>And, I added this ("rust-flexi-logger" ,rust-flexi-logger-0.28) to cargo-inputs. <sepeth>I can't figure out what's wrong. <yelninei>sepeth: last time i checked cargo-build-system does not consider git sources as valid cargo-inputs. Either try to fetch it as a tarball or as a workaround add the package to the normal inputs as the installed source will also be added to the vender (you still need it in #:cargo inputs such that its #:cargo dependencies are also included) <rynn>So, does anyone know what the culprit was here? I installed font-jetbrains-mono, but it refused to be available anymore, even after re-running fc-cache. I then manually copied the fonts from the /gnu/store pacakge location into ~/.local/share/fonts and rerun fc-cache, after which the fonts became available. <ieure>Magit 4.0.0 busted for anyone else? If I press b to open the branch menu, I get an "transient-setup: Symbol’s function definition is void: transient-prefix-object" error. <Rutherther>for everyone, it's been like that for more than a month <Rutherther>replace the transient dependency with one that has #:emacs emacs as argument <Rutherther>the issue is that transient comes with emacs with native comp files. Native comp files are preferred to to el files, loaded first. But the eln files are actually for too old transient version. So a fix for that is to native compile transient. You do that by giving it emacs as argument to emacs, since that supports native comp and the build-system will compile it <Rutherther>it's a "global" issue, can happen with any package like that. Currently the workaround is to just replace the inputs yourself - packages that come with Emacs itself, to set their argument to emacs <ieure>Rutherther, Thanks. What a pain. :( <ieure>ugh, emacs-org-roam propagates magit, so I also have to rewrite that to use the fixed package. <ieure>A bunch of stuff propagates the busted emacs-magit. <ieure>Also wondering if anyone has been able to get the TearFree option to work with xf86-video-intel? I have the package in my operating-system config, I have a config which enables it, I see in my Xorg.0.log that it's enabled, but my video still tears. <ieure>I don't want to use Wayland, and every X compositor is a buggy mess. <weary-traveler>during build, native-comp only ever takes a single core, right or am i doing it wrong? <ieure>weary-traveler, Sounds right to me, native-comp happens inside Emacs, which is single-threaded. <weary-traveler>ieure: yeah, except outside of guix, when emacs does native-comp asynchronously it knows how to spawn multiple emacsen in the background to do so <ieure>weary-traveler, Hm, have never looked. <ieure>weary-traveler, Perhaps it knows how to do that because it's JITting all the code at once, instead of one Emacs package at a time. <weary-traveler>ieure: haven't looked at the native-comp internals enough to know. btw, this is the behaviour on foreign distro. my point was simply that native-comp in emacs somewhere knows how to make use of multiple cores despite emacs itself being single-threaded. i don't believe, however, emacs-build-system knows how to <widespace_>Fun fact: Depending on the arguments given to .SHELLFLAGS make can insert it's default shell after the shell it was given in SHELL. <widespace_>I looked into why d-tools fails to build and rdmd creates a test makefile that fails because make inserts sh after rdmd_app_ <widespace_>And the fix to that is changing the order of the flags in .SHELLFLAGS <ieure>Argh.... the patch to add tearfree to the modesetting xorg driver was merged *two years ago*, but still isn't included in the stable release. <sneek>lfam, jpoiret says: rust has changed on master so we'll have to rebuild it anyways, t'would be a good time to merge boost and boost-for-source-highlighting <luca>Has anyone considered adding runit support to guix-install.sh? <Rutherther>nckx should I get responses for emails to issues to debbugs.gnu.org? I am not getting any, and they do not appear on the website even after more than half an hour. So it seems this could be a recurring issue for me, that the e-mails will get picked up only after few hours :) <weary-traveler>luca: as in the service management system? what would it mean for guix-install.sh having "runit support"? <f1refly>someone recommended me kanshi to manage update my display settings when outputs change on wayland and it's working great. I noticed that apparently kanshi can be compiled with ipc support, enabling the "kanshictl" target and making it possible to also change the output setup when i.e. a laptop lid switch is toggled. would it be possible to add this to the kanshi build on guix? should I open a ticket? <ieure>f1refly, You're welcome to open a bug requesting that. It's not explicitly disabled, maybe it needs another library to build that stuff? <ieure>This likely also needs some kind of service to launch the kanshi you control. <ieure>Be a good starter bug if you're interested in learning about contributing! <ArneBab>Does anyone else have problems building wine64? I see guix/build/utils.scm:761:4: In procedure alist-cons-after: Throw to key `match-error' with args `("match" "no matching pattern" ())'. <luca>How much space should guix take? My /gnu takes 8gb which seems like a lot <ArneBab>luca: Guix takes quite a bit; 8 GiB isn’t that much. <luca>Ok, in that case I didn't partition with guix in mind <ArneBab>Guix keeps around quite a few build files to speed up later builds (or very similar builds) and that costs disk space. <luca>Well disk space isn't much of an issue, but I gave /home much much more space than I did for / <weary-traveler>ArneBab: i believe i saw a recent bug for wine64 - may or may not be the same <lfam>In a lot of cases it's possible to resize partitions and filesystems while the system is running <luca>I'll do guix on a machine with more storage and when I feel confortable spread it around <ArneBab>luca: it includes docker images with data, but /gnu/ still takes up quite a bit. I gc only once every few months to be sure that I have custom environments cached when I need them quickly. <ArneBab>And these include Java — about 10 versions installed one after the other to have a clean build. <ArneBab>Also several firefox (icecat) versions and chromium <Rutherther>luca also don't forget to remove older system and home profiles you no longer need in the future, since all of these will be kept and their dependencies as well until you remove them, and gc afterwards <pranavats>luca: You can survive on 25GB but you won't get the benefits of rollbacks because you'd need to delete generations and collect garbage on every update. <ArneBab>I could gc more often, but then when I need an old version (I do, regularly, for testing) I have to build again. <ArneBab>(I didn’t remove older system profiles) <luca>well right now my distro takes up a good amount, so adding guix, which is almost a whole other OS. It adds up quickly <pranavats>Using LVM, I keep some free space unallocated to either root or home, and keep extending both as needed. <pranavats>Since you can extend volumes online with LVM. <ArneBab>anyone has a hint how to fix wine64? <ieure>luca, /gnu/store tends to get huge. It keeps any packages referenced by profiles or their generations (so stuff like rollback works). <ieure>luca, 8gb is fresh-install-size territory. I'm not sure how much you should budget for the store, but, a lot. 50-100gb? <luca>That is... quite a lot more than any other distro I've used. By a lot <Rutherther>I think it highly depends on how one uses guix system, home, shell, 100 gb can be on high side for some and low side for others <Rutherther>luca yes, guix takes more space than other distros, it's mainly due to the declarative nature, where every dependency change causes rebuild of package <ieure>luca, Yes, agreed. It's a pretty heavy distro. <jpoiret>also depends on whether you want a big pile of stuff or not, ie. gnome/kde <luca>Would setting up a different computer for builds (and cross builds?) help to keep the size down? <jpoiret>you usually don't build anything yourself anyways, you download from CI <jpoiret>unless you absolutely *want* to build everything yourself <pranav>Ah yes. I recommended 50GB without taking into account any desktop manager. Just some lightweight window manager. <luca>In that case I think I'll keep some other distro on my pewny raspberry pi with what I thought was a fat 64gb SD card <ieure>luca, For reference: This laptop I installed maybe a month ago has 11 system and 4 home generations, and /gnu/store is 41gb. The box I set up to build stuff for me so my lap doesn't get scorched is 166gb. <lfam>The space usage really depends on what you are doing. If you are just installing a handful of packages on top of another distro, you can live under 15 GBs <jpoiret>but i've been building the world over and over and haven't gc'd in a while <ArneBab>luca: yes, I wmould not put Guix on an RPi <pranav>jpoiret: Yes, I used to survive on 25GB, but slowly it gets to a point where I couldn't update without extending it. Same happened with 50GB. I do tend to put everything in one manifest though. <lfam>Like, use Guix like Debian and it's a lot bigger but not crazy for 2024. Does one really need to update the entire system daily, or is monthly enough? How many generations to keep? 3 or 4 is probably enough! <ieure>luca, I agree with you -- Guix isn't a great fit for a raspi. Both due to resource constraints and the inherent non-free nature of the hardware. <pranav>I also have several inferior channels. <jpoiret>pranav: ah yeah, I bet that adds a lot of duplicate dependencies <luca>ah I didn't even check if guix supports raspberry pies <lfam>There's little value to keeping dozens of old generations IMO <ieure>luca, It can be made to run on them. <luca>yeah no doubt. But I'll keep on the beaten path for now <ieure>The fundamental tradeoff of Guix IMO is space+compute for reproduceable builds and rollback. <ieure>And on a raspi, you're limited on both space and compute, so. <lfam>Guix is another level of resource consumption compared to old-school distros. Space consumption is comparable to macOS or Windows <ArneBab>And having specialized packages installed per shell — guix shell <somepackage> -- somepackage is a quick way to get something without polluting my install. <lfam>But for most of us it's worth it because hardware is cheap given the benefits <luca>Is guix about the same space wise as nixos? <ieure>luca, Recommend using the vanilla Debian image for raspi, it's fairly lightweight, well-supported (I don't know, but get the sense, that Debian's ARM support is better than Guix). Raspian or whatever they're calling it these days has always been a pain IMO. <ieure>luca, I've never run NixOS, but I'd expect that to be the case. <Rutherther>luca yes, it's similar. The reasons are the same <luca>I'm using void right now on my pi. Especially because I can cross build stuff from my desktop, as to not clutter the pi <ieure>ArneBab, Agreed, I like that a lot. <ieure>I've never had good success compiling stuff on raspis, they seem to overheat and crash. Last tried on a 3B+ with heatsinks. <ieure>Was just reading the other day how the raspi actually uses the (closed) GPU to boot an OS. <ieure>GPU does all the work, then hands off to the CPU. Weird design. <luca>The raspberry pi has a special place in my heart. It was my second home lab setup, after a mac mini with OSX 10.6 (which was outdated at the time as well). Learned a ton of linux on that pi <pranav>luca: you can use guix copy for sharing cross-builds with Guix on ARM boards, I suppose. <f1refly>ieure: the user is responsible for launching the daemon instance, it only needs a lib and a build flag I think <f1refly>i see, we don't have varlink packaged in guix yet <nikolar>luca: I wonder why they went with that design <luca>the raspberry pi foundation people? <nikolar>Also now that we're talking about arm, I'd like to get guix on a rock 5a <ieure>f1refly, Varlink is a D-Bus competitor? <luca>idk, probably the embedded market is less open than we'd wish <nikolar>Why not just boot off of flash with the CPU directly <f1refly>i think using varlink is just a personal choice the author made <nckx>What I was told is: rPi didn't design the chips, they just got a deal on these random chips from Broadcom. Broadcom had some space left over on some GPU die, thought we could fit a litte arm CPU on that for approximately 0 dollars extra, so they threw one on because why not. Hence the low power and upside-down design. Your ‘CPU’ is a free coprocessor that came with the box :) <nckx>It's probably oversimplified but it's a good story. <nikolar>And I guess they just kept doing it the same way for some reason <ArneBab>ieure: the patch works for me — thank you! <nckx><The GPU came first then> I think it's fair to say they *were* GPUs, or at least Broadcom thought of them that way. <luca>Anyway I know I've been a bit harsh on guix now, but I am really impressed by guix as a whole. From the ci, issues, packages, and guix itself. It's a very impressive project, and I would like to congratulate everyone here on working on it and with it <nckx>An extreme example that you mustn't take to seriously is somebody figuring out how to boot a full OS on a particularly powerful SSD controller, hooks up some proper peripherals to the thing, and sells it as a computer. The boot process would be all kinds of weird. <nikolar>Wonder why they even had a GPU that could boot though lol <lfam>Does anyone know what is supposed to provide UI icons in KDE programs? Specifically, I'm trying Konversation from Guix on Debian, and the UI icons in the Edit Network pane are blank <lfam>I've installed breeze-icons and oxygen-icons <civodul>lfam: hey! no idea where icons are supposed to come from <singpolyma>Given the way that guix works I don't imagine installing other packages will have an effect. Probably it's just broken