Reducing "You found a bug" reports

[Ian Eure]

There’s a steady number of bug reports generated by the "You found 
a bug" message which happens during `guix pull's.  The 
overwhelming majority of these reports are caused by networking 
problems or the Guix infrastructure being unreliable or 
overloaded.  Many of these were submitted during the recent 
guix.gnu.org downtime.


Some of these that I see:

55066
62023
62830
61520
58309

...I’m sure there are many more.

Is there some way for this code to be smarter about when it prints 
the "report a bug" message, so it doesn’t tell users to report 
bugs when none exist?  Is there a way for it to notice that the 
problem is related to networking, and tell the users to try again 
in a little while?  Is it worth removing the "report a bug" 
message entirely?


It doesn’t feel great to tell users to report a bug for things 
that aren’t bugs.  They’re either closed, or never followed up on; 
it’s a poor experience on both ends.


Thanks,

 — Ian

Re: Changing the defaults for --localstatedir and --sysconfdir?

[Maxim Cournoyer]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  writes:

> Hi everyone,
>
> On Thu, May 02 2024, Efraim Flashner wrote:
>
>> changing the defaults to use /var and /etc by default would be a good
>> change.
>
> If that's too complicated, someone could alternatively add
>
> ./configure --localstatedir=/var --sysconfdir=/etc
>
> to ./bootstrap.

