It appears that in order to workaround the intermittent false-negatives
emitted by repo_checker a number of patterns have been whitelisted. As an
aside, during my requests for feedback about issues and manual accepts for
previous repo_checker nothing was really mentioned although we have since come
across several cases that would have been present previously as well. As in
this case of working around an issue it would be preferred if a discussion is
started rather than me having to stumble across such workarounds.
Currently whitelisted patterns:
patterns-base-apparmor
patterns-kde-kde_telepathy
patterns-media-rest_cd_gnome
patterns-media-rest_cd_kde
patterns-media-rest_dvd
This is certainly less than ideal as it means that any real problems will be
ignored. In fact one of the oldest issues in against the repo_checker is in
regards to packages reference by patterns being removed without any proper
warning [1].
It is understandable given that they are false-negatives, but it seems are
proper solution is in order. As a side-note this is related to the larger
discussion about how often stagings will needed to be rebased now that
repo_checker ensures an entire staging is installable instead of just the
staged requests. This behavior is consistent in that all packages in letter
stagings are required to build regardless of what requests are in that
staging.
repo_checker acts like an extension of OBS in that OBS would check that the
BuildRequires can all be met before attempting to build while repo_checker
ensures the Requires can be met. Currently, anything added to the rings must
have all of the build dependencies present. This has led to packages being
split and all sort of fun stuff to avoid bringing in too many dependencies. At
the end of the day, packages in rings are only passed because all their
dependencies are also available in the rings.
Contrast that to patterns which while having their minimal build dependencies
present do not have there install-time dependencies present. That combined
with the exact version Requires causes the repo_checker to correctly find that
they are not installable from the letter staging. Not having the install-time
requirements met within the staging seems like a short-cut rather than an
idealistically correct setup. If patterns are of enough importance to be in
the rings, their install-time requirements ought to be as well. Otherwise, it
would seem logical to remove them from the rings since they really are not
being checked as the primary purpose of a pattern is to pull in other packages
which cannot be confirmed.
Alternatively, not having the hard version requirements would remove the
repo_checker errors, but still fail if packages required by the pattern are
removed. Either way, from what I can tell this should really be a process
change rather than either special-casing in repo_checker or whitelisting to
hide the problem.
I would imagine all other false-negatives are likely in this same category and
should be solved in the same way which should put the rebase question to rest
with regards to the repo_checker.
[1] https://github.com/openSUSE/osc-plugin-factory/issues/277
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
Hi,
After the release is before the release. Therefore Leap 15 is being
set up right now. tl;dr version: nothing to see yet. Concentrate
all efforts on Tumbleweed please :-)
The longer story is that I've just started to copy packages into the
openSUSE:Leap:15.0 project. It will take a while to bootstrap and
build all packages, as well as getting all tools and bots up and
running. So please don't submit anything there yet.
Also, this will be a major rebase on Tumbleweed and TW sees heavy
changes at the moment. So I'd like to concentrate on having the core
package set settled first rather than wasting too much energy
rebuilding with 12k packages from Tumbleweed at this point. So don't
worry if Leap 15 looks rather incomplete and unusable right now.
The goal is to get everything up to Ring2 to build and pass some
basic openQA checks. Ie KDE and GNOME default installations. That
alone will take some weeks, esp since I will be on vacation for a
while starting tomorrow :-)
Once we got there we can start adding all the rest again. As
announced on the conference the plan for that would be an opt-out
model for packages that were included in 42 before (minus packages
that got dropped in Factory meanwhile) and an opt-in model for new
packages as usual with Leap.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
Hi All,
Currently spec-cleaner is making a big mess of any pattern that runs
through it so for now can we reject any submissions of patterns that
have been through spec cleaner. In the medium term i'll put manual or
ignore blocks around the pattern headers so spec-cleaner doesn't make a
mess, but for now that seems not to work.
Cheers
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B