gsasl 2 libgsasl{18,-common,-devel,-doc}

[Brian Inglis]

On 2022-09-30 06:39, Jon Turney wrote:
> On 29/09/2022 07:49, Brian Inglis wrote:
>>
>> Hi folks, [Please Reply All as ISP blocking Cygwin mail]
>>
>> It looks as if gsasl 2 is ABI 18 compatible with gsasl 1.10, so I am 
>> looking to release 2.2 as a continuation of the existing versions, and 
>> that is consistent with FreeBSD and Debian, where the developer 
>> appears to be among the package maintainers.
>>
>> One issue is that autoreconfig replaces the package provided 
>> gtk-doc.make with one from /usr/share/gtk-doc/data/gtk-doc*.make and 
>> they (all) need patched to build PDFs with DESTDIR builds.
>>
>> I handled this with local patches, added a src_patch_apply_hook to 
>> apply these for scallywag builds, and submitted patches upstream to 
>> the gsasl list and gtk-doc repo.
> 
> Is this the relevant patch?
> 
> https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/147
> 
>> The current orphaned gtk-doc cygport build seems to work automagically 
>> from the upstream tar(.xz) included in the source package, and I am 
>> too ignorant of Gnome, GTK, dblatex, TeX, etc., that I am 
>> uncomfortable adopting gtk-doc, as I have enough backlogged package 
>> updates.
>>
>> Suggestions for doing a non-maintainer update?

> I'm not sure what you are asking for here.
> 
> If you like, I can review and apply that patch to our package, and 
> rebuild it (since it seems I made the last one).
> 
> If you'd like NMU privileges, I think that would be ok also (in current 
> upload authorization scheme certain maintainers are allowed to upload 
> orphaned packages, there is no general NMU upload privilege).
> 
> The gtk packages are kind of important, it's unfortunate that we don't 
> have a maintainer for them.

I've tried building gtk-doc, locally and in Scallywag, but check gives 
me more FAILs than PASSes, so if you can build with PASSes, that would 
be better!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]