all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	65391@debbugs.gnu.org, maximedevos@telenet.be, iyzsong@envs.net,
	mirai@makinata.eu, atai@atai.org, raingloom@riseup.net
Subject: bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)
Date: Mon, 11 Sep 2023 10:30:43 +0200	[thread overview]
Message-ID: <874jk183wx.fsf@web.de> (raw)
In-Reply-To: <87pm2ukxn5.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6526 bytes --]


Simon Tournier <zimon.toutoune@gmail.com> writes:
> On Wed, 30 Aug 2023 at 12:39, "Dr. Arne Babenhauserheide" <arne_bab@web.de> wrote:
>> Please don’t remove packages that are broken on the CI. I often had a
>> case where no substitute was available but the package built just fine
>> locally. This is not a perfect situation (nicer would be to track why it
>> doesn’t come from CI — sometimes it’s just a resource problem on the
>> CI), but if you removed a package I use that would break all updates for
>> me.
>
> Well, I do not think that any policy will mark a package for removal on
> the first build failure.  However, if the same package is still failing
> after several X <duration> or attempts, it means something is wrong.
> Marking it as a candidate for removal implies:
>
>  1. check if the failure is from CI when it builds locally,
>  2. keep a set of packages that we know they are installable.
>
> For instance, ocaml4.07-* packages are failing since more or less April.
>
> https://data.guix.gnu.org/repository/1/branch/master/package/ocaml4.07-ppxlib/output-history
>
> Does it make sense to keep them?  For another example, some perl6-*
> packages are failing since… 2021.
>
> https://data.guix.gnu.org/repository/1/branch/master/package/perl6-xml-writer/output-history
>
> Does it make sense to keep them?

This is a good example, but not for removing broken packages. For
perl6-xml-writer removing the package would keep breakage in Guix.

I just checked the build, and this looks like a Guix packaging error
that breaks the tests due to a change to some unrelated package:
/gnu/store/ap404x14l604wm0gvaj439ga2vjzwnl7-perl6-tap-harness-0.0.7/bin/prove6: /gnu/store/ap404x14l604wm0gvaj439ga2vjzwnl7-perl6-tap-harness-0.0.7/bin/.prove6-real: perl6: bad interpreter: No such file or directory

Disabling the tests makes the package build and work.

So here, removing a package would start at the wrong place: some change
between 2021-02-01 and 2021-04-30 broke the perl6-tap-harness and we did
not detect that.

This is a problem that would get hidden by removing broken packages.

The problem is that we (large inclusive we that stands for all users of
Guix) did not track down this problem that causes the build to fail.

From this I see two distinct cases:

- packages broken upstream
- packages broken by changes in Guix

If a package is broken upstream and not going to get fixed and this
requires regular patching in Guix, I agree that we have to remove it at
some point.

If however a change in Guix breaks packages, that change should get
rolled back / reverted and fixed, so it does not break the packages.

8 |   ocaml-migrate-parsetree
      ^^^^^^^^^^^^^^^^^^^^^^^
Error: Library "ocaml-migrate-parsetree" not found.

This likely means that a change in the inherited package removed the
input, but the breakage wasn’t detected.

And that’s actually what happened in
386ad7d8d14dee2103927d3f3609acc63373156a
Fri Jan 13 10:54:36 2023 +0000

This commit broke ocaml4.07-ppxlib by cleaning up the inputs of
ocaml-ppxlib (not naming names, this is not about shaming but about
detecting the deeper problem).

It should have been rejected (somehow) by CI. The change it would have
required is this:

diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
index 8ff755aea9..042432be9a 100644
--- a/gnu/packages/ocaml.scm
+++ b/gnu/packages/ocaml.scm
@@ -6845,6 +6845,9 @@ (define-public ocaml4.07-ppxlib
          (base32
           "0my9x7sxb329h0lzshppdaawiyfbaw6g5f41yiy7bhl071rnlvbv"))))
      (build-system dune-build-system)
