repl macro (metacommand?) for guix CLI (sub)commands

[jgart]

What do guixers think of having a repl macro that allows
you to run commands like if you were using the CLI?

Inspiration:

https://github.com/janet-lang/jpm/commit/6d494db43605b9fc7411875f25ae110cb8f77e0b

all best,

jgart

Re: Shall updaters fall back to other updaters?

[Kaelyn]

--- Original Message ---
On Sunday, July 3rd, 2022 at 1:12 AM, Hartmut Goebel 
 wrote:


> Am 01.07.22 um 15:15 schrieb Ludovic Courtès:
>
> > > BTW 2: Which updater is used for each package is non-deterministic.
> > > Do you have an example? I’d think they’re always tried in the same
> > > order, no?
>
>
> When looking at the code, I don't see any means of sorting:
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/upstream.scm#n245
>
> and below. (Maybe sorting is hidden in one of the function
> guile-internal used there there.)

I just looked at 'importer-modules and did some tracing of where the list of 
modules come from (back through 'all-modules, etc). It appears that by default 
the list of importer modules comes from 'scheme-file, which is defined at:

https://git.savannah.gnu.org/cgit/guix.git/tree/guix/discovery.scm#n43

That function builds a list of scheme files found recursively under a given 
directory with the help of 'scandir*. There is no sorting there or along the 
call chain back to 'importer-modules, so I'm fairly sure the directory entries 
are returned in a filesystem-dependent order. If the filesystem returns entries 
in sorted order or if the contents of that directory tree are relatively static 
(in that the order of directory entries hasn't changed), then the results will 
appear to be in a consistent/deterministic order. To me, this feels like the 
importers will need a more deterministic order imposed on them to get import 
results that are consistent across systems. HTH!

Cheers,
Kaelyn

Re: Teams: please add yourself to etc/teams.scm.in

[Andreas Enge]

Hello,

Am Sun, Jul 03, 2022 at 03:04:36PM +0200 schrieb Ricardo Wurmus:
> etc/teams.scm.in is now part of the repository.  The configure script
> generates the executable etc/teams.scm.
> Please feel free to add yourself to teams in that file by adding a
> definition like this:

thanks for pushing the teams idea forward!

I took the liberty to rename "maths and algebra" to "science", which is a
bit less narrow. Then it probably contains all of R and bio*, so maybe
this is too large? I am more thinking of "classical" science packages
written in C... So please feel free to rename back or to something else
if you think I have broadened the scope too much.

Andreas

Re: glibc-locales

[Tobias Geerinckx-Rice]

The intended use is NOT to use a package at all, see 
https://guix.gnu.org/en/manual/devel/en/html_node/Application-Setup.html#Locales-1

Strongly put (and very possibly missing something :-), this sounds like 
maintenance effort to support an antipattern.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: glibc-locales

[Vagrant Cascadian]

On 2022-07-03, Andreas Enge wrote:
> Am Sun, Jul 03, 2022 at 12:53:09PM +0300 schrieb Efraim Flashner:
>> I misread the source. I'd like glibc-utf8-locales built with glibc-final.
>
> Has glibc-utf8-locales not been removed some time ago? I always had it in
> my profile, then saw a message during upgrade that it had been removed,
> and dropped it from my profile (without any apparent harm to my GNU system).

Still is there as a hidden package and used as an input for some
packages, though this brings up another locales-related question...

Before glibc-utf8-locales was a hidden package, I preferred using that
because it only included a small subset of locales, and happened to
include the main one I needed (lucky me!).

How feasible would it be to make each locale it's own output on
glibc-locales (e.g. glibc-locales:en_US.utf8, or maybe cluster languages
together, e.g. glibc-locales:en) ? Most people probably only use a
relatively small number of locales on any given system... though which
locales any given person uses probably varies.

Is it a complexity vs. space-savings issue? Would it be tricky to
compose multiple locales packages into a single profile? Just not worth
the effort?

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Ten Years of Guix: Call for contributions

[Tobias Platen]

On Fri, 2022-07-01 at 15:30 +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> The Ten Years of Guix  event in Paris, 16–18 September, is shaping
> up,
> and you can register!
> 
>   https://10years.guix.gnu.org/
> 
> (There’s spam in the comment section of the registration form that we
> can’t fully block, but it’s functional.)
> 
> We’re planning to announce the program for Friday 16th, which focuses
> on
> uses of Guix in research, within a couple of weeks.  There will be
> room
> for lightning talks too.
> 
> For Saturday/Sunday, we already have a couple of nice talks and
> discussions scheduled (surprise! :-)), but we’d love to have more of
> them from you!  It could be “getting started” kind of talks for
> newcomers, demos, discussions on specific topics; for Sunday, it
> could
> be more in-depth hacking sessions or community discussions.
My proposed topic for one of these days is porting Guix to the 
Anbernic RG552, a mobile gaming console based on the libre-friendly
RK3399 SoC. I also own a RockPro64 which uses the same SoC.
> 
> Email Simon, Tanguy, and myself at guix-birthday-ev...@gnu.org or
> reply
> to this thread for proposals and questions.
> 
> Ludo’.
> 

Teams: please add yourself to etc/teams.scm.in

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Liliana Marie Prikler  writes:
>
>> Am Freitag, dem 01.07.2022 um 12:28 +0200 schrieb Ricardo Wurmus:
>>> [...]
>>> An example:
>>> 
>>>    ./pre-inst-env guile --no-auto-compile -l etc/teams.scm -c '(cc r
>>> core)'
>>> 
>>> This prints “git send-email” arguments to Cc members of the R and
>>> Core
>>> teams when a patch is received by Debbugs.
>>> 
>>> Another example:
>>> 
>>>    ./pre-inst-env guile --no-auto-compile \
>>>  -l etc/teams.scm -c '(list-teams)' | recsel -p name,members
>>
>> Could we perhaps make that script itself executable, so that we can
>> write 
>> $ ./etc/teams.scm list-teams | recsel -p name,members
>> $ ./etc/teams.scm cc r core
>
> Yes, we can.  Just like etc/committer.scm it would need to have a .in
> template to let us plug in the right guile shebang.

