Re: 2443 packages indirectly depend on unsupported openssl@1.0.2u

On Thu, Mar 11, 2021 at 05:46:47AM +0100, Léo Le Bouter wrote: > Hello! > > $ ./pre-inst-env guix refresh -l openssl@1.0.2u > Building the following 2320 packages would ensure 2443 dependent > [...] > > As upstream says at >: > > Version 1.0.2

Re: Commit pushed to master with unauthorised signature

On Thu, 2021-03-11 at 00:15 +0100, Taylan Kammer wrote: > [...] > Damn, sorry about that. I assumed of course that an improperly signed > commit would not be accepted, so I didn't pay any special mind. > > However, I also assumed that adding a new GPG key to my savannah.gnu.org > account would be

guix home

Hi guix! There is an implementation of `guix home` subcommand, which behaves similar to `guix system`, allowing declaratively manage applications and their configurations, but for a particular user, not the whole OS: https://git.sr.ht/~abcdw/rde/tree/master/item/gnu * Overview It possible to defi

2443 packages indirectly depend on unsupported openssl@1.0.2u

Hello! $ ./pre-inst-env guix refresh -l openssl@1.0.2u Building the following 2320 packages would ensure 2443 dependent [...] As upstream says at : > Version 1.0.2 is no longer supported. Extended support for 1.0.2 to gain access to security fi

GNOME 3.34 in GNU Guix and security

Hello! I must come to the conclusion that using GNOME 3.34 in GNU Guix right now is just straight out insecure. I would advise we either, get rid of GNOME, backport all individual security patches (they can be numerous..), or upgrade GNOME to latest and keep up over time. I don't think we can aff

pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

CVE-2021-21375 00:15 PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In PJSIP version 2.10 and earlier, after an initial INVITE has been sent, when two 183 responses are receive

Re: GNU Guix (pull?) on i686 broke after zstd grafting

On Wed, 2021-03-10 at 11:37 +0100, Ludovic Courtès wrote: > So I think there’s a genuine bug here. Could you take a look? At > worst, we should skip the offending test on i686 (and perhaps > ARMv7?). I pushed 2bcfb944bdd2f476ef8d34802fed436e4fdda0ab which disables tests entirely in the graft. A

GNOME Orca 'orca' package mislabeled by 'guix lint -c cve'

This is GNOME Orca in the CPE database: https://nvd.nist.gov/products/cpe/detail/660937?namingFormat=2.3&orderBy=CPEURI&keyword=orca&status=FINAL Currently CVE-2020-9298 is being wrongly reported by 'guix lint -c cve' because vendor is not taken into account, therefore: "cpe:2.3:a:spinnaker:orca"

glib@2.62.6 is vulnerable to CVE-2021-27218 and CVE-2021-27219

Upstream does not provide fixes for the 2.62.x series so we need to backport ourselves. I would rather switch to upstream-supported version (2.66.x or later) as backporting patches does not appear sustainable for us, we already have enough on our plate. See: - https://gitlab.gnome.org/GNOME/glib/

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

zimoun 写道： Therefore, is it possible to “restart” the build on Cuirass I used ‘guix build’, not Cuirass (AIUI its CLI is still ‘poke the SQL database with a stick’?). Kind regards, T G-R signature.asc Description: PGP signature

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

Simon, zimoun 写道： Attached, the list of the 180 ghc-* packages. I've started the builds on berlin except haddock. Not restarted: none of these had failed. Judging by how quickly it finished I think most of them had already been built, but I didn't pay enough attention to be certain. Kind

Re: Commit pushed to master with unauthorised signature

On 10.03.2021 22:22, Tobias Geerinckx-Rice wrote: > Earlier today the following commit was pushed to master: > > --8<---cut here---start->8--- > commit 15092548804b6c50ea276d098f76a79bd0042398 > gpg: Signature made Wed Mar 10 19:55:39 2021 CET > gpg:   

Release 1.2.1: Remove 31 Python 2 packages

Hi, Using “guix weather --display-missing” at commit 6bed29b, I have identified these 31 Python 2 packages to remove: --8<---cut here---start->8--- python2-arrow python2-cairocffi python2-cairocffi python2-dulwich python2-fido2 python2-flask python2-flask-babel

