Re: Creating local variation of match-theme
Thanks Marius!
On Wed, 18 Dec 2019, Marius Bakke wrote:
It's not pretty, but you could create a package that takes "match-theme"
as an input and makes the necessary adjustments.
See the 'mariadb/fixed-install-db' variant added in
9077cf68ec57c0303ef7746e203c3fe5ed041add for an example.
I tried this approach first, and find the results acceptable for this
purpose. This technique seems most applicable when what needs to modified
is a text file. I ended up with this package definition:
```
(package
(inherit matcha-theme)
(native-inputs '())
(inputs `(("matcha-theme" ,matcha-theme)))
(outputs '("out"))
(build-system trivial-build-system)
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules ((guix build utils)))
(let ((upstream-theme (assoc-ref %build-inputs "matcha-theme"))
(out (assoc-ref %outputs "out")))
(copy-recursively upstream-theme out)
(substitute* (find-files out "\\.css$")
(("abb9b6") "859900"))
(synopsis "jackhill's version of the matcha-theme"))
```
Another "cleaner" approach could be to use 'computed-file' to create a
patched source tarball, and pass that as the source in your local
variant.
I have not yet tried this. I should because, as you point out, this is
"cleaner", and would work in situations where what needs to be modified in
compiled into an opaque object in the output.
However, without trying this, I don't see how it would work better than
using a snippet in the origin definition. Or perhaps you meant to created
the patched source tarball from the output of the upstream matcha-theme
package?
Either way, I think I'm still left with the question of how can we make
modifying packages easier without the need to resort to kludges.
Best,
Jack
Re: Creating local variation of match-theme
Hi,
It's been a few days, so I was wondering if anyone had thoughts on the
following:
Best,
Jack
On Sun, 8 Dec 2019, Jack Hill wrote:
Hi Guix,
I'd like to create a local variation of the matcha-theme package with one of
the colors changed to suit my taste. Rather than make the change in my clone
of the git repository, which could then become outdated, I thought I would
try to make the change programatically as part of the package definition. I
decided to make my change in a snippet as part of the origin specification
because that seemed to logically fit with what I was trying to do (build a
package with modified source) and because matcha-theme uses the trivial build
system, which I don't believe has the concept of phases, so it wasn't clear
how I would add a phase to make my change during the build. I came up with
the following package definition:
```
(package
(inherit matcha-theme)
(source (origin
(inherit (package-source matcha-theme))
(modules '((guix build utils)))
(snippet
'(begin
(substitute* (find-files "." "\\.css$")
(("abb9b6") "859900"))
(synopsis "jackhill's version of the matcha-theme"))
```
Unfortunately, after building my modified source tarball correctly, the
package build fails. I believe this is because matcha-theme's
trivial-build-system recipe expects a source checkout and not a tarball, and
doesn't have the logic to expand the tarball that, e.g., the gnu-build-system
provides.
The build log contains the following:
```
@ build-started
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv -
x86_64-linux
/var/log/guix/drvs/rq//x5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv.bz2
28285
Backtrace:
4 (primitive-load "/gnu/store/j01a49zzlrn7fyr2x7ibxyqsph5?")
In ice-9/eval.scm:
191:35 3 (_ #f)
619:8 2 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
In
/gnu/store/ygivy1fvr7gbyva4z22b7vzzps1krbq5-module-import/guix/build/utils.scm:
343:27 1 (_ "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha?" ?)
In unknown file:
0 (copy-file "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj0?" ?)
ERROR: In procedure copy-file:
In procedure copy-file: Is a directory
`/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha-theme-2019-11-02.tar.xz'
-> `/tmp/guix-build-matcha-theme-2019-11-02.drv-0'
builder for
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv'
failed with exit code 1
@ build-failed
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv - 1
builder for
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv'
failed with exit code 1
```
For reference, matcha-theme's builder is:
```
(arguments
'(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let* ((out (assoc-ref %outputs "out"))
(source (assoc-ref %build-inputs "source"))
(bash (assoc-ref %build-inputs "bash"))
(coreutils (assoc-ref %build-inputs "coreutils"))
(themesdir (string-append out "/share/themes")))
(setenv "PATH"
(string-append coreutils "/bin:"
(string-append bash "/bin:")))
(copy-recursively source (getcwd))
(patch-shebang "Install")
(mkdir-p themesdir)
(invoke "./Install" "-d" themesdir)
#t
```
This leaves me with two questions:
How should I accomplish what I want to do (change one of the colors in
matcha-theme for local use)?
If I am right about trivial-build-system (that it makes it more difficult to
create modified packages compared to other build systems), should we try to
avoid using it in gnu/packages to ensure people have the easiest time
exercising their software freedom?
Best,
Jack
Re: gpg-agent error: No pinentry
Hello, Marco van Hulten ezt írta (időpont: 2019. dec. 18., Sze 22:41): > Hello— > > I have installed gnupg 2.2.18 and pinentry 1.1.0 on a Guix System. > When I try to import a key, I get this issue: > > $ gpg --import publiko-secret.asc > gpg: key 9FC3734DFB84400D: "Marco van Hulten (publiko) " > not changed > gpg: key 9FC3734DFB84400D/9FC3734DFB84400D: error sending to agent: No > pinentry > gpg: error building skey array: No pinentry > gpg: error reading 'publiko-secret.asc': No pinentry > gpg: import from 'publiko-secret.asc' failed: No pinentry > gpg: Total number processed: 0 > gpg: unchanged: 1 > gpg: secret keys read: 1 > > It seems that the public key is imported but not the private key (I can > encrypt but not decrypt). On an OpenBSD-current system importing this > key works properly. > > Do I need to do any more actions accept for 'guix package -i gnupg > pinentry'? > Yes, unfortunately you need to set pinentry program in gpgagent conf. I am on mobile right now, so I don't have the exact settings at hand, but this should give you enough info to search for the solution. > > Thanks, > > —Marco > Regards, g_bor > >
Re: gpg-agent error: No pinentry
Hello, On Wed, Dec 18, 2019 at 10:41:27PM +0100, Marco van Hulten wrote: > Do I need to do any more actions accept for 'guix package -i gnupg > pinentry'? I also have a file .gnupg/gpg-agent.conf in my home directory containing the following lines: default-cache-ttl 300 max-cache-ttl 3600 pinentry-program /home/USERNAME/.guix-profile/bin/pinentry-curses The first two determine how long, after typing your password, the key remains unlocked; it gets locked after 5 minutes without any usage, or 1 hour even if it is used, if I remember well. Andreas
gpg-agent error: No pinentry
Hello— I have installed gnupg 2.2.18 and pinentry 1.1.0 on a Guix System. When I try to import a key, I get this issue: $ gpg --import publiko-secret.asc gpg: key 9FC3734DFB84400D: "Marco van Hulten (publiko) " not changed gpg: key 9FC3734DFB84400D/9FC3734DFB84400D: error sending to agent: No pinentry gpg: error building skey array: No pinentry gpg: error reading 'publiko-secret.asc': No pinentry gpg: import from 'publiko-secret.asc' failed: No pinentry gpg: Total number processed: 0 gpg: unchanged: 1 gpg: secret keys read: 1 It seems that the public key is imported but not the private key (I can encrypt but not decrypt). On an OpenBSD-current system importing this key works properly. Do I need to do any more actions accept for 'guix package -i gnupg pinentry'? Thanks, —Marco
Re: Cannot build libdbi-drivers: "dbd_mysql.c:54:10: fatal error: mysql.h: No such file or directory"
jorge+l...@disroot.org (Jorge P. de Morais Neto) writes: > For more than a week I have been unable to update Gnucash. One of its > dependencies, libdbi-drivers, fails to build. I have attached the build > log. Hello Jorge, This is fixed with commit 9077cf68ec57c0303ef7746e203c3fe5ed041add. Thanks for reporting the issue! signature.asc Description: PGP signature
Re: ripit/perl: use perl_cddb_get package?
Thank you for your time, but I am afraid I have wasted it. The perl module dirs are set in a env variable in bash's files, and for that reason my fish couldn't find them. (Also the syntax isn't compatible so I you to copy them out, which is quite annoying). So in a way it's fixed now ^^" Thanks anyway! Am 9. November 2019 12:24:58 MEZ schrieb Marc Chantreux : >> This seems to be the problem, it returned: >> $ perl -E 'map say, grep -d, @INC' >> $ find /gnu/store/*perl* -iname "CDDB_get.pm" >> /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/CDDB_get.pm >> /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/CDDB_get.pm > >> So it seems like the problem is that this perl script package can't see the >> installed perl modules? > >yes: every module have its own store so perl don't see them >ok. i don't know enough of guix to help on it but from the perl >perspective, a module is available is in @INC which contains: > >* a built-in list of standard directories >* the list of directories provided by the $PERL5LIB env variable > (the awesome local::lib module is very helpful to manage $PERL* > variables: don't miss it) >* the list of directories hardcoded in the script using `use lib` > instruction > >if guix wants to compete with (or encapsulate) cpan tooling, it needs to >have a way to embrace the 2 most common strategies to install the >things > >* installing everything in a directory dedicated for the software > (this clear separation with the base system and other programs > makes it easy to install, remove, maintain without breaking anything > on the host... like containers does) > >* installing as much as possible in the standard directories using > system packages. > >it would be very good to reach the point when the combo >perlbrew+cpanm+local::lib (or carton) could be replaced by a guix >counterpart. this is probably the momentum i'm waiting for to replace >my perl toolchain with guix. > >for the projects providing cpanfiles, a strategy could be to provide >both a perl version and the installed modules from the perl cpanm >commands in the same store? > >also: having a plan9 experience, i would like to arg that the better way >to do that is having a single dir to bind everything we need in it. >that's basically what docker does poorly but i have no experience in >handmade linux namespaces > >> Any input is appreciated. > >i can help as "someone who knows the perl ecosystem practices" but >i don't know enough about guix. > >regards >marc > >
