Re: Deep vs Shallow trace: Removing the tradeoff?

[ilmu]

> What’s currently implemented is memoization: the hash (of the .drv and
> that of the output(s)) is computed over all the inputs.
>
> Since the output file name (the one passed to “./configure --prefix” &
> co.) appears in the build result 99% of the time, the content vary at
> least due to occurrences of the output file name.
>
> Thus, content comparison are not doable as is. What would help is
> content comparison modulo output file name(s).
>
> But again, “same hash as it did before” is a framing that doesn’t hold
> in a purely functional, stateless context.

Thank you for the clarification. Although, I must admit, I am not sure why the 
filename would change (except if it happens as a consequence of the hash being 
put in the filename).

I will need to spend the next few months actually reading the code and getting 
familiar with how things work "on the ground" before I can have anything useful 
to say. The reason I started this particular discussion was mostly to get a 
reality check whether the same methods apply in the build system context as in 
other authenticated datastructures (I don't see why not but I'm a layman, hence 
reality checks..)

In any case, glad to receive and answer. Keep up the good work! :)

Kind regards,
- Ilmu

Re: Security related tooling project

[Bengt Richter]

Hi,

tl;dr:

Given that crims  monitor developer discussions to discover
unfixed vulnerabilities and clues re exploiting them,
what are your ideas to avoid building a tool that can be abused?

E.g., How will your tool avoid leaking info during an embargo window
while trusted developers are secretly/privately fixing
critical vulns?

 (pls excuse the top-post)
 --
 
On +2021-04-17 17:20:13 +0200, Ludovic Courtès wrote:
> Hello Chris!
> 
> Christopher Baines  skribis:
> 
> > In May last year (2020), I submitted an application to NLNet. The work I
> > set out wasn't something I was doing at the time, but something I hadn't
> > yet found time to work on, tooling specifically around security issues.
> >
> > The application got a bit lost, probably somewhat down to email issues
> > on my end. Anyway, things picked up again in February of this year
> > (2021), and this is now something I'm looking to do roughly over the
> > next 8 months.
> 
> I’m late to the party, but I think this is excellent news!  Well done!
> 
> > 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/
> 
> [...]
> 
> > In terms of looking at security from a project perspective, I'm thinking
> > about these kinds of needs/questions:
> >
> >  - What security issues affect this revision of Guix? (latest or otherwise)
> >
> >  - How do Guix contributors find out about new security issues that
> >affect Guix revisions they're interested in?
> >
> > From the user perspective, I want to look at things like:
> >
> >  - How do I find out what (if any) security issues affect the software
> >I'm currently running (through Guix)?
> >
> >  - How can I get notified when a new security issue affects the software
> >I'm currently running (through Guix)?
> 
> That sounds like a great plan!
> 
> I see several “intermediate” issues that would be super helpful for the
> overall project, such as better CPE matching as Léo suggested and/or
> providing CPE suggestions: .
> 
> I think the Data Service is in a great position to help out
> wrt. monitoring.  I think it’d be nice to architect things in a way that
> services enhance monitoring, but are not required for get proper
> monitoring.  For instance, the proposed ‘guix health’¹ can be
> implemented without relying on intermediate services at all (it still
> needs to rely on the NIST server, of course, but we don’t need extra
> services.)
> 
> Anyhow, it’s awesome to see you work in this area.  Like Chris Marusich
> wrote, Guix is in a good position to address security issues, and you’re
> obviously in a very good position to know what and how to improve the
> state of things in Guix, so all hail!
> 
> Ludo’.
> 
> ¹ https://issues.guix.gnu.org/31442
> 

-- 
Regards,
Bengt Richter

Re: 1.2.1 pre-release testing

[Leo Famulari]

On Sat, Apr 17, 2021 at 07:09:59PM -0500, Guu, Jin-Cheng wrote:
> I've just tried again the same ISO, and chose "wired". It works right
> away this time. I think it was just a tiny hiccup last time. Should
> have tried more times then.. sorry about that!

Thanks a lot for testing again! We really appreciate it :)

Re: GIT_EXEC_PATH Re: 1.2.1 pre-release testing

[François]

On Sat, Apr 17, 2021 at 01:24:51PM -0400, Leo Famulari wrote:
> On Sat, Apr 17, 2021 at 01:35:45PM +0200, François wrote:
> > GIT_EXEC_PATH is very probably at fault.
> > 
> > It is set via profile to allow to use git subcommands installed by other
> > packages but it has no sane default when we are outside a profile.
> > 
> > Perhaps git should have a wrapper to manage this use-case.
> 
> I think it does work properly in Guix, but requires the user to log in
> again after installing Git. That's because a lot of Guix stuff is set up
> in the login shell initialization scripts. It might even be enough to do
> `bash --login` after installing the package.

I had exactly the same problem on foreing distro after installing git
and trying to use it without reloading ~/.guix-profile/etc/profile in
my current shell. So yes, it is just a matter of refreshing the current
environment.

> I guess that many of us install Git right away, so we don't notice a
> problem.

Probably.

GIT_EXEC_PATH Re: 1.2.1 pre-release testing

[François]

Hello,

