Re: Staging branch [kwayland test failure]

On Wed, Jan 27, 2021 at 11:26:52AM +0100, Guillaume Le Vaillant wrote: > It looks like the kwayland test failure on x86-64 doesn't happen all the time. > I just built it successfully on master and on staging by trying again > when the build failed. Thanks, that is useful info! I'll try building it

Re: Staging branch [kwayland test failure]

On Wed, Jan 27, 2021 at 02:44:42PM -0500, Leo Famulari wrote: > On Wed, Jan 27, 2021 at 11:26:52AM +0100, Guillaume Le Vaillant wrote: > > It looks like the kwayland test failure on x86-64 doesn't happen all the > > time. > > I just built it successfully on master and

Potential security weakness in Guix services

On January 19 2021, we received a message from Maxime Devos describing a potential attack vector on Guix System. If an attacker can exploit a remote code execution vulnerability (RCE) in a program used by a Guix service, they could use it to take over the system in some cases. We have not deployed

Re: branch staging updated (5aeee07 -> 104151f)

On Fri, Jan 29, 2021 at 05:05:35PM -0500, guix-comm...@gnu.org wrote: > htgoebel pushed a change to branch staging > in repository guix. > > from 5aeee07 gnu: VLC: Remove obsolete patch. > new 9085260 guix: qt-build-system, qt-utils: Unify wrapping of > qt-programs. > new 4ecc2a2

Re: branch staging updated (5aeee07 -> 104151f)

On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: > What would the Git hook do, precisely? The reason I ask is that some > bug fixes are appropriate on a frozen branch. How would a Git hook > determine whether a given commit should be allowed? I haven't given much thought to how it

Re: staging on i686-linux

On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote: > I tried to upgrade my i686-linux system to staging. I reconfigured > successfully, but I had to hold back a package upgrade that depends on > gst-plugins-good, which fails its tests. Here is the relevant portion of the test log: -

Re: staging on i686-linux

On Sun, Jan 31, 2021 at 12:26:10AM -0500, Leo Famulari wrote: > On Sun, Jan 31, 2021 at 01:06:45AM +0100, Ricardo Wurmus wrote: > > I tried to upgrade my i686-linux system to staging. I reconfigured > > successfully, but I had to hold back a package upgrade that depends on >

Re: branch staging updated (5aeee07 -> 104151f)

On Mon, Feb 01, 2021 at 08:43:19PM +, Christopher Baines wrote: > > Efraim Flashner writes: > > > >> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote: > >>> Hi, > >>> > >>> maybe the process should be the other way round: > >>> > >>> staging -> "staging-frozen" -> master > >>>

Re: Blog post about the upcoming FOSDEM + Guix Day

On Mon, Feb 01, 2021 at 04:57:58PM +0100, Pjotr Prins wrote: > So far, we'll have a GNU Hurd session and a Rust packaging session. We > will also discuss ARM, RISC-V and GNU Mes. Otherwise the program is > open for newbies and unconference topics alike. If you want to propose > something this may b

Re: Staging branch

The staging branch has been merged to master in commit 75b775e81b5a81a59656eeba8811b42f45d503da Hooray! Thanks to everyone that helped out with bug reports, fixes, CI assistance, etc. There is some discussion about changes to the branch workflow: https://lists.gnu.org/archive/html/guix-devel/20

Re: PowerShell core?

On Tue, Feb 02, 2021 at 06:35:14PM +0100, Nicolò Balzarotti wrote: > Bengt Richter writes: > > > Hi Yasu, > > > > "Just curious", what do you hope will be the effect of your post? > > > Hi Bengt Richter, thanks for asking the same things I had in mind. This > post seems just M$ propaganda, more

Re: PowerShell core?

On Tue, Feb 02, 2021 at 10:41:03PM +0100, Tobias Geerinckx-Rice wrote: > Still, we don't boycott malicious upstreams (ungoogled-chromium & worse) and > PowerShell looks like a welcome attempt to pull command interpreters out of > the 70s. > > Due to its (apparent) verbosity it looks better suited

