<defanor>is it planned to stick to syslog in guix? and will the programs that require systemd journal not get packaged in guix, or will there be some compatible library?
<lfam>defanor: Out of curiosity, what programs require journald?
<defanor>lfam: probably not many, i only have some of my programs (in-house ones, as work) in mind
<lfam>Anyways, I don't think we really have anything against systemd. One of our contributors created elogind, which is basically a standalone logind for things that require it. IIUC that's one factor that lets us have GNOME
<marusich>I'm failing to understand how the (((? option? o) args ...) part works
<marusich>I see in the Guile manual ((guile) Pattern Matching) that (? predicate pat_1 ... pat_n) will match "if predicate true and all of pat_1 thru pat_n match".
<marusich>However, I am confused about the structure of the code in ui.scm. I expected to see it as (((? option? o args ...) or something, but instead it is (((? option? o) args ...)
<marusich>Clearly, I'm missing something. What am I missing?
<marusich>I see that option? is a procedure which takes a single argument and tells me whether or not that argument (a string, ostensibly) begins with "-"
<marusich>I don't see how the (? option? o) part fits in with the pattern matching
<marusich>I think I understand what's going on for other clauses, but not that one. For example, for the ("help" command) clause, I believe it's saying that if args is a two-element list whose first element is the string "help", then we should run the matched command with the "--help" parameter.
<marusich>"(? predicate pat-1 ... pat-n): In this pattern, predicate must be an expression evaluating to a single argument function. This pattern matches if predicate applied to the corresponding value is true, and the subpatterns pat-1 ... pat-n all match."
<marusich>I think I'm missing something obvious here, and if someone could clarify things for me, that would be super awesome.
<marusich>Ah, I get it now, I think. I did some experimenting. I guess that the pattern matching mini-language interprets the pattern ((? predicate a) b) to mean the same thing as the pattern (a b), with the added restriction that (predicate a) evaluates to true.
<marusich>At least, that's how it seems to be when I do my experiments. If I'm wrong, please correct me.
<marusich>so ((? option? o) args ...) is meant to match any list where the first element is a string that is also an option
<defanor>how it one supposed to run pioneers? i've installed them with `guix package -i pioneers`, and tried to just run `pioners` – but getting an error that says that it can't find a pixmap file. also a couple of warnings before that
<defanor->getting this error when installing or removing packages: "Directory '/gnu/store/wbh2hzgnz4bgcjm8zxink8dgvsf7258w-xdg-mime-database/share/mime/packages' does not exist!"
<mark_weaver>defanor-: did you delete files from your store manually?
<mark_weaver>the fact that "setarch i686 config.guess" reports i686 tells us that the personality is propagated to subprocesses, and that "uname -m" returns a result that depends on the current personality
<wingo>yeah i seem to remember ludovic saying something like that
<mark_weaver>build-aux/config.guess has a #!/bin/sh shebang on top
<wingo>welp, i'm going to rebuild my proper guile first :)
<mark_weaver>GuixSD doesn't put programs at fixed locations in the filesystem, in general. we make an exception for /bin/sh only, because it would be too painful otherwise.
<lumidragon>I'm mostly exploring ways to make my zsh and emacs config more portable.
<mark_weaver>putting programs/libraries at fixed locations in the filesystem is incompatible with our basic design, which allows any number of versions of the system to exist together on the same filesystem.
<jmd>mark_weaver: I don't understand why it would be too painful. Anything which needs a sh should have had its reference to it substituted when it was built.
<lumidragon>then what would be a good shebang when scripting on guix then?
<lumidragon>awesome my emacs-helm package is in, hopefully email@example.com won't be far behind :)
<mark_weaver>well, ideally, scripts would proper guix packages in your profile, and we should provide tools to very easily import a simple script, rewriting the shebang as needed to reference something in /gnu/store directly
<mark_weaver>but in the meantime, if you need a shebang other than #!/bin/sh, I would suggest #!/run/current-system/profile/bin/python or whatever
<lumidragon>ah so every project should be guix package then?
<mark_weaver>but I think that the easy-script-import proposal is the Right Thing (TM)
<mark_weaver>one of our design goals is that if a program from a given profile works today, it should work tomorrow. if you update your system and something breaks, you should be able to roll back and the old version should work, as it did before.
<mark_weaver>and that depends on programs relying principally on immutable items in the store
<mark_weaver>shebangs that refer to things like #!/bin/sh that will change work against that goal
<mark_weaver>and make it more likely that roll-back will fail to work in some cases
<mark_weaver>and things like #!/usr/bin/env work against that goal in a deeper way, by searching for programs in your PATH
<davexunit>/usr/bin/env only gives the illusion of portability anyway
<lumidragon>so I should just turn my script projects into guix packages?
<mark_weaver>so let's say you have a python script that works today. by rewriting the shebang to refer to a specific immutable version of python in /gnu/store, that helps ensure that it won't break someday when you update the version of python in your system profile
<davexunit>I think that we need is a procedure that takes two arguments, a script file and the desired interpreter package, and returns a package object for it
<lumidragon>for the shebang? or something independent of the script?
<mark_weaver>davexunit: sounds good to me! that would be sufficient to easily add scripts to a manifest as used by "guix package -m" (which is the best way to maintain a user profile, IMO)
<davexunit>mark_weaver: yeah, that's how I'd envision it being used.
<mark_weaver>we'll probably want to find a good solution for people who don't use "guix package -m" as well
<davexunit>yeah there could be a CLI for it for one-off jobs
<mark_weaver>maybe some syntax for specifying such a script as an argument to "guix package -i"
<cbaines>I have a package which attempts to install during the check phase, and fails as it cannot write to the directory, I guess as its not there?
<cbaines>I'm not sure how to work around this, is there a common approach?
<cbaines>Would moving the install phase before the check phase help?
<mark_weaver>cbaines: if it fails to install because it can't write, that suggests that the problem is that you need to tell it the right place to install. separating the check and install phase wouldn't help for that.
<cpjjl>mark_weaver, after building, it all works perfectly thanks again
<mark_weaver>sneek: later tell cpjjl: even if the security flaw isn't in libreoffice itself, if there's, say, a security flaw in libxml2 or something, then if you don't update libreoffice you'll keep one that continues to use the old unpatched libxml2.