Re: Webkitgtk maintenance
Please see: https://cygwin.com/problems.html#personal-email This applies doubly so to former maintainers. Redirecting to cygwin- apps. On Tue, 2023-09-12 at 17:11 +0200, Blandin Jean-Marie wrote: > Dear Mr Selkowitz, > > First of all, I want to apologize for the time I take from you by > writing > this email. > It's about the cygwin package I put as object of this email which has > been > orphaned for many years. > The fact is other packages depend on it : I'm used to programming in > gambas3 language and as the cygwin maintainer of this package told > me, he > cannot update his part as long as the webkitgtk package is not > recent. > For sure I can imagine the large amount of time it takes to maintain > a > cygwin package but it is the only way AFAIK to use Linux apps on > windows > without admin rights. > You seemed to step back from webkitgtk maintenance a few years ago > and I > would be very glad if you could tell a name to follow on because of > the > importance for the gambas3 community on windows. I did not find any such discussion on the lists, so I don't know exactly what was said. Therefore, I'll give you as much background as I can. Even while I was still maintaining webkitgtk, I was stuck with what became even then a very old version. The reason for this is the upstream migration to WebKit2: https://trac.webkit.org/wiki/WebKit2 In order to support the then-new split-process model (which we now all take for granted in browsers and browser engines), there needs to be some form of IPC between the UI process and web process. In WebKit2 on *NIX this was done in a way that involved passing file descriptors over a unix socket, which Cygwin never supported. As such, once webkitgtk completed its migration to WebKit2, I was unable to further update the package. (For a similar reason, it became impossible for anyone to update mingw- webkitgtk in any distro because a Windows counterpart implementation to that IPC was either never developed or just not integrated into webkitgtk. With Apple abandoning Safari on Windows, and Qt migrating from QtWebKit to QtWebEngine (which is based on Chromium), there doesn't seem to be any commercial interest in maintaining WebKit2 for Windows.) Therefore, this issue is currently CANTFIX until Cygwin gains support for passing file descriptors over unix sockets (in a Linux-compatible way), at which point a new maintainer could theoretically then try to port a current webkitgtk version to Cygwin. I sincerely wish luck to whomever tries to tackle this, as it will likely be no small feat. HTH, -- Yaakov
Re: [ITP] openh264 (2.3.1)
On Mon, 2023-02-06 at 14:25 +0900, Takashi Yano via Cygwin-apps wrote: > On Mon, 06 Feb 2023 00:16:45 -0500 > Yaakov Selkowitz via Cygwin-apps wrote: > > > On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote: > > > On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote: > > > > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote: > > > > > I would like to propose new package openh264, which is > > > > > a H264 video codec library. This is needed by ffmpeg > > > > > package I had proposed, and also provided for ffmpeg-free > > > > > package in fedora. > > > > > > > > > > I already prepared the package at the following location. > > > > > > > > > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/ > > > > > > > Unfortunately, this cannot be included in the Cygwin distribution. > > > > Cisco's > > > > patent license only covers binaries they distribute. Fedora has a > > > > special > > > > arrangement with Cisco where they build their RPMs on Fedora > > > > infrastructure, > > > > but the packages are hosted by Cisco in a separate repository. > > > > > > http://www.openh264.org/ > > > "Cisco has taken their H.264 implementation, and open sourced it under > > > BSD > > > license terms. Development and maintenance will be overseen by a board > > > from > > > industry and the open source community. Furthermore, we have provided a > > > binary > > > form suitable for inclusion in applications across a number of different > > > operating systems, and make this binary module available for download > > > from > > > the > > > Internet. We will not pass on our MPEG-LA licensing costs for this > > > module, > > > and > > > based on the current licensing environment, this will effectively make > > > H.264 > > > free for use on supported platforms." > > > > This is exactly the point. Cisco paid for a license, but that license is > > limited to binaries they distribute. Unfortunately, I doubt that Cisco > > will > > do the same for Cygwin. > > OK. How about distributing only headers as cygwin package > for building ffmpeg? The Fedora package includes openh264 headers and a patch which will dlopen() libopenh264 if present. These could be used (with the modification libopenh264.so.N -> cygopenh264-N.dll of course) in the Cygwin package. -- Yaakov
Re: [ITP] openh264 (2.3.1)
On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote: > On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote: > > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote: > > > I would like to propose new package openh264, which is > > > a H264 video codec library. This is needed by ffmpeg > > > package I had proposed, and also provided for ffmpeg-free > > > package in fedora. > > > > > > I already prepared the package at the following location. > > > > > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/ > > > Unfortunately, this cannot be included in the Cygwin distribution. > > Cisco's > > patent license only covers binaries they distribute. Fedora has a special > > arrangement with Cisco where they build their RPMs on Fedora > > infrastructure, > > but the packages are hosted by Cisco in a separate repository. > > http://www.openh264.org/ > "Cisco has taken their H.264 implementation, and open sourced it under BSD > license terms. Development and maintenance will be overseen by a board from > industry and the open source community. Furthermore, we have provided a > binary > form suitable for inclusion in applications across a number of different > operating systems, and make this binary module available for download from > the > Internet. We will not pass on our MPEG-LA licensing costs for this module, > and > based on the current licensing environment, this will effectively make H.264 > free for use on supported platforms." This is exactly the point. Cisco paid for a license, but that license is limited to binaries they distribute. Unfortunately, I doubt that Cisco will do the same for Cygwin. -- Yaakov
Re: [ITP] faad2 (2.8.8)
On Sun, 2023-02-05 at 22:04 -0700, Brian Inglis wrote: > On 2023-02-05 19:46, Yaakov Selkowitz via Cygwin-apps wrote: > > On Fri, 2023-01-20 at 19:36 +0900, Takashi Yano via Cygwin-apps wrote: > > > I would like to propose a new package FAAD2 which is > > > a decoder library for AAC audio codec. This package > > > is needed by the new package moc I have proposed at > > > the same time. I have already prepared the package at: > > > > > > https://tyan0.yr32.net/cygwin/x86_64/release/faad2/ > > > > Unfortunately, this cannot be included in the Cygwin distribution. > > These packages are now GPL and available from Arch, Debian main repo, *BSD > ports, OpenSuSE, Slack, and more, so there may have been issues with > non-relocatable non-PIC assembler code, patents now > expired/lapsed/challenged, > VideoLan or alternative commercial licensing, for example no commercial use > restrictions? > Many codecs like these can be installed on Fedora, etc. from RPMfusion, > UnitedRPMs, or other repos. Anything blocked from Fedora itself for legal reasons cannot be part of Cygwin either. Its inclusion in any other distro or repo is insufficient. -- Yaakov
Re: [ITP] openh264 (2.3.1)
On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote: > I would like to propose new package openh264, which is > a H264 video codec library. This is needed by ffmpeg > package I had proposed, and also provided for ffmpeg-free > package in fedora. > > I already prepared the package at the following location. > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/ Unfortunately, this cannot be included in the Cygwin distribution. Cisco's patent license only covers binaries they distribute. Fedora has a special arrangement with Cisco where they build their RPMs on Fedora infrastructure, but the packages are hosted by Cisco in a separate repository. -- Yaakov
Re: [ITP] faad2 (2.8.8)
On Fri, 2023-01-20 at 19:36 +0900, Takashi Yano via Cygwin-apps wrote: > I would like to propose a new package FAAD2 which is > a decoder library for AAC audio codec. This package > is needed by the new package moc I have proposed at > the same time. I have already prepared the package at: > > https://tyan0.yr32.net/cygwin/x86_64/release/faad2/ Unfortunately, this cannot be included in the Cygwin distribution. -- Yaakov
Re: cygwin-pkg-maint cleanup
On Tue, 2022-11-29 at 21:36 +, Jon Turney wrote: > I've done another clean-up of cygwin-pkg-maint, removing those source > packages names which no longer exist after x86 was archived (i.e only > existed as x86 packages) > > > cygwin64-* ORPHANED (Yaakov Selkowitz) 32-bit only by design Is there a point in keeping the cygwin32-* packages around any longer? -- Yaakov
Re: [PATCH 7/7] Cygwin: remove miscellaneous 32-bit code
On Thu, 2022-06-09 at 17:23 +0200, Corinna Vinschen wrote: > On May 29 17:26, Ken Brown wrote: > > On 5/29/2022 9:39 AM, Jon Turney wrote: > > > On 26/05/2022 20:17, Ken Brown wrote: > > > > winsup/cygwin/autoload.cc | 136 - > > > > -- > > > > > > Looks good. > > > > > > I think that perhaps the stdcall decoration number n is unused on > > > x86_64, so can be removed also in a followup? > > > > Thanks, I missed that. > > > > Also, I guess most or all of the uses of __stdcall and __cdecl can be > > removed from the code. > > Yes, that's right, given there's only one calling convention on 64 bit. > > I have a minor objection in terms of this patch. > > When implementing support for AMD64, there were basically 2 problems to > solve. One of them was to support 64 bit systems, the other one was to > support AMD64. At that time, only IA-64 and AMD64 64 bit systems > existed, and since we never considered IA-64 to run Cygwin on, we > subsumed all 64 bit code paths under the __x86_64__ macro. > > But should we *ever* support ARM64, as unlikely as it is, we have to > make sure to find all the places where the code is specificially AMD64. > That goes, for instance, for all places calling assembler code, or > for exception handling accessing CPU registers, etc. > > I'm open to discussion, but I think the code being CPU-specific > should still be enclosed into #ifdef __x86_64__ brackets, with an > #else #error alternative. > > Right? Wrong? Useless complication? Highly recommended. -- Yaakov
Re: [PATCH cygport] xorg.cygclass: Allow configuration of default SRC_URI compression
On Mon, 2022-04-11 at 13:58 +0100, Jon Turney wrote: > Historically, xorg packages were usually provided as .gz and .bz2 > compressed tarballs. The current trend is to no longer provide .bz2, > but .gz and .xz instead. Allow the compression to be configured, with a > backwards compatible default. If all or even most current packages use .xz, then maybe just default to that and define XORG_SRC_COMPRESSION for the (current) exceptions? -- Yaakov
Fwd: update urls for cygwinports
--- Begin Message --- I'm working to phase out the ftp urls on my main website, and see these files in cygwinports using the ftp urls: byacc/byacc.cygport dialog/dialog.cygport diffstat/diffstat.cygport luit/luit.cygport ncurses/ncurses.cygport tack/tack.cygport xterm/xterm.cygport The change is ftp://ftp.invisible-island.net/XXX to https://invisible-island.net/archives/XXX At the moment I have files in both places, and am working to have package scripts updated before pulling the plug on ftp. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature --- End Message ---
Re: Cygport configure script argument handling
On Thu, 2022-03-10 at 16:41 +, Adam Dinwoodie wrote:
> I've fallen down a slight rabbit hole looking at the cygconf function in
> Cygport's autotools.cygclass. The specific bit of code that's causing
> me consternation is thus:
>
> case "x${confver}" in
> x2.6[0-9]*)
> confargs+=" --docdir=/usr/share/doc/${PN}
> --htmldir=/usr/share/doc/${PN}/html"
> ;;
> *)
> confargs+=" --infodir=${prefix}/share/info
> --mandir=${prefix}/share/man"
> ;;
> esac
>
> Firstly, I think the glob is incorrect: it looks like it was intended to
> match files that came from Autoconf versions 2.60 and up -- 2.60 is when
> Autoconf added the docdir and htmldir arguments -- but it has stopped
> working as expected: Autoconf released 2.70 in December 2020, and is now
> up to 2.71. The above code won't match those versions.
Yes, this likely needs to be updated for 2.70+.
> Secondly -- and I'm not sure if this is intended or not -- I don't
> understand why --infodir and --mandir are only defined for versions
> prior to 2.60 (and, apparently unintentionally, 2.70 onwards). Those
> are valid both before and after 2.60. My best guess is that the intent
> was for the first option to fall through to the second, so for 2.60+ all
> four options would be defined, but that would have required `;&` or
> `;;&` rather than `;;`.
No. 2.60 included changes for these (and other) directory values:
https://lists.gnu.org/archive/html/autotools-announce/2006-06/msg2.html
docdir and htmldir were added in 2.60, hence we don't want to pass them when
<=2.59 is detected. infodir and mandir were changed in 2.60, from
$prefix/{info,man} (which cygport needed to override for FHS compliance) to
$datarootdir/{info,man}, where the new datarootdir is $prefix/share, meaning
they no longer needed to be overriden by cygport.
HTH,
--
Yaakov
[PATCH] Cygwin: do not build MinGW testsuite/cygrun --with-cross-bootstrap
--- winsup/testsuite/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/winsup/testsuite/Makefile.am b/winsup/testsuite/Makefile.am index 4b8c7dbb7..ac68934d0 100644 --- a/winsup/testsuite/Makefile.am +++ b/winsup/testsuite/Makefile.am @@ -61,4 +61,6 @@ EXTRA_DEJAGNU_SITE_CONFIG = site-extra.exp clean-local: rm -f *.log *.exe *.exp *.bak *.stackdump winsup.sum +if CROSS_BOOTSTRAP SUBDIRS = cygrun +endif -- 2.34.1
Re: gnulib m4/threadlib.m4 bug crashing package tests
On Thu, 2021-11-25 at 11:26 -0500, Ken Brown via Cygwin-apps wrote: > On 9/29/2021 7:46 PM, Brian Inglis wrote: > > There is a gnulib bug in threadlib.m4 from at least serial 29 to serial > > 31 that incorrectly configures Cygwin support of weak references. > > > > This leads to SIGSEGV stack smashing crashes with no backtrace > > @ 0x1 or 0x0005 etc. normally during tests. > > > > Akim Demaille on bug-bison referred the issue to bug-gnulib where > > Bruno Haible diagnosed and patched the problem to appear in > > m4/threadlib.m4 serial 32: > > > > * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on > > Cygwin > > https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html > > [gl_cv_have_weak="guessing no"] > > > > The patch has now been applied to bison, wget, and wget2, and I have > > attached my patches for the copies in those packages, in case anyone > > else has this issue in their (mainly GNU) packages which may incorporate > > by > > inclusion recently updated gnulib m4 macros used in autotools builds. > > Thanks, Brian. > > I'm writing to reinforce this warning. I just spent 2 days trying to debug > mysterious texinfo crashes that were caused by this bug. I could have saved > a > lot of time if I had remembered your email and had checked the gnulib > version > being used by texinfo. > > For anyone else who bumps into this, gdb and strace are of no use in > debugging > this crash. I finally thought to look at the stackdump file, and the second > address from the top was in a gnulib file. That was the key clue. Add gl_cv_have_weak=no to cygconf? -- Yaakov
Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg
On Wed, 2021-09-29 at 22:15 -0600, Brian Inglis wrote: > Hi folks, > > Autotools needs m4 macros in autoreconf-archive to config for gcov and > other dependencies or build fails with e.g. > > "configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation." > > CI scallywag setup does not install nor does cygport nor autoconf > require autoconf-archive so packages have to include in BUILD_REQUIRES. > > As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that > would be the more appropriate place for an autoconf-archive requirement, > otherwise cygport would have to require it, which is not so obvious. autoconf-archive would be a build requirement of the package whose configure.ac references the AX_* macro, not of the autotools themselves. -- Yaakov -- Yaakov
Re: github password policy
On Mon, 2021-08-16 at 19:51 +0200, Thomas Wolff wrote: > > Am 16.08.2021 um 16:46 schrieb Lee: > > On 8/16/21, Thomas Wolff wrote: > > > github have changed their authentication policy not to allow passwords > > > anymore. > > > So they are asking maintainers to acquire another kind of password (a > > > "token"), which I did a while ago. > > > But they refuse to support users with the transition, there is no > > > "plug-and-play" howto available, except for those who are willing to > > > dive into details of authentication stuff and spend a few study hours on > > > that useless policy change. > > > As I cannot update mintty anymore right now from the git command line, > > > is any maintainer here impacted by the same issue and can help out with > > > some advice how to get rid of this nuisance? > > ssh keys work - start here: > > https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh > Thanks for the link. So I've now added my ssh key to github and > successfully tested it. > Now what? git push apparently still wants to use the old password and > reports an error. Make sure the (push)url for the remote to which you wish to push is in the form g...@github.com:NAMESPACE/PROJECT.git rather than an https:// form. -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc.
Re: [PATCH] Ensure PSAPI_VERSION is 1 when building ldd
On Wed, 2021-05-26 at 17:51 +0100, Jon Turney wrote: > On 26/05/2021 10:04, Corinna Vinschen wrote: > > On May 25 22:37, Jon Turney wrote: > > > On 22/05/2021 16:08, Jon Turney wrote: > > > > On 20/05/2021 19:05, Corinna Vinschen wrote: > > > > > Hi Jon, > > > > > > > > > > On May 20 18:46, Jon Turney wrote: > > > > > > The default PSAPI_VERSION is controlled by WIN32_WINNT, which we > > > > > > set to > > > > > > 0x0a00 when building ldd, which gets PSAPI_VERSION=2. > > > > > > In the just released w32api 9.0.0, _WIN32_WINNT is now set to 0xa00 by > > > default, so this issue is probably going to surface in a few other > > > places as > > > well. > > > > I added _WIN32_WINNT and NTDDI_VERSION settings to make sure we notice > > any problems right away. > > I'm not sure what the mechanism by which we're going to notice is? > > Adding WIN32_WINNT=0x0a00 everywhere changes the meaning of '#include > ' in a way that is incompatible with Vista. > > So this has broken dumper, and possibly other utils, on Vista. > > I don't know if there are any other imports in other header which also > have this annoying behaviour... Does Vista REALLY still need to be supported at this point? -- Yaakov
Re: [PATCH cygport] Update xorg.cygclass URLs [GOLDSTAR]
On Tue, 2021-01-05 at 15:06 +0100, Achim Gratz wrote: > Yaakov Selkowitz via Cygwin-apps writes: > > 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. > > The patch series from Lem plus another handful of cleanups is available > at: > > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/URL-updates Thank you Lem for the patches, and Achim for gathering them together on a branch. It was surely tedious work, but necessary and much appreciated. These are (finally!) merged, can we get some gold stars please? -- Yaakov
Re: [ANNOUNCEMENT] Updated: python packages
On Tue, 2021-02-09 at 21:31 +, Jon Turney wrote:
> On 22/01/2021 21:37, Marco Atzeri via Cygwin-announce via Cygwin wrote:
> > Several python packages have been promoted from test to stable
> >
> [...]
> > python{36,37,38}-lxml-4.6.2-1
>
> Marco,
>
> I noticed something a bit odd, which I'm not sure is expected or not.
>
> If I install 'python3-lxml', I get 'python36-lxml', which doesn't do me
> much good with 'python3' installed (which gets me python3.8 currently).
When I changed the packaging scheme from pythonX-* to pythonXY-*, 3.6 was the
"3" version at the time, and the python3-* created alongside python36-* were
only meant to be upgrade helpers from that point forward.
--
Yaakov
--
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: dblatex needs update
On Wed, 2021-02-03 at 16:49 -0500, Ken Brown via Cygwin-apps wrote: > dblatex (still shown as maintained by Yaakov) is currently broken because it > was built for python2 but its shebang points to python. > > I could do a quick non-maintainer upload to fix the shebang, but maybe > someone wants to adopt it and rebuild it for python3. Please note that the version currently in Cygwin is not Py3 compatible; the latest upstream version should be though. -- Yaakov
Re: [PATCH cygport] Update xorg.cygclass URLs
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.
--
Yaakov
Re: [PATCH] Use automake (v3)
On Wed, 2020-12-02 at 18:03 +, Jon Turney wrote: > On 02/12/2020 17:05, Corinna Vinschen via Cygwin-patches wrote: > > On Dec 2 15:36, Jon Turney wrote: > > > On 01/12/2020 09:18, Corinna Vinschen wrote: > > > > What bugs me is that the mingw executables are built in > > > > utils/mingw, > > > > but the object files are still in utils. Any problem > > > > generating the > > > > object files in utils/mingw, too? > > > > > > Not easily. > > > > > > This behaviour can be turned off by not using the 'subdir- > > > objects' automake > > > option. > > > > > > But then automake warns that option is disabled (since it's going > > > to be the > > > default in future). > > > > So why not just move the mingw source files to utils/mingw, too? > > There's probably some scope for doing that, but not in all cases, as > some files are built multiple times with different compilers and/or > flags. > > e.g. path.cc is built with a cygwin compiler and -DFSTAB as part of > mount, with a MinGW compiler as part of cygcheck, and with a MinGW > compiler and -DTESTSUITE as part of path-testsuite. Then something like: $ cat > winsup/utils/mingw/path.cc <<_EOF #define MINGW // whatever is needed here... #include "../path.cc" _EOF ?? -- Yaakov
Re: mingw64 packages
On Sat, 2020-10-31 at 10:29 +0100, Achim Gratz wrote: > Since I seem to pick up more of these… it is silly enough that you have > to have two almost identical cygport files for the two architectures, > but it does not make any sense to me to require these to be standalone > git repositories. They share the sources and (most) patches with the > Cygwin package of the same name and I don't really intend to track those > changes manually across multiple submodules. So I'd like to keep these > the same way I have done ZStandard: the Cygwin package and both MingW64 > packages in one Git repository. > > That of course doesn't work in the CI as Scallywag gets its knickers in > a twist when it sees more than one cygport file in the checkout. That > looks like something that could hopefully be solved with either a YAML > file or some more smarts on the Scallywag side? I had some work pending in cygport to allow a single .cygport to build both i686 and x86_64 mingw packages. That would probably be the best approach to this. (Cygwin native and MinGW cross builds are often different enough that trying to lump them all together is a bit of a stretch imo.) -- Yaakov
cygwinports domains
My domain registrations cygwinports.com, cygwinports.net, and cygwinports.org will expire very soon. If anyone would like to adopt them for the Cygwin project, please let me know ASAP. Otherwise, I will let them lapse. -- Yaakov
Re: [ITA] libiconv-1.16-1, libiconv2-1.16, libcharset1-1.16-1
On Sat, 2020-07-11 at 19:45 +0200, Marco Atzeri via Cygwin-apps wrote: > On 11.07.2020 04:03, Lemures Lemniscati via Cygwin-apps wrote: > > Hi! > > > > I suggest an update to libiconv 1.16, since the current Cygwin > > packages of libiconv 1.14 are old (updated 5 years ago). > > > > Cygport files are forked > > to https://github.com/cygwin-lem/libiconv-cygport/tree/w_1.16 > > from http://cygwin.com/git/cygwin-packages/libiconv . > > > > > > New test package files are placed here: > > https://cygwin-lem.github.io/libiconv-cygport/index.html . > > > > Please, check them: > > Looks good to me > > except the build of static import libraries > > usr/lib/libcharset.a > usr/lib/libiconv.a > > I will stick to only: > usr/lib/libcharset.dll.a > usr/lib/libiconv.dll.a Static libiconv is used when building Cygwin dumper.exe (as a dependency of libbfd.a, which is static only). Therefore it should be present. Note that my .cygport has an explicit --enable-static, which should have indicated that this was deliberate. -- Yaakov
Re: [ITP] wget2 - modern fast parallel file and recursive website downloader
On Thu, 2020-07-09 at 20:27 +0200, Marco Atzeri via Cygwin-apps wrote: > On 08.07.2020 22:28, Brian Inglis wrote: > > On 2020-07-08 14:05, Brian Inglis wrote: > > > wget2 is the successor of wget supplying a shared library API like curl > > > to build > > > a modern, fast, multi-threaded, parallel downloader using HTTP/2, HTTP > > > compression and If-Modified-Since headers; see > > > > > > https://gitlab.com/gnuwget/wget2 > > > > > > It is currently available on Arch, Debian/Ubuntu, openSUSE, Slackware: > > > see > > > https://pkgs.org/download/wget2 > > > > > > I could release the package as is with an exe and dll, but it should be > > > built as > > > separate bin, lib, devel, doc, and debuginfo packages, which I have never > > > done > > > before, so could do with some advice and assistance with the apporach > > > required, > > > which I based on curl, but that requires no script function overrides, > > > and I > > > believe this one may or I need some hints. > > > > > > I have attached my base wget2.cygport which builds one monolithic package > > > but > > > contains comments for subpackage variables, plus comments showing other > > > files > > > which I think should be included in the subpackages, and both references > > > to > > > their locations in subpkg_CONTENTS and alterbative src_install script > > > actions if > > > cygport will not move the contents into the appropriate install directory. > > > > Forgot to explain I also produced a summary of the files generated and/or > > available for packaging under the triplet directory in manifest.list to my > > previous email. > > > > > I also need to understand how cyg...dll package numbering should work > > > with this > > > package: base zero or one and include or exclude the 2: libwget0, > > > libwget1, > > > libwget2_0, or libwget2_1, and how to get that generated? > > > > > > Any advice, assistance, help, or hints from more experienced packagers > > > would be > > > welcome. > > > > > > I can also update and release what may be the last patched version of the > > > original wget 1.20.3 (currently 1.19.1) if Eric has no time, or ITA wget > > > if he > > > agrees. > > > > > > I could also ITA curl from Yaakov as I use that and wget a lot in scripts > > > and > > > cron jobs. > > My suggestion: > > this in libwget2_0 (per consistency) or libwget0 > > /usr/bin/cygwget-0.dll libwget0, based on the library name. > these in wget2 > > /usr/bin/wget2.exe > /usr/share/doc/wget2/AUTHORS > /usr/share/doc/wget2/COPYING > /usr/share/doc/wget2/ChangeLog > /usr/share/doc/wget2/NEWS > /usr/share/doc/wget2/README > /usr/share/locale/ca/LC_MESSAGES/wget2.mo > /usr/share/locale/cs/LC_MESSAGES/wget2.mo > /usr/share/locale/de/LC_MESSAGES/wget2.mo > /usr/share/locale/eo/LC_MESSAGES/wget2.mo > /usr/share/locale/es/LC_MESSAGES/wget2.mo > /usr/share/locale/et/LC_MESSAGES/wget2.mo > /usr/share/locale/fi/LC_MESSAGES/wget2.mo > /usr/share/locale/fr/LC_MESSAGES/wget2.mo > /usr/share/locale/ga/LC_MESSAGES/wget2.mo > /usr/share/locale/hr/LC_MESSAGES/wget2.mo > /usr/share/locale/hu/LC_MESSAGES/wget2.mo > /usr/share/locale/id/LC_MESSAGES/wget2.mo > /usr/share/locale/it/LC_MESSAGES/wget2.mo > /usr/share/locale/ja/LC_MESSAGES/wget2.mo > /usr/share/locale/nb/LC_MESSAGES/wget2.mo > /usr/share/locale/nl/LC_MESSAGES/wget2.mo > /usr/share/locale/pl/LC_MESSAGES/wget2.mo > /usr/share/locale/pt_BR/LC_MESSAGES/wget2.mo > /usr/share/locale/ru/LC_MESSAGES/wget2.mo > /usr/share/locale/sk/LC_MESSAGES/wget2.mo > /usr/share/locale/sr/LC_MESSAGES/wget2.mo > /usr/share/locale/sv/LC_MESSAGES/wget2.mo > /usr/share/locale/tr/LC_MESSAGES/wget2.mo > /usr/share/locale/uk/LC_MESSAGES/wget2.mo > /usr/share/locale/vi/LC_MESSAGES/wget2.mo > /usr/share/locale/zh_CN/LC_MESSAGES/wget2.mo > plus also the manual page that it is missing > > > What is this ? It seems a duplicate of wget2 > > /usr/bin/wget2_noinstall.exe Simply based on the name, I'm guessing it shouldn't be installed? > these in libwget2-devel or libwget-devel libwget-devel, based on the library name. > /usr/include/wget.h > /usr/include/wgetver.h > /usr/lib/libwget.dll.a > /usr/lib/pkgconfig/libwget.pc > /usr/share/man/man3/libwget-base64.3.gz > /usr/share/man/man3/libwget-bitmap.3.gz > /usr/share/man/man3/libwget-console.3.gz > /usr/share/man/man3/libwget-dns-caching.3.gz > /usr/share/man/man3/libwget-dns.3.gz > /usr/share/man/man3/libwget-error.3.gz > /usr/share/man/man3/libwget-hash.3.gz > /usr/share/man/man3/libwget-hashmap.3.gz > /usr/share/man/man3/libwget-io.3.gz > /usr/share/man/man3/libwget-ip.3.gz > /usr/share/man/man3/libwget-list.3.gz > /usr/share/man/man3/libwget-mem.3.gz > /usr/share/man/man3/libwget-net.3.gz > /usr/share/man/man3/libwget-parse_atom.3.gz > /usr/share/man/man3/libwget-parse_sitemap.3.gz > /usr/share/man/man3/libwget-printf.3.gz > /usr/share/man/man3/libwget-random.3.gz > /usr/share/man/man3/libwget-robots.3.gz > /usr/share/man/man3/libwget-stringmap.3.gz >
Re: [ITP] python3-pillow
On Mon, 2020-07-06 at 09:57 +0100, Hamish McIntyre-Bhatty via Cygwin- apps wrote: > On 05/07/2020 23:21, Yaakov Selkowitz wrote: > > On Fri, 2020-06-26 at 01:49 +0100, Hamish McIntyre-Bhatty via Cygwin- > > apps wrote: > > > This email signals my intent to package python3-pillow > > > (https://pypi.org/project/Pillow) for Cygwin. Pillow is a fork of the > > > Python Imaging Library. > > > > > > I wish to package this because I have found that PyCrust (built with > > > wxPython) depends on Pillow and won't run without it installed. As > > > before, my test packages can be found at > > > https://www.hamishmb.com/files/cygwin-temp/. > > > > > > If anyone has feedback I'd appreciate it very much. > > 1) Source packages are generally named python-*. > Yes, but the latest build of Pillow doesn't support Python 2 - I feel > calling it python-pillow would be misleading. No, this is the naming scheme we've been using for Python packages. python-foo: sources pythonXY-foo: binaries for each supported X.Y version of Python > > 2) This should be an ITA for python-imaging instead, which has been > > Pillow-based for a long time. > > The Python imaging library was replaced by Pillow as far as I can tell, > and seems to have been unmaintained since 2011. Could you give me a link > to the library you're talking about please? As I said, our python-imaging packages have been from Pillow for quite some time. Technically, at this point they should be named python-pil or the like, but the package name long predates the PIL namespace being mandatory (not to mention the Pillow fork in general), but I never renamed the packages to avoid the complications involved therein. Either way, "pillow" isn't the right name IMO because users don't "from Pillow import", they "from PIL import". -- Yaakov
Re: [ITP] python3-pillow
On Fri, 2020-06-26 at 01:49 +0100, Hamish McIntyre-Bhatty via Cygwin- apps wrote: > This email signals my intent to package python3-pillow > (https://pypi.org/project/Pillow) for Cygwin. Pillow is a fork of the > Python Imaging Library. > > I wish to package this because I have found that PyCrust (built with > wxPython) depends on Pillow and won't run without it installed. As > before, my test packages can be found at > https://www.hamishmb.com/files/cygwin-temp/. > > If anyone has feedback I'd appreciate it very much. 1) Source packages are generally named python-*. 2) This should be an ITA for python-imaging instead, which has been Pillow-based for a long time. -- Yaakov
Re: [PATCH cygport] mirrors: update mirror_debian
On Thu, 2020-06-04 at 05:10 +0900, Yasuhiro KIMURA wrote: > Hello Brian. Thank you for feedback. > > From: Brian Inglis > Subject: Re: [PATCH cygport] mirrors: update mirror_debian > Date: Wed, 3 Jun 2020 14:02:45 -0600 > > >> # MIRROR LIST > >> -# http://www.debian.org/mirror/list > >> +# https://wiki.debian.org/DebianGeoMirror > > > > NO - http://www.debian.org/mirror/list is the authoritative page (it says > > so); > > whereas https://wiki.debian.org/DebianGeoMirror is a discussion page. > > OK. Then should I update patch and submit it again? Yes. -- Yaakov
Re: Request for review: anthy 9100h+0.4 (Re: Update of packages by non-maintainer)
On Thu, 2020-06-04 at 01:20 +0900, Yasuhiro KIMURA wrote:
> From: Yasuhiro KIMURA
> > So I gave up to use override.hint and decided to change version number
> > to "9100h+0.4". It works fine with all of cygport, mksetupini and
> > setup-x86_64.
>
> Anyway version number issue has sloved. So I would like to request for
> review of anthy 9100h+0.4.
Not ready yet; see comments inline.
> * As for cygwin local patch, 9100h-no-undefined.patch is changed to
> make it fit to new source tree. Others are removed.
[snip]
> * Add "MAKEOPTS=-j1" because parallel make causes build error.
That's the whole purpose of the exeext patch, to fix parallel make.
Before you remove patches, you first need to understand what the patch
does, why it was needed, and see if it still is or not. If you don't
know, then you should be asking rather than just dropping them.
> PKG_NAMES="${NAME} lib${NAME}0 lib${NAME}-common lib${NAME}-devel
> emacs-${NAME}"
[snip]
> libanthy0_REQUIRES="libanthy-common"
> libanthy0_CONTENTS="usr/bin/cyganthy*.dll"
This is wrong; most of the DLLs will be -1.dll, so this needs to be
libanthy1 (but see below!!).
> 9100h-no-undefined.patch:
This looks mostly fine, except:
> --- origsrc/anthy-0.4/src-util/Makefile.am 2019-07-05 11:37:13.0
> +0900
> +++ src/anthy-0.4/src-util/Makefile.am 2020-05-23 00:59:26.155191100 +0900
> @@ -26,5 +26,6 @@
> libanthyinput_la_SOURCES = input.c rkconv.c rkhelper.c\
> rkconv.h rkmap.h rkhelper.h
> libanthyinput_la_LIBADD = ../src-main/libanthy.la
> +libanthyinput_la_LDFLAGS = -no-undefined
>
> pkgdata_DATA = typetab dic-tool-usage.txt
This should probably have -version-info flag as well upstream,
otherwise you'll have conflicts with libanthy0 and libanthy1.
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
Re: [PATCH] cygport: suppress spurious package dependencies
On Wed, 2020-06-03 at 13:51 +0200, Achim Gratz wrote: > The automatically generated dependencies sometimes have unwanted > components. This patch allows to suppress these on a per-package basis, > rather than requiring to patch the generated hint files after the fact. What exactly are you trying to "fix" with this? -- Yaakov
Re: [ITP] cairomm, as replacement for cairomm1.0
On Fri, 2020-05-15 at 11:30 -0400, Ken Brown via Cygwin-apps wrote: > cygport file attached. I've bumped the version to 1.12.2, which is the > latest > stable upstream release. Upstream has actually released 1.15.5, but the News > file says it's unstable and recommends that distros not package it. GNOME still uses the development/stable odd/even-minor versioning scheme (like the Linux kernel used to long ago). > I'm proposing an unversioned source package cairomm, as well as unversioned > devel and doc packages. This is what we do with many library packages, and > it > is consistent with Fedora's packaging. I would strongly recommend against this rename, and in fact it is Fedora that might have to adapt, because: > It will also ease future maintenance. I've looked at the upstream git repo, > and > there's been an ABI change from 1.0 to 1.14 and then to 1.16. It would be > annoying to have to create a new Cygwin package for each such change. 1.0 isn't an ABI version, it's an API version, and like many GNOME libraries, the GTKmm bindings carry the API version in all its directories and library names, so that multiple versions may be installed in parallel. (Any given application can use only one stack, but you can have some apps using the new and other apps using the current until they update.) Cairo is relatively newer than the rest of the stack, and so it hasn't been through this process before, but the others have. (That's they the current versions are e.g. 2.4 instead of 2.0, because the upcoming versions will be the third or even fourth API version for most of these packages; the previous versions were obsolete a LONG time ago. In fact, just remembering going through this last time, and then realizing how long ago that was, isn't making me feel any younger. :-) With the introduction of libsigc-3.0, this and the rest of the GTKmm stack is going to undergo a(nother) API version bump, with the new versions should be parallel installable with the current: Current: libsigc-2.0, glibmm-2.4, cairomm-1.0, atkmm-1.6, pangomm-1.4, gtkmm-2.4 and -3.0, New: libsigc-3.0, glibmm-2.66, cairomm-1.16, atkmm-2.30, pangomm-2.44, gtkmm-4.0, etc. We're going to want to be able to have both for a period of time, and of course this could always happen again in the future. That's why they always been, and should remain, versioned. -- Yaakov
Re: Python - plan & execution
On Mon, 2020-05-25 at 06:52 +0200, Marco Atzeri via Cygwin-apps wrote:
> On 27.04.2020 16:34, Jon Turney wrote:
> > On 23/04/2020 22:54, Yaakov Selkowitz wrote:
> > > On Fri, 2020-04-10 at 14:52 +0200, 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:
> > > >
> > > > currently we have
> > > >
> > > > 119 *python27*
> > >
> > > These are fine as is, but they also don't need to be rebuilt or updated
> > > any more.
> > >
> > > > 114 *python36*
> > > > 115 *python37*
> > > > 10 *python38*
> > >
> > > We don't need to _obsolete or remove python3[67]-* packages, we just
> > > need to track how many don't have python38-* equivalents yet.
> > > Obviously that's still the vast majority, since 3.8 just got updated to
> > > a stable version.
> > >
> > > Jon Turney, if a python-foo source package was previously building e.g.
> > > python27-foo, python36-foo, and python37-foo, and now starts building
> > > only python37-foo and python38-foo, is calm going to complain?
> >
> > Yes, currently it will complain about that ("install packages from
> > source package '...' have non-unique current versions")
> >
> > calm is currently smart enough to exclude old soversions from that
> > check, so I guess perhaps that it needs to be taught about python27 as
> > well.
> >
>
> there will be several cases to test;
> the first I am rebuilding is python-setuptools
> and it seems there are half of the packages to drop in 46.4.0
>
>
> python-setuptools python27-setuptools drop
I'd like to suggest you make two updates to setuptools, one to the last
version which supports 2.7 with all Pythons enabled, and then to the
latest version, dropping 2.7.
> python-setuptools python35-setuptools drop
3.5 is still supported upstream and by latest setuptools, why drop
this?
> python-setuptools python36-setuptools
> python-setuptools python37-setuptools
> python-setuptools python38-setuptools
No change here, as expected.
> python-setuptools python-setuptools-wheel drop
>
> on python-setuptools-wheel, this file is not build/installed anymore
>
> usr/share/python-wheels/setuptools-41.2.0-py2.py3-none-any.whl
>
> so I guess it was Py2 only
No; since setuptools dropped Py2 support, they must have stopped
declaring 'universal' compatibility, so the wheel would now be just
'py3' instead of 'py2.py3'. You don't want to drop this package,
because it is used by (patched) python3Y venv as well as by python3Y-
virtualenv.
OTOH, since the latest setuptools won't work with python27, then
python27 and python27-virtualenv shouldn't use python-setuptools-wheel
anymore. I'd have to look further into the best way to handle that.
--
Yaakov
Re: [ITA] libsigc2.0, [ITP] libsigc3.0
On Thu, 2020-05-14 at 17:14 -0400, Ken Brown via Cygwin-apps wrote: > cygport files attached. I've updated libsigc2.0 to the latest release in the > 2.0 series, and I've created libsigc3.0 as a new package, as Fedora does. > Note: > If you want to do a test build of the latter, you'll need to install the > updated > mm-common from the previous ITA. These look fine. Just curious, were you planning on doing the entire (or some part of) GTKmm stack? -- Yaakov
Re: [ITA] mm-common
On Thu, 2020-05-14 at 14:57 -0400, Ken Brown via Cygwin-apps wrote: > cygport file attached. I bumped the version to the latest upstream release, > and > I removed the custom src_compile, since the default src_compile now works > (and > the custom one doesn't, since the tarball no longer includes a configure > script). This is fine, go ahead. -- Yaakov
Re: [ITA] libpng
On Thu, 2020-05-14 at 11:17 -0400, Ken Brown via Cygwin-apps wrote: > Builds fine from Yaakov's cygport file, no update needed at present. Go ahead. -- Yaakov
Re: cygport development
On Tue, 2020-05-12 at 16:59 +0200, Federico Kircheis wrote: > On 10/14/19 10:55 AM, Federico Kircheis wrote: > > On 13/10/2019 18.41, Achim Gratz wrote: > > > Federico Kircheis writes: > > > > I've sent the patches the 14.07.19, unfortunately I still got no answer. > > > > > > The cygport maintainer is rather busy with non-Cygwin related work these > > > days, I suppose. Anyway, one of the questions I have is why you need > > > these changes. Most build systems do not actually work when they > > > encounter a path with spaces if they use make under the hood, so fixing > > > cygport to grok such path locations isn't getting you much further I'd > > > think. Can you explain? > > > > Yep. > > > > I've built some software in my windows home directory. > > It contains a space. > > I expected it to work. > > > > Instead of failing with a clear error message, the build process deleted > > some unrelated files as it cd failed (or cd in the wrong directory, cant > > remember right now). > > > > I believe it is unacceptable to delete unrelated data. > > > > Even if it stated that there is no intention to support path with > > spaces, those scripts should fail fast and ideally with a clear error > > message. > > > > I found it easier to quote the offending variables, as not only spaces > > might cause issues. > > The merge request in the repository has been closed. > > I'm attaching the updated patch. 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. 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. 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. -- Yaakov
Re: [ITA from Yaakov] python-wx
On Thu, 2020-05-14 at 11:02 +0100, Hamish McIntyre-Bhatty wrote: > Apologies for bumping this again, I'm just waiting for this to be done > before I start on wxPython 4, which is blocking progress for me doing > other things. If you're not interested in this fix, just let me know > and I'll move on to wxPython 4. > > I have re-built the packages using your new cygport as the starting > point, and it seems to work really well. I made some minor modifications > to include the license files and the new patches from Fedora. The new > files are available at https://www.hamishmb.com/files/cygwin-temp/ and I > have removed the previous attempt's files. This looks fine. > 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
Re: [ITA] zziplib
On Wed, 2020-05-13 at 14:44 -0400, Ken Brown via Cygwin-apps wrote: > cygport file attached. I bumped the version to 0.13.71, the latest upstream > release. I also made the following changes to Yaakov's cygport file, in > addition to a couple of trivial ones: > > 1. I removed the configure argument --disable-builddir, which is no longer > needed or supported. The macro that required that is commented out in configure.ac, so that's fine. > 2. I primed the cache so that configure would think I didn't have xmlto > installed. The latter failed to produce man files, for reasons I didn't try > to > figure out. They build on my system with xmlto 0.0.26, so it's probably a matter of a missing dependency. Do you have all the docbook-* packages installed? What error message is shown? -- Yaakov
Re: Symbol visibility problems with -std=
On Wed, 2020-05-13 at 13:21 +0300, Pavel Fedin via Cygwin wrote: > While compiling various software packages for Cygwin i notice that very > often i have to add something like #define _GNU_SOURCE to > them in order to compile correctly. Meanwhile on Linux they compile with no > problems at all. I've narrowed it down to -std=??? > option using a simple test case: [snip] > $ g++ test.cpp -o test - compiles OK > $ g++ test.cpp -o test -std=c++14 - error: 'strdup' was not declared in this > scope; did you mean 'strcmp'? > > By printing out predefined macros (-dM -E) i found out that -std=something > option adds " #define __STRICT_ANSI__ 1" to builtin > macros, but removes all *_SOURCE definitions, so _DEFAULT_SOURCE is not > triggered any more. That is what -std=c* is supposed to mean, that you are declaring strict ISO-standard language conformance. > I've compared the behavior with Linux system. On Linux -std=c++14 also > defines __STRICT_ANSI__, but various *_SOURCE macros are not > omitted. That's because _GNU_SOURCE is defined unconditionally by g++ on Linux, which overrides the __STRICT_ANSI__ defined by -std=c*. IIUC this is done only to handle the use of non-ISO functions in libstdc++, particularly in the implementation of newer C++ standards. The bottom line is, if you are using POSIX C extensions, then you shouldn't be declaring -std=c* without the appropriate _*_SOURCE. > Isn't this a Cygwin bug? Not really, just that our g++ is somewhat more strict. If anything, allowing use of functions outside the declared standards (the behaviour on Linux) is the bug, and it's been on my to-do list for a long time to fix. Fixing this isn't as simple as removing the unconditional define; the C library functions used by newer C++ need to be appropriately guarded, and then those specific guards used in libstdc++. It was a major project to get this working on Cygwin. > By the way, clang does not suffer from this problem. Clang also defines _GNU_SOURCE unconditionally when compiling C++, even on Cygwin. Perhaps *that* should be considered the bug. -- Yaakov -- 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] cygwin: doc: Add keywords for ACE order issues
On Tue, 2020-05-12 at 22:49 +0200, David Macek via Cygwin-patches wrote: > Windows Explorer shows a warning with Cygwin-created DACLs, but putting > the text of the warning into Google doesn't lead to the relevant Cygwin > docs. Let's copy the warning text into the docs in the hopes of helping > confused users. > > Latest inquiry: <https://cygwin.com/pipermail/cygwin/2020-May/244814.html> > > Signed-off-by: David Macek > --- > winsup/doc/ntsec.xml | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml > index 08a33bdc6c..b94cdd9a97 100644 > --- a/winsup/doc/ntsec.xml > +++ b/winsup/doc/ntsec.xml > @@ -2163,7 +2163,10 @@ preferred order. > the Windows Explorer insists to rearrange the order of the ACEs to > canonical order before you can read them. Thank God, the sort order > remains unchanged if one presses the Cancel button. But don't even > -think of pressing OK... > +think of pressing OK... For the sake > +of people searching for this explanation, let's note that the Explorer > +warning says "The permissions on ... are incorrectly orderer, which may > +cause some entries to be ineffective." > > Canonical ACLs are unable to reflect each possible combination > of POSIX permissions. Example: The wording seems awkward. Why not quote the text of the warning directly earlier in the paragraph, e.g.: Unfortunately, the security tab in the file properties dialog of the Windows Explorer will pop up a warning stating: "The permissions on ... are incorrectly ordered, which may cause some entries to be ineffective." Pressing the Cancel button will leave the order unchanged, but pressing OK will cause Windows to canonicalize the order of the ACEs, thereby invalidating POSIX compatibility. -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc.
Re: [ITA from Yaakov] freetype2
On Tue, 2020-05-12 at 12:50 -0400, Ken Brown via Cygwin-apps wrote: > My cygport file is attached. Aside from some trivial URL changes, it differs > from Yaakov's as follows: > > 1. I've bumped the version from 2.9.1 to 2.10.2, the latest upstream release. Unfortunately 2.10 has some ABI/API-breaking changes, which Fedora mitigates with the following patches: https://src.fedoraproject.org/rpms/freetype/raw/master/f/freetype-2.10.0-internal-outline.patch https://src.fedoraproject.org/rpms/freetype/raw/master/f/freetype-2.10.1-debughook.patch > 2. I removed the Fedora patch freetype-2.9-ftsmooth.patch, which is no longer > used in the Fedora build. Fine. > 3. I removed the line 'cygmake refdoc', which was previously used to build > the > API reference manual. The html files are now included in the source tarball. > The refdoc target is apparently now only needed for a build from the upstream > git repo. IIRC there were also new Python module build requirements necessary to (re)build the docs, so just as well. > PATCH_URI=" > > https://src.fedoraproject.org/cgit/rpms/freetype.git/plain/freetype-2.3.0-enable-spr.patch > > https://src.fedoraproject.org/cgit/rpms/freetype.git/plain/freetype-2.2.1-enable-valid.patch > > https://src.fedoraproject.org/cgit/rpms/freetype.git/plain/freetype-2.6.5-libtool.patch > " These currently work through forwarding but should be changed to the new locations: https://src.fedoraproject.org/rpms/freetype/raw/master/f/$FILENAME -- Yaakov
Re: Default mingw _WIN32_WINNT
On Mon, 2020-05-11 at 10:55 -0400, Chris Wagner wrote: > On 2020-05-05 5:05 am, Rainer Emrich wrote: > > Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: > > > Therefore it might be a good idea to bump the default for these > > > Cygwin-related headers to at least 0x0600. > > > > > > Setting them to 0x0602 sounds like a good idea, but as long as we didn't > > > drop Vista or W7 support it might be premature. > > > > > > Btw., checking Cygwin sources for Vista and W7-specific code, it turned > > > out that actually very few lines of code handle Vista or W7-specific > > > workarounds. The advantage of removing the code is pretty minor, so I > > > didn't push the changes. While it's a bad idea to keep Vista and W7 > > > running (at least attached to the internet), we can support them a while > > > longer. > > I would expect support for Windows 7 as long as the Micsrosoft ESU > > program is active. We don't work for Microsoft, so as an independent project, we'll support Windows 7 only as long as we feel is viable and valuable. As Corinna said, for now that's the case, but nobody here is guaranteeing anything beyond that. > I would just like to chime in that it would be a crying shame if Cygwin > were to ever drop support for Windows 7. There are many people, myself > one, who are dead set against Windows 10. "Ever"?!? You do realize that, ESU aside, Windows 7 is out of support and therefore should be assumed to be vulnerable? -- Yaakov -- 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
[ANNOUNCEMENT] tzdata 2020a-1
The following packages have been uploaded to the Cygwin distribution: * tzdata-2020a-1 The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. This release includes the latest time-zone changes: https://mm.icann.org/pipermail/tz-announce/2020-April/58.html -- Yaakov -- 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
tzdata 2020a-1
The following packages have been uploaded to the Cygwin distribution: * tzdata-2020a-1 The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. This release includes the latest time-zone changes: https://mm.icann.org/pipermail/tz-announce/2020-April/58.html -- Yaakov
[RFC] cygport mingw.cygclass
To ease the maintenance of MinGW cross-compiling packages, I have written a new mingw.cygclass (actually, a series of cygclasses, but that's the top-level one that you should use) which is designed to allow building both 32- and 64-bit MinGW binaries in the same build. It also allows for the introduction of Windows for ARM toolchains, which I have bootstrapped but am not able to verify due to the lack of access to such systems. (Therefore, they are disabled by default.) Because this moves fundamentally away from the single-arch paradigms on which cygport was built (remember that cygport predates the widespread availability of 64-bit Windows systems), extensive changes were required that could possibly break something. Therefore, I have posted this to the topic/mingw branch of cygport. If maintainers could please test this with both mingw and ordinary packages, that would be appreciated. Also needed is feedback on the naming schemes currently used: * mingw32_* functions and MINGW32_ definitions/variables for i686 * mingw64_* functions and MINGW64_ definitions/variables for x86_64 * mingwarm32_* functions and MINGWARM32_ definitions/variables for armv7 * mingwarm64_* functions and MINGWARM64_ definitions/variables for aarch64 * mingw-* for source package names * mingw64-i686-* for i686 binary packages * mingw64-x86_64-* for x86_64 binary packages * mingw64-armv7-* for armv7 binary packages * mingw64-aarch64-* for aarch64 binary packages The function/definition naming scheme is designed around Fedora (which does not have ARM, so I made those up myself) but the binary package scheme match our current usage. I realize the source package names are those from the old i686-only mingw.org packages; whether we want to rename the binary packages to mingw32-/mingw64-, or rename the source packages to mingw64-, or do something else entirely, I'm open to suggestions. -- Yaakov
Re: cygport patches for consideration
On Sun, 2020-05-10 at 10:58 +0200, Achim Gratz wrote: > I've reworked the series according to your comments, force-pushed to the > same branch: > > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream Merged, but changed NO_PERL_DEPS to PERL_NO_VENDOR_DEPS. -- Yaakov
[ANNOUNCEMENT] cygport 0.34.0
The following packages have been uploaded to the Cygwin distribution and the Fedora Cygwin COPR: * cygport-0.34.0-1 cygport is the standard method for building and maintaining packages for the Cygwin distribution. Highlights of this release: * A new BUILD_REQUIRES variable is accepted as a list of package names to check before trying to build as well as add as dependencies in the (new) separate -src.hint file. The DEPEND variable (which is not compatible therewith) is deprecated. * New [PKG_]PROVIDES and [PKG_]CONFLICTS variables are accepted and passed into the respective .hint files. * kde.org: default SRC_URIs are updated for KDE 19.12 and newer. * meson: cygmeson now passes the --auto-features=enabled flag. * ocaml-dune: new cygclass for Dune-based OCaml packages. * perl: new CPAN_SUBDIR optional variable is accepted. * python3: new PYTHON3_PKGVERSION definition. * python-wheel: default PYTHON_WHEEL_VERSIONS is now just 3.7 and 3.8. For contributors, there have been numerous testsuite improvements, and the testsuite is now run in CI, courtesy of Jon Turney. A full changelog follows. Achim Gratz (1): Switch submodule gnuconfig to HTTPS protocol Jon Turney (17): Document src_unpack_hook and src_patch_hook Add src_patch_apply_hook Don't allow SRC_URI or PATCH_URI to depend on ARCH Raise an error if we package a .stackdump file meson: use auto-features option Fixup __version_at_least a bit Add test which compares hints with expected Add provides: and conflicts: hints Generate a separate .hint for the source package Update tests for build-depends: appearing in source hints Updates to tests for package updates Add a GitHub action to run tests Add some case variants to list of default documentation files installed Restore build-depends: trailing space in expected hints, dropped by rebase Disable autotools/gtkmm test in CI Update upload package check for source hints Allow manpage section .3G, used by OpenGL manpages Yaakov Selkowitz (24): check_funcs, pkg_pkg: Replace DEPEND with BUILD_REQUIRES Transfer repository to Cygwin project Add Cygwin git repositories kde.org: update URLs for 19.12 release pkg_pkg: inform when packaging as test python3-distutils: force hardcoding of python3.y instead of python3 perl: add CPAN_SUBDIR python3: add PYTHON3_PKGVERSION Revert "python3-distutils: force hardcoding of python3.y instead of python3" python3: force hardcoding of python3.y instead of python3 python-wheel: update for 3.8 and obsoletion of 2.7 pkg_diff: ignore aminclude_static.am pkg_pkg: add cygport to all source package build-depends list_deps: use ocamlobjinfo for better OCaml dependency detection ocaml-dune: new cygclass testsuite: update python/wheel for Python 3.8 Update gnuconfig Update copyrights to 2020 Update and credit AUTHORS CI: update dependencies for python/wheel test CI: re-enable autotools/gtkmm test testsuite: fix dependencies of python/wheel CI: enable ocaml/dune test Bump version to 0.34.0 -- Yaakov -- 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
cygport 0.34.0
The following packages have been uploaded to the Cygwin distribution and the Fedora Cygwin COPR: * cygport-0.34.0-1 cygport is the standard method for building and maintaining packages for the Cygwin distribution. Highlights of this release: * A new BUILD_REQUIRES variable is accepted as a list of package names to check before trying to build as well as add as dependencies in the (new) separate -src.hint file. The DEPEND variable (which is not compatible therewith) is deprecated. * New [PKG_]PROVIDES and [PKG_]CONFLICTS variables are accepted and passed into the respective .hint files. * kde.org: default SRC_URIs are updated for KDE 19.12 and newer. * meson: cygmeson now passes the --auto-features=enabled flag. * ocaml-dune: new cygclass for Dune-based OCaml packages. * perl: new CPAN_SUBDIR optional variable is accepted. * python3: new PYTHON3_PKGVERSION definition. * python-wheel: default PYTHON_WHEEL_VERSIONS is now just 3.7 and 3.8. For contributors, there have been numerous testsuite improvements, and the testsuite is now run in CI, courtesy of Jon Turney. A full changelog follows. Achim Gratz (1): Switch submodule gnuconfig to HTTPS protocol Jon Turney (17): Document src_unpack_hook and src_patch_hook Add src_patch_apply_hook Don't allow SRC_URI or PATCH_URI to depend on ARCH Raise an error if we package a .stackdump file meson: use auto-features option Fixup __version_at_least a bit Add test which compares hints with expected Add provides: and conflicts: hints Generate a separate .hint for the source package Update tests for build-depends: appearing in source hints Updates to tests for package updates Add a GitHub action to run tests Add some case variants to list of default documentation files installed Restore build-depends: trailing space in expected hints, dropped by rebase Disable autotools/gtkmm test in CI Update upload package check for source hints Allow manpage section .3G, used by OpenGL manpages Yaakov Selkowitz (24): check_funcs, pkg_pkg: Replace DEPEND with BUILD_REQUIRES Transfer repository to Cygwin project Add Cygwin git repositories kde.org: update URLs for 19.12 release pkg_pkg: inform when packaging as test python3-distutils: force hardcoding of python3.y instead of python3 perl: add CPAN_SUBDIR python3: add PYTHON3_PKGVERSION Revert "python3-distutils: force hardcoding of python3.y instead of python3" python3: force hardcoding of python3.y instead of python3 python-wheel: update for 3.8 and obsoletion of 2.7 pkg_diff: ignore aminclude_static.am pkg_pkg: add cygport to all source package build-depends list_deps: use ocamlobjinfo for better OCaml dependency detection ocaml-dune: new cygclass testsuite: update python/wheel for Python 3.8 Update gnuconfig Update copyrights to 2020 Update and credit AUTHORS CI: update dependencies for python/wheel test CI: re-enable autotools/gtkmm test testsuite: fix dependencies of python/wheel CI: enable ocaml/dune test Bump version to 0.34.0 -- Yaakov
Re: Default mingw _WIN32_WINNT
On Tue, 2020-05-05 at 10:54 +0200, Corinna Vinschen wrote: > On May 5 08:45, Biswapriyo Nath via Cygwin wrote: > > Chaging the defines in package may break others installation. > > No, it doesn't in this case. In what case would it? > Yaakov is talking about mingw-w64 headers used to create *Cygwin* > applications using the occasional Windows function. Cygwin executables > in the distro run on Vista but not on XP or 2K3 anymore, given the > Cygwin DLL doesn't. That too, as well as the mingw64-*-headers used in the MinGW-w64 toolchain. > Therefore it might be a good idea to bump the default for these > Cygwin-related headers to at least 0x0600. > > Setting them to 0x0602 sounds like a good idea, but as long as we didn't > drop Vista or W7 support it might be premature. I suppose so for Cygwin, but the mingw64-*-headers could be different. > Btw., checking Cygwin sources for Vista and W7-specific code, it turned > out that actually very few lines of code handle Vista or W7-specific > workarounds. The advantage of removing the code is pretty minor, so I > didn't push the changes. While it's a bad idea to keep Vista and W7 > running (at least attached to the internet), we can support them a while > longer. Fair enough. -- Yaakov -- 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
Default mingw _WIN32_WINNT
JonY, In w32api-headers and mingw64-*-headers, the default value of _WIN32_WINNT can be configured at build-time with --with-default-win32- winnt=$VER, with the default still being 0x502 (XP x64/2003 R2). With 2008, 2008 R2, and 7 having gone out of support earlier this year, Server 2012 is now the oldest currently supported version. Is it time to set this to 0x602 by default? -- Yaakov -- 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: lyx and QT5 blank windows
On Sun, 2020-04-26 at 11:15 +0200, Marco Atzeri via Cygwin wrote:
> I am trying to rebuild lyx with QT5 enabled instead of QT4.
Good idea, since Qt4 is obsolete and unmaintained (both upstream and
downstream).
> The build is fine and it seems to start fine, but opening new windows
> like "open file" only produces a blank and black window.
>
> At running I see only this output, that is not clear if it is related
>
> QXcbShmImage: shmget() failed (88: Function not implemented) for size
> 1407600 (690x510)
> QXcbShmImage: shmget() failed (88: Function not implemented) for size
> 518976 (318x408)
> Gtk-Message: GtkDialog mapped without a transient parent. This is
> discouraged.
> QXcbShmImage: shmget() failed (88: Function not implemented) for size
> 12000 (100x30)
Do you have cygserver running, and was it started before the X server?
This is a requirement for the MIT-SHM extension, otherwise you need to
set QT_X11_NO_MITSHM=1 in your environment.
> and at build time there is a new warning coming from the compiler
>
> /usr/include/qt5/QtGui/qtransform.h: In member function ‘QTransform&
> QTransform::operator=(QTransform&&)’:
> /usr/include/qt5/QtGui/qtransform.h:81:46: warning: ‘void* memcpy(void*,
> const void*, size_t)’ writing to an object of type ‘class QTransform’
> with no trivial copy-assignment; use copy-assignment or
> copy-initialization instead [-Wclass-memaccess]
> 81 | { memcpy(this, , sizeof(QTransform)); return *this; }
>| ^
I think this can be ignored for now, and will likely be fixed by a
future update to qt5.
--
Yaakov
--
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: Python - plan & execution
On Fri, 2020-04-10 at 14:52 +0200, 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.
>
> first steps done:
> - updated 3.8 to 3.8.2
> - updated 3.7 to 3.7.7
> - updated also their python doc
> - upload of all of them is in progress
Didn't think of it earlier, but how about updating python3 (the major-
version symlinks) to 3.8 as a test: release now? That should help
maintainers start the move without breaking the world for everybody
else. Posted this to a branch to help:
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python3.git;a=commitdiff;h=772172be59111366ece38aebb1ea876322bfdd2f
> next steps:
> - I assume we can drop 3.5
Your call, it's still supported upstream for almost 5 more months. I
wouldn't build anything python35-* except for
setuptools/pip/wheel/virtualenv.
> - for the time being no need to update 2.7 and 3.6
>(we are just one version behind)
There's now a 2.7.18, we should probably pick that up, as it has the
final upstream fixes. After that, it's time to start moving to 3.8 en
masse.
> - verify which python packages we need to build/rebuild
>
> currently we have
>
> 119 *python27*
These are fine as is, but they also don't need to be rebuilt or updated
any more.
> 114 *python36*
> 115 *python37*
> 10 *python38*
We don't need to _obsolete or remove python3[67]-* packages, we just
need to track how many don't have python38-* equivalents yet.
Obviously that's still the vast majority, since 3.8 just got updated to
a stable version.
Jon Turney, if a python-foo source package was previously building e.g.
python27-foo, python36-foo, and python37-foo, and now starts building
only python37-foo and python38-foo, is calm going to complain?
> and ~ 225 other *python* packages (plus 10 for python35)
There are a lot of _obsolete python-*, python2-*, and python3-*
"packages" which we don't need to count. How many of those names are
NOT _obsolete?
> - verify the fedora python-unversioned-command
This is the last step.
--
Yaakov
Re: [ITA] python2-wx and related packages for wxPython and wxwidgets
On Thu, 2020-04-23 at 18:09 +0100, Hamish McIntyre-Bhatty wrote: > On 23/04/2020 17:08, Yaakov Selkowitz wrote: > > Please keep all discussion on list. > > > My apologies, I thought I'd sent the reply to the list. > > Most of that has already been figured out in our python-wx package. > > Looking at Fedora, it looks like we just need to add their wxPython- > > 3.0.2.0-suppress-version-mismatch-warning.patch and wxPython-3.0.2.0- > > fix-wxcairo.patch and we'll be in sync. > > > Okay, I'll add those patches. I think I've gotten confused somehow, > because my cygport and files are based on the source package for > python-wx at > http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/python-wx/, > but the cygport in that archive also builds all of the other packages, > and doesn't use the system wxWidgets headers, hence me hacking in the > wxWidgets 3.0.4 files and having to build everything together. The work to split them out is already published: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/wxWidgets3.0.git https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python-wx.git I suppose I just never needed to actually rebuild python-wx after that, but the work was done in preparation. > wxPython 3.0.2 itself is shipped with wxWidgets 3.0.2 in the tarball > from wxpython.org, and seems to insist upon building its own copy of > wxwidgets. Maybe by default, but it is buildable without. > > No, that's just bound to cause problems. > > > This is confusing me because it seems to be what the existing packages do. That's what they *used* to do. I moved away from that for the reasons outlined. > > Look forward to the follow up. > > > > BTW, did you have any plans to figure out wxPython4? > > Good to hear. I do, I just haven't had the time yet and I figured it'd > be best to get wxPython 3 in really good shape (and get some practice > with packaging!) before sorting that one out. Fair enough. python-sip will need to be updated for that as well, which requires also updating python-pyqt5* in sync therewith, so this will need to be coordinated. -- Yaakov
Re: [ITA] python2-wx and related packages for wxPython and wxwidgets
On Thu, 2020-04-23 at 16:16 +0100, Hamish McIntyre-Bhatty wrote: > Thanks for your feedback. I wasn't expecting this to be accepted, it's > only my first try after all :) Please keep all discussion on list. > > I do not recommend building both the C++ libraries and Python bindings > > from the same source package, for several reasons: > > > > * Python bindings need to be updated/rebuilt with each new version of > > Python, which occurs much more frequently than updated versions of > > wxWidgets. Keeping them separate minimizes the rebuild times. > > > > * wxPython and wxWidgets versions don't always match, as you mentioned > > above. Building them separately avoids jumping through those sort of > > hoops. > > > > * wxPython 3 is obsolete anyway, with current support only for version > > 4 (which is still for wxWidgets 3), so this scheme won't carry forward > > anyway. > > > > Since the standalone wxWidgets3.0 package is already at 3.0.4, all you > > may want to do is revbump and rebuild python-wx. > > This is fair enough. However, I was unable to build wxPython against the > already-installed system version of wxWidgets, as that isn't how it was > intended to be compiled, and it would require large changes to the > pre-existing packaging. Most of that has already been figured out in our python-wx package. Looking at Fedora, it looks like we just need to add their wxPython- 3.0.2.0-suppress-version-mismatch-warning.patch and wxPython-3.0.2.0- fix-wxcairo.patch and we'll be in sync. > How about I instead ignore the wxwidgets packages built this way? This > will result in long build times as per the pre-existing packaging, but > there will probably not be much need to re-build this. No, that's just bound to cause problems. > > Do NOT drop this patch. You might be aligned now, but as soon as > > gcc/libstdc++ get updated, the mismatch will reoccur, and programs will > > unnecessarily fail again. > Okay, I shall re-instate it and re-build. > > > The few remaining wxGTK* patches: > > > - No longer apply without error and don't seem to be needed with the > > > newer wxwidgets version. > > Patches were added for a reason; if you don't understand what they do > > and why they're there, then you should be asking why rather than > > dismissing them. In the case of Gentoo's collision patch, this is > > needed to support parallel installations of X.Y versions of wxWidgets. > > The updated patch is named wxGTK-3.0.5-collision.patch. > > > Good to know, I will attempt to find updated patches. Is there an online > repository where they are held? I will go back through the other patches > which did not apply and attempt to find replacements/ask what they do. Look forward to the follow up. BTW, did you have any plans to figure out wxPython4? -- Yaakov
Re: [ITA] python2-wx and related packages for wxPython and wxwidgets
On Thu, 2020-04-23 at 15:02 +0100, Hamish McIntyre-Bhatty wrote: > I've gotten a more stable build of wxPython 3.0.2 and wxWidgets 3.0.4 to > build now. wxPython is now also built against the version of wxWidgets > that is installed on the system, avoiding ABI mismatch warnings and > strange behaviour/freezes hat I was experiencing before. I'm going to recommend nacking this in its current form. > The test packages can be downloaded from > https://hamishmb.com/files/cygwin-temp/. > > I say "various other packages", because building wxPython also builds > the following packages: > > libwx_baseu3.0_0, libwx_gtk3u3.0-devel, python-wxversion, > libwx_baseu3.0-devel, python2-wx, libwx_gtk2u3.0_0, python2-wxversion, > libwx_gtk2u3.0-devel, python-wx3.0, wxWidgets3.0-debuginfo, > libwx_gtk3u3.0_0, python-wx-tools > > The build process is a bit strange because wxPython 3.0.2 ships with > wxWidgets 3.0.2 instead of the system version (3.0.4), so my build > script downloads and re-patches the wxWidgets source before proceeding > with the build. As a result of using wxWidgets 3.0.4 instead of 3.0.2, > many patches are no longer needed as they were included upstream. > Removed patches and the reason for removal are listed at the end of this > email. I've probably got some of this wrong, but it does seem to work > well at least :) I do not recommend building both the C++ libraries and Python bindings from the same source package, for several reasons: * Python bindings need to be updated/rebuilt with each new version of Python, which occurs much more frequently than updated versions of wxWidgets. Keeping them separate minimizes the rebuild times. * wxPython and wxWidgets versions don't always match, as you mentioned above. Building them separately avoids jumping through those sort of hoops. * wxPython 3 is obsolete anyway, with current support only for version 4 (which is still for wxWidgets 3), so this scheme won't carry forward anyway. Since the standalone wxWidgets3.0 package is already at 3.0.4, all you may want to do is revbump and rebuild python-wx. > Patches removed and the reasons why: > > http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-abicheck.patch > - No longer needed as we're now using the same ABI for runtime and build > versions. Do NOT drop this patch. You might be aligned now, but as soon as gcc/libstdc++ get updated, the mismatch will reoccur, and programs will unnecessarily fail again. [snip] > The few remaining wxGTK* patches: > - No longer apply without error and don't seem to be needed with the > newer wxwidgets version. Patches were added for a reason; if you don't understand what they do and why they're there, then you should be asking why rather than dismissing them. In the case of Gentoo's collision patch, this is needed to support parallel installations of X.Y versions of wxWidgets. The updated patch is named wxGTK-3.0.5-collision.patch. -- Yaakov
Re: Remove nas/libaudio from libao
On Mon, 2020-04-06 at 15:33 -0400, Yaakov Selkowitz wrote: > I'm currently attempting to deprecate a number of older software stacks > in order to narrow down the maintenance burden of Cygwin. As part of > dropping Qt/KDE 3 and 4, nas/libaudio could also be dropped, except > that libao still has a NAS backend enabled. > > Given that, could you please rebuild libao w/o the NAS backend? At the > same time, perhaps the ESD backend should be replaced by the Pulse > backend, since libesd is just a compat client for PulseAudio at this > point? There are also a few patches which you'll want to include if > you haven't already: > > https://src.fedoraproject.org/rpms/libao/tree/master David, Thanks for updating libao. Since it wasn't enabled in 1.1.0-3, I neglected to mention that aRts is also being dropped as part of KDE 3. Could I bother you to rebuild libao one more time without the aRts backend, leaving only OSS and Pulse enabled? Thanks again, and sorry for the confusion. -- Yaakov
Re: [PATCH cygport] Allow manpage section .3G, used by OpenGL manpages
On Fri, 2020-04-10 at 15:48 +0100, Jon Turney wrote: > --- > lib/src_install.cygpart | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > LGTM, please merge. -- Yaakov
Re: Linux compiling in kernel
On Wed, 2020-04-08 at 15:18 +0530, vishnu via Cygwin wrote: > I have installed cygwin. > I am trying to compile linux kernel.It is for x86 platform. > But When I give below command: > #make > CC scripts/mod/empty.o > cc1: error: code model kernel does not support PIC mode > make[1]: *** [scripts/Makefile.build:268: scripts/mod/empty.o] Error 1 > make: *** [Makefile:1116: prepare0] Error 2 > > This error iam facing. > Can you please help me. > > Your help is highly appreciated. https://sourceware.org/legacy-ml/cygwin/2012-06/msg00221.html -- Yaakov -- 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: [ITA] util-linux
On Mon, 2020-04-06 at 02:13 -0700, Mark Geisert wrote: > I'd like to adopt util-linux from Yaakov if that's possible. To that end > I've re-spun the current (for Cygwin) 2.33.1 release with additional > patches to enable building 'taskset' and 'chrt'. Taskset works, chrt > "works" but can't do anything useful. Tested both 64- and 32-bit Cygwin. > > I've placed a copy of the source tarball at > http://maxrnd.com/~mark/cygwin/util-linux/util-linux-2.33.1-2-src.tar.xz > for your reviewing pleasure. I'd appreciate any comments or corrections. LGTM, package is yours now. -- Yaakov
rpmconf-like tool for Cygwin
I put together an initial draft of a tool meant to fill the role of rpmconf on RPM-based systems: https://github.com/yselkowitz/cygetcconf It definitely needs more work (and maybe a better name) before inclusion anywhere, but in the spirit of "early and often", it's a start. HTH, -- Yaakov
Re: cygport patches for consideration
On Tue, 2020-04-07 at 18:52 +0200, Achim Gratz wrote: > Yaakov Selkowitz writes: > > > support subdirectories in CPAN download URL > > > > There is no need for two variables to do the same thing. I like > > Reini's idea but let's call it CPAN_SUBDIR instead. What about the > > attached patch 0001? > > Well, Reini's chimed in after he'd seen my patch and I just added that > functionality on top of what was already implemented and in use by > myself. I guess I can change my cygport generator instead to use > CPAN_DIR when needed, but haven't got around doing so. Depending on its size, it would be nice to get this generator into cygport's tools, and could possibly be used as the basis for other such generators for other languages. > > > pkg_info.cygport: correct search order for Perl dependencies > > > > Let's improve the auto-detection instead. What about the attached > > patch 0002? > > Autodetection just doesn't work, with both false positives and negatives > in spades. Your proposed change probably produces more false negatives > with not much change in the false positive rate. So why bother? This change would reduce the number of possible dependencies found by only looking for those starting at the beginning of a line, which should eliminate false positives from perldocs and optional deps. So, yes, some more false negatives, but also much less false positives. When would there be false positives in this case? > There are actually multiple modules on CPAN attempting that sort of > thing, one slower than the other and still none of them gets it right in > all cases. So your chances of doing better with a shell script are > pretty much zero. All Perl distributions come with metadata that tell > you the dependencies among them already, so I just need a way to > transfer that exactly into the cygport file (which again gets generated > from that exact metadata, not written by hand). By way of example, > Cygwin has several packages that support Perl OO layers, of which there > are many (Moose, Mouse, Moo, Mo…) so a dependency check pulling in all > of them would end up creating a dependency chain that's at least 200 > more distributions. Note that I very deliberately do not package Moose, > which is huge. > > > > Automatically create a test release if the release string starts with > > > a literal "0" > > > > Nak. There is not necessarily any correlation between a -0.* release > > and whether it should be test or not. > > Then there ought to be. :-) No, not really. > > > Show pkg_tag in chatter > > > > Pushed a slightly different approach to master. > > I obviously like my patch better, because it keeps that line in the > output no matter what the tag is (plus colors it so it's easier to catch > a left over wrong tag when scrolling through the backlog). Bikeshedding. :-) There is an indication now of test:, which should suffice. > > Not sure what the > > second part of that patch is supposed to be, however, as there is no > > $pkg_testrelease variable in cygport. > > That's a vestigial of some other patch that was ordered before this one > before I created the branch, I think. Will ignore then. > > > lib/src_install.cygpart: correct test in make_etc_defaults, possibly > > > show diff > > > > The first part is ok once the commit is reworded. But when would a > > user see the output of a postinstall script? > > When looking in setup.log.full… this output used to go to the console, > but got axed quite some time ago. Most people aren't going to check the log for that, nor does the log allow them to do anything about it. > > What would make more sense is to have a utility akin to "rpmconf -a" > > on RPM-based systems which allows the user to compare existing files > > with their /etc/defaults and choose if and how to merge the > > differences. > > Sure, but that's not cygport's business, no? No, this would be something separate, or possibly part of cygutils. But's it's not the postinstall's business either AFAIAC. -- Yaakov
Re: Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)]
On Mon, 2020-04-06 at 23:55 +, JonY via Cygwin wrote: > On 4/6/20 10:07 AM, Jan Nijtmans via Cygwin wrote: > > Ping. > > > > Would it be possible to release a version of mingw64-i686-binutils with the > > same patch as done for binutils-2.34+1git.de9c1b7cfe-1? I suspect > > this would resolve the problem described here. > > Can you please report this issue to the binutils mailing list? I am > unfamiliar with the binutils internals to know what exactly went wrong. JonY, I think the relevant differences after 2.34 were PR24511 and PR25447, which are already fixed upstream: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=40bfb9762747f8336b17c70a0173d10200fa62eb https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=82f439d028c65663a0baf0a17ef5c4a2ea5c84a7 Adding those as patches to 2.34 should fix the issue without having to resort to a git snapshot. -- Yaakov -- 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: cygport patches for consideration
On Sun, 2020-04-05 at 20:54 +0200, Achim Gratz wrote:
> I've prepared a branch on top of current master for your perusal:
>
> https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/to-upstream
>
> As you can see they've been battle-tested by me for quite some time already:
>
> commit 779a7dd2fc834d45fb0f46cded647557ece17d8f (to-upstream)
> Date: Sat Apr 20 20:02:33 2013 +0200
>
> switch submodule gnuconfig to HTTPS protocol
>
> Live more easily with stupid firewalls...
Pushed to master.
> commit fd17952c457b808e360e5ed75ffae8d9571283ad
> Date: Sun Dec 6 13:32:38 2015 +0100
>
> lib/pkg_pkg.cygpart: uniquify requirements after the version has been
> stripped off
>
> * lib/pkg_pkg.cygpart: Move the "sort -fu" command to after the
> stripping of the version part. Otherwise some dependencies might
> get listed twice (perl_base does this sometimes).
Please no CVS style commit messages, I haven't done that in cygport for
over a decade. Code itself looks okay though.
> commit 40296640fdd0951d72ae0c107f2a46bbf8111ca3
> Date: Wed Oct 3 08:56:42 2012 +0200
>
> support subdirectories in CPAN download URL
>
> * cygclass/perl.cygclass: Allow CPAN_AUTHOR to have an /... suffix.
> This is necessary for some modules that put the distribution files
> in some subdirectory. Only upcase the actual author name (up until
> the first "/") and preserve case for the suffix part. By request of
> Reini Urban, also add a variable CPAN_DIR that alternately, if set,
> will be used to concatenate as ${CPAN_AUTHOR}/${CPAN_DIR} before
> determining the CPAN download URL. Neither variable should have a
> slash ("/") at the beginning or the end.
There is no need for two variables to do the same thing. I like
Reini's idea but let's call it CPAN_SUBDIR instead. What about the
attached patch 0001?
> commit 22b3f22b92c472df80be0fdcfd3854bfd19e16f8
> Date: Sun May 18 17:52:10 2014 +0200
>
> pkg_info.cygport: correct search order for Perl dependencies
>
> * lib/pkg_info.cygpart: Correct search order for Perl dependencies and
> suppress auto-generation of Perl dependencies when NO_PERL_DEPS is
> defined.
>
> Dependency generation for Perl at least is too simplistic and doesn't
> take into account that some modules required or used might actually be
> optional. It tends to generate too long dependency lists that vary
> with the Perl distributions already installed.
>
> For starters, the search order should be the reverse of
> @INC to skip dependencies that are built-in to perl already, but that
> doesn't pick up those modules that are needed with a higher version
> since only the presence of the module is detected. Files in site_perl
> shoud never be searched since these are local installs. Files in
> vendor_perl might be useful to check, however due to the version
> problem it is better to inject the module dpenedencies from the
> cygport file. So skip those searches when NO_PERL_DEPS is defined,
> which it will be for auto-generated cygport files for Perl
> distributions (the information is pulled from CPAN/MetaCPAN).
Let's improve the auto-detection instead. What about the attached
patch 0002?
> commit 2e61b06df6bd5a742f92c25b50d335945e17a34b
> Date: Sat Aug 18 12:43:23 2018 +0200
>
> bin/cygport.in: provide all-test / almostall-test commands on CLI for
> symmetry with package-test / pkg-test
Nak. almostall is a deprecated alias of all, there is no need for
symmetry here.
> commit 34e6e1f2dcdf45ac4a3f9e70cae1a8290d860cd9
> Date: Fri Nov 3 21:47:54 2017 +0100
>
> Automatically create a test release if the release string starts with a
> literal "0"
>
> * lib/pkg_pkg.cygpart: Test for a literal "0" as the first character
> in the release string and make a test release if true.
Nak. There is not necessarily any correlation between a -0.* release
and whether it should be test or not.
> commit 7f6fb93eaa9e4afe9e12bd57ebb3e8a4daa135ff
> Date: Sat Apr 8 17:00:34 2017 +0200
>
> Show pkg_tag in chatter
>
> lib/pkg_pkg.cygpart: inform when creating hint files for a test
> release
Pushed a slightly different approach to master. Not sure what the
second part of that patch is supposed to be, however, as there is no
$pkg_testrelease variable in cygport.
> commit 01e199380e32f214c2809d3dcc76f51b61de6d01
> Date: Sat Sep 17 10:07:10 2016 +0200
>
> lib/src_install.cygpart: correct test in make_etc_defaults, possibly show
> diff
>
> * lib/src_install.cygpart (make_etc_defaults): The preremove script
> only removes plain files when they match the default, so the
> postinstall script must not install files if _anything_ with the
> same name already exists. Change the test from '-f' to '-e'. If
> /usr/bin/diff is installed and the target is a
Re: [PATCH cygport 0/2] Add provides: and conflicts:
On Sun, 2020-04-05 at 15:17 +0100, Jon Turney wrote: > It seems I missed updating the check that all the expected package files > exist for source package hints. > > Patch attached (without this upload isn't permitted when there's no > pvr.tar.xz, as no corresponding hint exists, only pvr-src.tar.xz and > it's hint). Thanks, pushed to master. -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc.
Re: [PATCH cygport 0/2] Add provides: and conflicts:
On Sun, 2020-04-05 at 15:17 +0100, Jon Turney wrote: > It seems I missed updating the check that all the expected package files > exist for source package hints. > > Patch attached (without this upload isn't permitted when there's no > pvr.tar.xz, as no corresponding hint exists, only pvr-src.tar.xz and > it's hint). Thanks, pushed to master. -- Yaakov
Remove nas/libaudio from libao
David, I'm currently attempting to deprecate a number of older software stacks in order to narrow down the maintenance burden of Cygwin. As part of dropping Qt/KDE 3 and 4, nas/libaudio could also be dropped, except that libao still has a NAS backend enabled. Given that, could you please rebuild libao w/o the NAS backend? At the same time, perhaps the ESD backend should be replaced by the Pulse backend, since libesd is just a compat client for PulseAudio at this point? There are also a few patches which you'll want to include if you haven't already: https://src.fedoraproject.org/rpms/libao/tree/master Thanks, -- Yaakov
[ANNOUNCEMENT] pkgconf 1.6.3-1
The following packages have been uploaded to the Cygwin distribution: * pkgconf-1.6.3-1 * libpkgconf3-1.6.3-1 * libpkgconf-devel-1.6.3-1 * pkg-config-1.6.3-1 pkgconf is a program which helps to configure compiler and linker flags for development frameworks. It is an alternative to pkg-config. This is an update to the latest upstream release. The cross-pkg-config commands have been switched to symlinks based on upstream advice. -- Yaakov -- 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
pkgconf 1.6.3-1
The following packages have been uploaded to the Cygwin distribution: * pkgconf-1.6.3-1 * libpkgconf3-1.6.3-1 * libpkgconf-devel-1.6.3-1 * pkg-config-1.6.3-1 pkgconf is a program which helps to configure compiler and linker flags for development frameworks. It is an alternative to pkg-config. This is an update to the latest upstream release. The cross-pkg-config commands have been switched to symlinks based on upstream advice. -- Yaakov
Re: Mingw pkg-config not working
On Sun, 2020-04-05 at 15:51 +0200, Carlo B. via Cygwin wrote: > I wanted to report that I received a reply on the issue that I had opened > here: > > https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 Thanks for following up. > The report has been closed and I got this reply: > > "You should use a symlink instead of a wrapper script when using the > personality feature." > > I hope that somebody has understood what he means (posix is not > exactly my primary platform) and it could be useful for fixing the > issue. Yes, that gave me the information I needed. There is actually code within pkgconf to automatically load $PREFIX.personality when called as $PREFIX-pkg-config. This requires a packaging change on our end, which I'm incorporating into the latest release. > Il giorno gio 26 mar 2020 alle ore 14:07 Carlo B. > ha scritto: > > Hello, > > I implemented the solution to this problem as a patch to > > pkgconf.cygport as requested. > > I attached small patch to this email, which resolved the troubles with > > CMake and Meson. > > I hope that you will find it useful and some developers will gently > > apply the correction to fix the issue. > > > > Thank you very much for your time and your support. > > Sincerely, > > > > Carlo Bramini. > > > > Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney > > ha scritto: > > > On 20/02/2020 11:06, Carlo B. wrote: > > > [...] > > > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > > > example the one for i686 is: > > > > > > > > #!/bin/sh > > > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > > > > > But while this solution mostly works when you exec it from the command > > > > line, it makes impossible to detect the presence of the tool from > > > > meson and cmake build systems. > > > > If you try to do this on the bash prompt, you get: > > > > > > > > $ i686-w64-mingw32-pkg-config --version > > > > pkgconf: --version specified with other options or module names, > > > > assuming --modversion. > > > > Please specify at least one package name on the command line. > > > > > > > > and this is exactly what happens with those build systems (and perhaps > > > > others, I don't know): it tries to call pkg-config with "--version" > > > > and it executes the above script that calls pkgconf. But sadly, the > > > > presence of the "--personality" option makes the process to fail, > > > > because the "--version" is currently allowed only when no other > > > > options are added. > > > > And, for this reason, meson and cmake fail the detection of the tool. > > > > > > > > I have also filed an issue here for pkgconf: > > > > https://todo.sr.ht/~kaniini/pkgconf/10 > > > > because the solution is actually to ignore the presence of the > > > > "--personality" option when the "--version" is written, but > > > > unfortunately I have not received any feedback. > > > > > > > > So, I'm also writing here, with the hope that you could find a solution. > > > [...] > > > > > > Thanks for reporting this issue. > > > > > > I guess the alternative to fixing pkgconf would be to modify those > > > wrapper scripts to detect when the parameters are just '--version' (or > > > equivalent) and not use --personality in that case? > > > > > > These wrapper scripts are specific to cygwin (generated by the cygport, > > > see [1]) > > > > > > It's possible other distros have more sophisticated wrapper scripts, > > > which avoid this problem? > > > > > > If you do write or discover some improved wrapper scripts, a patch to > > > [1] to update them would be appreciated. > > > > > > [1] > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 -- Yaakov -- 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: Putting packages up for adoption
On Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote: > > On Mar 19 23:47, Yaakov Selkowitz wrote: > > > Hello Cygwin package maintainers, > > > > To that end, in the best interest of the community, please consider my > > > packages up for adoption. > > > > Yaakov > > > > There's no number of goldstars or plush hippos which would do justice to > > what you did for Cygwin, Yaakov. If there's something like the ULTIMATE > > PLUSH HIPPO REPLACING EVRY OTHER PLUSH HIPPO, you should get it. > > Well that's what I get for not checking the list for a week. > > I'm happy to oblige, and I have sort of a picture in my head of what that > might look like, but I'm not skilled at rendering it. If anyone has any > recommendations, please send to me directly by email. While I appreciate the thought, please don't trouble yourself over this. A nicely polished "gold watch" will do just fine. :-) -- Yaakov
vim 8.2.0486-1
The following packages have been uploaded to the Cygwin distribution: * vim-8.2.0486-1 * vim-common-8.2.0486-1 * vim-minimal-8.2.0486-1 * gvim-8.2.0486-1 * xxd-8.2.0486-1 * vim-doc-8.2.0486-1 Vim (Vi IMproved) is an almost compatible version of the UNIX editor vi. Almost every possible command can be performed using only ASCII characters. Many new features have been added: multilevel undo, command line history, file name completion, block operations, and editing of binary data. This is an update to the latest release, with new features: https://www.vim.org/vim-8.2-released.php -- Yaakov
[ANNOUNCEMENT] vim 8.2.0486-1
The following packages have been uploaded to the Cygwin distribution: * vim-8.2.0486-1 * vim-common-8.2.0486-1 * vim-minimal-8.2.0486-1 * gvim-8.2.0486-1 * xxd-8.2.0486-1 * vim-doc-8.2.0486-1 Vim (Vi IMproved) is an almost compatible version of the UNIX editor vi. Almost every possible command can be performed using only ASCII characters. Many new features have been added: multilevel undo, command line history, file name completion, block operations, and editing of binary data. This is an update to the latest release, with new features: https://www.vim.org/vim-8.2-released.php -- Yaakov -- 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
publicsuffix-list 20200326-1
The following packages have been uploaded to the Cygwin distribution: * publicsuffix-list-20200326-1 * publicsuffix-list-dafsa-20200326-1 A public suffix is one under which Internet users can (or historically could) directly register names. Some examples of public suffixes are .com, .co.uk and pvt.k12.ma.us. The Public Suffix List is a list of all known public suffixes. This is an update for the latest upstream changes to the PSL. -- Yaakov
[ANNOUNCEMENT] publicsuffix-list 20200326-1
The following packages have been uploaded to the Cygwin distribution: * publicsuffix-list-20200326-1 * publicsuffix-list-dafsa-20200326-1 A public suffix is one under which Internet users can (or historically could) directly register names. Some examples of public suffixes are .com, .co.uk and pvt.k12.ma.us. The Public Suffix List is a list of all known public suffixes. This is an update for the latest upstream changes to the PSL. -- Yaakov -- 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
ca-certificates 2.40-1
The following packages have been uploaded to the Cygwin distribution: * ca-certificates-2.40-1 Mozilla's CA root certificates for use with OpenSSL, NSS, GnuTLS, and other software that handles certificate verification. This is an update to the latest upstream release. Today's p11-kit 0.23.20 is required to handle the new features in this release. -- Yaakov
[ANNOUNCEMENT] ca-certificates 2.40-1
The following packages have been uploaded to the Cygwin distribution: * ca-certificates-2.40-1 Mozilla's CA root certificates for use with OpenSSL, NSS, GnuTLS, and other software that handles certificate verification. This is an update to the latest upstream release. Today's p11-kit 0.23.20 is required to handle the new features in this release. -- Yaakov -- 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
[ANNOUNCEMENT] p11-kit 0.23.20-1
The following packages have been uploaded to the Cygwin distribution: * p11-kit-0.23.20-1 * p11-kit-server-0.23.20-1 * p11-kit-trust-0.23.20-1 * libp11-kit0-0.23.20-1 * libp11-kit-devel-0.23.20-1 * libp11-kit-doc-0.23.20-1 Provides a way to load and enumerate PKCS#11 modules. Provides a standard configuration setup for installing PKCS#11 modules in such a way that they are discoverable. This is an update to the latest upstream release. -- Yaakov -- 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
[ANNOUNCEMENT] nano 4.9-1
The following packages have been uploaded to the Cygwin distribution: * nano-4.9-1 GNU nano is a small and friendly console-mode text editor, based on and mostly compatible with UW Pico. Besides basic text editing, nano offers many extra features like an interactive search and replace, go to line and column number, auto-indentation, feature toggles, internationalization support, and filename tab completion. This is an update to the latest upstream release. A default nanorc file is now provided. -- Yaakov -- 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
pcre 8.44-1, pcre2 10.34-1
The following packages have been uploaded to the Cygwin distribution: * pcre-8.44-1 * pcre2-10.34-1 * libpcre1-8.44-1 * libpcre16_0-8.44-1 * libpcre32_0-8.44-1 * libpcrecpp0-8.44-1 * libpcreposix0-8.44-1 * libpcre-devel-8.44-1 * libpcre-doc-8.44-1 * libpcre2_8_0-10.34-1 * libpcre2_16_0-10.34-1 * libpcre2_32_0-10.34-1 * libpcre2-posix2-10.34-1 * libpcre2-devel-10.34-1 * libpcre2-doc-10.34-1 The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. This is an update to the latest upstream releases. -- Yaakov
[ANNOUNCEMENT] pcre 8.44-1, pcre2 10.34-1
The following packages have been uploaded to the Cygwin distribution: * pcre-8.44-1 * pcre2-10.34-1 * libpcre1-8.44-1 * libpcre16_0-8.44-1 * libpcre32_0-8.44-1 * libpcrecpp0-8.44-1 * libpcreposix0-8.44-1 * libpcre-devel-8.44-1 * libpcre-doc-8.44-1 * libpcre2_8_0-10.34-1 * libpcre2_16_0-10.34-1 * libpcre2_32_0-10.34-1 * libpcre2-posix2-10.34-1 * libpcre2-devel-10.34-1 * libpcre2-doc-10.34-1 The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. This is an update to the latest upstream releases. -- Yaakov -- 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
p11-kit 0.23.20-1
The following packages have been uploaded to the Cygwin distribution: * p11-kit-0.23.20-1 * p11-kit-server-0.23.20-1 * p11-kit-trust-0.23.20-1 * libp11-kit0-0.23.20-1 * libp11-kit-devel-0.23.20-1 * libp11-kit-doc-0.23.20-1 Provides a way to load and enumerate PKCS#11 modules. Provides a standard configuration setup for installing PKCS#11 modules in such a way that they are discoverable. This is an update to the latest upstream release. -- Yaakov
nano 4.9-1
The following packages have been uploaded to the Cygwin distribution: * nano-4.9-1 GNU nano is a small and friendly console-mode text editor, based on and mostly compatible with UW Pico. Besides basic text editing, nano offers many extra features like an interactive search and replace, go to line and column number, auto-indentation, feature toggles, internationalization support, and filename tab completion. This is an update to the latest upstream release. A default nanorc file is now provided. -- Yaakov
Re: Putting packages up for adoption
On Sat, 2020-03-28 at 04:33 +0100, Marco Atzeri wrote:
> 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 ?
See https://src.fedoraproject.org/rpms/python3/blob/master/f/python3.spec#_1051
> 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)
--
Yaakov
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 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 Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption. I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them. However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
>
> I am considering to take over python, and I am building 2.7.17 and 3.8.2
> to see how complicate it is.
>
> One question on the cygport
>
> # see PEP 394
> dosym python${slot}.exe /usr/bin/python
> dosym python${slot}.exe /usr/bin/python2
>
> do you see any problem to use alternatives for the same scope ?
The reason I avoided using alternatives for this was consistency.
Since we don't build our packages in a clean (ch)root, if a maintainer
had such created such symlinks themselves, and they were to be picked
up during a build (very likely), or simply relied upon by scripts which
typically hardcode a generic version (very common), it would lead to a
package which would not run identically, or possibly not at all, on
other users' systems. I would discourage using alternatives here.
Of course, in the meantime, the Python world has moved very strongly to
3.x, to the point that upstream has dropped it, Fedora has mostly
deprecated it, and /usr/bin/python is now a symlink to python3 provided
by a separate package. However wrt Python 2, the only version we care
about at this point is 2.7, and while it's lifespan is limited, it is
still needed.
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
Re: [PATCH cygport 0/4] Test suite fixes
On Wed, 2020-03-25 at 16:34 +, Jon Turney wrote: > Fixup test suite > > Add a GitHub action to run the test suite (unfortunately, there seems to be > no way to turn on case-sensitivity in that environment, so we also need to > adjust tests to function with case-insensitive filesystem) > > Jon Turney (4): > Update tests for build-depends: appearing in source hints > Updates to tests for package updates > Add a GitHub action to run tests > Add some case variants to list of default documentation files > installed Never imagined cygport would get CI. I'll trust you know what you're doing wrt github integration, otherwise LGTM, please merge. -- Yaakov
Re: Putting packages up for adoption
On Tue, 2020-03-24 at 15:11 +0100, Jan Nijtmans via Cygwin-apps wrote:
> Op di 24 mrt. 2020 om 14:51 schreef Yaakov Selkowitz:
> > > However, I created a "fedora" branch in (upstream) Tcl, in which
> > > I merged the two patches from fedora. Result:
> > > <https://travis-ci.org/github/tcltk/tcl/builds/666214831>
> >
> > The errors I see there are "Test file error: can't find package
> > tcltests", which sounds like an issue with the test environment and not
> > on those changes.
>
> The point is, Tcl has a specific order of paths where it searches its
> environment, like an $auto_path variable. The test-suite tests
> this algorithm, and - apparently - the outcome of the algorith
> changed. You can add additional paths, but you cannot change
> the order of existing paths that are searched. So, sorry, but
> I respectfully disagree. The test-suite adds a path where it
> can find the "tcltests" package, the fedora changes result
> in not finding that package any more. That's a bug in the
> path search algorithm, which is modified by the fedora patch.
Fedora, and possibly other distros as well, set a default search path
for tcl that conforms with their desired filesystem layout -- having
all extensions under /usr/{lib,share}/tclX.Y instead of scattered
throughout /usr/{lib,share}. Customing the directory layout of
interpreted language extensions is a common and accepted downstream
practice. Therefore, it would be a bug in the test environment, e.g.
in not using the Tcl it is testing to determine where tcltests should
be installed.
--
Yaakov
Re: Putting packages up for adoption
On Tue, 2020-03-24 at 12:41 +0100, Jan Nijtmans via Cygwin-apps wrote: > Op di 24 mrt. 2020 om 00:38 schreef Yaakov Selkowitz: > > > Hm. It appears that they did: > > > <https://src.fedoraproject.org/rpms/tcl/tree/master> > > > > I meant their mingw-tcl package. > > Indeed, you are right! > > However, I created a "fedora" branch in (upstream) Tcl, in which > I merged the two patches from fedora. Result: > <https://travis-ci.org/github/tcltk/tcl/builds/666214831> The errors I see there are "Test file error: can't find package tcltests", which sounds like an issue with the test environment and not on those changes. > So, I wonder if they ran the Tcl test suite this gives not > much thrust, since they changes assumptions made > in the test-cases, assumptions that user-applications > and other environments could depend on. -- Yaakov
Re: [PATCH cygport 0/2] Add provides: and conflicts:
On Sat, 2020-02-08 at 13:46 +, Jon Turney wrote: > Add the ability to specify provides: and conflicts: hints in the cygport. > > Jon Turney (2): > Add test which compares hints with expected > Add provides: and conflicts: hints > > lib/pkg_pkg.cygpart | 74 ++- > testsuite/hints/meson.build | 1 + > .../libmultiple-devel-3.14-1.hint | 6 ++ > .../libmultiple1/libmultiple1-3.14-1.hint | 8 ++ > .../dist/multiple/multiple-3.14-1.hint| 6 ++ > testsuite/hints/multiple/multiple.cygport | 35 + > testsuite/hints/multiple/multiple.list| 1 + > .../obsoleted-by-single-2.3.4-1.hint | 8 ++ > .../dist/single/single-2.3.4-1.hint | 8 ++ > testsuite/hints/single/single.cygport | 25 +++ > testsuite/hints/single/single.list| 1 + > testsuite/meson.build | 2 + > testsuite/test-driver | 17 - > 13 files changed, 189 insertions(+), 3 deletions(-) > create mode 100644 testsuite/hints/meson.build > create mode 100644 > testsuite/hints/multiple/hints/multiple-3.14-1.x86_64/dist/multiple/libmultiple-devel/libmultiple-devel-3.14-1.hint > create mode 100644 > testsuite/hints/multiple/hints/multiple-3.14-1.x86_64/dist/multiple/libmultiple1/libmultiple1-3.14-1.hint > create mode 100644 > testsuite/hints/multiple/hints/multiple-3.14-1.x86_64/dist/multiple/multiple-3.14-1.hint > create mode 100644 testsuite/hints/multiple/multiple.cygport > create mode 100644 testsuite/hints/multiple/multiple.list > create mode 100644 > testsuite/hints/single/hints/single-2.3.4-1.x86_64/dist/single/obsoleted-by-single/obsoleted-by-single-2.3.4-1.hint > create mode 100644 > testsuite/hints/single/hints/single-2.3.4-1.x86_64/dist/single/single-2.3.4-1.hint > create mode 100644 testsuite/hints/single/single.cygport > create mode 100644 testsuite/hints/single/single.list Pushed to master, please test. -- Yaakov
Re: [PATCH cygport 0/2] Use meson auto-features option
On Tue, 2019-04-02 at 18:21 +0100, Jon Turney wrote: > Jon Turney (2): > meson: use auto-features option > Fixup __version_at_least a bit > > cygclass/meson.cygclass | 9 - > lib/check_funcs.cygpart | 6 +++--- > 2 files changed, 11 insertions(+), 4 deletions(-) Pushed to master, please test. -- Yaakov
Re: [PATCH cygport] Raise an error if we package a .stackdump file
On Fri, 2018-07-13 at 17:15 +0100, Jon Turney wrote: > If we end up with a .stackdump file in a package, this tends to suggest > something has gone wrong somewhere, so raise an error. > --- > lib/pkg_pkg.cygpart | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Pushed to master, please test. -- Yaakov
Re: [PATCH cygport 0/2] Better handling of build depends
On Tue, 2017-10-03 at 20:53 +0100, Jon Turney wrote: > Jon Turney (2): > Rename DEPEND to BUILD_DEPENDS > Pass BUILD_DEPENDS through to .hint for source package as > build-depends: > > lib/check_funcs.cygpart | 17 - > lib/pkg_pkg.cygpart | 5 + > 2 files changed, 17 insertions(+), 5 deletions(-) Pushed somewhat modified to git master, please test. -- Yaakov
Re: [PATCH cygport 0/3] Don't allow source packages to differ by arch
On Tue, 2018-02-13 at 13:12 +, Jon Turney wrote: > This is where I got to, after the discussion at [1]. > > [1] https://cygwin.com/ml/cygwin-apps/2017-05/msg00050.html > > Jon Turney (3): > Document src_unpack_hook and src_patch_hook > Add src_patch_apply_hook > Don't allow SRC_URI or PATCH_URI to depend on ARCH > > bin/cygport.in | 26 ++ > lib/check_funcs.cygpart | 1 + > lib/src_prep.cygpart| 41 - > 3 files changed, 63 insertions(+), 5 deletions(-) Pushed to master, please test. -- Yaakov
Re: Putting packages up for adoption
On Mon, 2020-03-23 at 22:04 +0100, Jan Nijtmans wrote: > Op ma 23 mrt. 2020 om 16:45 schreef Yaakov Selkowitz: > > The bulk of the patchset is from Fedora, but they haven't updated > > recently either. > > Hm. It appears that they did: > <https://src.fedoraproject.org/rpms/tcl/tree/master> I meant their mingw-tcl package. -- Yaakov
Re: Putting packages up for adoption
On Mon, 2020-03-23 at 13:07 +0100, Jan Nijtmans wrote: > Op zo 22 mrt. 2020 om 23:34 schreef Yaakov Selkowitz: > > A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats > > Cygwin as a Win32 platform, necessitating extensive patches to make it > > comply with *NIX/X11 standards. These patches CANNOT be dropped > > without breaking compatibility, since Win32 and X11 APIs do not > > interact. Fortunately, Tcl/Tk moves rather slowly, so the existing > > patches should serve you well for some time. > > Yes, I'm aware of that. Of course, I'll be very careful to guarantee > 100% binary compatibility. > > Still, I have some questions. At first, I noted that the current Tcl > version is 8.6.8, which is two patchlevels behind (released > December 22, 2017, more than 3 years old, while 8.6.10 > is released November 21, 2019, 4 months ago). Work to do! It's only two patchlevels. As I said, Tcl/Tk moves slowly. > So, I tried starting with x86_64-w64-mingw32. Here are my remarks. > > - There are 7 patches included. Only one of them applies cleanly, > the others are not really necessary (Please correct me if I'm wrong. > Let's go through them. The bulk of the patchset is from Fedora, but they haven't updated recently either. > - tcl-8.5.6-mingw.patch > This one is wrong. Changing tools for cross-compilations should > be done by "configure ... --host=x86_64-w64-mingw32" You could try without it, it's not clear from the logs why it was needed. > - tcl-8.6.1-nativezlib.patch > OK. Tcl provides its own zlib.dll, in case it's not available externally. > In Cygwin it is available (as "mingw64-x86_64-zlib"), which is prefered. > (I added "cygautoreconf", so this patch would be part of "configure") > - tcl-8.6.3-autopath.patch > Not necessary for building, Only needed when we want to run > Tcl in a non-standard installed directory. Keep in mind that the MinGW stuff can, and in some cases actually has to, run from within the sysroot. (On Linux, this is done with Wine, but obviously we can just run them directly.) Therefore, anything needed for running properly should be left in. > - tcl-8.6.5-hidden.patch > Wrong. This exports some internal symbols, which are not > supposed to be exported at all. This is done in Fedora for their Linux builds as well. According to the logs, expect uses (used?) these symbols. Since my Cygwin builds haven't carried the patch, maybe it's no longer needed, but I'd double- check first. > - tcl-8-6-5-paralle-make-fix.patch > Already fixed upstream. Besides, it's for unix/Makefile.in, not for mingw. Probably just carried over from the native build patchset when first created. > - tcl-mingw-w64-compatibility.patch > Already fixed upstream: > <https://core.tcl-lang.org/tcl/info/8fbf108ea77e5351> Ok. > - tcl-nativetclsh.patch > Only needed when running Tcl, not for building the libraries See above wrt keeping MinGW runnable. > Further on, I noted the the resulting hints file contains: > requires: tcl > while I would expect: > requires: mingw64-x86_64-zlib You'll have to diagnose this one. > Here is my cygport file so far. HTH, -- Yaakov
Re: Putting packages up for adoption
On Fri, 2020-03-20 at 10:29 +0100, Jan Nijtmans wrote: > Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz: > > To that end, in the best interest of the community, please consider my > > packages up for adoption. I don't expect that any one person will take > > all of them; some are obsolete and due for removal anyway, some should > > be picked up as soon as possible, and others might just end up > > bitrotting if nobody is interested in them. However, in whatever there > > is interest (or need), hopefully what is there now will serve as a > > strong foundation to on which to continue to build. > > I'm willing to adopt the tcl-related packages: > > mingw64-i686-tcl Yaakov Selkowitz > mingw64-i686-tk Yaakov Selkowitz > mingw64-x86_64-tcl Yaakov Selkowitz > mingw64-x86_64-tkYaakov Selkowitz > tcl Yaakov Selkowitz > tcl-itcl Yaakov Selkowitz > tcl-itk Yaakov Selkowitz > tcl-iwidgets Yaakov Selkowitz > tcl-tix Yaakov Selkowitz > tcl-tk Yaakov Selkowitz > tcl-togl Yaakov Selkowitz A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats Cygwin as a Win32 platform, necessitating extensive patches to make it comply with *NIX/X11 standards. These patches CANNOT be dropped without breaking compatibility, since Win32 and X11 APIs do not interact. Fortunately, Tcl/Tk moves rather slowly, so the existing patches should serve you well for some time. -- Yaakov
Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
On Sat, 2020-03-21 at 07:40 +0100, Marco Atzeri via Cygwin wrote: > Am 21.03.2020 um 05:55 schrieb Marco Atzeri: > > Am 20.03.2020 um 20:24 schrieb Hans-Bernhard Bröker: > > > Am 20.03.2020 um 00:18 schrieb Brian Inglis: > > > > On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote: > > > > > It seems something is adding 5M or more to the normal > > > > > size of the programs > > > > > > > > See attached for summary details by arch, but main points for both > > > > are, on x86_64: > > > [...] > > > > > > Could this be due to the ginormous number of targets configured into > > > the build? > > > > may be, as it also take ages to full compile with the > > current configuration: > > > > # --enable-shared > > CYGCONF_ARGS=" > > --enable-install-libiberty > > --disable-gdb > > --disable-libdecnumber > > --disable-readline > > --disable-sim > > --enable-64-bit-bfd > > --enable-targets=all > > " > > > > I am testing a build dropping the "enable-targets=all" > > and also forcing the "enable-shared" > > > > --enable-shared \ > > lt_cv_deplibs_check_method=pass_all If that doesn't work, feel free to borrow: https://github.com/cygwinports/binutils/blob/master/2.24.51-shared-libs.patch However, these libraries are (by design) API-unstable, so is not recommended to allow other code to link against these shared libs, therefore I would also suggest: https://github.com/cygwinports/binutils/blob/master/binutils.cygport#L30-L38 > > Hoping it will note ages again > > "NOT take" > > dropping the target seems to work very well > > current version > $ du -sb /usr/bin/gprof.exe > 5424147 /usr/bin/gprof.exe > > under build > $ du -sb gprof/gprof.exe > 19968 gprof/gprof.exe > > any clue why we are using a "enable-targets=all" options ? Not sure, but if it's just so that 32-bit utils can read 64-bit binaries (which is useful), --enable-targets=x86_64-pep should be enough. > Any cross compiler should use its own binutils not the cygwin one, correct ? Yes, regardless. -- Yaakov -- 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: Why is taskset still not in util-linux?
On Sat, 2020-03-21 at 01:37 -0700, Mark Geisert wrote: > Eliot Moss wrote: > > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > > > > > Cygwin doesn't support syscalls. I'd be very wary of any code which is > > > conditional on any #ifdef SYS_*. > > > > Of course. AFAICT taskset does not need the syscall, it just needs the > > library call to work. Asking about the syscall is, I suppose, a kind of > > Linux > > shorthand to see if something is supported on the particular platform. > > Mark's > > suggestion of providing a fake definition of that syscall definition is a > > workaround that may disturb the util-linux sources the least. > > What I did here was definitely a hack. I'm not sure it's the best solution. > > I fully concur with Yaakov's warning. There's two levels to syscalls as seen > in > programs like taskset. On one level, configure checks whether a particular > syscall exists on the compiling machine because different Linux kernels have > different sets of syscalls. On the second level, the program actually uses a > call named syscall() to call into specific kernel routines. > > On Cygwin, what to do about programs that assume they're running on Linux and > so > make use of the Linux syscall feature? We could dummy up a sys/syscall.h but > implementing a full syscall() interface would be a lot of work and do nothing > but slow down programs making heavy use of it; it adds a layer of indirection. I have considered doing just that on multiple occasions, but never got so desperate for it to bother. Keep in mind that kernel APIs often vary from their userspace wrappers (which is one of the two reasons userspace code calls syscall, the other being to access yet-unwrapped calls), meaning such an implementation wouldn't be a simple mapping to existing userspace functions. However, I wouldn't worry so much about performance, the point would be compatibility. > Yaakov, do you have a general strategy for dealing with syscall usage when > you've come across it in all the porting you've done? Cygwin-specific patch? That depends very much on what the code is trying to do (and which syscalls it wants to call!), but using #ifdef SYS_* to guard use of the corresponding userspace function call might be a first. There are definitely some of my packages which I had to patch around syscall assumptions, but I'd have to go find them. -- Yaakov -- 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: Putting packages up for adoption
On Sun, 2020-03-22 at 17:36 +0100, ASSI wrote: > ASSI writes: > > I see the same thing. I have no idea why the linker doesn't pick up the > > reference, but it produces exactly the same error when removing > > "-lcairo" from the link list, which looks suspicious. > > Indeed if I replace that library reference with "-l:libcairo.dll.a" then > things work. The other cairo-dependent modules seem to have the same > problem. Could anybody with some more knowledge of binutils than me > explain why that happens and how to fix it? Case sensitivity. The modules depend on symbols both from other dependent modules as well as the C libraries which they bind. While for many of the libraries these names are slightly different, e.g. -lPango and -lpango-1.0, in the case of Cairo, the only difference is case (-lCairo -lcairo). FWIW I always ran Cygwin with case sensitivity on (except when Windows upgrades forcibly disabled that behind my back), as these issues are not infrequent particularly when building. ExtUtils::Depends used to use full paths for the module imports, e.g. /usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/ -lPango, but I guess that changed at some point. If building with case sensitivity enabled is not an option, then I suggest patching EU::D to use full paths for module imports again. HTH, -- Yaakov