Commit pushed to master with unauthorised signature

Guix, I have very little time to write a proper post-mortem. Luckily, thanks to the prompt help of rwp of #savannah fame and Ludo's sane ‘guix pull’ design, there's not much to report, although there's something to improve. Despite the scary title, at no point did anything untoward or mali

Release 1.2.1: Cuirass failed to build Haskell 179 packages

Hi, Using the command “guix weather --display-missing” at commit 6bed29b, I identify 180 packages ghc-* which are missing. Then I locally rebuild all of them and they build successfully. The only one broken is: ghc-haddock Therefore, is it possible to “restart” the build on Cuirass of these

Re: bsdiff package vulnerable to CVE-2020-14315

On Wed, 2021-03-10 at 12:32 -0500, Leo Famulari wrote: > Well, we could also just remove this package. It sounds like it is > not > supported on Linux. Does it offer some unique functionality? I would advocate for removal of the package, or at least warning about absence of security patches for se

Release 1.2.1: remove clang@3.6?

Hi, The package clang-runtime@3.6.2 is broken (commit 6bed29b) and giving a look to: it seems broken since long time. I propose to remove: clang clang-runtime clang-toolchain @3.6.2. Any objection?

Re: Generate diff with git-diff and use in patches field of packages

Hi Leo, On Wed, 10 Mar 2021 at 13:06, Leo Famulari wrote: > On Wed, Mar 10, 2021 at 06:49:37PM +0100, zimoun wrote: >> I could miss something but I was not suggesting to cherry-pick. :-) >> Cherry-picking means use the current packaged version and backport to it >> the commit(s) fixing the issue

Re: Release on April 18th?

On March 10, 2021 3:59:07 PM UTC, zimoun wrote: >Hi Efraim, > >On Wed, 10 Mar 2021 at 17:30, Efraim Flashner >wrote: > >>> Does it make sense to merge wip-ppc64le and core-updates? >>> >> I wanted an Easy Win™ and I've pushed a branch >wip-ppc64le-for-master, >> which cherry-picked (I think)

Re: Generate diff with git-diff and use in patches field of packages

Hi Leo, On Wed, 10 Mar 2021 at 12:09, Leo Famulari wrote: > On Wed, Mar 10, 2021 at 02:42:32PM +0100, zimoun wrote: >> If the package already uses git-fetch, why not directly uses the commit >> fixing the issue as source? > > It's different to build from a Git commit vs to cherry-pick a single >

Re: Generate diff with git-diff and use in patches field of packages

On Wed, Mar 10, 2021 at 06:49:37PM +0100, zimoun wrote: > I could miss something but I was not suggesting to cherry-pick. :-) > Cherry-picking means use the current packaged version and backport to it > the commit(s) fixing the issue. I know you were not suggesting to cherry-pick. But that is what

Re: Generate diff with git-diff and use in patches field of packages

On Wed, 10 Mar 2021 at 12:09, Leo Famulari wrote: > However, I think it's more reliable to include the patches in Guix > itself, and a lot easier for other packagers — including from other > distros — to read them. I often look at what other distros have done > when deciding how to fix things in

Re: bsdiff package vulnerable to CVE-2020-14315

On Wed, Mar 10, 2021 at 09:49:57AM +0100, Léo Le Bouter wrote: > A patch exists from FreeBSD: > https://www.freebsd.org/security/patches/SA-16:29/bspatch.patch - but > it needs non-trivial porting since FreeBSD seems to have diverged in > important ways from the source tree we use. > > Debian, Fe

Re: Generate diff with git-diff and use in patches field of packages

On Wed, Mar 10, 2021 at 02:42:32PM +0100, zimoun wrote: > If the package already uses git-fetch, why not directly uses the commit > fixing the issue as source? It's different to build from a Git commit vs to cherry-pick a single commit.

Re: Generate diff with git-diff and use in patches field of packages

On Wed, Mar 10, 2021 at 04:11:34AM +0100, Léo Le Bouter wrote: > Hello! > > While patching packages for security issues, I often am needing to get > some patches from git repos because upstream does not make releases. > > Including patch in "patches" directory etc. is a bit troublesome, I > would

Re: Will 2021 be the year of build systems on gexps?

