Re: [ITA from Yaakov] python-wx
On 17.05.2020 21:37, Hamish McIntyre-Bhatty via Cygwin-apps wrote: On 15/05/2020 09:10, Hamish McIntyre-Bhatty via Cygwin-apps wrote: On 15/05/2020 00:47, Yaakov Selkowitz wrote: This looks fine. I'm glad. What do I do next? Do I need to upload and mark as a testing package or similar? Seeing as I have no need to rebuild wxWidgets, I guess that can stay under your maintainership until an update is needed, at which point I'll be happy to pick it up. Let's discuss it then. -- Yaakov If you don't want maintainership of it I'm happy to take it, but I won't push an update until we need one. The new version of wxPython needs wxWidgets 3.1.x, so I'll probably be packaging that soonish anyway, but I'll work on wxPython 4.0.7 first because it's closer to what's already present in Cygwin. Hamish NB: Tested the SSH key and it seems to be working just fine. Should I upload this as a testing package or go straight for a normal package? I'm not sure how announcements work for testing packages. Hamish same as normal Announce, just use the tag "Test" https://sourceware.org/pipermail/cygwin-announce/2020-April/009511.html
Re: [ITA from Yaakov] python-wx
On 15/05/2020 09:10, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > On 15/05/2020 00:47, Yaakov Selkowitz wrote: >> This looks fine. > I'm glad. What do I do next? Do I need to upload and mark as a testing > package or similar? >>> Seeing as I have no need to rebuild wxWidgets, I guess that can stay >>> under your maintainership until an update is needed, at which point >>> I'll be happy to pick it up. >> Let's discuss it then. >> >> -- >> Yaakov >> > If you don't want maintainership of it I'm happy to take it, but I won't > push an update until we need one. > > The new version of wxPython needs wxWidgets 3.1.x, so I'll probably be > packaging that soonish anyway, but I'll work on wxPython 4.0.7 first > because it's closer to what's already present in Cygwin. > > Hamish > NB: Tested the SSH key and it seems to be working just fine. Should I upload this as a testing package or go straight for a normal package? I'm not sure how announcements work for testing packages. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: SSH key for Hamish McIntyre-Bhatty
On 14/05/2020 18:11, Hamish McIntyre-Bhatty via Cygwin-apps wrote: Name: Hamish McIntyre-Bhatty BEGIN SSH2 PUBLIC KEY Done.
Re: cygport development
Thank you for the feedback.
This patch is clearly not limited to the protection of data, as it
quotes variables that could in no way contain a space or have anything
to do with file paths.
Could you please point me to which variables are unrelated to files.
AFAIK i quoted files and arguments, which can all contain whitespace.
For example I did quote ${unpack_file_path}, but not ${unpack_cmd}.
As mentioned multiple times, using filenames
ore directories with spaces is asking for trouble, and I have no
interest in trying to support such a case.
The first commit makes sure that no information is lost while processing
file with spaces or other characters that cause globbing. This prevents
writing or modifying the wrong files, which is what happened to me.
The second commit add exit in case `cd` fails, which prevents other
errors afterwards.
Those modification do not add support for path with whitespace, as I was
still unable to compile the software, they did however prevent cygport
to delete unrelated data (or create data in the wrong location).
I'm willing to consider a
*limited* patch that makes sure that cygport doesn't do something it
shouldn't in that case, but that's about it.
Also because if the underlying tool like `make` does not support spaces,
it has no benefit.
The most minimal patch I can imagine is exiting if `cd` fails (just the
second commit).
Would you accept that?
But please also consider my other arguments.
Yaakov
PS:
A "nice" side-effect to quoting most variables that could contain white
space is that static-analyzers like shellcheck will emit less
diagnostic, making it easier to discover potential errors.
Re: cygport ... install starts in cwd but ... all does not
On 17.05.2020 08:45, Brian Inglis wrote:
When rerunning a cygport build with "cygport *.cygport all" after fixing up
problems stage by stage, "doicon $NAME.png" at the start of src_install, before
"cd/pushd ${B}" fails with fatal message "*** ERROR: file $NAME.png does not
exist", whereas rerunning "cygport *.cygport install" succeeds without any
messages.
Even changing cd to pushd, and adding popd at the end of each src_... function,
does not solve the issue.
The package does not include an icon, so I downloaded something suitable to the
same package directory as the $NAME.cygport and *.patch PATCH_URI files.
Any alternative approaches that anyone can suggest might work?
can we see the file ?
May be is a banal issue that you are oversighting
cygport ... install starts in cwd but ... all does not
When rerunning a cygport build with "cygport *.cygport all" after fixing up
problems stage by stage, "doicon $NAME.png" at the start of src_install, before
"cd/pushd ${B}" fails with fatal message "*** ERROR: file $NAME.png does not
exist", whereas rerunning "cygport *.cygport install" succeeds without any
messages.
Even changing cd to pushd, and adding popd at the end of each src_... function,
does not solve the issue.
The package does not include an icon, so I downloaded something suitable to the
same package directory as the $NAME.cygport and *.patch PATCH_URI files.
Any alternative approaches that anyone can suggest might work?
--
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.]
