IRC channel logs

<nouun>Is there a way to get the Guix config location when reconfiguring system or home? I want to set an envvar to the directory.

<euandreh>Can a root user inside a container escape the container?

<jab>nouun: I think guile has a pwd procedure.

<jab>I wonder if (guix records) has a way of saying you can define fieldname 'foo' or 'bar' but not both at the same time...

<jab>I know that it has a sanitize procedure...

<nouun>jab: Would that not print the directory in store rather than where the origin config is located

<jab>nouun: you could always hard code the value...

<nouun>Yea, that's what I'm doing now. Was just wondering if there was a nicer way to do it.

<jab>let me pull up my config...I do not think I am doing anything fancy...

<jab>all I am doing is: (define %current-directory "/home/joshua/prog/gnu/guix/guix-config/")

<wehlutyk[m]>maximed: thanks! (Late answer with the time difference). That's clearer. I'll try the PKG_CONFIG variable

<sperrhaken>Does somebody know which package I have to install for the “getconf” executable? Is there a Guix equivalent to Debianʼs “apt-file find”?

<oriansj>sperrhaken: not yet, here is the list of bits they do have: https://paste.debian.net/1234889/

<sperrhaken>I see, thanks.

<drakonis>oriansj: that should definitely be on the documentation

<sleepydog>I've been noticing that there are some ascii form-feed characters (0x0c) peppered throughout the guix source. are these significant or are they a side effect of someone's editor config?

<Ox151>hello, would anyone be able to tell why i am getting a "invalid field specifier" https://paste.debian.net/1235711/ i am pretty sure i copied the example from the docs correctly. but i guess i didnt

<Ox151>I added the menu-entry

<Ox151>figured it out, have to have (menu-entries (list (menu-entry (...)))) would be nice if the documentation was a little more descriptive in its example.

<apteryx>sleepydog: significant; it allows you to navigate the sections within Emacs (C-x ] goes to the next one, C-x [ to the previous one) :-)

<apteryx>(or M-x forward-page and M-x backward-page)

<sleepydog>ah, OK, I didn't know about that feature

