IRC channel logs

<nomike>Hi

<nomike>I've been using guix foreign on Ubuntu so far, but just installed guix-system on an old thinkpad. I went through the installer, booted into the new system and ran `guix pull` which gave me the following error:

<nomike>guix pull: error: Git error: cannot redirect from 'git.savannah.gnu.org' to 'https.git.savannah.gnu.org'

<nomike>Any ideas? I didn't do any modifications of the system yes, so that error is quite strange...

<nomike>Meanwhile I figured out, that this is a remnant of the codeberg migration. `guix pull --url=https://codeberg.org/guix/guix.git` works. But that's a very poor out of the box experience IMHO.

<sneek>untrusem: wb!

<untrusem>sneek: botsnack

<sneek>:)

<untrusem>sneek: botsnack

<sneek>:)

<untrusem>sneek: botsnack

<sneek>:)

<sham1>Please don't feed it too much botsnack! It'll make the bot a chonker!

<yarl>hi

<yarl>I have a problem. I am working on https://codeberg.org/guix/guix/pulls/12205 and now I would like to build the installation media and try it. But when I try to build the image with `guix system image`, I have an error because my commits lacks signature. What can I do there to disable authentication (guix system doesn't have such option).

<stampede_>hello

<yarl>hi

<jlicht>yarl: I could sign your commits later today, if that helps. Don't have an actual solution for you either

<yarl>jlicht: ;) ty but the question is more how to test those things locally when you are not a commiter.

<yarl>I think I narowed where the problem is, I will probably open an issue.

<yarl>It's between current-guix-package (gnu packages package-management) and channel-build-system (guix build-system channel).

<Rutherther>yarl: there are couple of options to do what you need

<yarl>Rutherther: I'm all ears!

<Rutherther>the least nasty one is overriding (current-guix) with "#:authenticate? #f"

<Rutherther>I think I should have the code somewhere, give me a sec

<Rutherther>a more nasty one I saw used by noe is overriding the authenticate procedure with a const #t :)

<yarl>Rutherther: Thank you a lot! btw, if that's ok for you, I will include a commit with the amended %installation-initrd-modules in #12205. So this will be modules from #5876 and more. Just to be sure if that's ok for you if I shortcut your PR?

<yarl>I can mention it in the commit message.

<Rutherther>I didn't find the code, but made this now, currently untested apart from evaluation, but I think it should work https://paste.debian.net/hidden/2d2da316. Just replace the "(current-guix)" with this. Or you could make a new file where you parameterize current-guix -- see the release artifact manifest in guix repo for examples of how the installation image current-guix is parameterized

<Rutherther>of course this unfortunately means you do not test the exact code you're submitting to a PR, but I think it's fine approximation as the only thing changed is the authentication... nothing else is, the current-guix is a channel-build-system package, so it can be overriden and arguments changed

<yarl>I'm currently working on 12205, I want to build the image to 1/test those commits, 2/test civodul's hack at https://codeberg.org/guix/guix/issues/7373#issuecomment-26784998 and run system tests and 3/get the correct set of initrd modules. All at one to avoid many many builds/tests

<Rutherther>yarl: I am completely fine with anything like that and no need to ask me in the future -- just treat my code as a donation that I do not really care about, anyone can do anything with it and I do not care even if I am not mentioned as the author. I was unable to finalize that PR mostly because I do not own the board, so it was just to try it

<yarl>right ;)

<Rutherther>btw another possibility for the auth I was considering before becoming a committer (then there was no need for it) was just adding my key to the repository and changing the initial trusted commit for my setup. It's a way for how to make your own guix forks

<Rutherther>(I mean the commit in make-channel-introduction)

<Rutherther>yarl: once you have new pr for rockpro feel free to ping me so I take a quick look + close my PR as superseded

<yarl>sure!

<smartin>Hello, does guix project has some global status of what is reproducible and what's not like https://reproduce.debian.net/ ?

