Re: Putting packages up for adoption
Am 27.03.2020 um 21:52 schrieb Yaakov Selkowitz:
On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
The plan looks fine. Thanks for it
unfortunately I see unexpected segfault on the testsuite
0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)
for both 2.7.17 and your original 2.7.16.
as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.
3.8.2 seems to stall later in the test, so it is another issue.
In my experience, particularly on Cygwin, the first and most common
cause of testsuite errors are in the tests themselves. While
eventually fixing these would certainly be welcome, I wouldn't block
progress thereon. How does the saying go, "don't let perfection be the
enemy of the good"?
--
Yaakov
usually I follow the same rules, but a bit of investigation
will be needed just to be sure.
Do you know a simple way to go on with the test or skip one ?
particular useful for 3.8.2
6:14:06 load avg: 0.31 running: test_subprocess (6 hour 13 min),
test_asyncio (6 hour 11 min), test_asyncore (6 hour 10 min), test_ssl (6
hour 13 min)
6:14:36 load avg: 0.30 running: test_subprocess (6 hour 13 min),
test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6
hour 14 min)
6:15:06 load avg: 0.41 running: test_subprocess (6 hour 14 min),
test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6
hour 14 min)
Re: Putting packages up for adoption
On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
> > On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> > > Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > I would suggest the following:
> >
> > * python2-2.7.z continues to provide all '2' symlinks.
> >
> > * python38 be updated to 3.8.2, and 3.8 be designated the next default
> > 'python3' version (with the '3' symlinks continued to be kept
> > separate), and adjust python-wheel.cygclass accordingly.
> >
> > * Similarly, a separate package (in Fedora it's called 'python-
> > unversioned-command') provide unversioned symlinks, pointing to 2.7 for
> > now (for compatibility).
> >
> > * Anything currently dependent on 'python' or 'python2' should either
> > be dropped if no longer needed, switched to 3 is possible, otherwise
> > rebuilt.
> >
> > * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
> > only build those modules that are actually needed by other things by
> > specifying "all".
> >
> > * Once that's done, look at what's still depending on /usr/bin/python
> > ('python-unversioned-command'), and based on that decide when that can
> > be changed to point to python3.
> >
> > HTH,
> >
> > --
> > Yaakov
> >
>
> The plan looks fine. Thanks for it
>
> unfortunately I see unexpected segfault on the testsuite
>
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
>
> for both 2.7.17 and your original 2.7.16.
>
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
>
> 3.8.2 seems to stall later in the test, so it is another issue.
In my experience, particularly on Cygwin, the first and most common
cause of testsuite errors are in the tests themselves. While
eventually fixing these would certainly be welcome, I wouldn't block
progress thereon. How does the saying go, "don't let perfection be the
enemy of the good"?
--
Yaakov
Re: Putting packages up for adoption
On 27/03/2020 19:10, Yaakov Selkowitz wrote: > On Fri, 2020-03-27 at 18:32 +, Hamish McIntyre-Bhatty via Cygwin- > apps wrote: >> Out of interest, are you also adopting the modules for Python 2 and 3? >> If not, or if you're not keen to adopt all of them, there are a few I'd >> like to adopt (python-wx, python-bs4, and python-pip). > At a minimum, it would probably be easier to coordinate new versions of > Python if one person maintained all the Python versions together with > at least python-setuptools, python-wheel, and python-pip, as those are > the most basic requirements for building Python extensions. > > Someone else has expressed interest in python-wx; perhaps you can work > together on it. > > -- > Yaakov That makes sense. I must have missed that. Who was it? I'm also interested in doing pylint potentially, any reason why that was orphaned before? Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Putting packages up for adoption
On Fri, 2020-03-27 at 18:32 +, Hamish McIntyre-Bhatty via Cygwin- apps wrote: > Out of interest, are you also adopting the modules for Python 2 and 3? > If not, or if you're not keen to adopt all of them, there are a few I'd > like to adopt (python-wx, python-bs4, and python-pip). At a minimum, it would probably be easier to coordinate new versions of Python if one person maintained all the Python versions together with at least python-setuptools, python-wheel, and python-pip, as those are the most basic requirements for building Python extensions. Someone else has expressed interest in python-wx; perhaps you can work together on it. -- Yaakov
Re: Putting packages up for adoption
On 27/03/2020 17:53, Marco Atzeri via Cygwin-apps wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
>> On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
>>> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
>
>> I would suggest the following:
>>
>> * python2-2.7.z continues to provide all '2' symlinks.
>>
>> * python38 be updated to 3.8.2, and 3.8 be designated the next default
>> 'python3' version (with the '3' symlinks continued to be kept
>> separate), and adjust python-wheel.cygclass accordingly.
>>
>> * Similarly, a separate package (in Fedora it's called 'python-
>> unversioned-command') provide unversioned symlinks, pointing to 2.7 for
>> now (for compatibility).
>>
>> * Anything currently dependent on 'python' or 'python2' should either
>> be dropped if no longer needed, switched to 3 is possible, otherwise
>> rebuilt.
>>
>> * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
>> only build those modules that are actually needed by other things by
>> specifying "all".
>>
>> * Once that's done, look at what's still depending on /usr/bin/python
>> ('python-unversioned-command'), and based on that decide when that can
>> be changed to point to python3.
>>
>> HTH,
>>
>> --
>> Yaakov
>>
>
> The plan looks fine. Thanks for it
>
> unfortunately I see unexpected segfault on the testsuite
>
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle
> skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
>
> for both 2.7.17 and your original 2.7.16.
>
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
>
> 3.8.2 seems to stall later in the test, so it is another issue.
>
> Regards
> Marco
Marco,
Out of interest, are you also adopting the modules for Python 2 and 3?
If not, or if you're not keen to adopt all of them, there are a few I'd
like to adopt (python-wx, python-bs4, and python-pip).
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
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: Putting packages up for adoption
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
The plan looks fine. Thanks for it
unfortunately I see unexpected segfault on the testsuite
0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)
for both 2.7.17 and your original 2.7.16.
as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.
3.8.2 seems to stall later in the test, so it is another issue.
Regards
Marco
Re: Putting packages up for adoption
Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
I would suggest the following:
* python2-2.7.z continues to provide all '2' symlinks.
* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.
* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).
* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.
* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".
* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.
HTH,
--
Yaakov
The plan looks fine. Thanks for it
unfortunately I see unexpected segfault on the testsuite
0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)
for both 2.7.17 and your original 2.7.16.
as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.
3.8.2 seems to stall later in the test, so it is another issue.
Regards
Marco
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: Requesting a new version of GNU ddrescue
So, I went ahead and made a package, and it's available at https://www.hamishmb.com/files/cygwin-temp/. Does anyone mind checking for me that I've done this right, just so I can get the technique down before I try to package anything complicated? Hamish On 25/03/2020 11:53, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Hello, > > I would like to request that GNU ddrescue 1.25 be packages for Cygwin. I > would be happy to produce this package if that would be appropriate - > I'd like to start with a simpler package before moving on to wxwidgets > and wxpython. > > Hamish > 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
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
