Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Leo Famulari writes: > [...] > To clarify, Leo Prikler is not the same person that was involved in > removing the Cairo bug fixes. That was a different person, also named > Leo. > > Not me, either :) Um, my bad, thank you!

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

Hi Maxime, Maxime Devos writes: > Joshua Branson schreef op za 01-05-2021 om 11:04 [-0400]: >> Hey guix people, >> >> I just ran across a pretty recent thread in bug-hurd land. Apparently >> there is a VERY WIP effort to get some guile-scheme bindings for GNU >> Mach and the Hurd. >> >> Since

Re: What processor features does Guix support on i686?

Hi Leo, Thanks for asking about this, and for ably taking care of our Linux-libre packages. I'm grateful for your work on this. Leo Famulari writes: > I noticed that Linux 5.12 has a new config option regarding "Processor > family". The default choice, Pentium-Pro (M686), is highlighted in thi

Hero culture among Guix maintainers

Hey Guix. There's a specific thing I'm motivated to address after the recent security incident with the "cosmetic" patches & all the fallout of that. In one of the comments that lead off that thread, Mark asked "does anyone else find it worrisome that Raghav has commit access?" I speculate this

Re: Jam: which licence is this?

Hi Jack, Jack Hill writes: > On Sun, 25 Apr 2021, Jack Hill wrote: > >> I have asked the FSF licensing lab about this in RT #1718940 Thanks very much for doing this, Jack. > I've also asked OSI: > https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2021-April/005139.htm

What processor features does Guix support on i686?

