Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA
Lemures Lemniscati via Cygwin-apps writes: > Alpine linux has multiple versions of lua, also [1]. > And packages names have periods in them when lua-versions are > specified [2]. I still consider Alpine a special snowflake despite their gains in container environments since they tend to have their own package splits. > Among cygwin packages, guile packages have dots in their package names. Nobody said things were consistent. > And, I'm wondering about no-dot-in-the-version scheme... What should we > do if its version comes to 5.10 or higher (just a hypothecical example). > It will be lua510-* without dots, but I would feel uneasy for it (just > in my opinion). We will cross that bridge when we get there. > Does it mean that we should have a way to rebase such dynamic objects > automatically? Well, the first step is to make sure that packaged and locally installed stuff stays separate (for Perl this is the distinction between vendor and site distributions) and set up a sensible precedence order. Next is that users might not have admin rights, so there's a separation between local system and local user to consider (Perl: local::lib). Once you have that sorted then yes, you need to think about when and how to do the rebase of any dynamic objects you are going to produce. For Perl I managed to insert an automatic ephemeral rebase, but only for i686 and packages built with ExtUtils::MakeMaker (so that build tests can actually work without having to do an extra step). The local installations should be taken care of via the autorebase facilities, although that requires cooperation from the system admin for user installations. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On 16.01.2021 23:31, Ken Brown via Cygwin-apps wrote: On 1/16/2021 3:33 PM, Adam Dinwoodie wrote: On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote: Version 0.65-1 of moreutils has been uploaded and should be coming soon to a distribution server near you. I assume you're quoting from https://cygwin.com/packaging/build.html. Scallywag does have some limitations currently, but I think the statement you quoted is obsolete. I often have Scallywag deploy my packages, as does Jon Turney. The limitations I've bumped into are: 1. Scallywag will time out after an hour on each arch until now I was hit only during test. But I stil need to deploy on our Git some of the heavy packages 2. Several of my packages fail to build on x86 because of gcc crashes. 3. sometimes the failure is not in the build, but in missing or imperfect testing I think these limitations are outweighed by the fact that a Scallywag build is automatically triggered by a push to an official source repo (https://cygwin.com/packaging/repos.html). All maintainers can use this without any special setup. +1 Ken but of course Adam, more options are always better, Thank for sharing Marco
Re: [PATCH cygport] A patch to add a flag __SKIP_LIST_DEPS_LUA
On Sat, 16 Jan 2021 07:50:52 +0100, ASSI > Lemures Lemniscati via Cygwin-apps writes: > > And I'm trying to package luarocks for lua5.3 and lua5.4 > > (lua5.3-luarocks and lua5.4-luarocks) by a single cygport file. > > The packages should be named lua53-luarocks and lua54-luarocks (no dot > in the version number), like OpenSUSE (they seem to be the only > distribution with a multi-version lua and that particular naming scheme > you've chosen). Alpine linux has multiple versions of lua, also [1]. And packages names have periods in them when lua-versions are specified [2]. [1]: https://pkgs.alpinelinux.org/packages?name=lua5.4 https://pkgs.alpinelinux.org/packages?name=lua5.3 https://pkgs.alpinelinux.org/packages?name=lua5.2 https://pkgs.alpinelinux.org/packages?name=lua5.1 [2]: https://pkgs.alpinelinux.org/packages?name=lua* Among cygwin packages, guile packages have dots in their package names. [3]: https://cygwin.com/packages/summary/guile3.0-src.html https://cygwin.com/packages/summary/guile2.2-src.html https://cygwin.com/packages/summary/guile2.0-src.html https://cygwin.com/packages/summary/guile1.8-src.html And, I'm wondering about no-dot-in-the-version scheme... What should we do if its version comes to 5.10 or higher (just a hypothecical example). It will be lua510-* without dots, but I would feel uneasy for it (just in my opinion). > A different question is if you really want to package this particular > feature. Just like all the other "package managers" that come with a > specific language or interpreter I'd expect this one to need (maybe > extensive) modifications to work correctly on Cygwin, especially if it > ends up building dynamic objects. Does it mean that we should have a way to rebase such dynamic objects automatically? > That's one reason I discourage the > use of CPAN on Cygwin, since folks tend to shoot themself into the foot > more often than not by using it. All right. Maybe, I should calm myself down. I will try simply to build subpackges for lua-5.4.2 (test), for the time being. Regards, Lem
Re: GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On 1/16/2021 3:33 PM, Adam Dinwoodie wrote:
On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
Version 0.65-1 of moreutils has been uploaded and should be coming
soon to a distribution server near you.
In case anyone's interested or has thoughts:
As part of working on this release, I've been playing with GitHub's
automation tools. The entire build / test / package / release / upload
process was performed using free ephemeral GitHub-managed VMs. At
least in theory, this reduces the manual work for future releases to:
- Commit a version of the Cygport file with an updated version number.
- Create a tag and push that tag to GitHub
- Wait for the confirmation email to arrive
- Send the announcement email
This is obviously serving a similar purpose to the automated builds
that Scallywag provides; I'm not sure I'd have bothered with this
project had I not already been most of the way through it before I
spotted Scallywag existed. I suspect in theory Scallywag's access to
the Cygwin servers means it's potentially more powerful, but Scallywag
also comes with some general caveats ("at this stage, this is only
probably useful for verifying that BUILD_REQUIRES is correct"),
I assume you're quoting from https://cygwin.com/packaging/build.html. Scallywag
does have some limitations currently, but I think the statement you quoted is
obsolete. I often have Scallywag deploy my packages, as does Jon Turney.
The limitations I've bumped into are:
1. Scallywag will time out after an hour on each arch.
2. Several of my packages fail to build on x86 because of gcc crashes.
I think these limitations are outweighed by the fact that a Scallywag build is
automatically triggered by a push to an official source repo
(https://cygwin.com/packaging/repos.html). All maintainers can use this without
any special setup.
Ken
GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
> Version 0.65-1 of moreutils has been uploaded and should be coming
> soon to a distribution server near you.
In case anyone's interested or has thoughts:
As part of working on this release, I've been playing with GitHub's
automation tools. The entire build / test / package / release / upload
process was performed using free ephemeral GitHub-managed VMs. At
least in theory, this reduces the manual work for future releases to:
- Commit a version of the Cygport file with an updated version number.
- Create a tag and push that tag to GitHub
- Wait for the confirmation email to arrive
- Send the announcement email
This is obviously serving a similar purpose to the automated builds
that Scallywag provides; I'm not sure I'd have bothered with this
project had I not already been most of the way through it before I
spotted Scallywag existed. I suspect in theory Scallywag's access to
the Cygwin servers means it's potentially more powerful, but Scallywag
also comes with some general caveats ("at this stage, this is only
probably useful for verifying that BUILD_REQUIRES is correct"),
whereas I think with care this could replace local builds today.
The configuration to make this work is almost entirely in
,
and I expect the modifications to make this work for most other
packages would be straightforward. I'm hoping to make the process and
required configuration simpler, by creating a pre-defined GitHub
action that hides most of the boilerplate.
If you're curious, you can see the full build output for the final
release build at
.
