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