<ryanprior>My local Guix build/test environment is royally screwed up. I did a make clean, configure, make and afterwards when I run "./pre-inst-env guix" it says "./pre-inst-env: 55: exec: guix: Permission denied"
<ryanprior>Anybody seen similar problem? Any suggestions for what I should try?
<ryanprior>Well, environment, not env. But I try to run "guix env" multiple times a week and my brain just cannot accept that it is not a valid shortcut. I guess eventually I'll figure out how to patch the Guix CLI to make it valid =X
<mdevos>ryanprior: if all else fails, you could try to git clone the source repository again
<mdevos>did you run sudo ./pre-inst-env guix etcetera at some point?
<mdevos>(or sudo make install or something like that)
<mdevos>in that case, some root-owned files could have been created in the source/build tree
<ryanprior>I ran "make guile" and now it works. So weird! I'd already run "make"
<mdevos>I tried deleting it, and then ran "make", and the first thing "make" does is recreating it.
<ryanprior>Well, it's possible that make is behaving in unusual ways on my system, because make has not exited 0 for like ~6 months. It always chokes on some PO files and dies after doing most of its work :\
<ryanprior>And I've tried debugging that but the best answers I've got are "yeah it does that for some people, but it's not a problem" and I'm not even clear on why make wants to generate the German docs when I never asked for them
<mdevos>ryanprior: I've got the issue at some point as well, and it disappeared at some point
<ryanprior>Right, that's what people have said, like it's a wandering poltergeist
<ryanprior>I want to learn more about the build system and how Guile works so I can rip out GNU make and create a tup build system that isn't subject to all these shenanigans
<roptat>I also have (link-show) that does the same as "ip l show" (including filters: (link-show #:device "lo") or (link-show #:type ARPHRD_ETHER)
<PotentialUser-54>I cannot seem to locate the key for the build farm. I keep getting : substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable
<PotentialUser-54>I am installing guix on top of arch and when I ran the install script, I told it I did not want to load binaries.
<PotentialUser-54>It can't seem to build successfully, so I wanted to try to load binaries. I cannot find the key for ci.guix.gnu.org on my system.
<marusich>efraim, I think I need 2da8fcfdee7cfde8110a68806f3c4d497f217fe5 for powerpc64le-linux, too. But can you remind me: why is it OK for binutils-final to refer to static-bash-for-glibc on powerpc architectures, but it isn't OK on other architectures?
<marusich>dftxbs3e, I do not need an answer to my prior question. I figured out a solution. It turns out that in commit 4a914de930a8317cab5bc11bdb608e3a3da3d1ad, we added logic to gcc-boot0 that would add configure option --with-long-double-128 when the boot triplet is "powerpc64le-linux-gnu". Maybe that was correct at the time, but it is not correct now. Currently, the boot triplet is "powerpc64le-guix-linux-gnu" - the special boot-triplet procedure
<marusich>adds "guix" to the triplet during commencement.
<marusich>So, I was able to get past that problem, and build more things, by changing that to add --with-long-double-128 when the boot triplet is "powerpc64le-guix-linux-gnu".
<marusich>I imagine I will need to make many changes similar to what you have already done, so I will be looking at your commits from months ago and seeing what I can take.
<marusich>FYI, I am going to put my work in the wip-ppc64le branch. I do not intend to rebase that branch. It seems nobody has been using it for a long time, so I just started making commits there. I merged master today.
<marusich>I have pushed my most recent changes to the branch, so feel free to take a look.
<apteryx>bootstrapping question: is it important to care about the reproducibility of intermediate bootstrap 'nodes' ?
<apteryx>the specific case is rust; I think the early bootstrap chain might not be reproducible, but I reckon the later rusts must be.
<ryanprior>apteryx: if you want to bootstrap for the purpose of "trusting trust" minimization, then you need reproducible intermediate steps.
<ryanprior>If you just want reliable hashes of the final built products, then the intermediate steps are less important. But I think the trust use-case is important to a lot of people in the project.
<timmydo>can someone tell me if (service network-manager-service-type) means i would use nmcli to set up my network interfaces? or if i want a static interface do i also throw in a static-networking-service-type?
<iyzsong-w>timmydo: yes, you can also use 'nmtui', NetworkManager will manage all interfaces, it can use static configuration.
<timmydo>iyzsong-w: thanks. so basically my network config will not be stored in config.scm then?
<iyzsong-w>yes, i think then they're in /etc/NetworkManager
***lukedashjr is now known as luke-jr
***iyzsong-- is now known as iyzsong-w
***amfl_ is now known as amfl
<efraim>marusich: there's an extra file that's a bash script specific to powerpc machines. I suppose we could just un-patch-shebang it back to /bin/sh
<xelxebar_>Unrelated, but I'm also having trouble building nyxt from the `2-pre-release-4` tag. Would someone mind giving it a try? (guix build --with-commit=nyxt=2-pre-release-4 nyxt)
<new-guix-user>That didn't work, but I'll try appending the specific packages I need to the config.scm file
<xelxebar_>new-guix-user: What exactly did you do and how did it fail?
<new-guix-user>I tried to figure out a way to make emacs available globally (and couldn't find one sans adding it to the list of packages in config.scm)
<xelxebar_>Oh, you want it available for all users, globally? Or do just want a specific user to have emacs?
<new-guix-user>I have emacs currently installed on root, and I'd like all users to be able to access it without having to reinstall its dependencies for each user
<xelxebar_>In the former case, then putting emacs in the packages of your operating-system declaration is what you want. In the latter case, you're probably better off just defining a manifest for that user.
<efraim>yay compression and deduplication. guix gc cleared 168GB of space, df -h says 25GB new unused space
<roptat>you probably didn't see yesterday. I was working on guile-netlink. I now have a first version of the high-level api I wanted, for links. I have link-show (similar to ip l show) and link-set (similar to ip l set). So I can do something like (link-set "lo" #:down #t) which does the same as "ip l set lo down" :)
<roptat>my goal is to replicate the behavior from iproute2 in guile, then use that higher-level API to re-implement the static-networking-service
<mothacehe>roptat: sounds terrific! it should also allow us to implement a static networking configuration page in the installer
<roptat>ideally, you could use it to create a veth pair and put them in separate netns for instance (one for the container, one outside), and route them, so you don't have to share network with the host directly
<joshuaBPMan>hello guix! I've got a define-syntax-rule* question...I've noticed that if I make a (define-syntax-rule* <lunch>) ... then if I try to create a lunch record via (define my-lunch lunch), I get a compile error that doesn't specify the error-line-number. Is there a way for guile to provide that error line number? Is this a guile bug/feature or a guix bug/feature? Also the correct code would be (define my-lunch (lunch)).
<joshuaBPMan>I'm also wondering if I should file this as a guile or guix issue.
<mdevos>joshuaBPMan: did you mean define-record-type*?
<nefix>hello! I've found a bug in spice-vdagentd, that prevents it from running (I find it very weird that no-one has changed it, since it was changed in the upstream spice repository 2 years ago. It's just deleting 4 characters. How can I change it and push it to Guix?
<mdevos>I would have to look at the error message, but it should be possible to extend define-record-type* to emit an error message in case of a syntax error ...
<mdevos>by extending the syntax-case expression below compute-abi-cookie ...
<mdevos>and using the procedure syntax-source for nice line number information
<apteryx>dandan26P: I think it you start from the lightweight-desktop.tmpl template and just add awesome to the list of system packages (next to where i3-wm gets added in the template), it should just work.
<apteryx>The lightweight-desktop template makes use of GDM as the login manager, and will allow you to choose any WM that installs a .desktop file.
<apteryx>bandali: that'd be awesome! I can lend a hand if needed.
<bandali>apteryx, thanks, will def let you know if i do!
<madage>luis-felipe, mdevos, bandali: I'm somewhat late but I've been using the guix version of Jami and it works here. Yesterday I had a video/voice call with two other people (them being on iOS and Android)
<cbaines>I've just read that email myself and replied
<lfam>I don't know the current status of Cuirass on berlin but, at least in the past, we would only build the "core" package subset of core-updates, until we were ready to start working on it in earnest
<lfam>This would limit the wasted effort while giving some kind of answer to "does it work at all?"
<lfam>I think that's a useful process, and it could be combined with this other proposal
<cbaines>With the prioritisation + build cancellation in the Guix Build Coordinator, I think it's possible to do better than that now
<cbaines>I needed to take some leave, and the team I'm on at the moment has a rather small support rota, but luckilly my support shifts lined up nicely with FOSDEM + the Guix Day :)
*jonsger is still to new in his company for support duties :P
<bwr_noob>hello all - trying to install guix in a VM from the 1.2.0 image, the download speed from ci.guix.gnu.org is pretty slow (15KiB/s), to the point where it's taking many hours to download the needed packages (even if I choose a lightweight WM like i3). Is this normal? / are there faster mirrors to use?
<cbaines>civodul, I'm hoping that by having the narinfo files in a database I can both solve the problem of distributing them to machines to serve requests, as well as doing tracing garbage collection to work out what to remove
<lfam>I'm curious, bwr_noob, which was the "bad" and "good" virtual adapters? It might be useful for helping others
<cbaines>civodul, the point of the database is to keep things in sync, so you'd just do it on the database, probably not via one of the replicas
<cbaines>civodul, but you could do things like cleaning out cached nars on the replicas in response to things being removed from the database
<cbaines>civodul, I'm kind of viewing this as a third component, alongside the Guix Data Service and Guix Build Coordinator, to help with serving substitutes once a single machine is infeasible or too unreliable to use
<cbaines>The publish hooks in the Guix Build Coordinator are OK, but I'd like low latency approaches for serving narinfos and to be able to remove nars in more complicated ways than just based on the generation time for example
***lukedashjr is now known as luke-jr
<jonsger>lfam: thx for all your driving work on staging!
<apteryx>civodul: re parallel-builds; this seems to work for a single 'connection' with the daemon (e.g., it'll spawn up to $parallel-builds in parallel); what I'm wondering is that when I launched multiple 'guix build X' in different terminal emulators, it seems to support maximum 2 concurrently. IIRC this is probably happening the same on my local machine.
<Shmiggles>Q: What are some examples of public projects utilizing Guix for reproducibility?
<civodul>apteryx: "guix offload" uses a global hard limit on jobs per machine (it uses lock files under /var/guix/offload to do that)
<Shmiggles>Ifam: Thanks, yeah. Yeah, there is this (https://gitlab.inria.fr/lcourtes-phd/edcc-2006-redone) in the HPC space. Very helpful. I was hoping to see a more engineering oriented example, though. Considering that reproducibility is such a big selling point in Guix, I am surprised it is so hard to find reproducible workflows in practice.