<nouun>Is there an example of how to copy files in a Guix Home? For example I have {guix conf dir}/external/awesome/*.lua and want to copy the to ~/.config/awesome/

<nouun>Sorry misworded that, I want to run a command on those files and then write the output to the respective file in XDG_CONFIG_HOME

<Ox151>is there a way to change the default image for grub? The bootloader-configuration manual doesnt say much for the grub-theme procedure.

***bryan- is now known as apis_and_ipas

<lilyp>nooun: You can use local-file to refer to files, the only issue then is to use the right procedure to place them elsewhere

<mrb`>Hello, what do I have to install to have the linux man pages (eg. for syscalls) installed?

<maximed>mrb`: install the "man-pages" package

<maximed>if you are looking for the C wrappers around the syscalls and not the syscalls theirselves, you can also read the glibc documentation with "info libc"

<maximed>Ox151: Have a look at the 'theme' field of 'bootloader-configuration'

<maximed>nouun: Have a look at (current-filename) and (current-source-location)

<mrb`>maximed: Thank you. man-pages is what I am looking for. Maybe its name is to generic for me to find it on my own ;)

<unmatched-paren>hello guix :)

<MysteriousSilver>hello

<unmatched-paren>i'm looking into getting a plymouth splash screen on guix; i found an issue adding a `plymouth` package, but there's no system service or anything... does anyone know if somebody is already working on this?

<unmatched-paren>i'm also not entirely sure how to test out plymouth post-boot... there's a `plymouth-x11` xorg plugin, but i'm on wayland

<unmatched-paren>i want to make sure it actually works before i even think about changing the initrd :P

<paladhammika>hey guix, again, what prevents this package (http://issues.guix.gnu.org/48909) from being merged? Its been unaddressed since last June.

<paladhammika>The patch submitter asked four times last year and I've now asked twice. I'm confused as to why this doesn't get addressed. It doesn't help resolve what is missing in the package defintion if there is anything nor does the package finally get added.

<unmatched-paren>paladhammika: well, it's unfortunately not uncommon for patches to go forgotten for a while. (this, of course, is not the fault of the maintainers.)

<unmatched-paren>there are a LOT of open posts in guix-patches

<unmatched-paren>it's quite hard to keep track of so many and respond to them all, sadly

<paladhammika>I see. A poor assumption on my part that the issues found on the tracker were all that was open.

<singpolyma>paladhammika: you could try submitting to a channel like guixrus

<paladhammika>singpolyma: yes thanks, i reached out to them.

<Ox151>maximed: for the grub theme in bootloader configuration, i see nothing that references background image. i tried (background_image '("image/path")) (which is how grub identifies it in the grub.cfg) and (background-image '("image/path")) but i get extraneous field initializers (background-image) when trying to reconfigure

<maximed>Ox151: as I wrote previously, have a look at the 'theme' field of 'bootloader-configuration'

<maximed>Not the non-existent background-image.

<maximed>Looking at gnu/bootloader/grub.scm, it accepts a 'grub-theme' record, which has an 'image' field that can be set

<maximed>Looks like it is partially documented in (guix)Bootloader Configuration, but unfortunately not all of it is documented

<maximed>paladhammika: a lack of people for reviewing and committers for commiting

<maximed>FWIW: inputs can be done in new-style: (native-inputs (list pkg-config qttools))

<maximed>trailing #t can now be removed

<maximed>nevermind, I'll just respond

<Ox151>maximed: thank you, i was looking at the web documentation and there was minimal documentation. sorry for my ignorance, but are you referencing 'bootloader-configuration' from a guix install itself? trying to understand so i can look this up myself.

<Ox151>specifically where is gnu/bootloader/grub.scm located on the system

<whereiseveryone>Hi Guixers!

<whereiseveryone>Today's Guix Packaging Meetup will feature singpolyma.

<unmatched-paren>Ox151: it's in the guix repo

<whereiseveryone>singpolyma will be discussing and demonstrating how to write a Guix package with javascript instead of guile.

<singpolyma>Also probably Lua. And assorted guile flavoured rambling

<unmatched-paren>Ox151: git clone https://git.sv.gnu.org/git/guix.git; cd guix

<whereiseveryone>Here's more info about the meetup: https://man.sr.ht/~whereiseveryone/wiki/meetup.md#guix-packaging-meetup

<unmatched-paren>singpolyma: guile has a lua backend now?

<singpolyma>unmatched-paren: not in tree. And it's a bit experimental/buggy but yes there is one

<whereiseveryone>And probably assorted jgart rambling also

<unmatched-paren>i remember seeing an unfinished python backend in a github repo somewhere

<whereiseveryone>be cool to have an idris backend

<singpolyma>I haven't tested the python frontend yet. It's packaged in guix I think

<unmatched-paren>you know what would be interesting? a racket frontend

<singpolyma>unmatched-paren: you mean just for racket-scheme?

<unmatched-paren>then we would get access to all the racket languages...

<whereiseveryone>dependently typed guix packages

<singpolyma>I think you would need one frontend for each of those languages sort of. But I'll admit to not knowing the internals

<unmatched-paren>haskell backend :)

<unmatched-paren>s/backend/frontend/g

<singpolyma>GHCJS and run on the ecmascript frontend ;)

<singpolyma>Or use purescript

<whereiseveryone>whitespace and brainfuck frontend would be cool too for when you're feeling bored

<singpolyma>I'm honestly surprised I haven't seen one of those

<unmatched-paren>well, a haskell frontend would certainly solve a certain annoying bootstrapping problem...

<unmatched-paren>whereiseveryone: pretty sure the guile repo has a brainfuck frontend

<unmatched-paren>as an example

<singpolyma>It may. Maybe I just forgot about it

<unmatched-paren> http://git.savannah.gnu.org/cgit/guile.git/tree/module/language/brainfuck

<unmatched-paren>-.o.-

<singpolyma>I will not be demoing a guix package written in BF today, sorry

<unmatched-paren>sad

<unmatched-paren>(probably wouldn't be possible anyway :P)

<podiki[m]>just catching up on the shepherd on fibers thread, very exciting!

<podiki[m]>better shepherd running and logging will be a very nice improvement for Guix

<whereiseveryone>unmatched-paren: yup, I've read through it before

<whereiseveryone>re: brainfuck frontend

<unmatched-paren>let's implement guile bytecode as a guile frontend >:)

<whereiseveryone>singpolyma: have you tried running the guix package for xmobar?

<whereiseveryone>I think it has a bug/issue

<whereiseveryone>I'll report it later today

<singpolyma>I have not. Been using qtile recently

<singpolyma>unmatched-paren: or warm and then a warm backend, heh

<singpolyma>...wasm

<whereiseveryone>I started using berry yesterday after packaging it: https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L595

<whereiseveryone>I'd like to use xmobar with it

<whereiseveryone>The void linux package for xmobar works but is way out of date

<whereiseveryone>The guix package for xmobar is broken or missing guix specific setup instructions since it doesn't work out of the box like the void xmobar does

<singpolyma>whereiseveryone: running on foreign?

<whereiseveryone>I've been using void linux

<singpolyma>Do you get errors that seem useful?

<whereiseveryone>Yes

<whereiseveryone>one sec, I'll paste

<whereiseveryone>I'd like to package that fancy sourcehut cli tool that simon ser wrote

<whereiseveryone>I think it has an interface to the paste service

<singpolyma>Or use termbin

<unmatched-paren>whereiseveryone: ah, yeah! i've been thinking about packaging `hut`, but never got around to it

<whereiseveryone>xmobar: SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 5>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/home/jgart/tmp/bus")}

<whereiseveryone>unmatched-paren: https://todo.sr.ht/~whereiseveryone/guixrus/28

<whereiseveryone>I opened an issue there for it

<whereiseveryone>We can edit the dependency list for hut and divide and conquer the work if you'd like

<unmatched-paren>whereiseveryone: oh, yeah. i forgot it was written in go :(

*unmatched-paren shudders at the thought of their attempt to package aerc

<whereiseveryone>unmatched-paren: do you have a sourcehut account? I can give you write access to that issue tracker if you'd like to join me

<unmatched-paren>whereiseveryone: yeah, i do have one

<unmatched-paren> https://sr.ht/~unmatched-paren

<singpolyma>Does the importer not work on it?

*unmatched-paren forgot about the importer... :P

<unmatched-paren>whereiseveryone: actually, could i try to merge my channel into guixrus? mine is just a random assortment of packages i wanted

<whereiseveryone>unmatched-paren: I added you with read/write access to the guixrus wiki

<unmatched-paren>stuff like tree-sitter, QBE, latest neovim, GLAD2

<whereiseveryone>unmatched-paren: I can also add your channel here: https://man.sr.ht/~whereiseveryone/wiki/channels.md

<whereiseveryone>We've been collecting a list of channels there

<whereiseveryone>But yes, If you'd like to maintain anything in a group/community setting before going to upstream feel free to send patches

<whereiseveryone>If you let me know what you'd like to merge over you can also open an issue and list the packages with links

<whereiseveryone>I'll try to find the time to go through them

<whereiseveryone>Anything that is upstream suitable will eventually get sent to guix-patches@gnu.org

<unmatched-paren>i think it'd be better to just merge them together, since they have basically the same goals

<whereiseveryone>That's one of guixrus' channel goals

<unmatched-paren>guixrus only has free software, right?

<whereiseveryone>Yes, we are a free software only channel

<unmatched-paren>right, cool

<whereiseveryone>We sometimes package software where upstream hasn't added a license yet but then we open an issue to ask them to add it

<whereiseveryone>I've had to do that a few times for promising github packages I've packaged

<whereiseveryone>I like to encourage up and coming software projects for suitability of being packaged for Guix

<whereiseveryone>unmatched-paren: patches for Guix 'R Us can be sent to ~whereiseveryone/guixrus@lists.sr.ht

<unmatched-paren>i guess they're technically not free, but if the upstream's intent was for it to be free but forgot to add a license then i'm fine with that, it's not like they'd sue me or anything

<whereiseveryone>Yup, that's the idea. We add the package with a #f in the license field until they add it upstream

<whereiseveryone>Then, we update the package

<unmatched-paren>i guess i'd need to add my .key file to guixrus's keyring?

<whereiseveryone>otherwise, it is removed if we find out it is not going to be free

<whereiseveryone>Yes, that too. If you'd like to have commit access let's talk about it.

<whereiseveryone>Currently just jgart (myself) and Raghav have commit access

<whereiseveryone>But I'd like to add more people

<unmatched-paren>maybe once i've added a few packages, but not right now

<whereiseveryone>I'd like for anyone with commit access to help with reviewing and upstreaming to GNU Guix

<whereiseveryone>otherwise, patches in Guix 'R Us usually get merged within a day or two if they don't have any serious problems

<whereiseveryone>If your package builds it will probably get merged within a day

<whereiseveryone>or a few hours

<whereiseveryone>We don't expect packages to be upstream ready. One of the goals of Guix 'R Us is to get the packages upstream ready

<whereiseveryone>So we accept packages without synopsis, description etc... As long as it builds

<unmatched-paren>makes sense :)

<whereiseveryone>Then we can crowd source getting that package ready through iterative development until we send it upstream to GNU Guix

<whereiseveryone>It's a pipeline

<whereiseveryone>And we benefit from having the package immediately available in a convenient manner

<whereiseveryone>with substitutes: https://bags.whereis.みんな/

***sneek_ is now known as sneek

<unmatched-paren>oh, substitutes are available? :D

<whereiseveryone>YES ;-)

<whereiseveryone>We've had a substitute channel up for a few weeks, iirc. I added some info about it to the Guix 'R Us README also

<unmatched-paren>hm, parts of that url to the substitute website show as invalid unicode boxes...

<whereiseveryone>unmatched-paren: https://git.sr.ht/~raghavgururajan/guix-config/tree/master/item/system/config.scm#L265

<unmatched-paren>what's the TLD for whereis.(...)?

<whereiseveryone>unmatched-paren: xn--q9jyb4c

<whereiseveryone>whereis.xn--q9jyb4c

<whereiseveryone>bags.whereis.xn--q9jyb4c

<whereiseveryone>etc...

<unmatched-paren>that's an... interesting... domain name

<singpolyma>It's everyone in Japanese

<unmatched-paren>oh, i see

<unmatched-paren>i guess that's why it doesn't display in my terminal then -.o.-

<singpolyma>Need more Japanese glyphs in your font ;)

<akonai>looks fine in emacs but browse-url chokes on it

<whereiseveryone>I'd like to add a "search engine" to whereis.xn--q9jyb4c then we can maybe make a defengine for it: https://gitlab.com/ambrevar/dotfiles/-/blob/master/.emacs.d/lisp/init-engine.el#L14

<whereiseveryone>there's currently 716 packages in Guix 'R Us

<whereiseveryone>We could use some help upstreaming ;)

<unmatched-paren>whereiseveryone: btw, my channel is here, if you want to pick out which packages you'd like me to merge in: https://git.sr.ht/~unmatched-paren/guix-channel

<whereiseveryone>unmatched-paren: thanks!

<whereiseveryone>We'll accept anything that builds

<unmatched-paren>there's some changes i haven't pushed tho

<whereiseveryone>unmatched-paren Oh cool! You packaged helix?

<unmatched-paren>yep :D

<whereiseveryone>Awesome!

<whereiseveryone>Is the tree-sitter working for it also?

<unmatched-paren>i'm not using it anymore because i missed some nvim plugins

<unmatched-paren>yes!

<unmatched-paren>but it should work

<whereiseveryone>sweet!

<unmatched-paren>HOWEVER it's not entirely built from source

<whereiseveryone>that's fine, we can work on it

<whereiseveryone>what's not built from source curently?

<whereiseveryone>did you build helix with a later rust version not in master?

<unmatched-paren>it downloads C blobs from tree-sitter grammar repos

<unmatched-paren>building tree-sitter grammars from the JS source will require changes to node-build-system

<whereiseveryone>unrelated: I'd like to package this language server soon: https://github.com/pappasam/jedi-language-server

<whereiseveryone>I've been using it with emacs and eglot

<whereiseveryone>It works much nicer than any other python language server I've used

<unmatched-paren>see: https://issues.guix.gnu.org/49946

<whereiseveryone>but unfortunately the python-build-system in master won't handle it yet

<unmatched-paren>i took most of the tree-sitter stuff from that issue (with attribution, of course)

<whereiseveryone>cool! Yes, let's add 49946 and any updates

<whereiseveryone>sounds like a nice project

<whereiseveryone>to work on

<unmatched-paren>the one thing i did do is update the tree-sitter package from 0.19 given in that patch to 0.20

<unmatched-paren>so no need to worry about that

<whereiseveryone>unmatched-paren: I've been pairing with konkrotte on upterm here: https://todo.sr.ht/~whereiseveryone/guixrus/19

<whereiseveryone>It's a nice alternative to tmate that we could use for the pairing at the packaging meetups since tmate hasn't been maintained

<whereiseveryone>unmatched-paren: re: tree-sitter 0.20: great!

<unmatched-paren>ah, cool

<planglois>unmatched-paren: Hi! Just seeing the discussion about tree-sitter, I'm still working on it, doing a build-system for the grammars, I should have a new version this week time permitting :-). In the meantime, feedback is very appreciated! I also have it updated to the latest version locally

<planglois>(Hi guix! :-))

<unmatched-paren>planglois: neat! you're clearly more patient than i am :P

<unmatched-paren>sorry, i need to log out for a moment to reload my gpg configuration (i've been having problems with it)...

<planglois>haha, yeah it's taking time to get it to the finish line, just realized I started in August :-)

<unmatched-paren>apparently logging out doesn't fix gpg...

<unmatched-paren>well, i certainly won't be able to do any git commits until this is fixed

<anadon>How do I build a stand along package file to test if I've written up the .scm correctly?

<planglois>anadon: Is this from a Guix git checkout or your own .scm file outside of Guix? If outside, you should be able to do something like `guix build -L <dir> <package-name>', where you augment the guile load path so it can find your .scm module.

<anadon>planglois Outside, then hopefully get it merged in.

<planglois>anadon: oh, almost forgot, there's also a `guix build -f=FILE` flag, that could help as well

<anadon>planglois: `-f` fails even for official packages.

<planglois>IIRC, with -f you need the file to evaluate to a package definition, so you can just put the variable of what you want to build as the last expression in the file

<unmatched-paren>a shame that there doesn't appear to be any fully-bootstrapped strongly typed functional languages

<unmatched-paren>ocaml doesn't count, camlboot gets close but isn't yet at the latest release

<unmatched-paren>(and camlboot's last commit was september last year)

<unmatched-paren>aha! i got gpg working again :D

<unmatched-paren>whereiseveryone: i'll send a patch to add my key in a few moments

<unmatched-paren>idris2 is bootstrappable using idris1, but idris1 is written in haskell

<anadon>Uhg. It finds the input package. It knows it needs the package. It knows that `pkg-config` is itself a valid package. But Satan help me if it counts as a valid input.

<unmatched-paren>typed racket isn't a first-class citizen in racket

<unmatched-paren>fsharp depends on dotnet, which is theoretically bootstrappable with mono

<anadon>Typing is one thing overlooked by a ton of people. Pretty sure it has caused harm in the Kernel due to L's bullheadedness w/r C.

<unmatched-paren>but the fsharp->dotnet bytecode compiler itself is written in fsharp...

<unmatched-paren>scala is written in itself

<unmatched-paren>anadon: C is hardly typed

<anadon>That's my point.

<unmatched-paren>right

<anadon>C++ has gotten into a kind of typing hell, but at least they're making a valiant effort to make types practical and make sense.

<unmatched-paren>anadon: i find C++ to have a load of extensions that I don't feel like I want and none of the ones that I do want :P

<anadon>I didn't say they have succeeded.

<anadon>`guix build: error: /home/anadon/Documents/code/guix-packages/antlr4.scm:42:2: package `libantlr4@4.9' has an invalid input: #<package pkg-config@0.29.2 gnu/packages/pkg-config.scm:33 7f40da812f00>` -- why is it invalid?

<unmatched-paren>the things i WOULD want in a 'better C' are: variant/tagged union types, a proper module system (which is apparently coming to C++ Very Soon We Promise(TM)), and generics (I know templates exist in C++, but they are apparently abominable works of the overengineering demon)

<planglois>anadon: is pkg-config in (inputs) or (native-inputs) in your definition? It should be the latter generally, that could be it

<planglois>I admit this error message isn't super helpful :-/

<unmatched-paren>it should be fairly easy to compile the latest OCaml with the camlbooted OCaml, but nobody has so far gotten around to it

<unmatched-paren>unfortunately, many of Guix/Guile's error messages are pretty unhelpful

<unmatched-paren>one moment, i'm just logging out to try to reload gpg again...

<unmatched-paren>ok, gpg is working now! (I had to export GPG_TTY.)

<anadon>planglois: former. Changed to (native-inputs (list pkg-config util-linux)), no change in behavior.

<unmatched-paren>whereiseveryone: i'm going to send my keyring patch now (finally)

<anadon>unmatched-paren: C++ templates are over-engineered, but the committee is making it better every update. I'll take that since we don't have many living programming gods left among us. It is the best we can do.

<unmatched-paren>well, https://drewdevault.com/2021/03/19/A-new-systems-language.html looks pretty promising as a better C

<unmatched-paren>it's actually way SMALLER than C

<unmatched-paren>which i think is in part due to the absence of a preprocessor

<unmatched-paren>well, the spec is smaller, anyway

<unmatched-paren>(i found the website, which has the spec, but i'm not going to share a link at the request of a paragraph on its front page :P)

<unmatched-paren>And also Zig

<drakonis>unmatched-paren: its called hare

<anadon>Preprocessors /may/ have been a mistake.

<singpolyma>Not sure you can be better than C if you copy malloc/free

<anadon>where is the guix package linter hiding these days?

<drakonis>guix lint?

<planglois>anadon: that'll be `guix style' these days

<drakonis>huh, nevermind.

<unmatched-paren>i don't really understand the aversion to manual memory management; i find void pointers to be a MUCH bigger mistake

<anadon>planglois: not on stable: `anadon@Poymon:~/Documents/code/guix$ guix style

<anadon>guix: style: command not found`

<drakonis>try pulling

<drakonis>it should be available on the master branch

<anadon>drakonis ...

<anadon>Do you know how many times I've pulled just this morning? That isn't it.

<drakonis>i called it just now and it showed up here

<drakonis>are you on a different branch?

<anadon>I'm on 1.2. That's the current stable release. It provides no hints that 1.3 even exists, let alone a way to upgrade to it. And that's assuming the upgrade would change the features of `lint` -> `style` to add `-f` for checking specific .scm package files.

<planglois>anadon: mmm that is strange, the guix that you run should generally always be following the master branch, what does `guix describe' tell you?

<whereiseveryone>unmatched-paren: re: key: Thanks, I'll look out for the patch

<drakonis>uh

<anadon>planglois: https://paste.debian.net/1235772/

<drakonis>1.2's from 2020?

<drakonis>that doesnt seem quite right

<anadon>It is straight from a blank slate from the installer script linked in the manual.

<drakonis>the commit you're on is the current head for v1.3.0

<planglois>anadon: oh yeah, you'll need to update. Guix doesn't really have the concept of a stable branch, it's more of a rolling release

<drakonis>if you've called `guix pull` it should put you on the newest commit

<planglois>unless it's pinned in your channels.scm file?

<drakonis>this one's from 10/05/2021

<anadon>Guys, you keep saying pull and update as if I don't know to and haven't been doing that for the past 2 days.

<anadon>I'm not that much of an idiot. It is something else.

<drakonis>look at your channels file

<anadon>It isn't `hash guix` either.

<anadon>Nor it is something rebooting helps.

<drakonis>could you paste the contents of .config/guix/channels.scm?

<anadon>```

<anadon>anadon@Poymon:~/Documents/code/guix$ less ~/.config/guix/channels.scm

<anadon>```

<drakonis>hmmm

<drakonis>that's not the content, is it?

<anadon>Formatting get destroyed.

<anadon>*got

<anadon>`/home/anadon/.config/guix/channels.scm: No such file or directory`

<drakonis>hm

<drakonis>that, is weird.

<drakonis>okay.

<drakonis>is this guix system or standalone?

<unmatched-paren>ok, one last thing: can you please show your /etc/config.scm?

<anadon>Ubuntu host

<drakonis>hhmmm

<anadon>All I did was use https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh

<drakonis>i see

<unmatched-paren>oh, okay...

<drakonis>have you run the pull command as a user?

<drakonis>its a dumb question

<drakonis>but i gotta ask

<anadon>*sigh*

<drakonis>i'm trying

<anadon>I was here 2 years ago doing minor packaging.

<drakonis>okay, fine.

<drakonis>this is irregular

<anadon>I know they super obvious stuff.

<drakonis>i havent heard about this happening before.

<anadon>No, I'm not running as root.

<drakonis>i apologize, i'm not trying to insult your capabilities

<planglois>mmmm this is confusing indeed, I wonder, the guix command should normally be $HOME/.config/guix/current/guix, is this the case?

<unmatched-paren>try `which guix` perhaps

<anadon>drakonis: Everything is frustrating in life right now.

<drakonis>installing with the shell script doesnt add it to /usr/bin and such

<anadon>unmatched-paren: `/home/anadon/.guix-profile/bin/guix`

<unmatched-paren>anadon: aha

<drakonis>oh

<drakonis>did you install guix to your profile?

<drakonis>try guix upgrade idk

<planglois>ha-ha! that'll be it :-D

<unmatched-paren>try running `/home/anadon/.config/guix/current/bin/guix describe`

<drakonis>or uninstalling guix from your profile and it should start pointing to the proper version

<unmatched-paren>and if it works:

<unmatched-paren>`guix remove guix`

<anadon>...I followed the install script above, as recommended in the manual.

<unmatched-paren>hm

<drakonis>hmm

<drakonis>try doing that though

<anadon>If I'm broken, there's a bigger issue.

<drakonis>i highly suspect that might be the cause?

<anadon>unmatched-paren: New behavior.

<drakonis>say, are you keeping your home directory from a previous install?

<anadon> https://paste.debian.net/1235773/

<drakonis>okay

<drakonis>that's the latest commit

<drakonis>you have a older guix revision installed on your profile

<unmatched-paren>right, now do `guix remove guix`

<anadon>Last I knew, those were symlinks.

<drakonis>it is a pinned symlink though

<unmatched-paren>guix handles itself separately from your profile

<drakonis>they dont get updated in lockstep with the generations

<drakonis>pulling doesnt bump packages installed in your profile

<drakonis>i can kinda see why nix has generally deprecated that

<anadon>Guix is now totally borked.

<drakonis>the support burden can be too much

<drakonis>use hash guix now

<unmatched-paren>`guix pull` upgrades guix, `guix upgrade` upgrades everything else

<unmatched-paren>this is because the `guix` CLI is provided as part of the `guix` channel, not separately

<unmatched-paren>so when you upgrade your channel(s), you upgrade the `guix` tool

<anadon>Back to old behavior. https://paste.debian.net/1235775/

<drakonis>did you not run `guix remove guix`?

<unmatched-paren>yes, i think they did

<drakonis>huh okay

<drakonis>weird.

<anadon>That becomes nessicary again, even after not installing it?

<drakonis>you don't need to keep it installed in your profile

<anadon>I don't.

<drakonis>i'm not good at this support thing

<unmatched-paren>anadon: can you try `echo $PATH`, please?

<anadon>`/home/anadon/.guix-profile/bin:/home/anadon/.guix-profile/sbin:/bin:/usr/bin:/usr/local/bin`

<unmatched-paren>as suspected

<unmatched-paren>hmm... could you `which guix` one more time? i think it might be using the one you got from apt now

<drakonis>ah yes.

<drakonis>hmm

<anadon>-what-

<unmatched-paren>oh, right

<drakonis>hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/anadon/.config/guix/current/bin/guix'.

<drakonis>maybe this?

<drakonis>idk

<anadon>apt doesn't have guix installed.

<unmatched-paren>you installed with the guix-install.sh script, not apt, right

<unmatched-paren>sorry :P

<unmatched-paren>you need to add the .../current/bin directory to PATh

<anadon>It could be old pathing stuff. I recall the install script having a number of sharp edges.

<unmatched-paren>`export PATH=~/.config/guix/current/bin` in ~/.profile, then `bash --login` to try it

<unmatched-paren>if it works, you can log out and back in and all should be working fine

<drakonis>at this point, i'm just using debian's guix package

<user`>Hi. In emacs init when running (guix-emacs-autoload-packages) I'm getting this error: 'File is missing: Opening directory, No such file or directory, /home/user/.guix-home/profile/share/emacs/site-lisp/obsolete'. Any tips? Can't find the "obsolete" directory manually either.

<planglois>the install script leaves a symlink to guix in /usr/local/bin doesn't it? For the initial install, maybe that's being picked up instead of the new one?

<unmatched-paren>anadon: sorry, that was the wrong command i told you to add to .profile

<drakonis>so it does

<anadon>unmatched-paren: Finally works as expected.

<unmatched-paren>it should be `export PATH=~/.config/guix/current/bin:$PATH`

<anadon>Already caught that.

<unmatched-paren>right, k

<anadon>I'm not disabling my entire OS.

<unmatched-paren>sorry

<anadon>No worries.

<unmatched-paren>glad to help, even if my advice can be dubious sometimes :P

<anadon>Now, back to my original questions: how do I actually fix a package which needs pkg-config to build?

<unmatched-paren>does it work with your new fixed guix?

<drakonis>try building that with the current revision just for good measure :v

<unmatched-paren>it should just work if you've got (gnu packages pkg-config) imported...

<anadon>nope. Definition here: https://paste.debian.net/1235776/

<unmatched-paren>aha

<anadon>The quotes

<unmatched-paren>you've got the package objects defined as strings

<unmatched-paren>s/defined/written out/

<anadon>I originally didn't have those.

<unmatched-paren>hm

<unmatched-paren>have you tried without the quotes in the new guix revision?

<anadon>Further. Still no success.

<unmatched-paren>huh

<anadon>Something about patching a shebang can't find python in PATH.

<anadon>I added python to native-inputs, still nothing.

<unmatched-paren>that should be a warning

<unmatched-paren>it should be fine

<anadon>OK

<unmatched-paren>could you please paste the log output?

<anadon>Next is...Oh lame.

<unmatched-paren>those `patching shebang` things are common and harmless

<anadon> https://paste.debian.net/1235777/

<unmatched-paren>guix has automation that changes certain shebangs to paths in the store

<anadon>Come on, cmake. You're better than this.

<unmatched-paren>oh god cmake

<unmatched-paren>that... doesn't look like a cmake package to me

<unmatched-paren>it looks, at first glance, like a maven package

<unmatched-paren>yeah, try `maven-build-system`

<anadon>unmatched-paren: here's where my actual questions start. I need to mess with the build steps to build the C++ runtime portion.

<unmatched-paren>ah... some of it uses C++?

<anadon>That part is cmake. And the buildsteps options for guix packages is rather opaque.

<unmatched-paren>packages with two build systems are Pain

<anadon>I can actually entirely ignore maven, actually.

<unmatched-paren>looks like you should be chdir'ing into `$BUILD_DIR/runtime/Cpp` before build

<anadon>But I do need to split this into a package with the .so's and a package with the .h's and .a's.

<unmatched-paren>so what you'll want to do is this:

<unmatched-paren>add an arguments field to the package (so `(package .... (arguments) ....)`)

<unmatched-paren>now add this inside the `arguments` field: `'(#:phases (modify-phases %standard-phases))`

<unmatched-paren>and add this after `standard-phases` in `modify-phases`: (add-before 'build 'change-dir (lambda _ (chdir "runtime/Cpp")))

<unmatched-paren>now it should change directory to runtime/Cpp before building

<unmatched-paren>oh, sorry

<unmatched-paren>change that `'build` to `'configure`

<user`>re. my issue with (guix-emacs-autoload-packages) above: loading init.el without this function seems to work fine, so no problem then

<user`>

<unmatched-paren>i just realized that `cmake` is invoked first in the `configure` phase, not `build`

<unmatched-paren>you might also need to change 'install, but we'll cross that bridge if we come to it

<unmatched-paren>anadon: ^

<anadon>Yup, trying to ingest LISP coming from Python and C++ land.

<unmatched-paren>`#:something` is a keyword, which is used to pass keyed arguments to functions like `foo(something = ...)` in Python

<unmatched-paren>i think the reason we put them in this list is that the list is spliced into the arguments to the build system's build function

<anadon>unmatched-paren: cmake isn't picking up UUID facilities from util-linux. Have you seen this before?

<unmatched-paren>so it ends up looking something like this:

<unmatched-paren>(function-that-builds-stuff #:phases (modify-phases ...))

<unmatched-paren>anadon: i think util-linux should be in `inputs`

<anadon>No change

<unmatched-paren>ok... could you please paste the log?

<anadon> https://paste.debian.net/1235779/

<unmatched-paren>whereiseveryone: sorry, i got a bit diverted; i'm trying to figure out how to get the GPG_TTY variable set permanently in fish

<unmatched-paren>anadon: ok, pkg-config can't find libuuid... i'm going to try `pkg-config --libs uuid` in a shell with util-linux and pkg-config

<unmatched-paren>are you sure that util-linux provides libuuid?

<unmatched-paren>yeah... it seems to :/

<unmatched-paren>ok, this is weird

<unmatched-paren>[I] paren@guix-aspire ~ [2]> ls /gnu/store/7nlzk7n90ib3llblxlpz725ym3k05gdj-util-linux-2.37.2-lib/lib/pkgconfig/

<unmatched-paren>blkid.pc fdisk.pc mount.pc smartcols.pc uuid.pc

<unmatched-paren>there definitely is a pkg-config file for it

<unmatched-paren>AHA

<unmatched-paren>anadon: you'll want to use (list util-linux "lib") instead of util-linux

<unmatched-paren>that selects the package's `lib` output, which contains all the libraries, instead of the default `out`, which contains the binaries

<unmatched-paren>it's possible that you'll need both

<anadon>That is not behavior I would have expected. I'll include both, and trim fat later.

<unmatched-paren>yea, i'm not sure why the libraries are separated

<unmatched-paren>try with just "lib" first

<anadon>unmatched-paren: `invalid input: ("_" "lib")`

<unmatched-paren>could you paste your package definition again?

<anadon> https://paste.debian.net/1235780/

<unmatched-paren>ah

<unmatched-paren>it should be (list (list util-linux "lib"))

<unmatched-paren>in (inputs)

<anadon>Why can't the DOE just pay me to do develop on stuff like this all day. This debugging is already more rewarding that all of my work in the past month.

<unmatched-paren>see, if you have just a package on its own, it's treated as equivalent to `(list pkg "out")`, since `out`'s the default; if you want to change the output, you need to make it a `(list)`

<anadon>Cloning into 'utfcpp'...

<anadon>fatal: unable to look up github.com (port 9418) (Name or service not known)

<anadon>I've never seen that before.

<unmatched-paren>... excellent. the build tries to access teh interwebs.

<anadon>Brilliant.

<unmatched-paren>guix disables internet access in builds, for obvious reproducibility reasons

<anadon>Add that to the things I need to package, then.

<anadon>Cool, it has already been packaged.

<unmatched-paren>if you download example.com/script.sh today, there's no guarantee that they'd be the same in ten weeks time

<unmatched-paren>you'll probably need to patch the build to stop it downloading stuff too... :(

<unmatched-paren>i'll see if i can figure out where it does that

<anadon>How do I shunt in the existing `utfcpp` package? To I need to just write a patch for the CMakeLists.txt?

<unmatched-paren>you probably don't even need a .patch file

<unmatched-paren>one moment

<anadon>Thanks for all the help. Man, I really wish there were fewer 'hacker' programmers and more poised ones.

<unmatched-paren>lemme just find the docs for `(substitute*)`

<anadon>unmatched-paren: I need to step away for a hot second. I'll ping you when I'm back, ETA 20 min.

<unmatched-paren>ok! :)

<unmatched-paren>i'll probably still be here

<unmatched-paren>anadon: search for `substitute*` in https://guix.gnu.org/manual/devel/en/html_node/Build-Utilities.html

<unmatched-paren>sneek: later tell anadon: search for `substitute*` in https://guix.gnu.org/manual/devel/en/html_node/Build-Utilities.html

<sneek>Got it.

<unmatched-paren>sneek: botsnack :D

<sneek>:)

<unmatched-paren>sneek: what is it like being a bot

<unmatched-paren>we should add AI to sneek :P

<unmatched-paren>lisp was historically used for AI, after all!

<unmatched-paren>sneek: later tell anadon: i think you do need to use maven; the build process appears to require the location of antlr.jar...

<sneek>Okay.

<unmatched-paren>sneek: botsnack again :P

<sneek>:)

<unmatched-paren>sneek: please try not to eat too much

<unmatched-paren>sneek: later tell anadon: actually... this package looks like it's going to be a real pain to build. you'll want to split it up into multiple packages inheriting from each other. when you ping me, i'll elaborate

<sneek>Okay.

<unmatched-paren>i would give sneek a botsnack but i'm worried they'd explode

<unmatched-paren>..and now i will FINALLY send that guixrus patch :)

***jonsger1 is now known as jonsger

<unmatched-paren>whereiseveryone: https://lists.sr.ht/~whereiseveryone/guixrus/patches/30592 :D

<unmatched-paren>sneek: later tell whereiseveryone: https://lists.sr.ht/~whereiseveryone/guixrus/patches/30592 :D

<sneek>Will do.

<unmatched-paren>sneek: bothealthymeal

<anadon>unmatched-paren: I'm back. I only watch to touch the C++ parts right now, and leave an `antlr4.scm` for those who come later.

<sneek>anadon, you have 3 messages!

<sneek>anadon, unmatched-paren says: search for `substitute*` in https://guix.gnu.org/manual/devel/en/html_node/Build-Utilities.html

<sneek>anadon, unmatched-paren says: i think you do need to use maven; the build process appears to require the location of antlr.jar...

<sneek>anadon, unmatched-paren says: actually... this package looks like it's going to be a real pain to build. you'll want to split it up into multiple packages inheriting from each other. when you ping me, i'll elaborate

<unmatched-paren>anadon: ok

<anadon>So, what packaging complications are you seeing? According to https://www.cs.sjsu.edu/~mak/tutorials/InstallANTLR4Cpp.pdf I don't need the .jar.

<unmatched-paren>hm, k

<unmatched-paren>according to the README, you need to specify the jar, but ok

<anadon>Which README?

<unmatched-paren> https://github.com/antlr/antlr4/blob/master/runtime/Cpp/README.md

<unmatched-paren>See 'Compiling on Linux'

<anadon>Oh hell.

<unmatched-paren>guix already has an antlr4 package

<anadon>Man, this project has significant Java and Apple biases.

<unmatched-paren>we might be able to use the jar from there

<unmatched-paren>haha, yeah :P

<unmatched-paren>actually

<anadon>The computer science behind it is great and insightful. As time wears on, I'm becoming less enamored with the implementation.

<unmatched-paren>we have a libantlr3c package

<anadon>Actually, as a rule, nobody has made a """good""" grammar tool AFAICT.

<unmatched-paren>anadon: try EDITOR=<your editor> guix edit libantlr3c

<unmatched-paren>it might contain some insights into handling the jar?

<anadon>Not a one.

<unmatched-paren>hm

<anadon>For some history

<anadon>The author completely re-engineering, re-architected, and re-philosophized everything between Antlr3 and Antlr4. They might as well be entirely unrelated projects by unrelated people.

<unmatched-paren>ok, i've finally gotten zathura to open that pdf... i'll have a look at it...

<unmatched-paren>ah

<unmatched-paren>anadon: anyway... let's try to fix that utfcpp download first

<anadon>ok

<unmatched-paren>so, i've looked through CMakeLists.txt, and i can't find anything mentioning utfcpp or git...

<unmatched-paren>this is the price you pay for a highly abstracted build system: debuggability :P

<unmatched-paren>anadon: i'll be AFK for a bit, sorry

<anadon>kk

<unmatched-paren>anadon: i'm back

<anadon>So the line is CMakeLists.txt:60

<unmatched-paren>ah!

<unmatched-paren>oh

<unmatched-paren>i thought you were talking about utfcpp :)

<anadon>I am

<unmatched-paren> if(NOT EXISTS "${ANTLR_JAR_LOCATION}")

<unmatched-paren>?

<anadon>nested, self similar dir structure

<anadon>For some foresaken reason.

<anadon>'runtime/Cpp/runtime/CMakeLists.txt`

<unmatched-paren>oh!!

<unmatched-paren>... i loathe cmake

<unmatched-paren>right, i guess we'll need to fix that thing

<anadon>cmake is bloated, that is for sure.

<unmatched-paren>according to suckless.org:

<anadon>There is a good reason that despite how many time and no matter how hard you try, getting away from `make` ultimately fails.

<unmatched-paren>cmake (written in C++) - so huge and bloated, compilation takes longer than compiling GCC (!).

<unmatched-paren>`make` could be good

<unmatched-paren>if only shell syntax wasn't so awful

<anadon>Personally, I'm sold on `meson` atm.

<anadon>Not a hill I'd die on, but it seems OK enough.

<unmatched-paren>i quite like meson, but i prefer make since there's no magic going on; it's easy to see why something is happening

<unmatched-paren>to be entirely honest, cmake syntax is somehow five hundred times worse than make

<anadon>So it looks like if utfcpp is installed, it'll detect it and use it rather than download. I'll see how well that works

<unmatched-paren>ok!

<unmatched-paren>btw, about the difference between inputs and native-inputs:

<unmatched-paren>it only matters when cross-compiling.

<unmatched-paren>basically, native-inputs should contain everything that would run on the host machine's architecture

<unmatched-paren>oh, wait

<unmatched-paren>apparently the difference is much simpler, according to the guix manual

<unmatched-paren>well, the above is what i've been previously told

<unmatched-paren>but anyway: see 2.1.3.3 'Inputs' in https://guix.gnu.org/cookbook/en/html_node/Extended-example.html

<anadon>It treats `utfcpp` as special. It doesn't log what happens when trying to find it, and it is the only dependency which it will automatically go out and fetch and build in case anything goes wrong. That is a terrible hack which should have never been merged.

<anadon>I'm not even confident it CAN detect it, despite some code being dedicated to that. Looking at line 42.

<anadon>Who wrote this?

<unmatched-paren>they must be hunted down

<unmatched-paren>and stopped, before they become a threat to society

<unmatched-paren>tbh it's probably too late :P

<unmatched-paren>anadon: ... maybe we could try to figure out how this abomination SHOULD behave and try to emulate it with manual calls to gcc?

<unmatched-paren>(i'm getting desperate :P)

<anadon>Maybe. I'm trying to think of what makes sense here.

<unmatched-paren>[I] paren@guix-aspire ~> ls /gnu/store/wbkcza77vbqzipb0j

<unmatched-paren>kaq588gf7hrg7k8-utfcpp-2.3.5/

<unmatched-paren>include share

<unmatched-paren>note the conspicuous absence of a `lib` directory...

<anadon>Just as a test, installing utfcpp doesn't expose utfcpp or utf8cpp from pkg-config.

<anadon>Oh? These two observations might be related.

<unmatched-paren>yeah, they almost certainly are

<unmatched-paren>.pc files live in $out/lib/pkgconfig/*

<unmatched-paren>the only thing i can think of is if utfcpp is a header-only library

<unmatched-paren>which seems unlikely since it has multiple headers

<unmatched-paren>looking at the package definition...

<unmatched-paren>it seems like the utfcpp package has no `install` target, so the package tries to emulate one

<unmatched-paren>shoddily

<anadon>Also, Antlr4 C++ uses utfcpp v3.1 and guix packages v2.3

<unmatched-paren>...this is a terrible package

<unmatched-paren>(not talking about yours :P)

<anadon>~It is better than what I can make~

<unmatched-paren>yours is better

<unmatched-paren>seriously, this one copies README.md into share/doc/ ????????

<unmatched-paren>why

<unmatched-paren>ok, apparently this library has only headers

<anadon>Because we can't have nice things.

<unmatched-paren>this is a really bizarre library

<anadon>Header only, tries to handle UTF weirdness.

<unmatched-paren>i've never heard of a multi-header header-only library...

<unmatched-paren>it also provides no pkg-config file

<anadon>Oddly, Antlr4 C++ runtime only seems to care about UTF8.

<anadon>I've put in magic-enum in guix, and it was kinda that was too, IIRC.

<unmatched-paren>i guess you'll want to define the latest utfcpp yourself...

<anadon>Fun. The 'not' is silent.

<unmatched-paren>hey, it could be worse -- at least it doesn't have a hard docker dependency! :)

<unmatched-paren>apparently those exist, according to some more experienced packagers

<anadon>You know. These are dumb headers. Why shouldn't I make`mv` be my install script?

<unmatched-paren>that is basically what happens in the `install` phase of the old utfcpp package

***CodeKiwi is now known as DigitalKiwi

<unmatched-paren>although

<unmatched-paren>i think this latest version has an install phase

<unmatched-paren>from a cursory glance at CMakeLists.txt

<anadon>It is just there to run tests, in effect. Which, tbf, we should do.

<anadon>It looks like it is just an un-augmented cmake build.

<anadon>Not bad AFA updating packages goes.

<anadon>I'm going to put this down for a bit. Got invited over to a friend's house. Friends are cool, like fezzes.

<unmatched-paren>anadon: good idea :)

<unmatched-paren>i'll try to prepare a utfcpp package for you

<anadon>unmatched-paren: Thanks for all the help! I'll see what I can do to get a PR in for updating utfcpp if you don't get to it first.

<unmatched-paren>shouldn't be toooooo hard

<unmatched-paren>bye :)

<anadon>famous last words.

<unmatched-paren>:P

<mekeor[m]>hi guix :)

<unmatched-paren>mekeor[m]: \o

<unmatched-paren>sneek: later tell anadon: i got a utfcpp package working! https://paste.debian.net/1235789/ it should work with pkg-config, though i haven't tested it thoroughly

<sneek>Got it.

<unmatched-paren>sneek: botsnack

<sneek>:)

<meena>heya folks o/~

<meena>I'm just trying to install guix on my elementary OS, using a Fish shell

<meena>every time i run guix it prints:

<meena>well, the stuff that says here: https://guix.gnu.org/en/manual/en/html_node/Application-Setup.html

<mekeor[m]>meena, so it prints advice about locales?

<meena>but i have glibc-utf8-locales installed, and i *have* GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" exported

<unmatched-paren>i think you want glibc-locales, not glibc-utf8-locales

<unmatched-paren>afaik

<unmatched-paren>meena: ^