<lfam>Should a makefile create the install subdirectories "bin", "lib", etc? Or does the gnu-build-system's install phase do that? I'm trying to workaround a "broken" Makefile by replacing the install phase but it fails because $out/bin/ doesn't exist: "cp: cannot create regular file ‘/gnu/store/...-peg-markdown-0.4.14/bin/peg’: No such file or directory"
<davexunit>apparently transmission tries to write over its config file all the time
<lfam>Yes, you can't edit the config file while the daemon is running
<lfam>At the very least, the daemon rewrites the file when it exits.
<davexunit>the recommended method to set a password is to edit the config file, add the plain text password, restart transmission, and let transmission overwrite the config file with a version that hashes the password.
<davexunit>the folks in the transmission irc channel do not see the issue with a config file that contains passwords that the daemon writes to whenever it feels like
<davexunit>so, while they are confused, what I get out of this is that we shouldn't be trying to manage this config with guix.
<davexunit>since, now that I remember, you can tweak things via the web interface that will be written to that config file later.
<davexunit>which is a shame, because it means that guixsd users can't version control their bittorrent settings.
<piyo>So I'm using git-fetch syntax for a package def I am writing, but as a sanity test I try "guix download guile-emacs" and it fails with "guix download: error: guile-emacs: failed to parse URI". I then notice my guix based git exec is failing to retrieve https://github.com/...git urls with a message "fatal: unable to access 'https://github.com/.../': server certificate verification failed. CAfile: none CRLfile: none". Is my "guix package
<fps>civodul: quick question: when someone tries to grab a substitute from my machine that is running the publish service and a derivation output is not available due to a build failure
<fps>civodul: what happens then? does the client trying to get the substitute try to build from source, too, which will subsequently fail?
<fps>or does the publish service check the db for failed builds and communicates the failure to the client?
<yvm>I did specify -L root for root partition, yep.
<fps>this is kind of related to my question about explicitly representing failures in the store. if they were represented as such the substitute server could just deliver the archive containing the build failure
<fps>so, if the function has never been attempted the store would have no result. that's fine..
<fps>but if it had been attempted and failed it would make sense to memoize that outcome, too, right?
<fps>nothing is lost, much is gained. or do i miss something?
<civodul>yes that's what "guix-daemon --cache-failures" does, but you already tried that, right?
<civodul>we could allow 'guix publish' to publish that information optionally
<civodul>feel free to leave an item on email@example.com! :-)
<fps>yeah, if we made the store more expicit in this regard, then there would be no need to touch the guix publish service
<fps>if the build failure was represented in store in such a way that an archive could be delivered containing it, then it would be more explicit and you'd gain the goodies
<civodul>no need, there's already a query-failed-paths RPC for that
<civodul>any volunteer to review the Let's Encrypt patch series? :-)
<fps>yeah, hmm, but still, think more functionally and in a more type-strict way :)
<fps>we really have a function f: derivation -> store-entry | some entries in some db (possibly, maybe)
<fps>wouldn't there be something to gain from making it f: derivation -> store-entry, where store entry is an explicitly variant type modelling the failure modes, too?
<davexunit>civodul: I've been meaning to review it, but haven't gotten to it.
<rgrau>Hi guixers, I tried to build this package (imported from nix), and it fails on configure phase. the ./configure file is a perl one, and it seems it's not recognizing it as such (it errs with "./configure: line 3: use: command not found"). https://gist.github.com/e12b87eeec6c63f00971 .
<fps>civodul: i'll leave a message on the bug list then...
<fps>civodul: and yeah --cache-failures seems to work just fine, locally, here.. i was just pondering some more consequences of this non-explicit representation..
<davexunit>rgrau: the GNU build system assumes that 'configure' can be run with bash
<iyzsong>rgrau: I think you should put perl into 'native-inputs', only that will be added to PATH.
<davexunit>rgrau: so you'll need to replace the 'configure' phase with a custom one
<iyzsong>or, I'm wrong about the reason, but it's still the right idea :-
<rgrau>ooks. the configure file has a shebang and I thought it would catch it on the fly and run perl. will try both native-inputs and custom configure. I guess I didn't pick the easiest package to train myself....
<iyzsong>cehteh: make sense. I tried, and it seems that we can output all the Makefile rules using Guile, but currently, ugly #f (as empty string for success) and "false" (as false command for failure) is required :(
<rgrau>I'm trying to write a custom configure phase, and I see plenty of 'alist-cons-before' calls in the package recipes, but I see no clear way to remove a phase from %standard-phases or replace it. also, It's kinda difficult for me because I'm new to guile, and I don't know how to try things interactively. can I put some kind of breakpoint that will leave me in a repl while building the package?
<rgrau>or some way M-. in geiser will bring me to the implementation of a function like alist-cons-before, for example
<df_>I'll have a look, with any luck it will be a relatively easy problem to start learning how to hack guix packges
***trisquel is now known as HeisenbergsMirro
***HeisenbergsMirro is now known as HeisenbergsDog
<rgrau>for apps that spit logs (openresty, think nginx), where should we place the logs? in the profile's share dir, profile's var/log dir, or root /var/log ?
<lfam>davexunit: Are you happy with the transmission service as it is? Or is the authentication system still insecure?
<lfam>When packaging software that works with both python2 and python3, is it normal to have to add python2-setuptools as an input for the python2 variant? Not knowing this is one reason my WIP lets-encrypt patchset is WIP — I'm wondering how to approach this. I also need to read the ML stuff from a few days ago and python2 packaging issues
<efraim>if python-setuptools are an input then package-with-python2 will translate that to python2-setuptools
<efraim>the python2 problem is when the python2 variant has extra inputs, then whenever it is used it needs to be called specifically
<lfam>efraim: Thanks, I really need to dig into it because I hit the exact issue on the ML (python2-ipaddress) and I thought I was losing my mind ;)
<rgrau>will try to write the associated tutorial (for things a bit harder than hello package)
<mark_weaver>hmm, "guix system build" on my long-standing OS config is now failing with git master, and even when I incrementally strip down my config to an increasingly minimal desktop config, I cannot find a config that works.
<lfam>I just noticed a problem with my peg-markdown package definition. The package provides `peg` and `leg` and a manpage "peg.1" that documents both binaries. But `man peg` works while `man leg` doesn't. Any suggestions for a revision? I don't know how to approach this.
<civodul>we can do that, but it's a problem for upstream to solve ultimately
<lfam>civodul: I don't think there is much an upstream for this one. I threw it together because rekado said it would be simple :p Is there a guile procedure for symlinks? Not much fun to grep for 'ln'
<mark_weaver>civodul: I have generations going back about 6 weeks, but switching to old generations doesn't seem to fix the problem with totem, even though totem and associated plugins are in my user profile. I guess maybe I need to boot into older generations of my system to get back to a working state :-(
<mark_weaver>or perhaps it some mutate state in my home directory.