Libreoffice building (sort of)

Libreoffice building (sort of)

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Well currently the libreoffice package in wip-libreoffice branch, builds, installs and 
seems to work ok.

Slightly worrying is that the first few builds crashed in one of LO's unittests.  I added
the line (setenv "CPPUNITTRACE" "gdb --args") which I expected just to give me a backtrace
to help me diagnose the problem.  I was very surprised doing this, caused the package to 
build, test and install without error! -- A Heisenbug.

Anyway, like I say, the  package works, but is a bit rough.   I suggest that some of the
dependencies are tidied up, reviewed and pushed to master,  and the deeper issues investigated
later.  Help doing this is welcome.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Libreoffice building (sort of)

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> Well currently the libreoffice package in wip-libreoffice branch, builds, installs and 
> seems to work ok.

Wo0t!  Excellent!

> Slightly worrying is that the first few builds crashed in one of LO's unittests.  I added
> the line (setenv "CPPUNITTRACE" "gdb --args") which I expected just to give me a backtrace
> to help me diagnose the problem.  I was very surprised doing this, caused the package to 
> build, test and install without error! -- A Heisenbug.

How is $CPPUNITTRACE used exactly?  If it’s used as in:

  sh -c $CPPUNITTRACE test-program

then I’m surprised it works at all, because ‘gdb --args test-program’
just spawns an interactive GDB session.

Any idea what happens?

> Anyway, like I say, the  package works, but is a bit rough.   I suggest that some of the
> dependencies are tidied up, reviewed and pushed to master,  and the deeper issues investigated
> later.  Help doing this is welcome.

Sounds like a good plan!

Ludo’.

Re: Libreoffice building (sort of)

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Mon, Nov 24, 2014 at 07:03:58PM +0100, Ludovic Court??s wrote:
     John Darrington <john@darrington.wattle.id.au> skribis:
     
     > Well currently the libreoffice package in wip-libreoffice branch, builds, installs and 
     > seems to work ok.
     
     Wo0t!  Excellent!
     
     > Slightly worrying is that the first few builds crashed in one of LO's unittests.  I added
     > the line (setenv "CPPUNITTRACE" "gdb --args") which I expected just to give me a backtrace
     > to help me diagnose the problem.  I was very surprised doing this, caused the package to 
     > build, test and install without error! -- A Heisenbug.
     
     How is $CPPUNITTRACE used exactly?  If it???s used as in:
     
       sh -c $CPPUNITTRACE test-program
     
     then I???m surprised it works at all, because ???gdb --args test-program???
     just spawns an interactive GDB session.
     
     Any idea what happens?

Yes, I was suprised too.  Maybe it runs some preprepared script.
     
J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

9x15bold xfont

[白い熊 @相撲道]

I'm very fond of the 9x15bold X font for work in the terminal. On Debian systems it's usually in the “xfonts” package. No such package exists in Guix. I checked, and none of the built xorg derivations on my system have the font. 

Does some package have it? 
--
白い熊 @相撲道

Re: 9x15bold xfont

[Andreas Enge]

On Mon, Mar 09, 2015 at 10:24:26PM +0100, 白い熊 @相撲道 wrote:
> I'm very fond of the 9x15bold X font for work in the terminal. On Debian systems it's usually in the “xfonts” package. No such package exists in Guix. I checked, and none of the built xorg derivations on my system have the font. 

In debian it is in xfonts-base, in the subdirectory "misc". We have various
font packages in xorg.scm. I think you are looking for font-misc-misc.

Andreas

Re: 9x15bold xfont

[白い熊 @相撲道]

On 2015年3月9日 23:03:20 CET, Andreas Enge <andreas@enge.fr> wrote:
>In debian it is in xfonts-base, in the subdirectory "misc". We have
>various
>font packages in xorg.scm. I think you are looking for font-misc-misc.

Thank you, that's the package. 

However, as there's obviously no /usr/share/fonts... dir, how and where should I configure, so that X apps will now see the fonts os installed. 

I could probably play with fontdir in xorg.scm manually, but is that the place? Will it survive system reconfigures? 
- -
白い熊 @相撲道

Re: 9x15bold xfont

[宋文武]

Yes, you can modify xorg.scm, and then reconfigure your GuixSD from
the modified sources.
But IMO the xserver.conf in xorg.scm is not in a good shape for customization.

Also you can install the fonts into user's profile, then do:
  xset +fp ~/.guix-profile/share/fonts/X11

Re: Libreoffice building (sort of)

[白い熊 @相撲道]

