| Message ID | 20191202091550.15132-1-mail@ambrevar.xyz |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#38455] doc: Mention how to test against make / guix pull breakage. | expand |
Hi Pierre, good idea, but I use $ guix environment --pure guix --ad-hoc git guile-readline guile-json (Not using "--pure" is asking for trouble in my opinion)
Indeed. Why would you need the ad-hoc part though?
On Mon, 02 Dec 2019 21:14:34 +0100
Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> Why would you need the ad-hoc part though?
I've added it because it didn't work without.
I *think* is was because there was a time where guile-json
was not a dependency of guix-the-package but it became
one of the guix git checkout, making the build of the guix
git checkout in a guix environment fail.
I really can't remember, though.
Some parts of the Guix build use git--can't remember which.
Hi Danny, On Mon, 2 Dec 2019 at 20:33, Danny Milosavljevic <dannym@scratchpost.org> wrote: > good idea, but I use > > $ guix environment --pure guix --ad-hoc git guile-readline guile-json I think that it is described here [1] [1] https://guix.gnu.org/manual/en/guix.html#Building-from-Git From my point of view, the change should only concern how to test "guix pull" by adding a bullet -- with a link to Building from Git and Running Test Suite. > (Not using "--pure" is asking for trouble in my opinion) I agree that --pure should be always added to avoid troubles. Maybe it should be the default of "guix environment"? Cheers, simon
Hi Danny, On Mon, 2 Dec 2019 at 22:59, Danny Milosavljevic <dannym@scratchpost.org> wrote: > On Mon, 02 Dec 2019 21:14:34 +0100 > Pierre Neidhardt <mail@ambrevar.xyz> wrote: > > > Why would you need the ad-hoc part though? > > I've added it because it didn't work without. Recently? > I *think* is was because there was a time where guile-json > was not a dependency of guix-the-package but it became > one of the guix git checkout, making the build of the guix > git checkout in a guix environment fail. > I really can't remember, though. I remember as well something like that. But now, it is fixed: "guix environment guix --pure" does the correct job, I guess. > Some parts of the Guix build use git--can't remember which. I do not think so. But having Git in the environment is really helpful (switch branch, revert, log, etc.) Cheers, simon
I've added two points as discussed here: `make` and `guix pull`. Commits bf99d7e0e2e79935b6748afa059e7392d8e110c8 and 9fcf28205826564a05cfccba301ac3b09d17e86d. I agree with Simon that a "guix pull" test would be nice. I've opened another issue for it. See "Add test for `guix pull'". Same with --pure being the default. Opening another issue "Make --pure the default for `guix environment'?". Closing.
Hi Pierre,
On Sun, 8 Dec 2019 at 16:42, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> Commits bf99d7e0e2e79935b6748afa059e7392d8e110c8 and
This commit is incorrect. Because it implies that ./configure has been
run before.
The correct advice -- which is obvious to me -- is: please check if
Guix builds and address the warnings.
All the best,
simon
Acknowledged. Fixed in da31e7d9ec11081807c6710f0f86def2372a7aff.
And thanks for the catch!
diff --git a/doc/contributing.texi b/doc/contributing.texi index ee72b2f94d..04a4ba3e1a 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -961,6 +961,16 @@ often better to clone the repository. Don't use the @command{name} field in the URL: it is not very useful and if the name changes, the URL will probably be wrong. +@item +Make sure your changes do not break Guix: rebuild it with +@example +guix environment guix -- make +@end example +and simulate a @code{guix pull} with +@example +guix pull --url=/path/to/your/checkout --dry-run +@end example + @end enumerate When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as