Re: [Libreoffice] Installing beta versions replacing stable versions

On 04/26/2011 02:39 PM, Michael Meeks wrote:
> Hi NoOp,
>
> On Tue, 2011-04-26 at 10:05 -0700, NoOp wrote:
> > >    So - please do try to fix the bug yourself, patches are most welcome.
> > > If you come with some solid research, and some concrete suggestions / a
> > > prototype patch you'll find some helpful feedback.
> >
> > Right...
> > https://bugs.freedesktop.org/show_bug.cgi?id=31747#c7
> > https://bugs.freedesktop.org/attachment.cgi?id=46059
>
>       Great - the most basic console output; it is a start of course. But
> this is really only a scratch into a rich seam of research:
>
> Unpacking libobasis3.4-ogltrans (from
> libobasis3.4-ogltrans_3.4.0-103_i386.deb) ...
> dpkg: error processing libobasis3.4-ogltrans_3.4.0-103_i386.deb (--install):
>  trying to overwrite 
> '/opt/libreoffice/basis3.4/share/config/soffice.cfg/simpress/transitions-ogl.xml', which is also 
> in package libobasis3.4-impress 3.4.0-103
>
>       Sounds like we need to grep for 'transitions-ogl' goodness inside our
> packaging code - please have a grep around in the scp2/ module and see
> what you can find there, to make a prototype fix.
>
> Setting up libreoffice3-dict-en (3.4.0-103) ...
> /opt/libreoffice/program/../basis-link/ure-link/bin/javaldx: symbol lookup error: 
> /opt/libreoffice/ure/bin/../lib/libuno_cppuhelpergcc3.so.3: undefined symbol: 
> _ZTIN9salhelper21SimpleReferenceObjectE, version UDK_3_0_0
> /opt/libreoffice/program/unopkg.bin: symbol lookup error: 
> /opt/libreoffice/program/../basis-link/program/libxcrli.so: undefined symbol: 
> _ZN4cppu11OWeakObject12queryAdapterEv, version UDK_3_0_0
> find: `/opt/libreoffice/./share/prereg/bundled': No such file or directory
> Setting up libreoffice3-dict-es (3.4.0-103) ...
>
>       Also looks odd; we need more information on what symbols the libraries
> export; find that with: objdump -T foo.so - and hunt around for the
> symbols it mentions. Similarly where this 'find ... bundled' comes from
> in the source is worth digging out: use './g grep prereg/bundled' and
> dig through it I guess.
>
>       The more information we have, and the better the detective job - the
> more we understand, the more obvious the fix will become. None of this
> work is beyond the wit of someone competent at installing things from
> the console as you are :-)
>
>       Thanks !
>
>               Michael.

Thanks, but as I mentioned previously:

"I'm not a developer, but I consider my self to be an above-average
user/tester with exeperience in installing, bug reporting et al on OOo
and more recently LO. I can/do install test versions on everything from
linux to Win (2K, XP, and Wn7) in both standard native partitions &
Virtual Machines. I think that Cor Nouows will attest to that."

I certainly don't mind testing new or pre-release versions, but I'm not
about to attempt patches or debugging (without specific instructions -
and then only if I have time on a clean test machine).

Fact of the matter is that the B1 and B2 .debs are borked. Bug reports
have been filed or added to (by me, other users, devs).

The "most basic console output" tells you, and other devs, exactly what
the issues are. If someone building LO Beta releases can't figure out
the issue from there then I'm pretty much at a loss.

- Who tested the .deb files before release?
- What distro did they test them on?
- B1 reported similar issues, etc., etc.

Going back to the OP and the premise of providing LO Beta/RC as
"Installing beta versions replacing stable versions" packages: you
already know the answer to this - it's been done on OOo versions for a
very long time. Are you telling the users on this thread that you a
uaware of the ooo-dev builds and how they are/were accomplished?

Bottom line is that previously I didn't mind testing LO pre-release
(B/RC) builds on my systems, contributing to LO bug reports, and/or
assisting other users with LO. But quite frankly given your we can't see
the forest for the trees response I see no reason to continue to do so.

If your simple pre-release builds can't install and your dev's can't
figure out the issue from "the most basic console output" then good
luck. I don't mind assisting if I can, but I do mind the condescending:

> So - if you have a Linux system, and you're capable of installing
> packages; then most likely you are able to climb the cliff of digging
> around to work out how to package them for a different prefix -
> right ? :-)

I *am* capable of installing packages. I *am* capable of trying LO
Beta/RC packages. I *am* capable of telling you (and whatever dev) that
the packages that *LO* put out fail (either on this list or in a bug
report). I *am* capable of telling you (and all other devs) on this list
that your B1 & B2 .deb packages are crap. They fail, they do not
install, they have already been reported and are documented in this thread.

The OP requested that beta versions be installed w/o affecting existing
version. You are well aware of the OOo-dev build process. You are well
aware of the issue, Yet you are asking posters to this thread to "dig
out the documentation, test that it still works"? Amazing.

I'll no longer test *any* LO pre-release versions. Good luck with
attracting future/further user testers.

tml <quote>
"That is because I am basically an incoherent dribbling idiot, la la la,
na na splutgh xzbbpfft! Me wants more porridge!"
</quote>