Re: Jam: which licence is this?

On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote: > However, I think that longstanding practice is orthogonal to the > question of whether licenses covering build system components can be > omitted from the 'license' field. [...] > Specifically, I'm objecting to the idea that the

Re: Jam: which licence is this?

On Sun, Apr 25, 2021 at 01:25:21PM -0400, Mark H Weaver wrote: > In general, I think that the license field of a package should include > all licenses that cover any files in its source distribution (by which I > mean the output of "guix build --source"). > > My rationale is that it is the source

Re: Organizing Tui Apps

On Fri, Apr 23, 2021 at 10:00:14PM +0200, Leo Prikler wrote: > Spreadsheets sounds fine to me, but I think the most important ones > (libreoffice and org-mode) are already excluded from that module for > obvious reasons ;) > Perhaps an even more generic "office" module might be better, because >

Re: A "cosmetic changes" commit that removes security fixes

On Fri, Apr 23, 2021 at 09:33:07PM +0200, Léo Le Bouter wrote: > I knew about this but I didnt feel like telling Raghav to do yet > another rebase. I felt like Raghav was taking on with so much already. > The rebase was specially complicated because Raghav's commit changed > indentation, git has

Re: A "cosmetic changes" commit that removes security fixes

On Fri, Apr 23, 2021 at 08:50:37PM +0200, Léo Le Bouter wrote: > I think there is no problem in accepting criticism but there is a > certain way Mark presents criticism and I don't feel like I can respond > to it when it is written in such way. Over several emails Mark was > looking to point to

Re: A "cosmetic changes" commit that removes security fixes

On Thu, Apr 22, 2021 at 12:05:36AM -0400, Raghav Gururajan wrote: > Okay, I was able to retrace. When Leo and I were working outside savannah, > there was master --> core-updates merge. Leo made these changes when he > committed to his repo > (https://logs.guix.gnu.org/guix/2021-03-26.log#000811),

Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)

On Thu, Apr 22, 2021 at 12:27:52PM -0400, Mark H Weaver wrote: > I don't understand why it's relevant how many patches are involved. It > sounds like if I had concatenated all of the CVE-2021-27219 patches into > a single file, you would have judged that as "simple", and therefore > ungrafted it,

Re: A "cosmetic changes" commit that removes security fixes

On Thu, Apr 22, 2021 at 12:16:13AM +0200, Leo Prikler wrote: > However, in taking more time to let patches sit on the > mailing list, I fear that I might come off as "unwilling" to those > contributors, whose work I help review, including Raghav, and also that > my involvement in some patch

Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)

On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote: > I just noticed that 'glib' is still grafted on the 'wip-ungrafting' > branch. Was that intentional? > > https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting=e12210dc92098d8581cea3007d57dbb6be16bb41#n171

Rust in Linux / linux-libre

We should continue working to improve Rust in Guix, because it won't be too long before it's part of Linux, which linux-libre is downstream from. Problems I see now: 1) Rust isn't yet supported on all CPU architectures supported in Guix 2) Rust packages don't use the normal Guix dependency

Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

On Tue, Apr 20, 2021 at 07:03:26PM +0200, pelzflorian (Florian Pelz) wrote: > On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote: > > It seems this is the bad commit. Downloading the enlightenment > > substitute got stuck and after a few minutes displayed the usual TLS > >

Re: 1.2.1 pre-release testing

On Sat, Apr 17, 2021 at 07:09:59PM -0500, Guu, Jin-Cheng wrote: > I've just tried again the same ISO, and chose "wired". It works right > away this time. I think it was just a tiny hiccup last time. Should > have tried more times then.. sorry about that! Thanks a lot for testing again! We really

Re: New 'version-1.3.0' branch and lifting string freeze on master

On Sat, Apr 17, 2021 at 02:44:52PM -0400, Maxim Cournoyer wrote: > To avoid keep master in string freeze longer, I've now created the > 'release-v1.3.0' branch where the fixes for the remaining blocking > issues should go. I kept a list of patches that were being held back due to the string

Re: 1.2.1 pre-release testing

I re-installed my Guix System based on the ISO found here: https://ci.guix.gnu.org/build/175632/details That's '/gnu/store/lw1j4gn8h51cbfp9dg0g025ngkg83sw1-image.iso.drv'. It's a simple system, but the process worked for me. It successfully recognized and re-used my existing /home partition.

Re: GIT_EXEC_PATH Re: 1.2.1 pre-release testing

