Re: CVEs missing from the NIST database

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Yes, that can happen when the CVE doesn’t list affected versions:
>
>   https://www.openwall.com/lists/oss-security/2017/03/15/3

Thank you for pointing out that thread, and for starting it 4 years ago.
I found it illuminating.

> The solution here is to add a ‘lint-hidden-cve’ property to the
> package with a comment explaining why we think these CVEs can be
> ignored (info "(guix) Invoking guix lint").

I've now done so for 'gnome-shell' and 'gvfs'.

Thanks,
  Mark

Re: [opinion] CVE-patching is not sufficient for package security patching

[Leo Famulari]

On Tue, Mar 16, 2021 at 07:19:59PM -0400, Mark H Weaver wrote:
> Ultimately, I gave up.  In my opinion, Guix has never achieved usability
> as a desktop system on non-Intel systems.  Therefore, the Guix community
> is unable to attract many developers who want a distro that supports
> non-Intel systems well.  Our community has thus become dominated by
> Intel users, and there's unsufficient political will to adopt policies
> that would enable us to provide a usable system for non-Intel users.
> 
> What do you think?

Thanks, as always, for your well-reasoned message. Your story of your
experience here, and what it means for Guix, computing security, and
free software in general, is really valuable. I still think it's really
unfortunate for the rest of us that you gave up, but I don't see how it
could have gone differently.

I agree with you that Guix moves too fast to support non-Intel
architectures in its current state. My hope is that, within the next two
years, there will be workstation aarch64 machines more widely available
at comparable prices to Intel/AMD, and this will translate into more
developer support for aarch64 in the years after that. Time will tell.

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

[Christopher Baines]

Léo Le Bouter  writes:

> It seems Fedora has automated infrastructure and feeds to monitor new
> upstream releases so that maintainers can get notifications on them.
>
> https://release-monitoring.org/
>
> Functional feed:
> https://apps.fedoraproject.org/datagrepper/raw?rows_per_page=1=127800=hotness
>
> I could not find the actual data it is based on for release monitoring
> (like Debian watch files).

I think it might be in the service itself.

> I could not find a similar feed for Debian's watch/uscan but it would
> be nice if they provided some sort of RSS feed (global or scoped to
> packages or sets of packages).
>
> I am thinking we should really get something like this with the Guix
> Data Service, start including something similar to Debian uscan/watch
> rules in every package so we can get reliable (in majority of cases)
> update notifications.

I did spot these patches
https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=7298

I think the Guix Data Service could run the "refresh" code from Guix and
store relevant data, although I'm also thinking along the lines of
trying to generate patches, like you go on to below...

> We could also have some feature that gives you a feed for a manifest or
> operating-system definition so that people can prioritize work on what
> they care about easily.
>
> I would really love to have some RSS feed for new upstream releases
> from Guix Data Service based on my operating-system definition I would
> upload there.

So, one thing I'm hoping to start work on in the coming weeks/months is
the long awaited service for providing subscriptions/notifications for
the Guix Data Service (+ other services).

My current plan is to use a WebSub like pattern, but this could easily
be adapted to RSS/email/...

> We could even go as far as preparing a patch (similar to guix refresh
> -u  && etc/committer.scm) and trying to build it and all it's
> dependents and if it doesnt cause any new failures we could send an
> automated patch contribution on guix-patches directly and tag it with
> "ci-update-ok" or something so a maintainer just has to double-check
> quickly and push (very efficient workflow).

Yeah, one problem with the current automated patch review stuff I've got
going at the moment is that there's no feedback when the Guix Data
Service finds out that things do/don't build.

However, as I also set out above, there's been a plan and design for
making that possible for years, it just needs implementing.

One thing I'm hoping to do once it's possible to subscribe to Guix Data
Service data is make the checks in Patchwork actually reflective of
results (like 4 packages broken by these changes), rather than just
providing links, and someone having to figure out what information is
hidden within.

Those same subscriptions could be used to prompt people to look at
patches for package updates that don't introduce breakages (following
what you set out above).

The pieces are slowly coming together for this, at least with the way I
would approach it. For example, it's possible to get commits in to
data.guix-patches.cbaines.net now by just pushing to the Git repository,
so to set out something similar to what you describe above:

 - Some service watches for new releases (through the guix refresh
   code), and then makes commits, and pushes them to a Git repo

 - There's a Guix Data Service reading from that Git repository, it
   starts processing the changes

 - Something (probably the "service" above") subscribes to find out when
   relevant information is available (like build successes/failures)

 - Builds happen via the Guix Build Coordinator, which feeds information
   back to the Guix Data Service

 - That "service" gets the notifications that the commits are good, and
   prompts someone to review them

I hope some of that makes sense,

Chris


signature.asc
Description: PGP signature

Re: [opinion] CVE-patching is not sufficient for package security patching

[Mark H Weaver]

Hi Léo,

Léo Le Bouter  writes:

> I would like to share some opinion I have on CVE-patching for non-
> rolling release GNU/Linux distributions and why we should strive to
> always update to the latest available releases or always follow
> upstream supported release series and never backport patches ourselves
> in most cases (some upstreams may have really good practices but these
> are rare).
>
> A lot of security issues are patched silently in upstream projects
> without ever getting a CVE, security issues may not be labeled as such
> by upstreams for various reasons (fear of shame, belief to patch
> something with no security impact while it has, bizarre security
> through obscurity policy, ..).

... and I'll add that it can be a lot of work to evaluate, for a given
bug, whether or not that bug is exploitable.

Anyway, I agree that bugs fixed upstream are sometimes exploitable, even
when they have not been explicitly identified as security flaws, and
that this is a valid argument in favor of keeping our packages updated
to the latest release.

That said, I strongly disagree that we should "never backport patches
ourselves in most cases".  The only way to do that, while addressing
security flaws, would be to promptly update even our lowest-level
libraries in response to CVEs, of which there is a steady stream.

Anyone with experience working on the 'staging' or 'core-updates'
branches in Guix, or in the release process of Debian, will immediately
recognize this proposal to be unrealistic.  In practice, updating
low-level or even mid-level libraries tends to cause breakage.  This
kind of integration breakage happens quite frequently, even on
x86_64-linux, the architecture that most developers work on.

It's *much* worse on other architectures.  New upstream releases quite
regularly cause breakage on less popular architectures.  It is often
left to distros such as Debian to fix these problems.

Since you're interested in security, I'll now remind you that *all*
modern Intel systems include another little computer inside them called
the Management Engine, which is always on when the machine is plugged in
(even when the computer is "off"), has it's own memory that the main CPU
cannot see, runs a proprietary OS that the user cannot replace, has full
access to the RAM and disk of the machine, and can talk to the network
without the main CPU even seeing those packets.

Are you comfortable with this?

If not, it would be good to work toward the goal of making Guix usable
on non-Intel systems.  I'm sorry to say that, in my opinion, your
proposal would move us in the wrong direction to achieve that goal.

In my experience, Guix is already moving far too fast to be usable on
less popular architectures.  I have some knowledge of this.  Years ago,
I made a serious effort to make Guix usable on non-Intel systems.  When
Guix was young, I initiated its first two ports to non-Intel
architectures: mips64el-linux and armhf-linux, and I tried to actually
use Guix on those systems in practice.  I found that my system was very
frequently broken by upstream updates, and that we didn't have nearly
enough developer energy to keep up with fixing those problems.

I've come to believe that having Guix work well on non-Intel systems is,
in practice, incompatible with the rate at which we update our packages.
I'm not sure that even Debian would have enough energy to keep less
popular architecures working well, given our practices.  I raised this
issue on guix-devel a few times over the years, but it became clear that
the desire in this community to keep packages aggressively updated far
outweighs any interest in supporting non-Intel systems.

Ultimately, I gave up.  In my opinion, Guix has never achieved usability
as a desktop system on non-Intel systems.  Therefore, the Guix community
is unable to attract many developers who want a distro that supports
non-Intel systems well.  Our community has thus become dominated by
Intel users, and there's unsufficient political will to adopt policies
that would enable us to provide a usable system for non-Intel users.

What do you think?

Regards,
  Mark

Re: Security-czar needed? WAS: Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari]

