bug#44678: Set a Firefox user agent for our Icecat build

[Arun Isaac]

Hi,

Many sites---jitsi among many others---don't work properly when they see
an Icecat user agent. Instead, when the user agent is set to a Firefox
user agent, these sites work as expected. Users can do this manually by
installing user agent switching extensions such as uaswitcher, but it
would be much better if our Icecat package, by default, came with a
Firefox user agent, and everything worked normally without any user
intervention.

This bug report arose out of a discussion on help-guix. See
https://lists.gnu.org/archive/html/help-guix/2020-11/msg00082.html

I would normally volunteer a patch, but building Icecat takes too long
(> 24 hours) on my slow computer. It would be nice if someone with a
faster build machine handled this.

Thanks,
Arun

bug#44675: guix lint: support for spellchecker or basic grammar

[zimoun]

Hi Vagrant,

On Sun, 15 Nov 2020 at 17:53, Vagrant Cascadian  wrote:
> Please consider a guix lint description/synopsis check for basic
> spelling, typo and rudimentary grammar issues.
>
> Most of the ones I've found were caught by debian's "lintian" tool:
>
>   https://tracker.debian.org/lintian

[...]

> Many of these are likely to be caught by most spell checking routines;
> I'm not sure if there is anything that would be implementable in pure
> guile, or it if would make sense to call out to an external
> spellchecker.

The tool is ’spellintian’ [1], right?  If yes, the work seems done by
[2] but I am not sure to understand if it is only regexp and Perl or if
an external tool is called.  And the list in debian/control is not very
helpful.

1:
https://salsa.debian.org/lintian/lintian/-/blob/master/bin/spellintian
2:
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Spelling.pm 


> That is, of course, if "guix lint" is being used consistently... :)

It should be! :-)


All the best,
simon

bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>> (%default-options): Set its default value to #f.
>> (show-help): Add help doc.
>> * guix/scripts/system.scm (perform-action): Propagate option...
>> (system-derivation-for-action): ...here.  Use it to set the volatile-root?
>> field of the image object passed to SYSTEM-IMAGE.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> Due notably to the “string freeze”, I think we shouldn’t apply it to
> ‘version-1.2.0’.
>
> Some comments:
>
>> +@code{disk-image}.  By default, the root file system of a disk image is
>> +mounted volatile; the @option{--non-volatile} option can be used to make
>
> That’s not generally the case, though in (gnu system image), only two
> image types have it set to false.

Note that the only two images with volatile-root? #f are ARM, and not by
intent but as a workaround:

   ;; FIXME: Deleting and creating "/var/run" and "/tmp" on the overlayfs
   ;; fails.

> Before the new image API though, ‘disk-image’ did not produce a volatile
> root, IIRC.  I’m tempted to think that we should set (volatile-root?
> #f) on image types where it makes sense, which is maybe all of them
> except ISO.  (Then we need to make sure ‘guix system vm’ still gets a
> volatile root.)
>
> WDYT, Mathieu?

Based on your comments and those of Mathieut, I've made volatile-root?
#f the default for 'guix system disk-image', with a '--volatile' option
to maintain the ability to have the rootfs mounted volatile, and
adjusted the doc accordingly.

> So apart from the sentence above, the patch LGTM for ‘master’!

Thanks for the review!

Maxim

bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

[Maxim Cournoyer]

Hey,

Ludovic Courtès  writes:

> Mathieu Othacehe  skribis:
>
>>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>>> (%default-options): Set its default value to #f.
>>> (show-help): Add help doc.
>>> * guix/scripts/system.scm (perform-action): Propagate option...
>>> (system-derivation-for-action): ...here.  Use it to set the volatile-root?
>>> field of the image object passed to SYSTEM-IMAGE.
>>> * doc/guix.texi (Invoking guix system): Document it.
>>
>> This is a nice addition and it looks good to me.
>
> Can we keep it for ‘master’ only, notably because of the “string
> freeze”?

Sure, let's do that!

Maxim

bug#44383: gst-plugins-good fails its test suite on armhf-linux

[Maxim Cournoyer]

Hello Marius,

Marius Bakke  writes:

> Maxim Cournoyer  writes:
>
>> Here's the output for the failing tests:
>
> This is using QEMU transparent emulation, right?

Yes.

> There is a substitute on Berlin:
>
> $ guix weather -s armhf-linux gst-plugins-good
> computing 1 package derivations for armhf-linux...
> looking for 1 store items on https://ci.guix.gnu.org...
> updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> https://ci.guix.gnu.org
>   100.0% substitutes available (1 out of 1)
>   at least 4.1 MiB of nars (compressed)
>   5.5 MiB on disk (uncompressed)
>   1.402 seconds per request (1.4 seconds in total)
>   0.7 requests per second
>
> I'm not sure to what extent we should patch packages to work with QEMU
> transparent emulation.  And currently the CI does not use it at all for
> 32-bit ARM (albeit for rather different reasons).

Do we have reasons to believe the QEMU user-mode emulation is not
reliable/accurate?  That'd be a bummer.  I haven't seen any disclaimer
in QEMU's documentation ?

Thanks,

Maxim

bug#44675: guix lint: support for spellchecker or basic grammar

[Vagrant Cascadian]

Please consider a guix lint description/synopsis check for basic
spelling, typo and rudimentary grammar issues.

Most of the ones I've found were caught by debian's "lintian" tool:

  https://tracker.debian.org/lintian


Common issues appear to be:

  "This packages" -> "This package"
  "allows to X" -> "Xs" or "Xing"


I've fixed many of these in the past:

  git log --author=vagrant --extended-regexp --grep='spelling|typo|grammar' 
--patch

But some of the very same patterns keep reappearing!


Many of these are likely to be caught by most spell checking routines;
I'm not sure if there is anything that would be implementable in pure
guile, or it if would make sense to call out to an external
spellchecker.

Some of them might be harder, and obviously we do not want too many
false positives, but no need to get perfectionist on solving this; even
just checking for "This packages" would haved detected many of these
issues!

That is, of course, if "guix lint" is being used consistently... :)