Re: Blog post about the upcoming FOSDEM + Guix Day

On Tue, Feb 02, 2021 at 07:07:47PM +0100, Ludovic Courtès wrote: > Here we go! > > https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/ People in #guix were asking, "When exactly does it start?" Can we update the blog post to say?

Re: Branch management, wip-ppc64le, and POWER9

On Thu, Feb 04, 2021 at 09:38:43AM +, Christopher Baines wrote: > > Specifically, I'm curious to know: > > > > - Is it usually expected that wip branches can be rebased? I don't plan > > to rebase wip-ppc64le, since I'd like to be able to coordinate with > > others using this branch, but I

Re: Branch management, wip-ppc64le, and POWER9

On Thu, Feb 04, 2021 at 01:53:37PM -0500, Leo Famulari wrote: > The signatures will be lost, but for "wip-" branches the expectation has > always been that history may be rewritten. For me, rebasing is a more > comfortable workflow for this kind of exploratory branch. I recomm

Re: Blog post about the upcoming FOSDEM + Guix Day

On Fri, Feb 05, 2021 at 11:37:49AM +0100, Ludovic Courtès wrote: > On IRC Leo (American timezone) was thinking about having a session to > discuss branching strategies, and there were also discussions about > substitute availability and continuous builds for QA. Yes, I think we can discuss branchi

Re: Building the core-updates branch.

On Sun, Feb 07, 2021 at 07:43:50PM +0100, Mathieu Othacehe wrote: > > > Turns out "core-updates" is still configured to build the "core" subset, > > I don't really understand why the evaluation 74281 triggered the build > > of so many packages. > > Just fixed it with 2c30440f89244202bddebe76f90c6

Re: Guix Day: Notes from the CI session

On Mon, Feb 08, 2021 at 06:07:25PM +0100, Ludovic Courtès wrote: > ## Open issue: new machines > > - fast ARM servers available > - criteria for hardware? > - must run free system (stock Guix System) > - hosting? > - the MDC (in Berlin) wouldn't host Guix-specific non-x86 servers >

Re: Guix Day: Notes from the CI session

On Mon, Feb 08, 2021 at 06:07:25PM +0100, Ludovic Courtès wrote: > ## Open issue: branching strategy > > - currently: building all of `master` + the "core" of `core-updates` > - schedule > - currently ad-hoc: volunteers get to choose when to freeze/merge > - actions > - pushes to `co

Re: branch naming conventions [was Re: Guix Day: Notes from the CI session]

On Wed, Feb 10, 2021 at 04:09:15PM +0200, Efraim Flashner wrote: > My concern about that is that it basically swaps what we have now. Using > -frozen makes it a bit clearer that we're building it out. Good idea, I like it.

Re: Guix Day: Notes from the CI session

On Wed, Feb 10, 2021 at 06:11:08PM +0100, Mathieu Othacehe wrote: > Thanks to Ricardo support I was able to setup a Wireguard tunnel between > berlin and the overdrive1. It seems to work pretty well and > https://ci.guix.gnu.org/workers shows that it is building some packages. > > I plan to connec

Re: GWL 0.3.0 released

On Thu, Feb 11, 2021 at 07:03:31PM +, Cook, Malcolm wrote: > > Do we know if a video recording Ricardo’s FOSDEM talk is/will be available? > I don’t (yet?) see it in FOSDEM’s Youtube channel. Thanks! Videos are on the way: https://twitter.com/bitcynth/status/1358761774577819650

Re: branch naming conventions [was Re: Guix Day: Notes from the CI session]

On Wed, Feb 10, 2021 at 10:49:04PM +0100, Ludovic Courtès wrote: > Leo Famulari skribis: > > > On Wed, Feb 10, 2021 at 04:09:15PM +0200, Efraim Flashner wrote: > >> My concern about that is that it basically swaps what we have now. Using > >> -frozen makes it a bit

Re: Guix Day: Notes from the CI session

On Thu, Feb 11, 2021 at 10:04:43PM +0100, Andreas Enge wrote: > that is not quite what I objected :) I think that if we buy many > not so expensive machines, we could host them at people's homes. I was > just a bit hesitant that individuals host a 1€ machine. If there > is only one or two, I m

