[ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis]

Noticing some more libraries used by curl and wget/2 that were outdated
and orphaned, I decided to take a look at building updates and would now
like to adopt them.

The list below shows the distributed packages, links to the Git Cygwin
Package repos (see playground branches), Appveyor CI builds and logs
for those who prefer looking at those, and links to Google drive folders
with all the usual files and archives for others.

I have issues building python2/27/3/36 modules, and/or which to obsolete.

I would like to get all this sorted and updated before updating the latest
curl release now available.

Feedback and questions welcome.

Binaries		Last		Proposed	Source
nghttp2			1.37.0-1	1.43.0-1	source
nghttp2-debuginfo	1.37.0-1	1.43.0-1
libnghttp2_14		1.37.0-1	1.43.0-1
libnghttp2-devel	1.37.0-1	1.43.0-1
python-nghttp2		1.37.0-1	obsolete?
python2-nghttp2		1.37.0-1	obsolete?
python27-nghttp2	1.37.0-1	obsolete?
python3-nghttp2		1.37.0-1	obsolete?
python36-nghttp2	1.37.0-1	obsolete?
python37-nghttp2	1.37.0-1	1.43.0-1
python38-nghttp2	new		1.43.0-1
mingw64-i686-nghttp2	1.31.0-1	1.43.0-1	source
mingw64-x86_64-nghttp2	1.31.0-1	1.43.0-1	source

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/nghttp2.git;a=summary
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-x86_64-nghttp2.git;a=summary
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-nghttp2.git;a=summary

https://ci.appveyor.com/project/cygwin/scallywag/builds/39370115
https://ci.appveyor.com/api/buildjobs/48gfcwh89ip3ts2g/log
https://ci.appveyor.com/api/buildjobs/5pggx6no64rhjdbv/log

https://drive.google.com/drive/folders/1Ee4KNQ6EaTnh8MkqbLNxnEpBaw3JOaFk

-- 
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: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Marco Atzeri]

On 28.05.2021 19:06, Brian Inglis wrote:
> Noticing some more libraries used by curl and wget/2 that were outdated
> and orphaned, I decided to take a look at building updates and would now
> like to adopt them.
> 
> The list below shows the distributed packages, links to the Git Cygwin
> Package repos (see playground branches), Appveyor CI builds and logs
> for those who prefer looking at those, and links to Google drive folders
> with all the usual files and archives for others.
> 
> I have issues building python2/27/3/36 modules, and/or which to obsolete.

you can drop all.
Python2.7 is dead upstream and Python3.6 will be at end of 2021

https://www.python.org/downloads/

Changed maintanership to you
(only for them this time)

Regards
Marco

Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis]

On 2021-05-28 12:33, Marco Atzeri via Cygwin-apps wrote:
> On 28.05.2021 19:06, Brian Inglis wrote:
>> Noticing some more libraries used by curl and wget/2 that were outdated
>> and orphaned, I decided to take a look at building updates and would now
>> like to adopt them.
>>
>> The list below shows the distributed packages, links to the Git Cygwin
>> Package repos (see playground branches), Appveyor CI builds and logs
>> for those who prefer looking at those, and links to Google drive folders
>> with all the usual files and archives for others.
>>
>> I have issues building python2/27/3/36 modules, and/or which to obsolete.
> 
> you can drop all.
> Python2.7 is dead upstream and Python3.6 will be at end of 2021
> 
> https://www.python.org/downloads/

I would appreciate advice on how to structure obsoleting the existing packages:

python-nghttp2
python2-nghttp2
python27-nghttp2
python3-nghttp2
python36-nghttp2

given replacement packages python37-nghttp2 and python38-nghttp2.
I can define all those as empty packages for the proposed release,
but which should obsolete what to get the appropriate replacements?
Should I define the following packages e.g.:

  python2-nghttp2 dummy obsoletes   python-nghttp2
python27-nghttp2 dummy obsoletes  python2-nghttp2
  python3-nghttp2 dummy obsoletes python27-nghttp2