On 2014年11月24日 18:19:33 CET, John Darrington wrote:
>Well currently the libreoffice package in wip-libreoffice
>branch, builds, 
>installs and 
>seems to work ok.

Until the building errors are all fixed and it's merged with master, is there a way I can install it on GuixSD? How would, I do this? 

Or is the only way to git pull Guix, build it in GuixSD, and deploy from the branch there? 
--
白い熊 @相撲道

Re: Libreoffice building (sort of)

[白い熊 @相撲道]

On 2015年3月10日 9:54:43 CET, "白い熊 @相撲道" <guix-devel_gnu.org@sumou.com> wrote:
>On 2014年11月24日 18:19:33 CET, John Darrington wrote:
>>Well currently the libreoffice package in wip-libreoffice
>>branch, builds, 
>>installs and 
>>seems to work ok.
>
>Until the building errors are all fixed and it's merged with master, is
>there a way I can install it on GuixSD? How would, I do this? 
>
>Or is the only way to git pull Guix, build it in GuixSD, and deploy
>from the branch there? 

So maybe it's working... What I've done: 

wget http://git.savannah.gnu.org/cgit/guix.git/snapshot/wip-libreoffice.tar.gz
guix pull --url=file:///path/to/wip-libreoffice.tar.gz
guix package -i libreoffice

It's building now, apparently everything from source, so probably a long way to go... 

Let's see if it will put a unable libreoffice instance in the store... 
--
白い熊 @相撲道

Re: Libreoffice building (sort of)

[Ludovic Courtès]

"白い熊 @相撲道" <guix-devel_gnu.org@sumou.com> skribis:

> wget http://git.savannah.gnu.org/cgit/guix.git/snapshot/wip-libreoffice.tar.gz
> guix pull --url=file:///path/to/wip-libreoffice.tar.gz
> guix package -i libreoffice
>
> It's building now, apparently everything from source, so probably a long way to go... 
>
> Let's see if it will put a unable libreoffice instance in the store... 

Please let us know how it goes.  If it builds and is usable, we should
merge it.

Ludo’.

Re: Libreoffice building (sort of)

[白い熊＠相撲道]

On 2015-03-10 13:41, ludo@gnu.org wrote:
> "白い熊 @相撲道" <guix-devel_gnu.org@sumou.com> skribis:
> 
>> wget 
>> http://git.savannah.gnu.org/cgit/guix.git/snapshot/wip-libreoffice.tar.gz
>> guix pull --url=file:///path/to/wip-libreoffice.tar.gz
>> guix package -i libreoffice
>> 
>> It's building now, apparently everything from source, so probably a 
>> long way to go...
>> 
>> Let's see if it will put a unable libreoffice instance in the store...
> 
> Please let us know how it goes.  If it builds and is usable, we should
> merge it.

Well it did build indeed! And now I have a working LibreOffice in the 
store. Tested briefly, works without a hitch so far.

Unrelated, but maybe you could advise me as I'm just starting to study 
Guix deeply:

Have I somehow "poluted" the environment via the pull of the 
wip-libreoffice tar? I'm asking this as I see a different behavior now 
with `guix package -d' and `-i' for other packages now than before, and 
a lot of building from source. Also `# guix gc' will delete as garbage a 
derivation of tar, bzip2, and module-import, and `# guix pull' spends a 
long time building these from source. And thus in a circle.

What can I do about this?
-- 
白い熊＠相撲道

Re: Libreoffice building (sort of)

[白い熊＠相撲道]

On 2015-03-11 10:01, 白い熊＠相撲道 wrote:
> Have I somehow "poluted" the environment via the pull of the
> wip-libreoffice tar? I'm asking this as I see a different behavior now
> with `guix package -d' and `-i' for other packages now than before,
> and a lot of building from source. Also `# guix gc' will delete as
> garbage a derivation of tar, bzip2, and module-import, and `# guix
> pull' spends a long time building these from source. And thus in a
> circle.

Plus, as a regular user `guix pull' will not complete, even though as 
root it does, so the connection is not the issue:

$ guix pull
starting download of `/tmp/guix-file.2KIQSf' from 
`http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...
http://git.savannah.gnu.org/.../guix-master.tar.gz	8700.4 KiB 
transferred
substitute-binary: updating list of substitutes from 
'http://hydra.gnu.org'...
substitute-binary: guix substitute-binary: warning: while fetching 
http://hydra.gnu.org/nix-cache-info: server is somewhat slow
substitute-binary: guix substitute-binary: warning: try 
`--no-substitutes' if the problem persists
The following files will be downloaded:
    /gnu/store/kz230rqp13lbx68wwf997bn7s8jf1nc6-gzip-1.6
    /gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28
    /gnu/store/57ss3s44vwi76rqjg0filinz88fh332w-grep-2.20
