IRC channel logs

<gabber>which vm image are you trying? you could try a newer one (if you're not on the master branch's HEAD) or an older one (using guix time-machine)

<nikolar>gabber: oh i just used the installer

<nikolar>i haven't guix pulled yet because of crappy wifi at the momemnt

<nikolar>might have something to do with it

<mirai>ha! I think I went over my email rate cap 😂

<Guest96>Hi all. Trying to package a python module (python-mkdocs-autorefs), and I immediately have checks fail with:

<Guest96>Using #f

<Guest96>error: in phase 'check': uncaught exception:

<Guest96>%exception #<&test-system-not-found>

<Guest96>Correct me if I'm wrong, but this seems like it is crashing BEFORE running any python

<Guest96>(That is followed by a guile traceback ending in ice-9/boot-9.scm)

<mirai>Guest96: paste snippet

<Guest96>mirai: see https://zacchae.us/89q01ml9rkqiinq4xknrgf3xi6cr1g-python-mkdocs-autorefs-0.5.0.drv.gz

<Guest96>for the full build log

<mirai>can you paste the package definition as well?

<mirai>oh, maybe it's not needed

<mirai>does this package have any tests at all to begin with?

<Guest96> https://zacchae.us/mkdocs-autorefs.scm

<Guest96>oh, um...

<mirai>if not, put “#:tests? #f ; no tests” in the arguments

<mirai>if it does try to get them working or if you define your own tests, you can modify the phases with (replace 'check …)

<Guest96>It seems like the upstream repository has a Makefile which has a check, which mentions pdm, another build system

<Guest96>Thanks for the help mirai, I think I have it for now

<Guest96>On an unrelated note:

<Guest96>Hey Guix! I am officially packaging some free software from my company in guix as part of my work duties! Don't know how much time I can spend on it, but I'm pretty excited

<Guest96>(I use guix as my daily driver, but haven't really packaged anything)

<Guest96>Speaking of which, do I need to get "GNU certified" or whatever? Since guix is a GNU project, I think there is some form I need to get signed by my company before I can contribute, right?

<mirai>no CLA or copyright assignment is required for guix

<mirai>other GNU projects may differ

<Guest96>Neat

<xelxebar>Sometimes at boot, my shepherd pegs a core at 100% for 10 minutes or so. Anyone else see that?

<Guest96>latest guix iso returns 502

<mothacehe>hey guix!

<janneke>o/

<civodul>Hello Guix!

<mothacehe>hey civodul

<janneke>o/

<nckx>xelxebar: Does your machine have an RTC, and is it set correctly? There's a bug where the Shepherd tries to mentally relive the 70s in real time or something if you don't.

<xelxebar>nckx: Bingo. Yes, and I'm having issues with it. Always get thrown back to 2021 on reboot.

<PurpleSym>Has anyone tried Guix on WSL2 recently? I only get a “Bus Error” when trying to `guix install` or `guix shell`.

<civodul>hey mothacehe! i pushed the alist->record changes to Cuirass

<civodul>hopefully that'll give us more assurance when changing the code

<mothacehe>civodul: awesome! no more alists! It will help a lot when working with database and template modules

<civodul>mothacehe: yup!

<civodul>i expected it to be a quick and rewarding change

<civodul>it wasn't quick

<civodul>:-)

<jonsger>I assume this change will have consequences for downstream channels or?

<civodul>jonsger: oh no, it's entirely limited to the internals of Cuirass

<mothacehe>hehe the commit is huge, never had the courage to do that myself

<jonsger>ah thats good :)

<civodul>heh :-)

<janneke>mothacehe: it's easy to break things with small commits too :)

<ngz>Uh Oh. "guix pull" is freezing for me. I hope I didn't break anything is my last push. Has anyone been able to guix pull in the last minutes?

<drewjose>works for me ngz

<ngz>drewjose: OK, thanks. At least it only broke here.

<janneke>yes, works for me too

