Re: Add a way to disable serialization support to (guix services configuration)
Hi, Xinglu Chen writes: [...] > From 90d63a46a29a8080b7f95eabcec115c5c2c6481e Mon Sep 17 00:00:00 2001 > Message-Id: > <90d63a46a29a8080b7f95eabcec115c5c2c6481e.1619869705.git.pub...@yoctocell.xyz> > In-Reply-To: > References: > From: Xinglu Chen > Date: Sat, 1 May 2021 13:31:27 +0200 > Subject: [PATCH 2/2] services: configuration: Add ability to use custom > serializer. > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Some configuration values should not be serialized to a configuration file, > e.g. command line options for a daemon. > > * gnu/services/configuration.scm (define-configuration): Add option to use a > custom serializer. > (empty-serializer): New procedure. > (serialize-package): Alias to ‘empty-serializer’. > --- > gnu/services/configuration.scm | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm > index 85e1ac78cb..7024b13136 100644 > --- a/gnu/services/configuration.scm > +++ b/gnu/services/configuration.scm > @@ -44,6 +44,7 @@ > define-configuration > validate-configuration > generate-documentation > +empty-serializer > serialize-package)) > > ;;; Commentary: > @@ -116,7 +117,7 @@ > (define-syntax define-configuration >(lambda (stx) > (syntax-case stx () > - ((_ stem (field (field-type properties ...) doc) ...) > + ((_ stem (field (field-type properties ...) doc custom-serializer ...) > ...) > (with-syntax (((field-getter ...) >(map (lambda (field) > (id #'stem #'stem #'- field)) > @@ -133,9 +134,12 @@ > (_ (syntax 'disabled))) > #'((field-type properties ...) ...))) > ((field-serializer ...) > - (map (lambda (type) > - (id #'stem #'serialize- type)) > - #'(field-type ... > + (map (lambda (type serializer) > + (match serializer > + (((serializer)) serializer) > + (_ (id #'stem #'serialize- type > + #'(field-type ...) > + #'((custom-serializer ...) ... > #`(begin > (define-record-type* #,(id #'stem #'< #'stem #'>) > #,(id #'stem #'% #'stem) > @@ -176,8 +180,8 @@ > #,(id #'stem #'stem #'-fields)) > conf > > -(define (serialize-package field-name val) > - "") > +(define (empty-serializer field-name val) "") > +(define serialize-package empty-serializer) > > ;; A little helper to make it easier to document all those fields. > (define (generate-documentation documentation documentation-name) Rebased on a change that allows to globally (at the configuration level) disable serialization and pushed as b3e99d3399. Thank you! :-) Maxim
Re: The purpose of the "license" list of a Guix package
Chris Marusich writes: > In the end, I think a packager is expected to be operating in good > faith, in accordance with the FSDG. This means that packagers look for > freedom issues and address them when found. It does not mean that > packagers are expected to provide a detailed "bill of materials" for > every single package, although that is certainly something that some > people think is important (and some people don't). Another way of saying this is that, in my understanding, the license field is "just a hint". It should be a useful hint, of course, but it is still just a hint, rather than an exhaustive or authoritative description of all licensing implications for all use cases. -- Chris signature.asc Description: PGP signature
The purpose of the "license" list of a Guix package (Was: Re: Jam: which licence is this?)
Hi, Leo Famulari writes: > On Sun, May 02, 2021 at 12:53:07AM -0400, Mark H Weaver wrote: >> My understanding is that the 'license' field of a package in Guix has >> _always_ been meant to summarize the license restrictions associated >> with the package source (the output of "guix build --source"), and >> *not* merely the package outputs. > > My understanding is that the license field describes the license that > the package is redistributed under, which is typically a single license, > but could be a dual (or multiple) license if that is the case. > > The manual section "package Reference" says: > > The license of the package; a value from (guix licenses), or a list of > such values. > > It's the license of the package, overall. Not of every single file in > the source code. > >> Really? Can you give some examples of this from our core packages? > > The 'hello' package is not core, but it is a typical Autotools-based > package, and the core packages will be similar. > > It is, overall, GPL3 or later. However, the component source files bear > these other licenses too: > > aclocal.m4: An unnamed permissive license > AUTHORS: An unnamed permissive license > configure: An unnamed permissive license > configure.ac: An unnamed permissive license > INSTALL: An unnamed permissive license > maint.mk: An unnamed permissive license > Makefile.am, Makefile.in: An unnamed permissive license > README, README-dev: An unnamed permissive license > THANKS: An unnamed permissive license > > build-aux/compile: GPL2+ > build-aux/config.rpath: An unnamed permissive license > build-aux/depcomp: GPL2+ > build-aux/install-sh: Expat license > build-aux/mdate-sh: GPL2+ > build-aux/missing: GPL2+ > build-aux/test-driver: GPL2+ > > doc: Some files bear the GFDL > > m4: Maybe unnamed permissive licenses (I'm getting tired) > > po/Makefile.in.in: The "GPL" with no version mentioned. I assume GPL1. > po/POTFILES.in: An unnamed permissive license > > tests/*: An unnamed permissive license > > Some of those unnamed permissive licenses are the same as each other, > some are different. > > It would be unhelpful if the package definition's license field said > "gpl3+ gpl2+ gpl1 non-copyleft expat gfdl". Nobody would be able to > answer the question "What is the license of the 'hello' package?" > >> The 'license' field can only mean one of these two things, and I think >> it's fairly clear which one it should be. Moreover, I think that this >> is what it has always meant in Guix. If not, that's a problem. > > My survey of the "hello" package shows that the license field in Guix is > about the overall license of the program, not an exhaustive list of the > many licenses used for various components of the source code. > > I don't think it's a problem to not mention those licenses in the > package definition. When the user acquires the source code, they still > get the benefits of the freely licensed components. Nothing is being > hidden. > > The suggestion that our package definitions' license field should > mention every license contain in the source code has no precedent in > Guix, at least since I joined. I don't there is a demonstrated benefit > to making that change. I agree with Leo. My understanding is that the intent of the "license" field (which can be a list) in a Guix package is to call out the "main" (deliberately vague here) licenses related to the code, not to provide an exhaustive or authoritative description of all the licenses affecting every file in every possible situation. As Leo has demonstrated, a package's license field (like probably most summaries of license information) is surely not exhaustive or authoritative; the licenses in the source code files themselves are authoritative. My understanding is that a packager is expected to audit the licenses in the files when adding the package. If an exhaustive audit is not feasible (which is often the case), they should perform a reasonable spot check and then list the "main" licenses in play in the licenses file. As in the GNU Hello case, there is clearly a judgment call regarding what goes into the Guix package's licenses list, since a simple list cannot describe everything. In general, even if hypothetically you did do an exhaustive audit of all files, it is not practical to try to describe all the licensing implications in the Guix package definition. I don't think that's the purpose of the license field. One more thing. I have always felt that the license field of a Guix package is intended to call out the licenses that apply to the built output of the package in particular. In other words, I think the license field is intended to call out the licenses that are most likely to apply in the situation where you "link" with the built output of the package. That is the purpose of many packages: to be "linked" from other source code. Since it is often the case that software you write will not be "linking" with the package's build scripts, but rather with
Re: Add a way to disable serialization support to (guix services configuration)
Hi Maxim, On Fri, May 07 2021, Maxim Cournoyer wrote: > Hello Xinglu! > > Thank you for working on it! You are very welcome! These are things that have annoyed me enough so I decided (try) to fix it myself :) >> +(define (configuration-no-default-value kind field) >> + (configuration-error >> + (format #f "`~a' in `~a' does not have a default value" kind field))) > > The kind and field should be inverted. Good catch >>configuration-field make-configuration-field configuration-field? >> @@ -112,7 +116,7 @@ >> (define-syntax define-configuration >>(lambda (stx) >> (syntax-case stx () >> - ((_ stem (field (field-type def) doc) ...) >> + ((_ stem (field (field-type properties ...) doc) ...) > > I'd rather keep the 'def' binding for the default value; properties is > too vague and implies many of them, which is not a supported syntax. Yeah, not exactly sure why I changed it to ‘properties’, anyway... >> (with-syntax (((field-getter ...) >>(map (lambda (field) >> (id #'stem #'stem #'- field)) >> @@ -121,36 +125,56 @@ >>(map (lambda (type) >> (id #'stem type #'?)) >> #'(field-type ...))) >> + ((field-default ...) >> + (map (match-lambda >> + ((field-type default _ ...) default) >> + ;; We get warnings about `disabled' being an >> + ;; unbound variable unless we quote it. >> + (_ (syntax 'disabled))) > > Here I think it'd be better to have the pattern more strict (e.g, > (field-type default-value) or (field-type); so as to not accept invalid > syntax. Good point! > I also think it'd be clearer to use another symbol than 'disabled, as > this already has a meaning for the validator and could confuse readers. Yeah, it’s not very descriptive. >> + #'((field-type properties ...) ...))) >> ((field-serializer ...) >>(map (lambda (type) >> (id #'stem #'serialize- type)) >> #'(field-type ... >> - #`(begin >> - (define-record-type* #,(id #'stem #'< #'stem #'>) >> - #,(id #'stem #'% #'stem) >> - #,(id #'stem #'make- #'stem) >> - #,(id #'stem #'stem #'?) >> - (%location #,(id #'stem #'-location) >> -(default (and=> (current-source-location) >> -source-properties->location)) >> -(innate)) >> - (field field-getter (default def)) >> - ...) >> - (define #,(id #'stem #'stem #'-fields) >> - (list (configuration-field >> -(name 'field) >> -(type 'field-type) >> -(getter field-getter) >> -(predicate field-predicate) >> -(serializer field-serializer) >> -(default-value-thunk (lambda () def)) >> -(documentation doc)) >> - ...)) >> - (define-syntax-rule (stem arg (... ...)) >> - (let ((conf (#,(id #'stem #'% #'stem) arg (... ... >> - (validate-configuration conf >> - #,(id #'stem #'stem #'-fields)) >> - conf >> + #`(begin >> + (define-record-type* #,(id #'stem #'< #'stem #'>) >> + #,(id #'stem #'% #'stem) >> + #,(id #'stem #'make- #'stem) >> + #,(id #'stem #'stem #'?) >> + (%location #,(id #'stem #'-location) >> + (default (and=> (current-source-location) >> + source-properties->location)) >> + (innate)) >> + #,@(map (lambda (name getter def) >> + (if (equal? (syntax->datum def) (quote 'disabled)) > > nitpick: eq? suffices to check for symbols. > >> + #`(#,name #,getter) >> + #`(#,name #,getter (default #,def >> + #'(field ...) >> + #'(field-getter ...) >> + #'(field-default ...))) >> + (define #,(id #'stem #'stem #'-fields) >> + (list (configuration-field >> + (name 'field) >> + (type 'field-type) >> + (getter field-getter) >> + (predicate field-predicate) >> + (serializer field-serializer) >> + ;; TODO: What if there is no default value? > > Seems
Re: Duplicate package in lisp-xyz
Duh! I'm so sorry about this. I had check some days (weeks?) ago, saw it wasn't there, prepared the package then rebased. In the meantime Sharlatan had committed it too! Maybe we could have a `make` or `guix lint` warning for this kind of things, I suppose they are bound to happen in the *-xyz files. I'll revert my commit. I'll be more careful about this pitfall next time, and thanks for catching this! signature.asc Description: PGP signature
Re: Emacs and URLs in Git commit messages
Hi, I gave hyperbole [1] a try, and now if I move the point to that bug string [bug#48262] or bug#48262 and press action key (M-RET) it magically brings me to the debbugs with that bug. Footnotes: [1] https://www.gnu.org/software/hyperbole/ -- Alexey
Duplicate package in lisp-xyz
Hi Pierre, One of your recent commits (22796f1ad16abb7b1519d11332175d147ae10b82) adds pathname-utils to "lisp-xyz.scm", however there was already a definition for this package (starting at line 16030). As far as I can see it doesn't break anything because the previous definition is just shadowed by the new one. signature.asc Description: PGP signature
