Re: Let’s meet in person in Paris, Sept. 16–18!

[Tobias Platen]

I'm not sure, but most likely I want to participiate in this
conference. Then I will present the Guix Gaming Service, 
on which I am currently working and the proposed Guix Deck hardware.

Tobias (alyx)

Re: Hardened toolchain

[Maxime Devos]

zimoun schreef op ma 02-05-2022 om 19:41 [+0200]:
> > (*) In my case, this is not about supercomputers or computer
> > clusters, but about having software run fast enough on the hardware
> > that is available.  In some situations, that's a fancy
> > supercomputer, but often a simple laptop can do ... if the software
> > is sufficiently optimised.
> 
> I agree that HPC practitioners can burn some CPU cycles and recompile
> the world if they care so much about run-time performances.
> 
> To me, it is the same trade-off by HPC folks as custom / performance
> vs portable / pre-built. :-)

I didn't mean rebuilding the world, only things like numpy, openblas,
fftw and maybe glibc -- avoiding rebuilding dependents, with the grafts
mechanism used by --tune.

Greetiings,
Maxime.


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

Mumi, public-inbox and tools

[zimoun]

Hi,

Recently, we discussed [1] in «public-inbox/elfeed -> Maildir bridge
(was: Incentives for review)» some tips to ease the workflow dealing
with the various lists and their volume.

Kyle wrote some Emacs glue around public-inbox, named piem [2].

One cool feature exposed by Kyle in [1] is being able to inject the
complete thread to a Maildir.

For instead, let configure piem with just:

--8<---cut here---start->8---
(setq
 piem-inboxes '(("guix-bugs"
  :url "https://yhetil.org/guix-bugs/";
  :maildir "/tmp/mail/guix-bugs"
  )
("guix-patches"
  :url "https://yhetil.org/guix-patches/";
  :maildir "/tmp/mail/guix-patches"
  )))
(add-hook 'eww-mode-hook #'piem-eww-mode)  
--8<---cut here---end--->8---

then, let create the maildirs:

mkdir -p /tmp/mail/guix-{bugs,patches}/{new,cur,tmp}

Last, just search for a number id:

M-x eww
https://yhetil.org/guix-patches/?q=a:39258

then click to one, and

M-x piem-inject-thread-into-maildir

paf!  The 126 messages of the patch submission #39258 are now in my
local maildir and I can read them using my favorite mail reader; say
Emacs-notmuch. ;-)

It completely replace my usage of the Debian scripts ’bts’ and
’mailscripts’.  Neat!  Because it was Perl… :-)


The issue is that it is going via a public-inbox query [4]:

a:   match within the To, Cc, and From headers

where it could be nice to directly use Mumi with:

M-x eww
http://issues.guix.gnu.org/issue/39258

However, then ’piem-inject-thread-into-maildir’ cannot find the
Message-ID even if many are visible:

--8<---cut here---start->8---
Arun Isaac wrote on 23 Jan 2020 20:51
SVG Image
Recipients:(address . guix-patc...@gnu.org)
Message-ID:cu7pnfaar36@systemreboot.net
--8<---cut here---end--->8---


Well, it could be nice if I could hook and directly import to my local
maildir the thread.


WDYT?  What is missing to bridge the current features of Mumi via
issues.guix.gnu.org, of public-inbox via yhetil.org/guix and the piem
glue?


It could be nice to:

 1. run “guix issues 12345” and get back something ready (as mbox or
 maildir) to go to a mail reader, or pipe to Git maybe.

 2. integrate such to Emacs-Guix.
 

1: 
2: 
3: 

4: 


Cheers,
simon

Re: Hardened toolchain

[zimoun]

Hi Maxime,

On Mon, 02 May 2022 at 18:25, Maxime Devos  wrote:
> zimoun schreef op vr 29-04-2022 om 12:31 [+0200]:
>> > Stack smashing protection (SSP) may incur measurable run-time
>> > overhead
>> > though so enabling that one by default may be less consensual.
>> 
>> That’s true and it could be an issue for HPC practitioners.  [...]
>
> I'm not sure if this wasn't already mentioned, but HPC practicioners
> can already use --tune.  Maybe HPC practicioners can have --without-
> hardening.  However, in the computing I do that needs to be high
> performance (*), it seems that the expensive computations are matrix
> multiplications, eigenvector decompositions and the like.  I wouldn't
> expect those kind of things to be hindered by hardening.
>
> (*) In my case, this is not about supercomputers or computer clusters,
> but about having software run fast enough on the hardware that is
> available.  In some situations, that's a fancy supercomputer, but often
> a simple laptop can do ... if the software is sufficiently optimised.

