Reassigned. Please have a look.

Stefan - we believe this is a direct consequence of the UNO re-work & package
splitting - that broke the bootstrapping logic used in this useful tool (for
gallery generation).

Can you have a quick read & suggest anything ?

Thanks.

Hi Michael, sorry for the delay ... I will have a look at it tomorrow ;-)

I've looked into this and am attaching a patch, from ooo-build:

http://svn.gnome.org/svn/ooo-build/trunk/patches/dev300/gengal-three-layer-install-scp2.diff
http://svn.gnome.org/svn/ooo-build/trunk/patches/dev300/gengal-three-layer-install-svx.diff

Created attachment 54199 [details]
fix: add gengalrc and remove dead code from gengal

kr/sb: six months later and we still have this open. PING? Can we get this into
3.1 (or imho even 3.0.1, the 3-layer OOo broke it) please?

I think this should be fixed in 3.0.1, this is a regression in a externally-used
tools (e.g. for openclipart) to generate the gallery files.

This was even reported against beta, so there was time to fix it for 3.0, but as
usual, the responsible pepole didn't care...

.

done in cws fixgengal

reassign for verification

reopen -  in the cws build gengal is still not working

instead of: 
  Failed to init content broker
  terminate called after throwing an instance of
'com::sun::star::uno::RuntimeException'

I now get:
  terminate called after throwing an instance of
'com::sun::star::registry::InvalidRegistryException'

kr: please have a look and review the patch or reassign

@jcn,rene:  Can anybody briefly explain what gengal is supposed to be doing?  It
was not identified as a relevant tool in the thread starting at
<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19840> and the
back-then owner of this issue (mmeeks) had the issue laying around idle for half
a year (and it apparently at least slipped through my radar).  Is this tool of
any relevance today?

sb: *gen*erate *gal*eries. generaing the gallery files of OOo from a tool (e.g.
from a filelist of png)

yes, actievly used in openclipart packaging by various distros to create the
various files for OOo to appear in the Gallery.

Wrt your mail: maybe soone at that time noticed? Or didn't oversee what issues
the 3-layer OOo cause to gengal?

Right, and why has the issue be idle since half a year?

------- Additional comments from kr Thu May 22 12:13:16 +0000 2008 -------

Hi Michael, sorry for the delay ... I will have a look at it tomorrow ;-)

kr wanted to look at it...

Most distros use ooo-build anyway, which has the patch included, so...

sb: *gen*erate *gal*eries. generaing the gallery files of OOo from a tool (e.g.
from a filelist of png)

yes, actievly used in openclipart packaging by various distros to create the
various files for OOo to appear in the Gallery.

Wrt your mail: maybe soone at that time noticed? Or didn't oversee what issues
the 3-layer OOo cause to gengal?

Right, and why has the issue be idle since half a year?

------- Additional comments from kr Thu May 22 12:13:16 +0000 2008 -------

Hi Michael, sorry for the delay ... I will have a look at it tomorrow ;-)

kr wanted to look at it...

some ime later, jcn added a patch (and afair he was owner then). Still nothing
happening. (And that patch fwiw works in ooo-build).

@rene:  No need to be offended (in case you are; your tone suggests you are).  I
just want to clarify how to proceed.

1  Is gengal needed when building OOo, or is it needed in an installed OOo? 
From your description ("generaing the gallery files of OOo from a tool") I would
assume the former, but oddly it is currently contained in the installation set.

2  How important is this for OOo 3.0.1, given that it is "actievly [sic] used in
openclipart packaging by various distros" and "[m]ost distros use ooo-build
anyway, which has the patch included"?

>@rene:  No need to be offended (in case you are; your tone suggests you are). 

I disagree. *You* copmlain about non-activity in months, but the non-acitity was
at your (or krs) side. Not mmeeks, not jcn.

Me personally didn't notice gengal was broken given that the time it was broken
also in ooo-build I didn't rebuild the openclipart packaages and then I already
had the fix :)

> 1  Is gengal needed when building OOo, or is it needed in an installed OOo? 
> From your description ("generaing the gallery files of OOo from a tool") I
> would assume the former, but oddly it is currently contained in the
> installation set.

Of course it should be in the installset. Where it should it be used from
anyway? For packages not doing anything with OOo except running gengal and
putting the files where they belong in the package?

(Of cuorse, IMHO it should be in -dev, which is done in my packages)

> 2  How important is this for OOo 3.0.1, given that it is "actievly [sic] used
in openclipart packaging by various distros"

