[Bug 1218184] New: Eliminate the need for 'OBS source links': convert to _multibuild
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Bug ID: 1218184 Summary: Eliminate the need for 'OBS source links': convert to _multibuild Classification: SUSE ALP - SUSE Adaptable Linux Platform Product: Dolomite Version: Milestone 5 Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs@suse.de Reporter: fcrozat@suse.com CC: dimstar@opensuse.org, dleuenberger@suse.com, fcrozat@suse.com, jslaby@suse.com, kernel-bugs@opensuse.org, mls@suse.com, msuchanek@suse.com, qa-bugs@suse.de, tiwai@suse.com Depends on: 1211226 Target Milestone: --- Group: SUSE Enterprise Partner Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1211226 +++ In order to prepare for 'git based source management', we need to fix up a few technical issues. One such issue is 'source links' not being supported in git (i.e in OBS we have openSUSE:Factory/kernel-source as the main package plus a bunch of 'linked packages', each with the name of the additional spec files) The solution is, technically seem, rather simple: using _multibuild multibuild support on OBS is known in two variants, one using a single spec file and conditionals inside the spec file based on @BUILD_FLAVOR@ (probably the more known way) but OBS also supports 'just' listing the additional spec files as 'flavors' the _multibuild to be added to the kernel-source (main package) can be generated like this: <!-----------------------> #!/bin/sh echo "<multibuild>" > _multibuild for pkg in *.spec; do test "{$pkg}" == "kernel-source.spec" && continue echo " <package>${pkg/.spec/}</package>" >> _multibuild; done echo "</multibuild>" >> _multibuild <!-----------------------> the spec files do not need to be changed in anyway with this method -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c1 Frederic Crozat <fcrozat@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent --- Comment #1 from Frederic Crozat <fcrozat@suse.com> --- The workarounds used to get kernel subpackages building with scmsync on IBS are breaking now. We need _multibuild on ALP kernel-source package. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c2 --- Comment #2 from Michal Suchanek <msuchanek@suse.com> --- Opening another bug does not change the fact that it's not possible to set in which repositories individual subpackages build/publish/are used for build. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c3 --- Comment #3 from Frederic Crozat <fcrozat@suse.com> --- It is to ensure we track this for ALP. It is a hard requirements for ALP to have all packages using _multibuild. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c4 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(fcrozat@suse.com) --- Comment #4 from Michal Suchanek <msuchanek@suse.com> --- Nothing to do from the kernel side, the multibuild infra is not up to the task of building the kernel. Please assign to OBS maintainers to fix that. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c5 --- Comment #5 from Jiri Srain <jsrain@suse.com> --- You have known about this request since months. What's the kernel team's ETA? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c6 Jiri Kosina <jkosina@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |denis.kirjanov@suse.com, | |jkosina@suse.com, | |mbrugger@suse.com, | |yousaf.kaukab@suse.com Assignee|kernel-bugs@suse.de |msuchanek@suse.com --- Comment #6 from Jiri Kosina <jkosina@suse.com> --- (In reply to Michal Suchanek from comment #2)
Opening another bug does not change the fact that it's not possible to set in which repositories individual subpackages build/publish/are used for build.
Michal, can you please elaborate what exactly is the problem here? What issue do you see with just adding _multibuild to the spec in ALP-current branch (not SLE)? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c7 --- Comment #7 from Jiri Kosina <jkosina@suse.com> --- Nevermind, apparently all the technical details are in bsc#1211226. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c8 --- Comment #8 from Jiri Kosina <jkosina@suse.com> --- So unless there is a buildservice-way how to build subpackages in different repositories (is there? Jiri? Frederic?) is there a reason not to do https://kerncvs.suse.de/gitweb/?p=kernel-source.git;a=commitdiff;h=89c3dd098... in ALP-current as well? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Frederic Crozat <fcrozat@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fcrozat@suse.com) |needinfo?(mls@suse.com) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c9 --- Comment #9 from Jiri Srain <jsrain@suse.com> --- If the main concern is excludebuild getting inherited if you build against the standard ALP repository, we can have it only conditional in our ProjectConfig, based on the project. Will this help? %if "%_project" == "SUSE:ALP:Source:Standard:Core:1.0:Build" BuildFlags: excludebuild:kernel-source:kernel-qa -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c10 --- Comment #10 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Jiri Srain from comment #9)
If the main concern is excludebuild getting inherited if you build against the standard ALP repository, we can have it only conditional in our ProjectConfig, based on the project. Will this help?
%if "%_project" == "SUSE:ALP:Source:Standard:Core:1.0:Build" BuildFlags: excludebuild:kernel-source:kernel-qa
as far as I understood, the issue is not coming from the main distro projects (there are no excludes in place for any kernel flavor - even with the old linked packages, kernel-obs-qa for example is being built (see https://bugzilla.suse.com/show_bug.cgi?id=1211226#c11) The special case is in the devel project: * Repo QA shall have only the *qa* kernel flavors * Repo standard (name just coincidentally matches) all the rest. => the excludebuild/onlybuild flags proposed in https://bugzilla.suse.com/show_bug.cgi?id=1211226#c3 sounded like a good starting point - but is limited by the special case that kernel-devel-prj/QA builds against kernel-devel-prj/standard (thus inherits prjconf from both repositories) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c11 --- Comment #11 from Michal Suchanek <msuchanek@suse.com> --- Also while exludebuild workaround exists for building I am not aware of any workaround for 'publish' and 'use for build'. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c12 --- Comment #12 from Jiri Srain <jsrain@suse.com> --- Would there be an option to define (in ProjectConfig) new macros for this purpose and let the .spec-file handle the rest? This would allow to solve the issue with inheritance, one could override the inherited value of the macro in any project (and therefore solve the issue with inheriting prjconf from two repos) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c13 --- Comment #13 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Jiri Srain from comment #12)
Would there be an option to define (in ProjectConfig) new macros for this purpose and let the .spec-file handle the rest? This would allow to solve the issue with inheritance, one could override the inherited value of the macro in any project (and therefore solve the issue with inheriting prjconf from two repos)
That should be doable.. something like: %repo_conf DEVEL %if "%{_repository}" == "QA" %repo_conf QA %endif and then in the spec file: %if "%{?repo_conf}" == "QA" # for the regular spec files ExclusiveArch: do-not-build %endif %if "%{?repo_conf}" == "DEVEL" # for the QA flavors ExclusiveArch: do-not-build %endif (needs some more conditions to trigger on the right flavors, but I think the idea is clear) ALP/Factory would not set repo_conf at all and thus get all flavors built (as done in the past with the linked packages) - and the devel project has some flexibility in overwriting the repo_conf marker (which is redefined multiple times on inherited config, last one wins) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c14 --- Comment #14 from Jiri Srain <jsrain@suse.com> --- Thank you Dominique, for confirming that this idea should work (and IMO it can give enough flexibility even if there is more granularity expected in the future) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c15 --- Comment #15 from Michal Suchanek <msuchanek@suse.com> --- How does that help for 'use for build'? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c16 --- Comment #16 from Jiri Srain <jsrain@suse.com> --- Could you, please, explain a bit more in detail what exactly the problem is and how it is solved with the links? Since most of the issues seem to have a solution, could you switch to _multibuild and add the needed macros to your project (we will add them to ALP once submiteed)? Otherwise, as you did not come up with any reason not to proceed as specified in Jiri Kosina’s comment#8, proceed according to it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c17 --- Comment #17 from Michal Suchanek <msuchanek@suse.com> --- The problem is that you can no longer control individual packages with mutibuild while you could with package links. The flags you can control with package links are 'build' 'publish' and 'use for build'. Wit multibuild you can control 'build' with gross spec file hacks, the rest cannot be controlled. This is, of course, only a concern for key packages like kernel or toolchain. Since conversion to multibuild cross-compilers do not build on devel:gcc. In linked package scenario the native binutils would not be used for build so that binutils breakage could be fixed by uploading new binutils revision. The cross-binutils are needed to build cross-gcc so in linked situation cross-gcc would build but with multibuild it's unresolvable because binutils are not used for build. There is similar situation with kernel-obs-build. It should be built in the standard repository but used for build in the QA repository to build kernel-obs-qa, all of these linked from kernel-source together with kernel-default. Determining which package is to be built and used for build in which repository is OBS's job. It should not be pushed on packagers leading to hacky and incomplete solutions. If multibuild is to be used in place of package links OBS should be fixed to deal with setting flags for individual multibuild packages. If we do not have enough people working on OBS to fix up multibuild to be usable, or even so much as comment on bugs concerning multibuild then multibuild should not be used. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c18 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown@suse.com --- Comment #18 from Richard Brown <rbrown@suse.com> --- (In reply to Michal Suchanek from comment #17)
The problem is that you can no longer control individual packages with mutibuild while you could with package links.
The flags you can control with package links are 'build' 'publish' and 'use for build'.
Wit multibuild you can control 'build' with gross spec file hacks, the rest cannot be controlled.
This is, of course, only a concern for key packages like kernel or toolchain.
Since conversion to multibuild cross-compilers do not build on devel:gcc. In linked package scenario the native binutils would not be used for build so that binutils breakage could be fixed by uploading new binutils revision.
The cross-binutils are needed to build cross-gcc so in linked situation cross-gcc would build but with multibuild it's unresolvable because binutils are not used for build.
There is similar situation with kernel-obs-build. It should be built in the standard repository but used for build in the QA repository to build kernel-obs-qa, all of these linked from kernel-source together with kernel-default.
Determining which package is to be built and used for build in which repository is OBS's job. It should not be pushed on packagers leading to hacky and incomplete solutions.
If multibuild is to be used in place of package links OBS should be fixed to deal with setting flags for individual multibuild packages.
If we do not have enough people working on OBS to fix up multibuild to be usable, or even so much as comment on bugs concerning multibuild then multibuild should not be used.
I'm now very confused. The premise of the original bug was that 'source links' need to be removed from the kernel package in Tumbleweed. The premise of this bug many months later is that 'source links' need to be removed from the kernel package in Tumbleweed and ALP Dolomite. kernel-obs-build, kernel-obs-qa, packages in devel:gcc, all seem to me to be chaff thrown up to confuse. Unless I'm missing something they seem to be wildly out of scope to the matter at hand - the kernel in our future products needs to be built using methods like multibuild. I don't think anyone minds what happens in devel projects, but our future/now present products are using 'git based source management' and the long communicated changes needed to facilitate that really need to be implimented now. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c19 --- Comment #19 from Michal Suchanek <msuchanek@suse.com> --- This is not the first time multibuild was suggested for kernel. https://jira.suse.com/browse/PM-1015 It has been rejected because OBS is not ready for multibuild. It was not ready then and is not ready now. (In reply to Jiri Srain from comment #5)
You have known about this request since months. What's the kernel team's ETA?
OBS people have known about the request to control repository flags for multibuild flavors individually for years. https://github.com/openSUSE/open-build-service/issues/3574 Sure, it's possible to implement workarounds in a lot of packages but maybe fixing the root cause would be more productive? There are is an additional problem with OBS multibuild support: package actions are broken for multibuild in the web UI. https://github.com/openSUSE/open-build-service/issues/12913 https://github.com/openSUSE/open-build-service/issues/7866 https://github.com/openSUSE/open-build-service/issues/7156 Apparently it's confusing repeatedly even to people doing packaging daily, reported repeatedly but not fixed. This is much worse for kernel developers who are often not packagers and interact with OBS only occasionally. For them sane interface is even more important, and figuring out the workaround less likely. Coupled with the previous issue that makes manual intervention more likely required it's pretty damning. (In reply to Richard Brown from comment #18) .
I'm now very confused.
The premise of the original bug was that 'source links' need to be removed from the kernel package in Tumbleweed.
The premise of this bug many months later is that 'source links' need to be removed from the kernel package in Tumbleweed and ALP Dolomite.
kernel-obs-build, kernel-obs-qa, packages in devel:gcc, all seem to me to be chaff thrown up to confuse.
Unless I'm missing something they seem to be wildly out of scope to the matter at hand - the kernel in our future products needs to be built using methods like multibuild.
I don't think anyone minds what happens in devel projects, but our future/now present products are using 'git based source management' and the long communicated changes needed to facilitate that really need to be implimented now.
Your hyperbolic comments do not contribute to solving the technical problem, and have potential to adding people problem in addition. I want to believe this is hyperbolic and not serious. In any case your contribution towards solving this problem has been less then none. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c20 --- Comment #20 from Jiri Srain <jsrain@suse.com> --- (In reply to Michal Suchanek from comment #19)
This is not the first time multibuild was suggested for kernel.
https://jira.suse.com/browse/PM-1015
It has been rejected because OBS is not ready for multibuild.
It was not ready then and is not ready now.
(In reply to Jiri Srain from comment #5)
You have known about this request since months. What's the kernel team's ETA?
OBS people have known about the request to control repository flags for multibuild flavors individually for years.
https://github.com/openSUSE/open-build-service/issues/3574
Sure, it's possible to implement workarounds in a lot of packages but maybe fixing the root cause would be more productive?
Which other "a lot of packages" do you mean? Kernel is now the only package still using source links in the ALP code base and if I remember Dominique correctly, it is the same for Factory. Everything else (including toolchain you mentioned in previous comment) has meanwhile switched to _multibuild.
There are is an additional problem with OBS multibuild support: package actions are broken for multibuild in the web UI.
https://github.com/openSUSE/open-build-service/issues/12913 https://github.com/openSUSE/open-build-service/issues/7866 https://github.com/openSUSE/open-build-service/issues/7156
Apparently it's confusing repeatedly even to people doing packaging daily, reported repeatedly but not fixed.
This is much worse for kernel developers who are often not packagers and interact with OBS only occasionally. For them sane interface is even more important, and figuring out the workaround less likely. Coupled with the previous issue that makes manual intervention more likely required it's pretty damning.
(In reply to Richard Brown from comment #18) .
I'm now very confused.
The premise of the original bug was that 'source links' need to be removed from the kernel package in Tumbleweed.
The premise of this bug many months later is that 'source links' need to be removed from the kernel package in Tumbleweed and ALP Dolomite.
kernel-obs-build, kernel-obs-qa, packages in devel:gcc, all seem to me to be chaff thrown up to confuse.
Unless I'm missing something they seem to be wildly out of scope to the matter at hand - the kernel in our future products needs to be built using methods like multibuild.
I don't think anyone minds what happens in devel projects, but our future/now present products are using 'git based source management' and the long communicated changes needed to facilitate that really need to be implimented now.
Your hyperbolic comments do not contribute to solving the technical problem, and have potential to adding people problem in addition. I want to believe this is hyperbolic and not serious. In any case your contribution towards solving this problem has been less then none.
Well, this can be meant seriously. If you need the links because of any issue with IBS, what prevents you to keep them in your devel project / projects and disable all packages building from _multibuild there? The binaries will build from the same .spec-file and from the same tarball, with the same patches applied, independently whether via links in your project or _multibuild in ALP / Factory. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c21 --- Comment #21 from Jiri Slaby <jslaby@suse.com> --- (In reply to Jiri Srain from comment #20)
Well, this can be meant seriously. If you need the links because of any issue with IBS, what prevents you to keep them in your devel project / projects and disable all packages building from _multibuild there? The binaries will build from the same .spec-file and from the same tarball, with the same patches applied, independently whether via links in your project or _multibuild in ALP / Factory.
Do I understand that you are suggesting to build the kernel in devel projects differently in devel projects and Factory. If so, strong NACK from me. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c22 --- Comment #22 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Jiri Slaby from comment #21)
Do I understand that you are suggesting to build the kernel in devel projects differently in devel projects and Factory. If so, strong NACK from me.
As if it even worked. (In reply to Jiri Srain from comment #20)
Which other "a lot of packages" do you mean? Kernel is now the only package still using source links in the ALP code base and if I remember Dominique correctly, it is the same for Factory. Everything else (including toolchain you mentioned in previous comment) has meanwhile switched to _multibuild.
And their develproject is still broken. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c23 --- Comment #23 from Michal Suchanek <msuchanek@suse.com> --- The bodge developed for one of the earlier attempts does not even work. The package is scheduled in the correct repository but then does not build: https://build.opensuse.org/package/live_build_log/home:michals:kernel-test/k... This is clearly another OBS/rpm bug. The same expression is used to determine in which repository to schedule and what is the build architecture yet the result does not match at schedule time and build time. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c24 --- Comment #24 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Dominique Leuenberger from comment #13)
That should be doable.. something like:
%repo_conf DEVEL %if "%{_repository}" == "QA" %repo_conf QA %endif
Does not look so. Conditionals are not allowed in the Macros: section because it is dumped into a rpm macro file, and that does not support them. %repo_conf QA on the other hand goes into the Macros: section -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c25 --- Comment #25 from Richard Brown <rbrown@suse.com> ---
Do I understand that you are suggesting to build the kernel in devel projects differently in devel projects and Factory. If so, strong NACK from me.
I think both Jiri and I do not wish to see development differ in devel Projects and Products However, this bug has been open now for approaching 9 months The failure to satisfactorily address this bug is now hindering/effectively blocking the build of our ALP products (Comment #2) That is why this bug is prioritised as a P1 issue. In order to be able to continue to develop the Product line which we've promised to our customers and investors, I'm reluctantly willing to suggest anything which will allow us to progress. Even if that means having a different build in devel projects and our products After all, reviewing the comments here, all the substantive arguments against _multibuild to date ONLY seem to apply to the devel projects. The 'lacking controls' are controls which are not available in the OBS Projects for Factory or our products anyway. Therefore suggesting the devel project could still use source links as long as the submitted kernel to our products used _multibuild seemed like a diplomatic workaround to table. The alternative would be to continue demanding that the long established hard requirement for _multibuild be finally met, circular discussions would likely continue, meanwhile ALP Product builds remain broken. The more esoteric arguments that _multibuild is fundamentally broken are countered by the realities of our codebase In Factory there are a grand total of 688 packages using _multibuild (package list attached) This list does not include the child-packages created as a result of multibuild. ie. this is the de-duplicated number This includes toolchain packages like cmake, gcc, glibc and is approximately 4% of all packages in Factory There is only ONE package building in Factory still using source links - kernel-source This has been verified by exhaustively searching through all 16000+ packages building in Factory for the presence of _link files. The only results are the linked children of kernel-source (package list also attached) Given it's been demonstrated by literally everyone else working on Factory and our ALP products that it's possible to use _multibuild, I think it's reasonable to expect our kernel experts to also manage it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c26 --- Comment #26 from Richard Brown <rbrown@suse.com> --- Created attachment 871639 --> https://bugzilla.suse.com/attachment.cgi?id=871639&action=edit Packages using multibuild in Factory as of 20240103 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c27 --- Comment #27 from Richard Brown <rbrown@suse.com> --- Created attachment 871640 --> https://bugzilla.suse.com/attachment.cgi?id=871640&action=edit Packages using source links in Factory as of 20240103 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c28 --- Comment #28 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Richard Brown from comment #25)
After all, reviewing the comments here, all the substantive arguments against _multibuild to date ONLY seem to apply to the devel projects. The 'lacking controls' are controls which are not available in the OBS Projects for Factory or our products anyway. Therefore suggesting the devel project could still use source links as long as the submitted kernel to our products used _multibuild seemed like a diplomatic workaround to table.
How would you imagine that to work, specifically?
The alternative would be to continue demanding that the long established hard requirement for _multibuild be finally met, circular discussions would likely continue, meanwhile ALP Product builds remain broken.
Why are long established bugs in multibuild support not fixed if there is hard requirement for using multibuild?
The more esoteric arguments that _multibuild is fundamentally broken are countered by the realities of our codebase In Factory there are a grand total of 688 packages using _multibuild (package list attached) This list does not include the child-packages created as a result of multibuild. ie. this is the de-duplicated number This includes toolchain packages like cmake, gcc, glibc and is approximately 4% of all packages in Factory
I am not disputing that the Factory can be built with _multibuild. However, lack of support for multibuild in OBS degrades OBS usability in general. It also makes maintenance of develprojects and addon projects harder, requiring baroque workarounds. This increases load on package maintainers and detracts from OBS as a selling point of our distribution enabling easy contribution. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c29 --- Comment #29 from Richard Brown <rbrown@suse.com> ---
I am not disputing that the Factory can be built with _multibuild.
However, lack of support for multibuild in OBS degrades OBS usability in general.
It also makes maintenance of develprojects and addon projects harder, requiring baroque workarounds.
This increases load on package maintainers and detracts from OBS as a selling point of our distribution enabling easy contribution.
Yes, this bug is blocking moves towards a more git based workflow Such a workflow would emphasise git more and OBS less That is the point, and the goal is for ALP products to use such a workflow when they have a public contribution path But the inability to build the kernel in ALP blocks everything.. hence this bug being so urgent Given we don’t have anyone contributing to the kernel via OBS anyway I really don’t understand this new argument We explicitly document that contributors must “submit patches to our git repository.” https://en.opensuse.org/Portal:Kernel/Topics I’ve never seen a non-employee submit a change via OBS to kernel:stable https://build.opensuse.org/package/requests/Kernel:stable/kernel-source And if that is your passion, then surely moving to a git workflow will make things better and easier for contributors rather than needing to worry about osc and the like? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c30 --- Comment #30 from Michal Suchanek <msuchanek@suse.com> --- So it does not build. https://build.opensuse.org/package/live_build_log/home:michals:kernel-test/k... Apparently 'needs root for build' is another flag which was available per spec file previously but now is set based on the main spec file. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c31 --- Comment #31 from Richard Brown <rbrown@suse.com> --- (In reply to Michal Suchanek from comment #30)
So it does not build.
https://build.opensuse.org/package/live_build_log/home:michals:kernel-test/ kernel-source:kernel-obs-build/QA/x86_64
Apparently 'needs root for build' is another flag which was available per spec file previously but now is set based on the main spec file.
needsrootforbuild is a very special flag which can only be used with consent and very specific configuration for each OBS instance https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.supported_f... As I am not an OBS Admin, I wouldn't want to speculate as to why non-multibuild kernels work when multibuild kernels don't, but if you need that flag, I'd say the OBS Admins are the ones to talk to about enabling it -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c32 --- Comment #32 from Richard Brown <rbrown@suse.com> --- also..isn't the correct syntax #!needsrootforbuild ? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c33 --- Comment #33 from Michal Suchanek <msuchanek@suse.com> --- Both ways were documented at some point - ! or space does not really make any difference. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c34 --- Comment #34 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Richard Brown from comment #31)
As I am not an OBS Admin, I wouldn't want to speculate as to why non-multibuild kernels work when multibuild kernels don't, but if you need that flag, I'd say the OBS Admins are the ones to talk to about enabling it
Maybe you could try talking to them if you want this to happen. I tried and got no response. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c35 --- Comment #35 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Richard Brown from comment #32)
also..isn't the correct syntax
#!needsrootforbuild
?
Well, OBS code for this is: if test "$BUILD_USER" = abuild ; then grep -E '^#[[:blank:]]*needsrootforbuild[[:blank:]]*$' >/dev/null <$RECIPEPATH && BUILD_USER=root else (so with my limited regex foo, I'd say the syntax used was correct) I'll check with the OBS team about the feature in the context of mulitbuild -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c36 --- Comment #36 from Dominique Leuenberger <dimstar@opensuse.org> --- config whitelisting for the kernel-obs-build has been adjusted in OBS: used to be .*/kernel-obs-build (.*/ to make it build permitted in all projects, for branches) Adrian extended the config to also allow kernel-source:kernel-obs-build; we should soon see a result in the test project -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c37 --- Comment #37 from Dominique Leuenberger <dimstar@opensuse.org> --- https://build.opensuse.org/package/live_build_log/home:michals:kernel-test/k... is now successful -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c38 --- Comment #38 from Michal Suchanek <msuchanek@suse.com> --- Does not work for kernel-source-vanilla or kernel-source${VARIANT} in general: https://build.opensuse.org/project/monitor/Kernel:linux-next -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c39 Dominique Leuenberger <dimstar@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(adrian.schroeter@ | |suse.com) CC| |adrian.schroeter@suse.com --- Comment #39 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Michal Suchanek from comment #38)
Does not work for kernel-source-vanilla or kernel-source${VARIANT} in general:
https://build.opensuse.org/project/monitor/Kernel:linux-next
Not surprising - the whitelist was changed from .*/kernel-obs-build to include .*/kernel-source:kernel-obs-build @Adrian: can you please change the new rule to .*/kernel-source.*:kernel-obs-build ? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c40 Adrian Schröter <adrian.schroeter@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(adrian.schroeter@ | |suse.com) | --- Comment #40 from Adrian Schröter <adrian.schroeter@suse.com> ---
@Adrian: can you please change the new rule to .*/kernel-source.*:kernel-obs-build ?
that is changed now -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c41 --- Comment #41 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Adrian Schröter from comment #40)
@Adrian: can you please change the new rule to .*/kernel-source.*:kernel-obs-build ?
that is changed now
Removing the allowrootforbuild prjconf flag, thanks. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c60 --- Comment #60 from Takashi Iwai <tiwai@suse.com> --- Now the same problem, the build failure of kernel-obs-build, appears on IBS ALP package build. (And confirmed that the old workaround with MyBS change worked.) Can IBS setup be fixed as well? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c61 --- Comment #61 from Adrian Schröter <adrian.schroeter@suse.com> --- changed the config on IBS as well now -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c65 --- Comment #65 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0129-1: An update that solves 10 vulnerabilities, contains three features and has 31 security fixes can now be installed. Category: security (important) Bug References: 1179610, 1183045, 1193285, 1211162, 1211226, 1212584, 1214747, 1214823, 1215237, 1215696, 1215885, 1216057, 1216559, 1216776, 1217036, 1217217, 1217250, 1217602, 1217692, 1217790, 1217801, 1217933, 1217938, 1217946, 1217947, 1217980, 1217981, 1217982, 1218056, 1218139, 1218184, 1218234, 1218253, 1218258, 1218335, 1218357, 1218447, 1218515, 1218559, 1218569, 1218659 CVE References: CVE-2020-26555, CVE-2023-51779, CVE-2023-6121, CVE-2023-6531, CVE-2023-6546, CVE-2023-6606, CVE-2023-6610, CVE-2023-6622, CVE-2023-6931, CVE-2023-6932 Jira References: PED-3459, PED-5021, PED-7322 Sources used: SUSE Real Time Module 15-SP4 (src): kernel-syms-rt-5.14.21-150400.15.65.1, kernel-source-rt-5.14.21-150400.15.65.1 SUSE Linux Enterprise Live Patching 15-SP4 (src): kernel-livepatch-SLE15-SP4-RT_Update_17-1-150400.1.3.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c66 --- Comment #66 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0117-1: An update that solves eight vulnerabilities, contains two features and has 13 security fixes can now be installed. Category: security (important) Bug References: 1109837, 1179610, 1202095, 1211226, 1211439, 1214158, 1214479, 1215237, 1217036, 1217250, 1217801, 1217936, 1217946, 1217947, 1218057, 1218184, 1218253, 1218258, 1218362, 1218559, 1218622 CVE References: CVE-2020-26555, CVE-2022-2586, CVE-2023-51779, CVE-2023-6121, CVE-2023-6606, CVE-2023-6610, CVE-2023-6931, CVE-2023-6932 Jira References: PED-5021, PED-5023 Sources used: SUSE Linux Enterprise Live Patching 12-SP5 (src): kgraft-patch-SLE12-SP5_Update_52-1-8.3.1 SUSE Linux Enterprise Software Development Kit 12 SP5 (src): kernel-obs-build-4.12.14-122.189.1 SUSE Linux Enterprise High Performance Computing 12 SP5 (src): kernel-source-4.12.14-122.189.1, kernel-syms-4.12.14-122.189.1 SUSE Linux Enterprise Server 12 SP5 (src): kernel-source-4.12.14-122.189.1, kernel-syms-4.12.14-122.189.1 SUSE Linux Enterprise Server for SAP Applications 12 SP5 (src): kernel-source-4.12.14-122.189.1, kernel-syms-4.12.14-122.189.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c67 --- Comment #67 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0115-1: An update that solves 10 vulnerabilities, contains three features and has 40 security fixes can now be installed. Category: security (important) Bug References: 1179610, 1183045, 1211162, 1211226, 1212139, 1212584, 1214117, 1214747, 1214823, 1215237, 1215696, 1215885, 1215952, 1216032, 1216057, 1216559, 1216776, 1217036, 1217217, 1217250, 1217602, 1217692, 1217790, 1217801, 1217822, 1217927, 1217933, 1217938, 1217946, 1217947, 1217980, 1217981, 1217982, 1218056, 1218092, 1218139, 1218184, 1218229, 1218234, 1218253, 1218258, 1218335, 1218357, 1218397, 1218447, 1218461, 1218515, 1218559, 1218569, 1218643 CVE References: CVE-2020-26555, CVE-2023-51779, CVE-2023-6121, CVE-2023-6531, CVE-2023-6546, CVE-2023-6606, CVE-2023-6610, CVE-2023-6622, CVE-2023-6931, CVE-2023-6932 Jira References: PED-3459, PED-5021, PED-7167 Sources used: openSUSE Leap 15.5 (src): kernel-source-rt-5.14.21-150500.13.30.1, kernel-livepatch-SLE15-SP5-RT_Update_9-1-150500.11.3.1, kernel-syms-rt-5.14.21-150500.13.30.1 SUSE Linux Enterprise Live Patching 15-SP5 (src): kernel-livepatch-SLE15-SP5-RT_Update_9-1-150500.11.3.1 SUSE Real Time Module 15-SP5 (src): kernel-source-rt-5.14.21-150500.13.30.1, kernel-syms-rt-5.14.21-150500.13.30.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c69 --- Comment #69 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0118-1: An update that solves eight vulnerabilities, contains two features and has 12 security fixes can now be installed. Category: security (important) Bug References: 1109837, 1179610, 1202095, 1211226, 1211439, 1214479, 1215237, 1217036, 1217250, 1217801, 1217936, 1217946, 1217947, 1218057, 1218184, 1218253, 1218258, 1218362, 1218559, 1218622 CVE References: CVE-2020-26555, CVE-2022-2586, CVE-2023-51779, CVE-2023-6121, CVE-2023-6606, CVE-2023-6610, CVE-2023-6931, CVE-2023-6932 Jira References: PED-5021, PED-5023 Sources used: SUSE Linux Enterprise Real Time 12 SP5 (src): kernel-source-rt-4.12.14-10.157.1, kernel-syms-rt-4.12.14-10.157.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c70 --- Comment #70 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0113-1: An update that solves eight vulnerabilities, contains two features and has 13 security fixes can now be installed. Category: security (important) Bug References: 1108281, 1109837, 1179610, 1202095, 1211226, 1211439, 1214479, 1215237, 1217036, 1217250, 1217801, 1217936, 1217946, 1217947, 1218057, 1218184, 1218253, 1218258, 1218362, 1218559, 1218622 CVE References: CVE-2020-26555, CVE-2022-2586, CVE-2023-51779, CVE-2023-6121, CVE-2023-6606, CVE-2023-6610, CVE-2023-6931, CVE-2023-6932 Jira References: PED-5021, PED-5023 Sources used: SUSE Linux Enterprise Server for SAP Applications 12 SP5 (src): kernel-source-azure-4.12.14-16.163.1, kernel-syms-azure-4.12.14-16.163.1 SUSE Linux Enterprise High Performance Computing 12 SP5 (src): kernel-source-azure-4.12.14-16.163.1, kernel-syms-azure-4.12.14-16.163.1 SUSE Linux Enterprise Server 12 SP5 (src): kernel-source-azure-4.12.14-16.163.1, kernel-syms-azure-4.12.14-16.163.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c71 --- Comment #71 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0110-1: An update that solves seven vulnerabilities, contains one feature and has six security fixes can now be installed. Category: security (important) Bug References: 1179610, 1211226, 1215237, 1215375, 1217250, 1217709, 1217946, 1217947, 1218105, 1218184, 1218253, 1218258, 1218559 CVE References: CVE-2020-26555, CVE-2023-51779, CVE-2023-6121, CVE-2023-6606, CVE-2023-6610, CVE-2023-6931, CVE-2023-6932 Jira References: PED-5021 Sources used: NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c74 --- Comment #74 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0141-1: An update that solves 10 vulnerabilities, contains three features and has 41 security fixes can now be installed. Category: security (important) Bug References: 1108281, 1179610, 1183045, 1211162, 1211226, 1212139, 1212584, 1214117, 1214747, 1214823, 1215237, 1215696, 1215885, 1215952, 1216032, 1216057, 1216559, 1216776, 1217036, 1217217, 1217250, 1217602, 1217692, 1217790, 1217801, 1217822, 1217927, 1217933, 1217938, 1217946, 1217947, 1217980, 1217981, 1217982, 1218056, 1218092, 1218139, 1218184, 1218229, 1218234, 1218253, 1218258, 1218335, 1218357, 1218397, 1218447, 1218461, 1218515, 1218559, 1218569, 1218643 CVE References: CVE-2020-26555, CVE-2023-51779, CVE-2023-6121, CVE-2023-6531, CVE-2023-6546, CVE-2023-6606, CVE-2023-6610, CVE-2023-6622, CVE-2023-6931, CVE-2023-6932 Jira References: PED-3459, PED-5021, PED-7167 Sources used: openSUSE Leap 15.5 (src): kernel-syms-azure-5.14.21-150500.33.29.1, kernel-source-azure-5.14.21-150500.33.29.1 Public Cloud Module 15-SP5 (src): kernel-syms-azure-5.14.21-150500.33.29.1, kernel-source-azure-5.14.21-150500.33.29.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c76 --- Comment #76 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0160-1: An update that solves 10 vulnerabilities, contains three features and has 42 security fixes can now be installed. Category: security (important) Bug References: 1179610, 1183045, 1211162, 1211226, 1212139, 1212584, 1214117, 1214158, 1214747, 1214823, 1215237, 1215696, 1215885, 1215952, 1216032, 1216057, 1216559, 1216776, 1217036, 1217217, 1217250, 1217602, 1217692, 1217790, 1217801, 1217822, 1217927, 1217933, 1217938, 1217946, 1217947, 1217980, 1217981, 1217982, 1218056, 1218092, 1218139, 1218184, 1218229, 1218234, 1218253, 1218258, 1218335, 1218357, 1218397, 1218447, 1218461, 1218515, 1218559, 1218569, 1218643, 1218738 CVE References: CVE-2020-26555, CVE-2023-51779, CVE-2023-6121, CVE-2023-6531, CVE-2023-6546, CVE-2023-6606, CVE-2023-6610, CVE-2023-6622, CVE-2023-6931, CVE-2023-6932 Jira References: PED-3459, PED-5021, PED-7167 Sources used: openSUSE Leap 15.5 (src): kernel-obs-build-5.14.21-150500.55.44.1, kernel-livepatch-SLE15-SP5_Update_9-1-150500.11.5.1, kernel-syms-5.14.21-150500.55.44.1, kernel-source-5.14.21-150500.55.44.1, kernel-default-base-5.14.21-150500.55.44.1.150500.6.19.2, kernel-obs-qa-5.14.21-150500.55.44.1 SUSE Linux Enterprise Micro 5.5 (src): kernel-default-base-5.14.21-150500.55.44.1.150500.6.19.2 Basesystem Module 15-SP5 (src): kernel-default-base-5.14.21-150500.55.44.1.150500.6.19.2, kernel-source-5.14.21-150500.55.44.1 Development Tools Module 15-SP5 (src): kernel-source-5.14.21-150500.55.44.1, kernel-obs-build-5.14.21-150500.55.44.1, kernel-syms-5.14.21-150500.55.44.1 SUSE Linux Enterprise Live Patching 15-SP5 (src): kernel-livepatch-SLE15-SP5_Update_9-1-150500.11.5.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 https://bugzilla.suse.com/show_bug.cgi?id=1218184#c77 --- Comment #77 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2024:0156-1: An update that solves 10 vulnerabilities, contains three features and has 31 security fixes can now be installed. Category: security (important) Bug References: 1179610, 1183045, 1193285, 1211162, 1211226, 1212584, 1214747, 1214823, 1215237, 1215696, 1215885, 1216057, 1216559, 1216776, 1217036, 1217217, 1217250, 1217602, 1217692, 1217790, 1217801, 1217933, 1217938, 1217946, 1217947, 1217980, 1217981, 1217982, 1218056, 1218139, 1218184, 1218234, 1218253, 1218258, 1218335, 1218357, 1218447, 1218515, 1218559, 1218569, 1218659 CVE References: CVE-2020-26555, CVE-2023-51779, CVE-2023-6121, CVE-2023-6531, CVE-2023-6546, CVE-2023-6606, CVE-2023-6610, CVE-2023-6622, CVE-2023-6931, CVE-2023-6932 Jira References: PED-3459, PED-5021, PED-7322 Sources used: SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 (src): kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1, kernel-syms-5.14.21-150400.24.103.1 SUSE Linux Enterprise Real Time 15 SP4 (src): kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1, kernel-syms-5.14.21-150400.24.103.1 SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 (src): kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1, kernel-syms-5.14.21-150400.24.103.1 SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 (src): kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1, kernel-syms-5.14.21-150400.24.103.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1, kernel-syms-5.14.21-150400.24.103.1 SUSE Manager Proxy 4.3 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1 SUSE Manager Retail Branch Server 4.3 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1 SUSE Manager Server 4.3 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1 openSUSE Leap 15.4 (src): kernel-obs-qa-5.14.21-150400.24.103.1, kernel-source-5.14.21-150400.24.103.1, kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-livepatch-SLE15-SP4_Update_22-1-150400.9.3.1, kernel-syms-5.14.21-150400.24.103.1 openSUSE Leap Micro 5.3 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1 openSUSE Leap Micro 5.4 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1 SUSE Linux Enterprise Micro for Rancher 5.3 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1 SUSE Linux Enterprise Micro 5.3 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1 SUSE Linux Enterprise Micro 5.4 (src): kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1 SUSE Linux Enterprise Live Patching 15-SP4 (src): kernel-livepatch-SLE15-SP4_Update_22-1-150400.9.3.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 (src): kernel-obs-build-5.14.21-150400.24.103.1, kernel-default-base-5.14.21-150400.24.103.1.150400.24.48.1, kernel-source-5.14.21-150400.24.103.1, kernel-syms-5.14.21-150400.24.103.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1218998 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1219005 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1219011 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Libor Miksik <libor.miksik@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|SUSE Enterprise Partner | Version|Milestone 5 |unspecified Product|Dolomite |SUSE Linux Enterprise Micro | |6.1 Component|Kernel |Kernel/filesystems -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Libor Miksik <libor.miksik@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel/filesystems |Other Group| |SUSE Enterprise Partner Product|SUSE Linux Enterprise Micro |Dolomite |6.1 | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Bug 1218184 depends on bug 1218998, which changed state. Bug 1218998 Summary: cannot abort build/restart build/wipe binaries for multibuild packages https://bugzilla.suse.com/show_bug.cgi?id=1218998 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1218184 Maintenance Automation <maint-coord+maintenance-robot@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com