Changes to the branching workflow

Based on experiences with the last "staging" cycle and discussions at the most recent Guix Day meeting [0], we've changed the branching workflow. The default branch names remain "core-updates" and "staging". When we begin actively building and testing the branches, they will be renamed to "core-u

Re: Changes to the branching workflow

On Fri, Feb 12, 2021 at 11:34:13AM +0100, Tobias Geerinckx-Rice wrote: > Leo Famulari 写道： > > During those periods, new patches can be pushed to "core-updates-next" > > and "staging-next". > > I suggest just ‘branching’ staging & core-updates to

Re: Changes to the branching workflow

On Fri, Feb 12, 2021 at 08:34:34PM +0100, Tobias Geerinckx-Rice wrote: > Ah, there's my blind spot. What kinds of mistakes? When is it harmful to > push to the open branch? Mistakes caused by lack of communication about the status of the branches. During the recent staging cycle, people kept pu

Re: Changes to the branching workflow

On Sat, Feb 13, 2021 at 12:24:50PM +0100, Hartmut Goebel wrote: > Am 12.02.21 um 21:49 schrieb Andreas Enge: > > From what I understood of the discussion, I would also go with Tobias's and > > Efraim's suggestion: There is a core-updates branch that is constantly open > > and where people can push

Re: Guix Day: Notes from the CI session

On Wed, Feb 10, 2021 at 06:11:08PM +0100, Mathieu Othacehe wrote: > Thanks to Ricardo support I was able to setup a Wireguard tunnel between > berlin and the overdrive1. It seems to work pretty well and > https://ci.guix.gnu.org/workers shows that it is building some packages. I noticed that the n

Re: Guix Day: Notes from the CI session

On Sun, Feb 14, 2021 at 09:42:46AM +0100, Mathieu Othacehe wrote: > > Hey Leo, > > > I would have guessed that a single slot is appropriate for the machine, > > but I'm curious what you saw that led to the change? > > This is most likely due to a worker crash. Workers are removed from the > data

Linux-libre 5.11

I pushed the addition of linux-libre 5.11 to the kernel-updates Git branch: https://git.savannah.gnu.org/cgit/guix.git/log/?h=kernel-updates And CI is building it (the x86_64 is already built and the i686 kernel should be done in about an hour): https://ci.guix.gnu.org/jobset/kernel-updates Fee

Re: Release on April 18th?

On Tue, Mar 02, 2021 at 03:51:33PM +0100, zimoun wrote: > I would like to propose to release on April 18th (anniversary of the > "Initial commit."). It could be 1.2.1 or 1.3. Well, from my > understanding, if core-updates is merged it makes sense to have 1.3 > otherwise 1.2.1 seems reasonable. W

Re: Release on April 18th?

On Wed, Mar 03, 2021 at 03:16:29PM +0100, Ludovic Courtès wrote: > I’m all for 1.2.1 ASAP, notably because of important bug fixes: > > https://issues.guix.gnu.org/46330 > https://issues.guix.gnu.org/44559 > > We’ve also accumulated a whole bunch of new features. > > Thoughts? More TODOs tha

Re: Release on April 18th?

On Thu, Mar 04, 2021 at 10:41:34AM +0100, zimoun wrote: > On Wed, 03 Mar 2021 at 13:51, Leo Famulari wrote: > > * Update tzdata > > “guix refresh tzdata -l” provides couple of dependants. Is it > reasonable to update it for the next release? For me, I see 1765 dependents (a

Re: Release on April 18th?

On Thu, Mar 04, 2021 at 11:18:19PM +0100, zimoun wrote: > I should have had emphasized «couple». ;-) > Ah, I miss something because I thought this kind of upgrade was a > candidate for core-updates or staging. > Anyway. :-) It is usually is, but we can be confident that it won't break anything, ba

Re: Release on April 18th?

