IRC channel logs

<spiderbit>is autoreconf in autotools or what package do I need?

<spiderbit>ok I think that will be a bigger thing than I thought :D

<Groumf>Could anybody have a look at that? I have a hard time making sense of the trace https://dpaste.com/6J436KUEG

<rekado>I have to leave now, but I’m sure someone here could share an example file with you that shows a rofi package variant that adds the missing inputs and uses the git checkout. It’s not very difficult

<rekado>ACTION –> zzzZ

<podiki>spiderbit: alternatively, there is rofi-calc, a packaged plugin if you want to make another. rofi has a search-path so it should find plugins

<spiderbit>I wonder if it woludn't be more easy and maybe more useful to build this plugin

<spiderbit> https://github.com/marvinkreis/rofi-file-browser-extended?tab=readme-ov-file#installation

<peanuts>"GitHub - marvinkreis/rofi-file-browser-extended: Use rofi to quickly open files" https://github.com/marvinkreis/rofi-file-browser-extended?tab=readme-ov-file#installation

<ulfvonbelow>"(it’s on my wishlist to have a transformation that injects extra inputs)" take mine: https://paste.debian.net/1306424/

<spiderbit>well I think I first need cmake

<peanuts>"debian Pastezone" https://paste.debian.net/1306424

<Groumf>meh I can't even execute the definition from the docs in a guix shell https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html

<peanuts>"Using the Configuration System (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html

<Groumf>Could it be that the doc is just outdated? I think there is something very wrong with my guix if I can't build this. I guix pulled today.

<spiderbit>#:use-module (guix packages xdisorg rofi)

<phoxfyre>Howdy

<spiderbit>hmm how can I use rofi so that the define-module is happy with it

<spiderbit>error: rofi: unbound variable

<spiderbit>hint: Did you forget a `use-modules' form?

<ulfvonbelow>module specifications take the form of a list that represents a directory hierarchy

<ulfvonbelow>so (guix packages xdisorg) represents guix/packages/disorg.scm

<spiderbit>ok makes sense module not package

<ulfvonbelow>to use multiple modules, use multiple #:use-module keywords

<spiderbit>but why is that then correct

<spiderbit>#:use-module (guix build-system cmake)

<ulfvonbelow>e.g. (define-module ... #:use-module (guix packages xdisorg) #:use-module (guix packages rofi))

<spiderbit>hmm don't get it nothing works

<ulfvonbelow>to be clear, you have a (define-module (some module name) ... #:use-module (guix packages rofi)) form in the file you're trying to load, and after that you try evaluating the symbol 'rofi', and it complains about it being unbound?

<spiderbit>yes

<spiderbit>(inputs

<spiderbit> (list rofi))

<ulfvonbelow>hmm, well, when I try looking at gnu/packages/rofi.scm it seems it doesn't exist, so that might explain something

<ulfvonbelow>(the file doesn't exist, that is)

<spiderbit>yes that's why I tried with xdisorg

<spiderbit>it's in there

<spiderbit>but however I combine them

<spiderbit>it does bring the same error

<spiderbit> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/xdisorg.scm#n1968

<peanuts>"xdisorg.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/xdisorg.scm#n1968

<spiderbit>it's there

<spiderbit>no code for module (guix packages xdisorg)

<ulfvonbelow>ahh that's because it's under gnu/, not guix/

<spiderbit>I tried some with that, too :D

<ulfvonbelow>guix/ holds the machinery, and gnu/ holds the package / service / system collection stuff

<spiderbit>ahh ok withouth the rofi

<spiderbit>it worked

<spiderbit>still don't get why cmake is cmake a file / module not a package

<ulfvonbelow>? cmake in (gnu packages cmake) is a package

<spiderbit>can a cli tool get me the hash for the git head?

<ulfvonbelow>if you have it downloaded and checked out, yes, use 'guix hash -x -r .' if it's your current directory

<spiderbit>no I don't have :D

<spiderbit>ulfvonbelow: like that: with a point at the end?

<spiderbit>guix hash -x -r .

<spiderbit>ohh you said it

<spiderbit>did not copy the point

<spiderbit>guix hash: error: unsupported hash format: rofi-fb-extended.scm

<spiderbit>default is for some reason nix-base32

<ulfvonbelow>aye, that's the format that package hashes are stored in

<spiderbit>(sha256

<spiderbit> (base32

<spiderbit>well I have that in my config

<spiderbit>that's from the other plugin

<spiderbit>how do I get a hash that it is ok with

<ulfvonbelow>'base32' in package definitions means nix-base32

<spiderbit>ahh now it says expected hash

<spiderbit>so I can copy that

<spiderbit>or actual

<spiderbit>how can I stop it from trying to make tests?

<spiderbit>phase `build' succeeded after 0.9 seconds

<ulfvonbelow>if there are no tests, or you have a good reason for disabling them, you can add #:tests? #f to the package's argument list

<spiderbit>but then it crashes with check / test