live well,
  vagrant


signature.asc
Description: PGP signature

bug#39272: `man -H` doesn't use absolute path to groff

[Maxim Cournoyer]

Hello pkill9,

pkill9  writes:

> when running `man -H curl`, I get the following output:
>
> ```
> man: command exited with status 255: (cd /tmp/hmanCnZGIK &&
> /gnu/store/l9j6dsfs2i4spfkia492wnighplvhb1c-man-db-2.9.0/libexec/man-db/zsoelim)
> | (cd /tmp/hmanCnZGIK &&
> /gnu/store/l9j6dsfs2i4spfkia492wnighplvhb1c-man-db-2.9.0/libexec/man-db/manconv
> -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /tmp/hmanCnZGIK &&
> /gnu/store/5sd2yanrfv9pq8mvnf4c6pga11r6x7qh-groff-minimal-1.22.4/bin/preconv
> -e UTF-8) | (cd /tmp/hmanCnZGIK &&
> /gnu/store/5sd2yanrfv9pq8mvnf4c6pga11r6x7qh-groff-minimal-1.22.4/bin/tbl)
> | (cd /tmp/hmanCnZGIK && groff -mandoc -Thtml)
> ```
>
> When I go into a guix environment containing groff however, it works.
> Looking at the command `man -H` tries to use, it needs an absolute path
> to groff.

I looked into this but it turns out that our man-db package is carefully
crafted not to refer to the full groff package to reduce its closure
size by more than half.

I think you'll have to live with installing groff manually to get the
HTML feature, or alter the man-db definition to your particular needs.

If this issue comes back often, we could revisit this choice and use the
full groff, which would mean adding about 50 MiB to the closure of the
bare-bones.tmpl system.

Closing,

Thanks for the report!

Maxim

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Marius Bakke]

Ludovic Courtès  writes:

> Hi,
>
> Daniel Brooks  skribis:
>
>> It should instead include the guix-daemon.cil file which was built from
>> it. The .in file has unsubstituted variabels in it which make it useless
>> as an SELinux policy.
>
> Yes, but running “./configure” gives you the ‘etc/guix-daemon.cil’ for
> your configuration.  What’s wrong with that?
>
> Marius: common practice is to not include instantiated templates; we
> wouldn’t use templates in the first place if contents were always the
> same.  :-)

Yes indeed; somehow I thought the bootstrapped tarball also had run
"configure" with the common options, but obviously that's incorrect.

Closing this bug, as there is no reason to special-case this one file.


signature.asc
Description: PGP signature

bug#44669: Shepherd loses track of elogind

[Marius Bakke]

Hello,

On a newly-installed i7 system, Shepherd believes that the "elogind"
service is not running.  Yet there is an 'elogind-daemon' process,
spawned by PID 1, preventing subsequent "herd start elogind" invocations
from succeeding.


