Investigating Cirrus CI FreeBSD failures

Investigating Cirrus CI FreeBSD failures

[Philippe Blain]

Hi,

I spent a bit of time investigating the Git Cirrus-CI failures on FreeBSD.
It seems something goes wrong with the Perl installation, as most failures 
are in t9001-send-email.sh, and the error messages are:

ld-elf.so.1: /usr/local/lib/perl5/5.32/mach/CORE/libperl.so.5.32: Undefined symbol "strerror_l@FBSD_1.6"

The first instance is in t9001.6. (See for example [1]).

I know next to nothing about Perl or FreeBSD, but simply changing our image
to FreeBSD 13.0 makes all failures in t9001 disappear [2]:


diff --git a/.cirrus.yml b/.cirrus.yml
index 0d94d89f6c..d1ea14362f 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -9,7 +9,7 @@ freebsd_12_task:
     DEFAULT_TEST_TARGET: prove
     DEVELOPER: 1
   freebsd_instance:
-    image_family: freebsd-12-2
+    image_family: freebsd-13-0
     memory: 2G
   install_script:
     pkg install -y gettext gmake perl5 vim

Is this something that we should do ? Or should we stick to FreeBSD 12
and try to debug this installation problem ?

Cheers,
Philippe.

[1] https://cirrus-ci.com/task/5856927879004160
[2] https://cirrus-ci.com/task/4597971764379648

Re: Investigating Cirrus CI FreeBSD failures

[Carlo Arenas]

Reviewed-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>

Re: Investigating Cirrus CI FreeBSD failures

[Ed Maste]

On Fri, 20 May 2022 at 20:38, Philippe Blain
<levraiphilippeblain@gmail.com> wrote:
>
> Hi,
>
> I spent a bit of time investigating the Git Cirrus-CI failures on FreeBSD.
> It seems something goes wrong with the Perl installation, as most failures
> are in t9001-send-email.sh, and the error messages are:
>
> ld-elf.so.1: /usr/local/lib/perl5/5.32/mach/CORE/libperl.so.5.32: Undefined symbol "strerror_l@FBSD_1.6"

Ah, what happened here is that this is picking up the perl package
built on 12.3 (i.e., the earliest supported FreeBSD 12.x) which added
strerror_l.
https://cgit.freebsd.org/src/commit/?id=d3912bec58d0b82509a0973cae02f156986d88fa

> I know next to nothing about Perl or FreeBSD, but simply changing our image
> to FreeBSD 13.0 makes all failures in t9001 disappear [2]:
>
> ...
> Is this something that we should do ? Or should we stick to FreeBSD 12
> and try to debug this installation problem ?

I expect this could have been addressed also by updating to 12.3.
Cirrus also supports "matrix" so both could be tested.

Re: Investigating Cirrus CI FreeBSD failures

[Philippe Blain]

Hi Ed,

Le 2022-05-30 à 12:09, Ed Maste a écrit :
> On Fri, 20 May 2022 at 20:38, Philippe Blain
> <levraiphilippeblain@gmail.com> wrote:
>>
>> Hi,
>>
>> I spent a bit of time investigating the Git Cirrus-CI failures on FreeBSD.
>> It seems something goes wrong with the Perl installation, as most failures
>> are in t9001-send-email.sh, and the error messages are:
>>
>> ld-elf.so.1: /usr/local/lib/perl5/5.32/mach/CORE/libperl.so.5.32: Undefined symbol "strerror_l@FBSD_1.6"
> 
> Ah, what happened here is that this is picking up the perl package
> built on 12.3 (i.e., the earliest supported FreeBSD 12.x) which added
> strerror_l.
> https://cgit.freebsd.org/src/commit/?id=d3912bec58d0b82509a0973cae02f156986d88fa

OK, so it is expected that the Cirrus 12.2 image would install this newer
version of the perl package which if I understand correctly is not compatible
with this version ?

Is there a way to tell pkg not to update packages to incompatible versions,
or is the FreeBSD policy that as soon as a release is marked as unsupported, 
then no guarantee is made that things (like installing packages) continue working 
on that version ?

> 
>> I know next to nothing about Perl or FreeBSD, but simply changing our image
>> to FreeBSD 13.0 makes all failures in t9001 disappear [2]:
>>
>> ...
>> Is this something that we should do ? Or should we stick to FreeBSD 12
>> and try to debug this installation problem ?
> 
> I expect this could have been addressed also by updating to 12.3.
> Cirrus also supports "matrix" so both could be tested.
> 

For now we opted to just update to 12.3, see [1].

Thanks for your answer,

Philippe.

[1] https://lore.kernel.org/git/20220525125112.86954-1-levraiphilippeblain@gmail.com/

Re: Investigating Cirrus CI FreeBSD failures

[Junio C Hamano]

Philippe Blain <levraiphilippeblain@gmail.com> writes:

>> Ah, what happened here is that this is picking up the perl package
>> built on 12.3 (i.e., the earliest supported FreeBSD 12.x) which added
>> strerror_l.
>> https://cgit.freebsd.org/src/commit/?id=d3912bec58d0b82509a0973cae02f156986d88fa
>
> OK, so it is expected that the Cirrus 12.2 image would install this newer
> version of the perl package which if I understand correctly is not compatible
> with this version ?
>
> Is there a way to tell pkg not to update packages to incompatible versions,
> or is the FreeBSD policy that as soon as a release is marked as unsupported, 
> then no guarantee is made that things (like installing packages) continue working 
> on that version ?

Sorry for a noise, but I would also be curious to know, as it is
quite unexpected for a packaging system to miss such a compatibility
issue and for a distro to not care.

>> I expect this could have been addressed also by updating to 12.3.
>> Cirrus also supports "matrix" so both could be tested.
>
> For now we opted to just update to 12.3, see [1].

Indeed we did.  Let's make sure we fast-track the topic down to
'master' and possibly to 'maint'.  I do not think it is worth
letting it sit in 'next' for a week, like we do for usual topics.

Thanks.

P.S. I'll be offline today (like every other Tuesday).

Re: Investigating Cirrus CI FreeBSD failures

[Johannes Schindelin]

Hi Junio,

On Tue, 31 May 2022, Junio C Hamano wrote:

> Philippe Blain <levraiphilippeblain@gmail.com> writes:
>
> > For now we opted to just update to 12.3, see [1].
>
> Indeed we did.  Let's make sure we fast-track the topic down to 'master'
> and possibly to 'maint'.  I do not think it is worth letting it sit in
> 'next' for a week, like we do for usual topics.

I am very much in favor of merging this down into `maint`, as every PR run
of GitGitGadget's PRs fails right now (and some new contributors already
were worried about this).

Thanks,
Dscho