Re: how to write services (was: Re: Teams)

caton...@gmail.com writes: > Ricardo, the general map of the concepts involved in conceiving a > service is useful > > But in my toot I asked for something different > > I asked for indications about the process (what magic to use in the > REPL) There is no REPL magic. I write the service in c

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

Re: how to write services (was: Re: Teams)

Il giorno mer, 15/06/2022 alle 17.01 +, Blake Shaw ha scritto: > > Catonano: > I think writing a home-service is much easier given that you don't > need to do produce an entire system generation before you find out > what you did wrong;  I suspected something like this This is why I hypotize

Re: RISCV porting effort

Most of you are probably aware that a RISC-V effort is going on in GNU Guix. Ekaitz is working on the GNU Mes bootstrap and Efraim is porting packages (gcc and clang are ported), both NLNet projects. Also with our NSF project we are using GNU Guix for emulators and running on bare metal! We have s

Re: how to write services (was: Re: Teams)

Thanks for the feedback, abelian groups are a good example because so many groups are abelian (fields etc). But, perhaps it's just getting late and the matters are now & the details are slipping my mind, but im starting to realize im unsure of many examples of file-like objects that aren't a file?

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > On the contrary, lets say I'm writing an intro book on CT. If I'm > demonstrating something trivial, say the initial object, I'm not > going to refer to it as "an initial-like object" for the sake of > generality. Neither does Guix? If you'r

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > AFAIK no relation to GNU. > > I thought recalled hearing it used in relation to GNU/Linux. A quick > search > brings up this stackexchange discussion[1], which quotes the book > "Linux > Philosophy" with the following: > > #+begin_example

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > Something I dislike about the ‘file AND file-like objects’ > > construction > > is that it suggests that files and file-like objects are separate > > and > > are handled separately, whereas files (as in, 'local-file' or > > 'computed-file')

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 17:01 [+]: > Thats very good advice and will be a useful guide in refactoring the > parts of the system services documentation. I think in general, we > need to find a nice middle ground between the extremely general and > the immediately sensible, as I re

Re: how to write services (was: Re: Teams)

Ricardo: Thats very good advice and will be a useful guide in refactoring the parts of the system services documentation. I think in general, we need to find a nice middle ground between the extremely general and the immediately sensible, as I remember when I first got into guix 1.5 years ago, arri

Re: Release v1.4?

Hello, Ludovic Courtès ezt írta (időpont: 2022. jún. 15., Sze 11:12): > Hello! > > Josselin Poiret skribis: > > > Should we also make use of the point release to remove some deprecated > > things/switch some defaults? I'm thinking of: > > * removing the swap-devices deprecation warning and com

Re: Set FORCE_SOURCE_DATE=1 by default

On 2022-06-15, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Fri, 10 Jun 2022 16:12:59 -0700 >> Subject: [PATCH] guix: gnu-build-system: Set FORCE_SOURCE_DATE in >> set-SOURCE-DA

Re: On commit access, patch review, and remaining healthy

Hi Simon, zimoun writes: > On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo wrote: > >>> It reduces a bit the pressure on the committers, IMHO. >> >> It raises a bit the pressure on the maintainers, IMHO :-) > > What does it mean “maintainer” here? Guix maintainers > Maybe I miss something but

Re: how to write services (was: Re: Teams)

caton...@gmail.com writes: > Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto: >> >> I found the documentation to be a bit confusing (understandably, as >> its new), but once the workflow snapped together its been amazing to >> see how easy it is to create new services.  > > Th

guix refresh to a specific version?

Hi, I wonder whether this is a way to refresh to a specific version, like one can import a specific version: works:     guix import pypi trytond@6.2.0 does not work:     guix refresh -u trytond@6.2.0     […]     guix refresh: error: trytond: package not found for version 6.2.0 My use-case

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 maradns-3.5.0020/deadwood-3.5.0020/src/Make

how to write services (was: Re: Teams)

Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto: > > I found the documentation to be a bit confusing (understandably, as > its new), but once the workflow snapped together its been amazing to > see how easy it is to create new services.  This is something I'm specifically intere

How to write a service (was: Re: Teams)

Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto: > > I found the documentation to be a bit confusing (understandably, as > its new), but once the workflow snapped together its been amazing to > see how easy it is to create new services.  I'm specifically interested in this issue

Re: Reproducible Builds Status Summary for Guix

Ludovic Courtès skribis: > Hi! > > Vagrant Cascadian skribis: > >> Some rough summaries about the types of issues: >> >> * ecl-* packages account for nearly half of the issues (~500 out of >> ~1000 packages) > > This seems to be a problem with generated identifiers at first sight; > would

Re: Reproducible Builds Status Summary for Guix

Hi! Vagrant Cascadian skribis: > I've been working on Reproducible Builds in guix a fair amount this > month. > > data.guix.gnu.org has proven invaluable for this work, big thanks for > that! > > > https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproduc

Re: Release ?

Efraim Flashner skribis: > I think we do release and then core-updates, before we get bogged down > in fixing packages in core-updates. Agreed! Ludo’.

Re: On commit access, patch review, and remaining healthy

Hi, Arun Isaac skribis: >> That’s why, I think the project should: >> >> 1. change the default branch of “git push” vs the default branch of >> “guix pull”. >> >> 2. add a bit more of checkers on patch submission easing patch >> review. > > I like and support both these ideas. Maybe, they a

Re: Release v1.4?

Hello! Josselin Poiret skribis: > Should we also make use of the point release to remove some deprecated > things/switch some defaults? I'm thinking of: > * removing the swap-devices deprecation warning and compatibility code; > * removing the bootloader-configuration-target warning and compati

Re: Set FORCE_SOURCE_DATE=1 by default

Hi! Vagrant Cascadian skribis: > From 7a39330b56934accef14b5e2ac003e211c7c6c5b Mon Sep 17 00:00:00 2001 > From: Vagrant Cascadian > Date: Fri, 10 Jun 2022 16:12:59 -0700 > Subject: [PATCH] guix: gnu-build-system: Set FORCE_SOURCE_DATE in > set-SOURCE-DATE-EPOCH phase. > > * guix/build/gnu-buil

Re: On commit access, patch review, and remaining healthy

Hi, > That’s why, I think the project should: > > 1. change the default branch of “git push” vs the default branch of > “guix pull”. > > 2. add a bit more of checkers on patch submission easing patch > review. I like and support both these ideas. Maybe, they are even long overdue! ;-) I w