Re: Python - plan & execution
On 26.05.2020 01:45, Yaakov Selkowitz wrote:
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?
we are not really supporting 3.5, we have only 8 packages and
stable is 3.6, so I see no reason to go backwards
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
I was moving to the next package after installing setuptools and I got
>>> python36-pip requires: python36 python38 python38-pip
ca-certificates python36-setuptools
>>> python36-pip OBSOLETES: python3-pip
>>> python37-pip requires: python37 ca-certificates python37-setuptools
>>> python38-pip requires: python38 ca-certificates python38-setuptools
that is very curious and due to
usr/bin/pip3
that is a copy of usr/bin/pip3.8
Should I manage "pip3" with alternatives so that is really available
for all python versions ?
I can also override with pip3.7 or pip3.6 to force a fixed default.
Regards
Marco
PYTHON_WHEEL_VERSIONS="3.6:3.7:3.8"
inherit python-wheel
NAME="python-setuptools"
VERSION=46.4.0
RELEASE=1
CATEGORY="Python"
SUMMARY="Python package management tool"
DESCRIPTION="PyPI Python eggs package management tool"
SRC_URI="${SRC_URI%.tar.gz}.zip"
ARCH=noarch
#PKG_NAMES+=" ${NAME}-wheel"
#python_setuptools_wheel_CONTENTS="
# usr/share/python-wheels/setuptools-*.whl
# usr/share/doc/${NAME}-wheel/
#"
python36_setuptools_CONTENTS+=" usr/bin/*-3.6"
python37_setuptools_CONTENTS+=" usr/bin/*-3.7"
python38_setuptools_CONTENTS+=" usr/bin/*-3.8"
#PKG_IGNORE="usr/bin/easy_install"
src_install() {
cd ${B}
python_wheel_install
}
PYTHON_WHEEL_VERSIONS="3.6:3.7:3.8"
inherit python-wheel
NAME="python-pip"
VERSION=20.1.1
RELEASE=1
CATEGORY="Python"
SUMMARY="Python package installation tool"
DESCRIPTION="The PyPA recommended tool for installing Python packages."
PATCH_URI="https://src.fedoraproject.org/rpms/python-pip/raw/master/f/dummy-certifi.patch;
ARCH=noarch
CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
rm src/pip/_vendor/certifi/*.pem
sed -i '/\.pem$/d' src/pip.egg-info/SOURCES.txt
}
# PKG_NAMES+=" ${NAME}-wheel"
# python_pip_wheel_CONTENTS="
# usr/share/python-wheels/pip-*.whl
# usr/share/doc/${NAME}-wheel/
# "
python36_pip_CONTENTS+=" usr/bin/pip3.6"
python36_pip_REQUIRES="ca-certificates python36-setuptools"
python37_pip_CONTENTS+=" usr/bin/pip3.7"
python37_pip_REQUIRES="ca-certificates python37-setuptools"
python38_pip_CONTENTS+=" usr/bin/pip3.8"
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
[ITA] libmypaint
cygport file attached.
The only notable change from Yaakov's cygport file is that upstream has changed
their library versioning scheme. Previously the DLL was cygmypaint-1-3-0.dll
and the library package was called libmypaint1.3_0. Now the DLL is
cygmypaint-0.dll, so I've called the library package libmypaint0.
This was a deliberate change, with much upstream discussion, so I don't think I
should mess with it.
Ken
NAME="libmypaint"
VERSION=1.6.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="MyPaint brush library"
DESCRIPTION="This is the brush library used by MyPaint. A number of other
painting programs use it too."
HOMEPAGE="https://github.com/mypaint/libmypaint;
SRC_URI="https://github.com/mypaint/libmypaint/releases/download/v${VERSION}/libmypaint-${VERSION}.tar.xz;
BUILD_REQUIRES="\
gobject-introspection \
libglib2.0-devel \
libjson-c-devel \
"
PKG_NAMES="libmypaint0 libmypaint-common libmypaint-devel
girepository-MyPaint1.6"
libmypaint0_REQUIRES="libmypaint-common"
libmypaint0_CONTENTS="
usr/bin/cygmypaint-0.dll
"
libmypaint_common_CONTENTS="
usr/share/doc/${NAME}
usr/share/locale/*/*/libmypaint.mo
"
libmypaint_devel_CONTENTS="
usr/include/libmypaint/
usr/lib/libmypaint.dll.a
usr/lib/pkgconfig/libmypaint.pc
"
girepository_MyPaint1_6_CONTENTS="usr/*/gir*-1.0/MyPaint-1.6.*"
[ITA] mypaint-brushes
cygport file attached.
It differs only trivially from Yaakov's.
Ken
NAME="mypaint-brushes"
VERSION=1.3.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="MyPaint brushes"
DESCRIPTION="Brushes used by MyPaint and other software using libmypaint."
HOMEPAGE="https://github.com/mypaint/mypaint-brushes;
SRC_URI="https://github.com/mypaint/mypaint-brushes/archive/v${VERSION}/mypaint-brushes-v${VERSION}.tar.gz;
ARCH=noarch
PKG_NAMES="${NAME} ${NAME}-devel"
mypaint_brushes_CONTENTS="
usr/share/doc/${NAME}
usr/share/mypaint-data/1.0/brushes/
"
mypaint_brushes_devel_REQUIRES=${NAME}
mypaint_brushes_devel_CONTENTS="
usr/share/pkgconfig/mypaint-brushes-1.0.pc
"
[ITA] gegl0.4
cygport file and patch attached.
As with babl, the build system has changed from autotools to meson.
And, as with babl, I've added a libgegl0.4-doc package, corresponding to
Fedora's gegl04-devel-docs package. I'm not sure why this wasn't packaged
before. Yaakov, is there some reason not to do this?
Ken
--- origsrc/gegl-0.4.22/gegl/meson.build2020-02-18 15:50:00.0
-0500
+++ src/gegl-0.4.22/gegl/meson.build2020-05-21 07:35:45.224379400 -0400
@@ -114,7 +114,7 @@ if get_option('introspection')
identifier_prefix: 'Gegl',
symbol_prefix: 'gegl',
header: 'gegl.h',
-includes: [ 'GLib-2.0', 'GObject-2.0', 'Babl-0.1' ],
+includes: [ 'GLib-2.0', 'GObject-2.0' ],
install: true,
)
inherit meson
NAME="gegl0.4"
VERSION=0.4.22
RELEASE=1
CATEGORY="Libs"
SUMMARY="Generic Graphics Library"
DESCRIPTION="GEGL (Generic Graphics Library) is a graph based image processing
framework. GEGL provides infrastructure to do demand based cached
non-destructive image editing on larger than RAM buffers."
HOMEPAGE="http://www.gegl.org/;
SRC_URI="http://download.gimp.org/pub/gegl/${VERSION%.*}/gegl-${VERSION}.tar.xz;
SRC_DIR="gegl-${VERSION}"
PATCH_URI="0.4.22-no-babl-gir.patch"
# python27-gi is needed for testsuite.
BUILD_REQUIRES="enscript \
gobject-introspection \
gtk-doc \
libIlmImf-devel \
libbabl-devel \
libcairo-devel \
libexiv2-devel \
libgdk_pixbuf2.0-devel \
libgexiv2-devel \
libglib2.0-devel \
libjasper-devel \
libjson-glib1.0-devel \
liblcms2-devel \
liblensfun-devel \
libpango1.0-devel \
libpng-devel \
libraw-devel \
librsvg2-devel \
libspiro-devel \
libsuitesparseconfig-devel \
libtiff-devel \
libumfpack-devel \
libwebp-devel \
meson \
python27-gi \
python-gi-devel \
vala \
"
PKG_NAMES="gegl0.4 libgegl0.4_0 libgegl0.4-devel girepository-Gegl0.4
vala-gegl0.4 libgegl0.4-doc"
gegl0_4_CATEGORY="Graphics"
gegl0_4_CONTENTS="usr/bin/*-0.4.exe"
libgegl0_4_0_SUMMARY="${SUMMARY} (runtime)"
libgegl0_4_0_CONTENTS="
usr/bin/cyggegl-0.4-0.dll
usr/bin/cyggegl-*-0.4.dll
usr/lib/gegl-0.4/
usr/share/doc/${NAME}
usr/share/locale/*/*/gegl-0.4.mo
"
libgegl0_4_devel_SUMMARY="${SUMMARY} (development)"
libgegl0_4_devel_CONTENTS="
usr/include/gegl-0.4/
usr/lib/libgegl*-0.4.*.a
usr/lib/pkgconfig/gegl*-0.4.pc
"
libgegl0_4_doc_SUMMARY="${SUMMARY} (documentation)"
libgegl0_4_doc_CONTENTS="usr/share/gtk-doc/"
girepository_Gegl0_4_SUMMARY="${SUMMARY} (GObject Introspection)"
girepository_Gegl0_4_CONTENTS="usr/*/gir*/Gegl-0.4.*"
vala_gegl0_4_SUMMARY="${SUMMARY} (Vala bindings)"
vala_gegl0_4_CONTENTS="usr/share/vala/vapi/gegl-0.4.*"
CYGMESON_ARGS="
--auto-features=auto
-Dworkshop=true
-Ddocs=true
-Dlibav=disabled
-Dlua=disabled
"
src_install() {
cd ${S}
meson_install
cd ${D}
mv usr/bin/gegl.exe usr/bin/gegl-0.4.exe
mv usr/bin/gegl-imgcmp.exe usr/bin/gegl-imgcmp-0.4.exe
mv usr/lib/libgegl.exe.a usr/lib/libgegl-0.4.exe.a
}
# One failed test on x86_64:
# 6/108 gegl:simple / buffer-sharingFAIL 12.01s
(exit status 1)
# --- command ---
# 13:51:24
ABS_TOP_BUILDDIR='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.x86_64/src/gegl-0.4.22/x86_64-pc-cygwin'
GEGL_PATH='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.x86_64/src/gegl-0.4.22/x86_64-pc-cygwin/operations'
ABS_TOP_SRCDIR='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.x86_64/src/gegl-0.4.22'
GEGL_SWAP='RAM'
/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.x86_64/src/gegl-0.4.22/x86_64-pc-cygwin/tests/simple/buffer-sharing.exe
# --- stdout ---
# timeout!
# Two failed tests on x86:
# 1/108 gegl:simple / backend-file FAIL 0.93s
(killed by signal 11 SIGSEGV)
# --- command ---
# 13:49:56
ABS_TOP_SRCDIR='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.i686/src/gegl-0.4.22'
ABS_TOP_BUILDDIR='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.i686/src/gegl-0.4.22/i686-pc-cygwin'
GEGL_PATH='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.i686/src/gegl-0.4.22/i686-pc-cygwin/operations'
GEGL_SWAP='RAM'
/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.i686/src/gegl-0.4.22/i686-pc-cygwin/tests/simple/backend-file.exe
# ---
# 6/108 gegl:simple / buffer-sharingFAIL 1.90s
(killed by signal 11 SIGSEGV)
# --- command ---
# 13:50:01
ABS_TOP_SRCDIR='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.i686/src/gegl-0.4.22'
ABS_TOP_BUILDDIR='/home/kbrown/src/cygpackages/gegl0.4/gegl0.4-0.4.22-1.i686/src/gegl-0.4.22/i686-pc-cygwin'
[ITA] babl
cygport file and patches attached.
The build system has changed from autotools to meson. The former is no longer
supported.
I have disabled gobject introspection for reasons explained here:
https://sourceware.org/pipermail/cygwin-apps/2020-May/040093.html
This represents no change, because Yaakov disabled it (for different reasons)
several years ago. I'm hoping to be able to re-enable it at some point.
I went to some trouble, with the help of Jon Turney, to make the html docs
build, so I packaged them in a (new) libbabl-doc package. Is there any reason
not to do this?
Fedora packages the docs also, in babl-devel-docs.
Ken
--- origsrc/babl-0.1.74/babl/meson.build2020-01-12 18:26:51.0
-0500
+++ src/babl-0.1.74/babl/meson.build2020-05-25 10:05:54.387799000 -0400
@@ -38,7 +38,7 @@ elif host_machine.system() == 'darwin' a
else
error('Linker doesn\'t support --version-script or -exported_symbols_list')
endif
-if platform_win32
+if platform_win32 or platform_cygwin
babl_link_args += '-Wl,--no-undefined'
endif
--- origsrc/babl-0.1.74/extensions/meson.build 2020-01-12 18:26:51.0
-0500
+++ src/babl-0.1.74/extensions/meson.build 2020-05-25 10:05:54.391822000
-0400
@@ -15,7 +15,7 @@ babl_ext_inc = [
# Linker arguments
babl_ext_link_args = [
]
-if platform_win32
+if platform_win32 or platform_cygwin
babl_ext_link_args += '-Wl,--no-undefined'
endif
--- origsrc/babl-0.1.74/meson.build 2020-01-12 18:26:51.0 -0500
+++ src/babl-0.1.74/meson.build 2020-05-25 10:08:03.005964600 -0400
@@ -79,6 +79,7 @@ conf.set_quoted('BABL_LIBRARY',
platform_android = false
platform_osx = false
platform_win32 = false
+platform_cygwin = false
host_cpu_family = host_machine.cpu_family()
message('Host machine cpu family: ' + host_cpu_family)
@@ -104,9 +105,10 @@ host_os = host_machine.system()
message('Host os: ' + host_os)
platform_win32 = (host_os.startswith('mingw') or
- host_os.startswith('cygwin') or
host_os.startswith('windows'))
+platform_cygwin = host_os.startswith('cygwin')
+
platform_osx = host_os.startswith('darwin')
if platform_osx
if cc.get_id() != 'clang'
@@ -118,7 +120,7 @@ platform_android = host_os.contains('and
path_sep = ( platform_win32 ? ';' : ':' )
dirs_sep = ( platform_win32 ? '' : '/' )
-if platform_win32
+if platform_win32 or platform_cygwin
lib_ext = '.dll'
elif platform_osx
lib_ext = '.dylib'
@@ -145,7 +147,6 @@ build_os = build_machine.system()
message('Build os: ' + build_os)
build_platform_win32 = (build_os.startswith('mingw') or
-build_os.startswith('cygwin') or
build_os.startswith('windows'))
# Only run cross compile objects if we have exe wrapper
--- origsrc/babl-0.1.74/docs/meson.build2020-01-12 18:26:51.0
-0500
+++ src/babl-0.1.74/docs/meson.build2020-05-24 22:10:24.081359400 -0400
@@ -54,22 +54,26 @@ index_html = custom_target('index.html',
build_by_default: true,
)
-Reference_html = custom_target('Reference.html',
+Reference_html_tmp = custom_target('Reference.html.tmp',
input : [
'Reference-static.html',
'toc',
-index_html_tmp,
],
- output: [ 'Reference.html', ],
+ output: [ 'Reference.html.tmp', ],
command: [
env_bin,
'cp', '@INPUT0@', '@OUTPUT@',
'&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
-'&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
],
- build_by_default: true,
)
+Reference_html = custom_target('Reference.html',
+ input : [ Reference_html_tmp, index_html_tmp, ],
+ output: [ 'Reference.html', ],
+ command: [ xml_insert, '@INPUT0@', 'BablBase', '@INPUT1@', 'cat_result' ],
+ build_by_default: true,
+ capture: true,
+)
CMYK_html = custom_target('CMYK.html',
input : [
--- origsrc/babl-0.1.74/docs/tools/xml_insert.sh2020-01-12
18:26:51.0 -0500
+++ src/babl-0.1.74/docs/tools/xml_insert.sh2020-05-25 07:54:31.875472500
-0400
@@ -7,6 +7,9 @@
#
# xml_insert.sh bar.xml foo foo.inc
#
+# If there's a fourth argument, cat the final result.
+#
+#
# 2005 © Øyvind Kolås
#
# FIXME: add argument checking / error handling
@@ -97,6 +100,9 @@ tailno=`expr $numlines - $splitno`
head -$splitno $tmp_file > $1
cat $3 >> $1
tail -$tailno $tmp_file >> $1
+if test -n "$4"; then
+ cat $1
+fi
rm -rf $tmp_dir
inherit meson
NAME="babl"
VERSION=0.1.74
RELEASE=1
CATEGORY="Libs"
SUMMARY="Any-to-any pixel format conversion library"
DESCRIPTION="Babl is a dynamic, any to any, pixel format conversion library.
It provides conversions between the myriad of buffer types images can be
stored in. Babl doesn't only help with existing pixel formats, but also
facilitates creation of new and uncommon ones."
HOMEPAGE="http://www.gegl.org/babl/;
SRC_URI="http://download.gimp.org/pub/babl/${VERSION%.*}/babl-${VERSION}.tar.xz;
PATCH_URI="0.1.74-cygwin.patch 0.1.74-docs.patch"
PKG_NAMES="libbabl0.1_0
Re: Current setup timestamp 1590343308
On 2020-05-25 14:14, Fergus Daly via Cygwin wrote: > Fergus Daly said: >>> What I have observed, twice now (earlier today using setup.ini >>> incorporating timestamp 1590343308 and now using the latest setup.ini >>> incorporating timestamp 1590407755) is that event (ii) is failing: the file >>> /etc/setup/timestamp is not updated - and if it isn't there at all, it is >>> not created. > > Ken Brown said: >>> I'm not seeing any change in behavior on my system. I just deleted > /etc/setup/timestamp and ran setup. A new /etc/setup/timestamp was created, > with contents 1590430423. This matches the value in the downloaded setup.ini > file: > setup-timestamp: 1590430423 > Do you see any error messages involving /etc/setup/timestamp in the setup log > files in /var/log? > > And thank you for this. In a way I am encouraged that things remain as they > should be for you and presumably for others, and that there's some kind of > local glitch on my machine. > It is trivially annoying, perplexing - and persistent! (I've just updated to > 1590430423) with these consequences: > Nothing at all relevant in /var/log/setup.log*: > ~> grep timestamp /var/log/setup.log* > ~> > yields nothing. And > ~> ls -altr /etc/setup/ > ends with > .. > .. > -rw-r--r-- 1 404 May 22 09:39 perl-TimeDate.lst.gz > -rw-r--r-- 1 629 May 22 09:39 mintty.lst.gz > -rw-r--r-- 111 May 25 17:10 timestamp > -rw-r--r-- 1 16283 May 25 20:45 installed.db > -rw-r--r-- 164 May 25 20:45 setup.rc > showing that the last update that actually altered my provision - not the > full offering by any means - took place on May 22. The timestamp file at time > 17:10 today is an artificial creation with the contents 158000 so that > tracking is easy. The update to 1590430423 occurred at 20:45 today and > revised only two of the three files that would normally be updated - > /etc/setup/timestamp has not changed. > .. .. ??!! > As I say - perplexing. > Fergus > (And /etc/setup/timestamp should update, even when there's no change to a > user's provision. It always has, until today.) > Thanks anyway. Is the difference whether set-x86/_64 option "-g, --upgrade-also Upgrade installed packages also" is specified or not? That option is built into my setup script in case install dependencies need upgraded, and as the default if no install is requested. I only run setup manually to install downgrades, tests, or when version formats change. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- 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: Current setup timestamp 1590343308
On 2020-05-25 14:14, Fergus Daly via Cygwin wrote: > Fergus Daly said: >>> What I have observed, twice now (earlier today using setup.ini >>> incorporating timestamp 1590343308 and now using the latest setup.ini >>> incorporating timestamp 1590407755) is that event (ii) is failing: the file >>> /etc/setup/timestamp is not updated - and if it isn't there at all, it is >>> not created. > > Ken Brown said: >>> I'm not seeing any change in behavior on my system. I just deleted > /etc/setup/timestamp and ran setup. A new /etc/setup/timestamp was created, > with contents 1590430423. This matches the value in the downloaded setup.ini > file: > setup-timestamp: 1590430423 > Do you see any error messages involving /etc/setup/timestamp in the setup log > files in /var/log? > > And thank you for this. In a way I am encouraged that things remain as they > should be for you and presumably for others, and that there's some kind of > local glitch on my machine. > It is trivially annoying, perplexing - and persistent! (I've just updated to > 1590430423) with these consequences: > Nothing at all relevant in /var/log/setup.log*: > ~> grep timestamp /var/log/setup.log* > ~> > yields nothing. And > ~> ls -altr /etc/setup/ > ends with > .. > .. > -rw-r--r-- 1 404 May 22 09:39 perl-TimeDate.lst.gz > -rw-r--r-- 1 629 May 22 09:39 mintty.lst.gz > -rw-r--r-- 111 May 25 17:10 timestamp > -rw-r--r-- 1 16283 May 25 20:45 installed.db > -rw-r--r-- 164 May 25 20:45 setup.rc > showing that the last update that actually altered my provision - not the > full offering by any means - took place on May 22. The timestamp file at time > 17:10 today is an artificial creation with the contents 158000 so that > tracking is easy. The update to 1590430423 occurred at 20:45 today and > revised only two of the three files that would normally be updated - > /etc/setup/timestamp has not changed. > .. .. ??!! > As I say - perplexing. > Fergus > (And /etc/setup/timestamp should update, even when there's no change to a > user's provision. It always has, until today.) > Thanks anyway. Is the difference whether set-x86/_64 option "-g, --upgrade-also Upgrade installed packages also" is specified or not? That option is built into my setup script in case install dependencies need upgraded, and as the default if no install is requested. I only run setup manually to install downgrades, tests, or when version formats change. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- 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
[ITA] libspiro
This is the first of several ITAs leading up to gimp. cygport file attached.
It's a routine update of Yaakov's.
Ken
NAME="libspiro"
VERSION=20200505
RELEASE=1
CATEGORY="Libs"
SUMMARY="Library for converting clothoid splines to bezier curves"
DESCRIPTION="Spiro is the creation of Raph Levien. It simplifies the drawing of
beautiful curves. Using bezier splines an artist can easily draw
curves with the same slope on either side of an on-curve point.
Spiros, on the other hand, are based on clothoid splines which make it
easy to maintain constant curvature as well as constant slope. Such
curves will simply look nicer."
HOMEPAGE="https://github.com/fontforge/libspiro/;
SRC_URI="https://github.com/fontforge/libspiro/releases/download/${VERSION}/libspiro-dist-${VERSION}.tar.gz;
PKG_NAMES="${NAME}1 ${NAME}-devel"
libspiro1_CONTENTS="usr/bin/cygspiro-1.dll usr/share/doc/ usr/share/man"
libspiro_devel_CONTENTS="usr/include/ usr/lib/"
Re: Current setup timestamp 1590343308
On 5/25/2020 12:47 PM, Fergus Daly via Cygwin wrote:
It looks to me that /etc/setup/timestamp is updated by the last successful setup
(upgrade?) run, and contains a copy of the selected mirror's setup.ini
setup_timestamp field as of the last successful setup (upgrade?) run, a few
hours earlier than the last successful setup (upgrade?) run.
Thank you for this.
I can't really think of anything to say other than repeat my observation,
today, of altered practice.
Since as long as I can remember (and I mean - a matter of years) a successful
upgrade of Cygwin32
(implementing the current version of setup-x86.exe currently 2.904
and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
has concluded with
(i) a glitch-free accounting in /var/log/setup.log(.full), together with
(ii) a revision of the file /etc/setup/timestamp
which reflects the timestamp line in the aforementioned setup.ini file.
(And other things too, quite apart from any updates to the Cygwin provision -
e.g. an updated /etc/setup/installed.db file.)
What I have observed, twice now (earlier today using setup.ini incorporating
timestamp 1590343308 and now using the latest setup.ini incorporating timestamp
1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not
updated - and if it isn't there at all, it is not created.
I'm not seeing any change in behavior on my system. I just deleted
/etc/setup/timestamp and ran setup. A new /etc/setup/timestamp was created,
with contents 1590430423. This matches the value in the downloaded setup.ini file:
setup-timestamp: 1590430423
Do you see any error messages involving /etc/setup/timestamp in the setup log
files in /var/log?
Ken
--
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: Current setup timestamp 1590343308
>> It looks to me that /etc/setup/timestamp is updated by the last successful
>> setup
>> (upgrade?) run, and contains a copy of the selected mirror's setup.ini
>> setup_timestamp field as of the last successful setup (upgrade?) run, a few
>> hours earlier than the last successful setup (upgrade?) run.
Thank you for this.
I can't really think of anything to say other than repeat my observation,
today, of altered practice.
Since as long as I can remember (and I mean - a matter of years) a successful
upgrade of Cygwin32
(implementing the current version of setup-x86.exe currently 2.904
and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
has concluded with
(i) a glitch-free accounting in /var/log/setup.log(.full), together with
(ii) a revision of the file /etc/setup/timestamp
which reflects the timestamp line in the aforementioned setup.ini file.
(And other things too, quite apart from any updates to the Cygwin provision -
e.g. an updated /etc/setup/installed.db file.)
What I have observed, twice now (earlier today using setup.ini incorporating
timestamp 1590343308 and now using the latest setup.ini incorporating timestamp
1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not
updated - and if it isn't there at all, it is not created.
Maybe this does not matter. The file is not referred to during any upgrade
session (or not obviously - I think the contents of /etc/setup/installed.db
are what dictate any necessary upgrades to an individual user's Cygwin
provision) but it has been, for me at least, a useful rapid check of whether
"what I've got" matches "what is now available".
All I was trying to do was draw attention to (what I perceive to be) suddenly
altered practice, with no change to the setup executable that might have
explained it or caused it. So (a) is it a real change? (easily confirmed, or
not, by anybody with /etc/setup/timestamp reporting < 1590407755 then running
an upgrade, and seeing what happens to /etc/setup/timestamp); and (b) if so, is
it intended? or is it a trivial glitch introduced goodness-knows-how that can
be corrected; and (c) if intended, to provide what improvement? because it
seems to me a bad move.
Fergus
--
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 1/3 v3] Cygwin: tzcode resync: basics
Hi Mark,
> On May 22 02:32, Mark Geisert wrote:
On May 25 14:06, Corinna Vinschen wrote:
> > Modifies winsup/cygwin/Makefile.in to build localtime.o from items in
> > new winsup/cygwin/tzcode subdirectory. Compiler option "-fpermissive"
> > is used to accept warnings about missing casts on the return values of
> > malloc() calls. This patch also removes existing localtime.cc and
> > tz_posixrules.h from winsup/cygwin as they are superseded by the
> > subsequent patches in this set.
> > [...]
> > @@ -246,6 +246,15 @@ MATH_OFILES:= \
> > tgammal.o \
> > truncl.o
> >
> > +TZCODE_OFILES:=localtime.o
> > +
> > +localtime.o: $(srcdir)/tzcode/localtime.cc
> > $(srcdir)/tzcode/localtime.c.patch
> > + (cd $(srcdir)/tzcode && \
> > + patch -u -o localtime.c.patched localtime.c localtime.c.patch)
> > + $(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
> > + -I$(target_builddir)/winsup/cygwin \
> > + -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
> > +
>
> This doesn't work well for me. That rule is the top rule in Makefile.in
> now, so just calling `make' doesn't build the DLL anymore, only
> localtime.o. The rule should get moved way down Makefile.in.
>
> What still bugs me is that we get these -fpermissive warnings (albeit
> non-fatal) and the fact that we don't get a dependencies file. On
> second thought, there's no good reason to keep localtime.cc a C++ file.
> Converting this file to a plain C wrapper drops the C++-specific warning
> and thus allows to revert the localtime.o build rule to use ${COMMON_CFLAGS}.
>
> So I took the liberty to tweak your patch a bit. I created a followup
> patchset, which I'd like you to take a look at.
>
> I attached the followup patches to this mail. Please scrutinize it and
> don't hesitate to discuss the changes. For a start:
>
> - I do not exactly like the name "localtime_wrapper.c" but I don't
> have a better idea.
>
> - muto's are C++-only, so I changed rwlock_wrlock/rwlock_unlock to use
> Windows SRWLocks. I think this is a good thing and I'm inclined
> to drop the muto datatype entirely in favor of using SRWLocks since
> they are cleaner and langauge-agnostic.
Two changes in my patchset:
- I didn't initialize the SRWLOCK following the books. Fixed that.
- Rather than creating the patched file in the source dir, I changed
the Makefile.in rule so that the patched file is created in the build
dir. This drops the requirement to tweak .gitignore. It's also
cleaner.
- Splitting the build rule for localtime.c.patched from the build rule
for localtime.o makes sure that the patched file is not regenerated
every time we build localtime.o.
I attached my patchset again, but only patch 3 and 4 actually changed.
Thanks,
Corinna
>From 2ce569ec924b75894492f1a103f42900610fe00f Mon Sep 17 00:00:00 2001
From: Corinna Vinschen
Date: Mon, 25 May 2020 13:45:17 +0200
Subject: [PATCH 1/4] Cygwin: move localtime.o build rule to end of file
otherwise a simple `make' in the cygwin dir won't build
the DLL anymore.
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/Makefile.in | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index 2ac8bcbd89ff..2e8c274a36b3 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -248,13 +248,6 @@ MATH_OFILES:= \
TZCODE_OFILES:=localtime.o
-localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
- (cd $(srcdir)/tzcode && \
- patch -u -o localtime.c.patched localtime.c localtime.c.patch)
- $(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
- -I$(target_builddir)/winsup/cygwin \
- -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
-
DLL_OFILES:= \
advapi32.o \
aio.o \
@@ -741,6 +734,13 @@ dcrt0.o sigproc.o: child_info_magic.h
shared.o: shared_info_magic.h
+localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
+ (cd $(srcdir)/tzcode && \
+ patch -u -o localtime.c.patched localtime.c localtime.c.patch)
+ $(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
+ -I$(target_builddir)/winsup/cygwin \
+ -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
+
$(srcdir)/devices.cc: gendevices devices.in devices.h
${wordlist 1,2,$^} $@
--
2.25.4
>From 57625ac256299c1472f371f6d39b23c59f55d72e Mon Sep 17 00:00:00 2001
From: Corinna Vinschen
Date: Mon, 25 May 2020 13:46:24 +0200
Subject: [PATCH 2/4] Cygwin: rename localtime.cc to localtime_wrapper.c
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/Makefile.in | 2 +-
winsup/cygwin/tzcode/{localtime.cc => localtime_wrapper.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename winsup/cygwin/tzcode/{localtime.cc => localtime_wrapper.c} (100%)
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index 2e8c274a36b3..1e1342ab7849 100644
---
Re: [ITA from Yaakov] python-wx
On 25/05/2020 14:28, Jon Turney wrote: > On 25/05/2020 13:45, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> On 17/05/2020 20:49, Marco Atzeri via Cygwin-apps wrote: >>> On 17.05.2020 21:37, Hamish McIntyre-Bhatty via Cygwin-apps wrote: NB: Tested the SSH key and it seems to be working just fine. Should I upload this as a testing package or go straight for a normal package? I'm not sure how announcements work for testing packages. Hamish >>> >>> same as normal Announce, just use the tag "Test" >>> >>> https://sourceware.org/pipermail/cygwin-announce/2020-April/009511.html >> >> Apologies Marco - accidentally send only to you at first. >> >> Okay, all done, but I don't think my announcement has made it through. >> >> >> I'm not sure how long it takes, but it doesn't seem to be in the >> archives yet. > > Unfortunately, the announce list is moderated by humans, not robots. Okay, good to know :) 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Help needed with gobject-introspection
On 5/24/2020 1:00 PM, Ken Brown via Cygwin-apps wrote:
On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote:
On 5/24/2020 11:56 AM, Jon Turney wrote:
On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 11:48 AM, Jon Turney wrote:
On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
On 5/21/2020 9:24 AM, Jon Turney wrote:
On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
I would like to adopt gimp and related packages. At the moment I'm
having trouble with babl, which is needed for gegl0.4, which is needed
for gimp. The problem involves gobject-introspection.
If I disable introspection, the build works fine. This would be OK,
since babl has been built without introspection for several years. But
then the gegl0.4 build complains about the missing babl introspection
files, so I would have to disable introspection there too, which hasn't
been done in the past.
So my preference is to figure out what the problem is and get the babl
build working with introspection. I'm attaching my cygport file and
patch.
Here's the failing command...
/usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT
--no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output
babl/Babl-0.1.gir --c-include=babl.h
'--identifier-filter-cmd=/usr/bin/python3
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py'
-DBABL_IS_BEING_COMPILED
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-I./. -I../. -I./babl/base/. -I../babl/base/.
--filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist
--cflags-begin -fno-unsafe-math-optimizations
-Wdeclaration-after-statement -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx -msse
-mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. --cflags-end
--library babl-0.1
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
--extra-library=m --extra-library=dl --extra-library=lcms2
...and the error message:
g-ir-scanner: link: gcc -o
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe
-ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong --param=ssp-buffer-size=4
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o
-L. -lbabl-0.1 -lm -ldl -llcms2
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
-lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0
-lglib-2.0 -lintl
ERROR: can't resolve libraries to shared libraries: babl-0.1
I don't understand the error message, because the command line contains
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I
even tried adding that directory to my PATH to make sure the right
cygbabl-0.1-0.dll would be found, but that didn't help.
This might possibly be related to the problem described in the comment for:
https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4
Yeah, this looks extremely plausible, there seem to be no GObject derived
types in babl's interface.
It might be possible to work around this by patching in a dummy GObject
derived type which does nothing.
I'll have to see if I can find my notes about how I debugged this before.
By the way, in case you're wondering why I disabled the building of
docs, it's because I was getting a build failure there too. I don't
know if this is related to the introspection failure. The failing
command there is
/usr/bin/meson --internal exe --unpickle
/tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat
cp: target 'docs/index.html.tmp' is not a directory
I don't know why it's not showing me the actual cp command that fails.
I believe it's is an infelicity in meson that it doesn't echo the actual
failing command here.
Noted here:
https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
The corresponding information in docs/meson.build is
Reference_html = custom_target('Reference.html',
input : [
'Reference-static.html',
'toc',
index_html_tmp,
],
output: [ 'Reference.html', ],
command: [
env_bin,
'cp', '@INPUT0@', '@OUTPUT@',
'&&', xml_insert,
Update: upx-3.96-1 (re-compiled: ucl-1.03-3)
UPX has been updated to version 3.96 for both x86 and x86_64 architectures. See the release news for changes: https://upx.github.io/upx-news.txt UPX is a free, portable, extendable, high-performance executable packer for several executable formats. UCL (which is a library used by UPX) has been re-compiled coinciding with this release. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
[ANNOUNCEMENT] Update: upx-3.96-1 (re-compiled: ucl-1.03-3)
UPX has been updated to version 3.96 for both x86 and x86_64 architectures. See the release news for changes: https://upx.github.io/upx-news.txt UPX is a free, portable, extendable, high-performance executable packer for several executable formats. UCL (which is a library used by UPX) has been re-compiled coinciding with this release. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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 25/05/2020 05:52, 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.
Hi Jon,
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
python-setuptools python35-setuptools drop
python-setuptools python36-setuptools
python-setuptools python37-setuptools
python-setuptools python38-setuptools
python-setuptools python-setuptools-wheel drop
I expect to see other similar as all recent packages
are now only supporting 3.5 or more to 3.8
https://pypi.org/project/setuptools/
Thanks to a patch by Yaakov, calm should now treat these similarly to
old soversions and not warn about them.
Re: [ITA from Yaakov] python-wx
On 25/05/2020 13:45, Hamish McIntyre-Bhatty via Cygwin-apps wrote: On 17/05/2020 20:49, Marco Atzeri via Cygwin-apps wrote: On 17.05.2020 21:37, Hamish McIntyre-Bhatty via Cygwin-apps wrote: NB: Tested the SSH key and it seems to be working just fine. Should I upload this as a testing package or go straight for a normal package? I'm not sure how announcements work for testing packages. Hamish same as normal Announce, just use the tag "Test" https://sourceware.org/pipermail/cygwin-announce/2020-April/009511.html Apologies Marco - accidentally send only to you at first. Okay, all done, but I don't think my announcement has made it through. I'm not sure how long it takes, but it doesn't seem to be in the archives yet. Unfortunately, the announce list is moderated by humans, not robots.
[ANNOUNCEMENT] Updated: python-wx-3.0.2.0-5
Version 3.0.2.0-5 of "python2-wx" has been uploaded. python2-wx is the Python 2 version of the cross-platform GUI toolkit, wxPython. This revision has the following changes: - Rebuilt against wxWidgets 3.0.4 to fix various issues. - Incorporated new patches from Fedora to fix various issues (including freezing/hangs and graphical glitches) - Used Yaakov's new packaging that separates wxWidgets and wxPython build processes. NOTE: These are test packages! Please try this out and let me know if this is working as expected. If no issues are reported, I will repackage as stable packages. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. 0x87B761FE07F548D6.asc Description: application/pgp-keys 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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
Updated: python-wx-3.0.2.0-5
Version 3.0.2.0-5 of "python2-wx" has been uploaded. python2-wx is the Python 2 version of the cross-platform GUI toolkit, wxPython. This revision has the following changes: - Rebuilt against wxWidgets 3.0.4 to fix various issues. - Incorporated new patches from Fedora to fix various issues (including freezing/hangs and graphical glitches) - Used Yaakov's new packaging that separates wxWidgets and wxPython build processes. NOTE: These are test packages! Please try this out and let me know if this is working as expected. If no issues are reported, I will repackage as stable packages. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. 0x87B761FE07F548D6.asc Description: application/pgp-keys 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Current setup timestamp 1590343308
On 2020-05-25 06:26, Fergus Daly via Cygwin wrote: > On 25 May 2020 13:13, marco atzeri wrote: >> On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote: >>> Current setup timestamp 1590343308 >>> does not seem to overwrite /etc/setup/timestamp accurately (or at all). >>> I think /etc/setup/installed.db is seen to as it should be. >> What exactly is your problem ? >> Be verbose we can NOT guess your thoughts. >> >> Unix time: seconds since Jan 01 1970. (UTC) >> https://www.unixtimestamp.com/index.php > Sorry for lack of clarity. > Cygwin32. > Current installed timestamp 1590341902 (got from /etc/setup/timestamp). > I noticed there's a newer setup.ini with timestamp 1590343308. > So I ran setup-x86.exe. > After a (presumed) successful run I noticed however, that the file > /etc/setup/timestamp had not altered. > "Presumed successful run" because the file /etc/setup/installed.db had a > new, current, timestamp. > (I deleted /etc/setup/timestamp and re-running setup-x86.exe to see whether > any self-correcting behaviour would ensue. The file was not recovered.) It looks to me that /etc/setup/timestamp is updated by the last successful setup (upgrade?) run, and contains a copy of the selected mirror's setup.ini setup_timestamp field as of the last successful setup (upgrade?) run, a few hours earlier than the last successful setup (upgrade?) run. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- 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 from Yaakov] python-wx
On 17/05/2020 20:49, Marco Atzeri via Cygwin-apps wrote: > On 17.05.2020 21:37, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >> NB: Tested the SSH key and it seems to be working just fine. >> >> Should I upload this as a testing package or go straight for a normal >> package? I'm not sure how announcements work for testing packages. >> >> Hamish >> > > same as normal Announce, just use the tag "Test" > > https://sourceware.org/pipermail/cygwin-announce/2020-April/009511.html Apologies Marco - accidentally send only to you at first. Okay, all done, but I don't think my announcement has made it through. I'm not sure how long it takes, but it doesn't seem to be in the archives yet. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: Current setup timestamp 1590343308
-Original Message- From: marco atzeri [mailto:marco.atz...@gmail.com] Sent: 25 May 2020 13:13 To: Fergus Daly Cc: cygwin@cygwin.com Subject: Re: Current setup timestamp 1590343308 On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote: > > Current setup timestamp 1590343308 > does not seem to overwrite /etc/setup/timestamp accurately (or at all). > I think /etc/setup/installed.db is seen to as it should be. > Fergus > -- What exactly is your problem ? Be verbose we can NOT guess your thoughts. Unix time: seconds since Jan 01 1970. (UTC) https://www.unixtimestamp.com/index.php Sorry for lack of clarity. Cygwin32. Current installed timestamp 1590341902 (got from /etc/setup/timestamp). I noticed there's a newer setup.ini with timestamp 1590343308. So I ran setup-x86.exe. After a (presumed) successful run I noticed however, that the file /etc/setup/timestamp had not altered. "Presumed successful run" because the file /etc/setup/installed.db had a new, current, timestamp. Fergus (I deleted /etc/setup/timestamp and re-running setup-x86.exe to see whether any self-correcting behaviour would ensue. The file was not recovered.) -- 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: Current setup timestamp 1590343308
On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote: > > Current setup timestamp 1590343308 > does not seem to overwrite /etc/setup/timestamp accurately (or at all). > I think /etc/setup/installed.db is seen to as it should be. > Fergus > -- What exactly is your problem ? Be verbose we can NOT guess your thoughts. Unix time: seconds since Jan 01 1970. (UTC) https://www.unixtimestamp.com/index.php -- 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 1/3 v3] Cygwin: tzcode resync: basics
Hi Mark,
On May 22 02:32, Mark Geisert wrote:
> Modifies winsup/cygwin/Makefile.in to build localtime.o from items in
> new winsup/cygwin/tzcode subdirectory. Compiler option "-fpermissive"
> is used to accept warnings about missing casts on the return values of
> malloc() calls. This patch also removes existing localtime.cc and
> tz_posixrules.h from winsup/cygwin as they are superseded by the
> subsequent patches in this set.
> [...]
> @@ -246,6 +246,15 @@ MATH_OFILES:= \
> tgammal.o \
> truncl.o
>
> +TZCODE_OFILES:=localtime.o
> +
> +localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
> + (cd $(srcdir)/tzcode && \
> + patch -u -o localtime.c.patched localtime.c localtime.c.patch)
> + $(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
> + -I$(target_builddir)/winsup/cygwin \
> + -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
> +
This doesn't work well for me. That rule is the top rule in Makefile.in
now, so just calling `make' doesn't build the DLL anymore, only
localtime.o. The rule should get moved way down Makefile.in.
What still bugs me is that we get these -fpermissive warnings (albeit
non-fatal) and the fact that we don't get a dependencies file. On
second thought, there's no good reason to keep localtime.cc a C++ file.
Converting this file to a plain C wrapper drops the C++-specific warning
and thus allows to revert the localtime.o build rule to use ${COMMON_CFLAGS}.
So I took the liberty to tweak your patch a bit. I created a followup
patchset, which I'd like you to take a look at.
I attached the followup patches to this mail. Please scrutinize it and
don't hesitate to discuss the changes. For a start:
- I do not exactly like the name "localtime_wrapper.c" but I don't
have a better idea.
- muto's are C++-only, so I changed rwlock_wrlock/rwlock_unlock to use
Windows SRWLocks. I think this is a good thing and I'm inclined
to drop the muto datatype entirely in favor of using SRWLocks since
they are cleaner and langauge-agnostic.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
>From 2ce569ec924b75894492f1a103f42900610fe00f Mon Sep 17 00:00:00 2001
From: Corinna Vinschen
Date: Mon, 25 May 2020 13:45:17 +0200
Subject: [PATCH 1/4] Cygwin: move localtime.o build rule to end of file
otherwise a simple `make' in the cygwin dir won't build
the DLL anymore.
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/Makefile.in | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index 2ac8bcbd89ff..2e8c274a36b3 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -248,13 +248,6 @@ MATH_OFILES:= \
TZCODE_OFILES:=localtime.o
-localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
- (cd $(srcdir)/tzcode && \
- patch -u -o localtime.c.patched localtime.c localtime.c.patch)
- $(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
- -I$(target_builddir)/winsup/cygwin \
- -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
-
DLL_OFILES:= \
advapi32.o \
aio.o \
@@ -741,6 +734,13 @@ dcrt0.o sigproc.o: child_info_magic.h
shared.o: shared_info_magic.h
+localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
+ (cd $(srcdir)/tzcode && \
+ patch -u -o localtime.c.patched localtime.c localtime.c.patch)
+ $(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
+ -I$(target_builddir)/winsup/cygwin \
+ -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
+
$(srcdir)/devices.cc: gendevices devices.in devices.h
${wordlist 1,2,$^} $@
--
2.25.4
>From 57625ac256299c1472f371f6d39b23c59f55d72e Mon Sep 17 00:00:00 2001
From: Corinna Vinschen
Date: Mon, 25 May 2020 13:46:24 +0200
Subject: [PATCH 2/4] Cygwin: rename localtime.cc to localtime_wrapper.c
Signed-off-by: Corinna Vinschen
---
winsup/cygwin/Makefile.in | 2 +-
winsup/cygwin/tzcode/{localtime.cc => localtime_wrapper.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename winsup/cygwin/tzcode/{localtime.cc => localtime_wrapper.c} (100%)
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index 2e8c274a36b3..1e1342ab7849 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -734,7 +734,7 @@ dcrt0.o sigproc.o: child_info_magic.h
shared.o: shared_info_magic.h
-localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
+localtime.o: $(srcdir)/tzcode/localtime_wrapper.c
$(srcdir)/tzcode/localtime.c.patch
(cd $(srcdir)/tzcode && \
patch -u -o localtime.c.patched localtime.c localtime.c.patch)
$(CXX) ${CXXFLAGS} ${localtime_CFLAGS} \
diff --git a/winsup/cygwin/tzcode/localtime.cc
b/winsup/cygwin/tzcode/localtime_wrapper.c
similarity index 100%
rename from winsup/cygwin/tzcode/localtime.cc
rename to
Re: [PATCH] Cygwin: pty: Stop counting number of slaves attached to pseudo console.
On May 25 17:49, Takashi Yano via Cygwin-patches wrote: > - The number of slaves attached to pseudo console is used only for > triggering redraw screen. Counting was not only needless, but also > did not work as expected. This patch removes the code for counting. > --- > winsup/cygwin/fhandler_tty.cc | 22 +- > winsup/cygwin/tty.cc | 3 +-- > winsup/cygwin/tty.h | 1 - > 3 files changed, 6 insertions(+), 20 deletions(-) Pushed. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer
Re: [PATCH] Cygwin: pty: Revise code to make system_printf() work after close.
On May 21 17:25, Takashi Yano via Cygwin-patches wrote: > - After commit 0365031ce1347600d854a23f30f1355745a1765c, the issue > https://cygwin.com/pipermail/cygwin-patches/2020q2/010259.html > occurs. This patch fixes the issue. > --- > winsup/cygwin/fhandler_tty.cc | 15 --- > winsup/cygwin/tty.cc | 23 +++ > winsup/cygwin/tty.h | 2 ++ > 3 files changed, 37 insertions(+), 3 deletions(-) Pushed. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer
[PATCH] Cygwin: pty: Stop counting number of slaves attached to pseudo console.
- The number of slaves attached to pseudo console is used only for
triggering redraw screen. Counting was not only needless, but also
did not work as expected. This patch removes the code for counting.
---
winsup/cygwin/fhandler_tty.cc | 22 +-
winsup/cygwin/tty.cc | 3 +--
winsup/cygwin/tty.h | 1 -
3 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 5faf896e4..df08dd20a 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -1019,8 +1019,6 @@ fhandler_pty_slave::close ()
fhandler_pty_common::close ();
if (!ForceCloseHandle (output_mutex))
termios_printf ("CloseHandle (output_mutex<%p>), %E", output_mutex);
- if (pcon_attached_to == get_minor ())
-get_ttyp ()->num_pcon_attached_slaves --;
return 0;
}
@@ -2924,21 +2922,11 @@ fhandler_pty_slave::fixup_after_attach (bool
native_maybe, int fd_set)
{
if (fhandler_console::get_console_process_id (get_helper_process_id (),
true))
- {
- if (pcon_attached_to != get_minor ())
- {
- pcon_attached_to = get_minor ();
- init_console_handler (true);
- }
- /* Clear screen to synchronize pseudo console screen buffer
-with real terminal. This is necessary because pseudo
-console screen buffer is empty at start. */
- if (get_ttyp ()->num_pcon_attached_slaves == 0)
- /* Assume this is the first process using this pty slave. */
- get_ttyp ()->need_redraw_screen = true;
-
- get_ttyp ()->num_pcon_attached_slaves ++;
- }
+ if (pcon_attached_to != get_minor ())
+ {
+ pcon_attached_to = get_minor ();
+ init_console_handler (true);
+ }
#if 0 /* This is for debug only. */
isHybrid = true;
diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
index 3fc46fb29..efdae4697 100644
--- a/winsup/cygwin/tty.cc
+++ b/winsup/cygwin/tty.cc
@@ -242,9 +242,8 @@ tty::init ()
screen_alternated = false;
mask_switch_to_pcon_in = false;
pcon_pid = 0;
- num_pcon_attached_slaves = 0;
term_code_page = 0;
- need_redraw_screen = false;
+ need_redraw_screen = true;
fwd_done = NULL;
pcon_last_time = 0;
pcon_in_empty = true;
diff --git a/winsup/cygwin/tty.h b/winsup/cygwin/tty.h
index c4dd2e458..7d6fc8fef 100644
--- a/winsup/cygwin/tty.h
+++ b/winsup/cygwin/tty.h
@@ -103,7 +103,6 @@ private:
bool screen_alternated;
bool mask_switch_to_pcon_in;
pid_t pcon_pid;
- int num_pcon_attached_slaves;
UINT term_code_page;
bool need_redraw_screen;
HANDLE fwd_done;
--
2.26.2