as said, it's a) a regression to 2.4.1 (so it should have been fixed in 3.0
anyway), but as it isn't, it's still a regression and thus should be fixed in 3.0.1.

> and "[m]ost distros use ooo-build anyway, which has the patch included"?

Well, that's a point, but why leave it broken in vanilla? (BTW, for 3.1 I plan
a vanilla switch, at that case (means ASAP, because I currently do those
packages) I need gengal fixed in vanilla

> > 1  Is gengal needed when building OOo, or is it needed in an installed OOo? 
> > From your description ("generaing the gallery files of OOo from a tool") I
> > would assume the former, but oddly it is currently contained in the
> > installation set.
>
> Of course it should be in the installset. Where it should it be used from
> anyway? For packages not doing anything with OOo except running gengal and
> putting the files where they belong in the package?

So yes, it's (of course) the latter. The former would not make sense, how do you
generate the gallery files out of openclipart in the OOo build? When openclipart
is completeley separate? ;-)

@rene:  I did not intend to appear complaining.  Anyway.

I still do not see why gengal needs to be part of a vanilla OOo installation set
(which might be ignorance on my part).  The problem is as follows:  If gengal
needs ucb/configmgr functionality, it needs bootstrap variables URE_BOOTSTRAP,
BRAND_BASE_DIR, OOO_BASE_DIR set.  The simplest way to achieve that is to have a
gengalrc next to gengal.bin that is a symlink to redirectrc in the brand layer
program directory.  However, as a basis layer by definition cannot point to a
corresponding brand layer (there might be multiple, varying over time), the only
sane solution would be to move gengal.bin from basis to brand layer (the gengal
wrapper script can probably be removed, anyway).  However, to keep the interface
between brand and basis layer small to ensure compatibility at the micro-version
level, that would in turn imply to split gengal into an executable in the brand
layer and the code itself in the basis layer, where the brand layer executable
just calls the code in the brand layer (cf. soffice.bin and libsofficeapp.so). 
Also, IMO it would be unfortunate to fill the brand layer program directory
(that should ideally only contain the stable interface of OOo that is of
relevance for clients) with tools that are apparently only needed in a very
special scenario (modifying an installed OOo to generate packages for a certain
Linux distro from the installed OOo) and might have uncertain interface stability.

In short, to me it looks like fixing gengal so that it can work as part of an
OOo installation set is nontrivial and has unwelcome consequences.  I think the
best fix would be to extract gengal from the OOo installation set and have it as
a separate tool.

For now, if you do need to call gengal, a workaround is to call it with

-env:URE_BOOTSTRAP=file:///opt/openoffice.org3/program/fundamentalrc

sb

> I still do not see why gengal needs to be part of a vanilla OOo installation 
> set (which might be ignorance on my part). 

It need to be either be in the OOo install set or in the OOo SDK install set.
Unless you operate it out completely as you suggest here:

> In short, to me it looks like fixing gengal so that it can work as part of an
< OOo installation set is nontrivial and has unwelcome consequences.  I think
> the best fix would be to extract gengal from the OOo installation set and
> have it as a separate tool.

Which still would work with an installed OOo.

> special scenario (modifying an installed OOo to generate packages for a certain
> Linux distro from the installed OOo) and might have uncertain interface
> stability.

Eh, no, you seem to misunderstand. The OOo build and OOo packages do nothing
with gengal - except installing it (at least for Debian (openclipart source
packages) , I know SUSE does it different and calls it after the OOo build).
In both scenarios, though, the gallery files get built and installed in
to OOos dirs. in separate packages if needed (Debian: openclipart-openoffice.org)

It's used like the SDK external tools. There's no "modifying an installed OOo".
And if you won't allow  that, how do you register clipart for the gallery
without needing to make the user do it hhimself or do it yourself when packaging?




 hrm, this could be, in ooo-build we have brand + basis in the same dir
(e.g. /usr/lib/openoffice) with the usual basis-link and ure-link dirs.
(basis-link -> basis3.0). 
Maybe it just works by chance in ooo-build because of this?

AFAIK, the only reliable paths on the 3-layer OOo are when they are accessed via
the link, which are intact..

@rene:  I still do not understand who is supposed to call gengal, when.

The reason it works in ooo-build is that it also works in fixgengal :-)

Looking at the gengalrc that is provided it is "obvious" that
OOO_INSTALL_PREFIX must be set.

