IRC channel logs


back to list of logs

<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?
<db48x>but that's just a guess
<rndd>db48x: the file is in /gnu/store/iqicv56va1l6m4fdhqgpj3var2xv39dy-sbcl-claw-stable/share/common-lisp/sbcl-source/claw/claw.asd
<leoprikler>dustyweb: okay, I am now somewhat aware of what you're going for
<dustyweb>leoprikler: ;)
<dustyweb>here, I can paste what I have
<dustyweb>it might be the wrong thing!
<leoprikler>It seems like you'll have to add it to (guix gexp) along with a (define-gexp-compiler setuid-program-compiler <setuid-program> ...)
<dustyweb>leoprikler: oh really!
<dustyweb>I can do that
<leoprikler>Okay, I was mistaken, you can define it outside as well
<leoprikler>define-gexp-compiler is a public export :)
<dustyweb>thanks leoprikler
***catonano_ is now known as catonano
<buenouanq>howdy friends
<buenouanq>I need some wifi help.
<buenouanq>Trying to install GuixSD on a 2011 Macbook Air.
<buenouanq>With a Think Penguin wireless USB thing.
<buenouanq>When I dhclient it hangs DHCPDISCOVERing a bunch and then fails.
<buenouanq>then `No DHCPOFFERS received.' `No Working leases in persistent database - sleeping.'
<buenouanq>M-x please-help
<lfam>buenouanq: Did you enable the interface and start wpa_supplicant as described here? <>
<roptat>maybe try rfkill?
<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>it seems I can't get the interface up...
<buenouanq>$ ip link set interface up
<buenouanq>returns with no error, but ip link still shows DOWN after...
<buenouanq>ok, it wasn't hanging, I just forgot the -B
<lfam>What does -B do?
<buenouanq>but still having the DHCPDISCOVER thing
<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
<buenouanq>and then dhclient gets stuck
<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>what is Wext?
<buenouanq>wpa_sup returns `Successfully initialized wpa_supplicant'
<buenouanq>it was a typo (;-___-) sorry
<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]>In 2019, yes
<kozo[m]>I'm trying it again to ween myself off flatpak
<lfam>Can you share the full error output on <>?
<kozo[m]>This is when I run Discord. File does exist and permissions are set as 444
<kozo[m]>and this is spotify
<lfam>Hm, not sure
<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
<kozo[m]>Understood. Thank you again.
<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...")) ...
<buenouanq>if that wasn't clear
<buenouanq>in a (package
<lfam>It's definitely possible — That's basically what `guix refresh --update` does
<buenouanq>how do I use it in the config.scm?
<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
<buenouanq>finally :3
<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'
<buenouanq>getting closer
<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>[you can specify multiple -p in that]
<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
<leoprikler>Why should that not work on foreign distros?
<sss2>i will retyr, but it does not worked for me on first attempt
<sss2>*i will retry
<sss2>looks like `info` have more info than
<leoprikler>The setup is admittedly non-trivial, but nothing mentions exclusivity to Guix System.
<sss2>hm..., or not, anyway, i will retry, thx
<leoprikler>Chances are you're missing a step or something.
<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>what exactly do you mean by that?
<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>for ssh
<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
<sss2>explain please
<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>got it
<sss2>but does it executed byt non-interactive ssh sessions ?
<leoprikler>it is executed on login, and ssh logs in IIRC
<divoplade>.profile is not sourced when I connect via ssh
<sss2>thx for explenetion
<divoplade>I think
<divoplade>I need to check
<leoprikler>add an echo "Hello world" to it and you shall see
<divoplade>No it's not :(
<leoprikler>which shell are you using?
<divoplade>bash on guix
<divoplade>(guix system)
<leoprikler>try putting it into bash_profile then
<leoprikler>zsh does read .zprofile fwiw
<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
<leoprikler>do NOT, I repeat do NOT put this into .bashrc
<divoplade>Didn't you just say otherwise?
<divoplade>I'm lost
<leoprikler>not RC
<sss2>so for "global" environment - .Xprofile, and for other shell settings - .Xrc ?
<sss2>corect ?
<divoplade>.bash_profile contains this by default:
<divoplade>if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
<divoplade>Should I discard the default?
<divoplade>Oh I see
<raghavgururajan>nckx: Yeah, it will be updated in near future. :-)
<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.
<ArneBab>Did anyone already experiment with using distcc in our buildservers?
<PotentialUser-35>Guix hangs on startafter pcspkr driver error, but it's not fatal error
<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
<PotentialUser-35>what needs to be done to fix
<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: Hello :)
<janneke>hey dannym :)
<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>Hmm, yeah
<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.
<janneke>dannym: okay...
<HiPhish>For example, system-guile prints (display "асдф") just fine, but Guix Guile prints a bunch of questions marks.
<HiPhish>Any ideas?
<HiPhish>I am running Void Linux:
<janneke>HiPhish: this works for me: ./pre-inst-env guile -c '(display "асдф\n")'
<janneke>but i'm on Guix System
<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.
<janneke>HiPhish: what is your LANG setting?
<janneke>i'm using LANG=en_US.UTF-8
<HiPhish>janneke: en_GB.UTF-8
<HiPhish>At least that's what the environment variable is set to.
<janneke>(yes, that's what i meant to ask)
<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
<cbaines>You'll need glibc-locales for that
<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?
<cbaines>That seems fine
<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
<HiPhish>Yes, it does.
<cbaines>Ok, what do you see in ~/.guix-profile/lib/locale
<HiPhish>A directory
<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: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/, for GNU/Linux 2.6.32, not stripped
<cbaines>Ah, there's your problem
<cbaines>Guile is using glibc 2.31
<cbaines>but you have the locales installed for 2.29
<HiPhish>OK, but why?
<HiPhish>I'm running guix upgrade now...
<HiPhish>It worked!
<HiPhish>So why did this happen?
<cbaines>Seems like guile was using a later glibc
<cbaines>So maybe you did guix pull in between installing glibc-locales and guile?
<HiPhish>That is probably what happened.
<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.
<cbaines>You're welcome
<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
<divoplade>And it is, indeed.
<db48x>this is really starting to annoy me:
<db48x> guix search foo
<db48x>In execvp of less -FXRS: No such file or directory
<roptat>db48x, export PAGER=cat :p
<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 (
<OriansJ>sss2: as we all must
<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>For sure
<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'
<db48x>which doesn't exist
<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
<ryanprior>Okay that does make a difference =D
<nckx>db48x: Did you set PAGER to that?
<db48x>everything else that uses PAGER works fine with it
<lafrenierejm>Anyone available to help troubleshoot a Rust recipe?
<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.
<db48x>nckx: yea, I saw that
<nckx>Hm, now it prints nothing if $PAGER is set but empty.
<db48x>that's progress, of a sort
<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.
<db48x>you're welcome
<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
<jonsger>do I need to define that somewhere?
<nckx>jonsger: (make-forkexec-constructor … #:user … #:group …)?
<divoplade>What do you pass as a value for #:user?
<nckx>A string.
<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
<dustyweb>in that it system-wide does a mutation
<divoplade>Do you have an example for this?
<jonsger>nckx: ah, thx
<divoplade>(continuing my questions to nckx)
<nckx>Ehm *says random thing* I'm sure mysql does that 😛
<nckx>So (gnu services mysql).
<nckx>Nope, (gnu services databases).
<divoplade>Thank you
<nckx>For a more complex example see getmail (gexps! spooky).
<dustyweb>leoprikler: around?
<dustyweb>I have "dustyweb is unsure, conceptually, if they understand what they're doing" questions :)
<cbaines>Is that about G-exps?
<dustyweb>cbaines: yes
<dustyweb>I'm trying to see if my impression is right about what was proposed on-list
<cbaines>What's your conundrum?
<cbaines>and is this about Postfix?
<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
<dustyweb>yes one sec
<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...
<cbaines>bonz060, and can you access it?
<g_bor[m]>dustyweb: hello
<apteryx>civodul: hello!
<g_bor[m]>Hello guix!
<dustyweb>hi g_bor[m] !
<g_bor[m]>Today I could try 1.2-rc1
<dustyweb>cbaines: yes, that makes sense
<dustyweb>cbaines: I think I could do it without adding a gexp compiler
<dustyweb>but maybe a gexp compiler is "cleaner"
<g_bor[m]>The install went without a glitch.
<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
<g_bor[m]>It looks to work fine.
<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 ...))
<dustyweb>just unpack into that
<dustyweb>since it needs more elements
<civodul>hey apteryx!
<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)
<g_bor[m]> [dustyweb]( what is vector here?
<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>cbaines: ah
<dustyweb>that could work
<g_bor[m]>Ah, ok
<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>thats' just for the setuid stuff
<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
<dustyweb>so I'm a bit self conscious here
<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.
<dustyweb>I probably have done things wrong
<bonz060>cbaines: Ah yes! That works: mysql -u'user' -p'pass' -h'' -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.
<g_bor[m]>Thanks for working on it.
<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>most recent matching
<leoprikler>guile@4 is bogus, at least for now
<nckx>Hi leoprikler. Is the reason for this snippet <> just to reduce unnecessary dependencies?
<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
<nckx>leoprikler: Hm, OK, thanks! Is the lack of a comment deliberate then? (I'm not sure what to think of the package myself, e.g,
<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 <> :)
<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.
<nckx>leoprikler: o/
<dustyweb>one more question
<dustyweb>the code in activation.scm...
<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
<dustyweb>cbaines: aha! very cool then
<dustyweb>I'll look, thanks
<cbaines>It uses with-imported-modules to scoop up (gnu build activation)
<dustyweb>cbaines: neat.
<civodul>apteryx: re i'm not sure what should be done, but yeah, recording the absolute file name of groff-minimal wouldn't help as you write
<apteryx>I'm checking whether it'd inflate any of our image templates
<nckx>curseofwar is cursed.
<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>nckx, what do you mean? :)
<roptat>bandali, I think you're a sysadmin for gnu or the fsf right? do you know how to submit videos to
<nckx>roptat: 4 follow-up commits notifications popped up at once.
<roptat>haha, my bad ^^'
<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.
<apteryx>from 1172 MiB
<dustyweb>ok, seems to work
<dustyweb>the setuid stuff that is
<db48x>mbakke: thank you :)
<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/
<sneek>Got it.
<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? ;)
<mbakke>db48x: see ; it also mentions relabeling, but now that I'm re-reading it it does not seem as redundant
<mbakke>db48x: your commit is here:
<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
<apteryx>rekado_: thank you!
<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>ah, but that would
<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
*civodul -> zZz
<apteryx>civodul: good nightz!
<db48x>it has the advantage that the script doesn't really need to care about the selinux policy (see #44649 if you haven't already)
<mbakke>db48x: yes :-) there is already an RPM for SUSE, so it should not be Too Hard to make an EPEL version:
*mbakke looks forward to a future when most distributions have a guix package
<db48x>that ought to make it easier