Re: Release progress, week 3

2022-11-16 Thread Andreas Enge
Am Tue, Nov 15, 2022 at 03:48:26PM -0500 schrieb Maxim Cournoyer:
> It'll have to go to core-updates.  The release will be cut from current
> master.

Okay, thanks, I will push it to core-updates when it comes out.

Andreas




Re: Release progress, week 3

2022-11-15 Thread Maxim Cournoyer
Hi,

Andreas Enge  writes:

> Hello,
>
> mpfr-4.1.1 is expected to be released tomorrow:
>https://sympa.inria.fr/sympa/arc/mpfr/2022-11/msg0.html
>
> I do not expect there to be any breakage (this is a bugfix release),
> but adding it would require to recompile everything.
>
> Is this feasible before the release? Or should we do it on a core-updates
> branch? Or simply postpone it till after the release?

It'll have to go to core-updates.  The release will be cut from current
master.

-- 
Thanks,
Maxim



Re: Release progress, week 3

2022-11-07 Thread Andreas Enge
Hello,

mpfr-4.1.1 is expected to be released tomorrow:
   https://sympa.inria.fr/sympa/arc/mpfr/2022-11/msg0.html

I do not expect there to be any breakage (this is a bugfix release),
but adding it would require to recompile everything.

Is this feasible before the release? Or should we do it on a core-updates
branch? Or simply postpone it till after the release?

Andreas




Re: Release progress, week 3

2022-11-07 Thread Ludovic Courtès
Hi,

Efraim Flashner  skribis:

> If you want to add a bit more to the mix you can add riscv64-linux and
> powerpc-linux as build targets.

We don’t have hardware in the build farms for these two, so that’s
future work.

Ludo’.



Re: Release progress, week 3

2022-11-06 Thread Efraim Flashner
On Thu, Oct 27, 2022 at 10:04:13AM -0700, Vagrant Cascadian wrote:
> On 2022-10-27, Ludovic Courtès wrote:
> > Release progress: week 3.
> ...
> >   • Architectures:
> >
> >  - powerpc64le-linux builds are back behind ci.guix, thanks to
> >Tobias!
> ...
> >  - armhf-linux: No progress so far.
> 
> Not sure where this fits into the release process, but I uploaded a git
> snapshot to Debian of guix from commit
> c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 ... ppc64le still has not built
> yet, and it has the same test suite failures on two 32-bit architectures
> (i386 and armhf):
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=guix&arch=armhf&ver=1.3.0%2B26756.c07b5-1&stamp=1666838910&raw=0
>   
> https://buildd.debian.org/status/fetch.php?pkg=guix&arch=i386&ver=1.3.0%2B26756.c07b5-1&stamp=1666825176&raw=0
> 
> 
> Testsuite summary for GNU Guix 1.3.0.26756-c07b5
> 
> # TOTAL: 2286
> # PASS:  2002
> # SKIP:  274
> # XFAIL: 4
> # FAIL:  6
> # XPASS: 0
> # ERROR: 0
> 
> 
> All 6 of the failures have the same error:
> 
> test-name: channel-news, no news
> ...
> actual-error:
> + (git-error
> +   #< code: -1 message: "invalid version 0 on git_proxy_options" 
> class: 3>)
> result: FAIL
> 
> 
> Would love to figure out these issues in time for release!
> 
> 
> Good news is it built reproducibly (at least on amd64; i386, armhf and
> arm64 pending):
> 
>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/guix.html
> 
> This is partly because the Debian package works around
> https://issues.guix.gnu.org/20272 by disabling parallelism in the
> build. Sure would be nice if guix was reproducible when built with Guix
> too!

If you want to add a bit more to the mix you can add riscv64-linux and
powerpc-linux as build targets. I'm not sure if they'll pass the test
suite though, I don't think they technically have support in the base
linux-libre package since it expects a kernel config and they only
really have their own specialized kernels for now.


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


test suite/ABI issues building guix on Debian (was Re: Release progress, week 3)

2022-11-04 Thread Vagrant Cascadian
On 2022-11-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
 test-name: channel-news, no news
 ...
 actual-error:
 + (git-error
 +   #< code: -1 message: "invalid version 0 on 
 git_proxy_options" class: 3>)
 result: FAIL
>>>
>>> This looks like an ABI issue with libgit2.  Are you sure the same
>>> version of libgit2 is used on all these platforms?

Well, rebuilding guix with a freshly built guile-git (against the newer
libgit2) seemed to resolve the issue on at least one build, so will
update in Debian and see if that helps in general...


>> My quick and rough archeaology shows that libgit2-dev
>> 1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
>> libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.
>
> [...]
>
>> Maybe there is a better way I can track the various guile-* packages in
>> Debian, but manually tracking all the relevent dependents seems
>> implausible (or at least, a lot of work)... which may lead to the
>> conclusion that maintaining Guix in Debian implausible. :/
>
> I don’t see how that’s specific to guile-* packages though.  Anytime a
> dependency is upgraded that introduces a different ABI, you need to
> rebuild dependents, right?  That’s what’s happening here.

Well, sure. I just have not personally maintained many packages that
need to worry about those kinds of headaches too much... Debian still
requires manual intervention to handle it in some form and lacks the
elegance of guix in this regard. :)


