Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5311 closed enhancement (fixed)

libreoffice-4.3.0

Reported by: Fernando de Oliveira Owned by: Fernando de Oliveira
Priority: normal Milestone: 7.6
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description (last modified by Fernando de Oliveira)

Attachments (2)

libreoffice.patch (3.0 KB ) - added by Armin K 10 years ago.
lo-update.diff (4.6 KB ) - added by christopher 10 years ago.
to update libreoffice page

Download all attachments as: .zip

Change History (61)

comment:1 by Fernando de Oliveira, 10 years ago

Description: modified (diff)

comment:2 by Armin K, 10 years ago

Has anyone been able to build this? I keep getting

Makefile:197: *** fetch__Download_item: libreoffice-dictionaries-4.3.0.4.tar.xz is empty.  Stop.

No matter what I try.

Last edited 10 years ago by Armin K (previous) (diff)

in reply to:  2 comment:3 by christopher, 10 years ago

Replying to Krejzi:

Has anyone been able to build this? I keep getting

Makefile:197: *** fetch__Download_item: libreoffice-dictionaries-4.3.0.4.tar.xz is empty.  Stop.

No matter what I try.

Well I am trying it now and I am getting

:fetchDownload_item: libreoffice-translations-4.3.0.4.tar.xz is empty.

comment:4 by Fernando de Oliveira, 10 years ago

I passed this point, hit two more errors but now it is building, used very not elegant procedure. Don't know if will complete.

Assume help and translations will be used.

After reaching the first error above (necessary, to load the packages or additional ones, if you have the previous version ones).

Restart the build from what follows:

      tar xf $SOURCEDIR/libreoffice-translations-$VERSION.$COMP_EXT \
          --no-overwrite-dir --strip-components=1                   &&
      tar xf $SOURCEDIR/libreoffice-help-$VERSION.$COMP_EXT         \
          --no-overwrite-dir --strip-components=1                   &&
      ./autogen.sh ... --disable-fetch-external                     &&
      make build

Notice the switch switch --disable-fetch-external.

Dictionaries have not been uncompressed, so I may reach a problem, and need to untar that, too.

If that works, building in other machines could start with the --disable-fetch-external all uncompressed, so that should not produce an error.

If everything is correct, it would be good to introduce a previous step in the book just to download, and start the real build already with -disable-fetch-external, if other solution does not appear.

in reply to:  4 comment:5 by christopher, 10 years ago

Replying to fo:

I passed this point, hit two more errors but now it is building, used very not elegant procedure. Don't know if will complete.

Assume help and translations will be used.

After reaching the first error above (necessary, to load the packages or additional ones, if you have the previous version ones).

Restart the build from what follows:

      tar xf $SOURCEDIR/libreoffice-translations-$VERSION.$COMP_EXT \
          --no-overwrite-dir --strip-components=1                   &&
      tar xf $SOURCEDIR/libreoffice-help-$VERSION.$COMP_EXT         \
          --no-overwrite-dir --strip-components=1                   &&
      ./autogen.sh ... --disable-fetch-external                     &&
      make build

Notice the switch switch --disable-fetch-external.

Dictionaries have not been uncompressed, so I may reach a problem, and need to untar that, too.

If that works, building in other machines could start with the --disable-fetch-external all uncompressed, so that should not produce an error.

If everything is correct, it would be good to introduce a previous step in the book just to download, and start the real build already with -disable-fetch-external, if other solution does not appear.

Well I have checked out their git version and have yet to hit any errors. It is building perfectly so far. I have used the same options as online book though as it is git I did not create the sym-links to the dictionaries or the translation files.

comment:6 by Fernando de Oliveira, 10 years ago

Build completed successfully. I cannot install and test immediately.

Last edited 10 years ago by Fernando de Oliveira (previous) (diff)

comment:7 by Fernando de Oliveira, 10 years ago

Build of comment 5 (and later install and test) was in LFS-7.1. Always start LO there, to compare with build with new tool chains.

This morning, woke up and had the unpleasant surprise that build on LFS svn (gcc still 4.9.0) failed.

I was so optimistic, that tried to build it with -j1, so could immediately update the page.

