bug#57316: (core-updates) dejagnu@1.6.3 sometimes fails to build

[Ludovic Courtès]

Maxime Devos  skribis:

> I cannot reproduce the test failure locally myself.
>
> * gnu/packages/dejagnu.scm (dejagnu)[#:out-of-source?]:
> Do an out-of-source build, as recommended upstream, and
> add a link to the upstream bug report.

Pushed in ‘core-updates’ as 0e305798454c558ab6e722cf66ba351c326a1a8d.

Thanks!

Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi,

(Cc’ing Andreas for extra advice.)

Maxime Devos  skribis:

> We disallow signing with SHA-1, because it is known to be vulnerable
> and as there are alternatives that are considered good, even if this
> limits what users can do with their OpenPGP keys.

Right, we know it’s affordable to break SHA-1 these days.

> In case of those curves, I'm not aware of any 'crytopgraphic proof'
> (*) that the curves are vulnerable (unlike for SHA-1), but as noted in
> ¹ and elsewhere, there are other kinds of evidence that something is
> wrong.

It’s different from SHA-1 though: ECDSA is not known to be vulnerable,
and AIUI we can’t tell that there’s a possibility NIST/NSA has a
backdoor as is the case for DualEC.  However, the whole NIST design
process is tainted.  So my understanding is that it’s really a gray
area.

> Except for the different nature of the evidence of vulnerability, it
> seems about the same situation to me. As such, I don't think we should
> support them (some nice error messages like 'This algorithm [...] is
> not supported yet’ or ‘This algorithm [...] is (likely/known to be)
> vulnerable’ would be good though!).

Yes, that we can improve.  :-)

> An alternative option would be to allow the channel
> .guix-authorization (of the previous commits, not the commit that is
> about to be verified!) to decide what's considered a 'good algorithm'
> (with some defaults) (with a field). Maybe we'll have to deprecate,
> say, RSA or SHA-3 eventually, it would be nice to have a migration
> method in place as early as possible, to minimise the risk of some
> people doing a "guix pull" from a Guix that does not support that
> field to a Guix or other channel that _does_ use that field.

It’s tempting, but I’d rather avoid introducing such mechanisms to keep
things as simple as possible.

Thanks,
Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Maxime Devos]

On 06-09-2022 13:58, Ludovic Courtès wrote:

Hi,

ECDSA and the NIST curves (and in fact a large part of NIST’s crypto
standardization work¹) are actually considered with skepticism by some:

   
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Concerns

That makes me wonder whether supporting them is a good idea, after all.
Evidently they’re not widely used in OpenPGP and not supporting them
hasn’t been much of a problem, it seems.  On one hand, we don’t want
Guix’s OpenPGP implementation to limit what users do with their OpenPGP
keys; on the other hand, we don’t want to encourage algorithms that
bring little to the table at best and are suspicious at worst.

What do people think?


We disallow signing with SHA-1, because it is known to be vulnerable and 
as there are alternatives that are considered good, even if this limits 
what users can do with their OpenPGP keys.


In case of those curves, I'm not aware of any 'crytopgraphic proof' (*) 
that the curves are vulnerable (unlike for SHA-1), but as noted in ¹ and 
elsewhere, there are other kinds of evidence that something is wrong.


Except for the different nature of the evidence of vulnerability, it 
seems about the same situation to me. As such, I don't think we should 
support them (some nice error messages like 'This algorithm [...] is not 
supported yet’ or ‘This algorithm [...] is (likely/known to be) 
vulnerable’ would be good though!).


(*) I mean proof, like in mathematical proofs, not merely evidence.

An alternative option would be to allow the channel .guix-authorization 
(of the previous commits, not the commit that is about to be verified!) 
to decide what's considered a 'good algorithm' (with some defaults) 
(with a field). Maybe we'll have to deprecate, say, RSA or SHA-3 
eventually, it would be nice to have a migration method in place as 
early as possible, to minimise the risk of some people doing a "guix 
pull" from a Guix that does not support that field to a Guix or other 
channel that _does_ use that field.


Zhu Zihao wrote:


My opinion: Maybe NSA recommend NIST family because they know how to get
around it.
If so, I believe this is an argument against allowing these curves, to 
avoid a method NSA could use for attacks.

