IRC channel logs

<bjc>i had ‘required-by’ working before 0.10, iirc. there have been a lot of changes in shepherd since then, so i'm not sure how hard it'd be to forward-port

<ngz>mirai: texlive-bin should not appear anywhere.

<ngz>mirai: texlive-updmap.cfg includes it.

<ulfvonbelow>bjc: how did you handle services being registered after the things they are 'required-by' had already started?

<mirai>ngz: that's not what I see

<ngz>mirai: what do you see?

<mirai>try guix build dblatex, cat the bin/dblatex for the updmap.cfg path and `tree' it

<mirai>there's no binaries in it

<bjc>ulfvonbelow: i punted, because that's how existing dependency chain changes work in shepherd

<bjc>it'd only affect services that hadn't yet started

<ngz>mirai: No, texlive-bin is propagated by texlive-updmap.cfg.

<mirai>hmmm… can the wrapped dblatex find it then?

<mirai>is it safe to remove that presumably bogus path from the wrapped PATH?

<ngz>mirai: I'm indeed wondering why texlive-updmap.cfg is used as an input.

<ngz>mirai: I need to go now. But that's something to investigate,

<Gurgl>Hey guys. Do you know of some hardware vendor that focus on stuff that has free drivers?

<Gurgl>Maybe that's slightly offtopic for the channel…

<cehteh>ikea

<cehteh>with each cabinet you get a free skrewdriver :)

<mirai>Gurgl: check out RYF

<Gurgl>damn… that's actually a good one.

<Gurgl>hmmm looks like I want a Taurinus.

<cehteh> https://secure.raptorcs.com/content/TL2MB1/purchase.html the cost of freedom :D

<Gurgl>damn this world is rough. I'll go wait in the freezer. Wake me up when they have cheap free laptops.

<mirai>8-bit laptops?

<cehteh>there is hurd for 8 bitters?

<damo22>Gurgl: i use an ivybridge intel chipset laptop, and remove 90% of the AMT ME blob

<damo22>close enough

<mirai>damo22: when you me_cleaned the firmware, did the iGPU also stopped working?

<damo22>no

<mirai>huh, that's interesting

<damo22>i use coreboot

<mirai>it borks the iGPU if I do it on haswell

<damo22>hmm havent tried haswell

<damo22>is there native raminit for haswell yet?

<damo22>im guessing not, and there is a MRC blob for that

<mirai>no idea, I've only done running mecleaner on the dumped firmware (with a eeprom programmer)

<damo22>ah ok

<damo22>its nice to have a corebooted thinkpad with 32GB ram.. this one has 4 dimm slots

<damo22>mirai: https://doc.coreboot.org/mainboard/lenovo/t440p.html

<damo22>that one is haswell though

<damo22>(not 4 dimm slots)

<mirai>damo22: interesting

<mirai>never knew that coreboot got support for haswell (or newer?)

<damo22>yes, using a blob for ram bringup

<damo22>provided by intel

<damo22>coreboot is mostly a wrapper for these blobs nowadays

<Gurgl>and what about chromebooks (not a fan of their keyboards afaics)?

<Gurgl>they seem supported

<damo22>google pushed hard with chromebooks to get some i7 support with FirmwareSupportPackage blobs from intel

<damo22>Gurgl: yes, you can get a chromebook and unlock the firmware to flash a plain coreboot image, but its a fair bit of work

<damo22>Gurgl: see https://mrchromebox.tech/

<Gurgl>heh I love how they put a gianormous screw just to lock the firmware. It really is figurative :D

<damo22>hey at least you can unlock it

<Gurgl>Meh, all of this is actually saddening. Plus my server is affected by downfall.

<Gurgl>I might revert to a mechanical computing with yoghurt pots and water.

<damo22> https://frame.work may be interesting if they port it to coreboot

<Gurgl>Ooooow they have matte screens. All right. That looks awesome. Probably corebootable too.

<mirai>what cursed input provides xkbregistry

<lnnk>Is anyone here using gnu boot?

<damo22>lnnk: its not ready yet

<oriansj>lnnk: libreboot is pretty common around here and those using an x200 can operate without the Intel ME shim

<Gurgl>What is the difference between base32 and nix-base32?

<xelxebar>Gurgl: Different character set. Check out guix/base32.scm for the defs.

<Gurgl>yeah I looked it up actually. I spend a lot of time searching on the web and stuff but the code is actually very readable.

<Gurgl>Well, I'll just guix hash all them things I guess.

<xelxebar>BTW, guix hash uses nix-base32-string by default, just in case you care.

<xelxebar>I'm not really sure of the reasons *why* nix has it's bespoke stringifying alg or why it's the default in guix, though.

<Gurgl>well I mostly see the output of sha256 in the wild.

<Gurgl>But running guix hash after is a very minor hassle.

<jpoiret>xelxebar: the nix hashing algorithm has its own character set that should minimize offensive substrings appearing in the hash

<xelxebar>Hah. That's not a reason I was expecting!

<amjoseph>jade_ i think you got trolled by a five year old april fools joke: https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00050.html

<amjoseph>crap wrong channel

<lilyp>twould be nice to have a working systemd package tho for stuff that can't be done with logind alone

<lilyp>but given that more and more components are extracted from it, I'm sure we can soon live in a world without it

<next4th>lilyp: meh, i think our gentoo/bsd friends won't agree.

<fschl>hi guys

<fschl>I am thinking about getting starten with guix for my homeserver. The current setup is a debian machine running docker containers. At the moment I have some basic idea about system+home configuration with guix on a test laptop but struggle to figure out how to run nginx and several php-based web services on GuixSD. Could anybody be so kind and direct me towards a guide/documentation or even an example repo? tyvm :)

<next4th>fschl: there are nginx and php service example in gnu/tests/web.scm, which should be a good start

<janneke>also, maintenance.git -- <https://git.savannah.gnu.org/cgit/guix/maintenance.git> has quite some nginx examples

<renngar>Any options for debugging errors when --on-error=debug does not drop you into the debugger and --keep-failed only produces empty folders?

<fschl>next4th janneke looks good. Thanks!

<ngz>sneek later tell mirai I'm not familiar with this part of the code (maybe rekado knows), but I think 1) you need to indeed add `texlive-bin' outside of `texlive-updmap.cfg' assuming dblatex tries to run binaries and need them in $PATH 2) GUIX_TEXMF should probably be exported in the wrapper so the local texmf tree is used instead of the one in the profile, if any.