I agree that HPC practitioners can burn some CPU cycles and recompile the
world if they care so much about run-time performances.

To me, it is the same trade-off by HPC folks as custom / performance vs
portable / pre-built. :-)


Cheers,
simon

Re: Hardened toolchain

[Maxime Devos]

zimoun schreef op vr 29-04-2022 om 12:31 [+0200]:
> > Stack smashing protection (SSP) may incur measurable run-time
> > overhead
> > though so enabling that one by default may be less consensual.
> 
> That’s true and it could be an issue for HPC practitioners.  [...]

I'm not sure if this wasn't already mentioned, but HPC practicioners
can already use --tune.  Maybe HPC practicioners can have --without-
hardening.  However, in the computing I do that needs to be high
performance (*), it seems that the expensive computations are matrix
multiplications, eigenvector decompositions and the like.  I wouldn't
expect those kind of things to be hindered by hardening.

(*) In my case, this is not about supercomputers or computer clusters,
but about having software run fast enough on the hardware that is
available.  In some situations, that's a fancy supercomputer, but often
a simple laptop can do ... if the software is sufficiently optimised.

Greetings,
Maxime.


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

Re: Hardened toolchain

[Katherine Cox-Buday]

zimoun  writes:

> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès  wrote:
>
>> Stack smashing protection (SSP) may incur measurable run-time
>> overhead though so enabling that one by default may be less
>> consensual.
>
> That’s true and it could be an issue for HPC practitioners.  However,
> quoting Wikipedia [1], for what it is worth:
>
> All Fedora packages are compiled with -fstack-protector since Fedora
> Core 5, and -fstack-protector-strong since Fedora 20.[19][20] Most
> packages in Ubuntu are compiled with -fstack-protector since 6.10.[21]
> Every Arch Linux package is compiled with -fstack-protector since
> 2011.[22] All Arch Linux packages built since 4 May 2014 use
> -fstack-protector-strong.[23] Stack protection is only used for some
> packages in Debian,[24] and only for the FreeBSD base system since
> 8.0.[25] Stack protection is standard in certain operating systems,
> including OpenBSD,[26] Hardened Gentoo[27] and DragonFly BSD.

For me at least, this is a compelling argument for also defaulting to more 
secure, but possibly slower, build flags. (Full disclosure: I would personally 
benefit from the security over performance model of defaults).

But I think we should state our reasons plainly in the documentation, and 
provide an easy way for those who need performance to "recompile the world".

-- 
Katherine

Re: Reproducibility of "core" packages in GNU Guix

[Vagrant Cascadian]

On 2022-05-02, zimoun wrote:
> On Mon, 02 May 2022 at 06:11, Vagrant Cascadian 
>  wrote:
>> $ guix challenge --diff=none $(cat guix-base-set)
...
>> The fact that the guix and guile packages do not build reproducibly is a
>> little disappointing as they're both so central to guix itself; I
>> suspect parallelism triggers those reproducibility issues(from
>> experience with Debian), though that may just reveal other issue in
>> guile itself.
>
> About Guix, probably bug#44835 [1] for one, I guess.  And note this old
> Guile bug#20272 [2] for two, which implies unreproducible Guix.
>
> 1: 

This one is regarding build paths, and since guix normalizes the build
path in the build environment, it should not affect builds in guix...

> 2: 

But this one definitely touches on the parallelism issue!

Thanks for the links! I remembered commenting on them... just didn't
find the links with a quick search...



live well,
  vagrant


signature.asc
Description: PGP signature

Re: Reproducibility of "core" packages in GNU Guix

[zimoun]

Hi Vagrant,

Cool to see these reports.


On Mon, 02 May 2022 at 06:11, Vagrant Cascadian 
 wrote:

