Re: Setting up gmail for git send-email

On 5/29/24 23:21, Imran Iqbal wrote: I am unsure if my reply on debuggs was sent, i am yet to get a email address that supports git send-email, Also if anyone sees this and has an invite to riseup email service ( should the service be capable of handling another stranger) then please may i

Re: Error handling when 'guix substitute' dies

Hi, On 3/29/24 11:10, Ludovic Courtès wrote: > > [...] OK, I’ll push it shortly, but… Lars Bilke skribis: thanks Ada for bringing this issue up again. I get the same error on `guix pull` almost always when I am on my enterprise network. Re-running `guix pull` a second time also almost

Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)

On Thu, Mar 21, 2024, at 11:11 AM, MSavoritias wrote: > On 3/21/24 17:08, Giovanni Biscuolo wrote: >> […] >> I don't understand how using petnames, uuids or even a re:claimID >> identity (see below) could solve the problem with "rewriting history" in >> case a person wishes to change his or her

Re: Git-LFS or Git Annex?

Hi, On Sun, Jan 28, 2024, at 5:33 AM, Nicolas Graves via Development of GNU Guix and the GNU System distribution. wrote: > I've left git-annex for git-lfs, I'll just add a few points about > git-lfs. > > > On 2024-01-24 18:39, Giovanni Biscuolo wrote: > >> Hi Ludo’ >> >> Ludovic Courtès writes:

Re: Git-LFS or Git Annex?

Hi, On 1/24/24 10:22, Ludovic Courtès wrote: The question boils down to: Git-LFS or Git Annex? [...] What’s your experience? What would you suggest? I have a few times had a problem for which I thought Git LFS might be a solution, and each time I have ended up ripping out Git LFS in

Re: Mixing GPL and non-copyleft code in source files

On Wed, Jan 3, 2024, at 3:32 PM, Vagrant Cascadian wrote: > On 2024-01-03, Wojtek Kosior via wrote: >> Before getting back to the discussion, please let me ask 1 question. >> Assume I submit a patch series that adds some useful and needed code and >> includes a copyright notice with a promise,

Re: Should commits rather be buildable or small

On 12/10/23 18:20, Attila Lendvai wrote: FWIW, this commit policy has always bothered me as a newcomer to Guix. pretty much everywhere else it's a major offence against your colleagues to commit something that breaks the build in any way. In the last few months I’ve repeatedly seen assertions

Re: git send-email

Hi, On Sun, Nov 19, 2023, at 12:27 PM, Felix Lechner wrote: > Hi Philip, > > On Sun, Nov 19 2023, Philip McGrath wrote: > >> 1. Can we reorganize things on the website so that the non-"devel" manual >> is much more prominent than the other one? > > Was

Re: git send-email

