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

[Carlo Zancanaro]

I've had a problem like this before, when I was trying to build 
the Shepherd from git.


On Wed, Apr 11 2018, Pierre Neidhardt wrote:

./configure: line 3350: config.log: Permission denied


I'm pretty sure this is what I had, and it was a problem of trying 
to build in a directory that was already built. I think the daemon 
copies the files, but the permissions aren't right, so it can't 
write over the file that my user had created. From memory I solved 
it by doing `make distclean` before running the build with Guix.


Carlo


signature.asc
Description: PGP signature

Re: inxi and inxi-full

[Pierre Neidhardt]

I've reported the issue upstream:

https://github.com/smxi/inxi/issues/143

> * In the meantime, can't we just remove the offending line from the
>   source?  This one:
>
>   $ENV{'PATH'} = 
> 'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';

As I initially suggested, this would work but we also need to change
@paths to the Guix PATH values.

> None of those paths are guaranteed to exist on GuixSD.  If we remove
> that line, then won't Perl's "system" function use whatever PATH is set
> in the environment?  If, in addition to removing that line, we wrap the
> script with our wrap-program procedure, then we will have full control
> over the PATH, and inxi should work.

Why would we need to wrap the program?  With the above fix, then we are
all good, aren't we?

Or is it to ensure that inxi does not see any other binary than the one
in its wrapped environment?  Then that would prevent inxi-minimal to be
"extended" by installing more programs.

> The system, and users on the system, may have a lot of these programs
> installed already.  For example, coreutils is certainly installed
> somewhere.  It is likely that inxi's closure overlaps with some of those
> already-installed tools.  Thanks to the functional software deployment
> model that Guix follows, such overlap will automatically be
> de-duplicated in the store.

Take for instance headless systems: those won't need the full mesa stack
to get information around their graphics capabilities.

--
Pierre Neidhardt

I hold it, that a little rebellion, now and then, is a good thing...
-- Thomas Jefferson


signature.asc
Description: PGP signature

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

[Chris Marusich]

Hi Pierre,

Pierre Neidhardt  writes:

