Portal:15.3/Retrospective

Welcome to the openSUSE Leap 15.3 retrospective.

Survey at https://survey.opensuse.org was opened since 1st June and closed on 16.06.2021 06:30am.

We've received 605 responses (compared to 409 in Leap 15.2) that is almost 200 more!

Raw data can be already found here File:Results-leap153retro.ods. Raw data can be useful in case that user makes cross reference in between what went well and what didn't go well. This information would be otherwise lost once we start categorizing feedback items. Following document which will be used in review rounds https://etherpad.opensuse.org/p/ReleaseEngineering-Leap-15.3-retro-20200616 It's also useful as reference, in case that some information got lost during categorization.

This wiki page will then be an archive of the retro result just like in 15.2.

Summary

Yast and installer appreciation. Improved performance on Desktop. Improved availability on mirrors. A lot of trouble with zypper patch (SLE part), we need to document the entire new maintenance setup bit more as it's difficult to understand. Great Virtualbox experience. KDE connect issues. Xfce install option appraisal. A lot of complaints regarding software versions of specific software, exceptions are glibc, systemd, flatpak. non-Public bug reports, uneasy to contribute to SLE. Leap containers could get some more love. Too enterprise-y release notes. Marketing seems to be performing well in inner circles of the openSUSE project, but not so much outside. WE have to improve the documentation of kernel backports. Partial translations.

What went well

Comparison with other distros

• First of all: i uses SuSE since V5.2 - but in the last decades i switched to debian. Now i switched back again, for these reasons:

a) it is stable and up-to-date (well, compared to debian and its derivates) b) i use it as productivity system (office, developement, graphics). Therefore i do not want any rolling releases. c) i really appreciate the possibility to define NFS-Shares during installation process. This is really great feedback and it generally helps us to understand our userbase. Thank you for this! Action item: send kudos to Yast team for the nfs-share feature in installer. One of the reason why person is us and not Debian!

Retro specific feedback

• We have an internal instance of retrospected, would we like to use it in the future? http://retrospected.core.qa.suse.de:8080/

TODO: Lubos to check retrospected is it opensource, would it work with our anonymous survey as input?

Generic feedback

• I was running the 15.3 release since the day it was released for testing. I honestly cannot think of anything that didn't go well. Well, for the end-user like myself, anyway.

• So far no negative points or concerns, just taking advantage of this operating system, congratulations for the excellent work.

• Everything has been MUCH better than I was expecting.

• Everything worked perfectly.

• No problem occured.

• I have nothing to complain about, amazing. I've been using openSUSE since version 10.

• There are probably tons of things whch could have gone wrong and which did not, so thank you very much for your hard work and this great distribution.

lkocman: :-) Thank you, it cheered the review group.

• Extremely stable release. I've been using it since April when it was still in Beta phase.

• Happy to see a new release!

• overall i like it

• Also I did a complete reinstall after the release and have not run into any new issues

• I've had one issue during the beta test which was fixed already in the RC.

• To me, openSUSE Leap 15.3 seems very polished and stable. I have not used it for quite a while and I am glad to see, that it is still the same polished experience.

• Yes, almost everyhing went well.

• It seems polished and snappy

• Everything worked up front. No issues.

• Good as usual.I'm glad that my wifi works with this release. I did not feel any thing so new or good to be exceptionally well done

Closing the Leap Gap specific feedback

• Submissions to SLE are now possible!

TODO: make these less painful

• Another solid release with basics well-tested and reliable thanks to Jump/SLE, OBS, and openQA. Good amount of positive buzz and marketing.

• Related to the CLTG activity in this release read this as: well done!

• Given the huge change we have taken it went relatively smooth

• Excellent job, BTW, from what I've seen on the ML/IRC, this all Jump project was PITA to pull off, but you did it, congrats to all people involved.

• opensuse is for me one of the most solid and secure distributions and now more since it shares code with the enterprise version of Suse

Action item: kudos to SLE product management?

• I have to admit I was surprised how well the switch to binary kernel packages shared with SLE15-SP3 went (except for the issues with out of tree modules signing). I may be pessimistic but I expected more problems and harder transition.

• Even with all the vendor change to SUSE LLC, and all the packages that required reinstallation, everything except what I reported below worked just fine. Keep in mind I upgraded from Leap 15.2 to 15.3 during the release

• I feel the implementation of Closing The Leap Gap and armv7 effort made some of the internal issues more visible which is a good thing. Many issues related to implementation were probably not expected by SUSE. Long release cycle with deadlines rather early, package rebuildability in old SPs, enforced maintainer.

• Seems like pace of implementation of community features will result into lots of exceptions for which we should rather create rules.

• In overall I think this project got quite resource expensive for example the need for Step and front-runner the Maintenance setup, while SUSE expected perhaps otherwise.

Action item: send kudos to the kernel team for great job on the Leap -> SLE kernel switch

Distribution freshness

• Big plus for updated glibc, systemd, Flatpak and other components critical for 3rd party software usage

Performance related

• The main difference, apart from the repositories, is - that everything's faster!
• 15.3 installation solved a weird VNC performance issue I had with 15.2

TODO: Talk to kernel that people are mentioning more responsive desktop experience.

Hardware Enablement

• Dual monitors works perfect. Ubuntu did not

Roadmap

• Release was in time, the Release Party in the openSUSE Bar was really cool,

Action item: send kudos to Marketing team for organizing the release party in /bar

• As per tradition, isos were available timely and installer was working perfectly.
• The release is on time as always.
• Given all the changes behind the scenes that were necessary for using the SLE packages, everything went surprisingly smooth :-)
• The repos were available in time
• The project handling really dynamic, up to the point and successful. All issues were immediately addressed.

• Everything worked well a Stable 18 months OpenSUSE Release In contrast to RedHat you recommend people to use your community version. Great!

Action item: send kudos to both SUSE and openSUSE marketing team as well as SUSE and Rancher community for advertising and recommending Leap

• Actually the milestones beta/rc/ga where reached before the dates indicated in the project plan. That was a positive change to some releases in that past, that were delayed.

lkocman: Thank you. What I'm thinking is tracking only the code submission deadlines and not the build availability, which in general is easier to meet. The product build itself can range from hours to several days. <break June 22nd 10:00am>

Social

• Introduction of /bar is nice during COVID!

Action item: Send Kudos to Gertjan and Maurizio :D # we need to create /bar themed recognitions Gertjan: we (m4u and me) want /bar founder tshirts! Lubos: we'll look into it.

Window / Desktop managers

• I've been pleasantly surprised by Xfce being updated to 4.16 and the availability of Cinnamon - I went with Plasma, maybe I'll switch to Xfce later on.

TODO: Kudos to Xfce team, and Cinnamon

Xfce

• I really like the inclusion of xfce DE.

Action item: Kudos to Xfce team for pushing on inclusion of the DE as an option in installer

KDE/Qt

• KDE Plasma is looking more elegant than ever
• Nice to see some old kde4 packages being removed.

TODO: KUDOS to KDE team TODO: Talk to kernel that people are mentioning more responsive desktop experience.

Budgie

• Budgie Desktop looks and works great without the need of any tinkering. Plus Flatpaks worked right out of the box, again without having to do any hacks. I had problems in 15.2, in non-KDE DEs getting Flatpaks to work.

Action item: kudos to people behind flatpack Action item: kudos to Budgie Desktop. Action item: we do plan all DM/WM refresh perhaps Budgie desktop should be in sync with others https://en.opensuse.org/Feature_Planning_15.4

Installation experience

• Easily install wine

• After RE - installing it worked well, but see "4" below. It took many attempts to get it right.

• Well I'm suspicious to say because I like openSUSE a lot, I've been using it for 6 years without problems, with Leap 15.3 it was no different, the system is perfect, I did a clean installation and everything went well.

• Leap worked out of the box on my unusual piece of hardware. a repurposed chromebook.

• Installation from usb stick was as painless and quick as usual. I installed on a Lenovo Thinkcentre 93p first, but will follow through on my various server, desktop and laptop machines.

• I reinstalled Leap on the release date with KDE from the 15.3 RC ISO (didn't want to download a new ISO). The installation included the online repositories and installed the system flawlessly. Obviously all the latest files were downloaded cleanly (just over 4 GiB). Copied various config files from my old installation and it just ran.

• 5 installs to different hardware, all fantastically problem free.

• Network installation working perfectly, as usual

• Worked like a charm. Took only few minutes and everything was running as expected!

Action item: we want to make this even shorter. E.g. boot of install media compared to competition is 30 seconds longer. Feature is already opened for it.

• Feels like a stable distribution: installation worked without issues. Hardware detection worked. No problems so far.
• Installation is great and easy!!! Good work, love leap 15.3!!!

• I didn’t upgrade but, rather, did a clean install of Leap 15.3. The process was smooth and polished and resulted in no errors or failures.

• Downloading and installation went smooth as usual, like in prevoius versions.

• Provided workaround for downloading iso from get.opensuse.org via Chrome

Virtualbox

• Good integration with Virtualbox, better than in previous version. It is good for users considering switch or reviewers - both groups usually tests distribution in Virtualbox first.

TODO: Kudos to wine maintainer TODO: Kudos to Virtualbox maintainer. TODO: This release had one challenge with openSUSE KMPs, so I'm really happy that we hear about positive experience. Kudos to people who worked on openSUSE-signkey-cert

Yast/Installer specific

• Yast team was always super responsive.
• Almost translated installer
• clever disk partitioner in installer
• guided installing to disk. no major changes with installer probably a good thing

Action item: share with yast team that people appreciate the guided disk setup

• repository filter in yast software
• boot linux system easily by linuxrc in installer media
• download packages while installing
• i really appreciate the possibility to define NFS-Shares during installation process.

TODO send kudos to Yast team for the nfs-share feature in installer. One of the reason why person is us and not Debian! TODO: send kudos to Yast team TODO: Send further kudos to Yast team for the partitioner and repository filter, and one-click (partitioner was also highlighted in 15.2)

Zypper specific

• Thanks to zypper team for fixing a lot of last minute issues.
• install updates by one-click in taskbar
• upgrading was easy (zypper dup --releasever is awesome)

TODO: send kudos to libzypp team

Upgrade Experience

• Updated a Dell server with RAID disks in less than 2 hours using zypper dup without any glitch. Only had to remove some packages that I don't use and got reinstalled with the update, like the firewall or NetworkManager.

• Offline upgrade, it's quick and worked flawlessly for us.

• Live upgrade with zypper (was supper :-)) went well

