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

[Maxim Cournoyer]

Hello Xinglu!

Thank you for working on it!  I spent the evening trying things but none
worked, so your kudos for finding how to make it work! :-).  Some
comments follow (and a patch implementing them):

Xinglu Chen  writes:

[...]

> @@ -63,6 +64,9 @@
>  (define (configuration-missing-field kind field)
>(configuration-error
> (format #f "~a configuration missing required field ~a" kind field)))
> +(define (configuration-no-default-value kind field)
> +  (configuration-error
> +   (format #f "`~a' in `~a' does not have a default value" kind field)))

The kind and field should be inverted.

>  (define-record-type* 
>configuration-field make-configuration-field configuration-field?
> @@ -112,7 +116,7 @@
>  (define-syntax define-configuration
>(lambda (stx)
>  (syntax-case stx ()
> -  ((_ stem (field (field-type def) doc) ...)
> +  ((_ stem (field (field-type properties ...) doc) ...)

I'd rather keep the 'def' binding for the default value; properties is
too vague and implies many of them, which is not a supported syntax.

> (with-syntax (((field-getter ...)
>(map (lambda (field)
>   (id #'stem #'stem #'- field))
> @@ -121,36 +125,56 @@
>(map (lambda (type)
>   (id #'stem type #'?))
> #'(field-type ...)))
> + ((field-default ...)
> +  (map (match-lambda
> + ((field-type default _ ...) default)
> + ;; We get warnings about `disabled' being an
> + ;; unbound variable unless we quote it.
> + (_ (syntax 'disabled)))

Here I think it'd be better to have the pattern more strict (e.g,
(field-type default-value) or (field-type); so as to not accept invalid
syntax.

I also think it'd be clearer to use another symbol than 'disabled, as
this already has a meaning for the validator and could confuse readers.

> +   #'((field-type properties ...) ...)))
>   ((field-serializer ...)
>(map (lambda (type)
>   (id #'stem #'serialize- type))
> #'(field-type ...
> -   #`(begin
> -   (define-record-type* #,(id #'stem #'< #'stem #'>)
> - #,(id #'stem #'% #'stem)
> - #,(id #'stem #'make- #'stem)
> - #,(id #'stem #'stem #'?)
> - (%location #,(id #'stem #'-location)
> -(default (and=> (current-source-location)
> -source-properties->location))
> -(innate))
> - (field field-getter (default def))
> - ...)
> -   (define #,(id #'stem #'stem #'-fields)
> - (list (configuration-field
> -(name 'field)
> -(type 'field-type)
> -(getter field-getter)
> -(predicate field-predicate)
> -(serializer field-serializer)
> -(default-value-thunk (lambda () def))
> -(documentation doc))
> -   ...))
> -   (define-syntax-rule (stem arg (... ...))
> - (let ((conf (#,(id #'stem #'% #'stem) arg (... ...
> -   (validate-configuration conf
> -   #,(id #'stem #'stem #'-fields))
> -   conf
> + #`(begin
> + (define-record-type* #,(id #'stem #'< #'stem #'>)
> +   #,(id #'stem #'% #'stem)
> +   #,(id #'stem #'make- #'stem)
> +   #,(id #'stem #'stem #'?)
> +   (%location #,(id #'stem #'-location)
> +  (default (and=> (current-source-location)
> +  source-properties->location))
> +  (innate))
> +   #,@(map (lambda (name getter def)
> + (if (equal? (syntax->datum def) (quote 'disabled))

nitpick: eq? suffices to check for symbols.

> + #`(#,name #,getter)
> + #`(#,name #,getter (default #,def
> +   #'(field ...)
> +   #'(field-getter ...)
> +   #'(field-default ...)))
> + (define #,(id #'stem #'stem #'-fields)
> +   (list (configuration-field
> +  (name 'field)
> +  (type 'field-type)
> +  (getter field-getter)
> +  (predicate field-predicate)
> +  (serializer field-serializer)
> +  ;; TODO: What if there is no default value?

Seems this TODO was 

Re: Authenticating maintenance.git

[Leo Famulari]

On Thu, May 06, 2021 at 01:03:21PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> I’ve added a ‘.guix-authorizations’ file in maintenance.git, at last!

Thanks for taking care of this!

Re: linux-libre source tarballs

[Leo Famulari]

On Thu, May 06, 2021 at 01:10:45AM -0300, Alexandre Oliva wrote:
> I have heard about early format changes, but since Linux itself has used
> git archive to generate tarballs on the fly, and published digital
> signatures based on archives generated this way, I presume an
> expectation that changes to the format won't be made without a very
> compelling reason.

I asked because, historically, the linux-libre project has chosen not to
store tarballs of its generated linux-libre source trees.

Linux, on the other hand, does store their tarballs in perpetuity, even
if they are created with `git archive`.

Do you know for sure that Linux generates tarballs "on the fly" and does
not simply preserve the signed tarballs forever?

Otherwise, the PGP signatures could go "stale" at some point, and that
would be unprecedented and unacceptable.

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

[Maxime Devos]

Ludovic Courtès schreef op do 06-05-2021 om 18:30 [+0200]:
> BTW, a dream of mine was to implement RPCs in Scheme.  That is, you’d
> have a macro that would essentially do the same work as MiG (the Mach
> Interface Generator), and then we’d pass the bytes directly to
> ‘mach_msg’.

The lisp bindings have a binding to ‘mach_msg’ (not yet schemified).
Note that the lisp hurd bindings never use "send-message", instead they
bind the C bindings generated by MiG.

Also, ‘implementing RPCs in Scheme’ is something I would like to see
as well.

One thing I have in mind, is that MiG RPCs can block, but mach_msg
itself seems to be perfectly usable in a non-blocking way (maybe using
port notifications?).  If we use something like guile-fibers, and integrate
guile-hurd with fibers, then we may be able to do crazy things like:

  * asynchronuously opening files, for free!
  * asynchronuous 'accept', for free!
  * asynchronuous disk I/O, for free!
  * asynchronuous ... practically anything, for free!

Another possibility is debugging the translator responsible for IP
and at the same time running a web browser (or IRC client, or ...)
based on guile-fibers+guile-hurd.  The web browser wouldn't be overly
bothered by the network translator temporarily being paused (for debugging)
and therefore not responsing to the RPCs for 'connect' et al.

Loading webpages will be delayed of course, but the browser itself won't
hang (so you can still scroll, copy & paste, perhaps browse the file system
...).

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: linux-libre source tarballs

[Maxim Cournoyer]

Hello,

Alexandre Oliva  writes:

[...]

> Back when we made the switch, I wrote extensive documentation and
> recipes as to the possibilities of getting to the GNU Linux-libre
> sources from it, how to verify signatures, etc.  It was to be assessed
> by then maintainers of Guix recipes to build GNU Linux-libre before
> publishing, but it doesn't look like I ever got feedback on them, and
> they hvae been unpublished so far.
>
> Is it correct to assume that they have never reached you?  Would you
> like to have a look and let me know whether they make sense to you?  I'd
> be glad to dig them up and share them with you, if so, and to take your
> feedback towards making them available to the public at large.

I for one have not seen them.  Would you mind making them available
somewhere?  I'd be interested in having a look.

Thanks,

Maxim

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

[Pierre Neidhardt]

Hi Ludo,

Thanks for the links, it's a good starting point.

> For the record, you can read about Guix roles and responsibilities at:
>
>   https://guix.gnu.org/en/blog/2019/gnu-guix-maintainer-collective-expands/

I think a good next step would be to store this information at a more
accessible location on https://guix.gnu.org.  A visitor looking for this
kind of information may not think to browse the blog entries.  It's
also not convenient, since it gets buried deeper and deeper as articles
get published.

> The “Contributing” section of the manual discusses specific policies:
>
>   https://guix.gnu.org/manual/en/html_node/Contributing.html

This page mentions the code of conduct, which gives some guidelines on
communication, but as I understand it, it does not say anything about
structure or governance.

The code of conduct itself could be expanded.  For a start, we could
address some characteristic communication issues that have occurred on
the mailing list over time.  For example, we could add a section on
"Accountability != blame", to paraphrase Jelle.
Another section (a very important one in my opinion) could be about
giving the benefit of the doubt and _ask why_ before policing someone.

Food for thoughts!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Application for aarch64 computing resources

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> On Fri, Apr 02, 2021 at 02:43:20PM -0400, Leo Famulari wrote:
>> 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:
>> 
>> https://github.com/WorksOnArm/cluster/issues/254
>
> Unfortunately our request was not granted, due to limited inventory.

Too bad; thanks for letting us know.

So now’s a good time to spend the project’s money on AArch64 hardware.
I think there’s already some on its ways, right?

If people can think of other potential sponsors, we can get in touch
with them, too!

Thanks,
Ludo’.

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

[Ludovic Courtès]

Maxime Devos  skribis:

> Ludovic Courtès schreef op zo 02-05-2021 om 22:51 [+0200]:
>> > [...] moved it to ;.
>> 
>> Nice!  I knew of the Common Lisp effort this is based on, and the idea
>> of reusing the .lisp code unchanged is smart.  Looks promising!
>
> The initial idea was to keep most of the .lisp code unchanged and ‘convert’
> most lisp -> Scheme by defining appropriate macro's. However:

Ah, I see.

BTW, a dream of mine was to implement RPCs in Scheme.  That is, you’d
have a macro that would essentially do the same work as MiG (the Mach
Interface Generator), and then we’d pass the bytes directly to
‘mach_msg’.

Ludo’.

Re: Bringing substitutes from the Guix Build Coordinator to users

[Ludovic Courtès]

Hallo!

Andreas Enge  skribis:

> Relatedly, and this may already be documented: How do I know where the
> packages are downloaded from?
> $ guix package -u
> substitute: updating substitutes from 'https://bayfront.guix.info'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>  imagemagick-6.9.12-4-doc  4.6MiB1.6MiB/s 00:01 [#
>  ]  32.5%
> Before the print format overhaul, the full URL would be printed.

You can use ‘-v2’ to see URLs:

  https://guix.gnu.org/manual/devel/en/html_node/Common-Build-Options.html

> Does the guix daemon complain when substitute URLs do not match any
> authorised key?

No, it just ignores it.

Ludo’.

Re: bug#47615: [PATCH 1/9] gnu: bootstrap: Add support for powerpc-linux.

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Chris Marusich  writes:
>
>> Efraim Flashner  writes:
>>
>>> On 923bb70a1bff657125c3008f119a477e5cb57c2b
>>>gnu:glibc-for-bootstrap: Fix patch.
>>>
>>> Run
>>> ./pre-inst-env guix build --target=powerpc-linux-gnu bootstrap-tarballs
> g>>
>>> Producing
>>>
>>> /gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0
>>>
>>> With guix hash -rx 
>>> /gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0
>>>
>>> 02xx2ydj28pwv3vflqffinpq1icj09gzi9icm8j4bwc4lca9irxn
>>
>> Generally speaking, this patch looks fine to me.  Just curious, what
>> sort of machines does one use for 32-bit powerpc?
>>
>> I want to build the bootstrap binaries, see if they're reproducible (in
>> particular GCC, which I suspect won't be), and verify the hashes.
>>
>> It might take a few days to do that, but I'll update this thread once
>> I've done it.
>
> I repeated Efraim's steps on two different x86_64-linux Guix System
> machines.  In both cases, it produced exactly the same hash.  Therefore,
> it would seem these bootstrap binaries are actually reproducible.

This is great news, thanks for checking!

With this, we can be more confident uploading the binary seeds to
ftp.gnu.org.

> I was surprised by this because of my experience with bug 41669.  I
> expected GCC to not be reproducible, but in this case it seems
> reproducible.

Yes, that’s weird, but it’s better this way.  :-)

Thanks,
Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner]

On Thu, May 06, 2021 at 04:48:09PM +0200, Ludovic Courtès wrote:
> Efraim Flashner  skribis:
> 
> > * gnu/packages/disk.scm (mac-fdisk): New variable.
> > * gnu/packages/patches/mac-fdisk-gentoo-patchset.patch,
> > gnu/packages/patches/mac-fdisk-p18.patch: New files.
> > * gnu/local.mk (dist_patch_DATA): Register them.
> 
> [...]
> 
> > +++ b/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
> > @@ -0,0 +1,866 @@
> > +https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/mac-fdisk/files
> 
> 
> [...]
> 
> > +++ b/gnu/packages/patches/mac-fdisk-p18.patch
> > @@ -0,0 +1,2070 @@
> > +This is the result of unzipping the 0.1-18 diff.gz
> > +https://cdn-aws.deb.debian.org/debian/pool/main/m/mac-fdisk/mac-fdisk_0.1-18.diff.gz
> 
> Given the size of these patches, please add a couple of sentences
> explaining what they do.
> 
> It would be best if we could refer to a fork instead of carrying those
> patches, though.
> 
> Ludo’.

I think I'm going to sit on the mac-fdisk package for a while. It would
be good to cut down the patches a bit. And I have to actually test it at
some point.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Maxime Devos  skribis:

> Efraim Flashner schreef op do 22-04-2021 om 10:59 [+0300]:
>> * gnu/packages/version-control.scm (mercurial)[arguments]: Skip tests on
>> powerpc-linux.
>> ---
>>  gnu/packages/version-control.scm | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> Unchanged since last patchset, IMO not ready for upstreaming.
>> 
>> diff --git a/gnu/packages/version-control.scm 
>> b/gnu/packages/version-control.scm
>> index 4d4b276a10..13e2ccd400 100644
>> --- a/gnu/packages/version-control.scm
>> +++ b/gnu/packages/version-control.scm
>> @@ -1688,7 +1688,11 @@ execution of any hook written in any language before 
>> every commit.")
>>   "--slowtimeout" "86400"
>>   ;; The test suite takes a long time and produces 
>> little
>>   ;; output by default.  Prevent timeouts due to 
>> silence.
>> - "-v"
>> + "-v"))
>> +   ;; Tests on powerpc-linux take more than 10 hours.
>> +   #:tests? ,(if (string=? "powerpc-linux" (or (%current-system)
>> +   
>> (%current-target-system)))
>> +   '#f '#t)))
>
> You can remove ' in '#f and '#t here.

You can even write:

  #:tests? (not (string-prefix? "powerpc-" (or …)))

Note: use ‘string-prefix?’ because ‘%current-target-system’ returns a
triplet, not a “system type”.

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Efraim Flashner  skribis:

> * gnu/packages/disk.scm (mac-fdisk): New variable.
> * gnu/packages/patches/mac-fdisk-gentoo-patchset.patch,
> gnu/packages/patches/mac-fdisk-p18.patch: New files.
> * gnu/local.mk (dist_patch_DATA): Register them.

[...]

> +++ b/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
> @@ -0,0 +1,866 @@
> +https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/mac-fdisk/files


[...]

> +++ b/gnu/packages/patches/mac-fdisk-p18.patch
> @@ -0,0 +1,2070 @@
> +This is the result of unzipping the 0.1-18 diff.gz
> +https://cdn-aws.deb.debian.org/debian/pool/main/m/mac-fdisk/mac-fdisk_0.1-18.diff.gz

Given the size of these patches, please add a couple of sentences
explaining what they do.

It would be best if we could refer to a fork instead of carrying those
patches, though.

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Efraim Flashner  skribis:

> * gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two
> phases to adjust for 32-bit big-endian systems.

[...]

> + (add-after 'unpack 'adjust-bootstrap-flags
> +   (lambda _
> + ;; Upstream knows about suggested solution.
> + ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214

The first comment line should preferably mention the problem, like:

  ;; Change optimization flags to work around crash on
  ;; 32-bit big-endian architectures: .

> + (substitute* "bootstrap/Makefile.in"
> +   (("^GUILE_OPTIMIZATIONS.*")
> +"GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives 
> -Ocps\n"
> + (add-after 'unpack 'remove-failing-tests
> +   (lambda _
> + ;; TODO: Discover why this test fails on powerpc-linux
> + (delete-file 
> "test-suite/standalone/test-out-of-memory"))

I’m surprised removing the executable works.  See
‘guile-2.2-skip-oom-test.patch’.

Ludo’.

Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Ludovic Courtès]

Hi Efraim,

Efraim Flashner  skribis:

> On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote:

[...]

>>   3. OTOH, what will be the status of this architecture?  I don’t think
>>  new 32-bit PPC hardware is being made (right?), so I guess we
>>  probably won’t have substitutes for that architecture.  That means
>>  it won’t be supported at the same level as other architectures and
>>  may quickly suffer from bitrot.
>
> I don't know about new 32-bit powerpc hardware, I think it's only being
> newly created for the embedded and networking space. As far as operating
> systems with support¹ Adélie Linux is the only one I know that's
> actually targeting the machines.
>
> I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is
> faster than building on native hardware (1 core, 1.5GB of RAM, original
> 4200 RPM disk), edging it out on single threaded compiling and doing
> great when it comes to using multiple cores and parallel builds.
> Ignoring how to create an OS image if we just targeted, say, mesa and
> maybe one or two other packages, we could have a core set which doesn't
> change regularly and won't take up too much emulated build time but will
> save days of compile time.

[...]

> The fear of bit-rot is real and I think we should mention in the manual
> (when I actually write the section) that support is best-effort with
> minimal substitutes.

I feel like “best-effort with minimal substitutes” is already more than
I’d be willing to commit to as a maintainer.

We just added POWER9, for which we have actual hardware, and even
getting to this minimal state where we provide a binary tarball required
quite some effort.

Doing the same with 32-bit PowerPC would require us to set up emulation;
we wouldn’t even have real hardware.

All in all, my preference would be to take the patches but not mention
PowerPC 32-bit support anywhere, or at least, not provide substitutes
and binary installation tarball.  IOW, few people would know whether it
actually works :-) but tinkerers could still play with it.

WDYT?

Ludo’.

Re: RISC-V is giving away developer boards

[Pjotr Prins]

> is this thread [1] ("Porting Guix to RISCV", from last october) the latest
> news on developments regarding guix and RISC-V?

Pretty much.

We have a few interested people here! GNU Mes is on board to help
create a bootstrap. I think it makes sense to submit an application to
NLNet and it also makes sense to become a member for RISC-V - and
maybe we can get some hardware.

I don't think it is appropriate to discuss ins and outs on this
mailing list. 

I set up an IRC channel #guix-risc-v. Connect from matrix with
#freenode_#guix-risc-v:matrix.org

Pj.

Re: RISC-V is giving away developer boards

[Gabriel Wicki]

hi

i'm also interested and in fact looking for an opportunity for my
bachelor thesis (coming fall semester). so i'd happily invest something
like 8-10hrs/week for 12-14 weeks (sept-dec). though not an expert with
neither guix nor risc-v i'd try to make up with enthusiasm and willpower.
and probably some of your help ;)

i guess the goal would be to get *guix system* to work on RISC-V
platforms, right?

is this thread [1] ("Porting Guix to RISCV", from last october) the latest
news on developments regarding guix and RISC-V?


g

[1] https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00498.html

Authenticating maintenance.git

[Ludovic Courtès]

Hello Guix!

I’ve added a ‘.guix-authorizations’ file in maintenance.git, at last!
We can now authenticate the repository we’ve checked out:

  guix git authenticate 8a7e10b447b574279a7016ae6ea15bc7bcd46253 \
"3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5" --stats

It’s also possible to authenticate all changes made to the repo since
the first signed commit in July 2016 by running:

  guix git authenticate 7f59985566b384e31da7e6f1a36744e9edfba54f \
"3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5" \
--historical-authorizations=historical-authorizations

If you ran the first command above before, you might want to clear your
authentication cache with:

  rm -rf ~/.cache/guix/authentication/checkouts

Note that ‘.guix-authorizations’ is a subset of the one on the main Guix
repository, but we can add people as needed.  I invite committers to
install the pre-push hook as mentioned in README:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/README

Happy hacking!

Ludo’.


signature.asc
Description: PGP signature