But they also have to believe foreign government can't break
it easily.
For people outside the US, the US (of which the NSA is an agency) _is_ a 
foreign government. As Guix is not an US-specific project, I do not 
think this is an argument for allowing the curves.


Greetings,
Maxime.

Ludo’.

¹ https://blog.cr.yp.to/20220805-nsa.html




OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Zhu Zihao]

My opinion: Maybe NSA recommend NIST family because they know how to get
around it. But they also have to believe foreign government can't break
it easily.

-- 
Retrieve my PGP public key:

  gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744

Zihao

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Thompson, David]

On Mon, Sep 5, 2022 at 5:33 AM zimoun  wrote:
>
> > I also pushed a follow-up commit
> > e4ccfcb22ad96e71ca4dfad95af5aa6229ed9869 that swaps out 'git' for
> > 'git-minimal', saving about 75MiB in the package closure.
>
> Neat!

Unfortunately, it was so neat that it broke the system test for the
gitolite service so I had to revert it.

- Dave

bug#57559: guix pull fails on http status code 503

[zimoun]

Hi Maxime,

On Mon, 05 Sep 2022 at 22:20, Maxime Devos  wrote:
> On 05-09-2022 10:21, zimoun wrote:
>> On sam., 03 sept. 2022 at 19:27, Maxime Devos  wrote:
>>
>>>* if some but not all channels are available, and there is at least
>>>  one updated channel --> log the missing channels, and update the
>>>  channels that_are_  available (but don't 'ignore' the missing
>>>  channels by removing them!).
>> What do you mean by «but don't 'ignore' the missing channels by removing
>> them!»?  Do you mean keep the last revision locally known for this
>> channel?
>
> I'm not sure what you're asking, because of the negatives.

[...]

> (It's not unlike double negatives! I first thought of the latter 
> interpretation but on second thought you might have meant the former.)

IIUC, you have hard time to parse the double-negative you wrote earlier
in this thread. :-)



> With "but don't ignore [...] by [...]", I meant that, yes.
>
> If you meant "don't ignore [...] by [...]", then no, with 'ignoring by 
> removing', I meant, literally removing them.  More concretely, a 
> situation like this:
>
>   * In the channels.scm, two channels are declared: guix and guix-foo.
>   * User does "guix pull"; Guix downloads the source code of guix and
> guix-foo.
>   * Downloading guix failed (503).  As such, Guix decided to ignore the
> guix channel, by removing it from the list of channels to build.
> (The in-memory list I mean, I don't mean modifying the channels.smc
> file)
>   * Guix tries building the guix-foo channel and installing it, without
> the guix channel.
>   * This cannot work (the guix-foo channel uses modules from guix for
> basic stuff like G-exps, packages, coreutils, ..., and it was the
> removed guix channel that had things build-aux/build-self.scm which
> is required for pulling).

The initial report by André is about:

--8<---cut here---start->8---
$ guix pull
Updating channel 'nonguix' from Git repository at 
'https://gitlab.com/nonguix/nonguix'...
guix pull: error: Git error: unexpected http status code: 503
--8<---cut here---end--->8---

So the situation is more likely: Guix from Savannah is reachable and
guix-foo is not.

For sure, we can discuss the case when Guix is unavailable.  However,
the 'guix channel is special; see all conditionals using ’guix-channel?’.  

Well, %default-guix-channel is somehow a corner use-case when the
regular use-case seems about a failure of additional channels.


Cheers,
simon

bug#57083: Closing

[Ségolène Métais]

bug#57611: rust-once-cell (alacritty dependency) build failure

[bdju]

Looks like alacritty can't be built because rust-wayland-commons and 
rust-wayland-client can't be built because rust-once-cell can't be built.

rust-once-cell build log: http://sprunge.us/8t8VaQ

p.s. my guix --version output still shows guix (GNU Guix) 0

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi,

ECDSA and the NIST curves (and in fact a large part of NIST’s crypto
standardization work¹) are actually considered with skepticism by some:

  
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Concerns

That makes me wonder whether supporting them is a good idea, after all.
Evidently they’re not widely used in OpenPGP and not supporting them
hasn’t been much of a problem, it seems.  On one hand, we don’t want
Guix’s OpenPGP implementation to limit what users do with their OpenPGP
keys; on the other hand, we don’t want to encourage algorithms that
bring little to the table at best and are suspicious at worst.