>> Seems like the most likely ones I would have to keep a close eye on are
>> guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
>> this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
>> guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
>> which adds another set of packages. Wheee. Hrm.
>
> Heh.  Speaking of which, guile-gnutls is now a thing of its own,
> separate from GnuTLS:
>
>   https://gitlab.com/gnutls/guile/
>
> I believe Andreas Metzler already update Debian’s guile-gnutls package
> accordingly.

Oh wow, it is already in debian experimental. :)

Will have to try building guix with it, now... and mentally prepare for
the possibility of more test-suite failure wrangling.


live well,
  vagrant


signature.asc
Description: PGP signature


Re: Release progress, week 3

2022-11-03 Thread Ludovic Courtès
Hi,

Vagrant Cascadian  skribis:

>>> test-name: channel-news, no news
>>> ...
>>> actual-error:
>>> + (git-error
>>> +   #< code: -1 message: "invalid version 0 on 
>>> git_proxy_options" class: 3>)
>>> result: FAIL
>>
>> This looks like an ABI issue with libgit2.  Are you sure the same
>> version of libgit2 is used on all these platforms?
>
> My quick and rough archeaology shows that libgit2-dev
> 1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
> libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.

[...]

> Maybe there is a better way I can track the various guile-* packages in
> Debian, but manually tracking all the relevent dependents seems
> implausible (or at least, a lot of work)... which may lead to the
> conclusion that maintaining Guix in Debian implausible. :/

I don’t see how that’s specific to guile-* packages though.  Anytime a
dependency is upgraded that introduces a different ABI, you need to
rebuild dependents, right?  That’s what’s happening here.

> Seems like the most likely ones I would have to keep a close eye on are
> guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
> this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
> guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
> which adds another set of packages. Wheee. Hrm.

Heh.  Speaking of which, guile-gnutls is now a thing of its own,
separate from GnuTLS:

  https://gitlab.com/gnutls/guile/

I believe Andreas Metzler already update Debian’s guile-gnutls package
accordingly.

Thanks,
Ludo’.



Re: Release progress, week 3

2022-11-02 Thread Vagrant Cascadian
On 2022-11-02, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> On 2022-10-27, Ludovic Courtès wrote:
>>> Release progress: week 3.
>> ...
>>>   • Architectures:
>>>
>>>  - powerpc64le-linux builds are back behind ci.guix, thanks to
>>>Tobias!
>> ...
>>>  - armhf-linux: No progress so far.
>>
>> Not sure where this fits into the release process, but I uploaded a git
>> snapshot to Debian of guix from commit
>> c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 ...
>
> Yay, thanks!
>
>> All 6 of the failures have the same error:
>>
>> test-name: channel-news, no news
>> ...
>> actual-error:
>> + (git-error
>> +   #< code: -1 message: "invalid version 0 on git_proxy_options" 
>> class: 3>)
>> result: FAIL
>
> This looks like an ABI issue with libgit2.  Are you sure the same
> version of libgit2 is used on all these platforms?

My quick and rough archeaology shows that libgit2-dev
1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.

Though, curiously, it looks like the amd64 and arm64 packages built
"fine" with these same versions... while i386 and armhf triggered these
issues. Maybe there was some 32-bit specific difference in the newer
libgit2 versions...


Lacking the property of guix where dependency chain changes trigger
package rebuilds... this has to be done manually on Debian when it
matters (e.g. ABI changes)...


Maybe there is a better way I can track the various guile-* packages in
Debian, but manually tracking all the relevent dependents seems
implausible (or at least, a lot of work)... which may lead to the
conclusion that maintaining Guix in Debian implausible. :/


For this specific set of tests, I can rebuild guile-git against the
current libgit2 and then try building guix again ... maybe that will
help.

Though long-term, that means any time one of guix's dependencies (at
least with C library dependencies?) changes in Debian, I'll also have to
rebuild guix in Debian as well... I think.

Seems like the most likely ones I would have to keep a close eye on are
guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
which adds another set of packages. Wheee. Hrm.


live well,
  vagrant


signature.asc
Description: PGP signature


Re: Release progress, week 3

2022-11-02 Thread Ludovic Courtès
Hi,

Vagrant Cascadian  skribis:

> On 2022-10-27, Ludovic Courtès wrote:
>> Release progress: week 3.
> ...
>>   • Architectures:
>>
>>  - powerpc64le-linux builds are back behind ci.guix, thanks to
>>Tobias!
> ...
>>  - armhf-linux: No progress so far.
>
> Not sure where this fits into the release process, but I uploaded a git
> snapshot to Debian of guix from commit
> c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 ...

Yay, thanks!

> All 6 of the failures have the same error:
>
> test-name: channel-news, no news
> ...
> actual-error:
> + (git-error
> +   #< code: -1 message: "invalid version 0 on git_proxy_options" 
> class: 3>)
> result: FAIL

This looks like an ABI issue with libgit2.  Are you sure the same
version of libgit2 is used on all these platforms?

Thanks,
Ludo’.



Re: Release progress, week 3

2022-10-29 Thread Guillaume Le Vaillant
Ludovic Courtès  skribis:

> Release progress: week 3.
>
>   • Architectures:
>  [...]
>  - armhf-linux: No progress so far.

I tried doing a "guix pull" for armhf-linux on a Raspberry Pi 2 B
(Raspberry Pi OS with Guix as package manager), and also on a more
powerful x86_64 machine with "guix pull -s armhf-linux -p /tmp/arm-guix",
but it fails in both cases when building "guix-packages-base.drv" (more
precisely the process hangs, CPU usage at 0 and memory around 2 or
3 GB).

The build log ends with:
--8<---cut here---start->8---
compiling...  95.6% of 344 files
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
[... same message many times ...]
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
--8<---cut here---end--->8---

Does someone have an idea how to fix this?


signature.asc
Description: PGP signature


Re: Release progress, week 3

2022-10-27 Thread Vagrant Cascadian
On 2022-10-27, Ludovic Courtès wrote:
> Release progress: week 3.
...
>   • Architectures:
>
>  - powerpc64le-linux builds are back behind ci.guix, thanks to
>Tobias!
...
>  - armhf-linux: No progress so far.

Not sure where this fits into the release process, but I uploaded a git
snapshot to Debian of guix from commit
c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 ... ppc64le still has not built
yet, and it has the same test suite failures on two 32-bit architectures
(i386 and armhf):

  
https://buildd.debian.org/status/fetch.php?pkg=guix&arch=armhf&ver=1.3.0%2B26756.c07b5-1&stamp=1666838910&raw=0
  
https://buildd.debian.org/status/fetch.php?pkg=guix&arch=i386&ver=1.3.0%2B26756.c07b5-1&stamp=1666825176&raw=0


Testsuite summary for GNU Guix 1.3.0.26756-c07b5

# TOTAL: 2286
# PASS:  2002
# SKIP:  274
# XFAIL: 4
# FAIL:  6
# XPASS: 0
# ERROR: 0


All 6 of the failures have the same error:

test-name: channel-news, no news
...
actual-error:
+ (git-error
+   #< code: -1 message: "invalid version 0 on git_proxy_options" 
class: 3>)
result: FAIL


Would love to figure out these issues in time for release!


Good news is it built reproducibly (at least on amd64; i386, armhf and
arm64 pending):

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/guix.html

This is partly because the Debian package works around
https://issues.guix.gnu.org/20272 by disabling parallelism in the
build. Sure would be nice if guix was reproducible when built with Guix
too!


live well,
  vagrant


signature.asc
Description: PGP signature


Release progress, week 3

2022-10-27 Thread Ludovic Courtès
Hello Guix!

Release progress: week 3.

  • ‘make assert-binaries-available’ reports 92.1% coverage, slightly