On Fri, Mar 05, 2021 at 03:31:22PM +0100, Andreas Enge wrote: > it would be nice if core-updates could be part of the release. I have > been waiting for gmp, mpfr and mpc to appear in master. In particular > mpfr-4.1.0 has been released in July 2020, and I have updated it in > core-updates in the s

Re: Release on April 18th?

On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote: > * Update tzdata > > * Ungraft I've pushed commits that accomplish these tasks to a 'wip-next-release' branch: https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-next-release For now, the branch is a &quo

Re: Release on April 18th?

On Wed, Mar 03, 2021 at 03:16:29PM +0100, Ludovic Courtès wrote: > zimoun skribis: > > > I would like to propose to release on April 18th (anniversary of the > > "Initial commit."). It could be 1.2.1 or 1.3. Well, from my > > understanding, if core-updates is merged it makes sense to have 1.3 >

Re: Release on April 18th?

s people have been maintaining private branches with specific updates cherry-picked and can vouch that they are working well. > On Fri, 05 Mar 2021 at 14:27, Leo Famulari wrote: > > Simon, is there a reason you chose April 18 for the release? Or could we > > choose a later date? >

Re: Heads-up from Linus -- potential bisection trainwreck: "A note on the 5.12-rc1 tag"

On Fri, Mar 05, 2021 at 06:54:05AM +0100, Bengt Richter wrote: > Hi, > > Not so usual to be switching rc kernels for guix I suppose, but > this looked worth mentioning anyway: > > LWN archive link [1] > > [1]https://lwn.net/ml/linux-kernel/CAHk-=wjnzdlsp3odxhf9emtyo7gf-qjanlbuh1zk3c4a7x7...@mail

Re: Packaging