On Tue, Mar 16, 2021 at 10:46:11PM +0100, Bengt Richter wrote:
> Just wish I could type
> guix --what-and-who-am-I-trusting-q --full-report
> and get a complete list, with batting averages of the
> developers (regressions vs fixes), packages (estimated
> number of times executed without problem, dangerous bugs
> in development history, etc).

Leaving aside the rest of your suggestion, which has merit, I strongly
object to ranking Guix contributors in that way. Most of us feel bad
enough about our mistakes without some kind of public scoreboard.

In general, as the person who was the de facto security team leader for
several years, I feel that such a position should be supported in a
material way.

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari]

On Tue, Mar 16, 2021 at 10:18:08PM +0100, Vincent Legoll wrote:
> I think we really should be shortening our releases cycles (core-updates,
> staging merges), because piling upon those branches for too long increase
> the disruption in a way that is probably more exponential than linear.

For most grafted packages, it's always been the goal to regularly
ungraft, maybe within a few weeks. However, we have never actually had
the build farm capacity to do this for all the platforms that we
support.

Currently, I think we have the capacity for x86_64 and i686 (they use
the same build machines), but not for anything else.

Some packages that qualify for grafts can usually be updated without any
breakage, like OpenSSL.

But other packages, like glibc, cannot be updated in isolation. They
require extensive validation and updates of other packages, sometimes
even requiring patching. It's not just a matter of compute capacity.

This distinction actually highlights what is meant by "core" in Guix.
Due to lack of build farm capacity, core-updates has come to encompass
any changes that causes more than 1800 rebuilds. But, "core" is actually
defined explicitly in Guix [0], and it's literally the core of the
package graph and the GNU system. As the number of packages in Guix has
grown, more and more non-core packages have come to fit in core-updates.
Maybe there is room for improvment here, but I don't know what it is.

I do think we should strive to ungraft things more quickly, maybe after
clarifying the support status of the armhf, aarch64, and ppc64le
platforms.

[0] Check the core-package? procedure in guix/scripts/refresh.scm

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Maxime Devos]

On Tue, 2021-03-16 at 15:29 -0400, Leo Famulari wrote:
> > [...]
> 
> No, sorry :) Someone else (maybe an i686 user?) will have to find the
> time to test it.

I haven't tried the patch, but note that x86-64 systems are also
i686 systems, so users of x86-64 systems can try

  ./pre-inst-env guix build --system=i686-linux zstd



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

Security-czar needed? WAS: Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Bengt Richter]

Hi all,

On +2021-03-16 15:29:43 -0400, Leo Famulari wrote:
> On Tue, Mar 16, 2021 at 08:25:50PM +0100, zimoun wrote:
> > Hi,
> > 
> > On Tue, 16 Mar 2021 at 20:18, Leo Famulari  wrote:
> > > On Tue, Mar 16, 2021 at 07:19:53PM +0100, zimoun wrote:
> > > > I guess that it will not build for i686.  Does it?
> > >
> > > I don't know. Either we will find out when building on CI, or people can
> > > test it manually now.
> > 
> > Please try out the patch from:
> > 
> > 
> > 
> > and if it works for you, please apply it.
> 
> No, sorry :) Someone else (maybe an i686 user?) will have to find the
> time to test it.
> 

I would feel better about running guix on my laptop if I
knew all you developers had gotten together and elected
a "security czar" who is the most competent of you to monitor
security and also cares the most, and had the power to prevent
applying unreviewed patches, and making sure all CVEs are taken
care of, and kitchen doors not left open the way we did in the '50s.

Sorry if it sounds like I think guix security is lax.
Please convince me it's not so ;)

Thanks, nevertheless, for all the great technical work!

Just wish I could type
guix --what-and-who-am-I-trusting-q --full-report
and get a complete list, with batting averages of the
developers (regressions vs fixes), packages (estimated
number of times executed without problem, dangerous bugs
in development history, etc).



-- 
Regards,
Bengt Richter

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Vincent Legoll]

Hello,

On Tue, Mar 16, 2021 at 9:53 PM Tobias Geerinckx-Rice  wrote:
> Wow, Léo.  You've done some seriously impressive CVE squashing in
> such a short timespan, and I'm very grateful to have you on board.

Yes, impressive, I have been following the repology page about potentially
vulnerable & upgradable packages for Guix, and the number has significantly
decreased the last weeks, kudos !

I did some package updates (chosen from the very same page) but unlike
you, I only cherry-picked the low hanging fruits from there and punted on
the more involved ones. A good part of that ended on core-updates due to
the rebuilds needed.

I think we really should be shortening our releases cycles (core-updates,
staging merges), because piling upon those branches for too long increase
the disruption in a way that is probably more exponential than linear.

