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
[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: [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,
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.
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