> $ guix challenge --diff=none $(cat guix-base-set)
>
> /gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5 contents 
> differ:
>   no local build for 
> '/gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5'
>   
> https://ci.guix.gnu.org/nar/zstd/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5:
>  19rg55v51wliy9v30sm82f38rxm1lqjpfqs6r63ikb3vklnj0pnw
>   
> https://bordeaux.guix.gnu.org/nar/lzip/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5:
>  14fax6g9sx7qj64z73hrh8ydlbv6kxzhd1hbyqz7v0ra51bprv1k
> /gnu/store/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3 contents differ:
>   no local build for 
> '/gnu/store/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3'
>   
> https://ci.guix.gnu.org/nar/lzip/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3:
>  1sag2bq9kbp5np3fpakyi4xg96kxq5xwbb7ib4hamx2bqh6vscr9
>   
> https://bordeaux.guix.gnu.org/nar/lzip/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3:
>  07ln4fqgvg0ag2d881xhgdw2h3m1lqzs6xlac8p7rz2rgx0wx1yr
> /gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23 contents differ:
>   no local build for '/gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23'
>   https://ci.guix.gnu.org/nar/lzip/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23: 
> 03a180af1my7lmsnig01qhrirxa2fp7j052jw9kv5ff4i6ya7fh4
>   
> https://bordeaux.guix.gnu.org/nar/lzip/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23:
>  1j24gc6ysa9d3z4hq6lsxvdik94ddb7nj93krv7cs5lmbmjwmqw7
> /gnu/store/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0 contents 
> differ:
>   no local build for 
> '/gnu/store/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0'
>   
> https://ci.guix.gnu.org/nar/lzip/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0:
>  0p7lhfxcx7bfjfwlyrp6h5j9fcyzswyj2wkbnhcd3fgxm5swdi6c
>   
> https://bordeaux.guix.gnu.org/nar/lzip/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0:
>  0yfpcsmvbnzw0vpjrjwwrjih4ss3yvk7cy4k6ibdpsn7dcx9kw2c
> /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8 contents differ:
>   no local build for '/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8'
>   
> https://ci.guix.gnu.org/nar/lzip/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8:
>  0vppx6fk1a7gvk9ccz9ma992w1h5bhfk535acddrnkhyrk92z5ln
>   
> https://bordeaux.guix.gnu.org/nar/lzip/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8:
>  05w5i5zq1k1avqx2gqxnqynn5lmdizis9babk34dkmnazb3h77kb
>
> 47 store items were analyzed:
>   - 42 (89.4%) were identical
>   - 5 (10.6%) differed
>   - 0 (0.0%) were inconclusive

[...]

> The fact that the guix and guile packages do not build reproducibly is a
> little disappointing as they're both so central to guix itself; I
> suspect parallelism triggers those reproducibility issues(from
> experience with Debian), though that may just reveal other issue in
> guile itself.

About Guix, probably bug#44835 [1] for one, I guess.  And note this old
Guile bug#20272 [2] for two, which implies unreproducible Guix.

1: 
2: 


Cheers,
simon

Re: phrasing of project vision

[Maxime Devos]

Joshua Branson schreef op vr 15-04-2022 om 09:56 [-0400]:
> +* Features scheduled for 2.0
> +- technical Guix System users can for GNU/Hurd Guix System on real hardware.
> +- Guix System installer supports guix home
> +- graphical (possibly gtk-based) front-end to guix cli
> +

Can we move over

+ distributed validation: compare contents of store items with
  others
  * resist a hydra.gnu.org compromise

from ‘Features for later’ to ‘Features scheduled for 2.0’? (Replacing
hydra.gnu.org with ci.guix.gnu.org)

This only requires ‘client-side’ changes -- currently, the substitute
authorisation code requires the narinfo hash to be signed by at least
one of the authorized-keys, things could be modified to check that the
same hash is signed by multiple authorized-keys (basically, 'and'
instead of 'or').

