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

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

Re: guix home

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

Re: guix home

> 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

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

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

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

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

Re: Release 1.2.1: python2-pylibmc and libmemcached

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

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

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.

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

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

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

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

Fedora/Debian release monitoring inspiration for Guix Data Service

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

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

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

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

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

Re: Adding Substitute Mirrors page to installer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]:

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

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

Re: CVEs missing from the NIST database

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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 &

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

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

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

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

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

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