What do people think?

Ludo’.

¹ https://blog.cr.yp.to/20220805-nsa.html

bug#57116: cling: missing some system header files

[Maxim Cournoyer]

Hi,

Maxime Devos  writes:

> On 03-09-2022 11:43, zimoun wrote:
>> Hi,
>>
>> On Sat, 03 Sep 2022 at 00:25, Maxim Cournoyer  
>> wrote:
>>
>>> Should we close it as 'notabug', or persist with the attempt to wrap the
>>> cling binary with the include paths required to ease its setup?
>>  From my understanding about what cling is, we have a similar issue with
>> some others packages.  Bigloo does not work out of the box [1]:
>>
>> --8<---cut here---start->8---
>> $ guix shell -C bigloo libunistring gcc-toolchain libgc pcre \
>>   -- bigloo /tmp/myfile.scm
>> --8<---cut here---end--->8---
>>
>> Idem for ghc (Haskell) which requires gcc-toolchain.  And I proposed [2]
>> to have -toolchain for a ready-to-use X compiling toolsuite where
>> could be cling, ghc, bigloo, etc.
>>
>> For instance, Debian has haskell-platform which includes all a regular
>> user needs for a regular Haskell development setup.  And we already
>> provide gcc-toolchain or clang-toolchain, or even gfortan-toolcahin,
>> gdc-toolchain, piet-toolchain, etc.  Therefore, we could also have
>> the package cling-toolchain propagating all the required packages that
>> we currently have to manually specify i.e. gcc-toolchain.
>>
>> WDYT?
>>
>>
>> 1: https://yhetil.org/guix/878rp3bs1a@gmail.com
>> 2: 
>> https://yhetil.org/guix/caj3okz0i0djqmzgj9wwzdc2tkc8wetzxqw46kh+vq9zkbgb...@mail.gmail.com
>
> I do not see any problems with a X-toolchain (with X=cling,ghc,bigloo,
> ...) and they appear to be convenient.
>
> I'd say, go for it.

In the case of cling, I'm not sure if that'd be adapted to the use case
(you don't really use cling as a toolchain, but as a REPL to try things
interactively), but otherwise I don't see any cons to being able to do
that.

Thanks,

Maxim

bug#57589: Guix hands on GDM with wayland

[Grigory Shepelev]

Creating new user didn't helped.

I created new user (did this Guix way, via adding to config and 
reconfiguring the system) and logged it as a new user. Still X11 system 
displays with `xrandr`, and `echo $XDG_SESSION_TYPE`. I don't think 
there is a need to try moving all home files, creating new user should 
be enough to test provided option.


Although I noticed a gear icon below in the right of the gdm screen when 
logging in as a default user (saw that in Ubuntu) with options "GNOME" 
or "GNOME on Xorg". Trying to login in "GNOME" (Wayland supposedly) 
gives a black screen for ~2s.  After couple attempts logged back into 
"GNOME on Xorg".


Attached logs again. They says something about DBUS. Any ideas?

---

(gsd-keyboard:5189): dbind-WARNING **: 13:35:36.273: AT-SPI: Error 
retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files
(gsd-xsettings:5219): dbind-WARNING **: 13:35:36.476: AT-SPI: Error 
retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files

GNOME Shell-Message: 13:35:36.777: Registering session with GDM
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:  Unsupported maximum keycode 708, clipping.
>   X11 cannot support keycodes above 255.
Errors from xkbcomp are not fatal to the X server
(gnome-shell:5099): mutter-WARNING **: 13:36:02.454: Connection to 
xwayland lost

---

On 05.09.2022 20:55, Grigory Shepelev wrote:

Had some info from Guix Matrix channel:
> GDM does wayland too with the option set to #t. I was able to get it 
to work going back from sddm, but I had to remove the home folder and 
recreate it from scratch, since gnome session was crashing on login. I 
had no problem starting gnome on a new account so i figured something 
was hanging around that cause a problem even after deleting all caches 
and configs etc.

> By “home folder” I mean my user’s directory /home/use

