IRC channel logs

<jonsger>so something pulls in a package from this list guix refresh --list-dependent python-jupyter-client

<ajarara>big list. I dropped down to base-services + elogind and removed i3. I'm going to try to bust up base-packages as well.

<janneke>ajarara: a meme that works for me: find /gnu/store -maxdepth 1 -name '*.drv' | xargs grep ...python-jupyter-xyz.drv

<ajarara>ha, sure.

<freakingpenguin>Does anyone have an example of using $ guix substitute --query? It seems a bit finnicky.

<freakingpenguin>Ah, I just needed to prepend the word 'have' to my request. Nevermind.

<Trevoke>Hey folks! Brand-new to guix. How do I find what package a binary may belong to? Specifically some of the otherwise standard ones, e.g. "file" ?

<janneke>chances are the weight-watchers-team could remove this dependency too

<freakingpenguin>Trevoke: If you already have it built, $ guix locate <binary>.

<Trevoke>freakingpenguin unfortunately I'm in a situation where I find that the binary is either required for compilation (a package I can't find on guix) or required to troubleshoot a problem (e.g. a stackoverflow answer)

<Trevoke>Maybe next question: is there a pattern for package names that I can rely on to do my guesswork? I've already found that programming language libraries tend to be called [language]-[libraryname] and that various compilation tools tend to be suffixed with -toolchain

<ajarara>I think it's brought in by gnome. That command brings up a font as the most likely entry point. Though that font (nor gnome) is not explicitly in my config (and doesn't show up if I grep the store for it). Will continue digging.

<ajarara>yep, it was this bit in services that looked benign: (set-xorg-configuration (xorg-configuration keyboard-layout keyboard-layout)), generated as part of the guix installer

<janneke>i believe it's font-abattis-cantarell

<ajarara>yep, looking at the package description for it gave me the gnome tip. Moving back to %desktop-services from %base-services + elogind also brings it in.