• I used the offline upgrade process and everything went perfect. I have a stock Lenovo Laptop e585 (which technically does not support Linux)

• Upgraded from Leap 15.2, everything went very well, no issues, and we up and running as quick as I could download the DVD and have it do it's Upgrade process.

• I did an update from 15.2 and was nervous about all the new repositories...

But the update defied even my talent for making mistakes (as a non-geek). All my apps, all my settings, all my connections... everything booted up perfectly.

The main difference, apart from the repositories, is - that everything's faster! Action item: KUDOS to KDE team Action item: Talk to kernel that people are mentioning more responsive desktop experience.

• Everything went well regarding the update.

• switched repos from 15.2 to 15.3 and followed the instructions for zypper commands. All went well, no problems.

• Overall the update of the released distribution went very well, as usual.

• Overall very satisfying, with the application update to the latest version.

• I have very old hardware Dell Inspiron 1525 which had Leap 15.2 installed and the upgrade to Leap 15.3 via external USB and choosing upgrade went very smoothly. The NET image was available just a few hours after launch when I tried and I had no hiccups during the download of packages here in India. All in all this method worked well for me.

• In general was a smooth upgrade without a major breakage.
• Update from 15.2 went well, current XFCE 4.16 desktop. System works well on installed machines.
• Positive experience with migration from the previous release.
• The live update did work flawlessly.
• Upgrade from openSUSE Leap 15.2 without any issues.
• I performed both a fresh installation and an upgrade. Both went smoothly. I experienced no hardware compatibility problems.

• Upgrade 15.1 -> 15.3 flawless. Same for 15.2 -> 15.3

• I am happy that the need to have an up-to-date Leap 15.2 installation prior to upgrading to Leap 15.3 was communicated clearly and in advance.

• 1 - I was surprised to update the system with the zypper dup command.
• 2 - the ${releasever} feature in repo file is very good
• 3 Cloud performance was very good in the new generations of AWS machines, below the link of the image I compiled. http://aws.amazon.com/marketplace/pp/B09776BCKK

Action item: kudos to software-stack / libzypp team for the zypper dup/$releasever appreciation Action item: send kudos to the cloud team specifically AWS

• The update was fine for most experienced users.

• Did a "zypper --releasever 15.3" dup upgarde of an old 10 year old dual boot laptop that was running Leap 15.2. The upgrade managed all configs so that after the first reboot all hardware components were working as before.

• Upgrade from 15.1 worked.

lkocman: Thank you, we'll definitely keep this in openQA

• Update via zypper dup was ok.

• I updated my server in production during the release party and went incredibly smooth. Got a few `NOKEY` warns, but other than that it was super smooth.

• I host a personal server at my home, connected with fiber link. I build this server 4 month ago with 15.3, expecting it was already ready. I was not disappointed, it works since very well, with a zypper dup from time to time. I may make a last zypper dup soon, I just wait to the dl server to be uptodate and not too busy :-).

So the preliminary stages went specially well, congratulations :-)

lkocman: The libzypp udpate TBD bug id supports getting of gpg-keys from repodata/gpg-* (also in release notes section "Seamless upgrade").

• I've been testing 15.3 since it entered alpha, on a few virtual machines and old netbook (15.1 -> 15.3 upgrade went smoothly on that one, BTW), so I expected the smooth upgrade on my desktop, and indeed it was.

• It was a very easy process to upgrade to 15.3. So far, it has been smooth and nothing glaringly obvious is broken which is encouraging.

• I didn’t do an upgrade but a new install over 15.2, just in case. Still, it was painless and smooth. The stability of the distro shows in not surprising the user unnecessarily.

Thank you, we try to profile as a stable distribution.

• The upgrade from 15.2 went fine! I upgraded from 15.2,with no big issues.

• Docu https://en.opensuse.org/SDB:System_upgrade is very good

• Upgrading with zypper -releasever=15.3 dup was very easy, much better than in previous versions.

• All repositories were ready in time for the new 15.3 release. I even did the upgrade hours before the official release and had no problems at all and I didn't have to disable non-core distribution repositories either.

• Upgrading was easy.

The upgrade process from 15.2 to 15.3 went smoothly.

• The documentation concerning migration from 15.2 was very good, and on a technical level, the upgrade process ran through without any major error.

• The upgrade process went well and without problems.

• Online update from 15.2 went smoothly. No major hiccups at all! This is quite a difference compared to other distros I've used.

• The zypper dup was seamless. Not a single file conflict or other hiccup. I started the upgrade before I went to bed and found the machine waiting for theast reboot inthe morning. Logged in and started working remotely through vpn as if I had not disconnected. Documentation for upgrading was spot on but if I was not already versed in the subject some wording might have left me stumped.

• I just used the commands from the wiki page and suddenly my system was upgraded.

• I use an encrypted system with an encrypted root and the update worked extremely seamless after the reboot.

Upgrade with packman

• Upgrading from 15.2 to 15.3 with Packman enabled worked well. I was surprised that it installed the VirtualBox drivers for me automatically.

Action item: same as 124 send kudos to Virtual box maintainer

Heroes / Infra / Autobuild

• Signing of images improved compared to 15. Torrents were flawless. Minimum issues with mirrors.

Thank you. This is because of not hiding the GM image. Again decision from 15.2 retro

• Infra running on Leap 15.3 prior release!

Action item: Send Kudos to autobuild and heroes

Marketing

• Leap beta, release candidate and release were properly mentioned in media, hopefully increasing user count in future

• https://forums.opensuse.org/showthread.php/554703-Testing-a-new-distribution-The-same-procedure-as-everytime

• Communication was good; however I am tapped into all OpenSUSE channels so this makes sense.

• I think communication and availability of software went very well.

• The release seemed to go smoothly and was well communicated.

• As for other positive things, I think there was a little more buzz about 15.3 release then 15.2, thou I was a bit surprised that Mr. Kocman or some other member of the release team didn't give a interview to, say, Destination Linux podcast, or Wendell (from Level1tech/level1linux) YT channel.

Dr.Pfeifer did an excellent job in his DLN interview, but that was a while back. Action item: Podcast about the release?

• Big thanks to Doug for driving Websprints and Marketing meetings
• Marketing team did amazing job on release announcement

TODO: send kudos to Websprint

TODO: send big kudos to Marketing team and specifically Doug TODO: Bill wanted to do podcasts TODO: Send recognition email to Gerald (= Dr. Pfeifer) Gerald: Everyone please spread the news, there are no limits in who can "advertise" openSUSE, totally do podcasts,... TODO: Kudos to Marketing TODO: Revisit the forum post, and perhaps do a bit more advertisement for such "Howto" in 15.4. Definitely keep doing this (entry in forum).

Availability

• Downloads were fast and the image worked well on older hardware.
• The release was readily available.
• It's already on the nearest mirror around me, including iso and repositories.
• The availability of the images and repositories days before the official release was very positive! Suddenly (last seen during the 42.x releases) the majority of mirror servers offered the Leap 15.3 images and repository - which made the migration very smooth and fast. Thank you!

lkocman: Thank you! This is what makes our retrospectives useful, it was listed as a pain point on 15.2 Retro and we decided to fix it by not hiding GM any more.

TODO: Send kudos to Lubos (for doing retros)!+1 TODO: I think the person who made that proposal was either Bernhard or Adrian. we should send them explicit KUDOS for this.

Hardware Enablement

• Thunderbolt 4 did not fully work for version 15.2; in 15.3, I have full Thunderbolt 4 support.

TODO: send kudos to kernel team for Thunderbolt 4 support.

• Most things, especially the official aarch64 support.

TODO: send big thanks to Guillaume and also owners of all non-SUSE components in bugzilla-o-o

What didn't go well

Availability

• Leap containers could use more attention

• Somewhat confusing as to exactly when 15.3 was released and where the images were downloadable from. For a time after release it seemed that it was only 15.2 was available from https://get.opensuse.org/leap/

• it would be nice to get a notification when a new release is out (or even after the teething troubles are sorted out), similar to the welcome screen after the installation. Useful information the notification could show would be the EOL of the currently installed release. Ideally, the notification would be configurable as to whether the notification should reappear every day / week / … or not until some fixed time before the EOL of the current release.

TODO: create feature for new release notification, perhaps with 2 weeks delay so the initial issues are fixed. Suggestion: Maybe an EOL notification can pop up 1-4 weeks before the release is EOL with a button to update that pops up a window to put in your root password and then zypper or Yast runs to update in the background and tells you to reboot into the new release when its done RHEL was using the redhat-release update to state how many months are left until the project/product is EOL. We could do the same Action item: talk to maintenance team about EOL notification to the system. Perhaps we already have something but it's not super visible to the user.

• Downloading iso from get.opensuse.org is still unresolved (I suppose chromium).

