GNU bug report logs - #26302
[website] translations

Previous Next

Full log

View this message in rfc822 format

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: sirgazil <sirgazil <at> zoho.com>, 26302 <26302 <at> debbugs.gnu.org>
Subject: bug#26302: [website] translations
Date: Tue, 5 Nov 2019 08:31:30 +0100

[Message part 1 (text/plain, inline)]

On Mon, Nov 04, 2019 at 06:19:32PM +0100, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > On Fri, Nov 01, 2019 at 03:54:42PM +0100, Ludovic Courtès wrote:
> >> […]
> >> Perhaps “nginx-accept-language-module”, to match the name of the
> >> upstream repo?
> >> 
> >
> > I agree.  Arch (who have no package for nginx-accept-language-module)
> > change their various nginx module package names to be more consistent,
> > I think, but this is not necessary in Guix, I think.
> 
> For Guix the general rule is to follow upstream (info "(guix) Package
> Naming").
> 

Makes sense.  I agree the general rule is appropriate here.



> > From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> > Date: Sat, 2 Nov 2019 13:13:01 +0100
> > Subject: [PATCH 1/3] doc: Add warning on the '--source' build option when
> >  linking statically.
> >
> > * doc/guix.texi (Additional Build Options): Add warning.
> > […]
> > +Note that for statically linked packages, @command{guix build -S} will
> > +@emph{not} return the complete and corresponding sources since these
> > +would include the sources of statically linked dependencies.  In this
> > +case, when distributing sources for license compliance, you may want to
> > +play it safe and use the following @code{--sources} option instead.
> 
> I don’t think this bit is necessary: ‘-S’ is documented to return “the
> source of the package” and that’s exactly what it does; static
> vs. dynamic linking is not a concern at this level, as I see it.
> 
> WDYT?
> 

I guess the meaning of `guix build -S` is not clear enough.  Let me
make an alternative proposal (attached).



> > From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> > Date: Sat, 2 Nov 2019 14:05:30 +0100
> > Subject: [PATCH 3/3] services: Make it possible to include dynamic modules in
> >  nginx.
> >
> > * gnu/services/web.scm (<nginx-configuration>): Add modules field.
> > (nginx-configuration-modules): New field accessor.
> > (emit-load-module): New procedure.
> > (default-nginx-config): Add support for the modules field.
> > * doc/guix.texi (NGINX): Document it.
> > […]
> > +@item @code{modules} (default: @code{'()})
> > +List of nginx dynamic modules to load.  Should be a list of strings or
> > +string valued G-expressions.
> 
> Then… how does nginx find the module in question, specifically the
> ‘nginx-accept-language-module’ package?  One has to specify
> ‘nginx-accept-language-module’ as the nginx package to use, is that
> right?  (I had overlooked that before.)
> 
> What about adding an example with the ‘accept-language’ module?
> 

Of course you are right.  I attach a patch with only a changed
doc/guix.texi.  I do not attach again the
nginx-accept-language-module.

Are these proposals OK?  Shall I push the three patches?

Regards,
Florian

[0001-doc-Explain-more-licensing-aspects-of-the-source-bui.patch (text/plain, attachment)]

[0003-services-Make-it-possible-to-include-dynamic-modules.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.