https://matrix.to/#/!jivGmMiiorFwdgwaxc:matrix.org/$W4HJQCzv8G0aHM3_PAFrtUaj6Q3aS18vMZCwlMch71I?via=matrix.org=hummingbard.com=privacytools.io 
 



Most likely will try for new user tomorrow

пн, 5 сент. 2022 г., 16:24 Grigory Shepelev :

   Oops. I accidentally replied privately to d...@jpoiret.xyz, not
   mentioning 57...@debbugs.gnu.org. I hope the history can be recovered
   from this message.

   Josselin recommended to

   - check permissions on /tmp/.X11-unix/ (gdm user should have r+w
   permissions)

     shegeley@zone51 /tmp$ ls -lah .X11-unix/
     total 0
     drwxrwxrwt 2 gdm  gdm    80 сен  5 16:12 ./
     drwxrwxrwt 6 root root  160 сен  5 16:16 ../
     srwxrwxrwx 1 shegeley users   0 сен  5 16:12 X1
     srwxr-xr-x 1 gdm  gdm 0 сен  5 16:12 X1024

   -  check /var/lib/gdm/, doesn't have the proper permissions

        Hm. That's really strange. For some reason /var/lib/gdm had
        "transmission" as user-group. I assure you that I didn't 
explicitly

        do any "dirty stuff" like that permission changing in my config


        shegeley@zone51 /tmp$ sudo ls -lah /var/lib/gdm
        total 0
        drwx-- 1 gdm  gdm   38 авг 26 21:46 .
        drwxr-xr-x 1 root root 248 авг 28 18:37 ..
        drwxr-xr-x 1  973 transmission  62 авг 26 21:46 .cache
        drwx-- 1  973 transmission  44 авг 26 21:46 .config
        drwx-- 1  973 transmission  10 авг 26 21:46 .local
        shegeley@zone51 /tmp$ sudo chown -R gdm:gdm /var/lib/gdm
        shegeley@zone51 /tmp$ sudo ls -lah /var/lib/gdm
        total 0
        drwx-- 1 gdm  gdm   38 авг 26 21:46 .
        drwxr-xr-x 1 root root 248 авг 28 18:37 ..
        drwxr-xr-x 1 gdm  gdm   62 авг 26 21:46 .cache
        drwx-- 1 gdm  gdm   44 авг 26 21:46 .config
        drwx-- 1 gdm  gdm   10 авг 26 21:46 .local


   After changing it was able to launch into GDM, but with X11 as display
   manager :( Attached new logs.


   On 05.09.2022 10:23, Josselin Poiret wrote:
    > Hi again,
    >
    > Grigory Shepelev writes:
    >
    >> My config is heavily depends on it's directory (passing it with
    >> --load-path). I can (and will) publish it all (I've been
   planning to do
    >> so) but I'd like to polish few parts.
    >>
    >> Any exact part are you looking for in config?  I attached my
   system-wide
    >> services.
    > I asked for that partly because it helps identifying common
   errors, and
    > it's always better for people debugging to have access to all the
    > information, and partly because I couldn't see anything that
   could help
    > in the logs.  However, it seems mutter can't write into
   /tmp/.X11-unix/,
    > could you check that the gdm user has the permission to write
   there?  It
    > 

bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Maxime Devos]

On 06-09-2022 09:18, Ludovic Courtès wrote:

"guix shell" is for making packages available in the
environment. Currently, "guix shell -- foobar" does not make any
packages available -- it's effectively a no-op except for setting
GUIX_ENVIRONMENT.

True, though you could always have scripts that read:

   guix shell $packages -- whatever

and that will suddenly behave differently if $packages expands to an
empty string.  Tricky!


Right, I didn't think of such uses.

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Thompson, David]

bug#57083: Fwd: Jekyll is unusable

[Ségolène Métais]

(I send this message again because it does not appear in the archive).

Hello,

Thank you Remco for your help. I was able to run jekyll without and with
bundle using your instructions.

I am not sure what should be done with the package.

