bug#41575: Container with openssh-service requires sshd user on the host

[conjaroy]

In an eariler bug comment [1] I corroborated that nscd was leaking
/etc/passwd information from the host OS into the Guix container, and I
wondered aloud why the container would use the host OS's nscd if there was
a risk of this happening.

I've looked into how Guix configures its own nscd, and it turns out that by
default it enables lookups only for `hosts` and `services` - not for
`passwd`, `group`, or `netgroup`. Presumably, then, this configuration is
sufficient for nscd to prevent the glibc compatibility issues described in
the manual [3].

After adding the following 3 lines in nscd.conf on my foreign distro
(Debian 10) and restarting nscd, my Guix system containers were able to
boot successfully while talking to the daemon:

enable-cachepasswd  no
enable-cachegroup   no
enable-cachenetgroupno

So I think the bug here is that the Guix manual page advising the use of
nscd on a foreign distro [3] doesn't elaborate on which types of service
lookups are safe to enable in the daemon. If Guix is used only to build and
run binaries then perhaps it could use nscd for all lookups, but this is
evidently not the case for Guix system containers.


Cheers,

Jason


[1] https://www.mail-archive.com/bug-guix@gnu.org/msg19915.html
[2]
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm?h=version-1.1.0#n1238
[3] https://guix.gnu.org/manual/en/html_node/Application-Setup.html

On Mon, Aug 24, 2020 at 11:15 PM conjaroy  wrote:

> I've observed this error under similar circumstances: launching a guix
> system container script with network sharing enabled, on a foreign disto
> (Debian 10) with nscd running.
>
> Using `strace -f /gnu/store/...-run-container`, we can observe the
> container's lookup of user accounts via the foreign distro's nscd socket:
>
> [pid 16582] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 11
> [pid 16582] connect(11, {sa_family=AF_UNIX,
> sun_path="/var/run/nscd/socket"}, 110) = 0
> [pid 16582] sendto(11, "\2\0\0\0\0\0\0\0\t\0\0\0postgres\0", 21,
> MSG_NOSIGNAL, NULL, 0) = 21
> [pid 16582] poll([{fd=11, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1
> ([{fd=11, revents=POLLIN}])
> [pid 16582] read(11,
> "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0"...,
> 36) = 36
> [pid 16582] close(11)   = 0
>
> Since the user ("postgres") is indeed missing in the foreign disto, the
> lookup fails. In this case, disabling nscd on the foreign distro allowed
> the container script to run without error.
>
> Based on comments in https://issues.guix.info/issue/28128, I see that it
> was a deliberate choice to bind-mount the foreign distro's nscd socket
> inside the container (instead of starting a separate containerized nscd
> instance). But I'm having trouble seeing why it's acceptable to leak state
> from the foreign distro's user space into the container. Is there something
> I'm missing?
>
> Cheers,
>
> Jason
>

bug#43274: fdisk fails to build on armhf

[Andreas Enge]

Hello Timotej,

On Tue, Sep 08, 2020 at 07:50:58PM +0200, Timotej Lazar wrote:
> genimage tests fail on arm64 due to differently signed char. The fix¹
> is in upstream master but has not been released yet. Maybe we can add
> it to the current Guix package until then?
> ¹ https://github.com/pengutronix/genimage/commit/f4524ddc

great, thanks a lot! I applied and pushed this patch, and dropped fdisk
from the inputs. I am happy to report that genimage now builds on all
our four architectures, instead of just x86_64.

So, do we drop fdisk, which now is a leaf package?

Also, I tried updating genimage to version 12, but there is still a test
failure even on x86_64:
   FAIL: test/basic-images.test 7 - mke2fs
Here is the diff of the test:
--- /tmp/guix-build-genimage-12.drv-0/genimage-12-checkout/test/mke2fs.dump 
2020-09-08 20:57:40.650216225 +
+++ dump2020-09-08 20:57:47.962216531 +
@@ -11,7 +11,7 @@
 Inode count:  8192
 Block count:  32768
 Reserved block count: 1638
-Free blocks:  27592
+Free blocks:  27590
 Free inodes:  8141
 First block:  1
 Block size:   1024
@@ -29,7 +29,7 @@
 Maximum mount count:  -1
 Last checked: Sat Jan  1 00:00:00 2000
 Check interval:   0 ()
-Lifetime writes:  123 kB
+Lifetime writes:  125 kB
 Reserved blocks uid:  0 (user unknown)
 Reserved blocks gid:  0 (group unknown)
 First inode:  11
@@ -47,13 +47,13 @@
 Journal start:0


-Group 0: (Blocks 1-8192) csum 0x62cb [ITABLE_ZEROED]
+Group 0: (Blocks 1-8192) csum 0xe083 [ITABLE_ZEROED]
   Primary superblock at 1, Group descriptors at 2-2
++ func_check
-  Block bitmap at 3 (+2), csum 0xb4967804
+  Block bitmap at 3 (+2), csum 0x0fddd371
   Inode bitmap at 7 (+6), csum 0xb1052088
   Inode table at 11-266 (+10)
-  7117 free blocks, 1997 free inodes, 18 directories, 1997 unused inodes
-  Free blocks: 1076-8192
+  7115 free blocks, 1997 free inodes, 18 directories, 1997 unused inodes
+  Free blocks: 1078-8192
   Free inodes: 52-2048
++ local ret=1
 Group 1: (Blocks 8193-16384) csum 0x7d4b [INODE_UNINIT, BLOCK_UNINIT, 
ITABLE_ZEROED]
++ set +x
Failed to execute 'check_ext'!
   Backup superblock at 8193, Group descriptors at 8194-8194
not ok 7 - mke2fs
FAIL: test/basic-images.test 7 - mke2fs


Andreas

bug#43151: Resolve Calibre run-time dependency

[Andreas Enge]

Hello,

On Mon, Sep 07, 2020 at 06:15:15PM +1000, Brendan Tildesley wrote:
> Your patch also works I think but it will wrap the programs twice, so
> you will get calibre, .calibre-real, and ..calibre-real-real, etc for
> every program, which seems ugly. My patch reproduces the same PYTHONPATH
> that is set in python-build-system in addition to wrapping PYTHONPATH
> (unless I made a mistake), although at the cost of code duplication. I
> leave it to you and who ever is reviewing this to decide which way is
> more correct and push one, haha.

thanks to both of your for your patches! I just pushed Brendan's, which
wraps only once at the price of copy-pasting from another package. I confirm
that it works, also to click on an epub file from within calibre. Closing
the two bugs asking about qtwebengine.

Concerning the update, is mathjax a required input now, or could we just
leave it out and update nevertheless?

Andreas

bug#43093: emacs-ess is broken by emacs 27.1

[Tim Howes via Bug reports for GNU Guix]

On 9/7/2020 2:52 PM, divoplade wrote:

Le lundi 07 septembre 2020 à 23:19 +0200, divoplade a écrit :

Sorry, I don't know how to make a patch.


By trying to make one, I noticed that you have already sent a patch. I
don't know why I did not recieve it. I am still clueless about a lot of
things here.

Anyway, you forgot to update the license. It is now GPLv3+.

Best regards,

divoplade



That's alright, I should have cc'd you with the patch, but forgot since 
I was using git send-email.


I started a separate thread here for this patch. There still seems to be 
a problem with it, as the build sometimes fails due to a file locking 
issue. And it was suggested that I should version it as a revision of 
18.02.2 instead of this versioning scheme.


https://issues.guix.gnu.org/43208

Thanks also for the note about the license. I'll update that accordingly.
-Tim

bug#43284: Synapse v1.14.0 fails to build

[Michael Rohleder]

Seems to be the same as in #42370:
https://issues.guix.gnu.org/42370


signature.asc
Description: PGP signature

bug#43284: Synapse v1.14.0 fails to build

[Katherine Cox-Buday]

It looks like it's failing when trying to build a dependency,
python-gssapi-1.6.5. Here's the log:

#+BEGIN_EXAMPLE
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/wc4xh9wj49rlbyivxi4lsws6whhzx4ab-python-wrapper-3.8.2/bin:/gnu/store/xdbplmjmgsdz6wxr63mghkxjkmma44k0-python-nose-1.3.7/bin:/gnu/store/q5s876bc5yghh6na3ibvfxlvj6fcj17l-mit-krb5-1.18/bin:/gnu/store/q5s876bc5yghh6na3ibvfxlvj6fcj17l-mit-krb5-1.18/sbin:/gnu/store/v6f44zccwh9z5zk3pjlywjybbi8n2hjh-tar-1.32/bin:/gnu/store/ncydgq2znms5n1d2k5yqshhf58nsixwv-gzip-1.10/bin:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/bin:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/bin:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/bin:/gnu/store/n4n560pfvvw50a9369axw5vj5rrqfj1n-diffutils-3.7/bin:/gnu/store/cd5qf3kcnlq35p9k392pjdpdzpsnds70-patch-2.7.6/bin:/gnu/store/hic7snhayfl7m6cpfqqr73nmm19bpqkg-findutils-4.7.0/bin:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/bin:/gnu/store/ishk7fswcs4gkwcp8mh788z4mvvl9bxh-sed-4.8/bin:/gnu/store/bhs4rj58v8j1narb2454raan2ps38xd8-grep-3.4/bin:/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/bin:/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin:/gnu/store/mpa04aq8lblbcviyxywxcsb1zbi0mf39-ld-wrapper-0/bin:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/bin:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/sbin:/gnu/store/q9rm8h9imazsq2c4qiv2yjpvlvliywqb-python-3.8.2/bin:/gnu/store/k30a2pgmc6b3ifmq3rn0dr5ng9gr8w81-which-2.21/bin'
environment variable `PYTHONPATH' set to 
`/gnu/store/scskwiwn6fj9zm0nfjjcz8w8kn1jiv6n-python-shouldbe-0.1.2/lib/python3.8/site-packages:/gnu/store/4y2czl0hbvnkisvx2aq42jf086cz1l6k-python-parameterized-0.7.4/lib/python3.8/site-packages:/gnu/store/zc5mv2h8b7p3lzd4cx3pcbcn9ix25vk5-python-k5test-0.9.2/lib/python3.8/site-packages:/gnu/store/xdbplmjmgsdz6wxr63mghkxjkmma44k0-python-nose-1.3.7/lib/python3.8/site-packages:/gnu/store/shzcgi33zamc0cy6ck2jqlxy3nk90m53-python-decorator-4.3.0/lib/python3.8/site-packages:/gnu/store/b0svsfz2vw2qwlfsi56k8fwbx4fzcfhk-python-six-1.14.0/lib/python3.8/site-packages:/gnu/store/q9rm8h9imazsq2c4qiv2yjpvlvliywqb-python-3.8.2/lib/python3.8/site-packages:/gnu/store/f87xpbsj5ximbgdf0nrxc015hm3f784d-python-forbiddenfruit-0.1.3/lib/python3.8/site-packages'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/q5s876bc5yghh6na3ibvfxlvj6fcj17l-mit-krb5-1.18/include:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/include:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/include:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/include:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/include:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/include:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/include:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include:/gnu/store/q9rm8h9imazsq2c4qiv2yjpvlvliywqb-python-3.8.2/include:/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libre-headers-5.4.20/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/q5s876bc5yghh6na3ibvfxlvj6fcj17l-mit-krb5-1.18/include:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/include:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/include:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/include:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/include:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/include:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/include:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include:/gnu/store/q9rm8h9imazsq2c4qiv2yjpvlvliywqb-python-3.8.2/include:/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libre-headers-5.4.20/include'
environment variable `LIBRARY_PATH' set to 

bug#43274: fdisk fails to build on armhf

[Timotej Lazar]

Hi,

Andreas Enge  [2020-09-08 18:24:21+0200]:
>> The next step would be to check newer releases (12 and 13) of genimage.
>> Has it actually ever been built on the arm architecture?

genimage tests fail on arm64 due to differently signed char. The fix¹
is in upstream master but has not been released yet. Maybe we can add
it to the current Guix package until then?

¹ https://github.com/pengutronix/genimage/commit/f4524ddc

bug#43274: fdisk fails to build on armhf

[Andreas Enge]

On Tue, Sep 08, 2020 at 05:47:53PM +0200, Andreas Enge wrote:
> The next step would be to check newer releases (12 and 13) of genimage.
> Has it actually ever been built on the arm architecture?

I tried 12 and 13, but already on x86_64 the test
FAIL: test/basic-images.test 7 - mke2fs
fails.

If someone with more experience with the package could have a look, that
would be nice.

Andreas

bug#43274: fdisk fails to build on armhf

[Andreas Enge]

On Tue, Sep 08, 2020 at 03:12:03PM +0200, Andreas Enge wrote:
> So there does not even seem to be a test that relies on fdisk.

Looking at the tests, they do call "fdisk" and "sfdisk", but these come
from the util-linux package. The fdisk package only provides "gnufdisk",
which does not seem to be used at all.

> I would suggest to drop fdisk from this package (and getting closer to
> dropping guile@1.8 as well).

The package without fdisk fails on aarch64 (where it also failed previously)
and on armhf (where previously its dependency fdisk failed). So I will push
a commit that drops fdisk.

The next step would be to check newer releases (12 and 13) of genimage.
Has it actually ever been built on the arm architecture?

Also, is there any opposition to then drop the fdisk package from the
distribution?

Andreas

bug#43277: emacs-next is broke, "seq" missing

[Martin Becze]

--debug-init doesn't help and we don't seem to be loading the init file.

On 9/8/20 9:01 AM, Michael Rohleder wrote:
> Hi Martin,
> 
> Martin Becze  writes:
>> emacs-next recently broke. It now has this error on start up.
>>
>> "require: Cannot open load file: No such file or directory, seq"
> 
> Maybe it's possible to find where this is coming from?
> (starting emacs with "--debug-init" might help or starting with a
> minimal .emacs.el etc)
> 



signature.asc
Description: OpenPGP digital signature

bug#43277: emacs-next is broke, "seq" missing

[Michael Rohleder]

Hi Martin,

Martin Becze  writes:
> emacs-next recently broke. It now has this error on start up.
>
> "require: Cannot open load file: No such file or directory, seq"

Maybe it's possible to find where this is coming from?
(starting emacs with "--debug-init" might help or starting with a
minimal .emacs.el etc)

-- 
Alle anziehenden Leute sind immer im Kern verdorben.
Darin liegt das Geheimnis ihrer sympathischen Kraft.
  Oskar Wilde


signature.asc
Description: PGP signature

bug#43277: emacs-next is broke, "seq" missing

[Martin Becze]

I just tried out emacs27 and what replicated Malte's experience. But
even after reloading my environment emacs28 doesn't work.

On 9/8/20 7:40 AM, Malte Gerdes wrote:
> Hi,
> 
> I had a similar error yesterday, with emacs27. Turned out I had to
> reload my environment because some variables still pointed to emacs 26.3
> directories which didn't exist anymore.
> 
> Malte
> 
> On Tue, 8 Sep 2020, 14:25 Martin Becze,  > wrote:
> 
> emacs-next recently broke. It now has this error on start up.
> 
> "require: Cannot open load file: No such file or directory, seq"
> 
> I think this must have happened relatively recently (with the last 3
> weeks) since it was working fine earlier.
> 



signature.asc
Description: OpenPGP digital signature

bug#43274: fdisk fails to build on armhf

[Andreas Enge]

Here is what happens when I drop fdisk from native-inputs of genimage:

starting phase `check'
make --no-print-directory check-TESTS
PASS: test/basic-images.test 1 - cpio
SKIP: test/basic-images.test 2 # SKIP cramfs (missing mkcramfs)
...
PASS: test/basic-images.test 20 - fit

Testsuite summary for genimage 11

# TOTAL: 20
# PASS:  19
# SKIP:  1
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

So there does not even seem to be a test that relies on fdisk.

I would suggest to drop fdisk from this package (and getting closer to
dropping guile@1.8 as well).

Andreas

bug#43277: emacs-next is broke, "seq" missing

[Malte Gerdes]

Hi,

I had a similar error yesterday, with emacs27. Turned out I had to reload
my environment because some variables still pointed to emacs 26.3
directories which didn't exist anymore.

Malte

On Tue, 8 Sep 2020, 14:25 Martin Becze,  wrote:

> emacs-next recently broke. It now has this error on start up.
>
> "require: Cannot open load file: No such file or directory, seq"
>
> I think this must have happened relatively recently (with the last 3
> weeks) since it was working fine earlier.
>
>

bug#43277: emacs-next is broke, "seq" missing

[Martin Becze]

emacs-next recently broke. It now has this error on start up.

"require: Cannot open load file: No such file or directory, seq"

I think this must have happened relatively recently (with the last 3
weeks) since it was working fine earlier.



signature.asc
Description: OpenPGP digital signature

bug#43274: fdisk fails to build on armhf

[Andreas Enge]

The same two tests also fail on an armhf machine.

Andreas

bug#43274: fdisk fails to build on armhf

[Andreas Enge]

Hello,

I am trying to build an armhf disk image on an aarch64 machine.

The build fails in this order:
genimage requires fdisk
fdisk requires guile-1.8.8 (!)
guile-1.8.8 fails two of its 16 tests:
ERROR: Value out of range -9223372036854775808 to 9223372036854775807: 
-9223372036854775808
FAIL: test-num2integral
fail: scm_is_signed_integer ((- (expt 2 63)), -9223372036854775808, 
9223372036854775807) == 1
FAIL: test-conversion

This might be due to trying to "pseudo-cross-compile" from an aarch64 machine.
Independently, the last fdisk release dates from 2011, and relying on
guile-1.8.8 is not sustainable.

Can we phase out fdisk in Guix? Replace it by parted? Something else?
Actually genimage is the only package depending on fdisk, so if anything,
we could maybe drop this dependency, marked as
(native-inputs
   ...
   ("fdisk" ,fdisk) ; for the tests

What do you think?

Andreas