Instead of running twice ./autogen.sh, I found the following would work (don't know if the sed could be the source for the error):

make -j1 fetch || true &&
sed 's/^fetch: get-submodules/#&/' -i Makefile &&
make -j1 build &&

The part with fetch practically was not tested, not sure if it would work without trying to build, because the download had already been done, and only the fetch errors described in previous comments appeared. I was planning to test it in the faster LFS-7.1, afterwards.

The sed makes the fetch (and consequent error) to be skipped.

Tail of error log:

[build LNK] CppunitTest/libtest_cppcanvas_emfplus.so
[build CUT] cppcanvas_emfplus
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

Failures !!!
Run: 1   Failure total: 1   Failures: 0   Errors: 1

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE            # for exception catching
export CPPUNITTRACE="gdb --args"    # for interactive debugging on Linux
export CPPUNITTRACE="\"[full path to devenv.exe]\" /debugexe" \
# for interactive debugging in Visual Studio
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_cppcanvas_emfplus

/tmp/libreoffice-4.3.0.4/solenv/gbuild/CppunitTest.mk:70: recipe for target \
'/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test' failed
make[1]: *** [/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test] \
Error 1
Makefile:224: recipe for target 'build' failed

real	539m26.441s
user	488m3.121s
sys	49m3.551s

(I replaced the full build path ~/tmp/paco... by /tmp and broke the lines, for easier reading.)

I am suspecting again gcc, but have not started trying to study this problem.

Help from both of you or anybody else is strongly welcome, please.

in reply to:  7 comment:8 by christopher, 10 years ago

Replying to fo:

Build of comment 5 (and later install and test) was in LFS-7.1. Always start LO there, to compare with build with new tool chains.

This morning, woke up and had the unpleasant surprise that build on LFS svn (gcc still 4.9.0) failed.

I was so optimistic, that tried to build it with -j1, so could immediately update the page.

Instead of running twice ./autogen.sh, I found the following would work (don't know if the sed could be the source for the error):

make -j1 fetch || true &&
sed 's/^fetch: get-submodules/#&/' -i Makefile &&
make -j1 build &&

The part with fetch practically was not tested, not sure if it would work without trying to build, because the download had already been done, and only the fetch errors described in previous comments appeared. I was planning to test it in the faster LFS-7.1, afterwards.

The sed makes the fetch (and consequent error) to be skipped.

Tail of error log:

[build LNK] CppunitTest/libtest_cppcanvas_emfplus.so
[build CUT] cppcanvas_emfplus
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

Failures !!!
Run: 1   Failure total: 1   Failures: 0   Errors: 1

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE            # for exception catching
export CPPUNITTRACE="gdb --args"    # for interactive debugging on Linux
export CPPUNITTRACE="\"[full path to devenv.exe]\" /debugexe" \
# for interactive debugging in Visual Studio
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_cppcanvas_emfplus

/tmp/libreoffice-4.3.0.4/solenv/gbuild/CppunitTest.mk:70: recipe for target \
'/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test' failed
make[1]: *** [/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test] \
Error 1
Makefile:224: recipe for target 'build' failed

real	539m26.441s
user	488m3.121s
sys	49m3.551s

(I replaced the full build path ~/tmp/paco... by /tmp and broke the lines, for easier reading.)

I am suspecting again gcc, but have not started trying to study this problem.

Help from both of you or anybody else is strongly welcome, please.

Sadly my attempt at installation failed at the installed stage with missing file errors.

I think that it is safe to say at this point at least, that it will not install. I will try again with updating the git checked out code, but that won't be for a while yet. With freeze coming up I am building the latest blfs systemd book.

comment:9 by Armin K, 10 years ago

We don't really need ugly workarounds and hacks to build a package that was working before. I'll bother upstream and let them fix it because it was them who broke it.

comment:10 by Fernando de Oliveira, 10 years ago

Good idea, thanks. I would add my name to the bug report, but perhaps it is not suitable, because we are both from the same distribution, what do you think?

However, th error that I hit in the build is still due to gcc-4.9.0, so will try later to search for a fix, unless you think it is not.

Meanwhile, I need to do other personal business always needed in the beginning of the months.

comment:12 by Armin K, 10 years ago

Unrelated to this issue, but please add your voice to this one too:

https://bugs.freedesktop.org/show_bug.cgi?id=82137

comment:13 by Armin K, 10 years ago

The main issue has been fixed upstream. The following update to the instructions is needed (attached).

by Armin K, 10 years ago

Attachment: libreoffice.patch added

comment:14 by Fernando de Oliveira, 10 years ago

Thanks, Armin. First, for the bug report and discussion with LO developers, so we have the fix (comment 11)

Second, for the attachment.

I had noticed that they moved form src to /external/tarbals.

Interesting, that during build, it checks for src, if it is there it mves to ;external/trbals and symlink sr to there.

I tried to build without the gcc patch (after reading your comment in the bug report) and when came back, it had failed. So, will have to start again.

Will add my voice in Bug 82137.

comment:15 by Armin K, 10 years ago

I have noticed that packages get downloaded to external/tarballs so I switched to using that one. If you use src, the symlinks will become invalid as soon as they are moved (unless you use the current ones with src, which is pointless because they get moved anyways).

comment:16 by Fernando de Oliveira, 10 years ago

No, no, I was not clear: I completely agree with you, thanks for the patch, intend to use it.

Was just expressing that I found it also, and it was already modified in my script, your patch saved me the time to edit those places where it was src.

Bad news is that I cannot, again, build libreoffice, failed with the same message of comment:7

IIRC, previous version failed only for 32bit, my case here, too.

I think Christopher uses 32bit, so, I would like to know if you, Christopher, succeeded building it.

At this point, I am as desperate as in the previous long standing problem of previous version. Will investigate, but any help would be much welcome.

in reply to:  15 comment:17 by Fernando de Oliveira, 10 years ago

Replying to Krejzi:

the symlinks will become invalid as soon as they are moved (unless you use the current ones with src, which is pointless because they get moved anyways).

Forgot to write: the symlink points to external/tarballs, as you know, but when running again autogen.sh or make, not sure wich one, a new src symlink is made, now inside the preivious one, so, inside external/tarballs, and the process is repeated again and again. It is imperative to modify as in your patch, thanks again

in reply to:  12 comment:18 by Fernando de Oliveira, 10 years ago

Replying to Krejzi:

Unrelated to this issue, but please add your voice to this one too:

https://bugs.freedesktop.org/show_bug.cgi?id=82137

Forgot that. Did it a while ago,

in reply to:  7 comment:19 by Fernando de Oliveira, 10 years ago

Replying to fo:

I cannot build this package. I am now using gcc-4.9.1, with the same problem. The two bugs that Armin reported have been quickly fixed. The bug introduced by gcc-4.9.0 and reported at 2014-05-02 06:36 UTC by Jürg Billeter Failure and that I added my name is still not being considered. Error is always the same described at comment 7:

Tail of error log:

[build LNK] CppunitTest/libtest_cppcanvas_emfplus.so
[build CUT] cppcanvas_emfplus
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

...

real 539m26.441s user 488m3.121s sys 49m3.551s }}}