<ulfvonbelow>that is, (arguments (list #:tests? #f))

<ulfvonbelow>but in general an effort should be made to make the tests pass

<spiderbit>I think I have to hmm

<spiderbit>change the plugindir still

<spiderbit>did comment that out because it's different here

<spiderbit>CMake Error at cmake_install.cmake:60 (file):

<spiderbit> file cannot create directory:

<spiderbit> /gnu/store/af3sjq1h5rpirmdfqpiy59z6bbpzjjpg-rofi-1.7.5/lib/rofi. Maybe

<spiderbit> need administrative privileges.

<spiderbit>would that be the right directory?

<spiderbit>because it brings a warning:

<spiderbit>CMake Warning:

<spiderbit> Manually-specified variables were not used by the project:

<spiderbit> CMAKE_INSTALL_LIBDIR

<spiderbit>;; Don't try to install directly to rofi, instead install

<ulfvonbelow>cmake-build-system will set something like -DCMAKE_PREFIX=/gnu/store/...-rofi-1.7.5 and that should be picked up

<spiderbit>;; to lib/rofi to match rofi's search-path ROFI_PLUGIN_PATH.

<spiderbit>that's with the calc plugin

<spiderbit>I am not sure I need to do that here, too

<ulfvonbelow>ah, if it needs to go in a certain subdirectory, then that should indeed be explicitly specified

<ulfvonbelow>CMAKE_INSTALL_LIBDIR *sounds* like the right thing to specify for that, but if it's "not being used by the project", I guess not

<spiderbit>but it's now cmake not the the gnu maketools

<spiderbit>ahh so I can't define that this way

<spiderbit>it's already defined but the project don't cares

<spiderbit>did I understand that correctly?

<ulfvonbelow>I'm not sure what you're trying right now. Are you using cmake-build-system?

<spiderbit>yes

<ulfvonbelow>okay, good

<ulfvonbelow>and it's complaining that it can't create the lib/rofi subdir

<spiderbit>yes

<ulfvonbelow>which is interesting both because it *should* be able to, and because it's warning that it's not using that directory... at the same time as erroring out because it's using that directory

<ulfvonbelow>sounds like something weird is going on in that build system

<spiderbit>ähh it makes sense to me

<spiderbit>I don't use sudo

<spiderbit>yet

<spiderbit>so how could it isnstall something in /gunu/

<ulfvonbelow>there is no sudo or setuid programs in the build environment, and in the build environment, /gnu/store is writable by the build user

<spiderbit>... /gnu

<spiderbit>does it expect the rofi directory

<spiderbit>because that don't exist

<spiderbit>ls /gnu/store/af3sjq1h5rpirmdfqpiy59z6bbpzjjpg-rofi-1.7.5/lib/

<spiderbit>pkgconfig/

<ulfvonbelow>I would assume that a build system would create any nonexistent parent directories

<spiderbit>I just wonder if it knows where to install it correctly

<ulfvonbelow>but you could try adding a phase that creates that directory

<spiderbit>because the bulid system of calc needed to replace it

<spiderbit>so I think it should not be installed there

<spiderbit>;; Don't try to install directly to rofi, instead install

<spiderbit>;; to lib/rofi to match rofi's search-path ROFI_PLUGIN_PATH.

<spiderbit>so I should make the build system let it install somewhere else

<ulfvonbelow>/gnu/store/af3sjq1h5rpirmdfqpiy59z6bbpzjjpg-rofi-1.7.5/lib/rofi is $output/lib/rofi

<spiderbit>that is what I understand from that comment but I could be wrong

<ulfvonbelow>the plugin needs to be installed to the lib/rofi subdirectory of the package's output

<ulfvonbelow>could you perhaps share your package definition so far?

<spiderbit>yes moment

<spiderbit> http://paste.debian.net/1306428/

<peanuts>"debian Pastezone" http://paste.debian.net/1306428

<spiderbit>there could be probably some stuff be cut out but kept it, no expert in this build systems, does cmake create makefiles or something... I never used cmake for own projects :D

<ulfvonbelow>ahhh I understand now

<ulfvonbelow>the store path you mentioned earlier was for rofi, not rofi-file-browser-extended

<spiderbit>yes

<ulfvonbelow>its CMakeLists.txt is doing pkg_get_variable(ROFI_PLUGINS_DIR rofi pluginsdir)

<ulfvonbelow>of course, rofi itself is immutable, so that won't work

<ulfvonbelow>so instead we arrange for a layout so that when the two packages are union'ed, they overlap as they should

<spiderbit>but how can I replace that?

<spiderbit>replace rofi-plugins-dir with "."

<spiderbit>or something :D

<ulfvonbelow>I don't know much about cmake, so I don't know if #:configure-flags #~(list (string-append "-DROFI_PLUGINS_DIR=" #$output "/lib/rofi")) would work

<spiderbit>is that in arguments?

<ulfvonbelow>but I do know that patching that line of CMakeLists.txt to replace pkg_get_variable(ROFI_PLUGINS_DIR rofi pluginsdir) with set(ROFI_PLUGINS_DIR /gnu/store/...rofi-file-browser-extended/lib/rofi) would work

<ulfvonbelow>yeah that's in arguments

<spiderbit>(arguments (list #:tests? #f

<spiderbit> #:configure-flags #~(list (string-append "-DROFI_PLUGINS_DIR=" #$output "/lib/rofi")))

<spiderbit> )

<spiderbit>you meant like that

<spiderbit>this does not work

<spiderbit>still tries to install into /rofi/

<ulfvonbelow>ah, that's too bad

<spiderbit>well

<ulfvonbelow>guess we'll have to add a phase that uses substitute* like rofi-calc does

<spiderbit>yes is it nearly 1:1

<spiderbit>or dös it have to be different because of the other build system

<spiderbit>just replace the strings and the file name?

<ulfvonbelow>nope, substitute* is still available since both build systems make (guix build utils) available, so yeah, all you have to do is replace the match string, replacement string, and filename

<spiderbit>what do you use if I press tab in emacs it uses I think 8 spaces or something in scheme is that standard?

<ulfvonbelow>I think we use spaces for indentation? I'm sure it's documented somewhere

<spiderbit>here it's tabs...

<spiderbit>now I have a mixture of both :D

<spiderbit>looks like you use 2 spaces

<spiderbit>can I tell that emacs somehow...

<ulfvonbelow>in the guix source tree at least it should be automatically using .dir-locals.el

<spiderbit>("plugindir=\\$\\{rofi_PLUGIN_INSTALL_DIR\\}\\/")

<spiderbit> "plugindir=${libdir}/rofi/"

<spiderbit>why is the rofi small here

<spiderbit>I think that was like that in the repos

<ulfvonbelow>dunno, it's just the way the author of the Makefile.am did it

<ulfvonbelow>there's probably some convention behind it

<spiderbit>hmm

<spiderbit>confusing

<spiderbit>(substitute*

<spiderbit> "CMakeLists.txt"

<spiderbit> (("pkg_get_variable(ROFI_PLUGINS_DIR rofi pluginsdir)")

<spiderbit> "(set(ROFI_PLUGINS_DIR {libdir}/rofi/)"))

<spiderbit>that should be right, not?

<spiderbit>-DCMAKE_INSTALL_LIBDIR=lib

<spiderbit>hmm

<spiderbit>(add-after

<spiderbit> 'unpack 'patch-plugindir

<spiderbit>uis that the problem

<spiderbit>does it never patch something?

<ulfvonbelow>you need to escape the parentheses in the regular expression

<spiderbit>the file is there from the beginning

<spiderbit>for set

<spiderbit>"(set(ROFI_PLUGINS_DIR \"{libdir}/rofi/\")"

<libfud>I'd like to try KDE plasma on guix. I'm not sure what I have to do to make gdm allow me to select a plasma session. I've run `guix install plasma-desktop` successfully, but logging out and rebooting do not make it visible.

<spiderbit>like that?

<ulfvonbelow>also, cmake isn't going to expand {libdir} I think

<libfud>I'm guessing there's some configuration to the display manager that I should be setting, but I'm not sure what.

<ulfvonbelow>ah no, the replacement string isn't interpreted specially in any way

<ulfvonbelow>the regular expression however is

<ulfvonbelow>so "pkg_get_variable(ROFI_PLUGINS_DIR rofi pluginsdir)" should be "pkg_get_variable\$ROFI_PLUGINS_DIR rofi pluginsdir\$"

<ulfvonbelow>(double backslashes because it's being interpreted twice - once by guile's reader, then again by the regular expression parser)

<spiderbit>ohh sorry

<spiderbit>my english parentheses not quotes

<ulfvonbelow>and the replacement should be something like (string-append "set(ROFI_PLUGINS_DIR " #$output "/lib/rofi)")

<spiderbit>why \\

<spiderbit>is that regex escaping with 2 \\

<ulfvonbelow>it's because we're first constructing an ordinary string using ordinary string syntax, then that string is getting passed to a regular expression parser

<libfud>also, is there a way to interact with the guix system calls `guix system` via a guile shell rather than bash (or any other sh-clone)

<spiderbit>it's so anoying that I can't look the changed file

<ulfvonbelow>so for example, (display "\(") produces just ( while (display "\\(") produces \(

<ulfvonbelow>you can pass --keep-failed to the command that starts the build and it will copy the build directory to /tmp and show you where it is

<spiderbit>environment variable `ROFI_PLUGIN_PATH' unset

<spiderbit>can I not just set that instead :D

<libfud>disregard my last question, I should have looked a bit harder to see there is a repl

<ulfvonbelow>I would assume even if cmake inherited ROFI_PLUGIN_PATH from the environment, it would still just clobber it as soon as it got to that pkg_get_variable part

<ulfvonbelow>but I could be wrong

<spiderbit>ok

<spiderbit>It's just so frustrating no way to look at this

<spiderbit>generated file

<ulfvonbelow>guix build --keep-failed rofi-file-browser-extended

<ulfvonbelow>ls /tmp/guix-build-rofi-file-browser-extended-VERSION.drv-N

<ulfvonbelow>look for the "keeping build directory" message in the output

<ulfvonbelow>also, you can try running things interactively via 'guix repl'

<spiderbit>(set(ROFI_PLUGINS_DIR {libdir}/rofi/)

<spiderbit>aja

<spiderbit>why is there a ( before it :D

<spiderbit>ohh

<spiderbit>ok was me but yes it does not translate that libdir

<spiderbit>CMake Error at cmake_install.cmake:85 (file):

<spiderbit> file cannot create directory: /usr/share/man/man1. Maybe need

<spiderbit>install(FILES "doc/rofi-file-browser-extended.1.gz" DESTINATION "/usr/share/man/man1")

<ulfvonbelow>looks like it's hardcoding the install path on line 56

<ulfvonbelow>gonna have to substitute that also

<ulfvonbelow>you can add a second clause to the original substitute*

<ulfvonbelow>that looks like (("/usr") #$output)

<spiderbit>do I need as argument the whole line

<spiderbit>or can I just replace strings?

<ulfvonbelow>substitute* will do substring searching

<ulfvonbelow>you can match start and end of line with ^ and $, respectively, if it's needed

<libfud>gdm-service-type is defined, but sddm-service-type is not, even though I have installed sddm

<ulfvonbelow>libfud: gdm-service-type is provided by (gnu services sddm); whether the package is in your profile won't affect whether the module is loaded into the guile that evaluates your operating system config

<spiderbit>("/usr/share/man/man1")

<spiderbit> (string-append #$output "usr/share/man/man1")

<libfud>ulfvonbelow: thank you, I wasn't sure where that was defined

<spiderbit>so something like that should be enough

<spiderbit>right

<ulfvonbelow>minus the usr at the start of the replacement

<spiderbit>k

<libfud>so either (gnu services [xorg|desktop]) provided gdm-service-type

<ulfvonbelow>(gnu services xorg) it seems

<libfud>that makes sense now, but it is a degree of nonsymmetry

<libfud>I appreciate it

<ulfvonbelow>indeed it is

<spiderbit>where do I find the substitute* helf now...

<spiderbit>help

<spiderbit>(substitute*

<spiderbit> "CMakeLists.txt"

<spiderbit> (("pkg_get_variable\$ROFI_PLUGINS_DIR rofi pluginsdir\$")

<spiderbit> (string-append "set(ROFI_PLUGINS_DIR " #$output "/rofi/)")

<spiderbit> ("/usr/share/man/man1")

<spiderbit> (string-append #$output "share/man/man1")))

<libfud>do the services lists use the first values they see, or can later values from the meta-variable override?

<ulfvonbelow>spiderbit: section 8.7.3 "File manipulation" of the manual

<spiderbit>in elisps it's so easy to get help C-h f

<ulfvonbelow>C-h i m guix RET i substitute* RET

<ulfvonbelow>spiderbit: it looks like you've got a four elements after the filename instead of two lists of two elements

<spiderbit> i Show all installed manuals

<spiderbit>doesn't work here

<ulfvonbelow>you might have to add a 'd' after 'C-h i' to get back to the top level listing

<spiderbit>ok I get that far

<spiderbit>ok now it works kind off

<spiderbit>but it's now about substitude server authorization

<spiderbit>not the function or procedure or whatever taht is substitute*

<spiderbit>ok found it

<ulfvonbelow>hmm, I use helm, so I get a list of candidates

<spiderbit>yes me too just a bit slow today :)

<spiderbit>thanks for your help

<ulfvonbelow>👍

<libfud>so after I installed, I ran `guix pull` and `guix package -u`. However, after an earlier failed attempt to run `guix system reconfigure kde-conf.scm`, I saw that it reverted what the pull and package update had done. Did I miss some kind of 'save' step?

<spiderbit>uit seems to have worked

<libfud>*after I installed guix onto a VM I'm testing in

<spiderbit>ls /gnu/store/3kb77lhk2fwhlkybinzlczxfls911vjr-rofi-file-browser-extended-1.3.1/

<spiderbit>is there

<ulfvonbelow>libfud: what did this reverting look like?

<libfud>ulfvonbelow: like I saw that my plasma-desktop package got reverted from 5.27 to 5.25, and that rerunning those 2 commands restored it

<libfud>guix describe also has a different result now. I can try to paste that for the prior generation and the current generation, if that's possible

<libfud>is paste.debian.net curl-able?

<ulfvonbelow>not sure, I've never tried it, but there is a debpaste emacs package

<libfud>well I'm being silly anyway, no reason I can't run a browser in the VM

<libfud>except it's not installed I guess

<spiderbit>hmm just rofi don't know about it ;D

<ulfvonbelow>libfud: after running 'guix pull' for the first time after installing, did you source ~/.config/guix/current/etc/profile or start a new login shell or anything like that?

<libfud>ahhh, I think I did?

<spiderbit>do I have to maybe install rofi as user to find the plugin or somthenig

<libfud>I may have done that *before* the pull though. Let me check history.

<libfud>ok, this'll be good. paste in a minute

<podiki>spiderbit: for rofi to find plugins they need to be in the same profile, e.g. guix shell rofi rofi-file-browser-extended

<ulfvonbelow>spiderbit: in order for rofi to find the plugin, it needs to be in ROFI_PLUGIN_PATH

<podiki>that will be set automatically if rofi is in the profile

<ulfvonbelow>in order for a profile containing a rofi plugin to know to set ROFI_PLUGIN_PATH, it also needs to have rofi in it, since that's where the environment variable is defined

<podiki>and plugins should be in lib/rofi of the packages output

<spiderbit>is it because I used only build

<spiderbit>no "install"

<podiki>yes

<spiderbit>$ guix shell rofi rofi-file-browser-extended

<podiki>do guix shell rofi <your plugin> -- rofi .....

<spiderbit>guix shell: error: rofi-file-browser-extended: unknown package

<libfud> https://paste.debian.net/1306434/

<peanuts>"debian Pastezone" https://paste.debian.net/1306434

<podiki>well where is it defined? you can use -f if you have it defined in a file

<spiderbit>still not there

<spiderbit>not detected

<spiderbit>guix shell rofi -f rofi-fb-extended.scm -- rofi

<libfud> https://paste.debian.net/1306435/

<peanuts>"debian Pastezone" https://paste.debian.net/1306435

<podiki>spiderbit: what was the command you used to build it?

<spiderbit>guix build -f rofi-fb-extended.scm

<podiki>try "guix shell rofi -f rofi-fb-extended.scm -- ls $GUIX_ENVIRONMENT/lib/rofi"

<podiki>or at least look at "tree -aC $(guix build -f rofi-fb-extended.scm)" and see where the library you build ends up

<spiderbit>no such file

<libfud>what modules do you need to load in geiser to replicate `guix repl`?

<spiderbit>rofi -f rofi-fb-extended.scm -- ls $GUIX_ENVIRONMENT

<spiderbit>rofi-fb-extended.scm rofi-fb-extended.scm~

<podiki>ah sorry, shell environment

<podiki>just do the guix shell part, and then after do the ls part (the variable is evaluated early i think)

<ulfvonbelow>could also do sh -c 'ls $GUIX_ENVIRONMENT'

<podiki>right, something to delay evaluation

<spiderbit>[env]$ ls $GUIX_ENVIRONMENT/lib

<spiderbit>gdk-pixbuf-2.0 pkgconfig

<spiderbit>or do you mean in /rofi/...

<podiki>okay, so you aren't building the plugin in the right directory

<podiki>it needs to output in its /gnu/store/<hash>-<pkg>-<version>/lib/rofi directory

<podiki>the output of the "tree" command earlier, or something similar, will help you see where the plugin is being built to

<spiderbit>... /gnu/store/wi37abh6xvwkispnldn0wv5kzp5bbfw1-rofi-file-browser-extended-1.3.1/rofi/filebrowser.so

<spiderbit>wait a second does it overwrite the old filebrowser maybe?

<podiki>it needs to go to lib/rofi not just rofi

<podiki>because rofi will look in lib/rofi for plugins

<spiderbit>(("pkg_get_variable\$ROFI_PLUGINS_DIR rofi pluginsdir\$")

<spiderbit> (string-append "set(ROFI_PLUGINS_DIR " #$output "/rofi/)"))

<spiderbit>is that not correct?

<spiderbit>ohh rofi

<spiderbit>lib/rofi?

<podiki>lib/rofi

<spiderbit> • +filebrowser

<spiderbit> • file-browser-extended

<spiderbit>ok now it's there

<podiki>say it together now, lib slash rofi

<podiki>woo

<spiderbit>but that still sucks slightly :D

<spiderbit>because I can't fire up each time a shell

<podiki>so just install it

<spiderbit>that makes a huge delay

<podiki>shell caches though, only first time is slow assuming nothing changes

<podiki>guix install -f rofi-extended-whatever.scm

<spiderbit>now it's always slow

<spiderbit>but whatever install

<podiki>guix shell should be near instantaneous if nothing has changed

<spiderbit>hmm no install don't has -f

<spiderbit>no it takes like 5 seconds

<spiderbit>for a thing that should happen in far below 1 seconds not fast enough :)

<podiki>then guix install $(guix build ....)

<podiki>shouldn't take 5 seconds, something is not quite right then, but anyway

<spiderbit>it installs

<spiderbit>but...

<spiderbit>rofi doesn't find it

<libfud>why do so many DE's insist on binding M-space

<podiki>presumably guix output something about search paths, since you now have an environment variable ROFI_PLUGIN_PATH

<libfud>finger's crossed this finally works and I can start kicking around a plasma shell session

<podiki>so follow the hint guix gave about sourcing a profile, or better just re-login so it works everywhere

<spiderbit>yes that confuses the heck out of me also everytime it says something with my search paths is wrong

<spiderbit>sure it's a "hint"

<podiki>because that variable wasn't set when you logged in, so your environment doesn't have it

<libfud>does guix work with intel AX210 chipsets?

<libfud>er, sorry, libre linux

<spiderbit>and why are there 2 alternatives

<podiki>you should be sourcing what it gives you or else you'll be missing things, like rofi not finding a plugin :)

<podiki>i don't know what you mean

<spiderbit>guix package --search-paths -p "/home/black/.guix-profile"

<spiderbit>that does not fix it

<podiki>that just tells you want variables it would set

<podiki>but you need to source the profile

<spiderbit>my user profile

<spiderbit>or /etc/profile

<podiki>i would suggest logging out and back in here, since presumably you want to call rofi not just from one shell

<podiki>i would read this if you haven't already, or re-read for more info look here

<podiki>whoops

<podiki> https://guix.gnu.org/en/manual/devel/en/html_node/Getting-Started.html

<peanuts>"Getting Started (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/Getting-Started.html

<spiderbit>well executing tihs 2 lines

<spiderbit>does not change anything

<spiderbit>but I logout

<libfud>is `guix upgrade` an alias for `guix package -u` or does it do something else?

<podiki>libfud: i believe alias yes

<libfud>podiki: is there a way I can get more debugging output, or drop into a guix shell when an error occurs?

<spiderbit>so no rofi still don't know about it :)

<podiki>libfud: the output should point you to a log if something went wrong

<podiki>spiderbit: did you follow the manual link above and make sure you are sourcing your profile?

<podiki>i assume if you do echo $ROFI_PLUGIN_PATH it is not set

<spiderbit>yep

<podiki>right, so you did not source the profile

<spiderbit>I put the 2 lines in my .bash_profile

<podiki>and $HOME/.guix-profile/lib/rofi has your plugin?

<podiki>you installed both rofi and your plugin with "guix install" ?

<libfud>podiki: https://paste.debian.net/1306439/

<peanuts>"debian Pastezone" https://paste.debian.net/1306439

<spiderbit>yes the file is there

<spiderbit>yes that could be the problem

<spiderbit>with the install

<libfud>not sure where the log is, but maybe I'm just being oblivious

<spiderbit>BUT

<spiderbit>the environment variable should be set

<spiderbit>no matter how I installed rofi right?

<podiki>libfud: you have an error in your system configuration

<podiki>spiderbit: no. rofi and the plugin must be in the same profile (e.g. guix install by default)

<podiki>typically you have your user profile (guix install) and system profile (system configuration); some (like me) use more profiles. but either way they must be in the same profile. that's how search-paths work, the package and whatever it is looking for need to be installed together

<spiderbit>ok

<spiderbit>that and copy this 2 lines

<spiderbit>brought it up

<spiderbit> GUIX_PROFILE="/home/black/.guix-profile"

<spiderbit> . "$GUIX_PROFILE/etc/profile"

<spiderbit>that 2 lines

<spiderbit>now it's there

<spiderbit>now I have to lougout again but well my first real package kind of :)

<podiki>woop

<podiki>search-paths are confusing :)

<spiderbit>as painful as that was, still better than in nixos :)

<podiki>search-paths really test if you know how some stuff in guix works: profiles, how packages can find each other, environment...

<libfud>I'd hate to have to learn a DSL on top of learning an API

<libfud>or library, or however you'd like to describe what the system config in guile scheme is.

<podiki>and then you will be experienced and realize the manual had what you needed, it is just a big adjustment

<podiki>well the beauty is that package definitions and your system config are the same, just scheme code (with some guix sugar on top)

<libfud>I'm not sure the manual really covers the pain points I'm experiencing very well.

<spiderbit>yeah it's a bit scattered around

<podiki>libfud: what is your system configuration?

<spiderbit>especially as elisper you have scheme to undertand

<libfud>the issue I have, podiki, is hidden state

<libfud>the one I currently use or the one I'm trying to install

<libfud> https://paste.ddebian.net/1306440/ is what I want to accomplish, but it has that error

<podiki>your error you shared is telling you something is wrong with the services you are trying to use

<libfud> https://paste.debian.net/1306440/ *

<peanuts>"debian Pastezone" https://paste.debian.net/1306440

<libfud>how can I see what the contents of %desktop-services is

<ulfvonbelow>echo -e '(use-modules (gnu services desktop))\n,pp %desktop-services' | guix repl

<spiderbit>Ok I log out now to get in in the profile again thanks for the help and I am out...

<ulfvonbelow>or look at ~/.config/guix/current/share/guile/site/3.0/gnu/services/desktop.scm

<spiderbit>cia

<libfud>ah, right. guix shell.

<libfud>s/shell/repl

<libfud>I'm a bit sick today, not thinking at my best

<libfud>what module has pprint

<ulfvonbelow>(ice-9 pretty-print) has pretty-print

<ulfvonbelow>you may want to replace %desktop-services with (map (compose service-type-name service-kind) %desktop-services) in that input to 'guix repl' if you just want a list of the names

<ulfvonbelow>... after first including (gnu services) also

<libfud>thank you

<libfud>I wasn't aware of compose before

<libfud>are `services`, `operating-system` and some of these other guix bindings syntax macros?

<ulfvonbelow>indeed. They are themselves produced by the define-record-type* macro.

<libfud>ok, I guess that explains the funkiness I'm encountering

<ulfvonbelow>what sort of funkiness?

<libfud>in guix repl, if I just type `service`, I get a syntax error.

<libfud>That doesn't happen if the binding is for a variable or procedure

<ulfvonbelow>I actually don't even understand why service is a macro. It could be implemented as a function just fine from the look of it.

<PotentialUser-95>Hey. I'm trying to download the guix system ISO but I get the following?

<PotentialUser-95>"Could not fild the requested build product."

<jmes>PotentialUser-95: That output is not familiar (to me) - what exactly are you trying to do when you get that error? With what software?

<PotentialUser-95>I am just trying to get the ISO installer from the guix.gnu.org website. When I click on the x86_64-linux link, I get that

<libfud>does it matter exactly where the --on-error=[strategy] argument goes when invoking guix system reconfigure? it doesn't seem to change anything for me, neither giving more information with backtrace, nor dropping into a guix repl with debug

<jmes>PotentialUser-95: okay, so if you try downloading it in a shell with `wget https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso' does that work?

<PotentialUser-95>I'm not on a gnu/linux system. I'm in the process of switiching over you see

<libfud>on windows you can click that link, wget just does it from a terminal

<jmes>Gotcha, well that link is working for me via browser

<jmes>The error message you were seeing comes from your web browser?

<PotentialUser-95>Yes, that's what I get in my web browser

<libfud>I'm able to download it (and it's the same one I downloaded earlier today)

<jmes>If you can, try a different browser or look up alternative methods of downloading on the system you are on. Also, the link I provided is the "standard" ISO, if that doesn't work try the "latest" variant.

<jmes>Not sure why that would matter though, they both seem to work for me.

<PotentialUser-95>Weird, I did try two different browsers. I'll see if I can get it through powershell, if there's a wget equivalent

<PotentialUser-95>I can get the 1.4.0 version, just not latest

<jmes>PotentialUser-95: oh I lied! The latest does indeed give me that error

<PotentialUser-95>Ah, so not me being silly then haha

<jmes>Well it won't matter. Guix is rolling release, you'll just have to update the system after you get installed to catch up with the latest guix

<PotentialUser-95>Yeah, I can get 1.4.0. Is it possible for me to get the stable version and update~

<PotentialUser-95>yeah thought so, thank you

<jmes>Yes, absolutely. No problem.

<PotentialUser-95>Have a lot to learn, I'll be sure to message here if I have anymore questions

<jmes>But that is something for the site maintainers, the link is actually broken!

<jmes>Have fun, Guix is awesome.

<libfud>lol I just saw this when I ran `guix system edit gdm`

<libfud>;; Since GDM depends on Rust ... and Rust is currently unavailable on non-x86_64 platforms, default to SDDM there (FIXME).

<libfud>There's a lot of interest in rust in my industry, but the lack of first class support for things that aren't amd64 or aarch64 kills it

<libfud>AHH! I wonder if this is it! The login-manager-service-type setting of xorg-configuration

<libfud>extraneous field initializer :(

<jmes>I have had that error many times messing with services. Can't remember what caused it though :P

<lechner>rekado / dthompson said earlier today not to use that code anymore. he recommended we switch to (haunt html)

<ieure>Who should I talk to about getting a patch into core-updates? I have a package that needs a newer icu4c than Guix has, and I just realized that's an input to glibc. So, not going to get accepted as part of my patch for a new package.

<ulfvonbelow>does it use icu4c directly or via glibc?

<ieure>It uses it directly.

<ieure>I know I can add icu4c-73 to avoid disrupting other packages.

<ulfvonbelow>then couldn't you just add an extra version of icu4c?

<ulfvonbelow>ah okay

<ieure>dYes. I coul.

<ieure>*could

<ieure>But since core-updates seems imminent and is going to cause a world rebuild, it seemed like a good thing to have on folks' radar.

<libfud>does anyone here use KDE?

<ieure>Probably not, since Guix doesn't have KDE packages.

<libfud>I really want to get into guix but not getting that is a pretty hard non-startert for me. ieure that's not true.

<ieure>Hm, guess you're right. Thought I was reading in the manual that it didn't have KDE, maybe it was an old version.

<libfud>that was the case for a long time, I only picked it up today because I saw that it had it now

<libfud>but if I can't actually log into it, then it's not really meaningful

<ieure>Nope, it's in the current manual: https://guix.gnu.org/en/manual/devel/en/html_node/Limitations.html

<peanuts>"Limitations (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/Limitations.html

<ieure>Hopefully it's the manual that's wrong.

<libfud>I believe it's the perennial bane of documentation, being out of date.

<libfud>More documentation, more places to fall out of date.

<ieure>Yeah, seems like it, other parts of the manual mention plasma-desktop-service-type.

<libfud>well, I guess the errors were superfluous... I'm still disconcerted by them, however.

<libfud>logging into plasma-desktop from sddm after rebooting

<libfud>anyone know if the Intel AX210NGW wireless card will work with linux libre?

<ieure>libfud, It won't.

<libfud>ahhhhh, damn

<libfud>I'm very certain the mediatek whatever-the-hell-it-is in my laptop won't either

<ieure>libfud, Far as I know, the only PCIe WiFi that has free drivers is the ath9k, and it's several years old.

<libfud>it also didn't work with the nonguix image I tested earlier

<libfud>ieure: then what do people using linux libre do for laptops???

<ieure>libfud, I have no idea, USB dongles?

<libfud>Wild. I thought the intel chipsets were supposed to be good for that.

<ieure>No, definitely not, never have been as far as I know.

<ieure>Clarifying, the *Linux drivers* are open-source, but they upload a proprietary binary firmware blob which the card doesn't work without.

<ieure>Which is how basically all that stuff works. Got WinModem'd to death... if anyone else is old enough to get that.

<libfud>Yeah, I kind of figured then. I was only a kid when I used modems, so I'm not entirely sure what you mean.

<libfud>I just remember the load noises, unstable connection, and AOL disc spam

<libfud>s/load/loud

<ieure>libfud,

<ieure>libfud, Used to be that a modem was full of individual parts and you talked to it over a serial link and anything with an RS-232 port could use it.

<ieure>libfud, Then the WinModem launched, and it used a DSP instead, and a Windows driver that uploaded the firmware to make it do stuff. Without the Windows driver, and the blob it loaded, they couldn't be used at all.

<libfud>before they got integrated into the computer with a more direct interface, like in POS compaq prescario we had

<ieure>But because they were cheaper to make, they were everywhere, and there were lots of clones.

<libfud>Ah. I didn't try out linux til I was a senior in HS, and I didn't seriously use it til a few years after that.

<ieure>So what use to be a rather simple affair -- pick a modem, buy it, use it -- became much more difficult, as you had to figure out ahead of time whether it was a Real Modem or one of these crappy soft-modem deals.

<libfud>I have the *immense pleasure* of regularly working with Rs-232 and RS-422 now.

<ieure>I first installed Slackware 2.1 around 1994 or 1995, off floppy disks I made from a Walnut Creek CD-ROM, onto a 386SX-16 with 2mb RAM (which required stripping stuff down to even get Linux to install).

<ieure>So... been at it a while.

<libfud>I was 5 in 1994 lol. We didn't get our first computer til 2000. My problems with linux were of the 'pulseaudio crapped itself again' variety

<ieure>Anyway; point is, a ton of hardware is like that now. It's half software, and that stuff's the stuff the manufacturer is least likely to open up. So they don't.

<libfud>Tell me about it. Getting vendors to tell us wtf is going on with their crap is like pulling teeth. Half the time the documentation is out of date, lies by omission, or lies outright!

<ieure>Software is much the same.

<libfud>my patience outside of work for sysadmin stuff is a lot less than it was before I got a job in software engineering

<libfud>if I can force myself to learn guix to the point that it's useful and I know what the edges are, I figure it should be mostly better than sticking with fedora

<ulfvonbelow>re: pci-e wifi, there's also b43

<ieure>Never been a fan of RedHat stuff. Tried it a couple times back in the 90s, always had problems.

<libfud>I think, however, that's going to involve going the nonguix route, which I know isn't sanctioned here. I'm personally more of the mind that perfect is the enemy of good, and ultimately I choose pragmatism over idealism.

<ieure>Seeing where they are now, I'm glad I didn't invest much energy.

<ieure>I'm of much the same mind.

<libfud>ieure: For whatever reason, I've never had HW issues with Fedora, Scientific Linux, and CentOS, but I did with debian and Ubuntu

<libfud>It does annoy me that the trend is in the 'wrong' direction, so pragmatism means continuously losing ground.

<libfud>At the very least, guix solving the insane environment replicability problems (or 99% solving it), is very strong incentive for me to get with it

<libfud>trying to install ruby 2.5.4 (compat with old software I need) on modern Fedora and Ubuntu is maddeningly difficult

<ulfvonbelow>hmm, what is one supposed to do when a pyproject.toml includes no build-backend entry and the default of setuptools.build_meta doesn't work?

<sham1>The reproducibility story will probably get even better once we can do stuff such as mount / as tmpfs and do the whole "Erase your Darlings" setup that people over in NixOS land sometimes do

<sham1>At least then you wouldn't have random bits and pieces of system state floating around

<lilyp>ulfvonbelow: write the developers a nicely worded mail

<libfud>the other big problem I see in tech, or at least in the way it affects my industry, is 3rd party package managers in the vein of pypy and node

<libfud>vulnerable, and highly insistent that the network is always available

<ulfvonbelow>I'd add cargo to that list

<libfud>yes, cargo is also in that same school

<ieure>Yes, sick of them.

<lilyp>Let's add Maven: all of the above, plus "binaries are all you'll need anyway"

<ulfvonbelow>in updating some rust packages I discovered that apparently some packages are in the habit of changing between using hyphens and using underscores

<ieure>My work has a bunch of stuff written for Amazon CDK, using Python. But the runtime is nodejs, and the Python (and every other) SDK has some cursed autogenerated code and fires up a node process that it talks to over pipes. So we have to stack two layers of this trash, one for Python and one for node.

<ieure>I really hate JavaScript, but I'd have picked that over Python and this pain.

<ulfvonbelow>you try to run 'guix import' with the hyphen, only to find it's not there anymore. That stuff is going to keep typosquatted malware in business.

<lilyp>For all its fault as a language, without Node, Javascript is pretty sane.

<libfud>I agree, but get other developers to use it without node

<ulfvonbelow>what bugs me the most about the language-specific package managers is that they seem to make packages *too* tightly interconnected, especially regarding versions.

<lilyp>hear, hear

<ulfvonbelow>if you have 3 dependencies and they each "churn" at a given rate, you're going to end up churning even faster, it seems. And anything with you as a dependency is going to churn faster still.

<sham1>lilyp: Maven is not the funnest thing to bootstrap, no. Having to go through Ant and all that jazz just to get to the most recent Maven

<sham1>But I will defend Maven as a build system until everyone's ears fall off. It's great

<sham1>It's super declarative

<sham1>And at least it's saner than Gradle

<lilyp>"at least it's saner than Gradle" is not a great argument in its favor though

<efraim_>If you're looking to work on rust packages I suggest the rust-team branch, there's been a lot of package updates there

<lilyp>And Maven's flaws already expose themselves once you consider Ant+Ivy.

<libfud>the proliferation of python tools like poetry and its ilk, and they all have problems

<ieure>Python packaging got so bad. It was never great, but it's absolutely the worst now.

<libfud>incompatabilities between the 3.x versions are also very frustrating

<libfud>I think a broader range of people are starting to realize the vulnerabilities of node/pypy/cargo & co. It'd be nice if there were a movement to correct it, but I kind of doubt that. Anyway, thanks for the help earlier.

<sham1>The problem with trying to correct the mistakes of cargo, node, pypy, etc. is that those tools are so entrenched that the effort needed would probably simply not be worth it for most developers

<frafra>hi :) is there a good way to install guix without being root?

<snape>frafra: https://hpc.guix.info/blog/2017/10/using-guix-without-being-root/

<snape>frafra: there is this too: https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org

<peanuts>"guix-notes/GUIX-NO-ROOT.org at master ? pjotrp/guix-notes ? GitHub" https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org

<snape>tldr: it's tricky

<civodul>Hello Guix!

<janneke>hello civodul!

<civodul>hey on-line version of janneke :-)

<civodul>heck, i wish were all hacking in the same building

<civodul>*we were

<civodul>the Liberating Parens HQ

<janneke>aww, that sounds wonderful

<janneke>let's pretend that we are, a virtual building for now

<futurile>morning guixers!

<civodul>hey futurile! moin!

<civodul>janneke: virtual building, indeed

<janneke>at least we managed to meet on the same planet :)

<civodul>right!

<civodul>it was great to get the energy from everyone there, both the old guard and new people

<civodul>like this futurile person ;-)

<janneke>yes!

<futurile>janneke: next time maybe we do Guix days in chamonix, then we can go skiing/boarding ;-)) - then I can combine two great loves

<civodul>that’d be fun

<civodul>though we’d have to be cautious :-)

<janneke>futurile: (y)

<janneke>hehe

<futurile>civodul: where does the project traditionally put the 'raw notes' that everyone wrote from the sessions?

<futurile>Pjotr asked for a blog post which makes sense - and then we can link to the deeper notes for thost that want to read more - but I don't know where those are going

<civodul>futurile: we started collecting them here: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024

<peanuts>"guix-days-2024\doc - guix/maintenance.git - Articles, talks, and documents for Guix maintainers" https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024

<civodul>we might still be missing a couple of them?

<civodul>but yeah, a blog post summarizing the topics and maybe some of the discussions would be awesome

<futurile>OK cool - I'll nudge it along

<efraim_>We clearly need to buy that castle

<civodul>efraim_: yup! :-)

<jpoiret>yet another propagated inputs annoyance: libraries using the C Python code need to have libcrypt available as well, but we wouldn't want to propagate libxcrypt to all users of python

<civodul>jpoiret: hey! you’re looking into libc 2.39?

<jpoiret>yes :)

<civodul>that libcrypt thing seems to be making things more difficult than we’d hope, right? :-)

<civodul>what’s your take on 2.38 + patches vs. 2.39?

<jpoiret>for now I'm still hopeful for 2.39, I'm building back up to gnome, and most of the annoying dependencies didn't cause any problems. But yeah the libxcrypt situation is a bit annoying

<jpoiret>choosing the right way to propagate the dependency is annoying

<civodul>ok

<jpoiret>2.38 + patches would work well I think

<jpoiret>like, without any additional issues

<jpoiret>wouldn't it be crazy if we had "intents" rather than just packages as inputs?

<jpoiret>like "yes i want to link against python" and "yes i want to use the python interpreter"

<jpoiret>that way we could propagate the proper things for each use

<jpoiret>sometimes you might want to do different things with the same output (or maybe it could be split up into multiple outputs)

<jpoiret>ghc and rust are building, which are the two main blockers usually

<jpoiret>is Guix usually present at ACM REP?

<jpoiret>this year it's at Inria Rennes

<jpoiret>ah, you're the on the PC civodul :)

<frafra>snape: thanks; I was a bit worried following a 7 years old guide :)

<jpoiret>eh, last year's program didn't seem that interesting

<snape>frafra: don't worry both links are still solid stuff

<civodul>jpoiret: full disclosure: i’m also working with others on a paper about the SWH/Guix connection for that conference

<civodul>(i won’t be reviewing it :-))

<civodul>but yeah, this looks like a nice conference for the researchy people among us

<jpoiret>you're not reviewing your own paper? missed occasion tbh

<jpoiret>"strong accept - this paper is the best there is"

