Re: Mitigating "dependency confusion" attacks on Guix users

[Christopher Baines]

Ryan Prior  writes:

> However, I'm still thinking about how to attack Guix users. Somebody who
> adds an internal channel for their own packages could still be
> vulnerable to a dependency confusion attack via a compromised or
> manipulated Guix maintainer. The target of the attack could install
> packages they believed would be provided by their internal channel but
> actually get another package provided upstream.
>
> The degree of vulnerability increases further with each channel used,
> with each channel maintainer becoming another potential vector of
> compromise. How can we make this kind of attack even more difficult?
>
> What comes to my mind is that we should encourage (require?) people to
> specify the channel name a package belongs to, if it's not the "guix"
> channel. So instead of referring to "python-beautifulsoup4" (ambiguous:
> is this from my channel or upstream Guix?) we say that "python-
> beautifulsoup4" always means that package from the "guix" channel and a
> version provided by my channel called "internal" needs to be called for
> explicitly, like "@internal/python-beautifulsoup4".

I'm not sure you can escape trusting the collection of channels you're
using. Because channels are code that's expected to interact, I'm not
sure it's easy to target a single package from a specific channel, and
expect that this provides some security. A malicious channel could
simply reach out and modify the state in modules from a different
channel, which would circumvent the protection you're suggesting.


signature.asc
Description: PGP signature

Re: Mitigating "dependency confusion" attacks on Guix users

[Lars-Dominik Braun]

Hi,

very interesting read.

> However, I'm still thinking about how to attack Guix users. Somebody who
> adds an internal channel for their own packages could still be
> vulnerable to a dependency confusion attack via a compromised or
> manipulated Guix maintainer. The target of the attack could install
> packages they believed would be provided by their internal channel but
> actually get another package provided upstream.
Usually you’d use module imports and variable names inside your
channel’s packages. Wouldn’t that defeat this attack? (Depending on
Guix’/Guile’s module loading order of course.)

What about substitute servers? As far as I understand as soon as they’re
authorized they can deliver substitutes for *any* package.

Lars

Re: ZFS on Guix

[raid5atemyhomework]

Hello Danny,

> I just wanted to say that I'm not ignoring your patch, I'm just not qualified
> to review it. I hope someone steps up to it--otherwise I can't really tell
> whether (mbegin %state-monad...) inside a random service procedure is a good
> idea.
>
> Then again, provenance-service-type does it and there it seems to be fine...


For ***this*** very specific case it is because of a random weirdness of 
`system-service-type`.

Specifically, the *value* of that service-type is an association list of 
filenames and their contained store values.  However, an ***extension*** of 
that service-type must be a monadic action that results in an association list 
of filename-contents.


Here is relevant code in `gnu/services`:

```scheme
(define (system-derivation entries mextensions)
  "Return as a monadic value the derivation of the 'system' directory
containing the given entries."
  (mlet %store-monad ((extensions (mapm/accumulate-builds identity
  mextensions)))
(lower-object
 (file-union "system"
 (append entries (concatenate extensions))

(define system-service-type
  ;; This is the ultimate service type, the root of the service DAG.  The
  ;; service of this type is extended by monadic name/item pairs.  These items
  ;; end up in the "system directory" as returned by
  ;; 'operating-system-derivation'.
  (service-type (name 'system)
(extensions '())
(compose identity)
(extend system-derivation)
(description
 "Build the operating system top-level directory, which in
turn refers to everything the operating system needs: its kernel, initrd,
system profile, boot script, and so on.")))
```

So *extensions* must be monads (due to `mapm/accumulate-builds` on the 
`mextensions`) but the raw value must be a simple non-monadic assoc list.

The patch moves some generated files ("kernel" and "hurd") from the value of 
the `system-service-type` to an extension of `system-service-type`, thus the 
extra `mbegin %store-monad`. It needs to be `%store-monad` since that is the 
monad used by the `system-derivation` function.

See:

```scheme
(define (kernel-builder-configuration->system-entry config)
  "Return the kernel and hurd entries of the 'system' directory."
  (mbegin %store-monad
#;...))
#;...
(define kernel-loadable-module-service-type
  (service-type (name 'kernel-loadable-modules)
(extensions
 (list (service-extension system-service-type
  
kernel-builder-configuration->system-entry))) ;; <-- OVER HERE
(compose concatenate)
(extend kernel-builder-configuration-add-modules)
(description
 "Register packages containing kernel-loadable modules and adds 
them+to the system.")))
```

So it is not just some "random service procedure", it is because that is the 
interface exposed by `system-service-type` for its extensions, extensions of 
`system-service-type` have to yield a monadic action.  `mbegin` is one of the 
simpler monadic actions.  It is also in the "correct place" as best as I can 
tell, since only service types in `gnu/services.scm` dare to extend 
`system-service-type`.

`provenance-service-type` does this as well because it *also* extends 
`system-service-type`.  This is basically done here simply because that is what 
`system-service-type` expects.

Thanks
raid5atemyhomework

Unexpected --export-manifest with simple transformations

[zimoun]

Hi,

If the transformations are in the manifest.scm file, then they are
lost.  For example, consider:

--8<---cut here---start->8---
$ guix package \
   -p /tmp/profile-cli \
   -i python python-numpy \
   hello --with-c-toolchain=hello=gcc-toolchain@10
guix package: warning: transformation 'with-c-toolchain' had no effect on 
python@3.8.2
guix package: warning: transformation 'with-c-toolchain' had no effect on 
python-numpy@1.17.3

[...]

$ guix package -p /tmp/profile-cli --export-manifest > /tmp/manifest.scm

$ cat /tmp/manifest.scm
;; This "manifest" file can be passed to 'guix package -m' to reproduce
;; the content of your profile.  This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(use-modules (guix transformations))

(define transform1
  (options->transformation
'((with-c-toolchain . "hello=gcc-toolchain@10"

(packages->manifest
  (list (transform1 (specification->package "hello"))
(specification->package "python-numpy")
(specification->package "python")))
--8<---cut here---end--->8---


So far, so good.  Then let use this manifest to create a profile.

   $ guix package -p /tmp/profile-exported -m /tmp/manifest.scm

and the issue is that ’/tmp/profile-exported/manifest’ does not contain
the transformation.  Other said:

--8<---cut here---start->8---
$ guix package -p /tmp/profile-exported --export-manifest
;; This "manifest" file can be passed to 'guix package -m' to reproduce
;; the content of your profile.  This is "symbolic": it only specifies
;; package names.  To reproduce the exact same profile, you also need to
;; capture the channels being used, as returned by "guix describe".
;; See the "Replicating Guix" section in the manual.

(specifications->manifest
  (list "hello" "python-numpy" "python"))
--8<---cut here---end--->8---


Note that obviously:

--8<---cut here---start->8---
$ ls -l /tmp/profile-{cli,exported}/bin/ | grep hello
lrwxrwxrwx 3 root root 64 Jan  1  1970 hello -> 
/gnu/store/qi7pqqsxhbwmy75hl43j7l0aw1xr7r42-hello-2.10/bin/hello
lrwxrwxrwx 3 root root 64 Jan  1  1970 hello -> 
/gnu/store/qi7pqqsxhbwmy75hl43j7l0aw1xr7r42-hello-2.10/bin/hello
--8<---cut here---end--->8---


Well, is it a bug or a feature? ;-)

>From my understanding, it makes sense to save the transformations from a
manifest.  But it is not clear what should be the good solution for
that because it is not easy; again from my understanding.


The obvious answer is: do not loose the manifest.scm file! :-) Sure, I
am working in the context where Alice produced a Docker image with “guix
pack -f docker --save-provenance -m manifest.scm” where manifest.scm
uses transformations.  Then since Alice is post-doc and goes doing other
stuff elsewhere, the source probably vanishes.  Bob wants to rebuild the
Docker image.  It is possible for simple case as I already illustrated
it. :-)

To be concrete, I am trying to write down a non-trivial example using a
custom package and a transformation for a blog post and/or Cookbook
recipe.