<sneek>Okay.

<renngar>Shortish answer to my question: guix build the failed derivation, examine the log output. In my case the top frame was a primitive-load, the partial hash pointed to a builder and I discovered .ko.gz kernel modules are explicitly handled, but my custom build was using zstd, which is not.

<lnnk>Where are wallpapers stored in guix distro?

<Altadil>lnnk: I think it depends on what desktop environment you are using.

<lilyp>is anyone knowledgable about low-level guix stuff here? I think I broke guix itself over at gnome-team; whenever I try building something, it starts pretty much from the bottom with gdk-pixbuf, even if earlier builds succeeded

<next4th>lilyp: eh, how could that happend.. if gdk-pixbuf was build succeeded, it won't build again unless its inputs/reciple changed (drv and output path will change)

<lilyp>that's exactly the thing i don't understand either

<next4th>did run 'guix build gdk-pixbuf; guix build gdk-pixbuf' will build it twice with different output paths?

<mirai>does anyone have any idea what package provides 'xkbregistry'?

<sneek>Welcome back mirai, you have 1 message!

<sneek>mirai, ngz says: I'm not familiar with this part of the code (maybe rekado knows), but I think 1) you need to indeed add `texlive-bin' outside of `texlive-updmap.cfg' assuming dblatex tries to run binaries and need them in $PATH 2) GUIX_TEXMF should probably be exported in the wrapper so the local texmf tree is used instead of the one in the profile, if any.

<nckx>mirai: libxkbcommon

<mirai>nckx: thanks

<mirai>Within the xkbregistry.pc file, there's this line: 'Requires.private: libxml-2.0'

<mirai>should libxml2 be propagated as an input?

<nckx>Ah, so you got a bogus ‘not found’ error? Those blow.

<nckx>There's no good answer for that.

<lnnk>I use gnome can anyone please say where where the wallpapers be stored will be stored?

<mirai>I get this:

<mirai>../gnome-session-42.0/meson.build:101:2: ERROR: Dependency lookup for gnome-desktop-3.0 with method 'pkgconfig' failed: Could not generate cargs for gnome-desktop-3.0:

<mirai>Package libxml-2.0 was not found in the pkg-config search path.

<mirai>Perhaps you should add the directory containing `libxml-2.0.pc'