<ngz>OK. I found out that my GUIX_PACKAGE_PATH contained garbage and prevented `guix pull' from completing. Thanks drewjose and janneke.

<civodul>GUIX_PACKAGE_PATH, sooo old-fashioned!

<ngz>Yes, I know =/

<civodul>:-)

<ngz>I have a question about (guix profiles)

<ngz>AFAICT, `manifest' doesn't contain references to propagated inputs from packages in the `manifest' itself. Or at least, there are some subtleties wrt these inputs. Is this something known?

<jonsger>ngz: do you test all these texlive packages in someway?

<ngz>jonsger: Do you mean the TeX Live packages I commit? Certainly not. I just ensure they build.

<andreas-e>ngz: I do not know the answer, but I have noticed that "guix package --export-manifest" only shows the packages that also appear with "guix package -I" and not the propagated ones.

<ngz>andreas-e: This is the core problem in the "guix pack python-notebook" problem reported recently.

<ngz>This stems from `python-nubconvert', which propagates its TeX Live inputs.

<ngz>While these inputs are correct, they do not appear when using `guix pack python-notebook'. Or to be more precise, they do appear, triggering the TeX Live font maps hook, but then disappear. I'm very confused.

<andreas-e>ngz: I have never looked at profile hooks, so just had a very high-level glimps. So you say that texlive-scripts is found and the hook is triggered, but then it fails because it does not find the other texlive packages?

<andreas-e>The first check is this, right? (if (any texlive-scripts-entry? (manifest-entries manifest))

<ngz>andreas-e: Almost. Yes, (pk (manifest-entries manifest)) just before that test returns everything that is needed. However (pk '#$texlive-entries) is empty.

<ngz>(the latest `pk' invocation being in the `build' function, right before `union-build' call)

<andreas-e>ngz: You mean texlive-inputs, not texlive-entries?

<ngz>Yes, sorry, '#$texlive-inputs

<ngz>Ultimately, the `union-build' creates nothing, resulting in a chdir error.

<andreas-e>So the difference between the two is gexp or no gexp?

<ngz>andreas-e: Note the error can be reproduced with `guix shell python-nbconvert'. But then, if you move `python-nbconvert''s propagated inputs to regular inputs, the same command succeeds.

<ngz>andreas-e: It seems a gexp vs. no gexp difference, indeed.

<andreas-e>The strange thing is that I do not see how this code could distinguish between propagated and normal inputs.

<ngz>Neither do I.

<andreas-e>ngz: 296 new texlive packages? Amazing!

<ngz>Yup. Modular TeX Live now have 70% coverage of the full TeX Live!

<ngz>has*

<andreas-e>ngz: I moved just one of the texlive propagated inputs of python-nbconvert to normal inputs. But then I also do not see anything with the (pk '#$texlive-inputs) command, which I just discovered.

<ngz>What command did you try?

<andreas-e>I did "./pre-inst-env guix shell python-nbconvert", after adding a line " (pk '#$texlive-inputs)" right before "(union-build ..."

<andreas-e>Now I added "(pk (manifest-entries manifest))" right after "(with-monad %store-monad". This prints a bunch of texlive-... things.

<civodul>ngz: 70%, woow!

<civodul>did you tweak the importer?

<civodul>do you have magic tricks? :-)

<ngz>just lot of spare time… ;)

<ngz>Yes, I did tweak the importer.

<civodul>neat

<civodul>maybe let's see if there's something we can import in the importer proper

<andreas-e>Then I added "(pk texlive-inputs)" right after "(with-monad %store-monad". This prints ";;; (())".

<andreas-e>So maybe the definition of texlive-inputs is wrong?

<ngz>andreas-e: I see that, too.

<ngz>civodul: what do you mean?

<civodul>ngz: i mean we should take the improvements you made to the importer

<ngz>civodul: Ah. I think those are very TeX Live specific, unfortunately. It is just parsing "texlive.tlpdb" file with more ardour than before.

<andreas-e>ngz: If in the definition of entry->texlive-input I take out the test and always return "(cons ..." instead of sometimes '(), then I obtain something.

<civodul>ngz: well, "guix import texlive" *is* texlive-specific, so that should be fine :-)

<ngz>andreas-e: so maybe there's something in the recursive call, i.e., in the DEPS parameter?

<ngz>andreas-e: No, that doesn't make sense. There should be at least one "texlive-" package in that case.

<ngz>adreas-e: I think I get it.

<ngz>andreas-e: The first package (python-nbconvert) has "python-" instead of "texlive-" prefix, so its dependencies are never checked.

