August 2017 - openSUSE Release Team - openSUSE Mailing Lists

[opensuse-releaseteam] Proposal to resolve the root cause behind whitelisting of Factory patterns for repo_checker

by Jimmy Berry

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

4 years, 1 month

2
7
0 0

[opensuse-releaseteam] Introduction of build-mkbaselibs-sle to Factory and file conflict

by Jimmy Berry

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

4 years, 2 months

1
0
0 0

[opensuse-releaseteam] Newer version of libsolv-tools required on packagelists for repo-checker

by Jimmy Berry

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

4 years, 2 months

2
3
0 0

[opensuse-releaseteam] Re: New comment in package X11:XOrg/Mesa by repo-checker

by Jimmy Berry

+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

4 years, 2 months

1
1
0 0

[opensuse-releaseteam] Post-update of lua in Factory there seems to be stale rpms

by Jimmy Berry

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

4 years, 2 months

3
3
0 0

[opensuse-releaseteam] Seemingly inconsistent API results for Factory/standard repo

by Jimmy Berry

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

4 years, 2 months

1
0
0 0

[opensuse-releaseteam] installation-images-debuginfodeps-Kubic installcheck problem

by Jimmy Berry

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

4 years, 2 months

1
0
0 0

2021

2020

2019

2018

2017

openSUSE Release Team August 2017