Scribus scripts

[Craig White]

Apparently Scribus uses python for scripting language but the scripts
aren't installed on x86_64 but only on i386

F7 - x86_64
# rpm -ql scribus|grep scripts
[root@dell-320-2 ~]#
# uname -ir
2.6.22.1-33.fc7 x86_64

F7 - i386
# rpm -ql scribus|grep scripts
/usr/share/scribus/scripts
/usr/share/scribus/scripts/CalendarWizard.py
/usr/share/scribus/scripts/CalendarWizard.pyc
/usr/share/scribus/scripts/CalendarWizard.pyo
/usr/share/scribus/scripts/ChangeLog
/usr/share/scribus/scripts/FontSample.py
/usr/share/scribus/scripts/FontSample.pyc
/usr/share/scribus/scripts/FontSample.pyo
/usr/share/scribus/scripts/NEWS
/usr/share/scribus/scripts/ReadMe
/usr/share/scribus/scripts/TODO
# uname -ir
2.6.22.1-41.fc7 i386

am I missing something here?

[David Christopher Chiipman]

Hi Chris,

If I were you, I'd post a bug report in the Fedora
bugzilla,

-David

[Todd Zullinger]

Craig White wrote:
> Apparently Scribus uses python for scripting language but the scripts
> aren't installed on x86_64 but only on i386

[...]
> am I missing something here?

Nope.  This appears to be a bug in the 64 bit builds.  It affects
ppc64 as well as x86_64.  I reported it to bugzilla here:

https://bugzilla.redhat.com/312091

It seems like a simple fix, but I don't have an x86_64 boxes to test
with.  As linked in the bug, the fix is reported to be to add
--with-extra-libs=%{_libdir} to the %configure call in the spec file.
(I think that the --with-python-dir=... option can be removed then,
but I haven't tested that.)

If you can build an test with the attached changes to the scribus spec
file, add a comment to the bug report if it helps.

(Disclaimer:  I know next to nothing about scribus, I was just curious
about the build failure. :)

[David Christopher Chiipman]

Hi Todd,

I just checked out your bug report, and I noticed that
you didn't indicate which platforms were affected. I certainly know you
have it typed in, but there is a drop down selection for "Platform" as
well, and it is currently set to "ALL". Could you please change that? I
tried, and it wouldn't let me. Thank you,

-Davdi Chipman

[Todd Zullinger]

David C. Chipman wrote:
> I just checked out your bug report, and I noticed that you didn't
> indicate which platforms were affected. I certainly know you have it
> typed in, but there is a drop down selection for "Platform" as well,
> and it is currently set to "ALL". Could you please change that? I
> tried, and it wouldn't let me. Thank you,

If you can tell me how to indicate that it affects both x86_64 and
ppc64*, I'll consider it.  AFAICT, the drop-down only allows one arch
to be selected, which is not correct in this case.

IMHO, this does apply to all hardware, as it's a bug in the spec file.
It only happens to become visible on *64 arches. :)

* at least, it likely affects other 64bit arches if they use a libdir
  other than /usr/lib

[Craig White]

On Sat, 2007-09-29 at 11:37 -0400, Todd Zullinger wrote:
> David C. Chipman wrote:
> > I just checked out your bug report, and I noticed that you didn't
> > indicate which platforms were affected. I certainly know you have it
> > typed in, but there is a drop down selection for "Platform" as well,
> > and it is currently set to "ALL". Could you please change that? I
> > tried, and it wouldn't let me. Thank you,
>
> If you can tell me how to indicate that it affects both x86_64 and
> ppc64*, I'll consider it.  AFAICT, the drop-down only allows one arch
> to be selected, which is not correct in this case.
>
> IMHO, this does apply to all hardware, as it's a bug in the spec file.
> It only happens to become visible on *64 arches. :)
> at least, it likely affects other 64bit arches if they use a libdir
> other than /usr/lib

----
thanks Todd...

believe it or not, I searched bugzilla first but thought that I would
poll the list before I created the bugzilla entry. You beat me to the
punch.

Since these replies came in after I left work on Friday, I didn't have a
chance to look at my one Fedora 7 PPC but I will check on Monday but I
suspect that you are correct.

