Packaging existing software for Guix

Packaging existing software for Guix

[Cássio Tavares]

Hi there!

I've been struggling with Guix for about three months now, but I still
couldn't get it working as I need it. I will need help on many fronts. One
of the problems is that the Guix ecosystem is still somewhat limited. I
know that there is a way to install Nix packages, but since I became full
linux-libre adept, I'm trying to stay as "pure-Guix" as I can. My main
motivation is that this provision does not encourage people to port the
packages so that they are directly available in Guix's repository, quite
the contrary, it delays Guix packages availability.

So, I'm looking into package definition, and I have a few questions to
start:

   1. If I submit an issue with a package request, does it take long for
   the package to be made available?
   2. Can someone with only a very basic understanding of the Scheme (and
   the functional paradigm) package software successfully enough to submit it
   to the Guix project?
   3. Would that be very time-consuming (because my work is in a very
   different area)? Is the learning curve steep?
   4. As far as I could understand, when defining a package from a git
   repository, I have to specify the package version and commit. Does this
   mean that I will forever have to check for new versions and edit the
   package definition to update it?
   5. Is there a relatively simple way to port packages from other distros
   into Guix? Could this be an automated process?
   6. Any further advice?

Thanks,
Cássio
-----
Faculdade de Letras - UFG
*“*
*Ou a gente se Raôni, ou a gente se Sting**”*

Re: Packaging existing software for Guix

[Ricardo Wurmus]

Hi,

Cássio Tavares <cassio.ufg@gmail.com> writes:

>    1. If I submit an issue with a package request, does it take long for
>    the package to be made available?

It can take quite some time when you don’t have someone to review the
package.  You are welcome to send me issue numbers with your patches and
I’ll review them more quickly.

>    2. Can someone with only a very basic understanding of the Scheme (and
>    the functional paradigm) package software successfully enough to submit it
>    to the Guix project?

Yes.  Ignore the language.  Most of the package definition is just
data.  You can even write a package definition as JSON first and then
have Guix convert it to the Guix DSL.

>    3. Would that be very time-consuming (because my work is in a very
>    different area)? Is the learning curve steep?

It depends on the software.  If an application follows well-established
conventions it can be trivial to package it.  On the other hand, some
software can be nearly impossible to package (e.g. Tensorflow 2).

Nixpkgs is often not a good template, because more often than not they
are cutting corners when it comes to bootstrapping or building from source.

>    4. As far as I could understand, when defining a package from a git
>    repository, I have to specify the package version and commit. Does this
>    mean that I will forever have to check for new versions and edit the
>    package definition to update it?

Yes, just like with any other source code.  You can make Guix use a
different source with transformations on the command line, but we try to
keep things up-to-date.

>    5. Is there a relatively simple way to port packages from other distros
>    into Guix? Could this be an automated process?

Not from other distros but from upstream repositories; see “guix
import”.  If you want a fun project you could work on extending “guix
import” to import from distro archives.

-- 
Ricardo

Re: Packaging existing software for Guix

[Cássio Tavares]

Hi, and thanks for your patient guidance, Ricardo!
So . . .

My progress

