- openSUSE Release Team

[opensuse-releaseteam] testing 123
by per＠xn--nidan-msa.ch 09 May '18

09 May '18

-- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org

1 0

[opensuse-releaseteam] Re: Packages you maintain are present in openSUSE:Leap:15.0
by Ludwig Nussel 19 Apr '18

19 Apr '18

Markus Slopianka wrote: > As long as libqt5-qtwebengine will automatically be picked up from > Factory to swiftly roll out security fixes, everything should be fine. That will only be done until the release. After the one has to submit updates explicitly. 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

1 0

[opensuse-releaseteam] Leap 15.0 release date
by Ludwig Nussel 13 Mar '18

13 Mar '18

Hi, I have been pondering about a release date for Leap 15.0 way too long. Before I announce it to a wider audience I'd like this group here to know. So finally I decided to aim for May 23rd with the option to defer to Friday 25th ie at the conference if desired for the show. 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

1 0

[opensuse-releaseteam] Re: [opensuse-factory] Leap 15 status update 20171220
by Max Lin 26 Dec '17

26 Dec '17

On 12/25/2017 05:05 PM, stakanov wrote: > In data domenica 24 dicembre 2017 23:58:55 CET, Basil Chupin ha scritto: >> On 24/12/17 21:07, stakanov wrote: >>> In data mercoled� 20 dicembre 2017 16:57:26 CET, Ludwig Nussel ha scritto: >>>> Hi, >>>> [1] see 'ADI' tab in >>>> >>>> https://build.opensuse.org/project/staging_projects/openSUSE:Leap:15 >>>> .0 >>>> >>>> [2] https://build.opensuse.org/project/status/openSUSE:Factory >>>> [3] mailto:opensuse-releaseteam@opensuse.org >>> >>> Don't know if the issue is known but link one gives me a Error 500 >> >> Same here -- and even cannot connect to [2] at all. >> >> BC > > Yes, tried it again today, probably an issue over the holidays. > link (1) gives error 500 and link (2) does load eternally without result. > I can therefore confirm your observation. > Seasonal greetings. The error is because of openqa.opensuse.org was down therefor the dashboard fails to reach openqa server, I even can not access to openqa machine so I don't know what is the problem there. This issue needs heros/infra's help, I just sent mail to @admin, as it's holiday there, I didn't expected the service can get back soon. Regards, Max -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner(a)opensuse.org

1 0

[opensuse-releaseteam] looking for someone to update the wiki for 15
by Ludwig Nussel 07 Dec '17

07 Dec '17

Hi, The wiki needs some information about 15, anyone up to grab the task? https://progress.opensuse.org/issues/24898 Some of it is already done AFACIT 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

1 0

[opensuse-releaseteam] Proposal to resolve the root cause behind whitelisting of Factory patterns for repo_checker
by Jimmy Berry 14 Sep '17

14 Sep '17

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

2 7

[opensuse-releaseteam] bootstrapping Leap 15
by Ludwig Nussel 07 Sep '17

07 Sep '17

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

1 0

[opensuse-releaseteam] Rejecting patterns run through spec-cleaner.
by Simon Lees 07 Sep '17

07 Sep '17

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

1 0

[opensuse-releaseteam] Introduction of build-mkbaselibs-sle to Factory and file conflict
by Jimmy Berry 23 Aug '17

23 Aug '17

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

1 0

[opensuse-releaseteam] Newer version of libsolv-tools required on packagelists for repo-checker
by Jimmy Berry 16 Aug '17

16 Aug '17

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

2 3