bug#48024: glib-2.62.6 build fails i686

[Maxim Cournoyer]

Hello,

Efraim Flashner  writes:

> On Wed, May 05, 2021 at 05:15:14PM -0400, Bone Baboon wrote:
>> Efraim Flashner writes:
>> > I looked closer at the bug report and I see they are timing out at 60
>> > and 180 for Bone Baboon as they currently are.
>> >
>> > Bone Baboon: Can you build the attached test-glib.scm file and send back
>> > the build log? I want to make sure I change the timeout to something
>> > long enough.
>> >
>> > You can build it with 'guix build -f test-glib.scm'
>> 
>> I ran `guix build --file=test-glib.scm` and I was successful.
>
> That was the plan. I bumped the test timeouts to high enough numbers so
> that I could see how long it took.
>
>> I was having trouble finding the build log.
>> 
>> I have instead attached the output of the build command.
>
> It's perfect.
>
> It looks like the two slowest are
>  83/259 glib:glib / 1bit-mutex  OK  85.13 s
>  84/259 glib:glib+slow / 1bit-emufutex  OK  89.22 s
>
> I was thinking of just tripling the duration but test_timeout_slow would
> likely have been missed since it was moved from 120 to 180, and
> extracting the number so I could multiply it by 3 isn't really the most
> readable and could leave the timeout near the edge. I've gone ahead and
> multiplied it by 10, if a test would hang forever it's still killed and if
> there's high load on a slow machine it should still pass.

It seems a similar change was made in commit
7b7bc91c3d7fba306884cd1681d12b51246c2aea, around the time it was
discussed.

Closing!

Thanks,

Maxim

bug#48024: glib-2.62.6 build fails i686

[Bengt Richter]

Hi Mark,

tl;dr -- would you by chance have a mhw-bootstrap.sh that could clone
your set-up of a private git repo to use the way you often mention doing?

I am interested in doing it your way  ;)

IIRC, Pjotr wrote extensive notes on how to build starting with a git clone,
but ended up advising against doing it unless there was no other way.

Any tips appreciated :)
TIA.

On +2021-05-07 13:46:07 -0400, Mark H Weaver wrote:
> Hi,
> 
> Bone Baboon  writes:
> > How can I use the glib I have built in a system configuration while this
> > fix or a variation of it makes it's way into the Guix master branch?
> 
> I guess that you'll need to set up a personal branch of Guix, like I do,
> with a patch applied to the 'glib' package, and another patch applied to
> 'inetutils' (referring to ).
> 
> My recommendation, for now, would be to do this:
> 
> (1) Set up your own git repository, with a personal branch that's the
> same as our official 'master' branch plus the additional patches
> that you need, and to periodically rebase this branch on top of our
> 'master' branch.
> 
> (2) On all of your systems that need these customizations, pass the
> "--url=URL" and "--branch=BRANCH" options to "guix pull", each time
> you use that command.
> 
> There _might_ be a nicer way to set this up using channels, but I've
> never used channels and am mostly ignorant of them.  Maybe someone else
> can chime in on that point.
> 
>   Regards,
> Mark
> 
> -- 
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about .
> 
> 
> 

-- 
Regards,
Bengt Richter

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,

Bone Baboon  writes:
> How can I use the glib I have built in a system configuration while this
> fix or a variation of it makes it's way into the Guix master branch?

I guess that you'll need to set up a personal branch of Guix, like I do,
with a patch applied to the 'glib' package, and another patch applied to
'inetutils' (referring to ).

My recommendation, for now, would be to do this:

(1) Set up your own git repository, with a personal branch that's the
same as our official 'master' branch plus the additional patches
that you need, and to periodically rebase this branch on top of our
'master' branch.

(2) On all of your systems that need these customizations, pass the
"--url=URL" and "--branch=BRANCH" options to "guix pull", each time
you use that command.