<amrit>smartin: https://guix.gnu.org/manual/1.5.0/en/html_node/Replicating-Guix.html

<amrit>Is this what you're looking for?

<stephen>what do other qutebrowser users do to access codeberg? anyone know why they block *older versions of chrome*? I've been missing out on a lot of stuff because I generally dont browse what's on codeberge I just clone, but now I can't even get to the project pages there

<amrit_>stephen: Change the user agent

<amrit_>After doing that it worked for me

<stephen>huh, yeah, that works, thanks

<untrusem>stephen, you are a emacs user?

<untrusem>then there is forgejo-client

<stephen>untrusem: only for interactively using info pages

<untrusem>that lets me not use browser 80% of the times

<stephen>neovimm has been my editor of choice lately

<untrusem>guix show emacs-fj

<untrusem>stephen, I see

<untrusem>ACTION prepares to kick stephen out

<stephen>I totally get it.

<stephen>Especially in like 30 seconds when I start going off on a rant about the problems with evil mode key bindings.

<stephen>Anyone else under the impression that sway has developed a memory leak recently?

<dariqq>is it possible to create an empty directory with the etc service?

<dariqq>i guess it could be acomputed-file that just creates the #$output

<untrusem>dariqq: what's your usecase for this btw

<untrusem>curiouss

<dariqq>i am writing a service and the daemon complains if the directory does not exist. In theory it is the location of more config files but right now I want to get something working with the minimal things (and the service would need to account for it being empty)

<dariqq>I guess the more future-prove way is union-build

<dariqq>ACTION finally has @reboot cron jobs

<mra>out of curiosity: is the guix command itself managed as a guix package?

<untrusem>mra: do "guix edit guix"

<mra>untrusem: oh, super cool!

<mra>is it included in %base-packages?

<bjc>guix is managed as a package, but the guix profile is its own

<bjc>the guix command has its own generations, distinct from system, home, or ad-hoc

<mra>bjc: hm, interesting. am I correct in thinking that `guix pull` is the command which updates the guix profile?

<untrusem>guix pull updates your guix binary

<bjc>yes, mra

<untrusem>that lives in .config/guix/current

<mra>okay, cool! so it updates all of your channels and then installs the `guix` package from the newly-updated channels to your (new) current guix profile?

<untrusem>yep

<untrusem>you can exclude or just update a single channel too

<mra>untrusem: neat! thanks for clarifying. I guess because the guix package come from the pulled channels, if you want to use some custom version of the guide command you need to define it in its own channel?

<untrusem>guide command?

<mra>untrusem: guix command, sorry

<mra>got autocorrected

<illybytes>so anyone here know a channel that implements a work around for xdg desktop portal not working on gnome?

<illybytes>god i feel like im going insane

<illybytes>i *just* fixed gnupg not taking over as the ssh agent like a fes days ago

<illybytes>why is it broken all of a sudden 😭

<illybytes>few*

<illybytes>nvm, rebooted fixed everything lmfao

<Icy-Thought>stampede_: I don't mean to push you into doing this, but a recent post on r/guix had me wondering if you could perhaps PR the noctalia greeter package you have defined in your repo :X

<Icy-Thought>pretty pls

<stampede_>Icy-Thought: That was always my intention :)

<stampede_>I'm waiting for the noctalia update i PR'd to be merged first

<Icy-Thought>thank you angel!

<stampede_>because it contains a fix for an issue that prevented syncing with the greeter

<Icy-Thought>OH WTF I just noticed you were the one to push the shell update!!

<Icy-Thought>ohhh that is awesome!

<Icy-Thought>Thank you so much for writing the PR and pushing it to guix!!!

<Icy-Thought>review may arrive tomorrow though since time for untrusem is a bit late. :S

<stampede_>oh i just saw the post, wth that's the same laptop i have lol

<Icy-Thought>we all have thinkpads apparently lol