python36-nghttp2 dummy obsoletes  python3-nghttp2
python37-nghttp2 real  obsoletes python36-nghttp2
python38-nghttp2 real  stands alone for now?

> Changed maintainership to you (only for them this time)

Thank you very much - appreciate that!
Repology.org dropped the extraneous maintainership adds/removes ;^>

-- 
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: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis]

On 2021-05-28 17:18, Brian Inglis wrote:
> On 2021-05-28 12:33, Marco Atzeri via Cygwin-apps wrote:
>> On 28.05.2021 19:06, Brian Inglis wrote:
>>> Noticing some more libraries used by curl and wget/2 that were outdated
>>> and orphaned, I decided to take a look at building updates and would now
>>> like to adopt them.
>>>
>>> The list below shows the distributed packages, links to the Git Cygwin
>>> Package repos (see playground branches), Appveyor CI builds and logs
>>> for those who prefer looking at those, and links to Google drive folders
>>> with all the usual files and archives for others.
>>>
>>> I have issues building python2/27/3/36 modules, and/or which to obsolete.
>>
>> you can drop all.
>> Python2.7 is dead upstream and Python3.6 will be at end of 2021
>>
>> https://www.python.org/downloads/
> 
> I would appreciate advice on how to structure obsoleting the existing packages:
> 
> python-nghttp2
> python2-nghttp2
> python27-nghttp2
> python3-nghttp2
> python36-nghttp2
> 
> given replacement packages python37-nghttp2 and python38-nghttp2.
> I can define all those as empty packages for the proposed release,
> but which should obsolete what to get the appropriate replacements?
> Should I define the following packages e.g.:
> 
>   python2-nghttp2 dummy obsoletes   python-nghttp2
> python27-nghttp2 dummy obsoletes  python2-nghttp2
>   python3-nghttp2 dummy obsoletes python27-nghttp2
> python36-nghttp2 dummy obsoletes  python3-nghttp2
> python37-nghttp2 real  obsoletes python36-nghttp2
> python38-nghttp2 real  stands alone for now?

I have changed the cygport to do the above and the results are here:

https://drive.google.com/drive/folders/1Ee4KNQ6EaTnh8MkqbLNxnEpBaw3JOaFk

until I can get git-cygwin-packages working again - see below!

>> Changed maintainership to you (only for them this time)
> 
> Thank you very much - appreciate that!
> Repology.org dropped the extraneous maintainership adds/removes ;^>

Do I also have ownership of:
ssh://cygwin@cygwin.com/git/cygwin-packages/{,mingw64-{x86_64,i686}-}nghttp2.git?

I am getting the following responses whenever I try to push to either playground
or master branches!

I have been pushing to playground for days while testing with no problems.

FYI I have ssh host *cygwin* defined as *cygwin@cygwin.com* with specific key;
git seems to get confused if I use the full cygwin@cygwin.com ssh login string.

$ git push
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 4 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (9/9), 2.23 KiB | 326.00 KiB/s, done.
Total 9 (delta 2), reused 0 (delta 0), pack-reused 0
remote: 'there can be only one!' at /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27.
remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280
remote: error: hook declined to update refs/heads/playground
To ssh://cygwin/git/cygwin-packages/nghttp2
  ! [remote rejected]           playground -> playground (hook declined)
error: failed to push some refs to 'ssh://cygwin/git/cygwin-packages/nghttp2'
$ git checkout master
$ git push
Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Delta compression using up to 4 threads
Compressing objects: 100% (13/13), done.
Writing objects: 100% (15/15), 3.03 KiB | 443.00 KiB/s, done.
Total 15 (delta 5), reused 0 (delta 0), pack-reused 0
remote: 'there can be only one!' at /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27.
remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280
remote: error: hook declined to update refs/heads/master
To ssh://cygwin/git/cygwin-packages/nghttp2.git
  ! [remote rejected]           master -> master (hook declined)
error: failed to push some refs to 'ssh://cygwin/git/cygwin-packages/nghttp2.git'

-- 
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: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Marco Atzeri]