On Sat, Mar 06, 2021 at 09:14:49AM -0500, Joshua Branson wrote: > mecqor labi writes: > > > Please package (Dialect) for Guix; Thanks > > > > (This is not my primary email) > > > > These kind of questions are probably best directed toward > help-g...@gnu.org. :) Also, it sounds like dialect > (

Re: Release on April 18th?

On Sat, Mar 06, 2021 at 12:58:52AM +0100, zimoun wrote: > Hi Leo, > > On Fri, 05 Mar 2021 at 15:19, Leo Famulari wrote: > > On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote: > >> * Update tzdata > >> > >> * Ungraft > > > > I&#

Re: Release on April 18th?

On Wed, Mar 03, 2021 at 01:51:51PM -0500, Leo Famulari wrote: > More TODOs that I think are possible in this timeframe: > > * Fix #46871 (problems with init scripts and guix-install.sh). > > * Update tzdata > > * Ungraft I remembered that we also have a few packages

Re: Release on April 18th?

On Sat, Mar 06, 2021 at 02:06:44PM -0500, Leo Famulari wrote: > I remembered that we also have a few packages that we aim to remove > sooner or later: > > Qt 4 <https://bugs.gnu.org/45704> I pushed a commit to wip-next-release that removes Qt 4 and all its users. Unfortunat

Re: Release on April 18th?

On Sun, Mar 07, 2021 at 12:39:04AM -0500, Raghav Gururajan wrote: > Hi Leo! > > > > Unfortunately, a package was added recently that depends on Qt 4 > > > (telegram-desktop). Hopefully its dependency graph can be updated to use > > > Qt 5. > > > > IIRC, telegram-desktop uses Qt5. > > > > Was it

Re: Release on April 18th?

On Sun, Mar 07, 2021 at 12:39:04AM -0500, Raghav Gururajan wrote: > Hi Leo! > > > > Unfortunately, a package was added recently that depends on Qt 4 > > > (telegram-desktop). Hopefully its dependency graph can be updated to use > > > Qt 5. > > > > IIRC, telegram-desktop uses Qt5. > > > > Was it

Re: core-updates: Emacs is only supported on x86_64-linux?

On Sun, Mar 07, 2021 at 05:46:24AM -0500, Mark H Weaver wrote: > For now, I suggest that Emacs should have input 'librsvg' only on > 'x86_64-linux' systems. Something like this (untested), for > core-updates: I think this is the right approach. We do something similar for FFmpeg with its dependen

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: 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: 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: 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 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: 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, Mar 11, 2021 at 12:15:19AM +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. The security model is based on the client-side, i.e. `guix pull`. That way, we don't have to tru

Re: CVEs missing from the NIST database

On Fri, Mar 12, 2021 at 04:31:59PM +0100, Ludovic Courtès wrote: > It could be that this CVE is still “pending” (I think that happens > sometimes). Do you know more about this one? I found some references from other distros: https://access.redhat.com/security/cve/cve-2020-35492 https://security-

Re: Examples on why ungrafting is necessary

On Thu, Mar 11, 2021 at 02:16:16PM +0100, zimoun wrote: > Updating the package r-chemminer, it leads to this huge stack of > grafts. To be concrete, it is 84 grafts for a “simple” R packages. On > my machine, the grafting steps are longer than building (compiling and R > dance). The performance

Re: Release 1.2.1: timeline

On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote: > > The architecture armf will not be included. > > Wait wait, I missed that. What happened? I think we should include it, > even if substitute availability remains low. I had asked about the status of the armhf branch on #guix wh

Re: Release 1.2.1: timeline

On Mon, Mar 15, 2021 at 02:14:52PM -0400, Leo Famulari wrote: > On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote: > > > The architecture armf will not be included. > > > > Wait wait, I missed that. What happened? I think we should include it, > > e

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 r

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 TOCTOU

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.

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 tryi

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 la

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 problem

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 sys

Re: Are gzip-compressed substitutes still used?

On Thu, Mar 18, 2021 at 09:00:20AM -0700, Vagrant Cascadian wrote: > Except for issues like the openssl bug which causes build failure due to > certificate expiry in the test suite basically would break guix pull in > those cases... maybe that is a deal breaker for the Debian packaged > guix... To

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote: > I knew this couldn't be right, but I thought I remembered it having > fewer dependencies. Oh well. Sorry for the noise. It's relatively new that ImageMagick is depended on by so many packages. I think we should look into this and s

Re: Release 1.2.1: status

On Fri, Mar 19, 2021 at 09:50:55AM +0100, zimoun wrote: > The release work happens on master. The branch wip-next-release > contains fixes, but AFAIK, it is not built by the CI, and these fixes > are ’core-updates’-like changes; I do not know if it is doable to merge > on time. I agree. The scope

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

On Fri, Mar 19, 2021 at 08:14:03PM -0400, Mark H Weaver wrote: > Leo Famulari writes: > > > On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote: > >> I knew this couldn't be right, but I thought I remembered it having > >> fewer dependenc

Re: Release 1.2.1: status

I suggest we use debbugs to keep track of tasks for the release. We can create a new bug called "1.2.1 release checklist". This bug can be made to depend on other bugs using the "block" feature of debbugs: https://debbugs.gnu.org/server-control.html Concretely, this means we send email to debbu

Re: Release 1.2.1: status

On Sat, Mar 20, 2021 at 11:56:57PM +0100, zimoun wrote: > > From the wip-next-release branch, we should cherry-pick the tzdata > > updates and Qt 4 removal. > > > > I'll rewrite the branch with those commits today, and then see about > > getting it built on CI. > > Do you mean cherry-pick and then

Re: Release 1.2.1: status

On Sun, Mar 21, 2021 at 12:00:20AM +0100, zimoun wrote: > We discussed that and I agree. We also discussed some tagging and Maxim > did some tests, IIRC. Please go ahead and let try if it helps to > synchronize. :-) Here is the checklist: https://bugs.gnu.org/47297 I've added a few items, but

Re: [art] Tiled Wallpaper Art

On Mon, Mar 22, 2021 at 04:07:15AM +0530, Sarthak Shah wrote: > Hello, I put together a tiled svg wallpaper for GuixSD (attached) > using the logo resources in the git repository. > I'm not sure where to submit it Cool! We usually keep this kind of thing in the 'guix-artwork' repository: https:/

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