<podiki>Trevoke: the package for file is....file! guix locate only helps locate things you have already unfortunately, though to do this more generally is certainly a request....(shouldn't hard to hack up given guix locate exists already, something for the build farm)

<podiki>guix search can help, or i sometimes resort to general internet search if it ends up being obscure

<Trevoke>podiki thanks - yeah, that would be really nice, because "finding the package I need by whatever name was chosen by people who were not me" is a lot of shooting in the dark :(

<Trevoke>In case anyone here is an emacs user who uses the vterm package - I know I could use the emacs-vterm guix package, *but* I have a need to keep my emacs config distro- and OS-agnostic. So I tried to add all the dependencies to build it to my guix home config, including eventually libvterm itself, but while it does build successfully (I think), I get

<Trevoke>this error: "Module could not be opened: "/home/trevoke/.emacs.d/elpa/vterm-20241118.1627/vterm-module.so", "libvterm.so.0: cannot open shared object file: No such file or directory""

<Trevoke>Am I really stuck using the emacs-vterm guix package, or is there something else I'm just not doing that I should be doing?

<Trevoke>vterm-module.so does exist in the vterm-2024* directory but no libvterm.so.0 there, if that matters

<PotentialUser-30>I installed guix package manager on Ubuntu 24. What should I do to resolve this error? guix pull: error: remounting /gnu/store writable: Permission denied

<PuercoPop>Trevoke: You can keep your emacs config distro agnostic but still use guix to install all the packages your config uses

<gigak9>Hi, brand new to guix and I'm getting the reconfigure error from jupytext mentioned earlier. Looks like jupyter-client build is failing, possibly related?

<gigak9>(also don't understand why a font needs jupyter but like I said, brand new here...)

<olafes>in #:make-flags this works: (string-append "prefix=" %output)

<olafes>is there a way to refer to package inputs in make flags in similar way?

<olafes>#:make-flags (string-append (assoc-ref %inputs "libdrm" "/lib/libdrm.so")) - how to make this work?

<Trevoke>Where can I find documentation on the various services provided? I have found in the code a service called `home-xmodmap-service-type` and it does a few things which I'm not familiar enough with shepherd or GUIX to understand

<Trevoke>PuercoPop: ah neat, thanks

<Trevoke>(TLDR: I want my caps lock key to be a control key)

<Trevoke>Pre-GUIX, I had a `setxkbmap` call in my .bash_profile -- and maybe that's still how I should do it in GUIX, though in that case it means I need to execute some code in my home config / bash service, and I haven't found how to do that either

<olafes>What's the proper way to refactor `(string-append (assoc-ref inputs "gcc") "/bin/gcc")` to make it respect --with-c-toolchain?

<olafes>Looking at the output of `guix build clang-toolchain`, the bin directory contains `cc`, so my question is: does default toolchain also produce cc or is it just gcc? (How to check that?)

<podiki>Trevoke: documentation is your friend: https://guix.gnu.org/manual/devel/en/html_node/Desktop-Home-Services.html

<podiki>also https://guix.gnu.org/manual/devel/en/html_node/Keyboard-Layout.html

<jakef>whenever i relog, another instance of all my shepherd daemons starts and the old ones are still running xD

<jakef>using GDM display manager FWIW

<jakef>when i reboot, i get back to having only 1 instance of each daemon running

<jakef>i might submit a bug cause i didn't see this before shepherd 1.0

<olafes>How to make guix explain why a dependency is being pulled in WITHOUT building the package to the end?

<efraim>olafes: perhaps guix graph will show you? It doesn't list all the paths that pull in the package but will give you a good idea of what is pulling in a dependency

<zlqrvx>Hi, I am trying to package fbterm. I have it building (https://bpa.st/KO2Q), but there are still several todo items. I would appreciate any suggestions.

<csantosb>Trevoke: documentation about services is in 11.10 Services and 13.3 Home Services, right ?

<csantosb>`home-xmodmap-service-type` is under 13.3.8 Desktop Home Services

<rekado>oh, numba fails to build since the python-team merge.

<rekado>will try to upgrade it.

<janneke>rekado: the python branch seems to have been problematic in a few ways

<janneke>it was merged(?) at a time when a test failed on master, it broke a test and quite some python packages do not build,...but also it seems it carried two year old commits?

<janneke>ACTION wonders if we can/should learn from that

<efraim>rekado: does it just need python-setuptools and python-wheel added?

<efraim>IIRC the python-team branch got overrun with no one shepherding it for a while and had a bumpy merge but should be better going forward

<janneke>ah, that figures

<janneke>efraim: yesterday i found that, even with the gcc wrappers in gcc-4.7, gcc-13 still doesn't build for me

<janneke>i've pushed a commit to not use gcc-13 for clang-runtime (as a comment mentioned that would be preferred), but we'd still want gcc-13 to build i guess :)

<efraim>I've fallen behind a bit on the other architectures trying to play catchup with rust on aarch64 and riscv64 on master, and making sure the mesa branch looks like it'll be good

<janneke>it came a lot further, a weird erron in libstdc++-v3

<efraim>yeah, it seems like it should be available in general, but clang needed it for its newer runtime, which it should get just fine from gcc-14

<janneke>=> https://dezyne.org/janneke/hurd/nyxp2g2il9bg1p3aw72hk1d788xqxf-gcc-13.3.0.drv.gz

<efraim>IMO we should make a gccgo-toolchain tracking the current gcc version and possibly drop some of the extra gccgo versions

<janneke>efraim: yeah, thanks a lot for all your work on this

<rekado>efraim: no, it's a bit more involved

<rekado>it fails because of the numpy version bump

<rekado>so it needs upgrading

<rekado>I had contributed to the python-team branch before, but lost energy when all the other branches got merged

<rekado>the branch got too big and rebasing was terribly difficult

<janneke>yeah scope creep can be very hard to avoid, you'd have to know which package update[s] cause[s] an update-storm

<efraim>I think I fixed my mistake for x86_64 on the wip-riscv-bootstrap branch. Time to see if I can get it in a good-enough state for nearly-there

<janneke>istm that versioned dependency ranges are rarely well discribed

<janneke>oh nice!

<efraim>I have like 800 lines of uncommitted changes, plus some fixing up to do, so that'll be "fun"

<efraim>I had hoped to nerd-flex by bringing my ibook g4 running guix system to guix days but I don't think I'll have time to hack it together by then :/

<janneke>hehe

<janneke>oh, the python branch merge broke my python-numpy gcc-14 build fix/upgrade altogether too

<efraim>I wonder if I can stick u-boot in an HFS partition and boot with EFI. Then I can have a "magic blob" partition for booting instead of actually needing to figure out packaging and dealing with HFS+

<janneke>:-(

<janneke>ACTION spent a whole night getting python-numpy to build on core-package-team...

<efraim>ok, initial look-through is a no-go on u-boot on my powermac

<janneke>hmm...the build-system for python-numpy was changed

<janneke>dude

<rekado>janneke: from python-build-system to pyproject-build-system? Or do you mean upstream?

<rekado>wrt lessons learned from python-team: I think we've already changed things here. This branch had been started when core-updates was still a thing.

<efraim>"small number of changes, merge frequently"

<rekado>since we're no longer doing that we should be able to avoid these very long lived branches that will have to be rebased on top of massive core-updates changes.

<efraim>or "small number of changes, fix fallout, merge, repeat"

<homo>it's very surprising to see how many python packages got upgraded in few days, almost all git logs are about python

<rekado>homo: that's years in the making. These were made on the python-team branch and regularly rebased.

<janneke>rekado: yes, =>pyproject-build-system but the change seems not to have as much impact as i feared...i got "pyproject-build-system" undefined errors after my patch inadventently reverted to the python-build-system

<janneke>efraim: yeah, "core-updates open" used to become some kind version-bump dumping ground -- however good the intentions were

<rekado>another lesson: when a branch is close to finished, please don't ask for another fundamental change to be snuck in to avoid another round of rebuilds.

<rekado>in the worst case that extra change can cause widespread breakage and deplete motivation of other contributors to fix the branch yet again.

<rekado>yet another lesson: upgrade Python things more often.

<rekado>we are upgrading leaf packages as needed while neglecting more fundamental packages, because upgrading them would cause a lot of rebuilds.

<rekado>(e.g. python-attrs)

<rekado>and so we're spanning a wide range of releases, stretching as far as we possibly can, patching requirements to avoid upgrades, until it all snaps and someone's got to upgrade all those unloved foundational packages.

<rekado>this reminds me... didn't we have a python-science branch that was supposed to track the python-team branch?

<janneke>possibly a (the?) new weight-watchers-team (dis-closure-team?) could alslo help, cutting dependencies for some core packages or targets may greatly help the speed of build iterations

<rekado>I think it contained numpy 2 and other big changes.

<janneke>ACTION agrees with rekado that splitting the archive is unwise, at least at the moment, but still believes that making things more loosely coupled could really help

<rekado>janneke: yes, it would certainly help

<rekado>with Python in particular it would also help to try again to do without propagated inputs.

<efraim>I like the dis-closure-team but it sounds like a poorly named security-team

<janneke>yeah, weight-watchers-team is probably just as fun and a better name

<rekado>(this would allow for having different package versions without conflicts)

<janneke>ah!

<efraim>mrustc 0.11.0 got released, with support for rust-1.74. still need to fixup other architecture support

<homo>btw, I wonder why builds at https://guix.gnu.org/en/download/latest/ don't have digital signatures

<rekado>homo: because people sign releases here; these builds are not signed by people, so they are not signed at all.

<homo>they aren't counted as substitutes when they come from substitute server?

<rekado>substitutes are something different

<janneke>ACTION fixes python-numpy build on core-package-team \o/

<janneke>and pushes squash! commit

<homo>automatic signature would be helpful in situations when release is not available for certain hardware or there is critical vulnerability or when driver plainly crashes, in my case I had to explicitly write in kernel-arguments modprobe.blacklist=amdgpu as it made screen completely frozen

<rekado>janneke: \o/ woo

<dariqq>can I maybe interest someone in skipping tests for skia on 32bit platforms? I looked a bit into them in #73575 and it looks like something is overflowing. After the node update this would make mate build again without any hacks on i686-linux (the cantarell font depends on skia)

<janneke>oh my, why are there so many llvm's (11, 13, 15) in my system closure?

<janneke>and ironically, even now we've switchet to gcc-14, llvm-14 seems to be the only one missing

<janneke>ACTION would rather avoid an llvm-14 bump and do that as a separate effort

<efraim>rust uses 13, 15 and 17 currently

<homo>1 version of rustc uses 3 different versions of llvm at the same time?

<efraim>no, it switches over time, the last one uses 17

<janneke>efraim: right

<dariqq>hmm while the python-werkzeug failure was fixed now numpy and scipy fail their tests (which are also only needed because of skia and cantarell font). Maybe it would be easier to not pull in the entirety of python because of a font

<janneke>dariqq: python-numpy builds (again) on current master

<dariqq>janneke: for i686-linux? I had a couple of test failures

<janneke>dariqq: for x86_64-linux, haven't checked i686-linux

<janneke>ACTION notes another potential weight-watchers-team member

<janneke>fwiw, i had to disable more python-numpy tests yet on core-package-team

<dariqq>ACTION meant pandas and not numpy

<janneke>ACTION 's /remark still holds with s/numpy/scipy

<janneke>eh, except for the core-package-team work

<nutcase>Hi, after the python updates got merged, a package (trash-cli) does not build anymore. Is this something that should've been recognized by QA?

<PotentialUser-59>hi gnus, the package server web seems down It seems that the Data Service is not accepting requests or it is taking too long to respond. You should try again, maybe it was just a blip. https://packages.guix.gnu.org/search/?query=minetest ;(

<Rutherther>PotentialUser-59: have you considered using guix search?

<PotentialUser-59>oh i just wanted to report this, i can use the cli for sure

<janneke>efraim: crap, trying to build gcc-11 i get a -Wincompatible-pointer-types problem

<janneke>just when i'm near the end of another world rebuild :( :( :(

<dariqq>hmm scipy reports 20 faiels tests but these seem to be non fatal (compared to python-pandas and python-pytest-regressions). Anyway I successfully reconfigured my 32 bit mate desktop now

<janneke>ACTION goes to see if they can just replace the `relax-gcc-14s-strictness' stage in gcc-11 which should be near-trivial thanks to efraim's foresight suggesting such a stage

<janneke>then we can move the new stage to gcc-4.7 as part of the next world rebuild

<janneke>ow crap no, that just as much influences gcc-final, causing a world rebuild

<janneke>hmm

<janneke>ACTION goes to create and a gcc-11-fixed package instead

<Trevoke>csantosb: you know what's weird - documentation on the xmodmap service is not in https://guix.gnu.org/manual/en/guix.html but it *IS* in the guix-emacs package.

<janneke>aaand gcc-11 now fails with the same error as gcc-13 fails => https://dezyne.org/janneke/hurd/nyxp2g2il9bg1p3aw72hk1d788xqxf-gcc-13.3.0.drv.gz

<efraim>I guess consistency is good

<janneke>what a day...

<janneke>true, one fix may well fix both

<fingu>hey guys

<fingu>can i compile shepherd without guix?

<fingu>is there any info on using it as the init system?

<Trevoke>fingu: I'm pretty new to all of GUIX but you can get the source code for shepherd and read its manual here https://www.gnu.org/software/shepherd/download/

<Trevoke>I imagine that at least the core information would be there, though maybe not a tutorial in replacing systemd or anything like that, not yet

<fingu>yeah i have, but it seems like it needs guix (the package manager) to even build it first place

<Trevoke>fingu I don't know if that's true, though it might be convenient to set up the dev env with a guix shell? https://git.savannah.gnu.org/cgit/shepherd.git/tree/README only shows you need Guile and Fibers (and make and such) ?

<Trevoke>.. Although the readme does point us to a file called INSTALL which seems to not be present in the latest commit, which is odd

<fingu>i'm doing that right now, but i wouldn't really like to be tied down to the package manager

<Rutherther>fingu: shepherd should be normally buildable by using autotools, configure and make, what seems to be the issue with that?

<fingu>i don't see any docs..

<Rutherther>it doesn't need any docs, it's standard gnu autotools stuff

<cbaines>I'm stuck reconfiguring bayfront: error: #{ %make-service-type-procedure/abi-check}#: unbound variable

<fingu>would you please then tell me how to compile it?

<fingu>standard make all/compile don't really are there

<janneke>fingu: the usual autoreconf -vif, ./configure; make?

<fingu>to be fair, i've never used autotools, thanks

<janneke>ACTION finds a possible hack around the gcc-11/13 troubles

<janneke>and coins new stage: add-after 'unpack 'patch-compatibility.cc--how-ironic

<janneke>compatibility.cc is not compatible with gcc-14

<janneke>sigh

<janneke>/gnu/store/3a9v2afjncjbhz0zlkxkiyikr3r2n0nm-gcc-fixed-11.4.0 => \o/

<Trevoke>Hey y'all, is there anywhere a flow written out, best practices, for bringing in something that has programming language packages? e.g. there's an old version of anki in guix because, according to a comment, "newer versions have nodejs dependencies that aren't in guix"

<jsbiff>Hey all, I'm wondering if it's safe to run multiple instances of guix at the same time? Problem: I kicked off a "guix build --no-substitutes emacs. It looks like that will take a very long time. In the meantime, I thought I'd like to install openjdk to use java. Can I get away with opening a new terminal window/tab, and running "guix package -i

<jsbiff>openjdk@17.0"?

<jsbiff>s/emacs\./emacs"\./

<Rutherther>jsbiff: yes, it is definitely safe for builds. I am not sure about changing permanent profiles, like running two install instances at the same time

<Rutherther>running build & install is okay for sure

<jsbiff>Thanks - I thought it should be, but wasn't sure

<jsbiff>I would agree about not trying to do two installs to the same profile at the same time. Seems like you could do, e.g. an install in one tab and something like guix shell in another tab - because the shell is it's own installation environment, right? Also, on a multi-user system, two users should be able to add or remove packages in their own user

<jsbiff>profiles, right? Seems like that would be completely separate operations?

<homo>that's the exact use case mentioned in website/documentation

<Rutherther>yes, I was talking about installing to the same profile

<Rutherther>so it of course applies only to guix home reconfigure and guix system reconfigure

<jsbiff>Right - that's what I thought you meant

<jsbiff>Thanks. Gonna drop, but appreciate the help

<z572>janneke: On my computer, automake@1.17 always backcompat2 nodef nodef2 failure on the test, see https://0x0.st/XFtF.17.drv, you can be successful there?

<homo>I wonder does amdgpu without proprietary firmware work with at least 1 card, maybe it's best to disable it in kconfig until free firmware is available, for now I have to explicitly blacklist it in modprobe to avoid kernel becoming completely unresponsive

<podiki>i've booted using nomodeset with linux-libre on recent amd cards, has basic functionality at least

<homo>does it run gdm and wayland?

<podiki>this was a long time ago, but if i recall i could use gdm and get to a desktop; this was on X though

<podiki>it was limited to something like 1024x768 resolution; presumably no real acceleration features

<janneke>z572: i've updated automake to 1.17 on the core-package-team branch, where are you at?

<z572>on the core-package-team branch too

<janneke>z572: weird, no i haven't seen that problem

<janneke>now that gcc-11[-fixed] builds with gcc-14, i'm looking at gcc-8

<janneke>hmm, bisecting gcc versions might be smarter, oh well

<Trevoke>Here's a chunk of the modmap service documentation, which says it swaps caps lock and control, but ... are the 'add' commands correct? It looks like it adds Lock to Caps Lock again? https://pastebin.com/J81c8BvC

<z572>janneke: When I reconfigure the system, and herd restart guix-daemon, the problem disappears, which is kind of weird.

<civodul>why oh why does python-gitpython depend on git instead of git-minimal/pinned?

<rekado>civodul: perhaps it predates the introduction of git-minimal/pinned

<Trevoke>Where in the documentation is 'file-like object' defined? I'm trying to make a simple service that runs setxkbmap as part of my home config

<civodul>hmm not sure, or maybe it became more ingrained or something

<janneke>z572: `interesting...

<janneke>ACTION notes civodul as another potential member of the weight-watchers-team / dis-closure-team

<Trevoke>Shouldn't this work? `(home-environment (keyboard-layout (keyboard-layout "us" #:options '("ctrl:nocaps"))))` ? I am getting "extraneous field initializers (keyboard-layout)" but ... I _think_ the documentation says this is ok? and I saw something quite like it in a video on youtube (

<Trevoke> https://www.youtube.com/live/4lJaVzxO_Bs?si=vtPnqoEra-kt2JwP&t=2049 )

<efraim>is there a keyboard-layout fied for home-environment?

<Trevoke>efraim I don't think I've seen anywhere what a home-environment is and isn't allowed to have

<efraim> https://guix.gnu.org/manual/devel/en/html_node/index.html section 13 is where the home configuraiton lives, but 13.3 is where it really goes through service by service

<Trevoke>all I want to do is have my caps lock key be mapped to control. I've tried with xmodmap service. I've looked for a way to run setxkbmap as part of bashrc. I'm now looking for a way to redo the keyboard layout *somehow*. I've spent a lot of hours looking up how to do something that I thought would be pretty trivial.

<Trevoke>Yeah, I think the problem is that searching for 'home-environment' through the entire documentation didn't get me anywhere that looks like "what a home environment declaration is allowed to have", so pointing me to the documentation again won't move me forward, I'm afraid :(

<efraim>what desktop are you using? When I was using enlightenment I had to do it through their GUI keyboard configurator

<Trevoke>I mean at the moment it's XFCE but, well, this is the reason I wanted to do it at the setxkbmap level

<Trevoke>Shouldn't it be really straightforward to set up a service in home-environment that runs setxkbmap?

<efraim>so looking back at the home-xmodmap-service-type, it is confusing me too, but I think that's the xmodmap being confusing

<efraim>I can get it to make sense if I separate the action and the key

<Trevoke>It _looks_ like a simple service based on bash/zsh/whatever-service and running the *rc thing should do it but I cannot find out how to execute setxkbmap from there, I went and looked at the gexp but I ended up more confused than before I read the docs

<efraim>so unmap Lock from Caps_Lock, "swap the names of Caps_Lock and Control_L", and then map Lock to our new Caps_Lock

<efraim>I've never actually used xmodmap before though, in Guix or outside of it

<Trevoke>oh. my. god. I think I had figured it out but I was missing a single quote. Hold on.

<Trevoke>Nope. This is wrong and I don't know how to fix the argument for the bashrc thing, it has to be a file-like object. Sorry for the 5-line paste

<Trevoke> 29 (define set-caps-lock-to-ctrl-service

<Trevoke> 30 (simple-service 'set-caps-lock-to-ctrl-service

<Trevoke> 31 home-bash-service-type

<Trevoke> 32 (home-bash-configuration

<Trevoke> 33 (bashrc

<Trevoke> 34 '("setxkbmap -option 'ctrl:nocaps'")))))

<efraim>you'll have to use a paste service like paste.debian.net

<Trevoke> https://pastebin.com/LZS4K0LV

<Trevoke>Instead of a string it has to be a file-like object but the documentation in gexps left me really confused about which of them would execute anything

<efraim>you could try '("setxkbmap" "-option" "ctrl:nocaps")

<Rutherther>Trevoke: stuff like setxkbmap better goes to something that run once, and on xorg init. What that is can depend on login manager and desktop environment you are using

<Trevoke>Rutherther do I then misunderstand that home-environment services are intended to run only on login?

<Trevoke>efraim no dice I'm afraid, it's mad about the type of the list, it should be ... something other than a list.

<Trevoke>Documentation about #'bashrc says it has to be a file-like object.

<Rutherther>Trevoke: uhh. home services do not run on login. They do something on activation that happens when you reconfigure. And what they do depends on what you specify. Here you are telling it to put something to your bashrc. Bashrc runs with every bash session.

<Rutherther>maybe you confused home-environment services with shepherd services?

<Trevoke>Rutherther alright so. setxkbmap has been in my bash_profile for probably over a decade. I really just want a thing that will run whether I'm in X or in a terminal and set me up so that caps lock operates as a control. Where and how should that go?

<Trevoke>I mean I dunno, maybe? I have 16 hours of experience with guix and 12 of that are difficulty reading the docs

<Rutherther>Trevoke: I would consider profile better than bashrc, still not the best, but both will work. Since as you are saying it wants file-like object, you ccan use "(plain-file "profile" "<contents of the file, so the setxkbmap command>")", and to make it profile, do not assign it to bashrc, but to bash-profile (just s/bashrc/bash-profile)

<Rutherther>you might also have to put it to a list, I am not sure. So it would be "(list (plain-file ...))". I am sure it will work with the list, not sure if without it. Anyway if you wanted to add more stuff, list will be better

<Trevoke>Rutherther Okay... So... if I have 100 lines in my bashrc, those 100 lines of bash become a multi-line string in the guile file that holds the home-environment declaration (or some submodule that holds the bash_profile declaration) ?

<Trevoke>Or would they each become an element in the list you just mentioned?

<Trevoke>*bash_profile sorry

<Rutherther>Trevoke: can be any of those, it's up to you. You can also just use the file you already have and local-file function "(local-file "./.my-bashrc")" and it will use that file

<Trevoke>Rutherther I think I am beginning to understand. A last question -in the sample home env file, it generated something like this: `(bash-profile '(local-file "~/.guix-config/.bashrc" "bashrc"))` - what is that second argument to the local-file function/declaration?

<Rutherther>oh right. My example wouldn't work actually. The second argument is name that goes to the store, the resulting file will end up as "/gnu/store/<hash>-bashrc". You usually don't need to specify the second argument, but only some names are accepted. One of the rules is that there cannot be a dot in the name. local-file takes name of the file from first argument as name, but since it has a dot in this case, it will end up in an error, hence the second...

<Rutherther>... argument that makes a name without dot

<civodul>janneke: weight watchers :-)

<civodul>i wonder if the Data Service collects info about closure size

<civodul>would be interesting!

<Trevoke>Rutherther thank you! I think I have all the bits I need to get going now, much appreciated

<yarl>Hmmm, I am trying to cross building a system image, I have this error:

<yarl>build of /gnu/store/4cp5ynqp76afzlv1h6rwb2idc251x3s3-elfutils-0.187.drv failed

<yarl>Could not find build log for '/gnu/store/4cp5ynqp76afzlv1h6rwb2idc251x3s3-elfutils-0.187.drv'.

<yarl>That's annoying I can't see the log :(. First time I see this.

<janneke>civodul: yeah, that name was coined by apteryx

<janneke>i got my inspiration for a dis-closure-team from cryptsetup, after creating a cryptsetup-minimal on core-package-team

<janneke>=> The ruby-asciidoctor dependency pulls-in pandoc, 316 ghc packages, and 204 ruby packages, for documentation only.

<Rutherther>yarl: if you are cross building on x86_64 to aarch64 linux, the error is "error: ‘__pread_alias’ writing 58 or more bytes into a region of size 10 overflows the destination [-Werror=stringop-overflow=]". Not sure why you didn't get the log, I get it fine for "guix build"

<civodul>this ‘stringop-overflow’ check is amazing

<Rutherther>but trying latest elfutils (using --with-latest=elfutils) seems to build fine. So maybe updating here would be a fine solution?

<mjw>ACTION looks up

<Rutherther>though if I am looking correctly, a lot of stuff depends on elfutils

<mjw>There is a backport patch for that stringop-overflow error, but I cannot find it right now.

<mjw>upgrading to latest elfutils is of course also a fix

<mjw> https://issues.guix.gnu.org/74669

<mjw>^ [PATCH] gnu: elfutils: Fix cross-compilation.

<mjw>BTW 0.187 is really old (2.5 years), latest is 0.192

<mjw>also the guix build is missing zstd support

<janneke>mjw: yeah, core-package-team has

<janneke>aaf20c2870 gnu: elfutils: Update to 0.192; fixes build with gcc-14.

<mjw>o cool

<yarl>Rutherther: yes, x86_64 to aarch64. Is there an open issue?

<yarl>Ah, mjw pointed it

<yarl>Also, if someone is interested https://issues.guix.gnu.org/74887

<ieure>If anyone's in the mood, #74891 and #74893 are both simple patches which fix some Python builds.

<janneke>crap magit over tramp seems to be broken again

<janneke>"error in process sentinel: Forbidden reentrant call of Tramp

<janneke>ACTION goes to try the gcc-8..13 build with gcc-14 fix on gcc-4.7, but nicer, as a patch

<janneke>bordeaux is terribly slow again...

<ieure>Anyone have some prior art for a QEMU system-image they can point me at? I want to spit out a Guix System qcow2 image I can boot directly in qemu, but not sure about the partition setup needed for that.

<janneke>56KiB/s

<ieure>I would like to avoid booting the installer in QEMU and doing an install into a blank qcow image; would much rather make a directly-bootable image.

<csantosb>ieure: this ? https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/guix/system.scm

<freakingpenguin>ieure: I have a qcow2 image I use for digitalocean if that's any help. https://git.sr.ht/~freakingpenguin/rsent/tree/master/item/rsent/system/digitalocean.scm

<ieure>csantosb, freakingpenguin, Thank you both, those look like just what I wanted.

<ieure>Hmm, still getting: "guix system: error: image lacks a partition with the 'boot' flag"

<rekado>ACTION looks at #74891

<ieure>rekado, Thank you!

<rekado>ieure: applied both

<ieure>rekado, Terrific!

<ieure>This is what I have for the QEMU image: https://paste.debian.net/1339990/

<fingu>what services are included by default in shepherd? can it be replaced as the /sbin/init out of the box?

<yarl>about https://issues.guix.gnu.org/74887, I could find in the store the system partition and loop mount it. I couldn't with the disk image, invalid ext4 error. In fact, after genimage, the bootloader (here u-boot) is copied to the disk image. But the second u-boot part (u-boot.itb) has no room to fit and it overwrites the beginning of the system partition. I was then able to boot on that disk image. (I needed to remo

<yarl>ve nvi in my configuration, though, a cross compilation problem I think).

<juli>is anyone else working on fixing python-emoji? because i think i have a fix and am building dependants to be sure and don't want to duplicate work

<juli>also if you get a python package failing to build because of something related to setuptools, it seems python-setuptools and python-wheel as native inputs may be the fix

<juli>oh gosh oh heck there are a lot of python packages broken because of that right now it seems...

<juli>i'm now moving on to python-colorthief for what seem to be similar reasons

<yarl>u-boot.itb is copied at sector 16384, measures 2109 sectors, thus ending at sector 18493. The partition (before the patch) is put at offset (in sectors) 18432, thus before the end of u-boot.itb.

<yarl>If someone is not too busy to take a look :)