On 29.05.2021 06:37, Brian Inglis wrote:
> On 2021-05-28 17:18, Brian Inglis wrote:
>> On 2021-05-28 12:33, Marco Atzeri via Cygwin-apps wrote:
>>> On 28.05.2021 19:06, Brian Inglis wrote:
>>>> Noticing some more libraries used by curl and wget/2 that were outdated
>>>> and orphaned, I decided to take a look at building updates and would 
>>>> now
>>>> like to adopt them.
>>>>
>>>> The list below shows the distributed packages, links to the Git Cygwin
>>>> Package repos (see playground branches), Appveyor CI builds and logs
>>>> for those who prefer looking at those, and links to Google drive 
>>>> folders
>>>> with all the usual files and archives for others.
>>>>
>>>> I have issues building python2/27/3/36 modules, and/or which to 
>>>> obsolete.
>>>
>>> you can drop all.
>>> Python2.7 is dead upstream and Python3.6 will be at end of 2021
>>>
>>> https://www.python.org/downloads/
>>
>> I would appreciate advice on how to structure obsoleting the existing 
>> packages:
>>
>> python-nghttp2
>> python2-nghttp2
>> python27-nghttp2
>> python3-nghttp2
>> python36-nghttp2
>>
>> given replacement packages python37-nghttp2 and python38-nghttp2.
>> I can define all those as empty packages for the proposed release,
>> but which should obsolete what to get the appropriate replacements?
>> Should I define the following packages e.g.:
>>
>>   python2-nghttp2 dummy obsoletes   python-nghttp2
>> python27-nghttp2 dummy obsoletes  python2-nghttp2
>>   python3-nghttp2 dummy obsoletes python27-nghttp2

this make no sense

>> python36-nghttp2 dummy obsoletes  python3-nghttp2

>> python37-nghttp2 real  obsoletes python36-nghttp2

usually I don´t do one full version to obsolete another full version

>> python38-nghttp2 real  stands alone for now?

I guess you can just avoid to pack

   python2-nghttp2
   python27-nghttp2
   python36-nghttp2

and obsoletes

   python3-nghttp2
   python-nghttp2

from python38-nghttp2

On ipython I packaged only 37 and 38, and calm did not complained of 
missing the other versions.

> I have changed the cygport to do the above and the results are here:
> 
> https://drive.google.com/drive/folders/1Ee4KNQ6EaTnh8MkqbLNxnEpBaw3JOaFk
> 
> until I can get git-cygwin-packages working again - see below!
> 
>>> Changed maintainership to you (only for them this time)
>>
>> Thank you very much - appreciate that!
>> Repology.org dropped the extraneous maintainership adds/removes ;^>
> 
> Do I also have ownership of:
> ssh://cygwin@cygwin.com/git/cygwin-packages/{,mingw64-{x86_64,i686}-}nghttp2.git? 

should be
but Jon is the expert here

> I am getting the following responses whenever I try to push to either 
> playground
> or master branches!
> 
> I have been pushing to playground for days while testing with no problems.
> 
> FYI I have ssh host *cygwin* defined as *cygwin@cygwin.com* with 
> specific key;
> git seems to get confused if I use the full cygwin@cygwin.com ssh login 
> string.
> 
> $ git push
> Enumerating objects: 11, done.
> Counting objects: 100% (11/11), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (7/7), done.
> Writing objects: 100% (9/9), 2.23 KiB | 326.00 KiB/s, done.
> Total 9 (delta 2), reused 0 (delta 0), pack-reused 0
> remote: 'there can be only one!' at 
> /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27.
> remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280
> remote: error: hook declined to update refs/heads/playground
> To ssh://cygwin/git/cygwin-packages/nghttp2
>   ! [remote rejected]           playground -> playground (hook declined)
> error: failed to push some refs to 
> 'ssh://cygwin/git/cygwin-packages/nghttp2'
> $ git checkout master
> $ git push
> Enumerating objects: 19, done.
> Counting objects: 100% (19/19), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (13/13), done.
> Writing objects: 100% (15/15), 3.03 KiB | 443.00 KiB/s, done.
> Total 15 (delta 5), reused 0 (delta 0), pack-reused 0
> remote: 'there can be only one!' at 
> /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27.
> remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280
> remote: error: hook declined to update refs/heads/master
> To ssh://cygwin/git/cygwin-packages/nghttp2.git
>   ! [remote rejected]           master -> master (hook declined)
> error: failed to push some refs to 
> 'ssh://cygwin/git/cygwin-packages/nghttp2.git'
> 

Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Jon Turney]

