From awilliamson at mandriva.com  Thu May  3 02:57:30 2007
From: awilliamson at mandriva.com (Adam Williamson)
Date: Wed, 02 May 2007 17:57:30 -0700
Subject: [Skencil-devel] Skencil build issues in modern environment
Message-ID: <1178153850.4968.712.camel@lenovo.local.net>

Hi!

I've been working through old packages in Mandriva updating them and I
came to Skencil, which has now been kicking my ass for a couple of
days :)

I can't get it to work in our current development environment:

Tcl/Tk 8.5a5
X.org 7.2
Python 2.5
python-imaging 1.1.16

I'm using current SVN skencil-0.6 branch.

it will build and run but crashes immediately:

[adamw at lenovo ~]$ skencil 
shared memory images supported
Could not load font '-misc-fixed-medium-*-*-*-11-*-*-*-*-*-iso8859-1'
for ruler. using defaults.
Traceback (most recent call last):
  File "/usr/bin/skencil", line 34, in <module>
    Sketch.main.main()
  File "/usr/lib/skencil-0.6.17/Sketch/Base/main.py", line 148, in main
    run_script = options.run_script)
  File "/usr/lib/skencil-0.6.17/Sketch/UI/skapp.py", line 183, in
__init__
    self.build_window()
  File "/usr/lib/skencil-0.6.17/Sketch/UI/skapp.py", line 223, in
build_window
    self.run_script)
  File "/usr/lib/skencil-0.6.17/Sketch/UI/mainwindow.py", line 97, in
__init__
    self.build_window()
  File "/usr/lib/skencil-0.6.17/Sketch/UI/mainwindow.py", line 592, in
build_window
    hrule = ruler.Ruler(root, orient = ruler.HORIZONTAL)
  File "/usr/lib/skencil-0.6.17/Sketch/UI/ruler.py", line 68, in
__init__
    font = self.tkwin.LoadQueryFont('fixed')
AttributeError: Ruler instance has no attribute 'tkwin'

I believe this to be an incompatibility with Tcl/Tk 8.5, as the same
package does build and run on Mandriva Linux 2007, which uses Tcl/Tk
8.4. Also uses python 2.4, X.org 7.1 and python-imaging 1.1.14, but I
feel the problem is with Tcl/Tk.

The Skencil build process also seems to be...

um...

antiquated :)

it really does not build at all on x86-64, it just isn't set up for it.
Doesn't understand the concept of /usr/lib64 or the possibility that
some stuff (e.g. the Python setup file) might live there.

It's still set up for old-fashioned monolithic X only: it expects
everything to be in /usr/X11R6.

It doesn't know Tcl/Tk 8.5 even exists :)

It installs everything to /usr/lib/skencil-{version}. This is not, I
think, in line with modern Python practice, where all the .py files are
supposed to go to /{libdir}/python{version}/site-packages/skencil ,
where {libdir} is /usr/lib or /usr/lib64.

I gave up on fixing the last issue, but I fixed all the others in my
current spec. It includes:

1. A patch to change the default FontPath in config.py:

-font_path = ['/usr/X11R6/lib/X11/fonts/Type1',
-	     '/usr/share/ghostscript/fonts',
-	     '/usr/lib/ghostscript/fonts']
+font_path = ['/usr/share/fonts/default/Type1',
+	     '/usr/share/fonts/default/ghostscript',
+	     '/usr/share/fonts/misc']

