Re: Merging core-updates?

[Kaelyn]

--- Original Message ---
On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner 
 wrote:
> 
> 
> On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote:
> 
> > Hi,
> > 
> > --- Original Message ---
> > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge andr...@enge.fr 
> > wrote:
> > 
> > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
> > > 
> > > > And I was able to rebuild (with --check) patch-mesboot. The error looks
> > > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> > > > :)
> > > 
> > > Ah indeed, that looks like deal breaking; maybe someone from MES can have
> > > a look?
> > > 
> > > What is the magic incantation with double "@@" to build this package?
> > > Ah, here we go, for reference to self:
> > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)'
> > > 
> > > Andreas
> > 
> > While not directly related to the patch-mesboot error, I want to mention 
> > that there is also https://issues.guix.gnu.org/58719 blocking i686 builds 
> > on core-updates (and x86_64 builds of certain packages like wine64, which 
> > has i686 dependencies) since the update to glibc 2.35.
> > 
> > It may also need assistance from the MES folks to fix, since the error 
> > message is about an undefined symbol in glibc-mesboot's libpthread.so.0:
> > 
> > make[2]: Entering directory 
> > '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic'
> > ../src/file -C -m magic
> > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup 
> > error: 
> > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
> >  undefined symbol: h_errno, version GLIBC_PRIVATE
> > make[2]: *** [Makefile:863: magic.mgc] Error 127
> > 
> > Cheers,
> > Kaelyn
> 
> 
> I think I found where this is coming from. %boot3-inputs added
> ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in
> glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs
> to see if that's enough to make that final file build. Hopefully it'll
> also fix the final tar for i686, which I found was also failing for me.

Interesting! Since my last email, I was able to fix the issue with file by 
adding "--disable-xzlib" to the file package in gnu/packages/commencement.scm 
(after discovering it when noticing "--disable-bzlib" was being passed to the 
configure script), but hadn't sent in a patch yet because I hit a subsequent 
test failure while building tar. I thought to disable xz support because I 
traced the source of the glibc-mesboot libpthread.so in the error message to 
xz-mesboot being detected by the configure script and linked in even though 
file itself was being linked against a newer glibc and had no explicit 
dependencies. (I think the error after upgrading to glibc 2.35 from 2.33 was an 
abi compatibility between the newer glibc and the old pthread being pulled in 
via xz-mesboot.)

Cheers,
Kaelyn

> 
> --
> Efraim Flashner efr...@flashner.co.il אפרים פלשנר
> 
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Re: Merging core-updates?

[Efraim Flashner]

