Scallywag glitch with texlive-collection-* packages

Scallywag glitch with texlive-collection-* packages

[Ken Brown]

Jon,

All texlive-collection-* packages are noarch.  This is defined in 
texlive.cygclass, so scallywag doesn't see it.  I just let scallywag deploy 
texlive-collection-bibtexextra and texlive-collection-bibtexextra-doc before I 
noticed that it was building for x86 and x86_64.

I won't have time to fix this until tomorrow.

Ken

Re: Scallywag glitch with texlive-collection-* packages

[Jon Turney]

On 13/09/2020 23:48, Ken Brown via Cygwin-apps wrote:
> Jon,
> 
> All texlive-collection-* packages are noarch.  This is defined in 
> texlive.cygclass, so scallywag doesn't see it.  I just let scallywag

Oof.

Yeah, this is an unfortunate consequence of trying to guess this stuff 
by looking at the .cygport, rather than running (some yet to be written 
mode of) cygport to process it and output the needed information.

I've made scallywag aware that 'inherit texlive' implies noarchness, so 
it should get it right going forward.

> deploy texlive-collection-bibtexextra and 
> texlive-collection-bibtexextra-doc before I noticed that it was building 
> for x86 and x86_64.
> 
> I won't have time to fix this until tomorrow.

Fortunately these are test: packages, so I think you can build a bumped 
package and then remove these mistaken packages at your convenience.

Thanks for testing!

Re: Scallywag glitch with texlive-collection-* packages

[Brian Inglis]

On 2020-09-14 05:47, Jon Turney wrote:
> On 13/09/2020 23:48, Ken Brown via Cygwin-apps wrote:
>> Jon,
>>
>> All texlive-collection-* packages are noarch.  This is defined in
>> texlive.cygclass, so scallywag doesn't see it.  I just let scallywag

> Yeah, this is an unfortunate consequence of trying to guess this stuff by
> looking at the .cygport, rather than running (some yet to be written mode of)
> cygport to process it and output the needed information.
> 
> I've made scallywag aware that 'inherit texlive' implies noarchness, so it
> should get it right going forward.

Any changes made or needed in cygport or scallywag for mingw64 packages?
I've rebuilt and reuploaded both Mingw curl noarches to see if they make it.

I found that for cygport NAME must be a hardcoded constant string not requiring
script evaluation; hopefully other content is evaluated in the script context
and does not also require to be hardcoded constants.

-- 
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 IEC units and prefixes, physical quantities in SI.]

Re: Scallywag glitch with texlive-collection-* packages

[ASSI]

Brian Inglis writes:
> Any changes made or needed in cygport or scallywag for mingw64 packages?
> I've rebuilt and reuploaded both Mingw curl noarches to see if they make it.

If you're just trying out things push to the playground branch and
iterate it there until it works.  You can force-push to this branch and
delete it afterwards if you want.

You still haven't added the necessary BUILD_REQUIRES correctly.  Btw,
ZStandard is available both natively and for mingw64 in Cygwin.

> I found that for cygport NAME must be a hardcoded constant string not requiring
> script evaluation; hopefully other content is evaluated in the script context
> and does not also require to be hardcoded constants.

You need to lose that $XARCH monkey business as well.  Scallywag just
looks at the file, it doesn't evaluate anything.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Scallywag glitch with texlive-collection-* packages

[Brian Inglis]

On 2020-09-14 23:34, ASSI wrote:
> Brian Inglis writes:
>> Any changes made or needed in cygport or scallywag for mingw64 packages?
>> I've rebuilt and reuploaded both Mingw curl noarches to see if they make it.
> 
> If you're just trying out things push to the playground branch and
> iterate it there until it works.  You can force-push to this branch and
> delete it afterwards if you want.

I just rebuilt all packages locally as release 2 and compared with the release 1
config and build logs to ensure the results were identical other than the
release number, before renumbering the cygport release back to 1 and committing
and pushing the cygport updates to git-cygwin-packages.

> You still haven't added the necessary BUILD_REQUIRES correctly.  Btw,

AFAIR multi-line BUILD_REQUIRES strings with and without \ at EoL caused
problems, so I have added a series of += statements to create that and DEPEND in
the latest cygport pushes to git-cygwin-packages, and align all 3 cygports as
much as possible for ease of comparison and maintenance (using gvimdiff).

> ZStandard is available both natively and for mingw64 in Cygwin.