To use Jekyll with bundle, here are the details in case someone would get
stucked:
sego@pluto ~/job/site/www$ guix shell jekyll ruby -D ruby
sego@pluto ~/job/site/www [env]$ jekyll new tmpdir
Running bundle install in /home/sego/job/site/www/tmpdir...
New jekyll site installed in /home/sego/job/site/www/tmpdir.
sego@pluto ~/job/site/www [env]$ cd tmpdir/
sego@pluto ~/job/site/www/tmpdir [env]$ bundle add webrick
sego@pluto ~/job/site/www/tmpdir [env]$ bundle exec jekyll serve
[...]
Server address: http://127.0.0.1:4000/
Server running... press ctrl-c to stop.

Cheers,
Ségolène

Le lun. 15 août 2022 à 12:51, Remco van 't Veer  a
écrit :
>
> The jekyll packages is pretty minimal and the generated site by a
> "jekyll new" requires more than supplied by the package.  To get it to
> work you either need to include the ruby package for bundler (as you
> did), set GEM_HOME to some writable directory, and pull in the
>
> development dependencies of ruby (to allow compilation of native code
> gems).  Or stay minimal, here's an example:
>
>   $ guix shell --pure jekyll -- jekyll new --skip-bundle testdir
>   New jekyll site installed in /home/me/tmp/testdir.
>   Bundle install skipped.
>   $ echo title: test title > testdir/_config.yml # drop theme and plugins
>   $ rm testdir/Gemfile # avoid bundler installing themes and plugins
>   $ echo test content >> testdir/index.markdown
>   $ guix shell --pure jekyll -- jekyll s --source=testdir
>   Configuration file: /home/me/tmp/testdir/_config.yml
>   Source: /home/me/tmp/testdir
>  Destination: /home/me/tmp/_site
>Incremental build: disabled. Enable with --incremental
> Generating...
>Build Warning: Layout 'post' requested in
_posts/2022-08-15-welcome-to-jekyll.markdown does not exist.
>Build Warning: Layout 'default' requested in 404.html does not
exist.
>Build Warning: Layout 'page' requested in about.markdown does not
exist.
>Build Warning: Layout 'home' requested in index.markdown does not
exist.
>   done in 0.156 seconds.
>Auto-regeneration: enabled for 'testdir'
>   Server address: http://127.0.0.1:4000
> Server running... press ctrl-c to stop.
>
> I am not sure this is an issue because it does work for the minimal
> approach.  Unfortunately it does not really operate as expected.  Maybe
> the package should be altered to generate a minimal setup as in the
> above example on "jekyll new"?
>
> Cheers,
> Remco

bug#57596: guix lint --checkers=derivation doesn't complete, Too many heap sections

[Christopher Baines]

Christopher Baines  writes:

> When running the derivation checker on all packages for recent guix
> revisions, it dones't seem to complete. Instead, you get an error which
> I think comes from the garbage collection implementation that Guile
> uses:
>
>   → guix lint --checkers=derivation
>   Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
>   Aborted
>
> I noticed this on data.guix.gnu.org, as it effectively does something
> similar when trying to record the lint warnings for a revision.
>
> Maybe there's enough derivations now that the process of computing them
> all is too much for Guile? Or maybe it's something in the graph that's
> forming a loop?

I've got a bit more information now, I'm guessing the changes in [1]
just tipped the balance as that's when the data service instances
started not being able to process revisions.

1: 
https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=aae98c297214f87eb45302863adb021078c41a6f...d22a5c18517d662516fc93889534367fd3a448f2

I think I've managed to work around this now in the data service [2],
but the problem still remains when running the linter through the
script.

2: 
http://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=b3d59c650a45429f90953e8fd865a3ba76a891cf


signature.asc
Description: PGP signature

bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Ludovic Courtès]

Maxime Devos  skribis:

> On 05-09-2022 15:06, Ludovic Courtès wrote:
>> The main difficulty here is that, should we eventually decide to change
>> behaviors, we’ll have to devise a migration timeline etc.  (As an
>> example, we chose to keep ‘guix environment’ until at least May 2023;
>> all this must take time if we want to avoid breaking user workflows.)
>>
>> Thoughts?
>
> "guix shell" is for making packages available in the
> environment. Currently, "guix shell -- foobar" does not make any
> packages available -- it's effectively a no-op except for setting
> GUIX_ENVIRONMENT.

True, though you could always have scripts that read:

  guix shell $packages -- whatever

and that will suddenly behave differently if $packages expands to an
empty string.  Tricky!

Ludo’.