Re: core-updates-frozen branch merged

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> In case you hadn't taken notice, the core-update-frozen branch was
>> finally merged into master.  So please reconfigure your remotes to avoid
>> uploading any further work there :-).
>
> I’m late to the party, but that’s because I’ve been contemplating my
> updated Guixes for a week.  Thumbs up everyone and Maxim in particular
> for getting it past the finish line!

Thank you!  I wasn't alone :-) We have motivated and skilled hackers
going as far as swapping hard drives in their laptop to reproduce hard
to debug problems like in [0], which is amazing!  Thanks to all who are
debugging and fixing things, it helps tremendously (in many ways,
including keeping in good spirits!)

> That makes me wonder: do we even have a list of all the big changes that
> made it into this branch?  Would be nice to come up with a summary.

I have a couple of changes on top of my head; I intend to lay them down
in NEWS as soon as the version-1.4.0 branch I've been refining with more
integrated bits and last minute updates is ready for one last
(hopefully) big rebuild.  For sure I'll have to survey the git log as
I'm sure I've lost track of many great things that went in also.

Thanks,

Maxim

[0]  https://issues.guix.gnu.org/52051

Re: core-updates-frozen branch merged

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).

I’m late to the party, but that’s because I’ve been contemplating my
updated Guixes for a week.  Thumbs up everyone and Maxim in particular
for getting it past the finish line!

That makes me wonder: do we even have a list of all the big changes that
made it into this branch?  Would be nice to come up with a summary.

Ludo’.

Re: [core-updates-frozen] Tryton broken

[Hartmut Goebel]

Am 14.12.21 um 09:15 schrieb zimoun:

Now, core-updates-frozen is merged, they can go to master. :-)


I pushed the fixes to master yesterday. Shall I cherry-pick them to the 
release-1.4 branch or will somebody else take care of that?


--
Regards
Hartmut Goebel

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

Re: core-updates-frozen branch merged

[Thiago Jung Bauermann]

Hello!

Em segunda-feira, 13 de dezembro de 2021, às 22:34:34 -03, Maxim Cournoyer 
escreveu:
> Hello Guix!
> 
> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.

Hooray! Thank you very much to everyone who made this happen! I really 
appreciate the effort. The master branch is working great for me.

-- 
Thanks,
Thiago

Re: Tensorflow fixes on core-updates-frozen

[Guillaume Le Vaillant]

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:
>
>> Unfortunately, this is not enough to build tensorflow.  At the very end
>> we have this problem: […]
>
> This should now be fixed with commit e1c91aae23af12bccab615902a08ebc86defc1ac.

Thanks!


signature.asc
Description: PGP signature

Re: Tensorflow fixes on core-updates-frozen

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Unfortunately, this is not enough to build tensorflow.  At the very end
> we have this problem: […]

This should now be fixed with commit e1c91aae23af12bccab615902a08ebc86defc1ac.

-- 
Ricardo

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[Maxim Cournoyer]

Hey Simon!

zimoun  writes:

> Hi Maxim,
>
> On Mon, 13 Dec 2021 at 22:20, Maxim Cournoyer  
> wrote:
>
>> It'll have to be resolved on core-updates :-).
>
> Well, Julia update can happen in master, IMHO.  Even, depending on the
> release date, it appears to me doable for the next release. ;-)

Oh wow!  You sound confident, I like it!  :-).

When you have polished patches ready, we could have them built on the
version-1.4.0 branch.

Cheers,

Maxim

Re: core-updates-frozen branch merged

[Maxim Cournoyer]

Hi!

zimoun  writes:

> Hi Josselin,
>
> On Tue, 14 Dec 2021 at 14:24, Josselin Poiret  wrote:
>
>> What exactly would those "release-specific enhancements" be?
>
> Basically,
>
> - Fix important bugs and/or blocking ones (I do not know if there are
> many today).  And previous release, a "release" bug had been opened to
> collect them.
> - Make sure that all work as expected: test installers etc.
> - String freeze for documentation updates.  Let the time for translators.
> - Update changelog / NEWS
> - Write blog post

Yes, this, and I was also thinking the occasional change that'd cause
too many rebuilds for master, such as fixing up sitecustomize.py [0]
that basically triggers a world rebuild if we want to ship it in the
next release.  We could batch others as well; I know that bumping our
xorg package to the recently released 1.7.3 would be nice to fix the
spurious warnings.  [1]

[0]  https://issues.guix.gnu.org/52269
[1]  https://lists.x.org/archives/xorg-announce/2021-December/003120.html

Thanks all for the great collaboration that went into readying
core-updates-frozen for the merge! :-)

Maxim

Re: core-updates-frozen branch merged

[Katherine Cox-Buday]

Congratulations, everyone!

I love Guix, and I really appreciate all the work that everyone puts into it. 
I'm updating now :)

Sincerely,
-- 
Katherine

Re: core-updates-frozen branch merged

[zimoun]

Hi Josselin,

On Tue, 14 Dec 2021 at 14:24, Josselin Poiret  wrote:

> What exactly would those "release-specific enhancements" be?

Basically,

- Fix important bugs and/or blocking ones (I do not know if there are
many today).  And previous release, a "release" bug had been opened to
collect them.
- Make sure that all work as expected: test installers etc.
- String freeze for documentation updates.  Let the time for translators.
- Update changelog / NEWS
- Write blog post

Cheers,
simon

Re: Tensorflow fixes on core-updates-frozen

[Ricardo Wurmus]

Hi,

> [[PGP Signed Part:Undecided]]
> guix-comm...@gnu.org skribis:
>
>> rekado pushed a change to branch core-updates-frozen
>> in repository guix.
>>
>>  new d503194  gnu: python2-entrypoints: Add missing input.
>>  new 672c7a2  gnu: tensorflow: Do not unpack directory.
>>  new 6d3439b  gnu: eigen-for-tensorflow: Build with GCC 7.
>
> Hi Ricardo,
>
> Given that the core-update-frozen branch has been merged in master,
> can't these fixes be pushed on master directly?

I accidentally pushed those to core-updates-frozen.  I pushed almost the
same commits to the “master” branch afterwards.

The only difference is in the list of inputs in python2-entrypoints.  It
uses the new style on “master”.

Unfortunately, this is not enough to build tensorflow.  At the very end
we have this problem:

--8<---cut here---start->8---
[ 99%] Building CXX object 
CMakeFiles/pywrap_tensorflow_internal.dir/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc.o
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/bin/c++ 
-DEIGEN_AVOID_STL_ARRAY -DSQLITE_OMIT_LOAD_EXTENSION -DTF_USE_SNAPPY 
-Dpywrap_tensorflow_internal_EXPORTS 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/external/eigen_archive
 
-I/gnu/store/54dclv4bsbg5894pyh0q5g768113368a-eigen-for-tensorflow-3.3.5-1.fd6845384b86/include/eigen3
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/gemmlowp/src/gemmlowp
 -I/gnu/store/jh8w9a3gnkisp8zgkklydhc372vgcsk6-jsoncpp-1.7.3 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/external/farmhash_archive
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/external/farmhash_archive/util
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/external/highwayhash
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/cub/src/cub
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/external/nsync/public
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/re2/install/include
 
-I/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/contrib/build/double_conversion/src/double_conversion
 -I/gnu/store/g88hslvix5j2rkdm13ay7biqyyqfja0f-snappy-1.1.9 
-I/gnu/store/p5fgysbcnnp8b1d91mrvjvababmczga0-python-3.9.6/include/python3.9 
-I/gnu/store/wgsmkn68q8h178sqc7ywjcdr330z9rb6-python-numpy-1.20.3/lib/python3.9/site-packages/numpy/core/include
 -fPIC -fno-exceptions -std=c++11 -fopenmp -O3 -DNDEBUG -fPIC -std=gnu++14 -MD 
-MT 
CMakeFiles/pywrap_tensorflow_internal.dir/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc.o
 -MF 
CMakeFiles/pywrap_tensorflow_internal.dir/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc.o.d
 -o 
CMakeFiles/pywrap_tensorflow_internal.dir/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc.o
 -c 
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:362:1:
 warning: converting to non-pointer type ‘long int’ from NULL 
[-Wconversion-null]
  362 | };
  | ^
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:
 In function ‘bool tensorflow::{anonymous}::Initialize()’:
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:623:36:
 error: no match for call to 
‘(tensorflow::{anonymous}::Initialize()::&)>) (const char [6], 
, const std::array&)’
  623 |   compare_types)) {
  |^
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:596:25:
 note: candidate: ‘tensorflow::{anonymous}::Initialize()::&)>’
  596 |   auto register_ufunc = [&](const char* name, PyUFuncGenericFunction fn,
  | ^
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:596:25:
 note:   no known conversion for argument 2 from ‘’ to ‘PyUFuncGenericFunction’ {aka ‘void (*)(char**, const long 
int*, const long int*, void*)’}
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:627:36:
 error: no match for call to 
‘(tensorflow::{anonymous}::Initialize()::&)>) (const char [10], 
, const std::array&)’
  627 |   compare_types)) {
  |^
/tmp/guix-build-tensorflow-1.9.0.drv-0/source/tensorflow/python/lib/core/bfloat16.cc:596:25:
 note: candidate: ‘tensorflow::{anonymous}::Initialize()::&)>’
  596 |   auto register_ufunc = [&](const char* name, PyUFunc

Re: core-updates-frozen branch merged

[Josselin Poiret]

Maxim Cournoyer  writes:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).

Great work and thanks for coordinating it!  Thanks also to everyone who
contributed :)

> A tentative release preparation branch 'version-1.4.0' was then created
> from master, where release-specific enhancements can go.  Things broken
> on master as it stands should be fixed there, and we can cherry pick
> these fixes into the release branch.

What exactly would those "release-specific enhancements" be?

Best,
Josselin Poiret

Tensorflow fixes on core-updates-frozen

[Guillaume Le Vaillant]

guix-comm...@gnu.org skribis:

> rekado pushed a change to branch core-updates-frozen
> in repository guix.
>
>  new d503194  gnu: python2-entrypoints: Add missing input.
>  new 672c7a2  gnu: tensorflow: Do not unpack directory.
>  new 6d3439b  gnu: eigen-for-tensorflow: Build with GCC 7.

Hi Ricardo,

Given that the core-update-frozen branch has been merged in master,
can't these fixes be pushed on master directly?


signature.asc
Description: PGP signature

Re: [core-updates-frozen] Tryton broken

[zimoun]

Hi Hartmut,

Sorry for the delay.

On Fri, 03 Dec 2021 at 14:41, Hartmut Goebel  
wrote:

> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=52259>
>
> They can be added on master, too, since they are not dealing with 
> 'sanitiy-check
>
> Question: After approval, shall I push them to core-updates-frozen and 
> or to master?

Now, core-updates-frozen is merged, they can go to master. :-)

However, because ’format-patch’ had been used without the ’--base’
option, and because the Git tree changed, I cannot apply and test your
patches.

Could you rebase them?  I have not tried them but they LGTM so maybe you
can push them modulo typo in patch 3/3.

Thanks for the fix.

Cheers,
simon

Re: core-updates-frozen branch merged

[Mathieu Othacehe]

Hey,

> That's it!  Enjoy the latest additions and improvements, and report any
> issues you encounter!

That's great news! Thanks to all the people that have been involved and
special thanks to you Maxim for your commitment.

Mathieu

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[zimoun]

Hi Maxim,

On Mon, 13 Dec 2021 at 22:20, Maxim Cournoyer  wrote:

> It'll have to be resolved on core-updates :-).

Well, Julia update can happen in master, IMHO.  Even, depending on the
release date, it appears to me doable for the next release. ;-)

Cheers,
simon

Re: core-updates-frozen branch merged

[zimoun]

Hi,

On Mon, 13 Dec 2021 at 20:34, Maxim Cournoyer  wrote:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).
>
> A tentative release preparation branch 'version-1.4.0' was then created
> from master, where release-specific enhancements can go.  Things broken
> on master as it stands should be fixed there, and we can cherry pick
> these fixes into the release branch.

Double yeah! \o/

Thanks for all involved to make it happen.

About the release, what is the draft schedule?

Cheers,
simon

Re: core-updates-frozen branch merged

[Timothy Sample]

Hi Maxim,

Maxim Cournoyer  writes:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).
>
> [...]
>
> That's it!  Enjoy the latest additions and improvements, and report any
> issues you encounter!
>
> Thank you,

Thank you Maxim!  I really appreciate the extra work you put in to get
this finished.  It was not an easy process, but your energy really kept
things moving.  I’ve been a happy c-u-f user for a while now, and the
updates are really terrific!

Here’s hoping the next one will be a little easier.  :)


-- Tim

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi,
>
> First, I am not convinced that upgrade Julia from 1.6.3 to 1.6.4 is
> something to do now; especially when the branch is “frozen”.  Using
> patches #52117 [1], all failures are fixed for 1.6.3.
>
> 1: https://issues.guix.gnu.org/52117
>
>
> Here a rough attempt which replaces the source of 1.6.3 by 1.6.4 and
> many tests are deeply broken (broken precompile is not a good sign, at
> all ;-)).  Well, it seems expected regarding the complexity of the Julia
> stack. :-)
>
> Therefore, the upgrade requires various other upgrades elsewhere and
> probably some fixes with couple of patches.  As it had been for previous
> Julia upgrades. :-)
>
> Then, using this upgraded julia@1.6.4, there is a high probability that
> many julia-* packages would be broken too and thus they would require
> fixes.
>
> IMHO, if we want a working Julia in the delay for the merge, the best
> seems to just apply patch#52117 and let this Julia upgrade for another
> round.  For what my opinion is here. :-)

Seems I had not answered here; thanks for attempting my suggestion!  It
seems you were right that Julia (even for a patch version bump) is
picky.

It'll have to be resolved on core-updates :-).

Thanks,

Maxim

core-updates-frozen branch merged

[Maxim Cournoyer]

Hello Guix!

In case you hadn't taken notice, the core-update-frozen branch was
finally merged into master.  So please reconfigure your remotes to avoid
uploading any further work there :-).

A tentative release preparation branch 'version-1.4.0' was then created
from master, where release-specific enhancements can go.  Things broken
on master as it stands should be fixed there, and we can cherry pick
these fixes into the release branch.

That's it!  Enjoy the latest additions and improvements, and report any
issues you encounter!

Thank you,

Maxim

Re: [core-updates-frozen] Haskell for i686-linux: report

[Timothy Sample]

Hi,

zimoun  writes:

> After some Cuirass monitoring and restarted some unexpected failures,
> the situation for ghc-* on i686-linux is the same as the one from
> current master.

I took a few minutes to triage these.  Most of them are fixable.

> Two packages are broken in core-updates-frozen and not in master:
>
>  1. ghc-ncurses
> https://ci.guix.gnu.org/build/1858160/details