<civodul>heh

<civodul>anyone knows how long files remain on files.pythonhosted.org (for PyPI)?

<civodul>i can’t seem to find a definite answer

<apteryx>civodul: perhaps ask in #python

<rekado>lechner: I just tried with (haunt html); it does not convert the literal non-breaking space to an entity.

<dthompson>is it supposed to? let's fix that :)

<dthompson>I guess no one, myself included, has tried using non-breaking spaces with haunt yet

<rekado>our old copy of your code—what later became (haunt html)—does convert a bunch of characters to their entity representations

<rekado>(including things like em spaces)

<dthompson>I found that that was only necessary because I wasn't using utf-8 encoding

<dthompson>with utf-8 encoding none of that seemed necessary and of course there were characters that were left out of that old version so it seemed like the more robust way to go

<dthompson><!DOCTYPE html> at the top of the document signifies utf-8 encoding

<dthompson>if there are still characters that need special handling I'd like to find a definitive list and fix this properly

<rekado>we are emitting DOCTYPE html, but firefox complains: “The byte stream was erroneous according to the character encoding that was declared. The character encoding declaration may be incorrect.”

<jpoiret>don't you need <meta charset="utf-8"> in the head instead?

<jpoiret>well maybe not instead but additionally

<dthompson>jpoiret: oh that might be it