On Tue, Mar 23, 2021 at 03:38:02PM +0100, Léo Le Bouter wrote: > For this, the problem is not grafting but that the replacement package > definition has been made public, this is an "issue" (?) that is known > and I try to not make replacement package definitions public now. The replacement should

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

On Tue, Mar 23, 2021 at 02:34:52PM +0100, Léo Le Bouter wrote: > In general my opinion is that backporting fixes is time-consuming and > that if we have to do it each time I wont be able to keep up with the > load. I'd rather update things to a version that already includes fixes > and is supported

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

On Mon, Mar 22, 2021 at 02:44:04PM +0100, raingloom wrote: > What about a Liberapay for Guix? Could also be used to pay developers. Some of us already have Liberapay accounts.

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

On Tue, Mar 23, 2021 at 07:05:42PM -0400, Mark H Weaver wrote: > Also, I'm not sure why you qualify your suggestion with "in this case". > What is it that distinguishes ImageMagick from, e.g. glib, for purposes > of this question? Would it be any less bad for "guix install glib" to > install a gli

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

On Tue, Mar 23, 2021 at 11:54:54PM +0100, Ricardo Wurmus wrote: > This seems to be a misunderstanding. The first step is to use the money > we already have but cannot exchange for hardware, because > > - finding appropriate hardware that you can actually buy is not easy > - hosting needs to be co

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

On Wed, Mar 24, 2021 at 09:24:40PM +0100, Vincent Legoll wrote: > I already volunteered (privately) to host the same (1 or 2 WS power-class), > currently on ADSL uplink (so not for substitute distribution, only building), > FTTH in the future, no UPS though. The architecture of the build arm is su

Re: [Mumi] incorrect Blocked by field

On Wed, Mar 24, 2021 at 10:37:11PM +0100, zimoun wrote: > however there are not sorted which is annoying. And there is a tiny bug > because the bug 1 is listed. For some reason, when I added the first "blockers", debbugs also added the "1" bug. I tried to remove it, but it can't be done.

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

On Thu, Mar 25, 2021 at 03:22:16PM +0100, Mathieu Othacehe wrote: > I recently added a new metric in Cuirass: "Builds count per machine > during the last day". Turns out the overdrive1 with its two workers > seems to outperform the hydra-guix-X running emulated builds on four > workers. That's goo

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

On Sat, Mar 27, 2021 at 05:36:48AM -0400, Mark H Weaver wrote: > > gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick > > It occurs to me that we could add "stable" variants of the > 'imagemagick', 'dblatex', and 'gtk-doc' packages. The stable variants > would be used as n

Re: Staging

On Tue, Feb 20, 2018 at 11:45:58AM +0200, Efraim Flashner wrote: > Java currently only affects x86_64, so I'm not sure that it would need > to be staging specifically. In any case if we can get it merged within > the next week or so that'd be amazing. I know our cmake is in need of an > upgrade, ma

Re: 01/01: gnu: tzdata: Preserve directory layout from before tzdata 2018a.

On Tue, Feb 20, 2018 at 06:17:34PM +0100, Marius Bakke wrote: > Leo Famulari writes: > > > lfam pushed a commit to branch staging > > in repository guix. > > > > commit 62868f124cf9443a43f4ea5867da692e32e77c58 > > Author: Leo Famulari > > Date: Mon

Re: 01/04: gnu: htop: Fix tree view.

On Wed, Feb 21, 2018 at 09:49:19AM -0500, Tobias Geerinckx-Rice wrote: > nckx pushed a commit to branch master > in repository guix. > > commit 79f0561f43cc62dd332007cd847c0ad2870b3afc > Author: Tobias Geerinckx-Rice > Date: Wed Feb 21 06:06:46 2018 +0100 > > gnu: htop: Fix tree view. >

Re: Staging

On Tue, Feb 20, 2018 at 04:54:36AM +0100, Marius Bakke wrote: > Leo Famulari writes: > > > There are some patches on the staging branch, including an update to the > > time zone database. > > > > What are the plans for the next week or so? Should we try merging

Re: 01/02: gnu: qemu: Update to 2.11.1.