On Wed, Mar 10, 2021 at 03:12:42PM +0100, zimoun wrote: > I do not think it interferes with the release since for now and except a > big change, the plan is to release without the core-updates merge. > Well, that’s my understanding of the previous discussion. That's my understand as well.

Re: Release on April 18th?

Hi Efraim, On Wed, 10 Mar 2021 at 17:30, Efraim Flashner wrote: >> Does it make sense to merge wip-ppc64le and core-updates? >> > I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master, > which cherry-picked (I think) all of the powerpc64le commits and > adjusted them to work ag

Re: Release on April 18th?

On Wed, Mar 10, 2021 at 02:27:47PM +0100, zimoun wrote: > Hi Chris, > > On Tue, 09 Mar 2021 at 10:17, Chris Marusich wrote: > > zimoun writes: > > > >> Is it doable to have core-updates merged in the next weeks? Or not at > >> all. > > > > Do we plan to upgrade GCC? This is required for the po

Re: Will 2021 be the year of build systems on gexps?

Hi Ludo, On Wed, 10 Mar 2021 at 12:09, Ludovic Courtès wrote: > The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being built, > it can build ‘guix’ and cross-build things like ‘sed’: > > > https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp > > https

Re: Generate diff with git-diff and use in patches field of packages

Hi, On Wed, 10 Mar 2021 at 04:11, Léo Le Bouter wrote: > While patching packages for security issues, I often am needing to get > some patches from git repos because upstream does not make releases. If the package already uses git-fetch, why not directly uses the commit fixing the issue as sour

Re: Release on April 18th?

Hi Chris, On Tue, 09 Mar 2021 at 10:17, Chris Marusich wrote: > zimoun writes: > >> Is it doable to have core-updates merged in the next weeks? Or not at >> all. > > Do we plan to upgrade GCC? This is required for the powerpc64le-linux > port; see below for details. You mean replace gcc-7 by

Re: 04/07: inferior: Break cached-channel-instance into two procedures.

Hey, > We need to keep ‘cached-channel-instance’ because it’s part of the > public API and used outside Guix (in Guix-Jupyter at least). We can use > ‘define-deprecated’. > > Also, I think ‘cached-profile’ doesn’t quite capture what this is > about. :-) The docstring should mention what COMMI

Re: 05/07: inferior: Fix concurrent cached-profile calls.