In case someone missed it, the above is now the default (/var and /etc),
since commit 1036f0970083c146b709d792d128f4235125 ("configure.ac:
Set default value for the 'prefix' variable.").

You can thus finally forget to use --localstatedir=/var
--sysconfdir=/etc when running the configure script.

-- 
Thanks,
Maxim

Did something with format-patch or send-email break?

[Ian Eure]

I’m not sure of the precise mechanism employed, but I believe that 
that in the past, if I ran `git format-patch' and `git 
send-email', it would send an email to the right place.  This is 
implied by the manual, which doesn’t mention a patch submission 
email address, except for an issue number address when sending a 
patch series.


This doesn’t seem to work anymore; the output of `git 
format-patch' has no To: header populated, so `git send-email' 
asks me where:


   meson!ieure:~/Projects/guix/staging$ guix describe
   Generation 13Jun 08 2024 17:39:39(current)
 atomized 6bb138d
   repository URL: 
   https://codeberg.org/ieure/atomized-guix.git

   branch: main
   commit: 6bb138db5b7f56f399c9cb2e0b45fecaa8cd0182
 guix bc8a41f
   repository URL: https://git.savannah.gnu.org/git/guix.git
   branch: master
   commit: bc8a41f4a8d9f1f0525d7bc97c67ed3c8aea3111
   meson!ieure:~/Projects/guix/staging$ git log --oneline 
   HEAD^..HEAD
   bc8a41f4a8 (HEAD -> master, upstream/master) gnu: mes: Update 
   to 0.26.1.
   meson!ieure:~/Projects/guix/staging$ echo "changes" >> 
   gnu/packages/python-xyz.scm && git ci -am "changes"

   [master 88e3f97240] changes
1 file changed, 2 insertions(+)
   meson!ieure:~/Projects/guix/staging$ git format-patch -1
   0001-changes.patch
   meson!ieure:~/Projects/guix/staging$ git send-email 
   0001-changes.patch

   0001-changes.patch
   To whom should the emails be sent (if anyone)?   C-c C-c

   meson!ieure:~/Projects/guix/staging$

Reproduced on Guix System, Guix on Debian (which the above output 
is from), and someone in #guix also reproduced it.


Is it broken?  Am I missing one of the numerous intricate fiddly 
bits of setup to make email patch flow work?  The manual’s "The 
Perfect Setup" section only mentions Geiser and yasnippet setup, 
which isn’t relevant to this.


Thanks,

 — Ian

Re: CLISP test failures on ‘core-updates’

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Maybe the CI just had a hiccup... I restarted the build, maybe it will
> be enough.

It looks like it worked.


signature.asc
Description: PGP signature

Re: CLISP test failures on ‘core-updates’

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Hello Lisp team! :-)
>
> The ‘clisp’ package has a few test failures on ‘core-updates’
> (x86_64-linux):
>
> --8<---cut here---start->8---
> finished  57 files:   6 errors out of  11,960 tests
>   1   alltest:0 errors out of 636 tests
>   2 array:0 errors out of 290 tests
>   3  backquot:0 errors out of  89 tests
>   4bin-io:0 errors out of  15 tests
>   5characters:0 errors out of 221 tests
>   6  clos:0 errors out of 496 tests
>   7   defhash:0 errors out of   6 tests
>   8  encoding:0 errors out of  36 tests
>   9eval20:0 errors out of  50 tests
>  10 ext-clisp:1 error out of  118 tests
>  11   ffi:0 errors out of 263 tests
>  12floeps:0 errors out of  20 tests
>  13format:0 errors out of 307 tests
>  14 genstream:0 errors out of  14 tests
>  15  hash:0 errors out of  48 tests
>  16  hashlong:0 errors out of  14 tests
>  17 hashtable:0 errors out of  10 tests
>  18iofkts:0 errors out of 228 tests
>  19lambda:0 errors out of  90 tests
>  20  lists151:0 errors out of 201 tests
>  21  lists152:0 errors out of 255 tests
>  22  lists153:0 errors out of   1 test
>  23  lists154:0 errors out of  46 tests
>  24  lists155:0 errors out of  25 tests
>  25  lists156:0 errors out of  20 tests
>  26  list-set:0 errors out of  10 tests
>  27  loop:0 errors out of 151 tests
>  28macro8:0 errors out of 253 tests
>  29   map:0 errors out of  64 tests
>  30   mop:0 errors out of 225 tests
>  31number:0 errors out of   3,655 tests
>  32   number2:0 errors out of 331 tests
>  33pack11:0 errors out of 211 tests
>  34  path:0 errors out of 179 tests
>  35 readtable:0 errors out of  27 tests
>  36  setf:0 errors out of 197 tests
>  37socket:0 errors out of  92 tests
>  38   steele7:0 errors out of  86 tests
>  39   streams:2 errors out of 388 tests
>  40   streamslong:1 error out of   25 tests
>  41   strings:0 errors out of 409 tests
>  42  symbol10:0 errors out of 152 tests
>  43   symbols:0 errors out of   6 tests
>  44  time:0 errors out of  22 tests
>  45 tread:0 errors out of 395 tests
>  46  type:0 errors out of 289 tests
>  47unportable:0 errors out of  31 tests
>  48mt:2 errors out of 102 tests
>  49  weak:0 errors out of 120 tests
>  50  weakhash:0 errors out of  26 tests
>  51 weakhash2:0 errors out of  47 tests
>  52 bind-eval:0 errors out of  72 tests
>  53  bind-compile:0 errors out of  72 tests
>  54conditions:0 errors out of  98 tests
>  55  restarts:0 errors out of  71 tests
>  56  excepsit:0 errors out of 395 tests
>  57   weakptr:0 errors out of 260 tests
> Real time: 68.01543 sec.
> Run time: 59.912647 sec.
> Space: 1416624568 Bytes
> GC: 1241, GC time: 13.156419 sec.
> 6
> Bye.
> make[2]: Leaving directory 
> '/tmp/guix-build-clisp-2.49-92.drv-0/source/src/tests'
> --8<---cut here---end--->8---
>
> (From .)
>
> I reported it upstream but there seems to be relatively little activity:
>
>   https://gitlab.com/gnu-clisp/clisp/-/issues/51
>
> Ideas on how to investigate/fix/work around?  This is blocking basically
> all things Common Lisp on ‘core-updates’.
>
> Ludo’.

Hi.
I just tried building CLISP a few times on x86-64, and I also see a few
errors in the test report (although not exactly the same number as in
the log on the CI), but they don't make the build fail.