My perception is the following (please correct me if I'm wrong):

A graft involves work on master for the inherited package & graft, sometimes
an update of the package on core updates, then the cleanup (which are more
or less all done in a short time frame when we want to release). So while it
may good enough for some fixes, they should be limited in number and in time,
which also comes to the release early, release often (in a reasonable way).

I was told that we can always update packages because guix easily allows
anyone to go back to a working state, the same reasoning should be applicable
to staging and core-updates merging. Why delay them for too long if
the potential
disruption is mitigated by going back to a workinig profile or system generation
(modulo the substitute availability which is almost only a compute resource
problem)

Cheers

-- 
Vincent Legoll

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Tobias Geerinckx-Rice]

Hi L[ée]o,

Wow, Léo.  You've done some seriously impressive CVE squashing in 
such a short timespan, and I'm very grateful to have you on board.


Leo Famulari 写道：
I do agree that updating this program 5 versions in a graft was 
perhaps

too much.

We should always try to cherry-pick bug-fix patches when 
grafting.

Otherwise the risk of breakage is too high.


I agree.  Whilst grafts are indispensible for timely deployment of 
security patches, they're also a dirty hack composed entirely of 
rough edges.


They exist for one purpose: patch out known vulnerabilities. 
Every extra change not strictly required for security is a 
liability.


We sometimes get away with grafting entire releases (OpenSSL comes 
to mind), but this is not an ideal to emulate.


At least, these types of patches should be reviewed on 
guix-patches.

Léo, can you send them to guix-patches in the future?


I have the same request :-)  Please submit non-trivial patches for 
review (and, unfortunately, grafts are hardly ever trivial).  This 
isn't a comment on your work; it's our standard way of doing 
things.


I know we're not the #1 bestest project when it comes to the swift 
review of patches.  I understand the sense of urgency in fixing 
things that one feels should have been fixed long ago.  Thank you 
for helping us to improve on both points.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari]

On Tue, Mar 16, 2021 at 07:19:53PM +0100, zimoun wrote:
> I guess that it will not build for i686.  Does it?

I don't know. Either we will find out when building on CI, or people can
test it manually now.

We might consider building the wip-next-release earlier than you had
suggested. There is a large number of major updates on the branch, so it
will unfortunately be more like core-updates than I had planned for.

If that's not acceptable, we can narrow the scope of the existing
grafts, by cherry-picking bug fix patches rather than updating the
entire package.

Re: [opinion] CVE-patching is not sufficient for package security patching

[Leo Famulari]

On Tue, Mar 16, 2021 at 12:10:26PM +0100, Léo Le Bouter wrote:
> For these reasons, I suggest that we always strive to update packages
> to their latest versions and that I think it is security relevant to
> always do so. Of course, new code could *introduce* new vulnerabilities
> but I am not trying to debate this, it's that to the best of the
> upstream's knowledge chances are that the latest version will contain
> more security fixes than older versions (if that upstream is actually
> maintaining the project).

I agree that every new release can be considered to have fixed security
problems.

Please read the rest of my message while keeping in mind that I have
spent *a lot* of time working on security in Guix over the years.

We must keep in mind that there are other values besides security.
Additionally, this kind of "security" mindset is a somewhat narrow way
of considering the problem of secure computing. It's important to
remember that security can be modeled with 3 factors: confidentiality,
integrity, and availability. The 3rd factor is often overlooked.

In terms of making a distro, there is a spectrum of approaches.

At one end of the spectrum, there is something like PyPi, which is just
a clearinghouse for upstream projects to distribute their code.
Everything is always updated to the latest version. It does not provide
a working system, even within the narrow world of "just Python"; there
are broad incompatibilities among the latest versions of Python
programs.

On the other end is the approach of Red Hat and Debian. They laboriously
filter the upstream software to provide stable operating systems.  They
do fix security bugs, but only after extensive validation that
functionality is not changed. The result is useful but the cost is very
high.

Guix has always been in the middle, along with other rolling release
distros, and I think that's a good place for us to be. With our superior
tooling we can be "more stable than rolling release" while also "moving
faster than stable".

It's instructive to consider the Linux kernel. They release about once a
week, and every release fixes serious but unpublicized bugs. At the time
they are announcing the release, they are already aware of other serious
bugs, that might be fixed in the next release. It sounds terrible, and
yet Linux is by far the most popular and useful general-purpose
operating system. The world of computing, which is based on Linux,
continues to serve our civilization well. That's because the most
important thing value in Linux development is to not break anything for
users; security is not the top priority, but just another important
thing to consider.

I think that, as an operating system distro, we must adopt a similar
mindset, and be careful not to sacrifice too much for an abstract sense
of security based on fixing CVEs, which are an arbitrary system that
have little bearing on utility or safety in the real world, which is
where security matters. Of course we should fix CVEs, but we must also
recognize that rushing too much reduces stability and availability. We
have to weigh the costs and benefits every time.


signature.asc
Description: PGP signature

Using package transformations declaratively (was: [bug#47163] [PATCH] refresh: Add '--installed' option.)

[Xinglu Chen]

On Tue, Mar 16 2021, Ludovic Courtès wrote:

> You may also like the new ‘--with-latest’ package transformation
> option.  :-)

I really like package transformations but is there a way to use specify
them with Guile so I can use them with `guix home`[1] or in manifests?

Ccing guix-devel

[1]: https://yhetil.org/guix-devel/878s6u2pco@trop.in

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari]

On Tue, Mar 16, 2021 at 08:25:50PM +0100, zimoun wrote:
> Hi,
> 
> On Tue, 16 Mar 2021 at 20:18, Leo Famulari  wrote:
> > On Tue, Mar 16, 2021 at 07:19:53PM +0100, zimoun wrote:
> > > I guess that it will not build for i686.  Does it?
> >
> > I don't know. Either we will find out when building on CI, or people can
> > test it manually now.
> 
> Please try out the patch from:
> 
> 
> 
> and if it works for you, please apply it.

No, sorry :) Someone else (maybe an i686 user?) will have to find the
time to test it.

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[zimoun]

Hi,

On Tue, 16 Mar 2021 at 20:18, Leo Famulari  wrote:
> On Tue, Mar 16, 2021 at 07:19:53PM +0100, zimoun wrote:
> > I guess that it will not build for i686.  Does it?
>
> I don't know. Either we will find out when building on CI, or people can
> test it manually now.

Please try out the patch from:



and if it works for you, please apply it.

