public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2
@ 2022-07-18  5:10 Brian Inglis
  2022-07-18 11:43 ` Marco Atzeri
  2022-07-18 16:14 ` [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2 ASSI
  0 siblings, 2 replies; 7+ messages in thread
From: Brian Inglis @ 2022-07-18  5:10 UTC (permalink / raw)
  To: cygwin-apps

I'd like to adopt orphaned package gsasl as new versions have been released.

	https://cygwin.com/packages/summary/gsasl-src.html

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git

I've rebuilt current 1.8 and upgraded releases 1.8.1, 1.10, 2.0, and
2.0.1 for x86/i686 and x86_64 without any issues.
The 2.0.1 build was run in GitHub Actions CI using the gsasl repo
playground branch; see:

	https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=gsasl

and scallywag logs are at:

	https://github.com/cygwin/scallywag/actions/runs/2682310926

I'd like to release 1.10 which is ABI compatible, as a test release with
libcurl4 depending on it (also mine), a lot of libraries depend on that,
and a lot of packages depend on those; try:

	$ cygcheck-dep -qSN libgsasl7 | less

Release 2.0 jumps to libgsasl18, so that should probably be released as
gsasl2/libgsasl2-{common,-devel,-doc}, and libcurl4 built and test 
released with that?

Should the new library stay as libgsasl18 or be named libgsasl2_18?

How to rebuild libcurl4 with libgsasl2-devel using libgsasl{2_}18?

-- 
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.]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2
  2022-07-18  5:10 [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2 Brian Inglis
@ 2022-07-18 11:43 ` Marco Atzeri
  2022-07-18 15:18   ` Brian Inglis
  2022-09-29  6:49   ` gsasl 2 libgsasl{18,-common,-devel,-doc} Brian Inglis
  2022-07-18 16:14 ` [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2 ASSI
  1 sibling, 2 replies; 7+ messages in thread
From: Marco Atzeri @ 2022-07-18 11:43 UTC (permalink / raw)
  To: cygwin-apps

On 18.07.2022 07:10, Brian Inglis wrote:
> I'd like to adopt orphaned package gsasl as new versions have been 
> released.
> 
>      https://cygwin.com/packages/summary/gsasl-src.html
> 

all yours

> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git
> 
> I've rebuilt current 1.8 and upgraded releases 1.8.1, 1.10, 2.0, and
> 2.0.1 for x86/i686 and x86_64 without any issues.
> The 2.0.1 build was run in GitHub Actions CI using the gsasl repo
> playground branch; see:
> 
>      https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=gsasl
> 
> and scallywag logs are at:
> 
>      https://github.com/cygwin/scallywag/actions/runs/2682310926
> 
> I'd like to release 1.10 which is ABI compatible, as a test release with
> libcurl4 depending on it (also mine), a lot of libraries depend on that,
> and a lot of packages depend on those; try:
> 
>      $ cygcheck-dep -qSN libgsasl7 | less
> 
> Release 2.0 jumps to libgsasl18, so that should probably be released as
> gsasl2/libgsasl2-{common,-devel,-doc}, and libcurl4 built and test 
> released with that?
> 
> Should the new library stay as libgsasl18 or be named libgsasl2_18?

I would follow the name of the library.
If it is just cyggsasl-18.dll use libgsasl18

> How to rebuild libcurl4 with libgsasl2-devel using libgsasl{2_}18?

I suggest to avoid collision between version 1 and 2.
possibly moving away the old version and leaving in the usual place the 
last one

/usr/include/*.h -> /usr/include/gsasl1/*.h
usr/lib/libgsasl.dll.a usr/lib/gsasl1/libgsasl.dll.a


Regards
Marco

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2
  2022-07-18 11:43 ` Marco Atzeri
@ 2022-07-18 15:18   ` Brian Inglis
  2022-09-29  6:49   ` gsasl 2 libgsasl{18,-common,-devel,-doc} Brian Inglis
  1 sibling, 0 replies; 7+ messages in thread
From: Brian Inglis @ 2022-07-18 15:18 UTC (permalink / raw)
  To: cygwin-apps

On 2022-07-18 05:43, Marco Atzeri wrote:
> On 18.07.2022 07:10, Brian Inglis wrote:
>> I'd like to adopt orphaned package gsasl as new versions have been 
>> released.
>>
>>      https://cygwin.com/packages/summary/gsasl-src.html
>>
> 
> all yours
> 
>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git
>>
>> I've rebuilt current 1.8 and upgraded releases 1.8.1, 1.10, 2.0, and
>> 2.0.1 for x86/i686 and x86_64 without any issues.
>> The 2.0.1 build was run in GitHub Actions CI using the gsasl repo
>> playground branch; see:
>>
>>      https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=gsasl
>>
>> and scallywag logs are at:
>>
>>      https://github.com/cygwin/scallywag/actions/runs/2682310926
>>
>> I'd like to release 1.10 which is ABI compatible, as a test release with
>> libcurl4 depending on it (also mine), a lot of libraries depend on that,
>> and a lot of packages depend on those; try:
>>
>>      $ cygcheck-dep -qSN libgsasl7 | less
>>
>> Release 2.0 jumps to libgsasl18, so that should probably be released as
>> gsasl2/libgsasl2-{common,-devel,-doc}, and libcurl4 built and test 
>> released with that?
>>
>> Should the new library stay as libgsasl18 or be named libgsasl2_18?
> 
> I would follow the name of the library.
> If it is just cyggsasl-18.dll use libgsasl18
> 
>> How to rebuild libcurl4 with libgsasl2-devel using libgsasl{2_}18?
> 
> I suggest to avoid collision between version 1 and 2.
> possibly moving away the old version and leaving in the usual place the 
> last one
> 
> /usr/include/*.h -> /usr/include/gsasl1/*.h
> usr/lib/libgsasl.dll.a usr/lib/gsasl1/libgsasl.dll.a

Grazie Marco, for the "adoption papers" ;^> and the advice.

Others' further thoughts are still sought and will be gratefully 
received and ad[ao]pted ;^>

-- 
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.]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2
  2022-07-18  5:10 [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2 Brian Inglis
  2022-07-18 11:43 ` Marco Atzeri
@ 2022-07-18 16:14 ` ASSI
  1 sibling, 0 replies; 7+ messages in thread
From: ASSI @ 2022-07-18 16:14 UTC (permalink / raw)
  To: cygwin-apps

Brian Inglis writes:
> I'd like to release 1.10 which is ABI compatible, as a test release with
> libcurl4 depending on it (also mine), a lot of libraries depend on that,
> and a lot of packages depend on those; try:
>
> 	$ cygcheck-dep -qSN libgsasl7 | less
>
> Release 2.0 jumps to libgsasl18, so that should probably be released as
> gsasl2/libgsasl2-{common,-devel,-doc}, and libcurl4 built and test
> released with that?
>
> Should the new library stay as libgsasl18 or be named libgsasl2_18?

No, at least it doesn't appear that upstream plans to support both
branches going forward.

At the moment no major distribution seems to package 2.0.1, but you can
glean what Debian is doing for their next release:

https://packages.debian.org/sid/source/gsasl

I would suggest keeping 1.10 current until at least two major distros
have switched.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gsasl 2 libgsasl{18,-common,-devel,-doc}
  2022-07-18 11:43 ` Marco Atzeri
  2022-07-18 15:18   ` Brian Inglis
@ 2022-09-29  6:49   ` Brian Inglis
  2022-09-30 12:39     ` Jon Turney
  1 sibling, 1 reply; 7+ messages in thread
From: Brian Inglis @ 2022-09-29  6:49 UTC (permalink / raw)
  To: Cygwin Applications; +Cc: Brian Inglis

On 2022-07-18 05:43, Marco Atzeri wrote:
> On 18.07.2022 07:10, Brian Inglis wrote:
>> I'd like to adopt orphaned package gsasl as new versions have been 
>> released.
>>
>>      https://cygwin.com/packages/summary/gsasl-src.html
>>
> 
> all yours
> 
>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git
>>
>> I've rebuilt current 1.8 and upgraded releases 1.8.1, 1.10, 2.0, and
>> 2.0.1 for x86/i686 and x86_64 without any issues.
>> The 2.0.1 build was run in GitHub Actions CI using the gsasl repo
>> playground branch; see:
>>
>>      https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=gsasl
>>
>> and scallywag logs are at:
>>
>>      https://github.com/cygwin/scallywag/actions/runs/2682310926
>>
>> I'd like to release 1.10 which is ABI compatible, as a test release with
>> libcurl4 depending on it (also mine), a lot of libraries depend on that,
>> and a lot of packages depend on those; try:
>>
>>      $ cygcheck-dep -qSN libgsasl7 | less
>>
>> Release 2.0 jumps to libgsasl18, so that should probably be released as
>> gsasl2/libgsasl2-{common,-devel,-doc}, and libcurl4 built and test 
>> released with that?
>>
>> Should the new library stay as libgsasl18 or be named libgsasl2_18?
> 
> I would follow the name of the library.
> If it is just cyggsasl-18.dll use libgsasl18
> 
>> How to rebuild libcurl4 with libgsasl2-devel using libgsasl{2_}18?
> 
> I suggest to avoid collision between version 1 and 2.
> possibly moving away the old version and leaving in the usual place the 
> last one
> 
> /usr/include/*.h -> /usr/include/gsasl1/*.h
> usr/lib/libgsasl.dll.a usr/lib/gsasl1/libgsasl.dll.a

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.

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?

-- 
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.]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gsasl 2 libgsasl{18,-common,-devel,-doc}
  2022-09-29  6:49   ` gsasl 2 libgsasl{18,-common,-devel,-doc} Brian Inglis
@ 2022-09-30 12:39     ` Jon Turney
  2022-09-30 17:55       ` Brian Inglis
  0 siblings, 1 reply; 7+ messages in thread
From: Jon Turney @ 2022-09-30 12:39 UTC (permalink / raw)
  To: cygwin-apps, Brian Inglis

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gsasl 2 libgsasl{18,-common,-devel,-doc}
  2022-09-30 12:39     ` Jon Turney
@ 2022-09-30 17:55       ` Brian Inglis
  0 siblings, 0 replies; 7+ messages in thread
From: Brian Inglis @ 2022-09-30 17:55 UTC (permalink / raw)
  To: Cygwin Applications; +Cc: 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.]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-09-30 17:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-18  5:10 [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2 Brian Inglis
2022-07-18 11:43 ` Marco Atzeri
2022-07-18 15:18   ` Brian Inglis
2022-09-29  6:49   ` gsasl 2 libgsasl{18,-common,-devel,-doc} Brian Inglis
2022-09-30 12:39     ` Jon Turney
2022-09-30 17:55       ` Brian Inglis
2022-07-18 16:14 ` [ITA] gsasl libgsasl{7,-common,-devel,-doc} gsasl 2 ASSI

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).