<mirai>to the PKG_CONFIG_PATH environment variable

<nckx>Oh, at least it named the right package. Build systems often don't (you'd get a ‘xkbregistry not found’ error even after adding libxkbcommon).

<mirai>if I remove libxml2 from gnome-session's native-inputs

<nckx>‘Don't.’

<mirai>but it looks like then that: a) libxml2 isn't a native-input, rather a input; b) it should be taken care by libxkbcommon

<nckx>Most of GNOME can't cross build due to librsvg, so yeah, it's likely there's a lot of uncaught native- vs. input inaccuracy.

<nckx>Pre-hiatus I started an experiment to patch these .pc files. I should pick it up again.

<mirai>I see gnome-desktop takes the input propagation approach

<mirai>whatever is listed within Requires.private is propagated

<nckx>Yeah, it's terrible.

<mirai>so perhaps libxkbcommon should have libxml2 propagated too?

<nckx>There is no good solution.

<nckx>Well, unless we patch such .pc file, which is doable, but currently done only in an ad hoc phase by a handful of packages.

<nckx>*files

<mirai>sneek: later ask ngz, exactly what value/path is to be set for TEXMF for the wrapped dblatex?

<sneek>Will do.

<nckx>The problem with packages like libxkbcommon is that there are ‘legitimate’ reasons to have them installed, so propagation is actually noticable by users. They'd suddenly get libxml2 installed along with it.

<nckx>‘Legitimate’ because they provide binaries, not just libraries.

<mirai>nckx: examples of .pc patching?

<nckx>No idea, but they're there.

<lilyp>yeah, just add libxml2 to the inputs of the package you need

<lilyp>I once suggested a kind of inputs that would only be propagated towards other packages and not profiles, but it got nowhere

<nckx>…with a comment similar to gnome-desktop's, so we can hunt them down some blessed day.

<mirai>hmm… it doesn't feel too right to have a “incomplete” libxkbcommon

<mirai>but yes, I'll put some comments for now

<lilyp>you could also try symlinking the .pc file

<nckx>mirai: I agree, but nor does it feel good to have one that propagates libxml2. Rock, hard place.

<lilyp>that ought to pull in libxml2 silently

<mirai>so that Someone™, Someday™, Somewhere™ will make things Right™

<nckx>It's worked so far.

<lilyp>"the .pc file" here meaning the one from libxml2 – add a symlink to libxkbcommon

<mirai>lilyp: add a libxkbcommon/lib/pkg-config/libxml2.pc ?

<mirai>as a symlink?

<lilyp>yep

<lilyp>that was suggested as a trick that might work way back when and now we finally have a situation to test it

<nckx>mirai: libarchive

<lilyp>ワクワク

<nckx>I still need to test what breaks if you add that as a default phase to gnu-build-system, but it's rotting in a tree nearby.

<nckx>I have high hopes.