• Package search page at https://search.opensuse.org/packages/ currently doesn't show Leap 15.3.
• Software search not yet up to date in the "Expert Download" Area (does not have links for the repos for 15.3. Still looking for a veiw community builds (most notably x2goserver and arduino)

Thank you for raising this, we'll try to fix this with https://github.com/openSUSE/software-o-o/issues/1033 We'll open a survey today to vote for "new reference for these repositories".

• The release on get-o-o was a bit slow and the updates on en-o-o could've have made it a little faster.
• The first time I visited the download website after release, the website still referenced 15.3 RC. (o-o related)
• get.opensuse.org/leap shown that 15.3 still RC when release news published, main option still on 15.2.

lkocman: My bad, we've switch from software-o-o to get-o-o and not all tasks in progress-opensuse-org reflected it. there were some additional changes needed. TODO: ensure that all get-o-o are in openSUSE-release-process and are reviewed by websprints team prior GA. TODO: look into an option to maintain the source of truth in a single place (specifically the release date, and current milestone (Alpha, Beta, RC, GM, GA). This would eliminate about 5 GA day tasks. E.g. in RHEL/Fedora it used to PDC https://pdc.fedoraproject.org.

• During transition from RC content of https://get.opensuse.org/leap/ was out of sync: stale links ...

lkocman: Yes the rename of images caused that -current links were removed. Lubos had to manually re-create these links. We have agreed to use links for the entire development + GA phase in Leap 15.2 retrospective, but they have to be recreated in some point in time during GA. Ideally the rename + sign of images would be scripted and also would ensure that links exist. In this way we would not loose -current symlinks at all.

• During the first days/weeks of a new release I think it is not wise to have beginners start with 15.3, first let's have more experienced users make the switch and have most "first week problems" ironed out. Beginners come in via https://www.opensuse.org/ and there only 15.3 can be found. For the first weeks the website should list both 15.2 and 15.3 with the notice that 15.3 is new and 15.2 is proven, but currently 15.2 can not even be found starting from https://www.opensuse.org/

m4u: I think that this would confuse users. lkocman: I feel that users who download Leap during these weeks, did actually visit the site to try Leap 15.3. And you can't really stop people from doing zypper dup --releasever 15.3 I think that the idea is to do better job at testing maintenance setup in 15.4. However we do not expect same magnitude of issues, as we've fully reworked the maintenance setup in 15.3 and the plan is not to change it (unless we could simplify it).

New reposistory layout

• Suddenly there are repositories added without explanation. At least one of them is not trusted as well?!?

As mentioned above we did document this only in Release Notes. https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#installation-new-update-repos. This should have been ideally on the wiki and release notes should just point to it. We'll rework the docs for this.

• The additional SLE and Backports repositories that suddenly popped up after the migration from 15.2 without prior notice. This was very unexpected and let some alarm bells ring (a la. did someone break into the systems and added 'his' repositories?). The additional repositories and key also required quite some work (accepting the additional signing key for openSUSE:Backports was not known in the dup'ed system before, which is not very nice if you have to accept/import the key on >50 machines) and adjustments in our Ansible and Salt management. I'm still not sure if we hit all occurrences (golden image builds for example), yet, so this was not a nice move.

We hear you, most of release team including me was unaware that we have separate update repositories. So we're really sorry for post-GM addition. The idea was not to create a financial damage to opensourcepress.At the time when we found the issue we had already placed an order to burn a lot of Leap 15.3 DVDs.

• During the development phase the online repositories became available very late, for some snapshots not at all. Therefore online update tests (zypper dup) from a running Leap 15.2 system were possible only very late. Problems related to the package signing keys could have been found earlier. I assume this keys-problem is a one time problem related to CLTG with Leap 15.3 and will not happen again in a similar manner for Leap 15.4. Still early testing may find other problems the next time and should be possible and encouraged. Additional update repositories (sle, backports) then additionally got available very late and this again resulted in last minute activity to integrate them and then some more problems by different post "zypper dup" update actions ("zypper patch", "you").

online update repos: yes this was a big problem, and I also see it as one-time effort/pain, unless we'll again revisit the maintenance layout. This should have been better tested ahead. I fully agree. We do not expect to hit this kind of issues in remaining Leap-15 codebase.

• The setup of the update repositories seems to be broken? What is "backports"? Why is the signing key unknown? Why does the updater want to de-install most of my packages? Why are updates from 2017(!) in the update/leap/sle repo? I tried to get some information in the forum and wiki - but it looks like nobody has an idea???

lkocman: We hear you we work on making this easier. You will be able to vote for the new terminology on survey.opensuse.org next week (early input for survey can be already found here https://pad.riseup.net/p/shared-codestream-poll See more details at https://lists.opensuse.org/archives/list/project@lists.opensuse.org/thread/RIUQNUEQ2SQ2UT4Q3RIJVHISUY3IAJGV/

About updates from 2017, we use aggregated repo with all SLE updates and there is a big chance that the package was not rebuilt unless this package got submit request. This is really how SLE is put together. On the other hand maintenance team is reworking publishing strategy as we speak. <break June 24th 18:00>

• A lot of people seem to have problems with the repository (seen that on Reddit and the Forums)

• repo mgmt feels complicated. Is there a "your repo setup should look like this after the update"?

We hear you, I did try to document this change in https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#installation-new-update-repos however the plan is to move it to wiki (There is already action item for this on line 546).

• Delivery of updates seems to have been not thought through, i.e. new update channels (repo-backports-update, repo-sle-update) were introduced *after* the release in a way that was indistinguishable from an MITM attack. To be clear: Introducing new update channels is okay (even though I sort of dislike changing such fundamental parts on such short notice).

• On upgraded systems it added the SLE updates repo twice, as I had already added it in preparation for the upgrade. - I incorrectly assumed the repo priority of the SLE updates repo should be higher, so I put it at 97 and upgraded. But that made it install a bunch of old packages from the SLE SP1 release. Fortunately the system still booted and I realized my mistake. It seems that old SLE service packs shouldn't be available, only the latest one.

• The repositories required are not fully defined in the wiki. Write the full URLs of the repositories in the Wiki

TODO: document this ASAP. We do have them in Release notes, so probably just copy and paste, perhaps even reference https://github.com/openSUSE/download.o.o/tree/master/YaST/Repos and 000product/Leap.prod same for skelcd-openSUSE in the wiki. Let's not duplicate information if possible.

Torrents

• I am trying to download and share using this torrent https://download.opensuse.org/distribution/leap/15.3/appliances/iso/openSUSE-Leap-15.3-KDE-Live-x86_64-Media.iso.torrent but I get an error saying that torrent is not available on tracker

TODO: let's review with what went wrong with Bernhard. Otherwise I had feeling like we did a better job on torrents than in 15.2 as the data was available

• I was disappointed that on release day there were no torrents available via https://download.opensuse.org/distribution. For several years I have always shared the release via torrents through my system to support openSUSE in its development

software-o-o

software shop not as good as ubuntu. Action item: can we improve software shop (I suppose software-o-o) in 15.4?

• software.o-o does not show all packages for 15.3

lkocman: we know about software-o-o https://github.com/openSUSE/software-o-o/issues/1033

Marketing

• In recent years I have seen that there is little information and few articles on new developments in distribution. As of today, there is still little material to be found that is complementary to the official announcement on news.opensuse.org. I think it is good to do more publicity to get noticed in the news media.

Action items: write some easy to understand page for the new Leap building process, perhaps attach slides from conferences as well. Something that we could reference in articles. https://en.opensuse.org/Portal:Jump this has too much information.

• I knew it was coming up but my social media did not mention it until a few days later Normally Imwould be aware of the exact day.

The feedback that we received is that the the release annoucement was very visible internally, however not so much outside of the community. Question: could you please share the country where you live? We could perhaps add action item to give some local magazine a heads up.

• it's strange that the color is yellow https://get.opensuse.org/leap/ Should be back to greeeeeeennnnnn!!!!

42.3 had light yellow/green DVD cover. We will discuss some box color strategy with marketing@opensuse.org We could create a plan to draw flags/pride flags/various gradients logo as the boxes are usually lined up in the line. It would look really cool on the shelve.

suggestion: make or use color from design system (https://opensuse.herokuapp.com/colors) or improve the design system

• Some key features should be announced on the main opensuse Leap page - Took me unnecessary' long to find the release notes from there.

TODO: make sure that release notes are linked from get-o-o and main page. The same for perhaps delayed availability of images. The point is not to duplicate information but reference pointer the the source.

• (Originally tracked in what went well) As to the marketing and communication, I don't think that it reached outside the circle of people that use suse and follow it's development. So if the point was to tell users that they can update, the point was met. However if the point was also to gain new users or an attention from people who don't use suse, I'm not sure if that went well.

TODO: Share this feeedback with marketing team. This was not a feature release, so we didn't have any big teasers aside from updated drivers, sle binary usage, and glibc. 15.4 should be really attractive for people who want to have a stable but up2date distribution (big refresh is happening) https://build.opensuse.org/project/monitor/openSUSE:Backports:SLE-15-SP4:FactoryCandidates

• Scheduling the OpenSUSE Conference the same time as the KDE Conference https://akademy.kde.org/2021 :(

Hardware Enablement

• One minor issue with a Lenovo laptop, install did not pick up the wireless card, Intel Corporation Dual Band Wireless-AC 3165 Plus Bluetooth (rev 99) however the device was available after install. Had to install with ethernet cable.

• One Asus laptop has an unsupported wifi chip. But Ethernet is working.

Question: could you please open a bug or share details about your hw? There is no much that we could do about it with given information. Thank you

• I have a laptop with a Broadcom bcm WiFi card. I had to search for the broadcom-wl driver and install it manually. (packman?)

• mute led in keyboard isn't working

• no availability of QLC+ for 15.3 yet, so installed the version for 15.2. That worked well, apart from the fact that an early version of libusb required for USB-->DMX controller wasn't added automatically, so my adaptor wasn't enabled. It was fine after I identified the problem and installed i the extra library through YaST.

• The installer did not recognize my internal ssd and could not install. My device is an Acer Aspire 5 A515-56-56DJ.

Action item: Please report a bug, otherwise we'll do it for you once we're done with retro and you might not be in the feedback loop.

Kernel

• Kernel in Leap 15.3 is not properly described. For most users it looks outdated, because there is no proper mentions in Release notes or on wiki with feature list about backported features. Will be good to write there, that kernel contains new graphics, sound and wifi drivers from kernel 5.9 (or whichever kernel drivers are used) - otherwise we are loosing some users just from reading about old kernel. And it is hard to buy new HW and checking for linux suppport, if I don't know, which HW support I really have.

TODO: marketing let's add reference to backported graphics drivers etc in our Features page.

Attila: consider adding kernel summary to RN about what was backported. Consider adding some graphics. We could also release a news-o-o blog post which would contain release notes highlight, also would contain summary of kernel changes/backported drivers and of course link to release notes.

TODO: Talk to marketing how could we make a list of backported features. We could perhaps utilize the code-o-o/leap/features or https://en.opensuse.org/index.php?title=Feature_Planning_15.4

• I hate the fact that you aren't using the Linux-libre kernel

• It would be IMHO worth it to take a closer look into why the issues with out of tree modules signing were found so late. Not in the sense of finger pointing, rather identifying what the blind spot was/is so that we can catch similar problems earlier next time.

Action item: talk to kernel team about out-of-tree modules. We recieved a lot of good feedback for Virtualbox, but I think packman/video 4 linux / OBS is a different story.

• after release Preempt voluntary is disabled by default. It should be as default parameter if desktop is installed.

lkocman: Prempt-voluntary change was documented https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#sec-upgrade-kernel. We did look into preempt voluntary to be the default for SLED and Leap (internal issue PM-2156), in the end we have decided to go different route. On the other hand we have several reports of improved performance/responsiveness compared to 15.1. Kernel team seems to be really happy with the current situation.

Nvidia

• Situations in which the upgrade process encounters a "merge conflict" between local modifications to a configuration file and package-induced modifications, which results in the creation of an "rpmnew" file, should probably be outlined more clearly via a consolidated summary of configuration changes that require manual review at the end of the "zypper dup" output. Going through the long zypper dup log looking for individual lines about the creation of rpmnew files is error-prone. I encountered an "interesting" conflict between NVidia's driver and CUDA repos, where the newest version of the driver (by driver version) that was provided by the CUDA repo was not built for the proper kernel. Zypper dup decided to switch to it nonetheless, which obviously caused GPU problems. I think it should somehow be possible for zypper/rpm to detect this kernel version conflict and refuse to install the driver package for the wrong kernel even if its version number is newer than that for the right kernel. But the lack of such conflict detection may emerge from a packaging error on Nvidia's side rather than a technical limitation of zypper/rpm. In any case, for those using NVidia hardware, the best workaround is probably to decrease the priority of the CUDA repo.

Action item: talk to nvidia maintainer about proposal for handling of nvidia conflicts including the cude repo priority suggesttion.

• after upgrade system couldn't boot into graphical mode because of nvidia drivers(i think), after running yast2 in text mode and adding repos and installing proprietary drivers everything went back to normal... i think in this case openSuse should've NICELY went back to the opensource noavou drivers automatically...

TODO: share feedback about nvidia proprietary installation with maintainer

• Start of final-version 15.3 doesn`t work at final version. It stops at login(maybe is nvidia graphic-card the problem) I must start leap 15.3 with kernel version 5.3.18-lp152.75-default

lkocman: please open a bug, specify hardware and we'll look into it. See https://en.opensuse.org/openSUSE:Submitting_bug_reports the information about kernel would be useful. I suppose that your system doesn't have enabled a repo with newer version of the kmod.

• a me personalmente e' piaciuto moltissimo Tumbleweed , tuttavia riscontro problemi con l'installazione dei drivers nvidia, non sono riuscito a farli funzionare correttamente, dopo aver correttamente installato il repository nvidia ti propone come pacchetto il G5 , ho provato piu' volte ma niente da fare l' OS riconosce la scheda video ma poi anziche' proporti i driver 460 ti propone tutt'altro e cosi non puo' funzionare, poi c'e' qualcosa che non va anche col riconoscimento della scheda rete e questo limita lo scaricamento di non so cosa per far funzionare correttamente tutto il sistema degli aggiornamenti, questo e' quanto sono riuscito a constatare, ah poi ho trovato in rete un aggiornamento che propone aggiunta di codec mancanti pero' installa codec piu' recenti di altre firme e restano installati in conflitto anche quelli installati di default, insomma avete imput per correggere un po di cose, se si riesce a sistemarle per me e' una distro superlativa, completa e affascinante, non mi ha fatto lo stesso effetto la Leap15.3 sembra un'altro mondo completamente diverso e comunque ha gli stessi identici problemi della Tumleweed, cordiali saluti e in bocca al lupo per la riuscita

gtranslated variant: I personally liked Tumbleweed very much, however I have problems with the installation of the nvidia drivers, I could not get them to work correctly, after having correctly installed the repository nvidia offers you the G5 as a package, I have tried several times but nothing to making the OS recognizes the video card but then instead of proposing the 460 drivers it offers you something else and so it cannot work, then there is something wrong with the recognition of the network card and this limits the download of non I know what to make the whole system of updates work correctly, this is what I was able to see, ah then I found an update on the net that proposes the addition of missing codecs but installs more recent codecs than other signatures and they remain installed in conflict even those installed by default, in short, you have input to correct a few things, if you can fix them for me it is a superlative, complete and fascinating distro, not it made me the same effect the Leap15.3 seems to be another completely different world and in any case it has the exact same problems as the Tumleweed, best regards and good luck for the success

Question: Please report a bug for your nvidia issue on TW, we'll need some more details from you otherwise we can't really help you. Same for codecs , please report a bug there as well, also please mention what repository are you using (I suppose packaman). https://en.opensuse.org/openSUSE:Submitting_bug_reports

• Runs terribly on my two nVidia NVS315s using the included drivers. Installing proprietary drivers from repos breaks the entire plasma environment. Tried both versions G04 and G05. Gave up and ended up just living with it being choppy and poorly rendered.

Action item: lkocman to talk to the nvidia maintainer. meanwhile Please open a bug for it https://en.opensuse.org/openSUSE:Submitting_bug_reports

Intel

• Support for Intel HD Graphics 11th gen desktop CPU is not working out of the box. Needed to add i915.force_probe=4c8a to get graphics up and running. Let me add that the system was actually booting without applying the force_probe. But with very low graphics resolution.

TODO: Lubos will open a bug for this behavior and release notes entry to tell people to do so. TODO: Collaboration with peeps from Tuxedo and test Leap and TW on latest available hw from their collection.

Virtualbox

• With the new version of VirtualBox the VM window stuck allways on 800x600 dpi. This bug is partly solved by Oracle but in Leap 15.3 there is not provided instructions how to overcome it.

• The default Installation option for the Net installer wouldn't work under VirtualBox, it threw a kernel error and failed to boot. I had to use the "Boot Linux system" option (if I remember correctly) to make it boot into the Net installer.

TODO: talk to VirtualBox maintainer and ask him if he could document this "known issue with fixed 800x600 dpi". TODO: share this feedback (net installer doesn't work) with virtualbox maintainer.

Distribution freshness

• wish openconnect had been updated to version 8.x.

TODO: openconnect: Let's have a feature for it in https://en.opensuse.org/Feature_Planning_15.4

• Regression to Leap 15.1 and Leap 15.2 Outdated mesa, again, actually more than in Leap 15.2 . Currently not an issue for me, as an user of NVidia, but considering buy AMD card, that can be issue for me in future.

• Desktop Environments and other Leap-only packages could be a bit more up to date.

• Some packages (e.g. gcc) still haven't been updated to newer major version.

• very bad to see still old version of IDE for developing in python such as spyder3... i think developer TOOLS should get nice updates for each point release to be on the edge of productivity

Regarding old version of IDEs, Leap 15.4 is a feature release, so you can expect refresh of most of components. If you feel something should get updated you can help us to plan the update in https://en.opensuse.org/Feature_Planning_15.4

• The version of Python available in the official repository is outdated. The initial release of Python 3.6 was 5 years ago and its maintenance will be stopped at the end of the year. A more recent Python version is needed.
• Problematic maintenance setup, missing update repos discovered late. Layered (SUMA, ...) product testing did not happen prior GA. * People expeting Leap next. We seem to be bit unpredictable when it comes to release cycle/refresh.

python36 - we can't change it in SLE 15. This was already discussed with python maintainer. Tracked in OPENSUSE jira project under OPENSUSE-41 - Please provide python>=3.8 (Rejected) also at https://en.opensuse.org/Feature_Planning_15.4 we do offer python39 in parallel, if you need any particular library, please reach out to us or use https://en.opensuse.org/Feature_Planning_15.4

• latest manaplus isn't available

• I've been looking thru some projects on OBS that build packages for 15.3, and I see that, for instance, not all postgresql versions are available for it, so postgis package is broken for postgresql11/13 (I think). Dr.Pfefier's idea of having a list of packages that are eligible for updates for every Leap-next is excellent, because something like that would 1. answer the 'should I bother submitting SR for this, or will it be updated by SLE side/kept as it is' 2. be sort of a checklist, so by the early Beta time in the development cycle, release team can see if there is something that they ask the community to do ("there are no pending SR's for these packages, and we would like to update them for the next release. any volunteers? we have cookies" mail to factory/project ML) :)

• More generally some package updates from Factory were missed I think due to confusion about the new process, so some parts of the distro are unnecessarily old. And we can always try to grow our marketing reach, it always seems undersized compared to our amount of users.

lkocman: 15.4 is supposed to be a big refresh. So I think that we don't have to take a big action item for it. Please see https://build.opensuse.org/project/show/openSUSE:Backports:SLE-15-SP4:FactoryCandidates and https://build.opensuse.org/project/show/openSUSE:Backports:SLE-15-SP4:SLECandidates Action item: marketing can we do an ideal FTE for openSUSE marketing team / per userbase? :-) Current downloads can be seen here https://metrics.opensuse.org/d/osrt_access/osrt-access?orgId=1&var-frequency=month&var-product=15.3

• Most of the software is delivered with very old versions without any improvements since past releases. For instance GIMP - the same old version is delivered without any improvement and it is crashing after Ctrl+C very frequently.

Question: Ctrl+c please open a bug for it. I don't really have this experience, so some reproducer would be nice. https://en.opensuse.org/openSUSE:Submitting_bug_reports

• I think that it would be a good idea to switch pulseaudio for pipewire by default.

lkocman: We could consider this, but this would have to be done on SUSE Linux Enterprise side, and this is quite significant change. We can definitely open a request for it https://en.opensuse.org/Feature_Planning_15.4 but I don't have high hopes for 15.X. I suppose the next major version will use piperwire

• Consider additional repositories with up2date software. Perhaps we could communicate something like kernel:HEAD repositories or YaST:HEAD where people can get up2date software for most of the time, this is specifically useful during development phase.

• thought the gnome version could be newer

lkocman: 15.3 was not a feature release (Tick-Tock model), but we'll have latest greatest stable GNOME in 15.4. Stay tuned! Otherwise if you prefer fast-moving and want up2date distribution give a shot to Tumbleweed.

• I was hoping to have a more current version of desktop environments. For example Gnome

lkocman: We do plan to refresh these in 15.4 see https://en.opensuse.org/Feature_Planning_15.4 15.4 is a Feature release (tick-tock model)

• I wish it came with a newer kernel
• Concern is that Leap will have more and more "old" software, f.e. KDE Plasma

lkocman kernel related: We're using kernel from SUSE Linux Enterprise, therefore we're driven by SLE development. You can expect larger updates in 15.4 perhaps including kernel (Tick-Tock model). We did backport a lot of drivers in 15.3, so we do have quite good hardware enablement. lkocman: KDE plasma: https://en.opensuse.org/Feature_Planning_15.4 we do plan to refresh all DM in 15.4

• I'm disappointed about the old kernel, old python3 version and the old Latex version.

lkocman: please share a usecase for a newer latex version (could be as simple as one sentence) and we can get it updated. https://en.opensuse.org/Feature_Planning_15.4

lkocman: Kernel development is now driven by SUSE Linux Enterprise. If you lack some driver or have some issue with hardware. Please let us know, we can backport changes from newer kernel.

lkocman: This is all about communication and sharing use cases. We can't update the entire distribution completely without communicating changes with partners and so on. Significant changes such as gcc update (which we did plan for) are not very typically for a single code stream e.g. Leap 15.X. These typically happen in major version bumps. But still if we plan for it ahead, and it's justified by some usecases we can always try to implement these changes, or backport necessary patches to older versions. See our planning page https://en.opensuse.org/Feature_Planning_15.4

Installation experience

• I did a fresh net install on June 2nd, around 9 p.m. CET: it required 4 tentatives before the installer started working (unavailable media error: oss repo not accessible). I guess it was release day servers overload.

• Nach dem Apgrate und anschließenden hochfahren bleit er beim Starten Localservis hängen After the upgrade and subsequent startup, it gets stuck when starting Localservis

(gtranslated After the upgrade and subsequent startup, it gets stuck when starting Localservis): Question: Please open a bug for the startup issue. This is the first time that I hear about such issue in 15.3 https://en.opensuse.org/openSUSE:Submitting_bug_reports

• After installation I checked for updates and got error messages that 1. a dependency for a file could not be resolved (can't remember which one). 2. no data for NonOSS and NonOSS update repositories could be found, I then replaced the "$_releaseserver" in the URL with "15.3" and it worked No problems so far.

After months there's always troubles with packages (who came from somewhere of /dev/null it seems) Regarding NON-OSS / NON-OSS update, following is the baseurls from Leap 15.3 host, so it seems that there is no typo or anything. I suppose this could have been a mirror issue or somebody republished these repos without my being aware of it (in that case thank you for a quick fix whoever did it).

TODO: repodata validation around Beta, RC timeframe for repos that don't typically get many updates.

• I have to install severely applications again, like opera browser.

• installer should install fcitx
• The hardware detection and driver loading part of the installing took way too long.

• net install take huge time to complete. offline installation is fast

Question: can you please share your locatio

TODO: consider fcitx (input method for X) to be part of patterns

Upgrade experience

• I was not able to complete the upgrade by just changing the repos. The official documentation for this was little more difficult and convoluted to follow. The system ended up still refering to 15.2 and my network was disconnected (no wifi hardware detected) so could not connect and resolve the issue. Had to do a snapper rollback and try the USB upgrade method which worked like a charm.

Action item: we need to make sure that zypper dup or yast upgrade are understood as preferred. https://en.opensuse.org/SDB:System_upgrade still contains information about how you can just bump repository paths and proceed to upgrade. This in general is not recommended nor tested. Ideally we should only recommend what's covered in openqa.

• Migration from Leap 15.2 to Leap15.3 failed!

• Offline upgrade/installation using a bootable medium seems error prone: Even though the ISO's checksum was correct, the offline upgrade failed to verify the integrity of two packages—apparently they were simply missing (gdl-lang and gimp). Fortunately, no critical packages were affected and YaST Software Management was able to install the missing packages after booting into the upgraded system. Note that I was also experiencing these issues when upgrading from Leap 42.3 to Leap 15.1.

TODO: check gimp and gdl-lang integrity issue during upgrade. Thank you for raising your concernsq

zypper patch

• the buggy bash update, and not even being able to shutdown or restart via the GUI and having to hard reset via holding down the power button are all horrible. Though I remain a fan of SUSE, both openSUSE and SUSE Enterprise, I am very disappointed with the issues related to this release.

• I had some weird updates(for zypper, bash and readline) i couldn't install after the upgrade. But waiting solved the problem() they disappeared). Maybe some f*up with my other installed repos. Now everything works fine

• Subsequent to the new installation, I have experienced four update conflict failures. These failures appear to arise because of the presence of the “update repository with updates from SLE 15;” disabling this repo has stopped the offending updates. I can find no clear direction whether the above-mentioned distro must be enabled and, if so, how to resolve the conflict problem. I am a Linux newbie who just uses openSUSE because it’s feature-packed and remarkably stable. I have no desire to spend the time combing through the forums to find an answer that I won’t understand because it’s not written in simple language.

Please enable the SLE repo back. Repositories were announced at https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#installation-new-update-repos Action item: wiki has to be refreshed so it describes the update repos. Ideally we should point release notes entry to wiki and do not duplicate information in RN if it's already in wiki. Action item: issue under the docs: https://github.com/openSUSE/openSUSE-docs-revamped-temp/issues/4 Action item: official blog post describing the maint setup.

• I had some issues with updating some LibreOffice packages

• Just after I finished installing it I already had a dependency conflict on a security update and more other conflicts after that. A regular user wouldn't know what to do in that situation.

• Package manager asked to add a basic update that wanted to uninstall over 2000 files. This is very dangerous.
• errors with regard to the update repositories
• immediately after install, with online repositories enabled, there were a number of updates, including a few which conflicted with just-installed packages.

• There were multiple issues with patches not being applied due to resolution conflicts or patches not being applied correctly as documented in https://bugzilla.opensuse.org/show_bug.cgi?id=1186642 due to the introduction of the SLE 15 repositories. It would have been more appropriate to delay the release until these issues are resolved as the problems were known as of the end of May and are still not fully resolved as of 2021-06-14. (Not even mentioning it in the release notes makes this even worse: Users, myself included, will only find out about this after the upgrade/installation.)

• The patch system was broken due to SLE, and this was a known issue in the release notes. Instead of listing it as a known issue, release should have been delayed until the SLE patches issue was fixed.

• Solid like a rock. Failed with the patch.

• Got heavy problems with an Update for BASH, after Upgrade from Version 15.2 to 15.3. Dependancy- problems with: readline-doc. GUI crashed while trieing to solfe the problem. Some Users had the same problems after a clean install.
• problem after fresh install patch 2021-1200 and 2021-1569 both have conflicts with libreoffice. Will not update

• Issues on release with patch/update repositories have caused a lot of headaches. Perhaps it was not such a good idea to release just after UsrMerge in Tumbleweed which also caused much work for the team.

TODO: synchronize with Dominique TW specifically for release day if there is any fire-fighting going on. Otherwise we have relatively strict and well known schedule.

• Update Konflikte

• is this really the best you can do? how many days since opensuse 15.3 leap has gone public release? how many more days are we gonna wait til fixage of zypper, updates, patches and other upgrade related f*ups?

• THREE FAILED PATCH. patch:SUSE-2021-1602-1.noarch está en conflicto con ruby-solv.x86_64 < 0.7.19-3.37.1 proporcionado por ruby-solv-0.7.19-3.23.1.x86_64. Two more LibreOffice patch failed too.

• it is june 10th 2021, and zypper patch still throws:

 sudo zypper patch
 Loading repository data...
 Reading installed packages...
 Resolving package dependencies...
 4 Problems:
 Problem: the to be installed patch:SUSE-2020-3304-1.noarch conflicts with 'libi2c0.x86_64 < 4.0-4.3.2' provided by the installed libi2c0-4.0-bp153.2.13.x86_64
 Problem: the to be installed patch:SUSE-2021-1499-1.noarch conflicts with 'webkit2gtk-4_0-injected-bundles.x86_64 < 2.32.0-3.74.1' provided by the installed webkit2gtk-4_0-injected-bundles-2.32.0-3.15.1.x86_64
 Problem: the to be installed patch:SUSE-2021-1200-1.noarch conflicts with 'libreoffice-writer-extensions.x86_64 < 7.1.2.2-13.15.1' provided by the installed libreoffice-writer-extensions-7.1.2.2-2.3.x86_64
 Problem: the to be installed patch:SUSE-2021-1569-1.noarch conflicts with 'libreoffice-writer.x86_64 < 7.1.3.2-13.18.3' provided by the installed libreoffice-writer-7.1.2.2-2.3.x86_64

 Problem: the to be installed patch:SUSE-2020-3304-1.noarch conflicts with 'libi2c0.x86_64 < 4.0-4.3.2' provided by the installed libi2c0-4.0-bp153.2.13.x86_64
  Solution 1: Following actions will be done:
  deinstallation of libi2c0-4.0-bp153.2.13.x86_64
  deinstallation of i2c-tools-4.0-bp153.2.13.x86_64
 Solution 2: do not install patch:SUSE-2020-3304-1.noarch

 Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c):

• Did an offline upgrade; the installer didn’t manage to install some packages (six libX packages, I forgot the exact ones) from the SUSE repository but otherwise successfully completed the installation. When starting YaST the first time, it notified about the missing libX-packages and prompted to install them, which it successfully did. Also there seems to be a problem with some libreoffice packages (libreoffice-icon-themes, and libreoffice localisations) being available in a newer version than the main libreoffice package, making them impossible to update.

• The OpenSUSE Leap 15.3 patching and update system is horrible now. The patches require the user to uninstall thousands of installed packages. How is it possible to make this ??? Now since a whole week after the release this strange behavior continues in the same way without any formal announcement or recommendations from you how to deal and overcome this problem. Very repulsive is this for OpenSUSE users. Accordingly, most of them have stopped refreshing their systems or are going to uninstall OpenSUSE 15.3. Please do something about this problem as soon as possible.

• There are some serious problems with post-installation updates. Since updating, I have run into problems on multiple occasions with updates where the "suggested updates", all of them patch:SUSE-..... format cannot be installed due to version conflicts with already installed 15.3 packages.

• SUSE patches do not install while performing YAST online update on openSUSE 15.3 KDE. It also mark several packages as conflict and ask for deletion of those packages.

• Updates seem to have issues with dependencies.

• Probably by now you guys have heard this one thousand times already, but the SUSE Enterprise 15 integration is being a big mess. The updates from that repo make the system unusable. I hope this can be fixed soon, without waiting for Leap 15.4 in a year from now. Now I am going back to 15.2.

• On the project mailing list, this survey has had been linked on june 2nd. today its like almost past june 7th and we still lack full fixed zypper zypp fixage. what gives?????? new era of opensuse quality management? sigh.

• After upgrade to 15.3 from 15.2 there are now numerous package conflicts that are unsolvable. I think that patches packages dependencies are really broken.

• The Upgrade from 15.2 to 15.3 does not work. For each package i get the error message that the package is damaged because of missing Keys. I restored the Backup and use 15.2 the next months. The Keys are there like in the doc described.

lkocman: This issue is really expected to be fixed see https://bugzilla.suse.com/show_bug.cgi?id=1184326 or feel free to re-open it if you think that the issue is not fixed.

• Have a weird minr problem with a patch that the update gui want's to install but can't (readline dependency for recommended bash update), zypper up does not have this issue and does not display this update.

• Update problems with libreoffice packages. Now issues with bash. Guys, you should get your s**t together. This is embarrassing. Now I see why you lost your greatness you once had... openSUSE is in my heart, but as it seems, it will never be on my systems ever again, no matter how hard I try to give you guys a chance every once in a while...

• The update process of the repo packages went fine, but after that, Discover showed me available updates that would have removed critical packages. It happened shortly after the installation of openSUSE. Could be a bug or so.

• on the project mailing list, this survey has had been linked on june 2nd. today its like almost past june 7th and we still lack full fixed zypper zypp fixage. what gives?????? new era of opensuse quality management? sigh.

• patch:SUSE-2021-1526-1.noarch is hell!

• Just installed openSUSE Leap 15.3. Is one of the best distros today. Ten points for me.

Thank you very much, we're really happy to hear that! But I had the same problems with the "readline-doc" in the recommended patchs for BASH and LibreOffice. Since last wednesday I can't solve it. Please openSUSE patch Leap 15.3. PATCH: BASH SUSE-2021-1526 (FAILED: patch:SUSE-2021-1526-1.noarch está en conflicto con readline-doc < 7.0-19.3.1 proporcionado por readline-doc-7.0-17.83.noarch) PATCH LIBREOFFICE KIT: SUSE-2021-1200-1 and PATCH LIBREOFFICE WRITER: SUSE-2021-1569-1

• We're really sorry to hear this otherwise same as bellow

• Post version upgrade, the update/upgrade issues are horrible.

• We're really sorry to hear this otherwise same as bellow

not that much. all sorts of little and larger trouble and stalls and especially unclear security related things such as sking for unknown pgp keys for signatures of packages and zypper wanting to unstall half of the already upgraded system once inside 15.3 what the heck? is this the way you handle the opensuse folks trying to lure them over to SLE? who in their right mind would upgrade to SLE coming from these situations.

• regarding the zypper patch uninstall. That's very unfortunate and I agree that this was so far the biggest pain-point in the release. We've already referenced the issue across multiple retro items: https://bugzilla.opensuse.org/show_bug.cgi?id=1186642 maintenance team is actively working on these.

Action item: in 15.4 we have to check conflicts basically all the time after Beta.

• What we already have in place: Leap 15.3 integration testing done as part of every SLE maintenance update, so I hope this will pay off (Being handled by openSUSE maintenance team).

The only issue I have seen, so far, is that the Online Updates (mainly patches) were giving errors and showing conflicts, to the point where I disabled the Software Update applet, at least until issues are resolved. Have been using "zypper up" to try to get available, workable updates installed. Thank you, this could be also our recommendation I suppose.

• Action item: write summary about the zypper patch situation to factory/project and news-o-o

https://news.opensuse.org/2021/07/19/leap-gains-maintenance-update-improvements/

rpm signing keys

• rpm signing keys - We have a newly implemented behavior in zypper where we reference all gpg-* keys repodata/* as part repomd.xml and if the key is recognized as trusted by zypper, then the gpg-key is automatically imported without prompting user to accept the key that he has never heard off. I suppose you refer to situation prior the libzypp update availability or for the RC phase itself. I have to admit that usage of mixed keys is quite painful.

• The absolute NO-GO is expecting your users to just accept a new cryptographic key w/o any means to actually verify it (also see https://bugzilla.opensuse.org/show_bug.cgi?id=1186593).

TODO: share feedback about implementation of our gpg-key with libzypp team. This issue was found relatively late and the implementation required a lot of interaction with various teams (including security audit).

TODO: gpg keys, repos... See https://en.opensuse.org/Feature_Planning_15.4 OPENSUSE-35 we'd like to improve way of handling / generating repositories so they're not sneaked in by a e.g. release package (solution is a service generated repo list). We could get the repos from e.g. https://api.opensuse.org/public/source/openSUSE:Leap:15.3/000product?view=productrepositories&product=Leap just like SUMA. Specifically for gpg-keys we have finally this in place https://bugzilla.suse.com/show_bug.cgi?id=1184326, this can be also found in release notes.

Disk space / btrfs snapshots

• I had some problems with diskspace when openSuse made a snapshot on btrfs, but the system was always usable and after deleting some snapshots everything was fine and surprisingly the updated system wasn't messed up

• .I did a new install.Re-install (It clears out old rubbish). It worked but the install instructions need MUCH more clarity, to BOTH reformat root"/", mount it, THEN SELECT snapshots in pop up, then select to mount swap and /home or you get mini installation in old root "/" without "/home" being added and without snapshots. 2. This ability to only add snapshots AFTER you select mount "/" is bad it needs it own clear box. The instructions should say snapshots wanted as a BOX on the page, before ticking 'mount'. then if low storage a reply "snapshots not available due storage limits" can be displayed 3. I experimented (with a friend) and found why others missed this 'snapshot' enable process.

• No problems with 15.3 itself but I'd put the upgrade instructions prominently on the download page and add some hints regarding snapper when doing upgrades. In my case snapper reserved ~20 GB during usage of 15.2 and upgrade to 15.3, which would have lead to an no-free-space-on-disk error, if I hadn't deleted the snapshots.

TODO: re-visit https://en.opensuse.org/SDB:System_upgrade supply listed information to the snapper section if any. TODO: some disk-space/snapshots checks prior upgrade

Upgrade with packman

• How online upgrade manages non-offcial openSuse repos. We have several installations and every one of them use different applications from Packman, and we faced some inconsistencies with multimedia libraries (previoulsy installed by "opi").

I have tried to install 15.3 Xfce from the live media using the link on the desktop which opens /usr/sbin/start-install.sh. It fails with Couldn't load plug-in qt. Installing lib-yui-qt-pkg15 solves the issue. Also when you select a lang/keyboard in the first step of the installer, hit next, use online repositories, hit back because you want to change the language/keyboard again, no online repositories are pre-selected in the next step. TODO: please open a bug for opi to require lib-yui-qt-pkg15 m4u: so this is not just a xfce issue? I think this package should maybe be a yast dependency rather than opi? Alternatively can simply add the dependency to the kiwi image file. TODO: open a bug for the yast team that the keyboard exchange during install breaks installation. We already have an action item for packman see line 662

• here were some packman (?) codecs for which dependencies were not available any more. So far everything seems OK, but I'm sure that this will bite me later, when e.g. I suddenly won't be able to call in to a meeting.

• I'm using packman essentials, and there are 15 packages still showing as unable to update. I During package downloads, there were a couple times the mirror stalled, but that's no big deal.

TODO: Let's talk to packman people more often. Seems like we were not really well co-ordinated. Let's talk to them, about what would be their preference. Something like we do for Leap community repos should be sufficient. I'm pretty sure that one of the biggest issues will be the fact that we build Leap in Backports.

zypper

• I had a handfull of software packages which are installed by default uninstalled and set to "tabu - do not install" but these were installed again by the upgrade. Why can't the upgrade process respect these settings like "not installed and blocked: do nothing" - if a package is installed and blocked for update, it's a different story. The packages are going to be deinstalled and blocked right away anyway, because they are not needed/wanted on the system. It's an unnecessary annoyance for the user.

TODO : improve upgrade process for zypper and yast upgrade do not update/upgrade packages which are not installed and explicitly blocked. Do it prior 26th June.

• The where a lot of unneeded packages left behind that I had to remove via YaST using the unneeded packages package classification. I did see during zypper dup there where packages removed but there were lots left after the upgrade the zypper might be able to pick up on during upgrade.

Action item: unneeded packages. Do we want to revisit the auto-cleanup after migration?

Docs

• (continuation of sentence of what did go well) Upgrade instructions could be summerised as it did seem a bit overwhelming reading the whole page when it actually was easy and boiled down to a few commands.

lkocman: I agree and sorry for that. I tried to summarize the problematics on https://en.opensuse.org/SDB:System_upgrade we'll simplify the page. TODO: TLDR version of https://en.opensuse.org/SDB:System_upgrade

Translations

• Some translations doesn't work well in several context menus.

Release notes

• Italian release notes: it is a mix of Italian and English.

TODO: Italian release notes, make sure we get them translated. Contact translations community

• There is too much enterprise language in release notes. It looks like articles from Oracle :-) Article on news.opensuse.org is mostly ok. Release notes on https://en.opensuse.org/Features_15.3 are bad, good they are mentioning lot of packages and changes, but mentioning, that Firefox has fixed NTFS bug or eight paragraphs of description about KDE changes, when KDE is actually the same version as in Leap 15.2, looks insane. Bad are feature highligts on https://en.opensuse.org/Portal:15.3/Features , again 12 lines just to say, that KDE is the same. Compare to https://en.opensuse.org/Portal:42.2/Features . And even in that big list is not mentioned, that kernel in 15.3 contains new drivers, which is big and important change.

TODO: talk to release notes team. We can discuss revisiting of a "language" for openSUSE Leap 15.3 release notes if it sounds too enterprise-y. In the other hand we are trying to be profiled as a free Enterprise distribution, so this is expected. TODO: send kudos to Lukasz K. for his reviews of release notes, he really improved quality.

• I would have appreciated a clear announcement that cyrus-imapd is not supported anymore in 15.3. Dropping packages is okay, but why not mention it at least in the release notes (https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#removed-deprecated)?

Action item: add note to cyrus-imapd to release notes post release.

X / Wayland

• Upgrade from 15.2 to 15.3 went smooth, except that with wand windows don't open and I had to switch x11. (originally tracked in what went well)

Closing The Leap Gap

• The visibility of bug reports in bugzilla is still a problem. When updates reference a bugzilla entry which is not visible to openSUSE users this is frustrating. Bugzilla entries can contain sensitive data and I understand that openSUSE/SUSE users(customers) could prefer to keep data or comments confidential. Maybe it would be possible to add functionality to bugzilla to manage the visibility of comments and9 attachments at a finer grained level, e.g. by setting individual comments or attachments to public or private, and not a complete bug. Or to have a public abstract for confidential bugs within the bug, so that e.g. the creators of bugs have to consider whether they want to make the complete bug public or to keep the bug confidential and create an additional abstract.

• There are some practical difficulties related to the late addition of Leap features. We need some general guidelines for the late project stages after the beta, especially considering the differences in the milestones and priorities. Problem background: The joint base of Leap and SLE leads to many requests late in the project. These are approximately 16 after the end of the beta. As expected, the Leap is used strategically to acquire new customers. This commercial interest draws the motivation to include many unexpected new features late in the SLE project. Additionally, sometimes different packages lead to a difference in the security pressure. The last affect the SLE and Leap development directly between Beta and GM. A prominent example is the new rpm, requested in Leap but very disturbing for SLE. SLE-17817 - LATE: update rpm to 4.14.3 Ready for TPM other examples for the pressure to add packages to SLE from Leap is SLE-17845 - "apache2-event" package is missing in SLES Ready for TPM (apache event as also many others) Other examples could be: A CVE for a package with a high CVSS score relevant only to Leap during the SLE RC phase. - Shall this be considered a risk in the SLE project? - Second question how relevant are the Leap use cases for the SLE business? - Shall we synchronize the code freeze between SLE and Leap? I want to achieve some general rules to spare the extensive per case analysis per case, efforts and discussions.

• RPM related ... this was in the end a maintenance update that was fixing CVE. That's perfectly common.

The update is not YET released and yes it was pretty visible, because some of components are rather harder to fix as a maint. update. I think that this is not a good example as CVEs must get fixed.

We're doing early planning according to SLE deadlines. I can't really ask community for more. Every feature is evaluated and if it's not applicable for currently developed release, then let's make it maintenance update just like for any request.

• Leap.Next and predictability we need to present our lifecycle more transparently. The current roadmap suggests 90months of Leap 15.X support. Unfortunately we can't have new Leap version if there is no new SLE. This is something openSUSE * team can't affect, especially after agreement to use SLE binaries.

Action item: talk to openSUSE marketing about making our roadmap and lifecycle more transparent and understandable by people from outside openSUSE community as well. (See bad lifecycle comparision in distrowatch review of 15.3).

• Leap is shipped with outdated application packages - qt and KDE, just to mention two. We need to go back to the model that application packages are sourced from TW during the development phase. If necessary, SLE must speed up, not the other way round For openSUSE Contributors the SLE process is intransparent - some more possibilities of influence are desireable.

• too many non-public bugreports, especially for SLE packages - non-public jira references - [so far more an issue with 15.2, but might also affect 15.3] getting a minor version update with bugfixes published as maintenance update is _very_ hard and needs lots of bugzilla paperwork (I had a case where the SLE maintainer only cherry-picked the least important fix and released that as maintenance update. In a way, that's funny[tm] ;-)

lkocman: I hear you. Oliver: the only viable option is to have public by default. And explicitly protect information that needs to be protected. e.g. openQA generated bug reports are public by default. Perhaps some tools are not doing that.

TODO: Some SUSE-internal discussion. Continuation of the public bugzilla effort. "Next steps" Gerald: There was an initiative "Public bugzilla". Oliver would like to participate. Let's sync on Monday (Gerald, Lubos, Oliver).

• That last minute hot-fix for missing repos was...fun :) But, IMHO, it just shows how complex/complicated Jump project is/was, so I don't really consider it a big deal (s*it happens, even with all the planing/testing). Speaking of repos, I'd love a clarification what's the equivalent of 15.2:Update now, to build 15.3 packages for/against, it's a bit confusing.

lkocman regarding update repos: https://en.opensuse.org/Feature_Planning_15.4 see OPENSUSE-35 TODO: revisit this, perhaps ensure that people know that even SLE has some flexibility for Late update requests. These in fact can always happen as maintenance updates as long as they do not cause full distro rebuild or break ABI. If some particular package situation troubles you, then join our Monday Feature review meetings, and we can do something about it https://en.opensuse.org/Portal:Jump/Policy/CommunitySLEChangeRequests

• On my side nothing good, Hard to contribute, Heretic version of packaging Hard to understand its development.

lkocman TODO: Revisit the slides from OSVC2021 perhaps do some post-processing and share it. lkocman: Please be aware of email from Adrian to factory where we're trying to do a bit of unification and have a single reference to "CODE 15 / CODE 15.3" for all (Leap, Bacports, SLE ... all should be essentially the same code). lkocman: reworking docs moving them from Jump to Leap 15.4 would be also useful namely https://en.opensuse.org/openSUSE:Packaging_for_Leap https://en.opensuse.org/Portal:Leap/SLEFeatureRequests

• all sorts of little and larger trouble and stalls and especially unclear security related things such as sking for unknown pgp keys for signatures of packages and zypper wanting to uninstall half of the already upgraded system once inside 15.3 what the heck? is this the way you handle the opensuse folks trying to lure them over to SLE? who in their right mind would upgrade to SLE coming from these situations.

lkocman: I suppose you're talking about this item https://bugzilla.suse.com/show_bug.cgi?id=1184326 We did announce the issue and solution in our release notes https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#sec.upgrade.152

• It would be nice if one could only install those packages which are maintained by SUSE. Something like an "only SUSE" repo. Such that SUSE LLC. packages are separated from community (I thinkg it is called backports?) packages.

repos: Please see the current survey https://survey.opensuse.org/index.php/517118?lang=en we do plan to improve this by using a single term e.g. SUSE_15.3 or so

• Sometimes I read that openSUSE is more or less independent of SUSE. Fedora does the same with RedHat (Fedora is a community distro, ok. But in my view this community consists mainly of RedHat employees). The openSUSE 15.3 release shows clearly who decides the direction of this distribution. Personally I'm really fine with this. SUSE is a great company. But please be more clear about that.

Action item: revisit our marketing strategy. Independent vs SLE based where that comes with a bond :-)

• Merging the SLE/SLES and OpenSUSE Repos did not work out the best

• Nothing very nice seeing with this version. It just is delivering the series of unacceptable bugs and problems that make the life of the user with OpenSuse unpleasant and heavy. It would have been nice if could OpenSUSE about SLES to look like CentOs to RHEL. Then maybe leaving now CentOs would come to OpenSuse. I would have been glad if this version of OpenSuse had achieved this, but it is not there.

Three options were presented: 1) Free SLE 2) Centos like rebuild of SLE, 3) was Leap built on top of SLE binaries We'll definitely revisit free alternative/option for SLE Next (be it 16 or whatever). I feel that this retrospective will gives us a lot of input about how well did the current option go. Thank you for your feedback.

• Apart from the small issues mentioned below everything went fine. I hoped there would be no issues with an intermediate upgrade (.2 → .3) of Leap but I suspect these were due to closing the Leap gap. Being binary compatible with SLE, however, is worth the inconveniences. I hope next release will be even smoother.

• Maintenance: we have an agreement that existing SLE packages without Maintainer in SUSE can be updated, as part of currently developed service pack. This is currently not possible in maintenance update as maintenance bot auto-rejects packages without maintainer.

• The problems with Leap 15.3 are the same as with Leap 15.2, 15.1, ...: Almost all bug references in changelogs, patchinfos etc. point to non-accessible (SLES) bugs. Due to this it's impossible to decide if an update is necessary or not. And thus there is just not enough information available to decide on if I should update or not. It is a pity that an open OS has the practice of being developed behind closed doors.

lkocman: We'll try to improve this in this release. But it will boil down to capacity of Maintenance and security team.

The openSUSE Leap 15.3 now contains packages that are not installable because they require SLE: $ sudo zypper in sle-module-certifications-release Loading repository data... Reading installed packages... Resolving package dependencies... 2 Problems: Problem: nothing provides product(SUSE_SLE) >= 15.3 needed by product:sle-module-certifications-15.3-0.x86_64 Problem: nothing provides product(SUSE_SLE) >= 15.3 needed by product:sle-module-certifications-15.3-0.x86_64 Problem: nothing provides product(SUSE_SLE) >= 15.3 needed by product:sle-module-certifications-15.3-0.x86_64 Solution 1: do not install product:sle-module-certifications-15.3-0.x86_64 Solution 2: break sle-module-certifications-release-15.3-47.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): FMPOV packages that are not installable should not be on the repositories. Maybe some extra installcheck should run at some point. If "SLE RPMS do not pass installcheck in Leap (are simply synced over from IBS to OBS)", then maybe we should run the installcheck on the repos after the sync is done :-) TODO: we should try to blacklist these packages from IBS -> OBS sync. So they do not cause issues to SUSE layered products in general. Also this could be covered in openQA I suppose. TODO create tracker for openSUSE QA in progress-o-o.

Yast

• I have problems with Yast2-1-Click-installations and SLE-15-SP1 dependencies.

• Additionally, zypper up wants to remove yast2-trans-en and install yast2-trans. YaST, however, marks yast2-trans as unneeded and wants to replace it with yast2-trans.

Action item: share the yast2-trans issue with yast team, in case that it wasn't just another zypper patch issue.

• yast settings like ratbagctl
• the partition manager, if you use your own layout, is... uncomfortable, at least.

Action item: Yast partition manager / custom layout could be more use friendly

• inconsistencies with the updates shown by yast (check following for more context: GNOME / gnome software center does not show any categories)

• when I try to open YaST software management and It's already being used I get a ruby error instead of a proper error message saying that it is already being used.

Xfce

• So far, after a whole workday and more, the only thing that seemed unusual for me was a frozen xfce terminal session which I had to close "uncleanly", otherwise smooth sailing. ❤

I told Xfce team :-) However please one a bug if you can reproduce this issue otherwise m4u will be upset. Here's how https://en.opensuse.org/openSUSE:Submitting_bug_reports

• i did not have "xfce4-goodies" when selecting "XFCE Desktop Environment" -why?)

Action item: Xfce patterns consider including xfce4-goodies

KDE / Qt

• KDE Plasma theme: I installed the sweet kde theme (without kvantum - not available on Leap) as global theme, but this affected the leave screen, which became unusable (empty blurred screen) - my work around has been to apply the theme in parts. Not sure if it's a Leap bug or Plasma or theme, it worked flawlessly on Tumbleweed.

TODO : report bug for KDE / leave screen after using Sweet kde as global theme.

• KDE Discover software installation repoted bug remains unresolved, regression from 15.2 software.opensuse.org does not correctly list packages for Leap 15.3
• No repository found via powerlan. ( I suppose related to KDE discover)
• Leap 15.3 repository don't work and discover say he is not connected to internet! With leap 15.1 and 15.2 all work great!!! Love opensuse!! Help for repository to work again!!! ( I suppose related to KDE discover)

Action item: KDE mainteiners, please have a look at open bugs against KDE Discover

• kde connect can't connect to phone,I should modify firewall setting

• I couldn't charge my phone connected to my laptop because the usb port where in a power saving mode by default and I had no easy way to disable that. I had to Install tlpui and that wasn't easy due to dependencies. KDE connect is not working. I already added it to the firewall and it still not working. If it needs a port to be open to run it, openSuse could detect it and ask the user if he wants to open it. It could also be installed by default. It worked in Ubuntu, I only had to install it and wasn't even using KDE.

lkocman: aPlease open bugs for such issues TODO: check on phone management/power saving setting for usb and KDE Connect.

Gnome / Gtk

• Maybe it's an old issue that still occurs (Leap 15.2 and now 15.3), the problem is that the performance on Gnome DE (3.34) sometimes performs quite poorly for a while (e.g. open Activity, open WiFi). Tried another DE (KDE Plasma) had no problems. - Compatibility issues in the repository "repository-sle-update", from the announcement the user will have to wait until next week.

Action item: Talk to Yifan regarding performance regressions compared to 15.1.

• gnome software center does not show any categories nor software packages available - the only way I could install something was through yast, software.opensuse.org but not through the gnome software center. Guys, set your priorities straight, if you want openSUSE to be great again. I love this distro and the community, but we need to be more out there, make the distro appealing to newcomers. Otherwise, everything will be lost and we will fade into a the mist of irrelevancy... Fedora is way more usable from the beginning, and so are most of the other distros, even Debian.

TODO: gnome-software-center did not show any packages available. TODO: Investigate.

• gnome edition can't display all yast settings in my pc
• The integration (on GNOME) of apps with the Software center (was in didn't go well).

• I'd love to have Dracula-gtk-theme in the 15.3 repo

https://build.opensuse.org/package/binaries/X11:common:Factory/dracula-gtk-theme/openSUSE_Leap_15.3 lkocman: Let's track it here, or simply submit a package to Leap 15.4 (15.4 setup should be available by this Friday) https://en.opensuse.org/Feature_Planning_15.4

Bootloader

• My mid 2011 iMac has issues with newer versions of secureboot/shim. If it attempts to load the shim.efi it just freezes and nothing will happen. This not only affects direct booting to the shim.efi but also chainloading it via grub. The issue was already present in leap 15.2 but only very late (afaik april 21). My solution was to turn of secure boot and that was it. However trying to load the Leap 15.3 dvd image resulted in the same freezing problem, as it contains a newer version of secureboot/shim. My workaround was to boot into my normal grub and chainload the grub from the leap 15.3 installer directly ._. however that means I'll have to keep the leap 15.2 disk image around, just in case grub decides to break itself :/. While an actually fix would be nice, a workaround could be to provide disk images without secureboot? Another mildly annoyance I faced were, that the packman repo could not be automatically changed, so I had to manually click each package I had installed from the packman repo and vendor change to to SUSE/openSUSE and after the install finish re-add the packman repo again.

Question: please open a bug, I think we can address this issue. I can open it for you but then you won't get the feedback loop and not many people have iMac so we could use some testing from your side. Thank you!

• can't hide grub loading message

• I cannot install or boot it on my laptop because of the shim issue https://bugzilla.opensuse.org/show_bug.cgi?id=1185232 so I unfortunately am using Fedora until opensuse is fixed

TODO: commented on the bug to provide a summary where are we with the fix. I hope it will help you to switch back soon to openSUSE

Multimedia

Still, after all these decades, no support for multimedia and (most) codecs? i did NOT really embrace the need to use third party sorces. lkocman: we're looking into making codec installation easier. See https://code.opensuse.org/leap/features/issue/22 Action item: TODO M4U to reference docs to OPI here. OPI is a cmdline tool which lets you install all multimedia codecs etc. We may want to perhaps write a yast plugin or something like that. https://github.com/openSUSE/openSUSE-docs-revamped-temp/blob/dev/project/docs/codecs.md https://github.com/openSUSE/opi Action item: perhaps live images could use more love and visibility. If we're compared to Fedora Debian and being easy to use, Live DVDs are easy to start with.

Translations

• Lack of translations EVEN THOUGH I am the (Finnish) translator! Some strings are missing even though I am sure they’ve been in the localization files for a long time. Like the system roles (KDE Plasma, GNOME, Xfce): they were translated in time for Leap 15.2 and remain translated in Weblate, so why are the strings not being used?

TODO: Talk to sbrabec about translations. I know we had some issues with patterns. The Leap 15.3 is bit special from translations point of view, as some packages might be reused from SLE instead. I think that this should be still action item for 15.3 and 15.4 as we could most likely get translations updated via maint updates.

Comparison to other distros

• (KDE Connect reference and Nvidia, patch conflicts) was moved to separate sections) Worst version ever... I'am a software developer and I've been using SuSE for the about 19 years and it's getting worst. I bought a laptop(HP Omen) in october 2019 and had to install Ubuntu 19.10 on it because I couldn't even run opensuse installer due to a problem with the nvidia card... Also couldn't find a way to run it on the command line. OpenSuse 15.2 was released after that but still had the same problem. Now with 15.3 I was finally able to install it but still had lots of problems. I took openSuse more then a year to fix a problem that Ubuntu fixed quickly. The hardware detection and driver loading part of the installing took way too long. SuSE used to be the best Linux distro on the Destkop but openSuse is far from it. Ubuntu: https://linux-hardware.org/?probe=beb9e327ad Opensuse: https://linux-hardware.org/?probe=0c01b21401

Issues with particular packages

Wine

• wine's vulkan isn't working(amd)

ibus

• installer will install ibus ime,but it can't change theme. selected breeze splash screen in settings,but suse splash is shown

python

• "pip" didn't work after the upgrade. I had to manually install it from their website to make it work again. - changing repos is, sorry, a pain in the ass. zypper should do it all.

• See python38 in distribution freshness

• https://bugzilla.suse.com/show_bug.cgi?id=1185748, but it was not a big problem for me :-)

I did ping our python packaging team. Otherwise bug seem to have owner, we should be all set. python2 will be removed in Leap 15.4/SLE 15 SP4, so I ensure you that this issue will have "permanent fix" :-)

wpa_supplicant

- there's a special problem whenever "wpa_supplicant" is updated, a connected shell not only hangs temporarily which would be understandable, but permanently, which is not understandable. So, whenever this package is updated, I have to go to the server and do it on the console and not remotely via a terminal program. It would be really, really cool if these three issues could be addressed in the future. TODO: track wpa_supplicant feature request?