<Icy-Thought>I am very close to making my own r/unixporn post tbh

<Icy-Thought>but I have some minor hickups that are not cool to share :/

<Icy-Thought> https://www.reddit.com/r/unixporn/comments/10n1xok/xmonad_not_satisfied_with_last_rice_retrying/ my very old setup (xmonad)

<stampede_>Honestly i'm pretty light on ricing myself lol, i like to keep things simple and out of the way

<Icy-Thought>My setup is not crazy cool though... I can show you if you want

<Icy-Thought>Or it's aight, I think

<stampede_>Whenever you make the post, you can share the link with me ^^

<Icy-Thought>going to make a small clip to maybe get some suggestions from yall

<Icy-Thought>now where do I share it...

<untrusem>security-fixes my beloathed

<Icy-Thought> https://streamable.com/0g9tft

<Icy-Thought>and he is awake

<Icy-Thought>:O

<Icy-Thought>(didn't show beyond this since qt and gtk are themed in a very odd way)

<stampede_>well lets not hurry him ^^ i already requested rereview so when he gets to it we'll see

<Icy-Thought>I did not mean it in REVIEW THIS NOW way, just that I was surprised to see him around

<stampede_>oh is that a scratchpad animation or smth Icy-Thought

<Icy-Thought>Hehe, it is!

<Icy-Thought>Mango got scratchpad animations just fine

<Icy-Thought>I gotta script what I want to show since that is going to be a alot cooler

<untrusem>ACTION looks at chat history

<untrusem>I will review it later z)

<Icy-Thought>I promise I did not mean to preasure you untrusem :S

<untrusem>haha no worries, if its for you I can get around to it quicker than usual

<Icy-Thought>awww thank you so much <3

<Icy-Thought>Btw remind me, what client are y'all using again (xmpp) since I got rid of jabber and keep forgeting to check web

<untrusem>in the meantime you try to build and test it, so I don't need to do it myselft

<Icy-Thought>sure thing!

<untrusem>Icy-Thought: we should take that to #phi-mu-lambda

<Icy-Thought>Just give me a moment since I am in the process of writing a define-syntax-rule for my config :S

<illybytes>hii, im having a super duper strange issue :p

<illybytes>so, for some reason, opening pika backup kill the graphical session

<illybytes>or thats what i thought

<illybytes>all processes run, and plugging in my external hdd and unplugging it plays the gnome sounds

<illybytes>okay so, this is related to my dex service

<illybytes>oh god dont tell me that pika somehow kills its monitor process, which ends up killing my whole use session for some reason??

<ekatwired>hello, hello, hello. I am dabbling with idea of using Guix on desktop, but the older Mesa version (where Debian Stable backports has even newer ones)… is kinda… eh. Is there any other channel, or plans to actually maintain Mesa more often?

<Icy-Thought>I just realized mesa is old

<Icy-Thought>bro change your name I keep pinging you by accident...

<ekatwired>who? (i do not see history, ofc)

<Icy-Thought>not you :P, there is a user so called o l d without spaces

<Icy-Thought>I keep saying that word and keep pinging them

<ekatwired>lel

<Icy-Thought>TBH we need a reminder bot or something to tell us about outdated stuff... or something like ryan-tm

<Icy-Thought>(nix bot to update packages)

<Icy-Thought> https://codeberg.org/guix/guix/pulls/9335 apparently

<ekatwired>I think I will need to package BIRD 3 :p

<vagrantc>stuff that triggers lots of rebuilds often takes a long time to update ... it is quite possibly on one of the in-progress branches

<Icy-Thought>ahh that makes sense!

<ekatwired>I wanna start with servers, so I will have to package probably everything I use on my server lel. Thought of moving to Nix but Guix seems much cooler :p

<vagrantc>mesa-updates branch unsurprisingly has a more recent version

<ekatwired>mesa-updates is branch of Guix packages?

