* git repositories for cygwin packaging - please test
@ 2019-08-04 20:08 Jon Turney
2019-08-05 2:03 ` Ken Brown
` (8 more replies)
0 siblings, 9 replies; 49+ messages in thread
From: Jon Turney @ 2019-08-04 20:08 UTC (permalink / raw)
To: cygwin-apps
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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
where <packagename> 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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
@ 2019-08-05 2:03 ` Ken Brown
2019-08-08 13:47 ` Andrew Schulman via cygwin-apps
` (7 subsequent siblings)
8 siblings, 0 replies; 49+ messages in thread
From: Ken Brown @ 2019-08-05 2:03 UTC (permalink / raw)
To: cygwin-apps
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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>
> where <packagename> 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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
Ken
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
2019-08-05 2:03 ` Ken Brown
@ 2019-08-08 13:47 ` Andrew Schulman via cygwin-apps
2019-08-08 14:04 ` Andrew Schulman via cygwin-apps
` (6 subsequent siblings)
8 siblings, 0 replies; 49+ messages in thread
From: Andrew Schulman via cygwin-apps @ 2019-08-08 13:47 UTC (permalink / raw)
To: cygwin-apps
> 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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>
> where <packagename> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
2019-08-05 2:03 ` Ken Brown
2019-08-08 13:47 ` Andrew Schulman via cygwin-apps
@ 2019-08-08 14:04 ` Andrew Schulman via cygwin-apps
2019-08-08 17:09 ` Ken Brown
2019-08-09 16:00 ` Jon Turney
` (5 subsequent siblings)
8 siblings, 1 reply; 49+ messages in thread
From: Andrew Schulman via cygwin-apps @ 2019-08-08 14:04 UTC (permalink / raw)
To: cygwin-apps
>
> 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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>
> where <packagename> 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'.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-08 14:04 ` Andrew Schulman via cygwin-apps
@ 2019-08-08 17:09 ` Ken Brown
2019-08-09 16:12 ` Jon Turney
0 siblings, 1 reply; 49+ messages in thread
From: Ken Brown @ 2019-08-08 17:09 UTC (permalink / raw)
To: cygwin-apps
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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>>
>> where <packagename> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
` (2 preceding siblings ...)
2019-08-08 14:04 ` Andrew Schulman via cygwin-apps
@ 2019-08-09 16:00 ` Jon Turney
2019-08-09 20:58 ` Brian Inglis
` (4 subsequent siblings)
8 siblings, 0 replies; 49+ messages in thread
From: Jon Turney @ 2019-08-09 16:00 UTC (permalink / raw)
To: cygwin-apps
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).
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-08 17:09 ` Ken Brown
@ 2019-08-09 16:12 ` Jon Turney
2019-08-09 19:12 ` Ken Brown
0 siblings, 1 reply; 49+ messages in thread
From: Jon Turney @ 2019-08-09 16:12 UTC (permalink / raw)
To: cygwin-apps
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...).
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-09 16:12 ` Jon Turney
@ 2019-08-09 19:12 ` Ken Brown
2019-08-13 11:55 ` Jon Turney
0 siblings, 1 reply; 49+ messages in thread
From: Ken Brown @ 2019-08-09 19:12 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
` (3 preceding siblings ...)
2019-08-09 16:00 ` Jon Turney
@ 2019-08-09 20:58 ` Brian Inglis
2019-08-13 11:55 ` Jon Turney
` (3 subsequent siblings)
8 siblings, 0 replies; 49+ messages in thread
From: Brian Inglis @ 2019-08-09 20:58 UTC (permalink / raw)
To: cygwin-apps
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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>
> where <packagename> 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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-09 19:12 ` Ken Brown
@ 2019-08-13 11:55 ` Jon Turney
0 siblings, 0 replies; 49+ messages in thread
From: Jon Turney @ 2019-08-13 11:55 UTC (permalink / raw)
To: cygwin-apps
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)
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
` (4 preceding siblings ...)
2019-08-09 20:58 ` Brian Inglis
@ 2019-08-13 11:55 ` Jon Turney
2019-08-19 18:36 ` Achim Gratz
` (2 subsequent siblings)
8 siblings, 0 replies; 49+ messages in thread
From: Jon Turney @ 2019-08-13 11:55 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
` (5 preceding siblings ...)
2019-08-13 11:55 ` Jon Turney
@ 2019-08-19 18:36 ` Achim Gratz
2020-05-27 22:27 ` Jon Turney
2020-05-29 14:40 ` Alexey Sokolov
8 siblings, 0 replies; 49+ messages in thread
From: Achim Gratz @ 2019-08-19 18:36 UTC (permalink / raw)
To: cygwin-apps
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+AlfA@public.gmane.org:/git/cygwin-packages/<packagename>
>
> where <packagename> 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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
` (6 preceding siblings ...)
2019-08-19 18:36 ` Achim Gratz
@ 2020-05-27 22:27 ` Jon Turney
2020-05-28 11:51 ` szgyg
` (4 more replies)
2020-05-29 14:40 ` Alexey Sokolov
8 siblings, 5 replies; 49+ messages in thread
From: Jon Turney @ 2020-05-27 22:27 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-05-27 22:27 ` Jon Turney
@ 2020-05-28 11:51 ` szgyg
2020-06-04 16:01 ` Ken Brown
` (3 subsequent siblings)
4 siblings, 0 replies; 49+ messages in thread
From: szgyg @ 2020-05-28 11:51 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
` (7 preceding siblings ...)
2020-05-27 22:27 ` Jon Turney
@ 2020-05-29 14:40 ` Alexey Sokolov
2020-06-07 15:06 ` Hamish McIntyre-Bhatty
8 siblings, 1 reply; 49+ messages in thread
From: Alexey Sokolov @ 2020-05-29 14:40 UTC (permalink / raw)
To: cygwin-apps
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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>
> where <packagename> 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").
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-05-27 22:27 ` Jon Turney
2020-05-28 11:51 ` szgyg
@ 2020-06-04 16:01 ` Ken Brown
2020-06-04 20:33 ` Brian Inglis
2020-08-06 20:20 ` Jon Turney
` (2 subsequent siblings)
4 siblings, 1 reply; 49+ messages in thread
From: Ken Brown @ 2020-06-04 16:01 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-06-04 16:01 ` Ken Brown
@ 2020-06-04 20:33 ` Brian Inglis
2020-06-09 13:26 ` Jon Turney
0 siblings, 1 reply; 49+ messages in thread
From: Brian Inglis @ 2020-06-04 20:33 UTC (permalink / raw)
To: cygwin-apps
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.]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-05-29 14:40 ` Alexey Sokolov
@ 2020-06-07 15:06 ` Hamish McIntyre-Bhatty
0 siblings, 0 replies; 49+ messages in thread
From: Hamish McIntyre-Bhatty @ 2020-06-07 15:06 UTC (permalink / raw)
To: cygwin-apps
[-- Attachment #1.1.1: Type: text/plain, Size: 1312 bytes --]
> 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 cygwin@cygwin.com:/git/cygwin-packages/<packagename>
>>
>> where <packagename> 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
[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-06-04 20:33 ` Brian Inglis
@ 2020-06-09 13:26 ` Jon Turney
2020-06-09 22:44 ` Brian Inglis
0 siblings, 1 reply; 49+ messages in thread
From: Jon Turney @ 2020-06-09 13:26 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-06-09 13:26 ` Jon Turney
@ 2020-06-09 22:44 ` Brian Inglis
0 siblings, 0 replies; 49+ messages in thread
From: Brian Inglis @ 2020-06-09 22:44 UTC (permalink / raw)
To: cygwin-apps
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.]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-05-27 22:27 ` Jon Turney
2020-05-28 11:51 ` szgyg
2020-06-04 16:01 ` Ken Brown
@ 2020-08-06 20:20 ` Jon Turney
2020-08-06 21:04 ` Ken Brown
2020-08-07 19:42 ` Achim Gratz
2020-08-23 21:01 ` Jon Turney
2020-11-16 21:54 ` Brian Inglis
4 siblings, 2 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-06 20:20 UTC (permalink / raw)
To: cygwin-apps
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?
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-06 20:20 ` Jon Turney
@ 2020-08-06 21:04 ` Ken Brown
2020-08-07 19:42 ` Achim Gratz
1 sibling, 0 replies; 49+ messages in thread
From: Ken Brown @ 2020-08-06 21:04 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-06 20:20 ` Jon Turney
2020-08-06 21:04 ` Ken Brown
@ 2020-08-07 19:42 ` Achim Gratz
2020-08-07 22:05 ` Ken Brown
1 sibling, 1 reply; 49+ messages in thread
From: Achim Gratz @ 2020-08-07 19:42 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-07 19:42 ` Achim Gratz
@ 2020-08-07 22:05 ` Ken Brown
2020-08-08 4:26 ` ASSI
2020-08-16 18:05 ` Jon Turney
0 siblings, 2 replies; 49+ messages in thread
From: Ken Brown @ 2020-08-07 22:05 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-07 22:05 ` Ken Brown
@ 2020-08-08 4:26 ` ASSI
2020-08-16 18:05 ` Jon Turney
1 sibling, 0 replies; 49+ messages in thread
From: ASSI @ 2020-08-08 4:26 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-07 22:05 ` Ken Brown
2020-08-08 4:26 ` ASSI
@ 2020-08-16 18:05 ` Jon Turney
1 sibling, 0 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-16 18:05 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-05-27 22:27 ` Jon Turney
` (2 preceding siblings ...)
2020-08-06 20:20 ` Jon Turney
@ 2020-08-23 21:01 ` Jon Turney
2020-08-26 22:00 ` Ken Brown
2021-05-09 14:39 ` Jon Turney
2020-11-16 21:54 ` Brian Inglis
4 siblings, 2 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-23 21:01 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-23 21:01 ` Jon Turney
@ 2020-08-26 22:00 ` Ken Brown
2020-08-30 15:00 ` Jon Turney
2021-05-09 14:39 ` Jon Turney
1 sibling, 1 reply; 49+ messages in thread
From: Ken Brown @ 2020-08-26 22:00 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-26 22:00 ` Ken Brown
@ 2020-08-30 15:00 ` Jon Turney
2020-08-30 15:22 ` Ken Brown
2020-08-30 16:44 ` ASSI
0 siblings, 2 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-30 15:00 UTC (permalink / raw)
To: cygwin-apps, Ken Brown
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 15:00 ` Jon Turney
@ 2020-08-30 15:22 ` Ken Brown
2020-08-30 15:46 ` Jon Turney
2020-08-30 16:44 ` ASSI
1 sibling, 1 reply; 49+ messages in thread
From: Ken Brown @ 2020-08-30 15:22 UTC (permalink / raw)
To: Jon Turney, cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 15:22 ` Ken Brown
@ 2020-08-30 15:46 ` Jon Turney
2020-08-30 17:25 ` Ken Brown
2020-11-12 21:30 ` Jon Turney
0 siblings, 2 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-30 15:46 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 15:00 ` Jon Turney
2020-08-30 15:22 ` Ken Brown
@ 2020-08-30 16:44 ` ASSI
2020-08-30 20:08 ` Jon Turney
2020-10-04 10:26 ` Achim Gratz
1 sibling, 2 replies; 49+ messages in thread
From: ASSI @ 2020-08-30 16:44 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 15:46 ` Jon Turney
@ 2020-08-30 17:25 ` Ken Brown
2020-08-30 20:06 ` Jon Turney
2020-11-12 21:30 ` Jon Turney
1 sibling, 1 reply; 49+ messages in thread
From: Ken Brown @ 2020-08-30 17:25 UTC (permalink / raw)
To: Jon Turney, cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 17:25 ` Ken Brown
@ 2020-08-30 20:06 ` Jon Turney
0 siblings, 0 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-30 20:06 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 16:44 ` ASSI
@ 2020-08-30 20:08 ` Jon Turney
2020-10-04 10:26 ` Achim Gratz
1 sibling, 0 replies; 49+ messages in thread
From: Jon Turney @ 2020-08-30 20:08 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 16:44 ` ASSI
2020-08-30 20:08 ` Jon Turney
@ 2020-10-04 10:26 ` Achim Gratz
2020-10-25 18:10 ` Jon Turney
1 sibling, 1 reply; 49+ messages in thread
From: Achim Gratz @ 2020-10-04 10:26 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-10-04 10:26 ` Achim Gratz
@ 2020-10-25 18:10 ` Jon Turney
0 siblings, 0 replies; 49+ messages in thread
From: Jon Turney @ 2020-10-25 18:10 UTC (permalink / raw)
To: cygwin-apps
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-30 15:46 ` Jon Turney
2020-08-30 17:25 ` Ken Brown
@ 2020-11-12 21:30 ` Jon Turney
1 sibling, 0 replies; 49+ messages in thread
From: Jon Turney @ 2020-11-12 21:30 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-05-27 22:27 ` Jon Turney
` (3 preceding siblings ...)
2020-08-23 21:01 ` Jon Turney
@ 2020-11-16 21:54 ` Brian Inglis
2020-11-16 22:16 ` Jon Turney
2020-11-17 19:21 ` Achim Gratz
4 siblings, 2 replies; 49+ messages in thread
From: Brian Inglis @ 2020-11-16 21:54 UTC (permalink / raw)
To: cygwin-apps
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
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.]
[-- Attachment #2: playground-git-config.txt --]
[-- Type: text/plain, Size: 542 bytes --]
[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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-11-16 21:54 ` Brian Inglis
@ 2020-11-16 22:16 ` Jon Turney
2020-11-16 22:54 ` Brian Inglis
2020-11-17 19:21 ` Achim Gratz
1 sibling, 1 reply; 49+ messages in thread
From: Jon Turney @ 2020-11-16 22:16 UTC (permalink / raw)
To: cygwin-apps
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://cygwin@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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-11-16 22:16 ` Jon Turney
@ 2020-11-16 22:54 ` Brian Inglis
0 siblings, 0 replies; 49+ messages in thread
From: Brian Inglis @ 2020-11-16 22:54 UTC (permalink / raw)
To: cygwin-apps
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://cygwin@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 'cygwin@cygwin.com@cygwin@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.]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-11-16 21:54 ` Brian Inglis
2020-11-16 22:16 ` Jon Turney
@ 2020-11-17 19:21 ` Achim Gratz
1 sibling, 0 replies; 49+ messages in thread
From: Achim Gratz @ 2020-11-17 19:21 UTC (permalink / raw)
To: cygwin-apps
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://cygwin@cygwin.com"]
pushInsteadOf = git://cygwin.com
[url "git://cygwin.com/git/cygwin-packages"]
InsteadOf = cygpack:
[url "ssh://cygwin@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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2020-08-23 21:01 ` Jon Turney
2020-08-26 22:00 ` Ken Brown
@ 2021-05-09 14:39 ` Jon Turney
2021-06-22 19:52 ` Jon Turney
1 sibling, 1 reply; 49+ messages in thread
From: Jon Turney @ 2021-05-09 14:39 UTC (permalink / raw)
To: cygwin-apps
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:
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2021-05-09 14:39 ` Jon Turney
@ 2021-06-22 19:52 ` Jon Turney
2021-06-23 4:22 ` Brian Inglis
2022-07-05 13:12 ` Jon Turney
0 siblings, 2 replies; 49+ messages in thread
From: Jon Turney @ 2021-06-22 19:52 UTC (permalink / raw)
To: cygwin-apps
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=<token>'.
>> Currently, these packages are built using 'cygport all-test', and so
>> will always be marked test:
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2021-06-22 19:52 ` Jon Turney
@ 2021-06-23 4:22 ` Brian Inglis
2022-07-05 13:12 ` Jon Turney
1 sibling, 0 replies; 49+ messages in thread
From: Brian Inglis @ 2021-06-23 4:22 UTC (permalink / raw)
To: cygwin-apps
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=<token>'.
>
>>> 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.]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2021-06-22 19:52 ` Jon Turney
2021-06-23 4:22 ` Brian Inglis
@ 2022-07-05 13:12 ` Jon Turney
2023-02-18 16:21 ` Jon Turney
1 sibling, 1 reply; 49+ messages in thread
From: Jon Turney @ 2022-07-05 13:12 UTC (permalink / raw)
To: cygwin-apps
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=<token>'.
>
>>> 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'.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2022-07-05 13:12 ` Jon Turney
@ 2023-02-18 16:21 ` Jon Turney
2023-02-18 17:43 ` Ken Brown
0 siblings, 1 reply; 49+ messages in thread
From: Jon Turney @ 2023-02-18 16:21 UTC (permalink / raw)
To: 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=<token>'.
>>
>>>> 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 cygwin@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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2023-02-18 16:21 ` Jon Turney
@ 2023-02-18 17:43 ` Ken Brown
2023-02-18 18:40 ` Jon Turney
0 siblings, 1 reply; 49+ messages in thread
From: Ken Brown @ 2023-02-18 17:43 UTC (permalink / raw)
To: 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=<token>'.
>>>
>>>>> 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 cygwin@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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: git repositories for cygwin packaging - please test
2023-02-18 17:43 ` Ken Brown
@ 2023-02-18 18:40 ` Jon Turney
0 siblings, 0 replies; 49+ messages in thread
From: Jon Turney @ 2023-02-18 18:40 UTC (permalink / raw)
To: 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 cygwin@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)
^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2023-02-18 18:40 UTC | newest]
Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-04 20:08 git repositories for cygwin packaging - please test Jon Turney
2019-08-05 2:03 ` Ken Brown
2019-08-08 13:47 ` Andrew Schulman via cygwin-apps
2019-08-08 14:04 ` Andrew Schulman via cygwin-apps
2019-08-08 17:09 ` Ken Brown
2019-08-09 16:12 ` Jon Turney
2019-08-09 19:12 ` Ken Brown
2019-08-13 11:55 ` Jon Turney
2019-08-09 16:00 ` Jon Turney
2019-08-09 20:58 ` Brian Inglis
2019-08-13 11:55 ` Jon Turney
2019-08-19 18:36 ` Achim Gratz
2020-05-27 22:27 ` Jon Turney
2020-05-28 11:51 ` szgyg
2020-06-04 16:01 ` Ken Brown
2020-06-04 20:33 ` Brian Inglis
2020-06-09 13:26 ` Jon Turney
2020-06-09 22:44 ` Brian Inglis
2020-08-06 20:20 ` Jon Turney
2020-08-06 21:04 ` Ken Brown
2020-08-07 19:42 ` Achim Gratz
2020-08-07 22:05 ` Ken Brown
2020-08-08 4:26 ` ASSI
2020-08-16 18:05 ` Jon Turney
2020-08-23 21:01 ` Jon Turney
2020-08-26 22:00 ` Ken Brown
2020-08-30 15:00 ` Jon Turney
2020-08-30 15:22 ` Ken Brown
2020-08-30 15:46 ` Jon Turney
2020-08-30 17:25 ` Ken Brown
2020-08-30 20:06 ` Jon Turney
2020-11-12 21:30 ` Jon Turney
2020-08-30 16:44 ` ASSI
2020-08-30 20:08 ` Jon Turney
2020-10-04 10:26 ` Achim Gratz
2020-10-25 18:10 ` Jon Turney
2021-05-09 14:39 ` Jon Turney
2021-06-22 19:52 ` Jon Turney
2021-06-23 4:22 ` Brian Inglis
2022-07-05 13:12 ` Jon Turney
2023-02-18 16:21 ` Jon Turney
2023-02-18 17:43 ` Ken Brown
2023-02-18 18:40 ` Jon Turney
2020-11-16 21:54 ` Brian Inglis
2020-11-16 22:16 ` Jon Turney
2020-11-16 22:54 ` Brian Inglis
2020-11-17 19:21 ` Achim Gratz
2020-05-29 14:40 ` Alexey Sokolov
2020-06-07 15:06 ` Hamish McIntyre-Bhatty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).