fetching path `/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28'...
found valid signature for 
'/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28', from 
'http://hydra.gnu.org/nar/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28'
downloading `/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28' (2.8 
MiB installed)...
guix substitute-binary: warning: while fetching 
http://hydra.gnu.org/nar/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28: 
server is somewhat slow
guix substitute-binary: warning: try `--no-substitutes' if the problem 
persists
guix substitute-binary: error: connect: Connection timed out
fetching path `/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28' 
failed with exit code 1
fetching path `/gnu/store/57ss3s44vwi76rqjg0filinz88fh332w-grep-2.20'...
killing process 9518
guix pull: error: build failed: some substitutes for the outputs of 
derivation `/gnu/store/94ysrjrjhkq7yclllcbkrb443d4z2il4-tar-1.28.drv' 
failed (usually happens due to networking issues); try `--fallback' to 
build derivation from source


What can I do to fix this?

-- 
白い熊＠相撲道

Re: Libreoffice building (sort of)

[Andreas Enge]

On Wed, Mar 11, 2015 at 10:27:15AM +0100, 白い熊＠相撲道 wrote:
> guix substitute-binary: error: connect: Connection timed out
> fetching path `/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28' failed
> with exit code 1

I think this is just a random error, due to hydra being overloaded. Normally
you can try again and there is a good chance it will work.

Andreas

Re: Libreoffice building (sort of)

[白い熊＠相撲道]

On 2015-03-11 13:04, Andreas Enge wrote:
> On Wed, Mar 11, 2015 at 10:27:15AM +0100, 白い熊＠相撲道 wrote:
>> guix substitute-binary: error: connect: Connection timed out
>> fetching path `/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28' 
>> failed
>> with exit code 1
> 
> I think this is just a random error, due to hydra being overloaded. 
> Normally
> you can try again and there is a good chance it will work.
> 
> Andreas

That's what I thought as well, so I tried many times, and it always 
failed thus. Inbetween though I ran it as root and it went through no 
problems, so it doesn't look like hydra was overloaded at the time.

Like I said, some strange behavior in the rebuilding of tar, bzip2, and 
module-import at the time, so thought the pull of the wip branch messed 
the system up slightly.

Currently, what I did to try to fix this - wget downloaded guix-master 
tar and pulled that file. Went through, no more bad connection errors on 
hydra...

Now it's still running, rebuilding gcc from source and from what I 
caught it'll build glibc and linux-libre... Why?

That's why I'm hoping some expert might give me a hint as to what is 
going on...
-- 
白い熊＠相撲道

Re: Libreoffice building (sort of)

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Mar 11, 2015 at 10:27:15AM +0100, 白い熊＠相撲道 wrote:
>> guix substitute-binary: error: connect: Connection timed out
>> fetching path `/gnu/store/8n7d1bgib9f1hml2k5ravgv79jv1whqf-tar-1.28' failed
>> with exit code 1
>
> I think this is just a random error, due to hydra being overloaded. Normally
> you can try again and there is a good chance it will work.

Actually hydra.gnu.org has been offline for about a day:

  https://pumprock.net/fsfstatus

The FSF sysadmins have been working on it, so hopefully it’ll be back
real soon.

Thanks,
Ludo’.

Re: Libreoffice building (sort of)

[Mark H Weaver]

白い熊＠相撲道 <guix-devel_gnu.org@sumou.com> writes:

> On 2015-03-10 13:41, ludo@gnu.org wrote:
>> "白い熊 @相撲道" <guix-devel_gnu.org@sumou.com> skribis:
>>
>>> wget
>>> http://git.savannah.gnu.org/cgit/guix.git/snapshot/wip-libreoffice.tar.gz
>>> guix pull --url=file:///path/to/wip-libreoffice.tar.gz
>>> guix package -i libreoffice
>>>
>>> It's building now, apparently everything from source, so probably a
>>> long way to go...
>>>
>>> Let's see if it will put a unable libreoffice instance in the store...
>>
>> Please let us know how it goes.  If it builds and is usable, we should
>> merge it.
>
> Well it did build indeed! And now I have a working LibreOffice in the
> store. Tested briefly, works without a hitch so far.
>
> Unrelated, but maybe you could advise me as I'm just starting to study
> Guix deeply:
>
> Have I somehow "poluted" the environment via the pull of the
> wip-libreoffice tar?

