git repositories for cygwin packaging - please test
Ken Brown
kbrown@cornell.edu
Sun Aug 30 15:22:37 GMT 2020
On 8/30/2020 11:00 AM, Jon Turney wrote:
> On 26/08/2020 23:00, Ken Brown via Cygwin-apps wrote:
>> On 8/23/2020 5:01 PM, Jon Turney wrote:
>>>
>>> I now have built an (opt-in) system which fetches the packages built by this
>>> into your upload area and triggers calm to process them, which I'm looking
>>> for a volunteer to test.
>>
>> I'd be willing to give it a try the next time I have something to upload. I'm
>> actually almost ready for a test release of doxygen. Unfortunately, the 32-bit
>> scallywag build of doxygen consistently fails with an ld crash, even though I
>> can build it locally. So I can't use it for this test.
>>
>> How does the opt-in process work? Is it per package? Is it easy to opt-out
>> again temporarily?
>
> We can arrange the details however you like. A specific package might be a good
> idea for a first try.
OK, I've got a test release of ghostscript ready to go. I've already tested it
on the playground branch, so I know it builds. If I put 'SCALLYWAG=deploy' in
the cygport and push to master, will that do the job?
> Only pushes to master are considered. You can opt-out by adding
> 'SCALLYWAG=nodeploy' to the cygport.
That sounds fine.
>>> Currently, these packages are built using 'cygport all-test', and so will
>>> always be marked test:
>>>
>>> One possible issue is that a git commit doesn't have to change VERSION or
>>> RELEASE, so this can build packages which are then immediately rejected by
>>> calm, as that PVR already exists.
>>
>> Does calm delete them after rejecting them or does the maintainer have to do
>> that?
>
> I've actually recently made a change to calm so that packages rejected as
> duplicates of existing PVR are discarded rather than retained, as this was just
> an inconvenience with no benefit.
Good.
Ken
More information about the Cygwin-apps
mailing list