Re: Package request inxi

[Pierre Neidhardt]

Oleg Pykhalov  writes:

> Yes, unfortunately ‘inxi’ doens't provide like a ‘./configure’ thing to
> discover and use inputs.  But we could patch paths to input binaries.

My point that the dependencies are not _needed_ during the build phase,
so getting all the inputs induces extra load for nothing for the builder.


-- 
Pierre Neidhardt

My way of joking is to tell the truth.  That's the funniest joke in the world.
-- Muhammad Ali


signature.asc
Description: PGP signature

Re: Package request inxi

[Oleg Pykhalov]

Pierre Neidhardt  writes:

> I'm running into a strange issue:
> Line 4506:
>
>   $item =~ 
> s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|®|\(rev
>  ..\)|\'|\"|\sinc\s*$|\?//gi;
>
> gets replace by
>
>
>   $item =~ 
> s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|??|\(rev
>  ..\)|\'|\"|\sinc\s*$|\?//gi;
>
> More precisely,
>
>   ®
>
> into
>
>   ??
>
> I use the trivial build system and the only substitute (for now) is
>
>(substitute* "inxi"
>  (("/usr/bin/env perl")
>   (string-append (assoc-ref %build-inputs "perl") "/bin/perl")))

Please, could you try to wrap a ‘substitute*’ procedure with:

(with-fluids ((%default-port-encoding #f)) (substitute* #;…))

Oleg.


signature.asc
Description: PGP signature

Re: Package request inxi

[Oleg Pykhalov]

Pierre Neidhardt  writes:

> Oleg Pykhalov  writes:
>
>> Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will
>> not be installed to a user's profile but available in build phases.
>
> But those dependencies won't be used during the build phase

Yes, unfortunately ‘inxi’ doens't provide like a ‘./configure’ thing to
discover and use inputs.  But we could patch paths to input binaries.

Oleg.


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

I'm running into a strange issue:
Line 4506:

$item =~ 
s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|®|\(rev
 ..\)|\'|\"|\sinc\s*$|\?//gi;

gets replace by


$item =~ 
s/chipset|components|computing|computer|corporation|communications|electronics|electrical|electric|gmbh|group|incorporation|industrial|international|nee|revision|semiconductor|software|technologies|technology|ltd\.||\bltd\b|inc\.||\binc\b|intl\.|co\.||corp\.||\(tm\)|\(r\)|??|\(rev
 ..\)|\'|\"|\sinc\s*$|\?//gi;

More precisely,

®

into

  ??

I use the trivial build system and the only substitute (for now) is

   (substitute* "inxi"
 (("/usr/bin/env perl")
  (string-append (assoc-ref %build-inputs "perl") "/bin/perl")))

-- 
Pierre Neidhardt

There's no real need to do housework -- after four years it doesn't get
any worse.


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

Oleg Pykhalov  writes:

> Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will
> not be installed to a user's profile but available in build phases.

But those dependencies won't be used during the build phase: it's
unnecessary load for the builder.

-- 
Pierre Neidhardt

He is a man capable of turning any colour into grey.
-- John LeCarre


signature.asc
Description: PGP signature

Re: Package request inxi

[Oleg Pykhalov]

Hello Pierre,

Pierre Neidhardt  writes:

> I'm trying to package inxi.

Thank you for working on this!  Let us know if you have more questions.

> Does guix support optional dependencies?

Unfortunately Guix doesn't.

Instead you could use ‘(inputs …)’ and ‘(native-inputs …)’ which will
not be installed to a user's profile but available in build phases.

> Or is it that I should just include them in the description?

‘(package (description #;…) #;…)’ is not a good place to list and track
dependencies, because a package could include more or less in future.

Oleg.


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

I'm trying to package inxi.  Does guix support optional dependencies?
Or is it that I should just include them in the description?

-- 
Pierre Neidhardt

I think that's easier to read.  Pardon me.  Less difficult to read.
 -- Larry Wall in <199710120226.taa06...@wall.org>


signature.asc
Description: PGP signature

Re: How to install prerelease package versions (particularly Emacs)

[Pierre Neidhardt]

Oleg Pykhalov  writes:

> Pierre Neidhardt  writes:
>
>> I tried reusing your package snippet from
>> http://lists.gnu.org/archive/html/help-guix/2017-09/msg00074.html by
>> setting
>>
>>(url "git://localhost/~ambrevar/projects/emacs")
>
> I'm sorry for probably an obvious question.  Does ‘git clone
> git://localhost/~ambrevar/projects/emacs’ work?
>
> […]
>
>> I'm not very familiar with the "git" protocol: does it require some
>> special configuration?
>
> It does, see 
> https://www.gnu.org/software/guix/manual/html_node/Version-Control-Services.html
>
> Be sure ‘user-path’ is setted correctly.
>
>> I also tried specifying a local path:
>>
>>(url "/home/ambrevar/projects/emacs")
>> 
>> […]
>> 
>> I think this is a bug: if git clone accepts local paths, then so should
>> git-reference.
>
> It would be a useful feature, but I don't know all pitfalls.
>
> We can do ‘guix pull --url=$PWD’ in “Guix checkout” though.

Thank you for the hint.  That said, I really don't want to set up a git
server for so little.

Is there a good reason not to allow local paths in git URLs?

-- 
Pierre Neidhardt

Every solution breeds new problems.


signature.asc
Description: PGP signature

Re: How to install prerelease package versions (particularly Emacs)

[Pierre Neidhardt]

Oleg Pykhalov  writes:

>>> In case of ‘emacs’ package recipe, ‘--with-source’ doesn't work for a
>>> snapshot of the ‘master’ branch.
>>
>> Why?  Because you’d need to run ‘autoreconf’ and the like?
>
> To run everything in ‘(arguments …)’ except ‘#:parallel-build? #t’.
>
> From http://lists.gnu.org/archive/html/help-guix/2017-09/msg00074.html
> --8<---cut here---start->8---
>   (arguments
>(substitute-keyword-arguments
>`(#:parallel-build? #t
>#:tests? #f
>,@(package-arguments emacs))
>  ((#:phases phases)
>   `(modify-phases ,phases
>  (add-after 'unpack 'autogen
>(lambda _
>  (zero? (system* "sh" "autogen.sh"
>  (delete 'reset-gzip-timestamps)
> --8<---cut here---end--->8---

What do you mean?  That parallel-build has to be turned off for the
master branch?

I actually noticed that running `make -j5` locally, the build fails at
the `temacs` step.  The build succeeds with `make`.

That said, I tried running

guix build --keep-failed 
--with-source=ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-26.1-rc1.tar.xz emacs

It fails with

starting phase `check'
make -C lib all
make info-real info-dir
You do not seem to have the test/ directory.
Maybe you are using a release tarfile, rather than a repository 
checkout.
make: *** [Makefile:937: have-tests] Error 1
make: *** Waiting for unfinished jobs

Why should it fail if it's a tarball?  The error message seems that it
understands precisely what we are trying to do.

-- 
Pierre Neidhardt

 Being overloaded is the sign of a true Debian maintainer.


signature.asc
Description: PGP signature

Re: How to install prerelease package versions (particularly Emacs)

[Pierre Neidhardt]

Mathieu Lirzin  writes:

> With the ‘#:recursive?’ keyword option set to #t, ‘local-file’ should
> work for directories.

Indeed, thanks for pointing out.

I tried and it failed with

starting phase `configure'
source directory: "/tmp/guix-build-emacs-dev-26.0.91.drv-0/source" 
(relative from build: ".")
build directory: "/tmp/guix-build-emacs-dev-26.0.91.drv-0/source"
configure flags: 
("CONFIG_SHELL=/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash"
 
"SHELL=/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash"
 "--prefix=/gnu/store/iaipasvi8dys79ms3y0axvwwdfnd31dq-emacs-dev-26.0.91" 
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
configure: WARNING: unrecognized options: --enable-fast-install
./configure: line 3350: config.log: Permission denied
./configure: line 3360: config.log: Permission denied
phase `configure' failed after 0.1 seconds

I inspected the content of
"/tmp/guix-build-emacs-dev-26.0.91.drv-0/source": many files are
missing, among others "configure".

I am very confused...

--
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: `guix package -u` upgrades packages to themselves

[Martin Castillo]

On 11.04.2018 11:40, Pierre Neidhardt wrote:
>
> Sorry if I was confusing:  the output remains the same after upgrade.
>
> I can repeat the command indefinitely, it keep "upgrading" the same set
> of packages as per the output (but it does not actually do anything).
>

I see the same on 792ddfdc76147d494052fa93ecbfdbee7e72be68.


-- 
GPG: 7FDE 7190 2F73 2C50 236E  403D CC13 48F1 E644 08EC
[13:56:45]pi@pi:~/code/updapr$ guix package -u
guile: warning: failed to install locale
warning: failed to install locale: Invalid argument
The following package will be upgraded:
   guile2.2.3 -> 2.2.3  
/gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3

substitute: guile: warning: failed to install locale
substitute: warning: failed to install locale: Invalid argument
nothing to be done
[14:19:21]pi@pi:~/code/updapr$ ll ~/.guix-profile/bin/guile
lrwxrwxrwx 5 root root 65 Jan  1  1970 /home/pi/.guix-profile/bin/guile -> 
/gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3/bin/guile*
[14:20:29]pi@pi:~/code/updapr$ guix package -u
guile: warning: failed to install locale
warning: failed to install locale: Invalid argument
The following package will be upgraded:
   guile2.2.3 -> 2.2.3  
/gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3

substitute: guile: warning: failed to install locale
substitute: warning: failed to install locale: Invalid argument
nothing to be done
[14:21:18]pi@pi:~/code/updapr$ ll ~/.guix-profile/bin/guile
lrwxrwxrwx 5 root root 65 Jan  1  1970 /home/pi/.guix-profile/bin/guile -> 
/gnu/store/nb39n4ia25fdmzcfm628il1jqdkipf7s-guile-2.2.3/bin/guile*


signature.asc
Description: OpenPGP digital signature

Re: `guix package -u` upgrades packages to themselves

[Ricardo Wurmus]

Pierre Neidhardt  writes:

> I can run the following command as much as I want it will keep updating
> a bunch of packages to themselves.

That’s expected if you’ve upgraded Guix since installing the packages.
(If you haven’t then it’s probably a bug.)

That’s because the package version itself is insufficient.  In Guix
we’re dealing with package “variants”.  Guix will never upgrade a
package to the same variant, but it can happen that there are different
variants for the same version of a package.

That’s usually because inputs to these packages have changed, which
results in a new package output in the functional package management
model.  The version stays the same, but since the inputs have changed,
the output will be different and thus end up in a new directory.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net