(the patch also makes a lot of other changes to the default font
definitions, but that may be Mandriva-specific, the changes are as
discussed on the Skencil download page - "Mandriva ships Skencil
packages, at least you can get them from their cooker and the mirrors.
At time of writing (May 2006) Mandriva's cooker has a 0.6.17 Skencil
package. Some Mandriva versions had missconfigured fonts. If you have
this problem there is a solution outlined in Mandriva Issue#20899.")

2. A patch that clues setup.py in to the existence of tcl 8.5:

-    for version in ["8.4", "8.3", "8.2", "8.1", "8.0"]:
+    for version in ["8.5", "8.4", "8.3", "8.2", "8.1", "8.0"]:

3. The following commands to respect X.org 7.x file locations:

perl -pi -e 's,/usr/X11R6,/usr,g' Pax/Setup.in
perl -pi -e 's,/usr/X11R6,/usr,g' setup.py
perl -pi -e 's,/usr/X11R6,/usr,g' Sketch/Modules/Setup.in

4. The following commands to clue Skencil in to the existence
of /usr/lib64 on x86-64 arch. %_libdir is a standard rpm macro that
expands to /usr/lib or /usr/lib64 as appropriate. Unfortunately I
couldn't use it for the substitions in the "%ifarch x86_64" bit because
they're a bit too indirect. Messy, I know. If you're wondering why just
one of the commands uses sed and the others all use perl it's because I
couldn't figure out how to escape a ' properly with perl's substitution
stuff! (the command replaces 'lib' with 'lib64')

perl -pi -e 's,\$\(exec_prefix\)/lib,%_libdir,g' Pax/Makefile.pre.in
perl -pi -e 's,\$\(exec_installdir\)/lib,%_libdir,g' Pax/Makefile.pre.in
perl -pi -e 's,\$\(exec_prefix\)/lib,%_libdir,g' Filter/Makefile.pre.in
perl -pi -e 's,\$\(exec_installdir\)/lib,%_libdir,g'
Filter/Makefile.pre.in
perl -pi -e 's,\$\(exec_prefix\)/lib,%_libdir,g'
Sketch/Modules/Makefile.pre.in
perl -pi -e 's,\$\(exec_installdir\)/lib,%_libdir,g'
Sketch/Modules/Makefile.pre.in
perl -pi -e 's,/usr/lib,%_libdir,g' Pax/Setup.in
perl -pi -e 's,/usr/lib,%_libdir,g' setup.py
%ifarch x86_64
perl -pi -e 's,lib/python,lib64/python,g' setup.py
sed -i s/\'lib\'/\'lib64\'/ setup.py
%endif

5. The parameter --python-setup=%py_platlibdir/config/Setup
to ./setup.py configure. %py_platlibdir is a Mandriva RPM macro that
expands to /usr/lib/python{version} or /usr/lib64/python{version} as
appropriate. Without this, the configure process always looks
for /usr/lib/python{version}/config/Setup, even on x86-64.

Note that I haven't yet tested the x86-64 build, not having an x86-64
machine handy to test on (I build via ssh on our build cluster's x86-64
machine, but I can't run X apps on it). I have tested the i586 build on
Mandriva 2007 and it appears to work OK.

Hope this is interesting to all. If anyone wants to help on the Tcl/Tk 
8.5 / font issue, that would be greatly welcomed :)
-- 
adamw


From bernhard at intevation.de  Thu May  3 10:30:51 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 3 May 2007 10:30:51 +0200
Subject: [Skencil-devel] Skencil build issues in modern environment
In-Reply-To: <1178153850.4968.712.camel@lenovo.local.net>
References: <1178153850.4968.712.camel@lenovo.local.net>
Message-ID: <200705031030.56347.bernhard@intevation.de>

Hi Adam,

thanks for the good write up and for fixing Skencil for Mandriva!

On Thursday 03 May 2007 02:57, Adam Williamson wrote:
> Note that I haven't yet tested the x86-64 build, not having an x86-64
> machine handy to test on (I build via ssh on our build cluster's x86-64
> machine, but I can't run X apps on it). I have tested the i586 build on
> Mandriva 2007 and it appears to work OK.

There has been a patch fixing a 64bit problem two days ago:
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/skencil/branches/skencil-0.6/Pax/fontobject.c?root=skencil&rev=694&r1=686&r2=694

> Hope this is interesting to all. If anyone wants to help on the Tcl/Tk
> 8.5 / font issue, that would be greatly welcomed :)

Yes, this is all very interesting!
We need to incoporate your changes in the Skencil codebase 
(and help with this is appreciated).

What problems do remain for you after your changes?

Bernhard R.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070503/8277d3ea/attachment.pgp

From awilliamson at mandriva.com  Thu May  3 10:42:02 2007
From: awilliamson at mandriva.com (Adam Williamson)
Date: Thu, 03 May 2007 01:42:02 -0700
Subject: [Skencil-devel] Skencil build issues in modern environment
In-Reply-To: <200705031030.56347.bernhard@intevation.de>
References: <1178153850.4968.712.camel@lenovo.local.net>
	<200705031030.56347.bernhard@intevation.de>
Message-ID: <1178181722.4968.770.camel@lenovo.local.net>

On Thu, 2007-03-05 at 10:30 +0200, Bernhard Reiter wrote:
> Hi Adam,
> 
> thanks for the good write up and for fixing Skencil for Mandriva!
> 
> On Thursday 03 May 2007 02:57, Adam Williamson wrote:
> > Note that I haven't yet tested the x86-64 build, not having an x86-64
> > machine handy to test on (I build via ssh on our build cluster's x86-64
> > machine, but I can't run X apps on it). I have tested the i586 build on
> > Mandriva 2007 and it appears to work OK.
> 
> There has been a patch fixing a 64bit problem two days ago:
> http://wald.intevation.org/plugins/scmsvn/viewcvs.php/skencil/branches/skencil-0.6/Pax/fontobject.c?root=skencil&rev=694&r1=686&r2=694

Yes, that's in my package (it's SVN rev 695).

> > Hope this is interesting to all. If anyone wants to help on the Tcl/Tk
> > 8.5 / font issue, that would be greatly welcomed :)
> 
> Yes, this is all very interesting!
> We need to incoporate your changes in the Skencil codebase 
> (and help with this is appreciated).