<Icy-Thought>as someone who recently migrated from nix, you benefit from having a lot of packages but then language is... not fun

<Icy-Thought>but then, you can always use nix packages in guix (iirc)

<bjc>heh. mostly i hear the reverse

<bjc>nix has a lot of packages, but the language is not fun

<Icy-Thought>that is what I said, no? :O

<bjc>oh, then i misread, sorry

<ekatwired>I know NixOS, i managed some Nix servers in the past.

<Icy-Thought>no worries bjc xD

<bjc>and i am less surprised

<ekatwired>I find the language okay, but it ain't Scheme (my beloved)

<vagrantc>guix refresh --list-dependent mesa

<vagrantc>Building the following 3043 packages would ensure 6548 dependent packages are rebuilt: compton@0.1beta2 ...

<Icy-Thought>The thing that _sucks_ with guix is, dated packages + missing packages (but those we are taking care of slowly ;) )

<Icy-Thought>vagrantc: dayum...

<Icy-Thought>now is tal a runescape player... I wonder

<Icy-Thought>or was that telos... I forgot

<Icy-Thought>here is a question, would you rather define-syntax-rule for easier writing or just write the damn lines? I have some (local-file (string-append my/dotfiles-dir "bla"))

<Icy-Thought>syntax rule would make it into (my/config-file "bla")

<ekatwired>Many desktop apps packages missing can be substitued with Flatpaks

<Icy-Thought>most of them do indeed have flatpaks, so that is solvable, but I'd rather guix native them than use additional packages for same stuff... idk

<ekatwired>Ngl same if I could sandbox them

<ekatwired>There is Nixpak for Nix which does bwrap

<ekatwired>Ngl it would be funny to make a thing based on landlock or something

<ekatwired>Also for Shepherd. Systemd is weirdly enough lacking landlock support and surprisingly even the awful OpenWrt systemd larp has it.

<Icy-Thought>hmmmmm... idk thb

<Icy-Thought>systemd is too much of a lot of things...

<Icy-Thought>I wonder why they just keep spamming new stuff

<ekatwired>i mean the service manager

<Icy-Thought>it is not a system service manager anymore, it is soon a kernel too

<Icy-Thought>lol

<Icy-Thought>did y'all see their new age verification service?

<ekatwired>It is the irony that systemd has so many things but missing landlock support in service manager

<tusharhero-xmpp>Icy-Thought: why macro when procedure do trick?

<ekatwired>They have age verification service? I thought they just add "age" field in the user database thingee.

<Icy-Thought>procedure how? show me xD tusharhero-xmpp

<Icy-Thought>also hi there :)

<Icy-Thought>let me check... I may have twsited it in my head ekatwired

<ekatwired>tbh it has been twisted around the intarwebs

<tusharhero-xmpp>(define (my/config-file name) (local-file (string-append my/doffilss-dir name)))

<Icy-Thought>yup it was brithday sorry, you were right! ekatwired

<Icy-Thought>because then you need recursive too

<Icy-Thought>or I gues args ...

<tusharhero-xmpp>This procedure should work right? Icy-Thought

<Icy-Thought>It should, but I wonder how it would handle something like (define (example args ...)) for something like #:recursive #t to work

<Icy-Thought>or the remaining args in the (define-record-type <local-file>

<tusharhero-xmpp>You add a \*, so define*

<tusharhero-xmpp>Look it up in the guile manual

<Icy-Thought>It should accept args ... without having to define them?

<Icy-Thought>Because syntax rule allows that iirc

<tusharhero-xmpp>Oh you mean like that

<Icy-Thought>yup

<Icy-Thought>Easier than redefining the whole damn thing

<tusharhero-xmpp>I thought you wanted to add your own keywords

<ekatwired>I guess it wouldn't be that hard to implement some sandboxing in shepherd...

<Icy-Thought>nope

<Icy-Thought>I wanted to shorten the typing xD

<tusharhero-xmpp>Icy-Thought: tbf do you really need to do everything. I would suggest only adding what you need

<Icy-Thought>guess i am having too much fun that I am accidentally making my own dsl... lol

<Icy-Thought>Good reminder tushar

<tusharhero-xmpp>Icy-Thought: yeah it is alluring

<Icy-Thought>I should spend more time reading david knuths book or something!

<ekatwired>if a DSL is so good, why there is no VDSL

<untrusem>btw "ol d" is a guile developer :) we owe them alot