On Sat, Apr 17, 2021 at 01:35:45PM +0200, François wrote: > GIT_EXEC_PATH is very probably at fault. > > It is set via profile to allow to use git subcommands installed by other > packages but it has no sane default when we are outside a profile. > > Perhaps git should have a wrapper to manage

Re: 1.2.1 pre-release testing

On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote: > First time posting here. Please let me know if I missed anything. Thanks for your report! >I chose the graphical method for the first installation. Everything >went well, except my wired internet connection failed as it >

Pruning inactive committers

such committers, yesterday and today. Specifically, this means: 1) removing the inactive committers from the Guix group on Savannah [1] 2) deauthorizing their code-signing keys [2] Sincerely, Leo Famulari [0] https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html [1] On Savannah, commit

Re: website: Building fails because of missing locales

On Tue, Apr 06, 2021 at 03:59:20PM +, Luis Felipe wrote: > Hello, > > I updated my local copy of guix-artwork repository today and now running > "haunt build" fails with this message: > > > Backtrace: > In ice-9/threads.scm: > 390:8 19 (_ _) > In ice-9/boot-9.scm: >

Re: Meta guix: making money with GNU Guix: slightly off topic

On Tue, Apr 06, 2021 at 12:05:00PM -0400, Joshua Branson wrote: > Aloha you lovely people! I personally believe that people should make > business out of free software. Here are some of my business ideas > involving GNU Guix. I invite you all to beat me to market! VPS service that accepts a

Re: Application for aarch64 computing resources

On Sat, Apr 03, 2021 at 04:28:28PM -0500, Katherine Cox-Buday wrote: > I'm extremely happy to see this, and I hope we can increase our ARM > capacity. Thanks for making this submission, Leo! Thank you so much for your support!

Re: Application for aarch64 computing resources

On Fri, Apr 02, 2021 at 11:56:03AM -0700, Vagrant Cascadian wrote: > You might want to also ask for hardware that has the extensions for > 32-bit arm, if we also want to improve substitute availability for armhf > too. The 32-bit extensions are optional for aarch64, and thus not all > hardware

Re: Application for aarch64 computing resources

On Fri, Apr 02, 2021 at 08:57:41PM +0200, Nicolò Balzarotti wrote: > Hi! There's a typo: "dinary distros" -> binary > > also, extra 'this' in: this goal this for x86 Thanks! Fixed :)

Application for aarch64 computing resources

Those of us who watch the Guix build farm [0] closely have identified the lack of capacity for building ARM binaries as a serious limitation. As part of our efforts to improve the situation, I've applied for donation of aarch64 (64-bit ARM) computing resources for the Guix build farm:

Re: Cuirass 1.0 released

On Thu, Apr 01, 2021 at 10:23:07AM +0200, Mathieu Othacehe wrote: > We are pleased to announce the release of Cuirass 1.0. Awesome! Your hard work is making a big difference for Guix :) > This is the first official release of Cuirass, the GNU Guix continuous > integration software. Since

Re: Document our WIP

On Wed, Mar 31, 2021 at 07:52:30PM +0200, Léo Le Bouter wrote: > On Tue, 2021-03-30 at 12:37 +0200, Ludovic Courtès wrote: > > To me, a good way to make sure work remains “in progress” is to post > > regular updates to this list, and then to write blog posts for the > > web > > site whenever an

Re: [aarch64] sbcl build failure

On Wed, Mar 31, 2021 at 01:26:20AM -0400, Leo Famulari wrote: > > I'm looking at the following cl-zstd build failure: > > https://ci.guix.gnu.org/build/133326/details > > which is caused by sbcl build failure that I > > reproduced locally. Unfortunately, the build fail

Re: [aarch64] sbcl build failure

On Wed, Mar 31, 2021 at 12:15:01AM +0200, Vincent Legoll wrote: > I'm looking at the following cl-zstd build failure: > https://ci.guix.gnu.org/build/133326/details > which is caused by sbcl build failure that I > reproduced locally. During the recent staging cycle, I noticed a huge number of

Re: hikari build failure

On Tue, Mar 30, 2021 at 11:58:57PM +0200, Vincent Legoll wrote: > > I've restarted . > > I'm seeing overdrive1 as idle (as a lot of hydra workers) yet the > restart is still in scheduled state. > > What am I missing ? I don't know exactly what

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

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

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

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

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

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

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

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:

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

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

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 dependencies.

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

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

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

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

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?

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: 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: [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: 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. E

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

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

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

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

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

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,

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 >

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

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

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 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'v

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

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

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 "work in

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

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,

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

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.

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

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 >

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

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

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

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

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

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

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 b

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

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

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

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

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

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

<    1   2   3   4   5   6   7   8   9   10   >