Also, some items in the roadmap have been done (‘guix publish’, all the
‘more OS features’, mcron, wicd, "guix system list-generations/delete-
generations", ‘using Git to fetch the source code’, ‘signed commits’)
and can be removed.

Greetings,
Maxime.


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

Reproducibility of "core" packages in GNU Guix

[Vagrant Cascadian]

On 2022-04-27, Vagrant Cascadian wrote:
> Lately, I've been trying to get a handle on the status of the really
> core packages in Debian
...
> I'd also be really curious to hear about the status of similar package
> sets in other distros!

With my metaphorical guix hoodie[1] on...

$ guix describe

Generation 73   May 02 2022 05:21:25(current)
  guix 9dafaf1
repository URL: /home/vagrant/src/guix
branch: master
commit: 9dafaf163574edca5cb4eac0f8dc3edbb0ef0a75

$ guix challenge --diff=none $(cat guix-base-set)

/gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5 contents differ:
  no local build for 
'/gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5'
  
https://ci.guix.gnu.org/nar/zstd/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5:
 19rg55v51wliy9v30sm82f38rxm1lqjpfqs6r63ikb3vklnj0pnw
  
https://bordeaux.guix.gnu.org/nar/lzip/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5:
 14fax6g9sx7qj64z73hrh8ydlbv6kxzhd1hbyqz7v0ra51bprv1k
/gnu/store/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3 contents differ:
  no local build for 
'/gnu/store/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3'
  
https://ci.guix.gnu.org/nar/lzip/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3:
 1sag2bq9kbp5np3fpakyi4xg96kxq5xwbb7ib4hamx2bqh6vscr9
  
https://bordeaux.guix.gnu.org/nar/lzip/7qz2jlghm4gc87jww5j24c5mcip0whzy-keyutils-1.6.3:
 07ln4fqgvg0ag2d881xhgdw2h3m1lqzs6xlac8p7rz2rgx0wx1yr
/gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23 contents differ:
  no local build for '/gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23'
  https://ci.guix.gnu.org/nar/lzip/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23: 
03a180af1my7lmsnig01qhrirxa2fp7j052jw9kv5ff4i6ya7fh4
  
https://bordeaux.guix.gnu.org/nar/lzip/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.23:
 1j24gc6ysa9d3z4hq6lsxvdik94ddb7nj93krv7cs5lmbmjwmqw7
/gnu/store/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0 contents 
differ:
  no local build for 
'/gnu/store/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0'
  
https://ci.guix.gnu.org/nar/lzip/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0:
 0p7lhfxcx7bfjfwlyrp6h5j9fcyzswyj2wkbnhcd3fgxm5swdi6c
  
https://bordeaux.guix.gnu.org/nar/lzip/45b6181w68a3lprx9m6riwgyinw3y145-guix-1.3.0-25.c1719a0:
 0yfpcsmvbnzw0vpjrjwwrjih4ss3yvk7cy4k6ibdpsn7dcx9kw2c
/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8 contents differ:
  no local build for '/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8'
  
https://ci.guix.gnu.org/nar/lzip/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8: 
0vppx6fk1a7gvk9ccz9ma992w1h5bhfk535acddrnkhyrk92z5ln
  
https://bordeaux.guix.gnu.org/nar/lzip/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8:
 05w5i5zq1k1avqx2gqxnqynn5lmdizis9babk34dkmnazb3h77kb

47 store items were analyzed:
  - 42 (89.4%) were identical
  - 5 (10.6%) differed
  - 0 (0.0%) were inconclusive


I love that Guix really has batteries included when it comes to
reproducible builds verification! :)

At first, I thought I would have to build all this stuff locally, but
then I realized guix actually has two independent build farms, so guix
challenge can compare the results between them! For more data points,
one could build them all locally!


The fact that the guix and guile packages do not build reproducibly is a
little disappointing as they're both so central to guix itself; I
suspect parallelism triggers those reproducibility issues(from
experience with Debian), though that may just reveal other issue in
guile itself.


The linux-libre package *ought* to be reproducible; I hope it is
something easy to fix there...

$ guix challenge --diff=diffoscope linux-libre

/gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5 contents differ:
  no local build for 
'/gnu/store/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5'
  
https://ci.guix.gnu.org/nar/zstd/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5:
 19rg55v51wliy9v30sm82f38rxm1lqjpfqs6r63ikb3vklnj0pnw
  
https://bordeaux.guix.gnu.org/nar/lzip/8gmqvwf0ccqfyimficcnhxvrykwx6y8g-linux-libre-5.17.5:
 14fax6g9sx7qj64z73hrh8ydlbv6kxzhd1hbyqz7v0ra51bprv1k
 ...
 0%  ETA:  4 days, 2:03:47

