<db48x>rndd: I don't know how the asdf-build-system works in guix, but that's where I would look <db48x>perhaps it tried to parse the version number and that failed because this package doesn't use a number? <leoprikler>dustyweb: okay, I am now somewhat aware of what you're going for <leoprikler>It seems like you'll have to add it to (guix gexp) along with a (define-gexp-compiler setuid-program-compiler <setuid-program> ...) <leoprikler>Okay, I was mistaken, you can define it outside as well ***catonano_ is now known as catonano
<buenouanq>Trying to install GuixSD on a 2011 Macbook Air. <buenouanq>When I dhclient it hangs DHCPDISCOVERing a bunch and then fails. <buenouanq>then `No DHCPOFFERS received.' `No Working leases in persistent database - sleeping.' <roptat>though if the interface shows up, that should be fine <buenouanq>The interface was softblocked so I did do rfkill unblock. <buenouanq>using wpa_supplicant which `Successfully initialized wpa_supplicant' but then hangs <buenouanq>returns with no error, but ip link still shows DOWN after... <buenouanq>lfam: send wpa_s.. to the background I think <lfam>So, the link is up and connected to the AP, but you can't get an IP assigned via DHCP <buenouanq>the command to bring the link up runs without error, but does not actually change the interface from DOWN to UP <iyzsong>did wpa_supplicant said it connected to the AP? you have to write ssid and psk in the config file, and sometimes pass '-Wext' with the command iirc. <buenouanq>wpa_sup returns `Successfully initialized wpa_supplicant' <iyzsong>um '-Dwext', some card need that driver <kozo[m]>Is there something new required for nix to work on guix using the service? I followed all the steps and it's working up until I run programs. It can't find files in it's own opt directory <lfam>Hm, was it working for you previously, kozo[m]? <kozo[m]>I'm trying it again to ween myself off flatpak <kozo[m]>This is when I run Discord. File does exist and permissions are set as 444 <lfam>Hopefully someone else knows more about our nix service <kozo[m]>Thanks lfam. I'll perhaps bring it up during EU primetime <kozo[m]>Would something like this be OK to send to the mailing list since it talks about non-free programs? <lfam>I recommend finding an example based on a freely-licensed program <lfam>You will get more help that way. We prefer not to offer support or recommend software that's not freely-licensed on our communication channels <lfam>Having said that, I'm not so familiar with nix (I've used it and assume the design is still very similar to Guix's), so I really don't know what could be going wrong here <lfam>If I had to guess, the problem would be that the environment isn't being set up properly when packages are installed, but I don't really know <buenouanq>I've come across something like: (version (package-version package \ in a package def, but the hash is still a hardcoded string... Can I somehow download and calculate the hash in place in the config? <buenouanq>... (inherit [package]) (version (package-version [package])) ... (sha256 (base32 "h4sh...")) ... <lfam>It's definitely possible — That's basically what `guix refresh --update` does <lfam>Well, I don't know. It's a tool for people working on packages <lfam>I just mean that it's possible to do <buenouanq>this is my first time delving into that myself I guess <lfam>Come on in... the water is wet! <buenouanq>`In most cases, updating a package to a newer version requires little more than changing the version number and the checksum. Guix can do that automatically aswell: $ guix refresh hello --update' <sss2>hi all, is it possible to use distributed compilling with guix on non-guix host os ? <leoprikler>IIUC all you need is the package manager plus some setup in /etc, but that's only as far as the documentation explains. <sss2>i see config samples only for system, not for standalone guix ( <leoprikler>Are we talking about `info '(guix)Daemon Offload Setup'`? <pinoaffe>Hi guix! in (guix build profiles), the function `build-etc/profile` generates posix shell code to enable the given profile - would it be a sensible addition to guix to also generate, say, guile code? <leoprikler>for which purpose exactly? so that you can run $GUIX_PROFILE/etc/profile-wrapper.scm <shell command>? <pinoaffe>leoprikler: I figured it'd be handy to have access to the required environment variable changes in a format different from posix shell, particularly since I want to be able to enable profiles in a guile/emacs/whatever process so that the profiles are enabled in any child processes forked off from said process <leoprikler>pinoaffe: Have a look at `guix package --search-paths -p <profile>` <leoprikler>it will return a set of export VAR=VAL assignments, that you can easily parse and pass onto your language's setenv <pinoaffe>leoprikler: thanks, I gues that'd do the trick <sss2>leoprikler, > Are we talking about `info '(guix)Daemon Offload Setup' - yes <sss2>i will retyr, but it does not worked for me on first attempt <leoprikler>The setup is admittedly non-trivial, but nothing mentions exclusivity to Guix System. <sss2>hm..., or not, anyway, i will retry, thx <sss2>good to know, so probably i did something wrong <sss2>also, related question, how to make guix binary in path for non-interactive shell <sss2>for now i workarounded this by simlinks in path, but i know this is not proper way to do this] <leoprikler>if you're on a foreign distro, you would probably need source ~/.config/guix/current/etc/profile as well as ~/.guix-profile/etc/profile. <leoprikler>[of course long variant, i.e. GUIX_PROFILE=$(HOME)/.config...; source $GUIX_PROFILE/etc/profile] <sss2>yes, but how to do this for non-interactive shell ? <sss2>~/.bashrc ~/.zsrc and other rc's obviously does not sourced in this case <leoprikler>you don't put such things into ~/.<x>rc, but ~/.<x>profile <sss2>leoprikler, where i can read more about this ? <leoprikler>In your shell's documentation, but if you just want to understand the rationale, I can explain it shortly <leoprikler>Putting Guix profile setup into .<x>rc is evil and will be punished with borked environments. <leoprikler>The reason for that is that .<x>rc will be evaluated whenever you spawn a shell, that is also for the shell-in-shell case. <leoprikler>If you do that in guix environment --pure|--container, well... your "container" is now no longer pure. <leoprikler>profile on the other hand is executed on login, which is exactly what you want for shells, secure or otherwise <sss2>but does it executed byt non-interactive ssh sessions ? <divoplade>.profile is not sourced when I connect via ssh <leoprikler>add an echo "Hello world" to it and you shall see <divoplade>OK with this in .bashrc the environment is set up when connecting through SSH but the pure environment works as expected <divoplade>test "x$SSH_CLIENT" = "x" || source ~/.profile <sss2>so for "global" environment - .Xprofile, and for other shell settings - .Xrc ? <g_bor[m]>FYI: the install of the 1.2-rc1 finished. <g_bor[m]>Everything seems to be working normally, at least for a very basic install. <sneek>Welcome back PotentialUser-35, you have 3 messages! <sneek>PotentialUser-35, nckx says: If you're the same PotentialUser that asked about Eiffel: Thank you for the kind words ☺ Unfortunately, the Liberty Eiffel ‘source’ consists of machine-generated C created by a previous version of LE. So it's not bootstrappable as-is. <sneek>PotentialUser-35, nckx says: Maybe if we start from an ancient version of SmallEiffel (that's 2 projects ago, pre-SmartEiffel...), but I'm not hopeful. There's other non-bootstrappable software in Guix but it's actually something we want to avoid wherever possible. Sorry. <sneek>PotentialUser-35, nckx says: If you're not the intended recipient, you must of course destroy the above message. <divoplade>My computer does that too if there are firmware missing <nixo_>Hi guix! I had a couple of packages that some months ago used to compile just fine, but that now fails with undeclared functions (std::sin, std::atexit, ::atol) did anything change in older GCCs? <leoprikler>nixo_: perhaps your paths have been outdated after a GC? try reconfiguring the source and ensure that everything is set up correctly <dannym>janneke: I've responded to your mail a few min ago; and am testing a Mes with better integer division algorithm right now on Banana. <dannym>janneke: but the other problem we found might implicate setjmp. But that was in the gcc-compiled version, right? Is that still using mes' setjmp ? <janneke>dannym: yeah, just reading it -- great! <janneke>yes, that's gcc with libmes (to make sure we get bit-for-bit identical traces) <janneke>the setjmp is only used in tcc in case of errors, so ... <janneke>we only need it to work if things go wrong ;-) <dannym>I'm pretty sure I haven't checked lib/arm-mes-gcc/setjmp.c much. After all, is much more aggressive caching variables in registers, so if I forget one register gcc needs that could totally explain this tcc_state variable seemingly going to 0 <dannym>If it has been cached in a register <dannym>(gcc much more aggressively caches variables) <HiPhish>I have a locale problem: I did the two steps from the Application Setup section of the manual. <HiPhish>But I still get hint: Consider installing the `glibc-utf8-locales'... message <HiPhish>Even worse: Guile does not know how to print non-ASCII characters. <HiPhish>For example, system-guile prints (display "асдф") just fine, but Guix Guile prints a bunch of questions marks. <janneke>HiPhish: this works for me: ./pre-inst-env guile -c '(display "асдф\n")' <HiPhish>janneke: Yeah, it seems to be a foreign distro issue. I had the same problem in Kubuntu. I was hoping that Void would fare better. <HiPhish>At least that's what the environment variable is set to. <cbaines>The name of the glibc-utf8-locales package is a bit misleading, it's more like some-glibc-utf8-locales <cbaines>It doesn't actually include en_GB.UTF-8 <HiPhish>cbaines: That's why I installed glibc-locales instead, to be on the safe side. <cbaines>Ok, and what's GUIX_LOCPATH set to in your current shell? <HiPhish>/home/hiphish/.guix-profile/lib/locale <HiPhish>Do I need to install glibc-locales twice? Once for me and once for root? <HiPhish>Would it be a problem if I did? I did that when I was trying random things. <cbaines>I wonder if guile is linked against the glibc version that matches the version of the glibc-locales package <cbaines>You've got guile installed in your profile right? <HiPhish>I installed Guix manually from binary, release 1.1.0 <HiPhish>cbaines: What do you mean by "in your profile"? <cbaines>HiPhish, like, does guix package -I list guile? <cbaines>If it does, it's installed in your profile <cbaines>Ok, what do you see in ~/.guix-profile/lib/locale <cbaines>Ok, and does ~/.guix-profile/lib/locale/2.29/en_GB.UTF-8/ exist? <cbaines>That all seems OK, so assuming guile is using glibc@2.29, I think it should be OK <HiPhish>How do I find out whether it is using that version of glibc? <cbaines>If you follow the symlinks, and find the store item for guile, what do you get? <HiPhish>/home/hiphish/.guix-profile/bin/guile <HiPhish>/home/hiphish/.guix-profile/bin/guile: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped <cbaines>but you have the locales installed for 2.29 <cbaines>Seems like guile was using a later glibc <cbaines>So maybe you did guix pull in between installing glibc-locales and guile? <HiPhish>I usually run guix pull and then wait a day or two so that the substitute binaries are built and I don't have to build from source. <HiPhish>Thank you very much, now I can use Guile normally again. <divoplade>Dear guix, does anyone have a prosody service? Mine ignores signals, so it's not possible to stop it. <divoplade>Well, if I run prosodyctl stop, I get Still waiting... and then it tells me prosody is still running <db48x>this is really starting to annoy me: <db48x>In execvp of less -FXRS: No such file or directory <sss2>leoprikler, problems woth ~/.profile was caused by incorrect system wide rc inherited from gentoo in 2008 ) <sss2>now all works as it should (env i mean), build offloading not tested yet <sss2>ah.., i am growing old ( <guixer>hej Guix! I'd like to set certain locale settings globally. Like LC_PAPER or LC_COLLATE. Default should be EN_US.UTF-8, but a few settings should be POSIX C or some other locale. Unfortunately I don't know how to set these properly. Also on guixsd the locale command is not available (by default) and I don't know what to install to get it. Any <ryanprior>db48x: I wonder if Guix needs less, why doesn't it depend on it? <nckx>It doesn't need it, and it shouldn't depend on it, but it could handle its absence better. <ryanprior>"It doesn't need it, it just crashes without it" seems like a distinction without a difference <db48x>acutally, the problem is that it's trying to run 'less -FXRS' <ryanprior>Ah so if it did shell-like splitting on the string then it would work? <db48x>you can reproduce with PAGER=less -FXRS guix search foo <nckx>db48x: Did you set PAGER to that? <db48x>everything else that uses PAGER works fine with it <lafrenierejm>During build phase I'm getting "error[E0463]: can't find crate for `tree_magic`" <nckx>Guix ‘[sets $LESS] unconditionally because some distros set it to something that doesn't work here’ to complicate matters even further. <nckx>Hm, now it prints nothing if $PAGER is set but empty. <nckx>Yeah, no regression on the previous behaviour. <nckx>Prolly not, but is there an elegant equivalent for (or a b c) but for "" instead of #f? <nckx>That would be ‘good enough’. <db48x>nckx: (any non-empty '(a b c)) <nckx>I knew it existed. Thanks. <nckx>I was looking for ‘or*’, no idea why, and probably a reinvented wheel I once saw. <nly>$ guix patch-shebang pkg ;; a man can dream <jonsger>hmpf, I don't understand why my service is started as root and not as service user <nckx>jonsger: (make-forkexec-constructor … #:user … #:group …)? <divoplade>Do you have to define that user somewhere else in the configuration? <nckx>Yes, you need to extend account-service-type. <dustyweb>define-gexp-compiler is kind of generic-ish I guess <nckx>Ehm *says random thing* I'm sure mysql does that 😛 <nckx>So (gnu services mysql). <nckx>Nope, (gnu services databases). <nckx>For a more complex example see getmail (gexps! spooky). <dustyweb>I have "dustyweb is unsure, conceptually, if they understand what they're doing" questions :) <dustyweb>I'm trying to see if my impression is right about what was proposed on-list <dustyweb>that the goal of adding the gexp compiler is so that <setuid-program> could be defined either outside of or unquoted in the gexp, but "passed through" <dustyweb>basically, "is the goal to allow it to be handed off from one layer to another in effectively the same structure" <cbaines>Do you have a link to the list post? <dustyweb>cbaines: it's to enable the postfix stuff <cbaines>Ok, so I've found the relevant activate-setuid-programs procedure now <cbaines>I think I follow what you're trying to do <cbaines>I think you'll need to re-arrange the code to make it possible though <cbaines>So, currently, the activation service type is extended with a gexp that contains (activate-setuid-programs (list <THEN SOME STRINGS>)) <bonz060>How would you access mariadb from inside a guix container? <cbaines>Rather than programs just becoming part of the list, you're going to need to map over it, and generate gexps for each element, the behaviour of those parts can then be influenced by the element, say if it's a record. Does that make sense? <cbaines>bonz060, I don't think there's just one way, it depends on how mariadb is configured, and also on how you've setup the container, like does it share a network namespace with mariadb <bonz060>cbaines: I'm running: `guix environment -C --pure --network --ad-hoc php coreutils mariadb`. Wrt Mariadb, it's set up from host distro i.e. ArchLinux. I'm trying to access that from within the container... <dustyweb>cbaines: I think I could do it without adding a gexp compiler <cbaines>dustyweb, I probably wouldn't use a compiler <dustyweb>the way I might do it would be just to, in that map, convert to a tagged vector <dustyweb>that gets just match'ed on the other end <cbaines>a gexp compiler is a useful way of generating a file from a record <bonz060>cbaines: I get: `ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2 "No such file or directory")"; then I tried: ` guix environment -C --pure --network --ad-hoc php coreutils mariadb --expose=/run/mysqld/` and (naturally) got: `guix environment: error: mount: mount "/run/mysqld/" on "/tmp/guix-directory.hTqO7l//run/mysqld/": Operation not permitted` <cbaines>You're not trying to generate a file though, you just want to generate some small gexps that form part of a larger gexp, from elements in a list <dustyweb>cbaines: so would it be reasonable enough to do something like <dustyweb>(list (vector 'setuid-program ...) (vector 'setuid-program ...)) <bonz060>cbaines: I was wondering if there's a way to expose mysql in a similar fashion like what sth like docker does... <cbaines>bonz060, well, I'd maybe look at connecting over the network, rather than the socket (that's what Docker does) <leoprikler>dustyweb: sorry, I missed that. Is it still relevant? <cbaines>dustyweb, rather than convert from the record to an intermediate format, then have some code run, you might skip some complexity by just going straight from the record to the staged code <dustyweb>g_bor[m]: basically the unpacking of the <setuid-program> record <dustyweb>leoprikler: talkinga bout it here with cbaines and g_bor[m], I thnk I'm fine thanks :) <cbaines>dustyweb, you could have a (match with a bit for the record, and a bit for a string. Each of those bits result in a gexp that does the right thing for that element. You then dump all those gexps in to the activation gexp. <dustyweb>cbaines: I'm close to a version that runs <dustyweb>maybe I should just finish that and post it <dustyweb>and then we can discuss whether there's a cleaner approach on-list? <dustyweb>haven't looked at the postfix stuff that uses it at all yet ;P <dustyweb>I have always felt, er... "gexp weak" with my guix contributions <g_bor[m]>In my thoughts the original thing in the setuid field, which is a gexp iirc is implicity converted in setuid context to a setuid record with backwards compatible defaults. <bonz060>cbaines: Ah yes! That works: mysql -u'user' -p'pass' -h'127.0.0.1' -P'3306'. Thanks! <cbaines>bonz060, I'm glad you got it working :) <g_bor[m]>The only thing that was missing then is the user/group and if it should be setuid/setgid/both <g_bor[m]>I remember someone mentioning some progress on this <g_bor[m]>The main issue in postfix is that you need to set different setgid on the different binaries, as it actively uses that for privilege separation <g_bor[m]>I could have written an activation gexp, but this seemed to be better solved by a more generic mechanism. <g_bor[m]>I am looking forward to review your version. <apteryx>civodul: I was about to ask a question about man-db and groff-minimal, but I think I figured it out :-) <atw>how do specifications like guile@2.2 work? Can a user put any version they like after the @ ? <g_bor[m]>I believe they look up name version pairs in the known packages. <apteryx>atw: Yes! It'll attempt to get the closest, most recent one; say if you just specified @2, it'll pick the newest 2.X Guile <apteryx>most recent one of that series, I think. <leoprikler>nckx: I'm not sure whether the anticaptcha stuff can be included in a free as in freedom software distribution <leoprikler>I've glanced over it a bit and it seems to be not more than advertisements for some paid SaaS. <apteryx>civodul: OK, here's the question, after all: #39272 is about man -H missing an absolute reference to groff. But since the groff referred to by man-db is groff-minimal, it wouldn't support -mandoc -Thtml options anyway. <leoprikler>The interpreters OTOH could probably be enabled were the dependencies packaged. If they should rather be stripped at build, that's an oversight on my part <leoprikler>I wasn't quite certain what to comment, and neither were the reviewers at the time, so it has gone on uncommented. <leoprikler>Rather than deliberate, it's just that we need to find the right words. <leoprikler>73b305737cccaf20cb0b0d82c8f80075b9eda35c does nothing wrong btw. <atw>thanks all! what I've learned is that specifications are very flexible ( guix show guile@2 shows this off well, three matching packages are returned) but that at least one matching version does have to be available in the distribution, so guix show icecat@68 doesn't find anything. Asking because <https://issues.guix.gnu.org/43610> :) <apteryx>So, I guess we can leave it as is, or we could double the size of our man-db package (form 100 to 200 MiB, about) to support all the features. <leoprikler>nckx: I'll be afk for a while, I'll report back once I've gathered more thoughts. <dustyweb>is that run with the code from the latest "guix" package, or <dustyweb>is it run from whatever the currently-being-hacked-guix code is? <dustyweb>if it's the latter I wonder how that's done <dustyweb>if it's the former it feels like there's some kind of intermediate state where you're changing the functionality of what's *available to*, or the interfaces of, the gexps <cbaines>dustyweb, it's the latter, see activation-script in gnu/services.scm <cbaines>It uses with-imported-modules to scoop up (gnu build activation) <apteryx>I'm checking whether it'd inflate any of our image templates <zimoun>roptat: feel free to ping me when you are available. If not today, tomorrow fits also for me. <roptat>zimoun, I was about to ping you :p <roptat>bandali, I think you're a sysadmin for gnu or the fsf right? do you know how to submit videos to audio-video.gnu.org? <nckx>roptat: 4 follow-up commits notifications popped up at once. <nckx>Oh, I hadn't noticed. No worries. <apteryx>civodul: groff would be a ~50 MiB raise on bare-bones.tmpl <nckx>Glad I'm not the only one triggered by ‘for Linux’, at least. <civodul>apteryx: actually i'm unclear why something needs to be changed at all; after all, "man" works, right? :-) <civodul>maybe i didn't fully grasp the original bug report <mbakke>db48x: You are welcome! Actually the latest manual change makes the previous mention of restorecon somewhat redundant, not sure if we should reword that. Thoughts? <nckx>civodul: Because you can ask man to output HTML instead of retro, and that's broken. <nckx>Seems like a case for man-minimal or so. <nckx>sneek: later tell jonsger: Welcome! \o/ <nckx>I know. I trust you more than I do most humans. <db48x>mbakke: I'll look. what commit? <rekado_>apteryx: thanks for letting me know about pigx; fixed on the “master” branch <db48x>nckx: wasn't sneek completely awol last week? ;) <db48x>oh, I understand your question now :) *mbakke hopes he did the GPG key authorization stuff right ... <db48x>yes, I intended to to make it more obvious that you have to relabel after every upgrade to guix-daemon <mbakke>db48x: indeed, it's a good change <db48x>mbakke: did you see my question the other day? I was thinking about the giant hole in this selinux policy <db48x>the documentation there mentiones fixing it by updating the policy after every upgrade, to only relabel the correct guix-daemon binary <db48x>but there's another way to fix it as well, which is to have a separate store just for guix-daemon packages <db48x>instead of putting guix-daemon in /gnu/store, it could go in /gnu/guix-daemon-store or whatever <mbakke>db48x: that could work I guess, but provides no value for other distros, so I'm not sure such a huge change will be accepted :P <apteryx>civodul: yes, it's just a bit surprising that 'man -H' would require the user to install groff, while the other paths are all absolutely referenced. <mbakke>db48x: I think the best fix would be a proper RPM for guix-daemon (EPEL?), like the recent Debian package <db48x>mbakke: having an rpm doesn't fix the policy problem <mbakke>db48x: then it could live in /usr/bin/guix-daemon instead of being self-updating <db48x>I didn't look at the details of the new deb package; does it install guix-daemon there or leave it in the store? <mbakke>db48x: the Debian package provides a 'guix' and 'guix-daemon' binary that have been built against the Debian distribution. <apteryx>civodul: also, 'guix size $(guix system build gnu/system/example/bare-bones.tmpl) | grep perl' is already found. <civodul>apteryx: right; but "man" works on bare-bones, right? <db48x>mbakke: that is obviously the right solution <civodul>apteryx: "guix size man-db groff" is twice "guix size man-db" though, FWIW <db48x>it has the advantage that the guix-install.sh script doesn't really need to care about the selinux policy (see #44649 if you haven't already) *mbakke looks forward to a future when most distributions have a guix package <db48x>that ought to make it easier