<ekatwired>Yes! yes! Guile <3

<Icy-Thought>And now I fear i should not write that word... :S

<Icy-Thought>please change your name love

<Icy-Thought>xD

<ekatwired>we can use »ancient«

<Icy-Thought>oh well

<Icy-Thought>old-is-gold

<Icy-Thought>alright going to sleep... cannot handle it anymore

<Icy-Thought>good night folks <3

<mra>is the recommended way to add a channel globally to add it to /etc/guix/channels.scm, or to customize the system-wide guixas described here: https://guix.gnu.org/manual/devel/en/html_node/Customizing-the-System_002dWide-Guix.html

<gnufairy>I would think its best to add it to your system config.scm so that you can just carry one file around

<stampede_>i would say channels.scm tbh, that's what i'm doing

<stampede_>also you can put it in ~/.config/guix/channels.scm

<stampede_>so that you can edit it without sudo

<gnufairy>I know how to use sudo, but is it possible to delete doas from %base-packages?

<gnufairy>*know how to use doas

<mra>stampede_: yes, but I'm talking about installing a channel globally, so it wouldn't go in ~/.config/guix/channels.scm, would it?

<mra>isn't that for user-specific channels?

<stampede_>ah that's what you meant, nvm me

<ieure>mra, I recommend the approach of the docs you linked.

<ieure>mra, The (atomized tranforms-ng) module in my channel has a transformer to help do this: https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/transforms-ng.scm#L479