<mirai>nckx: any preference for a comment “template” regarding the .pc thing

<mirai>so that you can easily grep for later if you feel like it

<nckx>‘;in Requires.private of libxkbcommon.pc’ if you have the space, ‘;for libxkbcommon.pc’ if you don't.

<nckx>Don't go messing up your indentation just for this :)

<mirai>nckx: doesn't look like libarchive's approach would work with something like this <https://paste.centos.org/view/36b5b7a7>

<mirai>am going to try the symlink route

<mirai>lilyp: The symlink route errors out at 'shrink-runpath/'validate-runpath with this: <https://paste.centos.org/view/2d8b28c2>

<mirai>nvm, was using the wrong filename /facepalm

<lilyp>…

<lilyp>building gdk-pixbuf?

<lilyp>again?

<lilyp>holy moly

<lilyp>nckx: for your displeasure: https://issues.guix.gnu.org/65383

<mirai>lilyp: uuh, I think I've experienced this too

<mirai>idk if it will change anything but can you try a clean-go (or a distclean)

<mirai>my hypothesis is that maybe this is related to shared-mime-info being relocated from one module to another?

<mirai>I think I was also getting frequent gdk-pixbuf rebuilds but didn't think much of it at the time

<lilyp>good hint, wil ltry

<mirai>regarding the xcbcommon & libxml, the symlink worked (for rebuilding gnome-session sans libxml2 in native-inputs)

<lnnk>I can't install yaru-theme

<lnnk>I ran the command guix install yaru-theme

<lnnk>If this theme is removed then why it is mentioned in https://packages.guix.gnu.org

<lilyp>lnnk pretty sure it still exists, no?

<ngz>mirai: maybe something like (string-append #$(this-package-input "texlive") "/texmf-dist")

<Guest6924>does anyone know how to explicitly allow non-forward updates? guix pull errors out.

<lilyp>allow-downgrade?

<Guest6924>how would you do that?

<lilyp>close enough, --allow-downgrades

<Guest6924>that seems to be working. thanks :)

<lilyp>np

<mirai>ngz: do you happen to know what provides mktexfmt ?

<mirai>dblatex is progressing further now with texlive-bin in inputs but its still missing that

<lilyp>clean-go did nothing

<mirai>lilyp: a distclean perhaps? failing that, maybe try reverting the shared-mime-info and see if its the culprit (odd as that may be)

<mirai>perhaps an indirect culprit? (since changing shared-mime-info does cause a rebuild on gdk-pixbuf)

<lilyp>are you vaguely familiar with the history of the gnome-team branch?

<lilyp>ahh, now I remember, that change is local to the gnome-team branch

<mirai>yea, since it originally lived on gnome.scm (iirc)

<lilyp>can you bisect da24d067d0954cc8f8d75fa9099ad6d8a01e1098..4346c092ea8f1c3084609d3e9173d232bf04af0c for me real quick?

<mirai>lilyp: you're testing with 'guix build gdk-pixbuf' twice right?

<lilyp>just --dry-run

<lilyp>if it gives you different .drvs, that's bad

<nckx>lnnk: If ‘guix install yaru-theme’ fails (it's not clear), we can't help you without the error message.

<nckx>lilyp: Thanks, as always, I hate it :)

<nckx>Not reproducible (heh) here…

<nckx>ACTION yanks.

<nckx>ACTION makes superclean && retries.

<nckx>lilyp: Does this happen only on the gnome-team branch?

<lilyp>as far as I know, yes

<lilyp>it would be weird if we had to rebuild master all the time

<lilyp>it's stable on emacs-team

<nckx>Yes let's keep the breaking of core Guix assumptions confined to branches I don't use 👍

<lilyp>you jest, but I wish more people were using the branch and working on it

<lilyp>right now it feels like a one-girl conceert

<lilyp>s/conceert/concert/

<mirai>what can possibly make a .drv deviate