> Chris Marusich  writes:
>
>> Can you share the package definition?
>
> Let's start from the most straight-forward:
>
> (define-public emacs-dev
>   (package
>(inherit emacs)
>(name "emacs-dev")
>(version "26.0.91")
>(source
>  (local-file "/home/ambrevar/projects/emacs-build" #:recursive? #t

I took this definition and adapted it as shown in the attached file.  I
then did the following things:

* Save the file at /tmp/emacs.scm.

* Clone Emacs' Git repository into /tmp/emacs at commit
  93678bffe6427b9d83dae032c56a4e480539a4a7.

* Get an environment with the necessary dependencies, and run autogen.sh:

guix environment emacs

  You could try with --pure to see if the emacs inputs are actually
  enough to bootstrap Emacs' Git repository.  I doubt they are.  You can
  experiment with adding dependencies by using the --ad-hoc option.
  Once you figure out what dependencies are required to run autogen.sh,
  you can add them to your custom package definition if you want
  (although they won't be required for building Emacs once you've built
  the "configure" script).

  I happen to have various tools, such as Autoconf, installed in my
  profile (mainly so I can browse the manuals locally).  I'm pretty sure
  that's why the next step succeeded for me.

* Run autogen.sh to create the "configure" script:

./autogen.sh

* Now that the "configure" script has been created, build Emacs:

guix build -f /tmp/emacs.scm

For me, the build proceeded but then failed during the "check" phase:

--8<---cut here---start->8---
SUMMARY OF TEST RESULTS
---
Files examined: 195
Ran 2767 tests, 2619 results as expected, 24 unexpected, 124 skipped
7 files contained unexpected results:
  src/process-tests.log
  lisp/progmodes/xref-tests.log
  lisp/progmodes/flymake-tests.log
  lisp/files-tests.log
  lisp/eshell/em-ls-tests.log
  lisp/calendar/todo-mode-tests.log
  lisp/net/tramp-tests.log
make[2]: *** [Makefile:280: check-doit] Error 1
make[2]: Leaving directory '/tmp/guix-build-emacs-dev-26.0.91.drv-0/build/test'
make[1]: *** [Makefile:255: check] Error 2
make[1]: Leaving directory '/tmp/guix-build-emacs-dev-26.0.91.drv-0/build/test'
make: *** [Makefile:945: check] Error 2
phase `check' failed after 104.0 seconds
builder for `/gnu/store/dshw12bj2486lcfv65g04g9rznxgfrwp-emacs-dev-26.0.91.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/dshw12bj2486lcfv65g04g9rznxgfrwp-emacs-dev-26.0.91.drv - 1 builder 
for `/gnu/store/dshw12bj2486lcfv65g04g9rznxgfrwp-emacs-dev-26.0.91.drv' failed 
with exit code 1
guix build: error: build failed: build of 
`/gnu/store/dshw12bj2486lcfv65g04g9rznxgfrwp-emacs-dev-26.0.91.drv' failed
--8<---cut here---end--->8---

I don't know much about the test failures, but this is a success as far
as I'm concerned: If you get this far, it means the local-file
declaration in your package definition is working as intended.

Hope that helps!

-- 
Chris


emacs.scm
Description: Binary data


signature.asc
Description: PGP signature

Re: inxi and inxi-full

[Chris Marusich]

Pierre Neidhardt  writes:

> The runtime dependencies are not exactly found by the PATH environment
> variable: ENV{'PATH'} is set manually and explicitly in the source.
> This is what I was discussing before (sorry if this was unclear).  Look
> at the diff I mentioned earlier.  (Or look at line ~100 in the source.)

Ah, I see that you mentioned this earlier.  Sorry for missing it!  To
resolve this issue, we could do a few things:

* Ask upstream not to manually set the PATH environment variable, which
  you mentioned in your email.

* In the meantime, can't we just remove the offending line from the
  source?  This one:

  $ENV{'PATH'} = 
'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';

None of those paths are guaranteed to exist on GuixSD.  If we remove
that line, then won't Perl's "system" function use whatever PATH is set
in the environment?  If, in addition to removing that line, we wrap the
script with our wrap-program procedure, then we will have full control
over the PATH, and inxi should work.

>> If inxi-minimal can provide genuinely useful information without
>> requiring the user to install additional packages, then I think it's
>> reasonable to add a package definition for it.  However, if almost
>> everyone is going to need to install additional packages into their
>> profile just to get the output from inxi-minimal that they wanted, then
>> I think we should not add it.
>
> inxi-minimal would work.  It does provide some information.  The crucial
> part here is that the set of optional dependencies is not bound to stop,
> it could grow indefinitely.  inxi is sort of a platform for hardware
> information.
>
> Tracking them all could be hard.  

I don't think it would be too hard if we use wrap-program.  In the best
case, somebody who cares about maintaining our inxi package would just
need to add a new input to the package definition every now and then.
The benefit is that inxi installed via Guix is complete and correct.

> Besides it might make inxi's closure much bigger.  This needs testing
> though.

The system, and users on the system, may have a lot of these programs
installed already.  For example, coreutils is certainly installed
somewhere.  It is likely that inxi's closure overlaps with some of those
already-installed tools.  Thanks to the functional software deployment
model that Guix follows, such overlap will automatically be
de-duplicated in the store.

So, I'm not too concerned about it.  But it would be good to check.

> My suggestion: let's give inxi-minimal and inxi a try, compare their
> closure size.  If it's not significant, then let's just have one single
> package.

Sounds good to me!

>> In any case, I can think of a few ways to package inxi:
>>
>> * Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
>>   and so forth appropriately.  This seems like the easiest way to me.
>
> That would not work, see my comment above.  PATH is hardwired in the program.

If we remove from the source code the offending line that sets the PATH,
then I think wrap-program will probably work.

Thank you for taking the time to work on this.

-- 
Chris


signature.asc
Description: PGP signature

Re: inxi and inxi-full

[Pierre Neidhardt]

Chris Marusich  writes:

> If we make two package definitions, I would prefer the name
> "inxi-minimal" for the version that is statically composed with the bare
> minimum of its runtime dependencies.  This is similar to how we have
> named other "minimal" packages in the past (e.g., qemu-minimal).

OK.

> I've taken a peek at inxi.  I assume it's this:
>
> https://github.com/smxi/inxi

Yes, sorry for not providing the link earlier.

> I see that it's a single perl script.  It runs various programs via
> Perl's "system" function in order to collate information about the
> system, and it then reports the results.  These programs - the runtime
> dependencies - are found via the PATH environment variable.  The script
> also embeds paths in some places that might need to be fixed.  For
> example, it looks like the get_gcc_data subroutine searches for gcc
> executables in the /usr/bin directory, which will not exist on GuixSD.

Thank you for the pointer to get_gcc_data.

The runtime dependencies are not exactly found by the PATH environment
variable: ENV{'PATH'} is set manually and explicitly in the source.
This is what I was discussing before (sorry if this was unclear).  Look
at the diff I mentioned earlier.  (Or look at line ~100 in the source.)

> If inxi-minimal can provide genuinely useful information without
> requiring the user to install additional packages, then I think it's
> reasonable to add a package definition for it.  However, if almost
> everyone is going to need to install additional packages into their
> profile just to get the output from inxi-minimal that they wanted, then
> I think we should not add it.

inxi-minimal would work.  It does provide some information.  The crucial
part here is that the set of optional dependencies is not bound to stop,
it could grow indefinitely.  inxi is sort of a platform for hardware
information.

Tracking them all could be hard.  Besides it might make inxi's closure
much bigger.  This needs testing though.

My suggestion: let's give inxi-minimal and inxi a try, compare their
closure size.  If it's not significant, then let's just have one single
package.


> In any case, I can think of a few ways to package inxi:
>
> * Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
>   and so forth appropriately.  This seems like the easiest way to me.

That would not work, see my comment above.  PATH is hardwired in the program.

> * Patch the absolute paths in the source with a patch file, a snippet,
>   or an extra build phase.

This would be a lot of hard work: the file is 16k+ lines, `system` calls
are all over the place and lots of variable names contain the program
names in question (e.g. `my @xdpyinfo`), which prevents global substitutions.

> * Ask the maintainer (or submit a patch to them) to provide a mechanism
>   to explicitly tell inxi where its dependencies live (e.g., some kind
>   of configure script), and then use that mechanism.  This seems like
>   the hardest way to me, but it is also the most ideal.

Or ask the maintainer not to manually set the PATH variable.
I'll report the issue on GitHub.

--
Pierre Neidhardt

Five bicycles make a volkswagen, seven make a truck.
-- Adolfo Guzman


signature.asc
Description: PGP signature

Re: inxi and inxi-full

[Chris Marusich]

Pierre Neidhardt  writes:

> Oleg Pykhalov  writes:
>
>> Pierre Neidhardt  writes:
>>
>> What do you think about ‘inxi’ package with inputs, which are only
>> required to run it,
>> and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
>> additional inputs?

If we make two package definitions, I would prefer the name
"inxi-minimal" for the version that is statically composed with the bare
minimum of its runtime dependencies.  This is similar to how we have
named other "minimal" packages in the past (e.g., qemu-minimal).

> My first thought is that it sounds like a good alternative to the
> concept of optional dependencies.
>
> I like the idea.
>
> It also means that the `inxi` package cannot patch inxi with full store
> paths.
>
> Any suggestion other than making leaving ENV{'PATH'} untouched and
> setting @paths to it?

I've taken a peek at inxi.  I assume it's this:

https://github.com/smxi/inxi

I see that it's a single perl script.  It runs various programs via
Perl's "system" function in order to collate information about the
system, and it then reports the results.  These programs - the runtime
dependencies - are found via the PATH environment variable.  The script
also embeds paths in some places that might need to be fixed.  For
example, it looks like the get_gcc_data subroutine searches for gcc
executables in the /usr/bin directory, which will not exist on GuixSD.

Let's suppose that we go ahead and create an "inxi-minimal" package that
only contains just enough inputs to get the tool to run, and we also
allow it to dynamically find tools at runtime via the PATH environment
variable.  Will inxi-minimal be useful for someone who wants to run
inxi?  Or is it more likely that someone will install inxi-minimal, run
it, find out that it didn't report all the info they expected it to
print (because they happened to not have some of the tools available in
their PATH), and then they will eventually realize they need to install
more packages in order for inxi to make use of them?

If inxi-minimal can provide genuinely useful information without
requiring the user to install additional packages, then I think it's
reasonable to add a package definition for it.  However, if almost
everyone is going to need to install additional packages into their
profile just to get the output from inxi-minimal that they wanted, then
I think we should not add it.  In any case, we should definitely have an
"inxi" package that is statically composed with as many of its runtime
dependencies as are required to make the tool useful by default.  Maybe
we can even add an "inxi-full" package that is statically composed with
as many of its runtime dependencies as possible, for those who need inxi
to report even more information.

I believe that whenever we can avoid it, we should not require a user of
Guix to manually compose software together at runtime by manually
installing additional packages.  I believe this is true even when the
software in question assumes (like inxi tacitly does) that that is how
most people will want to compose the software with its runtime
dependencies.  This sort of runtime composition may be useful or even
unavoidable in certain cases (e.g., when a program uses the EDITOR
environment variable to run the user's preferred text editor), but it
can result in incomplete or incorrect deployment, so we should avoid it
when we can.

In any case, I can think of a few ways to package inxi:

* Wrap the inxi program with wrap-program, setting its PATH, PERL5LIB,
  and so forth appropriately.  This seems like the easiest way to me.
  
* Patch the absolute paths in the source with a patch file, a snippet,
  or an extra build phase.

* Ask the maintainer (or submit a patch to them) to provide a mechanism
  to explicitly tell inxi where its dependencies live (e.g., some kind
  of configure script), and then use that mechanism.  This seems like
  the hardest way to me, but it is also the most ideal.

I would be happy with any of those approaches.  I just want to make sure
that whatever we add, we don't burden most users by requiring them to
install additional packages just to make inxi work the way they wanted.

-- 
Chris


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

Woof seems even better!  Thanks for the suggestion!
Can't believe I never ran into this before...

-- 
Pierre Neidhardt

We are not a clone.


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Clément Lassieur]

Marius Bakke  writes:

> Pierre Neidhardt  writes:
>
>> Clément Lassieur  writes:
>>
>>> Pierre Neidhardt  writes:
>>>
 vsftp: Very Secure FTP daemon
 Upstream URL:  https://security.appspot.com/vsftpd.html
 (It seems that there is not a single FTP server on Guix.  Strange... Can 
 anyone
 recommend anything better than vsftp for file sharing?  Not necessarily
 FTP.)
>>>
>>> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
>>> and it runs over SSH.
>>
>> My use-case is the following: share files with random people with
>> zero-configuration on their end.  Because FTP is supported by most web
>> browsers it is one of the most available options I think.
>>
>> Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
>> into that...
>
> I often start a HTTP server with `guix environment` for quick and dirty
> network sharing of the current directory:
>
> $ guix environment -C -N --ad-hoc python -- python3 -m http.server
>
> I suppose "wget" would be able to mass-download.

And there is 'woof' (packaged by Guix), it's a small HTTP server too,
very handy.  I use it very often at work to share files with my
collegues.  It serves the file only once unless specifed otherwise, and
'woof -U' provides an upload form, so that users can upload files
without having to install anything.  And it auto-tar directories.

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

Marius Bakke  writes:

> I often start a HTTP server with `guix environment` for quick and dirty
> network sharing of the current directory:
>
> $ guix environment -C -N --ad-hoc python -- python3 -m http.server
>
> I suppose "wget" would be able to mass-download.

This is absolutely fantastic!  Thank you so much for this!

Bye-bye FTP then :p

-- 
Pierre Neidhardt

Finster's Law:
A closed mouth gathers no feet.


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Marius Bakke]

Pierre Neidhardt  writes:

> Clément Lassieur  writes:
>
>> Pierre Neidhardt  writes:
>>
>>> vsftp:  Very Secure FTP daemon
>>> Upstream URL:   https://security.appspot.com/vsftpd.html
>>> (It seems that there is not a single FTP server on Guix.  Strange... Can 
>>> anyone
>>> recommend anything better than vsftp for file sharing?  Not necessarily
>>> FTP.)
>>
>> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
>> and it runs over SSH.
>
> My use-case is the following: share files with random people with
> zero-configuration on their end.  Because FTP is supported by most web
> browsers it is one of the most available options I think.
>
> Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
> into that...

I often start a HTTP server with `guix environment` for quick and dirty
network sharing of the current directory:

$ guix environment -C -N --ad-hoc python -- python3 -m http.server

I suppose "wget" would be able to mass-download.


signature.asc
Description: PGP signature

Re: inxi and inxi-full

[Pierre Neidhardt]

Oleg Pykhalov  writes:

> Pierre Neidhardt  writes:
>
> What do you think about ‘inxi’ package with inputs, which are only
> required to run it,
> and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
> additional inputs?

My first thought is that it sounds like a good alternative to the
concept of optional dependencies.

I like the idea.

It also means that the `inxi` package cannot patch inxi with full store
paths.

Any suggestion other than making leaving ENV{'PATH'} untouched and
setting @paths to it?

-- 
Pierre Neidhardt

There is more to life than increasing its speed.
-- Mahatma Gandhi


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

Clément Lassieur  writes:

> Pierre Neidhardt  writes:
>
>> vsftp:   Very Secure FTP daemon
>> Upstream URL:https://security.appspot.com/vsftpd.html
>> (It seems that there is not a single FTP server on Guix.  Strange... Can 
>> anyone
>> recommend anything better than vsftp for file sharing?  Not necessarily
>> FTP.)
>
> There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
> and it runs over SSH.

My use-case is the following: share files with random people with
zero-configuration on their end.  Because FTP is supported by most web
browsers it is one of the most available options I think.

Any other suggestion?  There is Samba, but I'm not sure I'd like to dive
into that...

-- 
Pierre Neidhardt

The brain is a wonderful organ; it starts working the moment you get up
in the morning, and does not stop until you get to work.


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Clément Lassieur]

Pierre Neidhardt  writes:

> vsftp:Very Secure FTP daemon
> Upstream URL: https://security.appspot.com/vsftpd.html
> (It seems that there is not a single FTP server on Guix.  Strange... Can 
> anyone
> recommend anything better than vsftp for file sharing?  Not necessarily
> FTP.)

There is SFTP, which is secure, and supported by GuixSD.  It's not FTP,
and it runs over SSH.

inxi and inxi-full

[Oleg Pykhalov]

Pierre Neidhardt  writes:

What do you think about ‘inxi’ package with inputs, which are only
required to run it,
and another ‘inxi-full’ package, which will inherit ‘inxi’, but with
additional inputs?

Oleg.


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Leo Famulari]

On Thu, Apr 12, 2018 at 03:04:59PM +0200, Ricardo Wurmus wrote:
> 
> Hi Pierre,
> 
> > Description:The RAR uncompression program
> > Upstream URL:   http://www.rarlab.com/rar_add.htm
> > (Not sure about the licensing of this one: does not look free.  Is there
> > any free way to extract RAR?)
> 
> This is not free software.  There was an unrar package, but it is no
> longer maintained and it had accumulated a few security problems, so we
> decided to remove it.

This discussion was in bug #28972:

https://bugs.gnu.org/28972

Apparently file-roller can handle some RAR files via libarchive.


signature.asc
Description: PGP signature

Re: Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Ricardo Wurmus]