<ieure>I find `modify-services' cumbersome.

<ieure>The linked function is a transform constructor, it returns a procedure, applying an operating-system to it adds the channels, ex. (define add-my-channel (xf/add-channels* (channel ...))) (add-my-channel (operating-system ...))

<mra>ieure: oh, awesome! I think that customizing the guix is also convenient for me because I should be able to tweak the underlying package to include hako's patches for zfs, I think

<ieure>mra, This doesn't let you replace the guix, only configure the one which is there.

<ieure>You're welcome to submit a patch to do that, though, if you like.

<ieure>I like my transform stuff, the new facility that just landed doesn't feel right to me. Seems strange that the transformer is a part of the thing being transformed.

<mra>ieure: does it not let you? my understanding was that using modify-services I should be able to edit the guix package used by guix-service-type

<ieure>mra, modify-services will let you, my transforms will not.

<mra>oh, you meant a pull request to your repo, gotcha

<ieure>Yes.

<illybytes>hmm,, so im trying to fix my binary package def of gram that i copied from a weirdo's codeberg, and im trying to see how to fix extensions not working at all, rn im missing rustlib for wasm32-wasip2

<illybytes>anyone got an an idea of how i would go about doing that?

<ekaitz>hi! do we have any requirements on the structure of the "out" directory of the buildsystem?

<ekaitz>does it "need" to be out/bin out/lib and such? or can each of the build system define the way it's done?

<bjc>i don't think there's any strict requirement. it depends on what your needs are

<bjc>for stuff to be executed by the user out/bin makes sense

<bjc>but i have things that go in other directories to be picked up by other tools, like udev

<ekaitz>we have a tricky case with prefixes and it would do some: out/gnu/store.../bin

<bjc>sorry, i was using shorthand for the not-much-shorter $#out

<ekaitz>it's not that we wouldn't follow bin, lib and such, but that we'd add the whole output directory there

<ekaitz>i'm talking the output of the `build` step, not after installation

<bjc>i dunno then. i would imagine that depends entirely on the requirements of the build system or whatever you use

<ekaitz>that's also what I would imagine

<bjc>i haven't seen anything in the docs about it that i recall

<ekaitz>me neither, but I just wanted to make sure. Maybe we just wanted to have something short and flat for readability

<ekaitz>this zig-build-system is a little bit annoying... they don't have any separate configure-build-install step

<bjc>there's no $prefix concept?

<ekaitz>yes

<bjc>that seems wild in this day and age

<ekaitz>bjc: if I `DESTDIR=out zig build --prefix /gnu/store...` it does `out/gnu/store.../bin`

<bjc>oof

<nckx>Isn't that how it always works?

<bjc>no, typically the out directory is in the workdir and just gets copied to the store

<bjc>but maybe i'm misunderstanding you

<nckx>Maybe.

<bjc>hrm. now i'm confused too

<ekaitz>i had a misunderstanding with some zig people and got a not-very-nice answer

<nckx>Using DESTDIR is generally a packaging mistake, so ‘it does weird things’ is not itself surprising.

<bjc>the build system definitely sets --prefix=/gnu/store/... for gnu build

<ekaitz>ACTION doesn't want to trigger another not-very-nice answer

<bjc>but my recollection is that the workdir only contains “out/bin” or whatever

<ekaitz>bjc: that's what I think, too

<bjc>not “out/gnu/store/.../bin”

<ekaitz>exactly

<ekaitz>i mean, let's try

<bjc>yeah

<bjc>i don't have my guix system up right now to test so i'm of limited use

<nckx>ACTION confused now too. It's spreading. 🦇

<ekaitz>i'll do it and tell you

<nckx>If were to set DESTDIR=/out prefix=/gnu/store/foo in any (sane) build system, I would expect it to produce /out/gnu/store/foo.

<ekaitz>let's see

<ekaitz>now guix shell is installing the world :S

<nckx>Faites vos jeux.

<ekaitz>--prefix=/gnu/store/j6bcg81ns5x0byb6abv9p4228z1bflf4-hello-2.12.3

<ekaitz>oh

<ekaitz>hehe

<ekaitz>hello is in the root folder

<bjc>what do you mean by “root”?

<ekaitz>of the build dir

<bjc>ACTION blinks

<ekaitz>what I did is to make the install phase to fail

<ekaitz>i guess what I need is to fail after install?

<ekaitz>to see what happens there

<bjc>yeah, install is just the “make install” phase, i think

<bjc>so it'd have to run to get it into the right place for the rest of guix to pick it up

<ekaitz>DESTDIR=HELLO make install

<ekaitz>ls HELLO/gnu/store/irpdzwda7lp8hqzpk8658f0pxs827vn4-hello-2.12.3/

<ekaitz>that run

<graywolf>afaiui DESTDIR is just a base directory to copy into during `make install'.

<ekaitz>yes

<ekaitz>that's it

<ekaitz>let me do it the other way around

<nckx>It's a temporary staging directory, for other types of distributions, so it's not really relevant to Guix.

<nckx>Backing up: why do you need(?) to set DESTDIR at all? The only time it's ever used in Guix is to work around buggy upstreams AFAIK.

<nckx>Upstreams that didn't understand they meant PREFIX.

<ekaitz>the thing here is zig doesn't separate phases really

<ekaitz>their `zig build` is a install that installs things locally

<ekaitz>like DESTDIR=zig-out make install would

<graywolf>In Guix not often I would expect, since --prefix is where you want to install. In other distros, it is used often.

<ekaitz>doing `zig build` makes a `zig-out/usr/bin...` directory in the current folder

<graywolf>Why? :-O

<ekaitz>if you change the --prefix it changes the 'usr/' part

<nckx>This is all ‘normal’…

<ekaitz>if you change 'DESTDIR' it goes to somewhere else