I think the real issue the CI got is:
--8<---cut here---start->8---
building of `/gnu/store/8dp91kjmlw0n6knvzpw2glsmvh9vw47r-cli

CLISP test failures on ‘core-updates’

[Ludovic Courtès]

Hello Lisp team! :-)

The ‘clisp’ package has a few test failures on ‘core-updates’
(x86_64-linux):

--8<---cut here---start->8---
finished  57 files:   6 errors out of  11,960 tests
  1   alltest:0 errors out of 636 tests
  2 array:0 errors out of 290 tests
  3  backquot:0 errors out of  89 tests
  4bin-io:0 errors out of  15 tests
  5characters:0 errors out of 221 tests
  6  clos:0 errors out of 496 tests
  7   defhash:0 errors out of   6 tests
  8  encoding:0 errors out of  36 tests
  9eval20:0 errors out of  50 tests
 10 ext-clisp:1 error out of  118 tests
 11   ffi:0 errors out of 263 tests
 12floeps:0 errors out of  20 tests
 13format:0 errors out of 307 tests
 14 genstream:0 errors out of  14 tests
 15  hash:0 errors out of  48 tests
 16  hashlong:0 errors out of  14 tests
 17 hashtable:0 errors out of  10 tests
 18iofkts:0 errors out of 228 tests
 19lambda:0 errors out of  90 tests
 20  lists151:0 errors out of 201 tests
 21  lists152:0 errors out of 255 tests
 22  lists153:0 errors out of   1 test
 23  lists154:0 errors out of  46 tests
 24  lists155:0 errors out of  25 tests
 25  lists156:0 errors out of  20 tests
 26  list-set:0 errors out of  10 tests
 27  loop:0 errors out of 151 tests
 28macro8:0 errors out of 253 tests
 29   map:0 errors out of  64 tests
 30   mop:0 errors out of 225 tests
 31number:0 errors out of   3,655 tests
 32   number2:0 errors out of 331 tests
 33pack11:0 errors out of 211 tests
 34  path:0 errors out of 179 tests
 35 readtable:0 errors out of  27 tests
 36  setf:0 errors out of 197 tests
 37socket:0 errors out of  92 tests
 38   steele7:0 errors out of  86 tests
 39   streams:2 errors out of 388 tests
 40   streamslong:1 error out of   25 tests
 41   strings:0 errors out of 409 tests
 42  symbol10:0 errors out of 152 tests
 43   symbols:0 errors out of   6 tests
 44  time:0 errors out of  22 tests
 45 tread:0 errors out of 395 tests
 46  type:0 errors out of 289 tests
 47unportable:0 errors out of  31 tests
 48mt:2 errors out of 102 tests
 49  weak:0 errors out of 120 tests
 50  weakhash:0 errors out of  26 tests
 51 weakhash2:0 errors out of  47 tests
 52 bind-eval:0 errors out of  72 tests
 53  bind-compile:0 errors out of  72 tests
 54conditions:0 errors out of  98 tests
 55  restarts:0 errors out of  71 tests
 56  excepsit:0 errors out of 395 tests
 57   weakptr:0 errors out of 260 tests
Real time: 68.01543 sec.
Run time: 59.912647 sec.
Space: 1416624568 Bytes
GC: 1241, GC time: 13.156419 sec.
6
Bye.
make[2]: Leaving directory 
'/tmp/guix-build-clisp-2.49-92.drv-0/source/src/tests'
--8<---cut here---end--->8---

(From .)

I reported it upstream but there seems to be relatively little activity:

  https://gitlab.com/gnu-clisp/clisp/-/issues/51

Ideas on how to investigate/fix/work around?  This is blocking basically
all things Common Lisp on ‘core-updates’.

Ludo’.

Re: GNU Mes 0.26.1 released

[Wilko Meyer]

Janneke Nieuwenhuizen  writes:
> Thanks to everyone who contributed to this release:
>
>   Andrius Štikonas (7)
>   Ekaitz Zarraga (15)
>   Janneke Nieuwenhuizen (29)
>   Michael Forney (4)
>   Timothy Sample (2)

Congratulations to the release & thanks to everyone who has worked on
this!

-- 
Kind regards,

Wilko Meyer
w...@wmeyer.eu