Cheers,
simon

Mitigating "dependency confusion" attacks on Guix users

[Ryan Prior]

Hi Guix! I've been digesting this piece, published hours ago, describing
dependency confusion attacks that revealed severe vulnerabilities at
many major organizations: https://medium.com/@alex.birsan/dependency-
confusion-4a5d60fec610

Guix users already have a few mitigations against this sort of attack.
Most importantly, no substitute servers or channels are installed by
default which allow arbitrary uploads by community contributors. That
feature of the affected public registries (npm, pypi, rubygems) is so
convenient, but contributes to this kind of attack. This is a great
motivation for people to move to Guix from those other package systems.

However, I'm still thinking about how to attack Guix users. Somebody who
adds an internal channel for their own packages could still be
vulnerable to a dependency confusion attack via a compromised or
manipulated Guix maintainer. The target of the attack could install
packages they believed would be provided by their internal channel but
actually get another package provided upstream.

The degree of vulnerability increases further with each channel used,
with each channel maintainer becoming another potential vector of
compromise. How can we make this kind of attack even more difficult?

What comes to my mind is that we should encourage (require?) people to
specify the channel name a package belongs to, if it's not the "guix"
channel. So instead of referring to "python-beautifulsoup4" (ambiguous:
is this from my channel or upstream Guix?) we say that "python-
beautifulsoup4" always means that package from the "guix" channel and a
version provided by my channel called "internal" needs to be called for
explicitly, like "@internal/python-beautifulsoup4".

Cheers,
Ryan

Re: Staging branch [substitute availability]

[Ricardo Wurmus]

Hi Mathieu,

sorry for missing this message (and all the others).
Leo pointed me to this message on IRC.  (Thanks!)

> The easier way to proceed could be to create a VPN for the remote build
> machines that are not on berlin local network. Wireguard could be a good
> candidate. That would mean that only one UDP port has to be opened on
> berlin.
>
> Ricardo, do you think that the sysadmins would agree to open traffic on
> UDP port 51820 for instance?

Yes, this should be okay.  Does this mean that we can get rid of all the
other ports that we previously requested?

If you’re sure that it should be UDP port 51820 for incoming connections
(and outgoing as well?) then I’ll submit the request.

Sorry again for the delay!  Feel free to ping me directly in the future.

-- 
Ricardo

Re: Guix Day: Notes from the CI session

[Leo Famulari]

On Mon, Feb 08, 2021 at 06:07:25PM +0100, Ludovic Courtès wrote:
> ## Open issue: branching strategy
> 
>   - currently: building all of `master` + the "core" of `core-updates`
>   - schedule
> - currently ad-hoc: volunteers get to choose when to freeze/merge
>   - actions
> - pushes to `core-updates` should cancel all pending builds on that 
> branch (see Guix Build Coordinator)
> - have a dashboard showing active branches, statuses (wild-west, frozen), 
> and merge deadlines
>   - could be implemented in Cuirass
>   - specs could have extra properties (such as "merge deadline") that 
> Cuirass would display
>   - or it could use status info from the Data Service, as in 
> https://data.guix-patches.cbaines.net/
> - naming convention: `core-updates-frozen` vs `core-updates`, etc.

So, does anyone want to change the naming conventions?

I like the idea of, in normal times, only pushing to "core-updates-next"
and "staging-next", and then freezing and building "core-updates" and
"staging".

Re: Guix Day: Notes from the CI session

[Leo Famulari]

On Mon, Feb 08, 2021 at 06:07:25PM +0100, Ludovic Courtès wrote:
> ## Open issue: new machines
> 
>   - fast ARM servers available
>   - criteria for hardware?
> - must run free system (stock Guix System)
>   - hosting?
> - the MDC (in Berlin) wouldn't host Guix-specific non-x86 servers
> - could rent space (currently renting space for bayfront.guix in 
> Bordeaux, France), but it's relatively costly
> - workstations could be in people's homes
>   - https://store.avantek.co.uk/ampere-altra-64bit-arm-workstation.html
> - (benchmark info: 
> https://www.phoronix.com/scan.php?page=article=ampere-altra-q80 - 
> compete with AMD Epyc 7nm 2nd Gen)
>   - 
> - small boards are unreliable or too slow
> - looking for volunteers to help
>   - pick hardware we could buy
>   - get in touch on `guix-devel` or `guix-sysadmin` (private) mailing 
> lists

I think the status quo of 64-bit ARM for us is untenable. The emulated
builds cause mass failures that can't be reproduced on real hardware.
There is a growing demand for this platform among hobbyists and hackers
who we could convert to Guix contributors!

Regarding hosting, I heard objections to spending significant amounts of
money on it. But, there was also an objection to hosting the machines in
people's homes. Do we know anyone who could donate some rackspace? Or
office-space, if we acquire workstations instead of servers?

As for the hardware itself, yes, it's expensive, but not any more than
what we'd pay for our x86_64 build farm (~1500 CPU cores and terabytes
of RAM). Again, do we know anyone who would donate some? Should we try
negotiating a discount with vendors?

I don't think that using hobbyist SBCs is viable.  It doesn't work for
our armhf platform. Not to mention, the most powerful ones available are
merely dual-core old Cortex-A72 design. For purchasing build farm
hardware, we should look for Cortex-A76, at least, if not Neoverse N1.
Hobbyist SBCs are designed for low-power consumption, not performance;
they are basically re-using SOCs designed for TV boxes and embedded
applications.

The Guix Build Coordinator in 2021

[Christopher Baines]

Hey!

Near the beginning of 2020, things changed such that I suddenly had some
time, and some of that time I spend putting idea's I'd had for a while
around building derivations, including across multiple machines, in to
practice [1].

1: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00323.html

Looking back now from 2021, I think it's been pretty successful.

In terms of building things for substitutes, the guix.cbaines.net [2]
site I setup for testing has generally had higher substitute
availability than ci.guix.gnu.org, at least for x86_64-linux, and this
is with far less compute resources.

2: http://guix.cbaines.net/

It's also allowed for massive leaps forward towards being able to
meaningfully test patches. Affected packages and system tests are now
being built, and the results of those builds are being sent to the
relevant Guix Data Service instance.

Up until recently, I've been trying to add more features. I've still got
more features in mind, but I also want to neaten up some things and pay
back some of the technical debt that's been accrued.

I've added a Roadmap section to the README file [3] if you're interested
in the specifics.

3: 
https://git.cbaines.net/guix/build-coordinator/about/#outline-container-orge5f01b3

Also, given that the Guix Build Coordinator is capably doing what it was
designed to do, there are problems that are now in a good position to
tackle. Things like trying to optimise substitute delivery over HTTP [4]
or otherwise, and making user interface improvements around
patchwork.cbaines.net [5] so that it's better at getting the right
information to the right people.

4: https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00104.html
5: https://patchwork.cbaines.net/

If you have any comments, questions, or are interested in getting
involved, please let me know!

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Discover GNU Guix eco-system with awesome-guix!

[zimoun]

On Tue, 9 Feb 2021 at 19:11, Bonface Munyoki K.  wrote:

> Also to add to what Léo mentioned, "awesome" lists
> are a quick way to get up to speed to some things;

Yeah, I thought it was the idea behind the Cookbook.  :-)
Well, the bottleneck with this (whatever the name ;-)) is recruiting
people who puts some love in.  Maybe what Léo is proposing fits better
the contribution workflow.

Now, I am thinking about that, give a look at:

  

Well, it is worth to add them and if someone volunteers, they need
some refresh. :-)

BTW, thanks for compiling curated materials.

Cheers,
simon

Re: Discover GNU Guix eco-system with awesome-guix!

[Bonface Munyoki K .]

zimoun  writes:

> Hi,
>
> On Tue, 9 Feb 2021 at 17:16, Léo Le Bouter  wrote:
>
>> Commonly awesome lists are used to share links to all things related to
>> some topic or some software. This lists's purpose is for anyone to be
>> able to easily get up to speed with what exists instead of having to
>> know each and every one to find out by word of mouth. It also helps
>> projects get more exposure that way.
>
> Thanks for the explanations.  I did not know.

