<lfam>But, building this package with -j1 could take forever
<cbaines>lfam, I think the relevant page on data.guix-patches.cbaines.net is currently broken from changes I made today, I'll fix it in a minute. I'm not sure there will be any useful information though as ci.guix.gnu.org data doesn't make it through, and the relevant Guix Build Coordinator instance hasn't been building that branch
<Noclip>jackhill: Wow wow wow wow! I think I finally did it! It just compiled sucessfully for the first time!
<valerii_leontiev>Hey there. Can guix be improved to use less resources of machine during the installation of package or pull or whatever? Now it's pretty slow and it use a lot of CPU. I know of course that guix isn't traditional package manager but despite this fact could it be improved in that aspects?
<Noclip>valerii_leontiev: Try to compile as less as possible.
<Noclip>If the guix repo gets updated the build farm needs to first build all updated packages before it can deliver them to you so it's always a bit slower than the repo and so always a few hours behind.
<valerii_leontiev>Noclip I do not compile any soft. I guess all soft what I've installed gas substitutes
<Noclip><lfam "Nevertheless, Noclip, it doesn't"> That might be true. However when I started using guix (at least several month) ago I had some issues with guix compiling a lot of stuff from source without me wanting that.
<valerii_leontiev>Could you explain how to enable this option in config? I hope it's just one line as "enable substitutes for manifest feature". Or us more complicated?
<valerii_leontiev>* Could you explain how to enable this option in config? I hope it's just one line as "enable substitutes for manifest feature". Or is more complicated?
<Noclip>leoprikler: I always use guix weather if ungoogled-chromium wants to be updated because in the past chromium sometimes failed to build on the substitute server. As the result my client couldn't download the substitute and tried to build it locally instead ... making my cpu temperature go crazy until I stopped it by hand ...
<valerii_leontiev>So substitutes for manifest feature makes guix almost binary distribution:)
<valerii_leontiev>I like to use operation system and don't like when it uses me and my time:) It's mercantile but true
<bone-baboon>lfam: Thanks for sharing that information about this webkitgtk bug. Hopefully it's build works for me this time as I have not limited it's cores or jobs. This sounds like it could be a problem for computers with just one CPU core. I have a couple single core computers building from source but they are stuck on this instead bug#47928.
<lfam>bone-baboon: You can still use -j2 on a single core
<lfam>I think it's worth doing that anyways, because it will use up some of the slack caused by I/O waits
<lfam>I suppose it depends on what kind of single core
<bone-baboon>lfam: Thanks for sharing that. I would do that with pull and reconfigure's `--max-jobs=2`?
<leoprikler>I don't have any context, but the only reason I can think of why the list wrapper exits in the first place is because the return value of (run-network-management-page) is not wrapped on its own
<lfam>I'm going to propose a followup patches offering the GPM service for this "non-desktop" case
<FennecCode>Hey, I recently noticed that there are packages corresponding to the Raspberry Pi bootloader, but no u-boot package. I'm not terribly familiar with the boot process for ARM boards. Are there any showstoppers for running Guix on a Raspberry Pi? How would I go about doing that?
<FennecCode>Ah, ok. I was wondering if maybe that would be covered by the rpi-open-firmware package
<FennecCode>These are more speculative packages for now rather than something that is ready?
<lfam>I don't know very much about installing Guix on ARM, but I do know that, usually, every board needs a unique bootloader
<lfam>It's not like Intel / AMD where the same ISO (for example) will boot on pretty much every computer of the last 20 years
<lfam>So, maybe nobody has packaged this bootloader for Guix yet, maybe can't offer it, I don't know the details
<lfam>I meant to write "... maybe we can't offer it ..."
<lfam>I do know the Pi's "CPU" is basically a coprocessor of a GPU
<lfam>If you wait long enough, you'll get an answer
<FennecCode>Got'cha. There was an article related to running Guix on ARM boards that have u-boot packages already written (https://guix.gnu.org/blog/2019/guix-on-an-arm-board/). I was wondering if the "raspi-arm-chainloader" package served a similar purpose. I can certainly see the Pi being a unique case because of its quirky organization
<lfam>The other question is, which version of the Pi? I think each one is totally different
<FennecCode>Right. This one's a 3B. The reason I was assuming it was version agnostic is because the rpi-open-firmware package claims to work on anything that isn't the original Pi
<lfam>Yeah, could be! Hopefully someone who actually knows the answer sees your questions soon :)
<wpeace>Hey, I came real quick because I feel the instructions to launch Guix from a vm are not exactly clear, I have not successfully done this yet. I figured out that because the ISO is on v 1.2, it needs generic linux, not guix 1.1, & I extracted it with the xz -d command, however, the system still seems to be unbootable in my vm, does anyone have any
<apteryx>wpeace: not yet! the artifacts just successfully built on all platforms for the first time :-) I should test it some just to make sure I'm not uploading garbage to the GNU FTP and then I can call for a round of testing for this RC1
<wpeace>I tried first with btrfs twice, I did manual partitioning first, but when it errored the first time, I figured I did it wrong, so I did btrfs with automatic partition, with the same issue, so I tried again with ext4 as the main issue, It says on the error screen to email email@example.com, so I guess I will do that if this isn't me doing something
<nckx>dante: My /tmp is an slightly-below 8 GiB tmpfs (50% of RAM) and I don't remember a build ever running out of spc. You can probably get away with a lot less. There's no answer: it depends on the package, the upstream, how many parallel builds & cores you have/choose, etc.
<cbaines>I'm guessing you have 8GiB of swap, plus a tmpfs nckx ?
<nckx>IME there are only a few outliers that really push the limits beyond what's reasonable. E.g. ungoogled-chromium is notorious for stuffing its face with your RAM. I don't know if it's as hungry for storage.
<nckx>cbaines: They have an upper limit, yes (see mount options), which defaults to 50% of usable RAM.
<cbaines>(I've had small machines run out of storage building ungoogled-chromium, I'm not sure what it requires though)
<cbaines>nckx, interesting, my expectation would be that tmpfs might be faster even if you have plenty of RAM because things will be written and the filesystem will actually have to write to the storage
<canant>I hope you're doing well. I'm happy to see that my commit is merged. Thanks for your indentation changes.
<canant>Now I'm trying to reproduce the slow query. However, I don't really understand how to make a temp_package_metadata table. Also when I try to see the tables related to the revision on the guix_data_service_small.dump I can't find.
<canant>Is there any example code or doc that can help me to make a temp_package_metadata?
<cbaines>you don't need to run the code though, it's just a reference for the relevant SQL
***pocketroid_ is now known as pocketroid
***pocketroid_ is now known as pocketroid
<apteryx>civodul: hi! I've generated the release artifacts on berlin (under /home/maxim/src/guix/release*); the automatic commits to bump the guix package haven't been signed (no gpg key there); would that cause a problem to use the built artifacts or not?
<roptat>apteryx, it would be an issue with the installer script, right?
<apteryx>I tried regenerating the same locally to get those commits signed, expecting to get 100% substitutes coverage; but weirdly it tries to build stuff and fails (due to virtualized armhf-linux and powerpc64le)
<apteryx>roptat: I'm not sure :-) I'll review what the script does
<apteryx>I think it just downloads the Guix release archive, so as long as the *archive* is signed (which I can do by uploading to FTP locally with the release support script), it should work I guess
<apteryx>yeah it seems to pick the latest release available for the guix-binary from ttps://ftp.gnu.org/gnu/guix/
<rekado>brendyyn: that blog post actually quotes my 2017 idea and has this to say: “Some have proposed making CPU features a first-class concept in Guix. That way, one could install with, say, --cpu-features=avx2 and end up downloading binaries or building binaries optimized for AVX2. The downsides are that this would be a big change, and that it’s not clear how to tell package build systems to enable such or such
<brendyyn>supposing that we had the time and resources, would it be a good idea to add another x86-64 target that was like x86-64-v4 for people with fast computers
<brendyyn>how many combinations of these options would people realistically want to use? would it be more than 5 or 10?
<apteryx>civodul: (testing the generated VM image for the 1.3.0rc1 release candidate) is it expecting that the Guix version string at boot time says Booting Guix 1.2.* rather than my 1.3.0rc1 tag?
<lle-bout>civodul: I understand, it's a great article, I can see how rebuilding for each arch is expensive though some people might want to do it anyway. If we have the build farm capacity we could also build packages for each -march GCC cpu-type and somehow have --with-toolchain-cpu-type=icelake-client or something, there could be substitutes for each and every of those, it would require less bandwidth for individual users to get optimized
<vagrantc>i've actually started doing reconfigure as a user, even though it doesn't have permission to finish the installation, just to limit what happens as root and then run the final "sudo -E guix system reconfigure ..." to actually install it
<vagrantc>i like the reduced verbosity of guix system reconfigure vs. guix system build
<vagrantc>similar for building packages; i often use guix environment --ad-hoc PACKAGE ... instead of guix build PACKAGE