On 29/05/2021 07:12, Marco Atzeri via Cygwin-apps wrote:
> On 29.05.2021 06:37, Brian Inglis wrote:
[...]
>>
>> until I can get git-cygwin-packages working again - see below!
>>
>>>> Changed maintainership to you (only for them this time)
>>>
>>> Thank you very much - appreciate that!
>>> Repology.org dropped the extraneous maintainership adds/removes ;^>
>>
>> Do I also have ownership of: 
> 
> should be
> but Jon is the expert here
> 
>> I am getting the following responses whenever I try to push to either 
>> playground
>> or master branches!
[...]
>>
>> $ git push
>> Enumerating objects: 11, done.
>> Counting objects: 100% (11/11), done.
>> Delta compression using up to 4 threads
>> Compressing objects: 100% (7/7), done.
>> Writing objects: 100% (9/9), 2.23 KiB | 326.00 KiB/s, done.
>> Total 9 (delta 2), reused 0 (delta 0), pack-reused 0
>> remote: 'there can be only one!' at 
>> /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27.
>> remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280
>> remote: error: hook declined to update refs/heads/playground
>> To ssh://cygwin/git/cygwin-packages/nghttp2
>>   ! [remote rejected]           playground -> playground (hook declined)
>> error: failed to push some refs to 
>> 'ssh://cygwin/git/cygwin-packages/nghttp2'
This is a new trigger I turned on recently, which (is supposed to) 
prevent pushes of trees which contain more than one .cygport file
(since that complicates navigating from source pacakage name to git 
history of the .cygport file in ways I have no interest in implementing)

I've tuned this down to a warning at the moment (and made it a bit 
clearer) so you should be able to proceed.

Can you provide a commit id which triggers this which but shouldn't, and 
I'll try to work out why...

Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Achim Gratz]

Jon Turney writes:
> This is a new trigger I turned on recently, which (is supposed to)
> prevent pushes of trees which contain more than one .cygport file
> (since that complicates navigating from source pacakage name to git
> history of the .cygport file in ways I have no interest in
> implementing)

Well, it was obvious that you didn't think it was useful, however I'd
really wish you would first discuss changes which prevent existing
practise to continue before implementing them.  I was in the process of
preparing an RFC about the package repository structure since there are
obviously multiple ways of going about it, but I'm going to hold off for
now.

> I've tuned this down to a warning at the moment (and made it a bit
> clearer) so you should be able to proceed.

Thanks.


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: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Achim Gratz]

Jon Turney writes:
> Can you provide a commit id which triggers this which but shouldn't,
> and I'll try to work out why...

--8<---------------cut here---------------start------------->8---
[master 8c744db] protobuf: update to version 3.17.1
 2 files changed, 22 insertions(+), 6 deletions(-)
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 1.29 KiB | 1.29 MiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
remote: warning: 8c744dbfb212bf55bb5df60f3e63d337d40bd921 seems to contain more than one .cygport file
remote: this is bad and you should feel bad
--8<---------------cut here---------------end--------------->8---

No, there is only one cygport file and even if there were I would not and
should not feel bad.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis]

On 2021-05-29 00:12, Marco Atzeri via Cygwin-apps wrote:
> On 29.05.2021 06:37, Brian Inglis wrote:
>> On 2021-05-28 17:18, Brian Inglis wrote:
>>> On 2021-05-28 12:33, Marco Atzeri via Cygwin-apps wrote:
>>>> On 28.05.2021 19:06, Brian Inglis wrote:
>>>>> Noticing some more libraries used by curl and wget/2 that were outdated
>>>>> and orphaned, I decided to take a look at building updates and would now
>>>>> like to adopt them.
>>>>> The list below shows the distributed packages, links to the Git Cygwin
>>>>> Package repos (see playground branches), Appveyor CI builds and logs
>>>>> for those who prefer looking at those, and links to Google drive folders
>>>>> with all the usual files and archives for others.
>>>>> I have issues building python2/27/3/36 modules, and/or which to obsolete.