Looks like this is due to an ncurses API update:

https://lists.gnu.org/archive/html/bug-ncurses/2020-08/msg00017.html

AFAICS, both scroll and ghc-ncurses are abandoned.  In the case of
scroll, you could say that it’s “finished” I guess, since it’s a game.
I bet it would work fine if we drop the “KEY_EVENT” line in
“lib/UI/NCurses/Enums.chs”.  Otherwise, we could consider dropping these
two packages.

>  2. ghc-lukko
> https://ci.guix.gnu.org/build/1858215/details

Upstream bug: https://github.com/haskellari/lukko/issues/15

The consensus so far is disable OFD locking on 32-bit platforms using
the “-ofd-locking” configure flag.

> These test suite failures require some investigations.  Many other ghc-*
> packages too:
>
>  - ghc-sha

This one is an out of memory error.  Not sure what to do.

>  - ghc-validty

Upstream bug: https://github.com/NorfairKing/validity/issues/84

There’s a patch there to fix the tests for 32-bit machines.

>  - ghc-bloomfilter

Upstream bug: https://github.com/bos/bloomfilter/issues/7

The tests are bounds checking using an overflowed literal: 0x.
Other distros get rid of the check, but the literal could be fixed, too,
as explained in the bug report.

>  - ghc-tar

Upstream bug: https://github.com/haskell/tar/issues/21 (from rekado!)

There’s no patch from upstream.  It looks like a simple word size
mistake in the tests like ghc-validity or ghc-bloomfilter.

>  - ghc-llvm-hs

Not sure about this one.

>  - ghc-lucid

This one I’ve seen before!  Upstream has trouble with nondeterministic
ordering of output HTML attributes.  I guess running the tests on a
32-bit machine exposes some more of these problems.  Patching the tests
to allow different orders would fix it.

[---]

It would be good to fix these, but it would be better to update our
whole Haskell stack.  That’ll have to be something to attempt once c-u-f
is merged.


-- Tim

[core-updates-frozen] Haskell for i686-linux: report

[zimoun]

Hi,

All related Haskell packages for both x86_64 and i686 in
core-updates-frozen are not blockers for the merge. \o/


After some Cuirass monitoring and restarted some unexpected failures,
the situation for ghc-* on i686-linux is the same as the one from
current master.

Two packages are broken in core-updates-frozen and not in master:

 1. ghc-ncurses
https://ci.guix.gnu.org/build/1858160/details

 2. ghc-lukko
https://ci.guix.gnu.org/build/1858215/details

Therefore, ’scroll’ (because #1) and ’ganeti’ (because #2) are also
broken.


These test suite failures require some investigations.  Many other ghc-*
packages too:

 - ghc-sha
 - ghc-validty
 - ghc-bloomfilter
 - ghc-tar
 - ghc-llvm-hs
 - ghc-lucid

https://ci.guix.gnu.org/search?query=spec%3Acore-updates-frozen+system%3Ai686-linux+status%3Afailed+ghc


Last, note that for x86_64 in core-updates-frozen, ghc-ncurses is also
broken:

https://ci.guix.gnu.org/build/1779259/details


Let merge core-updates-frozen!


Cheers,
simon

Re: [core-updates-frozen] Tryton broken

[Hartmut Goebel]

Hi,
I just sent in patches fixing this issue, see 
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=52259>


They can be added on master, too, since they are not dealing with 
'sanitiy-check


Question: After approval, shall I push them to core-updates-frozen and 
or to master?



--
Regards
Hartmut Goebel

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

Re: [core-updates-frozen] Tryton broken

[Hartmut Goebel]

Hi,

TL;DR: I'll take care of this within the next few days.

Am 01.12.21 um 17:44 schrieb zimoun:

Many thanks for providing this info and the links.



The issue with 'trythond-*' is the new phase `sanity-check' for
python-build-system.


The way trytond modules are intended (by the maintainers) to be 
installed is *very* special.  Thus I'm not astound to find sanity checks 
for end-points failing - end points are simply not supported by trytond 
for trytond modules as one would expect in Python.



Any chance that someone give a look before the merge?  Otherwise,
these broken packages could land to master; which would be sad.


trytond itself and tryton seem okay. So I suggest to remove the phase 
sanity-check to all failing packages due to this check. Hopefully only a 
few trytond- module are effected - those containing scripts.


I'll take care of this within the next few days.

--
Regards
Hartmut Goebel

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

[core-updates-frozen] Tryton broken

[zimoun]

Hi,

The branch core-updates-frozen will be merged soon.  Among some
breakage here or there, one block of broken packages is about 'tryton'
[1]: each points are sorted by alphabetical order, and the mouse on
the red point should provide the name of the package, then click leads
to the evaluation and from there you can access to the list of
dependencies, find the tryton broken one, click again, for instance
trytond-country, and last access to the log [2].

Well, this dashboard allow to quickly see the broken blocks.  To
directly find trytond-country, it is easy to go via:

https://ci.guix.gnu.org/search?query=spec%3Acore-updates-frozen+system%3Ax86_64-linux+trytond-country

The issue with 'trythond-*' is the new phase `sanity-check' for
python-build-system.

Any chance that someone give a look before the merge?  Otherwise,
these broken packages could land to master; which would be sad.

Cheers,
simon

1: <https://ci.guix.gnu.org/eval/50268/dashboard>
2: <https://ci.guix.gnu.org/build/1805859/log/raw>

[core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[zimoun]

Hi,

First, I am not convinced that upgrade Julia from 1.6.3 to 1.6.4 is
something to do now; especially when the branch is “frozen”.  Using
patches #52117 [1], all failures are fixed for 1.6.3.

1: https://issues.guix.gnu.org/52117


Here a rough attempt which replaces the source of 1.6.3 by 1.6.4 and
many tests are deeply broken (broken precompile is not a good sign, at
all ;-)).  Well, it seems expected regarding the complexity of the Julia
stack. :-)

Therefore, the upgrade requires various other upgrades elsewhere and
probably some fixes with couple of patches.  As it had been for previous
Julia upgrades. :-)

Then, using this upgraded julia@1.6.4, there is a high probability that
many julia-* packages would be broken too and thus they would require
fixes.

IMHO, if we want a working Julia in the delay for the merge, the best
seems to just apply patch#52117 and let this Julia upgrade for another
round.  For what my opinion is here. :-)


Cheers,
simon



--8<---cut here---start->8---
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/jl_kkDGDX/Foo4b3a94a1a081a8cb.jl:109
  Expression: g() === 2.0
   Evaluated: 97.0 === 2.0
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:240
  Expression: Foo.ptr2 === Ptr{UInt8}(0)
   Evaluated: Ptr{UInt8} @0x0001 === Ptr{UInt8} @0x
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:242
  Expression: Foo.layout1::Vector{Ptr{Int8}} == Ptr{Int8}[Ptr{Int8}(0), 
Ptr{Int8}(0), Ptr{Int8}(-1)]
   Evaluated: Ptr{Int8}[Ptr{Int8} @0x, Ptr{Int8} 
@0x0001, Ptr{Int8} @0x] == Ptr{Int8}[Ptr{Int8} 
@0x, Ptr{Int8} @0x, Ptr{Int8} 
@0x]
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:243
  Expression: Foo.layout2 == Any[Ptr{Int8}(0), Ptr{Int16}(0), Ptr{Int32}(-1)]
   Evaluated: Any[Ptr{Int8} @0x, Ptr{Int16} 
@0x0001, Ptr{Int32} @0x] == Any[Ptr{Int8} 
@0x, Ptr{Int16} @0x, Ptr{Int32} 
@0x]
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:269
  Expression: ms isa Array{Any, 1}
   Evaluated: ErrorException("Required dependency FooBase4b3a94a1a081a8cb 
[top-level] failed to load from a cache file.") isa Vector{Any}
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:267
  Expression: begin
ms = Base._require_from_serialized(cachefile)
#= /tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:269 =# 
@test ms isa Array{Any, 1}
end
   Evaluated: Test.LogRecord[]
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/usr/share/julia/stdlib/v1.6/Test/src/Test.jl:671
  Expression: contains_warn(read(fname, String), $(Expr(:escape, "@ccallable 
was already defined for this method name")))
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:291
  Expression: modules == [Base.PkgId(Foo) => Base.module_build_id(Foo)]
   Evaluated: Pair{Base.PkgId, UInt64}[Foo4b3a94a1a081a8cb [top-level] => 
0x000714cda79c2f8a] == Pair{Base.PkgId, UInt64}[Foo4b3a94a1a081a8cb [top-level] 
=> 0x000714cdcc92a9f5]
Error in testset precompile:
Test Failed at 
/tmp/guix-build-julia-1.6.4.drv-0/julia-1.6.4/test/precompile.jl:304
  Expression: Dict(modules) == merge(Dict((let m = Base.PkgId(s)
m => Base.module_build_id(Base.root_module(m))
end for s = ["Base", "Core", "Main", string(Foo2_module), 
string(FooBase_module)])), Dict((let m = Base.root_module(Base, s)
Base.PkgId(m) => Base.module_build_id(m)
end for s = [:ArgTools, :Artifacts, :Base64, :CRC32c, :Dates, 
:DelimitedFiles, :Distributed, :Downloads, :FileWatching, :Future, 
:InteractiveUtils, :LazyArtifacts, :LibCURL, :LibCURL_jll, :LibGit2, :Libdl, 
:LinearAlgebra, :Logging, :Markdown, :Mmap, :MozillaCACerts_jll, 
:NetworkOptions, :Pkg, :Printf, :Profile, :p7zip_jll, :REPL, :Random, :SHA, 
:Serialization, :SharedArrays, :Sockets, :SparseArrays, :Statistics, 
:SuiteSparse, :TOML, :Tar, :Test, :UUIDs, :Unicode, :nghttp2_jll])))
   Evaluated: Dict{Base.PkgId, UInt64}(Future 
[9fa8497b-333b-5362-9e8d-4d0656e87820] => 0x00071396ddcbf382, p7zip_jll 
[3f19e933-33d8-53b3-aaab-bd5110c3b7a0] => 0x00071399314d1416, FileWatching 
[7b1f6079-737a-58dc-b8bc-7a2ca5c1b5ee] => 0x000713941e0295e8, Profile 
[9abbd945-dff8-562f-b5e8-e1ebf5ef1b79] => 0x000713973b8b20ed, UUIDs 
[cf7118a7-6976-5b1a-9a39-7adc72f591a4] => 0x00071397dc9eef34, 
MozillaCACerts_jll [14a3606d-f60d-562e-9121-12d972cd8159] => 
0x0007139902e9e715, Logging 

Re: ‘core-updates-frozen’: julia status update

[zimoun]

Hi,

On Thu, 25 Nov 2021 at 03:13, zimoun  wrote:

> I am currently rebuilding all the julia-* packages.  It is high probable
> some are now broken.  But it appears to me not a blocker for the
> merge.

All is fixed in patch#52117 [1].  After this hacking session,

 1. The package julia uses parallelism to build, i.e., it requires much
much less time to build; something like 5x speedup on Berlin.

 2. The julia-build-system runs the tests with some degree of
parallelism.  The speedup depends on each ’test/runtests.jl’ script
provided by the package julia-* itself.

The strong issues to tackle are:

 a) bug#22304: build julia package with reproducible
 b) bug#47354: build julia-* packages reproducible


1: 
2: 
3: 


Cheers,
simon

‘core-updates-frozen’: julia status

[zimoun]

Hi,

On Mon, 22 Nov 2021 at 15:13, Maxim Cournoyer  wrote:
> zimoun  writes:

>> Julia is annoying,  Because the test suite sometimes passes, sometimes
>> not.  Well, I am not even sure it is the same part that fails.  I
>> notice that "guix build julia --without-tests=julia" then "guix build
>> julia" tends to works. :-)
>>
>> Any idea to debug this?
>
> No idea how to debug this, but when faced with nondeterministic tests,
> here's how I proceed:
>
> 1. Report them upstream.
> 2. Disable the problematic tests.  You may need to disable a whole test suite 
> of
> similarly faulted tests, if they all behave the same.

After this hacking day, Julia builds deterministically* on
core-updates-frozen.  Along the way, now the test suite runs in parallel
which reduces a lot the feedback loop. :-) And a variant of the current
patch of julia source is upstream PR.

*deterministically: at least on 2 machines. ;-)

One or two failing tests randomly failing should be investigated and
probably reported upstream.

The test suite of julia-* packages supports also (more or less) some
parallelism.  From my understanding, the limitation comes from the
script 'test/runtests.jl' from each package; each implements more or
less some parallelism.  Now, the environment variable JULIA_CPU_THREADS
is set but Julia does not always honor it as its doc specifies – see the
patch fixing the parallelism of Julia test suite ;-).  Therefore, the
test suite of each package is launched with
'--procs=(parallel-job-count)' and Julia exploits at best the available
workers.

I am currently rebuilding all the julia-* packages.  It is high probable
some are now broken.  But it appears to me not a blocker for the merge.

On a side note, Julia is not currently reproducible [1] and
'julia-build-system' neither [2].  Therefore, probable non-reproducible
build introduced by parallelism is currently not the point, IMHO.



Thanks Maxim for the help and the good vibes to tackle that.

Cheers,
simon

1: <http://issues.guix.gnu.org/issue/22304>
2: <http://issues.guix.gnu.org/issue/47354>

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hi Josselin,

Josselin Poiret  writes:

