openSUSE Release Engineering Meeting 18.02.2021
All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting ## Participants Meeting on meet.opensuse.org was cancelled for Feb 17th due to SUSE's SLE NEXT Workshop. See announcement on factory. !!! Please be aware that this meeting is hosted on https://meet.opensuse.org/ReleaseEngineeringMeeting ## Leap CtLG update: 10 features still in progress. Need to be finished until 15 SP3 Public Beta (out of 150 in total). Two more features nginx, and hplip seems to have a plan now, we'll no longer require python-scikit but rather recommend it. libreoffice/kde integration will happen once the new libreoffice is "final" eta around March. Seamless migration from SLE to Leap seems to be working, one last change related to rename of openSUSE -> Leap was submitted. Branched skelcd-control for 15.3 https://github.com/yast/skelcd-control-openSUSE/pull/225 Added Xfce Desktop as an option Looking internally for a librepo maintainer (blocks OPENSUSE-18) and drpm which blocks createrepo_c unification with SLE. Leap 15.3 Beta code drop deadline is today Wednesday 17th of February 15:00 CET, build can be expected within a week from the deadline. Requested Yast CI (practically just for skelcd-control) but there were some issues with deployment. lslezak should be on it. Still working on issue with publishing ftp-trees Requested refresh of SLE Updates snapshot for the Beta ## openSUSE Tumbleweed * Switch from LUA 5.3 to LUA 5.4 executed- some lua-* packages have the 'default lua provides' on the wrong package (lua53-*) as they hardcoded it in their spec file. (should be %lua_provides) * GCC 11 introduction: libgcc_s1 is coming from GCC11 by now, migration was without issues; Staging:Gcc7 currently tests GCC11 as default compiler. Tracking bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1181859 * glibc 2.33 - staging/testing in progress; so far looking painfree (gcc and lightdm were so far the only fallouts) * Autoconf 2.71: 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!) ## Richard (Kubic/TW MicroOS) MicroOS talks given at both SUSE Engineering Summit and FOSDEM. FOSDEM talk is on YouTube https://www.youtube.com/watch?v=HfaXrp4w648 (Engineering Summit content was pretty similar) devel-project Housekeeping on hold for now, too much other stuff ongoing MicroOS for Rock64 Image still in in testing Team awaiting news regarding NVIDIA Jetson Nano purchase/sponsorship options SELinux-by-default tests reviewed, changes still required, WIP Research into checksumming entire filesystems proving fruitful, now looking into ways of smoothly integrating it into MicroOS/Kubic. ## Max On vacation until 16th Feb (Lunar New Year). ## Guillaume - Arm Tumbleweed: * glibc 2.33 is in Factory:ARM but no snapshot released with it yet. * MicroOS images for Rock64 are still failing in Factory because we need to build u-boot against arm-trusted-firmware package which requires to have arm-trusted-firmware and edk2 packages in Tumbleweed first, but they are still blocked in legal queue (Staging:adi:75). Leap 15.3 ARM: * JeOS images for aarch64 added. Need to setup openQA to test them. * Armv7: openSUSE Step is setup in OBS. openSUSE:SLE-15- SP3:Backports now includes ports/armv7l. Huge backlog for armv7 in OBS: wait queue: 17749 packages / blocked queue: 24123 packages. More build power to build armv7 would be very useful. openQA: * Some random network issue in qemu: https://progress.opensuse.org/issues/88335 WSL: WIP to have WSL on aarch64 on https://build.opensuse.org/project/show/home:Guillaume_G:WSL The goal is to have WSL-DistroLauncher package built for aarch64. Help welcomed. ## Michel ppc64le not present, nothing special to report. ## Sarah - s390x * Sarah needed a new approval for openSUSE contributions after receiving a new Manager - additional discussions * Expanded tests for openSUSE Tumbleweed on s390x and has been fixing issues * rpm bug in TW: https://bugzilla.suse.com/show_bug.cgi?id=1181947 ( fix for s390x found) ## Doug * Beta Article Ready * matomo analytics script implemented in get.o.o * Shells.com looks to be a viable solution to help increase use (VDI solution) ## Dirk openSUSE Step has been announced last week - Thanks Doug! Very slow progress on openSUSE:SLE-15-SP3:Backports for armv7l build. Lubos todo: add Step to Leap project structure in https://en.opensuse.org/openSUSE:Packaging_for_Leap ## Gerald or any Board representative Not present ## Wolfgang (Package Hub) - slowly get rid of python2 builds - ## Adrian - CtLG Finished the SR mirroring tool for OBS -> IBS SRs including the server sid state changes and review bot messages.
On Thu, 18 Feb 2021 at 09:08, Lubos Kocman <lubos.kocman@suse.com> wrote:
## openSUSE Tumbleweed
* Switch from LUA 5.3 to LUA 5.4 executed- some lua-* packages have the 'default lua provides' on the wrong package (lua53-*) as they hardcoded it in their spec file. (should be %lua_provides)
I'll try and fix this fully (all lua packages) today if possible. -- Callum Farmer gmbr3@opensuse.org openSUSE - gmbr3
On Thu, 18 Feb 2021 at 09:08, Lubos Kocman <lubos.kocman@suse.com> wrote:
## openSUSE Tumbleweed
* Switch from LUA 5.3 to LUA 5.4 executed- some lua-* packages have the 'default lua provides' on the wrong package (lua53-*) as they hardcoded it in their spec file. (should be %lua_provides)
I'll try and fix this fully (all lua packages) today if possible. -- Callum Farmer gmbr3@opensuse.org openSUSE - gmbr3
On Thu 18-02-21 09:08:09, Lubos Kocman wrote:
* Autoconf 2.71: 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!)
This caught my eye since I'm maintainer of one such package (e2fsprogs) which runs autoreconf. I thought it is needed because our build system may provide some modified autoconf macros and so we need to regenerate the configure script. Was I just mistaken and this isn't needed? Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR
On Thu, 18 Feb 2021, Jan Kara wrote:
On Thu 18-02-21 09:08:09, Lubos Kocman wrote:
* Autoconf 2.71: 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!)
This caught my eye since I'm maintainer of one such package (e2fsprogs) which runs autoreconf. I thought it is needed because our build system may provide some modified autoconf macros and so we need to regenerate the configure script. Was I just mistaken and this isn't needed?
In the past we've smuggled support for new architectures into packages libtool via libtoolize called from autoreconf, yes. But I wouldn't call this the best idea and thus generally recommend against doing unconditional autoreconf & friends (I'd even recomment patching generated files if you patch configury with SUSE specific packages). A linter that checks for patches to .ac/.am without patching generated files and not calling autoreconf might be useful to catch no-op patch parts - not sure how reliable that could be. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On 22. 02. 21, 9:35, Richard Biener wrote:
On Thu, 18 Feb 2021, Jan Kara wrote:
On Thu 18-02-21 09:08:09, Lubos Kocman wrote:
* Autoconf 2.71: 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!)
This caught my eye since I'm maintainer of one such package (e2fsprogs) which runs autoreconf. I thought it is needed because our build system may provide some modified autoconf macros and so we need to regenerate the configure script. Was I just mistaken and this isn't needed?
In the past we've smuggled support for new architectures into packages libtool via libtoolize called from autoreconf, yes. But I wouldn't call this the best idea and thus generally recommend against doing unconditional autoreconf & friends (I'd even recomment patching generated files if you patch configury with SUSE specific packages).
Yes, and sometimes new auto tools break the build too (or even cause silent unwanted changes). So calling autoreconf when not actually needed should be avoided in general. I thought this is documented somewhere, but I fail to find it ATM. regards, -- js suse labs
participants (6)
-
Callum Farmer
-
Callum Farmer
-
Jan Kara
-
Jiri Slaby
-
Lubos Kocman
-
Richard Biener