> We might consider building the wip-next-release earlier than you had
> suggested. There is a large number of major updates on the branch, so it
> will unfortunately be more like core-updates than I had planned for.

Let's do that. :-)

> If that's not acceptable, we can narrow the scope of the existing
> grafts, by cherry-picking bug fix patches rather than updating the
> entire package.

You are right, it could be nice to have ASAP an idea about what is
acceptable and then how to narrow.


Cheers,
simon

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[zimoun]

On Tue, 16 Mar 2021 at 19:51, Léo Le Bouter  wrote:
> On Tue, 2021-03-16 at 19:46 +0100, zimoun wrote:

> > Well, it seems better to send such changes to guix-patches, waiting
> > 15
> > days, and then if no comment, push.  It is what the manual describes:
> >
> > Non-trivial patches should always be posted to
> > guix-patc...@gnu.org (trivial patches include fixing typos,
> > etc.). […]
> >
> > For patches that just add a new package, and a simple one,
> > it’s OK to
> > commit, if you’re confident […].  Likewise for package
> > upgrades, except
> > upgrades that trigger a lot of rebuilds […].
> >
> > […]
> >
> > […] If you didn’t receive any reply after two weeks, and if
> > you’re confident, it’s OK to commit.
> >
> > 
> >
> > And from my understanding, it is a non-trivial patch which triggers a
> > lot of rebuilds.  Double reasons. ;-)
>
> It's not just like any other patch, it's a security patch, so **15**
> days..

"To me, security is important. But it's no less important than
everything *else* that is also important!"

And nothing blocks you to have the patch in your tree in these (max)
15 days review time.