Also to add to what Léo mentioned, "awesome" lists
are a quick way to get up to speed to some things;
and IMHO are a sort of "gateway drug" to some
things. As an example, "awesome-guile"
(https://notabug.org/ZelphirKaltstahl/awesome-guile/src/master/list.md)
has served me well to get resources that I'd
otherwise never find on my own.

It'd be nice to aggregate something similar for
GUIX.

PS: You find interesting things when you search
for awesome-. Try it!

-- 
Bonface M. K. D4F09EB110177E03C28E2FE1F5BBAE1E0392253F
Humble GNU Emacs User / Bearer of scheme-y parens
Curator:  / Twitter: @BonfaceKilz


signature.asc
Description: PGP signature

Re: Discover GNU Guix eco-system with awesome-guix!

[zimoun]

Hi,

On Tue, 9 Feb 2021 at 17:16, Léo Le Bouter  wrote:

> Commonly awesome lists are used to share links to all things related to
> some topic or some software. This lists's purpose is for anyone to be
> able to easily get up to speed with what exists instead of having to
> know each and every one to find out by word of mouth. It also helps
> projects get more exposure that way.

Thanks for the explanations.  I did not know.


Cheers,
simon

Re: Discover GNU Guix eco-system with awesome-guix!

[Léo Le Bouter]

On Tue, 2021-02-09 at 12:56 +0100, zimoun wrote:
> Hi Léo,
> 
Hello!
> On Tue, 9 Feb 2021 at 12:19, Léo Le Bouter 
> wrote:
> 
> > I created an awesome-guix list at
> > https://git.sr.ht/~lle-bout/awesome-guix#awesome-guix
> 
> Sorry, I have probably missed the info: what is the aim of awesome-
> guix?

Commonly awesome lists are used to share links to all things related to
some topic or some software. This lists's purpose is for anyone to be
able to easily get up to speed with what exists instead of having to
know each and every one to find out by word of mouth. It also helps
projects get more exposure that way.

> 
> Cheers,
> simon


signature.asc
Description: This is a digitally signed message part

Re: Discover GNU Guix eco-system with awesome-guix!

[Léo Le Bouter]

On Tue, 2021-02-09 at 15:19 +0100, Tobias Geerinckx-Rice wrote:
> On 2021-02-09 12:56, zimoun wrote:
> > Sorry, I have probably missed the info: what is the aim of 
> > awesome-guix?
> 
> Same here!  This looks like an awesome list but the name doesn't do
> it 
> justice.
> 
> Another possible problematic word *if* you intend this as a Guix 
> community resource: 
> ;.  
> Of 
> course, it's entirely up to you otherwise.

Oh okay, well it's just the title of the email, I didnt know about that
"Ecosystem" could misqualify communities. Do we use movement instead?
Fine by me!

> 
> But mainly: thank you very much for compiling this list, Léo!  We've 
> been missing something like it, relying on tribal knowledge like 
> ‘cbaines is working on a cool thing’.

Yes! :-)

> 
> Kind regards,
> 
> T G-R
> 
> Sent from a Web browser. Excuse or enjoy my brevity.


signature.asc
Description: This is a digitally signed message part

Re: Discover GNU Guix eco-system with awesome-guix!

[Tobias Geerinckx-Rice]

On 2021-02-09 12:56, zimoun wrote:
Sorry, I have probably missed the info: what is the aim of 
awesome-guix?


Same here!  This looks like an awesome list but the name doesn't do it 
justice.


Another possible problematic word *if* you intend this as a Guix 
community resource: 
.  Of 
course, it's entirely up to you otherwise.


But mainly: thank you very much for compiling this list, Léo!  We've 
been missing something like it, relying on tribal knowledge like 
‘cbaines is working on a cool thing’.


Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Re: [DOUBT]: native-search-paths VS search-paths

[Leo Prikler]