What you've done is to roll back your Guix to the 4-month-old version of
Guix that the 'wip-libreoffice' branch was based on.

The proper way would be to use 'git' to rebase that branch on our
current master branch, and then use that.  "guix pull" can't do that.

> I'm asking this as I see a different behavior now
> with `guix package -d' and `-i' for other packages now than before,
> and a lot of building from source.

That's probably because Hydra has long ago deleted the binaries from 4
months ago.

     Mark

Re: Libreoffice building (sort of)

[白い熊＠相撲道]

On 2015-03-11 17:34, Mark H Weaver wrote:
> What you've done is to roll back your Guix to the 4-month-old version 
> of
> Guix that the 'wip-libreoffice' branch was based on.
> 
> The proper way would be to use 'git' to rebase that branch on our
> current master branch, and then use that.  "guix pull" can't do that.
> 
>> I'm asking this as I see a different behavior now
>> with `guix package -d' and `-i' for other packages now than before,
>> and a lot of building from source.
> 
> That's probably because Hydra has long ago deleted the binaries from 4
> months ago.

Thanks a lot for this confirmation Mark, I suspected something like this 
must have happened when I saw the sourcebuilding...

How best to proceed from here to:
- get back to current master
- keep the built libreoffice in the store

I had an idea that pulling the current master from the downloaded file 
will bring me forward again, but doesn't seem it happened - still 
building from source.

I don't use Guix from git, this is the GuixSD installed as a clean 
system from USB. Is there no other way now than to clone the git guix, 
build it an rebase? How will it interact with the GuixSD version of the 
tools? Isn't this going to lead to more conflicts? How do I insure the 
git guix will take precedende - just make sure to run local commands 
only from the git build directory?

Or would maybe now a system reconfigure bring me forward? What is the 
cleanest way?
-- 
白い熊＠相撲道

Re: Libreoffice building (sort of)

[Mark H Weaver]

白い熊＠相撲道 <guix-devel_gnu.org@sumou.com> writes:

> On 2015-03-11 17:34, Mark H Weaver wrote:
>> What you've done is to roll back your Guix to the 4-month-old
>> version of
>> Guix that the 'wip-libreoffice' branch was based on.
>>
>> The proper way would be to use 'git' to rebase that branch on our
>> current master branch, and then use that.  "guix pull" can't do that.
>>
>>> I'm asking this as I see a different behavior now
>>> with `guix package -d' and `-i' for other packages now than before,
>>> and a lot of building from source.
>>
>> That's probably because Hydra has long ago deleted the binaries from 4
>> months ago.
>
> Thanks a lot for this confirmation Mark, I suspected something like
> this must have happened when I saw the sourcebuilding...
>
> How best to proceed from here to:
> - get back to current master
> - keep the built libreoffice in the store
>
> I had an idea that pulling the current master from the downloaded file
> will bring me forward again, but doesn't seem it happened - still
> building from source.

A plain "guix pull", should bring you forward again, but now there's a
different problem: hydra.gnu.org is currently down.  Hopefully it'll be
back up soon.

After "guix pull", you'll also need to use "guix package -i" to bring
back the new versions of any packages you had installed while using the
wip-libreoffice branch.

Also, if you had run "guix system reconfigure" while you were on the
wip-libreoffice branch, then you should run that command again to get
back to the latest software.

> I don't use Guix from git, this is the GuixSD installed as a clean
> system from USB. Is there no other way now than to clone the git guix,
> build it an rebase?

If you want to merge two different branches of our git repository, then
'git' is the right tool for that job.

> How will it interact with the GuixSD version of the tools?

'guix pull' populates $HOME/.config/guix/latest (or
$XDG_CONFIG_HOME/guix/latest if XDG_CONFIG_HOME is set).  Other 'guix'
commands look in that directory and use the package descriptions found
there.

So, assumes your environment variables are set sanely, if you ran

  guix pull --url=file:///path/to/wip-libreoffice.tar.gz

as user 'foo', then only 'guix' commands run as user 'foo' will use
packages from the wip-libreoffice branch.  Other users running 'guix'
would not be affected.

> Isn't this going to lead to more conflicts? How do I insure
> the git guix will take precedende - just make sure to run local
> commands only from the git build directory?

When you run "/path/to/git/checkout/pre-inst-env guix ..." then it will
always use the package descriptions from the git checkout.  This is what
I *always* do.  In fact, to make this easier, I put this script in
~/bin/guix:

If you want to merge two different branches of our git repository, then
'git' is the right tool for that job.

> How will it interact with the GuixSD version of the tools?

'guix pull' populates $HOME/.config/guix/latest (or
$XDG_CONFIG_HOME/guix/latest if XDG_CONFIG_HOME is set).  Other 'guix'
commands look in that directory and use the package descriptions found
there.

So, assumes your environment variables are set sanely, if you ran

  guix pull --url=file:///path/to/wip-libreoffice.tar.gz

as user 'foo', then only 'guix' commands run as user 'foo' will use
packages from the wip-libreoffice branch.  Other users running 'guix'
would not be affected.

> Isn't this going to lead to more conflicts? How do I insure
> the git guix will take precedende - just make sure to run local
> commands only from the git build directory?

When you run "/path/to/git/checkout/pre-inst-env guix ..." then it will
always use the package descriptions from the git checkout.  This is what
I *always* do.  In fact, to make this easier, I put this script in
~/bin/guix:

If you want to merge two different branches of our git repository, then
'git' is the right tool for that job.

> How will it interact with the GuixSD version of the tools?

'guix pull' populates $HOME/.config/guix/latest (or
$XDG_CONFIG_HOME/guix/latest if XDG_CONFIG_HOME is set).  Other 'guix'
commands look in that directory and use the package descriptions found
there.

So, assumes your environment variables are set sanely, if you ran

  guix pull --url=file:///path/to/wip-libreoffice.tar.gz

as user 'foo', then only 'guix' commands run as user 'foo' will use
packages from the wip-libreoffice branch.  Other users running 'guix'
would not be affected.

> Isn't this going to lead to more conflicts? How do I insure
> the git guix will take precedende - just make sure to run local
> commands only from the git build directory?

When you run "/path/to/git/checkout/pre-inst-env guix ..." then it will
always use the package descriptions from the git checkout.  This is what
I *always* do.  In fact, to make this easier, I put this script in
~/bin/guix:

--8<---------------cut here---------------start------------->8---
#!/bin/sh

exec /home/mhw/guix/pre-inst-env guix "$@"
--8<---------------cut here---------------end--------------->8---

Also note that when 'pre-inst-env' is used, $HOME/.config/guix/latest is
always ignored, so anything you've done with 'guix pull' is irrelevant.

      Mark

Re: Libreoffice building (sort of)

[白い熊＠相撲道]

On 2015-03-11 20:17, Mark H Weaver wrote:
> When you run "/path/to/git/checkout/pre-inst-env guix ..." then it will
> always use the package descriptions from the git checkout.  This is 
> what
> I *always* do.  In fact, to make this easier, I put this script in
> ~/bin/guix:
> 
> --8<---------------cut here---------------start------------->8---
> #!/bin/sh
> 
> exec /home/mhw/guix/pre-inst-env guix "$@"
> --8<---------------cut here---------------end--------------->8---
> 
> Also note that when 'pre-inst-env' is used, $HOME/.config/guix/latest 
> is
> always ignored, so anything you've done with 'guix pull' is irrelevant.

So, if I understand correctly, I'd make the git version, but not make 
install it. Then running `pre-inst-env guix' this will use definitions 
from the git pull...

What about the store? Should I configure it with --localstatedir set to 
/var when building the git version?
-- 
白い熊＠相撲道

Re: Libreoffice building (sort of)

[Mark H Weaver]

白い熊＠相撲道 <guix-devel_gnu.org@sumou.com> writes:

> On 2015-03-11 20:17, Mark H Weaver wrote:
>> When you run "/path/to/git/checkout/pre-inst-env guix ..." then it will
>> always use the package descriptions from the git checkout.  This is
>> what
>> I *always* do.  In fact, to make this easier, I put this script in
>> ~/bin/guix:
>>
>> --8<---------------cut here---------------start------------->8---
>> #!/bin/sh
>>
>> exec /home/mhw/guix/pre-inst-env guix "$@"
>> --8<---------------cut here---------------end--------------->8---
>>
>> Also note that when 'pre-inst-env' is used,
>> $HOME/.config/guix/latest is
>> always ignored, so anything you've done with 'guix pull' is irrelevant.
>
> So, if I understand correctly, I'd make the git version, but not make
> install it. Then running `pre-inst-env guix' this will use definitions
> from the git pull...

Yes, that's right.

> What about the store? Should I configure it with --localstatedir set
> to /var when building the git version?

Indeed, that is important.  You'll also need to pass
--with-libgcrypt-prefix=$(guix build libgcrypt | head -1)

      Mark