Re: Status of ‘core-updates’

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

Hi Maxim,

On Wed, Apr 17 2024, Maxim Cournoyer wrote:

> The solution is to hunt the libtool .la files

Would my old web-based file finder, which I could resurrect, help with
locating such files?

Kind regards
Felix

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[Maxim Cournoyer]

Hi Matt,

Matt  writes:

>   On Mon, 15 Apr 2024 14:58:50 +0200  pelzflorian (Florian Pelz)  wrote 
> --- 
>
>  > Do you agree that I should commit your docs correction with @pxref?
>  > I believe it is an improvement over current “see @ref”, even though it
>  > looks different in the info reader.
>  
> Yes, I agree and thank you for double checking.  Sorry for not
> answering you more clearly before!  @pxref is the correct command to
> use within parentheses.
>
>  > I believe the Emacs errors are historical; looking at Emacs 29.3 as
>  > packaged in Guix, Emacs-Info displays xref properly as See.  Display
>  > errors had existed, but in the past only.
>
> I reported it to emacs-devel (it's addressed now) and the issue isn't
> technically @xrefs; it's the compilation of @xref and @ref, '*Note'
> and '*note' respectively.  Emacs looks at the context around these and
> renders them as 'See' or 'see' according to what's nearby.  The
> trouble is that the Texinfo documentation intends to show '*Note' and
> '*note' literally which is an exception to the Emacs logic.
>   
> I looked it up and the related Emacs code had been there for like 18
> years...I have a knack for finding these kinds of dumb things.  I
> can't decide if it's a superpower or a super-curse. :)

Awesome!  Definitely a superpower in my book.  Thanks for following it
through with the Emacs folks!  I'm sure I was bothered by that
inconsistency before but couldn't put my finger on the culprit.

-- 
Thanks,
Maxim

Re: Status of ‘core-updates’

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi Steve,
>
> Steve George  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