I noticed that Linux 5.12 has a new config option regarding "Processor family". The default choice, Pentium-Pro (M686), is highlighted in this quote: -- Processor family 1. 486SX (M486SX) (NEW) 2. 486DX (M486) (NEW) 3. 586/K5/5x86/6x86/6x86MX (M586) (NEW) 4. Pentium-Classic (M586TSC) (

Re: Jam: which licence is this?

Hi Leo, I took the liberty of adding a bit more context to your quotation of me below, since I've added Ludovic to the CC list. Leo Famulari writes: > On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote: >> It's true that Guix has a >> longstanding practice of omitting more lax licens

Re: linux-libre source tarballs

On Sat, May 01, 2021 at 10:45:22PM -0400, Leo Famulari wrote: > The immediate solution is for me to make sure the tarballs have built > before committing the updates. I already do this for x86_64 and I can > start doing it for aarch64 too. I started building the current derivations "by hand" on th

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

On Sun, May 02, 2021 at 12:17:59PM +0800, 宋文武 wrote: > Hello Leo, I see nothing wrong for assuming bad faith when security > fixes of packages are removed, in the end the truth matter, which I > believe is: You thought the patches for cario is not needed now on > core-updates, so you remove them. >

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

宋文武 writes: > Leo Prikler writes: > >> Hi Mark, >> >> Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver: >>> Hi Leo, >>> >>> Leo Prikler writes: >>> >>> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: >>> > > I also spent some time re-reading messages that Mar

Re: GNU Guix 1.3.0rc1 available for testing!

On Sun, May 02, 2021 at 12:05:42AM -0400, Leo Famulari wrote: > I've attached a patch. I sent this before seeing your patch. Feel free to disregard it.

Re: GNU Guix 1.3.0rc1 available for testing!

On Sat, May 01, 2021 at 10:52:18PM -0400, Maxim Cournoyer wrote: > > https://guix.gnu.org/manual/en/ > > https://guix.gnu.org/manual/devel/en/ > > Thank you for pointing that issue; I caught the problem with > guix-install.sh before posting, but overlooked that one. As you > pointed, that won't b

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Leo Prikler writes: > Hi Mark, > > Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver: >> Hi Leo, >> >> Leo Prikler writes: >> >> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: >> > > I also spent some time re-reading messages that Mark sent in this >> > > thre

Re: GNU Guix 1.3.0rc1 available for testing!

On Sat, May 01, 2021 at 05:25:45PM -0400, Leo Famulari wrote: > Maybe we should update the manual to mention "1.3.0rc1" and the correct > key. I've attached a patch. > > 1. Testing the binary tarball on the distro of your choice. You can > > download . Un

Re: branch master updated: gnu: sbcl: Update to 2.1.4.

On Sat, May 01, 2021 at 07:53:26AM -0400, guix-comm...@gnu.org wrote: > commit c04dfb39f62f764b1c3988d9b0fcedc8221afa67 > Author: Pierre Neidhardt > AuthorDate: Sat May 1 13:53:09 2021 +0200 > > gnu: sbcl: Update to 2.1.4. > > * gnu/packages/lisp.scm (sbcl): Update to 2.1.4. Hi Pier

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, I took the liberty of refilling the quotations in your email to make them more readable. Leo Prikler writes: > Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver: >> Can you please point out which of my words led you to conclude that I >> was assuming bad faith? > > I am basi

Re: GNU Guix 1.3.0rc1 available for testing!

Hi Vagrant, Vagrant Cascadian writes: > On 2021-05-01, Maxim Cournoyer wrote: >> A first RC for the upcoming 1.3.0 release is now available for testing: > > Thanks for all the hard work getting rc1 ready! > > > Also soon coming to a Debian mirror near you: > > https://buildd.debian.org/status/

Re: GNU Guix 1.3.0rc1 available for testing!

Hi Leo, Leo Famulari writes: > On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote: >> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz > > I tested the binary tarball on x86_64. > > I used `guix package --export-manifest > manifest` before beginning the >

Re: linux-libre source tarballs

On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascadian wrote: > Pragmatically speaking, on slower platforms this is a huge resource > overhead. So much so that ci.guix.gnu.org *usually* times out when > generating the linux-libre aarch64 tarballs: > > > https://ci.guix.gnu.org/search?query

linux-libre source tarballs

So, for better or worse, I do a lot with guix on aarch64 platforms and sometimes even armhf ones. And these platforms are... often... quite... slow... The way guix does updates of linux-libre sources by downloading upstream linux tarballs and applying the linux-libre deblobbing and related scrip

Pinebook Pro no longer WIP

Someone pointed to me various patches[0][1] and kernel module selections[2] related to the Pinebook Pro that lead to me feeling confident to merge some kernel and u-boot changes for the Pinebook Pro into guix/master... Which now means that you should be able to run Guix System on a Pinebook Pro wi

Making technology more inclusive Was: Leaving the GNU Guix community

On Fri, 30 Apr 2021 01:43:37 +0200 Leo Le Bouter wrote: > I think that the technicality of software development must be > redefined so that the hierarchy between the experienced and the > beginner disappears [...] I've been thinking a lot about these topics, and there are radical solutions that c

Re: Outreachy: Timeline tasks

On Sat, 01 May 2021 20:07:56 +0100 Christopher Baines wrote: > Luciana Lima Brito writes: > > > On Sat, 01 May 2021 09:16:08 +0100 > > Christopher Baines wrote: > > > >> Currently the timing of various sections of the process includes > >> timing smaller sections, and that may complicate rea

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Mark, Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver: > Hi Leo, > > Leo Prikler writes: > > > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: > > > I also spent some time re-reading messages that Mark sent in this > > > thread and, like him, I really don't u

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Mark H Weaver writes: > Leo Prikler writes: > >> Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: >>> If you want you can consider Mark used an /harsh/ tone but this is a >>> personal feeling, something one /could/ read "between the lines" even >>> if actually in a written comm

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, Leo Prikler writes: > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: >> I also spent some time re-reading messages that Mark sent in this >> thread and, like him, I really don't understand what Mark did wrong. >> >> For sure Mark /insisted/ that Raghav and Léo did so

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

Joshua Branson schreef op za 01-05-2021 om 11:04 [-0400]: > Hey guix people, > > I just ran across a pretty recent thread in bug-hurd land. Apparently > there is a VERY WIP effort to get some guile-scheme bindings for GNU > Mach and the Hurd. > > Since it might be of interest to guixy people, I

Re: GNU Guix 1.3.0rc1 available for testing!

On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote: > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz I tested the binary tarball on x86_64. I used `guix package --export-manifest > manifest` before beginning the test, so that I could easily recreate my pr

Re: Neovim plugin/addon packaging

Thanks for your reply. On Fri, 30 Apr 2021, Efraim Flashner wrote: On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote: Greetings Guix, I'd like to improve the experience of installing Neovim plugins/add-ons with Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hello Giovanni, I am not Mark or Ludo, but as a /generic other/, I'd still like to reply. Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: > Hello Mark and Ludovic, > > please forgive me if I'm going forward with this thread but, after > some > hesitation, I decided to write th

Re: Guix Home upstreaming plan

Hi, On Fri, Apr 30 2021, Ludovic Courtès wrote: > Hi Andrew, > > Andrew Tropin skribis: > >> There is a goal[0] to make Guix Home[1] a part of GNU Guix. It will reduce >> the duplications between projects, increase integrity and will provide >> Guix users with a missing tool for declarative con

Bringing substitutes from the Guix Build Coordinator to users

Hey, The Guix Build Coordinator has been around for a while, it's been available in Guix for more than 6 months now. The setup I've been using to test the Guix Build Coordinator for building things for substitutes (guix.cbaines.net) has been running since mid 2020. Anecdotally, the test setup I'v

Re: Outreachy: Timeline tasks

Luciana Lima Brito writes: > On Sat, 01 May 2021 09:16:08 +0100 > Christopher Baines wrote: > >> Currently the timing of various sections of the process includes >> timing smaller sections, and that may complicate reading the chart, >> since it won't convey which timed sections include other ti

Re: Leaving the GNU Guix community

Hello Tobias, On Sat, 2021-05-01 at 04:34 +0200, Tobias Geerinckx-Rice wrote: > Léo, > > Leo Le Bouter 写道： > > I feel like what has happened is really a disaster, > > I'm relieved that we share, at least, this.  I think everyone > does. > > > I don't feel like contributing to GNU Guix anymore

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hello Mark and Ludovic, please forgive me if I'm going forward with this thread but, after some hesitation, I decided to write this message because I /feel/ we could do better in dealing with issues like this one. Please when you'll read "you" consider it a /generic you/ ("you the reader") not Ma

FYI: guile-scheme bindings to GNU Mach and the Hurd

Hey guix people, I just ran across a pretty recent thread in bug-hurd land. Apparently there is a VERY WIP effort to get some guile-scheme bindings for GNU Mach and the Hurd. Since it might be of interest to guixy people, I thought I'd share: https://notabug.org/mdevos/guile-hurd Cheers! --

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

Hi Pierre, Pierre Neidhardt writes: > I haven't really followed the issue, I have, very carefully ;-) > so I couldn't say whether the decision taken by the core maintainers > was right or not. From my point of view it was /but/ this is *not* relevant: what's relevant here is that /if/ we trus

Re: Leaving the GNU Guix community

Tobias Geerinckx-Rice writes: > Léo, > > Leo Le Bouter 写道： >> I feel like what has happened is really a disaster, > > I'm relieved that we share, at least, this. I think everyone does. > >> I don't feel like contributing to GNU Guix anymore in the future. > > That's a great pity. I hope to welc

Re: Unfortunate statefulness of Guix Install image

Vladilen, I'm writing mainly to save you some time testing ‘guix system init --localstatedir’. That is a ./configure option used when building Guix from source. I don't think any option will help you here. Vladilen Kozin 写道： Except, when you try to do the manual install off the same USB ..

Re: Outreachy: Timeline tasks

Hi, On Sat, 01 May 2021 09:16:08 +0100 Christopher Baines wrote: > Currently the timing of various sections of the process includes > timing smaller sections, and that may complicate reading the chart, > since it won't convey which timed sections include other timed > sections. Does that make s

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

On Sat, May 01, 2021 at 12:53:43PM +0530, Arun Isaac wrote: > We may like to imagine that being a core maintainer is not a badge of > honor, but in reality, it *is* a badge of honor. A core maintainer is > not just a regular participant any more than the President is just a > public servant. If cor

Re: Unfortunate statefulness of Guix Install image

If I read this https://guix.gnu.org/manual/en/html_node/The-Store.html#The-Store correctly, then perhaps a proper solution to this is to also supply --localstatedir in attempt to ensure that the db with metadata ends up on the target partition? So e.g. like this: guix system --localstatedir /mnt/v

Re: Add a way to disable serialization support to (guix services configuration)

Hi, On Fri, Apr 23 2021, Xinglu Chen wrote: >> Wouldn’t it be nicer to write: >> >> (define-configuration foo >> (bar (integer 123) "doc" no-serializer) >> (baz (string "") "doc")) >> >> where ‘bar’ wouldn’t have a serializer and ‘baz’ would? >> >> It’s also probably easier to implement

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

Hello! I don't know the details of the case at all but let met mention this: https://communityrule.info/ It comes from the world of worker cooperatives and I think them "rules of the community" is discussed a lot there as well 😄 Cheers, Yasu > On May 1, 2021, at 18:16, Pierre Neidhardt wrote:

Re: #:cargo-inputs don't honor --with-input

Hi Ludo, Am 30.04.21 um 12:45 schrieb Ludovic Courtès: Uh. More generally, Rust packages kinda create a “shadow dependency graph” via #:cargo-inputs & co., which breaks all the tools that are unaware of it. It was discussed several times on this list, and apparently it’s unfortunately unavoid

Re: Outreachy: Timeline tasks

Luciana Lima Brito writes: > On Fri, 30 Apr 2021 18:05:15 +0100 > Christopher Baines wrote: > >> > >> > Task 1: Add instrumentation to identify the slow parts of processing >> > new revisions: >> > >> > - Implementing a chart over time to identify slow parts: >> >- The chart should consid

Re: GNU Guix 1.3.0rc1 available for testing!

On 2021-05-01, Maxim Cournoyer wrote: > A first RC for the upcoming 1.3.0 release is now available for testing: Thanks for all the hard work getting rc1 ready! Also soon coming to a Debian mirror near you: https://buildd.debian.org/status/package.php?p=guix&suite=experimental live well, v

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

Hi everyone, This decision aside, I share some of the general concerns raised by Pierre about core maintainership and the behind closed doors decision making process. > Being a core committer is *not* a badge of honour. It does not give > special privileges beyond what is expected. It does not g