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
The introduction of build-mkbaselibs-sle [1] introduced a problem detected by
repo_checker that will show up in all letter stagings.
x86_64
found conflict of build-mkbaselibs-20170804-3.1.noarch with build-mkbaselibs-
sle-20170804-1.1.noarch:
- /usr/lib/build/baselibs_global-deb.conf
- /usr/lib/build/baselibs_global.conf
- /usr/lib/build/mkbaselibs
i586
found conflict of build-mkbaselibs-20170804-3.1.noarch with build-mkbaselibs-
sle-20170804-1.1.noarch:
- /usr/lib/build/baselibs_global-deb.conf
- /usr/lib/build/baselibs_global.conf
- /usr/lib/build/mkbaselibs
The request was approved by the old repo_checker, but given the new package is
not in the rings it likely would not have been detected by the new one, prior
to acceptance, since it would have never built the new subpackage.
Regardless, the proper workflow is to add to the appropriate binaries to the
whitelist based on the effected archs (repo_checker-package-whitelist*) and
preferably fix the problem. :) It should be a simple conflict added in spec
like the other similar packages.
I see build-mkbaselibs-sle was added to the whitelist, but not build-
mkbaselibs which is the reason the errors keep showing up. Just build-
mkbaselibs-sle by itself would prevent installcheck messages from blocking,
but file conflict messages that thus involve two package need to have both
packages whitelisted.
I added build-mkbaselibs to the list [2] which should ignore the messages, but
lets get a 1-2 line fix to the package.
[1] https://build.opensuse.org/request/show/514523
[2] https://build.opensuse.org/package/rdiff/openSUSE:Factory:Staging/
dashboard?linkrev=base&rev=41709
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
openSUSE:Factory:Staging:adi:1 contains packages that use rich deps syntax
which confuse the installcheck tool which intern causes repo-checker to spit
out an error. This error would have caused the previous repo-checker to
silently crash and accept the review. :) Running repo-checker on a Tumbleweed
machine results in a pass, but on the packagelists machine results in a
failure.
The difference appears to be libsolv-tools:
Tumbleweed = 0.6.28
SLE-12-SP2 = 0.6.26
The resulting error:
could not add repo /tmp/repochecker-iewAELU/packages: susetags: line 5466484:
unknown relation: 'if'
It seems the most straightforward approach would be to use a newer version
libsolv on the machine. SLE-12-SP3 provides libsolv-0.6.27 which seems to
handle the syntax when run in a test container. As such the best solution is
likely to update the machine to SP3.
On a more general note this is likely to reoccur when new features are
introduced into rpm and used in Factory as the packagelists machine will
always be using trailing versions of libsolv. As such it might make more sense
to run the repo-checker within a docker container running the latest
Tumbleweed snapshot to ensure access to the latest underlying tooling. Any
opinions on doing this? I'll file an issue in osc-plugin-factory to track
discussion.
With the rpm package built that contains the repo-checker it should not be
hard to run things in a docker container.
What is the workflow for updating the packagelists machine?
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
+CC opensuse-releaseteam
On Monday, August 14, 2017 7:06:51 AM CDT Stefan Dirsch wrote:
> On Fri, Aug 11, 2017 at 07:13:29PM +0000, Repo Checker wrote:
> > Visit https://build.opensuse.org/package/show/X11:XOrg/Mesa
> >
> > Repo Checker wrote in package X11:XOrg/Mesa:
> >
> > The version of this package in openSUSE:Factory has installation issues
> > and may not be installable:
> >
> > can't install Mesa-libd3d-devel-32bit-17.1.5-168.2.x86_64:
> > nothing provides libvulkan_intel-32bit = 17.1.5 needed by
> > Mesa-libd3d-devel-32bit-17.1.5-168.2.x86_64 nothing provides
> > libvulkan_radeon-32bit = 17.1.5 needed by
> > Mesa-libd3d-devel-32bit-17.1.5-168.2.x86_64
> Guys, in case anybody figures out what's wrong in baselibs.conf of Mesa
> package, please let me know. Sigh.
After reading the baselibs.conf documentation [1] it seems there are two
different statements that are extremely similar and are confused within the
Mesa baselibs.conf.
The two statements being:
- arch <arch> package <package>
- arch <arch> targets <target_arch>[:<target_type>]
[<target_arch>[:<target_type>]...]
The first being used to apply only to <package> when arch is <arch>. The
second being used to control the arch and target_arch combinations applied
when evaluating the baselibs.conf file.
Given that the missing requirements should not be requirements of Mesa-libd3d-
devel-32bit and are not dependencies of Mesa-libd3d-devel.x86_64 it seems that
the parser is interpreting the arch lines as matching the second form (or
ignoring as invalid) rather then a conditional to the lines below them.
Mesa-libd3d-devel
requires "Mesa-libd3d-<targettype> = <version>"
arch aarch64 ppc64 ppc64le s390x x86_64 package libvulkan_intel
+/usr/share/vulkan/icd.d/intel_icd.*.json
arch aarch64 ppc64 ppc64le s390x x86_64 package libvulkan_radeon
+/usr/share/vulkan/icd.d/radeon_icd.*.json
arch aarch64 ppc64 ppc64le s390x x86_64 package Mesa-libVulkan-devel
requires "libvulkan_intel-<targettype> = <version>"
requires "libvulkan_radeon-<targettype> = <version>"
Since they happen to be placed after Mesa-libd3d-devel they are applied to it
as if written without the arch lines:
Mesa-libd3d-devel
requires "Mesa-libd3d-<targettype> = <version>"
+/usr/share/vulkan/icd.d/intel_icd.*.json
+/usr/share/vulkan/icd.d/radeon_icd.*.json
requires "libvulkan_intel-<targettype> = <version>"
requires "libvulkan_radeon-<targettype> = <version>"
>From the documentation there does not appear to be a conditional for multiple
archs. Instead the only option appears to be targettype in front of each line.
This obviously requires repeating for each arch which is a bit ugly. Short of
reading the parser to confirm this appears to be the only option.
Feel free to rework my request 516907 [2] as needed. Looking at the build
results it properly removes the dependencies from Mesa-libd3d-devel-32bit
It would seem possible for the parser to look for the "package" keyword and
allow for the desired syntax. I would imagine it either ignored those lines or
using the second syntax (with the target keyword).
[1] https://en.opensuse.org/openSUSE:Build_Service_baselibs.conf
[2] https://build.opensuse.org/request/show/516907
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
When performing `./repo_checker.pl project_only openSUSE:Factory` a crash
occurs due to trying to lookup the package providing
liblua5_3-32bit-5.3.3-2.2.x86_64 which is "lua", but the build is disabled so
the API call does not return it. The bs_mirrorfull script however sees it and
downloads the result. The error that causes the lookup is (which is included
in the dashboard/repo_checker file):
found conflict of liblua5_3-32bit-5.3.3-2.2.x86_64 with
liblua5_3-5-32bit-5.3.4-1.1.x86_64:
- /usr/lib/liblua.so.5.3
Not sure what the plan is with these two packages or if a binary wipe is
needed as there seems to be inconsistent data being returned.
Thanks,
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
Part of the repo-checker bot is crashing when trying to reverse lookup the
package to which rpms producing installcheck/file conflict errors belong. The
rpm causing the issue is not supposed to exist so the error makes sense.
Unfortunately, the /public API is still returning it even after the package
was disabled and binaries wiped.
RPM causing the error:
liblua5_3-32bit-5.3.3-2.2.x86_64
osc api '/public/build/openSUSE:Factory/standard/x86_64/_repository?
view=binaryversions&nometa=1'
<binary name="liblua5_3-32bit.rpm" sizek="118"
hdrmd5="3970ae129623ebcd89b9cbb0256f13f6" />
<binary name="liblua5_3-5-32bit.rpm" sizek="119"
hdrmd5="ab89d49de452657f6f6575b83d4ddcd3" />
The first of the two should not exist. Only the rpm with 5_3-5 in the name
should exist.
liblua5_3-32bit
liblua5_3-5-32bit
The displays on OBS indicate no binaries for the lua package which produces
the 5_3 rpm which is desired.
https://build.opensuse.org/package/binaries/openSUSE:Factory/lua?
repository=standard
https://build.opensuse.org/package/binaries/openSUSE:Factory/lua53?
repository=standard
It looks like the rpms are not properly being wiped from the repository.
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org
There remains another issue that should be fixed up post my conflict additions [1], as
it currently must be whitelisted due to being a ring package. I am not sure what
exactly is trying to be accomplished since the debuginfo packages do not seem to be produced.
I confirmed the same error when trying to install locally so it appears to be legitimate.
It would seem the package is not used given the error.
can't install installation-images-debuginfodeps-Kubic-14.323-1.1.i586:
nothing provides debuginfo(build-id) = 001b389d0fd7381cf67de1f62dda1db1b77ae190 needed by installation-images-debuginfodeps-Kubic-14.323-1.1.i586
nothing provides debuginfo(build-id) = 0043907daa0d65f200a948896d5e21578ad23541 needed by installation-images-debuginfodeps-Kubic-14.323-1.1.i586
nothing provides debuginfo(build-id) = 010d98e694b5c96e67f76d8977f678cecf19d22d needed by installation-images-debuginfodeps-Kubic-14.323-1.1.i586
nothing provides debuginfo(build-id) = 011d5a8202cba2c4c95113e886c31956696872ad needed by installation-images-debuginfodeps-Kubic-14.323-1.1.i586
nothing provides debuginfo(build-id) = 013254c4dd452e2bbf37170e5fe8ceaaf8760138 needed by installation-images-debuginfodeps-Kubic-14.323-1.1.i586
...
Hoping to slowly work towards resolving all these so any effort towards a fix is appreciated.
[1] https://build.opensuse.org/request/show/512936
--
Jimmy
--
To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org