>>>> you can drop all.
>>>> Python2.7 is dead upstream and Python3.6 will be at end of 2021
>>>> https://www.python.org/downloads/

>>> I would appreciate advice on how to structure obsoleting the existing packages:
>>> python-nghttp2
>>> python2-nghttp2
>>> python27-nghttp2
>>> python3-nghttp2
>>> python36-nghttp2
>>> given replacement packages python37-nghttp2 and python38-nghttp2.
>>> I can define all those as empty packages for the proposed release,
>>> but which should obsolete what to get the appropriate replacements?
>>> Should I define the following packages e.g.:
>>>  python2-nghttp2 dummy obsoletes   python-nghttp2
>>> python27-nghttp2 dummy obsoletes  python2-nghttp2
>>>  python3-nghttp2 dummy obsoletes python27-nghttp2

> this make no sense

>>> python36-nghttp2 dummy obsoletes  python3-nghttp2
>>> python37-nghttp2 real  obsoletes python36-nghttp2

> usually I don´t do one full version to obsolete another full version

They are empty dummy packages to replace and upgrade the previous
packages to proposed rather than just orphaning them:

 >>> python2-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

 >>> python27-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

 >>> python3-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

 >>> python36-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

from cygport:

python2_nghttp2_CATEGORY="$CATEGORY Python"
python2_nghttp2_SUMMARY="$SUMMARY (Python 2)"
python2_nghttp2_OBSOLETES="python-nghttp2"
#python2_nghttp2_CONTENTS="usr/lib/python2/site-packages/*nghttp2*"

python27_nghttp2_CATEGORY="$CATEGORY Python"
python27_nghttp2_SUMMARY="$SUMMARY (Python 2.7)"
python27_nghttp2_OBSOLETES="python2-nghttp2"
#python27_nghttp2_CONTENTS="usr/lib/python2.7/site-packages/*nghttp2*"

python3_nghttp2_CATEGORY="$CATEGORY Python"
python3_nghttp2_SUMMARY="$SUMMARY (Python 3)"
python3_nghttp2_OBSOLETES="python27-nghttp2"
#python3_nghttp2_CONTENTS="usr/lib/python3/site-packages/*nghttp2*"

python36_nghttp2_CATEGORY="$CATEGORY Python"
python36_nghttp2_SUMMARY="$SUMMARY (Python 3.6)"
python36_nghttp2_OBSOLETES="python3-nghttp2"
#python36_nghttp2_CONTENTS="usr/lib/python3.6/site-packages/*nghttp2*"

python37_nghttp2_CATEGORY="$CATEGORY Python"
python37_nghttp2_SUMMARY="$SUMMARY (Python 3.7)"
python37_nghttp2_OBSOLETES="python36-nghttp2"
python37_nghttp2_CONTENTS="usr/lib/python3.7/site-packages/*nghttp2*"

python38_nghttp2_CATEGORY="$CATEGORY Python"
python38_nghttp2_SUMMARY="$SUMMARY (Python 3.8)"
python38_nghttp2_CONTENTS="usr/lib/python3.8/site-packages/*nghttp2*"

>>> python38-nghttp2 real  stands alone for now?

> I guess you can just avoid to pack
>    python2-nghttp2
>    python27-nghttp2
>    python36-nghttp2
> and obsoletes
>    python3-nghttp2
>    python-nghttp2
> from python38-nghttp2
> On ipython I packaged only 37 and 38, and calm did not complained of missing the other versions.

As package versions may be dependent in most cases but independent when products
support installing parallel versions, calm is DTRT.
But wouldn't not packaging upgrades just orphan the older packages, requiring
manual removal/addition, as when there is a version epoch break?
[I have no clue how python modules of different versions interact.]