Hey Ludo, > However, there’s already a (file-exists? cached) call a few lines > above. So what you need instead is a TOCTTOU-free ‘symlink’, along > these lines: > > (define (symlink/safe old new) > (catch 'system-error > (lambda () > (symlink old new)) > (lambda args

Re: Will 2021 be the year of build systems on gexps?

If we aim at merging c-u before next release, we should probably wait next cycle, as this introduces quite a lot of changes, and packages might break in subtle ways. 10% increase for computing derivations is not great :/ it already takes a long time to do that on my arm system ^^". I wonder how

Re: Will 2021 be the year of build systems on gexps?

Hello! Ludovic Courtès skribis: > Over the last few days I’ve been head-down working on > ‘wip-build-systems-gexp’, the mythical branch that brings gexps to build > systems and packages, so we can say goodbye to > ‘build-expression->derivation’. And… it’s quite a ride! The current tip of ‘wip-

Re: Joining the Guix family

Hi Lars, Lars-Dominik Braun skribis: > today I’m joining the Guix family as a new committer. Some of you might > know me already from guix-patc...@gnu.org or the last Guix Days in > Brussels, which I also attended. Woohoo, welcome on board! :-) Please double-check

Re: Implications of QEMU binfmt transparent emulation for builds

Hi Chris, Christopher Baines skribis: > Anyway, something that's been on my mind regarding QEMU and builds is > how well this matches up with building natively. In particular, I'm > concerned that there are some derivations that will build on system A > with some QEMU configuration allowing bina

Re: GNU Guix (pull?) on i686 broke after zstd grafting

On Wed, 2021-03-10 at 11:37 +0100, Ludovic Courtès wrote: > Hi Léo, Hi Ludo! > So I think there’s a genuine bug here. Could you take a look? At > worst, we should skip the offending test on i686 (and perhaps > ARMv7?). I reported upstream and I got an answer, waiting for fix but also we could

Re: I've rebased wip-ppc64le onto core-updates

On Wed, Mar 10, 2021 at 11:17:02AM +0100, Ludovic Courtès wrote: > Hi Chris, > > Chris Marusich skribis: > > > I just wanted to let you know that I've rebased the wip-ppc64le branch > > onto core-updates. The wip-ppc64le branch head used to be > > 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but n

Re: GNU Guix (pull?) on i686 broke after zstd grafting

Hi Léo, Léo Le Bouter skribis: > After commit: > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=6f873731a030dd7ecbd8a5e756b38b26306f6966 > > This happened: > https://ci.guix.gnu.org/build/369538/details > > I made the commit, and not sure what to do here. > > The test suite seems to fail

Re: Getting the Guix Build Coordinator agent working on the Hurd

Hi, Christopher Baines skribis: >> There are open questions as to what to include in the build environment: >> >> https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ > > Isolation would be nice of course, although I'm not sure how much this > will affect reproducibility, unless thing

Re: Getting rid of the mandb profile hook?

Hi Brice, Brice Waegeneire skribis: > On 2021-03-03 15:13, Ludovic Courtès wrote: [...] >> I looked a bit at man-db, thinking it must have that already done >> more >> or less. Indeed, one can run “mandb -uc” to create the database. >> The problem is that it insists on writing databases and >

Re: TOCTTOU race

Hi Maxime, Maxime Devos skribis: > On Tue, 2021-02-23 at 16:30 +0100, Ludovic Courtès wrote: >> Hi, >> >> Maxime Devos skribis: >> >> > Is all addressed now? (Aside from the TOCTTOU.) >> >> Yes, thank you! > > If all is addressed now, could you apply the patch? > I don't see it in master yet

Re: 04/07: inferior: Break cached-channel-instance into two procedures.

Hi Mathieu! guix-comm...@gnu.org skribis: > commit 7d63b775513e7049047222dbe403a4181f63828d > Author: Mathieu Othacehe > AuthorDate: Fri Mar 5 09:51:42 2021 +0100 > > inferior: Break cached-channel-instance into two procedures. > > Break cached-channel-instance into two different pr

Re: I've rebased wip-ppc64le onto core-updates

Hi Chris, Chris Marusich skribis: > I just wanted to let you know that I've rebased the wip-ppc64le branch > onto core-updates. The wip-ppc64le branch head used to be > 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's > df5d633db7acf6389ca9d444b8f5784a0da5ac5d. > > I wanted to inform you

Re: guix environment --profile with --ad-hoc

Hi, > Can I ask: What is your use-case? Why not extend the existing profile > using `guix package -p /path -i foobar`? I'm making a script that uses guix containers for running applications isolated from eachother, and I have a single profile for each application. I want to be able to start the c

Re: Adding Substitute Mirrors page to installer

Hello, Below I have a patch that adds a page for substitute mirrors. Limitation is that the substitute mirror is only used after installation completes. During installation the guix daemon still loads from the Berlin server. Also, channel is still the default Guix channel (which is fairly slo

Re: 05/07: inferior: Fix concurrent cached-profile calls.

Hi Mathieu, guix-comm...@gnu.org skribis: > commit 6ee7e3d26b8f5d2a234518cc2ab1bfeba7cd7c18 > Author: Mathieu Othacehe > AuthorDate: Fri Mar 5 12:49:06 2021 +0100 > > inferior: Fix concurrent cached-profile calls. > > * guix/inferior.scm (cached-profile): Do not create the profile s

bsdiff package vulnerable to CVE-2020-14315

CVE-2020-14315 A memory corruption vulnerability is present in bspatch as shipped in Colin Percival’s bsdiff tools version 4.3. Insufficient checks when handling external inputs allows an attacker to bypass the sanity checks in place and write out of a dynamically allocated buffer boundaries. A p

Re: Release on April 18th? (ppc64le support specifically)

On Tue, Mar 09, 2021 at 10:32:18PM +0100, Vincent Legoll wrote: > Hello Chris, > > I'm all for that, what can I do to help ? > > I don't have a Talos, though... > > So only cross- or emulated- stuff... > > Willing to help, but needs directions. > The two ways forward that I can see is to figu