Re: perl 5.32
On 12/9/2020 3:37 PM, Achim Gratz wrote: I'll see to get 5.32.0 out for you as a test release (let me know which distributions you need in addtion to perl itself). Thanks. Here's the BUILD_REQUIRES: perl-Business-ISBN perl-Business-ISMN perl-Business-ISSN perl-Class-Accessor perl-Config-AutoConf perl-Data-Compare perl-Data-Dump perl-Data-Uniqid perl-DateTime-Calendar-Julian perl-DateTime-Format-Builder perl-Encode-EUCJPASCII perl-Encode-HanExtra perl-Encode-JIS2K perl-ExtUtils-LibBuilder perl-File-Slurper perl-File-Which perl-IO-String perl-IPC-Cmd perl-IPC-Run3 perl-LWP-Protocol-https perl-Lingua-Translit perl-List-AllUtils perl-List-MoreUtils perl-List-MoreUtils-XS perl-Log-Log4perl perl-Module-Build perl-Mozilla-CA perl-Parse-RecDescent perl-PerlIO-utf8_strict perl-Regexp-Common perl-Sort-Key perl-Test-Differences perl-Test-Simple perl-Text-BibTeX perl-Text-CSV perl-Text-CSV_XS perl-Text-Roman perl-URI perl-Unicode-Collate perl-Unicode-LineBreak perl-Unicode-Normalize perl-XML-LibXML perl-XML-LibXML-Simple perl-XML-LibXSLT perl-XML-Writer perl-autovivification perl-libwww-perl Whether we patch Biber back to 5.30 compatibility or wait for the 5.32.1 update for Biber remains to be decided later on I'd say. Sounds good to me. Ken
Re: [PATCH cygport] Update xorg.cygclass URLs
On Wed, 09 Dec 2020 21:10:18 +0900, Lemures Lemniscati
> On Mon, 07 Dec 2020 22:52:28 +0900, Lemures Lemniscati
> > On Wed, 02 Dec 2020 13:38:32 -0500, Yaakov Selkowitz via Cygwin-apps
> > > On Tue, 2020-12-01 at 15:47 +, Jon Turney wrote:
> > > > Update xorg.cygclass URLs since xorg.freedesktop.org now permanently
> > > > redirects to www.x.org
> > > > ---
> > > > cygclass/xorg.cygclass | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > Thanks, comments inline.
> > >
> > > > diff --git a/cygclass/xorg.cygclass b/cygclass/xorg.cygclass
> > > > index 47686e8..1665439 100644
> > > > --- a/cygclass/xorg.cygclass
> > > > +++ b/cygclass/xorg.cygclass
> > > > @@ -141,13 +141,13 @@ SUMMARY="X.Org ${ORIG_PN} component"
> > > > #
> > > > #o* xorg.cygclass/HOMEPAGE (xorg)
> > > > # DEFINITION
> > > > -HOMEPAGE="http://xorg.freedesktop.org/;
> > > > +HOMEPAGE="https://www.x.org/;
> > >
> > > OK.
> > >
> > > > #
> > > > #o* xorg.cygclass/SRC_URI (xorg)
> > > > # DESCRIPTION
> > > > # Download location of the release tarball.
> > > > #
> > > > -SRC_URI="http://xorg.freedesktop.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
> > > > +SRC_URI="http://www.x.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
> > > ^^^
> > > https://
> > >
> > > With that change, please proceed.
> > >
> > > In fact, there are probably a bunch of other http: which could be
> > > converted to https: at this point. I would suggest anyone who does
> > > that (in separate commit(s)) should get a gold star.
> > >
> >
> > Updated a few of them.
> >
> > Lem
>
> More patches.
>
> Lem
More patches.
Lem
0012-Update-URLs-in-cygclass-berkdb.cygclass.patch
Description: Binary data
0013-Update-URLs-in-cygclass-bzr.cygclass.patch
Description: Binary data
0014-Update-a-URL-in-cygclass-clang.cygclass.patch
Description: Binary data
0015-Update-URLs-in-cygclass-claws-mail.cygclass.patch
Description: Binary data
Re: [ITA] wxWidgets3.0
On 25/11/2020 10:02, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> Okay, so attached is my latest cygport file. I'm still building for >> 32-bit, so I'll upload and link to the new packages tomorrow. >> >> Changes: >> >> - Split BUILD_REQUIRES across two lines for definitely build time and >> probably only runtime deps. >> >> - Use system regex library explicitly. >> >> - Removed obsolete --without-gnomeprint option. >> >> - Use gnomevfs (old bug no longer seems to apply). >> >> I tried using the STL, but it results in libraries that don't work as: >> >> #1: the wxwidgets demos either segfault instantly or just exit instantly. >> >> #2: wxpython no longer works and returns the No such process error above. >> >> Hamish > Okay, cygport file attached again and the new packages can be had from > https://www.hamishmb.com/files/cygwin-temp/ as before. > > Hamish *bump* Would be good to get this verified so I can get on to other things for Cygwin. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: perl 5.32
Ken Brown via Cygwin-apps writes: > I've just followed up with the biber maintainer, with a copy to you. Thanks. I've checked again, there was talk about getting 5.32.1 going end of November but nothing happened since then (on the mailing list anyway). I think it's unlikely to get released this year since Big Sur has created a bunch of problems that they'll probably want to get on top of before collecting the backporting patches. I'll see to get 5.32.0 out for you as a test release (let me know which distributions you need in addtion to perl itself). Whether we patch Biber back to 5.30 compatibility or wait for the 5.32.1 update for Biber remains to be decided later on I'd say. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
[PATCH v2] cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn
This allows native processes to get Windows-default error handling behavior (such as invoking the registered JIT debugger). --- winsup/cygwin/spawn.cc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc index 92d190d1a..83b216f52 100644 --- a/winsup/cygwin/spawn.cc +++ b/winsup/cygwin/spawn.cc @@ -431,6 +431,13 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv, c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT; + /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they +get the default error mode instead of inheriting the mode Cygwin +uses. This allows things like Windows Error Reporting/JIT debugging +to work with processes launched from a Cygwin shell. */ + if (!real_path.iscygexec ()) + c_flags |= CREATE_DEFAULT_ERROR_MODE; + /* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround issues with the "Program Compatibility Assistant (PCA) Service". For some reason, when starting long running sessions from mintty(*), -- 2.29.2.windows.3
Re: perl 5.32
Achim Gratz writes: > I'd still be interested in what upstream thinks they get from 5.32 that > absolutely can't be had from 5.30. It's even more saddening or hilarious (depending on where you are standing) than I thought. The whole thing was developed while still being compatible with 5.30 and in preparation for the release they changed around a bunch of configs that have _nothing_ to do with the functionality to make 5.32 the requirement. 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: perl 5.32
Ken Brown via Cygwin-apps writes: > Yes, unfortunately it really is a requirement. But I'd be perfectly > happy to just install 5.32 locally and use it for building the > upstream biber (which is distributed as an archive created by > PAR::Packer). I can delay releasing Cygwin's biber package until > you're ready to update perl. I'd still be interested in what upstream thinks they get from 5.32 that absolutely can't be had from 5.30. > Would it be easy for you to send me a cygport file that I could use > for building my own perl 5.32? I'll have to check which patches to carry and pull them up to the new base. The other thing about 5.32 is that I would really like to wait until 5.32.1 is out and there is no date set for when that is going to happen. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re:
On 12/9/20 6:15 AM, chaparay01--- via Cygwin wrote: Who the fuck are you ! You been writing my husband -- HAHAHAHA... Oh yes... we've been sending him the acronym list and telling him all about posix coding and shell scripting!! THE HORRORS! LoL... -Ben -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH cygport] Update xorg.cygclass URLs
On Tue, 08 Dec 2020 20:17:43 +0100, Achim Gratz > Lemures Lemniscati via Cygwin-apps writes: > > Since it seems that 'Prefix' is different from 'Portage', > > I'm not sure that it's ok to replace only the citation. > > I think Prefix builds on Portage or rather is an extension on it, but > Michael Haubenwallner should be able to tell you more if you are > interested. So if Prefix does work on Cygwin, Portage certainly should > as well. Portage is the package manager of Gentoo and Gentoo builds > everything you install from source, on the system you are currently on. > AFAUI, Prefix additionally makes it possible to build into a foreign > installation and/or hosted by something other than Gentoo. So runnning > Prefix on Cygwin will enable you to use Portage packages on Cygwin, but > they will be built locally like on Gentoo by default. > > > Regards, > Achim. Thank you. And this is a propsal for modification of README in cygport: * Drop a URL to HOWTO Gentoo on Cygwin * Add some comments and a URL to Gentoo Prefix on Cygwin Regards, Lem diff --git a/README b/README index 3f5bf02..a166579 100644 --- a/README +++ b/README @@ -86,8 +86,11 @@ because: 4) Most importantly, setup.exe provides a GUI which makes installation easier for the uninitiated. -(It should be noted that there have been renewed attempts to run Portage -on Cygwin[3], and this was even recently ITP'd and rejected[4].) +(It should be noted that, there were renewed attempts to run Portage +on Cygwin, and this was ITP'd and rejected[3] in 2006. And, the project +"Gentoo on Cygwin", which contains Portage, is unmaintained as of 2008. +But, there is another project "Gentoo Prefix on Cygwin", as of 2020. +It's a try to run well-maintained "Gentoo Prefix" sources on Cygwin[4].) 2. CONCEPT @@ -245,6 +248,6 @@ Discussion on cygport should occur on the Cygwin-apps list [1] https://www.cygwin.com/ [2] https://cygwin.com/setup.html#package_contents -[3] http://gentoo-wiki.com/HOWTO_Gentoo_on_Cygwin (no longer available) -[4] https://sourceware.org/legacy-ml/cygwin-apps/2006-03/msg0.html +[3] https://sourceware.org/legacy-ml/cygwin-apps/2006-03/msg0.html +[4] https://wiki.gentoo.org/wiki/Prefix/Cygwin [5] https://cygwin.com/git-cygwin-packages/ 0011-Modify-README-Add-some-comments-about-Gentoo.patch Description: Binary data
[no subject]
Who the fuck are you ! You been writing my husband -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH cygport] Update xorg.cygclass URLs
On Mon, 07 Dec 2020 22:52:28 +0900, Lemures Lemniscati
> On Wed, 02 Dec 2020 13:38:32 -0500, Yaakov Selkowitz via Cygwin-apps
> > On Tue, 2020-12-01 at 15:47 +, Jon Turney wrote:
> > > Update xorg.cygclass URLs since xorg.freedesktop.org now permanently
> > > redirects to www.x.org
> > > ---
> > > cygclass/xorg.cygclass | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Thanks, comments inline.
> >
> > > diff --git a/cygclass/xorg.cygclass b/cygclass/xorg.cygclass
> > > index 47686e8..1665439 100644
> > > --- a/cygclass/xorg.cygclass
> > > +++ b/cygclass/xorg.cygclass
> > > @@ -141,13 +141,13 @@ SUMMARY="X.Org ${ORIG_PN} component"
> > > #
> > > #o* xorg.cygclass/HOMEPAGE (xorg)
> > > # DEFINITION
> > > -HOMEPAGE="http://xorg.freedesktop.org/;
> > > +HOMEPAGE="https://www.x.org/;
> >
> > OK.
> >
> > > #
> > > #o* xorg.cygclass/SRC_URI (xorg)
> > > # DESCRIPTION
> > > # Download location of the release tarball.
> > > #
> > > -SRC_URI="http://xorg.freedesktop.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
> > > +SRC_URI="http://www.x.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
> > ^^^
> > https://
> >
> > With that change, please proceed.
> >
> > In fact, there are probably a bunch of other http: which could be
> > converted to https: at this point. I would suggest anyone who does
> > that (in separate commit(s)) should get a gold star.
> >
>
> Updated a few of them.
>
> Lem
More patches.
Lem
0005-Update-URLs-in-cygclass-R.cygclass.patch
Description: Binary data
0006-Update-a-URL-in-cygclass-ant.cygclass.patch
Description: Binary data
0007-Update-a-URL-cygclass-apache.cygclass.patch
Description: Binary data
0008-Update-a-URL-cygclass-apache2.cygclass.patch
Description: Binary data
0009-Update-a-URL-in-cygclass-aspell-dict.cygclass.patch
Description: Binary data
0010-Update-URLs-in-cygclass-autotools.cygclass.patch
Description: Binary data
Re: [PATCH 1/1] cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn
On Dec 8 11:58, Jeremy Drake via Cygwin-patches wrote: > On Tue, 8 Dec 2020, Jon Turney wrote: > > On 07/12/2020 09:43, Corinna Vinschen wrote: > > > On Dec 4 10:35, Jeremy Drake via Cygwin-patches wrote: > > > > On Fri, 4 Dec 2020, Corinna Vinschen via Cygwin-patches wrote: > > > > > > > > > I'm not happy about a new CYGWIN option. > > > > > > > > > > Wouldn't it make sense, perhaps, to switch to > > > > > CREATE_DEFAULT_ERROR_MODE > > > > > for all non-Cygwin processes by default instead? > > > > I agree. > > > > Cygwin calls SetErrorMode(), so we need to use this flag to prevent that > > non-default behaviour being inherited by processes started with > > CreateProcess(). > > > > In that case, here's my initial, much simpler patch > [...] > - c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT; > + c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT > + | CREATE_DEFAULT_ERROR_MODE; > [...] Thanks, but the flag should only be added when starting a non-cygwin process. Checking against real_path.iscygexec() will do the job. Can you please resend this as a standard git format-patch'ed mail? Thanks, Corinna
Failure during build of Python 3.8 via cygport
Hi Marco, I was building Python locally so I can later submit a patch against it. It appears the local python.exe was built successfully, but a later step failed with: ./python.exe -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Traceback (most recent call last): File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/runpy.py", line 194, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/runpy.py", line 87, in _run_code exec(code, run_globals) File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 711, in _main() File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 699, in _main _generate_posix_vars() File "/usr/src/python38-3.8.3-1.src/python38-3.8.3-1.x86_64/src/Python-3.8.3/Lib/sysconfig.py", line 416, in _generate_posix_vars f.write(pybuilddir) UnicodeEncodeError: 'utf-8' codec can't encode characters in position 17-19: surrogates not allowed generate-posix-vars failed make: *** [Makefile:592: pybuilddir.txt] Error 1 *** ERROR: make failed I've seen UnicodeEncodeError before and searched and found how to fix it.. but hitting the issue while building Python itself seems more fraught. Is this a known issue with known fix? Thank you, ..mark
