Re: git repositories for cygwin packaging - please test
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
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
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: git repositories for cygwin packaging - please test
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'.
Re: git repositories for cygwin packaging - please test
On 2021-06-22 13: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: Nit: shouldn't the default value be documented as: The default *!scallywag* value is /build test nodeploy/. -- 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 binary units and prefixes, physical quantities in SI.]
Re: git repositories for cygwin packaging - please test
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:
Re: git repositories for cygwin packaging - please test
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 Currently, many packages will fail to build correctly due to: 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'm still not crazy about using AppVeyor as the back-end for this, but unless someone wants to donate some compute resources... Currently, these packages are built using 'cygport all-test', and so will always be marked test:
Re: git repositories for cygwin packaging - please test
Brian Inglis writes: > Could anyone please check and advise if the attached .git/config will > allow me to push to the playground repo and later branch for testing, > or demo the appropriate .git/config entries or git config commands to > do so properly? I usually define my own repo schemes in the global (user) Git config: --8<---cut here---start->8--- [url "ssh://sourceware.org/git/"] pushInsteadOf = cygwin: [url "ssh://cyg...@cygwin.com"] pushInsteadOf = git://cygwin.com [url "git://cygwin.com/git/cygwin-packages"] InsteadOf = cygpack: [url "ssh://cyg...@cygwin.com/git/cygwin-packages"] pushInsteadOf = cygpack: --8<---cut here---end--->8--- which then enables me to address the repo like this (each package is a submodule in an umbrella repository: --8<---cut here---start->8--- [submodule "perl"] url = cygpack:/perl active = true --8<---cut here---end--->8--- THis also works on the command line, so if I ever want to check out something quickly it is a lot easier to type. I never configure the playground as a local branch, I've posted how to push to that branch and remove it if and when you need it earlier. > Is there any way to move tags to a later commit once pushed? A tag is just a special commit, so as with all things Git: no, unless you can rewrite history, i.e. force-push. Just do not tag things you haven't published. > Finally are there other CI jobs.cgi?params=... other than id, > e.g. jobs.cgi?by=Brian+Inglis? Yes, that database is now large enough that filtering would be helpful. Probably a case of SHTDI, PTC… :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: git repositories for cygwin packaging - please test
On 2020-11-16 15:16, Jon Turney wrote: On 16/11/2020 21:54, Brian Inglis wrote: On 2020-05-27 16: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 To allow experimentation without messing up the version history unnecessarily: - All package repositories allow the maintainer(s) to create, push, rewind and delete a branch named 'playground'. - An additional package repository called 'playground' exists, that all maintainers can do anything to. Could anyone please check and advise if the attached .git/config will allow me to push to the playground repo and later branch for testing, or demo the appropriate .git/config entries or git config commands to do so properly? To push to the playground repo, I generally just use 'git push ssh://cyg...@cygwin.com/git/cygwin-packages/playground.git -f'. Thanks, the -f did it, but I've "-f'ed" myself a lot with git, so avoid it. The URLs in that config don't look quite right, since they seem to have hostname of just 'cygwin'? My ~/.ssh/config has "host" names for orgs and systems, but some programs (git?/lftp?/sftp?/?) get confused if you use those in other connection strings: "what do you mean 'cyg...@cygwin.com@cyg...@cygwin.com.com'", but your git command also worked without complaints. Is there any way to move tags to a later commit once pushed? I have one in wget that can't be deleted or forced because of the hook fallthru. tags don't have any particular significance, at the moment. I removed the wget '1.20.3-2' tag for you. Cheers, thanks! I will wait until finished changing and reviews before pushing tags in future. Finally are there other CI jobs.cgi?params=... other than id, e.g. jobs.cgi?by=Brian+Inglis? Not at this time. I agree it would be nice if you could filter by the various columns. The jobs.cgi script script is tiny (see [1]), if you want to make improvements. [1] https://cygwin.com/git/?p=cygwin-apps/scallywag.git;a=blob;f=jobs.cgi Not at this time. Would bloat up your tiny script! ;^> -- 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 binary units and prefixes, physical quantities in SI.]
Re: git repositories for cygwin packaging - please test
On 16/11/2020 21:54, Brian Inglis wrote: On 2020-05-27 16: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 To allow experimentation without messing up the version history unnecessarily: - All package repositories allow the maintainer(s) to create, push, rewind and delete a branch named 'playground'. - An additional package repository called 'playground' exists, that all maintainers can do anything to. Could anyone please check and advise if the attached .git/config will allow me to push to the playground repo and later branch for testing, or demo the appropriate .git/config entries or git config commands to do so properly? To push to the playground repo, I generally just use 'git push ssh://cyg...@cygwin.com/git/cygwin-packages/playground.git -f'. The URLs in that config don't look quite right, since they seem to have hostname of just 'cygwin'? Is there any way to move tags to a later commit once pushed? I have one in wget that can't be deleted or forced because of the hook fallthru. tags don't have any particular significance, at the moment. I removed the wget '1.20.3-2' tag for you. Finally are there other CI jobs.cgi?params=... other than id, e.g. jobs.cgi?by=Brian+Inglis? Not at this time. I agree it would be nice if you could filter by the various columns. The jobs.cgi script script is tiny (see [1]), if you want to make improvements. [1] https://cygwin.com/git/?p=cygwin-apps/scallywag.git;a=blob;f=jobs.cgi
Re: git repositories for cygwin packaging - please test
On 2020-05-27 16: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 To allow experimentation without messing up the version history unnecessarily: - All package repositories allow the maintainer(s) to create, push, rewind and delete a branch named 'playground'. - An additional package repository called 'playground' exists, that all maintainers can do anything to. Could anyone please check and advise if the attached .git/config will allow me to push to the playground repo and later branch for testing, or demo the appropriate .git/config entries or git config commands to do so properly? Is there any way to move tags to a later commit once pushed? I have one in wget that can't be deleted or forced because of the hook fallthru. Finally are there other CI jobs.cgi?params=... other than id, e.g. jobs.cgi?by=Brian+Inglis? -- 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 binary units and prefixes, physical quantities in SI.] [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "playground"] url = ssh://cygwin/git/cygwin-packages/playground.git fetch = +refs/heads/*:refs/remotes/origin/* [remote "origin"] url = ssh://cygwin/git/cygwin-packages/wget2.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = ssh://cygwin/git/cygwin-packages/wget2 merge = refs/heads/master [branch "playground"] remote = ssh://cygwin/git/cygwin-packages/wget2 merge = refs/heads/playground
Re: git repositories for cygwin packaging - please test
On 30/08/2020 16:46, Jon Turney wrote: On 30/08/2020 16:22, Ken Brown wrote: 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? Sure, I have made things work like that. Go ahead when you are ready. This is now enabled for all maintainers. To summarize, the following tokens are recognized in the SCALLYWAG variable set in the .cygport file: nobuild: Disables building packages. notest: Disables running 'cygport test' deploy: For the master branch, after a successful build, the built packages are handed-off to calm, the package uploader. Note that currently, these packages are built using 'cygport all-test', and so will always be marked as test.c
Re: git repositories for cygwin packaging - please test
On 04/10/2020 11:26, Achim Gratz wrote: ASSI writes: SCALLYWAG="notest" It seems that if I write something like SCALLYWAG="notest" # a comment then the line actually gets ignored due to a somewhat restrictive regex: match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?$', content, re.MULTILINE) Something like this might work better: match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?(\s*#.*)?$', content, re.MULTILINE) (I hope :-). Otherwise you'd first need to chop off any comments at the end and then shove the result into the original regex. It seems like there is a lot of ad-hoc code in that file that does things slightly differently for various settings, so that seems like it should get re-factored into something more general that is used uniformly across all the things you want to extract from the cygport file. As noted elsewhere, trying to parse variables out of the .cygport like this isn't a good approach, and really I want to add something which gets cygport to execute the file and then output the variables of interest. But I've tweaked things a bit so comments should get discarded before we start looking at the file contents, which hopefully helps this a bit.
Re: git repositories for cygwin packaging - please test
ASSI writes: > SCALLYWAG="notest" It seems that if I write something like SCALLYWAG="notest" # a comment then the line actually gets ignored due to a somewhat restrictive regex: match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?$', content, re.MULTILINE) Something like this might work better: match = re.search(r'^\s*SCALLYWAG=\s*"?(.*?)"?(\s*#.*)?$', content, re.MULTILINE) (I hope :-). Otherwise you'd first need to chop off any comments at the end and then shove the result into the original regex. It seems like there is a lot of ad-hoc code in that file that does things slightly differently for various settings, so that seems like it should get re-factored into something more general that is used uniformly across all the things you want to extract from the cygport file. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: git repositories for cygwin packaging - please test
On 30/08/2020 17:44, ASSI wrote: Jon Turney writes: Only pushes to master are considered. You can opt-out by adding 'SCALLYWAG=nodeploy' to the cygport. If additionally we'd not want the package to get tested, would we do SCALLYWAG="notest nodeploy" or SCALLYWAG="notest" SCALLYWAG+=" nodeploy" is supposed to work, then? Yes. But "nodeploy" is the default for everyone apart from Ken Brown and me, at the moment.
Re: git repositories for cygwin packaging - please test
On 30/08/2020 18:25, Ken Brown via Cygwin-apps wrote: On 8/30/2020 11:46 AM, Jon Turney wrote: On 30/08/2020 16:22, Ken Brown wrote: 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? Sure, I have made things work like that. Go ahead when you are ready. It worked. It took me two tries because the first time I added 'SCALLYWAG=deploy' I forgot to commit it before pushing. That's a pleasant surprise :) It should work in a similar way (for you) for any other packages.
Re: git repositories for cygwin packaging - please test
On 8/30/2020 11:46 AM, Jon Turney wrote: On 30/08/2020 16:22, Ken Brown wrote: 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? Sure, I have made things work like that. Go ahead when you are ready. It worked. It took me two tries because the first time I added 'SCALLYWAG=deploy' I forgot to commit it before pushing.
Re: git repositories for cygwin packaging - please test
Jon Turney writes: > Only pushes to master are considered. You can opt-out by adding > 'SCALLYWAG=nodeploy' to the cygport. If additionally we'd not want the package to get tested, would we do SCALLYWAG="notest nodeploy" or SCALLYWAG="notest" SCALLYWAG+=" nodeploy" is supposed to work, then? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: git repositories for cygwin packaging - please test
On 30/08/2020 16:22, Ken Brown wrote: 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? Sure, I have made things work like that. Go ahead when you are ready. Only pushes to master are considered. You can opt-out by adding 'SCALLYWAG=nodeploy' to the cygport. That sounds fine.
Re: git repositories for cygwin packaging - please test
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
Re: git repositories for cygwin packaging - please test
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. Only pushes to master are considered. You can opt-out by adding 'SCALLYWAG=nodeploy' to the cygport. 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. I'm not sure if that's a real problem, or what the workflow should look like in regards to that. I don't see it as a real problem, as long as all it means is that I get an email from calm. But if I also have to manually delete the packages from my upload area, that could be annoying.
Re: git repositories for cygwin packaging - please test
On 8/23/2020 5:01 PM, 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 Currently, many packages will fail to build correctly due to: 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? 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'm not sure if that's a real problem, or what the workflow should look like in regards to that. I don't see it as a real problem, as long as all it means is that I get an email from calm. But if I also have to manually delete the packages from my upload area, that could be annoying. Ken
Re: git repositories for cygwin packaging - please test
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 Currently, many packages will fail to build correctly due to: 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. 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. I'm not sure if that's a real problem, or what the workflow should look like in regards to that.
Re: git repositories for cygwin packaging - please test
On 07/08/2020 23:05, Ken Brown via Cygwin-apps wrote: On 8/7/2020 3:42 PM, Achim Gratz wrote: Jon Turney writes: One problem I have noticed is that some packages have test suites (which are getting run via 'cygport test' invoking src_test()) which: - require lots of extra dependencies to run, or I currently subsume these in BUILD_REQUIRES as they are indeed required for a (complete) build. It'd be possible to split them out into a separate variable indeed, but that is yet another level of specificatrion that needs to be figured out if it should become useful. Yeah, the only saving is that we don't need to spend the time to install those packages if we aren't going to run the tests. - don't succeed on Cygwin, or Any such tests I usually patch out or mark expected fail whichever seems easier. - take an inordinate amount of time to run (exceeding the resource limits) That is a problem that comes with CI I think and we didn't really have had to consider so far. I have a few packages that I don't run tests on by default because the test suite produces hangs or other unstable behaviour, but that is dealt with in the src_test function itself. If there are really resource hungry tests they usually need to be enabled somewhere and one could skip those if the build runs on CIm (how to find that out?). Here's an example where Jon's suggestion would have been useful: While building php recently, I noticed that the test suite took forever. I would have been happy to have a way to tell the CI to skip the tests and avoid exceeding the resource limits. But I wouldn't want to do that by modifying src_test, because I would still want to run the tests locally. It should now be possible to add to the .cygport a line like: SCALLYWAG="notest" which instructs it not to run the src_test() phase.
Re: git repositories for cygwin packaging - please test
Ken Brown via Cygwin-apps writes:
>>> - take an inordinate amount of time to run (exceeding the resource limits)
>>
>> That is a problem that comes with CI I think and we didn't really have
>> had to consider so far. I have a few packages that I don't run tests on
>> by default because the test suite produces hangs or other unstable
>> behaviour, but that is dealt with in the src_test function itself.
>> If there are really resource hungry tests they usually need to be
>> enabled somewhere and one could skip those if the build runs on CI (how
>> to find that out?).
>
> Here's an example where Jon's suggestion would have been useful: While
> building php recently, I noticed that the test suite took forever. I
> would have been happy to have a way to tell the CI to skip the tests
> and avoid exceeding the resource limits. But I wouldn't want to do
> that by modifying src_test, because I would still want to run the
> tests locally.
I think I didn't express myself clearly enough. If you look in the
perl-IO-Tty cygport file you'll find this:
src_test() {
cd ${B}
[ "no" != "${CYGPORT_RUN_UNSTABLE_TESTS-no}" ] &&
cygtest || echo "Unstable test, set CYGPORT_RUN_UNSTABLE_TESTS to run."
}
This is clearly an exceptional deficiency (even if presumably caused by
some border case in Cygwin) that needs to be handled in the package and
not a general thing that should be in cygport.
But that's not to say that something like CYGPORT_RUN_EXPENSIVE_TESTS
could not exist and arguably it should even be directly provided by
cygport itself if it was. Now, "expensive" has multiple dimensions, so
I'd expect that variable to have a list of values to indicate which of
these is considered relevant (like time, memory, network). There'd need
to be a matching set of values / limits provided by the local or CI
configuration to enable / disable tests as appropriate.
CPU wise the CI seems to have a pretty beefy configuration, I've not run
into memory problems yet (but didn't check that specifically). So at
the moment the relevant limits would be total runtime and maybe network
activity (I don't think I have a package that exercises that). But then
again, this could change with each run and certainly will change over
time, so hard-coding these limits doesn't seem like a good idea.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: git repositories for cygwin packaging - please test
On 8/7/2020 3:42 PM, Achim Gratz wrote: Jon Turney writes: One problem I have noticed is that some packages have test suites (which are getting run via 'cygport test' invoking src_test()) which: - require lots of extra dependencies to run, or I currently subsume these in BUILD_REQUIRES as they are indeed required for a (complete) build. It'd be possible to split them out into a separate variable indeed, but that is yet another level of specificatrion that needs to be figured out if it should become useful. - don't succeed on Cygwin, or Any such tests I usually patch out or mark expected fail whichever seems easier. - take an inordinate amount of time to run (exceeding the resource limits) That is a problem that comes with CI I think and we didn't really have had to consider so far. I have a few packages that I don't run tests on by default because the test suite produces hangs or other unstable behaviour, but that is dealt with in the src_test function itself. If there are really resource hungry tests they usually need to be enabled somewhere and one could skip those if the build runs on CIm (how to find that out?). Here's an example where Jon's suggestion would have been useful: While building php recently, I noticed that the test suite took forever. I would have been happy to have a way to tell the CI to skip the tests and avoid exceeding the resource limits. But I wouldn't want to do that by modifying src_test, because I would still want to run the tests locally. Ken
Re: git repositories for cygwin packaging - please test
Jon Turney writes: > One problem I have noticed is that some packages have test suites > (which are getting run via 'cygport test' invoking src_test()) which: > > - require lots of extra dependencies to run, or I currently subsume these in BUILD_REQUIRES as they are indeed required for a (complete) build. It'd be possible to split them out into a separate variable indeed, but that is yet another level of specificatrion that needs to be figured out if it should become useful. > - don't succeed on Cygwin, or Any such tests I usually patch out or mark expected fail whichever seems easier. > - take an inordinate amount of time to run (exceeding the resource limits) That is a problem that comes with CI I think and we didn't really have had to consider so far. I have a few packages that I don't run tests on by default because the test suite produces hangs or other unstable behaviour, but that is dealt with in the src_test function itself. If there are really resource hungry tests they usually need to be enabled somewhere and one could skip those if the build runs on CIm (how to find that out?). > So I'm wondering if .cygport files need: > > - an annotation to indicate tests shouldn't be run by this system (in > RESTRICT? or somewhere new?) Not RESTRICT please, that does things related to packaging. > - a separate TEST_REQUIRES to list packages which depended on for > running tests? That seems the most prudent name in this case. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: git repositories for cygwin packaging - please test
On 8/6/2020 4:20 PM, 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 Currently, many packages will fail to build correctly due to: One problem I have noticed is that some packages have test suites (which are getting run via 'cygport test' invoking src_test()) which: - require lots of extra dependencies to run, or - don't succeed on Cygwin, or - take an inordinate amount of time to run (exceeding the resource limits) So I'm wondering if .cygport files need: - an annotation to indicate tests shouldn't be run by this system (in RESTRICT? or somewhere new?) - a separate TEST_REQUIRES to list packages which depended on for running tests? I like both ideas. For the first one (don't run 'cygport test'), I have a slight preference for putting the annotation somewhere new, since it's pretty different from the current uses of RESTRICT. It doesn't affect what cygport does, but rather it tells the automated system not to run a certain cygport command. Ken
Re: git repositories for cygwin packaging - please test
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 Currently, many packages will fail to build correctly due to: One problem I have noticed is that some packages have test suites (which are getting run via 'cygport test' invoking src_test()) which: - require lots of extra dependencies to run, or - don't succeed on Cygwin, or - take an inordinate amount of time to run (exceeding the resource limits) So I'm wondering if .cygport files need: - an annotation to indicate tests shouldn't be run by this system (in RESTRICT? or somewhere new?) - a separate TEST_REQUIRES to list packages which depended on for running tests?
Re: git repositories for cygwin packaging - please test
On 2020-06-09 07:26, Jon Turney wrote: > On 04/06/2020 21:33, Brian Inglis wrote: >> On 2020-06-04 10:01, Ken Brown via Cygwin-apps wrote: >>> On 5/27/2020 6:27 PM, 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 >> >>> This is great! Thanks for doing this. One strange thing I've noticed is >>> that >>> sometimes a package will build fine on x86_64 but will fail on x86 with an >>> error >>> like this: >>> distutils.errors.CompileError: command 'gcc' terminated by signal 11 >>> make[4]: *** >>> [/usr/share/gobject-introspection-1.0/Makefile.introspection:160: >>> HarfBuzz-0.0.gir] Error 1 >>> Every time I've seen this, the build works fine on my local x86 install, so >>> it's >>> not a big deal. But I'm curious what might cause this. >> >> $ kill -l 11 >> SEGV >> >> distutils bug? > > There should be no input that distutils can give gcc that makes it SEGV, so > it's > at least a gcc bug as well. > > I've adjusted things so any .stackdump files created by the build should be > preserved, which might give a start at investigating this. Any chance it may have a similar or related cause to: https://bugzilla.redhat.com/show_bug.cgi?id=1737186#c11 "I went ahead and enabled the introspection build. The issue that was causing the introspection scanner to not find libharfbuzz-gobject.so.0 was that the spec file was removing the rpaths that the introspection scanner relies on." -- 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: git repositories for cygwin packaging - please test
On 04/06/2020 21:33, Brian Inglis wrote: On 2020-06-04 10:01, Ken Brown via Cygwin-apps wrote: On 5/27/2020 6:27 PM, 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 This is great! Thanks for doing this. One strange thing I've noticed is that sometimes a package will build fine on x86_64 but will fail on x86 with an error like this: distutils.errors.CompileError: command 'gcc' terminated by signal 11 make[4]: *** [/usr/share/gobject-introspection-1.0/Makefile.introspection:160: HarfBuzz-0.0.gir] Error 1 Every time I've seen this, the build works fine on my local x86 install, so it's not a big deal. But I'm curious what might cause this. $ kill -l 11 SEGV distutils bug? There should be no input that distutils can give gcc that makes it SEGV, so it's at least a gcc bug as well. I've adjusted things so any .stackdump files created by the build should be preserved, which might give a start at investigating this.
Re: git repositories for cygwin packaging - please test
> 04.08.2019 21:08, Jon Turney wrote: >> While a number of maintainers keep their cygwin packaging under some >> sort of version control, there is currently no central collection of >> these repositories. >> >> 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: >> >> git push cyg...@cygwin.com:/git/cygwin-packages/ >> >> where is a package name you are listed as a maintainer for >> in http://cygwin.com/cygwin-pkg-maint. >> >> These repositories are lazily created on the first push. >> >> Since it's intended that these repositories will only contain cygport >> scripts, patches, and other packaging files, and to prevent the >> accidental committing of upstream archives, pushes containing large >> binary files will be rejected. >> >> These repositories are viewable via gitweb at >> https://cygwin.com/git-cygwin-packages/ (URL may be subject to change), >> and should be cloneable via anonymous git/http with the URLs shown there. >> >> Please give this a test, if possible, and report any problems here. Works well for me, thank you. I was just wondering how I was going to update the cygport and patches, so very useful. Hamish McIntyre-Bhatty 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: git repositories for cygwin packaging - please test
On 2020-06-04 10:01, Ken Brown via Cygwin-apps wrote: > On 5/27/2020 6:27 PM, 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 > This is great! Thanks for doing this. One strange thing I've noticed is that > sometimes a package will build fine on x86_64 but will fail on x86 with an > error > like this: > distutils.errors.CompileError: command 'gcc' terminated by signal 11 > make[4]: *** [/usr/share/gobject-introspection-1.0/Makefile.introspection:160: > HarfBuzz-0.0.gir] Error 1 > Every time I've seen this, the build works fine on my local x86 install, so > it's > not a big deal. But I'm curious what might cause this. $ kill -l 11 SEGV distutils bug? -- 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: git repositories for cygwin packaging - please test
On 5/27/2020 6:27 PM, 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 This is great! Thanks for doing this. One strange thing I've noticed is that sometimes a package will build fine on x86_64 but will fail on x86 with an error like this: distutils.errors.CompileError: command 'gcc' terminated by signal 11 make[4]: *** [/usr/share/gobject-introspection-1.0/Makefile.introspection:160: HarfBuzz-0.0.gir] Error 1 Every time I've seen this, the build works fine on my local x86 install, so it's not a big deal. But I'm curious what might cause this. Ken
Re: git repositories for cygwin packaging - please test
04.08.2019 21:08, Jon Turney пишет:
>
> While a number of maintainers keep their cygwin packaging under some
> sort of version control, there is currently no central collection of
> these repositories.
>
> 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:
>
> git push cyg...@cygwin.com:/git/cygwin-packages/
>
> where is a package name you are listed as a maintainer for
> in http://cygwin.com/cygwin-pkg-maint.
>
> These repositories are lazily created on the first push.
>
> Since it's intended that these repositories will only contain cygport
> scripts, patches, and other packaging files, and to prevent the
> accidental committing of upstream archives, pushes containing large
> binary files will be rejected.
>
> These repositories are viewable via gitweb at
> https://cygwin.com/git-cygwin-packages/ (URL may be subject to change),
> and should be cloneable via anonymous git/http with the URLs shown there.
>
> Please give this a test, if possible, and report any problems here.
I've tried to push the playground branch to
cygwin.com:/git/cygwin-packages/znc and the output was full of this:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Re: git repositories for cygwin packaging - please test
On Wed, May 27, 2020 at 11:27:49PM +0100, Jon Turney wrote: > Currently, many packages will fail to build correctly due to: > > (iii) resource limits imposed by AppVeyor's free service which is used to > perform the actual builds, or Azure Devops may worth a try. s
Re: git repositories for cygwin packaging - please test
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 Currently, many packages will fail to build correctly due to: (i) missing or insufficient 'BUILD_REQUIRES', (ii) missing prerequisites implied by an 'inherit' (a bug in this system), (iii) resource limits imposed by AppVeyor's free service which is used to perform the actual builds, or (iv) other bugs in this system. At this stage, this is only probably useful for verifying that BUILD_REQUIRES is correct. (Note that a successful build doesn't always mean that you have reproduced your build: You'll need to check the configuration step output and/or dependencies of the produced packages are the same. Consider explicitly enabling the functionality you are expecting in the options to the configure script , if it supports that (e.g. CYGCONF_ARGS, etc.), to avoid it potentially silently turning off in future, if it's requirements change) To allow experimentation without messing up the version history unnecessarily: - All package repositories allow the maintainer(s) to create, push, rewind and delete a branch named 'playground'. - An additional package repository called 'playground' exists, that all maintainers can do anything to.
Re: git repositories for cygwin packaging - please test
Jon Turney writes: > 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: > > git push > cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer > for in http://cygwin.com/cygwin-pkg-maint. I spent the better part of last weekend to split up my private repositories to fit this structure and then to rebase my local repos on top of the history of co-maintained packages (from Yaakov) that had already been uploaded. The package listing page was a bit overwhelming to start with and even more so after my uploads, perhaps ther could be a way to pre-filter on first letter or prefix to more easily search? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: git repositories for cygwin packaging - please test
On 04/08/2019 21:08, Jon Turney wrote: These repositories are viewable via gitweb at https://cygwin.com/git-cygwin-packages/ (URL may be subject to change), and should be cloneable via anonymous git/http with the URLs shown there. Please give this a test, if possible, and report any problems here. Thanks for the feedback. I've made the following adjustments: Updated the gitolite version to get a performance fix for creating a repository (so it's ~O(1) rather than ~O(number of repositories)) https://cygwin.com/git-cygwin-packages/ is now paginated to improve pageload. This works moderately well when using the default sorting (by project), but unfortunately, it still needs to run thousands of git commands to get the information when sorting by last change or owner. The popular solutions to that problem seem to be "don't use gitweb" :). Patched gitolite to permit repository names starting with '_', since we have a couple of those.
Re: git repositories for cygwin packaging - please test
On 09/08/2019 20:12, Ken Brown wrote: On 8/9/2019 12:12 PM, Jon Turney wrote: On 08/08/2019 18:09, Ken Brown wrote: On 8/8/2019 10:04 AM, Andrew Schulman via cygwin-apps wrote: These repositories are lazily created on the first push. In my testing, git push hangs on the first push, after "Initialized empty git repositories". After I interrupt, it finishes normally. Maybe a misconfiguration on my end. I'm seeing something like this too now, though I didn't when I first tested. In my case it doesn't finish normally after the interrupt; I have to do a second git push, which then works. Thanks for reporting this problem. I need to look into this some more, but this looks like push is getting stuck due to creating the repo taking an unusually long time (perhaps due to lock contention with someone else creating a repo...). Whatever it was, it seems to be fixed now. I've updated gitolite with a fix so creating a repository isn't grovelling over all existing repositories (which was taking a ridiculously long time after lots of repositories had been created)
Re: git repositories for cygwin packaging - please test
On 2019-08-04 14:08, Jon Turney wrote: > > While a number of maintainers keep their cygwin packaging under some sort of > version control, there is currently no central collection of these > repositories. > > 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: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for in > http://cygwin.com/cygwin-pkg-maint. > > These repositories are lazily created on the first push. > > Since it's intended that these repositories will only contain cygport scripts, > patches, and other packaging files, and to prevent the accidental committing > of > upstream archives, pushes containing large binary files will be rejected. > > These repositories are viewable via gitweb at > https://cygwin.com/git-cygwin-packages/ (URL may be subject to change), and > should be cloneable via anonymous git/http with the URLs shown there. > > Please give this a test, if possible, and report any problems here. WJFFM - nice resource - got me to standardize some other stuff in my main package dirs. -- 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.
Re: git repositories for cygwin packaging - please test
On 8/9/2019 12:12 PM, Jon Turney wrote: > On 08/08/2019 18:09, Ken Brown wrote: >> On 8/8/2019 10:04 AM, Andrew Schulman via cygwin-apps wrote: These repositories are lazily created on the first push. >>> >>> In my testing, git push hangs on the first push, after "Initialized empty >>> git repositories". After I interrupt, it finishes normally. Maybe a >>> misconfiguration on my end. >> >> I'm seeing something like this too now, though I didn't when I first tested. >> In >> my case it doesn't finish normally after the interrupt; I have to do a second >> git push, which then works. >> > > Thanks for reporting this problem. > > I need to look into this some more, but this looks like push is getting stuck > due to creating the repo taking an unusually long time (perhaps due to lock > contention with someone else creating a repo...). Whatever it was, it seems to be fixed now. Ken
Re: git repositories for cygwin packaging - please test
On 08/08/2019 18:09, Ken Brown wrote: On 8/8/2019 10:04 AM, Andrew Schulman via cygwin-apps wrote: These repositories are lazily created on the first push. In my testing, git push hangs on the first push, after "Initialized empty git repositories". After I interrupt, it finishes normally. Maybe a misconfiguration on my end. I'm seeing something like this too now, though I didn't when I first tested. In my case it doesn't finish normally after the interrupt; I have to do a second git push, which then works. Thanks for reporting this problem. I need to look into this some more, but this looks like push is getting stuck due to creating the repo taking an unusually long time (perhaps due to lock contention with someone else creating a repo...).
Re: git repositories for cygwin packaging - please test
On 04/08/2019 21:08, Jon Turney wrote: Since it's intended that these repositories will only contain cygport scripts, patches, and other packaging files, and to prevent the accidental committing of upstream archives, pushes containing large binary files will be rejected. Actually, it seems that I'd configured things so that pushes containing binary files larger than 1kB were being rejected. This was catching some repos which contain icon(s) (for a menu item), so I've adjusted rule to permit those (based on file extension).
Re: git repositories for cygwin packaging - please test
On 8/8/2019 10:04 AM, Andrew Schulman via cygwin-apps wrote: >> >> While a number of maintainers keep their cygwin packaging under some >> sort of version control, there is currently no central collection of >> these repositories. >> >> 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: >> >> git push cyg...@cygwin.com:/git/cygwin-packages/ >> >> where is a package name you are listed as a maintainer for >> in http://cygwin.com/cygwin-pkg-maint. >> >> These repositories are lazily created on the first push. > > In my testing, git push hangs on the first push, after "Initialized empty > git repositories". After I interrupt, it finishes normally. Maybe a > misconfiguration on my end. I'm seeing something like this too now, though I didn't when I first tested. In my case it doesn't finish normally after the interrupt; I have to do a second git push, which then works. Ken
Re: git repositories for cygwin packaging - please test
> > While a number of maintainers keep their cygwin packaging under some > sort of version control, there is currently no central collection of > these repositories. > > 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: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for > in http://cygwin.com/cygwin-pkg-maint. > > These repositories are lazily created on the first push. In my testing, git push hangs on the first push, after "Initialized empty git repositories". After I interrupt, it finishes normally. Maybe a misconfiguration on my end. ~/d/c/fish> git push --set-upstream origin master Initialized empty Git repository in /sourceware1/projects/cygwin-home/cygwin-packages/fish.git/ # Insert Ctrl-C here Counting objects: 92, done. Delta compression using up to 4 threads. Compressing objects: 100% (75/75), done. Writing objects: 100% (92/92), 14.87 KiB | 249.00 KiB/s, done. Total 92 (delta 33), reused 0 (delta 0) To cygwin.com:/git/cygwin-packages/fish * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'.
Re: git repositories for cygwin packaging - please test
> While a number of maintainers keep their cygwin packaging under some > sort of version control, there is currently no central collection of > these repositories. > > 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: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for > in http://cygwin.com/cygwin-pkg-maint. Nice work, thanks. And, a big step towards an automated package build server! Gold star! https://cygwin.com/goldstars/#Jty
Re: git repositories for cygwin packaging - please test
On 8/4/2019 4:08 PM, Jon Turney wrote: > > While a number of maintainers keep their cygwin packaging under some sort of > version control, there is currently no central collection of these > repositories. > > 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: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for in > http://cygwin.com/cygwin-pkg-maint. > > These repositories are lazily created on the first push. > > Since it's intended that these repositories will only contain cygport > scripts, > patches, and other packaging files, and to prevent the accidental committing > of > upstream archives, pushes containing large binary files will be rejected. > > These repositories are viewable via gitweb at > https://cygwin.com/git-cygwin-packages/ (URL may be subject to change), and > should be cloneable via anonymous git/http with the URLs shown there. > > Please give this a test, if possible, and report any problems here. Great idea! Thanks for doing this. I've pushed a few of my repos, and I've cloned one of yours. So far everything works as expected. By the way, people who want to switch to using these new repos as their upstream can issue the following command: git remote set-url origin cyg...@cygwin.com:/git/cygwin-packages/ Ken