On Sat, Apr 17, 2021 at 01:43:33AM -0400, Leo Famulari wrote:
> On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote:
> >2.1. Better support for using git during installation process?
> > 
> >Before `guix system init /mnt/etc/config.scm /mnt', I'd like to getch
> >config.scm from my github repo. So I ran `guix package -i git'. But
> >when I `git clone ...' as usual, there's an error "git:
> >'remote-https' is not a git command .See 'git --help'".

> I also found some suggestions regarding $GIT_EXEC_PATH needing to be
> set.

GIT_EXEC_PATH is very probably at fault.

It is set via profile to allow to use git subcommands installed by other
packages but it has no sane default when we are outside a profile.

Perhaps git should have a wrapper to manage this use-case.

François

Re: 1.2.1 pre-release testing

[Guu, Jin-Cheng]

> Does the ethernet cable work on the installed system?  Or on other
> free distros?

It has never failed on me before, even when I was installing arch
linux. So I was a bit surprise yesterday. It had also worked before in
the Guix System I got from the official - so I suppose that's a
completely free distro. Maybe it was just a tiny hiccup..

> If Ethernet is only broken in the installer though, then the installer
> is at fault.

Urgh.. I should have tested it more extensively before installing
using cli. At that point that wasn't a huge problem for me, since my
wifi happened to work..

Jin

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

Hello Jin,

On Sat, Apr 17, 2021 at 01:27:09PM -0400, Leo Famulari wrote:
> I re-installed my Guix System based on the ISO found here:
> 
> https://ci.guix.gnu.org/build/175632/details
> 
> That's '/gnu/store/lw1j4gn8h51cbfp9dg0g025ngkg83sw1-image.iso.drv'.

Ethernet works on the four machines I tested.  Probably it is an issue
with missing hardware support in the Linux-libre kernel, but you could
try again or look at h-node.org if they have or have not listed your
laptop having working Ethernet.

Regards,
Florian

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

[Vincent Legoll]

Hi,

On Sat, Apr 17, 2021 at 9:44 PM Efraim Flashner  wrote:
> As far as operating systems with support¹ Adélie Linux is the only
> one I know that's actually targeting the machines.

There's also a void port being worked on, but not
upstreamed yet (https://voidlinux-ppc.org)

gentoo, openbsd & netbsd also still have support too.

-- 
Vincent Legoll

Re: bug#47615: [PATCH 3/9] gnu: binutils: Adjust test suite on powerpc-linux.

[Chris Marusich]

Chris Marusich  writes:

> (define binutils-boot0
>   (package
> (inherit binutils)
> (source (bootstrap-origin (package-source binutils)))
> (name "binutils-cross-boot0")
> (arguments
>  `(#:guile ,%bootstrap-guile
>#:implicit-inputs? #f
>
>#:modules ((guix build gnu-build-system)
>   (guix build utils)
>   (ice-9 ftw)); for 'scandir'
>
>,@(substitute-keyword-arguments (package-arguments binutils)
>((#:configure-flags cf)
> `(cons ,(string-append "--target=" (boot-triplet))
>,cf))
>;; The presence of '%standard-phases as the default value here is
>;; important.  It ensures that even when (package-argument
>;; binutils) does not already contain the #:phases keyword
>;; argument, the substitution will occur.  If you omit a default
>;; value and (package-arguments binutils) does not contain the
>;; #:phases keyword argument (e.g., on an x86_64-linux system),
>;; then the substitution will not occur, and no phases at all will
>;; be added.
>((#:phases phases '%standard-phases)
> `(modify-phases ,phases
>,@(if (string=? (%current-system) "powerpc-linux")
>  '((add-after 'unpack 'disable-rust-libiberty-test
>  (lambda _
>(substitute* "libiberty/testsuite/Makefile.in"
>  ((" check-rust-demangle ") ""))
>#t)))
>  '())
>(add-after 'install 'add-symlinks
>  (lambda* (#:key outputs #:allow-other-keys)
>;; The cross-gcc invokes 'as', 'ld', etc, without the
>;; triplet prefix, so add symlinks.
>(let ((out (assoc-ref outputs "out"))
>  (triplet-prefix (string-append ,(boot-triplet) "-")))
>  (define (has-triplet-prefix? name)
>(string-prefix? triplet-prefix name))
>  (define (remove-triplet-prefix name)
>(substring name (string-length triplet-prefix)))
>  (with-directory-excursion (string-append out "/bin")
>(for-each
> (lambda (name)
>   (symlink name (remove-triplet-prefix name)))
> (scandir "." has-triplet-prefix?)))
>
> (inputs (%boot0-inputs

Sorry, I meant to write this instead:

(define binutils-boot0
  (package
(inherit binutils)
(source (bootstrap-origin (package-source binutils)))
(name "binutils-cross-boot0")
(arguments
 `(#:guile ,%bootstrap-guile
   #:implicit-inputs? #f

   #:modules ((guix build gnu-build-system)
  (guix build utils)
  (ice-9 ftw)); for 'scandir'

   ,@(substitute-keyword-arguments (package-arguments binutils)
   ((#:configure-flags cf)
`(cons ,(string-append "--target=" (boot-triplet))
   ,cf))
   ;; The presence of '%standard-phases as the default value here is
   ;; important.  It ensures that even when (package-argument
   ;; binutils) does not already contain the #:phases keyword
   ;; argument, the substitution will occur.  If you omit a default
   ;; value and (package-arguments binutils) does not contain the
   ;; #:phases keyword argument (e.g., on an x86_64-linux system),
   ;; then the substitution will not occur, and no phases at all will
   ;; be added.
   ((#:phases phases '%standard-phases)
`(modify-phases ,phases
   (add-after 'install 'add-symlinks
 (lambda* (#:key outputs #:allow-other-keys)
   ;; The cross-gcc invokes 'as', 'ld', etc, without the
   ;; triplet prefix, so add symlinks.
   (let ((out (assoc-ref outputs "out"))
 (triplet-prefix (string-append ,(boot-triplet) "-")))
 (define (has-triplet-prefix? name)
   (string-prefix? triplet-prefix name))
 (define (remove-triplet-prefix name)
   (substring name (string-length triplet-prefix)))
 (with-directory-excursion (string-append out "/bin")
   (for-each
(lambda (name)
  (symlink name (remove-triplet-prefix name)))
(scandir "." has-triplet-prefix?)))

(inputs (%boot0-inputs

The point is that we can probably "inherit" the phases, so we wouldn't
have to repeat ourselves.

-- 
Chris


signature.asc
Description: PGP signature

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

[Chris Marusich]

Efraim Flashner  writes:

> * gnu/packages/base.scm (binutils)[arguments]: Add phase on
> powerpc-linux to adjust the test suite.
> * gnu/packages/commencement.scm (binutils-boot0)[arguments]: Move custom
> phases after inherited arguments. Add phase on powerpc-linux to adjust
> the test suite.

Nits: adjust the test suite to do what?  The message would be clearer if
it explained the purpose of the adjustment.  You could also name the
phases you added/moved, for extra clarity, if you want to.

> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index dbb7c619fe..b9fc0a6e29 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -531,7 +531,16 @@ change.  GNU make offers many powerful extensions over 
> the standard utility.")
>  
>;; Make sure 'ar' and 'ranlib' produce archives in 
> a
>;; deterministic fashion.
> -  "--enable-deterministic-archives")))
> +  "--enable-deterministic-archives")
> +  ,@(if (string=? (%current-system) "powerpc-linux")
> +  `(#:phases
> +(modify-phases %standard-phases
> +  (add-after 'unpack 'disable-rust-libiberty-test
> +(lambda _
> +  (substitute* "libiberty/testsuite/Makefile.in"
> +((" check-rust-demangle ") ""))
> +  #t
> +  '(

What's the problem?  Presumably the test fails; a comment here could
clarify that.

If it's a test failure, has the issue been reported upstream?

> (synopsis "Binary utilities: bfd gas gprof ld")
> (description
> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index 7c39a84008..f707a01d30 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -2653,7 +2653,22 @@ exec " gcc "/bin/" program
> #:modules ((guix build gnu-build-system)
>(guix build utils)
>(ice-9 ftw)); for 'scandir'
> +
> +   ;; #:phases gets modified for powerpc-linux in binutils,
> +   ;; so #:phases here needs to be after the inherited one.
> +   ,@(substitute-keyword-arguments (package-arguments binutils)
> +   ((#:configure-flags cf)
> +`(cons ,(string-append "--target=" (boot-triplet))
> +   ,cf)))
> +
> #:phases (modify-phases %standard-phases
> +  ,@(if (string=? (%current-system) "powerpc-linux")
> +  '((add-after 'unpack 'disable-rust-libiberty-test
> +  (lambda _
> +(substitute* "libiberty/testsuite/Makefile.in"
> +  ((" check-rust-demangle ") ""))
> +#t)))
> +  '())
>(add-after 'install 'add-symlinks
>  (lambda* (#:key outputs #:allow-other-keys)
>;; The cross-gcc invokes 'as', 'ld', etc, without the
> @@ -2667,12 +2682,8 @@ exec " gcc "/bin/" program
>  (with-directory-excursion (string-append out "/bin")
>(for-each (lambda (name)
>(symlink name (remove-triplet-prefix 
> name)))
> -(scandir "." has-triplet-prefix?)))
> +(scandir "." has-triplet-prefix?)
>  
> -   ,@(substitute-keyword-arguments (package-arguments binutils)
> -   ((#:configure-flags cf)
> -`(cons ,(string-append "--target=" (boot-triplet))
> -   ,cf)
>  (inputs (%boot0-inputs
>  
>  (define libstdc++-boot0

I think you can put all of this in the substitute-keyword-arguments
form, which would (1) eliminate the need for a comment, (2) eliminate
the need to worry about the order of the keyword arguments, and (3)
eliminate the need to duplicate the new phase in two package
definitions:

(define binutils-boot0
  (package
(inherit binutils)
(source (bootstrap-origin (package-source binutils)))
(name "binutils-cross-boot0")
(arguments
 `(#:guile ,%bootstrap-guile
   #:implicit-inputs? #f

   #:modules ((guix build gnu-build-system)
  (guix build utils)
  (ice-9 ftw)); for 'scandir'

   ,@(substitute-keyword-arguments (package-arguments binutils)
   ((#:configure-flags cf)
`(cons ,(string-append "--target=" (boot-triplet))
   ,cf))
   ;; The presence of '%standard-phases as the default value here is
   ;; important.  It ensures that even when (package-argument
   ;; binutils) does not already contain the #:phases keyword
   ;; argument, the substitution will occur.  If you omit a default
   ;; value and (package-arguments binutils) does not contain the
   ;; 

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

[Efraim Flashner]

On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> I haven’t looked into details so I’ll just share thoughts from a
> maintenance viewpoint:
> 
>   1. Those fdisk patch file names will make ‘guix lint’ unhappy.  :-)

I'll make sure to touch them up. I was also not happy about the
supported-architectures field of the package, I took that from Debain
(or was it Gentoo?) but I'm not sure of a technical reason why it can't
be built from other architectures.

>   2. Apart from mac-fdisk-p18.patch, which looks relatively big, the
>  changes seem to be rather non-intrusive, so it’s tempting to merge
>  them (on ‘core-updates’ I guess?).

Before I found some of the patches I played around with fixing the
package. Without looking at the patches too closely some of them fix
warnings and some of them actually make it compile correctly.

>   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.

> I’m torn between #2 and #3.
> 
> What do people think?

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.

> Thanks,
> Ludo’.

¹ https://en.wikipedia.org/wiki/PowerPC#Operating_systems_with_native_support

-- 
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: New 'version-1.3.0' branch and lifting string freeze on master

[Leo Famulari]

On Sat, Apr 17, 2021 at 02:44:52PM -0400, Maxim Cournoyer wrote:
> To avoid keep master in string freeze longer, I've now created the
> 'release-v1.3.0' branch where the fixes for the remaining blocking
> issues should go.

I kept a list of patches that were being held back due to the string
freeze:

https://bugs.gnu.org/47794
https://bugs.gnu.org/47804
https://bugs.gnu.org/47097
https://bugs.gnu.org/47763
https://bugs.gnu.org/47136

If the only thing blocking them was the string freeze, they can be
pushed to the master branch now.

New 'version-1.3.0' branch and lifting string freeze on master

[Maxim Cournoyer]

Hello!

With the remaining issues to be tackled for the current release (v1.3.0)
due tomorrow, I think we may need a bit of extra time to fix them and do
more testing.  These are the remaining issues (obtained by pressing the
'b' key in Emacs Debbugs while visiting the parent issue with
'debbugs-gnu-bugs RET 47297 RET').  The release task issue can also be
viewed at https://issues.guix.gnu.org/47297.

47808 important  Bone Baboonguile-git-0.5.0.drv build failed on 
i686-linux
47567 important  Alexandru-Sergiu M Installer crash in 'uuid->string' for a 
FAT16 partition
44872 important  Tim Magee  GuixSD 1.2.0 installer fails with exception 
when formatting drive
33848 important  Ludovic CourtèsStore references in SBCL-compiled code are 
"invisible"
47841 normal Julien Lepiller[release 1.2.1] could not install on 
foreign distro
47745 normal Mathieu Othacehe   ldap test is failing
47744 normal Mathieu Othacehe   nfs-root-fs test is failing

To avoid keep master in string freeze longer, I've now created the
'release-v1.3.0' branch where the fixes for the remaining blocking
issues should go.

I'll now attempt to produce a first release candidate (RC) via the
release tooling.

Thanks,

Maxim

Re: Feature request: hostname namespaces in guix environment

[Vinícius dos Santos Oliveira]

Em sáb., 17 de abr. de 2021 às 13:10, Ludovic Courtès  escreveu:
> Hi Vinícius,

Hi Ludovic,

> What we could do is add a ‘--uid’ option to ‘guix environment’ and/or a
> ‘--host-name’ option.
>
> WDYT?

The --host-name option would work for me. That'd be enough to control
xpra unix socket names.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page

[Christopher Baines]

Luciana Lima Brito  writes:

> On Sat, 17 Apr 2021 14:11:37 +0100
> Christopher Baines  wrote:
>
> Hi,
>
>> I think that's better, but you're still taking the matched-outputs,
>> matched-inputs and matched-sources alists, then later making the
>> values vectors rather than lists. The code would be even simpler if
>> you converted to a vector just after the map that produces the
>> relevant lists.
>>
>> I haven't looked to closely at the rest, but it looks like the
>> environment-variables binding is unnecessary, given how simple the bit
>> of code used is, it can just be inlined in the one place where the
>> binding is used.
>
> Done! :)
> I even simplified some other stuff, based on what you said.

Great, I think that looks much simpler.

Some more things to think about:

 - Variable naming, what does the "matched" in matched outputs mean?
   (same goes for the other "matched" things)

 - (if (null? ...), I'm unsure if all of those checks are necessary, I
   believe some fields at least will never be "null?".

 - Builder and arguments grouping, I think this makes sense on the HTML
   page, as they're connected, but does it make sense in the JSON?

I think you're getting close to something that's ready to merge though.

Chris


signature.asc
Description: PGP signature

Re: 1.2.1 pre-release testing

[Leo Famulari]

I re-installed my Guix System based on the ISO found here:

https://ci.guix.gnu.org/build/175632/details

That's '/gnu/store/lw1j4gn8h51cbfp9dg0g025ngkg83sw1-image.iso.drv'.

It's a simple system, but the process worked for me.

It successfully recognized and re-used my existing /home partition.

No trouble with the laptop's ethernet connection, and no trouble with
missing substitutes or failing substitution.

Re: GIT_EXEC_PATH Re: 1.2.1 pre-release testing

[Leo Famulari]

On Sat, Apr 17, 2021 at 01:35:45PM +0200, François wrote:
> GIT_EXEC_PATH is very probably at fault.
> 
> It is set via profile to allow to use git subcommands installed by other
> packages but it has no sane default when we are outside a profile.
> 
> Perhaps git should have a wrapper to manage this use-case.

I think it does work properly in Guix, but requires the user to log in
again after installing Git. That's because a lot of Guix stuff is set up
in the login shell initialization scripts. It might even be enough to do
`bash --login` after installing the package.

I guess that many of us install Git right away, so we don't notice a
problem.

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

[Vincent Legoll]

Hi,

On Sat, Apr 17, 2021 at 6:04 PM 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’m torn between #2 and #3.

I don't think we have checked that ppc64 is unable to build this in a
similar way that x86_64 is able to build 32 bit x86 without virtualization.

But that may be possible, so all hope is not lost.

-- 
Vincent Legoll

Re: [INFO]: Commit Access

[Ludovic Courtès]

Hi Raghav,

Raghav Gururajan  skribis:

> I am happy to say that, I have been granted commit access. I would
> like to convey my thanks; to Tobias, Maxim, and Danny for vouching for
> me; and to guix maintainers for approving my application.

As I said on IRC: congrats, and welcome aboard!

> My long-term vision for guix is to make it an ubiquitous operating
> system. I would like to see guix deployed in public-sectors; like
> public buildings, courts, hospitals, libraries, telephony, transits,
> utilities, etc.

That’s an exciting vision, I can only hope it’ll come true!

Ludo’.

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

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> I've rediscovered the little gem that is (guix services configurations),
> and attempted to make it more generally useful by adding an option to
> opt out of serialization (which is not well adapted for producing a list
> of command line arguments from the configuration for example):

In the meantime I saw you discuss this on #guile so maybe you’ve solved
the issue now?

If not, attached is a possible solution and example.  It’s not perfect:
in the example, you’ll get a warning about ‘serialize-integer’ being
unbound, which is completely harmless but suboptimal.  Not sure how to
address that.

HTH!

Ludo’.

diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
index 90f12a8d39..20e1647335 100644
--- a/gnu/services/configuration.scm
+++ b/gnu/services/configuration.scm
@@ -109,6 +109,9 @@
  (define (serialize-maybe-stem field-name val)
(if (stem? val) (serialize-stem field-name val) ""
 
+(define-syntax-parameter configuration-field-serialization?
+  (identifier-syntax #t))
+
 (define-syntax define-configuration
   (lambda (stx)
 (syntax-case stx ()
@@ -123,7 +126,8 @@
#'(field-type ...)))
  ((field-serializer ...)
   (map (lambda (type)
- (id #'stem #'serialize- type))
+ #`(and configuration-field-serialization?
+#,(id #'stem #'serialize- type)))
#'(field-type ...
#`(begin
(define-record-type* #,(id #'stem #'< #'stem #'>)
@@ -152,6 +156,16 @@
#,(id #'stem #'stem #'-fields))
conf
 
+(define-syntax-rule (without-field-serialization definition)
+  (syntax-parameterize ((configuration-field-serialization?
+ (identifier-syntax #f)))
+definition
+#t))
+
+(without-field-serialization
+  (define-configuration foo
+(bar (integer 123) "doc")))
+
 (define (serialize-package field-name val)
   "")
 

Re: Pruning inactive committers

[Ludovic Courtès]

Hi!

Leo Famulari  skribis:

> We recently formalized our policy regarding what to do about inactive
> committers [0]. Basically, after 1 year without activity using commit
> access, one's commit access will be disabled.
>
> In coordination with the Guix maintainer collective, I put this policy
> into practice and removed such committers, yesterday and today.

Thanks for taking care of this!  It’s one of these not-so-rewarding
maintenance tasks that contribute to keeping the project in a good state
overall.

Ludo’.

Re: Feature request: hostname namespaces in guix environment

[Ludovic Courtès]

Hi Vinícius,

Vinícius dos Santos Oliveira  skribis:

> Right now my hostname is leaking to the container and that is certainly a
> hint to my main persona.

AFAICS, ‘guix environment -C’ already starts contains in a separate UTS
namespace (see ‘%namespaces’ in (gnu build linux-containers)).

However, it does not attempt to change the host name, since you get a
non-zero UID inside that environment, you cannot change it.

What we could do is add a ‘--uid’ option to ‘guix environment’ and/or a
‘--host-name’ option.

WDYT?

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-ppc
>
> The wip-ppc branch on Savannah is currently in a good state. With the
> recent rapid churn on core-updates I haven't been very quick about
> rebasing on core-updates but I can confirm that building out to mesa
> works. Building is slow, it took 6 days to build from guile-final to
> mesa without stopping.
>
> The patches start with adding the bootstrap binaries for powerpc.

Woohoo!

>  gnu/build/vm.scm  |1 +
>  gnu/local.mk  |2 +
>  gnu/packages/base.scm |   11 +-
>  gnu/packages/bootstrap.scm|   37 +-
>  gnu/packages/commencement.scm |   21 +-
>  gnu/packages/debug.scm|2 +
>  gnu/packages/disk.scm |   44 +
>  gnu/packages/gl.scm   |   18 +-
>  gnu/packages/guile.scm|   21 +-
>  gnu/packages/nss.scm  |7 +-
>  .../patches/mac-fdisk-gentoo-patchset.patch   |  866 +++
>  gnu/packages/patches/mac-fdisk-p18.patch  | 2070 +
>  gnu/packages/version-control.scm  |6 +-
>  guix/packages.scm |4 +-
>  m4/guix.m4|4 +-
>  15 files changed, 3096 insertions(+), 18 deletions(-)
>  create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
>  create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch

I haven’t looked into details so I’ll just share thoughts from a
maintenance viewpoint:

  1. Those fdisk patch file names will make ‘guix lint’ unhappy.  :-)

  2. Apart from mac-fdisk-p18.patch, which looks relatively big, the
 changes seem to be rather non-intrusive, so it’s tempting to merge
 them (on ‘core-updates’ I guess?).

  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’m torn between #2 and #3.

What do people think?

Thanks,
Ludo’.

Re: Why ban underscores?

[Ludovic Courtès]

Hi Tobias,

Tobias Geerinckx-Rice  skribis:

> I was surprised by this commit:
>
> commit 426ade6c8bdab243da719e369a887284368179bb (upstream/master)
> Author: Xinglu Chen 
>
> import: go: Replace underscores with hyphens in package names.
>
> As per section '16.4.2 Package Naming' in the manual, use 
> hypens
> [sic] instead of underscores in package names.
>
> * guix/import/go.scm (go-module->guix-package-name): Replace
> underscores with hyphens.
>
> Signed-off-by: Leo Famulari 
>
>
> Indeed, underscores were explicitly banned in 2014 (commit 
> 25083588).  Why?

It’s a convention.  As Mark wrote, it’s mostly for the sake of
consistency.

> Where's the advantage in renaming the following packages from 
> their canonical names?

These package names didn’t follow the convention, so the change would
bring them back in line.  The “advantage” is just consistent naming and
following the rule of least surprise.

Now, renames should only be performed with proper ‘deprecated-package’
definitions in place so users aren’t caught by surprise.

I hope that makes sense!

Ludo’.

Re: Speed up package installation by using images instead of archives (like distri)?

[Ludovic Courtès]

Hi!

Mekeor Melire  skribis:

> In contrast, distri downloads the package as an (squashfs)
> image. That's it. The image will then be mounted (which is not an
> expensive IO operation) as a read-only virtual-file-system. (But as
> it's not recommendable to mount as many images as there are installed
> packages, distri mounts the package-images lazily, i.e. right before
> they are being used.)
>
> (At least, the above explanation reflects my understanding.)
>
> Thus, I wonder: (0) Does it make sense to make Guix follow this idea
> as well? I.e. should we make Guix install packages by downloading
> images and mounting those instead of extracting archives? (1) Does
> this even fit into Guix technically? I.e. how hard would it be to
> implement this? (2) And would it even be worth it? I.e. how much
> faster would Guix become?

The Guix blog post mentions squashfs images, suggesting it’s not
transposable to Guix.  :-)

Specifically, there are several practical issues if you think about what
it would take to mount squashfs images instead of extracting things:
you’d have one mount point per store item? how does that interact with
GC?  what about GNU/Hurd support?  I view it as a can of worms, if it’s
workable at all.

Would it be faster?  Like other proposals in the distri talk, it’s all
about doing things lazily instead of eagerly.  In this case,
decompression happens lazily instead of eagerly.  I think that could
make application startup on a cold cache slower, precisely because that
work has to happen anyway.  More importantly, mounting all these
squashfs images at boot time could be costly.

Looking at the big picture, with zstd substitutes available, the main
speed issues in Guix are elsewhere.  What would make a big difference is
if we didn’t have to download (or build) that much so often.  This is
what the end of the blog post hints at.

HTH!

Ludo’.

Re: Security related tooling project

[Ludovic Courtès]

Hello Chris!

Christopher Baines  skribis:

> In May last year (2020), I submitted an application to NLNet. The work I
> set out wasn't something I was doing at the time, but something I hadn't
> yet found time to work on, tooling specifically around security issues.
>
> The application got a bit lost, probably somewhat down to email issues
> on my end. Anyway, things picked up again in February of this year
> (2021), and this is now something I'm looking to do roughly over the
> next 8 months.

I’m late to the party, but I think this is excellent news!  Well done!

> 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/

[...]

> In terms of looking at security from a project perspective, I'm thinking
> about these kinds of needs/questions:
>
>  - What security issues affect this revision of Guix? (latest or otherwise)
>
>  - How do Guix contributors find out about new security issues that
>affect Guix revisions they're interested in?
>
> From the user perspective, I want to look at things like:
>
>  - How do I find out what (if any) security issues affect the software
>I'm currently running (through Guix)?
>
>  - How can I get notified when a new security issue affects the software
>I'm currently running (through Guix)?

That sounds like a great plan!

I see several “intermediate” issues that would be super helpful for the
overall project, such as better CPE matching as Léo suggested and/or
providing CPE suggestions: .

I think the Data Service is in a great position to help out
wrt. monitoring.  I think it’d be nice to architect things in a way that
services enhance monitoring, but are not required for get proper
monitoring.  For instance, the proposed ‘guix health’¹ can be
implemented without relying on intermediate services at all (it still
needs to rely on the NIST server, of course, but we don’t need extra
services.)

Anyhow, it’s awesome to see you work in this area.  Like Chris Marusich
wrote, Guix is in a good position to address security issues, and you’re
obviously in a very good position to know what and how to improve the
state of things in Guix, so all hail!

Ludo’.

¹ https://issues.guix.gnu.org/31442

Re: Deep vs Shallow trace: Removing the tradeoff?

[Ludovic Courtès]

Hi,

ilmu  skribis:

> To drive the point home: If the artefact has the same hash as it did before 
> then clearly the underlying change did not affect it. Early cut-off is 
> therefore not possible in the case where the program being depended on is 
> supposed to be used at runtime.
>
> This is at least how I am thinking about it, I think this would be a good 
> incremental improvement on the state of the art but it would still have these 
> limitations.

What’s currently implemented is memoization: the hash (of the .drv and
that of the output(s)) is computed over all the inputs.

Since the output file name (the one passed to “./configure --prefix” &
co.) appears in the build result 99% of the time, the content vary at
least due to occurrences of the output file name.

Thus, content comparison are not doable as is.  What would help is
content comparison _modulo_ output file name(s).

But again, “same hash as it did before” is a framing that doesn’t hold
in a purely functional, stateless context.

Ludo’.

Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page

[Luciana Lima Brito]

On Sat, 17 Apr 2021 14:11:37 +0100
Christopher Baines  wrote:

Hi,

> I think that's better, but you're still taking the matched-outputs,
> matched-inputs and matched-sources alists, then later making the
> values vectors rather than lists. The code would be even simpler if
> you converted to a vector just after the map that produces the
> relevant lists.
> 
> I haven't looked to closely at the rest, but it looks like the
> environment-variables binding is unnecessary, given how simple the bit
> of code used is, it can just be inlined in the one place where the
> binding is used.

Done! :)
I even simplified some other stuff, based on what you said.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science
>From 701c89e8f039a6bc7d9b616acded54eac26fb0a7 Mon Sep 17 00:00:00 2001
From: Luciana Brito 
Date: Sun, 11 Apr 2021 11:06:06 -0300
Subject: [PATCH] Implement basic json output for the derivation comparison
 page

---
 guix-data-service/web/compare/controller.scm | 100 ++-
 1 file changed, 97 insertions(+), 3 deletions(-)

diff --git a/guix-data-service/web/compare/controller.scm b/guix-data-service/web/compare/controller.scm
index a6aa198..14a25ee 100644
--- a/guix-data-service/web/compare/controller.scm
+++ b/guix-data-service/web/compare/controller.scm
@@ -588,9 +588,103 @@
  '(application/json text/html)
  mime-types)
 ((application/json)
- (render-json
-  '((error . "unimplemented")) ; TODO
-  #:extra-headers http-headers-for-unchanging-content))
+ (let* ((outputs (assq-ref data 'outputs))
+(matched-outputs
+ (map
+  (lambda (label items)
+(cons label
+  (list->vector
+   (map
+(match-lambda
+  ((name path hash-alg hash recursive)
+   `(,@(if (null? name)
+   '()
+   `((name . ,name)))
+ ,@(if (null? path)
+   '()
+   `((path . ,path))
+   )
+ ,@(if (or (null? hash-alg) (not (string? hash-alg)))
+   '()
+   `((hash-algorithm . ,hash-alg))
+   )
+ ,@(if (or (null? hash) (not (string? hash)))
+   '()
+   `((hash . ,hash))
+   )
+ ,@(if (null? recursive)
+   '()
+   `((recursive . ,(string=? recursive "t")))
+(or items '())
+  '(base target common)
+  (list (assq-ref outputs 'base)
+(assq-ref outputs 'target)
+(assq-ref outputs 'common
+
+(inputs  (assq-ref data 'inputs))
+(matched-inputs
+ (map
+  (lambda (label items)
+(cons label
+  (list->vector
+   (map 
+(match-lambda
+  ((derivation output)
+   `(,@(if (null? derivation)
+   '()
+   `((derivation . ,derivation)))
+ ,@(if (null? output)
+   '()
+   `((output . ,output))
+(or items '())
+  '(base target common)
+  (list (assq-ref inputs 'base)
+(assq-ref inputs 'target
+
+(sources (assq-ref data 'sources))
+(matched-sources
+ (map
+  (lambda (label items)
+(cons label
+  (list->vector
+   (map
+(match-lambda
+  ((derivation)
+   `(,@(if (null? derivation)
+   '()
+   `((derivation . ,derivation))
+(or items '())
+  '(base target common)
+   

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

Hello Jin,

On Sat, Apr 17, 2021 at 07:58:30AM -0500, Guu, Jin-Cheng wrote:
> > Does the ethernet cable work on the installed system?  Or on other
> > free distros?
> 
> It has never failed on me before, even when I was installing arch
> linux. So I was a bit surprise yesterday.

Arch ships with non-free drivers and firmware.

> It had also worked before in
> the Guix System I got from the official - so I suppose that's a
> completely free distro.

If you had used Guix System on the same Ethernet connection on the
same machine, no nonfree channels and it worked, then the installer
image is at fault.  I will test later today if there is anything is
wrong on any of my machines.

Regards,
Florian

Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page

[Christopher Baines]

Luciana Lima Brito  writes:

> On Sat, 17 Apr 2021 09:40:22 +0100
> Christopher Baines  wrote:
>
>> I think you're getting there, but it looks like you're close to what
>> you want with matched-outputs say, and then later you pick bits out
>> of that alist, generate vectors from the lists, and then rebuild the
>> alist. I think you can remove all that complexity by just tweaking
>> what you're doing up when you generate matched-outputs. I think this
>> is true for matched-outputs, matched-inputs and matched-sources.
>
> It's beautiful!
> Now I could understand better the alist, and things make much more
> sense to me. I simplified this part of getting properly the values from
> matched-outputs, matched-inputs and matched-sources.

I think that's better, but you're still taking the matched-outputs,
matched-inputs and matched-sources alists, then later making the values
vectors rather than lists. The code would be even simpler if you
converted to a vector just after the map that produces the relevant
lists.

I haven't looked to closely at the rest, but it looks like the
environment-variables binding is unnecessary, given how simple the bit
of code used is, it can just be inlined in the one place where the
binding is used.


signature.asc
Description: PGP signature

Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page

[Luciana Lima Brito]

On Sat, 17 Apr 2021 09:40:22 +0100
Christopher Baines  wrote:

> I think you're getting there, but it looks like you're close to what
> you want with matched-outputs say, and then later you pick bits out
> of that alist, generate vectors from the lists, and then rebuild the
> alist. I think you can remove all that complexity by just tweaking
> what you're doing up when you generate matched-outputs. I think this
> is true for matched-outputs, matched-inputs and matched-sources.

It's beautiful!
Now I could understand better the alist, and things make much more
sense to me. I simplified this part of getting properly the values from
matched-outputs, matched-inputs and matched-sources.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science
>From 8d91269ead953c7d087242fbce5857af89af3025 Mon Sep 17 00:00:00 2001
From: Luciana Brito 
Date: Sun, 11 Apr 2021 11:06:06 -0300
Subject: [PATCH] Implement basic json output for the derivation comparison
 page

---
 guix-data-service/web/compare/controller.scm | 114 ++-
 1 file changed, 111 insertions(+), 3 deletions(-)

diff --git a/guix-data-service/web/compare/controller.scm b/guix-data-service/web/compare/controller.scm
index a6aa198..d05c177 100644
--- a/guix-data-service/web/compare/controller.scm
+++ b/guix-data-service/web/compare/controller.scm
@@ -588,9 +588,117 @@
  '(application/json text/html)
  mime-types)
 ((application/json)
- (render-json
-  '((error . "unimplemented")) ; TODO
-  #:extra-headers http-headers-for-unchanging-content))
+ (let* ((outputs (assq-ref data 'outputs))
+(matched-outputs
+ (map
+  (lambda (label items)
+(cons label
+  (map
+   (match-lambda
+ ((name path hash-alg hash recursive)
+  `(,@(if (null? name)
+  '()
+  `((name . ,name)))
+,@(if (null? path)
+  '()
+  `((path . ,path))
+  )
+,@(if (or (null? hash-alg) (not (string? hash-alg)))
+  '()
+  `((hash-algorithm . ,hash-alg))
+  )
+,@(if (or (null? hash) (not (string? hash)))
+  '()
+  `((hash . ,hash))
+  )
+,@(if (null? recursive)
+  '()
+  `((recursive . ,(string=? recursive "t")))
+   (or items '()
+  '(base target common)
+  (list (assq-ref outputs 'base)
+(assq-ref outputs 'target)
+(assq-ref outputs 'common
+
+(inputs  (assq-ref data 'inputs))
+(matched-inputs
+ (map
+  (lambda (label items)
+(cons label
+  (map 
+   (match-lambda
+ ((derivation output)
+  `(,@(if (null? derivation)
+  '()
+  `((derivation . ,derivation)))
+,@(if (null? output)
+  '()
+  `((output . ,output))
+   (or items '()
+  '(base target common)
+  (list (assq-ref inputs 'base)
+(assq-ref inputs 'target
+
+(sources (assq-ref data 'sources))
+(matched-sources
+ (map
+  (lambda (label items)
+(cons label
+  (map
+   (match-lambda
+ ((derivation)
+  `(,@(if (null? derivation)
+  '()
+  `((derivation . ,derivation))
+   (or items '() 
+  '(base target common)
+  (list (assq-ref sources 'base)
+(assq-ref sources 'target)
+(assq-ref sources 

Re: 1.2.1 pre-release testing

[pelzflorian (Florian Pelz)]

Hello Jin.  Thank you for testing!

On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote:
> 1. Graphical Installation
> 
>I chose the graphical method for the first installation. Everything
>went well, except my wired internet connection failed as it
>indicated. Weirdly enough, my ethernet cable has been always on my
>machine for a while, and never failed. […]

Does the ethernet cable work on the installed system?  Or on other
free distros?

In the distant past, I had trouble using the built-in Ethernet on my
11-year old Macbook until (I think) a newer Linux-libre kernel release
added support.  Maybe this is similar.

If Ethernet is only broken in the installer though, then the installer
is at fault.

Regards,
Florian

Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page

[Christopher Baines]

Luciana Lima Brito  writes:

> On Fri, 16 Apr 2021 20:17:45 +0100
> Christopher Baines  wrote:
>
> Hi,
>
> I hope the patch is correct this time.
> I considered all you said, so I separated the
> functions to get outputs, inputs and sources. I also implemented
> everything inside the case of the json/application.

Yep, that's looking good, much neater.

>> While a flatter list is what you want when building an HTML table, I
>> think you were looking to get a JSON object separating the common,
>> base and target elements, right? If so, then map, rather than
>> append-map should be more useful to you here. Since above you're
>> passing in two lists of three things, if the procedure passed to map
>> returns a pair with a string in the first position, you'll end up
>> producing the scheme version of a JSON object (an alist).
>
> You were right about that, I'm using map now.
>
> Please, let me know if I missed something.
> Thanks in advance, I'm learning a great deal! :)

I think you're getting there, but it looks like you're close to what you
want with matched-outputs say, and then later you pick bits out of that
alist, generate vectors from the lists, and then rebuild the alist. I
think you can remove all that complexity by just tweaking what you're
doing up when you generate matched-outputs. I think this is true for
matched-outputs, matched-inputs and matched-sources.


signature.asc
Description: PGP signature