signature.asc
Description: PGP signature

bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
> (%default-options): Set its default value to #f.
> (show-help): Add help doc.
> * guix/scripts/system.scm (perform-action): Propagate option...
> (system-derivation-for-action): ...here.  Use it to set the volatile-root?
> field of the image object passed to SYSTEM-IMAGE.
> * doc/guix.texi (Invoking guix system): Document it.

Due notably to the “string freeze”, I think we shouldn’t apply it to
‘version-1.2.0’.

Some comments:

> +@code{disk-image}.  By default, the root file system of a disk image is
> +mounted volatile; the @option{--non-volatile} option can be used to make

That’s not generally the case, though in (gnu system image), only two
image types have it set to false.

Before the new image API though, ‘disk-image’ did not produce a volatile
root, IIRC.  I’m tempted to think that we should set (volatile-root?
#f) on image types where it makes sense, which is maybe all of them
except ISO.  (Then we need to make sure ‘guix system vm’ still gets a
volatile root.)

WDYT, Mathieu?

So apart from the sentence above, the patch LGTM for ‘master’!

Thanks,
Ludo’.

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Daniel Brooks]

Ludovic Courtès  writes:

> Yes, but running “./configure” gives you the ‘etc/guix-daemon.cil’ for
> your configuration.  What’s wrong with that?
>
> Marius: common practice is to not include instantiated templates; we
> wouldn’t use templates in the first place if contents were always the
> same.  :-)

That's true; I'd forgotten about that. The reason I mention it is that
it would be nice if guix-install.sh could set up the selinux policy. I
guess this is the only step that would need to run configure.

db48x

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Daniel Brooks 写道：

Marius Bakke  writes:

Actually I think both should be included.  The processed file 
will work
for 99% of users, and the template is needed for the 1% that 
use a

different store directory.


Fair enough.


Is a pre-generated .cil file required to run ./configure at all on 
some systems?  How's it different from, say, the Makefile which is 
also generated later?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Ludovic Courtès]

Hi,

Daniel Brooks  skribis:

> It should instead include the guix-daemon.cil file which was built from
> it. The .in file has unsubstituted variabels in it which make it useless
> as an SELinux policy.

Yes, but running “./configure” gives you the ‘etc/guix-daemon.cil’ for
your configuration.  What’s wrong with that?

Marius: common practice is to not include instantiated templates; we
wouldn’t use templates in the first place if contents were always the
same.  :-)

Thanks,
Ludo’.

bug#44662: Lua search paths

[raingloom]

I have a very WIP branch adding search paths to Lua.
https://git.sr.ht/~raingloom/guix-source/tree/raingloom/lua

The problem is that Lua uses a different path format compared to most
packages. Instead of a list of directories, it is a list of path
patterns, each potentially containing a question mark ('?'), which gets
substituted for the module being searched.

For pure Lua modules, this basically means /lib/lua/5.3/?.lua and
/lib/lua/5.3/?/init.lua.
I am not aware of any practical use of paths that do not contain a '?',
so there is a relatively easy solution here:
use the string.gsub function to expand every path component that does
not contain a '?' into two components, the ?.lua and the ?/init.lua one.
This means externally defined components are not expanded, only the
ones defined by Guix.

For C modules, it's a bit trickier, because there is a special
component that looks into loadall.so, which I must admit I'm not
familiar with. As far as I know, popular modules all define their own
shared object file, never a loadall.so.

Also, the path is separated by semicolons, not colons, but I think Guix
can already handle that.

The approaches I see:
- patch loadlib.c in Lua to expand LUA_PATH and LUA_CPATH according to
  the above mentioned heuristics, or
- patch Guix to support paths of this format
- define something like GUIX_LUA_PATH that gets expanded on its own and
  only contains Lua modules defined in Guix, and then gets appended to
  package.path (and do the same for package.path)


Solving this would open up access to the huge variety of Lua modules
and make things like game development in LÖVE much better integrated.
Its users could even use `guix pack` to distribute their games.

bug#44650: Do not suggest `guix pull --news' after first pull

[pelzflorian (Florian Pelz)]