Ok... well, I guess I won't wait for the results...


A better "core" package set for GNU Guix could surely be created. I came
up with this list of packages by taking the essential, required and
build-essential package sets from Debian, tweaking the package names
appropriately, dropping debian-specific stuff, and adding guile and
guix to create "guix-base-set":

acl
attr
audit
bash
binutils
bzip2
coreutils
diffutils
e2fsprogs
elogind
findutils
gawk
gcc
glibc
gmp
grep
guile
guix
gzip
isl
keyutils
libcap
libcap-ng
libnsl
libselinux
libsigsegv
libtirpc
libxcrypt
linux-pam
linux-libre
mpfr
ncurses
openssl
patch
pcre
pcre2
perl
readline
rpcsvc-proto
sed
shadow
tar
tzdata
util-linux
xz
zlib
zstd


> I would also like to see if there is anything in Debian or other
> distros that still needs to be pushed upstream, so we can all benefit!

Will dig into s

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[zimoun]

Hi,

On Tue, 05 Apr 2022 at 14:06, Ludovic Courtès  wrote:

>> Changing all pre-existing packages, maybe.  But doing this for new
>> packages (reducing review effort) and perhaps when a package is updated
>> (for purity) should be feasible I think?  Then gradually things would
>> improve and eventually(TM) doing the switch in the bootstrap phase may
>> become feasible ...
>
> Yes, we could do that as a first step (in fact it’s already happening as
> some projects no longer distribute tarballs).

Moreover, what appears to me unexpected is that the ’gnu-build-system’
run ’autoreconf’ but Autotools are not part of the build inputs by
default and the user has to explicitly add them.

--8<---cut here---start->8---
(define* (bootstrap #:key (bootstrap-scripts %bootstrap-scripts)
#:allow-other-keys)
  "If the code uses Autotools and \"configure\" is missing, run
\"autoreconf\".  Otherwise do nothing."

[...]

  (if (not (script-exists? "configure"))

[...]
(invoke "autoreconf" "-vif")
[...]
--8<---cut here---end--->8---

For sure, it leads to some issues for the deep nodes in the bootstrap
chain.  And it also leads to some other issues as fetching tarballs for
saving bandwidth or for checking signature, etc.

However, IMHO, the logic should be reverted:

 - include by default Autotools and run ’autoreconf’ by default
 - for some cases, use the provided ’./configure’ script


Cheers,
simon

Re: Status of KDE Plasma

[phodina]

Hi,

I'll send my updated patches on Friday. Those are rebased on Brendan's updates.

Petr

 Original Message 
On May 1, 2022, 9:32 PM, kiasoc5 wrote:

> Brendan Tildesley and Petr Hodina (ccd) have made great progress so far: 
> https://issues.guix.gnu.org/50862
>
> Brendan's patches: https://notabug.org/Brendan/guix/commits/kde-updates
> Petr has been rebasing them onto Guix: 
> https://github.com/phodina/guix/tree/patch/plasma-mobile
>
> I guess you can help them with testing and fixing builds, hopefully they are 
> getting close.

Re: Updating mumi on berlin

[zimoun]

Hi Arun,

On Wed, 27 Apr 2022 at 16:44, Arun Isaac  wrote:

> Yes, with the update, Mumi will have a GraphQL API. GraphQL APIs are
> more flexible than traditional REST APIs. See https://graphql.org/ for
> more.

Is the update of Mumi done?


Well, this GraphQL API could ease the current workflow, IMHO.

Today, one has to subscribe and it is not easy to locally read the
archives or follow what is going in.  The Emacs front-end to Debbugs
helps but Emacs is not always popular.

Instead of subscription, public-inbox provides the archives as a Git
repo.  Therefore, being up to date just becomes “guix pull” and the Git
repo can be transformed to Maildir using e.g.,

--8<---cut here---start->8---
$git rev-list  | while read sha; do
$git show $sha:m > /new/$sha
done
--8<---cut here---end--->8---

(modulo some errors for deleted messaged, another story).


The main issue is to synchronize the status of the Debbugs database;
from the messages, we cannot deduce the status, etc.

This GraphQL API would help to bridge the gap… at least my gap. ;-)


> At some point, I plan to add support for identifying a message just by
> its Message-ID. IIRC, zimoun requested this feature once. With this, I
> hope to write a simple 'mumi send-email' program or similar, that will
> let us send a patchset to mumi all in one go without inadvertently
> opening multiple issues.

Really cool!

Debian has this CLI tool [1], allowing to request against Debbugs.  It
could be nice to have a similar tool based on the top of Mumi.

And for instance, using this ’bts’ Debian script, it is “easy“ to have
other scripts for importing [2] bugs to any mail reader using Maildir.
Given a bug number, it allows to download all the thread of that bug.

We could package these Debian scripts and tweak them to work with the
Guix instance… Or maybe we could have some Scheme scripts. ;-)


About Message-ID and Mumi, yeah… for example, it is just an instant
using notmuch for finding the patch where you tweak Xapian and ‘guix
search’.  But to publicly refer to it, I have to open my browser scroll
and scroll again, and found it; the 14th message in the thread.  Well,
since I can easily stash the Message-ID from notmuch and I can easily
build an URL with it, then I think that:

   https://issues.guix.gnu.org/20200227204150.30985-1-arunis...@systemreboot.net

redirecting to,

   https://issues.guix.gnu.org/39258#14

would simplify my workflow. :-)  It appears to me weird that all is
built around email but core components as Message-Id is barely used.


