Re: I've rebased wip-ppc64le onto core-updates, Re: Release on April 18th?

[Chris Marusich]

Hi Ludo,

Ludovic Courtès  writes:

> Maybe you could “formally” ask for a review of the branch when you think
> it’s ready (perhaps even git-send-emailing the patches to guix-patches,
> for convenience), and then we can merge in ‘core-updates’ (if/when that
> matches other branch scheduling choices).

That's a good idea.  I'll do that for wip-ppc64le-for-master shortly.

I'll do it for wip-ppc64le later, after incorporating the changes from
wip-ppc64le-for-master, and after resolving the issues with the GCC 8
upgrade.

Ludovic Courtès  writes:

> It works on my laptop.  :-) If you’re confident, please push—thanks for
> the fix!

Done in commit 341dfe7eda4972af0a027357015ea595314438b0!

> (Next time please report the issue to bug-guix where it’s more likely to
> be seen and dealt with.  :-))

Good call.  It's easy to miss an email in a big thread like this.  Thank
you for noticing it and replying.  In the future, I'll send bugs/patches
to bug-guix/guix-patches to increase their visibility.

-- 
Chris


signature.asc
Description: PGP signature

Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Chris Marusich]

Hi,

I have good news!

Chris Marusich  writes:

> Subject: [PATCH] syscalls: mount: Fix a matching bug.

If there are no concerns about this patch, I will commit it to master
(with the "mount" typo fixed so it reads "mounts") in the next few days.

> Efraim Flashner  writes:
>
>> I'm now running make guix-binary.powerpc64le-linux.tar.xz and so far
>> it's made it past the initial building stages, we're on to building the
>> grafts now.
>
> Thank you.  This fixed the patch-related problem for me, too.  I'm
> currently running "make guix-binary.powerpc64le-linux.tar.xz", also, on
> my Debian ppc64le machine.  We'll see how far it gets - fingers crossed!

I'm happy to report that I was able to do all of the following things
successfully on the wip-ppc64le-for-master branch after (1) applying the
syscalls patch mentioned above, (2) running "make update-guix-package",
and (3) locally committing the updated guix package:

- On a bare metal Debian ppc64le machine, I ran "make
  guix-binary.powerpc64le-linux.tar.xz" successfully.

- I installed the resulting guix binary in a fresh Debian ppc64le VM
  successfully.

- In the VM, using the newly installed guix binary, I successfully ran
  "guix pull" to update Guix to the commit I made in (3) above.

- In the VM, using the newly pulled guix, I built GNU Hello and verified
  that it ran successfully.

This demonstrates that wip-ppc64le-for-master is working.  Therefore, we
should merge it to master and officially include powerpc64le-linux
support in the next Guix release!  Thank you, Efraim, for taking the
initiative to adapt some of the commits from wip-ppc64le so they could
be applied to master without rebuilding the world on other systems.

I've verified that the wip-ppc64le-for-master branch does not rebuild
the world.  I did this by verifying that the derivations for the "hello"
and "gcc-toolchain" packages were the same at the branch point as they
are at the tip of the branch (e.g.: ./pre-inst-env guix build -d hello).

As I see it, the next tasks for powerpc64le-linux in this release are:

- Do a final rebase of wip-ppc64le-for-master, then merge it to master.

- When the release happens, make a guix-binary.powerpc64le-linux.tar.xz
  available wherever binary releases are normally published.

- Start building powerpc64le-linux substitutes in the build farm,
  ideally on POWER9 hardware.

How shall we build the binary tarball for the release?  Of course,
anybody with a copy of the (source) release tarball can build their own
guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
themselves.  However, for convenience, it would be nice to provide a
pre-built binary if possible.  Shall I build this myself when the time
comes, or would people prefer to do it a different way?

-- 
Chris


signature.asc
Description: PGP signature

Re: Adding Substitute Mirrors page to installer

[raid5atemyhomework]

