Re: Recent change in 'guix package --search-paths' behavior?

[Chris Marusich]

Hi Ludo,

l...@gnu.org (Ludovic Courtès) writes:

> Chris Marusich  skribis:
>
>> Hi,
>>
>> The manual says ((guix) Invoking guix package):
>>
>>  This option can also be used to compute the _combined_ search paths
>>  of several profiles.  Consider this example:
>>
>>   $ guix package -p foo -i guile
>>   $ guix package -p bar -i guile-json
>>   $ guix package -p foo -p bar --search-paths
>>
>>  The last command above reports about the ‘GUILE_LOAD_PATH’
>>  variable, even though, taken individually, neither ‘foo’ nor ‘bar’
>>  would lead to that recommendation.
>
> [...]
>
>> Is the documentation wrong, or is this a regression?
>
> Try with “guile2.2-json” instead of “guile-json”.
>
> Ludo’.

As usual, you're right!  :-)  That worked:

--8<---cut here---start->8---
[0] marusich@garuda:/tmp
$ guix package -p foo -i guile
The following package will be installed:
   guile2.2.2   /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2

1 package in profile
The following environment variable definitions may be needed:
   export PATH="foo/bin${PATH:+:}$PATH"
[0] marusich@garuda:/tmp
$ guix package -p bar -i guile2.2-json
The following package will be installed:
   guile2.2-json0.6.0   
/gnu/store/a7hrfb8p7syai31rxhrcrmlq81kjcs5v-guile2.2-json-0.6.0

1 package in profile
[0] marusich@garuda:/tmp
$ guix package -p foo -p bar --search-paths
export PATH="foo/bin"
export GUILE_LOAD_PATH="bar/share/guile/site/2.2"
export GUILE_LOAD_COMPILED_PATH="bar/share/guile/site/2.2"
[0] marusich@garuda:/tmp
$ 
--8<---cut here---end--->8---

Why does 'guix' resolve to guile@2.2.2, but 'guile-json' resolves to
guile-json@0.6.0?  Is it because, as mentioned in the comments in
procedure 'find-newest-available-packages' in gnu/packages.scm, "the
preferred package is whichever one was found last by 'fold-packages'"?

I've attached a patch for the documentation which might help clarify
this for anyone who has the same question in the future.  What do you
think?  Too much detail for an edge case, or a useful footnote?

-- 
Chris
From 1b108931e88374a1835fb90dd6b0ebf715f3a267 Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Wed, 10 May 2017 23:05:31 -0700
Subject: [PATCH] doc: Clarify 'guix package --search-paths' example.

* doc/guix.texi (Invoking guix package): Explain why, in some cases, a user
  who runs the example code for 'guix package --search-paths' might see
  different results than what is written in the manual.
---
 doc/guix.texi | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 9b2fe3fdb..57f9f7863 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1802,7 +1802,13 @@ $ guix package -p foo -p bar --search-paths
 
 The last command above reports about the @code{GUILE_LOAD_PATH}
 variable, even though, taken individually, neither @file{foo} nor
-@file{bar} would lead to that recommendation.
+@file{bar} would lead to that recommendation@footnote{This example will
+only work as written if @code{guile-json} was built for the same major
+version of Guile that @code{guile} refers to (e.g., 2.x.x).  If that is
+not the case, then this command will @emph{not} report about
+@code{GUILE_LOAD_PATH} because the two packages were built for different
+major versions of Guile.  @xref{Invoking guix package}, for more
+information about how to precisely specify packages.}.
 
 
 @item --profile=@var{profile}
-- 
2.12.2



signature.asc
Description: PGP signature

about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013]

[ng0]

Hi,

I think this could be useful for extending the documentation
by explaining the limitations of linux-libre in case we
don't already do it in an easy language.
Appended Message Exchange with Alexandre Oliva:


On May  3, 2017, ng0 wrote:

> do you have a bugtracker where progress on this could be visible,

'fraid not.

> Do I have your permission to forward this message in full to our
> developer mailinglist,

Sure

> or do you happen to have an explanation already
> somewhere more public?

I'd have pointed to Bruce Byfield's interview, but evidently that was
not clear enough ;-)

- Forwarded message from Alexandre Oliva -