less than last week, probably because of the very recent merge
(details below).

  • Rust on AArch64:

 - Efraim reports that an update of ‘rust-bootstrap’ on ‘staging’
   has been running, which fixes the issue:
   <https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00229.html>.
   This has been merged just a day ago so we should be all fine,
   right?  <https://issues.guix.gnu.org/58661> can be closed?

  • Architectures:

 - powerpc64le-linux builds are back behind ci.guix, thanks to
   Tobias!

 - i586-gnu: childhurds at ci.guix are back, thanks to the
   workaround for <https://issues.guix.gnu.org/58320> in commit
   3fb3bd3da530a5f82a169b1fa451474f9d90c3b6; Cuirass is not yet set
   up to build for i586-gnu.  Many core packages fail to build due
   to test failures such as <https://issues.guix.gnu.org/58803>.  We
   can work around them without too much work, but we should
   probably decide next week whether to drop it this time.

 - armhf-linux: No progress so far.

  • Installer:

 - Warn when uvesafb is used (commit
   682639c107908426fe6bf0a1b8404b98b7820290,
   <https://issues.guix.gnu.org/58549>).

 - Bug fixed: <https://issues.guix.gnu.org/58734>.

  • Release issue <https://issues.guix.gnu.org/53214> blocked by 9 open
bugs.

  • Others:

 - Shepherd memory leak still being investigated:
   <https://issues.guix.gnu.org/58631>.

Ludo’.

Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

--8<---cut here---start->8---
computing 400 package derivations for x86_64-linux...
looking for 507 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  92.1% substitutes available (467 out of 507)
  at least 4,311.6 MiB of nars (compressed)
  6,423.0 MiB on disk (uncompressed)
  0.011 seconds per request (1.8 seconds in total)
  88.1 requests per second

  5.0% (2 out of 40) of the missing items are queued
  at least 1,000 queued builds
  aarch64-linux: 997 (99.7%)
  armhf-linux: 1 (.1%)
  powerpc64le-linux: 2 (.2%)
  build rate: 26.17 builds per hour
  x86_64-linux: 22.85 builds per hour
  i686-linux: 2.06 builds per hour
  powerpc64le-linux: 2.16 builds per hour

Substitutes are missing for the following items:
  /gnu/store/4vhjmlgzxr7k0hqdlrnhm32x7g26m0m7-bootstrap-tarballs-0  
 x86_64-linux
  /gnu/store/cxf0szcb0wcdhh8pb2dqgy22dqmg92ps-grep-3.6  
 x86_64-linux
  /gnu/store/fg7qqzxqk1vw1ad6q8da176qzq3d45n3-coreutils-8.32-debug  
 x86_64-linux
  /gnu/store/lqfyqn7c7a4jb4x6fbrh3ij8gzql802p-coreutils-8.32
 x86_64-linux
  /gnu/store/885iln2zpcxqvbr35d54bqhzs7l9djmq-libreoffice-7.3.5.2   
 i686-linux
  /gnu/store/3dng8r8ydla5sw515rb252mvl9xrvc42-mate-1.24.1   
 i686-linux
  /gnu/store/lrl3vqh31jwg97cdp1v63zf787bdqb3b-xz-5.2.5  
 i586-gnu
  /gnu/store/hp7x1kmbyvb8jmmvdli1nsskn45nj9yv-xz-5.2.5-static   
 i586-gnu
  /gnu/store/ifw4zdjck946phvfsrsd2bi37kcvsw69-tar-1.34  
 i586-gnu
  /gnu/store/zyls8m0n3m4ysrf358hnafvwr4dcxllq-gcc-toolchain-12.2.0-debug
 i586-gnu
  /gnu/store/rzvy8p25xmc2m34hkn17n3z6w4zm4n65-gcc-toolchain-12.2.0  
 i586-gnu
  /gnu/store/yl6bi7yxn5rx2kzqm0p14b7g5x8ngkbw-gcc-toolchain-12.2.0-static   
 i586-gnu
  /gnu/store/9mdi9nfn642fq0iixrk73f7dpi9bxd1j-make-4.3-debug
 i586-gnu
  /gnu/store/5gydsssmavix0f69sfb59kjhdj7g6rj0-make-4.3  
 i586-gnu
  /gnu/store/l42v9025ndkn29vlznh15qs2pa76m14r-gawk-5.1.0
 i586-gnu
  /gnu/store/rm49qi7bm16gn9f82b5nz2y9vaxad019-findutils-4.8.0 i586-gnu
  /gnu/store/x4gwg96bjngbmgay0zn7biccp8h1ypm4-grep-3.6  
 i586-gnu
  /gnu/store/nqfcsykwy3s6m1mi08pkwvnkqr4hjkmd-coreutils-8.32-debug  
 i586-gnu
  /gnu/store/jsrasjn4s9jlaigf05g6jzrscxhz46fc-coreutils-8.32
 i586-gnu
  /gnu/store/nz1rw5cfrh4z3bl7fm2qsvxxpl955cqh-guile-3.0.8-debug 
 armhf-linux
  /gnu/store/zmk1kmfk7wxm5w3ambajgnx7b0s5iq84-guile-3.0.8   
 armhf-linux
  /gnu/store/26yb2pj71wg9cywmhpmsf6n1d81i43c5-python-3.9.9-idle 
 armhf-linux
  /gnu/store/dh5rr8gd148afs3jzijs8i9gfwwi6igz-python-3.9.9  
 armhf-linux
  /gnu/store/x0yzk738mm4if6kbc8i8q7x3ajz2rd27-python-3.9.9-tk   
 armhf-linux
  /gnu/store/5p9jplb7hzci9nrpk4nxqa7qlyfb6wji-vim-9.0.0719  
 armhf-linux
  /gnu/store/v7xmdapgwgqgcnacf3qmapahgwfbgcsq-emacs-28.2
 armhf-linux
  /gn