On Sun, Nov 19, 2023, at 10:59 AM, Nicolas Débonnaire wrote: > Well, I just realised there is two version of the manual available and I was > looking at the wrong one from the beginning. (https://guix.gnu.org/en/manual/) > It looks like it's been fixed in the latest version. >

Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors

Hi, On Thu, May 25, 2023, at 5:04 PM, Felix Lechner wrote: > Hi Philip, > > On Thu, May 25, 2023 at 1:49 PM Philip McGrath > wrote: >> >> Here are results from Florida, US: >> >> 2023-05-25 16:28:07 (14.9 MB/s) >> 2023-05-25 16:28:53 (52.9 MB/s) >>

Re: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors

Hi, On Thu, May 25, 2023, at 9:52 AM, Christopher Baines wrote: > Hey! > > I was reminded again about substitute download speeds outside of Europe > again today. > > There was some feedback when I sent out a message to guix-devel [1], [2] > a while back. I think the rough summary is that there's

Re: tracking /etc/profile.d/*guix.sh in downstream distributions

On Friday, May 19, 2023 6:10:53 PM EDT Vagrant Cascadian wrote: > Philip McGrath recently pointed out that the /etc/profile.d/guix.sh > snippet had not been updating in the Guix packaging for Debian: > > https://bugs.debian.org/1036304 > > (and as bonus complication, was a

Re: Potential removal of unmaintained node-openzwave-shared

Hi, On Wed, Mar 22, 2023, at 8:08 AM, Jelle Licht wrote: > Hey guix, > > In getting `Node.js' updated to a more recent LTS version[0], I found > out that node-openzwave-shared no longer builds with modern versions of > node [1]; random people on the Internet seem to indicate that > the hip new

Re: Qt in core-updates (was: KDE in core-updates)

Hi, On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote: > > In any case, I realised that we are still compiling most packages (including > KDE) with Qt 5, which is seriously outdated (not maintained any more in the > free version since May 2021). Qt 6.3 support will end in April

Re: Can zig-build-system be an alternative to the gnu-build-system?

Hi Pjotr, On Wed, Feb 1, 2023, at 5:11 AM, Pjotr Prins wrote: > > There have been some older discussions about creating our own > replacement for autotools, cmake and others. I often fight these make > make systems - and meson and/or language specific build systems. It is > a time waster for

Re: RFC: libgit2 is slow/inefficient; switch to git command?

Hi, On Tue, Nov 22, 2022, at 10:39 AM, zimoun wrote: > Hi, > > On Mon, 21 Nov 2022 at 21:21, Maxim Cournoyer > wrote: > >> Given that: >> >> * the git CLI doesn't suffer from such poor performance; >> * This kind of performance problem has been known for years in libgit2 >> [0] with no fix in

Re: What 'sh' should 'system' use?

On Sunday, October 16, 2022 3:04:45 AM EDT Liliana Marie Prikler wrote: > Am Samstag, dem 15.10.2022 um 19:23 -0400 schrieb Philip McGrath: > > On Saturday, October 1, 2022 12:54:27 PM EDT Ludovic Courtès wrote: > > > Hello! > > > > > > Philip McGrath skribi

Re: What 'sh' should 'system' use?

On Saturday, October 1, 2022 12:54:27 PM EDT Ludovic Courtès wrote: > Hello! > > Philip McGrath skribis: > > 1) If we want to continue to hard-code a specific shell into Glibc, I > > think we should document the decision (for example, why 'bash-static' v

Re: Proposal: A new build-system API

Hi, On 9/26/22 14:07, Mája Tomášek wrote: For example, there's currently no guarantee that #:phases will contain list of functions and the error from that will be cryptic. Contrast that with the service-configuration API. There are field sanitizers that ensure that the configuration is propper

Re: What 'sh' should 'system' use?

Hi, On 9/19/22 03:07, Liliana Marie Prikler wrote: Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath: On the other hand, even Nix puts '/bin/sh' at its usual path: we are really quite an outlier in this respect. (IIUC, Nix also has '/usr/bin/env', but no other utilities at FHS

Re: What 'sh' should 'system' use?

perspective, this is part of why I've recently been thinking we should find 'sh' dynamically: most programs/environments don't, and shouldn't, need bash{-minimal,-static}, so it seems wrong to make it a mandatory dependency of libc. On 9/19/22 08:55, Maxime Devos wrote: On 19-09-2022 02:13, Philip

What 'sh' should 'system' use?

Hi Guix, The C standard library includes a function 'system' to run a string as a shell command. Other languages provide similar functions, including Guile and many other Schemes and the Standard ML Basis Library.[1][2] Even without a dedicated library function, a program might want to run

Re: secure boot

On Sun, Aug 21, 2022, at 4:46 AM, Josselin Poiret wrote: > Hi Antonio, > > Antonio Carlos Padoan Junior writes: > >> As far as I understand, Guix doesn't provide means to automatically sign >> bootloaders and kernels in order to use UEFI secure boot after each system >> reconfigure (assuming a

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On Sun, Jul 24, 2022, at 11:17 PM, Maxime Devos wrote: > * In principle, you can apply a patch from a phase. However, this causes the > result of "guix build --source" to not correspond to the actual source code > anymore (i.e., it doesn't act as corresponding source anymore), so consider >

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On Sun, Jul 24, 2022, at 11:17 PM, Maxime Devos wrote: > * Patches must not be used to remove non-free files, because a patch by > construction contains the non-free file itself so the patch would be > non-free, which would not be acceptable to Guix. Likewise, patches should not > be used to

Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of sub

Hi, On Tue, Jul 12, 2022, at 1:34 PM, John Kehayias wrote: > Hi Chris, > > Thanks for setting up some more mirrors, here is what I just got (in a > previous run the main Bordeaux server was a bit slower, more like 18 > MB/s) on a wired connection that maxes out at about 320 Mbps. > I also get

Re: The case for moving raw binaries

Hi, On Fri, Apr 29, 2022, at 12:59 PM, Liliana Marie Prikler wrote: > Am Freitag, dem 29.04.2022 um 11:27 +0200 schrieb Maxime Devos: >> [...] >> >> I thought that >> >>   (if already-wrapped? >>   ;; PROG is already a wrapper: add the new "export VAR=VALUE" >>   ;; lines just before

Re: Release v1.4?

On Fri, Jun 17, 2022, at 11:37 AM, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > Ludovic Courtès writes: > >> So plain ‘emacs’ package doesn’t work on Wayland? That sounds >> like a >> recipe for a poor user experience, no? > > The mainline Emacs is not

Re: FSDG-compatibility of APSL-2.0

Hi, On Friday, June 17, 2022 10:37:07 AM EDT zimoun wrote: > > On the other hand, I refuse to judge the intent behind a software. It > appears to me a slippery slope. The only way is to set a clear frame > and then scrutinize using this very frame. Debian defines a frame, GNU > defines

Re: FSDG-compatibility of APSL-2.0

Hi, On Thursday, June 16, 2022 3:43:39 AM EDT Liliana Marie Prikler wrote: > Hi Philip, > > Am Donnerstag, dem 16.06.2022 um 02:21 -0400 schrieb Philip McGrath: > > Hi Guix, > > > > Is the Apple Public Source License 2.0 (APSL-2.0 [1]) a free license > &

FSDG-compatibility of APSL-2.0

Hi Guix, Is the Apple Public Source License 2.0 (APSL-2.0 [1]) a free license according to Guix's standards? In , I sent a patch adding a package under this license, and Maxime Devos pointed out this choice-of-forum provision, which I agree is quite

Re: maradns reproducibility fixes and the merits of picking a random number

Hi, On 6/8/22 16:25, Vagrant Cascadian wrote: On 2022-06-09, Arun Isaac wrote: Hi Vagrant, But there's one nervous-making issue this revealed; maradns embeds a random number at build time ... allegedly for systems that don't have /dev/urandom... see

Re: Finding a “good” OpenPGP key server

Hi, On 4/18/22 16:24, Ludovic Courtès wrote: Hi, Tanguy LE CARROUR skribis: gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST gpgv:using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D gpgv: Can't check signature: No public key Would you like to add this key to keyring

Re: better error messages through assertions

Hi, On 3/30/22 05:37, Ludovic Courtès wrote: What is the preferred mechanism for exceptions? For Guix code, SRFI-34/35. Likewise, what record system should I use? SRFI-9. (Perhaps we should put answers to these questions in the “Coding Style” section of the manual.) As I've looked

Re: better error messages through assertions

Hi, On 3/30/22 09:28, Andy Wingo wrote: Too bad about all that other crap about checking whether the index is in range and the field is boxed or not, though :-/ Probably there is a better design... Andy For the index-out-of-range part, when I saw `record-accessor`, I thought of it as

Re: The Shepherd on Fibers

Hi, On 3/29/22 05:36, Maxime Devos wrote: Philip McGrath schreef op ma 28-03-2022 om 20:14 [-0400]: Maybe it would be enough for this case for Fibers to provide variants of `dynamic-wind` and/or `call-with-continuation-barrier` that cooperate with the Fibers implementation. I don't know

Re: The Shepherd on Fibers

On 3/28/22 20:14, Philip McGrath wrote: I'm not sure how useful any of that is, but take it for whatever it's worth. My overall impression is that the Shepherd on Fibers is a big step in the right direction. Congrats on the great work! -Philip P.S.: If you can get access to a copy of John

Re: The Shepherd on Fibers

Hi, On 3/23/22 18:36, Ludovic Courtès wrote: Hello Guix! I have pushed a ‘wip-fibers’ branch of the Shepherd: https://git.savannah.gnu.org/cgit/shepherd.git/log/?h=wip-fibers The goal is to make shepherd (the daemon) use Fibers¹ for concurrency. Exciting! As I wrote in

Re: better error messages through assertions

Hi, On 3/7/22 05:13, Ludovic Courtès wrote: Hi Philip, Philip McGrath skribis: Racket's state-of-the-art contract system has many features and nuances. I *do not* think anyone should try to implement them all in one fell swoop. I'm hoping there's a way to implement your simple assertions

Re: Semantics of circular imports

Hi, (Apparently I wrote this a month ago but left it sitting in "Drafts" ...) On 2/20/22 12:47, Maxime Devos wrote: > Philip McGrath schreef op zo 20-02-2022 om 11:47 [-0500]: >> I was just (or maybe am still?) dealing with some issues caused by cyclic >> imports

Re: License issue with SRFI 5

Hi, On Monday, March 7, 2022 5:41:46 AM EST Ludovic Courtès wrote: > Hi, > > Philip McGrath skribis: > > To start with that, my proposed approach, which I hope satisfies the > > FSDG, is here: https://github.com/racket/srfi/pull/15 > > Good to know; I hope the next

Re: better error messages through assertions

Hi, On Monday, February 28, 2022 7:59:02 AM EST Ludovic Courtès wrote: > Hi! > > Ricardo Wurmus skribis: > > Philip McGrath writes: > >> As a Racketeer, I think you're half way to reinventing contracts. > > > > Yes, I was in fact thinking of contracts, but

Re: Update CoC adapted from upstream 2.1 (instead of 1.4)

On 2/25/22 11:59, Taylan Kammer wrote:> Transwomen have many challenges they have to face, and some of them may be similar or equivalent to some challenges women have to face, but to claim I'm concerned that framing "transwomen" and "women" as though they were two contrasting groups is itself

Re: Faster "guix pull" by incremental compilation and non-circular modules?

Hi, On Sunday, February 20, 2022 7:19:07 AM EST Maxime Devos wrote: > Ekaitz Zarraga schreef op zo 20-02-2022 om 11:34 [+]: > > Making a Guix pull is unpredictable too... > > An idea for making "guix pull" faster: > > 1. Make package imports non-circular, breaking up package modules >

Re: Excessively energy-consuming software considered malware?

On Sunday, February 20, 2022 7:44:18 AM EST Taylan Kammer wrote: > On 20.02.2022 13:37, Maxime Devos wrote: > > The points about slippery slopes, research and niche use-cases seem > > reasonable to me. I do see follow-up questions though, should the > > description in Guix warn about potential

Re: better error messages through assertions

Hi, On 2/14/22 17:32, Ricardo Wurmus wrote: As you can probably tell easily by looking at this message, the “service” field of the operating system configuration looked something like this: (services (append (list a b c %desktop-services) #;oops)) instead of this (services (append

Re: License issue with SRFI 5

and Fedora, too), or is there anything more/different that needs to be done? Philip McGrath skribis: Since 2005, SRFIs have used the MIT/Expat license, and all but two older SRFIs were relicensed: however, the SRFI editors were not able to contact the author of SRFI 5, Andy Gaynor, so

Re: Public key pinning in guix?

Hi, On 1/9/22 06:54, Maxime Devos wrote: Hi, Philip McGrath schreef op za 08-01-2022 om 11:37 [-0500]: This sounds like HTTP Public Key Pinning (HPKP).[1] AIUI, HTTP Public Key Pinning was deprecated, and support has been removed from major browser engines by January 2020.[2][3][4] While

Re: Public key pinning in guix?

Hi, On 1/7/22 16:24, Maxime Devos wrote: The purpose is to resist a compromise of the CA system. More concretely, if you now do "guix refresh -u minetest-moreores" then a MITM that compromised a CA cannot secretly replace minetest-moreores with a mod that mines bitcoin for the MITM, or

Re: default tar format for "make dist" and patch file length

On 11/19/21 09:54, Ludovic Courtès wrote: Vagrant Cascadian skribis: So, I guess I'm leaning towards making the guix lint check a little more lenient. Thoughts? That sounds even better, I’m all for it (changing (guix lint) + fixing the two remaining issues)! It might also help to

License issue with SRFI 5

Hi Guix, I was recently reminded of a thorny license issue with the SRFI 5 standard document, which is part of the main Racket distribution. People from Racket, the SRFI community, Debian, and Fedora have taken steps to help mitigate the problem: I want to make some further improvements, but

Re: How did you handle making a GNU/Linux distribution?

On 9/12/21 11:09 PM, Christine Lemmer-Webber wrote: Philip McGrath writes: Christine Lemmer-Webber had floated the idea at some point of trying to integrate Racket and Guile. IIRC, I think what she's had in mind was trying to make a Guile backend for Racket along the lines of the Chez Scheme

Re: How did you handle making a GNU/Linux distribution?

Hi Simon, On 8/23/21 11:38 AM, zimoun wrote: The bootstrap path of Racket in Guix is not clear to me. I miss if a Racket interpreter or compiler in its binary format is used (as Haskell for instance) or if all is compiled from source using tools already bootstrapped. Anyway, I miss what you

Re: How did you handle making a GNU/Linux distribution?

Hi Sage, On 8/22/21 5:53 PM, Sage Gerard wrote: Thanks for the detailed answer! It seems wise to adapt GNU Mes towards Racket or Chez Scheme instead of Guile to bring GNU's benefits to more Scheme and Racket programmers. Has someone already tried something like that? I haven't tried Xiden

Re: cowsay could attract copyright and trademark enforcement action

On 7/16/21 6:26 PM, Leo Prikler wrote:> As others point out, it is debatable whether or not such a trademark can be enforced, but what we should be discussing -- and I'd be more than happy to be wrong on this -- is whether or not the cowfiles can be distributed under GPL-compatible terms/in

Re: unifying mcron and shepherd, service woes, improvements

On 5/15/21 12:59 PM, Ludovic Courtès wrote: raingloom skribis: Or is everyone else happy with the current design and it's just me who can't use Shepherd properly?  I think it’s fair to say it’s rough on the edges. :-) One thing that’s on the to-do list is switching to a real event loop in

Re: Racket 8 and store references (was [security] Chunked store references in .zo files in Racket 8 #47614)

Indeed, I expect this is a more precise diagnosis of the same problem. My patch in https://issues.guix.gnu.org/47180 solves it by putting the store references (search paths for foreign libraries) in a configuration data file that isn't compiled, so they don't end up in .zo files in the first