On Mon, Feb 13, 2023 at 09:35:32PM +0100, Andreas Enge wrote:
> Hello all,
> 
> here are my first important failures when trying to go beyond hello and mpc
> (aka the easy C programs):
> 
> ocaml-4.0.9 fails with
> gcc -c -O2 -fno-strict-aliasing -fwrapv -Wall -fno-tree-vrp -g 
> -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  
> -DOCAML_STDLIB_DIR='"/gnu/store/mzzak7bp6dpngq04hphlx58wzp62755m-ocaml-4.09.0/lib/ocaml"'
>   -DNATIVE_CODE -DTARGET_amd64 -DMODEL_default -DSYS_linux   -o 
> signals_nat_n.o signals_nat.c
> signals_nat.c:185:13: error: variably modified ‘sig_alt_stack’ at file scope
>   185 | static char sig_alt_stack[SIGSTKSZ];
>   | ^
> make[3]: *** [Makefile:343: signals_nat_n.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: Leaving directory 
> '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0/runtime'
> make[2]: *** [Makefile:1004: makeruntimeopt] Error 2
> make[2]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
> make[1]: *** [Makefile:417: opt.opt] Error 2
> make[1]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
> make: *** [Makefile:468: world.opt] Error 2
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "4" "world.opt") 
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `build' failed after 45.7 seconds
> command "make" "-j" "4" "world.opt" failed with status 2
> 
> openjdk-19.0.1-checkout fails:
> `File make/modules/java.desktop/lib/Awt2dLibraries.gmk is read-only; trying 
> to patch anyway
> patching file make/modules/java.desktop/lib/Awt2dLibraries.gmk
> Hunk #1 succeeded at 214 (offset -3 lines).
> File src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c is 
> read-only; trying to patch anyway
> patching file src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c
> Hunk #1 succeeded at 44 (offset 4 lines).
> Hunk #2 succeeded at 978 (offset 4 lines).
> File test/jdk/java/awt/JAWT/Makefile.unix is read-only; trying to patch anyway
> patching file test/jdk/java/awt/JAWT/Makefile.unix
> File test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c is read-only; 
> trying to patch anyway
> patching file test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c
> Hunk #1 FAILED at 67.
> 1 out of 1 hunk FAILED -- saving rejects to file 
> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c.rej
> source is at 'openjdk-19.0.1-checkout'
> applying 
> '/gnu/store/g6sgv9nipmvsxbmimlgsmhdcdvcssmhf-openjdk-15-xcursor-no-dynamic.patch'...
> applying 
> '/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch'...
> Backtrace:
>5 (primitive-load "/gnu/store/kpgzrwyczkxymc54lnkld0nmrd0…")
> In ice-9/eval.scm:
> 619:8  4 (_ #(#(# "ope…") #))
> In ice-9/boot-9.scm:
> 142:2  3 (dynamic-wind # …)
> In ice-9/eval.scm:
> 619:8  2 (_ #(#(#)))
> In srfi/srfi-1.scm:
> 634:9  1 (for-each # _)
> In guix/build/utils.scm:
> 812:6  0 (invoke "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-p…" …)
> 
> guix/build/utils.scm:812:6: In procedure invoke:
> ERROR:
>   1. :
>   program: 
> "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-patch-2.7.6/bin/patch"
>   arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
> "/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch")
>   exit-status: 1
>   term-signal: #f
>   stop-signal: #f
> Just a permission error on files to be patched, or a problem with the patch 
> itself?
> 
> Andreas

Looks like you might be able to drop openjdk-10-hotspot-stack-size.patch
from openjdk-19.0.1.

-- 
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: [gnu-soc] Guix internship ideas page

[Jose E. Marchesi]

> Hello Jose and all,
>
> The GNU Guix community would be happy to participate.
>
> We have a generic internship ideas page on libreplanet:
> https://libreplanet.org/wiki/Group:Guix/GSoC-2023
>
> Please also let us know if we can help in any way.

Thanks.
I have added the guix info to the ideas page.

Re: Merging core-updates?

[Development of GNU Guix and the GNU System distribution.]

Hi

On Mon, Feb 13, 2023 at 12:22 PM Andreas Enge  wrote:
>
> It looks like we have reached the Debian trap

How about applying selectively those patches from core-updates that do
not break anything? It would split the difference.

Future changes waiting in Debbugs could join the remainder, which
needs more work. Later, the new branch could go through the same
procedure, i.e. any breakage would be caught.

The new process would be gradual and allow some commits to advance
into the project history (also known as the 'master' branch) within a
predicable time frame.

Thanks everyone for your hard work!

Kind regards
Felix Lechner

Re: Merging core-updates?

[Andreas Enge]

Hello all,

here are my first important failures when trying to go beyond hello and mpc
(aka the easy C programs):

ocaml-4.0.9 fails with
gcc -c -O2 -fno-strict-aliasing -fwrapv -Wall -fno-tree-vrp -g 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  
-DOCAML_STDLIB_DIR='"/gnu/store/mzzak7bp6dpngq04hphlx58wzp62755m-ocaml-4.09.0/lib/ocaml"'
  -DNATIVE_CODE -DTARGET_amd64 -DMODEL_default -DSYS_linux   -o signals_nat_n.o 
signals_nat.c
signals_nat.c:185:13: error: variably modified ‘sig_alt_stack’ at file scope
  185 | static char sig_alt_stack[SIGSTKSZ];
  | ^
make[3]: *** [Makefile:343: signals_nat_n.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory 
'/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0/runtime'
make[2]: *** [Makefile:1004: makeruntimeopt] Error 2
make[2]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
make[1]: *** [Makefile:417: opt.opt] Error 2
make[1]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
make: *** [Makefile:468: world.opt] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-j" "4" "world.opt") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 45.7 seconds
command "make" "-j" "4" "world.opt" failed with status 2

openjdk-19.0.1-checkout fails:
`File make/modules/java.desktop/lib/Awt2dLibraries.gmk is read-only; trying to 
patch anyway
patching file make/modules/java.desktop/lib/Awt2dLibraries.gmk
Hunk #1 succeeded at 214 (offset -3 lines).
File src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c is read-only; 
trying to patch anyway
patching file src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c
Hunk #1 succeeded at 44 (offset 4 lines).
Hunk #2 succeeded at 978 (offset 4 lines).
File test/jdk/java/awt/JAWT/Makefile.unix is read-only; trying to patch anyway
patching file test/jdk/java/awt/JAWT/Makefile.unix
File test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c is read-only; 
trying to patch anyway
patching file test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c
Hunk #1 FAILED at 67.
1 out of 1 hunk FAILED -- saving rejects to file 
test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c.rej
source is at 'openjdk-19.0.1-checkout'
applying 
'/gnu/store/g6sgv9nipmvsxbmimlgsmhdcdvcssmhf-openjdk-15-xcursor-no-dynamic.patch'...
applying 
'/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch'...
Backtrace:
   5 (primitive-load "/gnu/store/kpgzrwyczkxymc54lnkld0nmrd0…")
In ice-9/eval.scm:
619:8  4 (_ #(#(# "ope…") #))
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9  1 (for-each # _)
In guix/build/utils.scm:
812:6  0 (invoke "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-p…" …)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. :
  program: 
"/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-patch-2.7.6/bin/patch"
  arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
"/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch")
  exit-status: 1
  term-signal: #f
  stop-signal: #f
Just a permission error on files to be patched, or a problem with the patch 
itself?

Andreas

[Internship] I contacted the Outreachy organizers

[Gábor Boskovits]

Hello Guix,

I have contacted the Outreachy organizers to clarify if we need an
alternative funding arrangement. I will keep you updated.

Regards,
g_bor

Re: Merging core-updates?

[Andreas Enge]

Hello,

Am Sun, Feb 12, 2023 at 05:51:47PM +0200 schrieb Efraim Flashner:
> I think we normally have a 2 week last-chance window to get all sorts of
> last minute packages bumped and then we freeze it and try to build
> "everything".

I am a bit hesitant to let more breakages in :)  It looks like we have
reached the Debian trap: releases/core-update merges happen so infrequently
that people become desperate to get their favourite update in, which causes
build failures, which delay the release cycle, da capo ad infinitum.

Personally I would prefer to freeze now, then to let other big changes
(mesa for instance) happen in a feature branch; if all goes well, it could
be merged a week or two later, if it breaks things, it will anyway take
the time it needs to fix them.

Andreas

[Internship][Discussion] How we want to arrange the mentoring of internships?

[Gábor Boskovits]

Hello Guix,

This is a kickoff message to start the discussion on how we can arrange
that community members who are willing to help in mentoring can
meaningfully participate if they can not commit to being a full time
primary mentor.

So the question is: How do we imagine a co-mentor?

Regards,
g_bor

[Internship][Discussion] Do we want to run our own internship program?

[Gábor Boskovits]

Hello Guix,

This is a kickoff message to start the discussion if we want to run our own
internship program as the Guix community.

We discussed this idea on the Guix Days, and came to the conclusion that
this is financially feasible, but needs effort and maybe also some know-how
from the community members.

So, the question is: do we want to run our own?

Regards,
g_bor

[gnu-soc] Guix internship ideas page

[Gábor Boskovits]

Hello Jose and all,

The GNU Guix community would be happy to participate.

We have a generic internship ideas page on libreplanet:
https://libreplanet.org/wiki/Group:Guix/GSoC-2023

Please also let us know if we can help in any way.

Regards,
g_bor

Re: Merging core-updates?

[Efraim Flashner]

On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote:
> Hi,
> 
> --- Original Message ---
> On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge  
> wrote:
> 
> >
> >
> > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
> >
> > > And I was able to rebuild (with --check) patch-mesboot. The error looks
> > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
> > > :)
> >
> >
> > Ah indeed, that looks like deal breaking; maybe someone from MES can have
> > a look?
> >
> > What is the magic incantation with double "@@" to build this package?
> > Ah, here we go, for reference to self:
> > guix build -e '(@@ (gnu packages commencement) patch-mesboot)'
> >
> > Andreas
> 
> While not directly related to the patch-mesboot error, I want to mention that 
> there is also https://issues.guix.gnu.org/58719 blocking i686 builds on 
> core-updates (and x86_64 builds of certain packages like wine64, which has 
> i686 dependencies) since the update to glibc 2.35.
> 
> It may also need assistance from the MES folks to fix, since the error 
> message is about an undefined symbol in glibc-mesboot's libpthread.so.0:
> 
> make[2]: Entering directory '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic'
> ../src/file -C -m magic
> /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup 
> error: 
> /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0:
>  undefined symbol: h_errno, version GLIBC_PRIVATE
> make[2]: *** [Makefile:863: magic.mgc] Error 127
> 
> Cheers,
> Kaelyn

I think I found where this is coming from. %boot3-inputs added
ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in
glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs
to see if that's enough to make that final file build. Hopefully it'll
also fix the final tar for i686, which I found was also failing for me.

-- 
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: Merging core-updates?

[John Kehayias]

Hi Katherine et al,

On Mon, Feb 13, 2023 at 09:40 AM, Katherine Cox-Buday wrote:

> Efraim Flashner  writes:
>
>> On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
>>> Hi Guix!
>>>
>>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>>> in a very long time. I'd volunteer to lead this effort, but I don't
>>> know what steps I should follow. Do we have some documentation about
>>> that?
>>
>> I think we normally have a 2 week last-chance window to get all sorts of
>> last minute packages bumped and then we freeze it and try to build
>> "everything".
>
>
> On that note, could we possibly give Mesa one final bump? The latest
> version is 22.3.5, and the version in core-updates is 22.2.4.
>
> I also hope to be able to test, but my schedule tends to run away from
> me.

Yes, I would like to get Mesa up to date, we have the smaller LLVM closure now 
and the pending patches for some Vulkan paths/packages. I would like to help 
review/test/push those but I'm in the middle of a move so if anyone wants to 
beat me to it in the next week or so, please do :) But yes, those are all on my 
radar and certainly a preferred activity to more packing...

John

Re: Merging core-updates?

[Katherine Cox-Buday]

Efraim Flashner  writes:

> On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
>> Hi Guix!
>> 
>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>> in a very long time. I'd volunteer to lead this effort, but I don't
>> know what steps I should follow. Do we have some documentation about
>> that?
>
> I think we normally have a 2 week last-chance window to get all sorts of
> last minute packages bumped and then we freeze it and try to build
> "everything".


On that note, could we possibly give Mesa one final bump? The latest
version is 22.3.5, and the version in core-updates is 22.2.4.

I also hope to be able to test, but my schedule tends to run away from
me.

-- 
Katherine

Re: Moving forward with teams and feature branches (was: Discussion notes on releases and branches)

[Andreas Enge]

Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> 4. staging merge happens, and the branch gets deleted.

I failed to compile my profile on staging, since rust-rav1e, a dependency
of ffmpeg, failed to build; see bug #61475.

Andreas

Re: Merging core-updates?

[Andreas Enge]

Am Mon, Feb 13, 2023 at 12:34:56PM +0100 schrieb Janneke Nieuwenhuizen:
> To use stat64 and friends on 32bit, I created the attached patch for GNU
> Mes and hope to create a 0.24.2 release from
> https://gitlab.com/janneke/mes/-/tree/wip-stat64

Thanks a lot, Janneke!

> Just hoping this is also a fix for
> https://debbugs.gnu.org/41264
> https://debbugs.gnu.org/49985
> as I haven't been able to reproduce this bug.  IWBN if someone could
> shed more light on that...

The patch-mes package also builds on my laptop with an SSD, so I do not
know how to reproduce it. If someone else does, that would be great.

Andreas

Re: Google Summer of Code?

[Pjotr Prins]

We can still add ideas after acceptance. We put one in for Mes.

On Mon, Feb 13, 2023 at 10:51:28AM +0100, Simon Tournier wrote:
> Hi,
> 
> On Fri, 10 Feb 2023 at 09:05, Gábor Boskovits  wrote:
> 
> > I will contact Jose, pass a link to the ideas side and check how to proceed
> > and if we can help somehow.
> 
> Cool!
> 
> Cross-finger for: February 22 - 18:00 UTC
> 
> List of accepted mentoring organizations published
> 
> 
> 
> Cheers,
> simon
> 

Re: Architecture support

[Andreas Enge]

Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner:
> Aarch64 and armhf are getting stuck at gcc-cross-boot0.

Hm, it looks like I went further: A bit earlier there was a directory
/tmp/guix-build-gcc-cross-boot0, and now it is gone and replaced by
/tmp/guix-build-glibc-intermediate.

Maybe a transient failure? Lack of memory? But I also have only 4GB.

Andreas

Re: Proposed changes to the commit policy

[Efraim Flashner]

On Mon, Jan 30, 2023 at 10:40:42PM +0100, Ludovic Courtès wrote:
> Hi!
> 
> My 2¢ on this…  As a committer & reviewer, I love that I can just go to
> , pick one of the patch series with a
> green tick, and have the assurance that the resource-intensive work is
> already done.  That makes a big difference!
> 
> As someone who submits patches, I realize the delay can be off-putting.
> For the hwloc upgrade I recently submitted, I got valuable feedback
> pointing at actual issues, but that was about a week later.  Then I had
> to switch contexts again to adjust the patch accordingly.
> 
> I guess that, to a large extent, that’s scheduling and resource issue.
> 
> Happy to discuss that in the coming days in Brussels!

Some of that might be mitigated by separating submitting patches and
pushing patches. On the rare occasion I've pushed patches belonging to
another committer if I felt it had been long enough and I needed it for
another patchset. If we're ok with touching up and pushing each other's
patches then reviewing all patches might go faster.

Even more so if we made it a rule that you couldn't push your own
patches (which I believe was suggested in 2017 and with using aegis).

-- 
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: Merging core-updates?

[Janneke Nieuwenhuizen]

Andreas Enge writes:

> Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller:
>> And I was able to rebuild (with --check) patch-mesboot. The error looks
>> a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
>> :)
>
> Ah indeed, that looks like deal breaking; maybe someone from MES can have
> a look?
>
> What is the magic incantation with double "@@" to build this package?
> Ah, here we go, for reference to self:
>guix build -e '(@@ (gnu packages commencement) patch-mesboot)'

To use stat64 and friends on 32bit, I created the attached patch for GNU
Mes and hope to create a 0.24.2 release from

https://gitlab.com/janneke/mes/-/tree/wip-stat64

Also, I have update my core-updates branch with preliminary 0.24.2 mes
and mes-boot packages here

https://gitlab.com/janneke/guix/-/tree/core-updates

Just hoping this is also a fix for

https://debbugs.gnu.org/41264
https://debbugs.gnu.org/49985

as I haven't been able to reproduce this bug.  IWBN if someone could
shed more light on that...

Greetings,
Janneke

>From bc1fa57851d360abb161c54dce5339ad9d7af7aa Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" 
Date: Sat, 29 Oct 2022 13:17:58 +0200
Subject: [PATCH] lib: stat: Use SYS_stat64 for 32bit platforms.

This fixes .

* include/linux/arm/syscall.h (SYS_stat64, SYS_lstat64,
SYS_fstat64)[__SIZEOF_LONG_LONG__ == 8]:
New defines.
(SYS_stat, SYS_lstat, SYS_fstat)[__SIZEOF_LONG_LONG__ == 8]: Redefine them.
* include/linux/x86/syscall.h (SYS_stat64, SYS_lstat64,
SYS_fstat64)[__SIZEOF_LONG_LONG__ == 8]:
New defines.
(SYS_stat, SYS_lstat, SYS_fstat)[__SIZEOF_LONG_LONG__ == 8]: Redefine them.
* include/sys/stat.h (struct stat): Move definition to...
* include/linux/arm/kernel-stat.h,
include/linux/m2/kernel-stat.h,
include/linux/x86/kernel-stat.h,
include/linux/x86_64/kernel-stat.h: These new files.
* include/gnu/x86/kernel-stat.h: New file.
* configure (main): Copy include///*.h to
include/.
* configure.sh: Likewise.
* .gitignore: Ignore them.  Add copyright header.
* build-aux/GNUmakefile.in (X86_ARCH_HEADERS, ARCH_HEADERS): New
variables.
(build): Use them.
(include/arch/%.h, arch-dir): New targets.
* build-aux/bootstrap.sh.in (AM_CPPFLAGS): Replace
include// with built ../include.
* build-aux/build.sh.in (AM_CPPFLAGS): Likewise.
* build-aux/install.sh.in: Also install built include.
* include/m2/types.h: New file.
* kaem.run: Use it.
* simple.sh: Copy kernel-stat.h, syscall.h for kernel/cpu to
include/arch.
---
 .gitignore |  19 
 build-aux/GNUmakefile.in   |  11 ++-
 build-aux/bootstrap.sh.in  |   4 +-
 build-aux/build.sh.in  |  11 ++-
 build-aux/install.sh.in|   3 +-
 configure  |   7 ++
 configure.sh   |   4 +
 include/gnu/x86/kernel-stat.h  |  25 ++
 include/linux/arm/kernel-stat.h|  79 +
 include/linux/arm/syscall.h|  19 
 include/linux/m2/kernel-stat.h |  47 ++
 include/linux/x86/kernel-stat.h|  79 +
 include/linux/x86/syscall.h|  20 -
 include/linux/x86_64/kernel-stat.h |  51 +++
 include/m2/types.h | 138 +
 include/sys/stat.h |  51 +--
 kaem.run   |   3 +
 lib/linux/_getcwd.c|   4 +-
 lib/linux/_open3.c |   2 +-
 lib/linux/_read.c  |   4 +-
 lib/linux/access.c |   4 +-
 lib/linux/brk.c|   4 +-
 lib/linux/chdir.c  |   4 +-
 lib/linux/chmod.c  |   4 +-
 lib/linux/clock_gettime.c  |   4 +-
 lib/linux/close.c  |   4 +-
 lib/linux/dup.c|   4 +-
 lib/linux/dup2.c   |   4 +-
 lib/linux/execve.c |   4 +-
 lib/linux/fcntl.c  |   4 +-
 lib/linux/fork.c   |   4 +-
 lib/linux/fstat.c  |   4 +-
 lib/linux/fsync.c  |   4 +-
 lib/linux/getdents.c   |   4 +-
 lib/linux/getegid.c|   4 +-
 lib/linux/geteuid.c|   4 +-
 lib/linux/getgid.c |   4 +-
 lib/linux/getpid.c |   4 +-
 lib/linux/getppid.c|   4 +-
 lib/linux/getrusage.c  |   4 +-
 lib/linux/gettimeofday.c   |   4 +-
 lib/linux/getuid.c |   4 +-
 lib/linux/ioctl.c  |   2 +-
 lib/linux/ioctl3.c |   2 +-
 lib/linux/kill.c   |   4 +-
 lib/linux/link.c   |   4 +-
 lib/linux/lseek.c  |   2 +-
 lib/linux/lstat.c  |   4 +-
 lib/linux/mkdir.c  |   4 +-
 lib/linux/mknod.c  |   4 +-
 lib/linux/nanosleep.c  |   4 +-
 lib/linux/pipe.c   |   4 +-
 lib/linux/read.c   

Re: Estimated overhead of building an orthogonal Musl-based LFS within Guix build system

[Csepp]

vtkq2fq...@liamekaens.com writes:

> Hi,
>
> I'm wondering what the overall estimated work or effort might look
> like to leverage Guix to build a co-existing family of packages that
> are in some sense "orthogonal" to the rest of Guix, based upon
> different package versions and perhaps musl libc - similar to
> https://github.com/dslm4515/CMLFS for example.
>
> Could a series of such packages be built up in the same way that these
> LFS type builds bootstrap themselves? For example, starting with the
> most primitive dependencies and going on upward.
>
> For this to work, different package versions for the same kind of
> package would need to coexist - which I don't believe is inherently a
> problem. But also, these builds would need to refer exclusively to
> paths and prefixes that are wholly self-contained and orthogonal to
> the rest of Guix.
>
> The overall aim here is to consider building some select packages for
> example with musl libc, or perhaps building a "stable track" of
> software that is unaffected by the rest of Guix evolving packages.
>
> The measurement of effort can be subjective. Perhaps it involves
> modifying existing recipes and adapting these to point to different
> packages/versions. Maybe there is a similar precedent somewhere.
>
> Any thoughts are appreciated.

I would love to see this but similar ideas have already come up (eg.:
BSD port) and the response from core contributors (based on experience
with Nix) was that maintaining multiple libc's is not worth the effort.

I would definitely want a more Alpine-y Guix though.

Architecture support [was: Re: Merging core-updates?]

[Efraim Flashner]

On Mon, Feb 13, 2023 at 10:43:17AM +0100, zimoun wrote:
> Hi,
> 
> Well, it could be helpful is Berlin or Bordeaux could build some
> manifest of core-updates (not necessary the whole core-updates).  And
> then, once the manifest builds, we could add some packages and repeat.
> 
> It would avoid that we all build the same things; worse, that each of us
> burn many CPU just for knowing it fails.
> 
> Chris, Mathieu?  What do you think?
> 

At least locally I try to build out to hello, and then to mesa.

Currently I believe only x86_64 is building to hello. I'm not against
downgrading file to an earlier version if it'll get i686 to get to
hello.

i686 is getting stuck at an unknown file.
Aarch64 and armhf are getting stuck at gcc-cross-boot0.
Riscv64 is getting stuck at gcc-final.
I haven't tested powerpc64le (or powerpc or mips64el).

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

Time for RFC? (was Re: Moving forward with teams and feature branches (was: Discussion notes on releases and branches))

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 22:13, Josselin Poiret  wrote:

> 1. Document this workflow in the manual, in a dedicated node, with a
>rationale as well.  One thing worth mentioning would be how to handle
>grafting/ungrafting now.  Also remove the staging/core-updates
>criterion.

Maybe it is also time for “RFC” as discussed earlier.  It would fit this
item #1.

Time for a request-for-comments process?
id:87cznqb1sl@inria.fr
Wed, 27 Oct 2021 23:22:50 +0200
https://yhetil.org/guix/87cznqb1sl@inria.fr

Some examples of other projects.

https://github.com/NixOS/rfcs
https://peps.python.org/pep-/
https://github.com/rust-lang/rfcs

Cheers,
simon

Re: avoid Computing Guix derivation when not necessary

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 01:10, Ludovic Courtès  wrote:

>> The principle is simple: get commit and directory info from the profile
>> manifest, compare commits, if commits for all channels are the same, do
>> not try to update the profile.

Indeed, some improvements could be done in that direction.  For
instance,

--8<---cut here---start->8---
$ guix describe
Generation 89   Jan 17 2023 15:20:08(current)
  guix 29efa27
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 29efa2791dafb042ca8ace77bcf8538fb404d492

$ guix pull --commit=29efa27
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   29efa27
Computing Guix derivation for 'x86_64-linux'... |
[...]
--8<---cut here---end--->8---

Going from one commit to the exact same commit should not trigger some
intensive «Computing Guix derivation».

Note that if I run “guix pull --commit=29efa27” two times in row, the
second one it displays: «nothing to be done» after «Computing Guix
derivation».

Last, note that:

/var/guix/profiles/per-user/simon/current-guix -> current-guix-90-link

and

--8<---cut here---start->8---
$ /var/guix/profiles/per-user/simon/current-guix-90-link/bin/guix describe
  guix 29efa27
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 29efa2791dafb042ca8ace77bcf8538fb404d492

$ /var/guix/profiles/per-user/simon/current-guix-89-link/bin/guix describe
  guix 29efa27
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 29efa2791dafb042ca8ace77bcf8538fb404d492

$ readlink -f /var/guix/profiles/per-user/simon/current-guix-90-link
/gnu/store/g32zjrbr40fzp1rj5i6gx7hal20myfyv-profile

$ readlink -f /var/guix/profiles/per-user/simon/current-guix-89-link
/gnu/store/pk1i1dsagdby5pqydmvfbffg0i80wwvy-profile

$ diff -r --no-dereference \
  /gnu/store/g32zjrbr40fzp1rj5i6gx7hal20myfyv-profile/manifest \
  /gnu/store/pk1i1dsagdby5pqydmvfbffg0i80wwvy-profile/manifest
12c12
<   "/gnu/store/96bibk75vy5yvmilnycd8pl0l2bydcww-guix-29efa2791"
---
>   "/gnu/store/ldp0snjsac6hp1fikk5b8413pihm77di-guix-29efa2791"
20c20
< (branch #f)
---
> (branch "master")
--8<---cut here---end--->8---

Hum, maybe I have something twisted somewhere in my configuration.  From
my understanding, it comes from (guix scripts pull):

--8<---cut here---start->8---
(match (find guix-channel? channels)
  ((? channel? guix)
   ;; Apply '--url', '--commit', and '--branch' to the 'guix' channel.
   (let ((url (or url (channel-url guix
 (cons (match ref
 (('commit . commit)
  (channel (inherit guix)
   (url url) (commit commit) (branch #f)))
--8<---cut here---end--->8---

where ’branch’ should not be #f but instead inherit from ’guix’.  I
remember discussing this but I do not find where. :-)


> One marginal improvement would be sharing the cache that ‘time-machine’
> uses with ‘guix pull’.  Last I looked it wasn’t as easy as one might
> hope, but I forgot the details.

It could be nice! :-)  Last time I gave a look, I had an headache. ;-)

Cheers,
simon

Re: Merging core-updates?

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 10:05, Julien Lepiller  wrote:

> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

Maybe a start could be to fix: 

Well, it could be helpful is Berlin or Bordeaux could build some
manifest of core-updates (not necessary the whole core-updates).  And
then, once the manifest builds, we could add some packages and repeat.

It would avoid that we all build the same things; worse, that each of us
burn many CPU just for knowing it fails.

Chris, Mathieu?  What do you think?


Cheers,
simon

Release (was Re: Discussion notes on releases and branches)

[Simon Tournier]

Hi,

Thanks Andreas for the notes. :-)

On Thu, 09 Feb 2023 at 13:19, Andreas Enge  wrote:

> - A release schedule for a release every 4 to 6 months sounds
>   reasonable.
> - Mathieu, Simon, Julien and Andreas volunteer to be members of a release

Ludo was volunteer for helping, if I remember correctly. ;-)

First we should start more or less now for the next release. :-)

Second, it was not clear and is still not clear for me when the branch
is created, if a core-updates branch is merged before, etc.  Well, I do
not remember we discussed the workflow.  Do we?  If yes, what was the
consensus?


Cheers,
simon

Re: Google Summer of Code?

[Simon Tournier]

Hi,

On Fri, 10 Feb 2023 at 09:05, Gábor Boskovits  wrote:

> I will contact Jose, pass a link to the ideas side and check how to proceed
> and if we can help somehow.

Cool!

Cross-finger for: February 22 - 18:00 UTC

List of accepted mentoring organizations published



Cheers,
simon