Good suggestion, as it is picked up automatically by Cygwin curl config, but
although everything appears to be the same for zlib and zstd, other than zstd
missing a default sharedlibdir definition in zstd.pc, that is not found in the
mingw64 config which fails:

configure:21544: checking for x86_64-w64-mingw32-pkg-config
configure:21575: result: /usr/bin/x86_64-w64-mingw32-pkg-config
configure:21644: checking for zlib options with pkg-config
configure:21658: result: found
configure:21723: checking for zlib.h
configure:21723: result: yes
configure:21811: found both libz and libz.h header
configure:22106: checking for x86_64-w64-mingw32-pkg-config
configure:22137: result: /usr/bin/x86_64-w64-mingw32-pkg-config
configure:22206: checking for libzstd options with pkg-config
configure:22220: result: found
configure:22253: checking for ZSTD_createDStream in -lzstd
configure:22284: result: no
configure:22298: checking for zstd.h
configure:22298: result: no
configure:22318: error: libzstd was not found where specified!

As I am new to mingw64 packaging, any suggestions for things to try or tweaks
for mingw64 build are welcome.
Do I need to cross_de/sysrootize zstd.pc or something?

$ head -n19 /usr/lib/pkgconfig/*z???*.pc
==> /usr/lib/pkgconfig/libzstd.pc <==
#   ZSTD - standard compression algorithm
#   Copyright (C) 2014-2016, Yann Collet, Facebook
#   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: zstd
Description: fast lossless compression algorithm library
URL: http://www.zstd.net/
Version: 1.4.5
Libs: -L${libdir} -lzstd
Cflags: -I${includedir}

==> /usr/lib/pkgconfig/zlib.pc <==
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
sharedlibdir=/usr/lib
includedir=/usr/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}

>> I found that for cygport NAME must be a hardcoded constant string not requiring
>> script evaluation; hopefully other content is evaluated in the script context
>> and does not also require to be hardcoded constants.
> 
> You need to lose that $XARCH monkey business as well.  Scallywag just
> looks at the file, it doesn't evaluate anything.

That variable makes it easier for me to align and copy/paste changes between
cygport scripts with fewer errors, which is why I added it, as I could not come
up with a meaningful name to call the mingw64-$XARCH prefix, and also worried
about possibly conflicting with cygport variables.

As not all variables can be specified as multi-line constants, and I am
uncomfortable specifying variables in lines hundreds of bytes long, they need to
be composed with short lines using +=, and not evaluating may lead to incorrect
results.

[TL;DR: I got used in (macro) assemblers and earlier (strict) languages to
abstracting out very granular architectural features and data, definitions, and
patterns into common specification header definitions distinct from the abstract
implementation in code, and that is still my preferred personal development
style, subject to project variations: that may annoy others as much as my seeing
others using any manifest constant values (other than 0, 1, various nulls) in code!]

-- 
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 IEC units and prefixes, physical quantities in SI.]

Re: Scallywag glitch with texlive-collection-* packages

[Brian Inglis]

On 2020-09-15 23:13, Brian Inglis wrote:
> On 2020-09-14 23:34, ASSI wrote:
>> Brian Inglis writes:
>>> Any changes made or needed in cygport or scallywag for mingw64 packages?
>>> I've rebuilt and reuploaded both Mingw curl noarches to see if they make it.
>>
>> If you're just trying out things push to the playground branch and
>> iterate it there until it works.  You can force-push to this branch and
>> delete it afterwards if you want.
> 
> I just rebuilt all packages locally as release 2 and compared with the release 1
> config and build logs to ensure the results were identical other than the
> release number, before renumbering the cygport release back to 1 and committing
> and pushing the cygport updates to git-cygwin-packages.
> 
>> You still haven't added the necessary BUILD_REQUIRES correctly.  Btw,
> 
> AFAIR multi-line BUILD_REQUIRES strings with and without \ at EoL caused
> problems, so I have added a series of += statements to create that and DEPEND in
> the latest cygport pushes to git-cygwin-packages, and align all 3 cygports as
> much as possible for ease of comparison and maintenance (using gvimdiff).
> 
>> ZStandard is available both natively and for mingw64 in Cygwin.
> 
> Good suggestion, as it is picked up automatically by Cygwin curl config, but
> although everything appears to be the same for zlib and zstd, other than zstd
> missing a default sharedlibdir definition in zstd.pc, that is not found in the
> mingw64 config which fails:
> 
> configure:21544: checking for x86_64-w64-mingw32-pkg-config
> configure:21575: result: /usr/bin/x86_64-w64-mingw32-pkg-config
> configure:21644: checking for zlib options with pkg-config
> configure:21658: result: found
> configure:21723: checking for zlib.h
> configure:21723: result: yes
> configure:21811: found both libz and libz.h header
> configure:22106: checking for x86_64-w64-mingw32-pkg-config
> configure:22137: result: /usr/bin/x86_64-w64-mingw32-pkg-config
> configure:22206: checking for libzstd options with pkg-config
> configure:22220: result: found
> configure:22253: checking for ZSTD_createDStream in -lzstd
> configure:22284: result: no
> configure:22298: checking for zstd.h
> configure:22298: result: no
> configure:22318: error: libzstd was not found where specified!
> 
> As I am new to mingw64 packaging, any suggestions for things to try or tweaks
> for mingw64 build are welcome.
> Do I need to cross_de/sysrootize zstd.pc or something?
> 
> $ head -n19 /usr/lib/pkgconfig/*z???*.pc
> ==> /usr/lib/pkgconfig/libzstd.pc <==
> #   ZSTD - standard compression algorithm
> #   Copyright (C) 2014-2016, Yann Collet, Facebook
> #   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)
> 
> prefix=/usr
> exec_prefix=${prefix}
> includedir=${prefix}/include
> libdir=${exec_prefix}/lib
> 
> Name: zstd
> Description: fast lossless compression algorithm library
> URL: http://www.zstd.net/
> Version: 1.4.5
> Libs: -L${libdir} -lzstd
> Cflags: -I${includedir}
> 
> ==> /usr/lib/pkgconfig/zlib.pc <==
> prefix=/usr
> exec_prefix=/usr
> libdir=/usr/lib
> sharedlibdir=/usr/lib
> includedir=/usr/include
> 
> Name: zlib
> Description: zlib compression library
> Version: 1.2.11
> 
> Requires:
> Libs: -L${libdir} -lz
> Cflags: -I${includedir}

Just compared mingw package contents and found actual .pc under sys-root:

$ head -n19 /usr/*86*-w64-mingw32/sys-root/mingw/lib/pkgconfig/*z???.pc
==> /usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig/libzstd.pc <==
#   ZSTD - standard compression algorithm
#   Copyright (C) 2014-2016, Yann Collet, Facebook
#   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

prefix=/usr/i686-w64-mingw32/sys-root/mingw
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: zstd
Description: fast lossless compression algorithm library
URL: http://www.zstd.net/
Version: 1.4.5
Libs: -L${libdir} -lzstd
Cflags: -I${includedir}

==> /usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc <==
prefix=/usr/local
exec_prefix=/usr/local
libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib
sharedlibdir=/usr/i686-w64-mingw32/sys-root/mingw/lib
includedir=/usr/i686-w64-mingw32/sys-root/mingw/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}

==> /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/libzstd.pc <==
#   ZSTD - standard compression algorithm
#   Copyright (C) 2014-2016, Yann Collet, Facebook
#   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

prefix=/usr/x86_64-w64-mingw32/sys-root/mingw
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: zstd
Description: fast lossless compression algorithm library
URL: http://www.zstd.net/
Version: 1.4.5
Libs: -L${libdir} -lzstd
Cflags: -I${includedir}

==> /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc <==
prefix=/usr/local
exec_prefix=/usr/local
libdir=/usr/x86_64-w64-mingw32/sys-root/mingw/lib
sharedlibdir=/usr/x86_64-w64-mingw32/sys-root/mingw/lib
includedir=/usr/x86_64-w64-mingw32/sys-root/mingw/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}

-- 
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 IEC units and prefixes, physical quantities in SI.]

Re: Scallywag glitch with texlive-collection-* packages

[Jon Turney]

On 16/09/2020 06:13, Brian Inglis wrote:
> 
> As not all variables can be specified as multi-line constants, and I am
> uncomfortable specifying variables in lines hundreds of bytes long, they need to
> be composed with short lines using +=, and not evaluating may lead to incorrect
> results.

The shallow analysis scallywag currently does understands about '+='.

If it doesn't work as expected, that is a bug.  Please report those, 
preferably not buried in the middle of a long email in reply to a email 
on a different subject.