There _might_ be a nicer way to set this up using channels, but I've
never used channels and am mostly ignorant of them.  Maybe someone else
can chime in on that point.

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
> One more important note: regardless of whether you run Guix from a git
> checkout or use the official 'master' branch, if you build everything
> locally, then it's important to pass "--gc-keep-derivations=yes" and
> "--gc-keep-outputs=yes" to the Guix daemon.
>
> Those flags change the way the Guix garbage collector operates, such
> that more store items are retained.  I've forgotten the precise details,
> but roughly, these flags cause not only the run-time requirements of the
> currently-installed software to be retained, but also the *build*
> requirements of that software.  Without these flags, "guix gc" will
> delete far too much, and you'll likely end up having to rebuild a great
> many packages that are needed at build time only.
>
> I have something close to this in the 'services' field of my OS config:
>
> --8<---cut here---start->8---
>   (modify-services %desktop-services
> (guix-service-type config =>
>(guix-configuration
>  (inherit config)
>  (use-substitutes? #f)
>  (authorize-key?   #f)
>  (authorized-keys '())
>  (substitute-urls '())
>  (extra-options '("--gc-keep-derivations=yes"
>   "--gc-keep-outputs=yes")
> --8<---cut here---end--->8---

Thank you for sharing this.

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Efraim Flashner writes:
>> > Bone Baboon: Can you build the attached test-glib.scm file and send back
>> > the build log? I want to make sure I change the timeout to something
>> > long enough.
>> >
>> > You can build it with 'guix build -f test-glib.scm'
>> 
>> I ran `guix build --file=test-glib.scm` and I was successful.
>
> That was the plan. I bumped the test timeouts to high enough numbers so
> that I could see how long it took.

Thank you.

I can build glib with `guix build --no-subsitutes --file=test-glib.scm`.
How can I use the glib I have built in a system configuration while this
fix or a variation of it makes it's way into the Guix master branch?

bug#48024: glib-2.62.6 build fails i686

[Bengt Richter]

Hi,

On +2021-05-06 09:45:00 +0300, Efraim Flashner wrote:
> On Wed, May 05, 2021 at 05:15:14PM -0400, Bone Baboon wrote:
> > Efraim Flashner writes:
> > > I looked closer at the bug report and I see they are timing out at 60
> > > and 180 for Bone Baboon as they currently are.
> > >
> > > Bone Baboon: Can you build the attached test-glib.scm file and send back
> > > the build log? I want to make sure I change the timeout to something
> > > long enough.
> > >
> > > You can build it with 'guix build -f test-glib.scm'
> > 
> > I ran `guix build --file=test-glib.scm` and I was successful.
> 
> That was the plan. I bumped the test timeouts to high enough numbers so
> that I could see how long it took.
> 
> > I was having trouble finding the build log.
> > 
> > I have instead attached the output of the build command.
> 
> It's perfect.
> 
> It looks like the two slowest are
>  83/259 glib:glib / 1bit-mutex  OK  85.13 s
>  84/259 glib:glib+slow / 1bit-emufutex  OK  89.22 s
> 
> I was thinking of just tripling the duration but test_timeout_slow would
> likely have been missed since it was moved from 120 to 180, and
> extracting the number so I could multiply it by 3 isn't really the most
> readable and could leave the timeout near the edge. I've gone ahead and
> multiplied it by 10, if a test would hang forever it's still killed and if
> there's high load on a slow machine it should still pass.
>

Couldn't autoconf emit some config info that test scripts could use
to run with appropriate timeouts and memory sizes etc?

Maybe with access similar to pkg-config?

Seems like someone must have thought of scratching that itch?

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

-- 
Regards,
Bengt Richter

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,

Bone Baboon  writes:

> Thank you for sharing this.  Also thank you for the warning about
> 'significant caveats and "rough edges"'.

The "rough edges" could surely be smoothed out with some effort.  I
haven't been motivated to work on it, partly because until recently,
I've felt quite alone in my preference for using Guix in this way.
However, you are now the second person to express interest in this in
the last couple of months.

> As a new user of Guix I think I will initially try to use the official
> Guix repository.

That's probably best for now, at least until you have a compelling
reason to do otherwise.

> However the message from Tobias Geerinckx-Rice in
> https://issues.guix.gnu.org/48213 gives me the idea that your flexible
> approach could be very useful if I find myself in a situation where I
> have an issue that will not be addressed by an upstream project and
> that has too much of a maintenance burden for Guix maintainers to take
> on.

Yes, it enables one to exercise an extraordinary amount of individual
control over one's system, while still benefitting from the work of the
larger Guix community.  Several of the commits on my private branch are
reversions of upstream changes in Guix that I disagreed with.

One more important note: regardless of whether you run Guix from a git
checkout or use the official 'master' branch, if you build everything
locally, then it's important to pass "--gc-keep-derivations=yes" and
"--gc-keep-outputs=yes" to the Guix daemon.

Those flags change the way the Guix garbage collector operates, such
that more store items are retained.  I've forgotten the precise details,
but roughly, these flags cause not only the run-time requirements of the
currently-installed software to be retained, but also the *build*
requirements of that software.  Without these flags, "guix gc" will
delete far too much, and you'll likely end up having to rebuild a great
many packages that are needed at build time only.

I have something close to this in the 'services' field of my OS config:

--8<---cut here---start->8---
  (modify-services %desktop-services
(guix-service-type config =>
   (guix-configuration
 (inherit config)
 (use-substitutes? #f)
 (authorize-key?   #f)
 (authorized-keys '())
 (substitute-urls '())
 (extra-options '("--gc-keep-derivations=yes"
  "--gc-keep-outputs=yes")
--8<---cut here---end--->8---

Regards,
  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Efraim Flashner]

On Wed, May 05, 2021 at 05:15:14PM -0400, Bone Baboon wrote:
> Efraim Flashner writes:
> > I looked closer at the bug report and I see they are timing out at 60
> > and 180 for Bone Baboon as they currently are.
> >
> > Bone Baboon: Can you build the attached test-glib.scm file and send back
> > the build log? I want to make sure I change the timeout to something
> > long enough.
> >
> > You can build it with 'guix build -f test-glib.scm'
> 
> I ran `guix build --file=test-glib.scm` and I was successful.

That was the plan. I bumped the test timeouts to high enough numbers so
that I could see how long it took.

> I was having trouble finding the build log.
> 
> I have instead attached the output of the build command.

It's perfect.

It looks like the two slowest are
 83/259 glib:glib / 1bit-mutex  OK  85.13 s
 84/259 glib:glib+slow / 1bit-emufutex  OK  89.22 s

I was thinking of just tripling the duration but test_timeout_slow would
likely have been missed since it was moved from 120 to 180, and
extracting the number so I could multiply it by 3 isn't really the most
readable and could leave the timeout near the edge. I've gone ahead and
multiplied it by 10, if a test would hang forever it's still killed and if
there's high load on a slow machine it should still pass.



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

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
>> I was having trouble finding the build log.
>
> Here's one way to find it:
>
> $ cd /var/log/guix/drvs
> $ ls -ltr */*-glib-2* | tail
>
> The very small log files are the result of grafting derivations.
> Look for the most recent one that's more than 1K.
>
> Alternatively, it _might_ work to run:
>
> $ guix build --log-file --file=test-glib.scm

Thank you this is helpful.

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,

Bone Baboon  writes:

> Efraim Flashner writes:
>> I looked closer at the bug report and I see they are timing out at 60
>> and 180 for Bone Baboon as they currently are.
>>
>> Bone Baboon: Can you build the attached test-glib.scm file and send back
>> the build log? I want to make sure I change the timeout to something
>> long enough.
>>
>> You can build it with 'guix build -f test-glib.scm'
>
> I ran `guix build --file=test-glib.scm` and I was successful.

That's good news!

> I was having trouble finding the build log.

Here's one way to find it:

$ cd /var/log/guix/drvs
$ ls -ltr */*-glib-2* | tail

The very small log files are the result of grafting derivations.
Look for the most recent one that's more than 1K.

Alternatively, it _might_ work to run:

$ guix build --log-file --file=test-glib.scm

Thanks,
  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Efraim Flashner writes:
> I looked closer at the bug report and I see they are timing out at 60
> and 180 for Bone Baboon as they currently are.
>
> Bone Baboon: Can you build the attached test-glib.scm file and send back
> the build log? I want to make sure I change the timeout to something
> long enough.
>
> You can build it with 'guix build -f test-glib.scm'

I ran `guix build --file=test-glib.scm` and I was successful.

I was having trouble finding the build log.

I have instead attached the output of the build command.



build-output.lz
Description: Binary data

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
> Did you also run "make"?

I have now.

> Hmm.  Can you please grep the build log for "TIMEOUT" and
> "increase-test-timeout", and show me the matching lines?

"increase-test-timeout":
```
starting phase `increase-test-timeout'
phase `increase-test-timeout' succeeded after 0.1 seconds
```

"TIMEOUT":
```
 53/259 glib:glib / rec-mutex   TIMEOUT 120.03 s
 83/259 glib:glib / 1bit-mutex  TIMEOUT 120.02 s 
 84/259 glib:glib+slow / 1bit-emufutex  TIMEOUT 180.05 s
```

Attached is the build log.

>>> (Incidentally, I *always* use Guix this way, using my own private branch
>>> of Guix, never using "guix pull", and never using substitutes.)
>>
>> This is interesting to me.
>
> I outlined how I use Guix in the following message:
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00625.html
>
> However, note that there are some significant caveats and "rough edges"
> to this approach.  I can't recommend it in good conscience, unless you
> truly need the extreme flexibility that it provides.
>
> To avoid the rough edges, I'd suggest using "guix pull --url" as
> outlined in the last two paragraphs of the message above.  For most
> purposes, I suspect you'd be much happier with that approach.

Thank you for sharing this.  Also thank you for the warning about 'significant 
caveats and "rough edges"'.

As a new user of Guix I think I will initially try to use the official
Guix repository.

However the message from Tobias Geerinckx-Rice in
https://issues.guix.gnu.org/48213 gives me the idea that your flexible
approach could be very useful if I find myself in a situation where I
have an issue that will not be addressed by an upstream project and
that has too much of a maintenance burden for Guix maintainers to take
on.



1kqwp7fsdphlkg75x0bhyw5m49y41d-glib-2.62.6.drv.bz2
Description: Binary data

bug#48024: glib-2.62.6 build fails i686

[Efraim Flashner]

On Tue, May 04, 2021 at 04:01:54PM -0400, Mark H Weaver wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> > In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
> > respectively.
> 
> Right.  Unfortunately, these timeouts are too short for many slower
> machines, such as 32-bit ARM systems.  Bone Baboon has also recently
> reported being unable to build 'glib' on a 32-bit i686 system due to
> these timeouts, even when making extreme efforts to reduce load from
> other processes.
> 
> > As I understand it, the tests which are are tagged '+slow' get the
> > test_timeout_slow property, with the test taking the longest on that
> > machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on
> > my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double
> > that time it still fell within the 180 seconds given by default in the
> > test suite so it was likely safe to remove the substitution entirely.
> 
> I think that this recently-reported bug ()
> demonstrates that we can't safely remove the substitution.
> 
> I think that we should re-introduce the 'increase-test-timeout' phase
> for all systems on the 'core-updates' branch.  Is there a disadvantage,
> besides having to wait a couple more minutes if a test fails to
> terminate?
> 
> What do you think?
> 
>   Regards,
> Mark

I looked closer at the bug report and I see they are timing out at 60
and 180 for Bone Baboon as they currently are.

Bone Baboon: Can you build the attached test-glib.scm file and send back
the build log? I want to make sure I change the timeout to something
long enough.

You can build it with 'guix build -f test-glib.scm'

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
; vim: set filetype=guix :

(use-modules
  (gnu packages glib)
  (guix utils)
  (guix packages))

(package
  (inherit glib)
  (replacement #f)
  (arguments
   (substitute-keyword-arguments (package-arguments glib)
 ((#:phases phases)
  `(modify-phases ,phases
 (add-after 'unpack 'adjust-test-timeout
   (lambda _
 (substitute* "meson.build"
   (("test_timeout = 60")
"test_timeout = 600")
   (("test_timeout_slow = 120")
"test_timeout_slow = 1200"))
 #t)))


signature.asc
Description: PGP signature

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Mark H Weaver writes:
> Right.  Unfortunately, these timeouts are too short for many slower
> machines, such as 32-bit ARM systems.  Bone Baboon has also recently
> reported being unable to build 'glib' on a 32-bit i686 system due to
> these timeouts, even when making extreme efforts to reduce load from
> other processes.

Here is information on the computer that is having tests timeout when
building glib.

* 4 GiB of RAM installed (the maximum)

* i686 32-bit 1 Core with 2.6 GHz

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Earlier, I wrote:
> I think that this recently-reported bug ()
> demonstrates that we can't safely remove the substitution.

To avoid having to scroll past the very long build log in the initial
bug report, it's probably best to read the bug report starting here:

https://bugs.gnu.org/48024#20

  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi Efraim,

Efraim Flashner  writes:
> In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
> respectively.

Right.  Unfortunately, these timeouts are too short for many slower
machines, such as 32-bit ARM systems.  Bone Baboon has also recently
reported being unable to build 'glib' on a 32-bit i686 system due to
these timeouts, even when making extreme efforts to reduce load from
other processes.

> As I understand it, the tests which are are tagged '+slow' get the
> test_timeout_slow property, with the test taking the longest on that
> machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on
> my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double
> that time it still fell within the 180 seconds given by default in the
> test suite so it was likely safe to remove the substitution entirely.

I think that this recently-reported bug ()
demonstrates that we can't safely remove the substitution.

> I don't have other suitably slow hardware to test on, but I am building
> it on my aarch64 board too, so I should be able to say in a day or two
> if it works there.

I don't see how a build test on your aarch64 board is relevant here.
As the comment above the 'increase-test-timeout' phase indicated, the
timeouts were increased for the sake of slower 32-bit ARM boards.

I think that we should re-introduce the 'increase-test-timeout' phase
for all systems on the 'core-updates' branch.  Is there a disadvantage,
besides having to wait a couple more minutes if a test fails to
terminate?

What do you think?

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Efraim Flashner]

On Mon, May 03, 2021 at 11:01:22PM -0400, Mark H Weaver wrote:
> Hi,  [added Efraim Flashner to the CC list]
> 
> Bone Baboon  writes:
> 
> > Thank you for your helpful response.
> >
> > Would a patch like this that addresses test timeouts be good to have in
> > the Guix repository?  It would help other Guix users who also run into
> > test timeouts when building glib.
> 
> Good question!  The problem is that applying this patch would entail
> rebuilding every package that depends on 'glib' for i686-linux, which is
> likely on the order of thousands of packages.  By policy, we don't make
> changes that require so many rebuilds on our 'master' branch.  Instead,
> such changes must be made on 'core-updates', or possibly 'staging',
> which are merged into 'master' a few times a year.
> 
> The plan seems to have been to remove the conditional on our
> 'core-updates' branch, so that the 'increase-test-timeout' phase would
> be included on *all* architectures.  See the comment above the code:
> 
>   
> 
> 
> However, I see now that the 'increase-test-timeout' phase was recently
> completely _removed_ by Efraim on our 'core-updates' branch a couple of
> weeks ago, in the following commit:
> 
>   
> 
> 
> Efraim: What was the rationale for removing that phase?
> 
> I think it would be good to keep that phase, for the benefit of users
> building 'glib' on slower machines.  I think the intent was to remove
> the conditional, but to keep the body that's within the conditional.
> 
> What do you think?
> 
>   Regards,
> Mark
> 

As part of my powerpc efforts I built glib on my way to building ...
something. This is on an iBook G4 with the original 4200 RPM drive from
~15 years ago, so old hardware.

In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
respectively. I initially merged the increase-test-timeout changes to
apply to all architectures, and then changed the time to 240 before
changing it to 1800 during my testing. I've attached the build log from
that round.

As I understand it, the tests which are are tagged '+slow' get the
test_timeout_slow property, with the test taking the longest on that
machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on
my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double
that time it still fell within the 180 seconds given by default in the
test suite so it was likely safe to remove the substitution entirely.

I don't have other suitably slow hardware to test on, but I am building
it on my aarch64 board too, so I should be able to say in a day or two
if it works there.

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


l8yf5a7jj5mz6s67fffhylyk7w1jbg-glib-2.68.0.drv.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,

Bone Baboon  writes:

> Mark H Weaver writes:
>> The following patch, applied to your copy of Guix, should work around
>> the problem:
>>
>> --8<---cut here---start->8---
>> diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
>> index c04bd334e9..b8f509306d 100644
>> --- a/gnu/packages/glib.scm
>> +++ b/gnu/packages/glib.scm
>> @@ -230,7 +230,8 @@ shared NFS home directories.")
>>#t)))
>>  ;; TODO: Remove the conditional in the next core-updates cycle.
>>  ;; Needed to build glib on slower ARM nodes.
>> -,@(if (string-prefix? "arm" (%current-system))
>> +,@(if (or (string-prefix? "arm" (%current-system))
>> +  (string-prefix? "i686" (%current-system)))
>>`((add-after 'unpack 'increase-test-timeout
>>(lambda _
>>  (substitute* "meson.build"
>> --8<---cut here---end--->8---
>>
>> To use this patch, you'll need to apply it to a Git checkout of Guix,
>> build it, and then use "/PATH-TO-GIT-CHECKOUT/pre-inst-env guix ..."
>> whenever building anything with Guix that depends on glib.
>
> Preparation steps taken:
> 1) cloned the Guix repository
> 2) ran `./bootstrap`
> 3) ran `./configure --localstatedir=/var/`
> 4) checked out a branch
> 5) applied the patch

Did you also run "make"?

> Then in the branch of the Guix repository with the patch applied I ran
> the following commands which failed with test timeouts.
>
> `./pre-inst-env guix build --no-substitutes glib`
> `./pre-inst-env guix build --no-substitutes --cores=2 glib`
> `./pre-inst-env guix build --no-substitutes --cores=3 glib`

Hmm.  Can you please grep the build log for "TIMEOUT" and
"increase-test-timeout", and show me the matching lines?

>> Alternatively, you *might* be able to build 'glib' successfully by not
>> doing anything else with your machine while it's building 'glib'.  [...]
>
> I tried this by having only ssh running so I could connect.  Then on a
> virtual terminal I ran `guix build --no-substitutes --cores=2 glib`.
> This failed with test timeouts.

Oh well, thanks for trying.

>> (Incidentally, I *always* use Guix this way, using my own private branch
>> of Guix, never using "guix pull", and never using substitutes.)
>
> This is interesting to me.

I outlined how I use Guix in the following message:

  https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00625.html

However, note that there are some significant caveats and "rough edges"
to this approach.  I can't recommend it in good conscience, unless you
truly need the extreme flexibility that it provides.

To avoid the rough edges, I'd suggest using "guix pull --url" as
outlined in the last two paragraphs of the message above.  For most
purposes, I suspect you'd be much happier with that approach.

> This is how I think a substitute server workflow could be modified to
> use this approach.  I would appreciate corrections or suggestions.

I'll postpone commenting on most of these, in case you decide to use the
"guix pull --url" method.  A few comments though:

> Substitute server clients would have a channel for the patched
> repository and no channel for the official Guix repository.

I've never used channels, and I'm not sure off-hand how to make them
work with my unusual approach.

> The commands stay the same on the clients of the substitute server.
>
> `guix pull --substitute-urls=:`
>
> `sudo guix system --subsitute-urls=:
> reconfigure `

This wouldn't work.  It's not enough to merely ask 'guix' to use your
substitute server.  If you did this, your clients would use the official
Guix package descriptions from our 'master' branch, but would look for
builds of those official packages on your substitute server.

To make this work, you would _also_ need to pass "--url "
each time you run 'guix pull' on your client machines.

Alternatively, if you chose to use my unusual approach, you'd need to
have built git checkouts of your custom branch of Guix on each of your
client machines, and run Guix from those git checkouts.

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,  [added Efraim Flashner to the CC list]

Bone Baboon  writes:

> Thank you for your helpful response.
>
> Would a patch like this that addresses test timeouts be good to have in
> the Guix repository?  It would help other Guix users who also run into
> test timeouts when building glib.

Good question!  The problem is that applying this patch would entail
rebuilding every package that depends on 'glib' for i686-linux, which is
likely on the order of thousands of packages.  By policy, we don't make
changes that require so many rebuilds on our 'master' branch.  Instead,
such changes must be made on 'core-updates', or possibly 'staging',
which are merged into 'master' a few times a year.

The plan seems to have been to remove the conditional on our
'core-updates' branch, so that the 'increase-test-timeout' phase would
be included on *all* architectures.  See the comment above the code:

  


However, I see now that the 'increase-test-timeout' phase was recently
completely _removed_ by Efraim on our 'core-updates' branch a couple of
weeks ago, in the following commit:

  


Efraim: What was the rationale for removing that phase?

I think it would be good to keep that phase, for the benefit of users
building 'glib' on slower machines.  I think the intent was to remove
the conditional, but to keep the body that's within the conditional.

What do you think?

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48024: glib-2.62.6 build fails i686

[Leo Famulari]

On Mon, May 03, 2021 at 06:00:19PM -0400, Bone Baboon via Bug reports for GNU 
Guix wrote:
> Mark H Weaver writes:
> > I also build everything locally, and have sometimes run into problems
> > like this on my slower machines.  Overly aggressive test timeouts,
> > chosen for powerful developer machines, are annoying.
> 
> What are the benefits of aggressive test timeouts chosen for powerful
> developer machines?

I don't think it's a question of "benefits" as much as "worked on my
machine". Developers don't use slow machines and they've set these
timeouts accordingly.

We do relax the timeouts sometimes, based on reports like yours, because
Guix is a build-from-source distro at heart, and it should be possible
to use it on slow or old computers.

bug#48024: glib-2.62.6 build fails i686

[Bone Baboon via Bug reports for GNU Guix]

Thank you for your helpful response.

Would a patch like this that addresses test timeouts be good to have in
the Guix repository?  It would help other Guix users who also run into
test timeouts when building glib.

Mark H Weaver writes:
> I also build everything locally, and have sometimes run into problems
> like this on my slower machines.  Overly aggressive test timeouts,
> chosen for powerful developer machines, are annoying.

What are the benefits of aggressive test timeouts chosen for powerful
developer machines?

> The following patch, applied to your copy of Guix, should work around
> the problem:
>
> --8<---cut here---start->8---
> diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
> index c04bd334e9..b8f509306d 100644
> --- a/gnu/packages/glib.scm
> +++ b/gnu/packages/glib.scm
> @@ -230,7 +230,8 @@ shared NFS home directories.")
>#t)))
>  ;; TODO: Remove the conditional in the next core-updates cycle.
>  ;; Needed to build glib on slower ARM nodes.
> -,@(if (string-prefix? "arm" (%current-system))
> +,@(if (or (string-prefix? "arm" (%current-system))
> +  (string-prefix? "i686" (%current-system)))
>`((add-after 'unpack 'increase-test-timeout
>(lambda _
>  (substitute* "meson.build"
> --8<---cut here---end--->8---
>
> To use this patch, you'll need to apply it to a Git checkout of Guix,
> build it, and then use "/PATH-TO-GIT-CHECKOUT/pre-inst-env guix ..."
> whenever building anything with Guix that depends on glib.

Preparation steps taken:
1) cloned the Guix repository
2) ran `./bootstrap`
3) ran `./configure --localstatedir=/var/`
4) checked out a branch
5) applied the patch

Then in the branch of the Guix repository with the patch applied I ran
the following commands which failed with test timeouts.

`./pre-inst-env guix build --no-substitutes glib`
`./pre-inst-env guix build --no-substitutes --cores=2 glib`
`./pre-inst-env guix build --no-substitutes --cores=3 glib`

> Alternatively, you *might* be able to build 'glib' successfully by not
> doing anything else with your machine while it's building 'glib'.  I
> notice that in your original bug report, only the "1bit-mutex" test
> timed out, but in your later build attempt, a total of 5 tests timed
> out.  These differing results suggest that you might have been running
> other programs at the same time.

I tried this by having only ssh running so I could connect.  Then on a
virtual terminal I ran `guix build --no-substitutes --cores=2 glib`.
This failed with test timeouts.

> (Incidentally, I *always* use Guix this way, using my own private branch
> of Guix, never using "guix pull", and never using substitutes.)

This is interesting to me.

This is how I think a substitute server workflow could be modified to
use this approach.  I would appreciate corrections or suggestions.

On the substitute server

Remove the official Guix substitute server from /etc/guix/acl.

Instead of: `guix pull --no-substitutes`
It would be: `git pull ` and merge the updated Guix
  repository with the local patched repository.

Instead of: `guix build --no-substitues `
It would be: `//pre-inst-env guix build `

Instead of: `guix publish `
It would be: `//pre-inst-env guix publish
  `

Instead of: `sudo guix system --no-substitutes reconfigure
 `
It would be: `sudo //pre-inst-env guix system
  reconfigure `

Substitute server clients would have a channel for the patched
repository and no channel for the official Guix repository.

The commands stay the same on the clients of the substitute server.

`guix pull --substitute-urls=:`

`sudo guix system --subsitute-urls=:
reconfigure `

bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver]

Hi,

Bone Baboon via Bug reports for GNU Guix  writes:
> On an i686 computer when I run the command `sudo guix system
> --no-substitutes --cores=2  reconfigure configuration.scm` I get this
> error:

and in a later message:

>  40/259 glib:glib / mutex   TIMEOUT 60.04 s
[...]
>  53/259 glib:glib / rec-mutex   TIMEOUT 60.04 s 
[...]
>  58/259 glib:glib / rwlock  TIMEOUT 60.03 s 
[...]
>  83/259 glib:glib / 1bit-mutex  TIMEOUT 60.02 s 
[...]
>  84/259 glib:glib+slow / 1bit-emufutex  TIMEOUT 180.03 s 

I also build everything locally, and have sometimes run into problems
like this on my slower machines.  Overly aggressive test timeouts,
chosen for powerful developer machines, are annoying.

The following patch, applied to your copy of Guix, should work around
the problem:

--8<---cut here---start->8---
diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index c04bd334e9..b8f509306d 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -230,7 +230,8 @@ shared NFS home directories.")
   #t)))
 ;; TODO: Remove the conditional in the next core-updates cycle.
 ;; Needed to build glib on slower ARM nodes.
-,@(if (string-prefix? "arm" (%current-system))
+,@(if (or (string-prefix? "arm" (%current-system))
+  (string-prefix? "i686" (%current-system)))
   `((add-after 'unpack 'increase-test-timeout
   (lambda _
 (substitute* "meson.build"
--8<---cut here---end--->8---

To use this patch, you'll need to apply it to a Git checkout of Guix,
build it, and then use "/PATH-TO-GIT-CHECKOUT/pre-inst-env guix ..."
whenever building anything with Guix that depends on glib.
(Incidentally, I *always* use Guix this way, using my own private branch
of Guix, never using "guix pull", and never using substitutes.)

Alternatively, you *might* be able to build 'glib' successfully by not
doing anything else with your machine while it's building 'glib'.  I
notice that in your original bug report, only the "1bit-mutex" test
timed out, but in your later build attempt, a total of 5 tests timed
out.  These differing results suggest that you might have been running
other programs at the same time.

 Regards,
   Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See  for more.

bug#48024: glib-2.62.6 build fails i686

[raingloom]

On Sun, 25 Apr 2021 23:35:42 -0400
Bone Baboon via Bug reports for GNU Guix  wrote:

> At the end of the build log this log is mentioned
> `/tmp/guix-build-glib-2.62.6.drv-0/build/meson-logs/testlog.txt`
> but it does not exist.
> 

Use the --keep-failed build option, otherwise the /tmp/guix-build-*
directories are deleted when their respective builds fail. Otherwise
they would just waste space.