<podiki>juli: make sure you are current with master, lots of python fixes in past day and even minutes, post python-team branch merge

<podiki>discussion on guix-devel too, but yes, some packages likely missing some native-inputs for missing wheel/setuptools

<juli>I pulled before starting to work, but I'll double check :)

<rekado>I've got fixes for python-xarray, snakemake, python-loompy, and python-deeptools.

<icepic1984>yarl: nvi crosscompiling problem is solved in https://issues.guix.gnu.org/issue/74838

<juli>patches submitted

<guix-newbie-123>I currently experimenting with podman in a vm image i built from a system configuration, I have setup podman for a user, subids and general podman configurations files exist, but the user cannot run containers, due to /etc/sys/cgroup having the wrong filesystem type. The filesystemtype on a physical guix system is different and seems to be correct.

<guix-newbie-123>Anyone got any ideas what could cause this?

<lfam>I'm trying to adapt my user's two shepherd services to shepherd 1.0. I can register and start either of them, but if I try to register and start both of them, only the first one works (alpha sorting in 'init.d/'). I get this error from fibers: <https://paste.debian.net/1340009/>

<lfam>The second service is not registered

<lfam>Is this a known problem?

<lfam>Or am I just holding it wrong?

<lfam>Or, does anyone have a publicly accessible set of user-level services for Shepherd 1.0 that I can study?