Here's what I do:

   mkdir fixgengal && cd fixgengal
   ooo-cws-co fixgengal
   cd config_office && ./configure [..]
   ./bootstrap
   dmake
   dmake install DESTDIR=$(pwd)/ooo-cvs prefix=
   export OOO_INSTALL_PREFIX=$(pwd)/ooo-cvs/openoffice.org3
   ooo-cvs/openoffice.org/basis3.0/program/gengal

OOO_INSTALL_PREFIX is supposed to be set by the gengal.sh script,
but that does not work in upstream's split install.

I'm attaching a working but kind of ugly patch for gengal.sh,
I can imagine that someone who actually understands this
split 3layer install can clean it up now it works.

Created attachment 59169 [details]
gengal.sh workaround for upstream's split 3layer install

> @rene:  I still do not understand who is supposed to call gengal, when.

? Didn't I already say that someone who wants to create a OOo gllery file calls
that? From wherever possible.

E.g. in Debian it's done via the openclipart package "build". After converting
svg->png:

                       xvfb-run -a /usr/lib/openoffice/program/gengal --name
"Animals" --path
"/home/rene/Debian/Pakete/openclipart/openclipart-0.18+dfsg//uild/usr/lib/openoffice/share/gallery"
--destdir "home/rene/Debian/Pakete/openclipart/openclipart-0.18+dfsg/build"
--number-from "70"
/usr/share/openclipart/png/animals/az-lizard_benji_park_01.png
/usr/share/openclipart/png/animals/birds/cormorant-md.png [...]

So again, it'a tool for registering whatever cliparts to  OOos gallery. Called
from wherever it's needed/wanted (at Debian in the openclipart build, for SuSE
afaik in the OOo build itself after everything is installed etc and they then
rely on the already packages openclipart and generate the files for the gallaery).

In all times they end up in a package which installs the files in the correct
location.

jcn: hrm, good point :) I don't know how I oversaw this, how embarassing

jcn: patch committed (with a minor comment change)