<nckx>Yes.

<vagrantc>anyone have an easy example for how to add a phase that fails the build ? I tried adding a phase with (lambda _ #f) ... but that failed to fail :)

<ekaitz>vagrantc: (lambda _ (error "DIEEEE"))

<vagrantc>ekaitz: thanks!

<ekaitz>nckx: the thing is we have separate build and install steps

<ekaitz>we could merge them, (could we?)

<nckx>Conventionally. Every build system can define whatever phases it wants.

<nckx>Guix itself doesn't really care.

<ekaitz>let's do just one then configure-build-install

<ekaitz>because that's what zig expects

<ekaitz>that would mean just saying the right prefix and let zig install its shit

<bjc>vagrantc: (exit 1)

<ekaitz>because it was done in two steps and that was causing trouble

<nckx>Or have 'build install into ./zig-out, then have 'install copy ./zig-out to / (assuming it contains only a single gnu/store/xxx directory), if you really want to split them.

<vagrantc>bjc: also thanks :)

<ekaitz>nckx: that's what we were doing, but then some package uses pkg-config and pc files need to have their absolute paths, that are taken from the --prefix

<bjc>sorry, i didn't see ekaitz' response first. so you can enjoy some redundancy =)

<nckx>The standard rule is: a programme built with ‘DESTDIR=/foo prefix=/usr’ will install itself into /foo/usr, but it *expects* (and might include code that assumes) to be run from /usr. The ‘/foo’ is a ‘staging directory’ that fits into the way some distributions build and tar up packages. It has no use in Guix.

<nckx>Yes, prefix is all that matters.

<bjc>yeah, destdir is for chroot or things like that

<ekaitz>in summary, there was a guide the author of the package wrote that was misleading me

<ekaitz>explaining how to split the steps

<ekaitz>so I thought: let's do that!

<nckx>ekaitz: No, if prefix is set correctly (to /gnu/store/foo) then pkg-config et al will have no problems.

<nckx>Yeah.

<ekaitz>let's merge phases and call it a day

<nckx>I was just about to suggest this sounds like you got bad advice without knowing it was bad (substitute ‘bad’ for ‘misleading’ if feeling charitable).

<bjc>sounds good to me

<ekaitz>ACTION now has to review all zig packages

<ekaitz>(:

<ekaitz>nckx: the funny thing is i told the dude his guide was wrong, and he saw no issue with it

<ekaitz>i don't know... sometimes...

<nckx>‘It worked for me on $distro!’

<nckx>DESTDIR and prefix are widely misunderstood TBH.

<ekaitz>he got me with a not-very-polite answer

<ekaitz>and... ugh

<ekaitz>affected me a little

<ekaitz>ACTION was off guard

<nckx>As I hinted above, there *are* a few packages in Guix that work around an upstream confusion. So we do use DESTDIR sometimes but it should not be normal.

<ekaitz>now it is understood

<ekaitz>because people ACTUALLY cared to listen

<ekaitz>thank you

<nckx>ACTION hands ekaitz some of their hot chocolate, sorry to hear that.

<bjc>tempers are so short these days

<bjc>i fly off the handle over nothing, and i don't like it

<ekaitz>also, it's hard for me sometimes to explain my concerns in english, specially when there's context needed and i'm on a chat

<bjc>takes some real willpower sometimes to extend grace

<ekaitz>and its very frustrating

<bjc>not the same thing, but i switched keyboard layouts a few years back, and oh man that was soooo frustrating

<ekaitz>haha

<bjc>i couldn't say anything

<ekaitz>so fellow guixers can enjoy "embrace the inherent complexity in your lovely packaging system :P "

<ekaitz>and that wasn't the best ;)

<nckx>Are you quoting them?

<bjc>i find nix/guix conceptually simple. more than other packaging systems, anyway

<nckx>That's ironic since our method is the simpler from a package point of view. prefix is where you install, prefix is where you run, that's literally it.

<bjc>the code isn't, necessarily, but the logic is clean

<ekaitz>yep

<ekaitz>i mean, it was surely me not explaining my concern properly

<ekaitz>but I don't think that's a proper answer to anyone trying to: 1) package software written in the programming language you take part on and 2) specifically the project you wrote