Hi Pierre,

> Description:  The RAR uncompression program
> Upstream URL: http://www.rarlab.com/rar_add.htm
> (Not sure about the licensing of this one: does not look free.  Is there
> any free way to extract RAR?)

This is not free software.  There was an unrar package, but it is no
longer maintained and it had accumulated a few security problems, so we
decided to remove it.

-- 
Ricardo

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

[Ricardo Wurmus]

Hi Pierre,

> Chris Marusich  writes:
>
>> Can you share the package definition?
>
> Let's start from the most straight-forward:
>
> (define-public emacs-dev
>   (package
>(inherit emacs)
>(name "emacs-dev")
>(version "26.0.91")
>(source
>  (local-file "/home/ambrevar/projects/emacs-build" #:recursive? #t

Here’s mine:

--8<---cut here---start->8---
(define-public my/emacs
  (package (inherit emacs)
(name "my-emacs")
(version "26.0.91")
(source (origin
  (method url-fetch)
  (uri (string-append "http://alpha.gnu.org/gnu/emacs/;
  "pretest/emacs-" version ".tar.xz"))
  (sha256
   (base32
"1841hcqvwnh812gircpv2g9fqarlirh7ixv007hkglqk7qsvpxii"
(arguments
 (substitute-keyword-arguments
 ;; NOTE: I don’t know if the tests pass in this version; this
 ;; is for a much older version.
 (append '(#:tests? #f ; tests fail in this development version
   #:configure-flags '("--with-xwidgets=yes"))
 (package-arguments emacs
(inputs
 `(("libxcomposite" ,libxcomposite)
   ("webkitgtk+" ,webkitgtk)
   ;; These two are needed to get HTTPS support in Webkit.
   ("glib-networking" ,glib-networking)
   ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
   ,@(package-inputs emacs)))
;; This is only needed when building from a git checkout.
(native-inputs
 `(("autoconf" ,autoconf)
   ("automake" ,automake)
   ,@(package-native-inputs emacs)
--8<---cut here---end--->8---

Since I don’t know what the source code looks like, I can only guess
that maybe you need to bootstrap the build system first.

--
Ricardo

find-files: /gnu/store/...-xf86-video-*-*/share/X11/xorg.conf.d: No such file or directory

[Pierre Neidhardt]

When I update my system with

  sudo guix pull
  sudo guix system reconfigure ~/.guix-config/config.scm

I get error messages like those

--8<---cut here---start->8---
grafting '/gnu/store/kyj009p7hl52w829vvlp51hiwcgbr0w7-xterm-331' -> 
'/gnu/store/x82n8m8czgg376nhz9x84hzqk6adq7wi-xterm-331'...
find-files: 
/gnu/store/fab9nfx61485r2wi6hsqxyaw09hj9xah-xf86-video-vesa-2.4.0/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/1h0gvcfpxxy48km0vynsh1qwayvxams2-xf86-video-fbdev-0.4.4/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/pas4s82rair60pnsm1gb1pihplfqz6w2-xf86-video-cirrus-1.5.3/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/syw30dy9dbs1hq5v761yjl5ippck2d5b-xf86-video-intel-2.99.917-9-af6d8e9/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/hhqsgmxbbbwnb6kjhvc5qvc2xqrmxpzx-xf86-video-mach64-6.9.5/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/d0fnpj2sn7gjk0ywm6mi407d1w9b7qcm-xf86-video-nouveau-1.0.15/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/sspz0nm7aa6xmmi7q4lcmfiwf382z3gi-xf86-video-nv-2.1.21/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/3qyv7kg9c9byh1xzz73bx6vm5mbkijqb-xf86-video-sis-0.10.9/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/k74qad1mvqbcqhrhjq78h5c9ckz258d7-xf86-input-keyboard-1.9.0/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/jkz0zvrdcvglykzjvwqiwc0z0dsfn96b-xf86-input-mouse-1.9.2/share/X11/xorg.conf.d:
 No such file or directory
--8<---cut here---end--->8---

or

--8<---cut here---start->8---
grafting '/gnu/store/3ql1sd3vmq5wpyl536ni4yb265vv3x08-xf86-video-ati-18.0.1' -> 
'/gnu/store/njld2ib9i9az6q55g3lzblmsnzc0cp2z-xf86-video-ati-18.0.1'...
find-files: 
/gnu/store/fab9nfx61485r2wi6hsqxyaw09hj9xah-xf86-video-vesa-2.4.0/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/1h0gvcfpxxy48km0vynsh1qwayvxams2-xf86-video-fbdev-0.4.4/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/pas4s82rair60pnsm1gb1pihplfqz6w2-xf86-video-cirrus-1.5.3/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/syw30dy9dbs1hq5v761yjl5ippck2d5b-xf86-video-intel-2.99.917-9-af6d8e9/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/hhqsgmxbbbwnb6kjhvc5qvc2xqrmxpzx-xf86-video-mach64-6.9.5/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/d0fnpj2sn7gjk0ywm6mi407d1w9b7qcm-xf86-video-nouveau-1.0.15/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/sspz0nm7aa6xmmi7q4lcmfiwf382z3gi-xf86-video-nv-2.1.21/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/3qyv7kg9c9byh1xzz73bx6vm5mbkijqb-xf86-video-sis-0.10.9/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/k74qad1mvqbcqhrhjq78h5c9ckz258d7-xf86-input-keyboard-1.9.0/share/X11/xorg.conf.d:
 No such file or directory
find-files: 
/gnu/store/jkz0zvrdcvglykzjvwqiwc0z0dsfn96b-xf86-input-mouse-1.9.2/share/X11/xorg.conf.d:
 No such file or directory
--8<---cut here---end--->8---

Nonetheless the update completes successfully.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

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

[Pierre Neidhardt]

Ricardo Wurmus  writes:

> Here’s mine:
>
> --8<---cut here---start->8---
> (define-public my/emacs
>   (package (inherit emacs)
> (name "my-emacs")
> (version "26.0.91")
> [...]
> --8<---cut here---end--->8---

Note that RC1 is out.

> Since I don’t know what the source code looks like, I can only guess
> that maybe you need to bootstrap the build system first.

No, my local folder has all the files, including the "configure" file.
The whole point of working over a directory instead of an archive or a
git reference is that all files are re-used as-is.

-- 
Pierre Neidhardt

When in doubt, tell the truth.
-- Mark Twain


signature.asc
Description: PGP signature

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

[Pierre Neidhardt]

Chris Marusich  writes:

> Can you share the package definition?

Let's start from the most straight-forward:

(define-public emacs-dev
  (package
   (inherit emacs)
   (name "emacs-dev")
   (version "26.0.91")
   (source
 (local-file "/home/ambrevar/projects/emacs-build" #:recursive? #t

-- 
Pierre Neidhardt

Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

See https://github.com/smxi/inxi: it's a Perl script that calls various
programs (if it finds them) _at runtime_.

Basically inxi makes a number of `system PROGRAM` calls, where PROGRAM
is found in the PATH environment variable.

Because most of those dependencies are optional, it could be nice not
depend on them.  Which means no input at build-time.  But then we cannot
substitute the relative paths by the static full path to the store.

Another approach would be to _not_ have optional dependencies are go
more Nix-y as you suggest with including all the required programs as
input and storing their full path inside the inxi script.

This is hard though, because it implies parsing a huge Perl script...


We could also go the dead-simple way: leave PATH and paths to their
current values: the only downside I see is that inxi could pententially
call programs of the same name installed in user-specific folders
(e.g. ~/.local/bin).

--
Pierre Neidhardt

To save a single life is better than to build a seven story pagoda.


signature.asc
Description: PGP signature

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

[Ricardo Wurmus]

Hi Chris,

> Ricardo Wurmus  writes:
>
>> That’s because the package version itself is insufficient.  In Guix
>> we’re dealing with package “variants”.
>
> Where is the concept of a package "variant" defined?  I briefly grepped
> in the source but only found some ad-hoc stuff for Python and OCaml,
> which actually do some kind of stuff with the package-properties.

What I meant is that the version string alone is insufficient.  You can
have multiple variants of a package with the same nominal version, but
the differences are in the closure of the package.  When Guix is
upgraded in between two invocations of “guix package -u” seeing the same
“version” of a package to be upgraded to is a common occurrence.

> How can the inputs have changed if Pierre is just running "guix package
> -u" repeatedly?

That bit of information was not available to me when I composed my
initial response.  If Guix is not changed in between then this behaviour
seems to be a bug.

--
Ricardo

Re: Package request inxi

[Chris Marusich]

Pierre Neidhardt  writes:

> Basically inxi sets a 'paths' variable with the usual Unix paths and
> then forces the environment PATH to the same value.
>
> My suggestion instead: set 'paths' to /run/current-system/* and
> ~/.guix-profile/{sbin,bin}.
>
> What do you think?  Is this generic enough?  Is ~/.guix-profile a
> guaranteed location for the user profile?

No, ~/.guix-profile is not guaranteed.  Users can and do create profiles
in various places, e.g. with "guix package -p my-profile -i hello".  In
addition, /run/current-system/* would not work on foreign distros.

Is inxi a program, or a library?  If it's a program, then a better
solution is to bind PATH to the required dependencies at build time.  An
easy way to accomplish that would be to use the wrap-program procedure
from (guix build utils).  Read its docstring and grep for wrap-program
in the gnu/packages directories to see how it's used.  The basic idea is
that we can create a wrapper script for inxi which launches inxi in an
environment where PATH is set to exactly the things it needs.

There are other ways to accomplish the same thing.  For example, we
could replace references in the source code with references that point
to precisely the things required.  Generally we would add or modify a
build phase to accomplish this; read the docstring for the substitute*
procedure (also defined in (guix build utils) and grep for it in the
gnu/packages directories to see this technique in action.

Inxi has been written, like much software, to be composed with other
software at runtime; the composition is normally achieved via
environment variables.  The techniques above allow us to compose inxi
with its dependencies at build time, which is desirable because it means
that the built program will behave the same on my machine as it does on
yours, regardless of how my environment is configured.  This is known as
"static composition" of software components (see Section 7.1.1,
"Principles", in the Nix thesis [1]).

Footnotes: 
[1]  https://nixos.org/~eelco/pubs/phd-thesis.pdf

-- 
Chris


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

I was using "optional dependencies" in the sense Arch Linux uses it:
they don't impact the build, they are only used at runtime.

From a package declaration perspective, they are merely hint for the
user.

The main advantage over simply adding them to the description is that
the package manager can tell about "optional reverse dependencies".
When removing a package that is optionally needed by others, it
makes it possible to warn the users if they are going to lose some
functionnality for some specified packages.

None of `inputs`, `native-inputs` or `propagated-inputs` allow us to do
that.

--
Pierre Neidhardt

Flying is the second greatest feeling you can have.  The greatest feeling?
Landing...  Landing is the greatest feeling you can have.


signature.asc
Description: PGP signature

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

[Chris Marusich]

Ricardo Wurmus  writes:

> That’s because the package version itself is insufficient.  In Guix
> we’re dealing with package “variants”.

Where is the concept of a package "variant" defined?  I briefly grepped
in the source but only found some ad-hoc stuff for Python and OCaml,
which actually do some kind of stuff with the package-properties.

> 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.

How can the inputs have changed if Pierre is just running "guix package
-u" repeatedly?

-- 
Chris


signature.asc
Description: PGP signature

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

[Pierre Neidhardt]

Chris Marusich  writes:

> Pierre Neidhardt  writes:
>
>> Is there a good reason not to allow local paths in git URLs?
>
> You might find the "local-file" procedure to be helpful here.  You can
> pass a local-file as the source of a package, which should allow you to
> define packages that use a local file path as the source.  See (guix)
> G-Expressions in the manual for details.

Thank you for this suggestion.  Mathieu Lirzin already mentioned it in
another branch of this thread and after trying it I ran into strange issues.
Do you have experience with local-file?

-- 
Pierre Neidhardt

job Placement, n.:
Telling your boss what he can do with your job.


signature.asc
Description: PGP signature

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

[Chris Marusich]

Pierre Neidhardt  writes:

> 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...

Can you share the package definition?

-- 
Chris


signature.asc
Description: PGP signature

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

[Chris Marusich]

Pierre Neidhardt  writes:

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

You might find the "local-file" procedure to be helpful here.  You can
pass a local-file as the source of a package, which should allow you to
define packages that use a local file path as the source.  See (guix)
G-Expressions in the manual for details.

-- 
Chris


signature.asc
Description: PGP signature

Re: Package request inxi

[Chris Marusich]

Pierre Neidhardt  writes:

> I'm trying to package inxi.  Does guix support optional dependencies?

Can you describe the "optional dependencies" in a little more detail?
Will certain features of inxi be available or unavailable depending on
whether or not a specific dependency is present during the build?  Or
perhaps at when running inxi after it has been built?

If by "optional dependency" you meant "an item of software that, when
present during the build, will enable a certain feature of inxi," then
the answer is: you should probably just write a package definition that
choose a reasonable set of inputs and configure flags as the default.
In Guix, it is possible to define a second package that "inherits"
attributes from the first but also has customized attributes.  Since
this is scheme, it is also possible to define a procedure that generates
a customized package.  Those are two popular ways to deal with this kind
of "optional dependency."

It's also worth mentioning that even if you accidentally specify an
input that isn't actually used, it isn't all bad.  Such inputs will
clutter up places like the package graph, and they will increase the
build time because they need to be built first (even though they are not
used).  However, they won't show up in the package's output, so they
will not contribute to the total size of the built package.

-- 
Chris


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

Going on with the package, I think we only need this patch beside the
shabang adjustment:

 ## System
 my ($bsd_type,$language,$os) = ('','','');
 my ($cpu_sleep,$dl_timeout,$limit,$ps_count,$usb_level) = 
(0.35,4,10,5,0);
-my @paths = qw(/sbin /bin /usr/sbin /usr/bin /usr/X11R6/bin 
/usr/local/sbin /usr/local/bin);
-$ENV{'PATH'} = 
'sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin';
+my @paths = qw(/sbin /bin /run/setuid-programs 
/run/current-system/profile/bin /run/current-system/profile/sbin);
+push (@paths, "$ENV{'HOME'}/.guix-profile/bin");
+push (@paths, "$ENV{'HOME'}/.guix-profile/sbin");
+$ENV{'PATH'} = 
'/sbin:/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin';
+$ENV{'PATH'} = '$ENV:$ENV{'HOME'}/.guix-profile/bin";
+$ENV{'PATH'} = '$ENV:$ENV{'HOME'}/.guix-profile/sbin";
 my $sensors_cpu_nu = 0;

Basically inxi sets a 'paths' variable with the usual Unix paths and
then forces the environment PATH to the same value.

My suggestion instead: set 'paths' to /run/current-system/* and
~/.guix-profile/{sbin,bin}.

What do you think?  Is this generic enough?  Is ~/.guix-profile a
guaranteed location for the user profile?

Last but not least, what's the better approach between
- a patch,
- a substitute,
- a snippet?

I only know very little about Perl so the above code might look very clumsy.

-- 
Pierre Neidhardt

There is very little future in being right when your boss is wrong.


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

Oleg Pykhalov  writes:

> Please, could you try to wrap a ‘substitute*’ procedure with:
>
> (with-fluids ((%default-port-encoding #f)) (substitute* #;…))

It worked.

-- 
Pierre Neidhardt

Research is to see what everybody else has seen, and think what nobody
else has thought.


signature.asc
Description: PGP signature

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

[Pierre Neidhardt]

For now I'll stick to Emacs 26 RC1.  I've adapted the package
declaration from "emacs" with the following changes:
- Disable the scheme patch.
- Disable tests.

Find the declaration attached.

-- 
Pierre Neidhardt

When you get your PH.D. will you get able to work at BURGER KING?


emacs.scm
Description: Binary data


signature.asc
Description: PGP signature