> The ability to also use the same mirror during install rather than after 
> it would be very nice. After all, the guix daemon has to be restarted during 
> installation in the meantime anyway, so on restart it should be possible to 
> switch the `substitute-urls`. However the complications are:
>
> -   The `(gnu installer service)` module inherently assumes that services are 
> completely orthogonal to everything else being configured in the 
> installation. I'm not sure what the best way to extract the substitute mirror 
> selection would be.
> -   The installation image has to do a local `guix system reconfigure` of 
> itself so that its shepherd points the guix daemon to a new mirror, so that 
> the guix daemon restart in `install-system` of `(gnu installer final)` will 
> refer to a new mirror.

Another way to do this would be to add another argument to the `start` action 
of `guix-daemon`, in much the same way the installer passes in its pid so that 
the guix daemon can access the copy-on-write store on the destination.  This 
argument would override the `--substitute-urls`.

So in `(gnu services base)` the `guix-shepherd-service` procedure would have 
something like:

(define substitute-urls
(match args
  ((_ substitute-urls . __) substitute-urls)
  (else #$(string-join substitute-urls

#; 

(fork-exec-command/container
  #; ...
  #:pid
  (match args
((pid . _) pid)
(else  (getpid)))
  #; ...)


The question now is how does the `install-system` procedure in `(gnu installer 
final)` determine what substitute URL to pass into `(start-service 'guix-daemon 
(list (number->string (getpid)) <>))`?

* Change the architecture of the installer somehow so that a single page can 
both manipulate the `services` field and also manipulate how `install-system` 
is invoked, and add a new argument to `install-system`.
* Or have `install-system` `read` in the `(%installer-configuration-file)`, 
look for the `operating-system` form, then delve in its `services` field for a 
`substitute-urls` field.  This feels fairly brittle but does take advantage of 
the homoiconicity of Scheme.

Thanks
raid5atemyhomework

Re: Adding Substitute Mirrors page to installer

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 09:49, raid5atemyhomework 
 wrote:

> If you mean other non-Guix channels, the only channels I know of that
> are not Guix cannot be named here, so --- are there any channels that
> *can* be named in official documentation about Guix? 

You can find a list of scientific related channels here: (Section Code)

  


All the best,
simon

Re: gpg key expiration time

[Paul Garlick]

Hi Tobias,

On Mon, 2021-03-15 at 18:24 +0100, Tobias Geerinckx-Rice wrote:

> The expiry date is not embedded in your cryptographic key, merely 
> attached to it as a signed ‘packet’.

Thanks. Got it!

Best regards,

Paul.

Re: [bootstrappable] GNU Mes 0.23 released

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!
> Jan Nieuwenhuizen  skribis:
>
>> and now also for armhf-linux and aarch-linux.  Work to integrate this
>> into Guix is ongoing: tinycc and gcc-core-2.95.3 have been built.
>
> Woohoo, impressive work!

Thanks!

> I suppose that will unlock the full-source bootstrap branch, right?

Yes!  For Guix we'll probably want to finish the ARM bootstrap first,
but for mes the coming release is to support the full-source bootstrap.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Release 1.2.1: timeline

[Leo Famulari]

On Mon, Mar 15, 2021 at 02:14:52PM -0400, Leo Famulari wrote:
> On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote:
> > > The architecture armf will not be included.
> > 
> > Wait wait, I missed that.  What happened?  I think we should include it,
> > even if substitute availability remains low.
> 
> I had asked about the status of the armhf branch on #guix when a few of
> us were trying to "tie up loose ends" for this release.

I'm not sure why I wrote "armhf branch". I meant to refer to the armhf
port of Guix.

Re: Release 1.2.1: timeline

[Vincent Legoll]

Hello,

On Mon, Mar 15, 2021 at 7:50 PM Leo Famulari  wrote:
> we should include in the release announcement a clear description of
> the level of support that users can expect.

Yes, that would be useful too, I'm all for giving people the information that
it may not be easily usable, but still providing what we have now so that
any one can try to push it a bit further.

-- 
Vincent Legoll

Re: [bootstrappable] Re: Can Guile be bootstrapped from source without psyntax-pp.scm?

[Michael Schierl]

Hello Ludo’,


Am 15.03.2021 um 18:09 schrieb Ludovic Courtès:

Woow, this is great news!  I think it would be great towards importing
it in Guile proper.

To do that, I think we should first get Andy’s opinion on the approach.


I don't think upstream is very interested in having psyntax-pp.scm
bootstrappable. In Guile 3.0.3 they broke even the `make
ice-9/psyntax-pp.scm.gen` target, and did not repair it even in Guile
3.0.5, that's why I used 3.0.2 for the bootstrap. But I included a patch
to repair it in 3.0.5 in case you really want to bootstrap that version
(psyntax-pp.scm has not changed there). OTOH, from the git log it seems
like psyntax is currently being overhauled for the next release, so
probably my code would need some updates for the next version.

Also, in the last 15 years I avoided directly contributing to "GNU
projects" (with FSF as copyright holder in the license headers), reasons
below. But if anyone else takes my code and upstreams it, I won't object.

Regardless, even when not part of Guile, I believe this code is very
useful for both the live-bootstrap project and Guix to get their Guile
bootstrapped. And even if nobody ever updates it for 3.0.6+, you can
always bootstrap the later versions from an earlier Guile. And maybe a
variation of it lands in GNU Mes, too.




And now for the reasons. It happened first to me 17 years ago, what
others would have called an honor, a private email from RMS himself if I
would consider upstreaming some of my code into GNU Emacs. I answered to
feel free to take it, since it is GPLv3+ (or was it GPLv2+ at that
point? not sure) anyway, and he replied that it is not that easy since
first they need a to have me sign "copyright assignment papers" and
asked for a postal address to send them. I was able to find an old
version of that assignment online and it included some clauses I was
unwilling to sign, so I asked if FSF could send me an electronic version
first before I give them my postal address so they can snail mail me the
dead-tree version, just to avoid work on their side assuming that I may
not be willing to sign that anyway. As FSF was unable/unwilling to do
so, it all stopped, until, years later somebody asked me to contribute
some of my code to ELPA. I guess I can spare you the details, they would
bore you.

I'm not at all against contracts, the http://developercertificate.org/
(which I agreed to before contributing a 2-line bugfix to the Linux
kernel) has recently got some traction, and also I've signed Google's
Contributor License Agreement. However, I would not sign Oracle's
Contributor License Agremment (the last version of it that I checked),
not because of the company but because of its contents.




Regards,


Michael

Re: Release 1.2.1: remove clang@3.6?

[zimoun]

Hi Ludo,

On Mon, 15 Mar 2021 at 17:38, Ludovic Courtès  wrote:

> > it seems broken since long time.  I propose to remove:
> >
> >  clang
> >  clang-runtime

> > @3.6.2.  Any objection?

> Sounds reasonable to me.

Done in .

Cheers,
simon

Re: Release 1.2.1: timeline

[Leo Famulari]

On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote:
> > The architecture armf will not be included.
> 
> Wait wait, I missed that.  What happened?  I think we should include it,
> even if substitute availability remains low.

I had asked about the status of the armhf branch on #guix when a few of
us were trying to "tie up loose ends" for this release.

I don't have an opinion one way or the other, but since we are not
building substitutes for it at all, we should include in the release
announcement a clear description of the level of support that users can
expect.

Re: gpg key expiration time

[Tobias Geerinckx-Rice]

Hi Paul!

Paul Garlick 写道：
After renewing the expiration time of one's gpg key, and 
uploading the

updated key to Savannah, is it also necessary to update the
corresponding file in the keyring branch?


No.

I notice from the log that, so far, none of the original files 
have
been updated.  Does this mean that the original validation is 
accepted

for new commits signed with an updated key?


Yes.

The expiry date is not embedded in your cryptographic key, merely 
attached to it as a signed ‘packet’.


Of course, OpenPGP has a reputation to maintain as the most 
confusing software on earth, so all these packets are stored 
together with your cryptographic key(s) in a single file that 
everyone calls your... ‘key’.


Anyway: Guix ignores expiry dates by design.  It merely verifies 
that each commit was signed with an authorised key.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Release 1.2.1: timeline

[Vincent Legoll]

Hello,

On Mon, Mar 15, 2021 at 5:55 PM Ludovic Courtès  wrote:
> > The architecture armf will not be included.
>
> Wait wait, I missed that.  What happened?  I think we should include it,
> even if substitute availability remains low.

IMHO, substitute availability should not be an inclusion criteria

-- 
Vincent Legoll

Re: Guile Netlink 1.0 released

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> I'm proud to announce the first release of Guile Netlink!
>
>   git clone https://git.lepiller.eu/git/guile-netlink
>   cd guile-netlink
>   git checkout 1.0 # or 29ff43368f1cc2d10a7e5f09dc9f80f85582d6ee
>   git tag -v 1.0

Yay, awesome!

Sounds like Guix will soon have a much nicer ‘static-networking’
service.  :-)

Ludo’.

Re: [bootstrappable] Re: Can Guile be bootstrapped from source without psyntax-pp.scm?

[Ludovic Courtès]

Hi Michael,

Michael Schierl  skribis:

> For the record, I have written a psyntax implementation that can be used
> by Guile (3.0.2) and does not require an expanded version of itself. It
> is not ideal (not fully hygienic and does not support with-ellipsis),
> but it works well enough to bootstrap a slightly patched version of
> psyntax.scm, which then can be used to bootstrap "the real thing" and
> then regenerate psyntax-pp.scm (resulting in a bit-for-bit identical
> version if you run the bootstrap on 64-bit Linux).
>
> The project is at
> .
>
> It may still contain some unnecessary code, and the patch for the
> patched vesion is definitely not minimal, but for now I'm glad that it
> works.

Woow, this is great news!  I think it would be great towards importing
it in Guile proper.

To do that, I think we should first get Andy’s opinion on the approach.
Then you could try to integrate the files into the Guile repo and adjust
the makefile machinery so that it uses this code to generate the initial
psyntax-pp.scm.

There may be additional things to look at, such as performance when
building from scratch.  We could still include the generated
psyntax-pp.scm in the tarball, like we do for some .go files, for those
who want a faster Guile build and are willing to make this tradeoff.

Thanks!

Ludo’.

Re: regression: “guix pack” Docker images no longer work on AWS

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Today I generated a new image that does not work.  It cannot be opened
> by ECS; it cannot find /bin/sh, which exists.  The manifest type is now
> recognized as

Could it be that /bin/sh is a symlink to /gnu/store/… and
Docker/whatever attempts to resolve that symlink in a context where
/gnu/store is missing?

Singularity had this bug, which led us to create symlinks to relative
file names:

  https://issues.guix.gnu.org/34913

HTH,
Ludo’.

Re: [bootstrappable] GNU Mes 0.23 released

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> We are happy to announce the release of GNU Mes 0.23, representing 125
> commits over one year by four people.
>
> Mes was ported to ARM and can now be used in the GNU Guix Reduced Binary
> Seed bootstrap as described here
>
> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
>
> and now also for armhf-linux and aarch-linux.  Work to integrate this
> into Guix is ongoing: tinycc and gcc-core-2.95.3 have been built.

Woohoo, impressive work!

I suppose that will unlock the full-source bootstrap branch, right?

Cheers,
Ludo’.

Re: CVEs missing from the NIST database

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> Ludovic Courtès  writes:
>
>> In this case, I noticed that ‘guix lint -c cve cairo’ wouldn’t report
>> CVE-2020-35492 and found that
>>  is 404.
>>
>> Likewise, this command:
>>
>>wget -qO - 
>> "https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2020.json.gz; | \
>>  gunzip | grep CVE-202-35492
>>
>> turns up nothing.
>>
>> It could be that this CVE is still “pending” (I think that happens
>> sometimes).  Do you know more about this one?
>
> I was looking in Debian's cairo package for fixes for other CVEs (namely
> the ones that "guix lint -c cve cairo" *did* report), and noticed that
> they included a fix for CVE-2020-35492.  I didn't investigate further.

OK.  It could be that it hasn’t reached the NIST database yet, as Leo
wrote.

> While we're on the subject on issues with the CVE database, or possibly
> with our linter, "guix lint -c cve" now erroneously reports:
>
> gnu/packages/gnome.scm:8434:2: gnome-shell@3.34.5: probably vulnerable to 
> CVE-2019-3820
> gnu/packages/gnome.scm:6452:2: gvfs@1.40.2: probably vulnerable to 
> CVE-2019-12447, CVE-2019-12448, CVE-2019-12449
>
>
> All of these are incorrect.
>
> * CVE-2019-3820 was fixed long before GNOME 3.34 came out, and I've
>   verified that the commit that fixes it is included in
>   gnome-shell-3.34.5:
>
> commit f0a7395b3006360905ccdc642982f9fc67378927
> Author: Ray Strode 
> Date:   Wed Jan 23 15:59:15 2019 -0500
>
> shellActionModes: disable POPUP keybindings in unlock screen
>
> * CVE-2019-12447, CVE-2019-12448, and CVE-2019-12449 are fixed in
>   gvfs-1.40.2, according to its NEWS file:

Yes, that can happen when the CVE doesn’t list affected versions:

  https://www.openwall.com/lists/oss-security/2017/03/15/3

The solution here is to add a ‘lint-hidden-cve’ property to the package
with a comment explaining why we think these CVEs can be ignored (info
"(guix) Invoking guix lint").

Thanks,
Ludo’.

Re: Release 1.2.1: timeline

[Ludovic Courtès]

Hello!

zimoun  skribis:

> The plan is to release on the April, 18th.  It is a target date.

I want to believe!  :-)

> We are planning an «ungraftathon» the last week-end of March (27-28).
> Please roam on #guix if you want to help.

+1

> A draft of the timeline is:
>
>  - until April 1rst: fixes, check substitute availability, etc.
>  - as soon as possible: start to build wip-next-release
>  - merge branch wip-next-release when ready
>  - on Monday 12th April, string freeze
>  - couple of days after, branch the release and write the materials
>(ChangeLog and posts)
>  - release

Sounds reasonable to me.

> The architecture armf will not be included.

Wait wait, I missed that.  What happened?  I think we should include it,
even if substitute availability remains low.

> The branch core-updates will not be merged.

Yeah, that sounds like the most reasonable approach.

> Once this release is done, we could write a timeline for the next
> core-updates merge and list what should be included in the next
> release (1.2.2 or 1.3).  Somehow, all this is an “experiment” for a
> webpage detailing the different timelines.
>
> Does it make sense?

It does.  Thanks for helping us stay on track!

Ludo’.

Re: guix home

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin  skribis:

> There is an implementation of `guix home` subcommand, which behaves
> similar to `guix system`, allowing declaratively manage applications and
> their configurations, but for a particular user, not the whole OS:
> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu
>
> * Overview
> It possible to define the desired environment with home-environment
> record, which contains a list of home-services and few other
> configuration options and build and install it with `guix home
> reconfigure`. The service extension mechanism works the same way as in
> operating-system and utilize fold-services from (gnu services).
>
> Current set of implemented essential services:
> - home-service :: return the derivation
> - home-profile :: manages a separate profile with packages provided by
> user or other services
> - home-environment-vars :: allows to set env vars for user's shell
> - home-shepherd :: manages user's shepherd, can be extended by other services
> - home-run-on-first-login :: launches shepherd and some other one-time actions
> - home-run-on-reconfigure :: update shepherd configuration and update
> symlinks from ~/ and ~/.config to guix-home-environment/files
> - home-symlink-manager :: extends on-reconfigure with a update-symlinks script

Nice!

When I stumbled upon your message, I thought it was about Julien’s
guix-home-manager, but now I gather you’re actually announcing another
project.  There’s no name like “home”.  :-)