Re: [bug#47163] Using package transformations declaratively (was: [bug#47163] [PATCH] refresh: Add '--installed' option.)

[Xinglu Chen]

On Tue, Mar 16 2021, zimoun wrote:

>> I really like package transformations but is there a way to use specify
>> them with Guile so I can use them with `guix home`[1] or in manifests?
>
> There is several ways to have package transformations at the manifest
> level.  One is:
>
> --8<---cut here---start->8---
> (use-modules (guix transformations))
>
> (define transform1
>   (options->transformation
> '((with-c-toolchain . "hello=gcc-toolchain@8"
>
> (packages->manifest
>   (list (transform1 (specification->package "hello"
> --8<---cut here---end--->8---

Cool, thanks for the help.

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[zimoun]

On Tue, 16 Mar 2021 at 19:08, Léo Le Bouter  wrote:
On Tue, 2021-03-16 at 13:55 -0400, Leo Famulari wrote:

> > I do agree that updating this program 5 versions in a graft was
> > perhaps
> > too much.
> >
> > We should always try to cherry-pick bug-fix patches when grafting.
> >
> > Otherwise the risk of breakage is too high. At least, these types of
> > patches should be reviewed on guix-patches. Léo, can you send them to
> > guix-patches in the future?
> >
> > Sometimes it is okay to update things in a graft, but it depends on
> > the
> > situation.
>
> 1.4.4 and 1.4.9 are ABI compatible? At least that's the reason I
> believed it wasnt risky. I can send them to the mailing list especially
> with such a core package (GNU Guix dependency). But often it stays
> there and no one is looking so. E.g. the unzip vulnerability patches,
> nobody looked until I actually pushed them out of waiting for reviews,
> I tried to hint multiple people on IRC during several days, no answer
> still, so I ended up pushing it, turns out I had several mistakes in it
> and because it was pushed well some people looked at it and helped
> fixing which was welcome.

Well, it seems better to send such changes to guix-patches, waiting 15
days, and then if no comment, push.  It is what the manual describes:

Non-trivial patches should always be posted to
guix-patc...@gnu.org (trivial patches include fixing typos,
etc.). […]

For patches that just add a new package, and a simple one, it’s OK to
commit, if you’re confident […].  Likewise for package upgrades, except
upgrades that trigger a lot of rebuilds […].

[…]

[…] If you didn’t receive any reply after two weeks, and if
you’re confident, it’s OK to commit.



And from my understanding, it is a non-trivial patch which triggers a
lot of rebuilds.  Double reasons. ;-)


Cheers,
simon

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 19:46 +0100, zimoun wrote:
> Well, it seems better to send such changes to guix-patches, waiting
> 15
> days, and then if no comment, push.  It is what the manual describes:
> 
> Non-trivial patches should always be posted to
> guix-patc...@gnu.org (trivial patches include fixing typos,
> etc.). […]
> 
> For patches that just add a new package, and a simple one,
> it’s OK to
> commit, if you’re confident […].  Likewise for package
> upgrades, except
> upgrades that trigger a lot of rebuilds […].
> 
> […]
> 
> […] If you didn’t receive any reply after two weeks, and if
> you’re confident, it’s OK to commit.
> 
> 
> 
> And from my understanding, it is a non-trivial patch which triggers a
> lot of rebuilds.  Double reasons. ;-)

It's not just like any other patch, it's a security patch, so **15**
days..

> 
> Cheers,
> simon


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

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 19:19 +0100, zimoun wrote:
> I guess that it will not build for i686.  Does it?
> If not, the patch attached to the previous email tweaks the offending
> test; as the original author of zstd has suggested:
> 
> 
> 
> (Thanks to the other Leo for opening the issue.)

Indeed it would not pass tests, thanks for the patch.

> 
> Well, I am confused.  If the update of zstd from 1.4.4 to 1.4.9 does
> not imply a huge rebuild, why is it a graft?  And not a simple
> update?

Well there is some huge rebuild involved, but there is something else
happening here, the zstd package as a specification now refers to 
zstd@1.4.9 and not zstd@1.4.4 (as grafted) because the version is
newer, I should've made the zstd@1.4.9 graft package definition private
here as I do now for other grafts.

$ ./pre-inst-env guix refresh -l zstd
Building the following 2 packages would ensure 2 dependent packages are
rebuilt: ecl-zstd@1.0-1.d144582 cl-zstd@1.0-1.d144582

We see only 2 here, but it's a false result, zstd is a dependency to
way more,

Then if we do this:

$ ./pre-inst-env guix refresh -l zstd@1.4.4
Building the following 5115 packages would ensure 10443 dependent
packages are rebuilt
[...]

There we are, almost all packages need to be rebuilt.

Léo


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

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 13:55 -0400, Leo Famulari wrote:
> I do agree that updating this program 5 versions in a graft was
> perhaps
> too much.
> 
> We should always try to cherry-pick bug-fix patches when grafting.
> 
> Otherwise the risk of breakage is too high. At least, these types of
> patches should be reviewed on guix-patches. Léo, can you send them to
> guix-patches in the future?
> 
> Sometimes it is okay to update things in a graft, but it depends on
> the
> situation.

1.4.4 and 1.4.9 are ABI compatible? At least that's the reason I
believed it wasnt risky. I can send them to the mailing list especially
with such a core package (GNU Guix dependency). But often it stays
there and no one is looking so. E.g. the unzip vulnerability patches,
nobody looked until I actually pushed them out of waiting for reviews,
I tried to hint multiple people on IRC during several days, no answer
still, so I ended up pushing it, turns out I had several mistakes in it
and because it was pushed well some people looked at it and helped
fixing which was welcome.


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

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[zimoun]

Hi,

On Tue, 16 Mar 2021 at 18:56, Leo Famulari  wrote:
>
> On Tue, Mar 16, 2021 at 05:34:34PM +0100, zimoun wrote:
> > The question is: should the next release 1.2.1 contain zstd@1.4.9 as
> > graft?  Or do we revert the commit and simply fix it on core-updates
> > and wait for the next core-updates cycle.  Personally, I am in favor
> > of the latter.  WDYT?
>
> The release should not contain any grafts, if we can help it.
>
> On the wip-next-release branch, I've simply updated zstd to 1.4.9:

I guess that it will not build for i686.  Does it?
If not, the patch attached to the previous email tweaks the offending
test; as the original author of zstd has suggested:



(Thanks to the other Leo for opening the issue.)


Well, I am confused.  If the update of zstd from 1.4.4 to 1.4.9 does
not imply a huge rebuild, why is it a graft?  And not a simple update?


Cheers,
simon

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[zimoun]

Hi,

On Tue, 16 Mar 2021 at 18:06, Léo Le Bouter  wrote:

> I suggest we disable the test-suite or the specific test in the interim
> for other architectures.

The patch attached in the previous email tweaks the offending test to
allow the test suite to pass on both architectures x86_64 and i686.  I
am not able to test the other architectures.

Well, this upgrading zstd from 1.4.4 to 1.4.9 is one way to fix, but
we could also graft by backporting a patch.  As Debian did for 1.4.8:




> The CVE-2021-24032 is Base Score: 9.1 CRITICAL - which is exceptionally
> high so fixing it is an absolute necessity in any branch.

For Suse, the severity is moderate and they rank to 6.2.



Well, even if I agree that security is often important, more haste and
less speed, is generally good. :-)


Cheers,
simon

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari]

On Tue, Mar 16, 2021 at 06:06:28PM +0100, Léo Le Bouter wrote:
> The CVE-2021-24032 is Base Score: 9.1 CRITICAL - which is exceptionally
> high so fixing it is an absolute necessity in any branch.

This is off-topic, but I think that CVE scoring is not really that
useful. This bug is a local TOCTOU race which is bad but hardly
critical, IMO. For something to be critical, it should enable remote
execution of arbitrary code.


signature.asc
Description: PGP signature

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Leo Famulari]

On Tue, Mar 16, 2021 at 05:34:34PM +0100, zimoun wrote:
> The question is: should the next release 1.2.1 contain zstd@1.4.9 as
> graft?  Or do we revert the commit and simply fix it on core-updates
> and wait for the next core-updates cycle.  Personally, I am in favor
> of the latter.  WDYT?

The release should not contain any grafts, if we can help it.

On the wip-next-release branch, I've simply updated zstd to 1.4.9:

https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-next-release

I do agree that updating this program 5 versions in a graft was perhaps
too much.

We should always try to cherry-pick bug-fix patches when grafting.

Otherwise the risk of breakage is too high. At least, these types of
patches should be reviewed on guix-patches. Léo, can you send them to
guix-patches in the future?

Sometimes it is okay to update things in a graft, but it depends on the
situation.


signature.asc
Description: PGP signature

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 13:48 -0400, Leo Famulari wrote:
> This is off-topic, but I think that CVE scoring is not really that
> useful. This bug is a local TOCTOU race which is bad but hardly
> critical, IMO. For something to be critical, it should enable remote
> execution of arbitrary code.

Well you don't know what people use zstd for, easily escalates to more
critical issues depending on people's use case. Also I think CRITICAL
reasoning here is also because it's a trivial to understand and exploit
issue, it's not like an obscure memory safety issue with no known PoC
but probable exploitation.

I do not agree in general not patching CVEs even if low (publicized)
severity as long as it's possible for us to do it. Often the
vulnerabilities have an unobserved attack angle and severity may be
underevaluated. The zstd patch was tested on x86_64-linux it's
unfortunate the test suite fails (errornously, not an actual fault) on
32bit archs, otherwise it's no issue. I wish the zstd test suite was
more reliable in general, generating random data in their test suite
doesnt help determinism here. I think I tried on i686-linux to build as
well and it succeeded for me so I pushed, but it didnt fail on me and
when I retried later it did, so definitely some non-determinism here.

Since we know there's no actual fault in the test suite because it
passes I thought it was relatively fine to disable the test suite
temporarily until core-updates comes in (if we don't change versions in
between and revisit).

Zimoun:
> which fails for the value 19 but not other values as 18 or 20 or many
> others.  After a quick reading of the doc, I am not sure to
> understand
> the meaning of such value.  Input welcome.

https://github.com/facebook/zstd/issues/2528 - I asked upstream earlier
and see their answer

> I agree that security is important but we lived more than one and
> half
> year with 1.4.4 so the upgrade to 1.4.9 should only go to
> core-updates, not as a 'replacement' graft.  IMHO.

To add, I don't think we should reason that way, it's not because we
lived with something that we should live with it longer, I don't want
unpatched zstd (or any other) CVEs on my system. Actually I am not sure
1.4.4 had any CVE before that one though, so that must also be why.

Léo


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

Re: [bug#47163] Using package transformations declaratively (was: [bug#47163] [PATCH] refresh: Add '--installed' option.)

[zimoun]

Hi,

On Tue, 16 Mar 2021 at 17:46, Xinglu Chen  wrote:
> On Tue, Mar 16 2021, Ludovic Courtès wrote:
>
> > You may also like the new ‘--with-latest’ package transformation
> > option.  :-)
>
> I really like package transformations but is there a way to use specify
> them with Guile so I can use them with `guix home`[1] or in manifests?

There is several ways to have package transformations at the manifest
level.  One is:

--8<---cut here---start->8---
(use-modules (guix transformations))

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

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


HTH,
simon

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

I suggest we disable the test-suite or the specific test in the interim
for other architectures.

The CVE-2021-24032 is Base Score: 9.1 CRITICAL - which is exceptionally
high so fixing it is an absolute necessity in any branch.


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

Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[zimoun]

Hi,

This commit 6f873731a030dd7ecbd8a5e756b38b26306f6966:



fixes CVE-2021-24032 which says: "Beginning in v1.4.1 and prior to
v1.4.9, output files were created with default permissions. [...]".

The mentioned commit replaces zstd@1.4.4 by zstd@1.4.9 which seems
more than just grafting.  Well,1.4.4 was released on Nov 2019 and
1.4.9 some days ago.

I agree that security is important but we lived more than one and half
year with 1.4.4 so the upgrade to 1.4.9 should only go to
core-updates, not as a 'replacement' graft.  IMHO.

The consequence of this change was the breakage of "guix pull" on
master for at least i686.  Which leads to the commit
2bcfb944bdd2f476ef8d34802fed436e4fdda0ab disabling the zstd test-suite
for all the architectures.



Noting that "guix pull" should be still failing for at least i686 on
core-updates because of the test suite of zstd@1.4.9.


The question is: should the next release 1.2.1 contain zstd@1.4.9 as
graft?  Or do we revert the commit and simply fix it on core-updates
and wait for the next core-updates cycle.  Personally, I am in favor
of the latter.  WDYT?

The issue is the test:

roundTripTest -g8M "19 -T0 --long"

which fails for the value 19 but not other values as 18 or 20 or many
others.  After a quick reading of the doc, I am not sure to understand
the meaning of such value.  Input welcome.

BTW, on my machine the attached patch builds for both x86_64 and i686
(emulated).

   ./pre-inst-env guix build zstd@1.4.9 --system=i686-linux --no-grafts

Depending on the answer of the previous question, the patch should go
to master or core-updates.  And other architectures should be examined
with care.


Cheers,
simon
diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 827ad43dc2..86ce3a697d 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -32,6 +32,7 @@
 ;;; Copyright © 2020 Léo Le Bouter 
 ;;; Copyright © 2021 Antoine Côté 
 ;;; Copyright © 2021 Vincent Legoll 
+;;; Copyright © 2021 Simon Tournier 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1483,7 +1484,13 @@ speed.")
 (base32 "14yj7309gsvg39rki4xqnd6w5idmqi0655v1fc0mk1m2kvhp9b19"
 (arguments
  (substitute-keyword-arguments (package-arguments zstd)
-   ((#:tests? _ #t) #f)
+   ((#:phases phases)
+`(modify-phases ,phases
+   (add-after 'unpack 'fix-test-i686
+ (lambda _
+   (substitute* "tests/playTests.sh"
+ (("roundTripTest -g8M \"19 -T0 --long\"")
+  "roundTripTest -g8M \"22 -T0 --long\""))
 
 (define-public pzstd
   (package

Re: Adding Substitute Mirrors page to installer

[raid5atemyhomework]

Hi all,

Below is the new patch version.

In this version, the installer now also reads the generated `operating-system` 
file to extract the `guix-configuration-substitute-urls`, in order to pass it 
into the `start` action of `guix-daemon`.  The `start` action also now supports 
a second argument, the space-separated list of substitute URLs.  I'm wary of 
this technique as I feel it is unclean, but it works and does not require 
significant changes to the existing software architecture of the installer.

Tested in this manner:

* Created an installer image by `./pre-inst-env guix system image -t iso9660 
gnu/system/install.scm`.
* Started a new VM with the installer image and selected the SJTUG mirror.
* Confirmed that during installation the installer downloaded substitutes from 
the SJTUG mirror.
* After installation completed on the VM, did a `guix pull` on the new VM 
instance and confirmed it downloaded substitutes from the SJTUG mirror.

I haven't tested for the use of the normal Berlin Cuirass, as that would be 
ridiculously slow right now from my network, but I expect it would continue to 
work.

Thanks
raid5atemyhomework

>From 68a42cce2b4ae876cbbd1911aaa2a5bc8348bf15 Mon Sep 17 00:00:00 2001
From: raid5atemyhomework 
Date: Tue, 16 Mar 2021 23:45:37 +0800
Subject: [PATCH] gnu: Add substitute mirrors page to installer.

* gnu/installer/services.scm (system-service) [snippet-type]: New field.
(%system-services): Add substitute mirrors.
(service-list-service?): New procedure.
(modify-services-service?): New procedure.
(system-services->configuration): Add support for services with
`'modify-services` snippets.
* gnu/installer/newt/services.scm (run-substitute-mirror-page): New
procedure.
(run-services-page): Call `run-substitute-mirror-page`.
* gnu/services/base.scm (guix-shepherd-service)[start]: Accept second
argument, a space-separated list of substitute URLs.
* gnu/installer/final.scm (%user-modules): New variable.
(read-operating-system): New procedure.
(install-system): Read the installation configuration file and extract
substitute URLs to pass to `guix-daemon` start action.
---
 gnu/installer/final.scm | 36 ++-
 gnu/installer/newt/services.scm | 26 +-
 gnu/installer/services.scm  | 62 -
 gnu/services/base.scm   | 15 ++--
 4 files changed, 125 insertions(+), 14 deletions(-)

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index fc0b7803fa..6eca3ec606 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -22,9 +22,13 @@
   #:use-module (gnu installer steps)
   #:use-module (gnu installer utils)
   #:use-module (gnu installer user)
+  #:use-module (gnu services)
+  #:use-module (gnu services base)
   #:use-module (gnu services herd)
+  #:use-module (gnu system)
   #:use-module (guix build syscalls)
   #:use-module (guix build utils)
+  #:use-module (guix ui)
   #:use-module (gnu build accounts)
   #:use-module (gnu build install)
   #:use-module (gnu build linux-container)
@@ -38,6 +42,20 @@
   #:use-module (ice-9 rdelim)
   #:export (install-system))

+;; XXX duplicated from guix/scripts/system.scm, but that pulls in
+;; (guix store database), which requires guile-sqlite which is not
+;; available in the installation environment.
+(define %user-module
+  ;; Module in which the machine description file is loaded.
+  (make-user-module '((gnu system)
+  (gnu services)
+  (gnu system shadow
+
+(define (read-operating-system file)
+  "Read the operating-system declaration from FILE and return it."
+  (load* file %user-module))
+;; XXX
+
 (define %seed
   (seed->random-state
(logxor (getpid) (car (gettimeofday)
@@ -174,6 +192,15 @@ or #f.  Return #t on success and #f on failure."
   options
   (list (%installer-configuration-file)
 (%installer-target-dir
+ ;; Extract the substitute URLs of the user configuration.
+ (os  (read-operating-system 
(%installer-configuration-file)))
+ (substitute-urls (and=> (find
+   (lambda (service)
+ (eq? guix-service-type
+  (service-kind service)))
+   (operating-system-services os))
+ (compose guix-configuration-substitute-urls
+  service-value)))
  (database-dir"/var/guix/db")
  (database-file   (string-append database-dir "/db.sqlite"))
  (saved-database  (string-append database-dir "/db.save"))
@@ -206,8 +233,15 @@ or #f.  Return #t on success and #f on failure."
(lambda ()
  ;; We need to drag the guix-daemon to the container MNT
  ;; namespace, so that it can operate on the 

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

[Léo Le Bouter]

On Tue, 2021-03-16 at 12:12 +0100, Ricardo Wurmus wrote:
> Léo Le Bouter  writes:
> 
> > I am thinking we should really get something like this with the
> > Guix
> > Data Service, start including something similar to Debian
> > uscan/watch
> > rules in every package so we can get reliable (in majority of
> > cases)
> > update notifications.
> 
> “guix lint” has a checker for releases:
> 
> --8<---cut here---start->8---
> $ guix lint -l
> Available checkers:
> […]
> - refresh: Check the package for new upstream releases
> --8<---cut here---end--->8---
> 
> It just needs to be extended to cover more packages.
> 
> Developing a service that runs this for all packages is an orthogonal
> issue.
> 

Just to clarify, I do know it exists and use it often :-)
Indeed it needs to be extended and that's what I am talking about
there, also Guix Data Service is important here because we cannot
possibly each on our sides spam the various URLs or APIs to generate
the release monitoring dataset. Instead, using Guix Data Service for
that with specially configured API keys and else sounds like a better
idea.


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

Re: Release 1.2.1: python2-pylibmc and libmemcached

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi,
>
> On Sat, 13 Mar 2021 at 20:58, Maxim Cournoyer  
> wrote:
>> zimoun  writes:
>
>>> takes ages.  Does it make sense to add something like:
>>>
>>>   (properties
>>>`((max-silent-time . 14400))) ; 4 hours, expected even on x86_64
>
>> libmemcached still seems like a fine package to have in Guix.  I say, if
>> the above change is enough to have it built by the CI, I think it's what
>> we should do :-).
>
> On my machine, the build of libmemcached takes ~5min without the tests.
> And with the test suite, it takes ~570min.  Well, I have been too lazy
> to remove the offending test which takes ages, and compare.  I do not
> know if Cuirass fails to build (time-out?) because an incorrect
> ’max-silent-time’ by default or because another parameter specific to
> Cuirass.

I went ahead and disabled the test suite for libmemcached in commit
9bab0950f7; the tests taking a lot of time were already marked as
expected to fail so it wasn't providing that much value to start with.

Thanks for the report!

Maxim

Re: [opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

On Tue, 2021-03-16 at 12:17 +0100, Jonathan Brielmaier wrote:
> I think the only two reasons against that are: time and
> CI/rebuilding. I
> think thats the reason why stuff like Gnome and others lower in the
> dependency tree are lacking behind... Being non-FHS and non-systemd
> makes updates for those stuff not easier and is maybe the third
> reason/root issue...

I agree with all 3 points. I have hope however that we can develop
better tooling over time to ease the burden on us so we can devote more
time to tasks that actually absolutely **require** our human oversight
to be done. And then even without an increase in the contributor base
we can avoid lagging behind on these updates.


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

Re: [opinion] CVE-patching is not sufficient for package security patching

[Jonathan Brielmaier]

On 16.03.21 12:10, Léo Le Bouter wrote:

For these reasons, I suggest that we always strive to update packages
to their latest versions and that I think it is security relevant to
always do so. Of course, new code could *introduce* new vulnerabilities
but I am not trying to debate this, it's that to the best of the
upstream's knowledge chances are that the latest version will contain
more security fixes than older versions (if that upstream is actually
maintaining the project).


I think the only two reasons against that are: time and CI/rebuilding. I
think thats the reason why stuff like Gnome and others lower in the
dependency tree are lacking behind... Being non-FHS and non-systemd
makes updates for those stuff not easier and is maybe the third
reason/root issue...

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

[Ricardo Wurmus]

Léo Le Bouter  writes:

> I am thinking we should really get something like this with the Guix
> Data Service, start including something similar to Debian uscan/watch
> rules in every package so we can get reliable (in majority of cases)
> update notifications.

“guix lint” has a checker for releases:

--8<---cut here---start->8---
$ guix lint -l
Available checkers:
[…]
- refresh: Check the package for new upstream releases
--8<---cut here---end--->8---

It just needs to be extended to cover more packages.

Developing a service that runs this for all packages is an orthogonal
issue.

-- 
Ricardo

[opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

Hello!

I would like to share some opinion I have on CVE-patching for non-
rolling release GNU/Linux distributions and why we should strive to
always update to the latest available releases or always follow
upstream supported release series and never backport patches ourselves
in most cases (some upstreams may have really good practices but these
are rare).

A lot of security issues are patched silently in upstream projects
without ever getting a CVE, security issues may not be labeled as such
by upstreams for various reasons (fear of shame, belief to patch
something with no security impact while it has, bizarre security
through obscurity policy, ..).

For these reasons, I suggest that we always strive to update packages
to their latest versions and that I think it is security relevant to
always do so. Of course, new code could *introduce* new vulnerabilities
but I am not trying to debate this, it's that to the best of the
upstream's knowledge chances are that the latest version will contain
more security fixes than older versions (if that upstream is actually
maintaining the project).

In many cases, browsing through the commit history of some popular
projects can uncover security issues not publicized through any
security mailing lists or CVEs anywhere, this is unfortunately quite
common. We cannot possibly monitor the commit history (and code) of
every single project to backport fixes when we would need to. It is
better for us to always strive to use the latest versions even when it
requires us to do more far-reaching changes because of
dependents/dependencies.

Let me know what you think!

Léo


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

Fedora/Debian release monitoring inspiration for Guix Data Service

[Léo Le Bouter]

Hello!

It seems Fedora has automated infrastructure and feeds to monitor new
upstream releases so that maintainers can get notifications on them.

https://release-monitoring.org/

Functional feed: 
https://apps.fedoraproject.org/datagrepper/raw?rows_per_page=1=127800=hotness

I could not find the actual data it is based on for release monitoring
(like Debian watch files).

I could not find a similar feed for Debian's watch/uscan but it would
be nice if they provided some sort of RSS feed (global or scoped to
packages or sets of packages).

I am thinking we should really get something like this with the Guix
Data Service, start including something similar to Debian uscan/watch
rules in every package so we can get reliable (in majority of cases)
update notifications.

We could also have some feature that gives you a feed for a manifest or
operating-system definition so that people can prioritize work on what
they care about easily.

I would really love to have some RSS feed for new upstream releases
from Guix Data Service based on my operating-system definition I would
upload there.

We could even go as far as preparing a patch (similar to guix refresh
-u  && etc/committer.scm) and trying to build it and all it's
dependents and if it doesnt cause any new failures we could send an
automated patch contribution on guix-patches directly and tag it with
"ci-update-ok" or something so a maintainer just has to double-check
quickly and push (very efficient workflow). 

Léo


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

Re: guix home

[Andrew Tropin]

> I see.  So do I get it right that `guix home` focuses primarily on
> profile and user service management?  Could you give examples of a
> minimal config and command invocations?

It optionally invades in different parts of the user environment:

- Manages configurations for user programs via home-services.
- Manages a separate profile with packages declared by user or service.
- Manages shell and its environment.
- Starts a shepherd on first login and other long-living processes from
  that.
- (Not yet in master) Manages state (like cloning git repos, bringing
  folder with wallpapers from backup server on new installation),
  potentially it can not only init state, but also sync/backup/archive
  it in the future.

https://git.sr.ht/~abcdw/rde/tree/master/item/examples/home-environment.scm.tmpl
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/README

> Oh nice, now I have to watch those!

Let me know what you think. Will be glad to hear all the comments and
suggestions on both content and delivery.

> I have yet to familiarize myself with ‘guix home’, but overall, I think
> a solution à la ‘guix home’ or guix-home-manager would be a welcome
> addition to Guix.

I would be glad to upstream it. We still completing some must have
features, home-services for important software and generic helpers for
declaring new ones. If you have any tips for simplification upstreaming
of such relatively beefy tool to keep in mind, please share them and I
hope, when `guix home` will be complete enough, the review and merge
process will be less painful.

-- 
Best regards,
Andrew Tropin

Re: [bootstrappable] Re: Can Guile be bootstrapped from source without psyntax-pp.scm?

[Andy Wingo]

On Mon 15 Mar 2021 20:50, Michael Schierl  writes:

> Am 15.03.2021 um 18:09 schrieb Ludovic Courtès:
>> Woow, this is great news!  I think it would be great towards importing
>> it in Guile proper.
>>
>> To do that, I think we should first get Andy’s opinion on the approach.
>
> I don't think upstream is very interested in having psyntax-pp.scm
> bootstrappable.

Why do you say that? :)

> In Guile 3.0.3 they broke even the `make ice-9/psyntax-pp.scm.gen`
> target, and did not repair it even in Guile 3.0.5, that's why I used
> 3.0.2 for the bootstrap.

Strange -- I used it many times over the past couple months without
problems.  But I see now from your patches what the issue was -- and omg
how embarrassing, I must have a stale canonicalize.go file hanging
around in the tree.  Goes to show how important bootstrapping is!

Andy

Re: guix home

[Andrew Tropin]

Joshua Branson  writes:

> I'll have to give your guix home command a try!  It sounds easy!

One of the goals is to make it effortless to use) For now we still
implement services for basic software and some fundamental features, but
in a couple of weeks plan to invite few more people to actively use
`guix home`. Follow the news on rde-announces mailing list [fn:1].

Thank you for kind supportive words!

Ryan Prior  writes:

> Thanks for sharing this Andrew, it looks awesome & I'm going to give it
> a try!

You are very welcome!)

> What do you think about changing the command? It manages user files,
> user services, user environment variables, the lifecycle of user
> sessions. So we could have "guix system" for system-level things, and
> "guix user" for user-level things.

I don't have very strong preference here and open for discussion, but
will provide my rationale for original naming:

- `guix system` manages operating systems and its generations and stuff.
- `guix package` installs, removes, upgrades packages.

Following this convention `guix user` would have to manage users, while
`guix home` manages user's home folders and related stuff. I find home
subcommand more suitable here, however other internal naming may be
temporary and is a subject to change if better options are found.

> Similarly, many of the services you describe sound to me like they
> would be easier to understand what they do with names like
> "user-service," "user-environment-vars," etc.

It's maybe true, however, the other benefit of home- naming is it makes
all the related concepts distinct. It will be harder to confuse
home-services with systemd user service for example. Still have to work
on a better naming in some places.

> I feel Guix needs something like this upstream. Whether this is the
> right implementation or not I'm not qualified to judge, but I'll read
> the source code and see what I can learn or contribute!

All the contributions from discussions to patches are welcome!)

* Footnotes

[fn:1] https://lists.sr.ht/~abcdw/rde-announce

-- 
Best regards,
Andrew Tropin

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Léo Le Bouter]

On Tue, 2021-03-16 at 09:08 +0200, Efraim Flashner wrote:
> On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote:
> > How shall we build the binary tarball for the release?  Of course,
> > anybody with a copy of the (source) release tarball can build their
> > own
> > guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
> > themselves.  However, for convenience, it would be nice to provide
> > a
> > pre-built binary if possible.  Shall I build this myself when the
> > time
> > comes, or would people prefer to do it a different way?
> > 
> 
> When aarch64 support was very new I gave ludo access to my board and
> he
> offloaded the build to it.
> 
> 

We have one ppc64le VM from OSUOSL which would qualify as "GNU Guix
owned" that nckx, myself, Efraim and Vincent Legoll have access to, so
we should definitely use that. We will be working into having that VM
added into Cuirass CI as soon as possible after merge into master too.


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

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Efraim Flashner]

On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote:
> 
> How shall we build the binary tarball for the release?  Of course,
> anybody with a copy of the (source) release tarball can build their own
> guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
> themselves.  However, for convenience, it would be nice to provide a
> pre-built binary if possible.  Shall I build this myself when the time
> comes, or would people prefer to do it a different way?
> 

When aarch64 support was very new I gave ludo access to my board and he
offloaded the build to it.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature