Re: Check whether package has substitution

[Ludovic Courtès]

Hi,

sirgazil  skribis:

> $ guix package -m manifest.scm 
> would install new manifest from 'aggregate-manifest.scm' with 45 entries
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivations would be built:
>/gnu/store/...-abc.drv
>/gnu/store/...-dfg.drv
> 149.1 MB would be downloaded:
>/gnu/store/...-mno-3.1.0
>/gnu/store/...-xyz-0.14.2
> The following profile hooks would be built:
>/gnu/store/...-manual-database.drv
>/gnu/store/...-xdg-mime-database.drv
>
> Do you want to proceed? If "Yes", your machine will have to build some 
> derivations
> locally. Depending on your machine, this process can take a lot of time. If 
> "No", a 
> request will be sent to https://ci.guix.gnu.org to build the derivations for 
> you; then,
> you can try again later to see if the substitutes are available for download. 
> (Yes/No)

I think ‘guix package’ should remain non-interactive, at least by
default.

Ludo’.

./configure fails when building Guix

[HiPhish]

Hello everyone,

I am trying to set up Guix for proper local development, but it fails during 
the configuration step because the script cannot find the guild binary. Here is 
what I did:

- Check out the Guix repo
- Switch to a local branch
- run `guix environment guix` in order to set up all dependiencies
- run `./bootstrap`
- run `./configure`

Here is the output of `./bootstrap`:

