IRC channel logs

<mgd>does anyone know which texlive package contains pdflatex? I'm trying to export an org file to pdf

<ngz>mgd: pdflatex is not sufficient to compile a TeX file

<ngz>mgd: I think you need texlive-collection-latexrecommended, and possibly a couple other packages, depending on your Org file.

<ngz>To answer your initial question, `texlive-bin' does provide `pdflatex' executable, but as pointed out, installing it will do you no good.

<s777>Hello, this is my first time contributing to Guix and I'm trying to package Typst, but right now I'm trying to figure out the licensing since some Rust crates that it depends on (specifically icu_collections and other libraries beginning with icu_*) specifies "Unicode-3.0" as the license, which I think is equivalent to "Unicode-DFS-2015" although not sure. Currently in guix/licenses there is

<s777>"unicode" which points to https://directory.fsf.org/wiki/License:Unicode which redirects to License:Unicode-DFS-2012, and there is one package in crates-io.scm using this license, but crates.io says it is "Unicode-DFS-2016". So I'm not sure what to put for the license of these crates, should I just do license:unicode?

<m4xxed>Hey folks, does anyone know whether I can use `modify-services` to extend the value of a parameter in a service instead of overwriting it? I am trying to extend a bash-home-configuration's aliases field by inheriting from the old config and then adding additional aliases to the values of the already existing aliases value.

<adanska>the `guile-emacs` package doesnt seem to be maintained anymore, and doesnt build either. the repo it pulls from doesnt seem to be hosted either, though i can find it on SWH.

<adanska>might be a good idea to remove it.

<janneke>adanska: apparently the URL changed to https://git.hcoop.net/bpt/emacs.git

<janneke>...and also ./pre-inst-env guix build --source guile-emacs works for me...

<adanska>interesting.

<adanska>still, it appears unmaintained

<jakef>when i add the guix-science-nonfree channel to my channels.scm and guix pull, i also get the channels guix-science and guix-past. is this a bug?

<adanska>im submitting a patch series to remove it

<adanska>no

<adanska>they are dependent channels

<jakef>adanska: interesting! thanks

<janneke>adanska: it would be a pity to see this removed!

<adanska>janneke: really? hmm. this package doesn't seem to be getting much love from upstream or downstream - i wonder if its worth keeping. but if you think its worth keeping, maybe you could send some patches updating it?

<janneke>adanska: yes, i'm looking into it

<adanska>janneke: okay! ill send a message to the debbugs issue once i get an issue number back explaining this :)

<s777>Hello, this is my first time packaging something for Guix and I'm trying to package Typst, but I have a few questions. First, I'm confused about the licensing regarding some of its dependencies on crates.io, which are licensed as "Unicode-3.0" (specifically the ones beginning with icu_*). Guix has "licenses:unicode" as an option, which has a URL pointing to

<s777> https://directory.fsf.org/wiki/License:Unicode which redirects to "License:Unicode-DFS-2012". However, the one package I saw on gnu/packages/crates-io.scm which uses it is licensed as "Unicode-DFS-2016", and I think "Unicode-3.0" is equivalent to "Unicode-DFS-2015", so I'm not sure if I need to add a new entry or if I should just use "license:unicode" for them.

<s777>2. The package file I generated with "guix import" is 2000+ lines long and I'm not sure which files each dependency needs to go in (I'm assuming gnu/packages/crates-*.scm but I don't know which crates-*.scm file they should go in.

<s777>3. Considering the amount of dependencies should I commit to master branch or a different branch?

<s777>4. Do I need to remove "skip-build" for all of the dependencies (which was automatically inserted)?

<adanska>man debbugs takes a while to respond with an issue number huh

<janneke>adanska: no promises just yet

<adanska>janneke: sure! ill submit the patches and send a follow up message saying that you might be working on an update patch

<adanska>let me know if you end up not bothering

<janneke>danderson: thanks, will do

<adanska>janneke: the issue is 71989 :)

<janneke>adanska: check

<janneke>...still building...

<civodul>Hello Guix!

<janneke>o/

<adanska>hi civodul! :-)

<theesm>g'day o/

<ngz>s777_ Handling dependencies in Rust packages is _very_ tedious. If you update pre-existing libraries from "crates-io.scm", I think the best way forward is to push these updates to "rust-team" branch, if efraim is OK with that. You should try hard to remove "#:skip-builds #t" from the importer, too, which means there's possibly a lot more work to do… Good luck!

