IRC channel logs


back to list of logs

<bone-baboon>I am getting this error "guix system: error: failed to load '/path/to/config.scm': No such file or directory" when I try to reconfigure a Guix system using a specific system configuration file. This is odd because ls shows the file and bash completion recognizes the file. I can reconfigure the system fine with another configuration file in the same directory.
<bone-baboon>I can also look at the contents of configuration file in question with less.
<civodul>bone-baboon: could it be that this config file includes another one?
<civodul>or uses 'local-file' to refer to another file?
<bone-baboon>civodul: It does not include another configuration file. Although this would be nice to learn about. What documentation should I look at to learn more about that?
<bone-baboon>civodul: I just searched the configuration file for "local-file" and there was no match.
<civodul>bone-baboon: weird; could you try "strace -o log guix system build /path/to/config.scm"?
<civodul>then you look at the 'log' file, and searching from the end, see which file has ENOENT before the error message
*bone-baboon building strace
<zzappie>I just realized that services order in os record can take have effect on system. Eg when there is implisit dependency of one sevice on another and the are placed in reverse order config will work
<zzappie>s/and the are/and they are/
<bone-baboon>civodul: The build of strace failed. Looking at the build log there were two failed tests: execve-v.test and execve.test
<civodul>oh :-/
<civodul>that's an additional bug to report i'm afraid
<civodul>please include details about the kernel being used ("uname -a")
<bone-baboon>civodul: Okay I will report it to the bug mailing list.
<bone-baboon>civodul: Is there a way to install a package substitute and later replace it with the package built locally? If so I will install the substitute for strace.
<civodul>bone-baboon: yes, but that's awkward: you have to "guix gc -D /gnu/store/*-strace*" and then "guix build strace"
<lfam>You would also need to invalidate the garbage collector roots that refer the store item. For example, by deleting profile generations that refer to it
<lfam>Otherwise you won't be able to delete it
<vagrantc>aww, didn't get the pinebook pro patches into the latest linux-libre :(
<vagrantc>i have better ones in the works anyways :)
<lfam>Oh dang it vagrantc. I'm sorry I forgot we were talking about that
<vagrantc>maybe i should just get a fixed arm64-generic for now
<lfam>I didn't mean to
<vagrantc>to avoid rebuilds on other arches
<vagrantc>lfam: it happens :)
<lfam>CC me next time :) My email client will highlight it
<vagrantc>i don't know what was wrong with the trackpad, but it seems all better now
<lfam>Anyways, I'll queue up your patches in a local branch for the next set up updates
<vagrantc>lfam: i did CC you on the initial bug report ... is X-Debbugs-Cc a thing with ?
<lfam>Oh, I guess I missed it anyways / don't really understand Mutt fully
<lfam>When a message is "To" me, it's highlighted with a 'T' character, but when CC-ed, it uses a C character. All this time I've been ignoring the 'C'
<lfam>It's totally my fault
<lfam>Well, I've got that branch queued
<apteryx>roptat: looking at doc-pot-update: in po/doc/; is there a reason for the 'for f in $(TMP_POT_FILES)' loop right at the beginning of the recipe?
<bone-baboon>civodul, lfam: thanks
<vagrantc>lfam: i've got an improved version that i was just about to submit
<lfam>Oh okay
<lfam>We can also push it in between updates. There's no rule against that
<lfam>I just thought it would be nice to batch them
<vagrantc>also supports 5.10, as i like to be able to fall back on a working LTS version in case, say, 5.12.x introduces regressions
<vagrantc>lfam: yeah, agreed
<vagrantc>i guess i could push a wip-linux-libre-next or something so that it doesn't get lost
<lfam>You can push directly to master, too
<lfam>Don't worry about coordinating this kind of thing with me
<roptat>apteryx, mh, no, it should probably be that loop with only one line: $(MAKE) $(srcdir)/po/doc/$$f-update;
<lfam>My workflow is all about local branches, so I can't possible miss it next time
<lfam>Since it's on the local branch with the name I use for kernel updates
*vagrantc feats lfam is tempting fate
<apteryx>roptat: ah, makes sense
<vagrantc>heh... fears
<lfam>No, it's not possible! :)
<lfam>I'm really stuck in my habits
<vagrantc>"what's that hissing sound coming from my computer? ..."
<lfam>The only thing I can't forget these days is the local branches with the expected name. The email avalanche only grows
<lfam>Like a snowball rolling downhill
<civodul>oh, forgot about wip-ungrafting
<civodul>we should merge or version-1.3.0 will be too different
*vagrantc wonders why it matters where version-1.3.0 vs. master differences really matter
<raghavgururajan>sneek, later tell pineapples: #48083 and #48091
<sneek>Will do.
<raghavgururajan>> vagrantc‎: "what's that hissing sound coming from my computer? ..."
<raghavgururajan>Were you running python? 🐍️
***iskarian_ is now known as iskarian
<iskarian>was the nix importer removed?
<leoprikler>yes, it was
*raghavgururajan didn't nix importer was removed
<raghavgururajan>Was there a reason?
<raghavgururajan>*didn't realize
<vagrantc>raghavgururajan: the commit message suggests it has long been broken
<vagrantc>is there a way to opportunistically recompile .go modules instead of just spitting out warnings such as: ;;; note: source file ./gnu/tests/install.scm
<vagrantc>;;; newer than compiled /home/vagrant/src/guix-pinebook-pro/gnu/tests/install.go
<vagrantc>lfam: ok, went ahead and pushed the linux-libre changes. hopefully didn't botch anything too big :)
<lfam>Fingers crossed!
<derivates>hi people, im curios to know which window manager or desktop manager are you using? (and if possible why!) :)
<vagrantc>oh, patches for linux-libre always have lint warnings because it doesn't match some of the package names ... e.g. linux-libre and linux-libre-arm64-generic both can use the same patches
<vagrantc>now i've got to tidy up my u-boot patches
*vagrantc waves
<bone-baboon>I am searching through the strace log that civodul suggested there are lots of matches for ENOENT. Any further suggestions for what to look for?
<lfam>bone-baboon: The final occurence
<lfam>If you aren't sure, share it on <>
<lfam>You will see the program looking for things, returning ENOENT several times in a row until it finds the thing
<lfam>But, at the end, it will have failed to find something, and that's the salient part
<bone-baboon>Here is the strace log:
***iyzsong-- is now known as iyzsong-w
<bone-baboon>The last thing in the strace log with ENOENT is `/gnu/store/<hash>-guix-locale-guix/en/LC_MESSAGES/`.
<apteryx>sneek: later tell derivates ratpoison because it uses 5 MiB of RAM and doesn't get in my way
<sneek>Got it.
<bone-baboon>lfam: thank you I have figured it out.
<lfam>Oh, what was it?
<lfam>Sorry I didn't reply sooner. I got distracted / busy
<bone-baboon>lfam: It was user error on my part. A typo in a file path that `with-input-from-file` was looking for.
<lfam>Oh, there you go :)
<bone-baboon>Maybe the error message could be inproved by mentioning the file refered to in the configuration file that did not exist instead of the error saying the configuration file does not exist.
<bone-baboon>sneek: later tell civodul Thank you. Your questions and strace suggestion where enough to help me solve the error with reconfiguring. It was user error on my part. A typo in a file path that `with-input-from-file` was looking for.
***V is now known as based
***Kimapr2 is now known as Kimapr
***based is now known as V
<bone-baboon>`uname -r` outputs "5.9.3-gnu" but I have "linux-libre-5.11.16" in the store. Why would uname say 5.9.3 when the store has 5.11.16?
<lfam>The store can contain many files, it does not mean they are in use
<lfam>5.9.3 is the version that 1.2.0 was released with
<lfam>So, it sounds like you haven't updated the system (or at least the kernel) yet
<lfam>bone-baboon ^
***leoprikler_ is now known as leoprikler
<leoprikler>sneek, later tell vagrantc that's much more a guile question in principle yes, but you'd need to hack extra machinery into resolve-module (more or less)
<merazi>Hello, GUIX noob here. I hope you're all having a nice day/night. I have a question regarding package management, I've been using the Guix System just by calling the guix package command each time I want to install or remove software, and that works like a charm but, is there a way for me to remove some apps I'm not actually using? For example: I installed the GNOME desktop, which included Epiphany as a web browser (I installed icecat) and gedit as the text
<merazi>editor (I'm using Emacs for that), I tried doing 'guix remove gedit' with no luck, sudo was not any better... So I'm a bit stuck here, Any suggestions?
<sneek>merazi, you have 1 message!
<sneek>merazi, brendyyn says: looks like this:
<merazi>sneek thank you! That's exactly how the epiphany icon looks for me. So... It is fixed on an update... I'll check tomorrow if there are any updates available, thanks again 😁
<merazi>Wait... That was merged one year ago, I should have the newest packaged version of epiphany
<tissevert>hello guix : )
<rekado_>merazi: does “guix describe” tell you that you’re using a recent Guix?
<rekado_>merazi: regarding the removal of packages: the Gnome desktop service in Guix System includes packages by default. You cannot remove them when you use that service unmodified.
<rekado_>to not have them installed you need to override the “gnome” package in gnome-desktop-configuration, the argument to gnome-desktop-service-type.
<rekado_>the default “gnome” package includes the whole suite of Gnome packages, including epiphany.
<sakalli>hi just to check i've understood this right. when i do 'guix pull' the repo gets updated, but the packages and system updates when i run, in my case, 'guix package -m manifestfile'. or is there another more idiomatic workflow?
<rekado_>no, this is the idiomatic workflow
<rekado_>“guix pull” updates your Guix, which includes the full description of the world of software that Guix can access.
<rekado_>all invocations of the “guix” command operate within that world defined by your current variant of Guix.
<sneek>Welcome back pineapples, you have 1 message!
<sneek>pineapples, raghavgururajan says: #48083 and #48091
<pineapples>sneek botsnack
<pineapples>sneek, later ask raghavgururajan: I'll wait, if I have to :) Thank you for your hard work!
<sneek>Will do.
***iyzsong-- is now known as iyzsong-w
<mothacehe>civodul: hey! i'm getting closer on the kmscon (so that we don't both spend time on that one)
<mothacehe>*kmscon issue
<civodul>mothacehe: oh excellent!
<civodul>i'm not looking into it currently
<civodul>(mostly because i don't have access to my partner's laptop to test it :-))
<civodul>hey andreas-e!
<mothacehe>hehe your patch just uncovered a big issue in my initial patch
<abcdw>hi guix!
<civodul>aaah, i guess that's "good news"?
<civodul>hi abcdw!
<andreas-e>civodul: Hello!
<mothacehe>civodul: just sent a new kmscon patch. No more 100% CPU use, and layout switch working on metal.
<mothacehe>going to test on a VM right now.
<jlicht>hey guix!
<mothacehe>hey jlicht!
<abcdw>jlicht: hi)
<rekado_>nckx: IT got back to me; they say you should now be able to access the machine over SSH from berlin.
<civodul>mothacehe: woohoo!
*civodul looks
<Noclip>When should I put an input into inputs and when into native-inputs?
<Noclip>I know they differ mainly/only for cross-compiling but I don't know a lot about cross-compiling.
<leoprikler>native-input if it's invoked during build
<brendyyn>Is there a way to make format error instead of printing a #f as a string
<leoprikler>formatted-message perhaps?
<Noclip>leoprikler: "invoked" means here more than just "referenced", right?
<leoprikler>If the build system has code for something, but never calls it, you don't need to add it to either input
<gastonbe>Hi guys. I keep getting this error when trying to update guix:
<leoprikler>So "invoke" really means "this contains programs, that the build system executes at some point"
<Noclip>leoprikler: What if a program is needed at build and run time? Do I need to put in both input fields then?
<leoprikler>well, in theory yes, but in practise this might result in behaviour, that is not sane
<Noclip>So what should I do then?
***rekado_ is now known as rekado
<leoprikler>First, check whether it's really absolutely needed in both, and if you do add it with an explanation as to why.
<Noclip>The manual says native-inputs is only for inputs needed only at build time but not at run time. Can I do it that way?
<leoprikler>native = build is a bit of a conflation
<leoprikler>native means the code that should be compiled for the machine doing the building
<mothacehe>civodul: now the only known installer issue left is the #f uuid, right?
<leoprikler>If you can do without that, you should.
<leoprikler>you can absolutely have non-native build inputs
<leoprikler>e.g. data packages
<leoprikler>or when some package only snarfs some constants from a shared library
<GNUtoo>Hi, when building a system (vm, docker, etc) is it possible to copy a file to /etc/ ?
<brendyyn>GNUtoo: you can extend the etc-service
<GNUtoo>Thanks, I'll try to grep for that
<GNUtoo>Can the file come from a given package?
<brendyyn>yes you use some gexp magic to do that
<brendyyn>grep for file-append
<GNUtoo>ok, thanks
<Frosku>Is there any way to make guix system reconfigure not run out of memory when compiling? I swear it's not supposed to take more than 32GB RAM to compile qtwebengine...
<brendyyn>Frosku: assigning less threads to it may help
<brendyyn>with --cores
<Frosku>What's the option for that? --cores=1?
<brendyyn>how many virtual cores does your cpu have?
<brendyyn>maybe set it to 12 or 8 and see what happens? 1 would likely take forever
<Frosku>I'll try 8
<GNUtoo>Does it really take that much memory while compiling? or does that happen during linking?
*GNUtoo is curious
<Frosku>GNUtoo: I dont know, it gets to 68% and then OOMs
<Frosku>And takes absolutely forever so it's a pain to reproduce
<GNUtoo>Many years ago, webkit and chromium already took quite a huge amount of memory at linking time with something like 8 cores
<GNUtoo>They probably use things like LTO which are "Link Time Obtimization"
<GNUtoo>AFAIK it puts everything in memory and try to do obtimizations
<GNUtoo>but with many cores the amount of required RAM also increases a lot...
<GNUtoo>And linking is usually done at the end...
<Frosku>I'm just surprised it decided to die there instead of on i.e. the kernel
<Frosku>Speaking of things that take painful amounts of time to compile, any chance of getting librewolf in the repo?
<brendyyn>chromium is bigger than linux
<GNUtoo>what is librewolf? is it a game or a TLS library?
<Frosku>It's Firefox without Mozilla branding
<Frosku>Latest version
<brendyyn>does it actually remove all nonfree stuff?
<Frosku>Isn't that just the branding?
<brendyyn>We already have a firefox called Icecat
<Frosku>Yeah, but that's drawn from an old version.
<Frosku>I have Icecat
<GNUtoo>Parabola also has iceweasel
<GNUtoo>So it might be possible to package that
<Frosku>Librewolf is the latest version
<GNUtoo>What is the latest version?
<GNUtoo>This is the version in Parabola: libre/iceweasel 1:87.0-1.parabola1
<brendyyn>for example firefox has some DRM stuff that icecat removes i think.
<GNUtoo>Whereas in Parabola, icecat is older: libre/icecat 78.9.0_pre-2
<brendyyn>it says that librewolf includes DRM but disables it by default, so we would not package that i think
<GNUtoo>So it should be pretty safe to package Parabola's iceweasel
<Frosku>I think 88 so iceweasel would be good
<Frosku>Much newer
<GNUtoo>At the end of the day the same work probably need to be done anyway
<GNUtoo>So to do that one needs to refresh the patch, not everything might be relevant for Guix though
<GNUtoo>(to get the version 88 instead of 87)
<civodul>mothacehe: yes, i think the main remaining installer issue is the (uuid->string #f) bug
<civodul>there are older issues in the bug tracker, but i'm not sure if they're still relevant
<pineapples>GNUtoo, brendyyn, Frosku: My two cents: I know this is not a make-a-wish message thread, but I'd love if we had Tor Browser packaged
<Frosku>Me too
<brendyyn>pineapples: tor was submitted but didnt get in. now the patches are likely stale
<pineapples>I've seen the patches, and I'm a little dejected by this fact
<brendyyn>pineapples: ive seen a channel that supports running binaries from other standard distros. it may be more feasible to add that and run the upstream tor binaries.
<brendyyn>pineapples: You can help by trying to resolve existing bugs to reduce load on reviewers
<Frosku>qtwebengine failed on 8 cores, have set to 1...
<brendyyn>did it look like it was only using 8 cores?
<Noclip>It seems to be always recommended to download the tor browser bundle from the tor project website instead of compiling it locally or installing it through a repository. Even Nix seems to do that: " `tor-browser-bundle-bin` package is the official version built by patched with `patchelf` to work under nix and with bundled scripts adapted to the read-only nature of the `/nix/store`." What's the reason for this?
<brendyyn>for patchelf?
<brendyyn>Tor Browser has a design goal to remain indistinguishable from other copies of its self for anonymity. if we built it ourselves we could mess that up potentially
<brendyyn>but also Nix devs dont care as much about building everything from source as Guix devs do
<Noclip><brendyyn "Tor Browser has a design goal to"> Ok, that makes sense.
<Noclip><brendyyn "but also Nix devs dont care as m"> Why not split up the guix package repo into two parts?: "main" stays the way the repo currently is and "alpha" allows not-so-clean package definitions to be added. That way guix could provide it's users with optional packages that are not yet bootstrapable.
<merazi>rekado_ thank you for explaining, I just saw the messages
<brendyyn>Noclip: We can create a channel for such things.
<brendyyn>Noclip: I have been thinking of creating it, called "outerguix". It would be different from nonguix in that it would only contain free software, but just software that isn't packaged up to guix standards yet
<Noclip>brendyyn: Yep, that's pretty much what I thought about.
<Noclip>brendyyn: To get more than just 5 packages on such a channel it might help to officially support it and add it to the official guix bulid farm.
<brendyyn>How can a probe in guile the arguments value of tests? for a package. I looked in package-arguments but that just shows some quoted code from the package definition
***iyzsong- is now known as iyzsong
<Frosku>This qtwebengine build is using 22GB RAM on 1 core.
<brendyyn>is your package modified from the default?
<Frosku>Yes, in a way I cant discuss here :P
<Frosku>Well, I can say there's a graft to replace mesa with something else
<brendyyn>i wonder if you can lower the optimisation level to make it build faster for testing
<Frosku>But that should only affect linking?
<Noclip><Frosku "This qtwebengine build is using "> I'm not experienced with building packages from source but this sounds pretty crazy xD
<Noclip>Frosku: Did you try building the original package? Did that perform significantly better?
<rekado>chromium is known for using excessive amounts of memory during linking
<Frosku>Noclip: I've never built the original package
<Frosku>Yeah but there's excessive
<Frosku>And then there's 22GB on a single threaded job
<Noclip><Frosku "Noclip: I've never built the ori"> Maybe you should try it then. Then you will see if the ram usage is caused by your modifications.
<Frosku>My modifications just link to nvidia libs instead of mesa libs, that shouldn't significantly affect RAM usage. I will try it if this fails to find out.
<Noclip><Frosku "And then there's 22GB on a singl"> This makes me feel bad for my 8 GB Ram laptop ...
<Frosku>(on an aside it'd be really nice to use... I can't remember the library but it handles this without having to graft everything)
<Noclip>(And this is exactly why I think the above discussed "outerguix" channel should be supported by the guix build farm!)
<Frosku> I am pretty sure it's free software and it makes life a lot easier for those of us who made the wrong call in purchasing. :P
<rekado>we already have such branches, but domain specific
<rekado>such as guix-science
<Frosku>Without bundling nonfree
<Frosku>OK we're past 68%
<Frosku>And hasn't OOM'd yet
<Noclip>Frosku: Good luck xD
<civodul>apteryx: morning! how's everything building? :-)
<apteryx>Got some offload error from overdrive1 last night (Throw to key `match-error' with args `("match" "no matching pattern" #<eof>)'.). Possibly just my connection reseting around 3 A.M. I'm tuning the po files a bit and will relaunch shortly.
<civodul>apteryx: great; there have been a few new commits on version-1.3.0, notably the kmscon fix
<civodul>let us know if it's fine or if we should stop committing
<apteryx>alright, I'll pull the branch before relaunching the release target
<apteryx>thanks for the heads up :-)
<civodul>do you think you can relaunch it later today?
<andreas-e>It is so motivating that whenever I make a software release, I can just update it in Guix. My distro immediately carries my software :)
<civodul>personal distro :-)
<bone-baboon>I installed Guix on a computer using the 1.2.0 installer. I have since pulled and reconfigured many times. uname shows the kerenel version is still the version of the 1.2.0 installer. Do I need state the desired kernel verison in the system configurtion?
<brendyyn>did you reboot?
<tissevert>yeah that's exactly how I feel : creating one's own packages has never been simpler and they are «real» packages with the same status as any other installed package, that feels like the «right» way to do it
<Noclip>Is guix just a package manager or a distro generator ... (This is not a serious question.)
<brendyyn>its a library for creating distros
<tissevert>maybe a good package manager should just be a distro generator ?…
<bone-baboon>brendyyn: Good question I am not sure. I will try rebooting the computer.
<brendyyn>bone-baboon: uname -a will show you the linux that is booted. you wont see the new one until you reboot
<tissevert>c. 2010 I was playing a lot with squashed file systems, trying to get a script to generate a ro image to boot on, and never to modify it directly but instead regenerate a new clean image at every change
<andreas-e>bone-baboon: And "uptime" will show you for how long your computer has been running.
<tissevert>I was using an existing package manager to install the software into the target system before squashing, now guix feels like the best implementation I could dream of
<tissevert>it gives me pure system I don't need to mess with but on the other hand I don't need expensive resquashing of all my root fs image each time I add a small utility
<tissevert>yeah, I'd say a marvelous library for creating distros like you say brendyyn
<Noclip><tissevert "c. 2010 I was playing a lot with"> When I got into linux I thought about something like that but had no idea how to do it. Now where I know Guix, Nix and Btrfs that probably won't be needed anymore.
<civodul>tissevert: mothacehe gave a great talk at FOSDEM about using Guix to cross-build images for "embedded" systems
<tissevert>yeah, I'm grateful I gave up long enough ago because that would've made my work completely obsolete ^^ (I still have a big crush for squashfs and unionfs though)
<tissevert>civodul: oh ! thanks !
<tissevert>I've been wanting to see if I could leverage guix to create light enough images for my small eeePC to use as a pokedex : )
<brendyyn>I ran (specification->package "foo") in a repl then suddenly guile dissapears saying its been nice interacting with you
<Noclip>tissevert: Do you use btrfs?
<tissevert>on our server but I didn't make the choice and I don't know much about it, I've mainly faced the consequences when it filled up and I had to flash-learn about rebalancing
<tissevert>(longest downtime ever… t'was a sad day that day)
*civodul amazed that bigloo was updated
<tissevert>package descriptions are i18ned ?
<Noclip>tissevert: But you do know about it's snapshot capabilities?
<tissevert>Noclip: kind of. I know it's what it's good at, I know we have a systemd service that snapshots our / periodically (daily ?) but I haven't seen or used that part myself
<tissevert>and I don't see clearly how it could interact positively with NixOS or GuixSD since profile generations already offer something similar
<tissevert>or maybe reserved for data storage ? how do you use it ? are there cool tricks I haven't thought of ?
<bone-baboon>andreas-e: thanks
<bone-baboon>brendyyn: Thank you. Rebooting worked uname now shows 5.11.16-gnu.
<Noclip>tissevert: It should be somewhat similar to what you did with squashfs back then but much more powerfull, simpler and efficient.
<tissevert>oh ?
<Noclip>Yea, for the OS itself Nix/Guix should make btrfs snapshots obsolete. But you could still use it to take care of your data.
<rekado>FWIW, ZFS snapshots have saved my butt a couple of times.
<tissevert>but you mean there's a RO component with btrfs ? what I mainly like about squashfs is : it's so small I can fit it in RAM
<tissevert>hmmmm ZFS pops again… : (
<rekado>when I accidentally let Guix delete part of /gnu/store due to misconfiguration
<bone-baboon>Does that mean that whenever I build a new Linux-libre kernel that to start using it I need to reboot the computer?
<tissevert>I hear about it every now and then, and each time I try to learn about it and wonder if I could be using it this time for this new disc I got it's always «no it's too complicated for you / you don't need it / not the right usecase» : (
<Noclip>Btrfs and ZFS are like siblings.
<tissevert>rekado: how do you use it ? what's needed ? (last time I read about it I was confused about the «no formating» it seems to simply «stand there» on its own)
<Noclip>tissevert: Yes both btrfs and zfs support RO snapshots.
<tissevert>so I could use it for like «instant snapshot» instead of having to compress a dir into a squashfs ?
<Noclip>As soon as a RO snapshot is created it is read only and can't be changed anymore.
<rekado>tissevert: I don’t maintain the ZFS installation.
<tissevert>too bad : )
<rekado>I merely wanted to mention that file system snapshots can be useful even in the presence of all the neat features Guix has to offer.
<Noclip>Yes, snapshots are instantly / atomic on btrfs and zfs.
<tissevert>hmmmm that could be useful
<tissevert>rekado: ok ! thanks for that I'm not yet fully aware of everything guix offers and how it could still be augmented
<tissevert>I haven't played enough with it to trash it badly : )
<rekado>tissevert: here at the institute ZFS is set up to snapshot directories once per day; I can access the past state via a hidden directory.
<Noclip>rekado: Using snapshots on top of guix/nix should give you an additional level of security.
<rekado>yeah, “convenience” is the word I’d use.
<tissevert>is it like a kind of LVM / raid thing ? do you know if there is a file system formatted over it ?
<rekado>sure, you *could* restore from backup, or you *could* reinstall based on the contents of manifests, etc, but just undoing a mistake by restoring a snapshot is usually quicker
<rekado>ZFS *is* the file system
<tissevert>ok thanks
<rekado>but here it presents itself as just another NFS.
<Noclip>Btrfs and zfs can replace most lvm features.
<tissevert>oh, but maybe because it is actually served from a network server ?
<brendyyn>how do i actually build a package from the repl?
<tissevert>so is there like a «mkfs.zfs» ? I was looking for it last time I tried to give it a go and never found it and then a clowder of sys admins told me how it was mainly useful for virtualization clusters and it wasn't used like I generally use a file system (format / mount)
<Noclip>tissevert: Also snapshoting is just one of the features btrfs/zfs support. There is also automated checksumming of every stored data and metadata block to prevent silent data corruption, data deduplication on the block level, multi-device support (somewhat like lvm), raid0 raid1 raid5 raid6 raid10 and built in data compression.
<tissevert>that's a lot ! Oo
<Noclip>I probably forgot some features xD
<Noclip>The list is long ...
<Noclip>tissevert: btrfs has mkfs.btrfs but I'm not sure about zfs.
<tissevert>yeah, btrfs seemed more «usual» somehow
<brendyyn>copy on write is nice but it seems you need to use a special tool for it. if i just copy a file in gui file manager it copies very slowly
<Noclip>I think ZFS doesn't make things always the way you would expect doing it on a linux system. Maybe that is because it's not really a linux filesystem in the first place. Btrfs is made specially for linux and does things as you would expect on linux.
<tissevert>I see
<Noclip>brendyyn: Which filesystem did you use for that?
<Noclip>Mhh, weird.
<brendyyn>i have a raid1 on luks encryption setup. i found that copying files was slow
<Noclip>Was it significantly slower than on ext4?
<Noclip>Btrfs should be a bit slower than ext4 but you should hardly notice that without benchmarking.
<bone-baboon>I am trying to set up a substitute server. The substitute server is up after running guix publish. When I try to pull from the substitute server I get an authentication error. On the computer that is pulling I have run `guix archive --authorize < <substitute-server-public-key>`.
<brendyyn>seems to copy instantly now in pcmanfm. thats cool
<rekado>our build farm in Berlin is now powered by hydropower.
<brendyyn>havent tested it in a long time
<Noclip><rekado "our build farm in Berlin is now "> Awesome!
<Noclip>What was it powered with before?
<Noclip>Random power mix?
<tissevert>rekado: cool !
<brendyyn>curl failed to build. test 644 failed
<brendyyn>resolving ipv6 ip6-localhost didnt work one time
<rekado>Noclip: I’m not sure, but it’s likely the same mix of coal + nuclear + trace amounts of renewables that is common here.
<Noclip>Does curl need internet to build?
<Noclip>Does the package building environment has internet access at all?
<roptat>Noclip, no, the build environment doesn't have network access
<roptat>if the build could access arbitrary files on the internet it would defeat the goal of reproducibility, and it could potentially also download binaries or other harmful stuff that we don't want
<Noclip>brendyyn: curl just compiled fine on my laptop.
<Noclip>And guix challenge says it's identical to the substitute from the guix build farm.
<brendyyn>doesnt seem to be doing it a second time
<Noclip>brendyyn: Did you challenge it?
<brendyyn>no my guix is slightly modified so i cant do that
<Noclip>(I've build it with "guix build --no-grafts --check curl".)
<brendyyn>plus you cant do that if the build fails anyway
<Noclip>brendyyn: But it didn't fail on the second try?
<Guest3>I'm new to Guix & Guile. How can I create an overridable operating-system declaration? e.g. I have a base config, then config A which adds a few packages, and config B which extends config A and adds some services and mount points
<brendyyn>you can use inherit it
<brendyyn>search inherit base-os in
<rekado>Guest3: “inherit” is the easiest way to accomplish this.
<rekado>Guest3: in the “maintenance” repository, which defines the operating systems in use for the Guix build farm we use procedures to generate customized operating-system values.
<rekado>here is an example:
<roptat>Guest3, if you need an example, I also have this for my systems: (the base os being declared in a separate file)
<rekado>this childhurd-os definition inherits unspecified fields from %hurd-vm-operating-system, and then overrides specified fields.
<roptat>(here for the base os I use: :)
<roptat>I was inspired by the maintenance repo, so it's definitely a good source too :)
<Guest3>Thanks guys! That's exactly what I was looking for
<Guest3>Also, what is required for a proper Guix boot? Can I delete everything other than /gnu and /boot?
<leoprikler>Guest3: I don't think so. I'd leave at least /var untouched and without /home you're going to be quite unlucky (though your home can be reduced to just the skeleton)
<wonko7>so how do I go about storing configuration files for wireguard? where do I put them? I've got a handful of files created by a vpn provider to switch between vpn endpoints, they usually live in /etc/wireguard
<terpri>wonko7, i'd expect them to just go in /etc/wireguard as usual
<terpri>speaking of which, /etc is another directory you'd need for to keep, Guest3
<wonko7>terpri: oh, right, I might have been overthinking things
<Guest3>leoprikler: I'm trying to make my system completely immutable(other than modifications by guix system reconfigure). I guess the way to go here is filesystem snapshots which restore every boot?
<Guest3>terpri: the etc-service-type doesn't run at boot?
<leoprikler>Guest3 look towards guix-home and guix-home-manager and stuff like that
<Guest3>leoprikler: thanks, I'll check them out
***leoprikler_ is now known as leoprikler
*civodul wonders what's up with
<roptat>civodul, is it different from
<civodul>roptat: actually no; i guess "guix" supersedes "guix-modular-master"
<civodul>didn't know about that one
<civodul>all is fine :-)
<samplet>civodul: I just pushed the Disarchive commit again with your changes. Thanks for the excellent advice as always! :)
<samplet>(Despite all my spelunking in build-self, I missed that “select?” predicate....)
<morgansmith>leoprikler: How long will it be before the big emacs change? I have another patch I want to send but it will have to be modified for the upcoming build system changes
<leoprikler>I submitted v2 on the 17th, so the 14 day limit would be May 1st, which is the day after tomorrow.
<morgansmith>I'll just wait then :) thanks!
<leoprikler>I might make it May 2nd, since May 1st is Labour Day.
<morgansmith>My patch is to make the emacs-org package reproducible. But I'm actually not entirely certain how to check reproducibility... guix --rounds doesn't do anything if the output is already built. then guix --check --rounds seems to verify against the installed output but I don't want that...
<leoprikler>Hmm, if you're willing to rebase your patch onto 47661-v2, you could send it out now, let it be blocked by 47661 and potentially get some review done early, so that we can merge it quickly then.
<morgansmith>It's a small patch. And it doesn't even really affect the user at all. I'm not super worried about getting it in soon.
<morgansmith>In fact I'm worried it's not needed at all. How the heck can I confirm that emacs-org isn't building reproducibly?
<leoprikler>guix challenge would be one idea
<leoprikler>garbage collecting emacs-org and rebuilding with rounds another
<leoprikler>(as is --check)
<morgansmith>oh I did it! I got rid of the substitutes using 'guix gc -D /gnu/blah...' then I did 'guix build --no-substitutes --rounds=5 emacs-org'. Now I know that it isn't reproducible!
<morgansmith>is this written out nicely in the manual and/or cookbook? I feel like it's important...
<leoprikler>yep, now just send the output of diffoscope (or at least some subset) to bug-guix
<leoprikler>It is somewhat documented as part of 16.6 Submitting Patches
<morgansmith>oh. I just kinda skipped the analysis step and figured it was likely the autoloads. So I made a patch that throws away the org loaddef stuff and replaced it with out autoload stuff. Now it seems to be reproducible. I was right this time but doing a proper analysis might've been the right thing to do
<leoprikler>That is a very nice finding indeed.
<morgansmith>nah, the 16.6 documentation isn't good enough for this. It's what I was referencing trying to get this done. We need to mention --no-substitutes and I really think --rounds should have an implied --no-substitutes
<leoprikler>I'm not too sure about that, --no-substitutes is harder than you think
<leoprikler>but I agree, that --rounds should disable substitutes particularly for the packages that were demanded
<leoprikler>as should guix challenge
<leoprikler>(at least rounds after 1, getting 1 substitute is fine)
<morgansmith>rounds currently only downloads it once. meaning with substitutes on it's basically a no-op
<morgansmith>ok, not a no-op but like --rounds doesn't modify anything at all
<morgansmith>It's an argument that has no effect on the output of the command
<morgansmith>oh and if you have the output already built then --rounds also doesn't do anything. So currently the only way to use --rounds as intended is to not have the output built and to have substitutes disabled. I think I take back what I said about the documention. I think the fault lies with how difficult it is to use the --rounds argument
<leoprikler>sorry, my network hates me
<morgansmith>All good :) you catching up from the logs?
<leoprikler>nah, it stopped at "basically a no-op" for me and I'm currently writing mail on the other end
<morgansmith>I just said this: if you have the output already built then --rounds also doesn't do anything. So currently the only way to use --rounds as intended is to not have the output built and to have substitutes disabled. I think I take back what I said about the documention. I think the fault lies with how difficult it is to use the --rounds argument
<leoprikler>Yep, the weirdness of --rounds is a known issue.
<leoprikler>I think the way people handle it is "guix environment <package> && guix build <package> --no-substitutes --rounds"
<leoprikler>missing a -- true after environment
***lukedashjr is now known as luke-jr
***Noisytoot is now known as \\
***\\ is now known as \r\n
***\r\n is now known as Noisytoot
<morgansmith>so I'm very confused with the emacs build system. So we run the install phase before the build phase. Meaning the .el files get bytecompiled in the store. However, when a file being compiled queries `load-file-name' it returns a path in /tmp. But it can't find the other files it needs to find from that path so I'm pretty sure that files aren't actually in /tmp
<leoprikler>hmm, could you paste that with a dummy package, that prints load-file-name at compilation time?
<ilmu>how do I set environment variable in the system config?
<leoprikler>ilmu: session-environment-service-type
<ilmu>thank you
<morgansmith>oh wait. I'm wrong. All the things do make it into /tmp and apparently that's where we are loading the files from. but the autoloads file doesn't make it into /tmp even though it is built. But when do we put things in /tmp? I'm very confused
<bone-baboon>I am trying to build an i686 package on a x86_64 computer. `guix build --no-substitutes --system=i686-linux go-gopkg-in-yaml-v2` starts building Python-3.8.2 which is not listed as a dependency in the output of `guix search go-gopkg-in-yaml-v2`. Am I doing something wrong?
<roptat>bone-baboon, it could be a dependency of a dependency
<roptat>actually, with --no-substitutes, it's probably one of the core packages, before the final toolchain even
<roptat>--system will build using the given architecture, so it's the same set of derivations as if you were building on i686 directly (it's native i686 compilation because your CPU supports it)
<roptat>so if you've never used --no-substitutes for i686 binaries before, it's expected that you don't get a substitute and start building stuff deep in the dependency graph
<civodul>sneek: later tell samplet yay for Disarchive support! \o/
<bone-baboon>roptat: thanks
<Guest3>Is it possible to re-export an entire imported module?
<roptat>Guest3, it's probably more a question for #guile. I'm not sure about the answer, but I know of this:
<roptat>I think it does what you want
<daviid>Guest3: if you mean the public interface of a guile module, then yes
<Guest3>roptat: yeah that looks like it, thanks
<roptat>\o/ looks like I finally have a working frama-c package!
<zzappie>roptat! this is great
<apteryx>civodul: I have noticed overdrive1 is unreachable from berlin (via ssh); do you observe the same?
<apteryx>fortunately it is still reachable from my machine
<apteryx>but it has a tendency to fail offloads with <eof>, perhaps due to high load
<civodul>apteryx: let's take it off berlin, temporarily
*civodul looks
<civodul>apteryx: i've stopped cuirass-remote-worker there (a bit abruptly), so it's all yours now!
<civodul>lemme know how it goes
<apteryx>thanks! I'll start a release run now
<civodul>you can use it for aarch64 and armhf
<apteryx>yes, that's how it's defined in my local machines.scm file :-)
<apteryx>and powerpc64le goes to
<civodul>right, is that one overloaded too?
<apteryx>so far so good!
<civodul>yeah it's building things, but it seems to be okay
<apteryx>is it something common to get that <eof> reply when the machine is too loaded?
<civodul>perhaps we could temporarily turn off the coordinator though, nckx?
<civodul>apteryx: i don't think so, i've only seen it recently on berlin, so i'm not sure what's wrong
<efraim>My understanding is that should be fine
<civodul>but something is wrong
<apteryx>I'm not sure what it's caused exactly, that's just my suspicion
<civodul>it could be that, we'll have to investigate
<civodul>i had a vague recollection of doing that for Guix but i can't find it
*zzappie just stepped into unknown teritory... infieriors...
<civodul>uh, the comment above was meant for #guile
<zzappie>I want to make guix package of guix checkout that is used in my %load-path to be available inside derivation
<zzappie>create inferior -> lookup guix package -> pass guix package to with-extensions -- Is this the right approach?
<civodul>zzappie: i'm not sure i follow, could you explain in more detail?
<civodul>sounds super meta :-)
<zzappie>civodul: haha, im basically trying to reuse (gnu services ...) code. This fails due to the fact that package patches are not copied to the build side. Maxime (don't know the nick here) suggested me to just include guix in with-extensions and use inferior to ensure that I have same guix package as one that im using
<zzappie>but I get incopatible bytecode errors anyways
<zzappie>I also thought of maybe I need to note which guile is used in guix inferior package and pass this inferior guile to #:guile-for-build...
<zzappie>but at this poing it goes beyond level my understanding of guix innerworkings and I feel like im just doing weird stuff
<civodul>adding guix to with-extensions sounds reasonable
<civodul>it gives you access to all the guix modules
<civodul>but then, i'm not sure where the inferior comes in
<civodul>perhaps that was discussed on the list?
<civodul>i should read before saying anything stupid :-)
<zzappie>yep It's here
*civodul has failed to follow help-guix for weeks :-/
<zzappie>I thougt that point of inferior is to make sure that guix package corresponds to guix in load-path
<civodul>zzappie: is your end goal to build a derivation inside a derivation?
<civodul>that'd be nice but it's not possible currently
<civodul>(the Nix folks have been working on it, "recursive Nix" is the keyword)
<zzappie>the goal is actually to invoke services inside services :D
<zzappie><it's not possible currently> this note pobably saved me a lot of time
<civodul>i know it's disappointing
<civodul>but, there are other things you can do, like using eval/container
<civodul>this one is explicitly for things with side effects, one of which is talking to the daemon
<civodul>maybe it can serve your use case?
<zzappie>civodul: hmm... But Im not sure that I will endup in a situation wher I'll need recursive Guix
<zzappie>shepherd is not running derivations its all plain scheme files
<ryanprior>What's the point of recursive nix / derivations inside derivations?
<ryanprior>(web searching now to see what people already wrote about it)
<zzappie>is this an exmple of mystical multistage code?
<drakonis>complex stuff, yes.
<drakonis>it lets them do chunkier and complex things that would normally not be possible with nix
<ryanprior>Okay, the sense I'm getting is that if we had this in Guix, we could use it to defer package definitions upstream
<drakonis>that'd be possible, sure.
<drakonis>generate package definitions on the fly
<drakonis>one sec
<ryanprior>You could write a package definition that's basically like "go fetch from this git repo, look for a package.scm file, and build the derivation as per the definition there"
<drakonis>i'd like to be able to defer package definition to be able to generate hashes
<ryanprior>what does that give you
<drakonis>hmm, the ability to do rapid experimentation with a package or a CI i suppose?
<drakonis>there's some interesting rfcs now
<ryanprior>what's standing in the way of your rapid experimentation presently
<ryanprior>for me it's lack of cacheing. if a package takes 5 minutes to build and I have a problem with the tests, then every test cycle is at least 5 minutes long, very boring
<ryanprior>if I could say "re-use the cached build stage from last time" this would enable my rapid experimentation with packages
<ryanprior>docker and earthly already do this automatically =D
<rekado>civodul, apteryx If you’re having network problems with berlin, please do let me know.
<civodul>rekado: i'm not sure we do! it might just as well be something else, but thanks :-)
<rekado>IT implemented the firewall changes I requested, which includes deleting unused rules.
<rekado>(“unused” as confirmed by mothacehe)
<zzappie>is it a bug?
<ilmu>oh my lord I just discovered
<drakonis>ryanprior: updating the hashes i guess?
<drakonis>but then i believe i could use a function to generate the hashes maybe?
<cybersyn>i come across a lot of interesting ideas from nixos. does anyone here use it in addition to (not on top of) guix? i have a laptop could run it on, but its obviously simpler to organize as many devices as possible with only guix.
<ryanprior>drakonis: I do not understand which hashes you would want to generate or update *shrug*
<ryanprior>The less I have to think about hashes (as an end-user) the better imho
<drakonis>oh yeah i mean
<apteryx>rekado: I think we're good, some things in our /etc/guix/machines.scm don't work anymore; they should be updated to use overdrive via its wireguard interface
<apteryx>(e.g. ssh access to overdrive1)
<ryanprior>Hashes to me are like assembly code, as a professional I care about it, as an end user I never want to see it
<drakonis>i want to be able to use guix like a ci
<ryanprior>drakonis: what prevents you from doing this now (and does it have something to do with hashes)
<apteryx>roptat: weird, once in a blue moon I get some error about a node not found in the italian translation. Clearing the tree and trying again works fine. Do you sometimes have this kind of very rare failure?
<drakonis>i cant answer the question properly yet
<apteryx>drakonis: if you want to setup your own CI you probably want to configure the cuirass service
<drakonis>i wanted a CI for building my own code
<ryanprior>I would like to have a guix-in-docker so I can easily use Guix in third party CI pipelines (like the corp git forges provide)
<ryanprior>I don't have any experience with Cuirass, would love to learn
<zzappie>ryanprior: you can use "guix system docker-image config.scm" to generate guix-in-docker
<ryanprior>Where's config.scm, do I have to write it?
<zzappie>yes it has to return operating-system record
<ryanprior>Okay well eventually I will try that, has somebody else already done this and pushed it to dockerhub?
<zzappie>there is actually even a template for that guix/gnu/system/examples/docker-image.tmpl
<ryanprior>okay damn writing all this down, I thought it was more complicated for some reason
<ryanprior>we should put out a canonical minimal Guix image on dockerhub though
<zzappie>yes there are some guix continers on dockerhub. But hey its guix make your own ;)
<ryanprior>less friction if people don't have to do this themselves
<leoprikler>I think the problematic part about that is the bootstrapping process.
<leoprikler>There are some alpine/guix recipes out there, so if you have that + config.scm, you can bootstrap your first real guix in docker in CI hopefully
<bone-baboon>What part of the output of `glxheads` would tell me if a GPU has 3D capabilites? 3D capabilities is part of the h-node reporting for a video card. Looking at video cards listed on h-node it looks like those that have 3d capabilities show the output of `glxheads`.
<zzappie>civodul: Taking guile from guix inferior and building gexp refering to guix inferior package works!
<civodul>zzappie: nice hack :-)