openSUSE Release Engineering Meeting 13.01.2021
All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting ## Participants guillaume_g, dleuenberger, lkocman, ddemaio, wolfgang, rbrown, skriesch, adrians !!! Please be aware that this meeting is hosted on https://meet.opensuse.org/ReleaseEngineeringMeeting ## Leap Still need to look into missing maintainers on SUSE side situation. New feature request for updating firewalld to 0.9.X Weekly openQA sessions on Fridays https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/T... Still some ongoing discussion about migration testing, we need to have migrations passing by Leap 15.3 Beta / 15 SP3 Public Beta (End of February). * Discussion with new packaging team lead about future python refreshes (previously done by Tomas Ch.) ## openSUSE Tumbleweed * RPM 4.16 has been merged and published as part of Snapshot 0110 * Xfce 4.16.0 is being tested as part of Snapshot 0111 * Autoconf 2.70: some backwards incompatible changes, and implicitly starts gtkdocize in case configure.ac contains GTK_DOC_CHECK; Especially for ring0 packages, this is painful, as we cannot add gtk- doc dependenices there. Those packages need to GTKDOCIZE=true before running autoreconf (most don't need to run autoreconf, unless they patch configure - upstream your patches!) * I was informed by the rpmlint2 maintainer that this is on hold for now. * Multiple Python 3 interpreters should be supported. Currently, integration of 3.6 parallel to the existing 3.8 is in progress. Future should add 3.9 as well (the interpreter is already in Tumbleweed, but no python-modules built yet) ## Richard (Kubic/TW MicroOS) devel-project Housekeeping: Going through devel:kubic identifying packages with no maintainer/no longer being maintained and either adopting them or considering the impacts of removal from Factory. Kubernetes 1.20.1 has been released MicroOS for Rock64 Image is WIP. Team is interested in community opinions regarding other DevBoards that might be good targets for MicroOS * There was some discussion about the Nvidia nano on factory, might be worth checking. Doug: I'd be interested in publishing something about Rock64 MicroOS talk discussing the wide scope of the Project will be at FOSDEM (Distro DevRoom) ## Max * Added below to Backports's prjconf for multi-layering repos issue # required after IBS SR#228071 Substitute: kmod-compat kmod # replacing module-init-tools Prefer: -kmod-compat # required to workaround libwayland-egl-devel/libwaylang-egl1 issue between Mesa(SUSE:SLE-15:Update) and wayland(SUSE:SLE-15-SP2:GA) Substitute: libwayland-egl-devel wayland-devel * Give https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11696 a try for zypper dup fail, the result https://openqa.opensuse.org/tests/1543987#step/zdup/13 looks it's the right track to go, we have to release a updated openSUSE-release to previous Leap version as the proper solution * Build disabled libreoffice in Leap 15.3, it was in Leap project due to is_opensuse macro, however it took almost 2 days to rebuild on aarch64 * Seems rpmlint-backports hasn't refuse opencv3 build on !x86_64 Update on new package requests and redirection by default to Backports. The official request to autobuild team is done, we might want to look for some workarounds. Some maintenance updates were not picked up by Maintenance team because of missing maintainer. Lubos will have a look if some of these can be tracked as feature requests, as we have a process for this (set particular label in jira). For maintenance requests I'll have to contact RM and probably maintenance TPM. ## Guillaume - Arm Tumbleweed: * Bug on the installer related to kernel 5.10 update fixed: https://bugzilla.suse.com/show_bug.cgi?id=1180408 * RPi400 is now supported (snapshot 20210108). with same image as raspberry pi 3/4 Leap 15.3 ARM: * RPi 400 (OPENSUSE-13): update firmware/u-boot in SLE is ready to release, so we should be all set on this side. * Armv7: Project setup to do. OBS projected created but setup is broken: https://build.opensuse.org/project/show/openSUSE:Leap:15.3:ARM * Lack of build resources for ARMv7 in OBS in general (we're building ARMv7 on aarch64 HW). The current setup is done in a way to rebuild both Leap 15.3 / SLE 15 SP3 and also updates in a single project. As it is we'll most likely have to separate it in multiple projects (separting SLE and Backports as well). For this a new functionality on OBS side. As of today we know that pure SLE 15 SP3 is not rebuild-able on ARMv7. WSL: WIP to have WSL on aarch64 on https://build.opensuse.org/project/show/home:Guillaume_G:WSL The goal is to haveWSL-DistroLauncher package built for aarch64. ## Michel ppc64le not present, nothing special to report. ## Sarah - s390x * No new Tumbleweed builds during last weekend because of GCC10 dependencies * New image and packages are building * IBM-internal discussion about z15 test systems in the IBM LinuxONE Community Cloud ## Doug EOY Results (https://en.opensuse.org/End-of-year-surveys/2020/Data) Meetup Planned for Jan. 30. Article, email will be sent Matamo is updated and working again lkocman: I got recently reached out by somebody from SUSE Technical Alliance about CentOS, about the effort. Meeting will be possibly on Thursday. suseportal.cz / opensuse.cz - ongoing discussion https://etherpad.opensuse.org/p/suseportalcz_discussion ## Dirk I've had a longer chat with Adrian on building non-SLES architectures for Leap. We came up with two potential solutions. TBD by Dirk * Use script that merges all updates into a single repository (similar to one for SLE updates for Leap), to get all sources together. This does unfortunately not build, as IBS builds it in a different (update) project structure. I was trying to build it against SLE-15:GA, and even that had already more build failures than we'd like. There would still need to be significant changes to bunch of packages, so we can build again from the source. * Added mporaryry Linuxrc Overlay for unblocking 5.10 Kernel Update In Factory:ARM * Worked on various build failures and package updates Finisheded rewording of Distribution Architecture Policy and posted update (was: Tier1 Policy): https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Architectures_Policy Next step: make the primary architecture change for TW On this topic: the change to structure of software-o-o has happened. All install images are now in tab Install images. ARMv7 doesn't have install image iso so that's out of scope for the change. Various Tumbleweed package updates: Reviewed https://github.com/openSUSE/software-o-o/pull/908 ## Gerald Not present ## Wolfgang (Package Hub) Staging process for openSUSE:Backports:SLE-15-SP3 works quite well We had to reject package updates which requires newer Qt version ## Adrian - CtLG Marco is still working on the submit request mirroring and transferring information. lkocman: Is there currently any todo list for the Maintenance setup? It would be great to have something testable by maintenance team after Beta. Note by Adrian: SLE maintenance updates are merged to a single channel by a script by Adrian whichis merging updates and keeps amount of repos/channels low. SLE Updates are published as soon as possible it's definitely within few hours, not days. Dimstar: we're enabling non-free repos for Ports. For s390x it is already enabled and published (to my surprise no changes were needed on the publisher side); question is basically if we can expect the publish to 'just happen' on ARM/PowerPC as well or if publisher adjustments would have to be expected
Hi, Am Mittwoch, 13. Januar 2021, 13:33:41 CET schrieb Lubos Kocman:
* Multiple Python 3 interpreters should be supported. Currently, integration of 3.6 parallel to the existing 3.8 is in progress. Future should add 3.9 as well (the interpreter is already in Tumbleweed, but no python-modules built yet)
This has the unpleasant side effect, that no /usr/bin/python3 is installed anymore on a fresh TW installation. Instead we have a /usr/bin/python3.8 - should there not be a link to python3? Cheers Axel
On Wed, Jan 13, 2021 at 1:31 PM Axel Braun <axel.braun@gmx.de> wrote:
Hi,
Am Mittwoch, 13. Januar 2021, 13:33:41 CET schrieb Lubos Kocman:
* Multiple Python 3 interpreters should be supported. Currently, integration of 3.6 parallel to the existing 3.8 is in progress. Future should add 3.9 as well (the interpreter is already in Tumbleweed, but no python-modules built yet)
This has the unpleasant side effect, that no /usr/bin/python3 is installed anymore on a fresh TW installation. Instead we have a /usr/bin/python3.8 - should there not be a link to python3?
There is supposed to be one included in python38-base, which it appears to be based on a repoquery: b463066456ad:/ # dnf --quiet repoquery --file /usr/bin/python3 python38-base-0:3.8.6-2.1.i586 python38-base-0:3.8.6-2.1.x86_64 It seems to be installed and available too: b463066456ad:/ # rpm -qf /usr/bin/python3 python38-base-3.8.6-2.1.x86_64 b463066456ad:/ # python3 --version Python 3.8.6 -- 真実はいつも一つ!/ Always, there's only one truth!
Am Mittwoch, 13. Januar 2021, 19:49:26 CET schrieben Sie:
On Wed, Jan 13, 2021 at 1:31 PM Axel Braun <axel.braun@gmx.de> wrote:
Hi,
Am Mittwoch, 13. Januar 2021, 13:33:41 CET schrieb Lubos Kocman:
* Multiple Python 3 interpreters should be supported. Currently, integration of 3.6 parallel to the existing 3.8 is in progress. Future should add 3.9 as well (the interpreter is already in Tumbleweed, but no python-modules built yet)
This has the unpleasant side effect, that no /usr/bin/python3 is installed anymore on a fresh TW installation. Instead we have a /usr/bin/python3.8 - should there not be a link to python3? There is supposed to be one included in python38-base, which it appears to be based on a repoquery:
b463066456ad:/ # dnf --quiet repoquery --file /usr/bin/python3 python38-base-0:3.8.6-2.1.i586 python38-base-0:3.8.6-2.1.x86_64
It seems to be installed and available too:
b463066456ad:/ # rpm -qf /usr/bin/python3 python38-base-3.8.6-2.1.x86_64 b463066456ad:/ # python3 --version Python 3.8.6
Not in my case: test@localhost:~> rpm -qf /usr/bin/python3 file /usr/bin/python3 is not owned by any package (I have set a link in between) ....although the /usr/bin/python3 is listed in the file list for python38-base Strange...
Am 13.01.21 um 19:31 schrieb Axel Braun:
Hi,
Am Mittwoch, 13. Januar 2021, 13:33:41 CET schrieb Lubos Kocman:
* Multiple Python 3 interpreters should be supported. Currently, integration of 3.6 parallel to the existing 3.8 is in progress. Future should add 3.9 as well (the interpreter is already in Tumbleweed, but no python-modules built yet) This has the unpleasant side effect, that no /usr/bin/python3 is installed anymore on a fresh TW installation. Instead we have a /usr/bin/python3.8 - should there not be a link to python3?
That is already the case. There will always be a primary python3 interpreter providing /usr/bin/python3. That selection is hardcoded into the interpreter package specfiles. The provider is currently python38-base. AFAIK a decision against update-alternatives was made here. The macros change nothing in this regard. The packages for the interpreters don't use the macros. How did you end up without /usr/bin/python3? Cheers, Ben
Hello Ben, Am Mittwoch, 13. Januar 2021, 22:48:39 CET schrieb Ben Greiner:
Am Mittwoch, 13. Januar 2021, 13:33:41 CET schrieb Lubos Kocman:
....
How did you end up without /usr/bin/python3?
Take an older TW DVD for installation (20200306) Enable online Repos during installation Select other desktops -> MATE pattern Installation files are coming from onlne-repos (as expected) After installation, run zypper dup to version 20210111 (to get kernel upgraded) I tried to reproduce it, and luckily I failed. So lets consider this as a one-off issue, and hope we dont see it again. Thanks Axel
On Wed, 2021-01-13 at 19:31 +0100, Axel Braun wrote:
Hi,
Am Mittwoch, 13. Januar 2021, 13:33:41 CET schrieb Lubos Kocman:
* Multiple Python 3 interpreters should be supported. Currently, integration of 3.6 parallel to the existing 3.8 is in progress. Future should add 3.9 as well (the interpreter is already in Tumbleweed, but no python-modules built yet)
This has the unpleasant side effect, that no /usr/bin/python3 is installed anymore on a fresh TW installation. Instead we have a /usr/bin/python3.8 - should there not be a link to python3?
as the planned future can't impact your present until the future becomes present, there must be something different going on at yours. python 3.8 (the default at this time) provides a /usr/bin/python3 symlink; if that is missing at yours, try "zypper in --force python38- base" Or are you using a python38-bse from a different project tnan the TW oss repo? Cheers, Dominique
Hi Dominique, Am Donnerstag, 14. Januar 2021, 10:28:28 CET schrieb Dominique Leuenberger / DimStar:
as the planned future can't impact your present until the future becomes present, there must be something different going on at yours.
as said, I could fortunately not reproduce it
python 3.8 (the default at this time) provides a /usr/bin/python3 symlink; if that is missing at yours, try "zypper in --force python38- base"
Here is how it looks on a fresh TW installation (from 11.01., dup'ed today): lrwxrwxrwx 1 root root 9 8. Okt 2019 /usr/bin/python3 -> python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7m -rwxr-xr-x 1 root root 14488 29. Nov 12:51 /usr/bin/python3.8 Thats kinda surprise, as not the latest python is considered. Running the forced installation showed among others: File /usr/bin/python3 from install of python38-base-3.8.6-2.1.x86_64 (Haupt-Repository (OSS)) conflicts with file from package python3-base-3.7.3-1.4.x86_64 (@System) which probably explains the above settings, as python3 is linked to python3.7. I did not expect I need allow-vendor-change on dup? More, I did ot find an option to use update-alternatives for python. That makes live difficult...
Or are you using a python38-bse from a different project tnan the TW
No, plain standard stting.... Cheers Axel
Am 17.01.21 um 13:48 schrieb Axel Braun:
Hi Dominique,
Am Donnerstag, 14. Januar 2021, 10:28:28 CET schrieb Dominique Leuenberger / DimStar:
as the planned future can't impact your present until the future becomes present, there must be something different going on at yours. as said, I could fortunately not reproduce it
python 3.8 (the default at this time) provides a /usr/bin/python3 symlink; if that is missing at yours, try "zypper in --force python38- base" Here is how it looks on a fresh TW installation (from 11.01., dup'ed today):
lrwxrwxrwx 1 root root 9 8. Okt 2019 /usr/bin/python3 -> python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7m -rwxr-xr-x 1 root root 14488 29. Nov 12:51 /usr/bin/python3.8
How "fresh" is your TW install if it still ships python3-base with Python 3.7?
Thats kinda surprise, as not the latest python is considered. Running the forced installation showed among others: File /usr/bin/python3 from install of python38-base-3.8.6-2.1.x86_64 (Haupt-Repository (OSS)) conflicts with file from package python3-base-3.7.3-1.4.x86_64 (@System)
which probably explains the above settings, as python3 is linked to python3.7. I did not expect I need allow-vendor-change on dup?
More, I did ot find an option to use update-alternatives for python. That makes live difficult...
python38-base does not use update-alternatives for /usr/bin/python3. Only the primary interpreted shall provide it. Did it use u-a in python 3.7 times? That might explain the update issue. Removing u-a links needs to execute the %postun scripts at the right time. Ben
Ben, On Sun, 2021-01-17 at 15:17 +0100, Ben Greiner wrote:
python 3.8 (the default at this time) provides a /usr/bin/python3 symlink; if that is missing at yours, try "zypper in --force python38- base" Here is how it looks on a fresh TW installation (from 11.01., dup'ed today):
lrwxrwxrwx 1 root root 9 8. Okt 2019 /usr/bin/python3 -> python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7m -rwxr-xr-x 1 root root 14488 29. Nov 12:51 /usr/bin/python3.8
How "fresh" is your TW install if it still ships python3-base with Python 3.7?
If I see this right, python38-base does 'provide' python3-base, but it does not obsolete it. Which in turn means: nothing obsoletes python3- base. Maybe there is a migration path issue? Which would be odd that we never saw this happen in openQA - but there we might simply have run victim of the resulting system ot be functional. And the Leap 15 upgrade testst TW (where we have a migration from python3-base to python38- base) do not show this issue. @Axel: do you have python3-base somehow locked? Or anything badly trying to preserve it? @Axel: you mention vendor dup: is your python3-base NOT from openSUSE? Anything keeping it in particular present? (try rpm -e --test python3 python3-base - I'd expect nothing to block those two!_ Cheers, Dominique
Hi Dominique, Am Sonntag, 17. Januar 2021, 17:09:20 CET schrieb Dominique Leuenberger / DimStar: <snip>
How "fresh" is your TW install if it still ships python3-base with Python 3.7? As described in my post from Thursday:
Take an older TW DVD for installation (20200306) Enable online Repos during installation Select other desktops -> MATE pattern Installation files are coming from online-repos (as expected) After installation, run zypper dup to version 20210111 (to get kernel upgraded)
If I see this right, python38-base does 'provide' python3-base, but it does not obsolete it. Which in turn means: nothing obsoletes python3- base.
Maybe there is a migration path issue? Which would be odd that we never saw this happen in openQA - but there we might simply have run victim of the resulting system ot be functional. And the Leap 15 upgrade testst TW (where we have a migration from python3-base to python38- base) do not show this issue.
@Axel: do you have python3-base somehow locked? Or anything badly trying to preserve it?
No....
@Axel: you mention vendor dup: is your python3-base NOT from openSUSE? Anything keeping it in particular present?
All packages are from openSUSE I was surprised to see a (vendor-wise) distinction between Haupt-Repository (OSS) and @System IMO a zypper dup should upgrade to latest python version
(try rpm -e --test python3 python3-base - I'd expect nothing to block those two!_
Nothing blocked manually. But: test@localhost:/mnt> rpm -e --test python3 python3-base error: package python3 is not installed Huh? Cheers Axel Cheers Axel
participants (5)
-
Axel Braun
-
Ben Greiner
-
Dominique Leuenberger / DimStar
-
Lubos Kocman
-
Neal Gompa