On Tue, Feb 20, 2018 at 12:28:57PM -0500, Marius Bakke wrote: > mbakke pushed a commit to branch master > in repository guix. > > commit 5fa6b52a548a806c36a450448972ae4007bbac17 > Author: Marius Bakke > Date: Tue Feb 20 17:44:43 2018 +0100 > > gnu: qemu: Update to 2.11.1. > > * gn

Re: Recent libx264 updates broke mpv via ffmpeg-git

On Thu, Feb 22, 2018 at 03:52:13PM -0500, Mark H Weaver wrote: > One of these two commits seem to have broken the 'ffmpeg-git' build, > needed by 'mpv', on my x86_64 GuixSD system. Here's an excerpt of the > failed log: > > --8<---cut here---start->8--- > CC

Re: Staging

On Wed, Feb 21, 2018 at 01:22:16PM -0500, Leo Famulari wrote: > On Tue, Feb 20, 2018 at 04:54:36AM +0100, Marius Bakke wrote: > > Leo Famulari writes: > > > > > There are some patches on the staging branch, including an update to the > > > time zone database. &

Re: Patch for broken Hiawatha

On Mon, Feb 26, 2018 at 03:07:51PM -0500, Kei Kebreau wrote: > Hello all, > > It seems that commit 22261238e7591c21d8362147992fbb12e67fda88, which > updates mbed TLS, has broken the hiawatha build [0]. It turns out that > the new release of mbed TLS contained a very minor typo that caused this > f

Re: Posts in languages other than English on help-guix?

On Fri, Mar 02, 2018 at 05:02:40PM +0100, Ludovic Courtès wrote: > What about allowing posts on help-guix in one of the languages that > regular contributors know, in addition to English? I didn't realize other languages were not allowed. Sounds good to me! signature.asc Description: PGP signatu

Re: Help needed: Unable to run Guix after installation

On Tue, Mar 13, 2018 at 01:55:28AM +0530, Aakanksha Jain wrote: > I have completed the GNU Guix installation using this script > https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-install.sh > > But while trying to run hello package, I get following error(image attached) The error message i

Krita 3 and 4 compatibility issues

I updated Krita to 4.0.0, but later I noticed some issues with the transition, notably that the Krita 3 and 4 file formats are not totally compatible and may not work consistently between versions: "Krita 4 has a new file format for vector and text objects. Krita 4 tries to import Krita 3 and olde

Re: 03/04: gnu: fribidi: Update to 1.0.2.

On Fri, Mar 23, 2018 at 01:27:11PM +0100, Marius Bakke wrote: > Also note that Fribidi gained 2149 new dependents on 'core-updates', so > we'll have to be careful about updating it once the branch starts. Just curious, what was the change? signature.asc Description: PGP signature

Re: Krita 3 and 4 compatibility issues

On Fri, Mar 23, 2018 at 03:06:52PM +, ng0 wrote: > Thorsten Wilms transcribed 1.2K bytes: > > A short note regarding the option to keep both Krita 3 and 4 accessible > > would be nice in this and any future similar case. The likelihood of not > > working in the same profile, potential configura

Annoying behaviour of the GPG signature verification pre-push hook

In HACKING, we recommend Guix committers install a pre-push hook to verify their GPG signatures before pushing to Savannah. [0] This is intended to catch mistakes only. This generally works, and I tend to forget I'm using it for months at a time :) There is one case where the hook is annoying: pu

Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.

On Mon, Apr 02, 2018 at 11:42:16AM +0200, Svante Signell wrote: > Hi, Hi and welcome to the Guix community... > Seeing this on April 1st I really hope it is a joke. If not I'm not > ever going to support GNU software or anything GNU related any more. > You should be ashamed of yourselves. Yes, i

Re: [PATCH] gnu: Add systemd.

On Tue, Apr 03, 2018 at 03:33:22PM -0700, Joshua Branson wrote: > So this isn't an april fools joke? guixSD may move to systemd? It was a joke :) signature.asc Description: PGP signature

Patching the default PATH of `su`

In the man page of su(1), it says this: -- The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.de

<    4   5   6   7   8   9   10   11   12   13   >