1: 
2: 


Cheers,
simon

Re: Status of KDE Plasma

[Hartmut Goebel]

Am 02.05.22 um 11:14 schrieb Hartmut Goebel:
Basically there are package definitions for most of the Plasma 
packages (as of 5.19), kwin, etc. One of the files has a list of state 
per package. Anyhow I failed to make Plasma start the actual desktop.


To emphasize this: Packaging the Plasma module is basically done. But 
making Plasma Desktop actually run is a major issue.


--
Regards
Hartmut Goebel

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

Re: Improving importers best investment for growing gnu/packages/

[zimoun]

Hi,

On Tue, 29 Mar 2022 at 10:50, Brendan Tildesley  wrote:

> Therefore I'm working on making use of
> https://github.com/rust-lang/crates.io-index  to fully import base definitions
> all required crates rather than pulling metadata from the internet with each 
> refresh.

>From my point of view, the issue is that it requires external Rust tools
and I think such tool will never be part of the Guix dependencies.  Guix
itself cannot depends on Rust-thing, GHC-thing, OCaml-thing,
Julia-thing, etc. because they ease the importers.

And that’s why the current importers parse metadata and somehow
“reimplement” the logic behind the package manager of each language.  I
agree that it is a lot of work and hard to maintain but doing so allow
Guix to have a small footprint (dependency, speaking).

That’s said, how to improve the importers?

Well, Guix provides now GUIX_EXTENSIONS_PATH which allows to extend by
other subcommands.  “guix workflow” is an example, I do not remember how
“guix home” did initially, anyway!

My point is: this mechanism allows to have a package (with many
dependencies) extending Guix itself.  Somehow, it reads

guix install guix-rusty
guix rusty 

where ’guix-rusty’ would be a Guile package (program) using whatever it
needs from the Rust ecosystem (say parse system calls of cargo or
whatever).

Guix is Scheme library after all, let use it! :-)


Cheers,
simon

Re: Status of KDE Plasma

[Hartmut Goebel]

Am 01.05.22 um 23:13 schrieb Anthony Wang:

I also found the wip-kde-plasma branch in the Guix Git repository has some made 
some progress too. However, this branch has not been committed to in more than 
a year and only supports KDE 5.19.


This branch intentionally is on 5.19, as the Readme says:

|Note 1: It might be worth making an older version of Plasma work, as 
this an older version has less dependencies. This is why this branch 
still sticks at 5.19.5. |


And to my experience Plama is a beast and taming it might be much easier 
when using a less beasty version. This is why I recommend sticking with 
this old version for now and update only after this works.


||

--
Regards
Hartmut Goebel

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

Re: Status of KDE Plasma

[Hartmut Goebel]

Hi,

glad to see someone to pick up this task.

Am 01.05.22 um 05:06 schrieb Anthony Wang:

I have a few questions: What is the current status of KDE Plasma on Guix? And 
also, how can I help or contribute?


You can find the current state of Plasma in the „wip-kde-plasma” branch 
.


