Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
On 24/03/2024 15:07, Jon Turney wrote: On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote: I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 3.6 (EOL Dec 2021)? (I'm still dealing with cleaning up the final pieces of python27 detritus, but these should hopefully be much smaller tasks) nothing should depend from 3.5 not sure for 3.6
Re: [ITP] mandoc 1.14.6-1
On 11/03/2024 19:06, Christian Franke via Cygwin-apps wrote: I would like to contribute mandoc. Also present in Debian, Fedora, Ubuntu, ... and as the default man page formatter on *BSD. Useful to check man pages for compatibility with *BSD systems. GTG diff --git a/cygwin-pkg-maint b/cygwin-pkg-maint .. +mandoc Christian Franke
Re: [ITP] bmake 20240301-1
On 09/03/2024 13:44, Christian Franke via Cygwin-apps wrote: I would like to contribute bmake. Also present in Debian, Fedora, FreeBSD, Ubuntu, ... I occasionally use it to check whether Makefiles are compatible with non-GNU versions of make. added diff --git a/cygwin-pkg-maint b/cygwin-pkg-maint +bmakeChristian Franke It could be worth to rename bmake-20240301-1.src.patch and use PATCH_URI to avoid renaming the patch every time. https://cygwin.github.io/cygport/src_fetch_cygpart.html#PATCH_URI Regards Marco
Re: Problem with git on cygwin.com?
On 09/03/2024 17:10, Jon Turney wrote: On 09/03/2024 15:55, Marco Atzeri via Cygwin-announce wrote: I start to see $ git pull cyg...@cygwin.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Has the configuration been modified ? Probably. What is the repository URL you are trying to fetch from (git remote -v) last one ssh://cyg...@cygwin.com/git/cygwin-packages/xxhash.git with netcdf changing from / to ssh://cyg...@cygwin.com/git/cygwin-packages/netcdf.git ssh://matz...@cygwin.com/git/cygwin-packages/netcdf.git I bypassed the problem, but I am not sure that it will work for every other maintainer
Re: [ITP] afflib 3.7.20-1
On Wed, Mar 6, 2024 at 11:26 PM Christian Franke via Cygwin-apps wrote: > > Jon Turney wrote: > > On 06/03/2024 15:39, Christian Franke via Cygwin-apps wrote: > >> Jon Turney wrote: > >>> > >>> Thanks! > >>> > > libafflib_CONTENTS=" > usr/bin/cygafflib-*.dll > >>> > >>> Any reason why this package doesn't include the soversion, i.e. why > >>> not libafflib0? > >>> > >> > >> Libtsk and libafflib are my first library packages, so I'm not sure > >> what the policy is. My recent package libtsk has been accepted > >> without soversion, so I omitted it also here. I assumed that the > >> soversion will > > > > I'm going to suggest that was an oversight in the review. > > Should I also rename libtsk to libtsk19 in the planned sleutkit-*-2 > package which will add afflib support ? yes please > The original package is only a few days old and has possibly only a > small but experienced audience, so I expect not much worries if the > change will be explained in the announcement. not worries at all if you use libtsk19_OBSOLETES=libtsk see https://cygwin.github.io/cygport/pkg_pkg_cygpart.html#PKG_OBSOLETES Regards Marco
Re: [ITA] libcue
On 06/03/2024 10:07, Takashi Yano via Cygwin-apps wrote: I would like to adopt libcue package. $ git diff |grep "^+" +++ b/cygwin-pkg-maint +libcue Takashi Yano +libcuefile Takashi Yano Thanks Marco
Re: scallyweg: ‘strcasecmp’ was not declared in this scope
On 29/02/2024 17:58, Jon Turney wrote: On 29/02/2024 06:21, Marco Atzeri via Cygwin-apps wrote: Hi Jon, I have a strange case with nco https://github.com/cygwin/scallywag/actions/runs/8060036334/job/22015501908 While Scallyweg complains about ‘strcasecmp’ scope, local build runs fine. I saw the same also on previous build Can you check ? I can reproduce the build failure locally. From a brief inspection, this seems to make sense: strcasecmp is unconditionally defined by strings.h, which doesn't seem to be included anywhere in antlr. (There's maybe some way it gets indirectly included, maybe via string.h if __BSD_VISIBLE, but perhaps that's due to some local flags settings?) thanks for double checking The problem was subtle; the original and ancient https://www.antlr2.org/download/antlr-2.7.7.tar.gz need patching to work with recent compiler. I had a different version, with the same name, on my computer but I forgot to update the SRC_URI, so me locally and scallyweg were working on different source packages. Further info on: https://nco.sourceforge.net/#Source Regards Marco
Re: [ITP] sleuthkit 4.12.1
On 02/03/2024 13:05, Christian Franke via Cygwin-apps wrote:
I would like to contribute sleuthkit. Also present in Debian, Fedora,
Ubuntu, ...
SUMMARY="Tools for analysis of volume and filesystem data"
DESCRIPTION="The Sleuth Kit (TSK) is a collection of command line tools
for disk images. It allows to analyze volume and filesystem data,
examine disk layout, recover deleted files, etc. Many partition and
filesystem formats are supported."
libtsk_SUMMARY="${SUMMARY} (runtime)"
libtsk_devel_SUMMARY="${SUMMARY} (development)"
I'm not sure about the LICENSE string:
LICENSE="CPL-1.0 AND GPL-2.0-or-later"
The license/README.md file mentions a bunch of licenses, see comment in
cygport file. CPL-1.0 is the main license, one separate tool uses
GPL-2.0-or-later.
The source package supports reproducible builds except for libtsk-devel
(timestamps in *.a files).
Hi Christian,
usually we do no distribute static library
Any reason here ?
except that GTG
$ git diff |grep "^+"
+++ b/cygwin-pkg-maint
+sleuthkitChristian Franke
Regards
Marco
Re: [ITA] fontconfig
On Fri, Mar 1, 2024 at 2:28 PM Takashi Yano via Cygwin-apps wrote: > > Hi Jon, > > On Thu, 22 Feb 2024 06:37:13 +0100 > Marco Atzeri wrote: > > +gnutls Takashi Yano > > +libssh Takashi Yano > > +libvpl Takashi Yano > > +nettle Takashi Yano > > +unbound Takashi Yano > > On Thu, 22 Feb 2024 06:40:43 +0100 > Marco Atzeri wrote: > > +libvpl Takashi Yano > > On Fri, 23 Feb 2024 03:18:25 +0100 > Marco Atzeri wrote: > > +dbus Takashi Yano > > +fontconfig Takashi Yano > > +libass Takashi Yano > > +openjpeg Takashi Yano > > +orc Takashi Yano > > +snappy Takashi Yano > > Should I wait for your review and GTG for these packages? > Or may I go ahead? > you can go ahead. you are a senior maintainer ;-) , so no need for me to check every of your ITP/ITA except if you have doubts and/or questions
scallyweg: ‘strcasecmp’ was not declared in this scope
Hi Jon, I have a strange case with nco https://github.com/cygwin/scallywag/actions/runs/8060036334/job/22015501908 While Scallyweg complains about ‘strcasecmp’ scope, local build runs fine. I saw the same also on previous build Can you check ? Regards Marco
Re: [ITP] setuptools-scm
On 23/02/2024 23:21, Libor Ukropec via Cygwin-apps wrote:
I would like to propose new package python-setuptools-scm.
(Only if Marco wasn't faster)
setuptools_scm extracts Python package versions from git or hg metadata
instead of declaring them as the version argument or in a SCM managed file.
This package is the new dependency for existing "duplicity" Python
package. It prevents from upgrading to duplicity version 2.2.2
Thank you,
Libor
already uploading
$ git diff |grep "^+"
+++ b/cygwin-pkg-maint
+python-build Marco Atzeri
+python-pyproject_hooks Marco Atzeri
+python-setuptools_scmMarco Atzeri
python{38,39}-build are needed to test python{38,39}-setuptools_scm
I think they are not needed as dependency for your needs.
python-pyproject_hooks is needed to test build, but to test it needs
flaky, so more works is needed.
But this weekend I am busy with personal stuff
So it will wait
Regards
Marco
Re: python dependency for build only - ITP required?
On 23/02/2024 03:14, Marco Atzeri wrote: On 22/02/2024 20:59, Libor Ukropec via Cygwin-apps wrote: Hi cygwiners, I maintain duplicity package that in a new version brought yet another dependency not present in cygwin yet (setuptools_scm) but it is needed only just for build (candidate for BUILD_REQUIRES). What is the best approach? Is it even allowed to download the python dependency via pip install during the cygport or just propose a new package (ITP)? Thank you, Libor Hi Libor, it is an ITP approved by default as needed for another existing package. I can pack it for you as I manage most of the python packages Let me check Marco am I wrong that there is an undeclared dependency on another python module "build" ? Regards Marco
Re: [ITA] fontconfig
On 22/02/2024 11:53, Takashi Yano via Cygwin-apps wrote: On Thu, 22 Feb 2024 19:40:36 +0900 Takashi Yano wrote: LICENSE="MIT AND Unicode-DFS-2016" More accurately, it seems MIT-Modern-Variant. https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/COPYING +++ b/cygwin-pkg-maint +dbus Takashi Yano +fontconfig Takashi Yano +libass Takashi Yano +openjpeg Takashi Yano +orc Takashi Yano +snappy Takashi Yano thanks very much Takashi specially for dbus and fontconfig Regards Marco
Re: python dependency for build only - ITP required?
On 22/02/2024 20:59, Libor Ukropec via Cygwin-apps wrote: Hi cygwiners, I maintain duplicity package that in a new version brought yet another dependency not present in cygwin yet (setuptools_scm) but it is needed only just for build (candidate for BUILD_REQUIRES). What is the best approach? Is it even allowed to download the python dependency via pip install during the cygport or just propose a new package (ITP)? Thank you, Libor Hi Libor, it is an ITP approved by default as needed for another existing package. I can pack it for you as I manage most of the python packages Let me check Marco
Re: [ITA] gnutls
On 21/02/2024 13:09, Takashi Yano via Cygwin-apps wrote: I would like to adopt gnutls package. $ git diff | grep -E "^\+|^-" --- a/cygwin-pkg-maint +++ b/cygwin-pkg-maint -gnutls ORPHANED (Yaakov Selkowitz) +gnutls Takashi Yano -libssh ORPHANED (Yaakov Selkowitz) +libssh Takashi Yano +libvpl Takashi Yano -nettle ORPHANED (Yaakov Selkowitz) +nettle Takashi Yano -unbound ORPHANED (Yaakov Selkowitz) +unbound Takashi Yano Thanks Marco
Re: [ITP] libvpl
On 21/02/2024 17:41, Takashi Yano via Cygwin-apps wrote: I would like to propose new package libvpl. This is Intel GPU accelerator driver dispatcher, which has the same function with mfx_dispatch package. mfx_dispatch is used by ffmpeg package, however, recent ffmpeg complains that libmfx is deprecated and use libvpl instead. +libvpl Takashi Yano your score is now: $ grep Yano cygwin-pkg-maint |wc -l 63 :-) Thanks Marco
Re: Please update bvi to 1.4.2
On 21/02/2024 06:46, Takashi Yano via Cygwin-apps wrote: On Wed, 21 Feb 2024 06:39:18 +0100 Marco Atzeri wrote: Current cygwin bvi package is 1.3.2 (release date 2004-02-14). However, the latest stable version is 1.4.2 (release date 2023-03-07). Could maitainer please update the package? What can we do for this case? i.e. the maintainer exists but not active enough? do you want to join as co-maintainer ? For bvi package? Yes. -bvi Jari Aalto +bvi Jari Aalto/Takashi Yano Thanks Marco
Re: Please update bvi to 1.4.2
On 21/02/2024 00:26, Takashi Yano via Cygwin-apps wrote: On Thu, 18 Jan 2024 17:24:41 +0900 Takashi Yano wrote: Jari? On Sat, 23 Dec 2023 05:01:19 +0100 Marco Atzeri wrote: On 23/12/2023 04:45, Takashi Yano via Cygwin-apps wrote: +Jari Are you still with us ? Jari? Ping. On Thu, 14 Dec 2023 20:50:01 +0900 Takashi Yano via Cygwin-apps wrote: Hi, Current cygwin bvi package is 1.3.2 (release date 2004-02-14). However, the latest stable version is 1.4.2 (release date 2023-03-07). Could maitainer please update the package? What can we do for this case? i.e. the maintainer exists but not active enough? do you want to join as co-maintainer ?
Re: [ITA] tdb
On 20/02/2024 15:54, Takashi Yano via Cygwin-apps wrote: On Tue, 20 Feb 2024 19:41:00 +0900 Takashi Yano wrote: I would like to adopt tdb package. cygport file revised. $ git diff |grep "^+" +++ b/cygwin-pkg-maint +db Takashi Yano +tdb Takashi Yano
Re: [cygport] enabling a replacement for "objdump -d -l"
On 18/02/2024 20:51, ASSI via Cygwin-apps wrote: Cygport uses "objdump -d -l" to extract the list of source files that need to be copied into the debuginfo package. This operation triggers some O(N²) or even higher complexity and in addition has been getting slower in recent binutils releases due to more and more information being put into the object files. For gcc-11 extracting the debug source files takes up to 45 minutes per executable (up from about 15 minutes until 2.39) and for gcc-13 (with about 1.5 times the number of lines to extract) it is already taking more than two hours. So if you just package gcc-13 using a single thread you'd be looking on the order of 20 hours wall clock time, which is unacceptable. The deassembly implied by the "-d" (which is not the part that has the superlinear complexity btw, but produces a baseline of 2 hours single thread runtime all by itself) is also unnecessary to extract just the filenames of the source files as we throw away the location information anyway and so I've written a small parser that works on the DWARF dump instead (which can be produced in linear time with a very small scaling factor, so practically constant time even for very large executables). Unfortunately binutils does not yet offer a machine readable format for these dumps, but parsing the text is not too difficult even though the format is undocumented. The DWARF-5 documentation isn't the most enjoyable read, but it was helpful enough to figure it all out. I've also integrated the filtering of unrelated source file information (from system headers and external libraries). The end result is the same runtime as before on small object files, a factor up to 100 speedup for medium sized object files and speedups in the several thousands range for large sized ones (or a total single-thread runtime of less than 20 seconds for gcc-13). Integration into cygport is made configurable via a variable to be set in .cygportrc for instance in order to easily revert back to the original objdump invocation if necessary. I've been producing packages with that setup for a while now and have not noticed any errors. In principle the new parser actually produces more complete output as there can be multiple line number statements and hence source files per location, but objdump only lists one of them in the disassembly (at least sometimes). In practise I haven't found a package until now where the final list (after filtering) is different. if works should not be the default ? Reducing that time is very interesting for the big stuff Regards, Achim. Thanks Marco
Re: [ITP] f3 8.0
On 17/02/2024 15:05, Christian Franke via Cygwin-apps wrote: I would like to contribute f3. Also present in Debian, Fedora, Ubuntu, ... SUMMARY="Test real flash memory capacity" DESCRIPTION="f3 is a simple tool that tests flash cards capacity and performance to see if they live up to claimed specifications. It fills the device with pseudorandom data and then checks if it returns the same on reading. F3 stands for Fight Flash Fraud, or Fight Fake Flash." The source package supports reproducible builds. Hi Christian Build and package LGTM, not tested on any flash. Added on the Package list (cygwin-pkg-maint) LICENSE="GPL-3.0-only" seems correct to me Regards Marco
Re: [ITA] libid3tag
On 17/02/2024 04:18, Takashi Yano via Cygwin-apps wrote: I would like to adopt libid3tag. $ git diff | grep ^+ +++ b/cygwin-pkg-maint +libid3tagTakashi Yano +libmad Takashi Yano +taglib Takashi Yano +taglib-extrasTakashi Yano +utf8cpp Takashi Yano Thanks Marco
Re: libuv 1.48.0 fixes CVE-2024-24806
On 13/02/2024 01:47, Brian Inglis via Cygwin-apps wrote: All releases >= 1.24.0 confirmed as affected includes all Cygwin releases https://seclists.org/oss-sec/2024/q1/124 building on scallywag Regards Marco
Re: glibc drops libcrypt recommends libxcrypt
On 03/02/2024 10:49, Brian Inglis via Cygwin-apps wrote: Perhaps time for an update to libxcrypt and libcrypt-devel 4.4.36? noted Marco
Re: cygwin 3.4.10-1
On 29/11/2023 15:08, Corinna Vinschen via Cygwin-announce wrote: The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.10-1 * cygwin-devel-3.4.10-1 * cygwin-doc-3.4.10-1 just for me or the cygwin server still states 3.4.9 as last version ?
Re: Overlay server instructions
On 26/01/2024 23:04, Ihor via Cygwin-apps wrote:
Hi!
While I was trying to test how fine my package is installed and works, I relied on instructions at
https://www.cygwin.com/package-server.html. Specifically on "Creating an overlay Cygwin
package server" section, as it looked like the fastest way to test everything for me. But it
was a bit complicated to follow all instructions correctly from the first attempt as some things
there depend on environment setup and there where cross-references inside the guide. So, I've
written alternative straightforward instruction for "Overlay method":
---
- Install packages: calm, php
- `cd` to directory where you want to build overlay server
- Run:
mkdir -p ./cygwin/{x86_64,x86,noarch}/release
- Copy your built package folder (e.g: pigz-2.8-1.x86_64\dist\pigz) to
./cygwin/x86_64/release folder
- Run:
mksetupini --arch x86_64 --disable-check
missing-required-package,missing-depended-package
--inifile=./cygwin/x86_64/setup.ini --releasearea=./cygwin
cat ./cygwin/x86_64/setup.ini | bzip2 > ./cygwin/x86_64/setup.bz2
cat ./cygwin/x86_64/setup.ini | xz -6e > ./cygwin/x86_64/setup.xz
(Make sure ./cygwin/x86_64/setup.ini contains information about your package)
- Start http server in current dir:
php -S 0.0.0.0:1234
Hi Ihor,
this is superflous.
You can install from local "fake" download
I am using a shortcut to run setup from the local cache directory where
both the main Mirror and my own tree is located
C:\Download\cygwin_cache\setup-x86_64.exe -X -O -s
https://mirrors.kernel.org/sourceware/cygwin/ -s
http://matzeri.altervista.org -R C:\cygwin64 -n -L --local-package-dir
C:\download\cygwin_cache
- Run normal cygwin installer (with -X flag), select there TWO mirrors:
- http://127.0.0.1:1234/cygwin
- Another your favorite mirror
- Install your package and try how it works
---
It's also attached to this Email.
Maybe there is sense to replace content of "Creating an overlay Cygwin package
server" section by this manual? Am I writing this Email to correct mailing list?
we always appreciate any improvement to the documentation
Best regards,
Ihor
Regards
Marco
Re: [ITP] pigz 2.8
On 26/01/2024 22:02, pigz-cygwin-maintainer-0...@pm.me wrote: Hi Marco, Achim, Thank you for your time, the suggestions and fixes. Yes, looks like everything works fine with your changes. Also, as I understand, line `# REQUIRES="zlib"` can be removed? you need to use REQUIRES is cygport "fails" to detect an application requirement $ cygport pigz.cygport deps | cat cygwin-3.4.10-1 zlib0-1.3-1 so cygport detects a library dependency to "/usr/bin/cygz.dll" not to package zlib, as zlib is the source package or as binary contains only the library manual $ cygcheck -l zlib /usr/share/doc/zlib/ChangeLog /usr/share/doc/zlib/FAQ /usr/share/doc/zlib/LICENSE /usr/share/doc/zlib/README /usr/share/man/man3/zlib.3.gz I'm attaching here latest pigz.cygport with your fixes and without `# REQUIRES="zlib"` line. Best regards, Ihor Regards Marco
Re: [ITP] pigz 2.8
On 26/01/2024 08:00, ASSI via Cygwin-apps wrote: Marco Atzeri via Cygwin-apps writes: BUILD_REQUIRES="zlib-devel ncompress gzip" Why is ncompress a build dependency? Please remove if possible. Regards, Achim. it is used in the testing
Re: Unmaintained packages in base package set
On 03/01/2024 08:49, Marco Atzeri wrote: +librsvg2 Marco Atzeri just discovered that librsvg2 requires Rust by long time ** The librsvg 2.40.x series is the last "C only" version of the library; it was deprecated in 2017.** https://viruta.org/do-not-use-librsvg-2.40.x.html https://viruta.org/docs/fmq-porting-c-to-rust.pdf So until we have a Rust compiler no new release is possible Regards Marco
Re: [ITP] pigz 2.8
On 25/01/2024 19:52, Ihor via Cygwin-apps wrote:
Hi Jon! Thank you for the reply!
I see... Okay, I'm attaching the file here and going to send additional Email
with an public SSH key.
Best regards,
Ihor
Hi Ihor,
bottom post on the cygwin mail lists
I adjusted the file to build also the debugging portion
and to NOT build in the source tree.
Also adjusted the REQUIRES (not DEPENDS) for the build.
please double check
Regards
Marco
NAME="pigz"
VERSION=2.8
RELEASE=1
CATEGORY="Archive"
SUMMARY="Parallel Implementation of GZip"
DESCRIPTION="pigz, which stands for Parallel Implementation
of GZip, is a fully functional replacement for gzip that
takes advantage of multiple processors and multiple cores
when compressing data."
HOMEPAGE="https://zlib.net/pigz/;
LICENSE="zlib"
# REQUIRES="zlib"
SRC_URI="https://zlib.net/pigz/${NAME}-${VERSION}.tar.gz;
BUILD_REQUIRES="zlib-devel ncompress gzip"
src_compile() {
cd ${S}
lndirs
cd ${B}
echo ${CFLAGS}
cygmake CFLAGS="${CFLAGS}"
}
src_test() {
cd ${B}
cygmake test
}
src_install() {
cd ${B}
exeinto /bin
doexe pigz.exe
doexe unpigz.exe
doman pigz.1
}
Re: Tmux crashes on copy
On 25/01/2024 10:04, Yasuhiro Kimura via Cygwin-apps wrote:
Switching to cygwin-apps as my question is about .cygport file.
Is there any .cygport file that downloads snapshot of repository on
GitHub as source archive?
I'd like to refer to it in order to package latest snapshot of tmux.
Best Regards.
---
Yasuhiro Kimura
Hi,
I am using from time to time
the baseline is using
GIT_URI=
GIT_REV=
inherit git
instead of
SRC_URI
-
FORGE="mpi"
NAME="octave-mpi"
VERSION=3.1.1
OV=3.1.0
RELEASE=0.3
LICENSE="GPL-3.0-or-later"
CATEGORY="Math"
SUMMARY="Forge: bindings for basic Message Passing Interface (MPI)"
DESCRIPTION="${SUMMARY}
Contributed functions for GNU Octave from octave.sourceforge.net"
HOMEPAGE="https://gnu-octave.github.io/packages/mpi;
GIT_URI="https://github.com/carlodefalco/octave-mpi;
GIT_REV="a44db30"
SRC_DIR="${PN}"
inherit git
#SRC_URI="https://github.com/carlodefalco/octave-mpi/releases/download/v${OV}/${FORGE}-${OV}.tar.gz;
#SRC_DIR="${FORGE}"
..
--
Re: [ITA] pocl
On 03/01/2024 06:25, Takashi Yano via Cygwin-apps wrote: On Wed, 3 Jan 2024 14:14:12 +0900 Takashi Yano via Cygwin-apps wrote: I'd like to adopt the pocl package. - Update to latest upstream release. $ git diff |grep "^+" +++ b/cygwin-pkg-maint +pocl Takashi Yano Sorry, the latest upstream release is 5.0 however, 4.0 and later cannot be built in current cygwin because LLVM package is old. This update is up to 3.1. - Enable CUDA support. Curiosity, how do we support CUDA on Cygwin ? Regards Marco
Re: Unmaintained packages in base package set
On 03/01/2024 05:59, Takashi Yano via Cygwin-apps wrote: On Sat, 23 Dec 2023 04:51:22 +0100 Marco Atzeri wrote: On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: I suggest to start with the smaller beasts one by one or small groups I suspect GTK3 needs a lot of effort Thanks for the advice. Now, GTK3 package of 3.24.39 has been successfully built and packaged in my environment with updating some other related packages. So, firstly, I would like to take over following packages that are related to GTK3. fribidi 0.19.7 -> 1.0.13 libdatrie 0.28 -> 0.2.13 libthai 0.1.26 -> 0.1.29 pango1.0 1.40.14 -> 1.51.0 atk1.0 2.26.1 -> 2.38.0 gtk3 3.22.28 -> 3.24.39 $ git diff |grep "^+" +++ b/cygwin-pkg-maint +atk1.0 Takashi Yano +fribidi Takashi Yano +gtk3 Takashi Yano +libdatrieTakashi Yano +libthai Takashi Yano +pango1.0 Please feel free to take it over. I'd withdraw from librsvg2. +librsvg2 Marco Atzeri Thanks for taking over so many packages Marco
Re: Please update bvi to 1.4.2
On 23/12/2023 04:45, Takashi Yano via Cygwin-apps wrote: +Jari Are you still with us ? Jari? Ping. On Thu, 14 Dec 2023 20:50:01 +0900 Takashi Yano via Cygwin-apps wrote: Hi, Current cygwin bvi package is 1.3.2 (release date 2004-02-14). However, the latest stable version is 1.4.2 (release date 2023-03-07). Could maitainer please update the package?
Re: Unmaintained packages in base package set
On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: On Wed, 20 Dec 2023 12:16:05 + Jon Turney via Cygwin-apps wrote: I tweaked the unmaintained packages report [1] a bit so it identifies 'base' and 'direct or indirect base dependencies'. (But you're quite right to point out that the build requirements for a native Cygwin build are also important) [1] https://cygwin.com/packages/reports/unmaintained.html I would like to take over: libass fontconfig fribidi gnutls openjpeg librsvg2 snappy libssh dbus gtk3 orc tdb db libid3tag libmad taglib if no one like to do that, because the packages I maintain use them. all in one shot ? I suggest to start with the smaller beasts one by one or small groups I suspect GTK3 needs a lot of effort I could be interested in librsvg2 for the same reason of you I also wonder what should we do for unchanged packaegs such as: libbs2b libmodplug lame libasyncns avahi musepack if unchanged, are for the time being less urgent and i they do not see critical anyway
adopting
Following the inputs from Jon https://cygwin.com/packages/reports/unmaintained.html I am taking over $ git diff | grep "^+" +++ b/cygwin-pkg-maint +alternatives Marco Atzeri +bzip2Marco Atzeri +gdbm Marco Atzeri +libffi Marco Atzeri Regards Marco
Re: Unmaintained packages in base package set
On 20/12/2023 13:16, Jon Turney via Cygwin-apps wrote: On 06/12/2023 17:19, Brian Inglis via Cygwin-apps wrote: On 2023-12-05 06:07, Jon Turney wrote: [...] I tweaked the unmaintained packages report [1] a bit so it identifies 'base' and 'direct or indirect base dependencies'. (But you're quite right to point out that the build requirements for a native Cygwin build are also important) [1] https://cygwin.com/packages/reports/unmaintained.html I could take over alternatives and bzip2. It seems our alternatives is a subset of upstream https://github.com/fedora-sysv/chkconfig I will need to look on the details of the implementation. I think to remember that upstream went for a road not feasible for us, but last I looked was long time ago, and I could remember totally wrong. Nice to have for alternatives is to manage in some ways also DLLs so for me to remove the Lapack PATH hack. Is anyone looking at QT5 and QT6 ?
Re: [scallywag] libksba-1.6.5-1 install anomaly
On 19/12/2023 12:24, Jon Turney wrote: On 19/12/2023 05:29, Marco Atzeri via Cygwin-apps wrote: Hi Jon on jobs 7426 and (rerun) 7428 I see that a file is built but not installed -- config.status: creating src/ksba-config ... >>> libksba-devel-1.6.5-1.tar.xz tar: usr/bin/ksba-config: Cannot stat: No such file or directory -- but if I run exacly the same jobs locally, the file is installed and packed as expected This is weird. But this seems to be by upstream design: Changelog 2022-03-31 NIIBE Yutaka build: When no gpg-error-config, not install ksba-config. + commit 41000330cdba87afdf9ea0b481e0260dab262a54 * configure.ac (USE_GPGRT_CONFIG): New. * src/Makefile.am [USE_GPGRT_CONFIG]: Conditionalize the install of ksba-config. [...] Any clue if I should add something to the BUILD_REQUIRES="libgpg-error-devel pkg-config" It seems the latest libgpg-error-devel doesn't provide gpg-error-config. And indeed, upgrading to your recent update to libgpg-error-devel allows reproducing the problem locally. thanks Jon, a second pair of eyes is always useful. I noticed the absence of libgpg-error in the new upstream but not the conditional installation of ksba-config Upstream is playing weird scheme Regards Marco
Re: [Attn. MAINTAINER] gpg2
On 19/12/2023 17:01, ASSI via Cygwin-apps wrote: Hi Marco, Since the last update gpg2 segfaults, rolling back step by step points at libgpg-error as the culprit. Regards, Achim. Noted I think I should remove the libgpg-error latest and dig on the root cause Regards Marco
[scallywag] libksba-1.6.5-1 install anomaly
Hi Jon on jobs 7426 and (rerun) 7428 I see that a file is built but not installed -- config.status: creating src/ksba-config ... >>> libksba-devel-1.6.5-1.tar.xz tar: usr/bin/ksba-config: Cannot stat: No such file or directory -- but if I run exacly the same jobs locally, the file is installed and packed as expected $ find libksba-1.6.5-1.x86_64 -name ksba-config libksba-1.6.5-1.x86_64/build/src/ksba-config libksba-1.6.5-1.x86_64/inst/usr/bin/ksba-config $ grep -H ksba-config libksba-1.6.5-1.x86_64/log/* libksba-1.6.5-1.x86_64/log/libksba-1.6.5-1-compile.log:config.status: creating src/ksba-config libksba-1.6.5-1.x86_64/log/libksba-1.6.5-1-install.log: /usr/bin/install -c ksba-config '/pub/devel/libksba/libksba-1.6.5-1.x86_64/inst/usr/bin' libksba-1.6.5-1.x86_64/log/libksba-1.6.5-1-pkg.log:usr/bin/ksba-config Any clue if I should add something to the BUILD_REQUIRES="libgpg-error-devel pkg-config" the only difference between system I can think about is case Sensitive file system. But I can not test it as my system loses some functionality like network if I turn all the file system to be case sensitive $ uname -svr CYGWIN_NT-10.0-19045 3.4.10-1.x86_64 2023-11-29 12:12 UTC Regards Marco
Re: [attn maintainer] latex dependencies
On 14/12/2023 23:21, Ken Brown via Cygwin-apps wrote:
On 12/14/2023 2:46 PM, Marco Atzeri via Cygwin-apps wrote:
On 14/12/2023 16:50, Ken Brown via Cygwin-apps wrote:
On 12/14/2023 4:22 AM, Marco Atzeri via Cygwin-apps wrote:
Hi Ken,
it seems that both
texlive-collection-latex
texlive-collection-latexextra
depend on
texlive-collection-latexrecommended
that seems to me contra intuitive. can you please check ?
Thanks. The problem is that line 111 of
/usr/share/texmf-dist/tex/latex/hyperref/hyperref.sty contains
\RequirePackage{pdftexcmds}. Since hyperref is in the latex collection,
pdftexcmds should also be in that collection. I'll report this upstream.
But there's no bug in the latexextra package. The upstream latexextra
collection does indeed depend on the latexrecommended collection, and
this is reflected in the Cygwin packaging. So this dependency is by
design (and it makes intuitive sense to me).
Thanks for the report.
Ken
Thanks for taking care
Regards
Marco
Re: [attn maintainer] latex dependencies
On 14/12/2023 16:50, Ken Brown via Cygwin-apps wrote: On 12/14/2023 4:22 AM, Marco Atzeri via Cygwin-apps wrote: Hi Ken, it seems that both texlive-collection-latex texlive-collection-latexextra depend on texlive-collection-latexrecommended that seems to me contra intuitive. can you please check ? Hi Marco, Do you have an example of a LaTeX file that uses packages only in texlive-collection-latex but fails to compile if texlive-collection-latexrecommended is not installed? Without this, it's very hard for me to check if the occurrences of "pdftexcmds.sty" that you found really indicate dependencies. My technical knowledge of LaTeX is not good enough to determine this just from looking at the .sty files. See below for further comments on a few of the occurrences. the last gl2ps package had such issue https://github.com/cygwin/scallywag/actions/runs/7204747329/job/19626758626 adding the texlive-collection-latexrecommended as dependency, solved that issue https://github.com/cygwin/scallywag/actions/runs/7206881393/job/19632744288
[attn maintainer] latex dependencies
Hi Ken,
it seems that both
texlive-collection-latex
texlive-collection-latexextra
depend on
texlive-collection-latexrecommended
that seems to me contra intuitive. can you please check ?
$ cd /usr/share/texmf-dist/tex
$ grep -rH pdftexcmds.sty .
./generic/catchfile/catchfile.sty: \input pdftexcmds.sty\relax
./generic/filemod/filemod-expmin.tex: \input pdftexcmds.sty
./generic/oberdiek/iflang.sty: \input pdftexcmds.sty\relax
...
./generic/stringenc/stringenc.sty: \input pdftexcmds.sty\relax
./latex/hardwrap/hardwrap.sty:\IfFileExists{pdftexcmds.sty}{%
./latex/nlctdoc/nlctuserguide.sty:% copied from pdftexcmds.sty
$ cygcheck -p pdftexcmds/pdftexcmds.sty
Found 3 matches for pdftexcmds/pdftexcmds.sty
...
texlive-collection-latexrecommended-20230313-1 -
texlive-collection-latexrecommended: TeX Live latexrecommended package
collection
$ cygcheck -p catchfile/catchfile.sty
Found 3 matches for catchfile/catchfile.sty
...
texlive-collection-latexextra-20230313-1 -
texlive-collection-latexextra: TeX Live latexextra package collection
$ cygcheck -p stringenc/stringenc.sty
Found 3 matches for stringenc/stringenc.sty
...
texlive-collection-latex-20230313-1 - texlive-collection-latex: TeX Live
latex package collection
$ cygcheck -p latex/hardwrap/hardwrap.sty
Found 3 matches for latex/hardwrap/hardwrap.sty
...
texlive-collection-latexextra-20230313-1 -
texlive-collection-latexextra: TeX Live latexextra package collection
$ cygcheck -p nlctdoc/nlctuserguide.sty
Found 1 matches for nlctdoc/nlctuserguide.sty
texlive-collection-latexextra-20230313-1 -
texlive-collection-latexextra: TeX Live latexextra package collection
scallywag: build of gl2ps
Hi Jon, when I build the gl2ps package on my new system, I have no problems [ 44%] Linking C shared library cyggl2ps-1.dll [ 44%] Built target shared [ 55%] Building C object CMakeFiles/gl2psTest.dir/gl2psTest.c.o [ 66%] Linking C executable gl2psTest.exe [ 66%] Built target gl2psTest instead Scallwag is hitting an issue on the W32API https://github.com/cygwin/scallywag/actions/runs/7190889779/job/19584829876 I increase the verbosity but I do not see any obvious culprit make -f CMakeFiles/gl2psTest.dir/build.make CMakeFiles/gl2psTest.dir/depend make[2]: Entering directory '/cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build' cd /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build && /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles" /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/src/gl2ps-1.4.2 /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/src/gl2ps-1.4.2 /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build/CMakeFiles/gl2psTest.dir/DependInfo.cmake --color= make[2]: Leaving directory '/cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build' make -f CMakeFiles/gl2psTest.dir/build.make CMakeFiles/gl2psTest.dir/build make[2]: Entering directory '/cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build' [ 55%] Building C object CMakeFiles/gl2psTest.dir/gl2psTest.c.o /usr/bin/gcc.exe -DHAVE_PNG -DHAVE_ZLIB -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fdebug-prefix-map=/cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/build=/usr/src/debug/gl2ps-1.4.2-1 -fdebug-prefix-map=/cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/src/gl2ps-1.4.2=/usr/src/debug/gl2ps-1.4.2-1 -O2 -g -DNDEBUG -MD -MT CMakeFiles/gl2psTest.dir/gl2psTest.c.o -MF CMakeFiles/gl2psTest.dir/gl2psTest.c.o.d -o CMakeFiles/gl2psTest.dir/gl2psTest.c.o -c /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/src/gl2ps-1.4.2/gl2psTest.c In file included from /usr/include/GL/freeglut_std.h:144, from /usr/include/GL/glut.h:17, from /cygdrive/d/a/scallywag/gl2ps/gl2ps-1.4.2-1.x86_64/src/gl2ps-1.4.2/gl2psTest.c:58: /usr/include/w32api/GL/glu.h:68:78: error: expected ‘)’ before ‘*’ token 68 | void APIENTRY gluQuadricCallback(GLUquadric *qobj,GLenum which,void (CALLBACK *fn)()); any suggestion will be appreciated. Regards Marco
Re: [Attn Maintainer] json-c
On 01.10.2023 16:43, Jon Turney via Cygwin-apps wrote:
On 24/09/2023 13:40, Daisuke Fujimura via Cygwin-apps wrote:
Hi,
I previously reported that json-c.pc seems incorrect.
- https://cygwin.com/pipermail/cygwin/2023-August/254350.html
Since Marco isn't available at the moment, I did an NMU with this change.
- PATH=${B}:${PATH} ctest
+ PATH=${B}:${PATH} ninja_test
Not sure if this part is needed.
But it seems like it indicates a missing piece in cygport. Perhaps there
should be a src_test() defined by the cmake.cygclass which does
ninja_test or ctest depending on the generator?
Thanks Jon
I am also updating to 0.17-1
Regards
Marco
Re: cygport upgrade to use gnupg2/gpg2 if available
On 21.11.2023 07:58, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: After applying the attached patches, which add support for the newer gpg2 from gnupg2 if installed, the attached log second chunk shows the new keys verified by gpg2 added to lib/src_prep.cygpart ___gpg_verify(). Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and definition and __gpg_sign() for use in gpg signing of Cygwin patches and files. We should just switch to gpg2 an require that, there is no point in trying to use GPG 1.x anymore. https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7 Regards, Achim. should I just retire gpg 1.x and stop having gpg2 as different binary name ? $ for i in /usr/bin/gpg* ; do echo -n $i " : " ; cygcheck -f $i ; done /usr/bin/gpg.exe : gnupg-1.4.23-1 /usr/bin/gpg2.exe : gnupg2-2.2.35-2 /usr/bin/gpg-agent.exe : gnupg2-2.2.35-2 /usr/bin/gpgconf.exe : gnupg2-2.2.35-2 /usr/bin/gpg-connect-agent.exe : gnupg2-2.2.35-2 /usr/bin/gpg-error.exe : libgpg-error-devel-1.47-1 /usr/bin/gpgme-config : libgpgme-devel-1.9.0-1 /usr/bin/gpgme-tool.exe : libgpgme-devel-1.9.0-1 /usr/bin/gpgparsemail.exe : gnupg2-2.2.35-2 /usr/bin/gpgrt-config : libgpg-error-devel-1.47-1 /usr/bin/gpgscm.exe : gnupg2-2.2.35-2 /usr/bin/gpgsm.exe : gnupg2-2.2.35-2 /usr/bin/gpgsplit.exe : gnupg-1.4.23-1 gnupg2-2.2.35-2 /usr/bin/gpgtar.exe : gnupg2-2.2.35-2 /usr/bin/gpgv.exe : gnupg-1.4.23-1 /usr/bin/gpgv2.exe : gnupg2-2.2.35-2 /usr/bin/gpg-wks-server.exe : gnupg2-2.2.35-2 /usr/bin/gpg-zip : gnupg-1.4.23-1
Re: python2 removal
On 02.07.2023 16:30, Jon Turney wrote: On 04/06/2023 20:17, Jon Turney via Cygwin-apps wrote: [...] I think the next step is to remove the python27 package itself. This will make it impossible to install anything which requires it on new installations (existing installations which already have the package installed will be uneffected). Once the wailing, rending of garments and gnashing of teeth has died down, I can remove the python2 modules and bindings at leisure. Marco, As python maintainer, any thoughts on when to do this? Anything you want to get done before that? Marco, Unless I hear otherwise from you, I shall try to do this removal sometime this coming week. Jon, feel free. For personal reason I will not be present in the coming weeks Thanks MArco
Re: [ITA] ruby-cairo-gobject 4.1.7
On 23/06/2023 15:30, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-cairo-gobject Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5330596103 Changes: - Remove PKG_IGNORE - implib is not generated without the linker option `-out-implib` changed maintainer
Re: [ITA] ruby-gobject-introspection 4.1.7
On 12/06/2023 16:18, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gobject-introspection Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5244423932 changed maintainer let me know the next ones you plan to work on as I will be off in the coming days Regards Marco
Re: [ITA] ruby-glib2 4.1.7
On 10/06/2023 09:54, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-glib2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5228739944 Changes - Remove 2.2.0-rubygem-dirs.patch (Not applicable) - Add ldflags to output implib explicitly changed maintainer
Re: [ITP] ruby-mini_portile2 2.8.2
On 10/06/2023 06:58, Daisuke Fujimura via Cygwin-apps wrote: Could you please rename it to `ruby-mini_portile2` instead of `ruby-mini-portile2` so that it has the same name as the gem if possible? (underscore instead of hyphen) - https://rubygems.org/gems/mini_portile2 --- a/cygwin-pkg-maint +++ b/cygwin-pkg-maint @@ -3477,7 +3477,7 @@ ruby-method_source ORPHANED (Yaakov Selkowitz) ruby-mime-types ORPHANED (Yaakov Selkowitz) ruby-mime-types-data ORPHANED (Yaakov Selkowitz) ruby-minitestORPHANED (Yaakov Selkowitz) -ruby-mini-portile2 Daisuke Fujimura +ruby-mini_portile2 Daisuke Fujimura ruby-molinillo ORPHANED (Yaakov Selkowitz) ruby-multi_json ORPHANED (Yaakov Selkowitz) ruby-mysql2 Daisuke Fujimura done
Re: [ITP] ruby-red-colors 0.3.0
On 08/06/2023 15:21, Daisuke Fujimura via Cygwin-apps wrote: Hello, [ITP] A new package proposal: ruby-red-colors - ruby-red-colors - ruby-red-colors-doc Reason - The latest version of ruby-cairo depends on ruby-red-colors added
Re: [ITP] ruby-mini_portile2 2.8.2
On 06/06/2023 15:25, Daisuke Fujimura via Cygwin-apps wrote: Hello, [ITP] A new package proposal: ruby-mini_portile2 - ruby-mini_portile2 - ruby-mini_portile2-doc added Reason - Required to build ruby-nokorigi also changed maintainer
Re: [ITP] ruby-matrix 0.4.2
On 06/06/2023 12:27, Daisuke Fujimura via Cygwin-apps wrote: Hello, [ITP] A new package proposal: ruby-matrix - ruby-matrix - ruby-matrix-doc added Cygport - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-matrix Packages and logs - https://github.com/cygwin/scallywag/actions/runs/5187271145 Reason - The latest version of ruby-cairo depends on ruby-matrix also changed maintainer
Re: [ITA] ruby-hpricot 0.8.6
On 28/05/2023 08:23, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-hpricot Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5102728345 changed maintainer
Re: [ITA] ruby-byebug 11.1.3
On 28/05/2023 08:09, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-byebug Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5102700939 changed maintainer
Re: [ITA] ruby-unicorn 6.1.0
On 28.05.2023 03:27, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-unicorn Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5101529707 Changes - Add runtime dependencies explicitly changed maintainer
Re: [ITA] ruby-websocket-driver 0.7.5
On 28.05.2023 02:15, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-websocket-driver Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5069702023 Changes - Add runtime dependencies explicitly Runtime dependent gems are detected from installed gems, but since scallywag does not install gems that are not explicitly listed in the cygport file, it is unable to detect runtime dependencies through automatic detection. changed maintainer
Re: [ITA] ruby-raindrops 0.20.1
On 26.05.2023 11:59, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-raindrops Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5086500118 changed maintainer
Re: [ITA] ruby-sqlite3 1.6.3
On 26.05.2023 05:31, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-sqlite3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5086092688 changed maintainer
Re: [ITA] ruby-pkg-config 1.5.1
On 24.05.2023 16:05, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-pkg-config Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5068809911 changed maintainer
Re: Are the dependencies in libpq-devel broken? (Re: [ITA] ruby-mysql2 0.5.5)
On 22.05.2023 13:20, Daisuke Fujimura via Cygwin-apps wrote: I have libpq-devel installed but libpq5 is not installed. https://www.cygwin.com/packages/summary/libpq-devel.html Package: libpq-devel depends: cygwin, libintl8, libssl-devel, pkg-config Therefore, it seems to be failing to create hints. https://github.com/cygwin/scallywag/actions/runs/5037987712/jobs/9035199432#step:6:1480 ``` which: no cygpq-5.dll in (/cygdrive/d/a/scallywag/ruby-pg/ruby-pg-1.5.3-1.x86_64/inst/usr/bin:/usr/local/bin:/usr/bin:/usr/bin:/usr/local/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows/System32) ``` Can you fix the dependencies in libpq-devel? noted
Re: [ITA] ruby-syck 1.4.1
On 22.05.2023 16:38, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-syck Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5046835338 changed maintainer
Re: [ITA] ruby-yajl 1.4.3
On 22.05.2023 15:50, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-yajl Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5046323775 changed maintainer
Re: [ITA] ruby-puma 6.2.2
On 22.05.2023 15:07, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-puma Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5035403880 Changes - Add fedora patch changed maintainer
Re: [ITA] ruby-zoom 0.5.0
On 22.05.2023 15:03, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-zoom Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5045872311 Changes - LICENSE not defined - https://rubygems.org/gems/zoom (LICENSES: N/A) changed maintainer
Re: [ITA] ruby-pg 1.5.3
On 21.05.2023 04:27, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-pg Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5035067622 updated maintainer
Re: [ITA] ruby-oj 3.14.3
On 21.05.2023 02:42, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-oj Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5034669025 updated maintainer
Re: [ITA] ruby-nio4r 2.5.9
On 20.05.2023 16:48, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-nio4r Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5032657089 changed maintainer
Re: [ITA] ruby-kgio 2.11.4
On 20.05.2023 15:21, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-kgio Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5032362958 changed maintainer
Re: [ITA] ruby-mysql2 0.5.5
On 20.05.2023 14:50, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-mysql2 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5032175827 changed maintainer
Re: [ITA] ruby-hitimes 2.0.0
On 20.05.2023 14:04, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-hitimes Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5031987345 Changes: - Add ARCH=noarch - https://github.com/copiousfreetime/hitimes/blob/main/HISTORY.md#version-200-2019-09-23 > Remove the C and Java extensions as Process.clock_gettime() has the same resolution as what the extensions did. changed maintainer
Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
On 11.05.2023 15:57, Andrew Schulman via Cygwin-apps wrote: Entrusted with these strange superpowers, the following god-like beings walk unknown amongst us: Achim Gratz Corinna Vinschen Ken Brown Marco Atzeri Hippos! https://cygwin.com/goldstars/ I have the impression that Jon is also in the list another Hippo please for all the work he is doing on the infrastructure of the Cygwin project. Marco
Re: [ITA] ruby-curses 1.4.4
On 08.05.2023 01:02, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-curses Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4909628745 changed maintainer to you Thanks Marco
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 06.05.2023 15:12, Jon Turney wrote: On 06/05/2023 06:37, Marco Atzeri wrote: On 05.05.2023 22:44, Jon Turney wrote: On 05/05/2023 21:15, Marco Atzeri via Cygwin-apps wrote: On 02.05.2023 21:47, Achim Gratz via Cygwin-apps wrote: Achim Gratz via Cygwin-apps writes: I'm going to release Perl 5.36.1 to Cygwin in a few days. Done. Regards, Achim. I do not succeed to upgrade. Setup complains that perl 5.36.1 requires perl_0536 but nothing provides it Please can you run setup with '-v', and mail me the setup.log.full? attached Thanks. It looks like the conflict is over subversion-perl, which has yet to be rebuilt. If you uninstall that, you should be able to upgrade perl. I'm not quite sure why that's not indicated as a possible solution in the dependency conflict report. only pratical solution seems to force perl and perl_base upgrade so I can now work to upgrade the packages with perl dependecy Regards Marco
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 02.05.2023 21:47, Achim Gratz via Cygwin-apps wrote: Achim Gratz via Cygwin-apps writes: I'm going to release Perl 5.36.1 to Cygwin in a few days. Done. Regards, Achim. I do not succeed to upgrade. Setup complains that perl 5.36.1 requires perl_0536 but nothing provides it
Re: [Attn. MAINTAINERS] Heads up: Perl 5.36.1 is imminent
On 01.05.2023 22:00, Achim Gratz via Cygwin-apps wrote: I'm going to release Perl 5.36.1 to Cygwin in a few days. I've skipped 5.34 in order to update only every second year (which I've done since the 5.22 release). I haven't seen any trouble in my own Perl distribution packages from the update even though there are lots of them that haven't been updated since at least 5.22. So I hope it will be smooth sailing for anything else depending on Perl also. Any maintainer having packages that depend on perl5_032 should re-release or upgrade these soon-ish after the Perl update is available, as otherwise users are either blocked from upgrading Perl or will have to uninstall the affected packages. The rebuilt packages need to have a dependency on perl5_036, which cygport provides automatically. Regards, Achim. are you planning to upload 5.36.1 as test ? I will be on the road for 2 weeks in May and I will not be able to update any package starting from 8th May Regards Marco
Re: [ITA] ruby 3.2.2
On 20.04.2023 00:42, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4743191979 all yours Are you planning to adopt also the ruby-* sub-packages ? Regards Marco
Re: Has scallywag problems with requirements ?
On 16.04.2023 03:32, Marco Atzeri wrote:
On 15.04.2023 20:31, Jon Turney wrote:
Also, if the configure script supports it, wouldn't it be better to
set the PYTHON env var, or do --with-python=/usr/bin/python${v} than
fiddling with alternatives?
the configure seems to not accept the
--with-python=/usr/bin/python${v}
it continued to pick python3.9 also when I requested 3.8
I have however not checked the details of the configure.ac
for documentation this variant works
--with-python PYTHON=/usr/bin/python${v}
just implemented in version -2 as I was re-enabling the FTP
protocol that was disabled by default upstream
Regards
Marco
Re: Has scallywag problems with requirements ?
On 15.04.2023 20:31, Jon Turney wrote:
On 15/04/2023 19:27, Jon Turney via Cygwin-apps wrote:
On 15/04/2023 17:42, Marco Atzeri via Cygwin-apps wrote:
On 15.04.2023 18:34, Marco Atzeri wrote:
building libxml2
Jobs 5790
https://github.com/cygwin/scallywag/actions/runs/4708605404
I see
/cygdrive/d/a/scallywag/libxml2/libxml2.cygport: line 72:
alternatives: command not found
I don't understand how this cygport is supposed to work.
It simply runs 'alternatives', but being installed as
/usr/sbin/alternatives, it's not on the path.
you are right. It worked locally on modified PATH.
I will modify the cygport.
Also, if the configure script supports it, wouldn't it be better to set
the PYTHON env var, or do --with-python=/usr/bin/python${v} than
fiddling with alternatives?
the configure seems to not accept the
--with-python=/usr/bin/python${v}
it continued to pick python3.9 also when I requested 3.8
I have however not checked the details of the configure.ac
Regards
Marco
Re: [ITA] rubygems 3.4.12
On 14.04.2023 14:55, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=tree;h=refs/heads/rubygems;hb=refs/heads/rubygems Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/4698944134 I changed maintainer-ship to you Thanks Marco
Re: Has scallywag problems with requirements ?
On 15.04.2023 18:34, Marco Atzeri wrote: Hi Kon, Jon (of course) building libxml2 Jobs 5790 https://github.com/cygwin/scallywag/actions/runs/4708605404 I see /cygdrive/d/a/scallywag/libxml2/libxml2.cygport: line 72: alternatives: command not found but python38 python39 python-38-devel python39-devel all should require alternatives $ grep require python38-devel/python38-devel-3.8.16-1.hint requires: alternatives bash pkg-config python38 python38-setuptools libcrypt-devel Regards Marco It seems there are other general issues >>> Compiling make-4.4.1-2.x86_64 cp: cannot stat '/usr/share/gettext/config.rpath': No such file or directory autoreconf-2.71: export WARNINGS= autoreconf-2.71: Entering directory '.' autoreconf-2.71: running: autopoint --force Can't exec "autopoint": No such file or directory at /usr/share/autoconf2.7/Autom4te/FileUtils.pm line 293. autoreconf-2.71: error: autopoint failed with exit status: 1 *** ERROR: autoreconf failed
Has scallywag problems with requirements ?
Hi Kon, building libxml2 Jobs 5790 https://github.com/cygwin/scallywag/actions/runs/4708605404 I see /cygdrive/d/a/scallywag/libxml2/libxml2.cygport: line 72: alternatives: command not found but python38 python39 python-38-devel python39-devel all should require alternatives $ grep require python38-devel/python38-devel-3.8.16-1.hint requires: alternatives bash pkg-config python38 python38-setuptools libcrypt-devel Regards Marco
Re: ConTeXt no longer available on Cygwin
On 14.04.2023 00:25, Ken Brown via Cygwin-apps wrote: [This is a follow-up to https://cygwin.com/pipermail/cygwin/2023-March/253326.html, on the cygwin list.] On 3/24/2023 11:00 AM, Ken Brown via Cygwin wrote: On 3/22/2023 12:56 PM, Ken Brown via Cygwin wrote: As I mentioned in the announcement of TeX Live 2023, there has been a major change in ConTeXt; see https://tug.org/texlive/bugs.html Briefly, ConTeXt development has been moved out of TeX Live into a separate project. Unfortunately, the maintainer of that project decided to remove Cygwin support, so I cannot easily provide a context binary. One Cygwin user of ConTeXt complained upstream, to no avail. At some point I will probably remove the texlive-collection-context package, which is now useless. But I am waiting to see how other distros are going to deal with this change. If you will be greatly inconvenienced by the absence of a context binary, please let me know by replying to this message. There may or may not be anything I can do about it. This turned out to be simple to fix. I will do that shortly, but first I want to finish discussing this with TeX Live maintainers for other distros. This turns out to be a complete mess, with no uniformity among maintainers, so I'm on my own. The simplest way for me to handle it is to package the missing binary as part of texlive-collection-context.(*) This presumably means that the latter can no longer be a noarch package. Jon, can you (or calm) cope with a package changing from noarch to x86_64? Alternatively, I could make a completely new package, say texlive-context-bin, which contains only the binary, if you think that's better. It require a manual intervenction on the repository but we have done it in the past in both directions. Ken (*) It used to be contained in the texlive package, but the sources are no longer in the texlive source tree, and the build system is completely different.
Re: python2 removal
On 03.04.2023 03:08, marco atzeri wrote: On Sun, Apr 2, 2023 at 11:47 AM Jon Turney via Cygwin-apps wrote: extra-cmake-modulesextra-cmake-modules ORPHANED (Yaakov Selkowitz) [†] probably ok, but should probably update & rebuild I adopted extra-cmake-modules and appstream that is required by it. I will upload as soon finished to clean both builds Regards Marco
Re: [ANNOUNCEMENT] cygport 0.36.1-1
On 26.03.2023 18:43, Jon Turney wrote: On 11/03/2023 20:15, Marco Atzeri via Cygwin-apps wrote: On 11.03.2023 17:29, Jon Turney via Cygwin wrote: The following packages have been uploaded to the Cygwin distribution: * cygport-0.36.1-1 Hi Jon, I was a bit too late... No problem, I can always make more releases! Updating the python 3.[89] subpackages, I finally hit a case where setup.py and setup.cfg are missing as obsolete. Attached patch solved the issue and allowed to build python-platformdirs-3.1.1-1 Thanks. I'm not sure if always emitting a warning if pyproject.toml is missing is good idea, so I might do a bit of tweaking, but I applied this patch. (as that will probably warn if you ever try to build an old version of a project, which is still perfectly buildable due to having a setup.py) Hi Jon, what about his form ? if [ ! -e pyproject.toml ] then warning "No pyproject.toml (PEP 518) detected in source tree" warning "Trying previous Distutils method." if [ ! -e setup.py ] && [ ! -e setup.cfg ] then error "No Python Distutils module neither pyproject.toml (PEP 518) detected in source tree" fi fi I would any some version of it released before I upload the git source that has only pyproject.toml. Otherwise scullywag will fail the build. Regards Marco
Re: python pylint missing dependencies
On 16.03.2023 17:44, Brian Inglis via Cygwin-apps wrote:
Hi Marco,
Trying to run python pylint3.6/7/8/9 pylint3.6/7/8 need
typing_extensions (see at bottom):
$ pip3.6/7/8 install typing_extensions
as python typing is only available as python{,2,27}-typing, and appears
not to have been updated to python3:
python-typing ORPHANED (Yaakov Selkowitz)
Noted. I already built python-typing-extensions
I will upload shortly for 3.8 and 3.9
All plus pylint3.9 also need python platformdirs (3.6 not available)
(see at bottom):
DEPEND/BUILD_/REQUIRES=python3?-platformdirs
although if defined in DEPEND/BUILD_REQUIRES should be detected by
cygport python dependency checker IIRC?
Anything I could do to help diagnose or fix this while your system is U/S?
Maybe a dependency no longer required another expected dependency:
I have already built platformdirs. It replaces appdirs.
Re: [ITP] bzip3 1.3.0
On Sat, Apr 8, 2023 at 7:53 AM Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > [ITP] A new package proposal: bzip3 > > - bzip3 > - libbzip3_0 > - libbzip3-devel GTG for me, but I can not add the pkg to the list so someone else need to do it
Re: python2 removal
On Sun, Apr 2, 2023 at 11:47 AM Jon Turney via Cygwin-apps wrote: > > On 14/03/2023 19:17, Jon Turney via Cygwin-apps wrote: > > On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote: > >> > >> This has come up in discussion a few times, and is now well overdue, I > >> think. > >> > >> Python 2.7 is the last python2 version, which was sunsetted on January > >> 1, 2020. > >> > > [...] > >> > >> 3) There might also still be some other packages lurking which just > >> install a script with a shebang containing 'python', and assume that > >> python is python2. I don't know how we could identify those. > > > > The remaining cases of packages which have a dependency on python and/or > > python2 are either this (packages which contain a python script with a > > python shebang line), or the other case which I hadn't previously > > considered - a package which contain an executable or shared library > > linked with libpython2.7.dll. > > > > So, again I need inspect these to determine what should happen to them. > > So here's the list, with *tentative* notes of the disposition for each > package. > > As before, I might look at rebuilding some of the more important > packages, as time permits, and some of these are candidates for removal > if not updated, but obviously adoptions and input on what is no longer > useful is welcomed! > > I've also adjusted numerous old package versions which depend on > 'python' to depend on 'python2' when that's what they actually require, > so they will become not-installable when python2 is removed, and can > subsequently be expired. > > (often these are historical package requirements which were synthesized > from the current package requirements from before we had per-version > requirements) > > Contrariwise, a few packages (e.g. clang, ibus, libglib2.0-devel, llvm, > lv2-devel, mysql-server, pulseaudio-equalizer) which depend on python2, > but contain a script which appears to work with python3 have been > adjusted to depend on 'python' > Thanks John > > source package package maintainer > > notes disposition > > boost boost-build ORPHANED (Yaakov Selkowitz) > > [†]unclear? depends on python2 and python3? > > boost libboost_mpi_python*" > > [*]libboost_mpi_python3* exists, so just remove? > > boost libboost_numpy* " > > [*]libboost_numpy3* exists, so just remove? > > boost libboost_python*" > > [*]libboost_python3_* exists, so just remove? I will adopt boost. > > extra-cmake-modulesextra-cmake-modules ORPHANED (Yaakov Selkowitz) > > [†]probably ok, but should probably update & rebuild I will look on it > > inkscape inkscapeORPHANED (Yaakov Selkowitz) > > [†][§][5] update and rebuild I will adopt inkscape > > octave-miscellaneous octave-miscellaneousMarco Atzeri > > [†]? ignore the dependency, it is coming from a demo script. I will remove on next octave rebuild > > vimvim-python Marco Atzeri > > empty and obsolete, remove Noted
Re: How to avoid tying up scallywag
On Mon, Mar 20, 2023 at 12:04 AM Ken Brown via Cygwin-apps wrote: > > Jon, > > I'll be ready to go with TeX Live 2023 in a couple days. That involves > about 60 packages. If I push them all at once, I'm afraid that would > tie up scallywag and make it unusable by others. I was thinking of > pushing them in batches of 5, with a couple hours in between batches. > But I don't know how many jobs scallywag can do at once. What do you think? > > Ken It is very easy in reality. Jon will surely implement the "nice" token to lower the priority of your jobs ;-) No preference for me , as I am out of service. Regards Marco
Re: xlsx2csv package may not be required.
On Fri, Mar 17, 2023 at 10:29 AM Adam Dinwoodie via Cygwin-apps wrote: > > On Thu, Mar 16, 2023 at 07:58:48PM -0600, Doug Henderson via Cygwin-apps > wrote: > > There is a current pure python version of xlsx2csv which runs for many > > versions of Python 2 and Python 3. > > > > It may not be necessary to provide a package for it in cygwin. > > Instead, users may install the pure python package from PYPI > > https://pypi.org/ using pip or another python package manager. > > Installing using pip or similar is an option for the vast majority of > packages that are available through the Cygwin installer; by that logic > it wouldn't make sense to provide most of the Python packages we > provide. Which wouldn't be an invalid strategy, but it would be a very > big change in how we handle things! > > I think the advantage of using the Cygwin packages is a better > likelihood of packages actually being compatible with Cygwin, rather > than having some weird and unpredictable package dependency issue. A > pure Python xlsx2csv is very unlikely to be affected by that sort of > issue, but providing it as a Cygwin package means users shouldn't need > to even think about whether the package is a pure Python package or not. I agree with Adam. I would have no problem to release the python package no if not for the problem to the laptop I guess one month from now I will be able to be operative again (assuming the target supplier of the laptop https://frame.work/ will not have delivery problem) Regards Marco
Re: python2 removal
On Wed, Mar 15, 2023 at 1:56 PM Brian Inglis via Cygwin-apps wrote: > > On 2023-03-14 13:17, Jon Turney via Cygwin-apps wrote: > > On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote: > >> > >> This has come up in discussion a few times, and is now well overdue, I > >> think. > >> > >> Python 2.7 is the last python2 version, which was sunsetted on January 1, > >> 2020. > >> > > [...] > >> > >> 3) There might also still be some other packages lurking which just > >> install a > >> script with a shebang containing 'python', and assume that python is > >> python2. > >> I don't know how we could identify those. > > > > The remaining cases of packages which have a dependency on python and/or > > python2 > > are either this (packages which contain a python script with a python > > shebang > > line), or the other case which I hadn't previously considered - a package > > which > > contain an executable or shared library linked with libpython2.7.dll. > > > > So, again I need inspect these to determine what should happen to them. > > Add: > > $ apt-cyg category Python | grep -iv python | xargs apt-cyg listall | awk > '...' Is apt-cyg an "official" tool now :-? > scons 4.4.0-1 x86_64 scons is already built for 3.9
service interruption :-(
Hi Guys, just to inform you that my old laptop is seriously considering to retire itself ; it froze several time this early morning. I will need to buy and configure a new laptop before being fully operative again. In the mean time if someone can upload job 5600 as test, I will appreciate. It is the latest upstream cmake 3.25.3 with python3.9 Unfortunately I was just at the start of updating all python sub-packages for only 3.8 & 3.9 before working on 3.11. No more activity on 3.6 & 3.7 The following (source) packages were already updated to latest upstream python38 3.8.16-1 python39 3.8.16-1 python-pip23.0.1-1 I assume I will be able to recover the data from disk, but if not I will need some additional time to rebuild them. Regards Marco
Re: disk space limit of scallywag ?
On 12.03.2023 22:00, Jon Turney wrote:
On 12/03/2023 20:33, Marco Atzeri via Cygwin-apps wrote:
On 12.03.2023 18:39, Jon Turney wrote:
On 12/03/2023 17:08, Marco Atzeri via Cygwin-apps wrote:
Hi Jon,
what is the current disk space limit of scallywag ?
jobs 5594
https://github.com/cygwin/scallywag/actions/runs/4397354263/jobs/7700519955
..
scallywag: staging/cmake/vim-cmake/vim-cmake-3.23.2-2.hint
scallywag: staging/cmake/vim-cmake/vim-cmake-3.23.2-2.tar.xz
xz: (stdout): Write error: No space left on device
tar: /cygdrive/d/a/scallywag/scallywag/builddir.tar.xz: Cannot
write: Broken pipe
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Traceback (most recent call last):
The the VM is supposed to have at least 14GB free disk space, which
seems like it should be enough.
But maybe there's something I'm doing wrong here (like trying to
create this archive on the wrong drive or something...). Let me look
into this a bit more...
just the testing is requiring
3.6G Tests
so no doubt it hits the 14GB issues
Yeah. It seems to be the test suite which takes a fantastic amount of
disk space (and time), so as a workaround for the moment, adding the
control token 'notest' should let it build and package successfully.
Hi Jon,
will be possible to pass the token notest to the sub-command rerun ?
For the time being I used SCALLYWEG="notest"
PS: there is a mismatch in the documentation
subcommands:
{cancel,deploy,help,rerun}
cancel cancel job
deploy deploy job
helpthis help
rerun re-run job
While on the web:
rebuild
rebuild a job (e.g. if it failed due to some transient condition, or
optionally with different tokens).
Regards
Marco
Re: disk space limit of scallywag ?
On 12.03.2023 18:39, Jon Turney wrote: On 12/03/2023 17:08, Marco Atzeri via Cygwin-apps wrote: Hi Jon, what is the current disk space limit of scallywag ? jobs 5594 https://github.com/cygwin/scallywag/actions/runs/4397354263/jobs/7700519955 .. scallywag: staging/cmake/vim-cmake/vim-cmake-3.23.2-2.hint scallywag: staging/cmake/vim-cmake/vim-cmake-3.23.2-2.tar.xz xz: (stdout): Write error: No space left on device tar: /cygdrive/d/a/scallywag/scallywag/builddir.tar.xz: Cannot write: Broken pipe tar: Child returned status 1 tar: Error is not recoverable: exiting now Traceback (most recent call last): The the VM is supposed to have at least 14GB free disk space, which seems like it should be enough. But maybe there's something I'm doing wrong here (like trying to create this archive on the wrong drive or something...). Let me look into this a bit more... cmake is a huge orc previous build tree on my laptop (only difference was python 3.8 instead of 3.9) $ du -hs cmake-3.23.2-1.x86_64 13G cmake-3.23.2-1.x86_64 $ du -hs * 9.0Gbuild 1.0Kconfig 0 CYGWIN-PATCHES 387Mdist 2.7Ginst 1.7Mlog 71M origsrc 0 patch 9.6Mspkg 71M src 656Ktemp just the testing is requiring 3.6GTests so no doubt it hits the 14GB issues Regards Marco
disk space limit of scallywag ?
Hi Jon, what is the current disk space limit of scallywag ? jobs 5594 https://github.com/cygwin/scallywag/actions/runs/4397354263/jobs/7700519955 .. scallywag: staging/cmake/vim-cmake/vim-cmake-3.23.2-2.hint scallywag: staging/cmake/vim-cmake/vim-cmake-3.23.2-2.tar.xz xz: (stdout): Write error: No space left on device tar: /cygdrive/d/a/scallywag/scallywag/builddir.tar.xz: Cannot write: Broken pipe tar: Child returned status 1 tar: Error is not recoverable: exiting now Traceback (most recent call last): Regards Marco
Re: [ANNOUNCEMENT] cygport 0.36.1-1
On 11.03.2023 17:29, Jon Turney via Cygwin wrote:
The following packages have been uploaded to the Cygwin distribution:
* cygport-0.36.1-1
Hi Jon,
I was a bit too late...
Updating the python 3.[89] subpackages, I finally hit
a case where setup.py and setup.cfg are missing as obsolete.
Attached patch solved the issue and allowed to build
python-platformdirs-3.1.1-1
Regards
MarcoFrom 4081ce236a5d8f9b76afd9c68e489600d7b434f1 Mon Sep 17 00:00:00 2001
From: Marco Atzeri
Date: Sat, 11 Mar 2023 21:00:15 +0100
Subject: [PATCH] Allow wheel to manage project without setup.py and setup.cfg
and use the pyproject.toml (PEP 518)
---
cygclass/python-wheel.cygclass | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/cygclass/python-wheel.cygclass b/cygclass/python-wheel.cygclass
index 1ef23826..b0f5288a 100644
--- a/cygclass/python-wheel.cygclass
+++ b/cygclass/python-wheel.cygclass
@@ -159,9 +159,13 @@ fi
python_wheel_compile() {
local ver
- if [ ! -e setup.py ] && [ ! -e setup.cfg ]
+ if [ ! -e pyproject.toml ]
then
- error "No Python Distutils module detected in source tree"
+ warning "No pyproject.toml (PEP 518) detected in source tree"
+ if [ ! -e setup.py ] && [ ! -e setup.cfg ]
+ then
+ error "No Python Distutils module detected in source
tree"
+ fi
fi
for ver in ${PYTHON_WHEEL_VERSIONS//:/ }
@@ -189,9 +193,13 @@ python_wheel_compile() {
python_wheel_install() {
local ver whl
- if [ ! -e setup.py ] && [ ! -e setup.cfg ]
+ if [ ! -e pyproject.toml ]
then
- error "No Python Distutils module detected in source tree"
+ warning "No pyproject.toml (PEP 518) detected in source tree"
+ if [ ! -e setup.py ] && [ ! -e setup.cfg ]
+ then
+ error "No Python Distutils module detected in source
tree"
+ fi
fi
for ver in ${PYTHON_WHEEL_VERSIONS//:/ }
--
2.39.0
scallywag
Hi Guys, may I propose another PLUSH HIPPO for Jon Turney for implementating and maintaining scallywag ? I just started to use it also for deploying packages and it reduce a lot my efforts (and my laptop overload) in maintaining complex packages. Thanks Jon very much Regards Marco
ATTN Maintainer : sqlite3 update ?
Hi Jan, could you update the package to last version ? Regards Marco
Re: next python
On 08.03.2023 22:40, Jon Turney wrote: On 07/03/2023 04:44, Marco Atzeri via Cygwin-apps wrote: Hi Guys, I was looking to start packing 3.10.X but I noticed that 3.11.2 is already out. Should I skip 3.10 and go directly to 3.11 ? I think that's probably the right thing to do. thanks for confirming It takes us a long while to find the maintainer time to get all the modules and bindings updated, so trying to do that for both 3.10 and 3.11 probably isn't a good idea. (although I'm probably in a place now where I have enough automation to start trying to do automatic rebuilds of affected packages) the major problem will be testing as on the main packages (python3X) it stacks on some IO. Almost all the python3X-* packages require the packages to be installed for the test to work. Usually I run only manually the test for 3.9 versions to save time. I am also considering to not update anymore python36-* and python37-* That also seems reasonable, since 3.6 is already EOL and 3.7 is EOL in Jun. Regards Marco
