<civodul>funny, usually it's the other way around <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 <lfam>Maybe we forget about the branch then, I don't know <lfam>We really need to see a good result on CI to feel confident about merging it quickly <civodul>yes, we need to see per-arch results at least *civodul tries "guix time-machine --branch=wip-ungrafting -- weather -m etc/release-manifest.scm" <civodul>release-manifest.scm is just ~500 key store items, but quite representative <civodul>ah well, it says we're missing powerpc64le-linux binaries <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>I recommend you not to pull always the latest repo version with "guix pull" because substitutes are not always available for them if they are still fresh. <Noclip><valerii_leontiev "Even without compiling guix is s"> It is slow but it shouldn't eat up any resources without compiling so running it in the background should be perfectly fine. <lfam>valerii-leontiev: We are always working to improve performance the underlying implementation of Guix, which is Guile. <brown121407>Hi! How do I make the message that says I need to install glibc-locales and set GUIX_LOCPATH disappear? I already did what it told me, but it still shows. <lfam>Currently, Guix package operations are extremely I/O intensive, due to a large number of grafts, and we were actually discussing some incremental improvements in that area just before you joined <lfam>brown121407: Install glibc-locals and set GUIX_LOCPATH both in the context where you run Guix, and also in the context where guix-daemon runs <lfam>And, after you do those steps, log in again, for example, with `bash --login` <civodul>valerii_leontiev: it can always be improved, and there's some work going on; if you interested in helping, we should look specifically at one source of slowness <Noclip>lfam: Completely prohibiting compilation isn't possible with guix, or is it? <lfam>No, Noclip. Guix is a build-from-source distro <valerii_leontiev><lfam "Currently, Guix package operatio"> It's great. Hope situation will change. <lfam>valerii_leontiev: That aspect of the situation will alternatively get better and worse as time passes <Noclip>valerii_leontiev: You can prevent it by not pulling the latest repo versions. <lfam>That is, as we apply and remove grafts (i.e. security updates of cores packages), the I/O intensive nature of installing packages will get worse and better, respectively. <Noclip>You can use "guix pull --commit=xxxxxx..." for that. <lfam>But, in the future, we don't have to have as many grafts as we have now. <lfam>We'll be discussing changes to our workflow to improve this in coming weeks <Noclip>I then run "guix pull --commit=xxxx" and "guix upgrade" on that commit. <lfam>I think that valerii_leontiev is talking about a different issue <lfam>Not about building packages, but also the slowness of Guix itself <lfam>No raghavgururajan. We only put Signed-off-by as part of the code review process <lfam>It's not necessary for cherry-picking <Noclip>lfam: Maybe. But valerii_leontiev also mentioned long update sessions with high cpu usage at the beginning and to me that sounds like the build process of some huge packages. <lfam>Noclip: valerii_leontiev wrote: I do not compile any soft. I guess all soft what I've installed gas substitutes <lfam>There's other situations besides package compilation that could load the CPU for what seems unreasonably long for a package manager <rekado_>Guix doesn’t actually remove packages, nor does it install them. It tries to mimic the interface of a traditional package manager, but under the hood it only knows about building profiles. <lfam>For example, making many grafts on a spinning disk <Noclip>lfam: And you said earlier that it's not possible to completely turn of compilation. <rekado_>and a profile with one fewer package can still require work (e.g. when Guix has been upgraded in between) <lfam>Nevertheless, Noclip, it doesn't contradict what valerii_leontiev wrote <lfam>None of us dispute that Guix is slow compared to other package managers <leoprikler>There has been work done on providing a channel-with-substitutes. <leoprikler>Which would get you to the newest master commit, that still has substitutes for your manifest <lfam>Ultimately, Guix is a build-from-source distro. It's not a binary distro <lfam>There are dozens of binary distros <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. <Noclip><leoprikler "Which would get you to the newes"> Sounds great! <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:) <Noclip>valerii_leontiev: If you don't pull the latest commits and make sure that your upgradeable packages are available as substitutes you also get an "almost binary distribution". <Noclip>It's not perfect of course but much better than making your cpu melt itself ... xD <Noclip>jackhill: I copied your make-flags and applied #:test-target as you said and then it just worked! <valerii_leontiev>I have pretty enough hobby and operation system is not included in my plans:) <Noclip>valerii_leontiev: Yea, that's a valid concern. That's what I meant with "It's not perfect". <Noclip>Not even a little bit hobby? How did you find your way to guix? <rekado_>the channels file can be made arbitrarily complex to check for all sorts of things <valerii_leontiev>Btw I have used pkg on freebsd and it's great despite the possible dependencies conflicts <Noclip>Apt on debian/ubuntu is also very simple and fast but adding tons of repos and PPAs just to get a programm in a recent version isn't that much fun ... <Noclip>I usually only use them if they are maintained by the official programm developers. <leoprikler>if you think hard about it Ubuntu is a PPA for debian :P <valerii_leontiev>It's better to use nix or guix or flatpak or appimage to prevent dependencies conflicts <leoprikler>Regarding "channels with manifests available", there is an example in the patches. IIRC, they update the docs accordingly. <valerii_leontiev><leoprikler "if you think hard about it Ubunt"> I don't care:) But almost all packages even in testing works just fine <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`? <lfam>Guix has --cores and --max-jobs <lfam>max-jobs=2 tells Guix to build two derivations (packages etc) at a time <lfam>The --cores argument controls how many threads to use per job <lfam>So, for your single core machines, you could do --max-jobs=2 or --cores=2, and the effect would be somewhat similar <lfam>There are parts of package building that are typically slow and single-threaded, like good old ./configure <lfam>Your load will exceed the number of cores, but I think that's okay most of the time <lfam>Linux is usually pretty good about that <Noclip>Does "guix environment -l" does the same as "-f" for "guix package" and "guix build"? <leoprikler>--ad-hoc -l does roughly a guix package minus the symlink <leoprikler>-l OTOH will give you an environment with the inputs <lfam>I'm guessing the problem is in the changes I made to run-services-page in gnu/installer/newt/services.scm, but I'm not sure <lfam>Maybe I should duplicate that (if ...), instead of adding to it <leoprikler>hmm I think that the outer list call might be the error here <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>Like, (if (null? desktop) (cons (run-network-management-page) (run-system-administration-cbt-page)) ...)? <lfam>(Sorry (I'm (bad (at (Scheme))))) <lfam>Alright, after my test of "duplicate that (if ...)" is done, I'll try that if it still isn't working <lfam>What's weird is that it also crashes if I replace the call to run-network-management-page with run-system-administration-cbt-page <lfam>As if there is something about run-system-administration-cbt-page itself <lfam>(I'm still building the ISO to test your cons idea leoprikler) <lfam>Or as if there is something wrong with ntp-service-type <lfam>But, I think that all this stuff does is add the snippet to the generated config.scm. <lfam>leoprikler: You nailed it! <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>milestone! make release -> Congratulations! All the release files are now in release-1.3.0rc1. <apteryx>this including for armhf-linux and powerpc64le <lfam>I don't think so. But this is an important step for 1.3 <lfam>I can try to help you with your questions, wpeace, but I don't understand what you meant <wpeace>If someone were to start guix in qemu/virt manager <wpeace>I haven't found a combination that is bootable so far <lfam>I use this: `qemu-system-x86_64 -net user -net nic,model=virtio -enable-kvm -m 5072 ./guix-system-install-1.2.0.x86_64-linux.iso` <lfam>"-enable-kvm" is optional, but the VM will run much faster if your computer supports KVM <lfam>And "-m 5072" gives the VM 5 gigabytes of RAM. That's a lot, and you won't need that much. But I recommend a minimum of 1.5 GB RAM <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 was going to set up my system in a vm <wpeace>is the vm iso adequate for that purpose or will a full iso be better? <lfam>wpeace: The VM ISO an installed Guix System, intended for VPS hosters <lfam>The other ISO is an installer, for installing Guix System on a disk / virtual disk <wpeace>thanks for the tip, I didn't know that <lfam>I woulud recommend installing Guix System in the VM, but I don't have experience with Virtualbox so I can't offer much advice about that <lfam>We do have this documentation about Installing Guix in a Virtual Machine, but it's about QEMU <wpeace>ah yeah, I guess I could have done that instead of virt manager <wpeace>I like the idea of using qemu over virtualbox, so it is fine <wpeace>I read most of the manual while I was stuck for a few hours yesterday, mostly about like what to do on a guix system <lfam>I'm go afk for a while but I'll be around later, or others can chime in :) <raghavgururajan>What is the syntax to expose a configure-flag only if the target-system is not mips64el? <raghavgururajan>In other words, hide a configure-flag when target-system is mips64el. <apteryx>raghavgururajan: are there no examples in the code base? <wpeace>Oh, I am unable to complete the guix install, no matter what settings I do, at the end I get an invoke error, it generally sites the <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 bug-gui@gnu.org, so I guess I will do that if this isn't me doing something <apteryx>wpeace: which installer image did you use? <wpeace>oh, I tried with the vm image earlier, but it wouldn't boot, but someone here told me that is for VPS's, so I used the main image ***butleria1 is now known as butlerian
<pat>wpeace:qemu-system-x86_64 -accel kvm -hda guix-system-vm-image-1.2.0.x86_64-linux -nic user,model=virtio-net-pci -m 2G works for vm image. remove -accel kvm if you don't have kvm setup <wpeace>How can I determine I do not have kvm set up? <wpeace>oh I don't have any particular reason to use the vm image, I just assumed it was a more minimal version of the normal iamge <apteryx>wpeace: I think you can look for /dev/kvm <apteryx>if it's missing, you probably don't have it <wpeace>Sorry I didn't respond for 20 minutes <vagrantc>i've never managed to use the image generation stuff as it only works with cross-compiling, strangely enough <vagrantc>but i do periodically boot a pinebook-pro and update the wip-pinebook-pro branch <kcombinator[m]><cbaines "kcombinator, this exists https:/"> Much appreciated. I somehow didn't see that <vagrantc>i think i originally installed from a binary installation on a foreign distro ... or guix system init onto boot media from another machine, can't quite recall <vagrantc>the LCD display, keyboard, mouse, serial console all work ... i've only used with usb ethernet <vagrantc>maybe usb wifi ... pretty sure the built-in wifi requires non-free firmware and therefor won't work with linux-libre <vagrantc>similar story with the usb-c video output <vagrantc>i keep trying to rebase the patchset down a bit so that it could be merged on master <vagrantc>sometimes people necourage me to merge it as is ... but it probably needs a good deal more review <vagrantc>pushing the patches upstream would also help a lot <vagrantc>too many "someday i'll get around to" tasks :/ <vagrantc>just run it from microSD ... barely touched the eMMC :) <vagrantc>if the nvme worked ... it'd be a decent little laptop <vagrantc>but aarch64 substitutes are usually pretty behind, so ... ironically for a slower machine you end up building more :/ <cbaines>I've got an nvme drive in the Pinebook Pro I've got, it's not running Guix though <vagrantc>oh, i think u-boot can't read the nvme ... and guix doesn't support a split /boot partition <vagrantc>so that might be hard to run Guix System off of the nvme <cbaines>I use the nvme drive for the store and build directory <vagrantc>though, pretty sure there is a bug regarding split /boot :) <cbaines>I was trying to install Guix on an old x86_64 system recently, and that wouldn't boot off an nvme drive either <vagrantc>well, all the patches on wip-pinebook-pro are basically from a manjaro maintainer, as far as i can tell ... so should be pretty similar <meo>i cant get guix installation to boot on hyperv gen2, initrd can't mount the installation fs, I presume the scsi driver is missing? <cbaines>that's more of a #guile question than one for #guix, but the answer is yes <no_nick_name>helooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo <no_nick_name>where i find documentation for making standalone guile application <cbaines>no_nick_name, maybe you need to register your nick <cbaines>I don't know, I'd see the #irchelp channel for IRC help <rekado>is that extra line break intentional? <dante>Question: during local build, guix creates a chroot in /tmp (if I understand correctly). How big should one's /tmp partition should be to not have the builds fail? <dante>I know it depends on the package... but any safe size? <mroh>Good morning nckx and #guix! <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) <nckx>cbaines: I do but it's not usually swapond. <nckx>Swapon'd. Swappedon. Swaponned. <dante>nckx, I see. Thank you. May I also ask what you think would be an ideal /var partition size? <cbaines>interesting, I don't think I've experimented much using a tmpfs for the build directory <dante>Oh... My /var/guix partition is 700M. I meant the /var partition in general... (off-topic) *nckx 's always been a single-partition person. <nckx>So no experience, sorry. <dante>I'm moving on to multiple partitions and it's quite a slippery slope, it seems. <nckx>cbaines: I've never benchmarked it. It may well make no difference if you have ‘enough’ RAM. <nckx>Then even without tmpfs most files would live & die cached without ever being written. <pineapples>Umm. About the issue I had yesterday.. would someone elaborate if that was an intended behaviour or if Shpeherd is just misbehaving? <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/ <civodul>apteryx: hi! in general i'd recommend running "make release" on your machine, with offloading for other architectures <civodul>and probably virtualization as well for "small" derivations that are not offloaded, such as grafting derivations <civodul>now, if you built it on berlin, running it on your laptop should just end up fetching substitutes <civodul>hmm though the commit ID is actually an input to the 'guix' package starting from 8ecc265c5c6519986758567682726647850d5d03 <brendyyn>lle-bout: looks exciting. Do you think it will make much difference using gcc 10 vs 7 for everything? <lle-bout>brendyyn: it's also because I don't think gcc 7 contains icelake specific optimizations <brendyyn>Is it possible to make your guix 'x86-64-v4' for example to enable modern optimisations? <rekado>brendyyn: I was thinking of building packages for different “micro architectures” <rekado>I think this would be neat for HPC <apteryx>civodul: yes that was my expectation (100% substitutes coverage) but that's not the case for some reason <brendyyn>rekado: is it superior to having generic binaries that dynamically detect what cpu features are available and load in the code at run time? <roptat>although I can't test easily, because make creates the multiple nodes version, not the single-page version <civodul>apteryx: re "for some reason", it's because of the commit ID, as i wrote above <lle-bout>I think function-multi-versioning is great but AIUI it's not perfect either and optimizations are still better with -march <civodul>did you read the blog post referenced there? <rekado>brendyyn: no, it’s not superior, but libraries that detect CPU features and swap out implementations are few and far between. <rekado>I suppose it would be more practical, though ultimately we would want applications and libraries to shift towards pluggable implementations <civodul>i'm convinced rebuilding everything with -march=native is not viable the reasons mentioned there <lle-bout>civodul: FYI I was talking about the feature Function Multi Versioning and not the repo itself <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 <rekado>optimizations in a generic way.” <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 <civodul>apteryx: the version string is taken from the 'guix' package <civodul>which itself comes from "make update-guix-package" <civodul>lle-bout: first find benchmarks, then we'll discuss :-) <civodul>it's not like Emacs will benefit from AVX2 <apteryx>civodul: on berlin the last two automated commits read as 'gnu: guix: Update to 1.3.0rc1.', and 'gnu: guix: Update to ea4f8d1.' <civodul>Intel's marketing is so strong that everyone think -march=native will magically squeeze performance out of every single program <lle-bout>civodul: maybe improvements will be small but small+small+small becomes sizeable, I am looking to improve battery life on my laptop that's why I try to recompile everything. <civodul>apteryx: did it change the base version string of the 'guix' package? <civodul>lle-bout: maybe; benchmarks will tell <apteryx>fun, didn't know the VM image was running XFCE <civodul>apteryx: if you did "make release", it should have created two commits: one for 1.3.0rc1, and a second one for 1.3.0rc1.cabbage (where "cabbage" is that short commit ID) <rekado>we would need to take advantage of the fact that the vast number of packages won’t benefit at all, so they should be shared. <rekado>the “micro architecture” would rather behave as an overlay of sorts <civodul>i very much think that load-time selection/FMV is the only viable approach <brendyyn>suppose a particular program would benefit, would it be likely to make much additional difference to have all its dependencies also with those optimisations? <apteryx>I have to go, will investigate this later, but the VM image at least seems to boot and run OK <apteryx>also grep -rin PACKAGE_VERSION doesn't report any 1.2* strings <civodul>apteryx: note for later: upload RCs to alpha.gnu.org, not ftp.gnu.org <apteryx>OK! is this handled by the maint scripts? <civodul>you have to explicitly say --to alpha.gnu.org:guix or something <brendyyn>we wouldnt be able to use just "-march=native", because that would make the builds non reproducible <apteryx>civodul: I've at least recreated the version-1.3.0 branch with what I used to generate artifacts that are on berlin <apteryx>e990899bd adds a check for guile-lib <apteryx>51f95d4e64 is untested but should allow easily testing the install script with any local Guix binary archive <apteryx>I think I've cherry picked all the recent important fixes from master, but otherwise ping :-) *apteryx really has to go now ;-) *brendyyn sees ''() in scheme. wat <rekado>the empty list inside a quoted expression <rekado>you’ll see this in substitute-keyword-arguments expressions <brendyyn>in a repl it comes out as the literal (quote ()) <Dr8128>Does anyone know how to make ed remove spaces? I tried 's/ //' and other things such as 's/l N/lN' but it all fails. <Dr8128>Seems like the s command just chokes on spaces <Dr8128>BTW, the 'l N' is becaus ethere is an l before the space and an N after it. <Dr8128>I guess that ed cannot search for the space at all, only 's/l.N/lN/' works. I just need to use the characters around to space to refer to the space. <lfam>Do we have a way to "compile" Python software that doesn't come with a setup.py file? <lfam>I know that we can package raw Python scripts (e.g. tremc), but my understanding is that it hurts performance <lfam>When deciding if a patch should be committed to master vs core-updates, do we "care" about cross-compiled builds? Or do we only count native builds? I'm looking at <https://bugs.gnu.org/47693> <civodul>apteryx: can we stop rebasing version-1.3.0? that way i can help cherry-pick the relevant fixes <nckx>civodul: What's the SRFI for exception mishandling...? Thanks for squashing (I hope) one of those pesky networking bugs! <nckx>lfam: I'm trying to think of a strong argument for ‘caring’ but come up dry. <lfam>Will it create a huge number of CI jobs? <lfam>If you have a strong feeling about it, that could be enough, too <nckx>Does CI cross-compile now? <lfam>There are some cross compiled jobs, but I'm not sure of the scope <nckx>But the graphics have got nicer *again* since I last checked (this must stop! they're distractingly pretty), so who knows what else I've missed. <lfam>I noticed them when looking at failures on the ungrafting branch *lfam makes patches for all the gstreamer bugs <nckx>Well, right, certain packages are cross compiled, but not entire package sets IIUC. <lfam>It would be great to make sure we UC <cage_>hi, ia mtrying to compile guix from git (on a guix-s vm) however when launcing configure i get an error and the config log shows a line like: ld: cannot find crt1.o: <g_bor[m]>cage_: are you in a guix environment guix? <cage_>it was working until (seems to me) i lauched a guix gc <lfam>You've deleted the files used by the environment :) <lfam>Exit the environment and run `guix environment guix` again <lfam>If you delete the development dependencies with `guix gc`, you'll often need to re-bootstrap and re-configure too <cage_>lfam, g_bor[m] it works now!! thanks a lot! :)) <cage_>alose learnt something about guic gc :) <lfam>Those environments are not registered to protect them from the garbage collector <lfam>You can do `guix environment --root=~/guix-dev-env.root guix` to register them <lfam>I've never used that, but it is an option <cage_>i am realizing guix is a very huge and complex project <lfam>Heh, I can't argue with that <lfam>I hope it's not too complex <cage_>i am i learning :) , i was even able to submite a couple of packages definition (with help from other people) :) <cage_>it was fun but also difficult :) <lfam>As you learn, it will become easy <g_bor[m]>:) well, that depends very much on the package... <lfam>What do people think about <https://bugs.gnu.org/47946>? It seems fine to me; I noticed these files appearing recently in my `git status`. But I don't know much about the docs <lfam>I guess it must be fine. We were already ignoring these files, but now they have grown past '9' to '10' <iskarian>Hello again :) how would I use an arbitrary package definition file (i.e. hand-written by me) in a system configuration (/etc/config.scm)? <cage_>uhm...i ham getting a scary C++ error when linking the darmon ld: nix/nix-daemon/guix_daemon-nix-daemon.o: <lfam>iskarian: I don't have any examples to show you, but I think you can just include it in the config.scm file. <cage_>unfortunately paste.debian says is just too long :-) i am going to cut it a bit <nckx>iskarian: Since it's all just Scheme, you can define anything you want and use it freely. I recommend keeping it simple like <https://paste.debian.net/plainh/f471fe0c>, you can experiment with multiple modules/channels later. <lfam>I just filed GNU bug #48000 <lfam>That number is increasing so fast these days <lfam>Huh, that's unexpected cage_. Are you sure you are within the development environment? That is, within `guix environment guix`? <cage_>honestly i never seen such a scary error message until now :) <cage_>i think yes, i launched the command you suggested and i got an '[env]' on the prompt <lfam>And then, the commands to build are `./bootstrap && ./configure --localstatedir=/var && make` <lfam>I'm stumped! Does anyone else have any ideas? <cage_>probably i just screwed the system beyond repair :( <iskarian>nckx: d'oh! Yeah, that makes sense :) I'm not familiar with scheme so a lot of this is just copying incantations to me <cage_>i think i'll start with a fresh vm <lfam>I don't think you can screw it up this way, but I understand that it's easiest to start fresh <civodul>nckx: heh, "exception mishandling" is the best summary i could come up with <nckx>iskarian: I started that way once! <nckx>civodul: I like it. It feels appropriate. <lfam>Nobody will ever have a better domain than w1.fi <cage_>time to go for me, lfam thanks again! <leoprikler>lfam regarding Gstreamer, Totem is always nice to have and pitivi for the editing services <leoprikler>well, since it's just the plugins, that means totem + your favourite set of differently encoded movies <drakonis>what's the status for the guix daemon in guile these days? <drakonis>is it still moving in bursts on a yearly basis? <civodul>drakonis: it's moving in bursts, but it's hard to estimate that the periodicity is <drakonis>it would be certainly quite nice to finally see it finished <lfam>civodul: I just did `hostname berlin` on berlin.gnu.org <drakonis>i'm curious however about whether i can generate a system but not build it <civodul>lfam: one "interesting" class of mistake that Guix System allows is reconfiguring to a completely different setup <lfam>Looking in the shell history of the root account, I see this recent command: `hostname overdrive1.guix.gnu.org` <lfam>So, that's probably got something to do with it <lfam>Not sure about your question re: generating a system drakonis <lfam>I don't know what you mean <roptat>drakonis, what's the difference between generating a system and building a system? <drakonis>hmm, i meant generating a plan for the system <drakonis>like seeing the files that can be output from the functions <lfam>That would be the derivations <lfam>You can do, for example, `guix system build config.scm --derivation` <lfam>There is not an intermediate step between the derivations and building <lfam>Well, you'd need to also pass --no-grafts if you wanted to avoid building anything <vagrantc>guix system build doesn't *quite* build all the same things as guix system reconfigure (e.g. bootloader and related files) <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 <lfam>There is the --quiet option <lfam>You can also do `guix build foo -v1` <vagrantc>honestly, it would be nice to be able to set various verbosity modes regardless of which command you're running ... <lfam>--verbosity=level is a Common Build Option <lfam>You can set it on any command that builds things, IIUC <lfam>nckx: Got any ideas about it? <vagrantc>i should try again ... i recall having trouble getting the kind of output i wanted and so started using my various workaround commands :) <nckx>lfam: Why one would run that on purpose? No. <nckx>I assume someone was working on ovd1 and got their windows mixed up, but it's not a very strong hypothesis. <lfam>Based on the shell history, I had the same hypothesis <lfam>I suppose we'll never know <lfam>It's nice to do everything with sudo instead of logging in as root, for better logging <lfam>Maybe we should close the root account <lfam>The sudo commands are all recorded in /var/log/secure <nckx>I'm not against that, although I do always sudo - su so I can C-r ‘that exact reconfigure command again’. But I'll live. <lfam>After a little while, you would be able to recycle your own history <lfam>But, we'd lose the ability to borrow from each other <nckx>I think installing some extra securities makes sense for what berlin is. <lfam>So maybe it's better as it is <nckx>Not strictly true: I could easily sudo grep others' bash history, I just prefer not to. <lfam>I actually don't know the recommended way to disable root logins for our use case <lfam>We don't really need to disable it anyways. Just discourage it <nckx>I could, but why? (I meant ‘sudo su -’ but you figured that out.) <nckx>My keystrokes aren't precious gifts from the gods. Is there a technical reason? <noisytoot[x]>I think commands entered there would be logged in /var/log/secure <nckx>I mean, the new session is logged, but not what happens inside it, and that's true for both. <nckx>acct is in Guix but I've never tried it. <nckx>noisytoot[x]: What does the [x] mean? <nckx>It's the coolest letter so it's obliged to mean something. <noisytoot[x]>nckx, I am connected via an XMPP bridge, it is to make it different from Noisytoot *nckx always forgets that XMPP exists and does a shame. *raghavgururajan also connects from XMPP *raghavgururajan is watching `Wrong Turn 3: Left for Dead` <nckx>"If [Wrong Turn] 2 raised the bar, then [Wrong Turn] 3 lowers it right back down to where it was, and possibly a notch or two lower." ***jx97 is now known as jx96
<nckx>Did you not see the epic netsplit unfold before your bleeding eyes. <nckx>Or does your bridge filter those out. <nckx>Wow, even ChanServ is down. <nckx>We are rudderless in an angry sea. <iskarian>I have a package kernel-loadable-modules which uses the linux-module-build-system, but how do I make sure the build system uses the same kernel version as the OS?