> * Alternative solutions
> In contrast to guix-home-manager, `guix home` doesn't introduce any too
> innovative approaches (those ideas are cool, but in some use cases are
> too radical), `guix home` uses the same extension mechanism [fn:1] as
> guix system services and doesn't require to make HOME read-only. Thus,
> it's possible to start using `guix home` gradually, along with other
> tools and workflows (stow, guix package, chezmoi, yadm, etc).

I see.  So do I get it right that ‘guix home’ focuses primarily on
profile and user service management?  Could you give examples of a
minimal config and command invocations?

> Talking about Nix's home-manager: it's a nice software, but maintained
> separately from nix package manager and kinda disconnected from Nix
> itself, which introduce a lot of duplications between NixOS modules and
> home-manager modules, requires additional installation steps and overall
> makes it harder to use for not very experienced nix users. Probably, we
> can learn from it and do better here.

Agreed.

> * Future steps
> `guix home` still under active development, but already complete enough
> for exloration and early adoption. There is no any documentation yet,
> because things were changing often and probably will change one more
> time during comming cleanup, however there were few video streams,
> explaining internals of `guix home`:
> mpv https://youtu.be/t3zRzQnarUI
> mpv https://youtu.be/4lJaVzxO_Bs
> mpv https://youtu.be/ZRQtCvo8MoM