<ngz>Hmm bordeaux farm seems to be asleep. Also, there are 10k blockeds commits in i686. How can one inspect that (links from <https://qa.guix.gnu.org/branch/core-updates> are broken)?

<ngz>blocked*

<cbaines>ngz, you can use the blocking builds page from the data service https://data.qa.guix.gnu.org/revision/e4da066f0029ef38f6a791f6f9d4cfdb8b39b6a3/blocking-builds?system=i686-linux&target=none&limit_results=50

<ngz>cbaines: Thanks! Where do you find that page ? From <https://data.qa.guix.gnu.org/revision/e4da066f0029ef38f6a791f6f9d4cfdb8b39b6a3>, I get to package derivations, which lets me see failing packages, but not blocked ones.

<cbaines>it's not linked to yet, it's mostly working but there are still things that show up that shouldn't

<ngz>Ok. So I'm not as blind as I thought.

<cbaines>the libfaketime issue was mentioned here https://issues.guix.gnu.org/70456#28

<ngz>I think Andreas just fixed it, didn't he?

<cbaines>I haven't seen anything, have you got a link ngz ?

<ngz>cbaines: Ah nevermind. He fixed librewolf. The libfaketime fix is yours.

<cbaines>I'm really not sure what to do with libfaketime, I'm not exactly sure what the problem is and it's only a big deal for us because we're using it in some package tests

<civodul>BTW, ci.guix is getting better (in large part thanks to cbaines) though i’ve accumulated a bunch of fixes/improvements

<civodul>i’ll send an update hopefully today or tomorrow

<cbaines>the least worst idea I've come up with is https://issues.guix.gnu.org/71993

<ngz>cbaines: What happens if you simply skip the failing test?

<civodul>if we don’t use libfaketime for the tests of nss & co., then those tests will fail in the near future due to time traps

<civodul>we’re between a rock and a hard place!

<ngz>civodul: I was suggesting to skip the failing test for libfaketime (i.e., check if the program is working properly on i686, independently on the test).

<civodul>ngz: ah yes, though it might need investigation and working with upstream to make sure it’s not fully “broken”

<civodul>(i haven’t checked)

<ngz>From my x86_64 computer, calling faketime "2" date +'%s' returns 1720396800, but the test expects 2. Though the test is apparently correct on this system. Hmmm.

<futurile>Morning all

<civodul>hey, futurile

<ngz>What would be the command to test cross-compiling libfaketime from a x86-64 system to i686-linux-gnu?

<ngz>Ah. --target=i686-linux-gnu. Duh.

<pjals>Hello! I'm making a package and I'm trying to make a phase that sources a script that sets a bunch of environment variables and then prints all of them out with env. I'm coming across an interesting issue where when importing (rnrs io ports) into the phase, (port) is available but (get-string-all) is not. The relevant snippet (not the entire package, the freeness of it is dubious) is available here:

<pjals> https://paste.debian.net/1322655/

<ngz>pjals: Have you tried with (ice-9 textual-ports) instead?

<pjals>I think I've tried, gonna try again.

<pjals>Yea, doesn't work, prints the same error.. (expected, it isn't a re-export or anything). It does print the warning "importing module (ice-9 textual-ports) from the host" quite some times from various places around guix/build-system/meson.scm.

<s777_>ngz: I just removed all of the #:skip-build and running "guix package -f file.scm" to build typst still works so I'm guessing all of them built successfully?

<ngz>s777_ Nope. That would be too easy.

<s777_>ngz: oh ok so I need to test every package

<ngz>s777_ In fact, typst doesn't care if Cargo inputs build or not, since it just uses them as source.

<ngz>s777_ But, in Guix, we insist that every intermediate input should also build, if only to make sure tests pass and so on. It wasn't always the case, hence the #:skip-build? keyword, but it is the current state of affairs.

<ngz>s777_: So, yes, you need to test every package (sorry).

<ngz>pjals: Sorry, that was my best shot =/

<s777_>ngz: The wiki says "The guix build command builds packages or derivations and their dependencies, and prints the resulting store paths." and I remember seeing a bunch of "building" CLI output when running the guix package command