<lfam>It works okay when I don't use individual per-service files in init.d, and instead put them all in init.scm and start them like that

<civodul>hey lfam!

<lfam>Howdy!

<civodul>lfam: i use it via Guix Home

<lfam>Aha

<lfam>I'm still doing the primitive method

<civodul>the full experience :-)

<civodul>heh

<lfam>When I put my services in init.scm and work like that, it's still much nicer than before 1.0

<civodul>“Attempt to suspend fiber”, interesting

<civodul>could you share that init.scm?

<lfam>Yes

<lfam>And 1 of 2 service files: <https://paste.debian.net/1340015/>

<lfam>Sorry about the messiness of 1/

<lfam>1/2

<civodul>what if you explicitly (load "init.d/first.scm") (load "init.d/second.scm") ?

<civodul>i think ‘for-each’ is still in C, so a continuation barrier

<civodul>(did that work before?)

<civodul>hmm actually no, it’s been in Scheme for some time already

<lfam>To be clear, the init.scm is copied and pasted from the Shepherd manual section Managing User Services

<lfam>But I can try loading the files as you suggest

<lfam>Same error as previously, and same behaviour (only the first service is registered)

<civodul>lfam: the first one (mpd) is registered and started?

<civodul>or just registered

<janneke>ACTION built gcc-5.5 with gcc-14