<dthompson>I have that on my blog

<dthompson>sorry I guess I misremembered...

<jpoiret>it should be in the first 1024 bytes of the page as well

<dthompson>figured it out at one point and then it fell out of my brain I guess

<rekado>the page in question: https://issues.guix.gnu.org/63508#4

<dthompson>what if you try <meta charset="utf-8">?

<peanuts>"[PATCH v2 0/4] Have udevadm look in /etc/udev/rules.d" https://issues.guix.gnu.org/63508#4

<jpoiret>they're apparentnly equivalent

<dthompson>I should try to reproduce this with haunt when I have a chance...

<jpoiret>something could genuinely not be utf-8 in the stream 🤔

<sham1>You should set the Content-Type header appropriately still

<rekado>sham1: is it not?

<sham1>Well, is it?

<sham1>I can't curl it or look at it properly rn

<bdju>anyone else get a segfault trying to launch lxappearance? running sway. https://0x0.st/Hk3t.txt

<jpoiret>sham1, rekado: it's unset so it should be fine no?

<sham1>IIRC without Content-Type, it assumes that the encoding is basically Latin1

<sham1>As per HTTP

<rekado>wget tells me that the server returns only “Content-Type: text/html”. It should include the charset here IIUC.

<sham1>Yeah

<rekado>I wonder if that’s an nginx setting we’re missing or if the application that nginx proxies to needs to do something to tell nginx what content type to return.

<sham1>I'd imagine that the proxied app should just add its own Content-Type, since it knows what it should be the best

<sham1>But don't quote me, I'm not an expert in nginx

<apteryx>where is an infinite loop likely to occur in guix when there are cycles in package graphs? transitive-inputs ?

<libfud>is it a difference between shepherd and systemd that necessitates entering the password to decrypt a luks partition twice on boot?

<apteryx>no, that's because /boot/grub is on / which is encrypted

<apteryx>so the first prompt (which takes forever) is from GRUB, the second from the kernel Linux

<libfud>ahh, yeah, that makes sense

<libfud>fedora sets up a different set of partitions and has an unencrypted /boot

<apteryx>right

<libfud>I'll remember when I set up a partition table on a laptop to keep /boot separate

<apteryx>it's not supported out of the box in Guix System

<apteryx>you have to keep a manual script/job to copy kernel files to there

<apteryx>I've been meaning to add a 'standalone-boot?' switch to the grub config or somewhere, but haven't got around yet