@jcn:  As I already wrote (#desc20) it does not work to have a basis layer
reference a brand layer.  Hence, the attached gengal.sh-3layer.diff is not an
acceptable, clean solution.

@rene:  I am *still* not confident I do understand exactly the scenarios in
which gengal is supposed to be called.

If it is intended to be called by arbitrary clients of OOo to import gallery
data into an OOo installation (similarly to unopkg being called by arbitrary
clients to import extensions) then it should be moved to the brand layer program
directory (i.e., become part of the stable OOo interface, like unopkg etc.). 
However, in that case, I would like to see general consensus that such a tool
should be maintained in the stable OOo interface (one could also imagine that
unopkg could offer this functionality, for example); ka, as gallery expert,
please speak up.

If, on the other hand, gengal is only supposed to be called in certain
restricted scenarios that can be subsumed under the broad category of producing
OOo installations, then I would still argue to remove gengal from the OOo
installation set and instead making it available (in whatever form appropriate)
during such production of OOo installations.

@rene:  In any event, if the attached gengal-three-layer-install-scp2+svx.diff
is going to be integrated into OOo 3.0.1, the new gid_File_Profile_Gengal is
missing a PATCH flag (see
<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=23009>) and should be
added to a module (like gid_Module_Root_Files_2 that already contains the other
two gengal files).

@sb:

I agree, that the current patches are no clean solution - but they fix (or
implement a workaround) for the people who actually request gengal to be working:
- linux distros who use go-oo
- linux distros who hopefully will use vanilla ooo

at the moment we ship a fully broken gengal. So any fix that improves the
situation is imho acceptable, as long as it does not introduce other regressions.

The rest of the discussion tends to be academic. 

I'd suggest to implement the workaround as suggested by jcn, include it in 3.0.1
(if cws gets approved) and file another issue for a clean solution (where
everyone is free to work on).

> jcn:  As I already wrote (#desc20) it does not work to have a basis layer
> reference a brand layer.  Hence, the attached gengal.sh-3layer.diff is not an
> acceptable, clean solution.

As long as it works...  Clean is not always equivalent with "working". We can
get a clean thing for 3.1 if you invest the time. We have a working solution now...

> @rene:  I am *still* not confident I do understand exactly the scenarios in
> which gengal is supposed to be called.

Then think.

> If it is intended to be called by arbitrary clients of OOo to import gallery
> data into an OOo installation (similarly to unopkg being called by arbitrary
> clients to import extensions) then it should be moved to the brand layer
> program directory (i.e., become part of the stable OOo interface, like unopkg
> etc.). 

Yes, it basically does. It does not import them directly, though but just
creates the files OOo expects and you can then put it into the dir. Like when
you would create them out of the OOo UI:

/.
/usr
/usr/lib
/usr/lib/openoffice
/usr/lib/openoffice/share
/usr/lib/openoffice/share/gallery
/usr/lib/openoffice/share/gallery/sg89.sdv
[...]


> If, on the other hand, gengal is only supposed to be called in certain
> restricted scenarios that can be subsumed under the broad category of
> producing OOo installations, then I would still argue to remove gengal from
> the OOo installation set and instead making it available (in whatever form>
> appropriate) during such production of OOo installations.

E.g. the SDK. It's just additional .sgv/.thm/.sdv files.

Again: the OOo install is the same, it's just additional files put there by
whoever elese, like when the usert would create a new Gallery item via the UI.

I dont argue for it staying in the main install, it also can be in the SDK
(that's what I actually have in Debian), but it has to stay and be available
(and work).

sb: (wrt scp2) yes, thanks. fixed

@andreschnabel:  I agree with you.  Except for the point that the discussion is
academic.  It is vital that OOo has a well-defined interface.  This very issue
shows that an unclear interface causes unnecessary fuss, late in the game.

@rene:  Just to make it clear:  I am not going to invest into a clean solution.
 Others might (ka?).

> @andreschnabel:  I agree with you.  Except for the point that the discussion is
> academic.  It is vital that OOo has a well-defined interface.  This very issue
> shows that an unclear interface causes unnecessary fuss, late in the game.

It caused fuss early in the game. in 3.0.0 beta. That you didn't do anything
even as there was a patch available (which admittedly needed a small fix) is not
my problem. It would have been a blocker for 3.0.0 already. So it's now one for
3.0.1.

Wrt the stable interface you might be right, just move it to the sdk deb and we
can get rid of the discussions, can we? Of course we can't do this 3.0.1 but for
3.1.

> @rene:  Just to make it clear:  I am not going to invest into a clean
> solution. Others might (ka?).

ka doesn't even do his job of getting important OOO300 changes to DEV300, so no,
I don't think he will do this.

I would volunteer for moving it to the SDK deb (same dir, though), but that's
all I would do.

@rene:  I do not really care where this tool ends up, and in what form.  (I only
wanted to prevent it from becoming part of the stable OOo interface if it would
have been a mistake to make it part of that interface, which I still do not
know.)  If you want to move it to SDK, please get in contact with the SDK
maintainers.

For whatever reasonI can not find a program called "gengal" anywhere in my OOo 2.4.1 installation of 
my Ubuntu 8.10, but anyway ...

If I understand correctly, the gengal tool origins somewhere around Kai Ahrens (may be CL?). As some 
of the distros seem to use it for generating galleries, we should raise it's state from "unclear" to 
somewhat like "official" and we may want to add it to the standard tests.

Looking at the code and the included "help" it seems, that "gengal" just generates these galleries as 
requested by some command line arguments, it does _not_ seem to register anything into any 
particular OOo installation (which then likely would have been the brand layer). Being able to run that 
even from the base dir would thus be fully sufficient.

I am going to discuss this tomorrow with Stephen B. to see if we somehow can achieve this.
 

CCing jsc. Ok with moving gengal to the SDK for 3,1?

kr:
> For whatever reasonI can not find a program called "gengal" anywhere in my OOo
> 2.4.1 installation of  my Ubuntu 8.10, but anyway ...

Because as I said in this issue various time, we have moved it to the
openoffice.org-dev package. I never said in this issue it *MUST* be in the
normal OOo install. sb talked about "installset" and the SDK also has one.

Hi Rene, I missed that ... took me already a while to read all the comments ;-) Though I think if you (or 
anybody else) had taken the chance to set the scene (as multiple times requested by SB), may be 
including some usage examples etc., it would have been much easier for us (SB, KR) and even may be 
others to understand what the use of this particular tool is, even if it is so obvious to you.

 

kr:

> If I understand correctly, the gengal tool origins somewhere around Kai Ahrens
> (may be CL?). As some 

No, Was done by Novell in 2.0.x times: issue 49174.
Credits where credits belong.

verified in fixgengal


notice: 
the patch fixes the current request (be able to run gengal in vanilla
openoffice.org instalation on unix) - not less but also not more. Eg.g. gengal
would still fail for other brands (e.g. broffice.org ...)

I set verified - for still open problems we should focus on issue 97814

ok in 3.1 - closed