Re: Status of ‘core-updates’

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Steve,
>
> Steve George <steve@futurile.net> skribis:
>
>> On 10 Apr, Ludovic Courtès wrote:
>
> [...]
>
>>> To be clear (but I guess it’s crystal clear to anyone who’s been around
>>> long enough :-)), what we need most is someone to keep track of changes,
>>> coordinate efforts, decide what goes in the branch and what’s postponed
>>> or moved to a separate branch, and send periodic (weekly) status updates
>>> over the course of a couple of months.  This can (and probably should)
>>> be done without doing any actual hacking on the branch.
>> (...)
>>
>> This sounds like something I can do:
>>
>> - track changes (in branch)
>> - co-ordinate blocking issues (in bug system)
>> - co-ordinate with people doing the actual work :-P
>> - send (periodic) weekly emails
>> - encourage shipping by minimising scope creep ;-)
>
> Awesome, thanks for volunteering!
>
>> Sounds like there's already agreement to revert the 'pkgconf' change
>> and push a new branch without them which becomes
>> 'core-updates'. Josselin on IRC I had the impression you were
>> working on that?
>
> I’m not sure what the situation is (I see Maxim just pushed changes on
> top of current ‘core-updates’, so maybe it’s OK?).

Since branches were merged in, I believe the problem we are facing at
the moment is librsvg failing its test suite with a segfault (!).  Could
be the glibc upgrade, or rust itself, I'm not sure.  I was trying to
upgrade librsvg, which needs an update anyway, but it pulls many rust
crates updates.  I'll get there eventually, if nobody beats me to it.

> Josselin, Maxim: could you explain what problems there are around
> pkgconf and what you would recommend?

Nothing in particular to point at the moment, but remaining problems
would manifest in the form of missing inputs, due to transitive libtool
dependencies causing overlinking and the new pkgconf being smart enough
to optimize away some previously captured link directives that would be
baked in the RUNPATH and sastify libtool overlinking needs.

The solution is to hunt the libtool .la files from the transitive
dependencies causing the problem and removing them. See commit
b6540bd285cbe5920ad379ddfc6256359ee7204c for an example.

-- 
Thanks,
Maxim