<libfud>where are kernels kept normally in guix

<apteryx>see: https://issues.guix.gnu.org/48172

<peanuts>"support split /boot partition" https://issues.guix.gnu.org/48172

<libfud>apteryx: maybe if I have enough time this weekend I can try tackling that issue

<libfud>Is there any reason the 'workaround' approach as a first implementation would be inappropriate?

<dthompson>rekado: fwiw my site return text/html for content type

<libfud>I suppose it would require some flag in the configuration, and to modify the package definition for the kernel (and initrd and related packages) to check for that, then run a script to install those files there

<apteryx>the workaround is OK but it keeps piling stuff in /boot, doesn't prune no longer relevant things, which a proper solution should

<dthompson>returns*

<libfud>apteryx: ah yes, that is a problem

<libfud>you need to keep the stuff for your active kernel, and some n-1 newest kernels

<apteryx>rekado: re firefox byte stream error from mumi sites, I've tried to understand that, and failed thus far. I guess the *content* we serve has a different encoding, perhaps?

<apteryx>the page is announcing the right encoding.

<apteryx>perhaps the email parsed content added to the page is not in UTF-8 or something?

<rekado>there’s a literal non-breaking space in the output. I wonder if there’s something *else* in there that causes Firefox to guess a different encoding.

<apteryx>looking at commit e4259d4e9e3251e4c4b45d1cce4008ac32b504c8, "Derivation-level cycles are not detected."; I think that's what I'm trying to debug with my pkgconf aspkg-config endeavour

<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e4259d4e9e3251e4c4b45d1cce4008ac32b504c8

<apteryx>it'd be nice if peanuts could pull the commit message summary

<peanuts>apteryx: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot

<apteryx>lechner: I like the bot by the way!

<apteryx>I've gotten used to specify bug by just their IDs and have the bot help expand it to their URL with title in context.

<jpoiret>oh no, segfault in librsvg tests :(

<apteryx>2.40 or recent one?

<jpoiret>2.56.4

<jpoiret>but on c-u with libc 2.39

<apteryx>OK; could it be a rust-related thing? (perhaps a newer rust isneeded for glibc 2.39?)

<libfud>why isn't $HOME/.guix-profile/etc/profile sourced in .bashrc or .bash_profile?

<rekado>(only ever source it in .bash_profile, lest you break “guix shell”)

<libfud>ok, but it seems like it'd be a good thing to have in .bash_profile, unless I'm missing some magic that happens when you start a new shell after updating

<rekado>Guix prints a notice the first time this becomes necessary

<apteryx>libfud: anything referenced from the grub.cfg menu entries, basically

<jpoiret>huh. building it again and no segfault

<jpoiret>i hate when that happens

<janneke>yay rust, a "safer and more secure" c

<rekado>is it expected that Python from Guix loads (incompatible) Python modules from ~/.local/lib?

<rekado>it appears to *prefer* Python modules from there.

<jpoiret>janneke: it's probably due to the C dependencies though

<rekado>I can prevent that with “python3 -I”, but I would have thought that Python from Guix would look for modules on GUIX_PYTHONPATH *first*

<apteryx>rekado: that's by design

<apteryx>it allows virtualenv to work as intended (users can override system provided libraries)

<rekado>hmm

<rekado>caught us by surprise: https://github.com/BIMSBbioinfo/flexynesis/issues/46

<apteryx>there was some idea/patch floated around that added a python switch/env var to script wrappers to change that behavior

<peanuts>"Guix installed flexynesis attempts to access user installed packages ? Issue #46 ? BIMSBbioinfo/flexynesis ? GitHub" https://github.com/BIMSBbioinfo/flexynesis/issues/46

<rekado>I guess I’d have to modify the wrapper to pass “-I” to have Python ignore ~/.local/lib.

<apteryx>rekado: some of it was discussed in #64573

<peanuts>"[PATCH 0/3] guix: build: python-build-system: Have applications by default ignore non-Guix libraries in user site dir" https://issues.guix.gnu.org/64573

<alethkit>Is the only supported bootloader for Guix System GRUB?

<alethkit>I'm wondering whether it's safe to go for a bcachefs-only root configuration

<apteryx>rekado: looks like we should use the EXTERNALLY-MANAGED file to avoid this

<apteryx> https://peps.python.org/pep-0668/#recommendations-for-distros

<peanuts>"PEP 668 ? Marking Python base environments as ?externally managed? | peps.python.org" https://peps.python.org/pep-0668/#recommendations-for-distros

<apteryx>here's an example from Arch: https://gitlab.archlinux.org/archlinux/packaging/packages/python/-/blob/main/EXTERNALLY-MANAGED

<peanuts>"EXTERNALLY-MANAGED ? main ? Arch Linux / Packaging / Packages / python ? GitLab" https://gitlab.archlinux.org/archlinux/packaging/packages/python/-/blob/main/EXTERNALLY-MANAGED

<apteryx>it basically breaks 'pip install --user'

<apteryx>printing an error like: error: externally-managed-environment with the content of that file

<rekado>I’m not much of a Python user, but breaking pip seems … undesirable, no?

<apteryx>on ne peut pas sauver le choux et la chèvre ;-)

<rekado>:)

<apteryx>it does seem undesirable, but if the distribution world has moved toward that direction and people are now mostly using pipx, perhaps that's OK

<rekado>I have transitioned to *recommending* the use of “pip install” from within a “guix shell” that provides *most* packages, here at the MDC

<rekado>this is the first time I hear of pipx

<apteryx>that`s because some packages are missing?

<apteryx>seems like a clone of pip that manages virtualenvs automatically, providing isolation

<apteryx>[missing in Guix] ?

<rekado>yes, missing in Guix or virtually impossible to package

<apteryx>hm.

<miro`>Hello, I am trying to integrate a package into guix but I have a problem when I build my xmake.scm file. The error is invalid field specifier

<miro`>However, I specified all the required fields

<jpoiret>need some packaging advice: with glibc 2.39 python requires libxcrypt as a replacement to the libc's removed libcrypt. So python extensions linking against it also need to have libxcrypt available. We could add -Lpathtolibxcrypt to the recorded python config flags, but then it would retain a reference to libxcrypt

<rekado>miro`: can you show the full error message, please?

<rekado>can you also paste your xmake.scm (not here but link to a paste please)

