openSUSE Release Process

The kernel is actually only one sample of packages that we can miss... (for strace it was red-herring and a co-incidence: 'grep' was the cause)

So this issue expands to everything in VMinstall and preinstall it seems

does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32

I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?

On Freitag, 16. Dezember 2016, 07:35:55 CET wrote redmine@opensuse.org:

[openSUSE Tracker]
Issue #15448 has been updated by okurz.

does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32

I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?

---

action #15448: Hole in ths staging process: issues can be missed
https://progress.opensuse.org/issues/15448#change-34360

• Author: dimstar
• Status: New
• Priority: Normal
• Assignee: mlin7442
• Category:

* Target version: ¶

Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:

• A new kernel is added to :LETTER
• The kernel, and related packages build
• openQA happens

The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)

We need a way to guarantee that:

• kernel-obs-build is amongst the first packages to be built

Just declare kernel-obs-build as not supported again.

However, you should only do so in Staging projects using

Suppport: !kernel-obs-build

there

• A full rebuilt of the project is done based on this new kernel

(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)

--

Adrian Schroeter
email: adrian@suse.de

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Maxfeldstraße 5

90409 Nürnberg
Germany

On Freitag, 16. Dezember 2016, 08:22:22 CET wrote redmine@opensuse.org:

[openSUSE Tracker]
Issue #15448 has been updated by adrian@suse.de.

On Freitag, 16. Dezember 2016, 07:35:55 CET wrote redmine@opensuse.org:

[openSUSE Tracker]
Issue #15448 has been updated by okurz.

does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32

I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?

---

action #15448: Hole in ths staging process: issues can be missed
https://progress.opensuse.org/issues/15448#change-34360

• Author: dimstar
• Status: New
• Priority: Normal
• Assignee: mlin7442
• Category:

* Target version: ¶

Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:

• A new kernel is added to :LETTER
• The kernel, and related packages build
• openQA happens

The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)

We need a way to guarantee that:

• kernel-obs-build is amongst the first packages to be built

Just declare kernel-obs-build as not supported again.

this can be misread;) I mean, just remove the "Support" flag
for it. That way the OBS will have it again in build meta data
and will trigger all packages on a change.

However, you should only do so in Staging projects using

Suppport: !kernel-obs-build

there

• A full rebuilt of the project is done based on this new kernel

(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)

--

Adrian Schroeter
email: adrian@suse.de

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Maxfeldstraße 5

90409 Nürnberg
Germany

The kernel is only one example... as I wrote already. Don't get hung up on this. We need a generic approach for the problems

As said: in the previous case for example we missed 'grep' having a regression; as nothing buildrequires grep (and still assumes it's there) - it's a great candidate. Rebuild=direct won't ever catch it (it's part of preinstall)

So we switch to transitive rebuild mode?

lnussel wrote:

So we switch to transitive rebuild mode?

well, that would still not good enough for Preinstall and VMinstall, need to check whether the staged request lists in Preinstall or Vminstall, if so waiting new build done and rebuild the others.