etc/teams.scm.in is now part of the repository.  The configure script
generates the executable etc/teams.scm.

Please feel free to add yourself to teams in that file by adding a
definition like this:

  (define-member (person "Ricardo Wurmus"
 "rek...@elephly.net")
r core mentors)

Thanks!

-- 
Ricardo

Re: glibc-locales

[Andreas Enge]

Am Sun, Jul 03, 2022 at 12:53:09PM +0300 schrieb Efraim Flashner:
> I misread the source. I'd like glibc-utf8-locales built with glibc-final.

Has glibc-utf8-locales not been removed some time ago? I always had it in
my profile, then saw a message during upgrade that it had been removed,
and dropped it from my profile (without any apparent harm to my GNU system).

Andreas

Re: Bug in strip phase of gnu-build-system?

[Mark H Weaver]

Hi,

elaexuo...@wilsonb.com writes:

> Hello,
>
> Sanity check, please.
>
> When `strip-binaries?` is `#f` and a "debug" output is defined, said output
> remains empty. Instead, I expect "debug" to get populated with separated debug
> files.
>
> The logic for creating debug files exists in (guix build gnu-build-system)
> under the definition of `strip`. In particular `strip-dir` extracts the debug
> info into "debug" if and only fi that output exists.
>
> Note, that (guix build-system gnu) already removes "debug" from the outputs
> when strip-binaries? is true.
>
> However, for some reason the actual `strip-dir1 invocation is wrapped in a (if
> strip-binaries? ...) check, meaning that the entire phase becomes a no-op.
> Shouldn't that if check be removed?
>
> I have CC'ed Mark Weaver, since it looks like he is the author of this
> particular if block.

The conditional was originally introduced by Ludovic, here:

  
https://git.sv.gnu.org/cgit/guix.git/commit/?id=877217b85ac318a0a702578f183dd638c9704112

My role was merely to reformulate the conditional as a 'when' instead of
an 'or', while making an unrelated change in a later commit, here:

  
https://git.sv.gnu.org/cgit/guix.git/commit/?id=9a87649c863e1ff8b073b356875eb05eecedbcf7

I've never studied this corner of Guix, and I don't have time to do so,
but perhaps Ludovic can respond further.

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: “Building a Secure Software Supply Chain with GNU Guix”

[Bengt Richter]

Hi Simon, and all,

On +2022-07-01 11:21:43 +0200, zimoun wrote:
> Hi Bengt,
> 
> On jeu., 30 juin 2022 at 23:37, b...@bokr.com wrote:
> 
> > I think IWBN to have some kind of trust code come with that git output,
> > like gpg's 1-5 but indicating how well the committer/signer trusts
> > that using the code will *not* cause a problem.
> 
> Well, from my understanding, Guix is dealing with 4 sort of code:
> 
>  1. Guix recipe of a package
>  2. Guix service
>  3. Guix itself
>  4. Upstream 
> 
> I do not think committers are pushing code about #1, #2 or #3 that they
> know beforehand it will cause a problem.
>

Hm, -- unless  ... ? :)

> Therefore, I do not see how it could be implemented without being rooted
> in committer feelings, opinion or self-confidence, i.e., highly variable
> from one committer to the other.
> 
> The GPG trust level works because it is based on the web of trust.
> Here, there is no web, IMHO.
>

Well, guix developers who know each other well "in real life" have a pretty
good web, if not formal, no? :)
It's just not accessible to newcoming outsiders, who can't see the trust
codes in the insiders' heads :)

> Most of the security issues are from #4.  Considering how hard it is to
> find and tackle the security issues, there is only two strategies, IMHO:
> do not trust which implies deep audit of distributed source code and so
> restrict the set of available packages (it is somehow an OpenBSD
> approach); or accept more packages which means somehow trust upstream,
> to some extent.
>

Agreed, #4 is usually the source of security issues.

I'm just looking for some greppable coded hint of the difference between
a package that consists of e.g. a reverse polish calculator homework
assignemnt that a nerdy friend showed how to submit as a package, vs.
e.g. a package where the comments say over 10K subscribers have now been
running this hundreds of times daily for 2 months of beta testing with
no reported problems. Vs. This is alpha stuff, but seems harmless enough
if you run it in a container.

I'm not asking any guarantees, just a professional's quick judgement.
Like a chef's quick opinion on the cantaloupes at the open market. 

This is separate from the issue of whether to include a package under guix.
No blocker if the cantaloupe is not ripe, but helpful to have a sticker
saying so, for those who (for lack of time perhaps) want to order on line
and use grep instead of their nose :)

> 
> However, all in all, it asks what is expected by the reviewing process,
> as discussed [1]. :-)
> 
> 1: 
> 
> 
> Cheers,
> simon

I am not forgetting that I should be thankful for anything I am provided
freely. So thank you all!
--
Regards,
Bengt Richter

Re: glibc-locales

[Efraim Flashner]

On Sun, Jul 03, 2022 at 11:53:45AM +0300, Efraim Flashner wrote:
> The package glibc-locales and glibc-locales-2.32 are nearly identical
> according to diffoscope.
> 
> (ins)efraim@3900XT ~$ guix shell diffoscope -- diffoscope 
> /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33 
> /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32
> --- /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33
> +++ /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32
> │   --- /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/lib
> ├── +++ 
> /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/lib
> │ │   --- 
> /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/lib/locale
> │ ├── +++ 
> /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/lib/locale
> │ │ ├── file list
> │ │ │ @@ -1 +1 @@
> │ │ │ -2.33
> │ │ │ +2.32
> │   --- /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/share
> ├── +++ 
> /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/share
> │ │   --- 
> /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/share/doc
> │ ├── +++ 
> /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/share/doc
> │ │ ├── file list
> │ │ │ @@ -1 +1 @@
> │ │ │ -glibc-locales-2.33
> │ │ │ +glibc-locales-2.32-2.32
> │ │ ├── /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
> │ │ │ @@ -1,8 +1,8 @@
> │ │ │
> │ │ │ -  Size: 36   Blocks: 0  IO Block: 4096   directory
> │ │ │ +  Size: 46   Blocks: 0  IO Block: 4096   directory
> │ │ │  Links: 1
> │ │ │  Access: (0555/dr-xr-xr-x)  Uid: (0/root)   Gid: (0/
> root)
> │ │ │
> │ │ │  Modify: 1970-01-01 00:00:01.0 +
> │ │ ├── /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
> │ │ │ @@ -1,8 +1,8 @@
> │ │ │
> │ │ │ +  Size: 46   Blocks: 0  IO Block: 4096   directory
> │ │ │ -  Size: 36   Blocks: 0  IO Block: 4096   directory
> │ │ │  Links: 1
> │ │ │  Access: (0555/dr-xr-xr-x)  Uid: (0/root)   Gid: (0/
> root)
> │ │ │
> │ │ │  Modify: 1970-01-01 00:00:01.0 +
> 
> 
> So while it would be nice to build glibc-locales-2.32 with glibc-2.33 I
> don't think it's actually in use anywhere since IIRC we jumped from 2.31
> to 2.33.
> 
> Also, for 2.33 I'd like to build it with glibc-final. glibc-locales
> doesn't retain a reference to any packages and it would reduce an
> instance of using an "extra" glibc when there's already one in the build
> environment.

I misread the source. I'd like glibc-utf8-locales built with glibc-final.
glibc-locales actually rebuilds the sources with an extra patch. I
suppose another option would be to use glibc-locales to build
glibc-utf8-locales.


-- 
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: RISCV porting effort

[Efraim Flashner]

On Thu, Jun 30, 2022 at 02:01:19PM +0200, Ludovic Courtès wrote:
> Howdy,
> 
> Efraim Flashner  skribis:
> 
> > (ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather -s 
> > riscv64-linux --substitute-urls="http://localhost:3000; -c100
> > computing 15,205 package derivations for riscv64-linux...
> > looking for 15,948 store items on http://localhost:3000...
> > http://localhost:3000
> >   14.3% substitutes available (2,274 out of 15,948)
> 
> Not bad!
> 
> Was it all built on a HiFive, or through emulated builds?

All on the HiFive. For some of the longer builds, like when I was
fiddling with llvm@9 and llvm@12 I emulated riscv64 on my machine so the
build was ~2 hours instead of ~6 hours, but after it built I garbage
collected it and rebuilt it on the native hardware.

> > Some notes:
> > * rust is definitely TODO
> > * GHC shouldn't be there on the list.
> > * gccgo should replace go@1.4. Currently I can't use gccgo@10 to build
> >   go@1.16.15, 1.17.9 or 1.17.11 on riscv64. gccgo@10 works for
> >   go@1.16.15 and 1.17.11.
> > * postgresql@13.6 I think is missing a patch currently
> > * libunwind isn't supported until 1.6.*
> > * valgrind isn't supported
> > * classpath@0.93 is the java bootstrap path
> > * openlibm, tbb and libunwind-julia are for julia
> > * node@10 doesn't (yet) recognize riscv64
> >
> > After that I don't remember offhand. I'm not sure I've tried yet to
> > build anything after ~170 so those can be ignored.
> 
> My guess is that upstream doesn’t go much further than you did, so
> thumbs up!

I just bumped libunwind on staging to 1.6.2 so that'll be available
eventually.

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

glibc-locales

[Efraim Flashner]

The package glibc-locales and glibc-locales-2.32 are nearly identical
according to diffoscope.

(ins)efraim@3900XT ~$ guix shell diffoscope -- diffoscope 
/gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33 
/gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32
--- /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33
+++ /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32
│   --- /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/lib
├── +++ /gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/lib
│ │   --- 
/gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/lib/locale
│ ├── +++ 
/gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/lib/locale
│ │ ├── file list
│ │ │ @@ -1 +1 @@
│ │ │ -2.33
│ │ │ +2.32
│   --- /gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/share
├── +++ 
/gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/share
│ │   --- 
/gnu/store/ixzmi6614baf4w37qfjgqrv8hwsl8jcv-glibc-locales-2.33/share/doc
│ ├── +++ 
/gnu/store/zrq9pr31wl128y6nwyh2022i9jqxazpz-glibc-locales-2.32-2.32/share/doc
│ │ ├── file list
│ │ │ @@ -1 +1 @@
│ │ │ -glibc-locales-2.33
│ │ │ +glibc-locales-2.32-2.32
│ │ ├── /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
│ │ │ @@ -1,8 +1,8 @@
│ │ │
│ │ │ -  Size: 36   Blocks: 0  IO Block: 4096   directory
│ │ │ +  Size: 46   Blocks: 0  IO Block: 4096   directory
│ │ │  Links: 1
│ │ │  Access: (0555/dr-xr-xr-x)  Uid: (0/root)   Gid: (0/root)
│ │ │
│ │ │  Modify: 1970-01-01 00:00:01.0 +
│ │ ├── /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin/stat {}
│ │ │ @@ -1,8 +1,8 @@
│ │ │
│ │ │ +  Size: 46   Blocks: 0  IO Block: 4096   directory
│ │ │ -  Size: 36   Blocks: 0  IO Block: 4096   directory
│ │ │  Links: 1
│ │ │  Access: (0555/dr-xr-xr-x)  Uid: (0/root)   Gid: (0/root)
│ │ │
│ │ │  Modify: 1970-01-01 00:00:01.0 +


So while it would be nice to build glibc-locales-2.32 with glibc-2.33 I
don't think it's actually in use anywhere since IIRC we jumped from 2.31
to 2.33.

Also, for 2.33 I'd like to build it with glibc-final. glibc-locales
doesn't retain a reference to any packages and it would reduce an
instance of using an "extra" glibc when there's already one in the build
environment.

-- 
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: Shall updaters fall back to other updaters?

[Hartmut Goebel]

Am 01.07.22 um 15:15 schrieb Ludovic Courtès:

BTW 2: Which updater is used for each package is non-deterministic.

Do you have an example?  I’d think they’re always tried in the same
order, no?


When looking at the code, I don't see any means of sorting: 
 
and below. (Maybe sorting is hidden in one of the function 
guile-internal used there there.)



--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |