What should go in our NEWS file?
Hi Guix! The Guix source tree contains a NEWS file in its root directory. What is supposed to go into this NEWS file? When should we update it? The GNU Standards just says that it should contain "a list of user-visible changes worth mentioning" ((standards) NEWS File): 6.7 The NEWS File = In addition to its manual, the package should have a file named `NEWS' which contains a list of user-visible changes worth mentioning. In each new release, add items to the front of the file and identify the version they pertain to. Don't discard old items; leave them in the file after the newer items. This way, a user upgrading from any previous version can see what is new. If the `NEWS' file gets very long, move some of the older items into a file named `ONEWS' and put a note at the end referring the user to that file. I'm curious to know what sort of changes should be included in our NEWS file, and what sort of changes should not. I'd like to know so that I will know when I need to update the file. For example, here are some common changes that we make in Guix: * Add a new package. * Change a package. * Add a new service type. * Change a service type. * Add a new Guix API or data type. * Change a Guix API or data type. And here are some things we do perhaps less frequently: * Remove a package, service type, Guix API, or data type. * Change something for security reasons. * Change something in backwards incompatible ways. I think it would be useful to put some guidelines for when to update the NEWS file into the Contributing section of our manual. However, I'm not familiar with what we should put into the NEWS file, so I'm hoping that others who have contributed more can offer insight on what to write. -- Chris signature.asc Description: PGP signature
Preferred blog format - Markdown or SXML?
Hi, I'd like to write a couple blog posts for the Guix blog [1]. The guix-artwork Git repository [2] appears to contain the existing posts. Most are written using SXML [3], but some are written using Markdown [4]. Is there a preferred format? Is there any reason why one might be better than the other for certain situations? Markdown looks easier to write, especially since I will probably want to embed pre-formatted text to show example code. Footnotes: [1] https://www.gnu.org/software/guix/blog/ [2] https://savannah.gnu.org/git/?group=guix [3] Example: https://www.gnu.org/software/guix/blog/2016/guixsd-system-tests/ [4] https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/ -- Chris signature.asc Description: PGP signature
New Brazilian Portuguese PO file for 'shepherd' (version 0.3.3-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Brazilian Portuguese team of translators. The file is available at: http://translationproject.org/latest/shepherd/pt_BR.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Preferred blog format - Markdown or SXML?
What about Org-mode? Rationale: http://karl-voit.at/2017/09/23/orgmode-as-markup-only -- Pierre Neidhardt Everything ends badly. Otherwise it wouldn't end. signature.asc Description: PGP signature
Re: Preferred blog format - Markdown or SXML?
Hi Chris, > I'd like to write a couple blog posts for the Guix blog [1]. The > guix-artwork Git repository [2] appears to contain the existing posts. > Most are written using SXML [3], but some are written using Markdown[…] Generally, the older ones are written in SXML because earlier Haunt did not have a Markdown reader. Unless you need special HTML constructs or classes I suggest using Markdown for the Guix blog. -- Ricardo
Re: What should go in our NEWS file?
Hi Chris, > The Guix source tree contains a NEWS file in its root directory. What > is supposed to go into this NEWS file? When should we update it? It’s updated prior to making a release. > I'm curious to know what sort of changes should be included in our NEWS > file, and what sort of changes should not. I'd like to know so that I > will know when I need to update the file. As you can see we use the same sections for every new release: package management distribution (also includes list of package additions and updates) programming interfaces noteworthy bug fixes native language support Some of these sections could be added to when a new notable feature has been added (e.g. a new export format for “guix pack” or a new build system). In the past we have been doing this when preparing for the new release, but it may make things easier on whoever cuts the new release if we edited the file as needed when notable features are merged. -- Ricardo
Re: Preferred blog format - Markdown or SXML?
Hi, Pierre Neidhardt writes: > What about Org-mode? > Rationale: > > http://karl-voit.at/2017/09/23/orgmode-as-markup-only The website uses the haunt [1] static site generator which does not currently support direct reading of org files. However, you could easily export an org file to one of the supported formats (like html). To my knowledge, the supported reader formats are: html, sxml, texinfo, skribe and commonmark (See "Programming Interface/Readers" in Haunt's documentation). The readers are defined in the site's haunt.scm file (in this case guix-artwork/website/haunt.scm). Currently sxml, html, and commonmark are defined in that file, so you could write a blog post in any of those formats (e.g. use whatever you prefer) and it will just work with the site generator. If you want to use texinfo or skribe you would just need to alter haunt.scm accordingly. However, even though Haunt handles multiple post formats, it's possible that the Guix project has a preferred format, so please let me know if that is the case. Best, Adam Footnotes: [1] https://dthompson.us/projects/haunt.html signature.asc Description: PGP signature
Proposed environment variable to skip running tests
Hello!
I would like to propose an environment variable that can be used to skip
tests, e.g. export GUIX_SKIP_TESTS=1
This could be implemented by changing line 297 of
guix/guix/build/gnu-build-system.scm:
(define* (check #:key target (make-flags '()) (tests? (not target))
(test-target "check") (parallel-tests? #t)
#:allow-other-keys)
(if (and tests? (not (getenv "GUIX_SKIP_TESTS"))) ;; HERE
(zero? (apply system* "make" test-target
`(,@(if parallel-tests?
`("-j" ,(number->string
(parallel-job-count)))
'())
,@make-flags)))
(begin
(format #t "test suite not run~%")
#t)))
The reason I suggest this is because installing GuixSD with --fallback
is sometimes necessary (I was getting a lot of 504's errors, so had to
use fallback) but in that case the subversion and git test suites take
many hours and perform excessive grinding on hard disk. Allowing users
the choice to skip tests in a situation like this means we can get
guixsd installed quickly.
Re: Successfully running GNOME on core-updates + staging
Hi Mark, Mark H Weaver skribis: > I've successfully updated my x86_64 GuixSD system to my private branch > based on 'core-updates' with recent 'master' and 'staging' merged into > it. This system includes a full GNOME desktop environment plus a few > programs based on Qt. It all works quite well. > > My branch includes a few draft fixes and workarounds that I haven't yet > pushed, but nothing that would require many rebuilds to update later. > > So, I think it might be time to ask Hydra to build all of core-updates, > after staging is merged into it. I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’ that Marius reported a few days ago, which I’m looking into right now. I don’t expect the fix(es) to trigger a full rebuild. If Marius and others don’t object, I’d say go for it! Thanks, Ludo’.
Re: Detecting duplicate field initializers in guix record constructors
Hello!
Mark H Weaver skribis:
> Recently, when doing a merge of 'master' into 'core-updates', I noticed
> that git's automatic merging sometimes results in duplicate field
> initializers being introduced, without any merge conflict being
> reported. This happens when a field is introduced independently in both
> 'core-updates' and 'master', but in different places within the
> constructor.
>
> So, I implemented duplicate field detection in (guix records).
> See below for my draft patches.
Excellent, I’ve been missing this for too long. :-)
> This revealed 9 occurrences of this error in my private branch, which is
> based on 'core-updates' with recent 'staging' and 'master' merged in.
Woow.
> I ran into another problem along the way. I found that after adding the
> duplicate field detection to (guix records), building Guix from a clean
> tree started failing with an apparently unrelated error. When the code
> in build-aux/compile-all.scm attempted to _load_ (guix scripts pack), it
> hit a fatal error, namely that 'gzip' was undefined, although it's
> clearly importing the right module. I guess this is somehow related to
> the cycles in our module dependency graph. I found that this problem
> could be prevented by moving $(GNU_SYSTEM_MODULES) above the modules in
> guix/{import,scripts} in MODULES in Makefile.am. The idea is that
> modules in guix/{import,scripts} sometimes import package modules, but
> never the other way around.
(Note: this was reported at .)
I still don’t quite get it. The #:use-module (gnu packages compression)
in (guix scripts pack) should lead to loading things in the right order,
no? Do you have a way to reproduce it?
> From 5e4422d81d4fd5581bce8f8b29f4c75864e37bd0 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Thu, 19 Apr 2018 16:18:26 -0400
> Subject: [PATCH 1/3] DRAFT: build: Load $(GNU_SYSTEM_MODULES) before
> guix/{import,scripts}.
>
> This works around an issue where modules in guix/import and guix/scripts
> sometimes depend on package definitions at module load time.
>
> * Makefile.am (MODULES): Move $(GNU_SYSTEM_MODULES) above guix/import/* and
> guix/scripts/*.
Let’s discuss this separately for 29774.
> From 907cd4b4a485fbce7662c3149d8d4eeb0b4e7d0d Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Thu, 19 Apr 2018 16:41:45 -0400
> Subject: [PATCH 2/3] DRAFT: Fix duplicate field initializers in guix record
> constructors.
LGTM!
> From 45e26da1e4c8559b843034de3fd2edef89f5349c Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Thu, 19 Apr 2018 12:33:25 -0400
> Subject: [PATCH 3/3] DRAFT: records: Detect duplicate field initializers.
LGTM too. Could you add a test in tests/records.scm? There’s already a
couple of ‘syntax-error’ tests there.
Thank you!
Ludo’.
Re: What should go in our NEWS file?
Hello, Ricardo Wurmus skribis: >> The Guix source tree contains a NEWS file in its root directory. What >> is supposed to go into this NEWS file? When should we update it? > > It’s updated prior to making a release. Committers following along should feel empowered to add noteworthy items there, and not just right before the release. This has to be rather concise because there are so many things going on, and rather about “important” changes, in the categories that Ricardo mentions. I’m saying this because updating NEWS right before the release can be quite cumbersome, and it’s also easy to overlook important things, so any contribution in that regard can be very helpful! Ludo’.
Re: Proposed environment variable to skip running tests
Hello, ra...@airmail.cc skribis: > I would like to propose an environment variable that can be used to > skip tests, e.g. export GUIX_SKIP_TESTS=1 > > This could be implemented by changing line 297 of > guix/guix/build/gnu-build-system.scm: > > (define* (check #:key target (make-flags '()) (tests? (not target)) > (test-target "check") (parallel-tests? #t) > #:allow-other-keys) > (if (and tests? (not (getenv "GUIX_SKIP_TESTS"))) ;; HERE Since builds are performed in an isolated environments with a clearly defined set of environment variables. Thus what you define would not work as-is. To achieve it, we’d have to, for instance, instruct guix-daemon to special-case ‘GUIX_SKIP_TESTS’ and let it through in the build environment. Even though I can imagine the pain you feel while rebuilding everything on GNU/Hurd, I’m reluctant to such changes. I would suggest using tricks to avoid full rebuilds in your case as much as possible. (If you provide concrete examples of rebuilds you’d like to avoid, I can perhaps illustrate what “tricks” you could use. :-)) Thanks, Ludo’.
Re: Cross-compiling bootstrap tarballs fails on core-updates
Hello Marius, Marius Bakke skribis: > There seems to be a couple of different problems here. > > 'patch' fails to build due to a conflicting declaration of > '__mktime_internal': > > CCLD patch > /gnu/store/9v09kidvqykyk2kh26q297di3lkjc8vy-glibc-cross-arm-linux-gnueabihf-2.27-static/lib/libc.a(mktime.o): > In function `__mktime_internal': > /tmp/guix-build-glibc-cross-arm-linux-gnueabihf-2.27.drv-0/glibc-2.27/time/mktime.c:353: > multiple definition of `__mktime_internal' > ../lib/libpatch.a(mktime.o):/tmp/guix-build-patch-2.7.6.drv-0/patch-2.7.6/lib/mktime.c:317: > first defined here > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:1230: patch] Error 1 > > > Note that there is a warning about __mktime_internal earlier: > > In file included from timegm.c:20:0: > > timegm.c: In function 'rpl_timegm': > > ../config.h:1974:25: warning: implicit declaration of function > '__mktime_internal' [-Wimplicit-function-declaration] > #define mktime_internal __mktime_internal > > timegm.c:30:28: note: in expansion of macro 'mktime_internal' > # define __mktime_internal mktime_internal > > timegm.c:39:10: note: in expansion of macro '__mktime_internal' >return __mktime_internal (tmp, __gmtime_r, &gmtime_offset); > > > Then we have 'ncurses' failing in the install phase with: > > make[1]: Entering directory > '/tmp/guix-build-ncurses-6.1.drv-0/ncurses-6.1/progs' > mkdir -p /gnu/store/553j76738bh6bcr31vsyri0wpxir2wkw-ncurses-6.1/bin > /gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/bin/install -c -s > tic /gnu/store/553j76738bh6bcr31vsyri0wpxir2wkw-ncurses-6.1/bin/`echo > tic| sed 's/$//'|sed 's,x,x,'|sed 's/$//'` > strip: Unable to recognise the format of the input file > `/gnu/store/553j76738bh6bcr31vsyri0wpxir2wkw-ncurses-6.1/bin/tic' > /gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/bin/install: strip > process terminated abnormally > make[1]: *** [Makefile:201: install.progs] Error 1 This is fixed by these commits: c77835db0 * gnu: tar: Work around a cross-compilation issue. b0ff3606b * gnu: ncurses: Do not use "install -s" when cross-compiling. d3878d3d5 * gnu: patch: Work around a cross-compilation issue. Thanks for the heads-up! Ludo’.
Re: What should go in our NEWS file?
Ludovic Courtès writes: > Ricardo Wurmus skribis: > >>> The Guix source tree contains a NEWS file in its root directory. What >>> is supposed to go into this NEWS file? When should we update it? >> >> It’s updated prior to making a release. > > Committers following along should feel empowered to add noteworthy items > there, and not just right before the release. Yes, absolutely! It’s a hassle to go through all commits since the last release and we have occasionally missed noteworthy changes. We welcome contributions to the NEWS file as noteworthy changes are made. -- Ricardo
