On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > Yes. Installability is a very basic test and it should be reliable. My > feeling is that broken dependencies are the most common packaging bug. > > > Or if it's not possible to make them work, disable them? In the > > current state we just waste everybody's time and teach packagers to > > ignore CI results. > > > As far as I know, installability tests are not required to pass gating by > default. Correct. > I think the problem is that the tests are run even if nobody asks for them. Well, I think it'd be fine if they were enabled by default _if_ they were reliable. > > one of them (60-Install-packages.txt) shows: > > Failed to resolve the transaction: > > Problem 1: package coreutils-9.5-4.fc41.x86_64 from @commandline conflicts with coreutils-single > > provided by coreutils-single-9.5-4.fc41.x86_64 from @commandline > > - conflicting requests > > I guess the test does not take RPM Conflicts into account. It's overly > optimistic when populating a system by installing all tested packages together > instead of creating a new system for each test seperately. Or by adding > --allowerasing to "dnf install" invocations if the CI wants to reuse > the system. Yes and no. The test does not look at the package metadata at all, it just tries to install all the packages that were part of the update. In the case above, coreutils.srpm builds coreutils.rpm and coreutils-single.srpm, which have Conflicts on one another, and cannot be installed at the same time. The test which (I think) we really want is to install the combined set of packages from the update, so we exercise the situation that will occur on end-user systems, but exclude the packages from this set which are known to be not co-installable. > > A third problem is that the output is full of things that _look_ like > > errors: > > > > Warning: Permanently added '3.14.151.22' (ED25519) to the list of known hosts. > > > > egrep: warning: egrep is obsolescent; using grep -E > > > > <string>:36: (WARNING/2) Bullet list ends without a blank line; unexpected unindent. > > > > <string>:9: (WARNING/2) Definition list ends without a blank line; unexpected unindent. > > > > This makes those jobs look semi-abandonded. It also makes it hard to > > look for the real error, because one has to consider each of those > > lines and answer the question "is this the error I'm looking for?". > > Yes, I've opened many issues regarding Fedora CI. I think the problem is that > the CI maintainer is not a regular packager and thus does not observe CI > reults in real life. On the other hand, package maintainers do not have accces > to the CI system and need to rely on the CI people. Or a CI person?!. The head > count is probably another problem. If there's one "CI person", then that is AdamW. He's doing great work (also in the update I linked in my original post). IIUC, AdamW's focus is on the 'update.*' tests, and those are fine, they generally pass. The bodhi results page says: For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team. For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team. For help debugging failed openQA tests (update.*), contact the Fedora Quality team, ... I added ci@xxxxxxxxxxxxxxxxxxxxxxx in CC. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
