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.]