<janneke>and now goes on to look at 4.8, 4.9

<janneke>ACTION has given up on 4.7 for now

<ekaitz>janneke: are you working in a public branch? which one?

<janneke>ekaitz: mostly core-package-team, but the last three comments aren't pushed yet

<janneke>*patches that go with...

<ekaitz>i'll take a look. I think this might be a great improvement for finishing the RISCV bootstrap

<janneke>ekaitz: but the fixes to build gcc-5...gcc-13 are similar to the ones i made to the gcc-11-fixed package

<janneke>ekaitz: let me push my work-in-progress to my gitlab's core-package-team

<ekaitz>don't worry, i won't look at it now

<janneke>ekaitz: in that case, efraim is also closely watching pretty closely what i'm doing :)

<ekaitz>yes i know, fixing the riscv bootstrap is his job actually

<ekaitz>hehe

<ekaitz>efraim: <3

<janneke>ekaitz: while you're here, does this error ring a bell?

<janneke>md-unwind-support.h:60:47: error: dereferencing pointer to incomplete type

<ekaitz>yes

<janneke>it's from libgcc/config/i386/linux-unwind.h

<janneke>nice

<janneke>someone forgets to include signal.h or something i guess, but i could not find the problem

<janneke>that's where i'm currently stuck building gcc-4.7 with gcc-14

