Currently none of the SUSE:* projects have :DVD subprojects and there is
no way to know short of checking if the project exists. This allows for
len(staging-dvd-archs) to be used to know.
Make sure the links of package in Rings must are valid before processing,
otherwise someone had package linked to the Ring package in somewhere else than
Rings will breaks select/delete/rm_to_prj, ie. _link will be created. Therefore,
only return the candidate if it has proper linked from another ring and have
different package name.
This allows for cases where the requested project was something like
openSUSE:Leap:42.3:Update and the returned project was openSUSE:Leap:42.3.
With this change the fallback will be triggered and the global maintainer
will then be used.
Have to clean up supportpkg list also during accepting staging project,
otherwise suppkg_rebuild can not handle it correct in case next time staged
package in the same staging project had the same supportpkg list.
It seems osc.core and similar generate both quoted and unquoted URLs that
are cached separately. Additionally, urlopen() handles quoted paths
differently from os.path.*() methods which can create issues for quoted
projects.
Useful for determining if a request has an open staging project review
which makes it likely that it has been staged and avoids the need to
review each staging project.
Allows the code to be properly shared between checkrepo and
check_maintenance_incidents as a todo suggests. Given that the majority of
similar cases for code sharing are extension of osc.core it seems to make
sense to place them in osclib.core.
Assuming requests are forwarded to Leap after being accepted into Factory
the devel project can be reviewed just as when the requests were submitted
to Factory.
This behavior is inconsistent in that no builds is ignored, but builds that
are disabled results in a decline. In order to allow for the request to be
evaluated in staging it should not be declined so early.
in opeSUSE:Factory, for example, there is also openSUS-Kubic.product and the
versions are supposed to stay in sync.
We newly find all product definitions inside a project and update all of them,
with the same limiation as before: only if version was a 8 digit version it will
be updated to the current date stamp
Additionally, this is a preparation for the new product builder, as _product is no
longer hardcoded, but found.
