* doc/contributing.texi (The Perfect Setup)
<Viewing Bugs within Emacs>: Make bug-reference-bug-regexp match
more URLs based on issues.guix.gnu.org.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Suggested-by: Simon Tournier <zimon.toutoune@gmail.com>
Start with Guile Studio and Vim/NeoVim.
* doc/contributing.texi (Alternative Setups): Add section explaining
other setups that are similar to the one in The Perfect Setup.
Signed-off-by: Efraim Flashner <efraim@flashner.co.il>
* doc/contributing.texi (The Perfect Setup)
<Viewing Bugs within Emacs>: Properly quote Elisp functions. Add 'require'
directives. Set BUG-REFERENCE-URL-FORMAT so the configuration is
self-contained.
Suggested-by: Mekeor Melire <mekeor@posteo.de>
* doc/contributing.texi (Circular Module Dependencies): New subsection.
Series-version: 2
Series-to: 65860@debbugs.gnu.org
Patch-cc: mhw@netris.org
Cover-letter:
Resolve a circular module dependencies in embedded modules
This series is the culmination of at least a day of effort tracking down the
source of a module dependency cycle (!). The last commit adds some guidelines
in the hope to avoid a repeat (perhaps 'lint' could be taught to
automate these checks).
END
Lack of clarity reported by lrustland on IRC.
* doc/contributing.texi (Running Guix Before It Is Installed): Refer to
the Building from Git section when giving instructions for generating
the pre-inst-env script.
Geiser now has support locating the project root and adding it to the load
path without external help; leverage it.
* .dir-locals.el [nil]: Remove obsolete Geiser configuration. Set the
geiser-repl-per-project-p variable to t.
* doc/contributing.texi (The Perfect Setup): No longer mention explicitly
setting the geiser-guile-load-path; instead mention the effect of the
.dir-locals.el file.
Reported-by: Wolf <wolf@wolfsden.cz>
At this point, there are three equivalent TeX Live sub-systems:
texlive-scheme-basic, texlive-tiny, and (texlive-updmap.cfg). It is confusing
to keep so many around.
* doc/contributing.texi (Submitting Patches): Remove reference to
TEXLIVE-TINY.
* gnu/packages/algebra.scm (pari-gp)[native-inputs]:
(giac)[native-inputs]:
* gnu/packages/chez.scm (chez-sockets)[native-inputs]:
* gnu/packages/engineering.scm (fastcap)[native-inputs]:
* gnu/packages/gettext.scm (po4a)[native-inputs]:
* gnu/packages/maths.scm (cddlib)[native-inputs]:
(gnuplot)[native-inputs]:
(itpp)[native-inputs]:
* gnu/packages/ocaml.scm (unison)[native-inputs]:
* gnu/packages/pdf.scm (extractpdfmark)[native-inputs]:
* gnu/packages/photo.scm (enblend-enfuse): Replace TEXLIVE-TINY with a call to TEXLIVE-UPDMAP.CFG.
* gnu/packages/radio.scm (gnuradio)[native-inputs]: Remove unnecessary
TEXLIVE-TINY.
* gnu/packages/tex.scm (texlive-tiny): Deprecate it in favor of TEXLIVE-SCHEME-BASIC.
(texlive-makecmds)[native-inputs]: Replace TEXLIVE-TINY with a call to TEXLIVE-UPDMAP.CFG.
* guix/lint.scm (check-inputs-should-be-native): Check only for
"texlive-updmap.cfg" input name.
Move away from using staging and core-updates, and make the strategy
independant of branch names.
Keep the 300 dependent threshold for changes to master, as I don't have any
specific reason to change this.
Most importantly, require using guix-patches issues to coordinate merging of
the branches, as I think that'll address the key issues that have shown up
recently where it's been unclear which branch should be merged next.
* doc/contributing.texi (Submitting Patches): Move the branching strategy to a
new Managing Patches and Branches section.
(Managing Patches and Branches): New section.
(Commit Policy): Simplify through referencing the new Managing Patches and
Branches section.
Signed-off-by: Christopher Baines <mail@cbaines.net>
In an effort to homogenize things, commit
3c40dfe285 replaced:
@deffn {Scheme Procedure}
with:
@defun
However, the latter prints "Function" when all existing material about
Scheme uses the term "procedure".
Thus, for consistency, this commit switches to:
@deffn {Procedure}
* doc/guix.texi, doc/contributing.texi: Use "@deffn {Procedure}"
consistently rather than "@defun" or similar.
The documentation for git send-email recommends the use of an equal sign when
specifying a recipient with the --to option. [1] Adjusts the reference manual
accordingly.
[1] https://git-scm.com/docs/git-send-email
* doc (contributing.texi): Specify recipient via equal sign in
'git send-email --to'.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
Automated via 'M-x texinfo-all-menus-update' in Emacs, and dropping
the *Contributing menu removal, which is erroneously removed because defined
in a different Texinfo file.
* doc/guix.texi: Update all menus.
* doc/contributing.texi (Submitting Patches): Likewise.
Fixes <https://issues.guix.gnu.org/58813>. No longer suggests to splice the
output of etc/teams.scm commands into the 'git send-email' command line; this
is now transparently handled by the Git configuration, which is also
automatic.
* doc/contributing.texi (Configuring Git): Streamline section, now automated
via Automake.
(Sending a Patch Series): Do not specify options configured as default by the
above. Prefer long option names, for readability.
(Teams): Rewrite the examples to use --header-cmd.
(Commit Access): Refer to the Configuring Git section instead of detailing
manual steps.
This is to make explicit something which until now had always been implicit.
* doc/contributing.texi (Commit Access): Mention that committers are expected
to employ consensus decision making.
Co-authored-by: Ludovic Courtès <ludo@gnu.org>
* doc/contributing.texi ("Submitting Patches")["Sending a Patch Series"]:
Note that a bug in 'git send-email' means '-v REVISION' (with a
space) will not work.
Signed-off-by: Christopher Baines <mail@cbaines.net>
Add more examples of when it can be appropriate to push changes without
review, as I think this can be appropriate in the case of trivial changes (as
mentioned before), but also non-trivial fixes.
No longer suggest pushing simple new packages or package upgrades (that don't
cause lots of rebuilds) without sending to guix-patches. Now there's some
automation for testing changes sent to guix-patches, sending changes there
before pushing can mean that more rigorous testing takes place and help speed
up substitutes becoming available. This is true, even if no human review takes
place.
Only suggest waiting one week for review for simpler changes, wait two weeks
for more significant changes.
Also, reorder some of the information in this section so it's grouped together
better.
* doc/contributing.texi (Commit Policy): Tweak.
Signed-off-by: Christopher Baines <mail@cbaines.net>
This is an experimental build system based on python-build-system
that implements PEP 517-compliant builds.
* doc/guix.texi (Build Systems): Add pyproject-build-system section.
* doc/contributing.texi (Python Modules): Mention pyproject.toml and the
PYTHON-TOOLCHAIN package, as well as differences to python-build-system.
* guix/build-system/pyproject.scm,
guix/build/pyproject-build-system.scm,
gnu/packages/aux-files/python/sanity-check-next.py,
gnu/packages/python-commencement.scm: New files.
* Makefile.am (MODULES): Register the new build systems.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add python-commencement.scm.
* gnu/packages/python.scm (python-sans-pip, python-sans-pip-wrapper): New
variables.
Co-authored-by: Marius Bakke <marius@gnu.org>
* doc/contributing.texi (Submitting Patches): Add a tip detailing how to
prefix the subject line with the branch name the change should be installed
to.
Add a scope list to each team. This list defines all the files and
directories that are mentored by the team.
Also add a cc-members command that takes two Git revision strings as input,
add returns the members that should be CC'ed given the files impacted between
the two revisions.
* etc/teams.scm.in (<team>)[scope]: New field.
(team, list-teams): Adapt those procedures.
(find-team-by-scope, diff-revisions): New procedures.
(main): Add a "cc-members" command.
* doc/contributing.texi ("Teams"): Document it.
("Sending a Patch Series"): Adapt it.
* etc/snippets/tempel/scheme-mode: New file.
* etc/snippets/tempel/text-mode: New file.
* etc/snippets/scheme-mode: Moved from here...
* etc/snippets/yas/scheme-mode: ... to here.
* etc/snippets/text-mode: Moved from here...
* etc/snippets/yas/text-mode: ... to here.
* doc/contributing.texi ("The Perfect Setup"): Adjust yasnippet setup
accordingly. Add tempel setup.
Signed-off-by: Liliana Marie Prikler <liliana.prikler@gmail.com>
Fixes <https://issues.guix.gnu.org/56114>.
Reported by Maxime Devos <maximedevos@telenet.be>.
* guix/monad-repl.scm (%build-verbosity): New variable.
(evaluate/print-with-store): New procedure.
(run-in-store): Rewrite in terms of 'evaluate/print-with-store'.
(verbosity, lower, build): New meta-commands.
* doc/guix.texi (Using Guix Interactively): New node.
(The Store Monad): Link to it.
(Invoking guix repl): Likewise.
* doc/contributing.texi (Running Guix Before It Is Installed): Refer to
it.
(The Perfect Setup): Suggest 'guix install' rather than 'guix package -i'.
Partially fixes <https://issues.guix.gnu.org/55821>. Partially because our
git package doesn't yet include the documentation. This change will need to
go to core-updates.
* doc/contributing.texi (Submitting Patches): Adjust the node name.
* doc/contributing.texi (Building from Git): Tweak so that all the
commands appear in @example boxes. Show --localstatedir=/var instead of
--localstatedir=@var{directory}.
* doc/contributing.texi (Running Guix Before It Is Installed): Mention
how to remedy "source file ... newer than compiled" error by running
`make -j`.
Co-authored-by: jgart <jgart@dismail.de>
Co-authored-by: Julien Lepiller <julien@lepiller.eu>
Co-authored-by: Ryan Prior <rprior@protonmail.com>
Co-authored-by: Blake Shaw <blake@nonconstructivism.com>
Signed-off-by: Nicolas Goaziou <mail@nicolasgoaziou.fr>
* doc/contributing.texi (Building from Git): Adds section on using
make clean-go.
Co-authored-by: jgart <jgart@dismail.de>
Co-authored-by: Julien Lepiller <julien@lepiller.eu>
Co-authored-by: Ryan Prior <rprior@protonmail.com>
Co-authored-by: Blake Shaw <blake@nonconstructivism.com>
Signed-off-by: Nicolas Goaziou <mail@nicolasgoaziou.fr>