<ekaitz>janneke: i think there is some ucontext_t thing in the unwind world that has issues

<ekaitz>i had something similar

<ekaitz>but I can't remember exactly what

<ekaitz>search for MD_UNWIND_SUPPORT

<ekaitz>it's a macro

<ekaitz>and in the config.host you have some `md_unwind_header=` variable

<ekaitz>maybe some misconfiguration in there?

<janneke>thanks, i'm taking notes :)

<ekaitz>in my gcc i remember i made some related change but i don't remember what

<ekaitz>you can try to read the commits i made

<janneke>(y)

<janneke>that's in commencement.scm, right?

<ekaitz> https://github.com/ekaitz-zarraga/gcc

<janneke>ekaitz: thanks

<ekaitz>take in account that the md-* file is generated... did you try to read its contents?

<newbie-MBR-to-GP>Hi Folks...i am new to Guix, running it in a VM. Had to resize disk adn this worked eventually...now i i see that it is actually a dos-disk...would like to have my Qcow2 to be a gpt...how to do it best?

<janneke>ekaitz: it's copied, right?

<janneke>ACTION found 0002-Fix-ucontext_t-issue.patch

<janneke>that looks pretty nice and silly if that's everything :)

<lfam>civodul: The first one registers, and sometimes it starts. It does not always start