<ngz>Duh :(

<andreas-e>I just came to the same conclusion...

<ngz>he he

<andreas-e>What is printed out is ((...)), so a list with only one entry.

<andreas-e>So apparently append-map is applied to only one entry. One would need to unroll one level, probably.

<ngz>Hmm. I think (append-map entry->texlive-input deps) should be applied to every input, otherwise it will not solve the problem of, e.g., python-notebook.

<andreas-e>Well, you are right, the problem is more complex. One always needs to check all dependencies. Recursion should stop at leaves, not packages starting with something else than texlive-. So there are 4 cases: leaf starting with texlive-: list with one element; leaf not starting with texlive-: empty list; other package recurses.

<ngz>I.e., something like (if (string-prefix? "texlive-" name) (cons (gexp-input ...) (append-map ... deps)) (append-map ... deps))

<andreas-e>Yes, but there must be an additional case for the empty list.

<ngz>What empty list?

<andreas-e>Your current recursion never stops.

<andreas-e>You could add two subcases depending on whether deps is empty or not.

<ngz>Ah, yes.

<andreas-e>Or maybe use matching/types. entry->texlive-input could also take the empty list as additional case and then return the empty list (I do not know if this is Guile compatible).

<andreas-e>Or maybe your solution above just works - append-map on the empty list should already return the empty list, right?

<ngz>I think so.

<ngz>Something like: (cond ((null? deps) ...) ((string-prefix? "texlive-" name) ...) (else (append-map ...)))

<ngz>Also checking for "texlive-" prefix in the first cond branch.

<ngz>I.e. (if (string-prefix? ...) (list (gexp-input ...)) '())

<andreas-e>I tried it out. Your solution works! (if (string-prefix? "texlive-" name) (cons (gexp-input ...) (append-map ... deps)) (append-map ... deps))

<ngz>Ah. Because `append-map' stops at the end of deps, or do nothing if it is empty.

<ngz>does*

<andreas-e>map returns the empty list when applied to the empty list. And then append-map also returns the empty list when applied to the empty list.

<ngz>adreas-e: Well, it looks like we solved bug#65474.

<andreas-e>Yes, what a nice feeling! Do you want to commit it?

<ngz>Fine. Are you OK with me crediting you in a Co-Authored line? (which may look funny in a single line patch!)

<andreas-e>ngz: Fine with me, thanks! Well, the time it takes to solve a problem is not necessarily related to the size of the solution :)

<ngz>Very true.

<peterpolidoro>can guix containers be run without issue inside of another guix container or could that cause strange problems?

<civodul>peterpolidoro: hi! for 'guix shell', you'll need the '--nesting' (-W) option

<peterpolidoro>oh interesting I have not seen that option I will look it up thanks

<civodul>yw!

<civodul>check out https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html

<janneke>ACTION just successfully ran: guix system build gnu/system/examples/devel-hurd.tmpl (devel-hurd.tmpl from the wip-hurd branch)

<peterpolidoro>for the outermost shell, is "guix" the only needed package to run any guix shell inside?

<civodul>janneke: neat! native, right?

<janneke>yeah

<civodul>woow

<janneke>after running guix pull

<janneke>well, guix pull --url=$PWD

<civodul>ok

<civodul>peterpolidoro: -W adds the current guix to the profile, so you don't need to explicitly add the 'guix' package

<peterpolidoro>but you probably always want coreutils correct?

<janneke>we might be getting really close to not having to re-install childhurds again

<civodul>peterpolidoro: probably yes

<civodul>janneke: why reinstall?

<peterpolidoro>but the innermost container cannot have permissions that the outermost containers do not have correct? So I have to expose and share all directories to the outermost container that I want to use in the inner containers?

<janneke>well, without guix pull and guix system reconfigure, you have to re-create/re-install again if you want to make any interesting update

<janneke>building all these VMs is getting a bit boring to me :)

<civodul>oh yes, you mean you have to cross-build the new stuff, right?

<civodul>yeah, understandably :-)

<janneke>yeah, make a swap file, install keys, etc

<janneke>clone the guix archive

<civodul>yup

<janneke>civodul: thoughts on my v4 for guix/self.scm? https://issues.guix.gnu.org/65456#12

<janneke>i'm pretty sure this one is correct, but really don't want to break master again

<janneke>jpoiret: you're looking at hurd 64bit already?

<civodul>ACTION looks

<apteryx>is anyone using an AMD GPU successfully with Guix, without any proprietary blob? What model and what's your satisfaction with it?

<civodul>janneke: just replied! ... with more questions :-)

<civodul>(BTW, i'll be mostly AFK in the coming week)

<janneke>civodul: thanks! some more stuff for me to try :)

<janneke>and a typo :)

<civodul>heheh

<janneke>(working code is great -- and this seems to work for the hurd -- but having some idea as to why it works is _much_ nicer :)

<akonai>How does one reboot/recover a Guix system if shepherd/herd is frozen?

<nckx>ACTION .oO REISUB.

<mirai_>akonai: yank the power cord/press the button (5sec) ?

<nckx>(The ‘advantage’ of REISUB is that whatever data can still be flushed to file systems, is.)

<mirai>nckx: oh, nice. TIL

<andreas-e>apteryx, mirai: What is the status of the core-updates branch? Do you plan more commits, or can we apply for merging? I would like to get the new wget version in to stop the anomaly of hosting a tarball privately.

<akonai>mirai: ofc, but preferrably avoiding potential data corruption

<andreas-e>By the way, what does it imply for the time machine? Since the spring core-updates merge, we have relied on this private tarball that I intend to delete.

<mirai>andreas-e: I've just sent my last intended batch of XML changes at <https://issues.guix.gnu.org/65479> and I'd recommend cherry-picking <https://issues.guix.gnu.org/60824> while we're at it as well

<mirai>in retrospect I should have requested a xml/docbook-branch (wasn't too confident & didn't anticipate the torrent of commits I'd end up writing)

<nckx>akonai: The ‘U’ part should take care of that.

<nckx>The layout is always US QWERTY, by the way, so if you have anything else you'll have to remap it in your brain or find a cheat sheet somewhere.

<andreas-e>mirai: Okay! I will let apteryx look at the issues, I think he is well-versed in the question.

<mirai>tangentially related, how do you all handle mail provider hourly limits for larger patch-series?

<mirai>I had to count the missing patches and manually send them since I went over my cap

<civodul>oh, Londoners have a Guix meetup today: https://mobilizon.fr/events/89220a82-ced2-413e-b291-7cc3fcd8aa7c

<cbaines>mirai, the --batch-size and --relogin-delay arguments to git send-email may come in useful

<andreas-e>cbaines: Concerning QA, there is a message for the core-updates branch: "Exception checking changes between merge base and master."

<andreas-e>Can this be solved by rebasing or merging master into the branch?

<andreas-e>I am surprised that on the activity page, I see only packages from master. Should there not be packages from other branches also, or from the patches branches?

<mirai>cbaines: thanks

<mirai>Is this intended behaviour for guix offload: <https://paste.centos.org/view/8c4b8938>

<cbaines>andreas-e, regarding core-updates, the message needs improving, but part of the issue will be that the data service hasn't processed the merge base commit yet https://data.qa.guix.gnu.org/revision/a27d172ee66472a255754bf88ae8fb4ce73ec9ad

<cbaines>this can be worked around by rebasing or merging master in, providing the new merge base is a commit that data.qa.guix.gnu.org has processed

<cbaines>as for the lack of builds for patches, I think they're in the queue, there's just master branch things to build first

<andreas-e>cbaines: Thanks for the explanation! Concerning the queue order, does master come first unconditionally, or do the branches mix with lower priority packages interspersed?

<andreas-e>We definitely need more machines...

<cbaines>builds for master will generally take priority, for the build coordinator priority is just a number and you can see the base priority for patches here https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/manage-builds.scm#n121

<andreas-e>Okay, thanks!

<andreas-e>cbaines: Ah, the emacs team gets a share, nice! Does anything need to be restarted on the activity page? I do not see anything appearing in the "Recent activity" box since this morning, and fear for my favourite evening entertainment.

<cbaines>andreas-e, I've restarted the bffe now. The server sent events stuff needs fixing to get it to reconnect to the coordinator when necessary. At the moment it often stops working.

<andreas-e>Thanks!

<cbaines>I'm not actually sure where those emacs-team builds are coming from, as I don't think there's been a merge request for emacs-team?

<cbaines>the one I've checked was scheduled yesterday

<andreas-e>So maybe it has happened, but there are still derivations left over to be processed?

<cbaines>hmm, maybe QA is building the first two branches, regardless of whether there's a merge request yet

<cbaines>andreas-e, I thought that might be the case, but I can't find the issue https://issues.guix.gnu.org/search?query=%22Request+for+merging%22

<andreas-e>cbaines: Indeed. So maybe patches should be preferred to branches? We have quite a queue, which is getting longer.

<andreas-e>(An admittedly interested request, I do have a patch in the queue...)

<cbaines>andreas-e, yeah, I just spotted a bug with submitting builds for patches, so that's probably been getting in the way (at least on x86_64-linux)

<andreas-e>Well, the emacs packages are fast, so this should not be a big practical problem.

<Guest35>What was the name of the application to change the icon theme from adwaita to something else?

<Guest35>Ah found it myself. I was looking for "lxappearance". Is there a way to automatically set this instead of manually doing it after a fresh system install?

<jpoiret>janneke: just wondering what it would take

<roptat>hi guix!

<jpoiret>if it's only a matter of upgrading to glibc 2.38 and adding a new target+system, shouldn't be too hard

<roptat>Guest35, I don't think so, it's a user preference, not a system configuration

<janneke>jpoiret: ah right; got me wondering how far upstream is

<janneke>anyway, it would be amazing if it were realy that simple; excting!

<Guest35>roptat: Okay thanks.

<Guest35>I have have a second disk which I mount in /home/user/media which results on a new system installation that no .bashrc and other default files are generated, since the home directory is now owned by root because of the mounting. What would be best practice for the mounting? Should I mount it at /media instead of home user, should I use a

<Guest35>different mount option?

<roptat>did you create the directory yourself manually during installation?

<Guest35>No, the system does this automatically

<roptat>oh I see, it's a case that's not handled well then

<roptat>probably adding an option to set owner would be good, but the installer doesn't know the UID yet, since the user doesn't exist yet

<roptat>you can quickly fix that with a chmod, I don't think it'll come back at next boot

<zamfofex>x86‐64 Hurd would be lovely! 😄

<roptat>but is it supported upstream?

<roptat>doesn't look like it: "64-bit port. There is some preliminary work for a x86_64 port."

<jpoiret>roptat: it does run

<roptat>oh

<jpoiret>Debian/Hurd 64-bit works from what i've seen

<janneke>jpoiret: no cdimages tho? https://cdimage.debian.org/cdimage/ports/latest/

<apteryx>andreas-e: mirai recently posted a docbook series that should go to core-updates after reviewed

<apteryx>(a follow-up to the original with more goodies)

<pranavats>Hello, since the `lib` output for gcc-toolchain is no longer available, what would be an apt replacement for it? I need the file libgcc_s.so.1 in my load path.

<podiki>pranavats: see https://issues.guix.gnu.org/63393 (stalled currently) and there was a guix-devel discussion https://lists.gnu.org/r/guix-devel/2023-05/msg00047.html (with some work arounds posted for now)

<pranavats>Thanks podiki. Let me take a look.

<podiki>(that was for libstdc++ but i think basically teh same for ligbcc_s)

<csantosb>Hi, I just discovered something funny.

<csantosb>I manage to 'guix pack -S /.guix-profile/bin=bin mg', for example.

<csantosb>But I have an error when I do a 'guix pack -S /.guix-profile/src=src mg', for example.

<csantosb>Same for libexec or sbin instead of src.

<csantosb>No problem when I use etc, lib, include ... any idea ? Is that the expected behavior ?

<nikolar>i have a guix install in a vm

<nikolar>when i run reboot, it just hangs

<nikolar>completely default gui-less install

<Guest96>I want to include a zip with sample data in a package for the checks phase. My idea was something like (define data (origin (fetch-url ...)...)) then adding a phase like (lambda _ (symlink ,data "...")), but that seems to break

<Guest96>Specifically, I get 'Unknown # object: "#<"'

<Guest96>Darn these packages trying to access the internet (shakes grandpa fist menacingly)

<Guest96>When I do guix build with just an origin definition, the file gets added to the store like I expect. Hence, I would expect 'data' to resolve to the path in the store like with packages.

<ulfvonbelow>Guest96: a file-like object is only replaced with its lowered representation when the builder is a gexp

<nckx>Hi Guest96. The , implies you're using ‘old style’ quotation to stage your phases. If you switch to gexps (the ‘new style’), i.e., #~(modify-phases … (lambda _ (symlink #$data …))), it should work. A second approach is to add your origin as an input, and address it that way.

IRC channel logs

2023-08-24.log