<nij>Hello! From a package definition we get a derivation. Then what's the point of G-exps? <cbaines>G-expressions are higher level abstractions for derivations too <cbaines>they're used lots for service definitions for example <nij>Right.. this is the impression I got from the manual. <nij>But isn't package definition good enough? <nij>Or G-exps allow more fine-grained controls? <cbaines>have you looked at some of the G-exps used for services? <cbaines>One thing to note is that G-exps are composable Guile code, so #~(make-kill-destructor) is a G-exp, just a single procedure call <nij>I haven't. Just compiled the first package in Guix. Am skimming what to learn next. <nij>cbaines: I will look into some specific examples and see what it can do. Thank you :) <cbaines>there is the potential that G-expressions might take a role in packages at some point, but that's quite a complicated topic <nij>(Oh no.. less lispier GUIX will become?) I will keep this in mind.. <cbaines>I don't quite understand your concern, but I think it might simplify writing some package definitions <Gooberpatrol66>I get ld: cannot find -lncursesw when I try to run make menuconfig <Gooberpatrol66>ncurses-with-gpm says it provides libncursesw, but it seems not to work <Gooberpatrol66>-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -I/gnu/store/mhwsnsh0dyb7vn8jx0y29gp9k22lk39z-ncurses-with-gpm-6.2/include <Anonymous__>If you just want to give a quick try instead of changing the make files etc just try ***Sleep_Walker is now known as Noctambulist
***Sleep_Walker[m] is now known as Sleep_Walker
<rictjo>good day everyone. I am having a problem with upgrading my guix system. It can build but after the switch to kernel 5.10 from 5.9 it says it cannot find my root luks partition anymore. Displaying an error from ice-9/boot-9. However I can boot the old config. I also tried using an almost identical config file but there is something that I don't understand here. I am completely new to this system and started using it 2020-12-25 (working config a <mdevos>rictjo: your message seems to be cut of after ‘(working config a’ <leoprikler>If it's the kernel, you should be able to fetch an old one using inferiors. <vagrantc>rictjo: possibly a change of needed available kernel modules to mount your root device? <vagrantc>sometimes happens between major kernel versions <vagrantc>rictjo: you also might try using an older kernel with the same updated config otherwise <vagrantc>rictjo: i think linux-libre 5.4 should also be available ... and that could rule out a problem with newer software and really identify that it was the kernel that was the problem <rictjo>right so inferiors to 5.4 if ok check kernel modules <vagrantc>guix ships multiple kernel versions ... all the currently supported LTS kernels in addition to the current kernels <rictjo>just specifying the 5.4 kernel then <vagrantc>that of course assumes 5.4 kernel will boot :) <rictjo>There was another quirky behaviour. I am using a swedish keyboard keymap and by intial grub image boots fine and I enter the encryption password. But the boot image keymap was not swedish even though it is set by the intial graphical installer generation script to swedish everywhere <mdevos>if I understand correctly: when booting, GRUB asks for password with swedish keyboard (weird, GRUB in Guix doesn't yet support setting the keyboard layout before disk decryption), and when booting Linux, Linux asks for a password with a non-swedish keyboard (I presume qwerty?) <mdevos>rictjo: you can test what GRUB uses, by entering a bogus password, then typing random characters to test in the rescue shell <rictjo>aha no I was being unclear and I see it is intended behaviour <rictjo>I was entering the encryption password with US keyboard setting (the hardware is swedish) <mdevos>rictjo: ah, something like that is the case for me as well. I enter the password as qwerty in GRUB, and azerty in Linux <leoprikler>raghavgururajan: looking at it, it seems like they want to generate some xml file from something else, but are failing, because a) it isn't writable (try to make-file-writable before) and and b) some weirdness in etree, that doesn't allow you to pass raw filenames <leoprikler>if b) would actually be caught somewhere it's actually just a) <leoprikler>I don't think there's a "write" module unless it's perhaps a submodule of something else <wingo>is there a canonical "how-to" article for using guix for reproducible research? or is civodul's paper from last year the thing *wingo tries guix time-machine <leoprikler>raghavgururajan: yep, it's a 'str', which has no 'write' attribute – attributes in python can be anything from variables in a module to fields/methods of an object *dftxbs3e is working on packaging gutenprint/gimp-print for their canon printer (also supports many others) <sakalli>hi all. n00b here. if i want to write a package that downloads a gtk package from github and makes it accessible from a specific path. the package has no build files. what would be the simplest way of doing it. is there perhaps an example you could point me to. as an aside, installing gnome-themes-standard/extra does not show up as options for my theme manager. using lxapparence. the pacakges are downloaded to the store tho. <rictjo>I posted previously about an error with LUKS devices during boot. It seems as though everything is working as intended but the problem arises when I want to place my home on a completely different encrypted drive than the root and boot. I see a reported warning that the new drive _might_ not be moutned during boot. After selecting the new image and entering the pass for the root and boot drive the locking is aborting saying that /run/cryptsetu <rictjo>that it could not acquire a read lock on the device <sakalli>sorry see that i was expressing myself confusingly above. just to be clear, talking about writing a package that installs a gtk-theme from github. <rictjo>I was able to create my system config by first mounting my encrypted device <rictjo>which was not present when the root,boot and home was placed on the same disk <rictjo>not sure because it fails directly after entering the first device pass, but it complains about not being able to acquire a read lock on the second (new home) device <rictjo>so it seems it accepts the password for the first device <rictjo>I think that /dev/sdxN is not present but I don't know how to work with the problem in this environment <raghavgururajan>rictjo: I think both devices should be mentioned under `(mapped-devices` in config.scm <raghavgururajan>It is also good to use UUID while having more than one encrypted drive. <rictjo>I specify it with the UUID. Thank you <rictjo>I tried changing the device mapping from luks to lvm and not get the error "guix system: warning: cannot determine provenance for current system" <rictjo>which I do not understand what it means <efraim>sneek: later tell lfam I just built pulseaudio on my aarch64 board for staging, no problems like seen on cuirass *civodul tests an upgrade of guile-3.0-latest <jlicht>roptat: If you don't have time to play around /w GUIX_EXTENSIONS_PATH, I can have a look <rekado_>jlicht: the entry point module needs to be installed to /share/guix/extensions/<command>.scm <jlicht>rekado_: yeah, I was looking at your recent work on the gwl to see what's what <jlicht>the only question I still have is how/where/when to 'install' an extension :) <jlicht>as I only used the latest gwl with `./pre-inst-env' and GUIX_EXTENSIONS_PATH set, from a git repo <abcdw>leoprikler, civodul: yesterday I digged into systemd implementation a little and it seems that it starts user-space process with pam. pam looks like a more general than .profile for starting user-space shepherd. What do you think? <abcdw>leoprikler: I don't see what can stop us from it) <leoprikler>maybe shepherd being (mostly?) implemented in scheme, whereas pam is based in shared objects <nij>Hello! `xmobar` does not run correctly, with error: connectSession: DBUS_SESSION_BUS_ADDRESS is missing or invalid. How could I fix this? <civodul>abcdw: PAM? why not just start a per-user shepherd process, as discussed yesterday? <civodul>that would mean that it runs even when the user is not logged in, though *abcdw will be back in few minutes <abcdw>civodul: 1. lingering-shepherd is not always desired. 2. I also faced following issue with it: When you run a shepherd whithout user session it complains about missing XDG_RUNTIME_DIR/shepherd, which usually created by (probably) pam_elogind on user login. <wingo>ok guix i have a dumb question <wingo>which is my kind of guix question <wingo>if i try to configure guile within a pure environment from that manifest, guile's configure fails with a note that "libunistring wasn't configured with iconv support" <wingo>when in reality it's just that the compilation test for libunistring doesn't link at all <wingo>does this ring any bells? obviously this guix can build guile as it has guile *wingo looks at civodul with puppy eyes <abcdw>wingo: Why you building it manually? Maybe easier to just inherit original guile, but change source and inputs if it needed? <civodul>wingo: ah ha! that doesn't ring a bell <civodul>wingo: since you have "gcc-toolchain" there, you can remove glibc and ld-wrapper <civodul>what does the link error look like in config.log? <wingo>weirdly it compiles but doesn't run <wingo>abcdw: is for a research project <wingo>i want the source to be in the tree <wingo>the error is actually at runtime: <wingo>./conftest: error while loading shared libraries: libunistring.so.2: cannot open shared object file: No such file or directory <roptat>jlicht, thanks, but I think I can handle it <wingo>and running ldd sin that pure environment hows it can't find libunistring.so.2 <wingo>and running ldd sin that pure environment shows it can't find libunistring.so.2 *wingo tries removing glibc and ld-wrapper <wingo>civodul: fwiw the "ld" in that profile is not the scheme wrapper; dunno if that makes any difference <wingo>whereas if i do "guix environment --pure guile", then that ld is the wrapper script <civodul>wingo: normally ld is the one from gcc-toolchain, and that is the wrapper <wingo>ah i see the one from binutils <wingo>perhaps i need to remove binutils then, and that was the problem <civodul>oh right, you need to remove that one as well <civodul>alternatively, you could use (package-transitive-inputs guile-3.0) in the manifest, i think <civodul>hmm actually no, it's a bit more wordy <wingo>yeah i wanted basically the equivalent of "build-deps:guile" <wingo>and had to go poking around and obviously didn't do the right thing <wingo>would it ever make sense to have e.g. "build-deps:foo" supported by specification->manifest ? <jlicht>roptat: amazing, looking forward :) <civodul>wingo: yes, definitely; currently you have to write something like (bag-transitive-inputs (package->bag guile)) to get that <wingo>i would like to avoid having to know what a bag is :) i feel like i've paged it in a few times but it has always slipped out of cache <wingo>which either means that i don't learn new things any more, or it's not essentially important ;) <civodul>moved higher up in my to-do list :-) <apteryx>it is possible the GNU libc regex-exec changed its behavior since 2018 (or perhaps it was Guile 3?) It used to throw an exception when processing a string containing NULs; now it seems to just stop processing upon encountering NUL. <rekado_>jlicht: you just install it into your profile and manually set GUIX_EXTENSIONS_PATH to $GUIX_PROFILE/share/guix/extensions <rekado_>it might work to install the extension into the “guix pull” profile, which should cause GUIX_EXTENSIONS_PATH to be set automatically, but I don’t think that’s a good idea. <rekado_>(because I can’t say how this should be upgraded) <rekado_>you know, “guix pull” could also upgrade all *other* packages in its profile <rekado_>or channels.scm could have a field “extensions” with a list of *packages* to install into that profile. <rekado_>civodul: what do you think about that? Add support for a “packages” or “extensions” field to the “channels” file, which would make “guix pull” install that package into the profile once “guix pull” has completed. <apteryx>eh, was Guix circa early 2018 still on Guile < 1.8.2? Guile's changelog for 1.8.2 says: ** `regexp-exec' doesn't abort() on #\nul in the input or bad flags arg <khassanov><lfam "khassanov: I add that to the (se"> Thank you, it works! <apteryx>the oldest existing Guile tag is v2.0.0 <apteryx>Which was made Wed Feb 16 10:25:23 2011 <rekado_>apteryx: I remember the substitute* problem. <rekado_>apteryx: guix environment --pure --ad-hoc guile@2.0 -- guile -e '(regexp-exec (make-regexp ".*d") (string #\a #\b #\c #\null #\d))' <apteryx>no code for module (ice-9 readline) ? <rekado_>try in a container or move your ~/.guile out of the way <apteryx>with --container --no-cwd, I can reproduce :-) thanks! <apteryx>I guess the problem is perhaps worked around above the call to regexp-exec in Guile 3, if it is <apteryx>this also crashes: guix environment --container --no-cwd --pure --ad-hoc guile -- guile -e '(begin (use-modules (ice-9 regex)) (list-matches ".*d" "a\0d"))' <rekado_>not surprising since list-matches uses fold-matches, and fold-matches uses regexp-exec <rekado_>the shortest reproducer is probably (regexp-exec (make-regexp ".") "\0") <civodul>rekado_: adding a "packages" field to .guix-channel could be useful, indeed <wingo>apteryx: there are older tags, e.g. release_1-6-8 <wingo>different format in those days <xelxebar>Trying to use some bluetooth headphones with bluez-alsa but not having much luck. <xelxebar>Doesn't seem like there's a service to run bluealsa? <xelxebar>Trying to invoke directly errors with: bluealsa: E: Couldn't acquire D-Bus name: org.bluealsa <apteryx>any idea why "guix environment --container --ad-hoc guile guix -- guile reproducer.scm", where reproducer.scm is https://paste.debian.net/1180208/ returns: warning: possibly unbound variable `call-with-temporary-output-file' ? <apteryx>this should be defined, having imported the (guix build utils) module <sneek>zimoun was in #guix 22 hours ago, saying: civodul: with old ad2c3ba, it works. :-) So the recent guile-json seems a reasonnable culprit. I will give a look later if you do not beat me. ;-). <rekado_>xelxebar: I use bluealsa on my living room “server” for mpd; no service. I just run it manually. <apteryx>ah, my confusion stemmed from guix-core-updates vs guix master. On master the 'call-with-temporary-directory' is still defined in (guix utils) rather than (guix build utils). <apteryx>err, call-with-temporary-output-file* <xelxebar>rekado_: Hrm. You just run `sudo bluealsa`? That's giving me the error above. <rekado_>xelxebar: I use “su -” to become root, and then I run “bluealsa --ldac-abr --ldac-eqmid=0 --a2dp-keep-alive=15 --a2dp-volume --sbc-quality=3 &” <rekado_>it’s a headless machine BTW, so this should not depend on other desktop services <rekado_>xelxebar: my system has this service: (dbus-service #:services (list bluez-alsa)) <rekado_>also this: (bluetooth-service #:auto-enable? #t) <apteryx>rekado_: fun, I finally found a way to reproduce. Setting LANG prevents the problem from ocurring, for some reason. <apteryx>so this: guix environment -C --ad-hoc guile guix -- guile reproducer.scm reproduces the "string contains #\\nul character: ~S", while with the -E LANG option, it doesn't. <apteryx>LANG is set to en_US.utf8 on my machine <civodul>apteryx: regexp-exec is a binding to the C function, so the string you pass cannot contain nul <civodul>the only way to work around it is to have a regexp implementation that does not use the C library's implementation <apteryx>what I don't get right now is why setting LANG=en_US.utf8 prevents the error from being triggered <civodul>hmm not sure why changing the locale helps <apteryx>The fix proposed by Mark in 2018, to remap NULs to other private unicode code points, works <apteryx>I'm just trying to completely understand what's going on as my initial attempts to reproduce the crash proved non trivial <apteryx>From what I understand, the locale (via LANG environment variable) shouldn't play a role since I'm setting %default-port-encoding to "UTF-8"; but interesting, it does. <civodul>jas4711: hi! looks like guix-x15 is offline; could you take a look? <apteryx>In one case the regex-exec code crashes, in the other case it doesn't. <civodul>apteryx: the libc function is locale-sensitive *jas4711 going downstairs <jas4711>civodul: one of them is up now. i'm doing an upgrade of debian <jas4711>civodul: it seems to have died 2020-12-29 <civodul>ok (and it seems we have suboptimal monitoring :-)) <civodul>dongcarl: that looks a bit scary, as it could be a userspace/kernel incompatibility <civodul>it would be nice to see if using an i686 kernel helps (in a VM i guess) <jas4711>there was a power outage then -- these devices doesn't power themselves on automatically <jas4711>civodul: ok to reboot the machines? they are busy building things <dongcarl>civodul: I know you've got a lot on your hands, so I'm happy to do the grunt work :-) <dongcarl>Can you briefly describe why you think using an i686 kernel might help with diagnosis? Just so I have a clearer idea <nojr>is it possible to install guix on a RK3308 ? <civodul>dongcarl: it semes that while the actual stat(2) syscall returns 0, user space sees it as returning something else <civodul>as if there's a user/kernel mismatch somehow <civodul>normally the kernel is able to determine whether it's a 32-bit program making the syscall <civodul>it would be great if we could build a program with the same compiler and the same libc as this bash <apteryx>civodul: makes sense, thanks for providing the last bit I was missing <civodul>jas4711: could you postpone the one that's building guile-3.0.5? <civodul>the other one is less important to me :-) <dongcarl>civodul: Yeah that would be great... I don't think we can do `guix environment` on a derivation yet tho, can we? <civodul>dongcarl: not on an derivation, but maybe you can find the actual package and then do: guix environment -e '(@@ (gnu packages commencement) bash-whatever)' <dongcarl>Not entirely sure... This is the bash used to build binutils-mesboot0 <dongcarl>patch-shebang: ./config.status: changing `/bin/sh' to `/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh' <civodul>"guix graph" suggests it's built by tcc-boot@0.9.27 <dongcarl>Would --build/host=i686-unknown-linux-gnu have something to do with this? <civodul>bash-mesboot0@2.05b is built by tcc-boot0@0.9.26 <civodul>no that's fine, this option just makes things explicit <dongcarl>Okay, so here's a conundrum: I am in my older Guix version, and the bash-mesboot0 is in the newer version, so I can't directly do: guix environment -e '(@@ (gnu packages commencement) bash-whatever)' <dongcarl>And I think if I use time-machine, it will try to build the package that's causing this in the first place, and fail... *dongcarl really wishes it were possible to do `guix environment` on a derivation <jonsger>somehow debbugs doesn't like me anymore. I can not close bugs anymore... <raingloom>how do i convince D-Bus to let me start snapperd? it's not picking up the config from the --ad-hoc env. do i have to install snapper globally or something? <apteryx>Should the Guix test suite be ran under a given locale, as otherwise it'd be susceptible to user chosen ones? *jonsger adds `fail2ban` to his personal todo list... <apteryx>civodul: do you think we can close #26948, or is there something more we could do? <apteryx>It seems the issue was that "Guile does not allows us to specify whether/how file names should be decoded". Wouldn't setlocale be used for this? <antidoto>I am trying to schedule a job using mcron. I have added something.guile in ~/.config/cron and then running mcron the cursor just hangs and sudo mcron gives me: Cannot read files in your ~/.config/cron (or ~/.cron) directory. With sudo herd status I can see that mcron is running. <antidoto>Cannot read files in your ~/.config/cron (or ~/.cron) directory is also the output in mcron --schedule=5 <apteryx>antidoto: so when running as your user the cursor hangs? <apteryx>jonsger: I just used emacs-debbugs to send done to 45047, thank you! <apteryx>antidoto: I thought I had a local example but no, I only have a user shepherd instance. <jonsger>apteryx: thx, hopefully I can close reports in the future myself. It worked before... <antidoto>apteryx: I really didn't understand what you mean. My knowledege in gnu/linux services, and even more in guix is extremely limited. I did guix install mcron and had the same result. After guix remove mcron, running mcron now shows the same message as above. <apteryx>antidoto: I just meant that I thought I had mcron examples of my own to perhaps help you with, but sadly I don't have any. <apteryx>I think it's normal though, it probably just runs as a daemon and prints nothing <apteryx>I mean, it runs in the foreground by default. You can pass -d to have it run in the background. <antidoto>mcron -d shows the same message about Cannot read file...... Maybe it happens because I installed and the removed cron as a user? <apteryx>perhaps there's a syntax error in your job file? <antidoto>replacing my code with yours and doing mcron -d now works. I can see the the job with mcron --schedule=5. So it must be a syntax error. <antidoto>So... I have deleted the file, but it keeps loging the date. How can I stop it? <apteryx>you have to kill the PID of the mcron process that was forked into the background <apteryx>'pgrep mcron' or 'ps aux | grep mcron' should provide a list of mcron processes. Make sure you kill the one that was started by your user (most likely the one with the highest PID). <apteryx>Would someone have an idea about how test efficiently a world rebuilding change with 'make check'? It tries rebuilding the world in its test-tmp directory. <antidoto>apteryx: I have succesfully stoped the loging and learned many things from you. Now I need to figure out what is wrong with my syntax. But first I am going to bed. :) Thank you! <apteryx>antidoto: have a good night! Happy to help :-) <civodul>it would be best if we could choose file name encoding independently of the current locale in Guile <civodul>but for now what we have is good enough <leoprikler>raingloom: yep, global install is required to pick up dbus autostarts, but you can also start the service manually and it should register itself <leoprikler>assuming that the service behaves sanely in such a situation, which some don't