<ekaitz>or anyone in general

<nckx>I guess people see /gnu/store/xxx instead of /usr/local and assume it implies added complexity when it's literally the same pattern.

<bjc>the big blob of hex doesn't help

<nckx>?

<bjc>in the store

<nckx>Ah.

<bjc>actually, is that hex? or like base32 or?

<nckx>(And it's not even hex…)

<nckx>It's not even base32!

<bjc>heh. yep

<ekaitz> https://github.com/riverwm/river/blob/main/PACKAGING.md#build-prefix-and-destdir <-- that's the guide

<ekaitz>am I right to say that if you then copy the file to a directory that is not /usr the thing may not work?

<ekaitz>i'm just trying to make sure I understand things properly

<nckx>ekaitz: No more or less than any other random package? Many packages include references to their own prefix, e.g., like you said, pkg-config files.

<ekaitz>nckx: the package that wrote that guide does have pc files

<nckx>I didn't read the rest but what the author writes in that section does sound quite sane.

<ekaitz>wouldn't the pc files get their paths set wrong?

<ekaitz>(this is the issue we had with the package)

<nckx>…no? If you set prefix to the correct /gnu/store/… i.e. #$output.

<ekaitz>but i mean from the examples there: --prefix /usr and then cp to /desired/install/location

<nckx>That is not what they suggest.

<nckx>I think.

<nckx>Maybe I am giving them too much credit.

<ekaitz>shouldn't it be --prefix /desired/install/location and then cp to /desired/install/location?

<nckx>Yeah, or cp -r /tmp/river-destdir/* /usr, which is what I was just typing.

<ekaitz>there you go

<ekaitz>i thought i was crazy

<nckx>I kind of glossed over that as an ‘obviously they meant /usr’ but if they insist that they don't, I don't know what to say. They are just wrong.

<ekaitz>no, he just said that's just an example

<nckx>Absolutely nothing to do with Guix either.

<ekaitz>it had to do with guix because i followed this guide years back to write the zig-build-system

<ekaitz>and i thought it was interesting to separate the phases, to make it more similar to the gnu-build-system, which is the most common

<nckx>No, I just mean, this is not Guix imposing some extra rule that they don't agree with, these are the general rules for all of Unixdom.

<nckx>Sure.

<ekaitz>yeah sure

<ekaitz>it's just it misled me

<ekaitz>and now here we are

<ekaitz>:)

<ekaitz>now we are talking... how should I test this?

<ekaitz>i mean, the test phase

<ekaitz>after installing?

<ekaitz>:S

<ekaitz>the "check" phase, i mean

<nckx>This is also just convention. The default is to 'check before 'install but some Guix packages move the 'check phase after 'install if the package really doesn't like being tested otherwise.

<ekaitz>okay! thanks a lot

<ekaitz>let's do that then

<nckx>Either way, it's not like Guix will leave half-installed packages around if the tests fail.

<ekaitz>yeah, but it ~feels weird~

<nckx>I think at this point it's more important that you get a working package, then you can still try to cross the i's at your leisure if it really bugs you. And you'll have a known-good reference point to return to.

<nckx>The other way 'round can be demotivating and it sounds like you're already close to that.

<ekaitz>:)

<ekaitz>it has been a loooong week

<ekaitz>thanks for the support

<ekaitz>ACTION is building the thing

<ekaitz>it works

<c2e>yay

<ekaitz>ACTION has to update every usage of 'build and 'install names in zig packages :S

<ekaitz>or do something very clever

IRC channel logs

2026-10-31.log