Re: Is it possible to 'cygport upload' with same p-v-r?
Mark Geisert writes: > I'd like to re-spin the latest version of cygutils, that is, upload > newer files with the same release number (1.4.16-5). Is this > possible, or do we now always change the release# when uploading? Re-spin == re-release, so you need to increase the release number. Test releases are releases too, the only difference is that users have to actively opt-in to their installation. You can only promote to current (aka un-test) or release another version (after you've done that you can delete the test version). You could make a lower version replace a test version that you want to delete (not sure how well tested that is and what the various unofficial methods of installing Cygwin would do in this case), but you can still not recycle the release number you gave that test version. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: Is it possible to 'cygport upload' with same p-v-r?
On Sat, 28 Aug 2021 at 09:09, Mark Geisert wrote: > > HI all,B > I'd like to re-spin the latest version of cygutils, that is, upload newer > files with the same release number (1.4.16-5). Is this possible, or do we > now always change the release# when uploading? > Thanks, I'm pretty sure this isn't possible, and nor should it be. Once it has been uploaded, people may have downloaded it. Without a change to at least the release number, the setup programs won't know that they should download and install the newer build.
Is it possible to 'cygport upload' with same p-v-r?
HI all,B I'd like to re-spin the latest version of cygutils, that is, upload newer files with the same release number (1.4.16-5). Is this possible, or do we now always change the release# when uploading? Thanks, ..mark
Re: cygport upload max-retries exceeded - please reset account again!
On 18/10/2020 18:44, Brian Inglis wrote: On 2020-10-17 09:52, Brian Inglis wrote: Could be due to problems with cygwin-git-package pushes, but I have a few updated packages to upload, and cygport uploads are now failing: Hi folks, Something else going on here since successful tzcode, tzdata uploads! Trying to upload curl packages and same failure: $ cygport curl.cygport upload >>> Uploading curl-7.73.0-1.x86_64 >>> Running lftp sftp://cygwin:@cygwin.com cd: Fatal error: max-retries exceeded (cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: Permission denied (publickey).) *** ERROR: Upload failed 'max-retries exceeded' here is coming from lftp locally. There's nothing to reset.
Re: cygport upload max-retries exceeded - please reset account again!
On 2020-10-17 09:52, Brian Inglis wrote: > Could be due to problems with cygwin-git-package pushes, but I have a few > updated packages to upload, and cygport uploads are now failing: Hi folks, Something else going on here since successful tzcode, tzdata uploads! Trying to upload curl packages and same failure: $ cygport curl.cygport upload >>> Uploading curl-7.73.0-1.x86_64 >>> Running lftp sftp://cygwin:@cygwin.com cd: Fatal error: max-retries exceeded (cyg...@cygwin.com: Permission denied (publickey).) *** ERROR: Upload failed -- 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.]
cygport upload max-retries exceeded - please reset account
Could be due to problems with cygwin-git-package pushes, but I have a few updated packages to upload, and cygport uploads are now failing: $ cygport tzcode.cygport upload >>> Uploading tzcode-2020c-1.x86_64 >>> Running lftp sftp://cygwin:@cygwin.com cd: Fatal error: max-retries exceeded (cyg...@cygwin.com: Permission denied (publickey).) *** ERROR: Upload failed $ cygport tzdata.cygport upload >>> Uploading tzdata-2020c-1.noarch >>> Running lftp sftp://cygwin:@cygwin.com cd: Fatal error: max-retries exceeded (cyg...@cygwin.com: Permission denied (publickey).) *** ERROR: Upload failed -- 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: cygport upload
> > OK, works. Can lftp or cygport be configured so that lftp does not ask > > for a password? Or to use sftp instead? > > I don't know of any configuration for lftp to turn off that behaviour > (which is arguably a defect in lftp), but that's probably something you > could investigate for yourself. > > I am not sure why lftp is used instead of sftp, possibly it is > insufficiently scriptable to do what cygport wants to do. I wrote the upload command for cygport, with review by Yaakov. Yes, it is harder to script than you might guess. I originally proposed to offer sftp and lftp options, but he said to strip it down to just lftp. The logic is in /usr/share/cygport/lib/pkg_upload.cygpart. If the SSH_KEY environment variable isn't set, then lftp connects with the connect string sftp://cyg...@cygwin.com which will prompt for a password. To use an ssh key, set SSH_KEY equal to the file name of the key. You can do that in ~/.cygport.conf, for example: SSH_KEY=~/.ssh/id_dsa Then if the key is already loaded in a running ssh_agent, or if it's unencrypted, you shouldn't get a password prompt. Note that SSH_KEY is documented in the cygport docs. Good luck! Andrew
Re: CLDR pkg-config (was: cygport upload)
On 2020-03-27 11:31, Thomas Wolff wrote:
> Am 27.03.2020 um 17:27 schrieb Jon Turney:
>> On 27/03/2020 16:15, Thomas Wolff wrote:
>>> Am 27.03.2020 um 16:41 schrieb Jon Turney:
>>>> On 27/03/2020 14:35, Thomas Wolff wrote:
>>>>> Am 27.03.2020 um 13:21 schrieb Jon Turney:
>>>>>> On 27/03/2020 10:17, Thomas Wolff wrote:
>>>>>>> How does cygport upload work?
>>>>>>> I previously uploaded with sftp but cygport apparently runs lftp and it
>>>>>>> asks me for a password.
>>>>>>
>>>>>> This just seems to be a thing lftp does.
>>>>>>
>>>>>> If the key isn't coming from ssh-agent, it always asks for a passphrase.
>>>>>> If the key doesn't have one, you can just hit enter (or type anything).
>>>>> OK, works. Can lftp or cygport be configured so that lftp does not ask for
>>>>> a password? Or to use sftp instead?
>>>>
>>>> I don't know of any configuration for lftp to turn off that behaviour
>>>> (which
>>>> is arguably a defect in lftp), but that's probably something you could
>>>> investigate for yourself.
>>>>
>>>> I am not sure why lftp is used instead of sftp, possibly it is
>>>> insufficiently scriptable to do what cygport wants to do.
>>>>
>>>>> Uploading the two Unicode packages, I got this response:
>>>>>
>>>>> ERROR: package '/sourceware/cygwin-staging/home/Thomas
>>>>> Wolff/noarch/release/unicode-cldr' is not in the package list
>>>>> ERROR: package '/sourceware/cygwin-staging/home/Thomas
>>>>> Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in
>>>>> the package list
>>>>> SUMMARY: 2 ERROR(s)
>>>>
>>>> Ah, right.
>>>>
>>>> I've updated cygwin-pkg-maint and made the appropriate adjustment.
>>>>
>>>> There still seems to be a problem with the form of the version number
>>>> you've
>>>> chosen, however.
>>> Yes, calm complains about
>>>
>>> '-' in version
>>>
>>> but 36-1 is the version format used upstream. Do I need to convert it?
>>
>> Looking at http://cldr.unicode.org/index/download, I see it called 36.1
> Right. The download files are provided at https://github.com/unicode-org/cldr
> where you can see release-36-1.
>>
>> The fact that the upstream filename contains '36-1' alone doesn't seem
>> sufficient to grant an exception.
> I think I'll put something like REPOVER=${VERSION//./-} into the cygport file
> for the download then.
>
>>>> I am not quite clear how unicode-cldr replaces
>>>> unicode-cldr-emoji-annotation, if we have anything which requires it to
>>>> build, since it doesn't appear to provide the .pc file that did.
>>> Please elaborate. I do not see any .pc file in the previous package.
>>> The new package include /usr/share/unicode/cldr/common/annotations (which
>>> the
>>> previous one provided solely) and other subdirectories of
>>> /usr/share/unicode/cldr/common.
>>
>> Maybe I am mistaken, but looking at the filelists in
>> https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html,
>> package unicode-cldr-emoji-annotation contains
>> /usr/share/pkgconfig/cldr-emoji-annotation.pc
> I wasn't aware of that. Not sure, though, what it's good for. I'd prefer to go
> without it unless it's missed by someone.
It's used mainly for X Window and utility builds with CLDR, and it would be
better and easier just to keep it around with an updated version, if not in the
original upstream package.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
Re: cygport upload
Am 27.03.2020 um 17:27 schrieb Jon Turney:
On 27/03/2020 16:15, Thomas Wolff wrote:
Am 27.03.2020 um 16:41 schrieb Jon Turney:
On 27/03/2020 14:35, Thomas Wolff wrote:
Am 27.03.2020 um 13:21 schrieb Jon Turney:
On 27/03/2020 10:17, Thomas Wolff wrote:
How does cygport upload work?
I previously uploaded with sftp but cygport apparently runs lftp
and it asks me for a password.
This just seems to be a thing lftp does.
If the key isn't coming from ssh-agent, it always asks for a
passphrase. If the key doesn't have one, you can just hit enter
(or type anything).
OK, works. Can lftp or cygport be configured so that lftp does not
ask for a password? Or to use sftp instead?
I don't know of any configuration for lftp to turn off that
behaviour (which is arguably a defect in lftp), but that's probably
something you could investigate for yourself.
I am not sure why lftp is used instead of sftp, possibly it is
insufficiently scriptable to do what cygport wants to do.
Uploading the two Unicode packages, I got this response:
ERROR: package '/sourceware/cygwin-staging/home/Thomas
Wolff/noarch/release/unicode-cldr' is not in the package list
ERROR: package '/sourceware/cygwin-staging/home/Thomas
Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is
not in the package list
SUMMARY: 2 ERROR(s)
Ah, right.
I've updated cygwin-pkg-maint and made the appropriate adjustment.
There still seems to be a problem with the form of the version
number you've chosen, however.
Yes, calm complains about
'-' in version
but 36-1 is the version format used upstream. Do I need to convert it?
Looking at http://cldr.unicode.org/index/download, I see it called 36.1
Right. The download files are provided at
https://github.com/unicode-org/cldr where you can see release-36-1.
The fact that the upstream filename contains '36-1' alone doesn't seem
sufficient to grant an exception.
I think I'll put something like REPOVER=${VERSION//./-} into the cygport
file for the download then.
I am not quite clear how unicode-cldr replaces
unicode-cldr-emoji-annotation, if we have anything which requires it
to build, since it doesn't appear to provide the .pc file that did.
Please elaborate. I do not see any .pc file in the previous package.
The new package include /usr/share/unicode/cldr/common/annotations
(which the previous one provided solely) and other subdirectories of
/usr/share/unicode/cldr/common.
Maybe I am mistaken, but looking at the filelists in
https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html,
package unicode-cldr-emoji-annotation contains
/usr/share/pkgconfig/cldr-emoji-annotation.pc
I wasn't aware of that. Not sure, though, what it's good for. I'd prefer
to go without it unless it's missed by someone.
Thomas
Re: cygport upload
On 27/03/2020 16:15, Thomas Wolff wrote: Am 27.03.2020 um 16:41 schrieb Jon Turney: On 27/03/2020 14:35, Thomas Wolff wrote: Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? I don't know of any configuration for lftp to turn off that behaviour (which is arguably a defect in lftp), but that's probably something you could investigate for yourself. I am not sure why lftp is used instead of sftp, possibly it is insufficiently scriptable to do what cygport wants to do. Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s) Ah, right. I've updated cygwin-pkg-maint and made the appropriate adjustment. There still seems to be a problem with the form of the version number you've chosen, however. Yes, calm complains about '-' in version but 36-1 is the version format used upstream. Do I need to convert it? Looking at http://cldr.unicode.org/index/download, I see it called 36.1 The fact that the upstream filename contains '36-1' alone doesn't seem sufficient to grant an exception. I am not quite clear how unicode-cldr replaces unicode-cldr-emoji-annotation, if we have anything which requires it to build, since it doesn't appear to provide the .pc file that did. Please elaborate. I do not see any .pc file in the previous package. The new package include /usr/share/unicode/cldr/common/annotations (which the previous one provided solely) and other subdirectories of /usr/share/unicode/cldr/common. Maybe I am mistaken, but looking at the filelists in https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html, package unicode-cldr-emoji-annotation contains /usr/share/pkgconfig/cldr-emoji-annotation.pc
Re: cygport upload
Am 27.03.2020 um 16:41 schrieb Jon Turney: On 27/03/2020 14:35, Thomas Wolff wrote: Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? I don't know of any configuration for lftp to turn off that behaviour (which is arguably a defect in lftp), but that's probably something you could investigate for yourself. I am not sure why lftp is used instead of sftp, possibly it is insufficiently scriptable to do what cygport wants to do. Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s) Ah, right. I've updated cygwin-pkg-maint and made the appropriate adjustment. There still seems to be a problem with the form of the version number you've chosen, however. Yes, calm complains about '-' in version but 36-1 is the version format used upstream. Do I need to convert it? I am not quite clear how unicode-cldr replaces unicode-cldr-emoji-annotation, if we have anything which requires it to build, since it doesn't appear to provide the .pc file that did. Please elaborate. I do not see any .pc file in the previous package. The new package include /usr/share/unicode/cldr/common/annotations (which the previous one provided solely) and other subdirectories of /usr/share/unicode/cldr/common. Thomas
Re: cygport upload
On 27/03/2020 14:35, Thomas Wolff wrote: Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? I don't know of any configuration for lftp to turn off that behaviour (which is arguably a defect in lftp), but that's probably something you could investigate for yourself. I am not sure why lftp is used instead of sftp, possibly it is insufficiently scriptable to do what cygport wants to do. Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s) Ah, right. I've updated cygwin-pkg-maint and made the appropriate adjustment. There still seems to be a problem with the form of the version number you've chosen, however. I am not quite clear how unicode-cldr replaces unicode-cldr-emoji-annotation, if we have anything which requires it to build, since it doesn't appear to provide the .pc file that did.
Re: cygport upload
Am 27.03.2020 um 13:21 schrieb Jon Turney: On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything). OK, works. Can lftp or cygport be configured so that lftp does not ask for a password? Or to use sftp instead? Uploading the two Unicode packages, I got this response: ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr' is not in the package list ERROR: package '/sourceware/cygwin-staging/home/Thomas Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the package list SUMMARY: 2 ERROR(s)
Re: cygport upload
On 27/03/2020 10:17, Thomas Wolff wrote: How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. This just seems to be a thing lftp does. If the key isn't coming from ssh-agent, it always asks for a passphrase. If the key doesn't have one, you can just hit enter (or type anything).
cygport upload
How does cygport upload work? I previously uploaded with sftp but cygport apparently runs lftp and it asks me for a password. Thomas
Re: cygport upload: patch for openssh 6.8p1
On Mon, 2015-06-01 at 04:04 -0400, Andrew Schulman wrote:
A more precise regex is
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:[A-Za-z0-9+/=]{43}
I've committed this change to my upload branch at
https://github.com/andrex-e-schulman/cygport.git.
Also in that branch, I've added documentation of the fact that users will need
to connect to cygwin.com at least one time by sftp before they upload, in
order
to store the host public key in their known_hosts file, as explained in
https://cygwin.com/ml/cygwin-apps/2015-03/msg00193.html .
Thanks, merged.
--
Yaakov
Re: cygport upload: patch for openssh 6.8p1
Any thoughts on a better regex or on keeping compatibility with other
systems?
Right, OK. See the attached revised patch, which uses
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:.{44}
to detect the key fingerprint. The left side is the same as now, for pre-6.8
systems, which use MD5 without a label. The right side is for version 6.8 and
later, where the default is SHA256 with the label 'SHA256:' prepended. So
this
should cover all cases.
A more precise regex is
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:[A-Za-z0-9+/=]{43}
I've committed this change to my upload branch at
https://github.com/andrex-e-schulman/cygport.git.
Also in that branch, I've added documentation of the fact that users will need
to connect to cygwin.com at least one time by sftp before they upload, in order
to store the host public key in their known_hosts file, as explained in
https://cygwin.com/ml/cygwin-apps/2015-03/msg00193.html .
Andrew
Re: cygport upload: patch for openssh 6.8p1
On Sun, 2015-05-24 at 12:32 -0400, Andrew Schulman wrote:
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256:lvRrjAXmEhzDp5kQqzelsei8s5hXJ+zLaqJ2yiGXmYc
This breaks the current logic for detecting key fingerprints in cygport's
lib/pkg_upload.cygpart. The attached patch fixes the problem. (You might
know
a more precise regex for the base64-encoded hash value than I do. I
couldn't
find any documentation of it anywhere, and just settled for
SHA256:.{44}
There's another problem: this is new to 6.8; any out-of-date Cygwin
systems, or even current RHEL or Fedora 21 systems, won't have this, nor
do they support the -E flag which could be used to specify md5.
Any thoughts on a better regex or on keeping compatibility with other
systems?
Right, OK. See the attached revised patch, which uses
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:.{44}
to detect the key fingerprint. The left side is the same as now, for pre-6.8
systems, which use MD5 without a label. The right side is for version 6.8 and
later, where the default is SHA256 with the label 'SHA256:' prepended. So this
should cover all cases.
Andrew
pkg_upload_key_fingerprint.patch
Description: Binary data
Re: cygport upload: patch for openssh 6.8p1
On Sun, 2015-05-24 at 12:32 -0400, Andrew Schulman wrote:
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256:lvRrjAXmEhzDp5kQqzelsei8s5hXJ+zLaqJ2yiGXmYc
This breaks the current logic for detecting key fingerprints in cygport's
lib/pkg_upload.cygpart. The attached patch fixes the problem. (You might
know
a more precise regex for the base64-encoded hash value than I do. I couldn't
find any documentation of it anywhere, and just settled for
SHA256:.{44}
There's another problem: this is new to 6.8; any out-of-date Cygwin
systems, or even current RHEL or Fedora 21 systems, won't have this, nor
do they support the -E flag which could be used to specify md5.
Any thoughts on a better regex or on keeping compatibility with other
systems?
--
Yaakov
cygport upload: patch for openssh 6.8p1
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256:lvRrjAXmEhzDp5kQqzelsei8s5hXJ+zLaqJ2yiGXmYc
This breaks the current logic for detecting key fingerprints in cygport's
lib/pkg_upload.cygpart. The attached patch fixes the problem. (You might know
a more precise regex for the base64-encoded hash value than I do. I couldn't
find any documentation of it anywhere, and just settled for
SHA256:.{44}
)
Andrew
pkg_upload_key_fingerprint.patch
Description: Binary data
[RFC] cygport upload
I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. I'm still undecided on $arch/!ready vs. $arch/release/$package/!ready. Thoughts? -- Yaakov
Re: [RFC] cygport upload
On 2/12/2015 11:42 PM, Yaakov Selkowitz wrote: I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. I'm still undecided on $arch/!ready vs. $arch/release/$package/!ready. Thoughts? $arch/release/$package/!ready should avoid the unlikely case when upload of a second package is running but a first package is in transfer from stage to main area. -- Yaakov Marco
Re: [RFC] cygport upload
On 2/12/2015 11:42 PM, Yaakov Selkowitz wrote: I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. I'm still undecided on $arch/!ready vs. $arch/release/$package/!ready. Thoughts? $arch/release/$package/!ready should avoid the unlikely case when upload of a second package is running but a first package is in transfer from stage to main area. I agree, in case that's not obvious. Andrew
Re: [RFC] cygport upload
I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. FWIW, I've been using it to upload my packages since the last update on Jan. 17, and before that too, with no problems. I always keep my ssh keys loaded in a running ssh-agent, so I've tested that case pretty well. I think it would be most useful to test the other cases: ssh-agent running but key not loaded; ssh-agent not running; private keys encrypted/unencrypted. Andrew
Re: [RFC] cygport upload
On Thu, 2015-02-12 at 20:23 -0500, Andrew Schulman wrote: I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. FWIW, I've been using it to upload my packages since the last update on Jan. 17, and before that too, with no problems. I always keep my ssh keys loaded in a running ssh-agent, so I've tested that case pretty well. I think it would be most useful to test the other cases: ssh-agent running but key not loaded; ssh-agent not running; private keys encrypted/unencrypted. I am testing it both with an ssh-agent (gnome-keyring) and without, and my keys are encrypted. -- Yaakov
Re: cygport upload command?
On Oct 14 01:12, Andrew Schulman wrote: On 2014-07-07 20:14, Andrew Schulman wrote: Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. I'm a bit busy at the moment, but it sounds like a good idea to me. I have an implementation of this ready at https://github.com/andrex-e-schulman/cygport. What's new compared to upstream git: * New upload command (cygport up). Minor nit: This should be `cygport upload' to be in line with the other cygport commands. Alternatively, cygport could introduce a two-letter abbreviation scheme, for instance: cygport download - cygport dl or (rcs-like) co cygport prep - cygport pr cygport build - cygport mk or cc cygport install - cygport in cygport package - cygport pk cygport upload- cygport up or (rcs-like) ci Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgphhE_wYKs9K.pgp Description: PGP signature
Re: cygport upload command?
Minor nit: This should be `cygport upload' to be in line with the other cygport commands. Alternatively, cygport could introduce a two-letter abbreviation scheme, for instance: cygport download- cygport dl or (rcs-like) co cygport prep- cygport pr cygport build - cygport mk or cc cygport install - cygport in cygport package - cygport pk cygport upload - cygport up or (rcs-like) ci I didn't say so, but yes, the command is named and described everywhere as 'cygport upload'. 'cygport up' also works. I didn't think of 'cygport ci', but that's a good idea.
Re: cygport upload command?
On 2014-07-07 20:14, Andrew Schulman wrote: Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. I'm a bit busy at the moment, but it sounds like a good idea to me. I have an implementation of this ready at https://github.com/andrex-e-schulman/cygport. What's new compared to upstream git: * New upload command (cygport up). * Documented upload command in manuals and README. * Currently only one upload client, lftp, is supported. I've tested the implementation a good bit, and it works well as long as there's no trouble, i.e. lftp can connect to sftp://cygwin.com. If it can't connect, then you get told max-retries exceeded and Upload failed, which doesn't help at all to figure out why the upload failed (can't connect, can't authenticate, ...). Unfortunately, it's hard to make lftp give much better information. * Simple API for adding support for other upload clients. The API is described in pkg_upload.cygpart. I'm planning to add support for sftp and rsync soon, and I hope it will be easier to get useful failure information from them if the upload fails. Please let me know if you have any comments or would like to see any changes. Andrew
Re: cygport upload command?
On 2014-07-07 20:14, Andrew Schulman wrote: Using cygport, I think that packaging has become quite easy now. That's always been my goal. :-) Except for one thing: the upload step. Maintainers still have to go through the procedure at https://sourceware.org/cygwin-apps/package-upload.html. Although it's easier than the old manual upload process, it's still a little tedious and error-prone. Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. I'm a bit busy at the moment, but it sounds like a good idea to me. If you don't have the time or interest to add an upload command yourself, would you consider a patch? I've spent some time looking through cygport code, and I might have time to give it a try, or maybe someone else would. PTC. Yaakov
cygport upload command?
Using cygport, I think that packaging has become quite easy now. At least, once the cygport script is built and working, updating a package to a new release is as easy as updating the version number in the cygport script, then running 'cygport ... download all'. Except for one thing: the upload step. Maintainers still have to go through the procedure at https://sourceware.org/cygwin-apps/package-upload.html. Although it's easier than the old manual upload process, it's still a little tedious and error-prone. Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. If you don't have the time or interest to add an upload command yourself, would you consider a patch? I've spent some time looking through cygport code, and I might have time to give it a try, or maybe someone else would. Andrew
Re: cygport upload command?
On Mon, Jul 07, 2014 at 09:14:29PM -0400, Andrew Schulman wrote:
Using cygport, I think that packaging has become quite easy now. At least,
once the cygport script is built and working, updating a package to a new
release is as easy as updating the version number in the cygport script,
then running 'cygport ... download all'.
Except for one thing: the upload step. Maintainers still have to go
through the procedure at
https://sourceware.org/cygwin-apps/package-upload.html. Although it's
easier than the old manual upload process, it's still a little tedious and
error-prone.
Yaakov, would you consider adding an 'upload' command to cygport, that
would handle the uploading details? That would take away the last bit of
manual work in a routine package update.
If you don't have the time or interest to add an upload command yourself,
would you consider a patch? I've spent some time looking through cygport
code, and I might have time to give it a try, or maybe someone else would.
FWIW, this is the script that I use. Obviously the path to the upload
directory would have to be changed.
cgf
#!/usr/bin/perl
use strict;
use Getopt::Long;
my $arch = 'all';
GetOptions('a|arch:s'=\$arch);
use constant {
FTP = '/usr/bin/lftp'
};
my @arch = ();
if ($arch eq 'all') {
@arch = ('x86', 'x86_64');
} else {
@arch = $arch;
}
my $exit = 0;
for $arch (@arch) {
# ftp -c 'connect sftp://cygwin:@cygwin.com/; cd x86/release; mirror -eRN2
mutt; put /dev/null -o !ready'
chdir /netrel/uploads/$arch or die $0: couldn't cd to
/netrel/uploads/$arch - $!\n;
for my $p (@ARGV) {
print Uploading $p($arch)...\n;
my $res = system FTP, '-c', connect sftp://cygwin:\@cygwin.com/; cd
$arch/release; mirror -eR $p; put /dev/null -o !ready;
$exit ||= $res;
if (!$res) {
print done\n;
} else {
warn $0: $p upload failed\n if $res;
}
}
}
exit $exit;
