All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting The meeting is hosted here https://meet.opensuse.org/ReleaseEngineeringMeeting ## Attendees bittin, Sarah, DimStar, Doug, Lubos, Adrian, Marcus, maxlin, Wolfgang ## Leap Leap 15.5 RC code submission deadline is today. We'll take only furher translations and bug fixes. Leap Micro 5.4 is Ready for transition to RC (waiting for SLE Micro 5.4 GA) Seems like we'll have issue with IPRQ (legal staffing) https://news.opensuse.org/2023/03/28/leapmicro-54-beta-hands-on/ We could do something similar as ^ Doug do we know if the article had increased amount of views compared to the usual numbers ^? 15.4 image respin based on QU2 - TBD Leap 16.0 - In discussions after recent changes in ALP development. As of today it seems that we will work on a more tranditional-style distribution based on ALP's core (Grassy Knoll). See my oSC2023 talk. Meeting with Czech National OSPO (Open Source Program Office) - went well we did discuss multiple ways to support the effort. I'll get further data during this week. ## openSUSE Tumbleweed openSUSE:Factory build fail stats: 111 failed 15 unresolvable (one week ago: 133 / 29) https://tinyurl.com/ysy4nnnz * As expectged, some -32bit packages were missing. So far I have received 5 bug reports, the mentioned packages (and deps) have been build-enabled. * Staging:C: openssl 3.1 incoming; a few packages failing to build i586 port: * No dedicated release manager - any volunteers? * Currently not passing openQA; Firefox has been marked ExcludeArch %ix86, openQA expects firefox to be tested though, thus does not let the snapshot pass. Call for help: anybody there to make Firefox build on i586 again? ## Richard (MicroOS) Not available The MicroOS Desktop Plasma/KDE is in desperate need of help else could be at risk of being dropped (again) https://microos.opensuse.org/blog/2023-04-02-state-of-microOS-Desktop-Plasma... ## Richard (ALP Architecture) Not available Richard in his new role as SUSE's Distribution Architect is looking at ways of improving ALP's contribution story and use by openSUSE as a base for future offerings. This is particually urgent as OBS's SUSE:ALP project is effectively in progress of being 'moved' to SUSE's internal IBS in order to comply with all the certifications SUSE need for ALP. For those who need a very brief understanding of how ALP is built - this is rather different from previous SUSE/openSUSE Products SUSE:ALP:Workbench is effectively the equivalent of Factory:Rings:0, being used for bootstrapping SUSE:ALP:Source:Standard is the name for the 'track', with there being concepts for possible future 'tracks' like "Rolling/Fast" or "Premium" or such SUSE:ALP:Source:Standard:Core is the name for where 'core' packages are built, the ones that will be used by all Products SUSE:ALP:Products:<PRODUCTNAME> is the name for where products are actually built, like a SUSE ALP Bedrock (aka Server) product and a SUSE ALP Micro product Current working plan is to recreate the above in an openSUSE:ALP namespace Everything SUSE does in their IBS equivalent namespaces will be synced 1:1 to the OBS openSUSE:ALP namespace Contribution to these layers of ALP might not be implimented in time for SUSE:ALP GA, but obviously we want that in the long term - we just also want it to be done better than we did with Closed-Leap-Gap Leap openSUSE will be able to create their own Products in the openSUSE:ALP:Products namespace - this might be where/how we build a "Leap 16.0" or maybe a more appropriately named traditional distro based on ALP, assuming the contributions for it can be found. After the above is implimented obvious next steps would include investigating establishing an openSUSE:ALP:Source:Rolling track, and mapping it to Tumbleweed so we can start using those projects for developing the 'ALP+1' codebase lkocman: Current solution for Leap 15.X is https://en.opensuse.org/Portal:Jump:OBS:SRMirroring (the bi-directional sync currently does not work). lkocman is the "feedback loop" bottleneck here. rbrown: ^ exactly - and we want to do something better than this, which might mean doing nothing until we have the time to really do something a lot better than that Adrian: people who might be interested in designing contribution process to ALP., should join the public meetings of https://en.opensuse.org/openSUSE:ALP/Workgroups/Git-Packaging-Workflow ## Max Leap 15.5 * Build 459.1 is latest published snapshot * Build fails in Backports: 2 unresolvables, 16 fails * Last round of /usr/bin/python shebang cleanup * rpmlint-backports got a update for a better way to address package conflicts to SLE packages what aren't released in SLE products, therefore the build number in Backports grows ## Guillaume - Arm Not available openQA: * openqa-aarch64 worker is very slow. Likely related to btrfs issues, investigating. Tumbleweed: * 20230330 was the 1st released snapshot which was rebuilt with gcc13. * GCC13 adds support for AArch64 LSE and LSE2 to libatomic. Disable outline atomics, and use LSE ifuncs for 1-8 byte atomics and LSE2 ifuncs for 16-byte atomics. (On Neoverse V1, 16-byte atomics are ~4x faster due to avoiding locks) * NVIDIA: tester with aarch64 server and NVIDIA card wanted - Proprietary drivers are now available for aarch64 (only G06): https://download.nvidia.com/opensuse/tumbleweed/ - New opengpu driver also available in OBS: https://build.opensuse.org/project/monitor/X11:Drivers:Video lkocman to check on who is the aarch64 + nvidia effort blocked on. I recall that there was a chosen point of contact. No update sorry. Leap: * 15.5 aarch64: No aarch64 specific issues * 15.5 armv7: no blocker ALP: * No aarch64 specific issues WSL: * Works with x86 emulator since appx installer is x86-64, but this is not really an issue since arm64 Win11 includes x86 emulator by default. => Could we publish it on Microsoft store anyway? lkocman: Team is okay, but we need to make sure that such case is covered in openQA https://progress.opensuse.org/issues/126083. Steps documented on the wiki to install the appx from download.o.o: https://en.opensuse.org/openSUSE:WSL#With_Appx_from_openSUSE_download_server ## Sarah - s390x Tumbleweed * release is rolling Leap: * working * new (waiting) Submissisions with fixes for gtkd and gnu-cobol * New topic HPC packages (enablement) at the Linux Distributions Working Group @ Open Mainframe Project * The Open Source CTO at IBM is looking for mainframe users, who want to use MPI and OpenMP for parallelism and optimizing builds/runs of open source software (example Kafka in the case of an Open Source Contributor in our Working Group) * 2 accepted presentations at the oSC lkocman: to reach out to Software AG regarding their s390x / openSUSE usecase Sarah will reach out to Mike Friesenegger ## Doug * Google Summer of Code * Processing for rankings * Ranking session planned for April 25 (deadline April 27) * oSC23 * CfP closed * Sunday is necessary * 107 registered, 87 submissions * Approving talks * Reaching out to people about talks * Making plan according to moch schedule * Need to eliminate a couple talks * arm is sponsoring * in discussions with amazon * openSUSE.Asia Summit * Waiting on location & dates * arm will sponsor * Continuing Leap 15.5 release annoucement * Processing TSP requests ## Dirk Not available Improved the CDN setup a bit further (https working now, caching issues fixed) and in progress of collecting in put from early testers. It looks like we have more issues to resolve. Did a strategic benchmarking exercise with various zypper options and a huge part of the slowness appears to be related to the choices of zypper options. In evaluation with zypper folks. A > factor 5 improvement even for european is possible over current setup. Other locations could be better. Sarah can provide mainframe acess - he has received VM from Sarah * also todo announce tumbleweed maintainer policy draft currently working on testing those in a private staging test project * Started ALP:RISCV:* builds in the new build setup Biggest speedup can be observed by switching zlib to zlib-ng, so looked into fixing the build failures caused by switching to zlibo-ng- compat ## Wolfgang (Package Hub), Scott Bahling * Moved duplicated packages to subpackages for SLE-15-SP5 (thanks to Max for the list of packages) * Packages in subpackages for SP5 is up to the level of SP4 (still considering putting more packages there because of migration from Leap to SLE) * patterns-mate added to openSUSE:Backports:SLE-15-SP5 (thanks Max) ## Maintenance team (Marcus or Maurizio (m4u)) lkocman: we need to syncup on Leap Micro 5.4 GA. I believe SLE Micro is only blocked on IPRQ and then they can go live. Our update channel should receive all SLEM 5.4 updates from that point in time. 15.5 setup is done lkocman: We're still not in RC phase, so better now than later. Key rotation: openSUSE:Leap:15.5 is done, Backports are bit more challenging because of SLES. Wolfgang: we're injecting the key. Marcus we probably want to do only Backports 15 SP5 for now. Marcus is working also on the SLES side, the update of package with the new key was released last week, it's just not activated yet, but it will be already trusted by Leap 15.5 systems. Leap 15.4 is working Leap Micro 5.3 is working Leap Micro 5.4 testing is now passing as well Leap 16.0 - we should revisit the update/sle repo as the current setup not exactly mirror friendly. Solutions could be dropping not so popular architectures or split repositories per architecture. securebootkey for SLES was rotated, it should be autotrusted and not noticeable. This will be in QU3, QU2 is already done. lkocman: 15.3 EOL could lead to stopping our physical Source DVD effort, as it seems we will not produce. As this was the last release which you could still get on a physical media. Lkocman: anything against decomissioning it? Not a single valid request since I've joined SUSE. We did receive only requests for binary install media which are not subject to ^. We do not plan to offer this for any new releases. ## Adrian - OBS DimStar pointed Adrian to issue handled by Marco - unresolvables due to python3.8 drop. So far it seems like a scheduler issue. Just wait for fix, local builds are not affected. ## Open Floor metrics-o-o https://metrics.opensuse.org/ https://github.com/openSUSE/openSUSE-release-tools/tree/master/metrics/acces... Bernhard provided couple of samples and it appears, that quite some traffic is taken with a single entity using 500+ Leap 15.4 containers/day. Most of these seem to live just for a few minutes. Intention is to collect more detailed information what kind of usage do we see. Also storing GEO location would be good.