<jpoiret>other solutions are: 1) manually adding a libxcrypt input to all the affected packages 2) propagate libxcrypt from python :(

<miro`>I'm brand new to irc and guix, I have no idea how to do this..

<jpoiret> https://paste.debian.net lets you do that

<peanuts>"Debian Pastezone" https://paste.debian.net

<miro`>thank you, here is the file: https://paste.debian.net/1306500/

<peanuts>"debian Pastezone" https://paste.debian.net/1306500

<rekado>miro`: it’s the source field

<rekado>the (sha256 …) should be part of the (origin …) expression

<rekado>the (build-system …) expression also needs changing

<rekado>should be cmake-build-system instead of just cmake

<rekado>and you likely need a couple more module imports

<apteryx>jpoiret: linking to libxcrypt with Python conf looks like the least effort short term, perhaps with a note mentioning 'remove and add libxcrypt to each package explicitly requiring it'

<rekado>e.g. (guix build-system cmake), ((guix licenses) #:prefix license:), etc

<rekado>apteryx: +1

<jpoiret>apteryx: ah, but I was thinking this is the better solution long term, although it increases the closure

<jpoiret>the problem is that there's no difference between python the interpreter that people might install to use and python the thing you want to link to

<jpoiret>but if that seems okay I'll try to go this way then

<apteryx>I'm not sure how widespread relying on libxcrypt is, but I was assuming it's not that common to propose explicitly adding libxcrypt where it's needed in the future

<miro`>/rekado cmake-build-system is an invalid field: error: (cmake-build-system): invalid field specifier

<miro`>

<rekado>(build-system cmake-build-system)

<jpoiret>well if you use the autoconf macros to link against python you do need libxcrypt :(

<snape>ci.guix.gnu.org seems to have not built anything for quite some time

<apteryx>ah! another good reason your linking solution then :-)

<apteryx>without the note I suggested, since it doesn't make sense

<miro`>Ok, another question. is use-modules necessary? and in what cases should it be used? because I have /home/miro/personal/guix/packages/xmake/xmake.scm:9:16: error: git-fetch: unbound variable

<miro`>hint: Did you forget a `use-modules' form?

<rekado>snape: https://ci.guix.gnu.org/workers says it’s busy

<peanuts>"Workers status" https://ci.guix.gnu.org/workers

<rekado>miro`: yes, it’s like “import” in Python.

<rekado>all these things are defined in Guile modules that need to be imported first

<rekado>git-fetch is provides by (guix git-download)

<snape>rekado: I can't make much sense of this interface

<snape>where does it say it's busy?

<rekado>snape: what you see there is representations of build machines and their free slots.

<rekado>wherever you see something colorful: that’s an ongoing build

<rekado>odd, though, that https://ci.guix.gnu.org/metrics reports 0 completed builds in the last 24 hours (with the exception of dover)

<peanuts>"Global metrics" https://ci.guix.gnu.org/metrics

<snape>that's my point

<rekado>yes, looks like you’re right

<apteryx>civodul: I spotted some 'logging' code in monads.scm: (format (current-info-port) ...)

<rekado>I picked an arbitrary build and it’s been going for 113155 seconds: https://ci.guix.gnu.org/build/3394671/details

<peanuts>"Build 3394671" https://ci.guix.gnu.org/build/3394671/details

<rekado>(just restarted it to see what happens)

<snape>thx

<rekado>only that build

<rekado>will check the cuirass logs next

<apteryx>that'd better be expressed as (log-debug ...) assuming we had something like https://issues.guix.gnu.org/68946

<peanuts>"[RFC PATCH 0/1] Add logging capability to Guix" https://issues.guix.gnu.org/68946

<rekado>cuirass says that polling jobsets expires

<jpoiret>why would one need to -lcrypt to link against python though 🤔

<rekado>there are two “cuirass evaluate” processes running. I guess these, too, will time out.

<apteryx>jpoiret: python3.pc has 'Libs.private: -lcrypt -ldl -lm'

<rekado>aside from that, pending builds aren’t processed. See https://ci.guix.gnu.org/jobset/master

<atw>if anybody wants an easy patch: dutree's home-page is broken. It should probably be https://lib.rs/crates/dutree or https://github.com/nachoparker/dutree

<peanuts>"master" https://ci.guix.gnu.org/jobset/master

<peanuts>"GitHub - nachoparker/dutree: a tool to analyze file system usage written in Rust" https://github.com/nachoparker/dutree

<jpoiret>apteryx: that's for static linking right?

<apteryx>pkg-config confuses the private thing

<jpoiret>why does this pkg-config thing seem like it's being brought up all the time these days

<jpoiret>yeah I know, but the intent is that right?

<rekado>cuirass-remote-server has nothing to download from workers. Not good.

<jpoiret>here it's not even pkg-config causing that issue, but the autoconf macros

<apteryx>because meson generates .pc files

<jpoiret>(python has specific autoconf macros)

<apteryx>that embeds lots of private stuff

<apteryx>at least that's probably one of the reasons

<rekado>I wonder if this is related to reconfiguring the build nodes, which is what I did during FOSDEM.

<jpoiret>if it's used by python3's pkg-config then we will actually *need* to propagate libxcrypt, not just change the recorded LDFLAGS

<rekado>ACTION restarts cuirass

<apteryx>pkgconfg wouldn't need it for dynamic linking

<apteryx>would avoid us having to propagate it or hacking the .pc files

<miro`>rekado, so something like that : https://paste.debian.net/1306503/ ?

<apteryx>pkgconf*

<peanuts>"debian Pastezone" https://paste.debian.net/1306503

<apteryx>jpoiret: rereading what you wrote, ugh, the provided autoconf macros expect to find it at all time... OK

<apteryx>maybe we could patch that out

<jpoiret>apteryx: but we're not close to having pkgconf, right?

<apteryx>very close

<jpoiret>oh, you managed to debug the cycle?

<apteryx>it's just a weird cycle I've been trying to debug

<apteryx>shaving yaks on the way

<apteryx>I think it's a derivation level cycle

<jpoiret>i don't think having pkgconf is going to be enough though, we'll also need to patch the .pc files, no?

<apteryx>not caught by our current simple package cycle detector

<civodul>rekado: was Cuirass stuck or something?

<apteryx>jpoiret: easiest would be to patch the .pc files yes

<rekado>miro`: more like this: https://paste.debian.net/1306504/

<peanuts>"debian Pastezone" https://paste.debian.net/1306504

<rekado>miro`: it doesn’t use CMake, as far as I can tell. But it still doesn’t build.

<apteryx>the private fields are not useful when dynamically linking ELFs that embed the necessary information already; I think it's for static compilation.

<rekado>civodul: yes. No builds for at least the last 24h, builds reported as ongoing but sitting idle for hours, etc.

<apteryx>which is seldom used in Guix, but ideally should be left intact in case users want to do so

<rekado>snape: seems to be working now

<rekado>snape: thank you for the report!

<civodul>uh

<snape>rekado, thank you!

<jpoiret>apteryx: it's mostly broken by the couple of packages we have where the static output is separated

<jpoiret>that can't be accounted for by pkg-config

<miro`>ok thank you!! I'll try to debug why it doesn't build

<rekado>miro`: probably something missing in the build environment. You may need to read their configure script to figure out why.

<apteryx>jpoiret: someone producing a static program would need to manually install all the packages, but at least the .pc files would hint as which are missing

<rekado>civodul: probably related to my “guix deploy” to the build farm during FOSDEM.

<jpoiret>even then, pkg-config wouldn't be able to find the static output's lib directory, since it's not recorded in there

<miro`>I no longer have the impression that I am not building the right directory but it is strange that it cannot find the files ./configure: line 808: /tmp/guix-build-xmake-2.8.6.drv- 0/source/core/src/tbox/tbox/src/xmake.sh: No such file or directory

<rekado>miro`: I see that this is a subtree. You’ll need to use (recursive? #t) in the (origin …) and update the hash.

<rekado>invalidate the hash by changing one 0 to a 1, then add the (recursive? #true), then rerun the build, then fix the hash.

<apteryx>or use the new fancy 'guix download -g ...' to avoid downloading it twice

<apteryx>something like 'guix download --git --commit=some-sha1 --recursive URL'

<miro`>Maybe I went too quickly in learning guix, but I didn't understand your message :)

<jpoiret>apteryx: I'll just propagate libxcrypt from python

<jpoiret>I don't like it, but it's the policy we have right now for pkg-config Require.private

<apteryx>jpoiret: alright!

<jpoiret>damn, everyone with a python dependency will have libxcrypt propagated. That's terrible

<jpoiret>all of this trouble when it's only needed for a module that's going to be removed in 3.13 :(

<apteryx>can you get by by hacking the .pc file?

<jpoiret>I could but it's non-standard compared to what we do currently

<jpoiret>what kind of hack do you mean? Removing -lcrypt or adding the proper -L?

<apteryx>removing -lcrypt from the private field

<jpoiret>I bet that's going to cause issues down the line for some static linking

<jpoiret>we might not static link a lot but python's definitely involved

<jpoiret>uh, well maybe we don't static link against python

<apteryx>to be seen; do we have statically linked packages that have python has inputs?

<apteryx>as input*

<libfud>I had no clue that ncurses was required for the `clear` command in bash

<dthompson>libfud: haha I feel like every guix user learns this fun fact at some point

<dthompson>I certainly remember when I learned it

<libfud>it's the kind of thing that I think I learned 10 years ago, and then forgot because it never was a problem to me again in the intervening time

<libfud>I usually go more on the 'kitchen sink' side of installs, because I'd rather get stuff done than worry about 'bloat'

<bost_>Hi. Is there a function to determine if an s-expression contains a particular s-expression? (Don't want to reinvent the wheel.)

<zamfofex>libfud: I never need to notice, because I always just use ‘ctrl‐L’ for it. 😄

<vagrantc>whow. i have not even touched the patch flow discussion on guix-devel@ ...

<libfud>zamfofex: that doesn't do the same thing, believe it or not

<lilyp>bost_: probably something close to that in sxml (try sxpath?)

IRC channel logs

2024-02-06.log