>> I have changed the cygport to do the above and the results are here:
>> https://drive.google.com/drive/folders/1Ee4KNQ6EaTnh8MkqbLNxnEpBaw3JOaFk
>> until I can get git-cygwin-packages working again - see below!

>>>> Changed maintainership to you

>> Do I also have ownership of:
>> ssh://cygwin@cygwin.com/git/cygwin-packages/{,mingw64-{x86_64,i686}-}nghttp2.git? 

> should be
> but Jon is the expert here

-- 
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: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis]

On 2021-05-29 04:09, Jon Turney wrote:
> On 29/05/2021 07:12, Marco Atzeri via Cygwin-apps wrote:
>> On 29.05.2021 06:37, Brian Inglis wrote:
>>> until I can get git-cygwin-packages working again - see below!
>>>>> Changed maintainership to you (only for them this time)
>>>> Thank you very much - appreciate that!
>>> Do I also have ownership of: 
>> should be
>> but Jon is the expert here

>>> I am getting the following responses whenever I try to push to
>>> either playground or master branches!...
>>> $ git push
>>> Enumerating objects: 11, done.
>>> Counting objects: 100% (11/11), done.
>>> Delta compression using up to 4 threads
>>> Compressing objects: 100% (7/7), done.
>>> Writing objects: 100% (9/9), 2.23 KiB | 326.00 KiB/s, done.
>>> Total 9 (delta 2), reused 0 (delta 0), pack-reused 0
>>> remote: 'there can be only one!' at /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27.
>>> remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280
>>> remote: error: hook declined to update refs/heads/playground
>>> To ssh://cygwin/git/cygwin-packages/nghttp2
>>>   ! [remote rejected]           playground -> playground (hook declined)
>>> error: failed to push some refs to 'ssh://cygwin/git/cygwin-packages/nghttp2'

> This is a new trigger I turned on recently, which (is supposed to) 
> prevent pushes of trees which contain more than one .cygport file
> (since that complicates navigating from source package name to git 
> history of the .cygport file in ways I have no interest in
> implementing)
> I've tuned this down to a warning at the moment (and made it a bit 
> clearer) so you should be able to proceed.
> Can you provide a commit id which triggers this which but shouldn't,
> and I'll try to work out why...
Criterion for having "only one!"?
There's a .cygport on both playground and master branches?
Which is kind of the point of having branches! ;^>

$ git push
Enumerating objects: 14, done.
Counting objects: 100% (14/14), done.
Delta compression using up to 4 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (12/12), 2.49 KiB | 425.00 KiB/s, done.
Total 12 (delta 4), reused 0 (delta 0), pack-reused 0
remote: warning: adae2d9f76a662dbf0151e8a48b750bf93dd2d13 seems to 
contain more than one .cygport file
remote: this is bad and you should feel bad
remote: scallywag: build 2916 queued
remote: scallywag: https://cygwin.com/cgi-bin2/jobs.cgi?id=2916
To ssh://cygwin/git/cygwin-packages/nghttp2
    ee14bc998685..adae2d9f76a6  playground -> playground
$

This seems to have committed/pushed one of my mingw64 package 
subdirectories, which has its own repo and .git tree:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/nghttp2.git;a=tree;h=refs/heads/playground;hb=refs/heads/playground

How do I get rid of that object and keep the real files?
Can I copy that dir tree and just git rm and push all the objects?

I may have already merged those objects into master as part of earlier 
tests.
Will re-merging playground after rm fix those up?

Only thing I can think of is that I somehow managed to get to the state 
below, perhaps by trying to stage/add/commit files in mingw... 
subdirectories, which may have been propagated up to the parent 
directory if lacking its own .git tree, if I had not yet cloned the 
mingw git/cygwin-packages repos:

$ git status -b -v
On branch playground
Your branch is based on 'origin/playground', but the upstream is gone.
    (use "git branch --unset-upstream" to fixup)

Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
          typechange: mingw64-x86_64-nghttp2/configure-ac-cxx-ext.patch
          modified:   mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2.cygport
          typechange: 