+     (propagated-inputs
+      (modify-inputs (package-propagated-inputs ocaml-ppxlib)
+        (prepend ocaml-migrate-parsetree)))
      (arguments
       `(#:phases
         (modify-phases %standard-phases

So for both the cases you named for removal, such a removal would have
caused us to miss actual problems in our process.

This does not mean that there will never be a case in which a package
has to be removed, but given that both cases you showed are likely
self-induced breakage due to changes that should have been rejected as
breaking seemingly unrelated packages, it rather looks like the
situation where removing the package is the right way forward is the
exceptional case.

The norm is that our CI should have detected a problem in the commit
causing the breakage.
(this is reasoning from only two datapoints, so take it with a grain of
salt …)

Can we automatically rebuild all inheriting packages when a package gets
changed?

> The usual situation is that CI is able to build the packages.  The set
> of packages that CI is not able to build is very limited and it is the
> exception.
>
> Having a rule to deal with the regular broken packages appears to me a
> good thing and very helpful to keep Guix reliable.  And that rule cannot
> be based on rare exceptional cases.

A rule should work with known cases, otherwise it causes known breakage.

Also see above: in the two cases you selected, removing the package
would be the wrong path forward.

> On Wed, 30 Aug 2023 at 12:39, "Dr. Arne Babenhauserheide" <arne_bab@web.de> wrote:
>> If a change in packages breaks my manifest, that is extremely painful.
>
> Yeah, and such rule for dealing with broken packages will be helpful for
> detecting such change and so avoid such situation.

Since a manifest is strictly dependent on all packages defined in it,
removing a single referenced package means that the manifest is broken:
no update works anymore. No security updates come in anymore — even if
the package in question worked locally. This is a situation we should
not cause.

If we had a way to have placeholder packages (similar to the renamings)
that emit warnings for missing packages but do not break the build, that
would reduce the damage done by removing a package. But I think such a
mechanism must be in place and tested before adding a rule to remove
packages.

And as we’ve seen from the two packages you selected, removal wouldn’t
have been the right decision.

The more important question is (serious question and *not* for assigning
blame, but to see whether we can improve processes): with the time we
already spent in this discussion, we could have fixed a lot of packages.
Why did we not do that?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

  reply	other threads:[~2023-09-11  9:19 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19 23:53 bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Maxime Devos
2023-08-22 23:45 ` Csepp
2023-08-24  9:57   ` Simon Tournier
2023-08-24 17:23     ` Csepp
2023-08-24 14:52   ` Maxime Devos
2023-08-24 17:27     ` Csepp
2023-08-29 22:52       ` Maxime Devos
2023-08-30  2:36         ` Maxim Cournoyer
2023-08-24 15:02   ` Maxime Devos
2023-08-24 17:38     ` Csepp
2023-08-27  1:13 ` 宋文武
2023-08-27  3:38   ` Maxim Cournoyer
2023-08-27  8:16     ` bug#65391: [Cuirass] feature requests for dashboard 宋文武 via Bug reports for GNU Guix
2023-08-27  3:39   ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Maxim Cournoyer
2023-08-27  4:30   ` Bruno Victal
2023-08-27 15:07     ` Giovanni Biscuolo
2023-08-27 16:24 ` bug#65391: People need to report failing builds even Andy Tai
2023-08-27 21:26   ` Andy Tai
     [not found] ` <handler.65391.B.169248925726403.ack@debbugs.gnu.org>
2023-08-29 14:03   ` bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Maxime Devos
2023-08-29 14:45     ` Maxim Cournoyer
2023-08-29 22:44       ` Maxime Devos
2023-08-30  2:28         ` Maxim Cournoyer
2023-08-30 10:39           ` Dr. Arne Babenhauserheide
2023-08-30 19:12             ` Maxim Cournoyer
2023-09-07 11:53             ` Simon Tournier
2023-09-11  8:30               ` Dr. Arne Babenhauserheide [this message]
2023-09-11 14:00                 ` Simon Tournier
2023-09-11 23:12                   ` Dr. Arne Babenhauserheide
2023-09-12  0:39                     ` Simon Tournier
2023-08-30 11:50           ` Maxime Devos
2023-09-07 11:32       ` Simon Tournier
2023-09-11  7:28         ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Csepp
2023-09-11  7:58           ` Simon Tournier
2023-09-11 21:52             ` Csepp
2023-09-12 18:43         ` bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Maxime Devos
2023-08-30 10:29     ` 宋文武 via Bug reports for GNU Guix
2024-02-14  9:13 ` bug#65391: Close Andreas Enge

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

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

  git send-email \
    --in-reply-to=874jk183wx.fsf@web.de \
    --to=arne_bab@web.de \
    --cc=65391@debbugs.gnu.org \
    --cc=atai@atai.org \
    --cc=iyzsong@envs.net \
    --cc=maxim.cournoyer@gmail.com \
    --cc=maximedevos@telenet.be \
    --cc=mirai@makinata.eu \
    --cc=raingloom@riseup.net \
    --cc=zimon.toutoune@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.