Am Dienstag, den 09.02.2021, 11:22 +0100 schrieb Hartmut Goebel:
> Am 09.02.21 um 11:06 schrieb Leo Prikler:
> > Depends on the package.  If it gets propagated into the build
> > environment, the variable is set as well.  At other times, it might
> > be
> > set through the wrap phase for runtime purposes.
> 
> This makes me think whether the wrap-phase of the qt-build-system
> does 
> it right (even after 45784 is merged): It searches the "inputs" for
> some 
> directories. This has the major drawback of including native-inputs 
> (most notable: cmake).
It probably does some wrong things there.  I'm also not sure if we can
distinguish between inputs and native-inputs at this stage, since IIRC
both get merged into %build-inputs, which is then passed as inputs.

For a similar issue look at python packages built with meson – they
likely retain a reference to meson as well.

Regards,
Leo

Re: Discover GNU Guix eco-system with awesome-guix!

[zimoun]

Hi Léo,

On Tue, 9 Feb 2021 at 12:19, Léo Le Bouter  wrote:

> I created an awesome-guix list at
> https://git.sr.ht/~lle-bout/awesome-guix#awesome-guix

Sorry, I have probably missed the info: what is the aim of awesome-guix?

Cheers,
simon

Discover GNU Guix eco-system with awesome-guix!

[Léo Le Bouter]

Hello!

I created an awesome-guix list at 
https://git.sr.ht/~lle-bout/awesome-guix#awesome-guix

Please contribute new items by email with patches to 
~lle-bout/awesome-guix-de...@lists.sr.ht! No promotion of proprietary
software please :-)

Léo


signature.asc
Description: This is a digitally signed message part

Re: [DOUBT]: native-search-paths VS search-paths

[Hartmut Goebel]

Am 09.02.21 um 11:06 schrieb Leo Prikler:

Depends on the package.  If it gets propagated into the build
environment, the variable is set as well.  At other times, it might be
set through the wrap phase for runtime purposes.


This makes me think whether the wrap-phase of the qt-build-system does 
it right (even after 45784 is merged): It searches the "inputs" for some 
directories. This has the major drawback of including native-inputs 
(most notable: cmake).


Now I wonder whether the correct paths are already available a 
"search-path"?


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [DOUBT]: native-search-paths VS search-paths

[Raghav Gururajan]

Hi Leo!


Both search-paths and native-search-paths are expanded in a build
environment to form an environment variable.  search-paths works on
inputs whereas native-search-paths works on native-inputs.  In
addition, native-search-paths also end up in your
$GUIX_PROFILE/etc/profile.


So it is like how "PATH" is established inside build environment?

Also, are they useful only to the package itself or to other
packages
that depend on it as well?

Depends on the package.  If it gets propagated into the build
environment, the variable is set as well.  At other times, it might be
set through the wrap phase for runtime purposes.


I am gonna sit on what you said and think.

Regards,
RG.



OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [DOUBT]: native-search-paths VS search-paths

[Leo Prikler]

Am Dienstag, den 09.02.2021, 04:56 -0500 schrieb Raghav Gururajan:
> Hi Leo!
> 
> > Both search-paths and native-search-paths are expanded in a build
> > environment to form an environment variable.  search-paths works on
> > inputs whereas native-search-paths works on native-inputs.  In
> > addition, native-search-paths also end up in your
> > $GUIX_PROFILE/etc/profile.
> 
> So it is like how "PATH" is established inside build environment?
> 
> Also, are they useful only to the package itself or to other
> packages 
> that depend on it as well?
Depends on the package.  If it gets propagated into the build
environment, the variable is set as well.  At other times, it might be
set through the wrap phase for runtime purposes.

Regards,
Leo

Re: [DOUBT]: native-search-paths VS search-paths

[Raghav Gururajan]

Hi Leo!


Both search-paths and native-search-paths are expanded in a build
environment to form an environment variable.  search-paths works on
inputs whereas native-search-paths works on native-inputs.  In
addition, native-search-paths also end up in your
$GUIX_PROFILE/etc/profile.


So it is like how "PATH" is established inside build environment?