Last statistics (I included many system libraries)

real	125m54.732s
user	883m58.519s
sys	72m44.200s

I am getting tired of this. It is more important solving this than most complaints that have been recently made. Yyesterday there was a very "important" discussion about it" about "gcc version should be a wild card", and I was accused of error, when it was intentional and not an error.

I am really getting tired. I need help here, but people are more keen to find "errors" so "important", that they believe BLFS should stop being published if they are not fixed or the editor should be crucified.

Will try to do some investigation about problem of LO and nothing else, until it is fixed.

Tired, tired.

comment:20 by Armin K, 10 years ago

Try building with clang. Note that building with clang fails on x86_64 though.

comment:21 by Fernando de Oliveira, 10 years ago

Thanks, Armin. Will try tomorrow. Today I'm really without courage of doing any work. Not even searching for solutions. If I get tired of being in bed, will try later today.

in reply to:  20 comment:22 by Fernando de Oliveira, 10 years ago

Replying to Krejzi:

Try building with clang. Note that building with clang fails on x86_64 though.

I forgot I have a commented line for that, and could have done before, thanks.

But as before, it fails and earlier than gcc.

I am leaving this ticket open, anybody wanting to solve build in i686 is welcome.

I have lost a lot of time, effort and courage with this and previous LO. I am inclined of not trying next ones.

It is a shame not having such important package updated in the book, more yet, having next release with an old version.

comment:23 by Armin K, 10 years ago

In the mean time, we can bump to 4.2.6, now marked as libreoffice-still.

DocumentFoundation started offering 2 version to download - still and fresh. Fresh is what is currently 4.3.0, latest release with new features but few regressions. Still is a more mature version, with more point releases and more testing, what is currently 4.2.6.

comment:24 by Fernando de Oliveira, 10 years ago

Description: modified (diff)
Owner: changed from blfs-book@… to Fernando de Oliveira
Status: newassigned
Summary: libreoffice-4.3.0libreoffice-4.2.6

OK. I noticed that, but failed to have this good idea.

Will try, thanks.

comment:25 by Fernando de Oliveira, 10 years ago

Description: modified (diff)
Owner: changed from Fernando de Oliveira to blfs-book@…
Status: assignednew
Summary: libreoffice-4.2.6libreoffice-4.3.0

Failed.

I am doing the following:

  1. changing this back to 4.3.0
  1. opening a ticket for 4.2.6
  1. giving back to the book.
  1. waiting a couple of months before I try LO again.

