<minima>is there any browser add-on for keyboard-navigation that's packaged under guix? i wasn't able to find anything
<dcunit3d>if i'm walking through "direct checkout hacking" section on a guix system, do i need to worry about the --localstatedir or --with-store-dir? i went through this before and I used ./test-tmp for the store path, but i can't recall why
<dcunit3d>minima there is module to build chromium extensions in ./gnu/build/chromium-extension.scm, but only play-to-kodi and ublock-origin are packaged (in ./gnu/packages/browser-extensions.scm)
<jpoiret>sarg: no unfortunately, I've been quite focused on core-updates for now
<jpoiret>i could probably have a look later. I filter my mail depending on whether I'm a direct recipient or not, so if you cc'd the core team it would've ended up in my inbox :)
<sarg>minima: it turned out pretty simple to add a home env to the image, see this patch to guix http://ix.io/4rfY/diff and then the image definition http://ix.io/4rg1/scheme. When you log in for the first time under your user, you need to run `/gnu/store/*-home/activate`
<sarg>guix patch might be not needed if I manage to make a wrapper for `initialize-root-partition`, smth like `(with-home-profile initialize-root-partition %my-home-conf)`
<jpoiret>sarg: to make patch review smoother when I get to it later, could you also describe how you tested that your patch worked?
<jpoiret>although I can imagine just booting via qemu and checking the partition table would be enough :)
<jpoiret>but in general it is good practice to include that information for reviewers, since you usually have it and reviewers don't wanna piece it back together
<sarg>actually I have installed the resulting image to my laptop
<sarg>minima: but getting rid of the manual home activation is not that easy. The code should run after the user is logged in, so it's either that the user's SHELL should be set to some wrapping script or a line should be added to `.bashrc`
<minima>sarg this is brilliant, thanks for sharing it
<sarg>minima are you good with gexps? I can't make the wrapper for `initialize-root-partition` work
<minima>sarg hm, i can more or less follow what a gexps does - but it might take me some time to put a decent one together
<sarg>lilyp: do you know if X-Debbugs-Cc needs to be added to each email sent to `<nnnn>@debbugs.gnu.org` ?
<minima>sarg i'm looking at `initialize-root-partition` in the codebase, what's the idea? to create a version of (or "wrap" around) that so that at some point the home configuration is applied?
<sarg>I think the only important part is `#:profile #$profile` argument to `initialize-root-partition`. It lowers the derivation of `home-configuration` putting it to the store. So the wrapper should just add this argument
<minima>would that avoid the need for the patch above?
<jpoiret>heh, was wondering whether that was gonna error out
<jpoiret>i'm quite close to finally starting the updated Hurd with qemu 🤞
<jpoiret>sarg: wdym run a process from the initrd?
<sarg>well, it mounts root and starts PID 1. Why not start something else as well?
<lechner>Hi, in case any reviewers are around: #62156 passes on x86_64 and aarch64, but has presumably been de-prioritized for the other arches. it adds a new package, and now it's just bit rotting, like so much else
<jpoiret>lechner: any reason you're running autoreconf from a distributed tarball?
<lechner>also, i worked for half a year on the new service presented in #41180, which i use in production. unfortunately, the issue is too old to be eligible for a CI job set, but like the previous package it's an addition that cannot break anything (except, perhaps documentation)
<mirai>it depends on how the tarballs are stored, some are generated on-demand, like github
<mirai>which is bad if they change how they generate it since you're hashing the tarball
<jpoiret>oh no, not autogenerated one, actual upstream releases made by real people who know why releases matter
<lechner>jpoiret / do you have commit privileges? without a committer present, this whole conversation is pointless. besides we are filing the edges of a cabinet that works. this project has come to complete halt
<jpoiret>lechner: I have a couple more remarks though
<mirai>the native-inputs or inputs are mis-indented?
<jpoiret>also you can probably fix the spacing with inputs if you have to do other changes
<jpoiret>also, guix needs more reviewers, not necessarily committers
<lechner>mirai / my emacs does not automatically replace tabs with spaces in scheme. i did not use scheme before switching to guix but it replaces spaces in other languages. i use .dir-locals.el in all my Guile projects
<lechner>jpoiret / actually, i disagree. there is no need to be perfect. we have to keep moving
<jpoiret>I have (setq-default indent-tabs-mode nil) on to avoid that, but it might be overkill if you actually need tabs anywhere else
<ArneBab>Can I somehow make my system use --tune with guix system reconfigure?
<jpoiret>I don't think that option has reached `guix system` yet
<jpoiret>it's probably doable though, but you'll have to build everything locally probably
<lechner>jpoiret / sorry that you were offended. i appreciate your review. it is in the nature of technical projects that most suggestions regard small and often cosmetic changes, which i am personally unlikely to complain about elsewhere
<jpoiret>I disagree though, I think it is natural for a distribution to care a lot about the details of packaging, because in the end that's what it's supposed to do
<jpoiret>yeah, and upstream is often less concerned about compatibility, licenses, security updates, software freedom, etc. than we are
<lechner>jpoiret / i am looking into the license. debian also has it as gpl2+. i could not find the "or later" language in the document i was looking at but am examining
<ArneBab>jpoiret: regarding tarballs: I prefer tarballs over git sources when both are availabe, because tarballs can be cached and provided from other places much more robustly. Also a tarball is usually something where the upstream ran make distcheck — so the tests are verified to have worked on the packaged version.
<lechner>jpoiret / we should be not be behind by eight years or so
<jpoiret>GPL2+ means that the file can be licensed under GPL2 or later, so usually the included license file is GPL2's
<jpoiret>you have to look at file headers to see the "or later" part
<jpoiret>ArneBab: but that means that we are in some way not building from source :)
<jpoiret>it also means that if you want to hack on the project yourself, `guix shell` is not enough, you need to also include all the tools that aren't needed for the tarball build
<ArneBab>if you can see a "or later", in the readme, that’s usually the safest bet. Otherwise you may have to check every file header whether there’s at least one without the "or later" clause …
<ArneBab>jpoiret: whether it’s the source depends on how the tarball is built. Guix shell is an argument against that, though … if you use tarballs, hacking on the project means to unpack the tarball and hack on that.
<jpoiret>ArneBab: but what if you want to hack on upstream's HEAD?
<jpoiret>it's happened a few times to me (guile included :p)
<ArneBab>lechner: I recently got push-privs for Guile to help the lilypond folks, but not for Guix
<jpoiret>packaging for Guix is hard work, and especially with languages and their package managers. It is unfortunate that we were behind, but it's more a problem of personpower than just committers at this point
<ArneBab>jpoiret: I think the hack on HEAD isn’t such a strong argument, because then you’re hacking on unstable code. But checking whether what’s not yet released would fix a problem would be a strong usecase.
<lechner>jpoiret / i believe the matter of git vs tarballs is unsettled inside the project. there is plenty of precedent for tarballs in the source code. i am well aware of the arguments on both sides. it is in that larger perspective that i struggle with the debate here
<lechner>jpoiret / in other projects, i have been admonished for not ending the header line in commit messages with a period
<lechner>i have also been told by groups (in writing!) not to use please or thank you
<ArneBab>lechner: for many packages I’ve had a really good experience with updating the version (I currently run from my local Guix checkout).
<jpoiret>ArneBab: wdym? if you want to contribute to upstream, you should work on HEAD, not on the last release
<ArneBab>jpoiret: that strongly depends on the project. In some projects, HEAD has known bugs, so they prefer patches against the last release where they can more easily verify correctness, while other projects want you to work on head.
<ArneBab>that depends on whether the git HEAD is used as release-tool or as communication tool.
<jpoiret>ah, I've never interacted with such projects then.
<lechner>ArneBab / that's got to be a really large project, though, plus for it to matter you have to work in a buggy area
<ArneBab>github with the rebase-PR-until-tests-pass is pushing strongly towards using HEAD for releases.
<ArneBab>But I think this is currently not making the depate easier (sorry for that).
<jpoiret>unless you're a huge project, i don't think it's a good idea to have patches on the latest release, otherwise as a maintainer you're going to spend much more time rebasing patches for the next release
<jpoiret>better let contributors write proper code in the first place
<ArneBab>There are many cases where that can fail. For example if my current HEAD is using an unstable API, it might not be that simple.
<jpoiret>i can't believe how long the guix package takes to build
<jpoiret>ah, but the main branch shouldn't contain drafts, only things that are accepted and will be included in the next release
<jpoiret>if you have projects that use unstable APIs or things that are subject to change, you shouldn't add them to the main branch. But then again, projects might have different sizes and requirements
<ArneBab>"the main branch shouldn’t" — that depends on project philosophy and branching model.
<ArneBab>There’s the idea that the "next" branch should always be releasable and that "main" should just be the latest release. In that case you’re right.
<lechner>ArneBab / i think most 'release' branches are buggy, too :)
<ArneBab>lechner: … though you don’t need a release-branch if you have actual releases
<ArneBab>In my case, I’ve already caught quite a few bugs in the process of creating releases. Though for Freenet that includes actually running the release and using it to upload the updated sources with the actual new code, so it adds a quite powerful smoke test :-)
<lechner>mirai / what is your preference for the indentation of inputs. mine is inconsistent in atftp. should the list be part of the "inputs" line, or not?
<ArneBab>lechner: what do you think would upstream prefer? Using the tarball or using a commit?
<ArneBab>… I feel like we’re getting sidetracked … again: sorry for that. I just wanted to ask for being careful with assumptions.
<lechner>isn't that what we do, track versions without contents?
<lechner>jpoiret / thanks for the whitespace hints earlier. they are very helpful indeed (although i have to read up on whitespace, as it does strange things to this circe buffer). also, i had accidentally disabled my indent-mode nil in init.el, but i think my indentation issues were not actually related to whitespace
<ArneBab>Somehow yes. But we do track the content of changes we do to those versions (via patches)
<lechner>we have control over those. the issue are changes we do not control
<lechner>ArneBab / none of those questions will matter if we switch to indexing and hashing our own manifests
<lechner>does it not seem like a future-proof way to track what's in the bag?
<lechner>jpoiret / ArneBab / also thank you for the gplv2 "or later" hint. i never noticed it since i worked mostly on original software and most packages I remember included the file snippet with "Ty Coon" in COPYING. i wonder if relegating it to each file is a bad idea because folks often forget to add that header, especially for Makefiles or tests. the gnu project also seems to acknowledge that those are different licenses
<stfnbms>I noticed that the font-sil-gentium package is very outdated: verson 5.00 (October 2014) – the current version is 6.200 (February 2023). The same seems to be th case with the other SIL fonts in Guix.
<stfnbms>I could try to learn how to update the Guix package, but that might take a long time, and presumably somebody else is in charge?
<ArneBab>lechner: I do not see an inherent advantage of having a manifest with hashes of all files over having a hash of a tarball with all files. Though the latter takes much less space.
<lechner>ArneBab / the hashes take the same space. the question is what they were made over. it is not advantageous in my view to also enshrine the compression format or any other part of the delivery scheme into it, but that is what everyone is currently doing
<stfnbms>lechner: That would be wonderful, thank you! How can I be in touch with you outside IRC? I will start by collecting the URLs for the up-to-date font files on the SIL website.
<ArneBab>lechner: at the moment we only verify that upstream did not tamper with the data we download. We do not identify the data with the hash, we just verify to make it tamper-proof.
<lechner>right. too tamper-proof, perhaps, as the recent github issue showed
<ArneBab>lechner: you’d use the hash for identification — which is a different usecase with different requirements.
<ArneBab>lechner: that was recent? I remember such a github issues a few years ago …
<ArneBab>"On January 30, 2023, GitHub deployed a change which slightly altered the compression settings on source code downloads." ← not the first time they did that. Do not use autogenerated tarballs from github …
<mirai>is there a way to retrieve the record-type from a record?
<lechner>my point is that all those delivery formats should come out as equivalent for our fingerprinting
<stfnbms>lechner: Here are the URLs for the three SIL fonts currently in Guix that have new versions:
<ArneBab>But we’re not fingerprinting. We’re verifying the source. Github broke that so this should give an error. They could have done more tampering — like changing timestamps of files which could change which files get rebuilt on running make.
<stfnbms>Did the shell and bootstrap. Get “bash: hostname: command not found”. Installed inetutils and have hostname in normal shell now, but still not in guix shell. Should I skip “guix shell -D guix --pure”?
<stfnbms>Ah, “guix shell -D guix inetutils --pure” did it.
<lechner>also, as an emacs user i would like to encourage you to have a look at Magit. i started using it this year (after several decades of skepticism). you can accept changes by marking them, i.e. no more git add -i
<lechner>guix should present you with the correct hash, which you can then copy (perhaps with embark) and insert into fonts.scm
<stfnbms>It downloaded the right zip file, but then the build failed with a complaint about the hash. Copy the “actual hash” that it gives me into fonts.scm?
<stfnbms>So undo everything and use Github instead?
<lechner>i don't think so, but i am not a reviewer (or have commit access). people here have all kinds of opinion, but being conservative seems to be the most acceptable stance. it's also why i run into trouble a lot
<stfnbms>Okay. Sticking with the SIL zip file as before sounds good.
<lechner>i personally would change it to github. how can you tell that it's not "canonical"?
<stfnbms>Let me run the lint on the other two fonts while you ponder the source and web fonts issue.
<lechner>you now what, for you first submission please keep as is
<rdrg109_>[Q] Is it safe to delete a directory in /var/guix/profiles/per-user with "rm"? I'm asking because I want to delete the directory that was created for a user that I don't use anymore (it is called /var/guix/profiles/per-user/rdrgfoo ) but I don't know if there is a guix tool that would delete that directory and that have side effects in other files.
<lechner>hwpplayer1 / yes, but until recently their repo forking was broken due to go-git. i also find the site harder to navigate than codeberg, but sr.ht is extremely popular with younger folks i think
<ekaitz>in the output of my package there are several libraries and one depends on the other, the validate-runpath phase fails with that, saying one of them is a dependency but it's not in the runpath. Should I just discard the validation or there is a good way to fix it?
<lechner>ekaitz / i think that needs to be fixed. what's the source language, please?
<lechner>ekaitz / are the prerequisites missing from RUNPATH included in any of the package inputs?
<ekaitz>lechner: honestly, i don't even know what the runpath is very well... but the issue it gives is `im` is a dependency of `im_jp2` and both are part of the package
<lechner>ekaitz / RUNPATH is an ELF feature that is used extensively in Guix to ensure that an executable has access to (and only to) it's stated prerequisites (aka "inputs"). i believe the gnu-build-system includes it automatically. otherwise ld.so would not know how to find anything in the store ls -al /usr/lib gives "ls: cannot access '/usr/lib': No such file or directory"
<ekaitz>lechner: but why does the validtion step fail in this package then?
<ekaitz>lechner: /gnu/store/d4z5069a5z9nn4wj2ji52cv60ghkm0ip-im-3.15/lib/libim_jp2.so: error: depends on 'libim.so', which cannot be found in RUNPATH ("/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib" "/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib" "/gnu/store/p7iq81hxxyk9zy7a9dngbf16zm8d4klx-libpng-1.6.37/lib" "/gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11/lib"
<lechner>so, the versioning probably does not matter in Guix because all our paths are separate anyway. i think you are looking at a shortcut upstream made to find its own library that is not obvious to our gnu build system. i am
<lechner>ekaitz / it probably makes no sense to declare package as it's own input, so we have to do something else. i am going to look through the Guix source tree for hints
<sarg>lechner: git clone works, probs sf.net filter by user-agent or something
<sarg>lechner, that's because only git protocol is supported on that host. git makes this request: `GET /p/atftp/code/info/refs?service=git-upload-pack HTTP/1.1`
<Guest74>How can I use git submodules if I use git-fetch for package definition?
<sarg>Guest74 `recursive?` flag in `git-reference`
<Guest74>sarg I tried that but it doesn't do anything. The folders are empty. Going to send whole definition
<Guest74>sarg https://paste.debian.net/1274639/ cm-ryml is the one I need recursive since it has a reference to a cmake script on another git repo. (ignore the copy paste, just wanted it to work for some testing)