Document shows that the following code is needed:
sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
it seem that normal "guix build" will broken when I run the above code and
close it.
At 2017-04-17 02:21:33, "Marius Bakke" <mba...@fastmail.com> wrote:
>Feng Shu <tuma...@163.com> writes:
>
>> The below is the workflow I used current, any other
>> simpler workflow exists? comments are welcome!
>
>Hello! If you intend to submit these packages, I would recommend working
>directly from the main git repository rather than messing with
>GUIX_PACKAGE_PATH. Have a look at the "Running Guix before it is
>installed" section in the manual:
>
>https://www.gnu.org/software/guix/manual/guix.html#Running-Guix-Before-It-Is-Installed
>
>There is a 'pre-inst-env' script that makes testing local changes easy.
>Here is my typical workflow (motley gear optional):
>
># Start with a clean master branch.
>$ git checkout master
>$ git pull # sometimes "--rebase" or simply `git reset --hard`..
># Create environment with all Guix dependencies.
>$ ge guix # "ge" is an alias for `guix environment`...
># If this is a new machine, prepare the sources for this environment.
>$ ./bootstrap
>$ ./configure --localstatedir=/var
># Now compile everything. This is typically done after each `pull`.
>$ make -j10
># Phew! Now let's start working on our package.
>$ git checkout -b package-foo
><insert matrix gif>
>$ ./pre-inst-env guix build foo # installing works too
># It builds! Let's commit it.
>$ git add -p
>$ git commit
># D'oh! Something was not right.
>$ ./pre-inst-env guix edit foo # I don't actually use this, but..
>$ ./pre-inst-env guix build foo
># Great, this looks better.
>$ git add -p
>$ git commit --amend # or --fixup=<commit> for later rebasing..
><repeat last steps 0-20 times for each patch>
># Allright, now we can submit it!
>$ mkdir outgoing # Not really necessary, but easier to "clean".
>$ git format-patch --cover-letter -n origin/master -o outgoing/
>$ edit outgoing/0000-cover-letter.patch
># Cover letter can be omitted, but is a good way to give some background
># info, raise questions, etc. Now, let's send it to open a bug report.
>$ git send-email --to guix-patc...@gnu.org outgoing/0000-cover-letter.patch
># Now we have a bug URL! Let's send the remainder there.
>$ rm outgoing/0000-cover-letter.patch
>$ git send-email --to nn...@debbugs.gnu.org outgoing/*.patch
>
>You can also make ~/.config/guix/latest a soft link to your git checkout
>and largely avoid the need for `./pre-inst-env`. I don't actually do
>that on my main development machine, since I need the `guix` command to
>always work, and my work tree is rarely "sane" :P instead, I manage my
>entire profile through `./pre-inst-env` and run `guix pull` once per
>week or so. I've been meaning to try git-worktree(1) instead.
>
>Hope it helps! Always interesting to see other workflows :)