I'm not qualified for that, I'm not a coder at all :) I just try to make
the stuff build.

> What problems do remain for you after your changes?

No functional problems I know of. Just the thing about installing
to /usr/lib/skencil : it doesn't seem right.

I forgot to mention some other things in my mail...we have the following
two workarounds in the spec, too, they pre-date my changes:

---

# (fg) Install program is shitty to say the least, we have to substitute
all
# occurences of RPM_BUILD_{ROOT,DIR} to void :(
# Geoff says that the following is too disgusting to watch and harmful
# for your health.

set +x
(
  cd $RPM_BUILD_ROOT

  for i in `find -type f`; do
    perl -pi -e "s|$RPM_BUILD_ROOT||" $i;
    perl -pi -e "s|$RPM_BUILD_DIR||" $i;
  done
)
set -x

---

# Now correct all the bugs the install script introduces:
%if %svn
cp Sketch/Modules/*so $RPM_BUILD_ROOT
%{_libdir}/%{name}-%{internalversion}/Sketch/Modules
cp Filter/*so Pax/*so $RPM_BUILD_ROOT
%{_libdir}/%{name}-%{internalversion}/Lib/
%else
cp Sketch/Modules/*so $RPM_BUILD_ROOT
%{_libdir}/%{name}-%{version}/Sketch/Modules
cp Filter/*so Pax/*so $RPM_BUILD_ROOT%{_libdir}/%{name}-%{version}/Lib/
%endif

---

I've verified both are actually still needed. Without the first, the
compiled files contain explicit references to our RPM build directory,
so obviously don't work. I really don't know what the hell the second
one is for, but without it, the build doesn't succeed on x86-64, with a
rather cryptic error.

Aside from this, another problem is that Skencil includes no icon and
no .desktop file. I took skencil-logo.png from the Fedora package (no
idea where they got it) to use as an icon, and I have these lines in the
spec to install freedesktop.org icon theme spec compliant icons:

mkdir -p %buildroot%{_iconsdir}/hicolor/{48x48,32x32,16x16}/apps
convert -scale 48x48 %SOURCE1 %buildroot%_iconsdir/hicolor/48x48/apps/%{name}.png
convert -scale 32x32 %SOURCE1 %buildroot%_iconsdir/hicolor/32x32/apps/%{name}.png
convert -scale 16x16 %SOURCE1 %buildroot%_iconsdir/hicolor/16x16/apps/%{name}.png

I have these lines to create a .desktop file:

mkdir -p $RPM_BUILD_ROOT%{_datadir}/applications
cat > $RPM_BUILD_ROOT%{_datadir}/applications/mandriva-%{name}.desktop << EOF
[Desktop Entry]
Encoding=UTF-8
Name=Skencil
Comment=Drawing tool
Exec=%{_bindir}/%{name} %f
Icon=%{name}
Terminal=false
Type=Application
StartupNotify=true
MimeType=image/x-sk
Categories=Graphics;VectorGraphics;X-MandrivaLinux-Multimedia-Graphics
EOF

The X-MandrivaLinux-Multimedia-Graphics category is Mandriva-specific,
the rest should be generic.
-- 
adamw


From bernhard at intevation.de  Thu May  3 11:02:17 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 3 May 2007 11:02:17 +0200
Subject: [Skencil-devel] Skencil build issues in modern environment
In-Reply-To: <1178181722.4968.770.camel@lenovo.local.net>
References: <1178153850.4968.712.camel@lenovo.local.net>
	<200705031030.56347.bernhard@intevation.de>
	<1178181722.4968.770.camel@lenovo.local.net>
Message-ID: <200705031102.18586.bernhard@intevation.de>

On Thursday 03 May 2007 10:42, Adam Williamson wrote:
> > There has been a patch fixing a 64bit problem two days ago:
> > http://wald.intevation.org/plugins/scmsvn/viewcvs.php/skencil/branches/sk
> >encil-0.6/Pax/fontobject.c?root=skencil&rev=694&r1=686&r2=694
>
> Yes, that's in my package (it's SVN rev 695).

Very good, I was only making this sure.

> > > Hope this is interesting to all. If anyone wants to help on the Tcl/Tk
> > > 8.5 / font issue, that would be greatly welcomed :)
> >
> > Yes, this is all very interesting!
> > We need to incoporate your changes in the Skencil codebase
> > (and help with this is appreciated).
>
> I'm not qualified for that, I'm not a coder at all :) I just try to make
> the stuff build.

Most of the changes you have made are for the build code
which is part of the code base. We just have to separate the generel
improvements from the Mandriva specific ones.

Generel should go into the main code
and specific ones we could add to our repository in a 
packaging/mandriva subdirectory.

> > What problems do remain for you after your changes?
>
> No functional problems I know of. 

Ah, this is good to know.

> Just the thing about installing 
> to /usr/lib/skencil : it doesn't seem right.
>
> I forgot to mention some other things in my mail...we have the following
> two workarounds in the spec, too, they pre-date my changes:

As I said, we could add the mandriva specs to the Skencil repository,
but I know that you already maintain them in your SCM, so it might
not be necessary. So we only need to extract which of your changes
are interesting for all Skencil users/builders.

Best,
Bernhard R.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070503/f81bc0b5/attachment.pgp

From awilliamson at mandriva.com  Thu May  3 11:10:44 2007
From: awilliamson at mandriva.com (Adam Williamson)
Date: Thu, 03 May 2007 02:10:44 -0700
Subject: [Skencil-devel] Skencil build issues in modern environment
In-Reply-To: <200705031102.18586.bernhard@intevation.de>
References: <1178153850.4968.712.camel@lenovo.local.net>
	<200705031030.56347.bernhard@intevation.de>
	<1178181722.4968.770.camel@lenovo.local.net>
	<200705031102.18586.bernhard@intevation.de>
Message-ID: <1178183444.4968.775.camel@lenovo.local.net>

On Thu, 2007-03-05 at 11:02 +0200, Bernhard Reiter wrote:
> On Thursday 03 May 2007 10:42, Adam Williamson wrote:
> > > There has been a patch fixing a 64bit problem two days ago:
> > > http://wald.intevation.org/plugins/scmsvn/viewcvs.php/skencil/branches/sk
> > >encil-0.6/Pax/fontobject.c?root=skencil&rev=694&r1=686&r2=694
> >
> > Yes, that's in my package (it's SVN rev 695).
> 
> Very good, I was only making this sure.
> 
> > > > Hope this is interesting to all. If anyone wants to help on the Tcl/Tk
> > > > 8.5 / font issue, that would be greatly welcomed :)
> > >
> > > Yes, this is all very interesting!
> > > We need to incoporate your changes in the Skencil codebase
> > > (and help with this is appreciated).
> >
> > I'm not qualified for that, I'm not a coder at all :) I just try to make
> > the stuff build.
> 
> Most of the changes you have made are for the build code
> which is part of the code base. We just have to separate the generel
> improvements from the Mandriva specific ones.

I feel that the changes I do are hacks, not genuine solutions. From what
I've seen, the build system Skencil uses is rather old, and I suspect if
you look at what is available in python 2.5 or what is used by other
modern python apps, it would include much more robust fixes for the same
issues.

> > I forgot to mention some other things in my mail...we have the
> following
> > two workarounds in the spec, too, they pre-date my changes:
> 
> As I said, we could add the mandriva specs to the Skencil repository,
> but I know that you already maintain them in your SCM, so it might
> not be necessary. So we only need to extract which of your changes
> are interesting for all Skencil users/builders.

I feel at least the first workaround indicates a problem with Skencil:
the Skencil build process is doing something wrong to actually write the
buildroot directories into the generated files. Generally speaking, with
a good build system, this kind of workaround in a spec file is not
necessary. I'm sorry I'm not a hacker and so can't tell you what the
build process is doing wrong :(
-- 
adamw


From bernhard at intevation.de  Fri May  4 10:24:54 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 4 May 2007 10:24:54 +0200
Subject: [Skencil-devel] Skencil build issues in modern environment
In-Reply-To: <1178183444.4968.775.camel@lenovo.local.net>
References: <1178153850.4968.712.camel@lenovo.local.net>
	<200705031102.18586.bernhard@intevation.de>
	<1178183444.4968.775.camel@lenovo.local.net>
Message-ID: <200705041024.58045.bernhard@intevation.de>

On Thursday 03 May 2007 11:10, Adam Williamson wrote:
> I feel that the changes I do are hacks, not genuine solutions. 

Some of the changes seem just to be fine, e.g. like adding a new tcl/tk 
version to the list or an X.org fontpath.

With the path of the installation, Bernhard Herzog told me that 
he deliberately did not place it under site-packages because there is
not good versioning and Skencil is a full blown application and not merely
a library. Python's distutils seem to be mainly for libraries which Skencil
is not. Is there a comparable user application in Python in Mandriva
that we could inspect to see where they place it?

There is the idea to be able to install more than one version of Skencil
and call them separately. Using a subdirectory seems prudent to me.

> From what I've seen, 
> the build system Skencil uses is rather old, and I suspect if 
> you look at what is available in python 2.5 or what is used by other
> modern python apps, it would include much more robust fixes for the same
> issues.

We have to inquire about the lib64 things 
and see what more modern distutils would actually help with.

> I feel at least the first workaround indicates a problem with Skencil:
> the Skencil build process is doing something wrong to actually write the
> buildroot directories into the generated files. Generally speaking, with 
> a good build system, this kind of workaround in a spec file is not
> necessary. I'm sorry I'm not a hacker and so can't tell you what the
> build process is doing wrong :(

Yes, this looks like a defect in the build process somewhere. 
Thanks a lot for your hints and opinions, this is quite useful and
hey it makes you a hacker even if you are not a hard-core coder! ;)

Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070504/63da80e3/attachment.pgp

From awilliamson at mandriva.com  Fri May  4 10:49:21 2007
From: awilliamson at mandriva.com (Adam Williamson)
Date: Fri, 04 May 2007 01:49:21 -0700
Subject: [Skencil-devel] Skencil build issues in modern environment
In-Reply-To: <200705041024.58045.bernhard@intevation.de>
References: <1178153850.4968.712.camel@lenovo.local.net>
	<200705031102.18586.bernhard@intevation.de>
	<1178183444.4968.775.camel@lenovo.local.net>
	<200705041024.58045.bernhard@intevation.de>
Message-ID: <1178268561.6812.24.camel@lenovo.local.net>

On Fri, 2007-04-05 at 10:24 +0200, Bernhard Reiter wrote:
> On Thursday 03 May 2007 11:10, Adam Williamson wrote:
> > I feel that the changes I do are hacks, not genuine solutions. 
> 
> Some of the changes seem just to be fine, e.g. like adding a new tcl/tk 
> version to the list or an X.org fontpath.

Oh, yeah, those two can be adopted. I think the font paths we use should
apply to all distros.

> With the path of the installation, Bernhard Herzog told me that 
> he deliberately did not place it under site-packages because there is
> not good versioning and Skencil is a full blown application and not merely
> a library. Python's distutils seem to be mainly for libraries which Skencil
> is not. Is there a comparable user application in Python in Mandriva
> that we could inspect to see where they place it?

Good idea. Here's an example - freevo:

http://sophie.zarb.org/viewrpm/0f002d883ca38b877a94ddd7a76759c7

as you can see, most stuff goes to the standard places - binaries
to /usr/bin , config stuff to /etc , static data to /usr/share - and all
the actual Python files go to /usr/lib/python2.5/site-packages/freevo .

Fedora uses the same system. So does SUSE, AFAICT. Ubuntu / Debian
appear to have a slightly customised system based around
a /usr/share/pycentral directory.

> There is the idea to be able to install more than one version of Skencil
> and call them separately. Using a subdirectory seems prudent to me.

In general distributions don't expect two versions of the same app to be
installable because it generally doesn't make sense. In the rare cases
where it does, we have systems for making it possible. This generally
involves having two packages and renaming the conflicting files (so
you'd have skencil1 and skencil2 packages,
with /usr/lib/python2.5/site-packages/skencil1
and /usr/lib/python2.5/site-packages/skencil2 , /usr/bin/skencil1
and /usr/bin/skencil2, etc). Where necessary, the Debian alternatives
system can be used to make it simple to switch between versions. This
isn't something that really needs to be made possible upstream IMHO,
unless for some reason you think it's critical.

> > From what I've seen, 
> > the build system Skencil uses is rather old, and I suspect if 
> > you look at what is available in python 2.5 or what is used by other
> > modern python apps, it would include much more robust fixes for the same
> > issues.
> 
> We have to inquire about the lib64 things 
> and see what more modern distutils would actually help with.

OK, cool :) You couldn't use my hacks, obviously, as they will only work
within an RPM build where the libdir macro is available. But I'm sure
it's something that you could get just by updating to a more modern
Python build system.

> > I feel at least the first workaround indicates a problem with Skencil:
> > the Skencil build process is doing something wrong to actually write the
> > buildroot directories into the generated files. Generally speaking, with 
> > a good build system, this kind of workaround in a spec file is not
> > necessary. I'm sorry I'm not a hacker and so can't tell you what the
> > build process is doing wrong :(
> 
> Yes, this looks like a defect in the build process somewhere. 
> Thanks a lot for your hints and opinions, this is quite useful and
> hey it makes you a hacker even if you are not a hard-core coder! ;)

Thanks :) As I mentioned, this workaround is not mine, it was in the
package when I came to it. Unfortunately it's not commented so I can't
tell who the original author was, otherwise I'd find them and ask if
they know what's wrong with the build process :)
-- 
adamw


From awilliamson at mandriva.com  Mon May  7 04:55:49 2007
From: awilliamson at mandriva.com (Adam Williamson)
Date: Sun, 06 May 2007 19:55:49 -0700
Subject: [Skencil-devel] More build issues
Message-ID: <1178506549.5335.108.camel@lenovo.local.net>

Hey, guys.

I thought I'd roll up my sleeves and see if I could hack Skencil to put
stuff in the right places.

The attached patch to setup.py results in stuff getting installed in the
right places, more or less. The .py and .so files go
to /usr/lib/python2.5/site-packages/skencil-{version}, and other stuff -
all static data files like font definitions, images etc - go
to /usr/share/skencil-{version}. It has a few obvious shortcuts: it's
not x86-64 safe (it installs stuff to /usr/lib whatever arch it's on)
and python2.5 is written into it because I'm not a hacker so I have no
idea how to make it check the python version. I tried 'python
%(pyversion)' since that variable seems to be used somewhere else in
setup.py, but that resulted in everything getting installed to a
directory really named "/usr/lib/python%(pyversion)", so that's not
it ;) The python thing should be very easy for a real coder to fix, the
x86-64 safety thing would come as a result of overhauling the whole
build process to be x86-64 aware.

The bigger problem, obviously, is that once all this stuff is changed,
Skencil doesn't work any more. It seems to be written only for the case
that all of Skencil's files are installed in one place, so of course it
breaks with the patch. I guess all that would be needed would be some
changes to config.py , but I'm not smart enough to make them. I think
this should also be quite easy for a real coder.

Well, anyway, I thought after complaining I should at least roll up my
sleeves and do what I could! hope this hacky effort is at least a
stimulus for someone to fix stuff properly. :)

I should note again that the 'standard' build process in recent versions
of python appears to cover all this stuff. At least, browsing the python
docs site, I see pages like
http://docs.python.org/inst/alt-install-windows.html which indicate that
the modern python installation process understands the basic concepts of
installing 'pure' modules to /usr/lib/site-packages , 'non-pure' modules
to /usr/lib{64}/site-packages , scripts to /usr/bin and static date
to /usr/share.
-- 
adamw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_install.patch
Type: text/x-patch
Size: 2985 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070506/e0c95db0/test_install.bin

From bernhard at intevation.de  Tue May  8 15:15:42 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 8 May 2007 15:15:42 +0200
Subject: [Skencil-devel] More build issues
In-Reply-To: <1178506549.5335.108.camel@lenovo.local.net>
References: <1178506549.5335.108.camel@lenovo.local.net>
Message-ID: <200705081515.43801.bernhard@intevation.de>

Hi Adam,

On Monday 07 May 2007 04:55, Adam Williamson wrote:
> I thought I'd roll up my sleeves and see if I could hack Skencil to put
> stuff in the right places.

wow, thanks for doing so.
Once I get Bernhard H. convinced that those are actually the right places,
we will find a way of putting Skencil there. Your input does give us some
arguments of course, this is what makes it valueable. ;)

> The bigger problem, obviously, is that once all this stuff is changed,
> Skencil doesn't work any more. It seems to be written only for the case
> that all of Skencil's files are installed in one place, so of course it
> breaks with the patch. I guess all that would be needed would be some
> changes to config.py , but I'm not smart enough to make them. I think
> this should also be quite easy for a real coder.

You probably have to change the PYTHONPATH to include all the directories.
Python's import statement will also use a patch components, like
	import xxx/yyy

> Well, anyway, I thought after complaining I should at least roll up my
> sleeves and do what I could! hope this hacky effort is at least a
> stimulus for someone to fix stuff properly. :)

It is. All feedback is nice.

> I should note again that the 'standard' build process in recent versions
> of python appears to cover all this stuff. At least, browsing the python
> docs site, I see pages like
> http://docs.python.org/inst/alt-install-windows.html which indicate that
> the modern python installation process understands the basic concepts of
> installing 'pure' modules to /usr/lib/site-packages , 'non-pure' modules
> to /usr/lib{64}/site-packages , scripts to /usr/bin and static date
> to /usr/share.

I will peek a look there and at your patch. 
Thanks again for the pointer and for fixing Skencil for Mandriva users!

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070508/012e757f/attachment.pgp

From mail at hboeck.de  Wed May  9 06:48:59 2007
From: mail at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=)
Date: Wed, 9 May 2007 06:48:59 +0200
Subject: [Skencil-devel] skencil configure --without-nls
Message-ID: <200705090649.00179.mail@hboeck.de>

Hi,

It's common on configuration scripts that if they support a --with-something 
option, it's also possible to pass --without-something.

This isn't true for --with-nls/--without-nls on skencil, attached patch will 
do it.

-- 
Hanno B?ck		Blog:   http://www.hboeck.de/
GPG: 3DBD3B20		Jabber: jabber at hboeck.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skencil-configure-without-nls.diff
Type: text/x-diff
Size: 481 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070509/f8f0c0d7/skencil-configure-without-nls.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070509/f8f0c0d7/attachment.pgp

From bernhard at intevation.de  Thu May 10 12:24:58 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 10 May 2007 12:24:58 +0200
Subject: [Skencil-devel] skencil configure --without-nls
In-Reply-To: <200705090649.00179.mail@hboeck.de>
References: <200705090649.00179.mail@hboeck.de>
Message-ID: <200705101224.59300.bernhard@intevation.de>

Hanno,

On Wednesday 09 May 2007 06:48, Hanno B?ck wrote:
> It's common on configuration scripts that if they support a
> --with-something option, it's also possible to pass --without-something.
>
> This isn't true for --with-nls/--without-nls on skencil, attached patch
> will do it.

thanks!
(BTW: You could also use the patch tracker on 
http://wald.intevation.org/tracker/?group_id=5)
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20070510/dd6896c9/attachment.pgp