Only hopes now are Christopher or Ken, they've got a 32bit dev machines.

comment:26 by christopher, 10 years ago

I am now going to attempt to build this MONSTER of a thing again.

I have just downloaded the main tarball again, and will apply the patch that Armin provided.

From looking through the bug reports, some of the issues that you both reported upstream are only going to be fixed in the next release, not this problematic one.

Regards,

Christopher.

comment:27 by bdubbs@…, 10 years ago

Perhaps we should just mark this for the 7.7 milestone.

in reply to:  27 comment:28 by christopher, 10 years ago

Replying to bdubbs@…:

Perhaps we should just mark this for the 7.7 milestone.

Well we have a bit of progress, though I would not call it positive in any way.

We have a new compile error. It does not build against boost 1.56.0 you get the following error:

error: use of deleted function ‘void boost::cref(const T&&) [with T = boost::shared_ptr<cairo::Surface>]’

searching on google found that it also fails on freebsd with the same error and no reported fix.

I will try again without using --with-system-boost and see which version it pulls down.

Thing is, even if it does fully build we would then need to make a decision as to weather to downgrade system boost or to try and work out how to fix the build.

Regards,

Christopher.

comment:29 by Fernando de Oliveira, 10 years ago

I thought it was the the problem, but sick of it, gave up, without even trying.

This has happened frequently in the past. I all cases, first thing is exactly what you have done: use bundled one.

If it is easy enough, submit a patch, never downgrade the book (I learned that the hard way).

If it is not easy to find a patch, we remove the switch from default in the book.

Thanks for the patience of doing this.

comment:30 by Fernando de Oliveira, 10 years ago

Now, drinking a mug of strong "arabica" black coffee.

Good job, thanks!

Looking forward for your successful build. I hope we will be able to include in 7.6 and close the other LO ticket.

Just to be sure, you are working on 4.3.0 or 4.2.6?

in reply to:  30 ; comment:31 by christopher, 10 years ago

Replying to fo:

Now, drinking a mug of strong "arabica" black coffee.

Good job, thanks!

Looking forward for your successful build. I hope we will be able to include in 7.6 and close the other LO ticket.

Just to be sure, you are working on 4.3.0 or 4.2.6?

Well it has finally finished and to a point was successful. It is installed and does work.

We have a new issue with it though. The dictionaries did not get built!!!!!. It was only after I had issued the install commands and went through to the point of the dictionary installs that it said:

root [ /usr/src/libreoffice-4.3.0.4 ]# chown -cR 0:0 dictionaries/: No such file or directory

Also the following on the cleanup:

Cleaning up ... Fixing permissions... /usr/src/libreoffice-4.3.0.4/bin/distro-install-desktop-integration cp: cannot stat ‘/libreoffice-base.appdata.xml’: No such file or directory cp: cannot stat ‘/libreoffice-calc.appdata.xml’: No such file or directory cp: cannot stat ‘/libreoffice-draw.appdata.xml’: No such file or directory cp: cannot stat ‘/libreoffice-impress.appdata.xml’: No such file or directory cp: cannot stat ‘/libreoffice-writer.appdata.xml’: No such file or directory

Please note that at this stage, as I was not even expecting it to complete the build and compilation correctly I have not calculated the SBU or run the test suite.

I will run it through again to calculate this and then update the package in systemd branch where it can be merged into trunk.

That is if everyone still thinks it okay to update the package despite the dictionaries vanishing without a trace.

Oh and it builds against boost 1.55.0.

It took about 10 1/2 hours for me to build using make -j2.

I will wait for comments before I go through and start the sbu dest-dir and tests.

Regards,

Christopher.

comment:32 by Armin K, 10 years ago

The appdata files issue is known and present in current releases too. We copy them manually.

As for dictionaries, if I remember right, we used to extract them manually (and still do in current release), so could you try that? They did work for me, but who knows what I did to get the build working.

in reply to:  30 comment:33 by christopher, 10 years ago

Replying to fo:

Now, drinking a mug of strong "arabica" black coffee.

Good job, thanks!

Looking forward for your successful build. I hope we will be able to include in 7.6 and close the other LO ticket.

Just to be sure, you are working on 4.3.0 or 4.2.6?

Hello Fernando,

I am glad that I was able to help with this. I am now about to build it yet again so that I can get the correct stats.

comment:34 by Fernando de Oliveira, 10 years ago

Very good, indeed! Thanks!

in reply to:  31 ; comment:35 by Fernando de Oliveira, 10 years ago

Milestone: 7.6future

Replying to cjg:

I will run it through again to calculate this and then update the package in systemd branch where it can be merged into trunk.

I was thinking in doing that, but Armin has just make it impossible in New Revision: 13972. He simply does not want you to help us.

The book has always a long tradition of using /opt for many packages, but he decided he does not like it and to change everything to usr. I have succeeded to revert some of these.

To see why I have fights with him, each time he thinks things are getting in peace, he takes the ocasion to do some very irritating thing and who complains aooears as the "bad guy".

This a fundamental disagreement between Armin and the rest of BLFS.

After suggestion of Bruce, changing the ticket to future.

comment:36 by Armin K, 10 years ago

I doubt that any change I made would make it complicated for you to merge the changes. It would be the same as setting LO_PREFIX to /usr. Everything else is just text simplification/correction.

in reply to:  35 comment:37 by Fernando de Oliveira, 10 years ago

Replying to fo:

Replying to cjg:

Just some facts from the past.

Gnome, Qt, LO were installed at /opt. Not after Armin. First, he took Gnome to /usr. Long discussion, finished after he wrote either his way or nothing. Qt, Bruce tried to accommodate giving two alternatives. Not good for Armin who left the book, asked to remove his privileges. LO, there was no complaint. I think there is another package, but cannot remember now.

When started editing, I tried to get things as they were before. Bu respecting his wishes, as alternatives usr or opt. He does not like alternatives. He only likes what he wants.

Yesterday you were running in opt. As usual, without combining with you, he just removed /opt. As he did with Qt. So, be warned: you will have to accept whatever he wants, he will never ask your opinion.

I remember that you were installing gnome in opt, did you change for usr? For what reason, if you don't my asking?

This constant stress with Armin decreases a lot the pleasure of working for BLFS.

comment:38 by Armin K, 10 years ago

Next time use mailing list for stuff like this, because it has nothing to do with the ticket.

  1. By default, LO was installed in /usr before I left. Why? There is no point installing it anywhere else because *everything* is contained in /usr/lib/libreoffice which can be moved around if needed, even to /opt making it possible to revert to an older version when needed. The stuff installed in /usr/bin and /usr/share are symlinks and files *required* to be there so desktops and stuff like that can find them. If you use /opt, you'd have to symlink icons, desktop files, mime data and app data to /usr so it can be found properly, which leaves out only binaries from PREFIX/bin. You have to add them in the path, and they are symlinks to ../lib/libreoffice/blah. Not worth the effort in my oppinion.
  1. GNOME can be installed in /opt, but you have to install some stuff other than from GNOME section in /opt too, namely D-Bus, Polkit, etc. As those are by default installed in /usr and I didn't want to add duplicate packages, it was easier to switch everything to /usr. I still accept any patches that make it possible for GNOME to install in /opt, using as few hacks/workarounds not appealing to my eyes as possible.

Christopher used jhbuild, and jhbuild builds D-Bus and installs it into chosen prefix, yet he couldn't start GDM because D-Bus misbehaved when installed like that. I have no clue why as I never used jhbuild for that kind of stuff. Not to mention that jhbuild builds everything from git, removes possibilities of listing optional, recommended deps and stuff like that.

Note that with KDE5 (Frameworks and Workspaces) it was rather easy to support installing into /opt and I even use that setup for myself.

  1. As for Qt, the instructions still offer installation to /usr and /opt. The "new" instructions back then broke support for installing both Qt's into /usr, which worked perfectly fine before then. BLFS systemd instructions are adjusted to give an user the possibility to install both Qt's into /usr, /opt, /hell or anywhere else without having to use hacks not appealing to my eyes to switch paths just because upstream solution (yes, qtchooser is developed by Qt developers) wasn't understood. The reason of why I quit because someone who had absolutely no clue about what was being done ended up changing the instructions, reverting my work because he thought he knew better (a common disagreement around here) but haven't had the idea what the packages did in the first place.

You and me were there, think about recent colord disagreement, just add "breaking stuff" to the list.

in reply to:  38 comment:39 by Fernando de Oliveira, 10 years ago

Replying to Krejzi:

Next time use mailing list for stuff like this, because it has nothing to do with the ticket.

This is other disagreement I have wit Armin; he dos not politely ask people for anything. He gives orders.

Yesterday he ordered me to "check again" imagemagik. For the sake of the book, I did, thanked and there were two mistakes from him, against thre from myself.

I then replied him ti *please* "check again'. I am still waiting for his acknowledgement.

Now I order Armin:

Next time you address to me or anybody esles be polite, do not give orders.

I strongly order him that, I am not politely asking.

Order Order Order Order Order Order Order Order Order Order Order