mingw64-x86_64-nghttp2/tests-Makefile-am-staticlib.patch

Untracked files:
    (use "git add <file>..." to include in what will be committed)
          1.7.1-win32-tests.patch
          check.uri
          ci.uri
          gdrive.uri
          nghttp2-1.37.0-1.i686/
          nghttp2-1.37.0-1.x86_64/
          nghttp2-1.43.0-1.i686/
          nghttp2-1.43.0-1.x86_64/
          nghttp2-i686-ci.log
          nghttp2-update-1.43.eml
          nghttp2-x86_64-ci.log

no changes added to commit (use "git add" and/or "git commit -a")
$

which I undid with a:

$ git stash
Saved working directory and index state WIP on playground:
29e92b49619d add empty python module subpackages to obsolete
$

although I thought I had previously cloned those earlier:

$ llgo -A {*/,}.git/config
-rw-r--r-- 1 426 May 28 22:21 .git/config
-rw-r--r-- 1 371 May 28 09:00 mingw64-i686-nghttp2/.git/config
-rw-r--r-- 1 373 May 28 08:53 mingw64-x86_64-nghttp2/.git/config
$ tail -n+0 {*/,}.git/config
==> mingw64-i686-nghttp2/.git/config <==
[core]
         repositoryformatversion = 0
         filemode = true
         bare = false
         logallrefupdates = true
         ignorecase = true
[remote "origin"]
         url = ssh://cygwin/git/cygwin-packages/mingw64-i686-nghttp2.git
         fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
         remote = origin
         merge = refs/heads/master
[branch "playground"]
         remote = origin
         merge = refs/heads/playground

==> mingw64-x86_64-nghttp2/.git/config <==
[core]
         repositoryformatversion = 0
         filemode = true
         bare = false
         logallrefupdates = true
         ignorecase = true
[remote "origin"]
         url = ssh://cygwin/git/cygwin-packages/mingw64-x86_64-nghttp2.git
         fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
         remote = origin
         merge = refs/heads/master
[branch "playground"]
         remote = origin
         merge = refs/heads/playground

==> .git/config <==
[core]
         repositoryformatversion = 0
         filemode = true
         bare = false
         logallrefupdates = true
         ignorecase = true
[remote "origin"]
         url = ssh://cygwin/git/cygwin-packages/nghttp2.git
         fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
         remote = ssh://cygwin/git/cygwin-packages/nghttp2
         merge = refs/heads/master
[branch "playground"]
         remote = ssh://cygwin/git/cygwin-packages/nghttp2
         merge = refs/heads/playground
$

-- 
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: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Achim Gratz]

Brian Inglis writes:
> This seems to have committed/pushed one of my mingw64 package
> subdirectories, which has its own repo and .git tree:
>
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/nghttp2.git;a=tree;h=refs/heads/playground;hb=refs/heads/playground

Don't do things like this.  You'd need to use submodules, but that
doesn't really work for this particular relation between the main and
MingW64 packages and submodules come with their own pitfalls.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis]

On 2021-05-29 12:01, Achim Gratz wrote:
> Brian Inglis writes:
>> This seems to have committed/pushed one of my mingw64 package
>> subdirectories, which has its own repo and .git tree:
>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/nghttp2.git;a=tree;h=refs/heads/playground;hb=refs/heads/playground

> Don't do things like this. You'd need to use submodules, but that
> doesn't really work for this particular relation between the main and
> MingW64 packages and submodules come with their own pitfalls.

As I said, it was unintentional, and may possibly have been a mistake 
with git deciding to helpfully add the subdirectory and files to a 
parent .git directory, or thought I was in the parent directory (e.g. cd 
... or cd - to wrong directory) and used e.g.:

	$ git add *.cygport *.patch; git commit -m '...'

I've been typing ahead blind on slow links, systems, and terminals, 
since using TECO over 110 dialup with noecho on a TTY for speedup! ;^>
That way you get a lot of experience by recovering from serious errors!

-- 
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.]