I'm trying to follow your (and @Vagrant <mailto:vagrant@debian.org>Cascadian
<mailto:vagrant@debian.org>'s) suggestions, looking into the `
guix.git/gnu/packages/*` files for examples of package definitions, reading
the development versions of the manual and the cookbook, and also
experimenting on my own. With that I could find out, for the package I'm
trying to port, what build-system to use, how to specify the origin and the
commit, and how to get the hash for that commit. So, some progress, but
there are still things to debug.

Your challenge

>    5. Is there a relatively simple way to port packages from other distros
> >    into Guix? Could this be an automated process?
>
> Not from other distros but from upstream repositories; see “guix import”.


I'm looking into `guix import`, and made a few experiments with it.  And ...


> If you want a fun project you could work on extending “guix
> import” to import from distro archives.


Interesting challenge ─ I'd like to be able to accept it. *But* (a *big*
*but*) I think I'm hundreds of miles away from being capable of doing
that ─ just
look at the picture you're painting:

Nixpkgs is often not a good template, because more often than not they
> are cutting corners when it comes to bootstrapping or building from source.
>

Tricky, isn't it? But just for brainstorming, does any other distro package
its applications in a way that is more descriptive of the build process, so
that it could be more easily translated into Scheme for Guix?

And, redirecting a bit the problem ─ would it be useful to have an importer
for NodeJS packages? (I know that most Node packages are defined
per-project in a package.json file, but there are those that can be used as
a stand-alone App) And that would be simpler or more complex than an
importer for a distro (assuming a carefully chosen, favorable distro)?
Just to be clear, this is just for the sake of exploring possibilities ─
I'm not committing to undertaking this project.

Anyway, I was touched by your availability:

You are welcome to send me issue numbers with your patches and
> I’ll review them more quickly.
>

Your offer makes me feel very much encouraged to proceed with my attempts
to package things for Guix, and, in doing so, contribute in a more concrete
way to the Free Software movement. But...

Failed attempts (help needed)

I want to install and use TiddlyMap
<https://github.com/felixhayashi/TW5-TiddlyMap>, which extends TiddlyWiki5
<https://github.com/Jermolene/TiddlyWiki5>, which is then its dependency.
So to isolate things, I started by writing a package definition for the
latter, which didn't work. At first debugging was easy, because guix
informs that some `use-module` expression is missing. But then I got stuck.
So, maybe you would be willing to take a look at how far I've got up to
now, and give me some guidance? Here it is:

(define-module (gnu packages tiddlywiki)
  #:use-module (guix packages)
  #:use-module (guix git-download)
  #:use-module (guix build-system node)
  #:use-module (guix licenses)

  #:use-module (gnu packages node))



(define-public tiddlywiki
  (package
    (name "tiddlywiki")
    (version "5.2.2")
    (source
      (origin
        (method git-fetch)
        (uri (git-reference
               (url "https://github.com/Jermolene/TiddlyWiki5")
               (commit (string-append "v" version))))
        (file-name (git-file-name name version))
        (sha256
          (base32
            "0ji5c3bqhjaign101fjy13bfhq1i804cxaibs61xmnfync6g1pf7"))))
    (build-system node-build-system)
    (home-page "https://tiddlywiki.com")
    (synopsis "A non-linear web-browser based personal notebook app")
    (description "TiddlyWiki is a complete interactive wiki in
      JavaScript. It can be used as a single HTML file in the browser
      or as a powerful Node.js application. It is highly
      customisable: the entire user interface is itself implemented
      in hackable WikiText.")
    (license bsd-3)))


# This last line is so that this file returns a package definition

tiddlywiki


Then I tried to install it with:  `guix shell --pure -f
/path/to/tiddlywiki.scm`, but it failed.
This is the relevant information (I think) inside the log-file:

starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to
`/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/bin:/gnu/store/g2ajyl8xk9aarxrgjbng2hkj3qm2v0z2-tar-1.34/bin:/gnu/store/iixwcv3k49ks1rf34pjgfzmzyhhgwng3-gzip-1.10/bin:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/bin:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/bin:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/bin:/gnu/store/ahmmvw21p11ik80lg1f953y7fd8bqkjm-diffutils-3.8/bin:/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-patch-2.7.6/bin:/gnu/store/39rsx3nl4c31952jybbjb8d6idr5hx7r-findutils-4.8.0/bin:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/bin:/gnu/store/wxgv6i8g0p24q5gcyzd0yr07s8kn9680-sed-4.8/bin:/gnu/store/xjwp2hsd9256icjjybfrmznppjicywf6-grep-3.6/bin:/gnu/store/d251rfgc9nm2clzffzhgiipdvfvzkvwi-coreutils-8.32/bin:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/bin:/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin:/gnu/store/s2pg5k98fl2g2szg9dykxyd9zl3xihv9-ld-wrapper-0/bin:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/bin:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/bin:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/sbin'
environment variable `NODE_PATH' set to
`/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/lib/node_modules'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to
`/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/include:/gnu/store/ri34iqiy08wn7k6czq43g5wl24ghsk97-libuv-1.42.0/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'
environment variable `CPLUS_INCLUDE_PATH' set to
`/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/include:/gnu/store/ri34iqiy08wn7k6czq43g5wl24ghsk97-libuv-1.42.0/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'
environment variable `LIBRARY_PATH' set to
`/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/lib:/gnu/store/ri34iqiy08wn7k6czq43g5wl24ghsk97-libuv-1.42.0/lib:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/lib:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/lib:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/lib:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/lib:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/lib:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/4jdghmc65q7i7ib89zmvq66l0ghf7jc4-glibc-2.33-static/lib:/gnu/store/fnr1z6xsan0437r0yg48d0y8k32kqxby-glibc-utf8-locales-2.33/lib'
environment variable `GUIX_LOCPATH' set to
`/gnu/store/fnr1z6xsan0437r0yg48d0y8k32kqxby-glibc-utf8-locales-2.33/lib/locale'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
      *... (very long list of unpacked files, with the indication of where
to)*
phase `unpack' succeeded after 0.6 seconds
starting phase `set-home'
set HOME to "/tmp/guix-build-tiddlywiki-5.2.2.drv-0/npm-home-0"
phase `set-home' succeeded after 0.0 seconds
starting phase `bootstrap'
no 'configure.ac' or anything like that, doing nothing
phase `bootstrap' succeeded after 0.0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0.0 seconds
starting phase `patch-source-shebangs'
    *... (list of shebangs patches)*
phase `patch-source-shebangs' succeeded after 0.5 seconds
starting phase `patch-dependencies'
phase `patch-dependencies' succeeded after 0.0 seconds
starting phase `delete-lockfiles'
phase `delete-lockfiles' succeeded after 0.0 seconds
starting phase `configure'
npm ERR! code ENOTCACHED
npm ERR! request to https://registry.npmjs.org/eslint failed: cache mode is
'only-if-cached' but no cached response available.

npm ERR! A complete log of this run can be found in:
npm ERR!
/tmp/guix-build-tiddlywiki-5.2.2.drv-0/npm-home-0/.npm/_logs/2022-04-02T17_48_43_558Z-debug.log
error: in phase 'configure': uncaught exception:
%exception #<&invoke-error program:
"/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/bin/npm"
arguments: ("--offline" "--ignore-scripts" "install") exit-status: 1
term-signal: #f stop-signal: #f>
phase `configure' failed after 0.6 seconds
command "/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/bin/npm"
"--offline" "--ignore-scripts" "install" failed with status 1

I have no idea what this means. Can you deduce anything useful from that?
What do I need to know to fix this?

Thanks again,
Cássio

Re: Packaging existing software for Guix

[raingloom]

For build system, the best is to look at the source.
eg.: if you see a `meson.build` file, it's most likely going to need
meson-build-system, etc. Read through the list of available build
systems in the Guix manual and see which one matches.

For hashes, just use the output of guix hash /dev/null. Guix will
complain that the hashes don't match, showing the expected hash and the
result, just copy the latter into your package.

Do *not* copy the hash from another package, because Guix will blindly
trust it and if for some reason the source of that package is also in
your store, it will use that. You would be building that other package
thinking that you were building the one you were actually working on.
It's not fun to debug that situation.

The "official" way to get the hash is actually to use `guix download`
but I'm always too lazy to figure out how to use that with git repos.
Maybe now it's easier to use it for them. For tarballs and such I do use
it.

On Mon, 4 Apr 2022 21:17:50 +0000
Cássio Tavares <cassio.ufg@gmail.com> wrote:

> Hi, and thanks for your patient guidance, Ricardo!
> So . . .
> 
> My progress
> 
> I'm trying to follow your (and @Vagrant
> <mailto:vagrant@debian.org>Cascadian <mailto:vagrant@debian.org>'s)
> suggestions, looking into the ` guix.git/gnu/packages/*` files for
> examples of package definitions, reading the development versions of
> the manual and the cookbook, and also experimenting on my own. With
> that I could find out, for the package I'm trying to port, what
> build-system to use, how to specify the origin and the commit, and
> how to get the hash for that commit. So, some progress, but there are
> still things to debug.
> 
> Your challenge
> 
> >    5. Is there a relatively simple way to port packages from other
> > distros  
> > >    into Guix? Could this be an automated process?  
> >
> > Not from other distros but from upstream repositories; see “guix
> > import”.  
> 
> 
> I'm looking into `guix import`, and made a few experiments with it.
> And ...
> 
> 
> > If you want a fun project you could work on extending “guix
> > import” to import from distro archives.  
> 
> 
> Interesting challenge ─ I'd like to be able to accept it. *But* (a
> *big* *but*) I think I'm hundreds of miles away from being capable of
> doing that ─ just
> look at the picture you're painting:
> 
> Nixpkgs is often not a good template, because more often than not they
> > are cutting corners when it comes to bootstrapping or building from
> > source. 
> 
> Tricky, isn't it? But just for brainstorming, does any other distro
> package its applications in a way that is more descriptive of the
> build process, so that it could be more easily translated into Scheme
> for Guix?
> 
> And, redirecting a bit the problem ─ would it be useful to have an
> importer for NodeJS packages? (I know that most Node packages are
> defined per-project in a package.json file, but there are those that
> can be used as a stand-alone App) And that would be simpler or more
> complex than an importer for a distro (assuming a carefully chosen,
> favorable distro)? Just to be clear, this is just for the sake of
> exploring possibilities ─ I'm not committing to undertaking this
> project.
> 
> Anyway, I was touched by your availability:
> 
> You are welcome to send me issue numbers with your patches and
> > I’ll review them more quickly.
> >  
> 
> Your offer makes me feel very much encouraged to proceed with my
> attempts to package things for Guix, and, in doing so, contribute in
> a more concrete way to the Free Software movement. But...
> 
> Failed attempts (help needed)
> 
> I want to install and use TiddlyMap
> <https://github.com/felixhayashi/TW5-TiddlyMap>, which extends
> TiddlyWiki5 <https://github.com/Jermolene/TiddlyWiki5>, which is then
> its dependency. So to isolate things, I started by writing a package
> definition for the latter, which didn't work. At first debugging was
> easy, because guix informs that some `use-module` expression is
> missing. But then I got stuck. So, maybe you would be willing to take
> a look at how far I've got up to now, and give me some guidance? Here
> it is:
> 
> (define-module (gnu packages tiddlywiki)
>   #:use-module (guix packages)
>   #:use-module (guix git-download)
>   #:use-module (guix build-system node)
>   #:use-module (guix licenses)
> 
>   #:use-module (gnu packages node))
> 
> 
> 
> (define-public tiddlywiki
>   (package
>     (name "tiddlywiki")
>     (version "5.2.2")
>     (source
>       (origin
>         (method git-fetch)
>         (uri (git-reference
>                (url "https://github.com/Jermolene/TiddlyWiki5")
>                (commit (string-append "v" version))))
>         (file-name (git-file-name name version))
>         (sha256
>           (base32
>             "0ji5c3bqhjaign101fjy13bfhq1i804cxaibs61xmnfync6g1pf7"))))
>     (build-system node-build-system)
>     (home-page "https://tiddlywiki.com")
>     (synopsis "A non-linear web-browser based personal notebook app")
>     (description "TiddlyWiki is a complete interactive wiki in
>       JavaScript. It can be used as a single HTML file in the browser
>       or as a powerful Node.js application. It is highly
>       customisable: the entire user interface is itself implemented
>       in hackable WikiText.")
>     (license bsd-3)))
> 
> 
> # This last line is so that this file returns a package definition
> 
> tiddlywiki
> 
> 
> Then I tried to install it with:  `guix shell --pure -f
> /path/to/tiddlywiki.scm`, but it failed.
> This is the relevant information (I think) inside the log-file:
> 
> starting phase `set-SOURCE-DATE-EPOCH'
> phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
> starting phase `set-paths'
> environment variable `PATH' set to
> `/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/bin:/gnu/store/g2ajyl8xk9aarxrgjbng2hkj3qm2v0z2-tar-1.34/bin:/gnu/store/iixwcv3k49ks1rf34pjgfzmzyhhgwng3-gzip-1.10/bin:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/bin:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/bin:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/bin:/gnu/store/ahmmvw21p11ik80lg1f953y7fd8bqkjm-diffutils-3.8/bin:/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-patch-2.7.6/bin:/gnu/store/39rsx3nl4c31952jybbjb8d6idr5hx7r-findutils-4.8.0/bin:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/bin:/gnu/store/wxgv6i8g0p24q5gcyzd0yr07s8kn9680-sed-4.8/bin:/gnu/store/xjwp2hsd9256icjjybfrmznppjicywf6-grep-3.6/bin:/gnu/store/d251rfgc9nm2clzffzhgiipdvfvzkvwi-coreutils-8.32/bin:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/bin:/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin:/gnu/store/s2pg5k98fl2g2szg9dykxyd9zl3xihv9-ld-wrapper-0/bin:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/bin:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/bin:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/sbin'
> environment variable `NODE_PATH' set to
> `/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/lib/node_modules'
> environment variable `BASH_LOADABLES_PATH' unset
> environment variable `C_INCLUDE_PATH' set to
> `/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/include:/gnu/store/ri34iqiy08wn7k6czq43g5wl24ghsk97-libuv-1.42.0/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'
> environment variable `CPLUS_INCLUDE_PATH' set to
> `/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/include:/gnu/store/ri34iqiy08wn7k6czq43g5wl24ghsk97-libuv-1.42.0/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'
> environment variable `LIBRARY_PATH' set to
> `/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/lib:/gnu/store/ri34iqiy08wn7k6czq43g5wl24ghsk97-libuv-1.42.0/lib:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/lib:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/lib:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/lib:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/lib:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/lib:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/4jdghmc65q7i7ib89zmvq66l0ghf7jc4-glibc-2.33-static/lib:/gnu/store/fnr1z6xsan0437r0yg48d0y8k32kqxby-glibc-utf8-locales-2.33/lib'
> environment variable `GUIX_LOCPATH' set to
> `/gnu/store/fnr1z6xsan0437r0yg48d0y8k32kqxby-glibc-utf8-locales-2.33/lib/locale'
> phase `set-paths' succeeded after 0.0 seconds
> starting phase `install-locale'
> using 'en_US.utf8' locale for category "LC_ALL"
> phase `install-locale' succeeded after 0.0 seconds
> starting phase `unpack'
>       *... (very long list of unpacked files, with the indication of
> where to)*
> phase `unpack' succeeded after 0.6 seconds
> starting phase `set-home'
> set HOME to "/tmp/guix-build-tiddlywiki-5.2.2.drv-0/npm-home-0"
> phase `set-home' succeeded after 0.0 seconds
> starting phase `bootstrap'
> no 'configure.ac' or anything like that, doing nothing
> phase `bootstrap' succeeded after 0.0 seconds
> starting phase `patch-usr-bin-file'
> phase `patch-usr-bin-file' succeeded after 0.0 seconds
> starting phase `patch-source-shebangs'
>     *... (list of shebangs patches)*
> phase `patch-source-shebangs' succeeded after 0.5 seconds
> starting phase `patch-dependencies'
> phase `patch-dependencies' succeeded after 0.0 seconds
> starting phase `delete-lockfiles'
> phase `delete-lockfiles' succeeded after 0.0 seconds
> starting phase `configure'
> npm ERR! code ENOTCACHED
> npm ERR! request to https://registry.npmjs.org/eslint failed: cache
> mode is 'only-if-cached' but no cached response available.
> 
> npm ERR! A complete log of this run can be found in:
> npm ERR!
> /tmp/guix-build-tiddlywiki-5.2.2.drv-0/npm-home-0/.npm/_logs/2022-04-02T17_48_43_558Z-debug.log
> error: in phase 'configure': uncaught exception:
> %exception #<&invoke-error program:
> "/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/bin/npm"
> arguments: ("--offline" "--ignore-scripts" "install") exit-status: 1
> term-signal: #f stop-signal: #f>
> phase `configure' failed after 0.6 seconds
> command
> "/gnu/store/akwqc82xg9l0g873hh7ia81pdwkf2sm6-node-14.18.3/bin/npm"
> "--offline" "--ignore-scripts" "install" failed with status 1
> 
> I have no idea what this means. Can you deduce anything useful from
> that? What do I need to know to fix this?
> 
> Thanks again,
> Cássio

Re: Packaging existing software for Guix

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

On 2022-03-29, Cássio Tavares wrote:
> So, I'm looking into package definition, and I have a few questions to
> start:
>
>    1. If I submit an issue with a package request, does it take long for
>    the package to be made available?

This can be highly variable, unfortunately. There aren't always enough
people to review the requests.

The good news is that guix generally makes it relatively easy to use
your local changes immediately while you wait for it to get merged.


>    2. Can someone with only a very basic understanding of the Scheme (and
>    the functional paradigm) package software successfully enough to submit it
>    to the Guix project?

I've made more than a few package updates, modifications to packages,
new packages, etc. without really knowing scheme at all. I do have prior
experience packaging with Debian, though it is quite different.


>    3. Would that be very time-consuming (because my work is in a very
>    different area)? Is the learning curve steep?

I pretty much just take examples from looking at other packages, asking
for help on IRC or the mailing lists when I get stuck. Folks are usually
quite willing to help out!


>    4. As far as I could understand, when defining a package from a git
>    repository, I have to specify the package version and commit. Does this
>    mean that I will forever have to check for new versions and edit the
>    package definition to update it?

For changes going into upstream Guix, generally yes. Because guix is
functional package management, you need to know the hashes of your
inputs in advance.

The exception might be that some upstream software provides a guix.scm
to be able to build from the current git checkout. For example, the GNU
Mes project:

  https://git.savannah.gnu.org/cgit/mes.git/tree/guix.scm


>    5. Is there a relatively simple way to port packages from other distros
>    into Guix? Could this be an automated process?

There are various importers that allow importing packages from other
sources, though they may require some manual fixups in order to be
useable; depends on the importer.


>    6. Any further advice?

Feel free to experiment! Guix provides various mechanisms that make it
easy to not break your current environment, such as:

  guix shell PACKAGE # temporary environment with PACKAGE installed

I use that a lot when testing new things so as not to pollute my working
environment with experiemental changes, while still being able to test
them out.

The folks on IRC are generally hugely helpful.

Try to wrap your head around the manual, as it has answers to *many*
questions; the hardest part is sometimes figuring out exactly what is
relevent to what you're trying to do. I'd recommend the development
version of the manual:

  https://guix.gnu.org/en/manual/devel/en/guix.html

The cookbook also has some great examples that are a little more hands
on and more about doing something specific:

  https://guix.gnu.org/en/cookbook/en/guix-cookbook.html


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Packaging existing software for Guix

[Cássio Tavares]

Thanks, Vagrant.


> For changes going into upstream Guix, generally yes. Because guix is
> functional package management, you need to know the hashes of your
> inputs in advance.
>
> The exception might be that some upstream software provides a guix.scm
> to be able to build from the current git checkout. For example, the GNU
> Mes project:
>
>   https://git.savannah.gnu.org/cgit/mes.git/tree/guix.scm
>

OK, I checked this scheme file, and it's just a four-line program, but I
don't get it. So, help me here ─ what is this *↓↓↓* `mes` code actually
doing?

(define %source-dir (dirname (current-filename)))
(add-to-load-path (string-append %source-dir "/guix"))
(use-modules (git mes))

mes.git


Thanks again,
Cássio

Re: Packaging existing software for Guix

[Bird]

Cássio Tavares <cassio.ufg@gmail.com> writes:

>> The exception might be that some upstream software provides a guix.scm
>> to be able to build from the current git checkout. For example, the GNU
>> Mes project:
>>
>>   https://git.savannah.gnu.org/cgit/mes.git/tree/guix.scm
>>
>
> OK, I checked this scheme file, and it's just a four-line program, but I
> don't get it. So, help me here ─ what is this *↓↓↓* `mes` code actually
> doing?
>
> (define %source-dir (dirname (current-filename)))
> (add-to-load-path (string-append %source-dir "/guix")) (use-modules
> (git mes))

This defines a variable called "%source-dir" which contains the
directory name of current file (which is guix.scm). If we assume the
current file is in ~/mes/guix.scm, it'll be ~/mes

Then it adds the ~/mes/guix in the places guix will look for
code. (load-path).

For more info, run: info "(guile) Modules and the File System"

The (use-modules (git mes)) line says to find a filename "mes.scm" under
directory "git". Guix searches in the directories defined in load-path
and it'll find ~/mes/git/mes.scm file.

The mes.scm file defines some packages including mes.git . Putting the
name of package at the end means you can use `guix build -f guix.scm' or `guix
install -f guix.scm' directly without specifying an exact package

>
> Thanks again,
> Cássio
>
>

Re: Packaging existing software for Guix

[Liliana Marie Prikler]

Hi Cássio

> OK, I checked this scheme file, and it's just a four-line program,
> but I don't get it. So, help me here ─ what is this *↓↓↓* `mes` code
> actually doing?
> 
> 
This line gets the name of the directory in which (current-filename),
i.e. /path/to/mes/guix.scm lies.
> (define %source-dir (dirname (current-filename)))
This adds /path/to/mes/guix to the Guile load path.
> (add-to-load-path (string-append %source-dir "/guix"))
This loads git/mes.scm from the load path (see above) and makes its
public bindings available.
> (use-modules (git mes))
This is just a variable, probably exported by the (git mes) module,
which should itself be a (package ...) description.
> mes.git

Cheers

Re: Packaging existing software for Guix

[Cássio Tavares]

Thanks. I followed the paths and found the corresponding modules, and I
think I get it: it's just a way not to hard-code the root of where the `mes`
code lies.

But then, it seems to me that @Vagrant Cascadian <vagrant@debian.org> is
not correct when he suggests that this code enables the build system to
checkout the current git commit, because there are still version
specifications in all the `define-public` statements within the actual `
mes.scm` file. Am I correct in this assessment?

Thanks,
Cássio
-----
Faculdade de Letras - UFG
*“*
*Ou a gente se Raôni, ou a gente se Sting**”*


On Fri, Apr 1, 2022 at 6:26 AM Liliana Marie Prikler <
liliana.prikler@ist.tugraz.at> wrote:

> Hi Cássio
>
> > OK, I checked this scheme file, and it's just a four-line program,
> > but I don't get it. So, help me here ─ what is this *↓↓↓* `mes` code
> > actually doing?
> >
> >
> This line gets the name of the directory in which (current-filename),
> i.e. /path/to/mes/guix.scm lies.
> > (define %source-dir (dirname (current-filename)))
> This adds /path/to/mes/guix to the Guile load path.
> > (add-to-load-path (string-append %source-dir "/guix"))
> This loads git/mes.scm from the load path (see above) and makes its
> public bindings available.
> > (use-modules (git mes))
> This is just a variable, probably exported by the (git mes) module,
> which should itself be a (package ...) description.
> > mes.git
>
> Cheers
>