Re: cygport ... install starts in cwd but ... all does not
On 18.05.2020 17:47, Brian Inglis wrote: On 2020-05-17 02:13, Marco Atzeri via Cygwin-apps wrote: On 17.05.2020 08:45, Brian Inglis wrote: When rerunning a cygport build with "cygport *.cygport all" after fixing up problems stage by stage, "doicon $NAME.png" at the start of src_install, before "cd/pushd ${B}" fails with fatal message "*** ERROR: file $NAME.png does not exist", whereas rerunning "cygport *.cygport install" succeeds without any messages. Even changing cd to pushd, and adding popd at the end of each src_... function, does not solve the issue. The package does not include an icon, so I downloaded something suitable to the same package directory as the $NAME.cygport and *.patch PATCH_URI files. Any alternative approaches that anyone can suggest might work? can we see the file ? May be is a banal issue that you are oversighting Doh - of course - attached! Hi Brian, may be also the patches ? Anyway removing most of the cygport to fake the compilation and installation and putting just some pwd before and after the pushd/popd to see what is happening: $ cygport tek4010.cygport compile >>> Compiling tek4010-1.5-1.x86_64 /pub/tmp /pub/tmp/tek4010-1.5-1.x86_64/build /pub/tmp $ cygport tek4010.cygport install >>> Installing tek4010-1.5-1.x86_64 /pub/tmp *** ERROR: file Tek4010.png does not exist so you need a pushd ${S} before doicon Tek4010.png pushd ${B} Regards Marco
Re: cygport ... install starts in cwd but ... all does not
On 2020-05-19 11:43, Marco Atzeri via Cygwin-apps wrote: > On 18.05.2020 17:47, Brian Inglis wrote: >> On 2020-05-17 02:13, Marco Atzeri via Cygwin-apps wrote: >>> On 17.05.2020 08:45, Brian Inglis wrote: When rerunning a cygport build with "cygport *.cygport all" after fixing up problems stage by stage, "doicon $NAME.png" at the start of src_install, before "cd/pushd ${B}" fails with fatal message "*** ERROR: file $NAME.png does not exist", whereas rerunning "cygport *.cygport install" succeeds without any messages. Even changing cd to pushd, and adding popd at the end of each src_... function, does not solve the issue. The package does not include an icon, so I downloaded something suitable to the same package directory as the $NAME.cygport and *.patch PATCH_URI files. Any alternative approaches that anyone can suggest might work? >>> can we see the file ? >>> May be is a banal issue that you are oversighting >> Doh - of course - attached! > may be also the patches ? You mean switching to apply during prep? You are probably right! Thanks very much for that insight. Will have to look into what that runs. > Anyway removing most of the cygport to fake the compilation > and installation and putting just some pwd before and after the > pushd/popd to see what is happening: > > $ cygport tek4010.cygport compile Compiling tek4010-1.5-1.x86_64 > /pub/tmp > /pub/tmp/tek4010-1.5-1.x86_64/build > /pub/tmp > > > $ cygport tek4010.cygport install Installing tek4010-1.5-1.x86_64 > /pub/tmp > *** ERROR: file Tek4010.png does not exist Thanks also for the suggestion of approach to take using pwd around everything. > so you need a pushd ${S} before > > doicon Tek4010.png > pushd ${B} SRC_DIR=Tek4010 as the sources are extracted in that directory instead of src. The local package files .cygport, .patch, .png are all under my main ~/src/cygwin/tek4010/ directory where I invoke cygport, so it starts there, but seems unable to get back there. Should be able to get this done and maybe offer an ITP. Although this package appears designed to build in user home dir under Raspbian (and Ubuntu, so also Debian), it does not seem to be packaged anywhere I can find. I'll see if the author would be interested in a packaging PR to remove home dir dependencies and support Cygwin packaging and its metas, and maybe I could also add Debian/Raspbian/Ubuntu metas as they are somewhat similar and standard. -- 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.]
Re: cygport ... install starts in cwd but ... all does not
On 19.05.2020 20:56, Brian Inglis wrote: On 2020-05-19 11:43, Marco Atzeri via Cygwin-apps wrote: On 18.05.2020 17:47, Brian Inglis wrote: On 2020-05-17 02:13, Marco Atzeri via Cygwin-apps wrote: On 17.05.2020 08:45, Brian Inglis wrote: may be also the patches ? You mean switching to apply during prep? You are probably right! Thanks very much for that insight. Will have to look into what that runs. I was just saying I can not test the full process, so I focused on just the doicon ;-) Anyway removing most of the cygport to fake the compilation and installation and putting just some pwd before and after the pushd/popd to see what is happening: $ cygport tek4010.cygport compile Compiling tek4010-1.5-1.x86_64 /pub/tmp /pub/tmp/tek4010-1.5-1.x86_64/build /pub/tmp $ cygport tek4010.cygport install Installing tek4010-1.5-1.x86_64 /pub/tmp *** ERROR: file Tek4010.png does not exist Thanks also for the suggestion of approach to take using pwd around everything. I am used to have "cd ${S}" or "cd ${B}" as first step, so I had no clue if there was a default. Cygport code is not obvious, so adding "pwd" was the easy way to debug so you need a pushd ${S} before doicon Tek4010.png pushd ${B} SRC_DIR=Tek4010 as the sources are extracted in that directory instead of src. The local package files .cygport, .patch, .png are all under my main ~/src/cygwin/tek4010/ directory where I invoke cygport, so it starts there, but seems unable to get back there. I use a common directory for both x86 and x86_64 platform and the test installation versions of both. $ readlink -f /pub /cygdrive/d/cyg_pub I assume unusual enough that "pwd" is useful a lot Should be able to get this done and maybe offer an ITP. Although this package appears designed to build in user home dir under Raspbian (and Ubuntu, so also Debian), it does not seem to be packaged anywhere I can find. I'll see if the author would be interested in a packaging PR to remove home dir dependencies and support Cygwin packaging and its metas, and maybe I could also add Debian/Raspbian/Ubuntu metas as they are somewhat similar and standard. The build system seems very basic and old style. Probably to be as light as possible as the target is a Raspberry Pi. Regards Marco
Help needed with gobject-introspection
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. Can anyone help? Thanks. Ken 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" PKG_NAMES="libbabl0.1_0 libbabl-devel" # girepository-Babl0.1 vala-babl0.1" libbabl0_1_0_SUMMARY="${SUMMARY} (runtime)" libbabl0_1_0_CONTENTS="usr/bin/*-0.1-0.dll usr/lib/babl-0.1/ usr/share/doc/" libbabl_devel_SUMMARY="${SUMMARY} (development)" libbabl_devel_CONTENTS="usr/include/ usr/lib/lib* usr/lib/pkgconfig/" girepository_Babl0_1_SUMMARY="${SUMMARY} (GObject Introspection)" girepository_Babl0_1_CONTENTS="usr/*/gir*/Babl-0.1.*" vala_babl0_1_SUMMARY="${SUMMARY} (Vala bindings)" vala_babl0_1_CONTENTS="usr/share/vala/" CYGMESON_ARGS="-Dwith-docs=false" # CYGMESON_ARGS+=" -Denable-gir=false" --- origsrc/babl-0.1.74/meson.build 2020-01-12 18:26:51.0 -0500 +++ src/babl-0.1.74/meson.build 2020-05-18 18:11:58.729959300 -0400 @@ -104,7 +104,6 @@ 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_osx = host_os.startswith('darwin') @@ -118,7 +117,7 @@ platform_android = host_os.contains('and path_sep = ( platform_win32 ? ';' : ':' ) dirs_sep = ( platform_win32 ? '' : '/' ) -if platform_win32 +if platform_win32 or host_os.startswith('cygwin') lib_ext = '.dll' elif platform_osx lib_ext = '.dylib' @@ -145,7 +144,6 @@ build_os = build_machine.system() message('Bui
Re: cygport ... install starts in cwd but ... all does not
On 2020-05-19 14:16, Marco Atzeri via Cygwin-apps wrote: > On 19.05.2020 20:56, Brian Inglis wrote: >> On 2020-05-19 11:43, Marco Atzeri via Cygwin-apps wrote: >>> On 18.05.2020 17:47, Brian Inglis wrote: On 2020-05-17 02:13, Marco Atzeri via Cygwin-apps wrote: > On 17.05.2020 08:45, Brian Inglis wrote: > >> >>> may be also the patches ? >> >> You mean switching to apply during prep? >> You are probably right! >> Thanks very much for that insight. >> Will have to look into what that runs. > > I was just saying I can not test the full process, > so I focused on just the doicon ;-) > >>> Anyway removing most of the cygport to fake the compilation >>> and installation and putting just some pwd before and after the >>> pushd/popd to see what is happening: >>> >>> $ cygport tek4010.cygport compile >> Compiling tek4010-1.5-1.x86_64 >>> /pub/tmp >>> /pub/tmp/tek4010-1.5-1.x86_64/build >>> /pub/tmp >>> >>> >>> $ cygport tek4010.cygport install >> Installing tek4010-1.5-1.x86_64 >>> /pub/tmp >>> *** ERROR: file Tek4010.png does not exist >> >> Thanks also for the suggestion of approach to take using pwd around >> everything. > > I am used to have "cd ${S}" or "cd ${B}" as first step, > so I had no clue if there was a default. > Cygport code is not obvious, so adding "pwd" was the > easy way to debug > > >>> so you need a pushd ${S} before >>> >>> doicon Tek4010.png >>> pushd ${B} >> >> SRC_DIR=Tek4010 as the sources are extracted in that directory instead of >> src. >> >> The local package files .cygport, .patch, .png are all under my main >> ~/src/cygwin/tek4010/ directory where I invoke cygport, so it starts there, >> but >> seems unable to get back there. > > I use a common directory for both x86 and x86_64 platform > and the test installation versions of both. > > $ readlink -f /pub > /cygdrive/d/cyg_pub > > I assume unusual enough that "pwd" is useful a lot > >> Should be able to get this done and maybe offer an ITP. >> >> Although this package appears designed to build in user home dir under >> Raspbian >> (and Ubuntu, so also Debian), it does not seem to be packaged anywhere I can >> find. >> >> I'll see if the author would be interested in a packaging PR to remove home >> dir >> dependencies and support Cygwin packaging and its metas, and maybe I could >> also >> add Debian/Raspbian/Ubuntu metas as they are somewhat similar and standard. On the project Github issues, someone already built and is using on Cygwin, so I will ask about packaging and some other requirements that came up there. > The build system seems very basic and old style. > Probably to be as light as possible as the target is a Raspberry Pi. Lack of any (interest in?) packaging background, but not development, and not that light, as this project just provides an X Window Tek emulator front end, under Debian LXDE X client and server, possibly over ssh or VNC, for a SimH PDP-11 (or PDP-8 for PiDP-8 emulated console) simulator running original Unix V7 or BSD 2.11 OS and graphics apps driving the Tek, inside a PiDP-11 providing a hardware interface to miniature emulated console switches and blinkenlights as well as a hardware serial port connected into the simulator: https://obsolescence.wixsite.com/obsolescence/pidp-11 -- 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.]