<lilyp>16a5ce3bb7fbd14fb17a6ba6a62fb079d2379fcc is good

<nckx>Did you compare the (transitive) contents of the .drv?

<nckx>If you have the hardware to throw at git bisect run that's… cool and I'm totally not jealous of a machine that doesn't require babysitting when it's this hot.

<lilyp>My oracle is simply `guix build gdk-pixbuf --dry-run; guix build gdk-pixbuf --dry-run'

<lilyp>well, I do run make on guix itself

<lilyp>no need to clean-go as I just found out

<mirai>the troubles start for me at 0a167432dbccb3ed5b6f27a48b61e570846cf784

<mirai>as to why… still looking into it

<lilyp>okay, so I'd only have to revert the latter two?

<mirai>5539ad8c65a943bfc0cec35dea76d016bcb881fc is ok

<mirai>this is strange

<mirai>diffoscope doesnt give anything interesting either <https://paste.centos.org/view/861e17ec>

<lilyp>hmm, look at your recipe, perhaps you're doing something naughty

<mirai>even sha256sums agree (with exception of pc file)

<mirai>so = ???

<mirai>hmmm

<mirai>well, I've spotted a potential spot of trouble

<mirai>that ungexp'd format call

<mirai>is actually bogus (found out recently)

<mirai>as seen in build log: xdgmime-path : #<package xdgmime@0.0-1.de283fc gnu/packages/freedesktop.scm:475 7fb9f239a630>/bin

<mirai>clearly not good

<mirai>yep

<mirai>put the ungexp on this-package-native-input

<mirai>the derivations now match (with --dry-run)

<lilyp>you know what, I'll actually clean this even harder, but thanks for finding the culprit

<mirai>saturday afternoon mystery solved: <https://paste.centos.org/view/176b4931>

<lilyp>fml

<ngz>mirai: texlive-scripts provides mktexfmt. But I'm not sure why it would need that. It's not supposed to create a TeX format.

<mirai>ngz: I've added texlive-bin and had GUIX_TEXMF wrapped in dblatex (locally) yet this is what I'm seeing <https://paste.centos.org/view/37772fe4>

<mirai>mktexfmt is also in texlive-bin so I don't get it

<ngz>mirai: The error message about "pdflatex.fmt" means you should add `texlive-latex-bin' to the inputs, in the texlive-updmap.cfg call.

