<vagrantc>well, 1.3.0 is almost a year old, and from what I recall the goal was roughly to have two releases a year ... <luke-jr>reminder: 1.3.0 also fails to build texlive stuff due to patches moving URIs <vagrantc>the_tubular: there is a recent thread on guix-devel about the staging branch which proposes a timeline for a new release <luke-jr>might be a good idea to setup a Guix-hosted mirror (or at least redirection webserver) to avoid these issues <vagrantc>there is a mirror in china from what i recall <luke-jr>eg, Gentoo mirrors all source files to distfiles.gentoo.org <luke-jr>vagrantc: but Guix doesn't use it by default, it would seem <vagrantc>oh, you mean a mirror of the source, not substitutes <luke-jr>I had to manually wget the files needed <luke-jr>actually, considering much of it is GPL'd, hosting substitutes arguably makes hosting the source a legal obligation too ;) *luke-jr ponders if Guix is infringing on the GPL :P <vagrantc>it's not required that you host them, but that they be available <vagrantc>though obviously the only way to ensure they're available is to make sure you have them <luke-jr>vagrantc: from whoever provides them (for GPLv2); and in that scenario you have to give notice upfront <vagrantc>there are some backends for sources such as disarchive and software heritage fallbacks, but obviously they don't always work <vagrantc>curious if an arrangement with archive.org would work; i recall archlinux folks saying they used archive.org <luke-jr>maybe the problem is the URI fetched a document, just the wrong one <vagrantc>all that said, i think guix should mirror all the sources itself ... no idea how much additional space that would consume, but i know at least one build farm got a large disk upgrade recently <luke-jr>any way to bypass the 'check' stage for a specific package? (so i can get past this libgit2 failure until it's fixed properly) ***rekado_ is now known as rekado
<GavinFreeborn[m]>Any good resources focused on using guix the package manager and features it offers outside of guix system? <drakonis>GavinFreeborn[m]: the documentation applies to both uses <singpolyma>vagrantc: SoftwareHeritage probably already mirrors most of it <singpolyma>luke-jr: I think there is a no-tests CLI flag or similar <singpolyma>vagrantc: big thing is SoftwareHeritage is git format index but lots of guix packages are using legacy tarballs, so it can make the search hard <bjc>does guile come with modules that can encode/decode xdr? <littlebobeep>singpolyma: Do you know even how to clone entire repos from softwareheritage? I could not find a way to do this from their website it was extremely obtuse compared to standard forges <singpolyma>littlebobeep: it's not really meant for that, but I'm sure you could put a repo clone together from it if desired <mekeor[m]><bjc> "does guile come with modules..." <- maybe ask at #guile? <littlebobeep>singpolyma: I don't understand the point of archiving as many VCS repos as possible then <drakonis>littlebobeep: it is being used for translating guix <cocomeat4[m]>I can see from `guix search linux-libre` that there is LTS kernels available, how can I switch to one of those ? <AceTheMercenary[><cocomeat4[m]> "I can see from `guix search..." <- out them in (kernel "here') under ooerating system <AceTheMercenary[><cocomeat4[m]> "like `(kernel "4.9") ?" <- you can maybe try this? not sure if it breaks <wurt>Hi, which package contains the libuuid library in Guix? I am unable to found it. ***modula is now known as defaultxr
<nckx>cocomeat4[m]: (kernel linux-libre-lts) <nckx>AceTheMercenary[: Is there a ‘but…’ implied there? <AceTheMercenary[>nckx: yeah, then he said something like there's lotta versions or something <koan>hello, is it possible to define a with-input package transformation based on a commit for the input package? <koan>i'm trying to upgrade two packages to their latest commit but one of them depends on the other <efraim>koan: you should be able to do `guix build foo --with-commit=bar=somecommit --with-commit=baz=othercommit` <koan>efraim, something like this doesn't work `guix install emacs-embark emacs-avy --with-branch=emacs-embark=master --with-branch=emacs-avy=master` <jpoiret>emacs-embark and emacs-avy don't really depend on each other either right? <jpoiret>the same command line (with `guix build` instead) works for me <bjc>it'd be nice if the guix boot repl had gnu readline <jpoiret>that'd require a statically linked readline too <bjc>is that particularly difficult, or just a matter of someone doing it? <jpoiret>just a matter of someone doing it i think <jpoiret>hmmmm, `make clean` doesn't seem to clean doc files, and i'm getting a bunch of errors coming from what i presume are outdated contributing.xx.texi files <bjc>i had issues yesterday with the guix manual <bjc>commenting out the build target got me going again. once the build completed i could put the old rule back in <bjc>i assume something changed in the last week or so, since i do ‘make clean’ fairly often <jpoiret>i just think the contributing.xx.texi files are missing from the clean target, but i can't read makefiles beyond the basics <jpoiret>(how do people even write and maintain those) <bjc>automake is a nightmare 😂 <jpoiret>maybe they should've gone with an archaeology major instead <unmatched-paren>jpoiret: regular, human-written makefiles aren't that bad, but i agree with bjc... <bjc>i can read normal makefiles just fine, but automake produces just awful code <jpoiret>yeah, but even the Makefile.am files are cryptic to me <unmatched-paren>i mean, make suffers from UNIX's Curse of Awful Syntax, as do C and sh, but at least it can be decyphered <bjc>it categorically does not <nckx>Problem is that most overzealous 'omg automake teh suxxors, how hard can this be to reinvent' ends up discovering exactly how hard, and now you have automake which actually works and ten improved alternatives which mostly work. <jpoiret>well, for now just manually rm'ing `doc/{guix-cookbook,contributing}.*.texi` did it for me <jpoiret>although i cannot guarantee the above shell globbing to actually be correct 8) <jpoiret>nckx: let's just rewrite it in Guile ™ <nckx>That glob is what I do, so it's correct. <unmatched-paren>I understand that there was a reason for am and ac to come about, weren't they invented in the time when there was tons of UNIces? <jpoiret>oh but for their time, it seems to be super useful <bjc>autoconf is a necessary evil, but i'm not sure what automake was even trying to solve that it actually made better <nckx>I'm not going to defend every choice made in autotools (or that these choices should still be there in 2022), but most of the braindeath in them comes from proprietary Unixes, which they had to support. <unmatched-paren>but honestly it seems that *today*, writing a normal Makefile that invokes pkg-config is sufficient 99% of the time <nckx>‘This is stupid’ — yes because it had to deal with stupid. <koan>can this help with install though? <jpoiret> the same command line (with `guix build` instead) works for me <nckx>unmatched-paren: I'm mostly in that camp, just — pretty please with ffs on top — use standard variable names. <jpoiret>there must be many scientific computing projects out there running into these issues <jpoiret>koan: well, could you describe how and what is not working with your guix install command? <nckx>jpoiret: That is… unfortunate. Anyway, I'll cede the channel to supporting koan :) <unmatched-paren>because cproc needs to do different things depending on the architecture it's being built for <koan>jpoiret, `guix install emacs-embark emacs-avy --with-branch=emacs-embark=master --with-branch=emacs-avy=master` throws an error about conflicting entries, emacs-avy@0.5.0 ... propagated from emacs-embark@0.16 <jpoiret>oh, that's conflict detection doing its things <unmatched-paren>i was trying to say 0.5% of *every* case, since make is enough 99% of the time <jpoiret>can you first do `guix remove emacs-embark emacs-avy`? <jpoiret>unmatched-paren: i just wish shell scripts weren't just a pile of arcane syntax (that's documented sure, but why would I want to read ${arg#*=}?) <unmatched-paren>as i said earlier: C, sh, and Make all suffer from The Curse of Awful UNIX(R) Syntax <koan>jpoiret, still conflicting. Is there a way to ignore the conflict detection? <jpoiret>still the same error after removing both packages?? <PurpleSym>Could someone tell the CI to start building the `wip-haskell` branch? I pushed GHC 9.0 and it takes “a while” to build locally. <jpoiret>hmmm, does anything in your profile depend on emacs-embark? <jpoiret>the thing is that if there actually is a conflict, guix won't be able to save you <bjc>i'm confused as to why emacs-embark requires emacs-avy at all <koan>i don't have anything else depending on these two packages <jpoiret>arf, the pitfalls of guix profile mutation... if only everyone used a manifest :p <nckx>No, but they require each other. I'm not a --with-tranformation= user myself, but it seems like it doesn't go ‘deep’ enough (I don't know if it's supposed to). <nckx>Yeah, I'm in the ‘use code’ camp :) <jpoiret>nckx: i could build a profile with just emacs-avy and emacs-embark with the transformations, so i don't think it's that <jpoiret>koan: can you search ~/.guix-profile/manifest for emacs-avy or emacs-embark? <nckx>jpoiret: Oh? I tried but it failed, I must have held it wrong. Gotta go tho'. <jpoiret>hmmm, let me update to the latest guix then <nckx>I'm sure I held it wrong, I really don't use the CLI much :) <jpoiret>there was a recent change to package transforms, so it may also be the culprit <koan>nothing in my profile manifest about these packages <jpoiret>erf. i'll try with a fresh `guix pull` then <koan>if this can work with a hand written manifest, I'm all for doing it. <jpoiret>very very weird, how recent is your guix? what does `guix describe` say? <jpoiret>i just retried with a fresh guix and i'm not getting that issue either <jpoiret>looking at the profile's internal manifest, the transformation options are propagated properly to emacs-embark's dep <koan>i pulled today, guix d2c5754 <koan>i'm using guix on foreign distro, maybe i've messed up something <jpoiret>no, you're right, with guix install i get the same <jpoiret>it's weird that the semantics would change between guix install and guix shell <koan>so this can work if i make the manifest that would be created with the transformations myself? <zamfofex>Hello, Guix! I know it’s off‐topic, but looking at the logs, I see you have been talking about makefiles. I haven’t fully investigated it, but I have heard some people talk about ‘redo’ being a nice, more idiomatic alternative: <https://redo.readthedocs.io> <bjc>“idiomatic” is a weird word to use when recommending a completely new system <koan>then this is the motive i needed to dive into package definitions :), thanks for your time jpoiret <unmatched-paren>anything that resembles a shell script sets off alarm bells for me :) <unmatched-paren>"one script for every file", while a neat idea, seems a little messy? <unmatched-paren>zamfofex: off-topic discussion generally seems to be allowed here :) <zamfofex>bjc: Yeah, indeed. I suppose I meant more so “concise” or “elegant”, I think. <unmatched-paren>the first example literally contains the exact shell syntax that jpoiret was complaining about: ${DEPS#*:} <bjc>zamfofex: yeah, i get it. i just think its funny the way words spill out of us sometimes. “idiomatic” certainly got a lot of use for a long time in situations it didn't belong <bjc>at least in the rust crowd now everything is “ergonomic” <furrymcgee>why do think make clean is required for contributing.xx.texi? <bjc>redo is apache licensed. i assume that'd be a no-go for the guix build system <jpoiret>furrymcgee: well, `make` was spitting a bunch of errors on me for these after I pulled, and rm'ing them solved the problem <furrymcgee>please have look at Makefile.am and doc/local.mk, maybe make clean-go <unmatched-paren>and anyway, i don't think the build system's license spills over into the program's license <zamfofex>unmatched-paren: It is difficult to find syntax that looks nice for everyone, I think. A lot of languages end up growing weird syntax because of poor planning (sometimes because it is justifiably difficult to look ahead in time). I think ‘redo’ (just as ‘make’) delegates some syntax to the underlying shell, whose syntax can be ideosyncractic because of its age as a techonology. (Also see: <https://github.com/rain-1/s>) <bjc>unmatched-paren: i'd assumed everything would need to be gpl3+ for gnu system <bjc>just for philosophical reasons, not legal <jpoiret>especially since guile has very complicated compiling semantics <jpoiret>the moment you touch macro definitions, everything falls apart <zamfofex>bjc: I think GNU projects should be released under the GPL or AGPL (or occasionally the LGPL), but that doesn’t mean they can’t use other projects that are distributed in other licenses. <nckx>unmatched-paren> zamfofex: off-topic discussion generally seems to be allowed here :) — There's off-topic (‘here's an interesting new system for building software, discuss’) and off-topic (‘check out this cool link about evil SJWs’). The first kind of off-topic is totally on-topic, possibly moved to (the hardly-ever-used) #guix-offtopic if it really grows legs; the second never is. You can always tell the difference. <nckx>Conclusion: don't stress too much about it 😉 <nckx>jpoiret: I used ‘guix install’, that explains it. <nckx>Well, it explains nothing, but it confirms the bug. <jpoiret>right, i'm looking at the package script <unmatched-paren>nckx: you mean the second is never on topic, or it's never moved to #guix-offtopic? <nckx>The distinction sounded a lot clearer in my head, sorry. I don't even consider redo, licencing, etc. to be off-topic here, especially if nothing much else is going on. <lilyp>Watch out, evil CCP nckx trying to hammer and sickle your hard drive! (just kidding in case you can't tell) <nckx>I always forget that's still in there, and once in a while someone gets very angry about it 🤭 <lilyp>Yes, how dare free software advocates support communism? <lilyp>We should all be ancaps trading NFTs for cryptocoins, obviously. <zamfofex>nckx: I suppose I was mostly afraid of interrupting some ongoing conversation with a tangent, I think. <lilyp>When IRC gets hot, we can handle two to three simultaneous topics – as long as help requests make it through, it's no biggie. <furrymcgee>gnu make removes files automatically if they are dependents of the intermediate special built-in target rule <jpoiret>so package transformations aren't applied uniformly throughout the different guix scripts <jpoiret>propagated inputs aren't being rewritten properly with `guix install` it seems <jpoiret>gnnnn, and guix shell produced manifests don't contain provenance information <nckx>Berlin evaluations sure are, at best, slow… <nckx>(That's the optimistic interpretation.) <ryanprior[m]>If I want to define a package where the source lives in the same directory as the package file, how do I express that as a Guile source expression? <lilyp>ryanprior[m]: use local-file with a variable that's bound to (dirname (current-filename)) <ryanprior[m]>Something like that? Right now when I try to build it's giving me "guix build: error: regular file expected" <singpolyma>Note that if you use local-file there is no hash so it will rebuild every time <jpoiret>shouldn't it be (local-file project-dire #:recursive? #t)? <jpoiret>by the way, you should be able to just do (local-file "./" #:recursive? #t) <ryanprior[m]>It doesn't like that, it says guix build: error: invalid name `./' <ryanprior[m]>I tried it with "." too, no dice. Binding project-dir and using #:recursive? #t does the trick. <ryanprior[m]>Don't know, but in either case my CWD was the same as the directory with the scheme file so that doesn't seem like a valid path. <jpoiret>well, looking at local-file source it *should* work <singpolyma>You can also set the source to anything you like and use --with-source=$PWD <ryanprior[m]>I knew about that strategy, but I vaguely recalled you could do it the other way too. Got it working, now I can ship a package.scm as part of the git repo which builds from local source. It works! <lilyp>ryanprior[m]: note that this is in literally every guix.scm shipped out there, so it's easy copypasta <ryanprior[m]>weird to me that the project chose guix.scm as the name of the default manifest for guix shell, when the community was already using that filename for in-repo package definitions <ryanprior[m]>weird that they implemented that whole feature without ever mentioning it once to guix-devel to ask for feedback <ryanprior[m]>in any case I'm using guix.scm as the manifest for a development shell, and calling the package definition package.scm instead <htsr[m]>hi! I'm trying to use qemu-binfmt, it work with armhf but with aarch64 but it doesn't seems to work, I can't build with `-s aarch64-linux`. I think the problem doesn't come from my service configuration (`(platforms (lookup-qemu-platforms "arm" "aarch64"))`). Am I the only one who experience this? <roptat>booted the debian installer on usb, installing debian on a spare hdd I had and then I'll use debian to install guix system on the target drive <singpolyma>ryanprior[m]: guix.scm is meant to be the package def <singpolyma>If you need extras for a dev shell you can use a manifest <roptat>now I'm pretty sure I could have booted the guix system installer image if I could cross-compile it <jpoiret>singpolyma: isn't guix.scm the default manifest file for guix shell? <ryanprior[m]>If they wanted to leave guix.scm for package definitions they wouldn't have made it the default location for a manifest <singpolyma>manifest.scm is the highest priority for guix shell <singpolyma>guix.scm will be used if present and the inputs of the package there are used (so you still get a dev ish shell) <roptat>debian installed, now let's see if it boots :) <ryanprior[m]>Wait so if I make guix.scm a package definition and don't provide a manifest, you get a shell with the dev dependencies for the package? <singpolyma>And if you need extras like linter etc then you can use manifest.scm as per my linked example above <jpoiret>right, what ryanprior was describing was my impression too <singpolyma>To be fair I never read the docs, but I did review the patches :) the manifest.scm priority order for override usage was my suggestion <ryanprior[m]>That's literally one of the problems with this project is maintainers grep the source code and read patches to learn how things work instead of reading the docs. <ryanprior[m]>Trying to learn Guix via the docs was an exercise in futility <ryanprior[m]>Every time I hear about a feature, read the docs to find out how it works, and then fail to understand or use the feature correctly until I read the source code or talk to somebody who did, I'm once again like "shame on me" <singpolyma>I'm honestly surprised that putting a manifest in guix.scm even works <ryanprior[m]>So, I renamed my package.scm to guix.scm and ran guix shell, so far so good, I get a dev shell as advertised. That's sweet. <ryanprior[m]>Then I tried renaming my manifest to manifest.scm with some additional dev packages and running guix shell again- now I get an error. <ryanprior[m]>I have it returning the package record, but that yields: In procedure manifest-entries: Wrong type argument: #<package my-pkg@0.0.1 /home/ryan/dev/my-pkg/guix.scm:19 7f24aeb0fa50> <singpolyma>Make sure running guix shell with the no cache flag? <ryanprior[m]>guix shell: error: /gnu/store/bzl2yy9l7cxml2wnpgyggymm09sr9fj1-tar-1.34 (system: i586-gnu) has no substitute <ryanprior[m]>Which isn't a problem if I rename manifest.scm to mnfst.scm, then it works just fine <lilyp>so for everyone confused about guix.scm vs. manifest.scm vs. package.scm: guix.scm is the community preferred way of writing a *local package definition* <singpolyma>Hmm, yup. Looks ok. Try just using the (package->development-manefest) part without the countdown concert? <lilyp>this is semantically equivalent to package.scm, but the latter doesn't convey any relatedness to guix and its way of building things <lilyp>manifest.scm on the other hand is as you guessed it for manifests <ryanprior[m]>singpolyma: yeah if I comment out the countdown part it works fine. <singpolyma>lilyp: the complaint was just that the guix shell docs do not clearly say that guix.scm is for packages and one could read it as being an alternate manifest name <lilyp>while not unique to guix, there is little confusion (outside of java perhaps) that this refers to a guix manifest <singpolyma>ryanprior[m]: so maybe an issue with the countdown package? <ryanprior[m]>Well, if I comment out the pkg part it also works fine and I can run countdown <ryanprior[m]>I don't actually care about countdown, I was just like what's something I don't have installed normally that I can test with <lilyp>singpolyma: fair enough, that's perhaps confusing, but note that there's two ways guix can load a file described down below <ryanprior[m]>If I change "countdown" to "python-black" it's the same error about tar has no substitute <ryanprior[m]>Countdown and python-black have nothing to do with each other, countdown doesn't use python at all. <singpolyma>lilyp: sure. I never found it confusing because I already know how it works. But do a totally new user reading from the top down it could be more clear <lilyp>"tar has no substitute" sounds like a super weird issue that would affect all of your package building no? <lilyp>please try to get a working tar, perhaps through `guix build tar --no-substitutes' <lilyp>gotcha, but I don't feel like you're supposed to stop reading at this point <lilyp>and any attempt to clarify it would increase verbosity, so I'm not really sure that the vagueness is that bad <lilyp>like, worst thing you try using a package for a manifest or vice versa, rename the file and then either go to the source or don't go to the source and conclude "huh, so that's how that was supposed to be used" <ryanprior[m]>yawn. it could be explained well in like two lines. meanwhile multiple people in this specific irc chat were confused by the current explanation <singpolyma>lilyp: well, in this case the user put the manifest in guix.scm and it sounds like it worked. So they concluded that putting a package in there was not allowed <singpolyma>Even just "manifest.scm (a manifest) or guix.scm (a package, used as per -D below)" is something maybe <singpolyma>lilyp: sure, the -f is already explained in the text but could phrase it that way for extra clarity <ryanprior[m]>"`guix shell' can load packages from `manifest.scm' and also load build-deps from a package described in `guix.scm'. If both files exist, their results will be overlaid (in that order) to produce the shell's profile." <htsr[m]>guix build: erreur : opening file `/gnu/store/33cq2vvf6b4gyw6brb3lzm0675chi8ab-tar.drv': No such file or directory <lilyp>their results won't be overlaid <lilyp>it will use the first that's found <singpolyma>ryanprior[m]: they are not overlaid. It picks the first one it finds in priority order <ryanprior[m]>I got the overlay working with your concat-manifest system, singpolyma, thank you for pointing that out <ryanprior[m]>I don't thoroughly understand where the errors were coming from but I think it's because I'm using some dependencies from a local guix checkout and the paths were screwed up <ryanprior[m]>I ran `./pre-inst-env bash` in my checkout, changed directory to my project, and then ran `guix shell`, and now everything's working <ryanprior[m]>Before I'd been running `guix shell -L/path/to/my/guix` and was getting those errors. So, lesson learned <lilyp>"You have been kicked for being idle" – I need to be more careful then <nckx>Come back to IRC! Here we only slap you. <yarl>inside 'guix shell --pure -D guix', I can't run successfully './pre-inst-env guix build --debug=4 hello' <yarl>guix build: error: | | | bind mounting `/dev/full' to `/gnu/store/jjn969pijv7hff62025yxpfmc8zy0aq0-hello-2.12.drv.chroot/dev/full' <yarl>outside of this guix shell, it works. <lechner>vivien: Thanks for steering me to opensmtpd! It works great. Like you, however, I wrote out the config file verbatim. Given your effort on Exim, did you try to improve Opensmtpd with Guile aside from your quasiquoter? The structure of the file seems like a bunch of lambdas, doesn't it? <vivien>But I don’t remember who and I think it was never merged <yarl>I forgot --no-substitutes, it does not work out of guix shell either <lechner>vivien: Thanks! How would I best go about looking for past correspondence? <yarl>Or I forgot to guix gc, anyway, does anybody knew that? <nckx>I recommend writing smtpd.conf in the native syntax, but that's me. <yarl>can someone try it so I can make sure I'm not wrong? <lechner>nckx: I think Guile with lambda chaining has the potential to simplify once and for all the complexity of mailserver configuration <yarl>Oh, I forgot to say please :) <nckx>lechner: Possibly! I prefer controlling every line by hand. I'll never trust (service mail-server #:open-relay? #f), but that's just me. For those new to mail serving it would be safer than forcing them to write everything out. <jpoiret>yarl: can confirm I get the same thing <lechner>nckx: while i run the danger here of appearing argumentative, i'll add that I find the unified configuration in Guile one of Guix's main selling points. It's never felt so easy to configure different software at the same time <lechner>in fsct, i nol see it as a packager's main responsibility to provide it <yarl>jpoiret well this seem bad. I was trying to get more information during the build of another program I am trying to package. <jpoiret>lechner: hmmmm, packagers responsibilities keep expanding <lechner>compared to Debian, you have a way to go <yarl>asking for more debug causing the crash is strange, I don't know enough of guix. I can't spot where the problem is yet. probably in libstore somewhere? <jpoiret>it seems that the builder dies without having done anything <nckx>lechner: Oh, I did not mean to argue. I love that I have the choice to do both. <nckx>If I were managing larger fleets of machines I'd probably prefer Scheme. <yarl>@jpoiret, should I report this as a bug somewhere? <nckx>bug-guix at gnu dot org please :-) <jpoiret>yarl: why did you need --debug=4 for though? <jpoiret>it seems that it would cause the daemon itself to print a lot of debugging info <yarl>I thought I could maybe spot more precisely why the program I want to package is failing. Maybe it wont. But anyway this worse reporting I guess? <jpoiret>for sure! but unless you're interested in debugging the daemon itself, it seems the things it spits out won't be of much use to you, but maybe i'm wrong <jpoiret>you'd have to increase the logging of whatever is doing the building <yarl>It might be pid namespace on pid namespace thing, I don't know yet. <jpoiret>could it be that the chlidren are not getting reaped properly yet <nckx>While using --debug is almost always a mistake... it should still work. <jpoiret>you could try looking through the proc list and seeing if there are zombie processes <yarl>Do you have an idea of what I can do so they are reaped? <jpoiret>you could try running the tests using something like tini <yarl>I'll write the mail before :) <yarl>jpoiret thanks for the mail, bug report sent. <sleepydog>it was more of an experiment than anything. it was pretty fun <nckx>That is an interesting idea... <sleepydog>i wanted to see if i could build namespaces with guix, that looked like an ordinary linux system to processes inside of it. in the end dynamically linked libs required the presence of /gnu/store, though <jpoiret>how's the perfomance of the overlayfs? <sleepydog>i know it's the default driver for a lot of docker/kubernetes deployments, so there should be people who care if it's slow. but i haven't tested performance <jpoiret>hmmmm great, grub-install failed to update the EFI entry because apparently there was no space left on device, and my old entry's missing <vivien>jpoiret, that’s not what it looks like <vivien>There’s a magic command to clean uefi-related things that you need to get your hand on <vivien>I think nckx helped me last time <jpoiret>yeah, i cleaned the dump-* files in the efivars <jpoiret>but don't you have to reboot for Linux to unlock the efivars? <jpoiret>in any case, i rebooted to w$ and am now trying to edit the boot entries from there, a nightmare. I wish there was a built-in EFI shell so that i could just manually load up grub <unmatched-paren>is there anyone with enough time on their hands who could please review my updated patches for #53833 and #53834? (sorry for being impatient :P) thanks in advance to $WHOEVER :) <lilyp>unmatched-paren: for the cproc one, i think there's things you wouldn't need to let-bind, e.g. ld-for-target <lilyp>for the qbe ones, I think there should be a single patch given that it's one package being added; #:tests? #f still exists for no good reason afaik <lilyp>IIRC we don't run tests for non-native builds, which are the only ones that evoke qemu <lilyp>also, small style but given that you have ,#~ in there, you might want to adopt the list of gexps pattern <unmatched-paren>i'll make the changes, rebase them into the correct arrangement, and send v3 <lilyp>also be careful with the marketing in synopsis/description as well as backend compiler vs. compiler backend (I'd stick to the latter) <lilyp>I think we should not focus on this aspect, but rather on the aspect that it is a compiler backend which takes SSA as input <lilyp>people outside of compiler construction typically don't consume those and thus might think the comparison with GCC to be off <lilyp>given that it needs a frontend like cproc, whereas gcc "just works"™ <lilyp>as with qemu, I do think those code paths are actually dead <unmatched-paren>but the TARGET variable i add actually propagates into it, i'll change it to GUIXTARGET <lilyp>hmm, i'm not sure if you actually need that patch or substitute* with `uname` and `uname -m` as patterns would work as well <lilyp>but it's easily substituted, see the other patch referenced <lilyp>as for the Makefile I mean (substitute* "Makefile" (("\\`uname\\`") [replacement code]) ...) <lilyp>for the tests, I'd actually just match cc=\"cc and replace it with cc=\" #$(cc-for-target) <lilyp>even though it's overkill and will just return gcc <unmatched-paren>i thought you meant "(not sure if you need that patch or substitute) as patterns would work as well" <unmatched-paren>actually wouldn't $CC be simpler than calling #$(cc-for-target) twice since CC is already defined for the makefile (which invokes test.sh)? <lilyp>ah yes, that was no logical or <lilyp>I don't think CC is set as an environment variable <lilyp>if that works, then even better <unmatched-paren>lilyp: well, "CC is already defined for the makefile (which invokes test.sh)" <unmatched-paren>seems like the TARGET variable was propagated to test.sh before i replaced it with GUIXTARGET to avoid that, so... <unmatched-paren>do i need to gexp (modify-phases) in the (list) if it doesn't ever use ungexp? <lilyp>well, you could quote it, but gexp is better <lilyp>also don't forget that you'd need to ungexp cc-for-target for example <jpoiret>rather, quoted style shouldn't be used for new code <lilyp>btw. for the description: "QBE is a small compiler backend using an SSA-based intermediate language as input." <unmatched-paren>lilyp: ok, they've appeared! any last issues with them? or should they be ok for merging now? <the_tubular>Like if I use guix deploy, to set a password on a user <bjc>i gotta say, having "bournish" in the boot repl is a really nice touch <nckx>brettgilio: Just about to turn in, TBH :) Feeling… pretty good about the world. Managed to help some people. Took the boat out for the first spin of the year. Met some friends I hadn't seen since covid. Tired, but happy. <nckx>And glad to see you around. <nckx>bjc: All that's missing is a statically compiled readline to make it really usable (somebody mentioned that here today… hm… maybe we can trick them into working on it?). <bjc>nckx: i think i mentioned it earlier ;) <nckx>nobody is trying to trick you *nckx jingles shiny keys as a distraction. <bjc>i think my next project is trying to get some early-boot scripting in <bjc>this rabbit hole just keeps going <jpoiret>bjc: I'd be up for some early boot refactoring <bjc>my current thinking is that it'll need some kind of user-level scripting. once again, my immediate need is zfs. so i need to get the zfs binaries into the initrd and then execute the pool import and root fs mount <nckx>(‘more modular’ is a good one.) <nckx>Just imagine the power of a tiny Guix System in the initrd. <bjc>i think adding another slot to (operating-system), like (initrd-boot-procedure)? <bjc>it already has a tiny guix system! it's just a wee bit *too* tiny ;) <jpoiret>hmmm, i'd be more in favor of a (services ...) like interface <bjc>i'll have to read up on them and how they work, but that makes sense to me from here <nckx>bjc: Well, I meant a proper shepherd (like <cocomeat4[m]>new to guix, how can I use guix as a source-based distro (instead of using bins, building everything from source) ? *nckx puts on flame-retardant pants <bjc>oh. i think shepherd in initrd might be a bridge too far~ <bjc>you know.. maybe we could actually just have the *real* shepherd in the initrd <jpoiret>what i'd love is to unify the pre-pivot-root and post-pivot-root file system mounting, so that we can restore proper dependencies in shepherd <nckx>cocomeat4[m]: You disable substitutes. I won't get into the details but it's totally doable, supported, and mostly documented. <bjc>as in, it'd start from initrd, do the filesystem shuffle, and keep going for the rest of the system services <jpoiret>i hate sorting boot fses and mapped devices <bjc>not to mention that the existing mechanisms don't work for some of us *cough* *nckx adds ‘the Royals didn't totally arse a game for once’ to the list of Good Day things and ends it here. Good night brettgilio, bjc, jpoiret, all. <jpoiret>bjc: it'd be kinda hard to have the full shepherd in there, since anytime you make a change you'd have to rebuild the whole initrd <bjc>rebuilding the initrd isn't too expensive, i don't think, but i hear you <jpoiret>eh, in terms of disk space it can be <bjc>i'm not a big fan of having shepherd be one giant ball of config, and this is more fallout from it <brettgilio>nckx I live in KC and I can hear them from my house when they play at home <jpoiret>but maybe we could simply let shepherd load the rest of its config after pivoting <jpoiret>that way, it won't live in the initrd <bjc>special case an early-boot service that gets copied over, and nothing else? <jpoiret>you'd have to handle shepherd hand-off in that case, and you lose the benefits of having a unified approach to eg. mounting fses <jpoiret>currently, each fs in operating-system gets its own little shepherd service to mount it... except the ones needed to get to the store and root, since they get mounted in early boot manually <bjc>from what i can see, shepherd doesn't handle the store and root at all <jpoiret>that means that shepherd services can depend on some fses being mounted, but there's that special case to remember that some fses actually don't exist as shepherd services <bjc>you can still declare file systems services and just have some of them be dependencies of early-boot, right? that'd get their services copied over <bjc>so it'd look and feel like having a unified structure <jpoiret>if we could just handle the whole boot sequence via shepherd, it'd be ideal and benefit from its improvements with fibers <bjc>outside of file systems, is there anything that would need to be special-cased? <bjc>well, file systems and any drivers necessary to access their hardware <bjc>we already have a required-for-boot? flag on file system declarations which could be retro-fit, potentially <jpoiret>what do you mean by special-cased? if we do get shepherd in early userspace, then there shouldn't be a need to special-case this <bjc>the issue is being able to access the files shepherd needs to get the system running without having root mounted yet <bjc>so some stuff is going to have to be copied to the initrd <jpoiret>hmmm, i'd say it's the opposite, we could simply have a service in shepherd called 'userspace that simply does (load "/run/current-system/userspace-shepherd.scm") <jpoiret>and that file contains the remainder of the services <bjc>that seems like the flip-side of having an explicit early-boot service to me <kete>hi, I'm trying to run an x84_64 bit tor browser on an x84_64 bit guix gnu/linux, but I am getting this error, "tor browser wrong architecture 32-bit vs. 64-bit". haven't done much besides installed guix system. <jpoiret>kete: where did you get that tor browser from? <kete>jpoiret: tor project website. I verified the signature <jpoiret>it's highly unlikely that binaries that you download will work on guix <jpoiret>either guix already packages it, or you'll need to patch them properly <jpoiret>you'd need to know basics of the ELF format and dynamic linking <kete>I might need to roll up my sleeves then because I didn't see a package. I don't know those, so maybe I can't. <bjc>flatpak has a tor browser that you might be able to use, and guix supports flatpak <kete>bjc: I'll look into flatpak 