> Maxim Cournoyer  writes:
>
> at it throws, after adding the missing polkit export:
>>
>> --8<---cut here---start->8---
>> $ ./pre-inst-env guix build  -s aarch64-linux gnome-control-center -n
>> guix build: error: gnu/packages/gnome.scm:5299:2: package
>> `colord-minimal@1.4.5' has an invalid input: ("polkit"
>> #)
>> --8<---cut here---end--->8---
>
> Since polkit is now syntax, it needs to be expanded before being
> compiled at all its uses, however guile (and our build system) doesn't
> automatically recompile all .scm files that use the changed definition.

That's the impression I got after realizing the fix.  Is there an open
issue about this shortcoming in Guile?  I think that's where a fix
should go.

> A simple `rm $(grep --include=\*.go -rl polkit .)` in the root of the
> checkout, followed by a `make` did it for me.

Thanks for the tip!

> As a side note, I'm also investigating that sddm error today.

Awesome!

Thank you,

Maxim

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[zimoun]

Hi,

On Mon, 22 Nov 2021 at 15:13, Maxim Cournoyer  wrote:

> 2. Disable the problematic tests.  You may need to disable a whole test suite 
> of
> similarly faulted tests, if they all behave the same.

I am becoming crazy…  For instance this test randomly* fails:

@test mul!(C, vf, transpose(vf), 2, 3) == 2vf*vf' .+ 3C0



Therefore, I add,

--8<---cut here---start->8---
(substitute* "stdlib/LinearAlgebra/test/matmul.jl" 
  (("@test mul\\!\\(C, vf, transpose\\(vf\\), 2, 3\\) == 2vf\\*vf' 
\\.+ 3C0") 
   "@test_broken @test mul!(C, vf, transpose(vf), 2, 3) == 2vf*vf' 
.+ 3C0")
(substitute* "test/math.jl" 
  (("@test isinf\\(log1p\\(-one\\(T\\)\\)\\)")
   "@test_broken isinf(log1p(-one(T)))"
--8<---cut here---end--->8---

So far, so good.  Then I get:

--8<---cut here---start->8---
Error During Test at 
/tmp/guix-build-julia-1.6.3.drv-0/julia-1.6.3/test/math.jl:278
 Unexpected Pass 
Expression: isinf(log1p(-(one(T
 Got correct result, please change to @test if no longer broken.
--8<---cut here---end--->8---

and thus the build is reported as failed.  Argh!!  Ok, because these 2
tests are random, I replace the snippet above by:

--8<---cut here---start->8---
(substitute* "stdlib/LinearAlgebra/test/matmul.jl" 
  (("@test mul\\!\\(C, vf, transpose\\(vf\\), 2, 3\\) == 2vf\\*vf' 
\\.+ 3C0") 
   "")
(substitute* "test/math.jl" 
  (("@test isinf\\(log1p\\(-one\\(T\\)\\)\\)")
   ""
--8<---cut here---end--->8---

And now, something magical happens, I get this error with parenthesis:

--8<---cut here---start->8---
Test Failed at 
/tmp/guix-build-julia-1.6.3.drv-0/julia-1.6.3/usr/share/julia/stdlib/v1.6/LinearAlgebra/test/matmul.jl:155
Expression: mul!(C, vf, transpose(vf), 2, 3) == (2vf) * vf' .+ 3C0
--8<---cut here---end--->8---

What?!  And AFAIU, it is not in the test suite.

Do I miss something with ’substitute*’?


Cheers,
simon

*randomly: because I do not know why, nothing is random with
 computer. ;-)

PS: Note that current Julia master contains this test:

@test mul!(C, vf, transpose(vf), 2, 3) ≈ 2vf*vf' .+ 3C0

https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/test/matmul.jl#L155

I am trying to ’substitute*’ with that.  Then I give up for now.

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

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

Maxim Cournoyer  writes:

at it throws, after adding the missing polkit export:
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build  -s aarch64-linux gnome-control-center -n
> guix build: error: gnu/packages/gnome.scm:5299:2: package 
> `colord-minimal@1.4.5' has an invalid input: ("polkit" # polkit>)
> --8<---cut here---end--->8---

Since polkit is now syntax, it needs to be expanded before being
compiled at all its uses, however guile (and our build system) doesn't
automatically recompile all .scm files that use the changed definition.

A simple `rm $(grep --include=\*.go -rl polkit .)` in the root of the
checkout, followed by a `make` did it for me.

As a side note, I'm also investigating that sddm error today.

Best,
Josselin Poiret

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hi Thiago,

Thiago Jung Bauermann  writes:

[...]

> IIUC it’s a bug to test (%current-system) before
> (%current-target-system). That’s because the latter is only defined
> for cross-builds, while the former is always defined. So in practice
> (%current-target-system) will never be checked.

Oh, good catch!  I've fixed it in the patch I just sent in my earlier
reply to Ludovic.

Thank you,

Maxim

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> gnu: polkit: Define polkit package variable based on architecture.
>>
>> * gnu/packages/polkit.scm (polkit): Rename to...
>> (polkit*): ... this.
>> (polkit-duktape): Adjust to inherit from polkit*.
>> (polkit-for-system): New procedure.
>> (polkit): New variable.
>
> LGTM!
>
>> But my "test" fails the same:
>>
>> $ ./pre-inst-env guix build --system=aarch64-linux \
>> -e '(@ (gnu packages polkit) polkit)' -n |& grep polkit
>> /gnu/store/dw11y85xfsb8hcg7w2cw57f1xfs4i74m-polkit-0.120.drv
>> /gnu/store/ric7yf4ra2p14p29fwsh18m1nakciakv-polkit-0.120.tar.xz
>
> That’s expected because here you’re effectively calling
> (%current-system) from the top level, and that’s x86_64.
>
> A good test is to try and build one of its dependents:
>
>   guix build -s aarch64-linux gnome-control-center -n
>
> should list polkit-duktape.

Arf, here's what it throws, after adding the missing polkit export:

--8<---cut here---start->8---
$ ./pre-inst-env guix build  -s aarch64-linux gnome-control-center -n
guix build: error: gnu/packages/gnome.scm:5299:2: package 
`colord-minimal@1.4.5' has an invalid input: ("polkit" #)
--8<---cut here---end------->8---

I don't see how it's different from pkg-config... Ideas?

> Are we done and ready for merging once this patch has been applied to
> ‘core-updates-frozen’?

Mostly, after applying fixes from jpoiret for GDM icons I believe
(thanks!); I'll also have to debug why my GDM-less desktop won't allow
me to login anymore (https://issues.guix.gnu.org/52051).

Thank you!

Maxim

>From 48730390fbfa618216c9e8db65643755ff585175 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Sun, 21 Nov 2021 22:20:35 -0500
Subject: [PATCH] gnu: polkit: Define polkit package variable based on
 architecture.

* gnu/packages/polkit.scm (polkit): Rename to...
(polkit*): ... this.
(polkit-duktape): Adjust to inherit from polkit*.
(polkit-for-system): New procedure.
(polkit): New variable.
---
 gnu/packages/polkit.scm | 76 ++---
 1 file changed, 48 insertions(+), 28 deletions(-)

diff --git a/gnu/packages/polkit.scm b/gnu/packages/polkit.scm
index c9edc53cf5..a1bf9786fd 100644
--- a/gnu/packages/polkit.scm
+++ b/gnu/packages/polkit.scm
@@ -29,6 +29,7 @@ (define-module (gnu packages polkit)
   #:use-module ((guix licenses) #:select (lgpl2.0+))
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix memoization)
   #:use-module (guix utils)
   #:use-module (guix build utils)
   #:use-module (guix build-system cmake)
@@ -46,9 +47,10 @@ (define-module (gnu packages polkit)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages qt)
-  #:use-module (gnu packages xml))
+  #:use-module (gnu packages xml)
+  #:export (polkit))
 
-(define-public polkit
+(define-public polkit*
   (package
 (name "polkit")
 (version "0.120")
@@ -151,32 +153,50 @@ (define-public polkit
 ;;; Variant of polkit built with Duktape, a lighter JavaScript engine compared
 ;;; to mozjs.
 (define-public polkit-duktape
-  (package/inherit polkit
-(name "polkit-duktape")
-(source
- (origin
-   (inherit (package-source polkit))
-   (patches
-(append
-(search-patches "polkit-use-duktape.patch")
-(origin-patches (package-source polkit))
-(arguments
- (substitute-keyword-arguments (package-arguments polkit)
-   ((#:configure-flags flags)
-`(cons "--with-duktape" ,flags))
-   ((#:phases phases)
-`(modify-phases ,phases
-   (add-after 'unpack 'force-gnu-build-system-bootstrap
- (lambda _
-   (delete-file "configure")))
-(native-inputs
- (append `(("autoconf" ,autoconf)
-   ("automake" ,automake)
-   ("libtool" ,libtool)
-   ("pkg-config" ,pkg-config))
- (package-native-inputs polkit)))
-(inputs (alist-replace "mozjs" `(,duktape)
-   (package-inputs polkit)
+  (let ((base polkit*))
+(package/inherit base
+  (name "polkit-duktape")
+  (source
+   (origin
+ (inherit (package-source base))
+ (patches
+  (append
+  (search-patches "polkit-use-duktape.patch")
+  (origin-patches (package-source base))
+  (arguments
+   (substitute-keyword-arguments (package-arguments base)
+ ((#:configure-flags flags)
+  `(cons "--with-duktape" ,flags))
+ ((#:phases phases)
+   

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Thiago Jung Bauermann]

Hello,

Em terça-feira, 23 de novembro de 2021, às 14:18:10 -03, Ludovic Courtès 
escreveu:
> > But my "test" fails the same:
> > 
> > $ ./pre-inst-env guix build --system=aarch64-linux \
> > 
> > -e '(@ (gnu packages polkit) polkit)' -n |& grep polkit
> > 
> > /gnu/store/dw11y85xfsb8hcg7w2cw57f1xfs4i74m-polkit-0.120.drv
> > /gnu/store/ric7yf4ra2p14p29fwsh18m1nakciakv-polkit-0.120.tar.xz
> 
> That’s expected because here you’re effectively calling
> (%current-system) from the top level, and that’s x86_64.
> 
> A good test is to try and build one of its dependents:
> 
>   guix build -s aarch64-linux gnome-control-center -n
> 
> should list polkit-duktape.
> 
> HTH!

Sorry, I should have taken a closer look at this patch yesterday. IIUC it’s 
a bug to test (%current-system) before (%current-target-system). That’s 
because the latter is only defined for cross-builds, while the former is 
always defined. So in practice (%current-target-system) will never be 
checked.

This what patch 1 in the series at https://issues.guix.gnu.org/49672 fixes.
Rebasing it and addressing Maxime’s comments is on my todo list.

> Are we done and ready for merging once this patch has been applied to
> ‘core-updates-frozen’?

Hooray! I’m currently investigating a problem with lualatex (issue 51252). 
I don’t know whether it’s serious enough to delay the merge.

-- 
Thanks,
Thiago

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> gnu: polkit: Define polkit package variable based on architecture.
>
> * gnu/packages/polkit.scm (polkit): Rename to...
> (polkit*): ... this.
> (polkit-duktape): Adjust to inherit from polkit*.
> (polkit-for-system): New procedure.
> (polkit): New variable.

LGTM!

> But my "test" fails the same:
>
> $ ./pre-inst-env guix build --system=aarch64-linux \
> -e '(@ (gnu packages polkit) polkit)' -n |& grep polkit
> /gnu/store/dw11y85xfsb8hcg7w2cw57f1xfs4i74m-polkit-0.120.drv
> /gnu/store/ric7yf4ra2p14p29fwsh18m1nakciakv-polkit-0.120.tar.xz

That’s expected because here you’re effectively calling
(%current-system) from the top level, and that’s x86_64.

A good test is to try and build one of its dependents:

  guix build -s aarch64-linux gnome-control-center -n

should list polkit-duktape.

HTH!

Are we done and ready for merging once this patch has been applied to
‘core-updates-frozen’?

Thanks,
Ludo’.

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hello again,

I've now tried this:

--8<---cut here---start->8---
gnu: polkit: Define polkit package variable based on architecture.

* gnu/packages/polkit.scm (polkit): Rename to...
(polkit*): ... this.
(polkit-duktape): Adjust to inherit from polkit*.
(polkit-for-system): New procedure.
(polkit): New variable.

1 file changed, 44 insertions(+), 27 deletions(-)
gnu/packages/polkit.scm | 71 
---

modified   gnu/packages/polkit.scm
@@ -48,7 +48,7 @@ (define-module (gnu packages polkit)
   #:use-module (gnu packages qt)
   #:use-module (gnu packages xml))
 
-(define-public polkit
+(define-public polkit*
   (package
 (name "polkit")
 (version "0.120")
@@ -151,32 +151,49 @@ (define-public polkit
 ;;; Variant of polkit built with Duktape, a lighter JavaScript engine compared
 ;;; to mozjs.
 (define-public polkit-duktape
-  (package/inherit polkit
-(name "polkit-duktape")
-(source
- (origin
-   (inherit (package-source polkit))
-   (patches
-(append
-(search-patches "polkit-use-duktape.patch")
-(origin-patches (package-source polkit))
-(arguments
- (substitute-keyword-arguments (package-arguments polkit)
-   ((#:configure-flags flags)
-`(cons "--with-duktape" ,flags))
-   ((#:phases phases)
-`(modify-phases ,phases
-   (add-after 'unpack 'force-gnu-build-system-bootstrap
- (lambda _
-   (delete-file "configure")))
-(native-inputs
- (append `(("autoconf" ,autoconf)
-   ("automake" ,automake)
-   ("libtool" ,libtool)
-   ("pkg-config" ,pkg-config))
- (package-native-inputs polkit)))
-(inputs (alist-replace "mozjs" `(,duktape)
-   (package-inputs polkit)
+  (let ((base polkit*))
+(package/inherit base
+  (name "polkit-duktape")
+  (source
+   (origin
+ (inherit (package-source base))
+ (patches
+  (append
+  (search-patches "polkit-use-duktape.patch")
+  (origin-patches (package-source base))
+  (arguments
+   (substitute-keyword-arguments (package-arguments base)
+ ((#:configure-flags flags)
+  `(cons "--with-duktape" ,flags))
+ ((#:phases phases)
+  `(modify-phases ,phases
+ (add-after 'unpack 'force-gnu-build-system-bootstrap
+   (lambda _
+ (delete-file "configure")))
+  (native-inputs
+   (append `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("libtool" ,libtool)
+ ("pkg-config" ,pkg-config))
+   (package-native-inputs base)))
+  (inputs (alist-replace "mozjs" `(,duktape)
+ (package-inputs base))
+
+
+(define (polkit-for-system system)
+  "Return a polkit package that can be built for SYSTEM; that is, either the
+regular polkit that requires mozjs or its duktape variant."
+  (if (string-prefix? "x86_64" system)
+  polkit*
+  polkit-duktape))
+
+;;; Define a top level polkit variable that can be built on any of the
+;;; supported platforms.  This is to work around the fact that our
+;;; mrustc-bootstrapped rust toolchain currently only supports the x86_64
+;;; architecture.
+(define-syntax polkit
+  (identifier-syntax (polkit-for-system
+  (or (%current-system) (%current-target-system)
 
 (define-public polkit-qt
   (package
--8<---cut here---end--->8---

But my "test" fails the same:

--8<---cut here---start->8---
$ ./pre-inst-env guix build --system=aarch64-linux \
-e '(@ (gnu packages polkit) polkit)' -n |& grep polkit
/gnu/store/dw11y85xfsb8hcg7w2cw57f1xfs4i74m-polkit-0.120.drv
/gnu/store/ric7yf4ra2p14p29fwsh18m1nakciakv-polkit-0.120.tar.xz
--8<---cut here---end--->8---

I'd have expected to see 'polkit-duktape' as the name of the package in
the output.

Thanks,

Maxim

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> +;;; Define a top level polkit variable that can be built on any of the
>> +;;; supported platforms.  This is to work around the fact that our
>> +;;; mrustc-bootstrapped rust toolchain currently only supports the x86_64
>> +;;; architecture...
>> +(define-public polkit
>> +  (if (string-prefix? "x86_64"
>> +  (or (%current-system) (%current-target-system)))
>> +  polkit*
>> +  polkit-duktape))
>
> This would instead have to be a macro, similar to the ‘pkg-config’
> macro, so that (%current-system) is checked at the right time rather
> than when loading this module.

Thanks for tipping in!

> However, since the only different between polkit and polkit-duktape
> (IIUC) is that an extra patch is applied for the latter, I would instead
> suggest adding a conditional build phase that applies the patch on
> non-x86_64 systems.

I'd still rather keep the distinct package approach, so that x86* users
may still find about polkit-duktape and use it instead of polkit (via
input rewriting) if they so wish.

Thanks,

Maxim

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[Maxim Cournoyer]

Hello,

zimoun  writes:

> Hi Ludo,
>
> On Mon, 22 Nov 2021 at 14:21, Ludovic Courtès  wrote:
>
>> >> … there’s probably more.
>
> Julia is annoying,  Because the test suite sometimes passes, sometimes
> not.  Well, I am not even sure it is the same part that fails.  I
> notice that "guix build julia --without-tests=julia" then "guix build
> julia" tends to works. :-)
>
> Any idea to debug this?

No idea how to debug this, but when faced with nondeterministic tests,
here's how I proceed:

1. Report them upstream.
2. Disable the problematic tests.  You may need to disable a whole test suite of
similarly faulted tests, if they all behave the same.

Thanks,

Maxim

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Ludovic Courtès  writes:


Hi,

Ricardo Wurmus  skribis:


on the core-updates-frozen branch we have a minor problem:
python-numpy has been upgraded to 1.21, but python-numba can 
only 
be built with 1.20[1].  I added python-numpy-1.20 and made

python-numba use it.


How big of an effort would it be to modify numba so that it 
works with

1.21?  With luck, that effort has already been made upstream?


I spoke too soon: 
https://github.com/numba/numba/issues/7175#issuecomment-975470113


 “Numba 0.55 release candidates will be out within the next week 
 or so (hopefully!), these will have NumPy 1.21.x series 
 support.”


So soon after the merge we will be able to switch back to numpy 
1.21 as the default.


--
Ricardo

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Hi,

Ludovic Courtès  writes:


Ricardo Wurmus  skribis:


on the core-updates-frozen branch we have a minor problem:
python-numpy has been upgraded to 1.21, but python-numba can 
only 
be built with 1.20[1].  I added python-numpy-1.20 and made

python-numba use it.


How big of an effort would it be to modify numba so that it 
works with

1.21?  With luck, that effort has already been made upstream?


It hasn’t.  Upstream doesn’t seem to know exactly how to 
accomplish this.  There’s a breaking change in numpy (something 
relating to typing of ufuncs) and it leads to incorrect type 
errors in numba AFAIU.  This is not something I’d feel comfortable 
just hacking around.


--
Ricardo

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[zimoun]

Hi Ludo,

On Mon, 22 Nov 2021 at 14:21, Ludovic Courtès  wrote:

> >> … there’s probably more.

Julia is annoying,  Because the test suite sometimes passes, sometimes
not.  Well, I am not even sure it is the same part that fails.  I
notice that "guix build julia --without-tests=julia" then "guix build
julia" tends to works. :-)

Any idea to debug this?


Cheers,
simon

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> +;;; Define a top level polkit variable that can be built on any of the
> +;;; supported platforms.  This is to work around the fact that our
> +;;; mrustc-bootstrapped rust toolchain currently only supports the x86_64
> +;;; architecture...
> +(define-public polkit
> +  (if (string-prefix? "x86_64"
> +  (or (%current-system) (%current-target-system)))
> +  polkit*
> +  polkit-duktape))

This would instead have to be a macro, similar to the ‘pkg-config’
macro, so that (%current-system) is checked at the right time rather
than when loading this module.

However, since the only different between polkit and polkit-duktape
(IIUC) is that an extra patch is applied for the latter, I would instead
suggest adding a conditional build phase that applies the patch on
non-x86_64 systems.

How does that sound?

Ludo’.

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> on the core-updates-frozen branch we have a minor problem:
> python-numpy has been upgraded to 1.21, but python-numba can only 
> be built with 1.20[1].  I added python-numpy-1.20 and made
> python-numba use it.

How big of an effort would it be to modify numba so that it works with
1.21?  With luck, that effort has already been made upstream?

Ludo’.

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> … there’s probably more.
>
> I noticed that we’re still using PYTHONPATH in a bunch of places, even
> though we should now be using GUIX_PYTHONPATH.  I’ve been slowly
> hacking away at the remaining offenders.

I see you fixed a bunch of them, yay!

> That said, it’s amazing how much progress we made in so little time!
> I’ll continue to prioritize core-updates-frozen for the next few days.

Yes, let’s do that.  I’ve fixed things I’ll probably never ever use,
like trytond.  A call to everyone though: make sure your favorite
packages work because you can’t necessarily count on others to test it
and fix it.  :-)

I’ve noticed Python packages still failing so if you rely on Python,
better be safe than sorry.

>>> Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great to
>>> have
>>> that branch finally merged in ‘master’ by then?
>>
>> Sounds doable, let’s keep up the good work!
>
> I hope we can make it!

Yup, let’s see!

Ludo’.

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Thiago Jung Bauermann  skribis:
>
>> Em quinta-feira, 11 de novembro de 2021, às 15:23:37 -03, Maxim Cournoyer 
>> escreveu:
>>> Hello Guix!
>>> 
>>> I've finally merged the core-updates-frozen-batched-changes to
>>> core-updates-frozen. 
>>
>> Hooray!
>>
>>> One thing we could do in the meantime is to replace our polkit package
>>> with polkit-duktape, which uses an (unmerged) patch to build polkit
>>> against duktape rather than mozjs [1].  The patch seems to have garnered
>>> some attention recently.  This would enable to build GTK and parts of
>>> GNOME without rust, I believe.
>>
>> I’d suggest replacing polkit with polkit-duktape only for non-x86_64 
>> architectures. What do you think?¨
>
> Yes, that seems like the most reasonable option.

How do we do this, though?

I tried to make it so that referring to the 'polkit' *variable* would
always expand to something supported (switching between vanilla polkit
and polkit-duktape variant based on the system):

--8<---cut here---start->8---
1 file changed, 38 insertions(+), 27 deletions(-)
gnu/packages/polkit.scm | 65 
++---

modified   gnu/packages/polkit.scm
@@ -48,7 +48,7 @@ (define-module (gnu packages polkit)
   #:use-module (gnu packages qt)
   #:use-module (gnu packages xml))
 
-(define-public polkit
+(define-public polkit*
   (package
 (name "polkit")
 (version "0.120")
@@ -151,32 +151,43 @@ (define-public polkit
 ;;; Variant of polkit built with Duktape, a lighter JavaScript engine compared
 ;;; to mozjs.
 (define-public polkit-duktape
-  (package/inherit polkit
-(name "polkit-duktape")
-(source
- (origin
-   (inherit (package-source polkit))
-   (patches
-(append
-(search-patches "polkit-use-duktape.patch")
-(origin-patches (package-source polkit))
-(arguments
- (substitute-keyword-arguments (package-arguments polkit)
-   ((#:configure-flags flags)
-`(cons "--with-duktape" ,flags))
-   ((#:phases phases)
-`(modify-phases ,phases
-   (add-after 'unpack 'force-gnu-build-system-bootstrap
- (lambda _
-   (delete-file "configure")))
-(native-inputs
- (append `(("autoconf" ,autoconf)
-   ("automake" ,automake)
-   ("libtool" ,libtool)
-   ("pkg-config" ,pkg-config))
- (package-native-inputs polkit)))
-(inputs (alist-replace "mozjs" `(,duktape)
-   (package-inputs polkit)
+  (let ((base polkit*))
+(package/inherit base
+  (name "polkit-duktape")
+  (source
+   (origin
+ (inherit (package-source base))
+ (patches
+  (append
+  (search-patches "polkit-use-duktape.patch")
+  (origin-patches (package-source base))
+  (arguments
+   (substitute-keyword-arguments (package-arguments base)
+ ((#:configure-flags flags)
+  `(cons "--with-duktape" ,flags))
+ ((#:phases phases)
+  `(modify-phases ,phases
+ (add-after 'unpack 'force-gnu-build-system-bootstrap
+   (lambda _
+ (delete-file "configure")))
+  (native-inputs
+   (append `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("libtool" ,libtool)
+ ("pkg-config" ,pkg-config))
+   (package-native-inputs base)))
+  (inputs (alist-replace "mozjs" `(,duktape)
+ (package-inputs base))
+
+;;; Define a top level polkit variable that can be built on any of the
+;;; supported platforms.  This is to work around the fact that our
+;;; mrustc-bootstrapped rust toolchain currently only supports the x86_64
+;;; architecture...
+(define-public polkit
+  (if (string-prefix? "x86_64"
+  (or (%current-system) (%current-target-system)))
+  polkit*
+  polkit-duktape))
 
 (define-public polkit-qt
   (package
--8<---cut here---end--->8---

it builds, and doesn't seem to break things, but:

--8<---cut here---start->8---
$ ./pre-inst-env guix build --system=aarch64-linux \
-e '(@ (gnu packages polkit) polkit)' -n \
|& grep polkit
/gnu/store/dw11y85xfsb8hcg7w2cw57f1xfs4i74m-polkit-0.120.drv
/gnu/store/ric7yf4ra2p14p29fwsh18m1nakciakv-polkit-0.120.tar.xz
--8<---cut here---end--->8---

suggests it isn't working.

Ideas?

Thanks!

Maxim

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[zimoun]

Hi Ricardo,

On Sat, 20 Nov 2021 at 10:42, Ricardo Wurmus  wrote:

> on the core-updates-frozen branch we have a minor problem: 
> python-numpy has been upgraded to 1.21, but python-numba can only 
> be built with 1.20[1].  I added python-numpy-1.20 and made 
> python-numba use it.

I think the upgrade of Numpy had been a mistake.  All the Python
scientific stack has to be upgraded in one go.  From my understanding,
it is the same issue as Haskell and LTS, for instance.  As Lars said,
try to have several versions would probably lead to a mess with weird
behaviours difficult to debug; from my understanding.

The best is to downgrades python-numpy to 1.20 (potentially 1.20.3
released on May 2021, that’s not that old :-)) and wait python-numba
works with Numpy 1.21.  IMHO.


Cheers,
simon

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Lars-Dominik Braun  writes:


Hello Ricardo,

So… since numpy 1.20 is the exception here, could we perhaps … 
rename it?  And then have python-numba import that renamed 
module 
“totally-not-numpy” instead of “numpy”?  Could we thus avoid 
this 
conflict?  If renaming is an option — how would it be done?  Is 
it 
enough to rename the “numpy” directory with “numpy-1.20”, the 
“numpy.py” file with “numpy-1.20.py”, and then update all 
“import” 
statements both by numpy itself and by python-numba?
I feel this is a dangerous idea. Python is dynamically typed and 
if we
– somehow – end up with objects from both, numpy 1.20 and numpy 
1.21
in the same program, which can still happen when renaming, 
things may
go wrong very badly. [1] says versions 1.* are ABI compatible, 
but the
API changes between releases, which is probably why numba cannot 
be used

with a newer numpy.

Can we rewrite the entire graph to use numpy 1.20 whenever a 
package

imports numba?


After a quick discussion on IRC we decided to make 1.20 the 
default and keep 1.21 as python-numpy-next.  Let’s hope we can 
switch to 1.21 for good soon.


--
Ricardo

Re: [core-updates-frozen] Different variants of Python packages in the same profile?

[Lars-Dominik Braun]

Hello Ricardo,

> So… since numpy 1.20 is the exception here, could we perhaps … 
> rename it?  And then have python-numba import that renamed module 
> “totally-not-numpy” instead of “numpy”?  Could we thus avoid this 
> conflict?  If renaming is an option — how would it be done?  Is it 
> enough to rename the “numpy” directory with “numpy-1.20”, the 
> “numpy.py” file with “numpy-1.20.py”, and then update all “import” 
> statements both by numpy itself and by python-numba?
I feel this is a dangerous idea. Python is dynamically typed and if we
– somehow – end up with objects from both, numpy 1.20 and numpy 1.21
in the same program, which can still happen when renaming, things may
go wrong very badly. [1] says versions 1.* are ABI compatible, but the
API changes between releases, which is probably why numba cannot be used
with a newer numpy.

Can we rewrite the entire graph to use numpy 1.20 whenever a package
imports numba?

Cheers,
Lars

[1] https://numpy.org/devdocs/user/depending_on_numpy.html

[core-updates-frozen] Different variants of Python packages in the same profile?

[Ricardo Wurmus]

Hi Guix,

on the core-updates-frozen branch we have a minor problem: 
python-numpy has been upgraded to 1.21, but python-numba can only 
be built with 1.20[1].  I added python-numpy-1.20 and made 
python-numba use it.


Now the problem I have is that numba is used with other packages 
(such as python-scikit-learn) that build with the latest numpy. 
An example is python-umap-learn, which propagates both 
python-numba (with python-numpy-1.20) and python-scikit-learn 
(with python-numpy).  This doesn’t work because Python only knows 
about the name “numpy” and will pick the first matching module on 
the load path.


So… since numpy 1.20 is the exception here, could we perhaps … 
rename it?  And then have python-numba import that renamed module 
“totally-not-numpy” instead of “numpy”?  Could we thus avoid this 
conflict?  If renaming is an option — how would it be done?  Is it 
enough to rename the “numpy” directory with “numpy-1.20”, the 
“numpy.py” file with “numpy-1.20.py”, and then update all “import” 
statements both by numpy itself and by python-numba?


I’d like to fix this before merging core-updates-frozen, as this 
affects at least 16 bioinformatics packages and working around 
this will be difficult for users.


--
Ricardo

[1]: https://github.com/numba/numba/issues/7176

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[Ricardo Wurmus]

Ludovic Courtès  writes:


… there’s probably more.


I noticed that we’re still using PYTHONPATH in a bunch of places, 
even though we should now be using GUIX_PYTHONPATH.  I’ve been 
slowly hacking away at the remaining offenders.


That said, it’s amazing how much progress we made in so little 
time!  I’ll continue to prioritize core-updates-frozen for the 
next few days.


Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great 
to have

that branch finally merged in ‘master’ by then?


Sounds doable, let’s keep up the good work!


I hope we can make it!

--
Ricardo

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[Ludovic Courtès]

Hi there!

Ludovic Courtès  skribis:

> I hereby declare tomorrow, Thursday Nov. 18th, day of the on-line
> ‘core-updates-frozen’ sprint!

I’d like to congratulate ourselves and call it a success!  A dedicated
group worked all day long anywhere-on-earth and pushed 79 commits fixing
a variety of things—thumbs up!

We’re almost done but we have yet to get past the finish line.

Please give it a spin either by testing your system:

  sudo guix time-machine --branch=core-updates-frozen -- \
system reconfigure /…/config.scm

or by upgrading your profile:

  guix time-machine --branch=core-updates-frozen -- upgrade

Expect rebuilds as things in the GNOME/Freedesktop stack are still
receiving fixes, or wait until ci.guix has caught up.

The issue Ricardo mentioned about ‘python-jupyter’ has yet to be fixed
too, and there’s probably more.

If you email bug-guix or guix-patches with “core-updates-frozen” in the
subject and a clear description of what the problem/fix is, your
friendly committer collective will be sure to fast-track your patch
(right? :-)).

> Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great to have
> that branch finally merged in ‘master’ by then?

Sounds doable, let’s keep up the good work!

Ludo’.

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[Ricardo Wurmus]

Ludovic Courtès  writes:

I hereby declare tomorrow, Thursday Nov. 18th, day of the 
on-line

‘core-updates-frozen’ sprint!

The idea is that you join #guix on IRC, you try to build your 
system or
profile from ‘core-updates-frozen’, and you report (and fix!) 
any issues
you may have, in the warmth of a collective of friendly human 
beings all

sharing the same goal and helping each other.


I’ll be there!

To give everyone a head start: we have some annoying errors:

1) 
/gnu/store/aw65rwl2c50ckwghafv0p98hpg4wqvxm-vigra-1.11.1-0.9b514fa.drv 
has a bunch of test failures; this blocks libreoffice.  Looks like 
this and was caused by the most recent boost upgrade:


--8<---cut here---start->8---
Boost.Python.ArgumentError: Python argument types in
   vigra.vigranumpycore.constructArrayFromAxistags(type, tuple, 
   numpy.dtype[float32], AxisTags, bool)

did not match C++ signature:
   constructArrayFromAxistags(boost::python::api::object, 
   vigra::ArrayVector >, NPY_TYPES, 
   vigra::AxisTags, bool)

--8<---cut here---end--->8---


2) python-notebook has failing tests.  Same for a more recent 
version (6.4.3).  The failing tests *all* relate to deleting files 
with send2trash.  Upgrading send2trash does not help.  These tests 
also fail outside the build container environment.  The errors 
look like this:


--8<---cut here---start->8---
notebook-6.4.3/notebook/services/contents/manager.py:279: in 
delete

   self.delete_file(path)
notebook-6.4.3/notebook/services/contents/filemanager.py:533: in 
delete_file

   send2trash(os_path)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = 
'/tmp/guix-build-python-notebook-6.4.3.drv-0/tmpkwgdpuk_/Untitled.ipynb'


   def send2trash(path):
   try:
   f = Gio.File.new_for_path(path)
   f.trash(cancellable=None)
   except GObject.GError as e:
   if e.code == Gio.IOErrorEnum.NOT_SUPPORTED:
   # We get here if we can't create a trash directory 
   on the same
   # device. I don't know if other errors can result 
   in NOT_SUPPORTED.

   raise TrashPermissionError('')

  raise OSError(e.message)
E   OSError: Error trashing file 
/tmp/guix-build-python-notebook-6.4.3.drv-0/tmpkwgdpuk_/Untitled.ipynb: 
No such file or directory

--8<---cut here---end--->8---


3) Building Gnome systems fails because of a package conflict. 
Commit 781f475bbac4e73848f68cb9f420a7283ec17c16 is the direct 
cause; different variants of at-spi2-atk end up in the same 
profile.



Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great 
to have

that branch finally merged in ‘master’ by then?


Yes!

--
Ricardo

Thursday 18th: ‘core-updates-frozen’ sprint!

[Ludovic Courtès]

Hello Guix!

I hereby declare tomorrow, Thursday Nov. 18th, day of the on-line
‘core-updates-frozen’ sprint!

The idea is that you join #guix on IRC, you try to build your system or
profile from ‘core-updates-frozen’, and you report (and fix!) any issues
you may have, in the warmth of a collective of friendly human beings all
sharing the same goal and helping each other.

Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great to have
that branch finally merged in ‘master’ by then?

See you on Thursday!  :-)

Ludo’.

Re: broken "make dist" on core-updates-frozen

[Ludovic Courtès]

Hi!

Vagrant Cascadian  skribis:

> I've now pushed to core-updates-frozen:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen=6cdf4e5bf230fdbe17e592c2ec74fb34dba70eb5

Thanks!

>> I'll also make a plea to create a "make dist" job on ci.guix.gnu.org
>> soon, to catch these things earlier, as issues like this could block
>> making a release!
>
> Still think this would be a great idea! :)

Yes.  Note also that ‘guix lint -c patch-file-names’ also reports these:

--8<---cut here---start->8---
$ LANGUAGE= guix lint -c patch-file-names |grep "too long"
gnu/packages/admin.scm:2672:2: debops@1.1.0: 
debops-constants-for-external-program-names.patch: file name is too long
gnu/packages/astronomy.scm:768:2: xplanet@1.3.1: 
xplanet-1.3.1-libdisplay_DisplayOutput.cpp.patch: file name is too long
gnu/packages/astronomy.scm:768:2: xplanet@1.3.1: 
xplanet-1.3.1-xpUtil-Add2017LeapSecond.cpp.patch: file name is too long
gnu/packages/geo.scm:311:2: libgeotiff@1.5.1: 
libgeotiff-adapt-test-script-for-proj-6.2.patch: file name is too long
gnu/packages/glib.scm:478:2: gobject-introspection@1.62.0: 
gobject-introspection-absolute-shlib-path.patch: file name is too long
checking go-github-com-google-gmail-oauth2-tools-go-sendgmail@0.0.0-0.e322915 
[patch-file-names]..gnu/packages/java.scm:13120:2: java-apache-ivy@2.4.0: 
java-apache-ivy-port-to-latest-bouncycastle.patch: file name is too long
gnu/packages/java.scm:8926:2: 
java-tunnelvisionlabs-antlr4-runtime-annotations@4.7.4: 
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is too long
gnu/packages/java.scm:9040:2: java-tunnelvisionlabs-antlr4@4.7.4: 
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is too long
gnu/packages/java.scm:9032:2: java-tunnelvisionlabs-antlr4-runtime@4.7.4: 
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is too long
gnu/packages/kde-frameworks.scm:3419:2: plasma-framework@5.70.1: 
plasma-framework-fix-KF5PlasmaMacros.cmake.patch: file name is too long
gnu/packages/llvm.scm:98:2: clang-runtime@3.9.1: 
clang-runtime-3.9-libsanitizer-mode-field.patch: file name is too long
gnu/packages/llvm.scm:98:2: clang-runtime@3.7.1: 
clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too long
gnu/packages/llvm.scm:98:2: clang-runtime@3.8.1: 
clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too long
gnu/packages/llvm.scm:851:4: clang-runtime@3.5.2: 
clang-runtime-3.5-libsanitizer-mode-field.patch: file name is too long
$ guix describe
Generacio 194   Nov 07 2021 23:40:30(nuna)
  guix bd41e59
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bd41e590dd24e54797fb8b6854c244efd4d12df5
--8<---cut here---end--->8---

It’s conservative so maybe not all these are problematic for “make
dist” (yet), but they’re worth fixing.

Ludo’.

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Ludovic Courtès]

Hi,

Thiago Jung Bauermann  skribis:

> Em quinta-feira, 11 de novembro de 2021, às 15:23:37 -03, Maxim Cournoyer 
> escreveu:
>> Hello Guix!
>> 
>> I've finally merged the core-updates-frozen-batched-changes to
>> core-updates-frozen. 
>
> Hooray!
>
>> One thing we could do in the meantime is to replace our polkit package
>> with polkit-duktape, which uses an (unmerged) patch to build polkit
>> against duktape rather than mozjs [1].  The patch seems to have garnered
>> some attention recently.  This would enable to build GTK and parts of
>> GNOME without rust, I believe.
>
> I’d suggest replacing polkit with polkit-duktape only for non-x86_64 
> architectures. What do you think?¨

Yes, that seems like the most reasonable option.

Thanks, Maxim!

Ludo’.

Re: broken "make dist" on core-updates-frozen

[Vagrant Cascadian]

On 2021-11-14, Vagrant Cascadian wrote:
> There is a very long patch in core-updates-frozen for the gd package
> which breaks "make dist" ... and about 10k packages are transitively
> dependent on gd... so this seems (at least to me) really important to
> fix before merging into master...
>
> I've pushed a fix (simply using a shorter patch filename) to
> core-updates-frozen-batched-changes:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen-batched-changes=22477c20604d88f2867c64405f86e7306a333f32

And apparently created core-updates-frozen-batched-changes in the
process? ugh. sorry.

I've now pushed to core-updates-frozen:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen=6cdf4e5bf230fdbe17e592c2ec74fb34dba70eb5


> I'll also make a plea to create a "make dist" job on ci.guix.gnu.org
> soon, to catch these things earlier, as issues like this could block
> making a release!

Still think this would be a great idea! :)


live well,
  vagrant


signature.asc
Description: PGP signature

broken "make dist" on core-updates-frozen

[Vagrant Cascadian]

Heads up for anyone working on merging core-updates-frozen into master!

There is a very long patch in core-updates-frozen for the gd package
which breaks "make dist" ... and about 10k packages are transitively
dependent on gd... so this seems (at least to me) really important to
fix before merging into master...

I've pushed a fix (simply using a shorter patch filename) to
core-updates-frozen-batched-changes:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen-batched-changes=22477c20604d88f2867c64405f86e7306a333f32

I hope that was a correct place to push it; I'm a little unclear as to
the correct branches with all the core-updates* variants right
now... clarity on that would be helpful.


I'll also make a plea to create a "make dist" job on ci.guix.gnu.org
soon, to catch these things earlier, as issues like this could block
making a release!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Thiago Jung Bauermann]

Hello Maxim,

Em quinta-feira, 11 de novembro de 2021, às 15:23:37 -03, Maxim Cournoyer 
escreveu:
> Hello Guix!
> 
> I've finally merged the core-updates-frozen-batched-changes to
> core-updates-frozen. 

Hooray!

> One thing we could do in the meantime is to replace our polkit package
> with polkit-duktape, which uses an (unmerged) patch to build polkit
> against duktape rather than mozjs [1].  The patch seems to have garnered
> some attention recently.  This would enable to build GTK and parts of
> GNOME without rust, I believe.

I’d suggest replacing polkit with polkit-duktape only for non-x86_64 
architectures. What do you think?¨

-- 
Thanks,
Thiago

Replacing polkit by polkit-duktape on core-updates-frozen ?

[Maxim Cournoyer]

Hello Guix!

I've finally merged the core-updates-frozen-batched-changes to
core-updates-frozen.  One of the changes it brought is an updated
(non-grafted) polkit; this polkit now depends on mozjs@78 which itself
depends on rust.

Unfortunately, our rust bootstrap doesn't currently build everywhere;
progress is being made in mrustc to improve the situation as we speak
[0], but in the meantime this rust-dependent polkit will cause problems
on non-x86_64 architectures (it is needed by GTK/GNOME through elogind).

One thing we could do in the meantime is to replace our polkit package
with polkit-duktape, which uses an (unmerged) patch to build polkit
against duktape rather than mozjs [1].  The patch seems to have garnered
some attention recently.  This would enable to build GTK and parts of
GNOME without rust, I believe.

What do you think?

[0]  https://github.com/thepowersgang/mrustc/issues/78#issuecomment-966470873
[1]  https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey Ricardo,

> It should be fine now.  I didn’t run the test myself, but I ran most of the
> commands and found a few more hardcoded tool file names that referenced /sbin
> or /usr/bin. 

Yes, I confirm it passes! I also fixed the childhurd test. Only 9 tests
to go :).

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Ricardo Wurmus]

Hi Mathieu,

I fixed the build.  Also had to upgrade 389-ds-base to get 
around a linker

error.


Thanks for your support here! The ldap test is now run, but 
sadly there

are some failures: https://ci.guix.gnu.org/build/928047/log/raw.


Thanks for checking!

It should be fine now.  I didn’t run the test myself, but I ran 
most of the commands and found a few more hardcoded tool file 
names that referenced /sbin or /usr/bin. 


--
Ricardo

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hello Ricardo,

> I fixed the build.  Also had to upgrade 389-ds-base to get around a linker
> error.

Thanks for your support here! The ldap test is now run, but sadly there
are some failures: https://ci.guix.gnu.org/build/928047/log/raw.

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey,

> For example, this evaluation from Sep 17 has thousands of scheduled 
> evaluations:
>
> https://ci.guix.gnu.org/eval/19271?status=pending

Mmmh, not nice. Any chance you could share the cuirass-remote-worker
logs on the guixp9 machine?

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Ricardo Wurmus]

Mathieu Othacehe  writes:


* ldap (https://ci.guix.gnu.org/build/901179/details)
 => 389-ds-base build appears to be broken.


I fixed the build.  Also had to upgrade 389-ds-base to get around 
a linker error.


--
Ricardo

Re: core-updates-frozen: Planning for the last world rebuild

[Thiago Jung Bauermann]

Hello Mathieu,

Em quinta-feira, 30 de setembro de 2021, às 06:03:52 -03, Mathieu Othacehe 
escreveu:
> Hey Thiago,
> 
> > I was waiting for this world rebuild to happen to see the results in
> > Cuirass now that powerpc64le-linux builds are only done on guixp9, but
> > in hindsight it would have been better if I requested that those
> > builds were restarted instead. Restarting this build should remove the
> > main roadblock though:
> > 
> > https://ci.guix.gnu.org/build/703194/details
> 
> Now restarted!

Thank you! Unfortunately that build is now affected by an issue that I only 
noticed yesterday: powerpc64le-linux builds for core-updates-frozen get 
permanently stuck in the ‘Scheduled’ state, even though guixp9 is 
completely idle (as it is right now).

For example, this evaluation from Sep 17 has thousands of scheduled 
evaluations:

https://ci.guix.gnu.org/eval/19271?status=pending

This is also happening with at least one other platform as well. This 
evaluation from Sep 25 has a lot of scheduled evaluations for i586-gnu (as 
well as powerpc64le-linux):

https://ci.guix.gnu.org/eval/23187?status=pending

> > When that build is restarted and succeeds, does Cuirass also restart
> > the
> > builds that failed because they depended on it, or do we need to
> > explicitly restart those as well?
> 
> Yes, on successful build completion Cuirass looks if some builds that
> were marked as "failed-dependency" (failing because some of the
> dependencies are also failing) can be resumed.

That is awesome!

> That being said, Cuirass is not performing nicely these days because of:
> this issue https://issues.guix.gnu.org/48468.

Ah, ok. Thank you for the heads up.

-- 
Thanks,
Thiago

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey Thiago,

> I was waiting for this world rebuild to happen to see the results in 
> Cuirass now that powerpc64le-linux builds are only done on guixp9, but in 
> hindsight it would have been better if I requested that those builds were 
> restarted instead. Restarting this build should remove the main roadblock 
> though:
>
> https://ci.guix.gnu.org/build/703194/details

Now restarted!

>
> When that build is restarted and succeeds, does Cuirass also restart the 
> builds that failed because they depended on it, or do we need to explicitly 
> restart those as well?

Yes, on successful build completion Cuirass looks if some builds that
were marked as "failed-dependency" (failing because some of the
dependencies are also failing) can be resumed.

That being said, Cuirass is not performing nicely these days because of:
this issue https://issues.guix.gnu.org/48468.

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[Efraim Flashner]

On Tue, Sep 28, 2021 at 01:57:45PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)
> 
> What about merging the patches blocked by
> <https://issues.guix.gnu.org/50358>?  We could even have them on a
> separate branch, have Cuirass build it, and merge it 24–36h later, at
> which point substitute coverage should be reasonably good.
> 
> I haven’t followed the new ports, POWER9 and RISC-V.  If there’s
> anything needed in this area, like localized toolchain changes, please
> send a heads-up!
> 
> As I say every time someone proposes a new port, the main issue is not
> the port itself but maintaining it longer-term.  And here it’s not even
> clear to me what the status of POWER9 is on ‘core-updates-frozen’, so
> it’d be great to get feedback on this, ensure Cuirass builds it, and so
> on.

I'm still building away on riscv64-linux. I have some minor changes,
namely renaming target-riscv? to target-riscv64? As far as cuirass
support I have it officially unsupported in %hydra-supported-systems (or
whatever that variable is called). I've tried to keep the patches so
that they can be applied without interfering with the other
architectures. At this point as far as I know it's waiting for another
pair of eyes or so to say it looks OK to merge.

-- 
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: core-updates-frozen: Planning for the last world rebuild

[Thiago Jung Bauermann]

Hello Ludo,

Em terça-feira, 28 de setembro de 2021, às 08:57:45 -03, Ludovic Courtès 
escreveu:
> Hello Guix!
> 
> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)
> 
> What about merging the patches blocked by
> <https://issues.guix.gnu.org/50358>?  We could even have them on a
> separate branch, have Cuirass build it, and merge it 24–36h later, at
> which point substitute coverage should be reasonably good.
> 
> I haven’t followed the new ports, POWER9 and RISC-V.  If there’s
> anything needed in this area, like localized toolchain changes, please
> send a heads-up!

There are two things I’m aware of for POWER9:

• diffutils test fix: https://issues.guix.gnu.org/50239
• gcc-5 build with GCC 10 fix: https://issues.guix.gnu.org/49896

In the case of diffutils, IMHO ideally we would apply the v2 patch there for 
the world rebuild, but as Ludo suggested it’s also possible to make the 
change only for powerpc64le-linux and avoid affecting other platforms.

In the case of gcc-5, it’s the same situation actually. But in addition to 
that, `guix refresh --list-dependent` says that modifying gcc-5 would only 
cause 32 dependent packages to be rebuilt so it’s not necessary to address 
it for the world rebuild.

> As I say every time someone proposes a new port, the main issue is not
> the port itself but maintaining it longer-term.  And here it’s not even
> clear to me what the status of POWER9 is on ‘core-updates-frozen’, so
> it’d be great to get feedback on this, ensure Cuirass builds it, and so
> on.

Yeah, the status of POWER9 on ‘core-updates-frozen’ is obfuscated by some 
build failures early in the dependency chain that were caused by QEMU bugs.
My impression is that the same is also true for aarch64-linux. For 
instance, QEMU can’t run libsigsegv’s testsuite (among other things), and 
that blocks a ton of stuff. Ditto for util-linux’s testsuite.

I was waiting for this world rebuild to happen to see the results in 
Cuirass now that powerpc64le-linux builds are only done on guixp9, but in 
hindsight it would have been better if I requested that those builds were 
restarted instead. Restarting this build should remove the main roadblock 
though:

https://ci.guix.gnu.org/build/703194/details

When that build is restarted and succeeds, does Cuirass also restart the 
builds that failed because they depended on it, or do we need to explicitly 
restart those as well?

What I can say is that IMHO POWER9 support isn’t too bad at least for the 
base packages given that I can build e.g., emacs (assuming that the patch 
for issue 50521 fixing a problem in gtk+-2 is applied), which depends on 
many base packages including X11 and GTK+.

-- 
Thanks,
Thiago

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey!

> have more system tests passing. Currently 16 out of 87 are
> broken. Except for the nfs-root-fs that has always been broken, the
> other tests probably cover user configurations out there.

Made some progress here but there are still a bit more work needed:

* childhurd (https://ci.guix.gnu.org/build/901219/details)
 => gnumach build appears to be broken.

* dovecot (https://ci.guix.gnu.org/build/901189/details)
 => dovecot build appears to be broken.

* patchwork (https://ci.guix.gnu.org/build/901227/details)
 => python-django-pipeline build (dependency of patchwork) appears to be
  broken.

* ganeti-kvm (https://ci.guix.gnu.org/build/901158/details)
 => ganeti build appears to be broken.

* ganeti-lxc (https://ci.guix.gnu.org/build/901157/details)
 => same reason.

* getmail (https://ci.guix.gnu.org/build/901187/details)
 => dovecot build appears to be broken.

* gui-installed-desktop-os-encrypted
  (https://ci.guix.gnu.org/build/923078/details)
 => emacs-exwm build is broken presumably because of
  https://issues.guix.gnu.org/50066.

* jami-provisioning (https://ci.guix.gnu.org/build/901214/details) and
 jami (https://ci.guix.gnu.org/build/901213/details)
 => sobjectizer build appears to be broken.

* ldap (https://ci.guix.gnu.org/build/901179/details)
 => 389-ds-base build appears to be broken.

The overall status can be seen here:
https://ci.guix.gnu.org/eval/24933/dashboard. Let's get those tests fixed
so that we can start this branch on good grounds!

Thanks,

Mathieu

Re: core-updates-frozen: Planning for the last world rebuild

[John Kehayias]

Hi Ludo’ and Guixers,

Thanks for the good progress on core-updates-frozen (where I'm currently 
writing from and have nearly everything working as before). Seems like we have 
a few different bug numbers and threads for the world rebuild. Sorry for 
repeating from #50860, which I will paste below.

In summary, I also noticed an older bug for Flatpak with p11-kit, as well as 
p11-kit being out of date. Locally I've tested it builds with the patch and 
version update and fixes the bug. The configuration change is the same as nix 
does for p11-kit for the same reason, for what that is worth.

Less critical is Mesa continuing to put out updates, both on 21.1 and now 
moving to 21.2 (considered stable I believe). I thought we might sneak that in 
if we're doing lots of rebuilding.

Thanks! Original message with more details below:

Is there anything else with huge rebuilds to push together? I don't want to 
keep finding and adding things, but two possibilities come to mind that I've 
just noticed:

1a. p11-kit #49957 https://issues.guix.gnu.org/49957

I've just hit this bug on core-updates-frozen as well, though was originally 
reported on master. As I noted there, I tried to test with just grafts but 
didn't fix it for me (I'm guessing grafting won't work with that configure flag 
change). The patch matches how nix configures p11-kit as well, due to this bug.

1b. p11-kit is also now out of date. The changelog doesn't look substantial or 
serious, but given the nature of p11-kit I wonder if we want to update it now 
too. https://github.com/p11-glue/p11-kit/releases/tag/0.24.0

2. (minor) Mesa has had a few more bugfix and major releases since my initial 
patch for core-updates-frozen. Now at 21.1.8 for the 21.1 branch (we have 
21.1.6 currently), but 21.2 has also had stable releases, with 21.2.2. I 
previously built 21.2.1 and sent a patch for it, and could test 21.2.2 if we 
want to do that too.

I'm aware this could continue forever, and #2 is likely lower priority. #1, 
though, should we consider p11-kit a critical update (version, at least) since 
we're still fixing core-updates-frozen?

John

bug#50346: [PATCH core-updates-frozen] gnu: strace: Allow readlink, readlinkat tests to pass.

[Simon South]

Could this patch be reviewed please?  It's needed to build strace from
core-updates-frozen on AArch64 and it would be good to get it applied
ahead of the merge.

It wasn't sent out to guix-patches and I think it got missed.

http://issues.guix.gnu.org/50346#7

-- 
Simon South
si...@simonsouth.net

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey!

> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)

That would be great :) Before merging to master, it would be nice to
have more system tests passing. Currently 16 out of 87 are
broken. Except for the nfs-root-fs that has always been broken, the
other tests probably cover user configurations out there.

I'm currently working on the installation tests.

Thanks,

Mathieu

core-updates-frozen: Planning for the last world rebuild

[Ludovic Courtès]

Hello Guix!

Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)

What about merging the patches blocked by
<https://issues.guix.gnu.org/50358>?  We could even have them on a
separate branch, have Cuirass build it, and merge it 24–36h later, at
which point substitute coverage should be reasonably good.

I haven’t followed the new ports, POWER9 and RISC-V.  If there’s
anything needed in this area, like localized toolchain changes, please
send a heads-up!

As I say every time someone proposes a new port, the main issue is not
the port itself but maintaining it longer-term.  And here it’s not even
clear to me what the status of POWER9 is on ‘core-updates-frozen’, so
it’d be great to get feedback on this, ensure Cuirass builds it, and so
on.

Thanks,
Ludo’.

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

[Xinglu Chen]

On Mon, Sep 27 2021, Mathieu Othacehe wrote:

> Hello,
>
>> The manual should also be updated to reflect this change.
>
> Fixed, thanks for the reminder.

You are welcome!  :-)

>> Also, is there any reason for making this change on
>> ‘core-updates-frozen’ rather than ‘master’?
>
> Yes, that's a follow-up of 86cf4c039631cdf15c4c428bf4ffe52d6cbd7d4c that
> was pushed on core-updates a while ago.

Ah, OK.


signature.asc
Description: PGP signature

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

[Mathieu Othacehe]

Hello,

> The manual should also be updated to reflect this change.

Fixed, thanks for the reminder.

> Also, is there any reason for making this change on
> ‘core-updates-frozen’ rather than ‘master’?

Yes, that's a follow-up of 86cf4c039631cdf15c4c428bf4ffe52d6cbd7d4c that
was pushed on core-updates a while ago.

Thanks,

Mathieu

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

[Xinglu Chen]

On 27 September 2021 15:26, guix-comm...@gnu.org wrote:

> commit 502925655d1a51aad544804c8ef492a5d24e1776
> Author: Mathieu Othacehe 
> AuthorDate: Mon Sep 27 19:22:56 2021 +
>
> services: database: Change postgresql default socket.
>
> Adapt to the postgresql default socket directory set to 
> /var/run/postgresql.
>
> * gnu/services/databases.scm 
> ()[socket-directory]: Set
> to /var/run/postgresql.
> (): Ditto.
> * gnu/tests/databases.scm (run-postgresql-test): Adapt it.
> ---
>  gnu/services/databases.scm | 4 ++--
>  gnu/tests/databases.scm| 3 +--
>  2 files changed, 3 insertions(+), 4 deletions(-)

The manual should also be updated to reflect this change.

Also, is there any reason for making this change on
‘core-updates-frozen’ rather than ‘master’?




signature.asc
Description: PGP signature

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Thiago Jung Bauermann]

Hello again,

Em quinta-feira, 9 de setembro de 2021, às 19:47:20 -03, Thiago Jung 
Bauermann escreveu:
> Hello,
> 
> Em quinta-feira, 9 de setembro de 2021, às 19:33:43 -03, Tobias
> Geerinckx-
> Rice escreveu:
> > Thiago Jung Bauermann 写道：
> > 
> > > Curiously, the odd-numbered workers still advertise
> > > powerpc64-linux:
> > > https://ci.guix.gnu.org/machine/hydra-guix-101
> > 
> > …?  Curious indeed!  I definitely remember odd numbers scrolling
> > by, but I don't recall .101 specifically, nor did I read the
> > (voluminous) output in detail.  I'll take a look tomorrow.
> 
> Perhaps there’s a delay in when those web pages are updated. Today for
> the first time I’ve seen a build being routed to guixp9:
  ⋮

  ⋮
> So it seems to have worked, even though https://ci.guix.gnu.org/metrics
> still says there were 0 builds there in the past 24h.

Actually, it’s not a case of the web pages being out of date. The
hydra-guix- machines are still doing emulated powerpc64le-linux 
builds, unfortunately. :-/

ON the bright side, guixp9 is doing some of the builds as well!

-- 
Thanks,
Thiago

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Sarah Morgensen]

Hi,

Maxim Cournoyer  writes:

> Hello Guix!
>
> Since there's going to be at least this change [0] causing a world
> rebuild of the core-updates-frozen branch, I'd like to know if there are
> other world-rebuilding but low-risk changes you'd like to see integrated
> into the branch.

Perhaps we also want to wait for the fix for "cannot build missing
derivation" [0] to be pushed and deployed as well?  A world-rebuild is
likely to cause a *lot* of this, leading to useless CI feedback.

[0] https://issues.guix.gnu.org/50040
--
Sarah

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Attila Lendvai]

not sure this is relevant here, but there is this fix for wrap-script, too:

http://issues.guix.gnu.org/40039

Sent from mobile, pardon my brevity.

 Original Message 
On Sep 8, 2021, 17:00, Maxim Cournoyer wrote:

> Hello Guix!
>
> Since there's going to be at least this change [0] causing a world
> rebuild of the core-updates-frozen branch, I'd like to know if there are
> other world-rebuilding but low-risk changes you'd like to see integrated
> into the branch.
>
> If you do, feel free to 'block' the 50358 issue with the changes, so
> that I can review them and push them at the same time as [0].
>
> Thank you!
>
> Maxim
>
> [0] https://issues.guix.gnu.org/50358

Re: [core-updates-frozen] Blockers for working system

[Liliana Marie Prikler]

Hi Jonathan,

Am Samstag, den 11.09.2021, 00:16 +0200 schrieb Jonathan Brielmaier:
> /gnu/store/2p3lw0dy8b3b34xfn2xlwg9ngrw493v7-gnome-maps-3.38.5.drv
>Fails in testsuite with:
> JS ERROR: Error: Expected 1,001 m (string) but was 1001 m (string)
> I have no clue why, maybe something is "wrangled" with LC_ALL or LANG
> variables. Or it has to do with our mozjs-78 (used by gjs), where I
> assume comes the `toLocaleString` function from...
There is a phase called "fix-broken-tests" in gnome-maps which patches
exactly those strings to add a comma.  gnome-maps expects the new
behaviour (exactly the one you're observing), but building against an
old mozjs probably borked those tests at the time.  The obvious fix is
to drop that phase as it's no longer needed.

Happy hacking!

Re: [core-updates-frozen] Blockers for working system

[Guillaume Le Vaillant]

Jonathan Brielmaier  skribis:

> Hi Guix folks,
>
> here are the blockers which prevent me from using core-updates-frozen on
> my personal machine. So those 14 derivations failed for me this morning:
>
> [...]
>
> /gnu/store/7mz3ci5gydg606wmh2y6yl7q53mp5x68-materialdecoration-1.1.0-9.6a5de23.drv
>   Unbound variable: %build-inputs -> needs to be replaced by the gexp
> way of naming it...

Hi,

I fixed materialdecoration-1.1.0 in 856591e2b50cb5f186f01b252be239ae7553eeef.


signature.asc
Description: PGP signature

[core-updates-frozen] Blockers for working system

[Jonathan Brielmaier]

Hi Guix folks,

here are the blockers which prevent me from using core-updates-frozen on
my personal machine. So those 14 derivations failed for me this morning:

/gnu/store/fm4wk6zf8zir5qgc7m0fb52i9vrc1a21-gnome-calculator-3.34.1.drv
-> fixed: 67b8aa91f7

/gnu/store/mszx21cxrhsi1r1hx66fjb6qp2v4y372-babl-0.1.86.drv
-> fixed: 45055c73c8

/gnu/store/2p3lw0dy8b3b34xfn2xlwg9ngrw493v7-gnome-maps-3.38.5.drv
  Fails in testsuite with:
JS ERROR: Error: Expected 1,001 m (string) but was 1001 m (string)
I have no clue why, maybe something is "wrangled" with LC_ALL or LANG
variables. Or it has to do with our mozjs-78 (used by gjs), where I
assume comes the `toLocaleString` function from...

/gnu/store/lv2mx78q9zxp6lznbf53hg9k8qbgkisp-lilypond-2.20.0.drv
  The configure script does not find fikparm.mf which is used as a test
for cyrillic font support. fikparm.mf doesn't end up in texlive-lh,
although found in the sources. Maybe the configure script should check
different for the font support (upstream issue).

/gnu/store/7mz3ci5gydg606wmh2y6yl7q53mp5x68-materialdecoration-1.1.0-9.6a5de23.drv
  Unbound variable: %build-inputs -> needs to be replaced by the gexp
way of naming it...

/gnu/store/b35i6d0gdlwyi5d4hrcc6iia9dqlg4p9-range-v3-0.11.0.drv

-> should be fixed by
https://github.com/ericniebler/range-v3/commit/a91f0e1be27a31c446452a753001d4518ef83a6b

/gnu/store/9yzalfd8cbm26sxfs5z4b4lkki6pi3hm-icedtea-1.13.13.drv

/gnu/store/9w248mmnax1l22clm2v3d288z93akgk0-make-4.2.1.drv

/gnu/store/7904dmirxvxy2smc6sprib0kvb6kdk1c-ruby-json-pure-2.2.0.drv
/gnu/store/0h78mzmmhvlx95swh6r6s99adnyf9rkf-ruby-minitest-bonus-assertions-3.0.drv
/gnu/store/2pbksnah4zww5fil5b24cx7adh182p4k-ruby-pandoc-ruby-2.1.4.drv
/gnu/store/w2pn1xjgx8pvixy50qii4a97hl4vq1rb-ruby-racc-1.4.14.drv
/gnu/store/3jrh6hz4kr781hk35aamv8jaf8n65nfg-ruby-regexp-property-values-1.0.0.drv
/gnu/store/bys2c9jc2bz7diliw3hhj7ksrs4q9ikm-ruby-term-ansicolor-1.7.1.drv
-> The ruby stuff is all failing in check phase...

So there are still 12 left to fix. The good thing is: they are all
pretty high in the leaves so have less then 100 dependencies each...

Happy hacking
Jonathan

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Thiago Jung Bauermann]

Hello again,

Em quarta-feira, 8 de setembro de 2021, às 12:00:34 -03, Maxim Cournoyer 
escreveu:
> Since there's going to be at least this change [0] causing a world
> rebuild of the core-updates-frozen branch, I'd like to know if there are
> other world-rebuilding but low-risk changes you'd like to see integrated
> into the branch.
> 
> If you do, feel free to 'block' the 50358 issue with the changes, so
> that I can review them and push them at the same time as [0].

I just remembered these patches which I sent a while back to fix gawk in 
‘%static-inputs’. They fix native builds of static-binaries-tarball:

https://issues.guix.gnu.org/50174

-- 
Thanks,
Thiago

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Thiago Jung Bauermann]

Hello,

Em quinta-feira, 9 de setembro de 2021, às 19:33:43 -03, Tobias Geerinckx-
Rice escreveu:
> Thiago Jung Bauermann 写道：
> 
> > Curiously, the odd-numbered workers still advertise
> > powerpc64-linux:
> > https://ci.guix.gnu.org/machine/hydra-guix-101
> 
> …?  Curious indeed!  I definitely remember odd numbers scrolling
> by, but I don't recall .101 specifically, nor did I read the
> (voluminous) output in detail.  I'll take a look tomorrow.

Perhaps there’s a delay in when those web pages are updated. Today for the 
first time I’ve seen a build being routed to guixp9:

--8<---cut here---start->8---
Sep 07 14:51:14 guixp9 cuirass[25700]: Building `/gnu/store/
4rf7myvpzjmnfqksp3hlf2r2qm36gn3k-ublock-origin-chromium-1.37.2.drv' 
derivation.
Sep 07 14:51:14 guixp9 cuirass[25700]: ;;; (("https://ci.guix.gnu.org; 
"https://bordeaux.guix.gnu.org;))
Sep 08 18:27:47 guixp9 cuirass[25700]: Building `/gnu/store/
4rf7myvpzjmnfqksp3hlf2r2qm36gn3k-ublock-origin-chromium-1.37.2.drv' 
derivation.
Sep 08 18:27:47 guixp9 cuirass[25700]: ;;; (("https://ci.guix.gnu.org; 
"https://bordeaux.guix.gnu.org;))
Sep 09 04:47:10 guixp9 cuirass[25700]: Derivation `/gnu/store/
4rf7myvpzjmnfqksp3hlf2r2qm36gn3k-ublock-origin-chromium-1.37.2.drv' build 
failed: build of `/gnu/store/4rf7myvpzjmnfqksp3hlf2r2qm36gn3k-ublock-
origin-chromium-1.37.2.drv' failed
--8<---cut here---end--->8---

So it seems to have worked, even though https://ci.guix.gnu.org/metrics 
still says there were 0 builds there in the past 24h.

-- 
Thanks,
Thiago

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Tobias Geerinckx-Rice]

Thiago Jung Bauermann 写道：
Curiously, the odd-numbered workers still advertise 
powerpc64-linux: 
https://ci.guix.gnu.org/machine/hydra-guix-101


…?  Curious indeed!  I definitely remember odd numbers scrolling 
by, but I don't recall .101 specifically, nor did I read the 
(voluminous) output in detail.  I'll take a look tomorrow.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Thiago Jung Bauermann]

Hello,

Em quinta-feira, 9 de setembro de 2021, às 12:47:56 -03, Tobias Geerinckx-
Rice escreveu:
> Thiago Jung Bauermann 写道：
> 
> > Mathieu made the change with commit c0a9022d8234 (“hydra:
> > cuirass: Disable
> > powerpc64le emulation.”) on the maintenance repo (thanks!), so
> > what is left
> > is deploying it on every hydra build machine for it to take
> > effect.
> 
> I just reconfigured all berlin build nodes, with no errors
> reported.

Thank you!

Curiously, the odd-numbered workers still advertise powerpc64-linux: 
https://ci.guix.gnu.org/machine/hydra-guix-101

> Note that /proc/sys/fs/binfmt_misc/qemu-ppc64le still exists on
> all of them and is still listed in berlin-nodes.scm.  I don't know
> if there are still ways for emulated builds to ‘leak’ into
> happening behind Cuirass's back, and/or whether it's now unused
> cruft that should be removed.

I don’t know either.

-- 
Thanks,
Thiago

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Tobias Geerinckx-Rice]

Thiago Jung Bauermann 写道：
Mathieu made the change with commit c0a9022d8234 (“hydra: 
cuirass: Disable 
powerpc64le emulation.”) on the maintenance repo (thanks!), so 
what is left 
is deploying it on every hydra build machine for it to take 
effect.


I just reconfigured all berlin build nodes, with no errors 
reported.


Note that /proc/sys/fs/binfmt_misc/qemu-ppc64le still exists on 
all of them and is still listed in berlin-nodes.scm.  I don't know 
if there are still ways for emulated builds to ‘leak’ into 
happening behind Cuirass's back, and/or whether it's now unused 
cruft that should be removed.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Thiago Jung Bauermann]

Hello Maxim,

Em quarta-feira, 8 de setembro de 2021, às 12:00:34 -03, Maxim Cournoyer 
escreveu:
> Hello Guix!
> 
> Since there's going to be at least this change [0] causing a world
> rebuild of the core-updates-frozen branch, I'd like to know if there are
> other world-rebuilding but low-risk changes you'd like to see integrated
> into the branch.

Not a code change for the branch, but it would be nice if powerpc64le-linux 
emulation would be removed from the workers so that we can have more 
reliable CI results on that platform by making it use the OSUOSL POWER9 
build machine that has been recently added (guixp9). Some packages can be 
built with emulation, but some very early in the dependency tree can’t 
(e.g., libsigsegv) so I don’t see much benefit in trying.

Mathieu made the change with commit c0a9022d8234 (“hydra: cuirass: Disable 
powerpc64le emulation.”) on the maintenance repo (thanks!), so what is left 
is deploying it on every hydra build machine for it to take effect.

-- 
Thanks,
Thiago

Re: Batching world-rebuilding changes for the core-updates-frozen branch

[Guillaume Le Vaillant]

Maxim Cournoyer  skribis:

> Hello Guix!
>
> Since there's going to be at least this change [0] causing a world
> rebuild of the core-updates-frozen branch, I'd like to know if there are
> other world-rebuilding but low-risk changes you'd like to see integrated
> into the branch.
>
> If you do, feel free to 'block' the 50358 issue with the changes, so
> that I can review them and push them at the same time as [0].
>
> Thank you!
>
> Maxim
>
> [0]  https://issues.guix.gnu.org/50358

Hi,

I just pushed a world-rebuilding fix for a bug in binutils (see [1])
2 hours ago.
It's evaluation 15282 on ci.guix.gnu.org. Maybe someone with admin
access to the CI could cancel it, in order not to rebuild everything
twice.

[1] https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00077.html


signature.asc
Description: PGP signature

Batching world-rebuilding changes for the core-updates-frozen branch

[Maxim Cournoyer]

Hello Guix!

Since there's going to be at least this change [0] causing a world
rebuild of the core-updates-frozen branch, I'd like to know if there are
other world-rebuilding but low-risk changes you'd like to see integrated
into the branch.

If you do, feel free to 'block' the 50358 issue with the changes, so
that I can review them and push them at the same time as [0].

Thank you!

Maxim

[0]  https://issues.guix.gnu.org/50358

Re: [core-updates-frozen] Bug in binutils 2.37

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Leo Famulari  skribis:
>
>> On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote:
>>> There's a bug in binutils 1.37, which we are using on the
>>> core-updates-frozen branch.
>>
>> 2.37, right? :)
>>
>
> Indeed. :)
>
>
>>> It's a file descriptor leak that can lead to 'malformed archive' errors
>>> when linking libraries. We get this problem at least when building
>>> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
>>> (see [1]), but it doesn't work for qtwebengine.
>>> 
>>> The bug was discussed at [2] and upstream has a patch to fix it at [3].
>>> However, adding this patch to our binutils rebuilds the world.
>>> I'm currently trying to build things with the patched binutils.
>>> If everything works, should I push this fix on core-updates-frozen, or
>>> does someone have an idea that would lead to less rebuilds?
>>
>> There are a few options:
>>
>> 1) Apply the patch in the normal way and rebuild the world. If the
>> changes in the patch are limited to fixing this bug, then we can be
>> confident that changing binutils will not break other packages, which is
>> the main goal behind "freezing" the core-updates branch. Do you think
>> that expectation is reasonable? Otherwise, the branch is frozen except
>> for bug fixes; we'd like to avoid rebuilding the world but it's not a
>> problem if we have to.
>> 2) Create a binutils-fixed package and only use it for qtwebkit and
>> qtwebengine
>> 3) Try to work around the bug in the qtwebkit and qtwebengine packages
>>
>> 2 and 3 are not great because maybe the bug affects other packages in
>> some situations. Do you know if it manifests deterministically?
>
> The problem happens when linking a library with a lot of members (I
> don't know exactly how many), which is the case at least for qtwebkit
> and qtwebengine. Users creating such libraries in their projects will
> also have the problem.
>
> Increasing the maximum number of open file descriptors seems not be
> a very robust workaround. Setting it at 4096 for qtwebkit works,
> but I tried 4096, 8192 and 16384 for qtwebengine and it didn't work.
>
> I have built many packages with the patched binutils and I didn't get
> any new failure so far. I'm not yet at qtwebkit and qtwebengine though
> (compiling the 20 versions of rust took a while).
> So when I get there, and if the patch really solves the issue, pushing
> it looks like the best solution.
>
> Do you know if there are other world-rebuilding pending fixes that could
> go in at the same time?

I confirm that the patch fixed the compilation issues for qtwebkit and
qtwebengine, and it didn't cause new build failures, so I pushed it as
de8e2a699c0219f5ea86f6bbfff4d5ee35104738.


signature.asc
Description: PGP signature

Re: [core-updates-frozen] Bug in binutils 2.37

[Guillaume Le Vaillant]

Leo Famulari  skribis:

> On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote:
>> There's a bug in binutils 1.37, which we are using on the
>> core-updates-frozen branch.
>
> 2.37, right? :)
>

Indeed. :)


>> It's a file descriptor leak that can lead to 'malformed archive' errors
>> when linking libraries. We get this problem at least when building
>> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
>> (see [1]), but it doesn't work for qtwebengine.
>> 
>> The bug was discussed at [2] and upstream has a patch to fix it at [3].
>> However, adding this patch to our binutils rebuilds the world.
>> I'm currently trying to build things with the patched binutils.
>> If everything works, should I push this fix on core-updates-frozen, or
>> does someone have an idea that would lead to less rebuilds?
>
> There are a few options:
>
> 1) Apply the patch in the normal way and rebuild the world. If the
> changes in the patch are limited to fixing this bug, then we can be
> confident that changing binutils will not break other packages, which is
> the main goal behind "freezing" the core-updates branch. Do you think
> that expectation is reasonable? Otherwise, the branch is frozen except
> for bug fixes; we'd like to avoid rebuilding the world but it's not a
> problem if we have to.
> 2) Create a binutils-fixed package and only use it for qtwebkit and
> qtwebengine
> 3) Try to work around the bug in the qtwebkit and qtwebengine packages
>
> 2 and 3 are not great because maybe the bug affects other packages in
> some situations. Do you know if it manifests deterministically?

The problem happens when linking a library with a lot of members (I
don't know exactly how many), which is the case at least for qtwebkit
and qtwebengine. Users creating such libraries in their projects will
also have the problem.

Increasing the maximum number of open file descriptors seems not be
a very robust workaround. Setting it at 4096 for qtwebkit works,
but I tried 4096, 8192 and 16384 for qtwebengine and it didn't work.

I have built many packages with the patched binutils and I didn't get
any new failure so far. I'm not yet at qtwebkit and qtwebengine though
(compiling the 20 versions of rust took a while).
So when I get there, and if the patch really solves the issue, pushing
it looks like the best solution.

Do you know if there are other world-rebuilding pending fixes that could
go in at the same time?


signature.asc
Description: PGP signature

Re: [core-updates-frozen] Bug in binutils 1.37

[Leo Famulari]

On Mon, Sep 06, 2021 at 03:39:52PM +, Guillaume Le Vaillant wrote:
> There's a bug in binutils 1.37, which we are using on the
> core-updates-frozen branch.

2.37, right? :)

> It's a file descriptor leak that can lead to 'malformed archive' errors
> when linking libraries. We get this problem at least when building
> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
> (see [1]), but it doesn't work for qtwebengine.
> 
> The bug was discussed at [2] and upstream has a patch to fix it at [3].
> However, adding this patch to our binutils rebuilds the world.
> I'm currently trying to build things with the patched binutils.
> If everything works, should I push this fix on core-updates-frozen, or
> does someone have an idea that would lead to less rebuilds?

There are a few options:

1) Apply the patch in the normal way and rebuild the world. If the
changes in the patch are limited to fixing this bug, then we can be
confident that changing binutils will not break other packages, which is
the main goal behind "freezing" the core-updates branch. Do you think
that expectation is reasonable? Otherwise, the branch is frozen except
for bug fixes; we'd like to avoid rebuilding the world but it's not a
problem if we have to.
2) Create a binutils-fixed package and only use it for qtwebkit and
qtwebengine
3) Try to work around the bug in the qtwebkit and qtwebengine packages

2 and 3 are not great because maybe the bug affects other packages in
some situations. Do you know if it manifests deterministically?

[core-updates-frozen] Bug in binutils 1.37

[Guillaume Le Vaillant]

Hi,

There's a bug in binutils 1.37, which we are using on the
core-updates-frozen branch.

It's a file descriptor leak that can lead to 'malformed archive' errors
when linking libraries. We get this problem at least when building
qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
(see [1]), but it doesn't work for qtwebengine.

The bug was discussed at [2] and upstream has a patch to fix it at [3].
However, adding this patch to our binutils rebuilds the world.
I'm currently trying to build things with the patched binutils.
If everything works, should I push this fix on core-updates-frozen, or
does someone have an idea that would lead to less rebuilds?

P.S.: The patch I'm trying is in attachment.
From d90e95640f0c2bd3271e370516e51fac56929be7 Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant 
Date: Mon, 6 Sep 2021 17:32:38 +0200
Subject: [PATCH] gnu: binutils: Fix file decriptor leak.

* gnu/packages/patches/binutils-1.37-file-descriptor-leak.patch: New file.
* gnu/packages/local.mk (dist_patch_DATA): Add it.
* gnu/packages/base.scm (binutils)[source]: Use it.
---
 gnu/local.mk  |   1 +
 gnu/packages/base.scm |  17 +-
 .../binutils-1.37-file-descriptor-leak.patch  | 231 ++
 3 files changed, 241 insertions(+), 8 deletions(-)
 create mode 100644 gnu/packages/patches/binutils-1.37-file-descriptor-leak.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 8c41b5b676..5814587ef2 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -884,6 +884,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/behave-skip-a-couple-of-tests.patch	\
   %D%/packages/patches/beignet-correct-file-names.patch		\
   %D%/packages/patches/bidiv-update-fribidi.patch		\
+  %D%/packages/patches/binutils-1.37-file-descriptor-leak.patch	\
   %D%/packages/patches/binutils-boot-2.20.1a.patch		\
   %D%/packages/patches/binutils-loongson-workaround.patch	\
   %D%/packages/patches/binutils-mingw-w64-timestamp.patch	\
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index b9841a5cef..f5486c6aae 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -510,14 +510,15 @@ change.  GNU make offers many powerful extensions over the standard utility.")
   (package
(name "binutils")
(version "2.37")
-   (source (origin
-(method url-fetch)
-(uri (string-append "mirror://gnu/binutils/binutils-"
-version ".tar.bz2"))
-(sha256
- (base32
-  "1m3b2rdfv1dmdpd0bzg1hy7i8a2qng53szc6livyi3nh6101mz37"))
-(patches (search-patches "binutils-loongson-workaround.patch"
+   (source
+(origin
+  (method url-fetch)
+  (uri (string-append "mirror://gnu/binutils/binutils-"
+  version ".tar.bz2"))
+  (sha256
+   (base32 "1m3b2rdfv1dmdpd0bzg1hy7i8a2qng53szc6livyi3nh6101mz37"))
+  (patches (search-patches "binutils-loongson-workaround.patch"
+   "binutils-1.37-file-descriptor-leak.patch"
(build-system gnu-build-system)
 
;; TODO: Add dependency on zlib + those for Gold.
diff --git a/gnu/packages/patches/binutils-1.37-file-descriptor-leak.patch b/gnu/packages/patches/binutils-1.37-file-descriptor-leak.patch
new file mode 100644
index 00..1fd3d3d9b7
--- /dev/null
+++ b/gnu/packages/patches/binutils-1.37-file-descriptor-leak.patch
@@ -0,0 +1,231 @@
+From 1c611b40e6bfc8029bff7696814330b5bc0ee5c0 Mon Sep 17 00:00:00 2001
+From: "H.J. Lu" 
+Date: Mon, 26 Jul 2021 05:59:55 -0700
+Subject: [PATCH] bfd: Close the file descriptor if there is no archive fd
+
+Close the file descriptor if there is no archive plugin file descriptor
+to avoid running out of file descriptors on thin archives with many
+archive members.
+
+bfd/
+
+	PR ld/28138
+	* plugin.c (bfd_plugin_close_file_descriptor): Close the file
+	descriptor there is no archive plugin file descriptor.
+
+ld/
+
+	PR ld/28138
+	* testsuite/ld-plugin/lto.exp: Run tmpdir/pr28138 only for
+	native build.
+
+	PR ld/28138
+	* testsuite/ld-plugin/lto.exp: Run ld/28138 tests.
+	* testsuite/ld-plugin/pr28138.c: New file.
+	* testsuite/ld-plugin/pr28138-1.c: Likewise.
+	* testsuite/ld-plugin/pr28138-2.c: Likewise.
+	* testsuite/ld-plugin/pr28138-3.c: Likewise.
+	* testsuite/ld-plugin/pr28138-4.c: Likewise.
+	* testsuite/ld-plugin/pr28138-5.c: Likewise.
+	* testsuite/ld-plugin/pr28138-6.c: Likewise.
+	* testsuite/ld-plugin/pr28138-7.c: Likewise.
+
+(cherry picked from commit 5a98fb7513b559e20dfebdbaa2a471afda3b4742)
+(cherry picked from commit 7dc37e1e1209c80e0bab784df6b6bac335e836f2)
+---
+ bfd/plugin.c   |  8 +++
+ ld/testsuite/ld-plugin/lto.exp | 34 ++
+ ld/testsuite/ld-plugin/pr28138-1.c |  6 ++
+ ld/testsuite/ld-plugin/pr28138-2.c |  6 

Re: branch core-updates-frozen updated: gnu: sddm: Fix build.

[Efraim Flashner]

On Thu, Sep 02, 2021 at 06:47:10PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> guix-comm...@gnu.org skribis:
> 
> > efraim pushed a commit to branch core-updates-frozen
> > in repository guix.
> >
> > The following commit(s) were added to refs/heads/core-updates-frozen by 
> > this push:
> >  new f883677  gnu: sddm: Fix build.
> > f883677 is described below
> >
> > commit f8836774e2c76c1f4d9bee11339839f7d878e32a
> > Author: Efraim Flashner 
> > AuthorDate: Thu Sep 2 17:15:39 2021 +0300
> >
> > gnu: sddm: Fix build.
> > 
> > * gnu/packages/display-managers.scm (sddm)[arguments]: Use gexp for
> > configure-flags.
> 
> Out of curiosity, what was the build issue?  Could it be that
> ‘%build-inputs’ was undefined for this build system?

definitely a possiblity.

> 
> >  (arguments
> >   `(#:configure-flags
> 
> [...]
> 
> > +   ,#~(list
> > +;; This option currently does nothing, but will presumably be 
> > enabled
> > +;; if/when <https://github.com/sddm/sddm/pull/616> is merged.
> > +"-DENABLE_WAYLAND=ON"
> > +"-DENABLE_PAM=ON"
> > +;; Both flags are required for elogind support.
> > +"-DNO_SYSTEMD=ON" "-DUSE_ELOGIND=ON"
> > +"-DCONFIG_FILE=/etc/sddm.conf"
> > +;; Set path to /etc/login.defs.
> > +;; An alternative would be to use -DUID_MIN and -DUID_MAX.
> > +(string-append "-DLOGIN_DEFS_PATH="
> > +   #$shadow
> 
> Note that this style makes it impossible for users to override “shadow”
> via something like:
> 
>   (package
> (inherit sddm)
> (inputs `(("shadow" ,my-very-own-shadow
> 
> To avoid that pitfall, the New Recommended Style™ is:
> 
>   #~(list …
>   #$(this-package-input "shadow"))
> 
> Thanks,
> Ludo’.

Sounds good. I'll take another go at it in the morning unless someone
beats me to it.

-- 
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: branch core-updates-frozen updated: gnu: sddm: Fix build.

[Ludovic Courtès]

Hello!

guix-comm...@gnu.org skribis:

> efraim pushed a commit to branch core-updates-frozen
> in repository guix.
>
> The following commit(s) were added to refs/heads/core-updates-frozen by this 
> push:
>  new f883677  gnu: sddm: Fix build.
> f883677 is described below
>
> commit f8836774e2c76c1f4d9bee11339839f7d878e32a
> Author: Efraim Flashner 
> AuthorDate: Thu Sep 2 17:15:39 2021 +0300
>
> gnu: sddm: Fix build.
> 
> * gnu/packages/display-managers.scm (sddm)[arguments]: Use gexp for
> configure-flags.

Out of curiosity, what was the build issue?  Could it be that
‘%build-inputs’ was undefined for this build system?

>  (arguments
>   `(#:configure-flags

[...]

> +   ,#~(list
> +;; This option currently does nothing, but will presumably be 
> enabled
> +;; if/when <https://github.com/sddm/sddm/pull/616> is merged.
> +"-DENABLE_WAYLAND=ON"
> +"-DENABLE_PAM=ON"
> +;; Both flags are required for elogind support.
> +"-DNO_SYSTEMD=ON" "-DUSE_ELOGIND=ON"
> +"-DCONFIG_FILE=/etc/sddm.conf"
> +;; Set path to /etc/login.defs.
> +;; An alternative would be to use -DUID_MIN and -DUID_MAX.
> +(string-append "-DLOGIN_DEFS_PATH="
> +   #$shadow

Note that this style makes it impossible for users to override “shadow”
via something like:

  (package
(inherit sddm)
(inputs `(("shadow" ,my-very-own-shadow

To avoid that pitfall, the New Recommended Style™ is:

  #~(list …
  #$(this-package-input "shadow"))

Thanks,
Ludo’.

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[zimoun]

Hi Lars,

On Tue, 31 Aug 2021 at 18:41, Lars-Dominik Braun  wrote:

> pushed as bac072e09bb80c172672e13782e1ed25ce04d6d5. Please don’t
> hesitate to ping me if there’s any other issuse with the sanity check
> phase.

Thanks.  I will do. :-)  I am going to check if all the 'python2-'
packages on core-updates-frozen build or not.

Cheers,
simon

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[Lars-Dominik Braun]

Hi,

> From my point of view, yes you can push because it is a fix.
pushed as bac072e09bb80c172672e13782e1ed25ce04d6d5. Please don’t
hesitate to ping me if there’s any other issuse with the sanity check
phase.

Cheers,
Lars

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[zimoun]

Hi,

On Tue, 31 Aug 2021 at 14:39, Lars-Dominik Braun
 wrote:

> See attached patch for a fix.

LGTM.


> Can I simply push that to core-updates-frozen or is there anything else I 
> should do?

>From my point of view, yes you can push because it is a fix.

Cheers,
simon

Re: [core-updates-frozen] python2-google-api-client and sanity-check

[Lars-Dominik Braun]

Hi zimoun,

> Because this ’sanity-check’ is new, IIUC, my question is: is it
> expected?  And is it worth to fix such Python 2 packages or simply
> remove them because ’sanity-check.py’ uses Python 3 only features?
setup.py of this package is broken, because the package list contains a slash.
See attached patch for a fix.

Can I simply push that to core-updates-frozen or is there anything else I 
should do?

Lars

-- 
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate

www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964
diff --git a/gnu/packages/python-web.scm b/gnu/packages/python-web.scm
index 91b68cf5f4..4763abce8b 100644
--- a/gnu/packages/python-web.scm
+++ b/gnu/packages/python-web.scm
@@ -4338,7 +4338,15 @@ Google search engine.  Its module is called 
@code{googlesearch}.")
  "1wpbbbxfpy9mwxdy3kn352cb590ladv574j1aa2l4grjdqw3ln05"
 (build-system python-build-system)
 (arguments
- '(#:tests? #f)) ; tests require internet access
+ `(#:tests? #f ; tests require internet access
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'fix-setup-py
+   (lambda _
+ (substitute* "setup.py"
+   (("googleapiclient/discovery_cache")
+"googleapiclient.discovery_cache"))
+ #t)
 (native-inputs
  `(("python-httplib2" ,python-httplib2)
("python-six" ,python-six)


signature.asc
Description: PGP signature