<ngz>mirai: (and you don't need texlive-scripts, which is indeed propagated by texlive-bin)

<mirai>ngz: no dice, still complains about the same <https://paste.centos.org/view/694c965d>. I've attached what the current package looks like

<ngz>mirai: I got further by using (,(string-append (getenv "GUIX_TEXMF") ":" texmf)) instead of (,texmf)

<ngz>mirai: Now it seems we're missing texlive-eepic

<mirai>getenv GUIX_TEXMF isn't too pretty though 😅 (as it would make things leak a bit), but that's good news

<ngz>So far, I added texlive-eepic, texlive-times, texlive-pdflscape…

<ngz>mirai: ^

<ngz>texlive-courier…

<ulfvonbe`>what dynamic state are asyncs run with? Just whatever happens to be current, or what was current when sigaction was called, or what?

<ngz>mirai: The following package definition build your example file: <https://paste.debian.net/1289473/>.

<ngz>mirai: Maybe one way to avoid the (getenv "GUIX_TEXMF") would be to loop over the inputs and add all /whatever/share/texmf-dist to GUIX_TEXMF. However, I didn't change the part about GUIX_TEXMF, so rekado may have a better idea.

<ngz>I don't know how to provide, in a simple way, an isolated and fixed texmf tree.

<ngz>But I think GUIX_TEXMF was introduced for that purpose.

<nckx>mirai: Nicely caught (the wobbly FORMAT).

<mirai>ngz: something is odd (without applying your changes yet) when I strace this

<mirai>mktexfmt is gone from texlive-bin (I was doing guix build on an older checkout and it was still present back then)

<ngz>mirai: "kpathsea: Running mktexfmt pdflatex.fmt" means it cannot locate contents of texlive-latex-bin package. Are you sure you're using the definition I pasted? (note that the package name is dblatex-test)

<ngz>mktexfmt is a red herring.

<ngz>It should not be required in dblatex.

<mirai>nckx: you mentioned something along the lines of having localhost in guix offload a while ago?

<mirai>was there any caveat in doing so?

<amjoseph>hi, i'm trying to get an understanding of how guix does certain things, coming from a background with (quite a lot of) nix experience but almost no scheme exposure. in nix we have an eval/build separataion: the packaging language evaluates to a derivation, and derivations do not have access to the packaging language evaluator (well, they do, but that mechanism is called "IFD" and is forbidden in nixpkgs).

<amjoseph>it looks like guix does not have this restriction: search-input-file is an example of something that you can't do in nix without IFD.

<amjoseph>does guix's derivation language allow arbitrary guile expressions?

<amjoseph>nix's derivation language is basically not executable. it's just a list of environment variables and a list with argv[].

<amjoseph>can i do something like (search-input-file ...) and then, say, branch on whether the length of the resulting string is odd or even?

<andreas-e>Hello, amjoseph! I think the answer is that a Guix derivation is an arbitrary Scheme file.

<amjoseph>fascinating!

<andreas-e>I tried this: "guix build hello -d"

<andreas-e>This gives as .drv file.

<andreas-e>Towards the end, I see "/gnu/store/pspxyd64587jq55jhbz3z92j4lnqm857-hello-2.12.1-builder".

<andreas-e>And this is indeed a Guile file.

<amjoseph>oh! i get it. the derivation language is still "just argv[] and envp", but since the "builder" (argv[0]) is often the guile interpreter rather than scheme, it's easy to defer chunks of the packaging language into the derivation. i totally get it now.

<amjoseph>so i guess the fundamental difference that makes this possible in guix is the fact that scheme programs are easy to serialize, and nix programs are basically impossible to serialize.

<amjoseph>s/rather than scheme/rather than bash/

<andreas-e>You probably understand it better than I do ;-)

<amjoseph>i think we each understand different parts of it; thank you so much for sharing your part

<andreas-e>Your explanation sounds good to me. Since we still use the Nix daemon, the "derivation language" must probably be the same one.

<amjoseph>i thought you folks had rewritten nix-daemon? are you using some fork of the C++-language nix 2.3.16?

<andreas-e>In our git repo, there is a subdirectory nix/nix-daemon with a file guix-daemon.cc, and Copyright Eelco Dolstra between 2006 and 2014 (and then Ludovic)...

<amjoseph>ah c2033df432af87d0176347858c7d11acfe2ed89f build: Include a copy of Nix's libstore and daemon

<andreas-e>When you speak of "serialising scheme", this is probably quoting: Considering code as just a list. There is a quoting/unquoting dance (or nowadays, gexping and ungexping) in the package recipes, that distinguishes between Scheme that is compiled into the package object and Scheme that is passed on to the builder.

<mirai>ngz: indeed, with getenv it builds the test file

<mirai>I've dumped GUIX_TEXMF within the build env and after a pipeline of text manipulations, these are the suspects <https://paste.centos.org/view/bbcba458>

<mirai>ngz: some progress though I struggle to understand how this texlive-updmap.cfg works <https://paste.centos.org/view/52d1b24f>

<sneek>wb lilyp!!

<magnumDK>is there anyway to install qemu-guest-agent so proxmox can see guix?

<nckx>magnumDK: See the manual.

<nckx>mirai: I only remember that it didn't work a year or two back, but I'm afraid I don't remember why or whether the problem was trivial or structural.

<nckx>Sorry.

IRC channel logs

2023-08-19.log