[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:Re: A simple workflow for adding apps guix

From: tumashu
Subject: Re:Re: A simple workflow for adding apps guix
Date: Mon, 17 Apr 2017 10:21:48 +0800 (CST)

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" <address@hidden> wrote: >Feng Shu <address@hidden> 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: > > > >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 address@hidden 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 address@hidden 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 :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]