<lfam>I have to go AFK but I'll stay here in IRC

<ekaitz>janneke: yeah the ucontext_t issue is a pain in the balls, it's the libc that changed a little there and makes some things explode

<janneke>ekaitz: i'll go try that and else look through other patches of yours..after i get 4.8, 4.9 to build

<ekaitz>(y)

<janneke>lovely that you remembered and just happened to be here too

<janneke>some might say, coincidence ;)

<ekaitz>you were just lucky, i'm not good at remembering details

<newbie-MBR-to-GP>Hi Folks...sorry for annoying but i am a bit scared as i am not sure if chrooting into a guixsd is working as i know it from gentoo and if i mess up the partition table i might be f*cked

<janneke>ekaitz: yeah, right :)

<janneke>newbie-MBR-to-GP: have you seen: https://guix.gnu.org/manual/devel/en/html_node/Chrooting-into-an-existing-system.html ?

<crlas>Hey, all. I recently did a guix pull and then tried to update my system, but the reconfigure is failing to build the python-minimal-wrapper package. It says I can view the build log for the derivation, but I don’t know how, so I’m stuck 😅

<newbie-MBR-to-GP>janneke hmmm...hmmm...thx first... i will try to work with that. anything i should keep in mind while messing with my disks of while chrooting...some best practices of some kind?