On Sun, Nov 15, 2020 at 02:56:30AM +0100, pelzflorian (Florian Pelz) wrote:
> -  (when previous
> +  (if previous
>  (let ((old-channels (profile-channels previous))
>(new-channels (profile-channels profile)))
>;; Find the channels present in both PROFILE and PREVIOUS, and print
> @@ -405,7 +405,8 @@ previous generation.  Return true if there are news to 
> display."
>#:concise? #t)))
>  channels))
>  
> - (any ->bool more?))
> + (any ->bool more?
> +#f))

I changed the patch to use `and` instead of `if` (attached).  I
confirmed that channel news display fine on a later `guix pull`.

Should I add a copyright line?  I believe no.

Regards,
Florian
>From 8b1557004f618a47d4bea3a65a5b88c4cb718c4c Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 14 Nov 2020 23:36:52 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] pull: Do not suggest running `guix pull --news' on the first
 run.

* guix/scripts/pull.scm (display-channel-news-headlines): If there
are no news to display, return false instead of .
---
 guix/scripts/pull.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index bb1b560a22..7fd8b3f1a4 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -385,7 +385,7 @@ previous generation.  Return true if there are news to 
display."
 (and=> (relative-generation profile -1)
(cut generation-file-name profile <>)))
 
-  (when previous
+  (and previous
 (let ((old-channels (profile-channels previous))
   (new-channels (profile-channels profile)))
   ;; Find the channels present in both PROFILE and PREVIOUS, and print
-- 
2.29.1

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Daniel Brooks]

Marius Bakke  writes:

> Actually I think both should be included.  The processed file will work
> for 99% of users, and the template is needed for the 1% that use a
> different store directory.

Fair enough.

bug#44649: 1.2.0rc0 tarball includes guix-daemon.cil.in

[Marius Bakke]

Daniel Brooks  writes:

> It should instead include the guix-daemon.cil file which was built from
> it. The .in file has unsubstituted variabels in it which make it useless
> as an SELinux policy.

Actually I think both should be included.  The processed file will work
for 99% of users, and the template is needed for the 1% that use a
different store directory.

@Ludo: WDYT about the attached patch for version-1.2.0?

From 8b77d853a4c9503df61fb75190d562206d1de1d2 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 15 Nov 2020 15:56:04 +0100
Subject: [PATCH] maint: Install the processed SELinux policy file in addition
 to the template.

This fixes .
Reported by Daniel Brooks .

* Makefile.am (dist_selinux_policy_DATA): New target.
---
 Makefile.am | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5b84d74f08..4c061db3ca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -561,8 +561,10 @@ dist_zshcompletion_DATA = etc/completion/zsh/_guix
 # Fish completion file.
 dist_fishcompletion_DATA = etc/completion/fish/guix.fish
 
-# SELinux policy
+# SELinux policy.  Install both the template and the compiled version so
+# it works "out of the box", but can be rebuilt as necessary.
 nodist_selinux_policy_DATA = etc/guix-daemon.cil.in
+dist_selinux_policy_DATA = etc/guix-daemon.cil
 
 EXTRA_DIST +=		\
   HACKING		\
-- 
2.29.2



signature.asc
Description: PGP signature

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

[Ludovic Courtès]

Hi!

Miguel Ángel Arruga Vivas  skribis:

> I was looking through the lists because I have a patch that does exactly
> what you describe here.  I guess this goes to core updates, so this
> version is on top of it.  WDYT?

Yes, looks like a change for ‘core-updates’.

> From 145273418d3131bcf3b73d416d19f641645cf3f8 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
>  
> Date: Fri, 13 Nov 2020 15:24:46 +0100
> Subject: [PATCH] gnu: libtool: Restore shebangs on all libtoolize files.

You can add “Fixes .”

> * gnu/packages/autotools.scm (libtool)[restore-build-aux-shebang]: New
> phase after install.
> [restore-ltmain-shebang]: Remove phase, it is now performed by the phase
> restore-build-aux-shebang.

LGTM, thanks for digging through old bugs!

Ludo’.

bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> The question for us becomes how to ensure long-term reproducibility in
>> the presence of such bugs.
>>
>> In this case, I think the only solution would be to change the system
>> clock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, but
>> you end up with different derivations, which is not necessarily
>> desirable).
>>
>> Thoughts?
>
> There is a related bug report here:
>
>   https://issues.guix.gnu.org/39310
>
> Perhaps we could make a "--with-system-clock" option for 'guix build'
> that instructs the daemon to fake the system time?

How would it fake it though?

There are time_namespaces(7), but it’s only for CLOCK_MONOTONIC and
CLOCK_BOOTTIME.

LD_PRELOAD like ‘datefudge’ does is probably not a viable option.

Ludo’.