Re: Libreoffice building (sort of)
白い熊＠相撲道 guix-devel_gnu@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---
Re: Libreoffice building (sort of)
Andreas Enge andr...@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)
白い熊＠相撲道 guix-devel_gnu@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
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)
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)
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)
On 2015年3月10日 9:54:43 CET, 白い熊 @相撲道 guix-devel_gnu@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)
白い熊 @相撲道 guix-devel_gnu@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 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? -- 白い熊 @相撲道
Libreoffice building (sort of)
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. signature.asc Description: Digital signature
Re: Libreoffice building (sort of)
John Darrington j...@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)
On Mon, Nov 24, 2014 at 07:03:58PM +0100, Ludovic Court??s wrote: John Darrington j...@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. signature.asc Description: Digital signature