guix$ ./bootstrap
+ find po/doc -type f -name *.po
+ sed -e s,guix-manual\.,,
+ xargs -n 1 -I{} basename {} .po
+ langs=zh_CN
de
ru
es
fr
+ [ ! -e doc/guix.zh_CN.texi ]
+ [ ! -e doc/guix.de.texi ]
+ [ ! -e doc/guix.ru.texi ]
+ [ ! -e doc/guix.es.texi ]
+ [ ! -e doc/guix.fr.texi ]
+ exec autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: running: autopoint --force
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-
autoconf-2.69/bin/autoconf --force
autoreconf: running: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-
autoconf-2.69/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its 
use is discouraged.
configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro 
instead,
configure.ac:23: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your 
Makefile.am 
files.
Makefile.am:601: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
autoreconf: Leaving directory `.'

And here is the output of `./configure`:

guix$ ./configure
checking for a BSD-compatible install... /gnu/store/
020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /gnu/store/
020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /gnu/store/
020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/grep
checking for egrep... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/
grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether NLS is requested... yes
checking for msgfmt... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/
msgfmt
checking for gmsgfmt... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/msgfmt
checking for xgettext... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/xgettext
checking for msgmerge... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/msgmerge
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by GCC... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-
profile/bin/ld
checking if the linker (/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for sed... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/sed
checking for the Guix system type... x86_64-linux
checking for the store directory... /gnu/store
checking the length of the installed socket file name... 40
checking for unit test root directory... /home/aleksandar/Developer/guix/test-
tmp
checking the length of the socket file name used in tests... 72
checking the length of a typical hash bang line... 73
checking the length of a hash bang line used in tests... 109
checking for pkg-config... /gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 2.2
conf

Re: ./configure fails when building Guix

[Julien Lepiller]

Le 14 mai 2019 11:52:40 GMT+02:00, HiPhish  a écrit :
>Hello everyone,
>
>I am trying to set up Guix for proper local development, but it fails
>during 
>the configuration step because the script cannot find the guild binary.
>Here is 
>what I did:
>
>- Check out the Guix repo
>- Switch to a local branch
>- run `guix environment guix` in order to set up all dependiencies
>- run `./bootstrap`
>- run `./configure`
>
>Here is the output of `./bootstrap`:
>
>guix$ ./bootstrap
>+ find po/doc -type f -name *.po
>+ sed -e s,guix-manual\.,,
>+ xargs -n 1 -I{} basename {} .po
>+ langs=zh_CN
>de
>ru
>es
>fr
>+ [ ! -e doc/guix.zh_CN.texi ]
>+ [ ! -e doc/guix.de.texi ]
>+ [ ! -e doc/guix.ru.texi ]
>+ [ ! -e doc/guix.es.texi ]
>+ [ ! -e doc/guix.fr.texi ]
>+ exec autoreconf -vfi
>autoreconf: Entering directory `.'
>autoreconf: running: autopoint --force
>autoreconf: running: aclocal --force -I m4
>autoreconf: configure.ac: tracing
>autoreconf: configure.ac: not using Libtool
>autoreconf: running: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-
>autoconf-2.69/bin/autoconf --force
>autoreconf: running: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-
>autoconf-2.69/bin/autoheader --force
>autoreconf: running: automake --add-missing --copy --force-missing
>configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
>and its 
>use is discouraged.
>configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
>macro 
>instead,
>configure.ac:23: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
>Makefile.am 
>files.
>Makefile.am:601: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
>autoreconf: Leaving directory `.'
>
>And here is the output of `./configure`:
>
>guix$ ./configure
>checking for a BSD-compatible install... /gnu/store/
>020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/install -c
>checking whether build environment is sane... yes
>checking for a thread-safe mkdir -p... /gnu/store/
>020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/mkdir -p
>checking for gawk... gawk
>checking whether make sets $(MAKE)... yes
>checking whether make supports nested variables... yes
>checking whether make supports nested variables... (cached) yes
>checking whether make supports the include directive... yes (GNU style)
>checking for gcc... gcc
>checking whether the C compiler works... yes
>checking for C compiler default output file name... a.out
>checking for suffix of executables...
>checking whether we are cross compiling... no
>checking for suffix of object files... o
>checking whether we are using the GNU C compiler... yes
>checking whether gcc accepts -g... yes
>checking for gcc option to accept ISO C89... none needed
>checking whether gcc understands -c and -o together... yes
>checking dependency style of gcc... gcc3
>checking how to run the C preprocessor... gcc -E
>checking for grep that handles long lines and -e... /gnu/store/
>020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/grep
>checking for egrep...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/
>grep -E
>checking for ANSI C header files... yes
>checking for sys/types.h... yes
>checking for sys/stat.h... yes
>checking for stdlib.h... yes
>checking for string.h... yes
>checking for memory.h... yes
>checking for strings.h... yes
>checking for inttypes.h... yes
>checking for stdint.h... yes
>checking for unistd.h... yes
>checking minix/config.h usability... no
>checking minix/config.h presence... no
>checking for minix/config.h... no
>checking whether it is safe to define __EXTENSIONS__... yes
>checking whether NLS is requested... yes
>checking for msgfmt...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/
>msgfmt
>checking for gmsgfmt...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
>bin/msgfmt
>checking for xgettext...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
>bin/xgettext
>checking for msgmerge...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
>bin/msgmerge
>checking build system type... x86_64-pc-linux-gnu
>checking host system type... x86_64-pc-linux-gnu
>checking for ld used by GCC...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-
>profile/bin/ld
>checking if the linker
>(/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/
>bin/ld) is GNU ld... yes
>checking for shared library run path origin... done
>checking for CFPreferencesCopyAppValue... no
>checking for CFLocaleCopyCurrent... no
>checking for GNU gettext in libc... yes
>checking whether to use NLS... yes
>checking where the gettext function comes from... libc
>checking for sed...
>/gnu/store/020aw068yfsq84h6scmnvfrjacmznsgz-profile/bin/sed
>checking for the Guix system type... x86_64-linux
>checking for the store directory... /gnu/store
>checking the length of the installed socket file name... 40
>checking for unit test root directory...
>/home/aleksandar/Developer/guix/test-
>tmp
>checking the length of the socket file name used in tests... 72
>checking the length of a typical hash bang line... 73
>checking the length of a hash bang line used in tests... 10

Re: ./configure fails when building Guix

[HiPhish]

On Tuesday, 14 May 2019 12:51:03 CEST Julien Lepiller wrote:
> Le 14 mai 2019 11:52:40 GMT+02:00, HiPhish  a écrit :
> 
> I get that too on foreign distros. Here configure finds your distso's guile
> (in /usr/bin). Try to run configure inside a pure guix environment:
> 
> guix environment guix --pure -- ./configure

Thank you, that did it.

Re: Update on 1.0.1

[Ludovic Courtès]

Hi Amin,

Amin Bandali  skribis:

> Not critical, but it would be nice to update guix-install.sh to mention
> “ci.guix.gnu.org” instead of “ci.guix.info” for clarity, similar to this
> previous commit of yours [0] from a while back.

Ricardo fixed it recently, thanks!

Ludo’.

Re: Update on 1.0.1

[Ludovic Courtès]

Giovanni Biscuolo  skribis:

> Ludovic Courtès  writes:
>
> [...]
>
>> Any other really important bit people would like to address?
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35655
> (Installer: mount error using btrfs on already formatted partition)

Looks like this one should be fixed!  If you want, you’re welcome to
build the image and give it a try:

  
https://www.gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html

Thanks,
Ludo’.

Parameterized packages

[Ludovic Courtès]

Hello Guix!

While thinking about  and looking
for ways to allow users to install just the locales they need right from
‘guix package’, I realized that “parameterized packages” are a
low-hanging fruit (by “parameterized packages” I mean something kinda
like Gentoo USE flags, or like a procedure if you will, but with a
command-line interface.)

Namely, one could write:

  (package
(name "glibc-utf8-locales")
;; …
(arguments
  `(#:phases … ,(assoc-ref (package-properties this-package)
   'locales)
…)))


and then we’d have a package transformation option like, say,
‘--with-argument=glibc-utf8-locales:locales=zh_CN.utf8’, which would
add the right property, like so:

  (package
(inherit glibc-utf8-locales)
(properties `((locales . ("zh_CN.utf8")

and tadaam! we have a parameterized package.

There’s a couple of gotchas:

  • We’d need to store more info in manifest entries so that
transformation options are preserved upon ‘guix upgrade’.

  • We might need to expose the package parameters somehow, so that if
one types ‘--with-argument=foobar=baz’, they get a correct error
message saying that “foobar” is not a known parameter.

  • We might want to make the CLI option less verbose too, but how?

Thoughts, comrades?

Thanks,
Ludo’.

Re: Parameterized packages

[Tobias Geerinckx-Rice]

Ludo',

Ludovic Courtès wrote:
While thinking about  and 
looking
for ways to allow users to install just the locales they need 
right from

‘guix package’, I realized that “parameterized packages” are a
low-hanging fruit


Wow.  Unexpected turn…

I'm still thinking about this, so all this is just me doing it out 
loud:



  (package
(inherit glibc-utf8-locales)
(properties `((locales . ("zh_CN.utf8")

and tadaam! we have a parameterized package.

There’s a couple of gotchas:

  • We’d need to store more info in manifest entries so that
transformation options are preserved upon ‘guix upgrade’.

  • We might need to expose the package parameters somehow, so 
  that if
one types ‘--with-argument=foobar=baz’, they get a correct 
error

message saying that “foobar” is not a known parameter.


Interesting idea to piggy-back on the properties field, and it 
might save some code (at least initially), but I don't see the 
overlap here.


None of the current properties (superseded, upstream-name, 
*-variant, cpe-name, hidden?) make much sense to expose in this 
way; they're semimmutable facts about the package.


While a dedicated field can provide richer metadata, such as 
description, basic ‘types’ & sane/permitted values, to be used by 
the UI.


Looking at Exherbo/ntoo, this will inevitably lead to factoring 
out very common option metadata so one doesn't have to keep 
writing ‘x11 bool "Add support for the X Window System"’ in 
every. single. package.


Then come the people asking how to set CFLAGS for all packages and 
you'll know you've made it.


  • We might want to make the CLI option less verbose too, but 
  how?


Possibly relevant: do you see package options¹ being added to 
package specifications?  That seems to be the classical approach.


Kind regards,

T G-R

[1]: I use the term ‘option’ because it's what my last FHS 
distribution called them, and it was a good distribution, and 
because ‘arguments’ is already an unrelated field in package 
expressions, and flags are boolean, but substitute whatever name 
you prefer.


signature.asc
Description: PGP signature

guix pull --commit and custom channel ?

[zimoun]

Dear,

When speaking about "Scientific Reproducibilty", one would roll-back
to a previous state of Guix. And it is possible with `guix pull
--commit='.

(noting it is only possible for not too old states, say v0.15 or post-inferior?)


However, it is not possible to roll-back the state of a custom
channel. Or I have missed something.

The UI should be: guix pull --commit=channel1:hash1  --commit=channel2:hash2
or guix pull --commit=channel1:hash1,channel2:hash2

Moreover, is it possible to roll-back with a manifest containing
several custom channels ?

I imagine something such that:
 guix describe > commits.txt
then months (or years?) later:
 guix pull --manifest=commits.txt

In other words, continue ideas proposed here [1].
[1] 
https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/


What do you think ?

All the best,
simon

Re: guix pull --commit and custom channel ?

[zimoun]

Hi,

Thank you.
Sorry for the noise, I missed the option in the manual.

> This is already possible:
>
>  $ guix describe -f channels > my-channels.scm
>  $ guix pull -C my-channels.scm

Well, it fits perfectly my needs. :-)

All the best,
simon

Re: guix pull --commit and custom channel ?

[Marius Bakke]

zimoun  writes:

> Dear,
>
> When speaking about "Scientific Reproducibilty", one would roll-back
> to a previous state of Guix. And it is possible with `guix pull
> --commit='.
>
> (noting it is only possible for not too old states, say v0.15 or 
> post-inferior?)
>
>
> However, it is not possible to roll-back the state of a custom
> channel. Or I have missed something.
>
> The UI should be: guix pull --commit=channel1:hash1  --commit=channel2:hash2
> or guix pull --commit=channel1:hash1,channel2:hash2

I don't think `guix pull` exposes these options through the CLI yet, but
you can specify exact commit(s) in channels.scm.

> Moreover, is it possible to roll-back with a manifest containing
> several custom channels ?
>
> I imagine something such that:
>  guix describe > commits.txt
> then months (or years?) later:
>  guix pull --manifest=commits.txt

This is already possible:

 $ guix describe -f channels > my-channels.scm
 $ guix pull -C my-channels.scm

HTH!
Marius


signature.asc
Description: PGP signature

guix package --search slow ?

[zimoun]

Dear,

When searching packages with `guix search`, it appears to me slow;
especially compared to `aptitude` of Debian.

Say on my machine:

$ time guix package --search=python-numpy | recsel -p name -
name: python-numpy
name: python-numpy-documentation
name: python-numpydoc
name: python2-numpy-documentation

real0m11.864s
user0m1.160s
sys 0m0.212s


$ time aptitude search python-numpy
i A python-numpy- Numerical Python adds a fast array facilit
v   python-numpy-abi9   -
v   python-numpy-api10  -
p   python-numpy-dbg- Fast array facility to the Python language
v   python-numpy-dev-
p   python-numpy-doc- NumPy documentation
p   python-numpydoc - Sphinx extension to support docstrings in

real0m3.219s
user0m0.656s
sys 0m0.088s


I am not sure to exactly understand how the search works.
Basically, a "big" `fold' is done on `%package-module-path' and there
is no caching. Right?

What should be done to improve the search speed?


All the best,
simon

Re: guix package --search slow ?

[Ricardo Wurmus]

For me this command

  time guix package --search=python-numpy

when run for the first time takes

  real  0m4.729s
  user  0m1.332s
  sys   0m0.815s

All following invocations finish in about a second:

  real  0m1.469s
  user  0m1.459s
  sys   0m0.108s

-- 
Ricardo

Re: GNU gettext 0.20.1 released

[Miguel]

Hi Tobias,

Tobias Geerinckx-Rice :
> Bruno,
> 
> Wow.  Thank you for this great summary!  Would that all projects 
> published such clear (and custom) release notes…  <3
> 
> I see that gnu/packages/gettext.scm has a nice chronological list 
> of copyright lines, which does make it appear as if I'm the 
> current packager of gettext in Guix.  However, the Guix project 
> doesn't have this notion of (package) maintainer: everyone 
> packages, fixes, and updates what they can whenever they can. 
> This might change in future but it works rather well now.
> 
> For that reason, I'm CC'ing the guix-devel@gnu.org list.  I 
> encourage you to add it to your own for future releases.
> 
> I'm having some trouble with the actual upgrade but I'll save that 
> for a reply.

What are the issues you have?  I could help with that. :-)

I see a big point that need special care: gettext-tools now depends on
libtextstyle, so gettext-boot0 will definitely fail if only
gettext-minimal is updated to the next version.

This is going to be a big big update in any case.  We can avoid
the new bootstrap, keeping 0.19.8.1 for it, but we should update
gettext-minimal so it may not worth the effort as probably almost all
the packages will be rebuilt.

My snippet for building it is this one, with some code from
gettext-minimal and it need some work:
>8
(define-public gettext-next
  (package (inherit gettext-minimal)
(name "gettext-next")
(version "0.20.1")
(source (origin
 (method url-fetch)
 (uri (string-append "mirror://gnu/gettext/gettext-"
 version ".tar.gz"))
 (sha256
  (base32
   "0p3zwkk27wm2m2ccfqm57nj7vqkmfpn7ja1nf65zmhz8qqs5chb6"
(inputs
 `(("xml2" ,libxml2)
   ;; Avoid dependency cycles
   ("unistring" ,(@ (gnu packages libunistring) libunistring))
   ("ncurses" ,(@ (gnu packages ncurses) ncurses
(arguments
 `(#:configure-flags
   (list "--with-included-libunistring=no"
 "--with-included-libxml=no"
 (string-append "--with-libxml2-prefix="
(assoc-ref %build-inputs "xml2"))
 (string-append "--with-libncurses-prefix="
(assoc-ref %build-inputs "ncurses"))
 (string-append "--with-libtermcap-prefix="
(assoc-ref %build-inputs "ncurses"))
 (string-append "--with-libunistring-prefix="
(assoc-ref %build-inputs "unistring")))
   #:phases
   (modify-phases %standard-phases
(add-before 'configure 'patch-fixed-paths
 (lambda* (#:key inputs #:allow-other-keys)
   (let* ((bash (which "sh")))
 (substitute* '("gettext-tools/config.h.in"
"gettext-tools/gnulib-tests/init.sh"
"gettext-tools/tests/init.sh"
"gettext-tools/system-tests/run-test")
   (("/bin/sh")
bash))
 (substitute* '("gettext-tools/src/project-id"
"gettext-tools/projects/KDE/trigger"
"gettext-tools/projects/GNOME/trigger")
 (("/bin/pwd")
  "pwd"))
 #t)))

(add-before 'check 'patch-tests
 (lambda* (#:key inputs #:allow-other-keys)
   (let* ((bash (which "sh")))
 ;; Some of the files we're patching are
 ;; ISO-8859-1-encoded, so choose it as the default
 ;; encoding so the byte encoding is preserved.
 (with-fluids ((%default-port-encoding #f))
   (substitute*
   (find-files "gettext-tools/tests"
   "^(lang-sh|msg(exec|filter)-[0-9])")
 (("#![[:blank:]]/bin/sh")
  (format #f "#!~a" bash)))

   #t)

   ;; When tests fail, we want to know the details.
   #:make-flags '("VERBOSE=yes")
8<

Happy hacking,
Miguel


pgpO_JRNXDZ5L.pgp
Description: Firma digital OpenPGP

Re: guix package --search slow ?

[Meiyo Peng]

Hi zimoun,

zimoun writes:

> When searching packages with `guix search`, it appears to me slow;
> especially compared to `aptitude` of Debian.
> ...
> What should be done to improve the search speed?

I remember "guix package --search" has always been pretty fast since
this patch series of Ludovic is merged into guix:
https://lists.gnu.org/archive/html/guix-patches/2019-01/msg00254.html.

Before that, "guix package --search" is slow.

Please check your guix's version.  If you are not using an old Guix.  I
am not sure why your experience is different from us.


--
Meiyo Peng
https://www.pengmeiyu.com/