[bug#66262] Failed to build in QA

[bug#66262] Failed to build in QA

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]


"reza.housseini@gmail.com" <reza.housseini@gmail.com> writes:

> On October 5, 2023 10:49:06 AM GMT+02:00, Christopher Baines <mail@cbaines.net> wrote:
>>
>>"reza.housseini@gmail.com" <reza.housseini@gmail.com> writes:
>>
>>> I submitted an issue to guix. But QA refuses to build it [1]. I have
>>> no clue what the problem is, can anyone shed light on a possible
>>> resolution?
>>
>>You pretty much found the problem, the relevant line on the page you
>>linked to is:
>>
>>[  6/ 50] loading...	 24.0% of 25 filesbuilder for `/gnu/store/qhvpjfn3d9cwz5zxadblbnbqa92a8i27-guix-cli-core.drv' failed due to signal 11 (Segmentation fault)
>>
>>So the data service wasn't able to build Guix. This probably isn't due
>>to your changes, and it doesn't happen very often, so the thing to do
>>here is just retry.
>>
>>I've triggered QA to reapply the patches now (by deleting the
>>issue-66262 branch), so hopefully things will work better this time.
>>
>>Thanks,
>>
>>Chris
>
> Thanks very much, it seems to have worked, but now it's stuck with
> paraview undefined symbol, although the necessary module
> (gnu/packages/image-processing) is imported?

This is probably down to a top level circular dependency. In particular,
trying to paraview to compute the version to form part of the
native-search-path at the top level causes problems.

Making openfoam have LD_LIBRARY_PATH as a search path seems like the
incorrect use of search paths though, since you're searching for
something in the same package. Replacing this with wrapping would be an
improvement, although still I'm unsure why LD_LIBRARY_PATH would need
setting in this case.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

[bug#66262] Failed to build in QA

[Reza Housseini]

[-- Attachment #1.1.1: Type: text/plain, Size: 702 bytes --]

> This is probably down to a top level circular dependency. In particular,
> trying to paraview to compute the version to form part of the
> native-search-path at the top level causes problems.

I'm wondering why it builds fine locally but causes problems in QA have 
you any pointers what might be the difference?

> Making openfoam have LD_LIBRARY_PATH as a search path seems like the
> incorrect use of search paths though, since you're searching for
> something in the same package. Replacing this with wrapping would be an
> improvement, although still I'm unsure why LD_LIBRARY_PATH would need
> setting in this case
Hmm maybe you are right, will try to wrap the binaries instead...

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 15557 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[bug#66262] Failed to build in QA

[reza.housseini]

On October 9, 2023 12:40:40 PM UTC, Reza Housseini <reza.housseini@gmail.com> wrote:
>> This is probably down to a top level circular dependency. In particular,
>> trying to paraview to compute the version to form part of the
>> native-search-path at the top level causes problems.
>
>I'm wondering why it builds fine locally but causes problems in QA have you any pointers what might be the difference?
>
>> Making openfoam have LD_LIBRARY_PATH as a search path seems like the
>> incorrect use of search paths though, since you're searching for
>> something in the same package. Replacing this with wrapping would be an
>> improvement, although still I'm unsure why LD_LIBRARY_PATH would need
>> setting in this case
>Hmm maybe you are right, will try to wrap the binaries instead...

I removed the search-path but it still fails to build, I cannot make sense of the error message...

[bug#66262] Failed to build in QA

[Reza Housseini]

Hi Christopher

I submitted a new revision to the issue, but the QA link shows

Issue not found
This could mean the issue does not exist, it has no patches or has been 
closed.

do you know what the problem is here?

Thanks for your help,
Best,
Reza

[bug#66262] Failed to build in QA

[reza via Guix-patches via]

> i also see this every once in a while. i guess it's because the SMTP server-farm receives mutliple emails in close proximity, and they end up reaching debbugs in a different order.

What is the way to go here, shall I just resubmit?

[bug#66262] Failed to build in QA

[reza via Guix-patches via]

On 11/29/23 21:11, reza via Guix-patches via wrote:
>> i also see this every once in a while. i guess it's because the SMTP server-farm receives mutliple emails in close proximity, and they end up reaching debbugs in a different order.
> 
> What is the way to go here, shall I just resubmit?

I submitted them now (twice). The first attempt ended the same as the 
former and the second time I waited until the mail appeared in the issue 
tracker, a rather slow and inefficient way to submit patches.

What I do not understand is why the list seems to receive the mails in 
order, but then issues.guix.gnu.org mangles them somehow. Is this a bug?

I now also have a new error for QA:

An error occurred
Sorry about that!

json-invalid
#<input:delimited input port 7f52a7ff97c0>

I have the impression I now cycled through all possible pitfalls...