All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting ## Participants dleuenberger, lkocman, michel, ddemaio, adrian, maxlin ## Leap Back from vacation Still going through the survey responses. Big thanks to Nathan W. for helping me with data processing. https://progress.opensuse.org/projects/leap152retro/documents https://etherpad.opensuse.org/p/ReleaseEngineering-Leap-15.2-retro-20200804 (in- progress) I'd really love to see randomized heartwarming quotes from what went well on openSUSE landing page or software-o-o. Who would be the best to talk to make this happen? s390x resources: Ihno mentioned that he can have a look if we could have more resources available. s390x openQA situation, we'll invite Berthold to rel-eng meetings. ## openSUSE Tumbleweed * The DNS issues on openQA have mostly been resolved (new DNS in the SUSE/DMZ is referenced) - except the new DNS server filters out dnssec records which causes some few issues in tests. We still have ariel configured to use Google's DNS Servers for now * Tumbleweed has received a new signing key for the kernel/KMPs, together with a fixed grub2 package, to mitigate against boothole * RPM's /usr/libexec change passed all builds by now - continuing with openQA fallouts ## ddemaio * Leap 15.2 Boxes Coming. Problem with policy of DHL and SUSE that make delivery difficult ^ who would be the person to escalate "logistic" issues to? More than likely Olli, but can't affect DHL * openSUSE + LibreOffice Conference Meeting * 99 Submissions, CfP closed * GDPR Meeting with legal and heroes on 06.08.2020 ## Dirk * openSUSE distribution architecture policy discussion * not a lot of focus on openSUSE in the last week Lubos: we need to do closure on this topic. I'll send some emails over and see what's left to do. ## Guillaume - Arm On Vacation ## Gerald Not available ## Max * Jump has started testing on openQA https://openqa.opensuse.org/group_overview/75 * The problem from the test results: vendor change while upgrading, need to find a solution to handle this issue * Thanks to Adrian for fixed product buidler space issue. Re-enabled aarch64 and ppc64le on product media build, will also re-enable s390x. * Copied NonFree sources from Leap NonFree to Jump NonFree Lubos: https://jira.suse.com/browse/PM-2094 - Allow vendor change from openSUSE -> SUSE, SUSE -> openSUSE on the Leap installation media. ## Adrian - Jump * Jump ftp tree and images got build and published to stageing server. ~ 250GB * ToDo: - make it public - add s390x architecture Discussion with Release Managers about submissions to SUSE Linux Enterprise. Lubos: the Community Partner requests could be available within next 5 weeks. We could mirror requests referencing OPENSUSE-1234 issue keys. ## Michel PowerPC TW, build problems "modprobe: ...Key was rejected by service" Michel is looking for a guidance as he's blocked on the issue. Adrian: please send me a concrete example. ## Richard MicroOS bare metal self installing ISO needs to be submitted to Factory /tmp as tmpfs will now be the default for new Tumbleweed installations, all submissions are now in staging MicroOS/Kubic heading towards SELinux by default, apparmor disabled by default. ## Tom Not present ## Wolfgang Not present ## Ludwig No update ## Overview of Commmunity SLE Feature Requests (See details in https://en.opensuse.org/Portal:Leap/SLEFeatureRequests ) (This section will be newly part of ReleaseEngineering meeting minutes) * DNF for SLE / Leap Next (PM-2044) - List of benefits was put together by Neal Gompa and Daniel Mach - Request was raised to PM attention Response from Architect: The current dnf implementation is unusable as zypper replacement (our list of problems and missing functionality is much longer than above) and we should not provide them as alternative. Especially as dnf does not/cannot read the zypper repo informations, so it would be pretty useless as alternative. But we should work together with the dnf maintainers to make dnf5 a good candidate by solving our problems, especially the massive python dependencies. Having one tool with a big community would make many things much easier. But according to our developers who participate already in the dnf meetings, dnf5 will again be based on python, so no option for us. Response from Neal: Not reading zypp repo directory is intentional, since DNF invalidates the cache if the repo file has been modified, which zypper does on every run (it reads and writes back what it processed). If this is not a problem, the zypp repo directory can be added to the DNF repo search path. DNF does not rewrite repo files on read operations. As for DNF 5, there will be four interfaces: a C++ library with bindings to various languages available (libdnf), a C++ CLI (Micro DNF), a Python CLI (DNF), and a C++ D-Bus daemon (DNFDaemon). The intent is to make the only thing MicroDNF cannot do is load Python plugins (at least initially). The long-term goal is to retire the Python CLI and incorporate a method to load Python plugins from the C++ implementation. * Add python 3.8 support (PM-1482) - New awaiting PM evaluation - Originally requested for Blender but, now it seems like people generally ask for 3.8 to be available. - Notified PM that this topic is getting attention - Packaging team is working on py38 39 etc via koinstall * Please update glibc to 2.29 or newer (PM-2030) Pending ECO approval - Originally reported as https://bugzilla.opensuse.org/show_bug.cgi?id=1173761 - Deferred to the next release, can't be done as a maintenance update. * Update Apparmor to 2.13.4 (PM-1983) - ECO pending approval - Pinged maintainer whether bsc#1172040 respective o.o equivalent boo#1171315 can't be used as an input for the maintenance update * python-mailman 3.3.1 update requires update of python- importlib_resources, python-zope.interface (PM-1954) - SR done against different SP then the ECO was approved for. - Next step send SR against SLE-15:Update * lqxt-build-tools update to 0.7.0 (PM-1914) - TPM evaluation Done - Deferred to SP3 * add authselect for managing auth stack configuration (PM-1881) - Pending PM Evaluation - Aiming for 15 SP3 - PM generally likes the idea, we're looking for a feedback from Security team. Security team wants to hear feedback from Architect as there seems to be an overlap with pam-config. - Thorsten (Architect) mentioned that we'll have to find resources for pam-config modification as he doesn't have time for it. Any help from community side would be appreciated! * Update libcdio required by python-pycdio 2.1.0 and whipper (PM-1801) - Next release - Will be deferred to the next release (15 SP3) as it does not qualify as a SLE 15 SP2 RC phase request. Change requires rebuild of underlying dependencies. Namely: cdio-utils.spec, ffmpeg.spec, gstreamer-plugins-ugly.spec, gvfs.spec, libcddb.spec, libcdio, paranoia.spec, libcdio.spec, vcdimager.spec