IRC channel logs
2023-04-28.log
back to list of logs
<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 <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/libappmenu-xfce.so' <Grimpper>Installing subprojects/registrar/appmenu-registrar to /gnu/store/...-xfce-appmenu-gtk-module-0.7.6/libexec/vala-panel Installing applets/libappmenu-xfce.so to /gnu/store/...-xfce4-panel-4.18.3/lib/xfce4/panel/plugins FAILED: meson-install <Grimpper>For context this is the derivation: paste.debian.net/1278736 <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 <jpoiret>unmatched-paren: have you tested it out on the guix codebase? <jpoiret>I remember writing some match-records with thunked fields myself <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>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 <abrenon>I tried including %base-packages, glibc and glibc-locales into my profile but it didn't change anything <abrenon>well there is one defined in my --pure environment <abrenon>not pointing to /run/current-system but to some location in the store <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 ? <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 <civodul>looks like issues.guix.gnu.org 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 <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>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 <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>bost: emacs-guix has a derivation mode i think <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 <jpoiret>futurile: you should try to `git clean -dfx` in the checkouts in ~/.cache/guix/checkouts/ <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>this broke some proot tests, so i'm fixing them upstream, but there's also one that has a nontrivial failure <jpoiret>apteryx: andreas reported it to be working after installing it in their profile <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! <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"? <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 <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>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>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>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 tried figuring out where/how that got set in Fedora, but I think it wasn't obvious. <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) <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 <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>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) <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 <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>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' <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 <efraim>civodul: I don't, I reran it immediately and then it passed <patched[m]>What package is libstdc++.so.6 in now that 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 <jpoiret>ls does not recurse into subdirectories <bjc>bjc@psyduck:~% guix shell which gcc-toolchain -- which c++ <bjc>/gnu/store/x35ljd0cb4yhvwrfnnzg3mlcpcfw7my2-profile/bin/c++ <patched[m]>Same result with tree. Also I missed a /lib on GUIX_ENVIRONEMNT in the message <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 <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 :^ <jpoiret>gcc wasn't removed, just hidden, and that was before the core-updates merge i believe <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.. <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. <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 <civodul>jpoiret: i had never thought about it (passing messages among services), but it should easy to do <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. " <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 <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>with SGML messages sent over TCP/IP, and a reference implementation in C89 <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 git.savannah.gnu.org: Temporary failure in name resolution <apoorv569[m]>internet is working, I'm on same networking messaging here. <mirai>civodul: what do you think on shepherd accepting a new keyword argument #:capabilities for make-forkexec-… & friends? <civodul>but #:capabilities in what sense? POSIX or "actual"? <mirai>things like CAP_NET_BIND_SERVICE <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 <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 <spiderbit>there is a package called gnome-settings-daemon, but there is no binary inside any idea how to start it? <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>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>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 <apteryx>I wonder why this needs to be specially handled instead of always available in Guile <mirai>apteryx: I remember asking civodul about a similar question <mirai>try searching the logs of this channel <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 <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.. <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) <unmatched-paren>spiderbit: also, i'm pretty sure there's a much easier way to do this :) <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 <jpoiret>guix home is still considered experimental <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 <mirai>writing documentation isn't “easy”, moreso for _good_ documentation <mirai>and it doesn't tend to be a satisfying job <apoorv569[m]>In my config I mentioned the @logs subvol as @log instead.. <spiderbit>unmatched-paren saw that, but it's not clear what the documentation really means <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")))) <unmatched-paren>^ this will link /bin/ec to /gnu/store/...-emacs-.../bin/emacsclient <unmatched-paren>yeah, if you use SIMPLE-SERVICE you don't have to explicitly re-specify the defaults, too <mirai>jpoiret: writing the docs in docbook but as sxml, this way it can be reasonably embedded within the codebase <spiderbit>you mean it links to the binary emacsclient? <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 <unmatched-paren>right, so, you can just replace (file-append ...) with (local-file ...) <spiderbit>the -n has probably to go I think wasn't that cli <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>that is just a small side thing... that I thought I do for it <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 <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>well, the intention is that the things you move into guix home, you also remove from your regular profile <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 <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 <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>I want to go a bit baby step before I commit all in <spiderbit>it just should put the file in /home/.../bin/ <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 :) <unmatched-paren>anyway, the variables from that service eventually end up in a regular old bash script :) <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>btw the Scheme equivalent of CONCAT is STRING-APPEND (yes, it's too long :P) <spiderbit>I think format is the way to do everything in guile I think :D <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 might be better to just add my original version to your system file... <spiderbit>but the -r--r--r-- 1 65534 overflow 74 Jan 1 1970 /gnu/store/7vk8k3ssi9qfz0wn7agfrhsdpvl0znyn-ec <unmatched-paren>you can replace the (local-file ...) with the (program-file ...) form <spiderbit>so I have to use program-file "ec" (plain-file..) <unmatched-paren>(computed-file "ec" #~(begin (copy-file #$(local-file "ec") #$output) (chmod #$output #o555))) <ieure>If you don't want to do it all in Lisp, Guix may not be for you. <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 <unmatched-paren>for instance, #$(local-file "ec") builds that local-file and expands to its path in the store <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 <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 <spiderbit>boahh bash only understands absolute paths and relative to cwd <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 <spiderbit>well I searched a few days ago a alternative to emacs tramp <spiderbit>the only thing I remember being like that was gnu hurd <spiderbit>that can use remotes or protocols as folders <jpoiret>~ is a feature that so many people think is universal but unfortunately it's just a very useful hack :) <spiderbit>.../bin/sh: bad interpreter: No such file or directory <spiderbit>which probably makes sense but bad for my problem :D <spiderbit>probably would have to logout my whole X session <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]>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? <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 :-) <jpoiret>civodul, bjc: i get "unable to start greeter: authentication error: pam_open_session: SERVICE_ERR" <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 ($ <...> ...) <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? <civodul>jpoiret: that error though, could it be an undeclared dependency on some other service? <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 <unmatched-paren>jpoiret: there's currently no uses of MATCH-RECORD-LAMBDA, but there are plenty of MATCH-LAMBDA ($ <...> ...) <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/pam_elogind.so" 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 <jpoiret>unmatched-paren: you might be matching against a bona fide guile record though <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) <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 https://issues.guix.gnu.org/63068 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>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>elogind is special: it is started eagerly via shepherd, but it can also be started on-demand by dbus-daemon <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 <atka>packages.guix.gnu.org 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>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 <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) <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 <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]>You were chatting about greetd. Is that an alternative (that also just does its job)? <bjc>greetd is not simple, it is written in rust 