Order Order Order Order Order Order Order Order Order Order Order

I finish this discussion with him at this point.

comment:40 by Armin K, 10 years ago

Order? I'm pointing out things. I don't ask, order or whatever, but point out mistakes and stuff like that. You don't need to fix anything if you prefer having something wrong.

by christopher, 10 years ago

Attachment: lo-update.diff added

to update libreoffice page

in reply to:  30 ; comment:41 by christopher, 10 years ago

Replying to fo:

Now, drinking a mug of strong "arabica" black coffee.

Good job, thanks!

Looking forward for your successful build. I hope we will be able to include in 7.6 and close the other LO ticket.

Just to be sure, you are working on 4.3.0 or 4.2.6?

Hello Fernando,

I have just attached a patch for you to update libreoffice in trunk.

Regards,

Christopher.

in reply to:  41 comment:42 by Fernando de Oliveira, 10 years ago

Milestone: future7.6
Owner: changed from blfs-book@… to Fernando de Oliveira
Status: newassigned

Replying to cjg:

Hello Fernando,

I have just attached a patch for you to update libreoffice in trunk.

OK. Thank you very much!

comment:43 by Fernando de Oliveira, 10 years ago

Thanks, Armin and Bruce.

Especial many thanks to Christopher!

That second SBU (144 SBU - 165 SBU) was introduced by Igor or Ken, because build in x86_64 takes much more space. After he introduced, I didn't want to undo it.

Christopher, I needed to make some small fixes, one that I remember is in Command Explanations, adding a fourth sed. I also left the gcc patch - is it OK, or to be removed? Please, check if everything is OK.

Thanks again.

Leaving open until Christopher checks it.

Hopefully fixed at r13990.

in reply to:  43 ; comment:44 by christopher, 10 years ago

Replying to fo:

Thanks, Armin and Bruce.

Especial many thanks to Christopher!

That second SBU (144 SBU - 165 SBU) was introduced by Igor or Ken, because build in x86_64 takes much more space. After he introduced, I didn't want to undo it.

Christopher, I needed to make some small fixes, one that I remember is in Command Explanations, adding a fourth sed. I also left the gcc patch - is it OK, or to be removed? Please, check if everything is OK.

Thanks again.

Leaving open until Christopher checks it.

Hopefully fixed at r13990.

Hello Fernando,

The gcc patch I think is needed. I applied the patch as I was building it both times. I doubt that they have fixed the gcc issue in at least this version. For next version I will try without the patch. It would be good to not have to patch.

After I had made the patch I realized that I had forgotten to do the sed information and I really did not feel like re-doing it again. That is why I covered myself with regards to asking you to check everything, though I knew you would anyway.

As for the SBU value, thank you for the clarification. I had no idea why that was like that and I thought on it for quite some time before going ahead and making the change. Normally for something like that Ken would add a comment in the code for the reason.

I am very glad that I was able to assist with this.

There is one other thing that I find a little alarming with regards to this packages installer. It tried to delete /opt when installing pre-stats calculating install. I do not like packages that try to delete directories they have no right to. Seems like the developers need to change that behaviour as well.

Regards,

Christopher.

in reply to:  44 ; comment:45 by Fernando de Oliveira, 10 years ago

Replying to cjg:

As for the SBU value, thank you for the clarification. I had no idea why that was like that and I thought on it for quite some time before going ahead and making the change. Normally for something like that Ken would add a comment in the code for the reason.

OK. I will insert a comment.

I am very glad that I was able to assist with this.

There is one other thing that I find a little alarming with regards to this packages installer. It tried to delete /opt when installing pre-stats calculating install. I do not like packages that try to delete directories they have no right to. Seems like the developers need to change that behavior as well.

I agree. But I wanted to understand better "delete /opt when installing pre-stats calculating install', because it is very alarming, and should be warned in the page. Imagine this in /usr, trying to delete /usr/lib...

Would you please come with some words for a <warn>? (Cannot remember the correct tag)

in reply to:  45 comment:46 by christopher, 10 years ago

Replying to fo:

Replying to cjg:

As for the SBU value, thank you for the clarification. I had no idea why that was like that and I thought on it for quite some time before going ahead and making the change. Normally for something like that Ken would add a comment in the code for the reason.

OK. I will insert a comment.

I am very glad that I was able to assist with this.

There is one other thing that I find a little alarming with regards to this packages installer. It tried to delete /opt when installing pre-stats calculating install. I do not like packages that try to delete directories they have no right to. Seems like the developers need to change that behavior as well.

