unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Tony O <me@fron.io>, leo@famulari.name, ludo@gnu.org
Cc: 48924@debbugs.gnu.org, efraim@flashner.co.il
Subject: [bug#48924] Add systemd
Date: Sun, 13 Jun 2021 23:44:47 +0200	[thread overview]
Message-ID: <7519d8b43228f04281990bebda04ca785563b21f.camel@student.tugraz.at> (raw)
In-Reply-To: <WjWOB6SEHVWj_yb7XY2hHap6RSYQCliMBzpT5GoeFwCdoYKDFRmX74U0qPRlZFOo5Z7xAsXcFPGi3bO6fYE2ng==@fron.io>

Am Sonntag, den 13.06.2021, 19:56 +0000 schrieb Tony O:
> Okay, I was going by the similarity to the nix package, but if you
> require concrete proof then I just built it without the sandbox and
> with my kernel supporting cgroups. Exactly 15 test fail, out of
> nearly 400. Each of them by best approximation due to binaries not in
> scope and/or systemd not being PID1 (as is repeatedly echoed on the
> error log).
> 
> If those 15 tests pose a concrete issue to you, I would consider
> fixing them, but only with the guarantee that the result end up in
> guix. As it stands disposition seems to be to not merge this, so I'll
> reserve the effort.
15/400 tests failing sounds somewhat reasonable, especially if we can
explain their failure modes (e.g. stuff like not being PID1).  Even if
we add the other tests, that require cgroups on top, that'd be fine,
but we'd have to be able to display all that info in a meaningful
fashion like
  ;; these tests want systemd to be PID1 
  "foo" "bar" "baz"
  ;; these tests require cgroups
  "spam" "ham" "eggs"
  ;; these are missing libquux
  "i" "ran" "out" "of" "funny" "variable" "names"
However, this is somewhat different from the package description at
hand, which lacks those explanations.

The reference point is of course the thing that's compiled within the
sandbox, not anything without.  Having most tests pass when compiling
stuff "normally" with Guix is perhaps a good indicator, that at least
compiling works, but it's really just that.

Finally – and this might be my ignorance of the systemd test suite
speaking, so ignore me if I say something stupid – just because we have
a test coverage of let's say 90% or even 100%, doesn't mean that the
installed binaries will still be able to work.  There is a large
potential for bugs to sneek in, e.g. through an insufficient wrap
phase, so for software like systemd, we should be able to do some
trivial tasks, e.g. `systemctl start hello-world` with a systemd, that
has not claimed PID1.

TL;DR: the plan is to
- Get the sandboxed package to match up as closely as you can get to
the non-sandboxed one w.r.t. testing.
- Document how the remaining disabled tests fail.
- Prove, that components of systemd run when invoked directly from the
store/from within a suitable environment.

It is probably still a somewhat long and bumpy road, but in my personal
opinion one that has an end.
@lfam, ludo, efraim: WDYT?

Regards,
Leo





  reply	other threads:[~2021-06-13 21:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 16:19 [bug#48924] Add systemd Tony O
2021-06-09 17:42 ` Ludovic Courtès
2021-06-09 18:08   ` Tony O
2021-06-09 20:25     ` Ludovic Courtès
2021-06-09 20:31       ` Tony O
2021-06-09 22:33         ` Leo Prikler
2021-06-11 16:39           ` Ludovic Courtès
2021-06-11 17:11             ` Leo Prikler
2021-06-13  7:31               ` Efraim Flashner
2021-06-13  9:36                 ` Ludovic Courtès
2021-06-13 12:19                   ` Efraim Flashner
2021-06-13 18:14                   ` Leo Famulari
2021-06-13 18:54                     ` Tony O
2021-06-13 19:00                       ` Leo Prikler
2021-06-13 19:56                         ` Tony O
2021-06-13 21:44                           ` Leo Prikler [this message]
2021-06-13 22:35                             ` Leo Famulari
2021-06-14 12:30                               ` Ludovic Courtès
2021-06-14 15:25                                 ` Leo Famulari
2021-06-15  9:38                                   ` Ludovic Courtès
2021-06-15 13:40                                     ` Leo Famulari
2021-06-15  6:35                                 ` Efraim Flashner
2021-06-15  9:29                                   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7519d8b43228f04281990bebda04ca785563b21f.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=48924@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    --cc=leo@famulari.name \
    --cc=ludo@gnu.org \
    --cc=me@fron.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).