IRC channel logs

2022-08-22.log

back to list of logs

<isf>No, im speaking about man, the program
<isf>who search manuals for the programs you have installed normaly in the terminal
<grobx[m]>isf try info guix.es
<grobx[m]>if I run `guix pull --branch=master` then when I `guix edit something` I should see the same definition I see in the master branch of a clone of guix repo right?
<podiki[m]>believe so, but shouldn't need the --branch (unless I guess you are using another one in your channels specification)
<podiki[m]>also note that "edit" will open readonly files in /gnu/store unless you are doing this from a local git clone with pre-inst-env (see manual)
<podiki[m]> https://guix.gnu.org/en/manual/devel/en/html_node/Building-from-Git.html
<grobx[m]>yeah it should be the version-1.3.0 by default I suppose
<podiki[m]>?
<grobx[m]>I would like to try a patch that is only in master
<podiki[m]>no, guix pull pulls from master latest commit by default
<podiki[m]>only if you specifiy a different branch in your channels would it be different
<podiki[m]>there is no versioning in guix, it is rolling once you install and do guix pull
<grobx[m]>ah, ok, I tought it was 1.3.0 for some reason
<grobx[m]>so I'm struggling to understand why I dont see the latest emacs-haskell-mode patch
<podiki[m]>did you install it? and/or upgrade?
<podiki[m]>guix pull just gets new package definitions, it doesn't update/upgrade anything
<grobx[m]>yeah I'm trying to install, but it fails, and when I guix edit it's not the expected version (ie https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1147e0bee372e509873ce0b06d1863770c0951cb)
<podiki[m]>if you didn't see it already: https://guix.gnu.org/en/manual/devel/en/html_node/Getting-Started.html
<podiki[m]>you are on a guix system?
<grobx[m]>no a foreign distro
<jab>nckx: Would you say that guix is one of the most translated/multi-lingual free software projects?
<podiki[m]>you installed guix, did guix pull, and then installed the package you want? or installed before and did a guix upgrade?
<grobx[m]>well nevermind, I solved, I hadnt sourced the .profile :)
<podiki[m]>ah, was my next question
<grobx[m]>thanks podiki
<podiki[m]>happy to almost help!
<grobx[m]>it helped
<isf>whats the difference between standar and last version of GNU Guix distro?
<rekado_>isf: the latest release is pretty old, but it is known to work. You can easily update from the last release to the current version with “guix pull” and then “guix system reconfigure”
<isf>"GNU Guix can be installed as an additional package manager on top of an installed Linux-based system."
<isf>But, Linux isnt a system
<isf>Must be of an installed GNU/Linux based system, maybe that is more properly
<nckx>jab: Maybe for its size/age/userbase/funding level, sure :)
<nckx>isf: ‘-based’.
<isf>anyway, the point is Linux isnt a system
<nckx>The text is correct as is.
<isf>Why?
<isf>Is completly wrong
<isf>Linux isnt a system of you based a operating system
<podiki[m]>?
<isf>The whole operating system,
<isf>is where you can install GNU Guix
<nckx>I don't think that needs to be a GNU/Linux system though.
<nckx>Hence ‘Linux-based’.
<isf>But Linux is a kernel
<isf>not a operating system
<nckx>Correct.
<isf>So, must be GNU/Linux
<isf>becouse you cant install GNU Guix package manager in any Linux
<nckx>No?
<isf>Ofcourse not
<nckx>Thanks for letting us know.
<isf>Only if you have a operating system with linux added
<isf>Sorry?
<nckx>I don't think that's true: you can install Guix on Alpine Linux for example.
<isf>Alpine
<isf>Is BusyBox operating system
<isf>with linux added
<isf>where is your answer?
<nckx>Sorry, to?
<isf>Show me a linux where you can install Guix without a operating system
<isf>hahaha
<isf>rofl
<nckx>I don't follow, sorry. :-/
<isf>well, ofcourse
<isf>good bye
<podiki[m]>....wut
<nckx>Guix should run on all mainstream Linux-based operating systems, although there are probably exceptions.
<Cairn>Hey nckx! Yep, I got the message =)
<Cairn>Crazy that it took two hours
<nckx>2h 11m to be precise. I have no idea why.
<Cairn>Just the other day my staff sent me an Internet at 10 o'clock in the morning on Friday... I got it yesterday! Why? Tubes! The internet is tangled up tubes!
<Kolev>singpolyma: Are other users having issues with Dismail's XMPP service?
<podiki[m]>Cairn: i didn't even know about hydroxide, this is great!
<Cairn>podiki: Yeah! The proton bridge is mostly putting it out of business, since I think it even has a headless version now
<Cairn>But Hydroxide's light weight and developed by a really nice person.
<Cairn>I can (just barely, apparently) use git-send-email with it.
<podiki[m]>very nice, would love to have my protonmail in emacs and have put off setting up the protonmail bridge on my home server
<nckx>Cairn: They accidentally sent me 2 Internets, so you can have one of mine.
<Cairn>Ok, so I individually send each patch now? Or can I git send-email a batch of patches?
<nckx>You can ‘git send-email --to=<NNNN>@debbugs.gnu.org -<N>’ a series.
<singpolyma>Kolev: I just got one other report of such. Could check their status page
<nckx>As long as you --to the bug number, everything will end up in the right place. It's only when you forget (or misconfigure) that, that things become messy and we have to get the merging stick.
<Cairn>Hm.
<Cairn>Alright, I'll try my best
<nckx>I believe in you.
<Kolev>singpolyma: im Csh2
<nckx>Night all.
<nckx>Don't let the trolls bite.
<singpolyma>Kolev: oh, ha. Then I've only seen report from you so far ;)
<Kolev>:p
<singpolyma>They do have a status page / uptime page though. It's automated so usually accurate
<Kolev>I like Guix but it lacks systemd features I want, like homed.
<Kolev>I'm such a Red Hat shill. I'm doomed.
<Kolev>It says some stuff is wrong with xmpp servers
<Cairn>Well I sent all 7 hydroxide patches by messenger pigeon. As long as there's not a storm, the guix mailing list should get them in about two weeks.
<Cairn>WAIT! These ones went through instantly! What gives!?
<podiki[m]>yup, see them all on issues front end
<podiki[m]>I think once you are past initial moderation should be immediate
<Cairn>Haha. Well what a relief.
<singpolyma>Kolev: ok. I don't know what timezone the admin there is on, but I'm sure they'll see it soon
<Cairn>I did it! I contributed to Guix!
<Cairn>:D
<singpolyma>Cairn: 🙏
*nckx logs back in to remember:
<Kolev>Can I run Guix in a container?
<nckx>apteryx: Status update: there is no status update, rsync is still running fine.
<nckx>Kolev: We welcome all Linux-based shills, welcome.
<nckx>Kolev: Many interpretations of that question, but Guix does provide containment facilities yes, and should run in one if you give it the privs it craves.
<Kolev>Docker or Podman?
<nckx>podiki[m]: It wasn't a moderation issue at all, and I approved the message the minute it arrived. Here is the official diagnosis: 🤷
<nckx>Cairn: Congrats!
<Kolev>I'm enamored with both Guix and Silverblue, ironically.
<podiki[m]>ah
<podiki[m]>mysteries of the tubes
<nckx>Cairn: Now you wait the traditional 2 months for our special accelerated review for first-time contributors.
<Cairn>Hehe, I can't wait
<podiki[m]>no, you will wait :-P
<Cairn>Oh you're right
<nckx>Second, hopefully more final, because I'm knackered, good night all.
<Cairn>I can't wait to wait
<Cairn>👋
<podiki[m]>night nckx
<podiki[m]>Cairn: how have you used hydroxide so far? just for git-send-mail?
<singpolyma>2 months? Must have sped up ;)
<Cairn>podiki: Sending the hydroxide patch set was the first time I used it
<Cairn>But now that I've packaged it, I can send way more patches 😎
<Cairn>I'm not a local email client person yet, but I agree; I'll probably end up using it with Guix
<Cairn>s/Guix/Emacs/
<Cairn>Oops
<podiki[m]>I see it notes that imap support is WIP...will have to investigate
<Cairn>emersion has thought about removing it, since apparently it's a hassle to maintain. But especially since the recent merges of go-imap extensions (which I've made sure update in my patchset), it should have all the capabilities you expect
<Cairn>So if it works now, it'll surely keep working, even if someone needs to fork it eventually
<podiki[m]>yes, was just reading, thanks
<podiki[m]>I think for the official protonmail bridge it is just a ton of dependencies to be packaged, but in theory is also possible
<Cairn>Maybe my next challenge 😎
<Cairn>I enjoyed packaging go dependencies, so maybe I'll get more practice in it.
<dcunit3d>what kind of license should be added to package metadata when there is no license on a project?
<dcunit3d>this is for a personal channel btw
<singpolyma>#f
<dcunit3d>thanks. also, if i run guix-switch-to-repl and guix-devel-mode is on, when i try to use "C-c . b" to build the package, I get "Geiser REPL not found". is there any way to manually associate the buffer to the REPL?
<anhj>good morning!
<unmatched-paren>Cairn: Since you've said your patchset depends on the aerc patchset, be prepared to wait a long time ;)
<unmatched-paren>Because not many people have the --insanity-- courage to review 41 Go patche.
<unmatched-paren>patches
<unmatched-paren>Cairn: Also, you probably should use the latest tagged version of hydroxide, not the latest commit.
<unmatched-paren> https://do-not-ship.it
<phf-1>Hello Guix! Can somone help me with this? `name' and `version' evaluate to `#f' but not `inputs', why? How to get these values in this context? Thank you. Context:  https://paste.debian.net/1251279/
<unmatched-paren>phf-1: you need to use #$name
<unmatched-paren>because inputs is bound inside the gexp
<unmatched-paren>whereas name/version are bound outside it.
<phf-1>ok, great. thank you.
<unmatched-paren>and you can remove name and version from that lambda
<phf-1>Yes, of course.
<unmatched-paren>there's no name or version keyword for (arguments ...) :)
<phf-1>Haaaa... that's why!
<unmatched-paren>sneek: later tell Cairn: if you need to send a v2, use the -v flag for format-patch: git format-patch -${N} -o outgoing -a --cover-letter -v2
<sneek>Will do.
<unmatched-paren>sneek: later tell Cairn: also, https://logs.guix.gnu.org/guix/2022-08-22.log#074122
<sneek>Okay.
<unmatched-paren>sneek: good bot :)
<unmatched-paren>sneek: botsnack for you
<sneek>:)
<phf-1>And it's in the sources indeed: `guix/build/gnu-build-system.scm': « The trick is to #:allow-other-keys everywhere, so that each procedure in PHASES can pick the keyword arguments it's interested in. »
<unmatched-paren>If this revision number goes into double-digits I will not be happy. https://issues.guix.gnu.org/55903#375
<jpoiret>podiki[m], Cairn: I had some preliminary work for the protonmail bridge
<jpoiret>I managed to package the qt binding library that was used, but didn't go further, too many imported dependencies didn't build without modifications
<unmatched-paren>jpoiret: Isn't the official bridge Electron-based...?
<jpoiret>no, at least it still depends on the qt binding library from what i can see
<jpoiret>maybe it uses the webview internally
<unwox>unmatched-paren: guix's got the most thorough patch review process i've ever seen. i considered contributing my aerc recipes to guix but seeing amount of work you have to put into your patches is just shocking
<unmatched-paren>unwox: Eh, it's usually not too hard. It's just nobody wants to review Go or Rust packages, so they get left around.
<unmatched-paren>Also, thorough patch review is good :)
<unwox>yeah i agree it's great to know all packages that go into guix are of high quality
<unmatched-paren>(Maxime, who was reviewing my aerc patches before, decided that they didn't have the energy to review Go patches anymore because there's so many different forks of packages.)
<unmatched-paren>e.g. i've seen at least 3 different go-shlex packages
<unwox>i'll try contributing something simple when i get some spare time for it
<jpoiret>Thanks to maxime's work Rust might become easier to review :)
<jpoiret>Go on the other hand 🙄
<jpoiret>someone could very well code up some antioxidant-like build system for go, since the internal compiler and linker are available as well. It'll be a major pain though
<unmatched-paren>yes, true
<jpoiret>to be honest that's where packaging protonbridge led me
<unmatched-paren>`go tool compile` and `go tool link`
<jpoiret>it was either rewriting a build system or just letting it go
<unmatched-paren>pun intended?
<jpoiret>oh, didn't even notice it
<unmatched-paren>:)
<jpoiret>I've been thinking. With the PEP that allows different build systems for python packages, is it possible that some of them will have self-fetching capabilities like rust or go?
<jpoiret>that would be annoying as well
<unmatched-paren>So we might need snake-charmer-build-system along with gopher-repellent-build-system and antioxidant-build-system :(
<jpoiret>I can already see "The Build System That Lets You Stop Worrying About Dependencies™. Totally Good Idea" being used by python developers
<unmatched-paren>Oh, don't forget about mocha-coffee-build-system. :)
<jpoiret>although pip does a good job with that
*unmatched-paren away
***Dynom_ is now known as Guest9655
<tschilptschilp23>Hi guix!
***Dynom_ is now known as Guest5828
<antipode>nckx: I've found the dejagnu issue (well, upstream people found the issue ...): https://issues.guix.gnu.org/57316#1 (core-updates)
<sneek>Welcome back antipode, you have 2 messages!
<sneek>antipode, nckx says: Restarted both.
<sneek>antipode, nckx says: I tried building dejagnu on berlin a few times and it failed, even with -{M,c}1. When I ran it in a loop with those options it eventually succeeded.
<florhizome[m]>Telegram Desktop fails to build
<florhizome[m]>Hey guix 👋
<florhizome[m]>I specified --max-jobs=5 as an extra Option to the guix Dämon, but the build Output still says it uses "make -j 8" . Shouldnt that be a 5 then?
***Dynom_ is now known as Guest4710
<nckx>No, that's --cores.
<nckx>Jobs are Guix builds.
<nckx>Now, whilst care is taken to convince even nonstandard build systems to use -j <cores>, there are surely oversights where you might see different number. Some packages deliberately build with -j 1 to avoid known bugs.
<nckx>antipode: On the go, but thanks! (...for reporting their work 🙂)
<imtheonewhodudes>Dear guixers, I've been banging my head over this for too long so here I am.
<imtheonewhodudes>Do you see anything wrong in this origin definition? https://github.com/fishinthecalculator/mobilizon-reshare-guix/blob/main/modules/mobilizon-reshare/dependencies.scm#L257
<imtheonewhodudes>I'm able to build the package from the root of the channel with guix build -L ./modules python-aerich
<imtheonewhodudes>But when I try and copy that into gnu/packages/databases.scm and build it with the usual ./pre-inst-env guix build -K python-aerich I always get the following error
<imtheonewhodudes>Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f))'.
<imtheonewhodudes>and the supposedly unbound variable is tar
<imtheonewhodudes>is this a bug? or am I doing something wrong without noticing? Of course I tried this on the same Guix commit
***Dynom_ is now known as Guest9712
<rekado>imtheonewhodudes: IIUC the snippet field is not thunked, so the references to other packages are not delayed.
<imtheonewhodudes>@rekado: thanks a lot, but then does this mean the fact that it works in a channel is a bug?
<rekado>could be due to a module cycle, which becomes a problem because the snippet is not delayed.
<rekado>I’d just move this to a build phase
<Cairn>Hey unmatched-paren! I explain in my cover letter that it's necessary to use the latest commit of Hydroxide in order to access the PR I sent. It means I don't need to package depreciated dependencies which should probably be kept out of Guix.
<sneek>Welcome back Cairn, you have 2 messages!
<sneek>Cairn, unmatched-paren says: if you need to send a v2, use the -v flag for format-patch: git format-patch -${N} -o outgoing -a --cover-letter -v2
<sneek>Cairn, unmatched-paren says: also, https://logs.guix.gnu.org/guix/2022-08-22.log#074122
<Cairn>I know sneek, you silly bot, that's what I'm responding to!
<Cairn>unmatched-paren: I fully expect to send a v2 though, and I appreciate the advice on that. Mainly because someone (maybe me) will probably have to set up a cookie jar in Hydroxide in order to fix some authentication issues certain users face. That feature will probably bump the patch number and should be stable for a while. So it's not so bad to wait a while for aerc.
<Cairn>Oh, excuse me, I see now that you sent sneek to me directly unmatched-paren. I'm using a matrix bridge, so my account should always be online, and mentioning me gives me a convenient red notification which I can jump to.
<Cairn>unmatched-paren: I checked out your "don't ship work in progress" page. And that makes sense. I'll try to stick to versions more closely in the future. I suppose I could have waited until the version number was bumped, but I have a working patchset that I thought I should get on the mailing list for improvement over time. And the previous version number has some obvious flaws which makes it unshippable; something I can't fix, since I'm not even really
<Cairn>a software developer 😅
<Cairn>I did what I can this time around, I'll send a v2 once someone's closer to reviewing aerc. Sorry for the hundred pings!
<imtheonewhodudes>rekado: thanks again, I moved this to a snippet since I'd like to remove poetry's big closure from aerich's one since it serves no purpose at runtime and the python-build-system has that famous bug of merging inputs
<imtheonewhodudes>I read on one of the many mailing lists that there's a new python-build-system in the works that should be able to correctly interpret pyprojects.toml . Is there an open issue that I can help testing? I think python packages closure are becoming ridicolously big
<linj>hi guix, what is the guarantee of binary cache, i.e. if I pull the master of guix, is it guaranteed that I will have all binary caches?
<Cairn>linj: Do you mean up to date substitutes?
<imtheonewhodudes>linj: not really but you can configure your channels.scm to at least pull a mostly built package graph. see https://guix.gnu.org/en/manual/devel/en/guix.html#Channels-with-Substitutes
<linj>Cairn: up to date? I mean nixpkgs's nixos-unstable branch guarantees all binary cache are available for it
<Cairn>Ah, I see. Yeah, you'll just have to check the build system's progress on certain things: https://ci.guix.gnu.org/
<Cairn>Running a `guix pull` updates your /system/, which makes sure the packages you're trying to access are all the most up-to-date definitions. But that's unrelated to fetching substitutes.
<Cairn>Substitutes, being the Guix word for the binary cache in Nix, I think.
<Cairn>You can check out the `guix weather` command to make packages have binaries availabe as well =)
<linj>imtheonewhodudes: thanks for the pointer. I am a bit confused by "Note that this does not mean that all the packages that you will install after running guix pull will have available substitutes". What is the reason for that?
<Cairn> * You can check out the `guix weather` command to make sure packages have binaries available as well =)
<efraim>rekado: I made the mistake of going down the rabbit hole of haskell and I think I might have a working ghc for aarch64.
<efraim>Also what was the purpose of hugs again?
<Cairn>linj: It means they might not be built yet.
<linj>ah, I see
<imtheonewhodudes>linj: because some packages may contain errors, may be broken by and updated dependency hence they'll never be buildable or the build farm may just be under jheavy load
<Cairn>Oh that's fair
<rekado>efraim: what do you mean by “purpose”? hugs merely exists.
<linj>So if I want to avoid building package locally and use new packages when updating my system, is it feasible?
<rekado>I just intended to use it for the bootstrap because we can build it without a haskell compiler
<Cairn>linj: Yeah!
<efraim>but it needs more massaging for that?
<nckx>linj: Because c-w-s-a is not about packages, it's about the (relatively expensive) guix pull operation itself. It basically recompiles Guix. This, itself, is subsititable. But it has nothing to do with waiting until any packages are built.
<rekado>efraim: yes, it’s not usuable for the bootstrap as is
<nckx>*substitutable.
<rekado>efraim: hugs supports haskell98 with extensions, which is more than any of the other old haskell compilers we could have, but it’s not enough to interpret even the oldest GHC release.
<Cairn>linj: I just run `guix weather` to check that certain packages aren't gonna be rebuilt (like a browser).
<efraim>rekado: i see
<Cairn>nckx: What's c-w-s-a?
<imtheonewhodudes>channel-with-substitutes-available
<Cairn>Aha, thanks
<linj>Cairn: doesn't look good enough theoretically, but I think it works well in practice?
<imtheonewhodudes>linj: i didn't know about what nckx said, i thought it worked for all packages since i never recompiled chromium after using that
<efraim>So then I assume gofer wouldn't help either
<Cairn>linj: Sorry, what do you mean?
<rekado>efraim: recently I tried to just build GHC 4 from the included generated C code, but that didn’t work either.
<imtheonewhodudes>IME it does work. the only package i rebuild every time is telegram-desktop
<linj>imtheonewhodudes: why do you need to build telegram
<imtheonewhodudes>not really sure, it could be not substitutable or too expensive for the build farm limits
<linj>telegram definitely needs less time than chromium
<nckx>imtheonewhodudes: Unless the code has changed (and dramatically so), that's coincidence, but the two are of course correlated and the build farm is *beefy*
<nckx>🐮
<nckx>There are no build farm expense limits.
<imtheonewhodudes>not even on time? I know telegram is not that expensive but I actually rebuild it once a week. not really sure why
<Cairn>Might just be unlucky. Looks like a substitute isn't availabe for it yet today
<nckx>There are timeouts meant to kill stuck builds. But that's not why it fails.
<nckx>Something called nimf failed...
<nckx>Sorry: librime.
<nckx>Uh oh: http://ci.guix.gnu.org/build/1201472/log/raw
<imtheonewhodudes>OMG i cannot imagine how big the store in ci.guix.gnu.org must be :O
<nckx>I fixed that node. I'll restart the build when I can log in (on laptop).
<nckx>imtheonewhodudes: We have 100T of storage, it's almost empty... For now 😉
<imtheonewhodudes>is it?? are the retention policies readable somewhere? how do you decide when to stop serving a given guix commit's package graph
<nckx>Not.
<linj>emm, committer can log into build farm? that sounds a bit unsafe
<nckx>Uh. How else can you administer machines?
<Cairn>linj: How do you think other distros handle it? nckx is one of the primary maintainers...
<linj>if only a few core members can login, that's fine
*nckx away but will do the laptop thing soon.
<nckx>linj: Yes, sorry, did not read what you meant as 'all committers'. Certainly not.
<Cairn>I sometimes log into the build farm just to play nethack really fast
<Cairn>So glad you leave the build farm password in the motd <3
<Cairn>linj: Sorry, not making fun of what you said, I just think the situation sounds funny =)
<linj>Is there any interest to make sure all packages are substitutable? nix use a branch called nixos-unstable for it
<linj>That will improve user experiences
<Cairn>Oh that's interesting
<linj>nixos-unstable branch is updated after the build farm finishes the building
<Cairn>To be fair, it's not so bad as it is. I've barely rebuilt anything major on my own. I only once started rebuilding a browser, but I just cancelled the build and waited until the build farm was done with it.
<Cairn>That's a cool idea though!
<Cairn>Huh, that really is a cool idea...
<nckx>Cairn: Remember, we all share the same password, so if you change it don't make it too difficult.
<Cairn>Hehe
<nckx>linj: The idea of a ‘gated’ branch that only updates when a jobset has been built has been floating around $forever (most of us used Nix, too :). It's not an insurmountable task, but it would require integration between a few separate parts (Cuirass, Guix, Savannah) which isn't trivial. Probably why nobody's done it yet, but don't let anyone discourage you.
<nckx>It's not hard either, just a project.
<nckx>imtheonewhodudes: So to clarify my very short answer earlier: we don't (currently) decide when to stop serving anything, because everything is kept forever.
<nckx>However, we don't have substitutes going back to the dawn of Guix, far from it, but we hope to keep everything we do have going forward.
<nckx>‘Hope’ is the right word to use when you don't pay for back-ups.
<imtheonewhodudes>lmao
<imtheonewhodudes>wow I didn't think it was feasible. if you did some estimates, how long do you think 100T will last? or if you prefer how big is a whole package graph for x86 today?
<imtheonewhodudes>(x86_64)
<imtheonewhodudes>mm now that i think of it, the question is malposed sorry. I was assuming that each commit implies a world rebuild but it obviously does not. A world rebuild can happen at worst when core-updates is merged right? so once every six months or so
<linj>nckx: thanks for the info. I am afraid that task is out of my reach now. I have not used guix. But will try it in the future.
<imtheonewhodudes>linj: what were you thinking of using guix for? in my experience lately local builds are rare if you use guix as a developer tool, say as a virtualenv substitute
<imtheonewhodudes>some rebuilds are to be expected if you use a lot of big desktop applications
<tschilptschilp23>Does anyone know how to automatically load paredit when starting the geiser- or slime-REPLs? I've taken the autoload- and add-hook configurations from https://www.emacswiki.org/emacs/ParEdit and paredit becomes active in ielm and .{lisp,el,scm} file-buffers automatically. However, in geiser and slime I have to 'M-x paredit-mode' to activate it. Is there any customizable variable I'm missing?
<nckx>imtheonewhodudes: We're terrible at keeping records of things like that, but, with sources, I'd say it's currently between 100 and 200G for a full word rebuild? Assuming you've encountered the term ‘core-updates’ before: full world rebuilds are rare.
<nckx>Plus, btrfs compression, plus, guix-daemon file-level deduplication.
<linj>imtheonewhodudes: I plan to use guix on vps, development environment and maybe use it as a distro on my physical machines. wrt binary cache, I just hear from a firend that he has to build konsole after upgrading
<imtheonewhodudes>nice nice
<Cairn>tschilptschilp23: You added paredit-mode to slime-repl-mode-hook?
<linj>btw, what is my nickname you see on irc?
<Cairn>linj
<imtheonewhodudes>nckx: Do you happen to use guix deploy for ci.gnu.guix.org or is it something like k8s?
<linj>cool
<tschilptschilp23>Cairn: thanks -- just by now, i scrolled down after posting, sorry!
<Cairn>linj: You can check the channel logs if you need to see anything from beyond the matrix POV: https://logs.guix.gnu.org/guix/2022-08-22.log
<nckx>Oh, that estimate was per architecture. And a lot of trash is built, like testing WIP branches that will never be downloaded by anyone not working on the branch. So it would be nice if Cuirass supported per-branch retention policies one day, even if the one for master etc. would remain infinite. Still, if we manage to fill 100T within two decades, I think we might be doing something wrong.
<nckx>imtheonewhodudes: guix deploy :)
<imtheonewhodudes>linj: yeah i see linj on hexchat. i would say in my experience of the three use cases you mentioned the only risks you can run into are rebuilds for desktop application.
<imtheonewhodudes>nckx: that's awesome. I used to work in a big public compute service provider in Italy, they used ansible for everything and I run frequently in supposedly stateless notebook that weren't actually quite so
<Cairn>Could also wait to rebuild until a certain check passes with `guix weather`. So you could provide a manifest of all your packages, then only update when they're available.
<nckx>Seeing (qt)webkit(gtk) or a Modern Browser start to build locally is usually a ^C moment, but if you have a 🐮 PC it's possible to build even those at home.
<cassio>Hi everybody!
<imtheonewhodudes>nckx: Anyway I hope we can discuss this in person at guix 10th year event if you'll be there
<Cairn>cassio: 👋
<imtheonewhodudes>i wuold love some production ready examples of how to handle a lot of machines with guix deploy
<nckx>imtheonewhodudes: It's rudimentary but it works, and you can't remotely compare the two in popularity or funding so that's no mean feat.
<nckx>imtheonewhodudes: I'd love to have been there, but alas :(
<nckx>I should make FOSDEM in Feb, assuming it happens.
<Cairn>Is there an online component of the 10 year event?
<imtheonewhodudes>nckx: That's too bad, for me it'll be the first IRL guix event i attend so i really look forward to it
<imtheonewhodudes>Cairn: https://10years.guix.gnu.org/
<nckx>imtheonewhodudes: This is most of the build farm (‘berlin’) configuration: <https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra> — there are a *lot* of hysterical raisins in there, and it's a very heterogenous environment (head node + build nodes, done).
<nckx>Sorry for all the disclaimers, I just want to avoid disappointment, I guess.
<imtheonewhodudes>:D
<imtheonewhodudes>nckx: Wow thanks a lot!
<nckx>Hetero? *NOT* hetero. Very homo.
<Cairn>imtheonewhodudes: Can't quite tell the format of the event from that link.
<imtheonewhodudes>nckx: LMAO we need more maid catgirl Guix memes
<Cairn>At least enough to answer my question =\
<imtheonewhodudes>Cairn: I actually don't know anything :D I figured i'll just go and see
<imtheonewhodudes>there's a program here
<imtheonewhodudes> https://10years.guix.gnu.org/program/
<cassio>Could anyone help me with this:
<cassio>When I run `guix home reconfigure path/to/my/home-configuration.scm`, it overloads my CPU in such a way that I can't manage to run anything else ─ even the keyboard and mouse don't respond anymore. And this sometimes lasts for days in a row! So. How can I limit CPU access to the reconfiguration processes in such a manner that I can work on other
<cassio>things at the same time?
<Cairn>I guess I'll just be jealous of those who can attend in person imtheonewhodudes.
<Cairn>Have a good time!
<nckx>Cairn: Not really, sorry.
<imtheonewhodudes>nckx: Thanks a lot for the link! Do you think it would be valuable to have something like an awesome list of guix channels and configurations? Or maybe in the cookbook
<nckx>There are some third-party ones.
<imtheonewhodudes>oh nice, I didn't know
<nckx>I do think it's valuable, but I think it's something that's fine (even good) to leave up to the community, not ‘officially’ by the project.
<florhizome[m]><nckx> "Now, whilst care is taken to..." <- yeah this as a danke build system build. hm so I should take 3 cores I guess. During builds my UI tends to freeze. Or is that a memory issue?
<nckx>I really can't say. It could be. If you see significant amounts of memory pressure (PSI, I think htop gives a nice graph of that if you configure it), it likely is.
<nckx>If you're not running -j64 on a 4-core CPU, but sticking to ~1 job per core, actual *freezing* merely due to CPU activity is extremely unlikely.
<nckx>*make job, to avoid further confusion.
<cassio>nckx: how can I do that? is there a tutorial or a manual somewhere so that I can limit to 1 job per core?
<nckx>There's no way to tell Guix to run exactly 1 job on each core whenever possible (i.e., avoid idle cores at all costs), because that would be very complex across build systems. But you can use --max-jobs=1 --cores=$(nproc) to build only one package at a time, and ask its build system to only spawn as many concurrent tasks as you have cores.
<nckx>CPU cores will often sit idle but you asked for a limit, so…
<nckx>(E.g., when running ./configure, or ‘make install’, or simply if the package disabled parallel builds for some reason.)
<podiki[m]>isn't --max-jobs=1 and --cores=$(nproc) the daemon default?
<nckx>Poss. You know me & defaults.
<nckx>podiki[m]: If the documentation is accurate, you are correct!
<podiki[m]>personal experience (that all encompassing and ultimate source of data) concurs
<nckx>In practice, it's a fragile dance to set --max-jobs and --cores to something that will fully load your expensive CPU as much as possible without bringing the machine to its knees.
<podiki[m]>I have set max-jobs higher a few times when I knew I was building lots of smaller stuff where I thought that would be more efficient
<nckx>Yeah.
<podiki[m]>usually the bottleneck are things that take a long time to build and are using all the cores they can though
<lfam>New kernel option for 5.19, could be germane to Guix and reproducibility: https://cateee.net/lkddb/web-lkddb/INITRAMFS_PRESERVE_MTIME.html
<lfam>"
<lfam>Each entry in an initramfs cpio archive carries an mtime value. When enabled, extracted cpio items take this mtime, with directory mtime setting deferred until after creation of any child entries."
<lfam>Does anyone know about this stuff?
<lfam>If we leave this disabled, what mtime will extracted cpio items carry?
<podiki[m]>no, but thank you in advance for the kernel configs!
<nckx>podiki[m]: Or it's qtwebkit (IIRC?) and it's both a bottleneck *and* a huge build *and* with parallel-build disabled! \o/
<nckx>One of the Webkits does that.
<podiki[m]>nckx: yes, I think that one is, the death of the day for building
<podiki[m]>when you realize your computer is only mildly warm but going for some time....oh, and nss tests maybe? takes longer than the build
<podiki[m]>(which reminds me, nss is in need of a graft, I had a version update patch some time ago after someone noted that here, but didn't update with the graft)
<nckx>lfam: I thought that applied only to the extracted files, i.e. those briefly in memory. Still, it could (very) hypothetically create a more deterministic initrd, and there's probably no drawback. And we decide how the initrd behaves so can fix it if so.
<lfam>Alright, I'll turn it on (the default)
<lfam>Thanks!
<nckx>To answer your other question: I'm pretty sure it's the current (boot) time.
<nckx>But don't pin me to that, I didn't actually test it.
<nckx>podiki[m]: And then the git (less so) & ceph (extremely so) test suites are absolute murder on rotational drives, and go mostly unnoticed by SSD users.
<nckx>Guix: something for everyone.
<podiki[m]>hahah we aim to please(?)
<lfam>nckx: Well we will find out! I'm sure it won't be a disaster either way
<lfam>Guix is a great way to tell what kind of storage you have and if you created your ext4 filesystem with the default parameters ;)
<cassio>nckx said:
<cassio>>> ask its build system to only spawn as many concurrent tasks as you have cores
<cassio>I like the idea of using `make guix-home`, but I'm kind of raw ─ do you have a sample make-file that I could learn from? Including this thing about the number of cuncurrent tasks?
<nckx>Yeah, (re-)reading the patches, the unset case is simply leaving mtime to the ‘normal’ kernel process, i.e. mtime = when it was extracted, the =y case is explicitly reset it afterwards.
<nckx>Which, OK, apparently has a 25% performance overhead, so that would be an argument against.
<lfam>That's a fine argument against. Is there an argument for?
<nckx> https://lkml.kernel.org/linux-fsdevel/20211213232007.26851-3-ddiss@suse.de/
<nckx>lfam: Well, my ‘in theory timestamps could change initrd behaviour’ above, but that wasn't intended to be a convincing argument.
<nckx>No, I'd agree with disabling it, lfam.
<lfam>Okay. I figure that if "mtime = when it was extracted" causes problems, they will be noticed and we can turn this on
<lfam>I appreciate you making the effort to look into this! Had you already read the patches? You said you were re-reading them
<nckx>Note that it's the current behaviour, so we can be quite certain it's fine.
<lfam>Exactly
<nckx>Sorry if I confused you above, it was supposed to sound like me trying very hard to find a pro-argument, but that didn't carry well in text, and I hadn't thought of the con yet
<nckx>lfam: I read LKML for fun.
<nckx>Not for profit, I'm just sick.
<nckx>I'd happened to have seen this patch.
<nckx>Coincidence.
<lfam>We have shades of the same illness I think
<nckx>(Possibly) like you, I first thought it was more relevant to reproducibility than it turned out to be after inspection :)
<lfam>Oh good, there's a LiFi now
<nckx>We already create reproducible initrds with our (Ludo's) Guile cpio reimplementation.
<lfam>Networking over a light bulb
<lfam>And a photosensor
<lfam>The best thing about doing these configs is seeing what kinds of kooky hardware are being brought to market
<lfam>It's like `make ARCH=i386 oldconfig`... "Do you want to enable support for utility-scale battery charge controllers?"
<lfam>Yeah, sure
<nckx>> Networking over a light bulb
*nckx reminisces about IrDA.
<lfam>Get the 20 year old laptop out for the power plant
<lfam>I can't wait for the crystal woo people to learn about LiFi
<nckx>Never used it, but it felt mighty futuristic to tiny Toby on their then-already-ancient hand-me-down Compaq laptop with a broken screen.
<nckx><I can't wait> lol.
<lfam>I saw you mentioned FOSDEM. I wonder when they will make a decision about the event
<podiki[m]>so that mtime setting is by default set on, which has performance overhead? huh
<nckx>I wonder if they'd be intrigued or horrified if you put a crystal on a wireless phone charger pad.
<nckx>podiki[m]: Yeh.
<nckx>Well, it creates a more accurate image of the original file system, but it sure feels odd to flip the default this late in the game.
<lfam>The other thing about the kernel configs is getting options for hardware that seems tied to another arch. The x86_64 config asks about supporting the Raspberry Pi Sense HAT
<nckx>I guess something (systemd?) used the mtime for something? I dunno. But you might want to run make in the initrd, so better safe than sorry.
*podiki[m] nods like he understands everything, but is more just happy people who are in the know are in charge here
<lfam>¯\_(ツ)_/¯
<nckx>Actually, considering I recently managed to create an initrd with broken auto-compile Guile that actually did try to remake everything *during the initrd* phase, maybe those kernel folks are onto something.
<lfam>Nooooo lol
<nckx>No, I have no idea what happened, nor how I created that initrd. I swear I did nothing weird.
<lfam>That's one for the books nckx. There should be a bloopers session at the upcoming event
<nckx>:)
<nckx>Re: FOSDEM: they've always decided relatively ‘late’ (compared to other, esp. US, events), so far too early to say.
<podiki[m]>haha would love bloopers
<nckx>Decided the dates, I mean.
<nckx>Of course, ‘will it happen’ is a different matter, but then so is gov covid policy being even more unpredictable than university whims.
<lfam>I mean if they are going to host the event in Brussels rather than online
<lfam>I guess I am out of step with European norms at this point. Obviously the US authorities have given up
<nckx>Not much different here, except maybe vaxx rates (dunno).
<nckx>Currently no restrictions though.
<imtheonewhodudes>lfam: In Europe as well, the war (rightfully? don't know really) ate all media and policy-makers attention
<lfam>That makes a lot sense. Hard to imagine what it's like, as an American
<lfam>And the energy issues seem to loom
<nckx>lfam: Last year, they decided near the end of October.
<nckx>imtheonewhodudes: Yeah, that's my impression too.
<nckx>That and the macroeconomy.
*nckx → foodz.
<imtheonewhodudes>LOL this autumn there'll be laughs to have
<imtheonewhodudes>not sure if that sentence makes sense in english
<lfam>It's not idiomatic but it makes sense to me
<imtheonewhodudes>but what I mean is life has never been worse after ww2 in my opinion
<lfam>It certainly seems scary
<lfam>The depths of the postwar years are very far down, however
<imtheonewhodudes>yeah but i mean the whole of it, it's quite bad
<imtheonewhodudes>covid + war + energy issues + precariat
<imtheonewhodudes>no wonders fridays for future calls for a global strike once every 6 months
<imtheonewhodudes>are OTs tolerated in here? Or is there a more suitable channel to move these kind of discussion to? something like #guix-ot
<lfam>It's tolerated for a while. But we shouldn't go off-topic all day
<lfam>And if it becomes discordant then it should stop
<lfam>I think it was somewhat on-topic, since we were discussing meeting in Europe
<imtheonewhodudes>makes sense, sometimes I love to discuss with fellow tech workers this kind of very general policy issues since they always indirectly reflect on our FOSS work
<imtheonewhodudes>also the amount of time each one of us is able to dedicate to contribute to FOSS just for the usefulness of it is quite political imho
<lfam>I think many people would agree with you. The problem is when the channel becomes angry or unpleasant while we are discussing something besides Guix
<lfam>So, we must use our judgement
<imtheonewhodudes>definitely, i agree 100%
<lfam>Also, there are people here from all over the world. So, people may not agree on these non-Guix topics, or even care very much about them
*nckx will soon be plump.
<nckx>There is a #guix-offtopic channel, as long as off-topic doesn't become incendiary.
<imtheonewhodudes>nice, i'll join that too
<nckx>Which… certain topics can't resist becoming.
<lfam>Ah, I missed the creation of that channel. Perfect!
<imtheonewhodudes>nckx: indeed but some topics are worth disagreeing upon imho, always with respect for other position
<nckx>Absolutely, it's just hard to actually follow that ideal in practice, and it's eleventy billion times as hard on the Internet.
<lfam>New options for randomizing the layout of kernel structures: https://paste.debian.net/1251333/
<nckx>What Li-Fi actually reminded me of even before IrDA, but I couldn't remember the name until now: https://yewtu.be/watch?v=p3Pzxmq-JLM
<lfam>That was so cool. I remember the ads
<lfam>I like the example
<lfam>"take dog to vet (neuter)"
<lfam>As if you'd forget why you were taking the dog to the vet
<vagrantc>lfam: is the randomizing kernel layout applied at runtime or to the on-disk binary?
<vagrantc>as, there's an obvious reproducibility issue if it randomizes things on-disk
<lfam>vagrantc: https://cateee.net/lkddb/web-lkddb/RANDSTRUCT_FULL.html
<lfam>Not sure
<nckx>vagrantc: Binary.
<vagrantc>:(
<nckx>I think you can set the seed.
<nckx>Correction: I know you can set the seed, I just can't say where off the top of my head.
<nckx>Of course: the obvious.
<vagrantc>well, with a known seed, that kind of defeates much of the point of randomizing things
<nckx>And it's unlikely that somebody's attacking your kernel without knowing which distro you run.
<nckx>Yes, exactly.
<lfam>What's the point of randomizing the binary at all?
<lfam>I can see the point of randomizing memory layout
<nckx>OpenBSD theatre envy?
<nckx>(They relink & rewrite the kernel binary on each boot.)
<vagrantc>i swear there were options to do this sort of thing at runtime
<nckx>Sure.
<vagrantc>a perfect environment for a virtually undetectable backdoor!
<vagrantc>"yeah, it changes all the time, that makes it secure because an attacker won't know the layout of the binary!"
<lfam>Well, I'll make sure it's turned off
<nckx>The kernel's full of these options, but they all tweak a certain thing, and this one tweaks this thing, and is probably not appropriate for Guix.
<nckx>Thanks!
<vagrantc>great!
<nckx>There are plenty of *other* options to make the kernel slow^Wrandomer that are run-time, and most are enabled, don't worry.
<vagrantc>slow is a feature of guix!
<nckx>Dangles. I shoulda submitted my horked self-recompiling initrd as a security patch.
<nckx>‘Can't be hacked if you're still booting.’
<unmatched-paren>Cairn: The deprecated dependency is fine, but if the release has serious problems that's different
<unmatched-paren>but you should *always* add a comment when you do something abnormal like disable tests or use a commit instead of a tag
<Cairn>Nice, I'll keep that in mind
<unmatched-paren>(So long as the dependency doesn't have security vulnerablities or anything :))
<lunabee>any specific reason the posix manpages aren't packaged? thinking of packaging them and curious if there's eg. known licensing problems
<degauss>Hi channel! When trying to upgrade my Guix profile to 89d427e, I got a conflict between the "gnutls" in my profile and the one propagated from "guix", output here: https://paste.debian.net/1251345/
<degauss>The later wants to stay in 3.7.2, but the former wants to jump to 3.7.7 as provided by variable gnutls-latest in tls.scm, instead of the "stable" one in the gnutls variable.
<degauss>I had to "--do-not-upgrade gnutls", I wonder why it does that version jump and if there's a workaround which doesn't imply staying with the older version.
<unmatched-paren>degauss: Wait, do you have the `guix` package installed?
<degauss>Yes, I have.
<unmatched-paren>Remove it
<unmatched-paren>problem solved.
<unmatched-paren>`guix pull` is how you install the `guix` package
<unmatched-paren>the `guix` package only exists (a) so you can use it with `guix shell` (b) so Guix extensions can use it as inputs
<unmatched-paren>we're going to make guix package fail when you try to install guix soonish, promise :)
<degauss>I probably had it installed from very old times when an old "emacs-guix" was in the same profile.
<unmatched-paren>If you install `guix`, you'll have old packages and an outdated version of the CLI :)
<degauss>I'll remove it and see if anything else breaks. Thanks for the help, unmatched-paren!
<unmatched-paren>No problem!
<unmatched-paren>The problem with fixing `guix package -i guix` is that any solution would be a little inelegant
<unmatched-paren>well, either inelegant or overgeneralized
<degauss>:) Yeah, I also had to upgrade the Emacs profile first after a "guix pull" as it also has "guix" in it, I'll try removing it from there too.
<degauss>Correction: I actually removed "guix" from the Emacs profile long ago! :D
<degauss>Thanks again for the help and the extra info! :)
<unmatched-paren>We could implement something like post-install hints, but there's no other package that would use them, as far as I can see
<unmatched-paren>or we could add something like (package-thats-only-installable-through-guix-shell ...) but that has the same problem
<unmatched-paren>but (when (string=? (package-name pkg) "guix") #|display error and exit|#) is a bit iffy
<muradm>hello guix
<unmatched-paren>muradm: hello
<degauss>Umm, removing "guix" from my main profile does break "emacs-guix" (maybe because I'm on a foreign distro?): guix-geiser-eval: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception: Unbound variable: %max-returned-list-size
<unmatched-paren>degauss: Hmm. Is emacs-guix installed via guix?
<muradm>apteryx: 56608 fail2ban-service-type updated
<degauss>unmatched-paren: Yeah, on a separate profile for Emacs stuff.
<muradm>unmatched-paren: o/
<unmatched-paren>degauss: Hmm, sorry, I have no idea why :(
<apteryx>muradm: thanks for the notice
<unmatched-paren>I guess it can't find Guix's modules anymor
<unmatched-paren>anymore
<Joop>Hi, I'm getting a 502 'Bad Gateway' when trying to download cppcheck from ci.guix.gnu.org
<Joop>Is this known?
<degauss>unmatched-paren: BTW, installing "guix" in the Emacs profile (though that wouldn't be a nice solution as you mentioned) doesn't fix "emacs-guix" either. Weird.
<degauss>unmatched-paren: Umm, I should've updated shell variables first, I'll check again.
<unmatched-paren>degauss: could you do `command -v guix` please?
<degauss>unmatched-paren: Sure, in my usual setup (with "guix" in the main profile too) I get: /home/ivan/.config/guix/current/bin/guix
<nckx_>Joop: Yes, I restarted some services including nginx.
<unmatched-paren>okay, try `guix describe`
<Joop>Ah, ok
<nckx_>I'd posted a notice here but entirely coincidentally my bouncer went down and it didn't arrive.
<nckx_>Provider issue, apparently.  Anyway.  It's me.  Nobody else writes like this.
<PotentialUser-89>Hey everyone. I'm a brand new guix user trying to learn the ropes. I'm trying to put together a package definition right now. I'm using the cargo build system.  After the build phase starts, I get this error:
<PotentialUser-89>Updating git repository `https://github.com/XAMPPRocky/octocrab`
<PotentialUser-89>warning: spurious network error (2 tries remaining): failed to resolve address for github.com: Name or service not known; class=Net (12)
<PotentialUser-89>I could use some help
<degauss>unmatched-paren: "guix describe" output: https://paste.debian.net/1251352/
<unmatched-paren>nckx_: While you're here, wrapping the value of `to-install` in `options->installable` in guix/scripts/package.scm with a `map` that checks each package to see if its name is `guix` doesn't seem *too* inelegant, so why not use it? Any other solution I've thought of would be too general.
<rekado>PotentialUser-89: looks like a transient network problem.
<rekado>you can try ping github.com to see if it resolves
<unmatched-paren>degauss: hmm... that doesn't look outdated
<unmatched-paren>maybe your emacs-guix is outdated?
<degauss>unmatched-paren: All pkgs in my Emacs profile are currently up to date to the same commit.
<unmatched-paren>????
<nckx_>PotentialUser-89: There is no Internet access inside the build container, and no way to get it.  You'll have to convince Cargo not to try to fetch random things from GitHub.  I think this simply means a required package is missing from inputs (or a Cargo-specific #:something-inputs), and you need to package rust-octocrab first.
<degauss>unmatched-paren: I mean that I have Emacs and all its packages in a separate profile, with the same Guix commit as shown by "guix describe". :)
<unmatched-paren>is there a make rule in the guix repo to rebuild only the scheme files, not the docs or anything else?
<unmatched-paren>degauss: I was expressing confusion at your issue, not your message :)
<degauss>:D
*nckx_ AFK.
<PotentialUser-89>nckx_: Thanks for the reply. That means that octocrab needs to be provided as an input to my package? Which means it needs to be packaged for guix as well?
<unmatched-paren>PotentialUser-89: yep!
<unmatched-paren>however, this package seems to use git
<unmatched-paren>not crates.io
<unmatched-paren>so guix import probably won't work
<PotentialUser-89>Ok, so if i am currently troubleshooting my package definition using guix install-from-file, how do I reference as an input another package definition that I am working on as a stand alone file?
<unmatched-paren>You shouldn't use `-f` for prototyping
<unmatched-paren>instead, create a directory and cd to it, then put the file in the directory
<unmatched-paren>remove the returned package name from the bottom
<unmatched-paren>and turn the file into a module
<unmatched-paren>(define-module (my-testing-package-module) #:use-module ... #:use-module ...)
<unmatched-paren>and use -L . with guix package
<unmatched-paren>`guix package -L . -i rust-octocrab`
<unmatched-paren>or `guix install -L . rust-octocrab` of course :)
<PotentialUser-89>Ok. That makes sense. Why is that superior to `-f`?
<unmatched-paren>Because it will load all the modules in the directory
<unmatched-paren>and subdirectories
<unmatched-paren>so you can have multiple files
<PotentialUser-89>gotcha
<unmatched-paren>also, the module name must be the same as the file name minus the .scm
<unmatched-paren>and slashes become spaces:
<unmatched-paren>foo/bar/baz.scm becomes (foo bar baz)
<nckx_>Gnorf.  After restarting nginx & the cuirass gang, SSH to berlin is almost instant again (and almost certainly degrading from there).
<degauss>unmatched-paren: I redid the test with the Emacs profile: I started a shell with no Guix env vars (I have a script for that), then I loaded the profile for the Emacs profile, then the profile for current guix. Launching Guix commands in Emacs did work! :) (I may have messed some step in the previous test.)
<unmatched-paren>degauss: nice! :D
<degauss>unmatched-paren: So I should be able to remove the "guix" package from the main profile safely. Thanks again for your help and your patience! :)
<nckx_>unmatched-paren: I hadn't forgot you :)   It's just that: I want to test for guixness and not merely a name.  Consider it a personality fault.  Which ‘other solution’ occurred to you?
<PotentialUser-89>unmatched-paren: sweet. thanks for the help. I'll probably be back later with more problems
<nckx_>*solutions.
<PotentialUser-89>lol. thats what i meant
<unmatched-paren>nckx_: Two others that are far too general: something like (package-that-cant-be-installed-but-can-be-shelled ...)
<unmatched-paren>and post-install notes (notes (list (post-install-note "..." #:warning? #t #:shell-only? #t)))
<nckx_>PotentialUser-89: I'm probably ruining your joke, but just in case: I was correcting myself, not you.  Problems are always welcome.
<unmatched-paren>but I can't think of any other package that would possibly use those
<unmatched-paren>so it'd be a whole new feature just for one package
<nckx_>unmatched-paren: Oh.  OK, thanks.  No, I'm not wild about either (and TBH I was already dreading having to knock your post-install-note patch which I knew was coming, and which I don't think would be a good idea, so I'm relieved...).
<nckx_>So I'm not wild about any solution, which means we should probably go for the simplest by far :) (string=? "guix" name)
<unmatched-paren>nckx_: The reason I considered post-install notes was for guix extensions, to tell users about the GUIX_EXTENSIONS_PATH thing
<unmatched-paren>but I realized that fixing that properly was pretty simple
<nckx_>Yeah, I think it (the concept) is a crutch.  I'm not criticising you, I'm criticising the concept as implemented in every single distro I've used so far that had it.
<unmatched-paren>also, s/shell-only?/not-shell?/
<nckx_>And I don't think it's because they were idiots.
*nckx_ AFK again, sorry.
<unmatched-paren>and not-shell? would also be an ad-hoc feature even if post-install-notes were needed for other packages
<unmatched-paren>nckx_: No need to dread knocking my patches :)
<degauss>unmatched-paren: I remembered that I also had installed "guix" and "guile" for some script I had which tried to load Guix libs, but I can run it anyway with "guix shell guile guix -- guile -s SCRIPT...". :)
<unmatched-paren>Yes, you're supposed to use `guix shell` for Guix modules :) One of the reasons we can't simply hide `guix`
<unmatched-paren>Hmm, you could try this:
<unmatched-paren> https://paste.sr.ht/~unmatched-paren/f50850fc6c0a081a15c3c8c9237eaa2295c1895e
<atka>hey guix, is reconfigure broken for anyone else?
*unmatched-paren guix pull && guix system reconfigure
<atka>thanks unmatched-paren
<atka>sneek: botsnack
<sneek>:)
<degauss>unmatched-paren: Works like a charm, cool! :)
<Lumine>atka: yep, fresh install fails on the font package cantarell in the python packages, this is on VBox btw
<degauss>Enough stuffed fixed for the day, time to rest a little. :)
<unmatched-paren>atka: Works for me, but cantarell is a GNOME package, and I don't use GNOME
<atka>unmatched-paren: thanks for checking
<unmatched-paren>s/GNOME package/font used by GNOME/
<Lumine>Huh, I did use Gnome but it also failed on Xfce for me last night, I might recheck if the package was in fact the same
<unmatched-paren>Hmm, maybe Xfce uses it too.
<atka>anyway, somethings broken again
<unmatched-paren>But I know it's the official GNOME font. Maybe the issue where it wasn't used by GNOME by default was fixed recently, and that broke it.
<Lumine>Is there a way to exclude specific packages from reconfigure or is that even a good idea?
<unmatched-paren>That wouldn't work
<unmatched-paren>because reconfigure creates a whole new system, it doesn't mutate the previous one
<Lumine>Right
<atka>gotta admit its pretty frustrating when there's a package breakage you can't modify your system until its fixed
<unmatched-paren>could one of you put the log on a paste site?
<spaethnl>Hi. I'm a relatively new Guix user, but I am wondering about the naming of directories in /gnu/store. The are named [hash]-[package-name], but is there any reason that could not have been reversed to [package-name]-[hash]? Occasionally I want to inspect one of them, e.g., kdb. My intuition is to cd /gnu/store/kbd<tab>, but because the order is the way it is, that is made much more difficult.
<Lumine>unmatched-paren: I can but it will be slow since I need to make another pull and a reconfigure and it's slow as heck on my other HDD
<unmatched-paren>Okay, maybe atka could
<unmatched-paren>spaethnl: You can use `guix build` to get the store path of a package
<atka>unmatched-paren: sorry, can't atm, not on guix
<orneb>Hi! How do you partition your devices with GPT/bios-seabios? During my first installation (device encrypted with LUKS) I created the same scheme described in this link https://unix.stackexchange.com/questions/692420/does-coreboot-seabios-support-gpt-partition-table in the "Install with LUKS disk encryption" section but I was wondering if the 512M partition were necessary. According to other manuals, with a GPT/bios layout you only need
<orneb>a bios_boot partition.
<nckx>atka, Lumine: Which package originally fails, exactly? ‘In the python packages’ is vague.
<unmatched-paren>nckx: cantarell, apparently
<unmatched-paren>strange because it was last changed a while ago
<unmatched-paren>2022-06-26
<Lumine>It had two parts, ab-something and cantarell, but it was part of the python builds, I need to reconfigure so bear with me
<unmatched-paren>okay :)
<nckx>orneb: The 512MB partition is a separate unencrypted /boot, which Guix doesn't support.
<nckx>Don't be distracted by that example, look at the first. All that matters is that ‘BIOS boot’ partition.
<spaethnl>unmatched-paren: Okay, but my actual question was is there a technical reason they needed to be named that way?
<unmatched-paren>spaethnl: I don't know, sorry
<nckx>unmatched-paren: I assume cantarell is the end of a cascade of dependency failures, with python-something at the top, but who knows.
<unmatched-paren>Ah, true.
<nckx>I'm pulling, then will try.
<Lumine>My pull is taking me a year apparently
<unmatched-paren>Lumine: Do you mean you're a year behind?
<unmatched-paren>Or it's taking years to complete?
<Lumine>Joke, year to complete :)
<unmatched-paren>Right, phew :)
<nckx>spaethnl: It would make reference scanning more complex (i.e., slower) for no (or negligible, if you consider tab-completion relevant) benefit.
*nckx builds font-abattis-cantarell, and of course it spits out an already-built file name. That's why knowing the exact package name is really going to help.
<nckx>/gnu/store/3pyzv6ds8f5iw9vrgxm31gl7rppwylir-font-abattis-cantarell-0.303.drv
<nckx>Is that the same one?
<Lumine>Yep
<Lumine>That was it
<nckx>Right, so it built fine here or substituted dandily.
<Lumine>It does the 'check, build, install' thing for me
<nckx>Who does?
<Lumine>Still waiting on the pull
<nckx>If it's font-abattis-cantarell, that means all (including python-*) prerequisites built fine.
<nckx>Lumine: Okido, take your time.
<nckx>Learn to play piano. Write a book. Travel.
<Lumine>That would probably be just enough for it
<Lumine>Note to self: never install Guix on VBox, use qemu
<unmatched-paren>Lumine: VBox has freeness issues anyway iirc
<Lumine>Yup
<Lumine>I'm forced to deal with it for the time being though
<orneb>nckx: and I don't have to declare the bios_partition in my config file, it'd be like the first example in the manual https://guix.gnu.org/en/manual/en/html_node/Using-the-Configuration-System.html even with my root partition encrypted with luks? Was wondering if the Grub menu was missing due to this mistake. I had to add an option that I don't remember now to display the console version of GRUB.
<nckx>People are working to relicence the problem with VirtualBox: https://github.com/open-watcom/open-watcom-v2/discussions/271#discussioncomment-1755369
<nckx>It's impressive they've gone through this considerable effort at all.
<nckx>orneb: No, the BIOS Boot partition is not relevant to your operating system, only to the boot loader. It changes nothing about how you should partition your disc.
<nckx>Create it, but then ignore it going forward, and partition/configure as you would normally.
<nckx>A LUKS system won't look like that example, it will look like the snippet you will find if you search for mapped-devices on that same Web page.
<nckx>But yeah, minus the /boot/efi file-system.
<nckx> https://paste.debian.net/plainh/5696a4f2
<florhizome[m]>nckx actually i copied the --max-jobs line from efraims config and i just checked He actually has it like that
<nckx>You can also use (device "/dev/mapper/root"), which is actually what I do.
<nckx>florhizome[m]: And what's wrong with that?
<nckx>Or, what do you mean otherwise?
<florhizome[m]>I thought it was --max-cores now?
<orneb>nckx: Yes I should add only this: this bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sdX"))).
<nckx>florhizome[m]: No.
<nckx>There was never such an option.
<nckx>orneb: Yep. No sdX1 or so. The whole device.
<nckx>GRUB will automatically do the needful with the reserved partition.
<nckx>florhizome[m]: Here's a message I wrote earlier to someone else: https://logs.guix.gnu.org/guix/2022-08-22.log#162437
<Lumine>Ok so the first time I run the reconfigure, it fails like this, which baffles me: https://paste.opensuse.org/38452523
<florhizome[m]>oh
<florhizome[m]>but --max-jobs doesn't relate to the -j flag of make f.e
<florhizome[m]>what i want to do is spare some threads because the laptop Trends to freeze during builds
<nckx>Lumine: That looks like a very poorly-handled network error/interruption/whatever.
<nckx>florhizome[m]: No, that's --cores.
<florhizome[m]>*tends
<nckx>‘Jobs’ are Guix jobs, i.e. a package build or source download.
<nckx>--max-jobs=5 will download/build 5 packages at once, when possible.
<nckx>--cores=5 will build each package with -j5, when supported.
<florhizome[m]>ah ok so there ist a core option
<nckx>Ja.
<nckx>It's all in the link I pasted above :)
<nckx>Lumine: Anything more useful on the second run?
<Lumine>Running it now
<florhizome[m]>and it does relate to physical cores, not threads
<nckx>Lumine: OK. It shouldn't happen again, but it might, if something else randomly disconnects. Guix just doesn't handle network error intelligibly. That's TODO… :-/
<nckx>florhizome[m]: It relates to make jobs, nothing more. The default if you don't specify it explicitly is, I believe, the number of threads, but there's no rule that says you have to follow that.
<pashencija[m]>@nckx I hope you don't mind I just CCed you in our bootloader thread
<Lumine>nckx: I see
<nckx>I have 8T/4C, so I set --max-jobs=3 --cores=3 so the CPU is over 50% used in most unfavourable situations, and not too overloaded in favourable ones.
<pashencija[m]>I just don't feel there's a way we come to anything with @antipode
<unmatched-paren>pashencija[m]: You don't need to @ people on IRC :)
<unmatched-paren>Just mention their name.
<florhizome[m]>ah ok so my confusion came from guix jobs vs make jobs
<orneb>nckx: thanks! Does the graphical Grub menu work with Coreboot? With my current configuration it was missing and as suggested here https://www.mail-archive.com/help-guix@gnu.org/msg13012.html I had to add (terminal-outputs '(console)))) to enable the console-mode grub menu but it produced this error after entering the first passphrase: "error: no video mode activated". I could reach the login prompt but it was taking longer to unlock
<orneb>the bootloader.
<nckx>pashencija[m]: Ouch. That sounds inauspicious.
<pashencija[m]>Ok)
<pashencija[m]>Just a habbit from Telegram
<florhizome[m]>Actually same so i will copy that
<pashencija[m]>Well, I feel like the problem is not the parch, but pantherx email. They question patches from these emails, even without intent to check them carefully
<florhizome[m]>what ist suspicious is that on my 2C/4T ThinkPad i don't get freezes but maybe IT has to do with running gnome here
<nckx>It might be RAM related and nothing to do with your CPU.
<nckx>Way too many possibly causes to be able to say anything from this distance.
<florhizome[m]>Thats feasible, i only have 8G here as of right now and Just using zram and No swap
<nckx>pashencija[m]: That doesn't jive with my image of antipode. I did read & respond to the note about upstream/downstream, which you did fix. I would expect them to review the patch with their usual above-average rigour but no more. I'm sorry you experienced it that way.
<florhizome[m]>upgrade is on the way though :)
<pashencija[m]>Ok
<pashencija[m]>Anyway, if there's someone more familiar with uboot, raspberries, m1n1 or bootloaders in general - I really need help there explaining things
<nckx>I am familiar with exactly 0 of those specifics.
<nckx>‘Bootloaders in general’ — sure, but the patch addresses a pretty specific issue on one specific platform (no DTC on x86), which I don't use.
<nckx>I'll take a look.
<pashencija[m]>Very well!
<pashencija[m]>On x86, that you do not use, there's no FDT
<pashencija[m]>So, given extlinux bootloader, for example, or syslinux, that line is redundant
<nckx>Right. I just meant that even my above-average ‘general knowledge’ of these things is still heavily biased towards x86.
<pashencija[m]>That's why I propose to make it optional!
<nckx>OK.
<nckx>I'll reply when I've read everything.
<nckx>So not right now.
<pashencija[m]>Even on x86, this patch could benefit people if they need to make an image with extlinux.conf
<pashencija[m]>I should have mentioned that in my emails
<pashencija[m]>Ok, fine. Thank you!
<nckx>orneb: I think so…? Funny, I use Coreboot and I couldn't tell you for sure :) I'll have to pay more attention next I reboot.
<spaethnl>Is bug-guix@gnu.org suitable for reporting outdated package versions, or is it specific to broken functionality?
<nckx>orneb: I couldn't handle self-doubt so I rebooted. GRUB is definitely in graphical mode. I can tell by the font, and the pixels.
<nckx>spaethnl: The latter. Outdated packages are ‘reported’ to guix-patches@, hint hint hint :)
<nckx>It's generally very little work. But if you're not ready for that, that's fine! Which package?
<spaethnl>nckx: That was my suspicion, but yes, I thought there might be a mechanism to report packages for newer users to help make a smoother transition from other systems.
<Lumine>Well that sure took its sweet time but, nckx: https://paste.opensuse.org/2730447
<nckx>Speaking only for myself, I don't need or want that. The people interested in package X already have several tools to check for X updates, and updating packages you don't care about gets old (turns into $work) fast.
<unmatched-paren>Lumine: There'll be more log
<unmatched-paren>could you paste the whole thing?
<spaethnl>nckx: The latest available version of nodejs is 14.19.3 which is the maintenance mode lts version. The current lts version is 16., and the active version is 18.x
<cassio>Hi there!
<cassio>I'm having trouble with things that take up 100% of the CPU time so that I can't even use the keyboard or mouse ─ in two circumstances:
<cassio>1. When reconfiguring my `guix home`, even when I use the options `--max-jobs=1 --cores=$(nproc)`. What can I do about this?
<cassio>Earlier, nckx suggested that if using a makefile I can set things up so that the packages are built one at a time, and that this, together with the above options, I would solve the matter. Since I'm so raw, can someone offer me a sample makefile for me to learn from?
<cassio>2. Periodically (I can't tell how often), some background task that I suppose is run by the system itself. How can I find out what is it that does that, and how to make it less obstrusive?
<nckx>Lumine: Yes, moar log.
<nckx>bzcat /var/log/guix/drvs/6y/skz2ddf8mq7q52xgmpd8ll5npbsvww-python-jaraco-functools-3.5.0.drv.bz2
<nckx>What you pasted is just ‘something went wrong :-(’, nothing we can debug from that.
<unmatched-paren>cassio: --max-jobs=1 should build only one package at a time, i think?
<nckx>cassio: I think you might have misunderstood me, because I honestly have no idea why or when I would have suggested writing a Makefile.
<cassio>unmatched-paren: not according to nckx, if I got it right...
<Lumine>The whole nine yards: https://paste.opensuse.org/40563213
<nckx>--max-jobs=1 → build 1 package at a time, --cores=$(nproc) → politely ask that package to spawn as many tasks as you have logical cores, but it's not a hard guarantee. Not all phases meaningfully parallelise either.
<nckx>cassio: If 100% CPU use is an issue (my CPU is constantly at 100% all cores, my mouse works fine), you can set --cores=N where N is smaller than your number of logical cores (nproc).
<nckx>Lumine: Thanks!
<cassio>nckx: well, you said that `max-jobs` and `cores` would be a precarious solution, and that I would have to "make job" (I think) to limit the build to one package at a time, so as to not freeze the CPU while getting a reasonable performance...
<nckx>Lumine: …uhh, are you sure that's the output of zcat /var/log/guix/drvs/6y/skz2ddf8mq7q52xgmpd8ll5npbsvww-python-jaraco-functools-3.5.0.drv.bz2 ? That just looks like terminal output to me.
<cassio>nckx: maybe your mouse and keyboard are PS2? USB interface are not preemptive...
<nckx>cassio: Bluetooth, even.
<nckx>Well, the mouse.
<nckx>Free found abandoned Magic Mouse for the win.
<Lumine>nckx: sorry, first time ever doing a paste for someone :)
<nckx>No problem, it is all gibberish.
<orneb>nckx: then my wrong partitioning scheme messed grub up.
<cassio>nckx: Is Bluetooth preemptive?
<lechner>Hi, what's everyone's favorite way to maintain system and home configs in Git, please?
<nckx>As (non-)preemptive as USB, because I also use a USB mouse when docked with equal success.
<nckx>cassio: All I said (or at least meant :) was that you'd have to find a balance between --max-jobs and --cores that works for you. It's precarious because there is no right set of values, it's always a suboptimal compromise. The extreme solution for you would be --max-jobs=1 --cores=1 — asking Guix never to use more than 1 CPU core. Serious drawback: builds will take even longer.
<unmatched-paren>lechner: I use local-file to grab the configs from the directory: https://git.sr.ht/~unmatched-paren/conf
<nckx><it's always a suboptimal compromise> And the right values differ per *Guix invocation*, not per machine.
<nckx>Lumine: It might be overkill, but there's a wgetpaste tool you can ‘guix install’ into which you can pipe text (like the output of bzcat … | wgetpaste) and it will spit out a ready-made URL.
<cassio>nckx said:
<cassio>>> cores=$(nproc) → politely ask that package to spawn as many tasks as you have logical cores, but it's not a hard guarantee. Not all phases meaningfully parallelise either.
<cassio>Well, I tested that, and apparently they do not comply, since all cores go to 100% and stay there! I'll try to limit to 3 cores then... Later I'll report the result.
<podiki[m]>lechner: I use stow and git, with (some) literate programming org files that produce the dot files; not (yet?) guix home
<nckx>cassio: I generally don't accept the challenge to debug performance issues from a difference, because it's simply too inefficient. But in your case I'd look at which process is to blame for that ~300% CPU usage. I suspect it's guile, but even Guile should respect your core count preference, although I admit to never testing it with 1.
<nckx>‘from a difference’? From a distance :-/
<nckx>cassio: And it's perfectly possible that you found a bug that nobody ever noticed.
<nckx>Most people simply won't notice that something's using 300% instead of 100%.
<nckx>cassio: If ‘-{M,c}1’ uses more than, say, 200% CPU for a signficant time, I'd report it.
<Lumine>nckx: as requested https://paste.opensuse.org/96850541
<vivien>Some build systems think they are more clever than you and will always use all your cores, whatever guix asks for
<unmatched-paren>for those it might be possible to make them respect --cores by passing some flag, I guess
<nckx>vivien: And we shall lovingly correct them >:)
<nckx>I didn't mean to imply it's not always going to be whack-a-mole, it is, but we should still encourage people to report the moles for whacking.
<vivien>I already picture the answer: ??? Why would you want to NOT use all your cores to compile a project in $language?
<vivien>Anyway, $language is slow to compile, so we prefer to activate all cores by default so that users won’t notice that it’s slow.
<unmatched-paren>vivien: I believe most build systems have a way to configure cores, but the Guix wrapper doesn't respect it.
<unmatched-paren>s/doesn't/sometimes doesn't/
<vivien>That’s the most probable thing yes
<nckx>For example, it's easy to write a custom phase to ‘make’ that extra thing and forget to apply invoke make-flags to it.
<nckx>(Or the other-build-system equivalent.)
<nckx>Oh, no, wait, not even make-flags, the even more complicated cargo snippet to respect (number->string (parallel-job-count)) that litters the tree. :)
<nckx>Lumine: Thanks.
<nckx>God.
<nckx>So not only is it a timing issue, it is a test that deliberately induces a timing issue expecting a known result?
<nckx>I assume you read the ‘reason’ field of that test. There is absolutely no reason to spend any time debugging it, I'll just disable the test.
<cassio>nckx: I'm running the reconfiguration now with `cores=3` and `max-jobs=1`. So far the average cpu usage ranges from 72 to 96%. I'm not blocked out. So I ran `top`, sorted by CPU time. It seems that the heaviest processes are from `gcc`, mainly this one: `cc1plus`.
<antipode>nckx,pashencija[m]: I would like to clarify that I don't really know extlinux and DT well, my 'knowledge' comes from checking lwn.net regularly and browsing the web a bit.
<cassio>nckx: and there is this, which I didn't expect ─ `.telegram-desktop-real`
<antipode>My concern is more based on "it appears that this is a problem that can be solved more automatically by sending stuff upstream (Linux), who presumably would appreciate better functionality and fixes" than "that would actually work".
<apteryx>nckx: looks like the rsync already finished?
<antipode>(on the extlinux) There might be technical problems with that, but the way the responses were written, the real problem appeared to be a lack of willingness to send fixes upstream.
<nckx>Yes.
<nckx>apteryx: ☝
<apteryx>thanks!
<nckx>/var/cache is the SAN now.
<antipode>Which is not a practical basis to run distro 'maintenance' on, hence my insistence on "why not just send your improved device tree to Linux".
<apteryx>great!
<apteryx>nckx: thank you :-)
<nckx>You're welcome, sorry for the misunderstanding or I'd have done it sooner.
<pashencija[m]>antipode: I cannot agree these are upstream issues
<antipode>nckx: On the dejagnu: the issues.guix.gnu.org I linked to has a patch, hint hint (the way your response was written, it appeared that you thought I just linked to an upstream discussion)
<apteryx>nckx: no worries!
<rekado>nckx apteryx is berlin stable enough to be reconfigured this week?
<rekado>I’d like to fix guixwl.org
<nckx>antipode: That was indeed how I read it, and I didn't even click the link!
<apteryx>the two issue at this point are: bootloader needs post reconfigure manual care (still) and shepherd appears to eventually lock itself
<nckx>rekado: I was reconfiguring earlier but got disconnected before it finished, but yes, the answer is yes.
<nckx>Just don't reboot.
<nckx>I mean, it can be booted if that would happen, but it's still manual.
<rekado>okay
<rekado>thanks
<nckx>apteryx: Oh, about that: https://logs.guix.gnu.org/guix/2022-08-22.log#195901
<pashencija[m]>nxkx, antipode, the problem is that there're some platforms that do not require loading FDT and Guix does not support that
<nckx>Bizarre and implausible but observed fact.
<pashencija[m]>That's not the upstream issue that uboot should not load FDTs on these platforms. It's how things are intended to work!
<apteryx>nckx: perhaps related to #56674
<nckx>Sorry, but a board owner having to know that their board does or doesn't require loading this thingamajig called an efdeetee is broken, intended or not. That's software's job. Someone in the stack needs to know that and DTRT, not pretend it's the user's job.
<apteryx>if they make use of waitpid and system* or other things that don't play well with fibers
<pashencija[m]>I do not understand why Guix that
<pashencija[m]>1) Violates the "The Boot Loader Specification"
<pashencija[m]>2) Passes additional param to uboot that is not supposed to be there
<pashencija[m]>is not a guix issue? Why is it an upstream issue? Why do not other distros have troubles with this boot order?
<nckx>That is not what I said.
<pashencija[m]>What did you say then?
<pashencija[m]> * I do not understand why Guix that
<pashencija[m]>1. Violates the "The Boot Loader Specification"
<pashencija[m]>2. Passes additional param to uboot that is not supposed to be there
<pashencija[m]>is not a guix issue? Why is it an upstream issue? Why do not other distros have troubles with this boot order?
<nckx>I assume you're talking to antipode, because zero of these questions are relevant to what I said.
<nckx>So finding the answers is up to you.
<pashencija[m]>Ah, the problem for you is that it's user's deciding?
<pashencija[m]>s/'s//
<nckx>Maybe I gave the impression that the user shouldn't be able to decide. That was not my intention.
<pashencija[m]>I don't understand you then
<pashencija[m]>It's like... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c10d925eb7c3ce0f37d5d4aae5eb6f4d0a23de6c)
<pashencija[m]>The code above can be a part of channel, for example
<nckx>Then what antipode says above isn't true because they can't both be true.
<nckx>So OK, implication received.
<jab>unmatched-paren: I am getting closer to merging my debbugs-guix-bugs to debbugs. The patch will also include a debbugs-gnu-my-open-bugs function.
<nckx>I wouldn't have got caught in between had I known *that* :)
<pashencija[m]>That's actually the aproach that's not used in guix
<pashencija[m]>Check u-boot-beaglebone-black-bootloader in guix/gnu/bootloader/u-boot.scm
<pashencija[m]>that's used*
<pashencija[m]>I'm kind of sleepy
<nckx>Will do.
<pashencija[m]>Thank you!
<nckx>I never meant to imply Guix was automatically correct.
<nckx>Lumine: You got lost in all this. Could you pull & try again?
<mubarak>Hi guix :-)
<Lumine>nckx: sure
<mubarak>three days ago I tried two times to install guix 1.3.0 amd64 on my laptop. one installing guix with Xfce desktop and the second one install GNOME desktop. Each time after "guix system init /mnt/etc/config.scm" complete installing all the packages it say system installed successfully and run "reboot" to boot to the new system. After rebooting the bios says 'No bootable device'. I tried to "chroot" to installed system after mounting /dev/sda1 to /mnt. but
<mubarak>there is no "guix" command or "grub-install". I don't know what to do to make it boot.
<mubarak>here is my config.scm https://paste.debian.net/1251379/
<pashencija[m]>You need to do system reconfigure
<Cairn>This is a very basic question, but you remembered to add your mount point to "guix system init" right?
<pashencija[m]>Are you sure you need MBR boot?
<pashencija[m]>Are you sure the correct drive was `/dev/sda`?
<mubarak>pashencija[m], yes I'm sure
<mubarak>when formating /dev/sda1 I make a label with "mkfs.ext4 -L my-root /dev/sda1"
<mubarak>Cairn, yes. I just forget to type it here
<Cairn>Ok, just being sure =)
<Cairn>So when you chrooted into it after the reboot, was anything there? Like, did it seem like it should work if only it booted? Or was it missing a bunch of dirs?
<Joop>When is the store directory for a package that is being built normally created?
<Joop>I'm a bit puzzled since a fairly standard gnu-build-system package that I'm writing a definition for complains during the install phase that /gnu/store/<hash>-<package name>-<package version> does not exist
<mubarak>Cairn, when I chroot to /dev/sda1 mounted to /mnt, I saw most of the directory's there like etc, dev, home, var. When I typed guix it says command not found or grub and pressed the "tab" key and their is less than 20 command(like single user mode thing)
<Cairn>Joop it should be created as the very last step iirc. That way, if it fails, it doesn't leave a broken package around.
<Cairn>Joop: strange though. What are you passing as install flags?
<Joop>I'm not passing any install flags
<Joop>Just a PREFIX= make flag and CC=gcc
<mubarak>OK pashencija[m] I will install it tomorrow and I will try 'system reconfigure' and will let you know. I think when I reboot and and I try system reconfigure, it's going to download all the packages again like a fresh installion. right?
<Cairn>Ok
<Joop>Cairn: What do you mean by the very last step? In the install phase?
<pashencija[m]>mubarak: You should do that after you find out what's wrong with your system config
<pashencija[m]>I hope someone more familiar with it then me can help you with that
<Cairn>Joop: I suppose the build phase.
<Joop>Weird, I've left that one as-is. I have deleted the configure phase, though, which I think is most likely the culprit
<Joop>I'll take a look at (guix build gnu-build-system) again
<Cairn>mubarak: I don't think there's any issue with your configuration; I looked through it carefully.
<nckx>Joop: If the package's build scripts assume that $prefix exists, and it doesn't, you'll have to mkdir-p it before the 'install phase.
<nckx>(And it doesn't; Guix doesn't create it for you.)
<Joop>Huh, so the store directory isn't created directly by Guix, but by the build system?
<jab>Hey Cairn we talked yesterday!
<Cairn>Hey jab!
<mubarak>Cairn, yeah it's confusing. the first time I install it, I umount /mnt before reboot. The second time I reboot without umounting as the installer said to reboot without mentioning umounting.
<antipode>Joop: (string-append "CC=" #$(cc-for-target)), for cross-compilation, though it won't resolve your issue.
<nckx>Joop: Yes.
<antipode>Caveat: in some rare situations, a native c compiler is needed instead.
<Cairn>mubarak: Either way it sounds like it's being written to the mount point, since it was there when you chrooted. Are you extra sure that you don't need to use UEFI?
<Joop>antipode: Thanks, I'll put that in the definition 👍
<mubarak>Cairn, there is a option in the bios to enable UEFI but I haven't enable it for a year, since I bought this laptop(
<mubarak>(HP Probook 4530s)
<Joop>nckx: Interesting. I assume Guix does provide a default for $prefix to the build system, no? I didn't have to specify $prefix the last time I wrote a package
<mubarak>Installed on it Trisquel, Debian, OpenBSD, and all worked just fine with MBR
<antipode>Joop: it does not (IIRC)
<Cairn>mubarak: Wow, then I'm really not sure.
<antipode>Guix currently expect it uses a system like Autotools or such to generate a 'make' and passes --prefix to ./configure
<antipode>I think it would be nice to add a 'toolless-make-build-system' though, setting PREFIX, prefix and CC appropriately.
<mubarak>In 2021 installed Guix 1.0 amd64 on my old laptop 'Toshiba Satellite C660' which didn't have UEFI. I boot to the new system successfully
<Joop>antipode: Ah, ok. So that's why the project which I'm packaging (which supplies its own makefile and does not use configure) does not have its store directory created automatically, right?
<nckx>Correct.
<nckx>Guix doesn't pass default ‘make’ flags like it does ./configure flags.
<Joop>Cool. Thanks for explaining :)
<nckx>Joop: Store file names don't need to be directories, so creating a directory would be a bit… forceful.
<nckx>(Better late than never.)
<nckx>s/ name//