Also, are they useful only to the package itself or to other packages 
that depend on it as well?


Regards,
RG.


OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

[DOUBT]: native-search-paths VS search-paths

[Leo Prikler]

Hello,

Both search-paths and native-search-paths are expanded in a build
environment to form an environment variable.  search-paths works on
inputs whereas native-search-paths works on native-inputs.  In
addition, native-search-paths also end up in your
$GUIX_PROFILE/etc/profile.

Regards,
Leo

[DOUBT]: native-search-paths VS search-paths

[Raghav Gururajan]

Hello Guix!

In the package-reference, there are fields called native-search-paths 
and search-paths. Unfortunately, the corresponding page 
(https://guix.gnu.org/manual/en/html_node/package-Reference.html) in the 
manual doesn't explain much. In my experience of packaging I could 
understand vaguely about them. I would like to know more. :-)


[1] What are they?
[2] What are the differences between them?
[3] When to use one or the other or both?

Thank you!

Regards,
RG.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Unreproducible “guix pack -f docker” because config.scm-builder

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sat, 06 Feb 2021 at 22:46, Ludovic Courtès  wrote:
>
>> See?  One has just 1 link (did you disable deduplication on that one?),
>> there other has 5 links.
>
> Yes, I see but I do not understand why.  I have not changed, well, only
> the number of cores and jobs:
>
> ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon 
> --build-users-group=guixbuild -c 128 -M 99
> Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
>  LC_ALL=en_US.utf8
>
>
> And my 2 Debian systems give the same result, one is the default and the
> other is:
>
> ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon 
> --build-users-group=guixbuild --gc-keep-outputs=yes --gc-keep-derivations=yes
>
>
>
> There is another configuration file that I could miss?

No.

I’m not sure exactly why it happened, but it’s clear that (guix docker)
would let the nlink value influence tar.

>> Having looked at the tar manual (info "(tar) hard links"), it seems
>> clear that this is the default behavior and that we have to pass
>> ‘--hard-dereference’ to avoid it.
>
> Do you mean in (guix docker) here:
>
>   (apply invoke "tar" "-cf" "../layer.tar"
>  `(,@transformation-options
>,@%tar-determinism-options
>,@paths
>,@(scandir "."
>   (lambda (file)
> (not (member file '("." ".."
>
> if I read correctly?
>
> And the option «-h, --dereference: Follow symlinks; archive and dump the
> files they point to.» isn’t enough?

It’s really ‘--hard-dereference’.

Pushed as 18a4882e3029a084d2f0c63d9d0148682a854546, thank you!

Ludo’.

Guix Day: Notes frome the Bootstrap session

[Jan Nieuwenhuizen]

Hello Guix!

Attached the notes from the "Bootstrap what's next" session yesterday.

Greetings,
Janneke

- Branch wip-arm-bootstrap is getting ready but stuck at glibc-mesboot0,
  when finished: release mes-0.23.

- Branch wip-full-source-bootstrap is ready for review; wait with merge
  until wip-arm-bootstrap?  When finished, relase mes-0.24.

- Support for PowerPC and RISC-V

- Submitting a GSOC proposal to have a student help out with some of the
  problems ^^

- Building for PowerPC isn't straightforward. You'd need actual h/w to
  test things out.

- Making the guix build system code less dependent on Guile and more
  dependent on MES

- PowerPC
 + Glibc+GCC version combination during bootstrap is problematic on PowerPC.
 + Glibc changes introduces uncertainty.
 + Branch with bootstrap binaries is ready for merging:
   https://git.sr.ht/~lle-bout/guix/log/wip-ppc64le

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Unreproducible “guix pack -f docker” because config.scm-builder

[zimoun]

Hi,

On Tue, 9 Feb 2021 at 09:35, Ludovic Courtès  wrote:

> Pushed as 18a4882e3029a084d2f0c63d9d0148682a854546, thank you!

Thanks!  Your comment is better that the none of mime. ;-)

I have not tried yours but I confirm with mine which is the same, the
issue is fixed. :-)

Cheers,
simon