> Date: Wed, 03 May 2017 00:20:56 -0300
> From: Alexandre Oliva
> To: ng0
> Subject: Re: question about a bug mention in an interview back in 2013
> 
> On May  1, 2017, ng0 wrote:
> 
> >> Indeed, I became aware that some users have got the idea that
> >> blocking the loading of blobs is a feature. It's not; it's just a
> >> bug that's quite difficult to fix. The decision on whether or not to
> >> use a piece of software, be it Free or not, should belong to the
> >> users, and it's not our intent to make that difficult.
> 
> > If for example linux-libre is installed on a device with an
> > intel wifi card, and your bug is solved, would this imply that
> > the intel card can be loaded (which currently can't be achieved)?
> 
> I suppose you mean 'the blob that controls the intel card can be
> loaded'.  If so, the answer is yes.  Loading it and running it is a
> user's decision, even when the software is non-Free.  We don't stop
> users from doing so, but unfortunately we make it very difficult
> (modifying the module sources and rebuilding the kernel, or at least the
> module, is currently required).  If the bug was fixed, it would likely
> work out of the box.
> 
> Unfortunately, it looks like fixing this bug is not possible.  Even with
> the internal firmware loader and if we were to enumerate available
> firmware files before ever asking for them, hashed or not, a userland or
> networked filesystem implementation could make a file listing available
> that amounted to *installable* firmware rather than to *installed*
> firmware, and then, once the kernel asks for a file, proceed to install
> it, or ask the user to agree to have it installed.  This sort of
> kernel-directed request and installation is precisely what we wish to
> avoid, and there doesn't seem to be any way to avoid it, and it's not
> like the development of such an automated firmware installer is
> far-fetched: AFAIK it has been done through hotplug scripts.
> 
> -- 
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

- End forwarded message -

-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

Re: backup w/ duplicity borg attic bup?

[Alex Sassmannshausen]

Hello,

myglc2 writes:

> I am looking for a command line de-duplicating backup tool. I will be
> using it between GuixSD, Guix/GNU/Linux, and MacOS.
>
> Based on what I see in gnu/packages/backup.scm and in https://brew.sh,
> duplicity, borg and attic seem like they could be good choices.
>
> I am also intrigued by bup (https://github.com/bup/bup), for which we
> don't have a package (yet).
>
> I would like to avoid python, but all of the above seem to use it ;-(
>
> Does anyone out have suggestions?

I've gone through obnam, duplicity and am now using borg.  For various
reasons the former two ended up not working for my needs.  Suffice to
say borg is working great for me now.

HTH,

Alex

Re: Heads-up: transition to Guile 2.2

[Ludovic Courtès]

myglc2  skribis:

> g1@g1 ~/src/guix$ guix package -i icecat
> guix package: warning: Your Guix installation is 85 days old.
> guix package: warning: Consider running 'guix pull' followed by
> 'guix package -u' to get up-to-date packages and security updates.
> [...]
>
> But I just did a git pull ...
>
> g1@g1 ~/src/guix$ git -C ~/.config/guix/latest describe
> v0.12.0-3681-gbc0e6c931
>
> ... and my ~/.config/guix/latest points to it ...

This is a special setup.  The warning above just stats
~/.config/guix/latest.  For someone using ‘guix pull’, it’s a symlink
that’s updated each time ‘guix pull’ is invoked.

In your case it’s a symlink that’s never updated… but your warranty is
void anyway.  ;-)

Ludo’.

Re: Recent change in 'guix package --search-paths' behavior?

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Chris Marusich  skribis:
>>
>>> Hi,
>>>
>>> The manual says ((guix) Invoking guix package):
>>>
>>>  This option can also be used to compute the _combined_ search paths
>>>  of several profiles.  Consider this example:
>>>
>>>   $ guix package -p foo -i guile
>>>   $ guix package -p bar -i guile-json
>>>   $ guix package -p foo -p bar --search-paths
>>>
>>>  The last command above reports about the ‘GUILE_LOAD_PATH’
>>>  variable, even though, taken individually, neither ‘foo’ nor ‘bar’
>>>  would lead to that recommendation.
>>
>> [...]
>>
>>> Is the documentation wrong, or is this a regression?
>>
>> Try with “guile2.2-json” instead of “guile-json”.
>>
>> Ludo’.
>
> As usual, you're right!  :-)  That worked:

[...]

> Why does 'guix' resolve to guile@2.2.2, but 'guile-json' resolves to
> guile-json@0.6.0?

It’s because we’re not done with the transition:

  https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00436.html

The idea is to incrementally rename all “guile2.2-foo” packages to
“guile-foo”, and, when needed, keep an extra “guile2.0-foo”.  For
guile-json this hasn’t been done yet, but now’s probably a good time to
do it.

> Is it because, as mentioned in the comments in procedure
> 'find-newest-available-packages' in gnu/packages.scm, "the preferred
> package is whichever one was found last by 'fold-packages'"?
>
> I've attached a patch for the documentation which might help clarify
> this for anyone who has the same question in the future.  What do you
> think?  Too much detail for an edge case, or a useful footnote?

I would rather not add more text to it because the example will become
valid again soonish, and the extra text might muddy waters.

WDYT?

Thanks,
Ludo’.

Re: store reference detection (was Re: JARs and reference scanning)

[Chris Marusich]

Hi Ricardo,

Ricardo Wurmus  writes:

> Chris Marusich  writes:
>
>> There are probably many ways to accomplish that.  For example, in Java,
>> perhaps we could implement a custom classloader.  Or maybe we could
>> patch the built-in class loading mechanism [1].  Similarly, in Python
>> there are also ways to customize the import mechanism [2].  Perhaps Perl
>> also has a similar mechanism?
>
> Jar files can be told to import classes from another Jar by adding it to
> the “Class-Path” field of the Jar’s manifest.
>
> Here’s an example:
> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html

I didn't know this!  That's awesome; it might be just what we need.

> I don’t know if this mechanism permits the use of absolute paths, but
> it’s worth a try.  I should note that this doesn’t help with store
> reference detection, because the manifest will be part of the compressed
> Jar.  But if this works we could avoid propagation for Java packages.

Preliminary testing shows that this does in fact work.  See the attached
tarball; when you run "make" on its extracted contents, you can verify
for yourself that it works (don't forget to do 'guix -i icedtea:jdk'):

--8<---cut here---start->8---
[0] marusich@garuda:~
$ java -cp /tmp/embed-absolute-classpath-in-jar/Main.jar Main
Hello world!
[0] marusich@garuda:~
$ jar -tvf /tmp/embed-absolute-classpath-in-jar/Main.jar
 0 Thu May 11 01:35:26 PDT 2017 META-INF/
   131 Thu May 11 01:35:26 PDT 2017 META-INF/MANIFEST.MF
   309 Thu May 11 01:35:26 PDT 2017 Main.class
[0] marusich@garuda:~
$ jar -tvf /tmp/embed-absolute-classpath-in-jar/Greeter.jar
 0 Thu May 11 01:35:28 PDT 2017 META-INF/
69 Thu May 11 01:35:28 PDT 2017 META-INF/MANIFEST.MF
   396 Thu May 11 01:35:26 PDT 2017 Greeter.class
[0] marusich@garuda:~
$ grep /tmp/embed-absolute-classpath-in-jar 
/tmp/embed-absolute-classpath-in-jar/*
Binary file /tmp/embed-absolute-classpath-in-jar/Main.jar matches
/tmp/embed-absolute-classpath-in-jar/Main.txt:Class-Path: 
/tmp/embed-absolute-classpath-in-jar/Greeter.jar
[0] marusich@garuda:~
$ strings /tmp/embed-absolute-classpath-in-jar/Main.jar | grep 
/tmp/embed-absolute-classpath-in-jar
Class-Path: /tmp/embed-absolute-classpath-in-jar/Greeter.jar
[0] marusich@garuda:~
$ 
--8<---cut here---end--->8---

Based on this test, it looks like we can embed absolute paths in
uncompressed JAR files.  This is great!  It means that if we can package
Java libraries in this way, we won't need to propagate inputs for Java
libraries (because Java will find the classes via the embedded
Class-Path values), and the usual reference scanning mechanism will just
work (because the JAR files are not compressed).

I don't know what limits there are on the number of entries one can put
into the Class-Path line, but hopefully that won't be an issue.

-- 
Chris


embed-absolute-classpath-in-jar.tar.xz
Description: Binary data


signature.asc
Description: PGP signature

Re: Recent change in 'guix package --search-paths' behavior?

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Hi Chris,
>
> Chris Marusich  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Chris Marusich  skribis:
>>>
 Hi,

 The manual says ((guix) Invoking guix package):

  This option can also be used to compute the _combined_ search paths
  of several profiles.  Consider this example:

   $ guix package -p foo -i guile
   $ guix package -p bar -i guile-json
   $ guix package -p foo -p bar --search-paths

  The last command above reports about the ‘GUILE_LOAD_PATH’
  variable, even though, taken individually, neither ‘foo’ nor ‘bar’
  would lead to that recommendation.
>>>
>>> [...]
>>>
 Is the documentation wrong, or is this a regression?
>>>
>>> Try with “guile2.2-json” instead of “guile-json”.
>>>
>>> Ludo’.
>>
>> As usual, you're right!  :-)  That worked:
>
> [...]
>
>> Why does 'guix' resolve to guile@2.2.2, but 'guile-json' resolves to
>> guile-json@0.6.0?
>
> It’s because we’re not done with the transition:
>
>   https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00436.html
>
> The idea is to incrementally rename all “guile2.2-foo” packages to
> “guile-foo”, and, when needed, keep an extra “guile2.0-foo”.  For
> guile-json this hasn’t been done yet, but now’s probably a good time to
> do it.
>
>> Is it because, as mentioned in the comments in procedure
>> 'find-newest-available-packages' in gnu/packages.scm, "the preferred
>> package is whichever one was found last by 'fold-packages'"?
>>
>> I've attached a patch for the documentation which might help clarify
>> this for anyone who has the same question in the future.  What do you
>> think?  Too much detail for an edge case, or a useful footnote?
>
> I would rather not add more text to it because the example will become
> valid again soonish, and the extra text might muddy waters.
>
> WDYT?

Yes, I agree - we don't need to explain this temporary edge case.

-- 
Chris


signature.asc
Description: PGP signature

narinfo/nar mismatch on nginx caches

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

> On 07/05/2017 11:36, Ludovic Courtès wrote:
>
>>> guix pull: error: build failed: some substitutes for the outputs of 
>>> derivation 
>>> `/gnu/store/d1qkv7x8ayi75qjlg7d5j5g1h7y4fl5p-make-boot0-4.2.1.drv' failed 
>>> (usually happens due to networking issues); try `--fallback' to build 
>>> derivation from source
>>
>> I fixed it yesterday, let me know how that goes.
>
> There seems to be a reservoir of similar bugs.

Looks like it.  :-/  The hope with the new ‘guix publish --cache’ is
that these issues will vanish over time; the 404s that were reported are
for older store items for which we still had old entries in cache.

> Here is the one I just ran into:
>
> hash mismatch in downloaded path
> `/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.12': expected
> aea4335a5e6d65a36ed74561b15f8242773c49110be30d8ab7b43590f0568e60, got
> 49b3fc5b436309b4d097ed3c84946d5cab742db6159d76f5ad7a1d7896a2760f
> fetching path `/gnu/store/9761yfpvyr1fcpjhry8pgb3f0k6kj8n4-sed-4.2.2'...
> killing process 3685
> guix pull: error: build failed: some substitutes for the outputs of
> derivation
> `/gnu/store/wn2068qzbyh1v64dxxwbfjik7cjq0sji-python-2.7.12.drv' failed
> (usually happens due to networking issues); try `--fallback' to build
> derivation from source

This hash mismatch is a different story: this package did not build
deterministically, caches have kept the data (the nar) but they have
updated the meta-data (narinfo), which now advertises a different hash.
IOW, the cached data no longer matches the meta-data.

If we were not running nginx caches in front of ‘guix publish --cache’,
we would not have these problems.  However, we need those caches to
distribute the load.

Long-term the best option of course is to have all packages be
bit-reproducible, but until we get there, I’m not sure how to address
it.  Thoughts anyone?

Thanks for your report,
Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

l...@gnu.org (Ludovic Courtès) skribis:

> It’s time to plan for the next release!  Here’s what we maintainers
> think should be done for the next release, which would hopefully happen
> within less than a month:
>
>1. ‘core-updates’ merged.  We’re almost there!
>
>2. ‘wip-installer’ retested, and probably merged.
>
>   I think the prerequisite for it would be to do some more testing.
>   Last time people reported glitches here and there but John has
>   done quite a bit of work since then.  John: what about doing
>   another round of tests?
>
>   In the installation image, we should probably make the installer
>   optional and mark it as “beta” or something like that.  That will
>   leave us time to iron out remaining issues, and will avoid having
>   people expect a rock-solid Debian-style installer.
>
>   As far as review is concerned, we can probably do a quick and
>   lightweight review process since that’s quite a big chunk of code
>   and we don’t want the branch to block indefinitely.  So we can do
>   that quick process, and then incrementally improve it if needed.
>   I think it’s a reasonable approach given that the installer is
>   mostly an independent component.
>
>   John, everyone: thoughts?
>
>3. UEFI support documented and possibly improved.
>
>   We can certainly document the UEFI setup and add the /boot/efi
>   partition in some of the ‘operating-system’ examples.
>
>   The more difficult part is the installation: do we need to make a
>   second, UEFI-specific, installation image?  When I installed
>   GuixSD on UEFI, I booted our installation image as “legacy”, but
>   then GRUB would default to a legacy install, not a UEFI install:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>
>   I’m not sure exactly what needs to be done.  Thoughts?
>
>4. Fix low-hanging fruits at ; your help
>   welcome!
>
> Please share your thoughts!

With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
should we aim for next week (like Wed. 17th)?  Can we focus on polishing
the remaining bits and testing?

If the schedule turns out to be too tight, we could move to the week
after.

Thoughts?

Ludo’.

New template for 'guix' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/guix-0.13.0.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://www.fdn.fr/~lcourtes/tmp/guix-0.13.0tp.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New template for 'guix-packages' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix-packages' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/guix-packages-0.13.0.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://www.fdn.fr/~lcourtes/tmp/guix-0.13.0tp.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: store reference detection (was Re: JARs and reference scanning)

[Ricardo Wurmus]

Chris Marusich  writes:

>> Jar files can be told to import classes from another Jar by adding it to
>> the “Class-Path” field of the Jar’s manifest.
>>
>> Here’s an example:
>> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html
>
> I didn't know this!  That's awesome; it might be just what we need.
[…]

Thanks for testing this!

One limitation appears to be that this only works for applications, not
for libraries.  This could be a problem for us.  We don’t really need
this urgently for applications if we automatically generate shell
wrappers (as we do for Python executables).

It would be interesting to know if this could be used for libraries as
well, so that the application in the end does not need to know about all
transitive dependencies, but only its first-level dependencies.

--
Ricardo

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

Re: Heads-up: transition to Guile 2.2

[myglc2]

On 05/11/2017 at 10:29 Ludovic Courtès writes:

> myglc2  skribis:
>
>> g1@g1 ~/src/guix$ guix package -i icecat
>> guix package: warning: Your Guix installation is 85 days old.
>> guix package: warning: Consider running 'guix pull' followed by
>> 'guix package -u' to get up-to-date packages and security updates.
>> [...]
>>
>> But I just did a git pull ...
>>
>> g1@g1 ~/src/guix$ git -C ~/.config/guix/latest describe
>> v0.12.0-3681-gbc0e6c931
>>
>> ... and my ~/.config/guix/latest points to it ...
>
> This is a special setup.  The warning above just stats
> ~/.config/guix/latest.  For someone using ‘guix pull’, it’s a symlink
> that’s updated each time ‘guix pull’ is invoked.
>
> In your case it’s a symlink that’s never updated… but your warranty is
> void anyway.  ;-)
>
> Ludo’.

Oh! Thanks! I can force a new symlink each time I re-make guix.

Maybe this is a situation where it would be beneficial to embed a
date. ISTM a canonical date can be determined for any guix version so it
would not lead to un-reproducibility. And it would be a nice gift to
researchers doing an archelogical dig 1000 years from now ;-)

Re: backup w/ duplicity borg attic bup?

[André]

I've been using borg recently, and it has been doing it's job well so far.

There's a very useful comment on Reddit about backup solutions that I
found very helpful some time ago:

https://www.reddit.com/r/linux/comments/42feqz/i_asked_here_for_the_optimal_backup_solution_and/czbeuby/

Re: Heads-up: transition to Guile 2.2

[Vincent Legoll]

> This is a special setup.  The warning above just stats
> ~/.config/guix/latest.  For someone using ‘guix pull’, it’s a symlink
> that’s updated each time ‘guix pull’ is invoked.

Would there be a downside to stating the pointed-to file rather than
the link itself ?

-- 
Vincent Legoll

Re: Distributing substitutes over GNUnet

[Maxim Cournoyer]

Hi,

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Maxim Cournoyer  skribis:
>
>> I think what I meant was "integration of GNUnet with guix publish".
>> Something which would allow anyone to effortlessly share what's been
>> built on their machine with the other Guix users. A zero config kind
>> of thing, with auto discovery of peers and available substitutes.
>
> Sure, I agree this is a worthwhile goal.  If you haven’t already, check
> out the GSoC by Rémy Birot-Delrue on this topic a couple of years ago:
>
>   https://gnu.org/software/guix/news/gsoc-update.html
>
> Rémy ended up with Guile bindings for GNUnet, along with a
> proof-of-concept publish and substitute process using GNUnet:
>
>   https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00455.html
>
> I know ng0 is very interested in this as well.  I’d love to work in this
> area!
>
> Ludo’.

This is a very interesting idea indeed! Thank you for the pointers. I've
taken a quick look at the  code Rémy created in 2015. I wonder if it's
still working. Looks like there are a some tests, so that's good! I'll have to 
try it!

Maxim


signature.asc
Description: PGP signature

Re: Debugging info unavailability

[ng0]

Maxim Cournoyer transcribed 4.2K bytes:
> Hello ng0,
> 
> Sorry for the delayed reply!
> 
> ng0  writes:
> 
> > Maxim Cournoyer transcribed 1.0K bytes:
> > …
> >> >> What good is a substitute server if it doesn't hold the stuff I need
> >> >> *now*? :) On the other side, it really makes me want to look at GNUnet,
> >> >> which seems like the better long term solution.
> >> >
> >> > Though GNUnet doesn’t solve the fact that one needs a lot of CPU and
> >> > storage to build and store all this.  :-)
> >> >
> >> 
> >> I think what I meant was "integration of GNUnet with guix publish".
> >> Something which would allow anyone to effortlessly share what's been
> >> built on their machine with the other Guix users. A zero config kind
> >> of thing, with auto discovery of peers and available substitutes.
> >> 
> >> I haven't researched much about GNUnet yet, but it seems it might be
> >> fit for that purpose.
> >> 
> >> Maxim
> >> 
> >
> > This has been addressed between 2013? and late 2015, and I'm about to 
> > document my own
> > discussions, thoughts, and roadmap for this (gathered in the last 2 years).
> > In the sense of freedom of choice, I'd rather make this an opt-in (contrary 
> > to what
> > my own position in discussions was before) so that I can make pragmaOS use 
> > this and
> > those who would like to use it too.
> > The main roadblocker is 5 weeks - 5 months until a new GNUnet release, but 
> > there's
> > some tasks to work on which can be quickly updated once we have released 
> > GNUnet 0.11
> > or which version number is decided upon.
> > If you are interested, I can CC you in the message update when I have 
> > documented
> > the ideas (though they are 90% identical to the outcomes of the GSoC 
> > discussions
> > of the past, thought about without knowing it has been discussed
> > before).
> 
> Count me in. I'd like to learn more about GNUnet and any design
> ideas/known issues there might be to integrate 'guix publish' with it.

This week applications for university started, so I will transfer the
documentation when I have more time. Probably within the next weeks.

> > My basic idea without going too much into depth (I don't want to search my 
> > papers):
> >
> > - following the ideas of pragmaOS, to first make GNUnet as easy as
> >   possible to use and configure (the system service I'm working on)
> 
> Shouldn't deploying GNUnet on Guix be as easy as adding a service to the
> system declaration (and maybe tweeking a few parameters) ?

For just the system service, yes. But I want to make the most out of
shepherd and include every possible option which can be later extended
to have example or services documented for configuring the gnunet-vpn, etc
(actually the system-service part is only a small part of improving
the usability).

> > - update the gnunet-guile bindings for HEAD of gnunet but work with 0.10.1 
> > for the
> >   current version of the service
> [...]
> > I know from the meeting december of last year that Ludovic is sceptic about
> > GNUnet by now to some degree, and if I could decide on releases GNUnet 
> > would now
> > have an -dev or -preview or whatever release. The amount of bugfixes which 
> > happened
> > since 0.10.1 are just too much to keep 0.10.1 around, especially since the 
> > compability
> > no longer works between nodes running 0.10.1 and ones running HEAD.
> >
> 
> Is backward compatiblity absolutely necessary, given that this version
> has its share of problems and is fragmenting the network. I'd rather put
> efforts on making GNUnet 'next' working, and well.

There is no backwards compability. This extra step is just done because
in past discussions some of us in Guix insisted on an available release.
Given that we (at GNUnet) now explicitly recommend not to run 0.10.1,
and the only delay is 2 bugs which depend on Christian freeing up time
in the schedule between jobs, it's annoying that we can't use HEAD.

Anyway, for getting the service started it should work like this,
I'm just generally stuck on services and the help on services is
mostly try and run it until it could/should/would work… I don't expect
any help, but there's more help on packages then getting started with
services. It takes much longer.

> Also, why not packaging a GNUnet-next already in Guix? With only two
> bugs left to fix, it should already work rather well (maybe better?)
> compared to 0.10.1? Guix makes it easy to have multiple versions if we
> need -- let's make use of it!

Refer to Ludovic and others for the reasons why we don't have that.
In any case I have many different variants of gnunet in my public
package repository https://git.pragmatique.xyz/ng0-packages/log.html

I could test run the current HEAD with some of my definitions, but
I don't really want to waste my time on discussions about the why
and why not again. If you want it, it can be added very quickly.

> Maxim



-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

New French PO file for 'guix' (version 0.13.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the French team of translators.  The file is available at:

http://translationproject.org/latest/guix/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Heads-up: transition to Guile 2.2

[ng0]

With a normal setup this has lead to:

;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/scribus.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/scsi.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/sdcc.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/selinux.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/serveez.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/shellutils.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/simh.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/skarnet.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/skribilo.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/smalltalk.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/stalonetray.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/sync.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/syndication.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/synergy.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/task-management.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/tmux.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/tv.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/uml.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/unrtf.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/uucp.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/vtk.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/wdiff.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/web-browsers.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/wine.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
;;; WARNING: loading compiled file 
/home/ng0/.config/guix/latest/gnu/packages/xnee.go failed:
;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
guix pull: error: libtiff-CVE-2017-7593.patch: patch not found

in the user profile and normal working conditions in the root profile.

Recreating the account is no option and it is minimalistic, no build
software installed in profile.
-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

Re: font-build-system

[Arun Isaac]

ng0 writes:

> we have 20 - 25 fonts (I didn't really count), and only 2 are using a
>
> system* make args
>
> in their build phase, every other font just extracts, creates folders
> and copies the fonts to the folders.
> This is much repetition which could be avoided by just calling a build
> system, rather than applying changes to fonts over and over again.
>
> It looks like this can be achieved by something as small as the emacs
> build-system. Would anyone give it a try?

Is anybody working on this? I'd like to give this a shot, if nobody else
is working on it already.

Re: Heads-up: transition to Guile 2.2

[Adonay Felipe Nogueira]

Thanks! This also fixes the problem for me. :)

Re: Heads-up: transition to Guile 2.2

[Ludovic Courtès]

Vincent Legoll  skribis:

>> This is a special setup.  The warning above just stats
>> ~/.config/guix/latest.  For someone using ‘guix pull’, it’s a symlink
>> that’s updated each time ‘guix pull’ is invoked.
>
> Would there be a downside to stating the pointed-to file rather than
> the link itself ?

I can already tell you that the mtime of the symlink target is 1.
:-)

Ludo’.

Re: Debugging info unavailability

[Ludovic Courtès]

ng0  skribis:

> Maxim Cournoyer transcribed 4.2K bytes:

[...]

>> Also, why not packaging a GNUnet-next already in Guix? With only two
>> bugs left to fix, it should already work rather well (maybe better?)
>> compared to 0.10.1? Guix makes it easy to have multiple versions if we
>> need -- let's make use of it!
>
> Refer to Ludovic and others for the reasons why we don't have that.

Hi!  :-) At the time we discussed it I was reluctant to adding a GNUnet
snapshot as a package because (1) we have the general rule¹ to package
only releases, and (2) when we violate the rule anyway ;-), we need to
be confident that we’re doing the right thing, such as picking the right
commit.

#2 is hard unless you’re also an upstream developer of the software in
question.  For example we wouldn’t want to have Guix users run a version
of GNUnet that uses a protocol compatible neither with the old nor with
the next version.

So I would urge you to lobby on the gnunet-developers list until we get
a shiny new release.  :-)

Ludo’.

¹ https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html

font-build-system vs fc-cache profile hook

[Danny Milosavljevic]

Hi Arun,
Hi ng0,

On Thu, 11 May 2017 20:15:00 +
ng0  wrote:

> I don't think anyone is working on a font-build-system. But this won't
> solve the fc-cache problem as the reply by Mark suggests.

I agree, it won't.

For that, one could merge-install the fonts in a well-known location (that 
already happens) and then add a profile hook to guix/profiles.scm 
(%default-profile-hooks).

But there's already a "fonts-dir-file" hook there - which was recently extended 
to actually traverse all the font dirs and invoke mkfontscale, mkfontdir in 
them.

So for fixing the font problem it would first require someone to find out what 
exactly is missing.  What does fc-cache do that mkfontdir and mkfontscale 
don't?  Is it necessary to invoke all three?  Then we could just invoke all 
three in the fonts-dir-file hook (or invoke fc-cache in a new hook?).

Note that fc-cache needs to be invoked once per architecture, so it isn't quite 
as straightforward as it would seem (for example on x86, you'd potentially have 
to run it once for x86_64 and once for i386 - which means you'd have to find 
out which architectures are used in the profile).

You can pass a list of "interesting" directories as command-line parameters to 
fc-cache.

fc-cache supports both user caches and system caches.  You'd have to find out 
which of those is more appropriate.  Probably the system cache?  So invoke 
fc-cache "--system-only" ?

Also, can fc-cache handle the Guix timestamp-less directories?  If not, it 
would have to be invoked with "--force" "--really-force" (the latter makes it 
unlink existing cache files, the former prevents it from trying to load cache 
files afterwards).  Would that be slow?

One cache dir is specified when building fontconfig, called FC_CACHEDIR, which 
can be specified when invoking configure: "--with-cache-dir=DIR" (defaults to 
LOCALSTATEDIR/cache/fontconfig).  The Guix package for fontconfig overrides it 
to be /var/cache/fontconfig and I have a lot of files in there (I'm a GuixSD 
user).

Not sure whether that's good.  Why not put the cache into the profile and have 
an environment variable point there?  Just using "/var" sounds unsafe for 
non-GuixSD users... what if the foreign operating system has incompatible files 
there?  Also, reproducibility?

On the other hand, user cachedirs are in the directory specified by environment 
variable XDG_CACHE_HOME.

Each cache corresponds to a list of font directories - which are found by 
appending sysroot and an entry in the cache body.  If sysroot is not set, just 
the entry in the cache body is used.  I think the former is because the cache 
filename is a MD5SUM of the font directory name - which can lead to hash 
collisions.  But later on, FcDirCacheUnlink just unlinks the cache of each 
directory specified (on really-force, for example) - so if you specify just one 
of the directories that would cause a collision it will silently invalidate the 
other one too (which you didn't specify). :P

What are these cache files caching in the first place?  Don't mkfontdir and 
mkfontscale already cache font family, variant etc?

Also, reading the Arch bugtracker, if not running fc-cache, fontconfig is 
supposed to generate the cache into the user directory automatically when 
invoking an application that needs fontconfig fonts.  Not sure how it can 
happen for them to be broken...

In any case, invoking fc-cache --system-only can't hurt I guess.

But first it would be good to strace some application with broken fonts and see 
what it's trying to open that fails.

Re: GuixSD bootable ISO-9669 image

[Danny Milosavljevic]

Hi Ludo,

>I’d prefer to add a special ‘iso-9660-uuid’ form similar to ‘uuid’ in (gnu 
>system file-systems).
> That way we could detect that we get a valid UUID at macro-expansion
> time or system-instantiation time, rather than end up with an error at
> boot time.

Hmm, I've never seen that macro before.  Should it be used in config.scm ?

Right now config.scm could have:

  (file-systems (cons* (file-system
(device "1234-5678-")
(title 'uuid)
(mount-point "/")
(type "ext4")
(needed-for-boot? #t))

Which kind of UUID is it then?  Should string->uuid try to be clever about it?  
Or a new function string->uuid-like ?

find-partition-by-uuid right now uses read-partition-uuid and then uses 
bytevector=?.

So all these forms should continue to be bytevectors.  Then it would work fine 
without lots of changes.

So something like this?

- Add "string->uuid-like" and use it in canonical-title (instead of using 
"string->uuid").
- string->uuid-like would have a case analysis by some weird markers, then 
parse the uuid using the right parser into a bytevector with length 
typical-for-this-filesystem-but-not-unique.
- Modify uuid->string to have a case analysis by the bytevector length, then 
print the uuid using the right printer into a string 
typical-for-this-filesystem.  This will fail to detect ISO9660 correctly 
because these are the same length as real uuids (Linux uses 16 bytes of the 
17-byte iso9660-uuid)
- Leave the uuid macro as-is since it should already do the right thing then?
- Add a new macro fat32-uuid, and a new macro iso9660-uuid.

String lengths:
- FAT32 UUID-string: 3 Byte to 9 Byte (variable-length numerals.  Is that 
actually how Linux writes them?  I misplaced my USB stick... where is it? 
*mumbles*)
- ISO9660 UUID-string: 16 Byte (fixed-length numerals).  That's the same length 
as the ISO9660 bytevector since it's actually the same content
- Real UUID-string: 36 Byte

Bytevector lengths (right now):
- FAT32 UUID: 4 Byte
- ISO9660 UUID: 16 Byte (oops...)
- Real UUID: 16 Byte

Re: ‘guix pull’ vs. transition to Guile 2.2

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> As of commit 608e42e7c92114497e7908980424288079acee1e, Guix builds with
>> Guile 2.2 (to be released sometime within the next 24 hours) and the
>> whole test suite passes.
>>
>> All the dependencies of Guix except Guile-SSH (optional; use for
>> offloading and for ‘guix copy’) are already compatible with Guile 2.2.
>
> With the attached patch, the ‘guix’ package is built against Guile 2.2.
> I’m running it on my GuixSD machine, and it works like a charm!
>
> There’s a problem though, called “guix pull”.  ~/.config/guix/latest
> currently contains 2.0 .go files.  Thus after reconfiguring GuixSD to
> use Guix-for-2.2, running ‘guix’ typically gives loads of warnings like:
>
>   ;;; WARNING: loading compiled file
> /home/ludo/.config/guix/latest/guix/derivations.go failed:
>   ;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
>
> The fix is for ‘guix pull’ to build with Guile 2.2 when that’s what
> we’re running.  For that, build-self.scm must be sure it can get the
> ‘guile2.2-ssh’ package when we’re on 2.2, or it will fail to compile the
> new Guix.  However, ‘guile2.2-ssh’ appeared a day ago, so it’s missing
> from most installations…
>
> In short, ‘guix pull’ is broken in a way that may practically prevent it
> from handling the 2.0-to-2.2 transition.  The risk is that ‘guix pull’
> will fail to upgrade, preventing users from upgrading Guix altogether.
> To work around that, people will have to use a Git checkout of Guix.  Of
> course that’s what many of us already do, but still.
>
> Maybe the upcoming release is a good time to make that transition: at
> least people installing GuixSD or Guix from that release will already be
> on 2.2 and won’t have problems from there on.
>
> Thoughts? Ideas?
>
> We all know it, but it’s really really time to fix ‘guix pull’…

For what it's worth, I ran guix pull on my GuixSD machine today (as root
and as my normal user).  Everything seems to work just fine.  I'm
currently running 'guix system reconfigure', but since substitutes
aren't available, it's building a lot of stuff from source, so who knows
how long it'll take.  I'll let you know if I encounter any problems.

I've also run guix pull (again, as root and also as my normal user) on
my Ubuntu machine, and again everything seems fine.

So far so good! :-)

-- 
Chris


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello Guix!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> It’s time to plan for the next release!  Here’s what we maintainers
>> think should be done for the next release, which would hopefully happen
>> within less than a month:
>>
>>1. ‘core-updates’ merged.  We’re almost there!
>>
>>2. ‘wip-installer’ retested, and probably merged.
>>
>>   I think the prerequisite for it would be to do some more testing.
>>   Last time people reported glitches here and there but John has
>>   done quite a bit of work since then.  John: what about doing
>>   another round of tests?
>>
>>   In the installation image, we should probably make the installer
>>   optional and mark it as “beta” or something like that.  That will
>>   leave us time to iron out remaining issues, and will avoid having
>>   people expect a rock-solid Debian-style installer.
>>
>>   As far as review is concerned, we can probably do a quick and
>>   lightweight review process since that’s quite a big chunk of code
>>   and we don’t want the branch to block indefinitely.  So we can do
>>   that quick process, and then incrementally improve it if needed.
>>   I think it’s a reasonable approach given that the installer is
>>   mostly an independent component.
>>
>>   John, everyone: thoughts?
>>
>>3. UEFI support documented and possibly improved.
>>
>>   We can certainly document the UEFI setup and add the /boot/efi
>>   partition in some of the ‘operating-system’ examples.
>>
>>   The more difficult part is the installation: do we need to make a
>>   second, UEFI-specific, installation image?  When I installed
>>   GuixSD on UEFI, I booted our installation image as “legacy”, but
>>   then GRUB would default to a legacy install, not a UEFI install:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>>
>>   I’m not sure exactly what needs to be done.  Thoughts?
>>
>>4. Fix low-hanging fruits at ; your help
>>   welcome!
>>
>> Please share your thoughts!
>
> With UEFI (almost) ready, Guile 2.2 in the house, and “make release”,
> should we aim for next week (like Wed. 17th)?  Can we focus on polishing
> the remaining bits and testing?
>
> If the schedule turns out to be too tight, we could move to the week
> after.

I’d like to merge wip-installer, but not start it by default.  It would
be a shame to see the branch bit-rot.

We also need to fix the glibc on hurd (the patch for i686 should not be
applied there), but I haven’t been able to reproduce the failure on
hydra.  https://hydra.gnu.org/build/2036383/nixlog/1/raw

What do you think?

--
Ricardo

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

Re: about this linux-libre 'bug' [Fwd: Re: question about a bug mention in an interview back in 2013]

[Ricardo Wurmus]

ng0  writes:

> I think this could be useful for extending the documentation
> by explaining the limitations of linux-libre in case we
> don't already do it in an easy language.

I don’t think the Guix documentation is the right place for this, but if
you want to add it please prepare a patch.  Otherwise this probably
won’t happen.

-- 
Ricardo

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

Re: systemd on debian8, a possible solution

[Ricardo Wurmus]

Hi ng0,

> could we point out the solution redhat had in this case?
>
> root@sharknado9000:~# systemctl enable guix-daemon
> Failed to execute operation: No such file or directory

I’m missing context here.  If this is a bug then please report it to
bug-g...@gnu.org.  Otherwise it will get lost amidst unrelated
discussions on guix-devel.

--
Ricardo

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

Re: store reference detection (was Re: JARs and reference scanning)

[Mark H Weaver]

Hartmut Goebel  writes:

> Am 02.05.2017 um 14:43 schrieb Ludovic Courtès:
>> Hartmut Goebel  skribis:
>>
>>> Am 27.04.2017 um 15:46 schrieb Ludovic Courtès:
 ‘propagated-inputs’ is one way to manually specify run-time references.
 It works at the package level and not at the store level—that is, the
 store item’s references are unaffected by what ‘propagated-inputs’
 contains.  It’s usually enough for our purposes though.
>>> I'm not sure if 'propagated-inputs' are enough. For example
>>> "python-passlib" as propagated-input python-py-bcrypt, but the later
>>> does not show up as reference, requisite nor referrer:
>> Right, that’s what I meant by “not at the store level” above.
>>
>> Ludo’.
>  So I propose to add a small text file ".guix-dependencies' to all
> language's packages which do not add some kind of references themselves:
> Python, Perl, Java, etc.

I have thought of doing this in the past, but there's another more
difficult problem that would also need to be solved: how to make
grafting work for these non-plaintext references.  If grafting doesn't
work, there's a good chance that software with known security flaws will
continue to be executed.

   Mark

Re: store reference detection (was Re: JARs and reference scanning)

[Chris Marusich]

Ricardo Wurmus  writes:

> Chris Marusich  writes:
>
>>> Jar files can be told to import classes from another Jar by adding it to
>>> the “Class-Path” field of the Jar’s manifest.
>>>
>>> Here’s an example:
>>> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html
>>
>> I didn't know this!  That's awesome; it might be just what we need.
> […]
>
> Thanks for testing this!
>
> One limitation appears to be that this only works for applications, not
> for libraries.

In what way does this not work for libraries?  I'm not criticizing you;
I'm genuinely curious.  To ask this question another way: how would a
solution that "works for libraries" behave, exactly?  I'm not sure what
the phrase "it works for libraries" might mean, since I suspect its
meaning varies depending on what one is trying to accomplish.

> This could be a problem for us.  We don’t really need this urgently
> for applications if we automatically generate shell wrappers (as we do
> for Python executables).
>

I agree.

> It would be interesting to know if this could be used for libraries as
> well, so that the application in the end does not need to know about all
> transitive dependencies, but only its first-level dependencies.

I think there are at least two concrete goals here.  I would phrase them
as follows:

1) I can run Java applications (built with Guix).

2) I can use Java libraries (built with Guix) in an IDE to develop Java
   applications.

We can accomplish (1) by using wrapper scripts.  I suppose we could also
maybe accomplish (1) by using JARs with embedded classpaths, but as long
as wrapper scripts are sufficient, it isn't really necessary to do this.
As for (2), I think it's probably trickier, since the exact way in which
an IDE might want to be informed about the dependencies of a project may
vary.  I'm still not sure how I would develop Java applications using
Java libraries built with Guix, without putting in a lot of manual
effort to tell my IDE where the dependencies live.  Surely there is a
way...

-- 
Chris


signature.asc
Description: PGP signature