The top-level directory contains a 00-README-Plasma.txt 
, 
explaining the current state in detail. The branch also provides some 
helper-scripts for testing, etc. I strongly recommend reading through 
all of these files to find the hidden gems ;-)


Basically there are package definitions for most of the Plasma packages 
(as of 5.19), kwin, etc. One of the files has a list of state per 
package. Anyhow I failed to make Plasma start the actual desktop.


--
Regards
Hartmut Goebel

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

[zimoun] Re: Viewing derivation output in the store

[zimoun]

Hum, I guess, I have screwed up the reply’s header… Anyway!

 Start of forwarded message 
From: zimoun 
To: Ludovic Courtès 
Subject: Re: Viewing derivation output in the store
Date: Fri, 29 Apr 2022 11:41:17 +0200

Hi,

On Thu, 28 Apr 2022 at 09:30, Ludovic Courtès  wrote:

> I guess we could do that, though it seems to me like a marginal
> improvement over ‘mbegin’ and ‘mlet’.

What do you mean by marginal?


Because the current pattern,

--8<---cut here---start->8---
(with-store store
  (run-with-store store
(mlet* %store-monad
((drv (gexp->derivation "myderivation" test-gexp))
 (output -> (derivation->output-path drv)))
  (mbegin %store-monad
(built-derivations (list drv))
(return (format #t "~a~%" output))
--8<---cut here---end--->8---

is really cumbersome, i.e.,

(with-store store
  (run-with-store store

(mlet* %store-monad
()
  (mbegin %store-monad

when you compare with this proposal,

--8<---cut here---start->8---
(mdo %store-monad
  (drv <- (gexp-derivation "myderivation" test-gexp))
  (output <- (return (derivation->output-path drv)))
  (built-derivations (list drv))
  (return (format #t "~a~%" output)))
--8<---cut here---end--->8---


First, monadic style is not popular among Lispers.  Second, the current
monadic style is hard to grasp.  Consequence, few people dive* in monadic
things.

For sure, it will not revolutionize but it would bridge various
materials about monadic things.

Therefore, if nothing is preventing us from having do notation à la
Haskell, we are avoiding success at all costs (as the Haskell’s slogan
says ;-)).


Cheers,
simon



*few people dive: I remember some discussion with Guixers at FOSDEM some
 time ago, that’s why I wrote an attempt of explanations,



and such improvement would even simplify «the Store Monad» concept,
IMHO.
 End of forwarded message 

Re: Build failure of extra-cmake-modules 5.91.0 (was: Status of KDE Plasma)

[Andreas Enge]

Hello,

there is also this line:

Am Mon, May 02, 2022 at 02:03:45AM +0800 schrieb Zhu Zihao:
> Could not set up the appstream test. appstreamcli is missing.

Maybe this is the real error, and a dependency is missing? We do have a
package called appstream in Guix, and it contains the binary appstreamcli.
How about trying to add the package to native-inputs?

Andreas

Re: Haskell updates: GHC 9 and Stackage 19

[Lars-Dominik Braun]

Hi zimoun,

> In the light of «‘staging’ branch is open!» [1], it could be nice! :-)
there’s no way we’ll get this done by your proposed date May 8th. Last
time it took me two weeks full time to update everything. I don’t want
to delay the merge of staging for this.

> About the importer, I do not know.  But we can share the workload.
> Well, I will give a try next week.
Sure, go ahead. But for starters we don’t even have GHC 9.0 as a
package yet. Meanwhile I’m working on improvements for the cabal
importer, so it does not choke on certain .cabal files.

Cheers,
Lars

Re: Let’s meet in person in Paris, Sept. 16–18!

[Tanguy LE CARROUR]

Hi Guix!


Quoting Ludovic Courtès (2022-04-14 16:08:46)
> This year is Guix’s ten year anniversary and also a time when in-person
> meetings are again possible in some regions of the world, so… Simon and
> myself have tentatively scheduled an in-person meeting in Paris, France,
> from September 16th to 18th!  \o/

If everything goes as planned (but life being what it is… who knows!?)
I should be able to attend the 3 days! \o/


> For this to work, we’ll need your help: to define the program (looking
> for speakers, for facilitators for work groups or hacking sessions), for
> the logistics (especially if you live in Paris, but also: setting up
> video capture and publication, live streaming), setting up a web page,
> and so on.

I live in (near) and work in Paris so I can give a hand with logistics!
… depending on what "logistics" means! ^_^'
I can definitively carry stuff and move things around. For the rest, who
knows! :-)


> We have been in contact with IRILL¹, which kindly offers to host the
> event in its offices; we are discussing to confirm the details.
> 
> The way we see it, it would go as follows:
> 
>   1. Friday will be dedicated to uses of Guix for reproducible research
>  workflows, primarily with talks from people with experience in the
>  field.

That might be the perfect time to discuss something that I've wanted to
organise for a looong time: talking about Guix on the French radio in
the April's "Libre à vous" [1][].
Guix as is, is a bit too technical for the audience, but Frédéric Couchet
suggested to talk about a broader subject: "reproductibilité des environnements
logiciels pour la recherche" ("software environment reproducibilité for 
research").
And Guix would be a part of it.
We "just" need to identify potential speakers.

[1]: https://www.libreavous.org/


>   2. Saturday and Sunday will be more informal, with a mixture of talks,
>  tutorials, hacking sessions, install parties, or really whatever
>  you’d like to see happen—including having a birthday cake.  :-)


> We invite y’all to share ideas and suggestions: things you’d like to
> talk about or hear about, hacking sessions you’d like to have with
> others, things you’d like to do to introduce Guix to newcomers.

For what it is worth, here is my top 3:

- Guix System on Olimex Olinuxino
- Guix System GNU/Hurd on Olinuxino… and Viking D8… and Thinkpad T200
- GNUnet on Guix System GNU/Hurd on Olinuxino

Have you spotted the pattern?! :-)

Looking forward to September!

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Philip,


Quoting Philip McGrath (2022-04-29 21:11:41)
> On 4/18/22 16:24, Ludovic Courtès wrote:
> > Hi,
> > 
> > Tanguy LE CARROUR  skribis:
> > 
> >> gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
> >> gpgv:using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
> >> gpgv: Can't check signature: No public key
> >> Would you like to add this key to keyring 
> >> '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
> >> yes
> >> gpg: keyserver receive failed: No data
> > 
> > This indicates that ‘guix refresh’ failed to download the relevant GPG
> > key from the default key server, the one that appears in
> > ~/.gnupg/dirmngr.conf (if it exists).
> > 
> > That’s unfortunately often the case these days.  :-/ This key appears to
> > be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> > ignores it (for no good reason):
> > 
> > --8<---cut here---start->8---
> > $ gpg --no-default-keyring --keyring 
> > /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver 
> > keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpg: key D6B570842F7E7F8D: no user ID
> > gpg: Total number processed: 1
> > $ gpg --no-default-keyring --keyring 
> > /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 
> > 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpg: error reading key: No public key
> > --8<---cut here---end--->8---
> > 
> > I’m not sure what a good solution is (other than looking for the key
> > manually on Savannah or on some random key server).
> > 
> 
> Many distributions of GnuPG include a patch to handle keys without “user 
> ID” packets.[1] In fact, it may well be *most* distributions: Debian, 
> Fedora, Nix, OpenSUSE[2], and at least one commonly-recommended 
> installation option for Mac. Debian packagers have argued [3]:
> 
> > I think GnuPG's inability to receive these
> > kinds of cryptographic updates to OpenPGP certificates that it knows
> > about is at core a security risk (it makes it more likely that users
> > will use a revoked key; or will be unable to use any key at all, and
> > will send plaintext).
> 
> Unfortunately, the upstream GnuPG maintainer has rejected the patch, I 
> guess because strict conformance to the OpenPGP standards requires user 
> ids.[4]
> 
> I am by no means an expert on PGP or GPG issues, but I'd be in favor of 
> Guix adopting this patch.
> 
> -Philip
> 
> [1]: https://keys.openpgp.org/about/faq#older-gnupg
> [2]: https://build.opensuse.org/package/show/openSUSE:Factory/gpg2
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665#10
> [4]: https://dev.gnupg.org/T4393#133689

Oh… thank you so much for your answer! Looks like the proper way to go!
I'll try to update GnuPG package definition to integrate one or several
of those patches.
Or maybe we should first figure out it this is the right thing to do?!

Guix, thoughts!?

Regards,

-- 
Tanguy