I will also download the srpm and try out your suggestion and report
back to your bugzilla entry...thanks

Craig

[Craig White]

On Fri, 2007-09-28 at 22:47 -0400, Todd Zullinger wrote:
> Craig White wrote:
> > Apparently Scribus uses python for scripting language but the scripts
> > aren't installed on x86_64 but only on i386
>
> [...]
> > am I missing something here?
>
> Nope.  This appears to be a bug in the 64 bit builds.  It affects
> ppc64 as well as x86_64.  I reported it to bugzilla here:
>
> https://bugzilla.redhat.com/312091
>
> It seems like a simple fix, but I don't have an x86_64 boxes to test
> with.  As linked in the bug, the fix is reported to be to add
> --with-extra-libs=%{_libdir} to the %configure call in the spec file.
> (I think that the --with-python-dir=... option can be removed then,
> but I haven't tested that.)
>
> If you can build an test with the attached changes to the scribus spec
> file, add a comment to the bug report if it helps.
>
> (Disclaimer:  I know next to nothing about scribus, I was just curious
> about the build failure. :)

----
OK - haven't added any comments to bugzilla but I will but wanted to
report my lack of success thus far with building from adjusted spec
file.

First of all, it appears that both the i386 and x86_64 versions of
python devel & libs are installed so after a few abortive installs, I
removed the i386 devel and libs packages.

still though, according my build logs (both commenting out
with-pythondir= line and leaving it in)...

Configuration Summary:

Libraries:
   Freetype2 installed:     Yes
   Fontconfig found:        Yes
   CUPS installed:          Yes
   LittleCMS installed:     Yes
   libtiff installed:       Yes
   Libxml2 installed:       Yes
   Python installed:        No (or too old - 2.3 required)
Configuration options:
   Debugging enabled:       No
   cairo enabled:           No (If you don't know you need this, ignore
it)
Other details:
   GhostScript 8.15 was found at /usr/bin/gs

Good - your configure finished. Start make now

+ --with-extra-libs=/usr/lib64
/var/tmp/rpm-tmp.12154: line 52: --with-extra-libs=/usr/lib64: No such
file or directory
error: Bad exit status from /var/tmp/rpm-tmp.12154 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.12154 (%build)

which leads me to the obvious problem is that it is not finding what it
expects for python. I have tried the following...

in the spec file...
   --with-pythondir=%{_prefix}
   --with-extra-libs=%{_libdir}
or
   --with-pythondir='/usr/lib64'
   --with-extra-libs=%{_libdir}
or
  commenting out the pythondir altogether and
   --with-extra-libs=%{_libdir}

still no change.

It does build ok if I remove the '--with-extra-libs=%{_libdir}' but of
course, without the python scripts.

[Craig White]

On Mon, 2007-10-01 at 12:15 -0700, Craig White wrote:
> On Fri, 2007-09-28 at 22:47 -0400, Todd Zullinger wrote:
> > Craig White wrote:
> > > Apparently Scribus uses python for scripting language but the scripts
> > > aren't installed on x86_64 but only on i386
> >
> > [...]
> > > am I missing something here?
> >
> > Nope.  This appears to be a bug in the 64 bit builds.  It affects
> > ppc64 as well as x86_64.  I reported it to bugzilla here:
> >
> > https://bugzilla.redhat.com/312091
> >
> > It seems like a simple fix, but I don't have an x86_64 boxes to test
> > with.  As linked in the bug, the fix is reported to be to add
> > --with-extra-libs=%{_libdir} to the %configure call in the spec file.
> > (I think that the --with-python-dir=... option can be removed then,
> > but I haven't tested that.)
> >
> > If you can build an test with the attached changes to the scribus spec
> > file, add a comment to the bug report if it helps.
> >
> > (Disclaimer:  I know next to nothing about scribus, I was just curious
> > about the build failure. :)
>
> OK - haven't added any comments to bugzilla but I will but wanted to
> report my lack of success thus far with building from adjusted spec
> file.
>
> First of all, it appears that both the i386 and x86_64 versions of
> python devel & libs are installed so after a few abortive installs, I
> removed the i386 devel and libs packages.
>
> still though, according my build logs (both commenting out
> with-pythondir= line and leaving it in)...
>
> Configuration Summary:
>
> Libraries:
>    Freetype2 installed:     Yes
>    Fontconfig found:        Yes
>    CUPS installed:          Yes
>    LittleCMS installed:     Yes
>    libtiff installed:       Yes
>    Libxml2 installed:       Yes
>    Python installed:        No (or too old - 2.3 required)
> Configuration options:
>    Debugging enabled:       No
>    cairo enabled:           No (If you don't know you need this, ignore
> it)
> Other details:
>    GhostScript 8.15 was found at /usr/bin/gs
>
> Good - your configure finished. Start make now
> --with-extra-libs=/usr/lib64
>
> /var/tmp/rpm-tmp.12154: line 52: --with-extra-libs=/usr/lib64: No such
> file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.12154 (%build)
>
> RPM build errors:
>     Bad exit status from /var/tmp/rpm-tmp.12154 (%build)
>
> which leads me to the obvious problem is that it is not finding what it
> expects for python. I have tried the following...
>
> in the spec file...
>    --with-pythondir=%{_prefix}
>    --with-extra-libs=%{_libdir}
> or
>    --with-pythondir='/usr/lib64'
>    --with-extra-libs=%{_libdir}
> or
>   commenting out the pythondir altogether and
>    --with-extra-libs=%{_libdir}
>
> still no change.
>
> It does build ok if I remove the '--with-extra-libs=%{_libdir}' but of
> course, without the python scripts.

----
OK - I was wrong...this did work - I forgot the \ at the end of the
line. Therefore, this works...

%build
[ -n "$QTDIR" ] || . %{_sysconfdir}/profile.d/qt.sh
%configure  \
   --with-pythondir=%{_prefix} \
   --with-extra-libs=/usr/lib64
make %{?_smp_mflags}

but of course, this is for the x86_64 so some logic would have to be
integrated.

I'm going to test this out on ppc in a few minutes

Thanks (and I will report to bugzilla)

[Todd Zullinger]

Craig White wrote:
> OK - I was wrong...this did work - I forgot the \ at the end of the
> line. Therefore, this works...
>
> %build
> [ -n "$QTDIR" ] || . %{_sysconfdir}/profile.d/qt.sh
> %configure  \
>  --with-pythondir=%{_prefix} \
>  --with-extra-libs=/usr/lib64
> make %{?_smp_mflags}
>
> but of course, this is for the x86_64 so some logic would have to be
> integrated.

The %{_libdir} macro should do the right thing.  On 32 bit arches it
should evaluate to /usr/lib and on 64 bit arches to /usr/lib64.  Does
that one work for you?  If not, what does rpm --eval '%{_libdir}' say
on a 64 bit arch?  (I don't have any to test with, so I'm just going
off of what I'm reading in the rpm macro configs and my understanding
of how it's supposed to work -- either of which may be wrong. :)

I'm pretty sure that using %{_libdir} works on the Fedora build
system, I just built some scrath packages as a test.  Hopefully that
works for you as well. :)

[Craig White]

On Tue, 2007-10-02 at 13:08 -0400, Todd Zullinger wrote:
> Craig White wrote:
> > OK - I was wrong...this did work - I forgot the \ at the end of the
> > line. Therefore, this works...
> >
> > %build
> > [ -n "$QTDIR" ] || . %{_sysconfdir}/profile.d/qt.sh
> > %configure  \
> >  --with-pythondir=%{_prefix} \
> >  --with-extra-libs=/usr/lib64
> > make %{?_smp_mflags}
> >
> > but of course, this is for the x86_64 so some logic would have to be
> > integrated.
>
> The %{_libdir} macro should do the right thing.  On 32 bit arches it
> should evaluate to /usr/lib and on 64 bit arches to /usr/lib64.  Does
> that one work for you?  If not, what does rpm --eval '%{_libdir}' say
> on a 64 bit arch?  (I don't have any to test with, so I'm just going
> off of what I'm reading in the rpm macro configs and my understanding
> of how it's supposed to work -- either of which may be wrong. :)
>
> I'm pretty sure that using %{_libdir} works on the Fedora build
> system, I just built some scrath packages as a test.  Hopefully that
> works for you as well. :)

----
yeah - you're right...

# rpm --eval '%{_libdir}'
/usr/lib64