Oh nice, now I have to watch those!

> In addition to documentation it will be necessary to implement a lot of
> home-services for different tools, add rollback, shepherd-graph,
> extension-graph and other actions, but before doing it I would like to
> spend some time polishing essential services and decide on upstreaming
> the tool to guix itself.
>
> The question is: do we want and need at all `guix home` to be a part of
> the guix? As for me, the tool seems like a natural addition to guix's
> declarative configuration management approach and covers the missing
> piece of user space software management and as I mentioned early
> upstreaming will allow to make it better integrated with the rest of the
> guix and easier to use for newcommers and casual users, but my
> perception is obviously biased.
>
> Dear maintainers and users, what do you think about making `guix home` a
> part of guix?

I have yet to familiarize myself with ‘guix home’, but overall, I think
a solution à la ‘guix home’ or guix-home-manager would be a welcome
addition to Guix.

I agree that these tools are a natural extension of Guix and that it
makes sense to settle on one approach and make it part of Guix proper.

Thanks!

Ludo’.

Re: Release on April 18th?

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> From 5417f68ee5892f6a587895105854cadf29eb7297 Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Thu, 11 Mar 2021 23:19:30 -0800
> Subject: [PATCH] syscalls: mount: Fix a matching bug.
>
> On some systems, the columns in /proc/self/mountinfo look like this:
>
> 23 28 0:21 / /proc rw,nosuid,nodev,noexec,relatime shared:11 - proc proc rw
>
> Before this change, the mount procedure was written with the assumption that
> the type and source could always be found in columns 8 and 9, respectively.
> However, the proc(5) man page explains that there can be zero or more optional
> fields starting at column 7 (e.g., "shared:11" above), so this assumption is
> false in some situations.
>
> * guix/build/syscalls.scm (mount): Update the match pattern to use ellipsis to
> match zero or more optional fields followed by a single hyphen.  Remove the
> trailing ellipsis, since multiple ellipses are not allowed in the same level.
> The proc(5) man page indicates that there are no additional columns, so it is
> probably OK to match an exact number of columns at the end like this.
> ---
>  guix/build/syscalls.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm
> index 552343a481d..726c8e86d06 100644
> --- a/guix/build/syscalls.scm
> +++ b/guix/build/syscalls.scm
> @@ -621,8 +621,9 @@ current process."
>(if (eof-object? line)
>(reverse result)
>(match (string-tokenize line)
> +;; See the proc(5) man page for a description of the columns.
>  ((id parent-id major:minor root mount-point
> - options _ type source _ ...)
> + options _ ... "-" type source _)
>   (let ((devno (string->device-number major:minor)))
> (loop (cons (%mount (octal-decode source)
> (octal-decode mount-point)

It works on my laptop.  :-) If you’re confident, please push—thanks for
the fix!

(Next time please report the issue to bug-guix where it’s more likely to
be seen and dealt with.  :-))

Ludo’.

Re: Release 1.2.1: remove clang@3.6?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> The package clang-runtime@3.6.2 is broken (commit 6bed29b) and giving a
> look to:
>
> 
>
> it seems broken since long time.  I propose to remove:
>
>  clang
>  clang-runtime
>  clang-toolchain
>
> @3.6.2.  Any objection?
>
>
> Note that llvm@3.6.2 cannot be removed because of the package clamav.

Sounds reasonable to me.

Thanks,
Ludo’.

Re: GNOME Orca 'orca' package mislabeled by 'guix lint -c cve'

[Ludovic Courtès]

Hi Léo,

Léo Le Bouter  skribis:

> Currently CVE-2020-9298 is being wrongly reported by 'guix lint -c cve'
> because vendor is not taken into account, therefore:
> "cpe:2.3:a:spinnaker:orca" also matches.
>
> Reminder that we need cpe-vendor property as told in <
> https://issues.guix.gnu.org/40142>.
>
> I would like to tag the package but currently cannot because cpe-vendor 
> does not exist yet.

As a workaround, you could tag it with ‘lint-hidden-cve’ with an “XXX”
comment explaining the situation.

Thanks for looking into all this!

Ludo’.

Re: I've rebased wip-ppc64le onto core-updates

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> In short, I think it will be simplest to just merge wip-ppc64le into
> core-updates and then merge core-updates into master.

Maybe you could “formally” ask for a review of the branch when you think
it’s ready (perhaps even git-send-emailing the patches to guix-patches,
for convenience), and then we can merge in ‘core-updates’ (if/when that
matches other branch scheduling choices).

Thanks!

Ludo’.

Re: guix environment --profile with --ad-hoc

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> strace reveals more.  For example, some time is lost searching libraries
> and other files.  (At least the excessive library searches should
> already have been mitigated by changes on the core-updates branch.)
> This includes reading .go files, .scm files, reading TLS certs for
> guile-gnutls, etc.

I think you’re stracing via ./pre-inst-env.  ‘guix’ from ‘guix pull’
stats less thanks to the optimizations in (@@ (guix self)
guix-command):

--8<---cut here---start->8---
$ ./pre-inst-env strace -c guix build hello -d
/gnu/store/cl250cyzml3sk521y0n6940cr60r481x-hello-2.10.drv
% time seconds  usecs/call callserrors syscall
-- --- --- - - --
 54.030.009214   1  6542  4863 stat
 12.460.002124   2  1023   mmap
  9.300.001585   1  1535   626 openat

[...]

-- --- --- - - --
100.000.017052   1 14180  5528 total
$ strace -c guix build hello -d
/gnu/store/cl250cyzml3sk521y0n6940cr60r481x-hello-2.10.drv
% time seconds  usecs/call callserrors syscall
-- --- --- - - --
 28.770.002299   1  1282   625 openat
 20.770.001660   1  1519   325 stat

[...]

-- --- --- - - --
100.000.007991   0  8143   983 total
--8<---cut here---end--->8---

(The former is sensitive to the length of GUILE_LOAD_PATH, the latter
isn’t.)

> I’m guessing that we could avoid some of that searching (and thus
> condense a whole lot of stat calls) by constraining things a little
> ahead of time.  We know the location of Guile modules in advance, so
> perhaps we can come up with a way to avoid having to go on
> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH for everything, e.g. by
> recording GUIX_ROOT and using that.

Yes, that’s what the “package cache” built by ‘guix pull’ does.
Essentially, it makes it so that:

  guix build hello

is equivalent to:

  guix build -e '(@ (gnu packages base) hello)'

> But this is still all rather benign.  The real slow-down is due to
> talking to the daemon.  I’m not sure I understand all the strace output,
> but it looks like we read file names from the daemon socket and then
> write the contents of the builders and derivations for these files back
> to the daemon socket.
>
> It’s not clear to me if Guix computes these builders and derivations
> from scratch and then sends them over the socket, or if it reads them
> from files and sends them over.  But it does seem like perhaps we could
> avoid some of the work, or at least some of the socket communication
> when the daemon could read existing files directly.

All the derivations and builders are computed from scratch, so caches
(notably the cache that maps packages to derivations) have a huge
impact.

Ludo’.

gpg key expiration time

[Paul Garlick]

Hi Guix,

After renewing the expiration time of one's gpg key, and uploading the
updated key to Savannah, is it also necessary to update the
corresponding file in the keyring branch?

I notice from the log that, so far, none of the original files have
been updated.  Does this mean that the original validation is accepted
for new commits signed with an updated key?

Best regards,

Paul.

Re: Adding Substitute Mirrors page to installer

[Ludovic Courtès]

Hi,

raid5atemyhomework  skribis:

> From af7e4d1336ed9010a31011d2fbae2a27fdaca237 Mon Sep 17 00:00:00 2001
> From: raid5atemyhomework 
> Date: Wed, 10 Mar 2021 09:21:42 +
> Subject: [PATCH] gnu: Add substitute mirrors page to installer.
>
> * gnu/installer/services.scm (system-service) [snippet-type]: New field.
> (%system-services): Add substitute mirrors.
> (service-list-service?): New procedure.
> (modify-services-service?): New procedure.
> (system-services->configuration): Add support for services with
> `'modify-services` snippets.
> * gnu/installer/newt/services.scm (run-substitute-mirror-page): New
> procedure.
> (run-services-page): Call `run-substitute-mirror-page`.

Looks nice!  Mathieu, could you take a look as time permits?

I wonder if the “conversations” in (gnu installer tests) need to be
adjusted.

Thanks,
Ludo’.

Re: Release 1.2.1: Remove 31 Python 2 packages

[zimoun]

Hi Maxim,

On Sun, 14 Mar 2021 at 02:03, Maxim Cournoyer  wrote:
> zimoun  writes:

> In the end though, the Python 2 packages must go, so I think it's not
> unreasonable to remove the broken ones to start.  Someone finding the
> packages important enough could fix them and publish them in a separate
> Python 2 channel.

I removed 25 packages from the list.   See:
.  Feel free to push if everything
is fine. :-)

The remaining ones are:

> > python2-ipykernel
> > python2-ipyparallel
> > python2-ipython
> > python2-ipython-cluster-helper
> > python2-jupyter-console
> > python2-pyfakefs

because "guix weather" reported them as substituable with recent commit.

All the best,
simon

Re: regression: “guix pack” Docker images no longer work on AWS

[zimoun]

Hi Ricardo,

On Sat, 13 Mar 2021 at 00:39, Ricardo Wurmus  wrote:

> I’d very much like to push a newly generated image.  Is there a way to
> generate the image as it was done in the summer of 2020?

Is it possible to download these 2 Docker images?  In order to compare
then locally.
And do you have the commit that you used back on 2020?  Maybe the
manifest.scm file?


> Note that both these images appear to work “fine” with a local Docker
> installation (i.e. when run with “docker run”).  (When running /bin/sh
> in the container interactively it appears to freeze whenever I try to
> actually run a command, but perhaps I’m just holding it wrong…)

I do not know if it is related, there is this recent change:
18a4882e3029a084d2f0c63d9d0148682a854546.

Cheers,
simon

Re: GNU Mes 0.23 released

[Léo Le Bouter]

Thanks a lot! Keep it up! :-D


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

Re: Guile Netlink 1.0 released

[Léo Le Bouter]

Exciting new possibilities! Great work!


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

Re: guix environment --profile with --ad-hoc

[zimoun]

Hi Lars.

On Sat, 13 Mar 2021 at 08:59, Lars-Dominik Braun  wrote:

>> Instead, I'd like the following behaviour:
>> […]
> hm, I feel that’s unnecessarly complex with lots of if’s and else’s. If
> I could design the frontend from scratch, I’d have one command that does
> profile/environment manipulation (because they’re essentially the same)
> and one that can set them up for use. In that world you’d do
>
> $ guix environment $(guix profile -m manifest.scm -i additional-package)

For the record, such command (as “profile manager”) had been discussed,
for example:






Note that the (still experimental and) undocumented GUIX_EXTENSIONS_PATH
allows to test new commands design without writing them in stone.
Basically, set the variable GUIX_EXTENSIONS_PATH to the path containing
the Guix module ’(guix extensions profile)’ then “guix help” should list
the extension and “guix profile” should work.


Cheers,
simon

Re: Release 1.2.1: python2-pylibmc and libmemcached

[zimoun]

Hi,

On Sat, 13 Mar 2021 at 20:58, Maxim Cournoyer  wrote:
> zimoun  writes:

>> takes ages.  Does it make sense to add something like:
>>
>>   (properties
>>`((max-silent-time . 14400))) ; 4 hours, expected even on x86_64

> libmemcached still seems like a fine package to have in Guix.  I say, if
> the above change is enough to have it built by the CI, I think it's what
> we should do :-).

On my machine, the build of libmemcached takes ~5min without the tests.
And with the test suite, it takes ~570min.  Well, I have been too lazy
to remove the offending test which takes ages, and compare.  I do not
know if Cuirass fails to build (time-out?) because an incorrect
’max-silent-time’ by default or because another parameter specific to
Cuirass.


Cheers,
simon