packaging Typst?

[Alexis Simon]

Hi,

Is anyone looking into packaging Typst (https://github.com/typst/typst)?

This is a very promising Latex alternative.

If no one is doing that I could try to investigate packaging it but I 
would need some help on where to start.

This is a rust app but not available on crates.io.

Thanks!
Alexis

Re: branch master updated: gnu: Add passff.

[Clément Lassieur]

See here for the patches.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66868

Thanks,
Clément

Re: branch master updated: gnu: Add passff.

[Clément Lassieur]

On Mon, Oct 30 2023, Clément Lassieur wrote:

> Hi Kaelyn,
>
> On Sat, Oct 28 2023, Kaelyn wrote:
>
>> I agree about this. When I packaged passff-host locally some time ago, I saw

> I'm happy I'm not alone packaging Icecat extensions :)
>
>> it has a runtime dependency on python and also needs to be able to find the
>> pass binary.
>
> My patch also has dependencies on python and password-store.  You can
> have a look at documentation about G-Expressions to understand how.

It's indeed better if the inputs are explicit (see conversation with
John) so I amended my patch again to change a few things.  Now it has
fewer dependencies (password-store and python, as you rightfully said
above), and they all are explicit.

>> I've attached the bare (unfinished/unpolished) package definition
>> extracted from my local channel and attached it, for if it is of assistance 
>> to
>> folks.
>
> It's a bit late for passff-host because it's already there (and it works
> well), but if you need help for packaging other Icecat extensions, I'd
> be glad to help.
>
>> My definition tries to embed a sane path for finding pass with a
>> default of the path to the password-store package it was built against, and
>> also tries to copy the passff.json into the correct browser folder for
>
> [...]
>
>> ;; FIXME: The passff.json in etc/ needs to go into a browser-dependent
>> ;; location to work with that specific browser. How to install it to the
>> ;; right location needs to be figured out and documented.
>
> The Icecat browser-dependent location did not exist before
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=25043e01b6cb6696ffdc6cdedd9cdf8235bb695c.
>
> Now it is in /lib/icecat, e.g. /lib/icecat/native-messaging-hosts
>
> [...]
>
>> ;; NOTE: python-build-system is used instead of copy-build-system to
>> ;; automatically pick up the Python 3 dependency and to wrap the 
>> installed
>> ;; Python script.
>
> `trivial-build-system` is enough, most of the work is done by the
> Makefile and install_host_app.sh.

Well this was wrong :) See my updated patch where I use
copy-build-system and don't use Makefile and install_host_app.sh
anymore...

Thanks,
Clément

RFI response: Strengthening the Free Software Supply Chain via Guix and GNUnet

[Maxim Cournoyer]

Hello,

Just for your info, I'm relaying the response I've sent for
consideration to the US government [0] in reply to their RFI (Request
For Information) [1].  It's about adding support for GNUnet for
sharing Guix substitutes.

I had no prior experience authoring these so it is probably written in a
naive style :-).  Reading the other comments, it's interesting to note
how the other submissions cover topics all over the places.  It seems a
common theme is 'rewrite the world in Rust' :-).

[0]  https://www.regulations.gov/comment/ONCD-2023-0002-0033
[1]  https://www.regulations.gov/document/ONCD-2023-0002-0001

-- 
Thanks,
Maxim

[cuirass] Typo?

[Ricardo Wurmus]

Hi,

In (cuirass base) there is this definition:

--8<---cut here---start->8---
(define (exception-reporter . results)
  "Return an exception handler that reports the exception on the error port
and returns the values RESULTS."
  (lambda (key . args)
(false-if-exception
 (let* ((stack (make-stack #t))
(depth (stack-length stack))
(frame (or (and (> depth 1) (stack-ref stack 1))
   (and (> depth 0)) (stack-ref stack 0
   (print-exception (current-error-port) frame key args)
   (apply values results)
--8<---cut here---end--->8---

The parentheses for the binding of “frame” look wrong to me:

(frame (or (and (> depth 1) (stack-ref stack 1))
   (and (> depth 0))
   (stack-ref stack 0)))

-- 
Ricardo

Re: Expressing system test dependencies

[Maxim Cournoyer]

Hi Bruno,

Bruno Victal  writes:

> Hi,
>
> There are system tests that would benefit from being able to express
> that their results are dependent on the result of other tests, when
> these constitute independent units, especially when there are
> configuration variants present. (e.g. gnu/tests/gdm.scm)
>
> Consider the following files/system-tests [1]:
> * gnu/tests/gdm.scm
>   Right now this module implements two tests: %test-gdm-x11 and
>   %test-gdm-wayland. (whose names are self-explanatory)
>
> * gnu/tests/vnc.scm
>   This module implements one test, %test-xvnc, in particular it does so
>   by testing the XDMCP feature using GDM.
>   Note: this module predates gnu/tests/gdm.scm.
>
> Here's where we would benefit from being able to express system-test
> dependencies. Clearly some of the “test-assert” clauses in
> gnu/tests/vnc.scm would be better placed in gnu/tests/gdm.scm as they
> are GDM specific tests. Since they constitute configuration variants of
> the service, it would be placed into a %test-gdm-autosuspend variable.
>
> The rationale for a test-dependency mechanism is as follows:
> Suppose we split the GDM specific test to (gnu tests gdm). Now let's say
> that we run %test-xvnc and it fails. Is the failure due to GDM or is it
> caused by something else? (within the %test-xvnc)
>
> By splitting the test to (gnu tests gdm) we would have to run the GDM
> tests first, which isn't obvious. If we could express a dependency here,
> the debugging experience is improved as we now have a way to know that a
> integral component involved in the test failed. (or could be used to
> rule out other parts)
>
> Since the system-test results are expressed as derivations, successful
> tests shouldn't result in duplicate runs so perhaps we could make use of
> this fact for the effect?

Ideally, any kind of tests would be independent from each other, but for
system tests where it's an integration of various components, we do rely
on the individual components used in a test working.

I'm not sure it's worth adding more complexity though; a failure in GDM
should have been caught at the time packaging/upgrading GDM with its own
test suite; it seems these cases would be very rare, and we have actual
real problems to fix (c.f. our bug tracker) :-).

-- 
Thanks,
Maxim

[PATCH qa-frontpage] Sort the patches before applying them to the git branch.

[Vivien Kraus]

By default, the patches are not ordered.  Because of the unreliability
of e-mail delivery, they can be received completely out of order.
Patchwork may also re-order them, and they may get ordered by commit
author date (or, equivalently, e-mail Date header).  Both
possibilities lead to failure to apply patches if the order is
incorrect for two patches that do not commute.

The patch name contains a header: [bug#xxx,v12,i/n] where "i" is the
variable part and indicates the patch number. Git pads "i" with zeros
if needed. The string order of the names is thus the true commit
order.

* guix-qa-frontpage/manage-patch-branches.scm (create-branch-for-issue):
Sort patches according to their "name".
---
 guix-qa-frontpage/manage-patch-branches.scm | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/guix-qa-frontpage/manage-patch-branches.scm 
b/guix-qa-frontpage/manage-patch-branches.scm
index a42f3a0..74d7b8b 100644
--- a/guix-qa-frontpage/manage-patch-branches.scm
+++ b/guix-qa-frontpage/manage-patch-branches.scm
@@ -243,8 +243,13 @@
(invoke-read-line "git" "show-ref" "--hash" base-tag)))
 
   (let loop ((patch-data
-  (vector->list
-   (assoc-ref patchwork-series "patches")))
+  (stable-sort
+   (vector->list
+(assoc-ref patchwork-series "patches"))
+   (lambda (patch-a patch-b)
+ (let ((name-a (assoc-ref patch-a "name"))
+   (name-b (assoc-ref patch-b "name")))
+   (string

Re: How to get nginx and letsencrypt working on the guix system

[Clément Lassieur]

On Tue, Oct 31 2023, Tobias Alexandra Platen wrote:

> I installed the guix system on a virtual machine, and changed the
> config as documented in the guix manual under 12.9.19 Web Services:
>
> (service certbot-service-type
> (certbot-configuration
> (email "tpla...@posteo.de")
> (certificates (list (certificate-
> configuration
> (domains '("stream.isengaara.de")) (deploy-hook
> %nginx-deploy-hook))
>  ;;; nginx testing
>  (service nginx-service-type 
> (nginx-configuration
>   (server-blocks
> (list (nginx-server-configuration
>   (server-name '("stream.isengaara.de"))
> (root "/srv/http/stream.isengaara.de"))
>
> Certbot needs running nginx to create a certificate, and nginx wont
> start without a certificate. The documentation does not explain how
> to solve this circular service dependency.

Hi!  There is some reading about it there:

https://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Acertbot;package=guix

There is a proposal from Brice but it's not implemented yet, as far as I
know (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46961).

Please talk about it on the bug tracker rather than guix devel, this
allows for better tracking.

Thanks,
Clément

Re: branch master updated: gnu: Add passff.

[Clément Lassieur]

Hi John,

Thanks for taking the time to write this message.

On Tue, Oct 31 2023, John Kehayias wrote:

> Right, it uses gexps but I think here the better and more explicit
> style would be to use inputs/native-inputs. Then instead of
> referencing directly like #$ use
> #$(this-package-input "package-name") to get the store path. This I
> think is clearer and I believe better allows for inheritance,
> input-rewriting, and so on.

You are right, I'll amend my patch, taking this into account.

I believe `guix lint` should say something about it though, maybe warn
when using an input that is not explicitly added in the `input` field.
Those errors are hard to catch and are in our code base at several
places already.

I've also noticed there is some subtle in-between style in our code
base: people adding x as input but still using #$x in the package
definition instead of using #$(this-package-input "x").  It's wrong
because in this case input rewriting does not work.

G-Expressions allow for weird things.  Here's another weird pattern from
our code base: going from (inputs `("foo", ,(origin ...))) to #$(origin
...)  without inputs.  This removes input rewriting too.

> Feel free for anyone else to chime in on this point, I'm always
> looking to learn to improve my own packaging and review, but this is
> what I understand is preferred when possible.
>
>>> Was this change sent as a patch to guix-patches?
>>
>> No it wasn't.
>
> The mantra I've heard, and agree with, is that the
> trivial-build-system is anything but trivial. Not saying it wasn't the
> best choice here, or has anything to do with the above points, but
> thought it worth mentioning for anyone else.

Agreed.

> But this is also why I think it would have been better to have it go
> through review. I see there's been several followup commits to improve
> the style and fix things which also could have been avoided. Not a
> huge deal perhaps, but I would err on the side of review for something
> like this.

I thought my patch was trivial, but I was obviously wrong since I
(indeed) amended it twice, and now a third time.

> Of course, thanks for the contribution!

Thanks for the kind words :)

Clément

Re: How to get nginx and letsencrypt working on the guix system

[Tobias Alexandra Platen]

shepherd: Starting service nginx...
..
Throw to key `%exception' with args `("#< program:
\"/gnu/store/8dgzjx9iirxqbwdcr9nfagjp0mn9g4qy-nginx-1.23.3/sbin/nginx\"
  arguments: (\"-c\" \"/gnu/store/ywl1y1p77sbcm4nf9nahn6q9cndw637f-
nginx.conf\" \"-p\" \"/var/run/nginx\") 
  exit-status: 1 term-signal: #f stop-signal: #f>")'.
  
The directory /var/run/guix does not exist, where is created? How can I
get nginx logs for the failed start?

Re: How to get nginx and letsencrypt working on the guix system

[Julien Lepiller]

Usually, this is fixed by not uting ssl at first, let certbot generate 
certificates, and reconfigure with ssl.

Le 31 octobre 2023 19:23:32 GMT+01:00, Tobias Alexandra Platen 
 a écrit :
>I installed the guix system on a virtual machine, and changed the
>config as documented in the guix manual under 12.9.19 Web Services:
>
>(service certbot-service-type
>(certbot-configuration
>(email "tpla...@posteo.de")
>(certificates (list (certificate-
>configuration
>(domains '("stream.isengaara.de")) (deploy-hook
>%nginx-deploy-hook))
> ;;; nginx testing
> (service nginx-service-type 
>(nginx-configuration
>  (server-blocks
>(list (nginx-server-configuration
>  (server-name '("stream.isengaara.de"))
>(root "/srv/http/stream.isengaara.de"))
>
>Certbot needs running nginx to create a certificate, and nginx wont
>start without a certificate. The documentation does not explain how
>to solve this circular service dependency.
>

How to get nginx and letsencrypt working on the guix system

[Tobias Alexandra Platen]

I installed the guix system on a virtual machine, and changed the
config as documented in the guix manual under 12.9.19 Web Services:

(service certbot-service-type
(certbot-configuration
(email "tpla...@posteo.de")
(certificates (list (certificate-
configuration
(domains '("stream.isengaara.de")) (deploy-hook
%nginx-deploy-hook))
 ;;; nginx testing
 (service nginx-service-type 
(nginx-configuration
  (server-blocks
(list (nginx-server-configuration
  (server-name '("stream.isengaara.de"))
(root "/srv/http/stream.isengaara.de"))

Certbot needs running nginx to create a certificate, and nginx wont
start without a certificate. The documentation does not explain how
to solve this circular service dependency.

Re: Order of manifest and overlapping binaries

[Greg Hogan]

On Mon, Oct 23, 2023 at 10:39 AM Kaelyn  wrote:
>
> Hi,
>
> --- Original Message ---
> On Monday, October 23rd, 2023 at 6:18 AM, Greg Hogan  
> wrote:
>
> >
> > On Tue, May 16, 2023 at 4:55 PM Csepp raingl...@riseup.net wrote:
> >
> > > Greg Hogan c...@greghogan.com writes:
> > >
> > > > I could not find documentation on this circumstance or how to resolve.
> > > > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> > > > can go in the $GUIX_PROFILE.
> > > >
> > > > Creating a container, the latter package overshadows the former
> > > > package, as below. Unclear if this is consistent. In my manifest the
> > > > former package overshadows the latter (I'd prefer to have parallel's
> > > > parallel, but by default I have sorted the listing alphabetically). Is
> > > > there a better way to fix this?
> > > >
> > > > Greg
> > > >
> > > > --8<---cut here---start->8---
> > > > $ guix shell --container moreutils parallel which coreutils
> > > > [env]$ readlink -f `which parallel`
> > > > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
> > > >
> > > > guix shell --container parallel moreutils which coreutils
> > > > [env]$ readlink -f $(which parallel)
> > > > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> > > > --8<---cut here---end--->8---
> > > >
> > > > This is operating from a recent guix pull:
> > > >
> > > > --8<---cut here---start->8---
> > > > $ guix describe
> > > > Generation 44 May 11 2023 17:02:53 (current)
> > > > guix d6f6b57
> > > > repository URL: https://git.savannah.gnu.org/git/guix.git
> > > > branch: master
> > > > commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> > > > --8<---cut here---end--->8---
> > >
> > > You could create a package that just copies the contents of moreutils
> > > to $output, but renames some files, then include the resulting package
> > > in your manifest. If moreutils is not propagated from any other
> > > package, then you don't even have to do an input rewrite.
> >
> >
> > I'm still cutting my teeth on Scheme, and this looks like a simple
> > error, but the following from my manifest results in the error below.
> > The function accepts a package to inherit from and a list of files to
> > rename by appending the package name. This works if I change to pass
> > in a single string and create the list within the for-each argument.
> >
> > (define (rename-files parent-package files)
> > (package/inherit parent-package
> > (arguments
> > (substitute-keyword-arguments (package-arguments parent-package)
> > ((#:phases phases #~%standard-phases)
> > #~(modify-phases #$phases
> > (add-after 'install 'rename-files
> > (lambda* (#:key outputs #:allow-other-keys)
> > (let ((out #$output) (name #$(package-name parent-package)))
> > (for-each
> > (lambda (file)
> > (rename-file (string-append out "/" file)
> > (string-append out "/" file "-" name)))
> > #$files))
> >
> > (define moreutils-decollide
> > (rename-files moreutils (list "bin/parallel")))
> >
> > --8<---cut here---start->8---
> >
> > starting phase `rename-files' error: in phase 'rename-files': uncaught 
> > exception: wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") 
> > ("bin/parallel") phase` rename-files' failed after 0.0 seconds
>
> This error is because using gexps adds an extra layer of expansion on top of 
> normal scheme. The error is coming from the use of "#$files"... specifically 
> in the subform "(for-each (lambda (file) ...) #$files)", #$files is 
> replaced--in the usage example--with exactly ("bin/parallel"), resulting in:
>(for-each (lambda (file) ...) ("bin/parallel"))
>
> Because it is a gexp, #$file is replaced with ("bin/parallel") and then the 
> resulting form is evaluated on the builder. Since ("bin/parallel") now looks 
> like a function call, it tries to treat it as one. The three main options 
> that I know of are to
> 1) quote the argument when calling rename-files so that "list" is first in 
> the literal list:
> (rename-files moreutils '(list "bin/parallel"))
> 2) quote the list within the gexp:
> (for-each (lambda (file) ...) '#$files)
> 3) build the list within the gexp:
> (for-each (lambda (file) ...) (list #@$files)
>
> In my opinion the second option is probably the easiest and safest to work 
> with. #1 and #3 both suffer from needing to specially craft the incoming 
> argument to handle being evaluated twice. For #1, the argument has to be a 
> list after being evaluated twice (the first evaluation is of the quote, the 
> second occurs after the gexp was expanded and calls list with the string 
> arguments). For #3, the expectation of a list is more explicit, but the 
> argument has to evaluate to a list where all of the elements have to then 
> evaluate to something meaningful (not too much 

Re: shepherd-action debug help needed

[Attila Lendvai]

> Exit code 127 means "command not found". [1] More information is
> available in stderr (or sometimes stdout) if you can capture it.

but how come binaries are not found when i have the full path for the 
commands...?

the install binary is only used to set the umask of the result. without it, a 
simple invokation of tar also fails, even without --gzip.

i dug a bit deeper, and it turned out that the SYSTEM call i thought was coming 
from guile was rebound by shepherd to point to its own SPAWN-SHELL-COMMAND. 
through various complex code paths, it ends up calling fork+exec-command. 
SPAWN-SHELL-COMMAND's role is to make the SYSTEM call non-blocking.

as a quick test, i have added a simple (system "ls -l /bin/sh") call to my 
action, and that fails, too.

i'll need to add proper logging to shepherd and see what's going wrong. but for 
that i need https://issues.guix.gnu.org/61750 merged.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Justice is not concerned with the results of the various transactions, but 
only with whether the transactions themselves are fair.”
— F.A. Hayek (1899–1992), 'Law, Legislation and Liberty', I.6.j

Re: Cuirass 1.2.0 released

[Katherine Cox-Buday]

On 10/30/23 10:42 AM, Ludovic Courtès wrote:

Hello Guix!

It’s a bit of a non-event since we’ve been packaging and using snapshots
of Cuirass all along, but nevertheless, I’m totally thrilled to announce
that Cuirass 1.2.0 is out!


Congratulations! It might be my holiday project this year to stand up a 
local instance :)

Re: mesa-updates: call for patches

[Maxim Cournoyer]

Hi John,

John Kehayias  writes:

> Hi Guix-ers,
>
> Time for another round of Mesa and friends updates! I've been waiting
> for another Mesa release but seems the 23.2 series has stalled out and
> now is a good time before 23.3 or 24. I've been using 23.2.1 for some
> packages locally without issue. I would like to get this branch built
> and then promptly merged, assuming no showstoppers. Actually, probably
> just cherry-pick since it is should just be a few commits and I find
> that cleaner, personally (but happy for advice here).

If you're going to put a branch for it and build it whole, I'd simply
merge it whole after it's done building and hasn't regressed on package
failures or other things.

> There's already a CI build job and I'll submit the request to merge
> for hopefully QA to compare. I will also do some ungrafting. Maxim,
> I'm CC'ing you since you mentioned the core-updates cycle about to
> happen, so if this branch takes some time maybe we'll be better off
> just combining. Let me know. Otherwise I hope to have the branch
> building in a few days and then let it churn.

I'd say go for a branch!

> Here is a list of what has been on my radar and I'll be looking to
> apply on the mesa-updates branch. If there's something I missed and
> you think makes sense here (e.g. lower level graphical/X related
> libraries) please let me know. And yes, I need to make a Mesa team. It
> is on my list!
>
> 1. ungraft libx11 and libxpm
>
> 2. update mesa (23.2.1)
>
> 3.  (libepoxy fix for GTK, see 
> )
>
> 4.  (mesa vulkan search-paths)
>
> 5.  (sdl2 vulkan-loader; and update sdl2?)
>
> 6.  (libdrm update; to even newer version 
> now)
>
> 7.  (libxkbcommon update)
>
> 8.  (pixman update)
>
> 9. submit patch for mesa team
>
> Thanks everyone! And when you see the updates pushed on mesa-updates
> and builds become available, please do test and let me know. Or if
> you'd like to join this team of one, happy to have you on board.

Sounds like a fine plan!  Thank you for tackling this!

-- 
Thanks,
Maxim

Re: Proposal: Differentiate products more clearly (Cycle 01)

[pinoaffe]

Hi!

I think it's important to clarify what Guix is (and I really like your
mockups/some of the concrete proposed changes), but I don't quite agree
with the idea behind your proposal.

I think it would be more useful to produce and maintain a clear list of
what guix can do than to bifurcate guix into a package manager and an
operating system, especially since many of the aspects of Guix don't
cleanly fall in either of those two categories.

Luis Felipe  writes:
> This is a proposal to help differentiate Guix, the package manager,
> from Guix System.

Guix is (in my opinion) a (set of) tool(s) with a broad set of features
centered around reproducibly managing software/computers.  Some of those
features enable you to set up and manage entire GNU/linux systems, some
even enable you to do so remotely, others enable you to configure
homedirs, to set up containers, to reproducibly build software or to
manage your computational environment.  In my view, these functions are
all quite tightly intertwined, and I don't think it makes sense to
categorize Guix features as belonging to either the package management
or the operating system side of things.

Since guix packages kernels, since it can install and configure
bootloaders, and since it can manage/configure system-wide services, it
can be used as an "operating system".  I think that it is important to
- clearly communicate the various different things guix can be used for,
- emphasize how guix can be used with other operating systems and tools,
- and to show how these various features relate to each other.

> Background: As far as I understand, Guix was supposed to be GNU's
> package manager, and GNU was supposed to be the operating system: two
> products with two different websites. Unfortunatelly, that didn't
> happen and the Guix website became the home for two products: Guix,
> the package manager, and Guix System, a distribution of the GNU
> operating system.

Guix has become a package manager developed as part of and endorsed by
the GNU project.  GNU (to me) is an operating system family with
significant overlap with the Linux family, and Guix falls somewhere in
between as a distribution of both.  I personally don't see this as a
failure, but I guess that this largely a matter of perspective and
beside the point.

> Since then, both products have been presented almost
> as a single one in the website. Probably as a result of this some
> people call both products by the same name (Guix), and some other
> people don't understand what «Guix» is by skimming through the home
> page.

While there is indeed confusion, presenting Guix as just an operating
system and a package manager would not clear that up (in my opinion),
- since ~guix deploy~ is related to managing operating systems, but is
  not really a function of the operating system itself,
- since ~guix home~ is best used on an entire system managed by guix but
  can IIRC also be used on foreign distros,
- since ~guix shell~ doesn't really fall into either package management
  or operating system territory, etc.

> I've seen comments related to this issue in different places through the 
> years. Some examples:
>
> 2018-01-17 · website: say what Guix is at the very top
> https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00232.html
>
> 2020-01-02 · How to present Guix to a wider audience
> https://lists.gnu.org/archive/html/help-guix/2020-01/msg2.html
>
> 2022-09-16 · Guix as a tool for computational science
> https://10years.guix.gnu.org/video/guix-as-a-tool-for-computational-science/
>
>
> Proposal: In summary, I'd like to propose clearer product differentiation, 
> starting with the following changes:
>
> 0. Main menu: Change Overview and Download items to
>
>Overview
>• Package manager
>• Operating system
>
>Download
>• Package manager
>• Operating system
>
> 1. Home page: Focus on Guix, the package manager.
> 2. Download page: Likewise.
> 3. Operating system home page: New page.
> 4. Operating system download page: New page.
>
> The following mockups illustrate the proposed changes. You can start
> in the Home page mockup, and click links to go to the other
> mockups. If your browser doesn't support PDF, you can find a PNG
> version of each mockup in the same URL paths (simply change the "pdf"
> extension to "png").
>
>
> ·
> Resource: Home page
> Path: https://guix.gnu.org/
> Mockup: 
> https://luis-felipe.gitlab.io/downloads/temp/guix-website-2023-09-21-LF/home-page.pdf
> ·
> Resource: Download page
> Path: https://guix.gnu.org/en/download/
> Mockup: 
> https://luis-felipe.gitlab.io/downloads/temp/guix-website-2023-09-21-LF/download-package-manager-page.pdf
> ·
> Resource: OS Home page
> Path: https://guix.gnu.org/en/operating-system/
> Mockup: 
> https://luis-felipe.gitlab.io/downloads/temp/guix-website-2023-09-21-LF/os-home-page.pdf
> ·
> Resource: OS Download page
> Path: https://guix.gnu.org/operating-system/download/
> Mockup: 

Re: doc: Mention the responsibilities that blocking comes with.

[Ricardo Wurmus]

Simon Tournier  writes:

> +concerns are actively resolved with proposals that work for everyone.  A
> +contributor (which may or may not have commit access) wishing to

Should be “who” instead of “which”.

> +understand its finer details, you are encouraged to read
> +.

Isn’t this URL also supposed to be wrapped in @url?

-- 
Ricardo

Nix Daemon protocol post / Tvix

[Florian Klink]

Hey,

I stumbled across your post
https://guix.gnu.org/blog/2023/a-build-daemon-in-guile/.

I'm working on Tvix (https://tvix.dev/), a reimplementation of Nix in
Rust.

Different components are nicely separated, some of the nix-specific
protocols and formats are developed in a independent, intended to be
general-purpose `nix-compat` crate that doesn't depend on Tvix itself.

All with hopefully comprehensive documentation and a lot of test cases.

Tvix can already evaluate bigger chunks of nixpkgs the same way as Nix,
and come up with the same calculated output paths :-)

Some of the protcols are implemented in a nicer fashion, while providing
a Nix-compatible "view" into the system.

For example, tvix-store is using a content-addressed merkle storage DAG
(tvix-castore) under the hood, allowing partial substitution and store
path subtree sharing.
However we can still provide a Nix-compatible view into all this, so can
synthesize NAR Archives and NARInfo files for a given store path on
demand, if we want to. We currently use the HTTP Binary cache protocol
as a store interface for Nix (via `nar-bridge`, which spins up a
webserver).

At some point, we now also want to implement the daemon protocol - both
a client and server, to allow talking to Nix more directly - be it a
"remote store", or just querying the local Nix store for certain
information. This is so far mostly oriented towards store operations (as
we didn't do too much work on the Builder interface yet)


Nevertheless, I think we should collaborate.

Be that:
 - just a simple exchange of notes about the behaviour of the protocol
 and certain operations
 - discussions about designing new protocols, ensuring interop between
 tvix-store and guix stores (there's some ideas for P2P substitution)
 - or even collaboration and work on getting tvix-store (and tvix-build,
 once it's there) to work with a Guile frontend :-)

I think we're sharing a lot of common interest and would like to start
having these conversations :-)

Cheers,
flokli


Some links:

 - Tvix status update from NixCon 2023
 (https://media.ccc.de/v/nixcon-2023-35254-tvix)
 - Tvix Website: https://tvix.dev/
 - Code: https://code.tvl.fyi/tree/tvix

Request-For-Comment process: concrete implementation

[Simon Tournier]

Hi,

This is a proposal for implementing Request-For-Comment process.
Comment are welcome in #66844 [1]:

1: https://issues.guix.gnu.org/issue/66844


The proposal is highly inspired by Rust RFC:

https://github.com/rust-lang/rfcs

and also by GHC Haskell proposal process [1] and Nix RFC process [2].  Based
on my understanding of Guix community interactions, I write down this
text; below the text for easing the reading.

Cheers,
simon

1: https://github.com/ghc-proposals/ghc-proposals
2: https://github.com/NixOS/rfcs

--

RFC process
===

# -*- mode:org -*-
#+TITLE: Request-For-Comment process
#+DATE: 2023-10-31

+ Issue: 66844
+ Status: pending
+ Supporter: Simon Tournier
+ Co-supporters:

* Summary

The "RFC" (request for comments) process is intended to provide a consistent
and controlled path for new features to enter the Guix project, so that all
stakeholders can be confident about the direction it is evolving in.

* Motivation

The freewheeling way that we add new features to Guix has been good for early
development, but for Guix to become a broadly used system we need to develop
some more self-discipline when it comes to changing our beloved system.  This
is a proposal for a more principled RFC process to make it a more integral
part of the overall development process, and one that is followed consistently
to introduce substancial features.

There are a number of changes that are significant enough that they could
benefit from wider community consensus before being introduced.  Either
because they introduce new concepts, big changes or are controversial enough
that not everybody will agree on the direction to take.

Therefore, the purpose of this RFC is to introduce a process that allows to
bring the discussion upfront and strengthen decisions.  This RFC is used to
bootstrap the process and further RFCs can be used to refine the process.

Note that this process does not cover most of the changes.  It covers
significant changes, for some examples:

 + change of inputs style
   (Removing input labels from package definitions, #49169)
 + introduction of =guix shell= and deprecation of =guix environment=
   (Add 'guix shell' to subsume 'guix environment', #50960)
 + introduction of authentication mechanism (Trustable "guix pull", #22883)
 + massive Python 2 removal
   (Merging the purge-python2-packages branch, mailing list guix-devel)
 + collaboration via team and branch-features
   (several places mailing list guix-devel)

* Detail design

** When you need to follow this process

This process is followed when one intends to make "substantial" changes to the
Guix project.  What constitutes a "substantial" change is evolving based on
community norms, but may include the following.

  + Any change that modifies Guix API
  + Big restructuring of packages
  + Introduction or removal of subcommands

Certain changes do not require an RFC:

  - Adding, updating packages, removing outdated packages
  - Fixing security updates and bugs that don't break interfaces

A patch submission to Debbugs that contains any of the afore-mentioned
substantial changes may be asked to first submit a RFC.

** How the process works

  1. Clone https://git.savannah.gnu.org/git/guix.git
  2. Copy rfc/-template.org to rfc/00XY-good-name.org where good-name is
 descriptive but not too long and XY increments
  3. Fill RFC
  4. Submit to guix-patc...@gnu.org

Make sure the proposal is as well-written as you would expect the final
version of it to be.  It does not mean that all the subtilities must be
considered at this point since that is the aim of review discussion.  It means
that the RFC process is not a prospective brainstorming and the proposal
formalize an idea for making it happen.

The submission of a proposal does not require an implementation.  However, to
improve the chance of a successful RFC, it might be recommended to have an
idea for implementing it.  If an implementation is attached to the detailed
design, it might help the discussion.

At this point, at least one other person must volunteer to be "co-supporter".
The aim is to improve the chances that the RFC is both desired and likely to
be implemented.

Once supporter and co-supporter(s) are committed in the RFC process, the
review discussion starts.  Advertisement of the RFC on the mailing-lists
guix-devel is mandatory and IRC is recommended.

After a number of rounds of review, the discussion should settle and a general
consensus should emerge.  If the RFC is successful then authors may contribute
to the implementation.  This bit is left intentionally vague and should be
refined in the future.

A successful RFC is not a rubber stamp, and in particular still does not mean
the feature will ultimately be merged; it does mean that in principle all the
major stakeholders have agreed to the feature and are amenable to merging it.

An unsuccessful RFC is *not* a judgment on the value of the work, so a refusal
should rather be interpreted as “let’s 

Re: doc: Mention the responsibilities that blocking comes with.

[Simon Tournier]

Hi,

On sam., 14 oct. 2023 at 11:44, Maxim Cournoyer  
wrote:

> I thought I'd advertise this proposed change here:
>  that touches to our common rules, so
> that everyone gets to see it/comment on it.

Here is the change:

--8<---cut here---start->8---
+@url{https://www.seedsforchange.org.uk/consensus}.  It is expected from
+all contributors, and even more so from committers, to help build
+consensus and make decisions based on consensus.  By using consensus, we
+are committed to finding solutions that everyone can live with.  It
+implies that no decision is made against significant concerns and these
+concerns are actively resolved with proposals that work for everyone.  A
+contributor (which may or may not have commit access) wishing to block a
+proposal bears a special responsibility for finding alternatives,
+proposing ideas/code or explain the rationale for the status quo to
+resolve the deadlock.  To learn what consensus decision making means and
+understand its finer details, you are encouraged to read
+.
--8<---cut here---end--->8---

No more comment?  Ready for pushing it?

Cheers,
simon