Re: git repositories for cygwin packaging - please test

2023-02-18 Thread Jon Turney via Cygwin-apps

On 18/02/2023 17:43, Ken Brown via Cygwin-apps wrote:

On 2/18/2023 11:21 AM, Jon Turney via Cygwin-apps wrote:


You can now interact with your build jobs in some ways which require 
authentication using ...


Thanks!


Currently, available sub-commands are:

cancel (request termination of an unwanted build job)

deploy (get a job to deploy (if it's suitable: i.e. successfully 
built, from master, etc.) (e.g. if you forgot to set the deploy option 
before hand)


I assume we would specify the job id after the cancel or deploy command?


Invoking without any arguments, or with '--help', should produce some 
help text.


rebuild (rebuild a job if it failed due to some transient condition, 
or optionally with different token options)


For the second case, would we specify the new tokens on the command 
line?  After the job id?


$ ssh cyg...@cygwin.com jobs rerun --help
usage: jobs rerun [-h] [--token TOKEN] ID

positional arguments:
  ID job id

optional arguments:
  -h, --help show this help message and exit
  --token TOKEN  tokens (default: as previous run)



Re: git repositories for cygwin packaging - please test

2023-02-18 Thread Ken Brown via Cygwin-apps

On 2/18/2023 11:21 AM, Jon Turney via Cygwin-apps wrote:

On 05/07/2022 14:12, Jon Turney wrote:

On 22/06/2021 20:52, Jon Turney wrote:

On 09/05/2021 15:39, Jon Turney wrote:

On 23/08/2020 22:01, Jon Turney wrote:

On 27/05/2020 23:27, Jon Turney wrote:

On 04/08/2019 21:08, Jon Turney wrote:
To remedy this lack, using the same ssh key you use for sftp 
package upload, package maintainers can now also push to git 
repositories, like so:


Package maintainers may have noticed that the output from pushing 
to these git repositories now includes a line like:


"remote: scallywag: build nnn queued"

This is a *prototype* of a system to automatically build the 
packages, where the results appear (some time later) at [1] (URL 
subject to change)


[1] https://cygwin.com/cgi-bin2/jobs.cgi

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.


Since that seems to be working about as well as can be expected, 
I've bodged together something so maintainers can now opt themselves 
in (and out) of this, by uploading (or removing) a file called 
'!scallywag' containing 'deploy' in the root of their upload area.


I've updated the brief documentation at [1] to mention this.

[1] https://cygwin.com/packaging/build.html


I've updated that page to document the fact that the behaviour for an 
individual push can now be controlled with 'git push 
--push-option='.


Currently, these packages are built using 'cygport all-test', and 
so will always be marked test:


Since my concerns about this producing horribly broken packages seem 
to be moot, I've changed the default so this now produces stable 
packages (i.e. uses 'cygport all' rather than 'cygport all-test'').


You can request the previous behaviour of labelling as test using the 
token 'label'.


You can now interact with your build jobs in some ways which require 
authentication using 'ssh cyg...@cygwin.com jobs'.


Thanks!


Currently, available sub-commands are:

cancel (request termination of an unwanted build job)

deploy (get a job to deploy (if it's suitable: i.e. successfully built, 
from master, etc.) (e.g. if you forgot to set the deploy option before 
hand)


I assume we would specify the job id after the cancel or deploy command?

rebuild (rebuild a job if it failed due to some transient condition, or 
optionally with different token options)


For the second case, would we specify the new tokens on the command 
line?  After the job id?


Ken


Re: git repositories for cygwin packaging - please test

2023-02-18 Thread Jon Turney via Cygwin-apps

On 05/07/2022 14:12, Jon Turney wrote:

On 22/06/2021 20:52, Jon Turney wrote:

On 09/05/2021 15:39, Jon Turney wrote:

On 23/08/2020 22:01, Jon Turney wrote:

On 27/05/2020 23:27, Jon Turney wrote:

On 04/08/2019 21:08, Jon Turney wrote:
To remedy this lack, using the same ssh key you use for sftp 
package upload, package maintainers can now also push to git 
repositories, like so:


Package maintainers may have noticed that the output from pushing 
to these git repositories now includes a line like:


"remote: scallywag: build nnn queued"

This is a *prototype* of a system to automatically build the 
packages, where the results appear (some time later) at [1] (URL 
subject to change)


[1] https://cygwin.com/cgi-bin2/jobs.cgi

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.


Since that seems to be working about as well as can be expected, I've 
bodged together something so maintainers can now opt themselves in 
(and out) of this, by uploading (or removing) a file called 
'!scallywag' containing 'deploy' in the root of their upload area.


I've updated the brief documentation at [1] to mention this.

[1] https://cygwin.com/packaging/build.html


I've updated that page to document the fact that the behaviour for an 
individual push can now be controlled with 'git push 
--push-option='.


Currently, these packages are built using 'cygport all-test', and so 
will always be marked test:


Since my concerns about this producing horribly broken packages seem to 
be moot, I've changed the default so this now produces stable packages 
(i.e. uses 'cygport all' rather than 'cygport all-test'').


You can request the previous behaviour of labelling as test using the 
token 'label'.


You can now interact with your build jobs in some ways which require 
authentication using 'ssh cyg...@cygwin.com jobs'.


Currently, available sub-commands are:

cancel (request termination of an unwanted build job)

deploy (get a job to deploy (if it's suitable: i.e. successfully built, 
from master, etc.) (e.g. if you forgot to set the deploy option before hand)


rebuild (rebuild a job if it failed due to some transient condition, or 
optionally with different token options)


I've updated the brief documentation at [1] to mention this.

[1] https://cygwin.com/packaging/build.html



Re: python26 remnants

2023-02-18 Thread Jon Turney via Cygwin-apps

On 12/01/2023 16:53, Jon Turney via Cygwin-apps wrote:


Preparatory to removal of python27, the final python2 version, I've been 
cleaning up the last remnants of python26.


There are still some old (pre-2012) packages which install files into 
/usr/lib/python2.6/site-packages/, I removed the following package 
versions:


bzr-fastimport-0.13.0-1
cvs2svn-2.3.0-1
getmail-4.34.0-1
python-fastimport-0.9.2-1
python-feedparser-5.0.1-1
python-pyrex-0.9.9-2
xml2po-0.20.10-1 (gnome-doc-utils)

I retained for the moment, as the most recent version:

archivemail-0.9.0-1
flawfinder-1.27-2

Jari,

As the maintainer of both of these, what do you want to do with these 
two packages?


These are just python scripts, which install an .egg-info file into 
usr/lib/python2.6/site-packages/


I am sceptical that they work as desired currently, as the python 
scripts which they contain probably assume /usr/bin/python is python2, 
which is increasingly unlikely to be the case.


If you want to orphan them, they will be removed.

If you think they are still useful, it would help if you could please 
produce updated packages for python3, or assure me that isn't needed.


In the absence of any response, I have assumed they are orphaned, and 
removed archivemail and flawfinder.


If that's not what you wanted to happen, please let me know.