<ngz>Yes, but Cargo inputs are not regular inputs (listed in the `inputs' field). They are listed in the `#:cargo-inputs' keyword within `arguments'.

<ngz>`cargo-build-system' is a somewhat irregular build system.

<s777_>ngz: oh ok so does that mean there isn't a way to test all of them at once?

<s777_>the file is like 2500 lines long

<jab>how does one go about adding themselves to a guix team ?

<s777_>I just replaced the typst package with a random library and the build is failing, I see the problem now

<ngz>s777_: There is certainly a way to build every Rust package in the file, but I don't know it.

<ngz>jab: Just ask on the ML (or, if you have commit access, add yourself to the "teams.scm" module)

<pjals>Couldn't you just do a for-each on all of the exported symbols of the file?

<jab>ngz: which mailing list should I use for that I wonder?

<jab>probably not guix-devel

<ngz>jab: Devel seems fine to me.

<pjals>ngz, s777_: You can in fact iterate over every variable (including packages) a module exports: (module-map (lambda (x variable) #! Do things with variable, not sure what x is. You can dereference it with variable-ref to get the actual variable. This will contain other garbage so do a check with package? !# ) (resolve-module '(gnu packages your-module)))

<pjals>This interface is strangely undocumented (like all the other hacky reflection stuff in Guile).

<rhuijzer>Hi! I'm still trying to use my hostname as a var in the file path of my home-files-service-type. This works (local-file "./files/nvim/init.vim"), but when I use (string-append) as the input for local-file it is suddenly expecting an absolute path because of the computed value. So I used (local-file (string-append (car %load-path) "/sway/screen/" (gethostname))))

<rhuijzer>That results in "ERROR: In procedure %resolve-variable:

<rhuijzer>Unbound variable: local-file

<rhuijzer>"

<rhuijzer>Does someone have an idee how to proceed? \

<abbe>rhuijzer: local-file is not a function, but a syntax object, so it's special

<abbe>my guix-fu is not good, but maybe you can figure out from: guix/gexp.scm

<rhuijzer>hmm okey tnx, will look into it

<gabber>how can i figure out which profile references a specific entry of a package (so i can resolve a reconfiguration conflict)?

<Deltafire>gabber: try guix gc --referrers <store path>

<gabber>Deltafire: thanks!

<gabber>hmmm.. so one of the conflicting paths shows some profiles (e.g. my home profile) the other one only shows packages. how come guix tries to create a profile containing both versions?

<gabber>should i delete my home profile and only then try to (re-)configure that?

<gabber>i honestly have no idea how to resolve this issue and it's been bugging me for quite a while

<civodul>oh, the hash mismatch for Git is back: https://ci.guix.gnu.org/build/5017919/log

<civodul>might be an issue when rebasing

<attila_lendvai>a simple package update patch: https://issues.guix.gnu.org/71810

<attila_lendvai>*leaf package

<vagrantc>any suggestions how to improve this guix.scm file? https://salsa.debian.org/reproducible-builds/notveryreproducible/-/blob/main/guix.scm?ref_type=heads

<vagrantc>in particular, i am not sure why i had to workaround the install target

<vagrantc>also, is there a "domainname" command in guix, or something similar?

<yelninei>vagrantc: I think DESTDIR is unset and thus the files get "installed" in the build directory. Can't really help you with the other things

<vagrantc>yelninei: thanks!

<vagrantc>so maybe setting DESTDIR to "out" or something ...

<ieure>vagrantc, Yeah, that's typical for non-autotools-based stuff.

<ieure>Autotools projects get a --prefix arg automatically set to the output dir by gnu-build-system, if they don't respect that, it's a bug.

<ieure>(with the project)

<efraim>we normally have PREFIX and don't set DESTDIR

<efraim>vagrantc: ah, i see. don't forget to substitute out /usr in the Makefile

<efraim>I think that would bother me more than DESTDIR vs PREFIX

<vagrantc>hrm. still struggling to get it to install anything anywhwere the package actually uses it

<vagrantc>ah, maybe it needs to be a makeflag rahter than an environment variable?

<efraim>DESTDIR as a make-flag should work

<vagrantc> #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs "out"))) ... which looks like what is in the manual ... does not seem to work

<vagrantc>error: %outputs: unbound variable

<ieure>vagrantc, You need a gexp, #~(list ... #$output)

<ieure>vagrantc, Can almost guarantee there's prior art in some package if you want to grep DESTDIR in gnu/packages in the Guix repo.

<vagrantc>i see lots of examples, but my skills at adapting them appear to fall short

<vagrantc>ieure: wow. that works ... there are lots of examples of the other syntax too ... but no clue why both exist but only one works in my case.

<ieure>vagrantc, There's a lot of pre-gexp package definitions in Guix still.

<vagrantc>sure ... but ... how does those even still work ...

<ieure>vagrantc, Not sure what you were cribbing from, but likely the whole argument list which #:make-flags is a part of is quasiquoted.

<vagrantc>just looking at the package definitions for the gexp vs. non-gexp ones that try to pass some make-flags arguments with the output directory

<ieure>ex: (arguments `(... #:make-flags (list ...)))

<vagrantc>yes, i have never wrapped my head around the various forms of quoting

<vagrantc>i just see a bunch of magic characters and my eyes glaze over :)

<ieure>Pretty important thing to know if you're going to be hacking lisp. Would you like a five0minute explainer?

<ieure>*five-minute

<vagrantc>i am already a bit too far into various rabbit holes ... and the last 7 five minute explainers of this sort of stuff never managed to sink in :)

<vagrantc>let's just say i like guix despite lisp, not because of it :)

<ieure>Fair enough. I will just urge you to spend some time figuring it out, then. IMO, really helps to read an explanation and try things out in the REPL as you do.

<madeleine-sydney>is `gnu/packages/crates-graphics` an appropriate home for a library concerned with rendering graphs to plain text?

IRC channel logs

2024-07-08.log