IRC channel logs


back to list of logs

<unmatched-paren>jpoiret: the thingy hath been thingied
<unmatched-paren>ACTION zzz now
<lemos1898>helping a friend out updating a package, how could i test the package build/install from the git clone of the repo? found nothing searching so far :/
<oriansj>lemos1898: you'll want to make a channel and check it into the channel, it'll be much simpler as the main repo is signed.
<apteryx>oh, procps' top layout has changed a bit with the update
<apteryx>mirai: mpd-service-type in its default pulse config now works for me with just 'music-directory' :-)
<apteryx>I'll add a permission check for the music-directory when set, and I think I'll be on my way
<unmatched-paren>morning, guix
<unmatched-paren>apteryx: i sent in a fix for that bug/feature request you posted yesterday
<Grimpper>Good morning. Please could someone help me with understanding this error.
<Grimpper>I'm creating a derivation which should be of this form: `/gnu/store/...-xfce-appmenu-gtk-module-0.7.6.drv`
<Grimpper>The problem is that it fails during the install, and for a good reason.
<Grimpper>PermissionError: [Errno 13] Permission denied: '/gnu/store/...-xfce4-panel-4.18.3/lib/xfce4/panel/plugins/'
<Grimpper>Installing subprojects/registrar/appmenu-registrar to /gnu/store/...-xfce-appmenu-gtk-module-0.7.6/libexec/vala-panel Installing applets/ to /gnu/store/...-xfce4-panel-4.18.3/lib/xfce4/panel/plugins FAILED: meson-install
<Grimpper>For context this is the derivation:
<smmm>hey, quick one - I have built a package and have added `iptables` as a propagated-input... when i run the package inside `guix shell -C...`, I can find iptables in the $PATH, but the daemon I am packaing cannot find it - is there a good way to perhaps check if the PATH is being properly read / maybe strace and see what's going on?
<AwesomeAdam54321>smmm: I think the simplest way is to check the package's source code to see how it calls iptables, using grep
<AwesomeAdam54321>I wonder if glibc accepts patches to remove the Python dependency
<jpoiret>unmatched-paren: have you tested it out on the guix codebase?
<jpoiret>I expect quite some breakage
<jpoiret>I remember writing some match-records with thunked fields myself
<abrenon>hello guix
<abrenon>anyone has an idea what package (from %base-packages I presume ?) lets one use UTF-8 characters ? I noticed that when I enter a --pure environment I can no longer type a 'é' or any other UTF-8 character in my shell
<abrenon>and also some haskell process I wrote which filters text now chokes on an input having UTF-8 (but importantly, not on ASCII-only inputs)
<jpoiret>you need some utf8 glibc locales i would say
<abrenon>yeah but how would I put that into my --pure shell or container ? I tried the ol' export LANG=fr_FR.UTF-8 trick to no avail
<jpoiret>you would also need to set LOCPATH. I don't think there's a minimalist glibc utf8 locales package
<abrenon>how about a not minimalist one ?
<abrenon>also, I have no $LOCPATH set in my usual environment but it still works
<abrenon>hmm including %base-packages doesn't help so there has to be some additional magic
<zimoun>abrenon: for French part of UTF-8, the “minimalist” package is glibc-utf8-locales
<jpoiret>it doesn't exist anymore
<abrenon>I tried including %base-packages, glibc and glibc-locales into my profile but it didn't change anything
<jpoiret>ah, maybe GUIX_LOCPATH instead?
<abrenon>that does exist
<abrenon>well there is one defined in my --pure environment
<abrenon>not pointing to /run/current-system but to some location in the store
<zimoun>ah indeed, stopped at 2.29.
<abrenon>so I guess I need to find the right packages to include so that the file at $GUIX_LOCPATH is able to handle utf-8 ?
<zimoun>are you running Guix System or Guix on the top of something?
<abrenon>ok, actually when I enter such a manifest, then re-export LANG like I mentioned above, then spawn a new bsah, that works
<abrenon>Guix System ! I even got a sticker to put on the laptop during the 10th year anniversary
<abrenon>so the problem is LANG not being defined when bash is spawned by guix shell
<jpoiret>yes, you can manage this by using "env LANG=... bash" as the command for guix shell
<jpoiret>but you'll probably need to include coreutils in the manifest as well
<jpoiret>if it's only for scripts, C.UTF-8 should be enough, and we could consider adding a package with just this locale
<zimoun>why does “guix shell glibc-locales --search-paths” return nothing? I was expecting some environment variables.
<jpoiret>zimoun: I believe it is glibc that sets the search paths
<abrenon>indeed including glibc does return the GUIX_LOCPATH
<abrenon>and would it be possible to have guix shell automatically default LANG to that when this package is included and LANG would get otherwise erased by the --pure or --container options ?
<jpoiret>might be too quirky
<abrenon>it's somehow frustrating to be able to capture a list of packages but not an environment in a manifest since some variables may be required for a computation
<PotentialUser-14>Hi !!!
<PotentialUser-14> seems to be down ?
<civodul>looks like search now ignores submitter: and author: contraints
<mfg[m]>does gnome-terminal depend on systemd? i'm running sway and alacritty doesn't launch anymore so i wanted to use gnome-terminal and it errors out saying "org.gnome.Terminal was not provided by any .service files"
<abrenon>mfg[m]: nope, we don't have systemd in Guix System
<mfg[m]>i know that systemd isn't part of guix system, but i only know .service files from systemd. So i don't get why gnome-terminal would error out like this
<civodul>mfg[m]: .service files are for D-Bus
<civodul>dbus-daemon can start "D-Bus services" on-demand
<mfg[m]>Ahh, thanks civodul :D
<civodul>now i'm not sure what's supposed to happen with org.gnome.Terminal :-)
<jpoiret>the gnome terminal has a client server architecture for some reason
<jpoiret>and it relies on dbus
<jpoiret>if a client starts, it will ask dbus to connect it to the server, and if it's not started it will start in the background :)
<mfg[m]>thanks for the explanation jpoiret :)
<jpoiret>if you're running sway, I would recommend some lighter and simpler terminals
<jpoiret>foot would be a good one (disclaimer: that's what i use)
<mfg[m]>Yeah that would have been my next question :D
<mfg[m]>I've seen bjc (?) was trying to update and/or fix the alacritty package, but as it is written in rust that seems to be a frustrating experience. Maybe i should switch permanently to something else 🤔
<bjc>efraim has fixed alacritty, i think. but i've also switched to foot as i no longer trust anything written in rust, particularly alacritty
<mfg[m]>i feel you :D
<bost>Hi. Is there a way how to pretty-print or derivation files? I mean, a drv file is an unreadable one-liner... ugh.
<bost>pretty-print or visualize
<jpoiret>i was not aware that is now in the kernel
<jpoiret>bost: emacs-guix has a derivation mode i think
<jpoiret>but otherwise no
<bjc>M-x guix-prettify-mode
<bost>jpoiret bjc Thx. I'm gonna have a look at it.
<apteryx>civodul: it's the same as all the other d-bus services in Guix; they only work if they are *installed* to under ~/.guix-profile/etc/dbus-1 or something
<futurile>Q: what does this mean -> guix build: warning: failed to load '(nongnu ci)':
<futurile>In procedure abi-check: #<record-type <operating-system>>: record ABI mismatch; recompilation needed
<apteryx>civodul: jami used to have that problem when it relied on d-bus to start its daemon
<futurile>I've just done a guix pull
<jpoiret>futurile: you should try to `git clean -dfx` in the checkouts in ~/.cache/guix/checkouts/
<jpoiret>and pull again
<jpoiret>this is while pull'ing, right?
<futurile>jpoiret: after a pull, was doing `guix build nudoku --no-substitutes`
<civodul>jpoiret: so argc is always strictly positive now?
<civodul>apteryx: yes; i know how it's supposed to work, but i'm wondering what's wrong with GNOME Terminal (from a distance: i don't use it :-))
<apteryx>oh; does it now work after installing it to the user profile?
<mfg[m]>jpoiret, bjc thanks for recommending foot :)
<jpoiret>civodul: on newer kernels, yes :)
<jpoiret>this broke some proot tests, so i'm fixing them upstream, but there's also one that has a nontrivial failure
<jpoiret>I wanted to finally push through with the fix for
<jpoiret>apteryx: andreas reported it to be working after installing it in their profile
<apteryx>civodul: ^
<apteryx>httpd stremaing stopped working for me with mpd since some time
<apteryx>does anyone still have a working configuration?
<civodul>jpoiret: oh, it'd be great to have that bug fixed, indeed!
<apteryx>I think the "bug" is rooted in security considerations
<apteryx>I seem to recall you had a discussion with upstream about d-bus' inflexibility on d-bus services location, but that was many years ago. Perhaps worth revisiting!
<apteryx>I'm not sure if it's related anymore, but the thread I had on mind was this:
<jpoiret>would any of you be willing to endorse my committer application? I think I'm only missing one
<apteryx>civodul: perhaps the issue is the lack of guidance in our documentation.
<apteryx>if a "search path" for ${datadir}/dbus-1 could be devised that'd be awesome, but that seems it'd be insecure based on the linked thread above
<civodul>apteryx: you're refering to the GNOME Terminal issue?
<civodul>actually i don't know what the issue is, i was merely explaining what .service files are
<civodul>overall Guix System handles .service files correctly for services
<civodul>but things like GNOME Terminal are not services from Guix's viewpoint, so i'm not sure how that's supposed to work
<civodul>i don't use GNOME but i use things like Evince, and that works
<civodul>maybe Terminal is more "sophisticated"?
<civodul>ACTION prepares Shepherd 0.10.0rc1
<apteryx>I think the GNOME terminal spawns a user 'daemon' via d-bus, by using the d-bus autostart mechanism. and teh issue is that we have a hard coded list of places d-bus consults to find its service definitions, such as /etc/dbus-1 or ~/.guix-profile/etc/dbus-1, rather than in arbitrary places such as a 'guix shell' profile
<civodul>oh, i see
<apteryx>basically the engine/presentation logic of GNOME terminal is decoupled and talk over d-bus, IIUC
<civodul>and so you can't launch it from "guix shell", unless you're already running GNOME, right?
<apteryx>which strikes me as an overkill architecture for a terminal, but I'm no architecture guru
<apteryx>civodul: no, you can't launch it at all, unless you've installed the D-Bus service definitions of gnome-terminal to one of the few places our d-bus packages is hard-coded to look at
<apteryx>'guix install gnome-terminal'
<apteryx>I guess it used to work when installing the 'gnome' meta-package because it'd propagate gnome-terminal to the system profile, which must be among the places consulted
<apteryx>no longer, it's been replaced by 'console'
<civodul>ah yes, Console is the new thing
<civodul>so why are we even talking about Terminal? :-)
<apteryx>someone preferred using that over console, I think. and stumbled on that year-old dbus issue
<civodul>(i don't expect Console to be less overkill though)
<apteryx>I think we should just document that "gotcha" as a resolution
<apteryx>if it isn't already
<apteryx>it doesn't seem to be
<apteryx>by the way, fun thing: our profile doesn't set a terminal name in the prompt, so the tabs in console are blank
<apteryx>/etc/profile or whatever sets our default PS1
<bjc>how do i tell guile to never elide backtrace output?
<civodul>apteryx: a terminal name using the magic OSC sequence?
<apteryx>I think so!
<apteryx>I tried figuring out where/how that got set in Fedora, but I think it wasn't obvious.
<apteryx>but manually setting it was working
<bjc>civodul: how hard would it be to fix ‘ungexp’ so that it tells you when a symbol isn't defined, rather than: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f
<apteryx>bjc: thanks for working on better error messages :-)
<bjc>i wouldn't know where to begin with this one. for some reason i find scheme's macro system much harder to parse than what i'm used to from ‘defmacro’
<apteryx>I guess because it's more powerful (thus dense/complex)
<apteryx>I also have a hard time with macros
<apteryx>strange output:
<bjc>i have another attempt at #63044 which doesn't fix everything, but does make the fix adding ‘python-toolchain’ or ‘python-setuputils’ to native-inputs
<jpoiret>bjc: I could work on it
<bjc>it's still a lot of package rebuilds, but less than doing it in python
<bjc>jpoiret: i'll make a bug report for it in a bit
<apteryx>no audio team yet?
<apteryx>it's a bit too loose a definition perhaps
<bjc>linux audio is such a headache
<Altadil>Where can one learn more about this teams/branches thing ? I have seen it mentioned here but I don’t remember seeing on the Guix website.
<rekado>Altadil: in the source repository see etc/teams.scm
<efraim>civodul: have you thought about sending the shepherd pre-release announcement to the platform-testers mailing list? They have all sorts of systems
<jpoiret>Altadil: we're definitely missing a more discoverable page on the website for it
<Altadil>jpoiret: rekado: Thanks ! I agree, it seems very nice for would-be contributors !
<bjc>podiki[m]: i've updated #63044 to only touch python-setuptools. i'm fixing the stuff that's still broken with other, much smaller patches
<panosalevro>hi all, I get "1 dependencies couldn't be built" after trying `guix upgrade`. any help much appreciated
<jpoiret>apteryx: about the patch adding a default .git/config, wouldn't that break people own local configs?
<civodul>efraim: i'm not interested in "all sorts of systems", i just care about GNU/Linux here (GNU/Hurd soon)
<bjc>soon 👀
<civodul>yeah, needs a new Fibers release
<jpoiret>also, I think we could add "format.forceinbodyfrom=true" by default, so that people whose From: header gets rewritten by debbugs/mailman still have the proper attributions by default
<civodul>platform-testers is very much about testing things on AIX, HP-UX, NetBSD on alpha, things like that
<jpoiret>I got the reason from the mailman team, it's because of DKIM: since debbugs rewrites the To: headers, which are signed by DKIM, it needs to alter the sender to still pass DKIM by resigning everything itself
<jpoiret>and some of our contributors don't really control their provider's DKIM policy, so this option seems like the best mitigation
<apteryx>jpoiret: no, it's simply included
<jpoiret>ah, ok! I thought the makefile would automatically copy it
<apteryx>the pre-push is copied, the gitconfig fragment is included
<efraim>civodul: aside from the odd mac and windows systems they have a large collection of different linux architectures and operating systems of different vintages
<jpoiret>ohhh, I didn't see the Makefile using `git config` to add the include, very nice!
<jpoiret>wdyt about format.forceinbodyfrom=true?
<efraim>anyway, I built from the git tag on the second try on aarch64, had a test failure the first time around. testing armhf-linux and riscv64-linux ATM. If I find a spare outlet I can test powerpc-linux too
<civodul>efraim: oh; suggests intermittent test failures on aarch64 (plus the usual timeout for guile-fibers@2.2, but that's another story)
<civodul>do you have a test-suite.log file at handle for those aarch64 issue?
<apteryx>ACTION just send a 17 patches series with 'mumi send-email'
<unmatched-paren>apteryx: what's the command you used?
<unmatched-paren>jpoiret: hmm, no, i should probably check through the codebase
<jpoiret>apteryx: was it a new bug #?
<jpoiret>I can't seem to get past the debbugs dance, always running into the timeout
<apteryx>unmatched-paren: mumi current 63082 && mumi send-email -a mpd-v1, where mpd-v1 was produced with 'git format-patch --cover-letter -ompd-v1 74e41b16a7..' and the cover-letter.patch edited there
<apteryx>it was an existing bug
<efraim>civodul: I don't, I reran it immediately and then it passed
<patched[m]>What package is in now that gcc is gone?
<jpoiret>patched[m]: wdym gcc is gone?
<jpoiret>gcc-toolchain is what you probably want
<jpoiret>civodul: how doable do you think it would be to add message passing between shepherd dependencies?
<jpoiret>i'm thinking something that could eg. capture a WM's WAYLAND_DISPLAY variable once started and then pass it on to other services
<jpoiret>that way you could control all user services through shepherd, like graphical applications that auto start
<patched[m]>jpoiret: $ guix shell gcc-toolchain
<patched[m]>[env]$ ls $GUIX_ENVIRONMENT | grep c++
<patched[m]>Yields nothing
<jpoiret>ls does not recurse into subdirectories
<bjc>bjc@psyduck:~% guix shell which gcc-toolchain -- which c++
<patched[m]>Same result with tree. Also I missed a /lib on GUIX_ENVIRONEMNT in the message
<patched[m]>bjc: I need libstdc++
<sime>hi, what do i need to install in order to watch videos on youtube with epiphany? when i click on any video it says "No compatible source was found for this media." i tried to install gstreamer and gst-plugins-good but that didn't help
<bjc>patched[m]: ah, yeah, i don't see it either. puzzling
<mfg[m]>gcc:lib maybe?
<jpoiret>patched[m]: what do you need it for? It's actually in gcc:out, so if you reaaaally need it you can get it through `guix build -e "(@ (gnu packages gcc) gcc-11)"`
<patched[m]>mfg[m]: Worked before gcc was removed in last core update :^
<patched[m]>As a package
<jpoiret>gcc wasn't removed, just hidden, and that was before the core-updates merge i believe
<patched[m]>jpoiret: A binary I need to run depends on it
<apoorv569[m]>Just installed Guix on a different machine with encrypted btrfs file system. Installation went without any errors, but rebooting into installed system shows error, "refusing to check /dev/mapper/cryptroot file system already mount at /" and just stuck here..
<apoorv569[m]>did I do something wrong?
<mfg[m]>I see, i'd consider it a bug then, that gcc:lib contains items that gcc-toolchain doesn't while not alternatively providing gcc-toolchain:lib
<jpoiret>apoorv569[m]: what's the relevant parts of your config.scm?
<patched[m]><jpoiret> "patched: what do you need it for..." <- It was in gcc:lib previously and doesn't appear with your expression, how can I modify it to use :lib instead?
<jpoiret>the previous command should give you all of gcc's outputs
<jpoiret>gcc:lib, sorry! the expression will still give you all outputs though
<jpoiret>there's no easy way to tell build to only build one output
<apoorv569[m]>jpoiret: It's the default config generated plus a little modifications to use btrfs filesystem and all.
<apoorv569[m]>Here is the entire config, 106 lines only.
<patched[m]>jpoiret: Ah allright, then I guess passing the same to guix shell --expression= must not work 🤔
<apoorv569[m]>I did fstab /dev/nvme0n1 and created UEFI layout and 2 partitions for boot and root.
<apoorv569[m]>then formatted first partition to fat for EFI and second to btrfs
<apoorv569[m]>created subvols and also did btrfs filesystem mkswapfile --size 10G /mnt/swapfile
<apoorv569[m]>then I edited the config to work with btrfs filesystem with correct UUIDs
<apoorv569[m]>also forgot to mention, also did cryptsetup luksFormat /dev/nvme0n1p2 to create a LUKS encrypted parition.
<jpoiret>I'm thinking that since you mount the same filesystem multiple times, so once it's mounted once somewhere, the subsequent checks will fail :(
<jpoiret>patched[m]: guix shell -e "(list (@ (gnu packages gcc) gcc-11) \"lib\")"
<jpoiret>for guix shell you can actually specific the output
<apoorv569[m]>and used /dev/mapper/cryptroot as the partition for root
<apoorv569[m]>jpoiret: Yes, but btrfs file system works with subvols to mount it correctly.. this config worked previously
<apoorv569[m]>unless something has changed since last time I did this, in the documentation.
<jpoiret>apoorv569[m]: you might need to add (check? #f) to all other subvolumes
<jpoiret>as long as the first one gets checked, the others should be okay anyways
<apoorv569[m]>I see. How can I fix this without re-installing
<civodul>jpoiret: i had never thought about it (passing messages among services), but it should easy to do
<jpoiret>I can only see chrooting as a solution, and that is not trivial to get right. Should still be doable though. see
<civodul>note that you can already pass arguments to 'start'
<civodul>efraim: i managed to reproduce a test failure on aarch64-linux so... i have more work to do now :-)
<patched[m]><jpoiret> "patched: guix shell -e "(list (@..." <- Thanks, now it appears in the environment!
<jpoiret>i'll be rebooting with shepherd 10 first :)
<apoorv569[m]>"Some bootloaders, for example GRUB, only mount a Btrfs partition at its top level during the early boot, and rely on their configuration to refer to the correct subvolume path within that top level. The bootloaders operating in this way typically produce their configuration on a running system where the Btrfs partitions are already mounted and where the subvolume information is readily available. As an example, grub-mkconfig, the
<apoorv569[m]>configuration generator command shipped with GRUB, reads /proc/self/mountinfo to determine the top-level path of a subvolume. "
<apoorv569[m]>Hmm.. From Guix documentation,
<janneke>ACTION wonders why a starting graphical application would need message passing, the home-kodi-service works nicely as it is
<jpoiret>janneke: you need DISPLAY/WAYLAND_DISPLAY
<jpoiret>and the WM sets it when it starts (and sure it's most likely :0, but it would be a hack to rely on this)
<janneke>ah right, yuo're not talking about home services
<jpoiret>well, I am
<bjc>iirc, systemd allows you to do this by having the ability to set systemd's environment itself. so your wm can start, tell systemd that DISPLAY=:1, then you can start services normally from that point
<jpoiret>yes, dbus as well, but it is ugly: the environment variables are not scoped, you modify the whole starting environment with it.
<bjc>i'm not, personally, thrilled by the idea of arbitrary message passing in shepherd, but i agree this is a problem
<jpoiret>with proper message passing, you could scope the variables (and other info) to exactly the services that need them
<jpoiret>by message passing, I mean that one service could say in its definition "oh my start action takes an additional argument which is what service Y's value is"
<jpoiret>I'm not proposing dbus or anything like this :)
<civodul>G-Bus! let's create G-Bus!
<civodul>with SGML messages sent over TCP/IP, and a reference implementation in C89
<jpoiret>seems like the right thing to do
<janneke>we need a C89 compiler in scheme
<bjc>we need a scheme compiler in xslt
<mirai>a DSSSL implementation in XSLT
<apoorv569[m]>inside chroot env, I cannot do guix pull Git error: failed to resolve address for Temporary failure in name resolution
<apoorv569[m]>internet is working, I'm on same networking messaging here.
<apoorv569[m]>also outside chroot I can ping
<apoorv569[m]>but not inside
<mirai>civodul: what do you think on shepherd accepting a new keyword argument #:capabilities for make-forkexec-… & friends?
<civodul>mirai: not for 0.10 :-)
<civodul>but #:capabilities in what sense? POSIX or "actual"?
<mirai>things like CAP_NET_BIND_SERVICE
<jackhill>what are "actual" capabilities? :)
<bjc>i would love that
<jackhill>agree, seems like a neat idea
<civodul>mirai: we could do that, though i guess we'd need libcap bindings?
<civodul>jackhill: i mean "actual" as in "ocap"
<bjc>how would ocap would fit into arbitrary process spawning?
<bjc>it's not like the kernel knows about them
<jackhill>civodul: ah! thanks!
<civodul>bjc: heh :-)
<mirai>does anyone see what's causing the G-Exp problem here? <>
<mirai>I've forgot a bit of the context here (has been a while since I wrote this) but iirc string-append fails here because it sees G-Exps
<mirai>instead of strings
<spiderbit>there is a package called gnome-settings-daemon, but there is no binary inside any idea how to start it?
<spiderbit>outside of gnome that is
<apteryx>up my duckdns mcron job mysteriously stopped working:
<apteryx>now with actual job source:
<apteryx>I'm guessing (effective-version) is now wrong or something. Could i use 'with-extensions' instead?
<efraim>civodul: no issues building shepherd from git on armhf-linux
<mirai>apteryx: I've received the cover letter of the series
<mirai>though I'm still waiting up for yhetil to catch up
<mirai>I'm quite impressed with the sheer amount of patches you wrote
<apteryx>they're small :-)
<apteryx>ah, there's no longer guile modules shipped with gnutls itself
<apteryx>I guess I need to add 'guile-gnutls' as an extension
<apteryx>perhaps that snippet could have a place in the cookbook
<mirai>I wonder, is it worth attaching the failed build log for a bug-guix report?
<jpoiret>civodul: aha, couldn't get a login screen with shepherd 0.10
<apteryx>mirai: I usually include just the relevant tail of it
<apteryx>if whole it should be compressed at least
<apteryx>but I don't think it's pertinent
<apteryx>should be easy to reproduce locally :-)
<mirai>I could send the drv.gz of it
<mirai>but you'd get the same log if you rebuild locally so
<mirai>it looks like it'd be a waste of resources but without it the report reads like a very low effort 1-line message
<mirai>better than no report at all I guess?
<apteryx>it's sad we can't use source-properties in define-configuration
<spiderbit>ok maybe more guix specific question, with home service can you not just dump a file into the config file and then it get's copied and symlinked? I want a "ec" file that does open emacsclient -c <files> loaded
<spiderbit>in ~/bin/
<apteryx>I wonder why this needs to be specially handled instead of always available in Guile
<apteryx>too much overhead, perhaps
<mirai>apteryx: I remember asking civodul about a similar question
<mirai>try searching the logs of this channel
<jpoiret>btw, civodul: could you have a look at and
<apoorv569[m]>jpoiret: I ran the guix time-machine system init command again on /mnt instead fixing via chroot
<jpoiret>with a chroot i'm not sure you needed the time machine
<apoorv569[m]>Now i am not getting that error but still stuck on that screen
<apoorv569[m]>This time no error
<jpoiret>ah. Any other error?
<apoorv569[m]>Not with chroot just badically reinstalled
<apoorv569[m]>just this..
<apoorv569[m]>and its stuck here
<jpoiret>did this specific computer ever work with guix before?
<jpoiret>i'm seeing amdgpu here, you might need to blacklist it
<jpoiret>can you try to add nomodeset to the grub options? you can use 'e' while hovering a grub option to edit the command line, and there you can add it to the linux line's options
<apoorv569[m]>Yes.. I had it installed before also.. BTW ext filesystem works..
<apoorv569[m]>Something must be wrong with btrfs configuration
<spiderbit>any idea why that does not work
<apteryx>I'm getting a confusing error on 'guix pull'; guix-package-cache.drv fails, suggests it is caused by a channel I use. The derivation fails because the channel uses 'python-pycrypto', which no longer exist. But since the channel is pinned to use an inferior at 9ed65e6af77893b658a7159b091b5002892c2f95 which still has such package, why should it fail this way?
<spiderbit>Wrong type to apply: (("ec" #<<local-file> file: "ec" absolute: #<promise #<procedure 7f64903ad888 at /home/black/src/guix-config/home-configuration.scm:41:16 ()>> name: "ec" recursive?: #f select?: #<procedure true (file stat)>>))
<mirai>apteryx: huh, I'm surprised at some of the patches
<unmatched-paren>spiderbit: home-emacsclient-script-service has to be a procedure that takes the configuration (so that its return value can change based on what's in the config)
<apteryx>looks a lot like: #47949
<unmatched-paren>spiderbit: also, i'm pretty sure there's a much easier way to do this :)
<spiderbit>yes but find it
<spiderbit>very bad bad documentation
<mirai>there have been some changes that happened prior to merge that I didn't recognize
<unmatched-paren>spiderbit: well, i agree there are issues, but keep in mind that guix volunteers are just that -- volunteers
<mirai>ah curses, yhetil still hasn't caught up completely with the series
<spiderbit>jeah but what am I supposed to do as user of this tool
<spiderbit>read the source code?
<jpoiret>sometimes, yes
<jpoiret>guix home is still considered experimental
<spiderbit>but iths is one of the most basic things
<spiderbit>well I guess mkdir bin mv ...
<spiderbit>is the solution
<unmatched-paren>spiderbit: there's a service which lets you symlink it in on system reconfigure, let me just try find it
<mirai>spiderbit: your grievance is valid though consider the perspective of who wrote the code you're about to use
<unmatched-paren>documentation is hard :)
<mirai>writing documentation isn't “easy”, moreso for _good_ documentation
<apoorv569[m]>I just noticed something..
<unmatched-paren>spiderbit: try SPECIAL-FILES-SERVICE-TYPE:
<mirai>and it doesn't tend to be a satisfying job
<apoorv569[m]>In my config I mentioned the @logs subvol as @log instead..
<apoorv569[m]>Maybe this is what's causing the error..
<spiderbit>unmatched-paren saw that, but it's not clear what the documentation really means
<unmatched-paren>spiderbit: try adding this to your SERVICES field:
<spiderbit>ahh ok thought you meant something else
<mirai>jpoiret: I had this idea a few days ago, regarding the texi/xml thing
<spiderbit>I only need the file link no special service for it
<unmatched-paren>(simple-service '/bin/ec-service special-files-service-type `(("/bin/ec" ,(file-append emacs "/bin/emacsclient"))))
<spiderbit>so definding special-files-service directly
<spiderbit>should be enough shouldn't it?
<unmatched-paren>^ this will link /bin/ec to /gnu/store/...-emacs-.../bin/emacsclient
<spiderbit>I want it to link to a own file
<spiderbit>called ec
<unmatched-paren>yeah, if you use SIMPLE-SERVICE you don't have to explicitly re-specify the defaults, too
<unmatched-paren>yup, that's what the snippet i wrote does
<mirai>jpoiret: writing the docs in docbook but as sxml, this way it can be reasonably embedded within the codebase
<spiderbit>byt why to emacsclient?
<spiderbit>you mean it links to the binary emacsclient?
<spiderbit>overwrites it?
<mirai>and perhaps it eases up the anxieties of open/closing tags
<unmatched-paren>no, it creates a link at /bin/ec that points to the full path to the emacsclient binary
<spiderbit>but I don't want that
<spiderbit>ec is a bash script that does more
<unmatched-paren>ah, i see now
<unmatched-paren>right, so, you can just replace (file-append ...) with (local-file ...)
<unmatched-paren>or, actually, better:
<spiderbit>the -n has probably to go I think wasn't that cli
<unmatched-paren>you could write the script in guile instead, like this:
<unmatched-paren>(program-file "ec" #~(system* #$(file-append emacs "/bin/emacsclient") #| maybe add some new args here idk |#))
<unmatched-paren>that way you don't have to have a separate file or use the clumsy LOCAL-FILE
<spiderbit>I think I am over it, it's not worth the effort and not reproducable... if I have to do something similar in 1 month I have forgotten all that either there is some documentation or it's not reproducable
<spiderbit>I have a real problem
<spiderbit>that is just a small side thing... that I thought I do for it
<spiderbit>to be more efficiant
<unmatched-paren>if you do (simple-service '/bin/ec-service special-files-service-type `(("/bin/ec" ,(local-file "ec")))) it'll just do what your service does
<unmatched-paren>but LOCAL-FILE isn't great imo
<unmatched-paren>spiderbit: could you send the ec script itself?
<spiderbit>unmatched-paren look last ix link
<unmatched-paren>i think you accidentally reposted the service-type code
<spiderbit>btw how can I update the packages I have installed in my home into tha configuration without overwriting all my changes?
<spiderbit>well I don't eat something today so my pations is apperently not endless :D
<unmatched-paren>spiderbit: what do you mean by "without overwriting all my changes"? i don't quite understand :)
<spiderbit>so if I am a bit unfriendly I am sorry, try not to
<unmatched-paren>no, it's okay, i understand :)
<unmatched-paren>guix can frustrate you at times
<unmatched-paren>okay, that script is definitely doable in scheme
<spiderbit>well if I would use guix home build
<spiderbit>wouldn't it overwrite my current profile?
<unmatched-paren>guix home uses its own profile
<spiderbit>but when I start it creates a profile
<spiderbit>the question is
<spiderbit>how can I refresh
<spiderbit>from what I have installed
<spiderbit>in my profile -> the scm file
<unmatched-paren>oh, i see what you mean
<unmatched-paren>well, the intention is that the things you move into guix home, you also remove from your regular profile
<spiderbit>so I could import to a new directory
<spiderbit>and copy/paste
<spiderbit>the package list?
<unmatched-paren>i suppose, but that's not really how you're meant to use guix home
<spiderbit>well I am totally new in guix, not very keen in guile (emacs-lisp is my strength), and not even stumpwm
<spiderbit>but I (stupidly maybe) decided to switch to it all at once :D
<spiderbit>so I don't do all perfectly
<unmatched-paren>fair enough
<unmatched-paren>(i actually don't like emacs lisp at all, but really like scheme)
<spiderbit>well it's at least all lisp
<unmatched-paren>^ this program-file will hopefully emulate your bash script
<unmatched-paren>so you'd just need to replace the local-file with it to get everything in the one scheme file
<spiderbit>well at least that would solve the "PATH" variable problem I guess?
<spiderbit>I just think that could be a bit overoptimisation
<spiderbit>to much steps at once
<unmatched-paren>it's much nicer to do everything in scheme, trust me
<spiderbit>it doesn't build on existing wisdom
<unmatched-paren>for instance, you can do pre-processing on your dotfiles:
<unmatched-paren>this computed-file strips out comments from the waybar.json config-file
<spiderbit>guix home: error: no target of type 'special-files' for service '/bin/ec-service'
<unmatched-paren>using LOCAL-FILE in that way is inadvisable imo because it depends on the reconfigure command being run in the same directory as the ec file
<spiderbit>do I need some import or something
<spiderbit>well ~/.../../ should work then?
<unmatched-paren>spiderbit: i suppose, but it's not pleasant :)
<spiderbit>I want to go a bit baby step before I commit all in
<unmatched-paren>oh, is this meant to be a home service?
<unmatched-paren>fair enough
<spiderbit>I don't care what it is
<unmatched-paren>right, you'd need to add it in your system file, not your home file
<spiderbit>it just should put the file in /home/.../bin/
<unmatched-paren>you want it there
<unmatched-paren>not at /bin
<unmatched-paren>in that case, this should work:
<spiderbit>basically what the bash-service-type does
<spiderbit>technically I could put it in that
<spiderbit>but it's no "bash" file
<unmatched-paren>(simple-service 'bin/ec-service home-files-service-type `(("bin/ec" ,(local-file "PATH/TO/ec"))))
<unmatched-paren>i thought you were adding this as a system service that symlinked into /bin/ec :)
<spiderbit>yes now it seems to work
<unmatched-paren>yay! :)
<unmatched-paren>sorry about this being such a wild ride
<spiderbit>no prob thank you
<unmatched-paren>once you've used guix more, things should make more sense
<spiderbit>does it put that directory in path?
<spiderbit>it seemed like container did it
<spiderbit>which suprises me
<spiderbit>why would it do that?
<unmatched-paren> <- i wrote these to help boil down complex topics, although there's nothing about services yet
<unmatched-paren>spiderbit: i don't know...
<unmatched-paren>it definitely shouldn't
<spiderbit>("ec" . "emacsclient -c ")
<spiderbit>I had that in aliases
<spiderbit>so I have to put it into PATH
<spiderbit>something like that
<unmatched-paren>i think you could actually just do "$PATH:$HOME/bin"
<spiderbit>ahh yes makes sense
<unmatched-paren>anyway, the variables from that service eventually end up in a regular old bash script :)
<spiderbit>can I do that somehow in the same service
<spiderbit>or do I need this seperate service
<unmatched-paren>no, you can't
<unmatched-paren>a SIMPLE-SERVICE essentially creates a new SERVICE-TYPE that does nothing but extends the given base service type with the given configuration
<unmatched-paren>to extend multiple in one service you'd need to create a SERVICE-TYPE manually
<unmatched-paren>i don't think it's worth it
<unmatched-paren>btw the Scheme equivalent of CONCAT is STRING-APPEND (yes, it's too long :P)
<unmatched-paren>Scheme doesn't like to abbreviate names
<spiderbit>there is some concatenatitaty... long name
<spiderbit>that is impossible to wirte correctly
<spiderbit>was it in "s" module
<spiderbit>(concatenate 'string short-title
<spiderbit>well not that bad :D
<spiderbit>I think format is the way to do everything in guile I think :D
<spiderbit>but back to my problem
<spiderbit>it removes the executable bit
<spiderbit>so as alternatvie put it in user-profile/bin/
<spiderbit>wouldn't that take care of the executable bit and path
<unmatched-paren>it removes the executable bit? that's a surprise
<unmatched-paren>it might be better to just add my original version to your system file...
<spiderbit>well it does not copy the file
<spiderbit>but creates a symlink
<spiderbit>in ~/bin/ec
<spiderbit>but the -r--r--r-- 1 65534 overflow 74 Jan  1  1970 /gnu/store/7vk8k3ssi9qfz0wn7agfrhsdpvl0znyn-ec
<unmatched-paren>okay, that makes sense to me now
<unmatched-paren>you probably want to use the PROGRAM-FILE version...
<unmatched-paren>btw is there anyone who has read who can give me some feedback?
<apoorv569[m]>jpoiret: works now.. No need for check? #f now either..
<apoorv569[m]>The problem was i had one of subvol named wrong
<apoorv569[m]>log instead of logs
<apteryx>ACTION gits rid of its single channel to avoid the symptoms described at
<unmatched-paren>ACTION goes to try mumi send-email
<apoorv569[m]>The error was weird though.. Didn't make any sense.
<spiderbit>program-file name exp
<spiderbit>plain-file name content
<spiderbit>I can't just replace it somehow
<unmatched-paren>spiderbit: <- this is the PROGRAM-FILE
<unmatched-paren>you can replace the (local-file ...) with the (program-file ...) form
<spiderbit>so I have to use program-file "ec" (plain-file..)
<spiderbit>if I don't want to do it all in lisp
<unmatched-paren>no, that's not it
<unmatched-paren>you can't not do PROGRAM-FILE in lisp
<unmatched-paren>you could try doing COMPUTED-FILE
<unmatched-paren>like this:
<unmatched-paren>(computed-file "ec" #~(begin (copy-file #$(local-file "ec") #$output) (chmod #$output #o555)))
<unmatched-paren>this will create a new "ec" file that has the executable bits set
<spiderbit>my brain hurts why so complex :D
<unmatched-paren>to break it down:
<unmatched-paren>(computed-file NEW-FILE-NAME EXPR)
<unmatched-paren>NEW-FILE-NAME is the name of the file in the store
<ieure>If you don't want to do it all in Lisp, Guix may not be for you.
<unmatched-paren>EXPR is a "g-expression" that contains some code to create the file
<unmatched-paren>G-expressions are created with #~(...)
<unmatched-paren>and within them, you can write #$THING, which will be expanded to THING outside the gexp, or the path to the thing that THING builds to
<spiderbit>but why do you then copy-file
<unmatched-paren>for instance, #$(local-file "ec") builds that local-file and expands to its path in the store
<unmatched-paren>spiderbit: the LOCAL-FILE creates something like /gnu/store/HASH-ec
<unmatched-paren>which will *not* have the executable bit
<unmatched-paren>the COMPUTED-FILE will create a different file /gnu/store/HASH-ec (same name, different hash) using the code in the g-expression
<unmatched-paren>#$output is a special case of #$ that expands to the path to the store item that's being built
<spiderbit>wasn't the full lisp version easier don't find it yet
<unmatched-paren>so first we need to copy the LOCAL-FILE to the output path, then change its permissions to add the executable bit
<spiderbit>well I use it for now I guess
<unmatched-paren>so COPY-FILE and then CHMOD
<unmatched-paren>lisp is almost always going to be longer than shell, but it should usually make more sense
<unmatched-paren>it's just that people are frequently far more experienced with shell
<unmatched-paren>so they've gotten used to its insane bits
<spiderbit>I still think it would be nice
<spiderbit>as suggestion
<spiderbit>for a feature
<spiderbit>to just 1:1 copy files or linked versions
<spiderbit>would make it easier for beginners
<unmatched-paren>reproducibility becomes an issue there
<unmatched-paren>it'd be better to just add an (executable-file ...) procedure
<unmatched-paren>(executable-file (local-file "ec"))
<spiderbit>boahh bash only understands absolute paths and relative to cwd
<spiderbit>can't replace /home/black/... with ~
<unmatched-paren>spiderbit: do you typically use fish or something?
<spiderbit>I use sometimes eshell which has a local history which makes fish to some degree useless
<unmatched-paren>i suspect that acts like fish in that it always expands ~ at the start of words to $HOME
<unmatched-paren>whereas bash relies on utilities to implement that themselves :S
<spiderbit>well I searched a few days ago a alternative to emacs tramp
<spiderbit>but there is nothing
<spiderbit>the only thing I remember being like that was gnu hurd
<spiderbit>that can use remotes or protocols as folders
<spiderbit>on filesystem level
<jpoiret>~ is a feature that so many people think is universal but unfortunately it's just a very useful hack :)
<spiderbit>pfff now the shebang is bad :D
<spiderbit>well is that a kind of bug
<spiderbit>I think container
<spiderbit>has no access of /bin/
<spiderbit>.../bin/sh: bad interpreter: No such file or directory
<spiderbit>which probably makes sense but bad for my problem :D
<spiderbit>hmm in container it adds the path
<spiderbit>with reconfigure it doesn't
<mechalain>whois /mechalain
<mechalain>oops sorry lol
<spiderbit>probably would have to logout my whole X session
<spiderbit>to get the new path
<spiderbit>yes in a new login it set's the path
<spiderbit>not very canonical / functional but well
<spiderbit>I wanted do task X and this was just a microoptimisation on the side.. but now I am way to tired to solve my real problem :D
<jpoiret>anyone else tried shepherd 0.10 with greetd?
<jpoiret>i'm getting a PAM error on boot, but I can't reproduce in a vm
<rekado>Sughosha reported something similar earlier
<nutcase[m]>Hi, I can't reconfigure my Guix System, because slim fails to build:
<nutcase[m]>does anyone know, what could be problem in my case?
<bjc>jpoiret: i haven't tried 0.10, but what's the error?
<nutcase[m]>or: why does my system try to compile slim instead of downloading a binary from the substitutes?
<bjc>i'm going to guess you can't download a substitute because ci also can't build it wor the same reason. in particular, that error has started showing up with the new gcc
<bjc>it's fairly easy to patch around with a ‘substitute*’ rule, at least. the compiler just wants an explicit NULL/nullptr
<nutcase[m]>the package definition needs a patch of the source code to compile slim with the gcc version?
<nutcase[m]>s/patch/patch rule/
<unmatched-paren>apteryx: for me it's still using an old guixrus version even though i just pushed two commits that try to stop it exploding
<bjc>nutcase[m]: yeah. another possibility is that it's already fixed upstream, so a version bump might clear it, too
<civodul>jpoiret: i use GDM/Xorg just fine, FWIW; i can't wait to see your /var/log/messages :-)
<unmatched-paren>ACTION sent v2 of MATCH-RECORD patches
<jpoiret>civodul, bjc: i get "unable to start greeter: authentication error: pam_open_session: SERVICE_ERR"
<civodul>d'oh, PAM
<jpoiret>but apparently i may have had this error before, but here it happens 7 times in one sec
<jpoiret>so i'm thinking shepherd doesn't have any retry delay now? (or never had and i'm mistaken?)
<unmatched-paren>jpoiret: i confirmed that there was no explicit uses of FORCE or (cut <> rec) to remove; seems like the only uses of those were paired with MATCH and ($ <...> ...)
<jpoiret>unmatched-paren: great!
<nutcase[m]>bjc: yes, I think that this is the way to go, the upstream should be fixed.
<civodul>jpoiret: no retry delay when starting, indeed
<jpoiret>did you try to make clean-go and make just to see if there are any compile-time error? not that it would catch all of them
<bjc>nutcase[m]: i don't have time to look at the error right now, but i've fixed it a few times in other places already, so i'm reasonably confident about it. if you can't fix it yourself, can you file a bug report and send me the number so i can get to it later?
<unmatched-paren>jpoiret: no, i didn't...
<jpoiret>civodul: did it ever had any?
<jpoiret>arf, then that's weird
<civodul>jpoiret: that error though, could it be an undeclared dependency on some other service?
<civodul>now it's starting things in paralle
<jpoiret>I'd have to read up a bit on pam
<unmatched-paren>ACTION tries
<civodul>so that could uncover problems
<bjc>pam isn't a separate service, is it? i thought it was just a shared library
<jpoiret>I don't think greetd would rely on anything other than pam, and pam is not a shepherd service
<bjc>greetd relies on an extra mountpoint
<civodul>bjc: it's just a library yes, but for instance pam_elogind talks to logind
<unmatched-paren>jpoiret: the v2 fixes dir-locals.el's MATCH-RECORD indent entry (it had 2 rather than the proper 3) and adds a MATCH-RECORD-LAMBDA syntax
<bjc>i can't rember how greetd declares it dependency on the tmpfs it makes in /run, though. so it might be a place to look
<unmatched-paren>at some point someone should sweep the codebase to replace all uses of MATCH ($ <...> ...), i suppose
<jpoiret>unmatched-paren: 👍 good thinking
<unmatched-paren>jpoiret: there's currently no uses of MATCH-RECORD-LAMBDA, but there are plenty of MATCH-LAMBDA ($ <...> ...)
<unmatched-paren>i just wanted to get the tool in place first
<unmatched-paren>(technically there is a use of MATCH-RECORD-LAMBDA, i suppose; in tests/records.scm :P)
<jpoiret>civodul: so you would say that services that depend on pam need elogind to be up?
<bjc>no, you don't need elogind
<bjc>i use greetd fine w/o it
<jpoiret>yes but if you do use it, pam_elogind is there
<jpoiret>so you might need elogind to be up before pam_elogind can be used?
<bjc>it shouldn't be referenced by greetd, though
<jpoiret>SERVICE_ERR could be an indication of that
<jpoiret>greetd doesn't decide what PAM modules get used though no?
<jpoiret>it only asks for PAM to open a session
<bjc>it has its own greetd module for pam
<bjc>it also uses the base pam ones, but i can't see a reference to elogind in /etc on my system
<bjc>it'd be in /etc/pam.d/elogind, right? or some similar thing
<jpoiret>I have "session required /gnu/store/9sp8nqyiarcxh9ivpk8vp8i6xx5wb0yn-elogind-246.10/lib/security/" in /etc/pam.d/greetd
<unmatched-paren>jpoiret: here's an idea: add an override for MATCH in (guix records) that checks to see if you've used ($ <...> ...) and prints a warning
<unmatched-paren>at compile time of course
<jpoiret>unmatched-paren: you might be matching against a bona fide guile record though
<nutcase[m]>bjc: let me know, if you need more information
<nutcase[m]>and thanks so far!
<jpoiret>let me try to add a dependency on elogind, we'll see
<unmatched-paren>jpoiret: it should be possible to check whether the record type is from DEFINE-RECORD-TYPE* with the MAP-FIELDS machinery
<unmatched-paren>only raise the warning if (TYPE map-fields ...) doesn't throw a syntax error
<jpoiret>unmatched-paren: right. Seems plausible, but still more technical
<jpoiret>you'd probably have to locally bind map-fields to avoid it raising an error and handle that case yes
<jpoiret>I wonder why syntax-parametrize wasn't used for map-fields
<jpoiret>civodul, bjc: that was it, seems like I needed a dependency on elogind
<jpoiret>now, I don't know how we could encode this properly, ie. add a dependency on elogind if the service is going to be using pam.
<jpoiret>on the flipside though, start-up is extremely fast
<jpoiret>I think we're starting to stretch the current service machinery. Maybe it could be time to re-examine it with the experience we have now, and look for some new mechanisms? (and also change the name :p)
<podiki[m]>is QA not building patches currently?
<podiki[m]>ah, or just running a bit behind
<bjc>jpoiret: i don't have that dependency in /etc/pam.d/greetd
<bjc>there's no reference to elogind in any of the files in thet directory
<bjc>i think i'm up-to-date with master from a couple days ago, too, so it shouldn't have changed
<bjc>jpoiret: are you using %desktop-services or %base-services in your system config?
<civodul>jpoiret: ah sure, we could reexamine it; glad you found a solution!
<nutcase[m]>I created my first patch, but I'm not sure, if this solves my problem of not being able to update Apache Maven. If someone with more knowledge than I have has the time to have a look at and maybe comment on it, that would be great.
<civodul>nutcase[m]: hi! i pushed patches minutes ago fixing a number of Maven packages
<jpoiret>bjc: you're not using elogind, right?
<jpoiret>That dependency is dynamically added by the elogind service
<jpoiret>civodul: but here the solution is adding an ad-hoc dependency directly in the guix source, there's no nice way to do it otherwise
<jpoiret>(Other than simply copy-pasting the whole greetd code)
<civodul>jpoiret: you mean adding elogind to the 'requirements' field of greetd's shepherd service, right?
<bjc>jpoiret: correct, i'm only using greetd
<nutcase[m]>civodul: great! but you are still testing with Maven 3.8.6, right? I have a rather profane issue that I'd like to use a newer version of Maven. Using guix shell --with-version says that it can't find the version upstream. I hoped that my proposed patch will fix it. Unfortunately I don't have a suitable environment yet, to check with my local git working copy of guix.
<bjc>it'd be unfortunate to hard-code a shepherd dependency, imho, since you can use greetd without it
<civodul>nutcase[m]: oh, i can't look at it right now; could you add details about what you were trying do do in the issue above?
<civodul>like the command you used and what it produced
<civodul>bjc: you mean you can use greetd without elogind, right?
<bjc>yes, civodul
<bjc>at one point i had to delete elogind from %desktop-services because of a conflict. i'm kind of surprised you don't have to do that anymore
<civodul>then you can have that shepherd dependency only when needed i guess?
<bjc>how would you detect that automatically?
<civodul>i admit i never understood what greetd is about :-)
<civodul>or rather, i never understood why elogind isn't enough
<bjc>elogind created issues for me with cgroups, so i switched
<civodul>hmm ok
<civodul>elogind is special: it is started eagerly via shepherd, but it can also be started on-demand by dbus-daemon
<civodul>it's quite thorny
<civodul>ideally, dbus-daemon and shepherd would merge :-)
<bjc>yeah, and it seems to do a lot of stuff. probably something to do with it being excised from systemd ;)
<zacchae[m]>Alright, I installed gcc and binutils, created a three-line main function (char * buf; sprintf(*); system(*);) in c. This fails with "ld: cannot find crt1.o: no such file or directory"
<bjc>i know this is probably heretical, but the more i think about the way i want shepherd to work for me, the more i start to think, “maybe it makes more sense to just integrate systemd”
<zacchae[m]>Resources online say I need multilib gcc. That can't be right... How could such a simple c program fail to compile?
<bjc>i don't even like systemd, but it's a lot of work to get shepherd where i'd like it, and i'm not sure i understand the value
<nutcase[m]>civodul: I commented on
<atka> down?
<nutcase[m]>civodul: I also tried to build the package from a modified git working copy, but failed in doing so
<zacchae[m]>Alright, I needed gcc-toolchain, but even then, I had to add LIBRARY_PATH=/run/current-system/profile/lib. I'm guessing this is on purpose, though I can't imagine why. Anyone know why */profile/lib (system, home, package) aren't added to LIBRARY_PATH (or GUIX_LIBRARY_PATH?) by default?
<jpoiret>civodul: yep
<jpoiret>bjc: i'd say the value of shepherd is that it's in scheme
<jpoiret>although it's not as malleable as guix for example, it can definitely be, as opposed to systemd where you are tightly constrained by whatever upstream deems to be ok or not
<bjc>i think i don't value that as highly as others. maybe one day i'll see the light =)
<bjc>it's more in the “nice to have” camp for me, and has some of its own unique downsides
<ellysone[m]>hi, since gcc:lib is gone, how do you access libstd++ and libgcc in a guix shell? Asking in order to run the tor browser binary
<Altadil>ellysone[m]: I needed to add libgccjit
<Altadil>and libcxx as well
<ellysone[m]>Altadil: thanks
<bjc>woof. this slim issue seems like an old long-standing bug that gcc11 finally sniffed out
<civodul>atka: it should be back up (i restarted it)
<nutcase[m]>bjc: a bug known upstream?
<bjc>nutcase[m]: it's in the issue tracker, and fedora has the same patch for it i was going to implement
<bjc>i've sent in a patch
<nutcase[m]>bjc: you also created a PR upstream?
<bjc>no, one already exists:
<nutcase[m]>Only 17 months old ...
<bjc>i don't think slim gets much active development anymore. there's a slim-ng project i just found out about while i was looking at this issue…
<bjc>yeah, the last commit was the end of 2013
<nutcase[m]>Thank you for investigating and fixing the issue. To be honest, I see my display manager about once in a month only. Maybe I just switch the DM again?
<bjc>eh, i'm not a big advocate of switching things that work just cuz they get old
<bjc>slim is tiny and does its job. it's less likely to have bugs than more complex things that are actively maintained, imho. though it obviously does contain at least one
<nutcase[m]>Yes, it just did its job
<nutcase[m]>You were chatting about greetd. Is that an alternative (that also just does its job)?
<nutcase[m]>Or gtkgreetee respectively
<bjc>greetd is not simple, it is written in rust