<janneke>=> /gnu/store/r7xl0agiqvai22n4wrwhyrw9q1h54m59-gcc-fixed-4.8.5

<janneke>newbie-MBR-to-GP: make backups?

<janneke>before hitting enter, stand up, think, sit down, look again

<ekaitz>newbie-MBR-to-GP: and be careful

<ekaitz>janneke: yay!

<dodoyada>hello! wrt emacs+guix is there a way to update emacs packages/init after guix reconfigure without restarting?

<newbie-MBR-to-GP>i copied my custom stuff(config.scm and some other stuff) already...Plan was to convert(if possible) and later chroot into it to fix what might be broken...

<janneke>ekaitz: yay, now i get until...

<janneke>gcc-14.2.0/include/c++/stdlib.h:38:12: error: ‘std::abort’ has not been declared

<ekaitz>i've seen that before

<janneke>hoped you might

<ekaitz>i don't remember the solution though

<ekaitz>let me think

<janneke>ACTION already browsed through your patches, of course...

<stochastic>> Hi Folks...sorry for annoying but i am a bit scared as i am not sure if chrooting into a guixsd is working as i know it from gentoo and if i mess up the partition table i might be f*cked

<stochastic>do you have a separate home partition?

<janneke>ACTION wonders if gcc-4.7 builds on master, ie, with gcc-11

<ekaitz>janneke: https://github.com/ekaitz-zarraga/gcc/commit/88f971c41e628e361fce8647d22c24a031e6f671

<stochastic>one of the unexpected advantages of guix is that almost all of the root config comes from the config.scm file

<ekaitz>janneke: i think it's related with libstdc++ and libc collisions... i don't remember very well

<stochastic>one of the unexpected advantages of guix is that recovering from a thrashed root is easier since almost all of the system config comes from the config.scm file

<janneke>ekaitz: huh? musl?

<janneke>confusion sounds about right, tho

<ekaitz>yes it's related with the libc in use

<janneke>or collison

<janneke>*collision -- oh my type

<ekaitz>this i don't remember very well, i think stikonas knows more about this

<ekaitz>but we fixed it somehow

<ekaitz>janneke: in riscv setting the device as generic removed some of the issues we had with functions that were optimized

<ekaitz>but this std::abort was a different thing

<ekaitz>you see the error with many other functions in the std namespace, right?

<stikonas>janneke: gcc 4.7 can't build gcc 11

<stikonas>It can build GCC 10 with some minor patching