I agree. But I wanted to understand better "delete /opt when installing pre-stats calculating install', because it is very alarming, and should be warned in the page. Imagine this in /usr, trying to delete /usr/lib...

Would you please come with some words for a <warn>? (Cannot remember the correct tag)

Hello Fernando,

I am now able to actually use the computer a bit. Installing lfs-systemd-rc1.

I just checked through the log file for libreoffice and found that I was not dreaming about it attempting to delete /opt when I did the install without a log file.

This is in the log:

rmdir: failed to remove ‘/opt’

It is indeed very alarming to see it attempt deleting a directory like this.

Now for the warning:

<warning>This program attempts deleting directories that it has no rights to.</warning>

I think that warning should be simple enough. Unless Bruce or others have a better one.

Regards,

Christopher.

comment:47 by Fernando de Oliveira, 10 years ago

Thanks for your reply, Christopher and for your great contribution to this.

Sorry to disturb you at this time, and to insist about this.

I am really worried about this.

Do you have more than one log?

ISTR, once, not having properly set

LO_PREFIX=/opt/libreoffice-4.3.0.4

but

LO_PREFIX=/opt/

because in my script I had at that time

LO_PREFIX=/opt/$PACKAGE

and doing by hand, I forgot to set PACKAGE, then I got that message. Is there any chance you could verify that possibility?

./autogen.sh --prefix=$LO_PREFIX

I have it installed, but in LFS-7.1, and there, I failed to find any reference to this.

E.g:

$ xzgrep "rmdir" /home/fernando/Downloads/blfs/libreoffice-4.3.0.4-build-2014.08.03-10h32m29s.log.xz
[build SRS] cui/source/tabpages/frmdirlbox.src
[build CXX] svx/source/dialog/frmdirlbox.cxx

I do find (and perhaps was in that cleaning stage that I got the problem):

DEST install
Installing in /opt/libreoffice-4.3.0.4/lib/libreoffice ...
Cleaning destdir...
Running LibreOffice installer
... checking environment variables ...

in reply to:  47 ; comment:48 by christopher, 10 years ago

Replying to fo:

Thanks for your reply, Christopher and for your great contribution to this.

Sorry to disturb you at this time, and to insist about this.

I am really worried about this.

Do you have more than one log?

ISTR, once, not having properly set

LO_PREFIX=/opt/libreoffice-4.3.0.4

but

LO_PREFIX=/opt/

because in my script I had at that time

LO_PREFIX=/opt/$PACKAGE

and doing by hand, I forgot to set PACKAGE, then I got that message. Is there any chance you could verify that possibility?

./autogen.sh --prefix=$LO_PREFIX

I have it installed, but in LFS-7.1, and there, I failed to find any reference to this.

E.g:

$ xzgrep "rmdir" /home/fernando/Downloads/blfs/libreoffice-4.3.0.4-build-2014.08.03-10h32m29s.log.xz
[build SRS] cui/source/tabpages/frmdirlbox.src
[build CXX] svx/source/dialog/frmdirlbox.cxx

I do find (and perhaps was in that cleaning stage that I got the problem):

DEST install
Installing in /opt/libreoffice-4.3.0.4/lib/libreoffice ...
Cleaning destdir...
Running LibreOffice installer
... checking environment variables ...

Hello Fernando,

It is in the cleaning stage that this happens. I used Bruce's script for this install. The libreoffice prefix is correctly set:

#!/bin/bash

source /usr/src/stats

#######################

DIR=pwd PROGRAM=libreoffice-4.3.0.4 LOG=$DIR/$PROGRAM.log TITLE=$PROGRAM TIMEFORMAT="$TIMEFMT $TITLE" export LO_PREFIX=/opt

BUILDDIR=/opt/build/libreoffice DEST=$BUILDDIR/install

Notice that I have exported the prefix in the script.

I hope that this is the information that you are asking for.

Regards,

Christopher.

in reply to:  48 ; comment:49 by Fernando de Oliveira, 10 years ago

Replying to cjg:

Hello Fernando,

It is in the cleaning stage that this happens. I used Bruce's script for this install. The libreoffice prefix is correctly set:

DIR=pwd PROGRAM=libreoffice-4.3.0.4 LOG=$DIR/$PROGRAM.log TITLE=$PROGRAM TIMEFORMAT="$TIMEFMT $TITLE" export LO_PREFIX=/opt

BUILDDIR=/opt/build/libreoffice DEST=$BUILDDIR/install

Notice that I have exported the prefix in the script.

I hope that this is the information that you are asking for.

Thanks. That was exactly what I was asking.

You need to change

export LO_PREFIX=/opt

to the new version:

export LO_PREFIX=/opt/libreoffice-4.3.0.4

I am assuming that uou are using in the script

./autogen.sh --prefix=$LO_PREFIX         \
             --sysconfdir=/etc           \
...

with that, the cleaning is on /opt/libreoffice-4.3.0.4, not /opt

Please, confirm that, and we won't need the warning.

in reply to:  49 comment:50 by christopher, 10 years ago

Replying to fo:

Replying to cjg:

Hello Fernando,

It is in the cleaning stage that this happens. I used Bruce's script for this install. The libreoffice prefix is correctly set:

DIR=pwd PROGRAM=libreoffice-4.3.0.4 LOG=$DIR/$PROGRAM.log TITLE=$PROGRAM TIMEFORMAT="$TIMEFMT $TITLE" export LO_PREFIX=/opt

BUILDDIR=/opt/build/libreoffice DEST=$BUILDDIR/install

Notice that I have exported the prefix in the script.

I hope that this is the information that you are asking for.

Thanks. That was exactly what I was asking.

You need to change

export LO_PREFIX=/opt

to the new version:

export LO_PREFIX=/opt/libreoffice-4.3.0.4

I am assuming that uou are using in the script

./autogen.sh --prefix=$LO_PREFIX         \
             --sysconfdir=/etc           \
...

with that, the cleaning is on /opt/libreoffice-4.3.0.4, not /opt

Please, confirm that, and we won't need the warning.

Hello Fernando,

Yes I am using:

./autogen.sh --prefix=$LO_PREFIX \

--sysconfdir=/etc \ --with-vendor="BLFS" \ --with-lang="en-US pt-BR" \

I got the same warning though when I was not using the script. I did a normal export LO_PREFIX=/opt.

So are the published instructions incorrect? I am just trying to understand why I got this error both with and without the script. I just followed the export command that was on the previous versions page.

Regards,

Christopher.

comment:51 by bdubbs@…, 10 years ago

I didn't/don't have a make script for libreoffice. What Fernando has should be correct, but I haven't checked it.

comment:52 by Fernando de Oliveira, 10 years ago

No, the published instructions are correct:

Due to the large size of the package, you may prefer to install it in /opt, instead of /usr.
Depending on your choice, replace <PREFIX> by /usr or by /opt/libreoffice-4.3.0.4:

export LO_PREFIX=<PREFIX>

...

./autogen.sh --prefix=$LO_PREFIX         \
...

in reply to:  52 comment:53 by christopher, 10 years ago

Replying to fo:

No, the published instructions are correct:

Due to the large size of the package, you may prefer to install it in /opt, instead of /usr.
Depending on your choice, replace <PREFIX> by /usr or by /opt/libreoffice-4.3.0.4:

export LO_PREFIX=<PREFIX>

...

./autogen.sh --prefix=$LO_PREFIX         \
...

It was my frigging error. In my hurry to get it tested I just saw to export the prefix that libreoffice was to be installed to. I totally failed to see that it had to be the full path to libreoffice directory.

I am so glad that it was not the developers who had made a serious gaff.

I was only now able to check the online version as the testsuite on this gcc has put my systems load up to 19 with systemdcoredumps during the testing. Coming up to 4 hours now for gcc.

comment:54 by Fernando de Oliveira, 10 years ago

No problem.

Thanks for confirming, so we can get it right.

Again, thankyou very much for your collaboration.

Bottom line: I will include in the xml a comment about the reason for the ranges aof SBU and MB in the statiscs, thanks to you.

Cheers.

comment:55 by Fernando de Oliveira, 10 years ago

Replying to cjg:

It was my frigging error.

We all do these things, no problem at all, really. You are doing a great job.

comment:56 by Fernando de Oliveira, 10 years ago

Resolution: fixed
Status: assignedclosed

Small fixes at r14034.

comment:57 by Armin K, 10 years ago

Building in chroot and I have hit the same problem as in comment 7.

However, it looks to me like the unit test needs access to X (DISPLAY set and being able to use it).

After I ran "xhost +" on my host and restarted the build, it finished just fine.

Can anyone confirm?

comment:58 by Armin K, 10 years ago

A good way to confirm it would be building through SSH without X forwarding, and when it fails try to run make again (still without X), and if it fails again, try to run make again, but with X forwarding.

For now, I can make an assumption that it needs to be built from an X environment.

comment:59 by Fernando de Oliveira, 10 years ago

Cannot test now. Please wait when I will start 7.6-rc1. I am trying to not be off, but need to do things very slowly, and hopefully get back to full speed for testing rc1.

Note: See TracTickets for help on using tickets.