June 2022 - openSUSE Project - openSUSE Mailing Lists

Mirror infrastructure problems?
by Stefan Seyfried 17 Jun '22

17 Jun '22

Hi all, I seem to remember that there have recently been changes to the mirror infrastructure. I'm seeing problems with that, since maybe around one week. It manifests like that: Retrieving package btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64 (1/1192), 420,1 KiB ( 1,2 MiB unpacked) Retrieving: btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm ............................[not found] File './x86_64/btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/seife:/testing/15.4' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm ............................[not found] File './x86_64/btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/seife:/testing/15.4' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm ............................[not found] File './x86_64/btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/seife:/testing/15.4' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: btop-1.2.7+git20220528.c3eb02f-lp154.31.1.x86_64.rpm ............................[done] Retrieving package fusefile-0.1~3_g1bfc0a7-lp154.1.1.x86_64 (2/1192), 11,9 KiB ( 11,4 KiB unpacked) Retrieving: fusefile-0.1~3_g1bfc0a7-lp154.1.1.x86_64.rpm ....................................[not found] File './x86_64/fusefile-0.1~3_g1bfc0a7-lp154.1.1.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/seife:/testing/15.4' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: fusefile-0.1~3_g1bfc0a7-lp154.1.1.x86_64.rpm ....................................[not found] File './x86_64/fusefile-0.1~3_g1bfc0a7-lp154.1.1.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/seife:/testing/15.4' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: fusefile-0.1~3_g1bfc0a7-lp154.1.1.x86_64.rpm .........................................[done] Retrieving package ipxe-bootimgs-1.21.1+git20210908.02ec659b-lp154.48.1.noarch (3/1192), 1,9 MiB ( 4,8 MiB unpacked) Retrieving: ipxe-bootimgs-1.21.1+git20210908.02ec659b-lp154.48.1.noarch.rpm .................[not found] File './noarch/ipxe-bootimgs-1.21.1+git20210908.02ec659b-lp154.48.1.noarch.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/seife:/testing/15.4' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: ipxe-bootimgs-1.21.1+git20210908.02ec659b-lp154.48.1.noarch.rpm ........[done (218,1 KiB/s)] So I'm getting a 404 for packages (or metadata also), and after retrying a few times (or just repeating the "zypper ref" a few times, it finally succeeds. This is mostly happening on "fringe" repos: my home project, CrossToolchain:avr, ..., only very seldom on the main opensuse repos. I'm guessing that I'm first redirected to a mirror which does not carry this repos (or is outdated) and after a few retries, I'm actually redirected to a "good" mirror. This can be up to 6 or 7 retries. Often, once a good mirror is found, more packages from the same repo can be downloaded without retry, but sometimes almost every single package needs retries (right now this is happening with http://download.opensuse.org/repositories/home:/seife:/vdrdevel/15.4) Is there a bugzilla category for such problems? Or should I just bounce this mail to admin(a)opensuse.org? Apparently I am not the only one seeing this as I have gotten reports that http://download.opensuse.org/repositories/vdr/15.4 would not carry binary packages only to get an update a few minutes later that retrying solved the issue. Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

2 1

Update on next generation of SLE
by Stefan Behlert 14 Jun '22

14 Jun '22

(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.) Moin, In the last months many people have brought up the topic of "When will the next SLE major version come out?". Today we would like to give you a first update on the plans. Since 2018, when SLE 15 was initially released a lot of things have changed, including requirements from users and customers, technologies, the speed of new versions of applications, languages and their libraries appearing. Also the connection between Leap and SLE has changed. And while some bits and pieces got better, we firmly believe we can do better. SLE 15 is a great general purpose operating system, yet challenges with some use cases, now places of deployment, and the type of enhancement requests show that it's time for a successor. With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;) First and foremost, ALP will be developed in the open. We are not going to put the pieces together internally and then share outside, as in the past. No, we are creating and building in the openSUSE Build Service - in a project next to you :). You get to directly see to see what is going on and participate more easaily. Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based. You might say "This is very generic, can you tell us more?" - of course. In the upcoming weeks more and more will crystalize, and we will share as quickly and regularly as possible. This is just a first heads-up to inform you that we are in the process of setting everything up - from project to feedback channels, from documentation to testing. Of course, you will have lots of other questions - how will contribution work, what impacts this has on LEAP and get-o-o, how migration could work, and many more. We kindly ask you for a little bit of patience. We promise we will share as soon as possible more details. ciao, Stefan -- Stefan Behlert, SUSE Software Solutions Product Management SUSE Linux Enterprise Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nuernberg)

11 23

Community Meeting/ALP WG: Week 24
by ddemaio 14 Jun '22

14 Jun '22

The ALP WG will take place tomorrow at 14:30 UTC The Community Meeting is on Thursday at 19:00 UTC. Both meeting will be in https://meet.opensuse.org/meeting You can read the notes from last week's at https://etherpad.opensuse.org/p/weeklymeeting20220609 You can view the meeting notes from the ALP WG and other notes at https://etherpad.opensuse.org/p/weeklymeeting. v/r Doug

2 1

Re: Why all the fear?
by Lukáš Krejza 10 Jun '22

10 Jun '22

Dne čtvrtek 2. června 2022 21:13:37 CEST, iob napsal(a): <snip> > pretty much same here. snapper is enabled for example. Never had a > serious problem and never used those fancy stuff. it was not always > perfect and with some configuration here and there, i consider TW > stable for a rolling distro. > > But in the other side, i think it is very easy to mess up or break the > system. Usually with some repo that you found online or someone > recommended etc. > > IMO one of the reasons for the fear comes from the lack of good/working > documentation and tutorial. > Yeah, that is why i mentioned documentation as one of the three most important parts that should be mentioned on the openSUSE web page here: [1]. But i guess nobody cares or noticed that, since the thread got massively off-topic. [1]: https://lists.opensuse.org/archives/list/project@lists.opensuse.org/ message/V76ABRHJ6AYC5S4UW5CE4TLQYUNZZRUW/ Regards, Gryffus

1 0

openSUSE @ Open Source Day (Mentoring)
by Sarah Julia Kriesch 09 Jun '22

09 Jun '22

Hello together, last year was the first time, that I and my zsystems team has participated at th virtual Open Source Day [0]. The Open Source Day is a hackathon day in the USA, where female mentees can contribute to open source projects. I was asked because they had looked for a Linux community and a female community Representative. I can say, that we had success and have received also some new openSUSE Members on this way. But we had provided only s390x tasks. We want to join again. Is anybody else interested to join our team as a Mentor? Then we can provide more tasks (outside of s390x). These tasks can be also packaging related or other (development) stuff. But most should be entry level. The next Open Source Day is Friday, September 16th, 2022. A small warning for all openSUSE Contributors from Europe: That will be a hack night for us! ;) We (from the zsystems team) are planning to join this event again. We would be happy about additional openSUSE Mentors, because the former assigned Mentors were more on an intern level as a qualification. In parallel, a female Release Manager by a hardware distributor should have been a Mentee and interacted as a Mentor. If you are interested to join us, answer to this email and apply on the Open Source Day page[1] as a Mentor. Best regards, Sarah [0] https://opensourceday.anitab.org/agenda/session/570707 [1] https://ghc.anitab.org/programs-and-awards/open-source-day/

1 0

Community Meeting: Week 23
by ddemaio 09 Jun '22

09 Jun '22

Hi all, There will be a Community Meeting this evening.All meeting take place in https://meet.opensuse.org/meeting You can view the meeting notes from the ALP WG and other notes at https://etherpad.opensuse.org/p/weeklymeeting. Cya later v/r Doug

1 0

openSUSE Community Releases Leap 15.4 Version
by ddemaio 09 Jun '22

09 Jun '22

On behalf of all contributors to the openSUSE Project and the release team, I would like to inform you that we have released openSUSE Leap 15.4. Please view the announcement online at https://news.opensuse.org/2022/06/08/leap-offers-new-features-familiar-stab… I would like to thank all those involved in the release. A special thank you to the developers, release team, packagers, testers, bug reporters, partners and community projects. I want to personally thank those who helped with the release notes, translations, release announcement, artwork and social media. v/r Doug

3 2

Re: openSUSE Release Engineering meeting 04.05.2022
by Luna Jernberg 06 Jun '22

06 Jun '22

Will miss the meeting this week as another thing popped up, but will read the minutes about what was said later and download 15.4 Stable later that day On Wed, May 11, 2022 at 8:49 AM Luna Jernberg <droidbittin(a)gmail.com> wrote: > Will attend the meeting live today :) > > On Sun, May 8, 2022 at 12:39 PM Luna Jernberg <droidbittin(a)gmail.com> > wrote: > >> Hey! >> >> Did read up on this now, has had too much to do earlier this week, and >> started working a bit on the Swedish Translations of the Leap 15.4 Release >> notes, and @Johan Dot <jonte1(a)gmail.com> promised to continue to work on >> them later today :) >> >> On Thu, May 5, 2022 at 3:56 PM Lubos Kocman <lubos.kocman(a)suse.com> >> wrote: >> >>> All meeting minutes can be found here: >>> https://etherpad.opensuse.org/p/ReleaseEngineering-meeting >>> Meeting is hosted here >>> https://meet.opensuse.org/ReleaseEngineeringMeeting >>> >>> ## Attendees >>> guillaumeg, DimStar, rbrown, lkocman, mpiala, ddemaio, maurizio >>> (m4u).maxlin, Sarah >>> >>> ## Internal SUSE IT Supported distribution >>> >>> Guests: Martin Piala, Vojtech Pavlik >>> >>> Idea: openSUSE Leap as supported system by SUSE IT! >>> Vadim G. is looking for a help to kickstart the effort. >>> We're thinking of starting a hackweek with a Leap 15.4 spin with some >>> preinstalled tools for SUSE environment. >>> >>> https://hackweek.opensuse.org/21/projects/opensuse-build-supported-by-suse-… >>> >>> Our feature tracker for any issue references. >>> https://code.opensuse.org/leap/features/issue/77 >>> >>> Next steps collect requirements for Minimal Viable Product >>> I believe Vojtech could help us there. >>> >>> How does Rancher product portfolio fit in? >>> >>> Datto is using gnome-initial-setup for post-install tweaks. >>> https://github.com/endlessm/gnome-initial-setup/blob/master/HACKING >>> We could start there as well. However, they're already looking for some >>> futher management tools. >>> I believe that we do not need any 3rd party tools. Perhaps SUMA could >>> help with post-installation management. >>> >>> Martin: currently supported systems by IT are Windows 10 and MacOS, we >>> would like to change this >>> Martin: we'd like to have pre-installed tools required for daily work. >>> slack, teams. >>> We have company portals for Windows10 and Mac and some of the apps can >>> be already preinstalled for the image. >>> Martin: we do not yet have experience for responsibility of building >>> Linux apps and we need your help. >>> Ideally it should be done by the end of the quarter. End of July >>> >>> It's not decided yet what should we use. Whether we need a script post- >>> install. >>> >>> Richard: I do have a couple of questions: >>> >>> Which HW are we talking about? >>> * How often will be the recommended hardware changing? >>> Martin: We have some predefined laptops specific. 2 hardware specs >>> (standard, power). New ones are Lenovo, we're also rotating the older >>> Dells. >>> Martin will discuss this with team. In the next HW rotation we should >>> take the support of the chosen OS into consideration. >>> * Would the best option be Leap based? And perhaps risk some of the >>> missing hardware support? >>> * Or should we consider something Tumbleweed based? Perhaps you will >>> end up with something like MicroOS >>> * Desktop. Teams, Slack would be then consumed from Flatpaks. >>> >>> lkocman: I recommend to consider two approaches: provide root password >>> to the user or not. For less technical users it would be preferred if >>> SUSE it would do most of the changes. >>> Martin: For IT are also preferred these two options, one with admin >>> access (here the user is responsible for the setup), and another with >>> limited permissions, where IT is responsible for maintenance + the >>> laptop must be enrolled (most probably in VMware Workspace One, >>> currently under research). >>> >>> ## Leap >>> >>> Leap Micro 5.2 is RC! >>> >>> We've also progressed on release-notes-leap-micro (Thanks cboltz and >>> Lukas) >>> https://doc.opensuse.org/release-notes/x86_64/openSUSE/LeapMicro/5.2/ >>> >>> Rework of LeapMicro get-o-o layout >>> community worked on overview for Leap Micro >>> https://etherpad.opensuse.org/p/weeklymeeting20220505#L51 >>> We should also consider single page layout MicroOS and backport >>> overview changes as well >>> https://github.com/openSUSE/get-o-o/pull/87 >>> >>> >>> A lot of changes from SLE 15 SP4 post-RC. Removing snapshot at this >>> point in time was not so good choice in the end. Some more changes will >>> be taken in today, tomorrow. Mass rebuild is planned in next few days >>> (Friday/Saturday). Maint snapshot for SLE 15 SP4 on Sunday. >>> We need to be able to finish the RC build, that's not possible now. >>> >>> Leap Desktop/Workstation workshop is next week! >>> 50+ people have signed up for workshop >>> >>> https://www.reddit.com/r/openSUSE/comments/udr5ly/desktop_workshop_for_next… >>> - syncup with Scott and Yi Fan prior the acutal workshop >>> Looking for drivers who could help us "kickstart the initial workshop". >>> Long story We need some people who already know what to do (how lucid >>> works, create some initial topics) to inspire others. >>> >>> Interesting last minute feature for laptop customizations. (Big thanks >>> Dirk) I'll see what would be easily adoptable. SLED is interested as >>> well. >>> https://code.opensuse.org/leap/features/issue/75 >>> >>> >>> ## openSUSE Tumbleweed >>> >>> openSUSE:Factory build fail stats: 108 failed, 10 unresolvable (last >>> week: 123/11) >>> https://tinyurl.com/ysy4nnnz >>> >>> * GNOME 42.1 shipped in snapshot 0501 (snapshot 0429 and 0430 were >>> blocked due to dracut) >>> * KDE Plasma 5.24.5 staged - ready for either 0504 or 0505 >>> * Meson 0.62 is staged - another round of 'syntax validation getting >>> stricter' (not too many issues seen though) >>> * GCC12 as default compiler still staged, results are looking very good >>> (Staging QA all passed, waiting for the final go) >>> lkocman: I hope that Alp will adopt to the new default(s) as well. >>> Mentioned the llvm situation in Leap 15.X >>> >>> GPG Key to sign packages/repos is planned to be updated to be a >>> 4096/RSA key (implementation schedule pending) >>> Tracker bug : https://bugzilla.suse.com/show_bug.cgi?id=1199184 >>> >>> OBS seems to have some hard time finding workers for ceph and kernel >>> builds: very frequently, staging projects are blocked by waiting for >>> the 4 same packages still being scheduled (ceph, kernel-default, >>> kernel-vanilla, kernel-debug) (constraints limit to 18 (ceph) resp 24 >>> (kernels) workers) >>> >>> ## Richard (Kubic/MicroOS) >>> >>> Started Discussion with the Kubic community about winding down the >>> Kubic project and focusing more attention on MicroOS (and MicroOS >>> Desktop) - >>> >>> https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org/thread/23… >>> For those currently on Kubic, Kubernetes atop MicroOS is best addressed >>> with using k3s/RKE direct from Rancher. Whether we need >>> tooling/documentation to help with potential migrations is an open >>> question. >>> lkocman: This topic was raised also on the community meeting. Isn't >>> Kubic the only Kubernetes and CNCF certified distro that we have now? >>> Richard: depends on your definition of 'we' - CNCF certification is >>> specific to the Kubernetes that is part of Kubic. Rancher k3s supports >>> MicroOS and is itself CNCF certified, so 'we' will still have that. >>> lkocman: The question that popped up was how to get the k3s running on >>> Leap Micro. I did share the whitepaper for SLE Micro 5.1. Richard: this >>> should just work with 5.2+. >>> >>> Objecting to the Leap Micro get.opensuse.org page overstating it's case >>> at the expense of other openSUSE Projects that address the same use >>> cases - https://github.com/openSUSE/get-o-o/issues/88 >>> >>> MicroOS (GNOME) Desktop has a fresh community effort to get out of >>> beta, possibly by writing a fresh notification tool for transactional- >>> updates instead of relying on PackageKit. Join the Telegram/Matrix >>> MicroOS Desktop channel to join the effort. >>> >>> Podman 4.0.x now working perfectly >>> >>> Working on various interesting MicroOS research tracks: >>> - kiwi-less/container first VM image building Status: POC >>> - nerdctl support in toolbox Status: Broken prototype >>> - buildkit and its limit as a container builder >>> - TW-to-MicroOS conversion >>> - curl-minimal and making it default (like Fedora) Status: >>> Investigating >>> - Re-arranging Factory so products like MicroOS can build with >>> different PrjConf than Tumbleweed >>> - MicroOS Desktop using TIU instead of transactional-update (ie. >>> remove all individual rpm package management) (research not sure if >>> it's worth updating docs yet) >>> Please ping rbrown(a)suse.com if you are interested/have opinions on any >>> of the above, feedback/thoughts/existing knowledge is welcome. >>> >>> ## Max >>> >>> Leap Micro >>> * Have a look repotred Leap Micro selfinstall has different behavior >>> compare to SLEM on openqa, it should boot iso instead of raw image for >>> the testing, bsc#1197877 >>> * Removed beta flag >>> >>> Leap 15.4 >>> * Look into python-certbot bug, the culprit is: python-pyopenssl in >>> SLE15 SP4 has been updated to version 20, it's requiring python- >>> cryptography > 3.2 however we had 2.8 in SLE, the minimal requirement >>> can not filled, this should affected many packages rely on pyopenssl, >>> bsc#1198851 (There is a SLE maintenance request for python-cert*, but >>> it's a major version bump) >>> Marcus does not recommend forking package in Leap as there are other >>> SLE python modules that will depend on it. >>> * Removed snapshot repo >>> * Preparing 15.4 RC build >>> Lubos will send an annoucement that RC will be delayed because of >>> incoming changes from SLE 15 SP4. >>> * Build fail stats in Leap 15.4: 20 build fails, 0 unresolvables >>> lkocman: I'll open individual bugs for remaining build failures. >>> >>> Santiago mentioned that he'll have more free cycles for Leap/openQA >>> this week. I'll reach out to him regarding focus on the migration >>> scenarios. >>> >>> ## Guillaume - Arm >>> >>> Tumbleweed: >>> * Rolling again >>> * Upcoming GCC 12 tested for aarch64: >>> >>> https://build.opensuse.org/project/show/home:dirkmueller:branches:openSUSE:… >>> >>> Leap 15.4: >>> * aarch64: >>> * Issue with Numpy/openBLAS fixed: >>> https://bugzilla.suse.com/show_bug.cgi?id=1198885 >>> * armv7: >>> * Enlightenment package still fails in rpmlint check (missing >>> whitelist?): https://bugzilla.opensuse.org/show_bug.cgi?id=1194047 >>> lkocman: will reach out to simotek and Wolfgang >>> * scc product class looks wrong (Marina/Marcus) (for all non-intel >>> arches). x86_64 has OPENSUSE-BETA while for the others the class is >>> SLES-ARM64-BETA, SLES-PPC-BETA, SLES-Z-BETA. >>> https://sd.suse.com/servicedesk/customer/portal/1/SD-82355 (Internal, >>> Ticket with SCC team, team lead is aware of the request). Request is >>> now resolved. (lkocman: Correction trello shows me that 2/4 items are >>> still pending). SCC team confirmed that this is done. I did check non- >>> intel arches and they seem to all use OPENSUSE-BETA. >>> >>> Leap Micro 5.2: >>> * SR to add Default-SelfInstall image for aarch64: >>> https://build.opensuse.org/request/show/974751 >>> Lubos will open a JIRA for 5.3. I'll ask if it would be option for 5.2 >>> as well. >>> >>> lkocman to check if we could remove the firefox tests from the >>> 42.X/15.0 upgrade test suite. It doesn't seem to happen outside of that >>> (same for TW). >>> lkocman will try to look into this >>> >>> ## Sarah - s390x >>> >>> SUSE has shutdown 3 LPARs because of performance issues >>> Issue has been also reported to the CTO for ZSystems of IBM >>> >>> Tumbleweed: >>> * Is rolling >>> >>> >>> openSUSE Leap Beta: >>> * no issues at the moment >>> >>> * maven issues are existing -> discussions about upgrading the Java >>> version or how to fix it >>> >>> lkocman: slightly related topic, should we perhaps re-consider >>> recommended memory amount in Release Notes? I think we still recommend >>> something like 2G minimal / 4G or 8G optimal. >>> * KDE for s390x adopted >>> >>> ## Doug >>> * TSP >>> * Solution seems to be found >>> * No update on status on when it can be implemented >>> * Community Meeting >>> * Discussion/workshop planned for community meetings on May 10 & 12 to >>> discuss successor of Leap >>> * >>> >>> https://lists.opensuse.org/archives/list/project@lists.opensuse.org/thread/… >>> * oSC22 >>> * Will cancel all talks on confrimed by May 6 >>> * Schedule mostly complete >>> * Ordering badge and signage >>> * Setting up venueless platform >>> * Slides need to be 16x9 >>> * OSCAL oSC22 >>> * Will start creating schedule >>> * Reached out to people to confirm their talks >>> * GSoC >>> * 4 proposals ranked for May 12 deadline >>> >>> Installfest in CZ. CfP deadline was Monday midnight: >>> MicroOS >>> Leap and Leap Micro >>> D-Installer >>> >>> talks were submitted >>> >>> ## Dirk >>> >>> Not available >>> >>> lkocman: Thanks for the framework laptop setup >>> We're not currently listed as framework laptop compatible distro >>> https://gist.github.com/cornfeedhobo/8f32430dc6c52b9a4776df91701b1d96 >>> >>> * switched obs-arm-11 worker to aio=io_uring away from aio=threads >>> which appears to reduce I/O cost (bsc#1197746), which caused issues on >>> x86_64. still chasing that down. >>> * did a full rebuild of openSUSE:Factory:ARM as Guillaume was away and >>> openqa was broken anyway :) did introduce more issues than it fixed it >>> appears >>> * Still to work rust 1.59 / ghc issues on armv6 and armv7: all have the >>> same root cause, use of SWP/SWPB instructions which is imperfectly >>> emulated by the aarch64 host kernel. works fine with armv6/v7 kernel. >>> * looked into gcc11 build failures >>> >>> In backlog: https://code.opensuse.org/leap/features/issue/17 >>> >>> ## Wolfgang (Package Hub), Scott Bahling >>> >>> Not available >>> >>> ## Maintenance team (Marina or Marcus, Maurizio (m4u)) >>> >>> - Marcus: 15.4 is set up channel wise, updates will go in testing >>> occasionaly, if you need more ping me, no openqa setup yet >>> lkocman: could you please help me with cleanup of maintenance tasks in >>> https://progress.opensuse.org/projects/opensuse-leap-15-4/issues/gantt >>> lkocman: will contact Jan Stehlik. Santi (PO for the topic) mentioned >>> he'll work on it. >>> lkocman: messaged Jan >>> - Marcus: 15.3 openQA is ok again. >>> >>> lkocman: (still pending) will open a release notes entry for a change >>> Security Advisory identification >>> TODO Marcus: could you give me example of old and new values? >>> >>> - Marina and Maurizio: SLE-PackageHub overlaps >>> (https://github.com/openSUSE/openSUSE-release-process/issues/71) work >>> in progress following the initial list of overlapping packages >>> (https://progress.opensuse.org/issues/106610#note-3). More incidents >>> are under QA. Work is going on and under control (and tracked >>> internally as jsc#MSC-303). >>> Already released: (AH PERFECT!) >>> SUSE:Maintenance:22929:265929 (babl libbabl-0_1-0 typelib-1_0-Babl-0_1) >>> SUSE:Maintenance:23000:266006 (MozillaThunderbird enigmail) >>> SUSE:Maintenance:23009:266004 (freerdp freerdp-devel freerdp-proxy >>> libfreerdp2 libgsm) -> libgsm1 was missing in PH making freerdp not >>> installable >>> SUSE:Maintenance:22928:266007 (argyllcms csync libcsync0 libcsync- >>> plugin-sftp libcsync-plugin-smb) >>> SUSE:Maintenance:23015:267052 (gfbgraph-devel libgfbgraph-0_2-0 >>> typelib-1_0-GFBGraph-0_2 librest gcr) -> librest, gcr and libgoa are >>> needed too for making gfbgraph installable >>> SUSE:Maintenance:23334:268316 (gutenprint gutenprint-devel) >>> SUSE:Maintenance:23486:268867 (hp-drive-guard, upower) --> needs >>> libupower-glib3 >>> SUSE:Maintenance:23487:268897 (liba52-0 liba52-devel) >>> SUSE:Maintenance:23506:268899 (libdvdread4 libdvdread-devel) >>> >>> Meet product security at the openSUSE Conference. There are about 3 >>> talks on the maintenance and security topics. Come and say Hello! >>> >>> ## Adrian - OBS >>> >>> Not present >>> >>> feedback loop on mirrored submissions doesn't workstation. Lubos wills >>> end an email with an example to Marco and Adrian. (Sent last week) >>> Marco has reached out to me regarding the mirroring. He has example(s) >>> from SUSE:SLE-15:SP4:GA >>> >>>

1 0

Reminder meeting : openSUSE Board meeting next Monday (13:00 Europe/Berlin)
by openSUSE Meeting Reminder 04 Jun '22

04 Jun '22

Hello all, The biweekly board conf call will be held in two days at 13:00 Europe/Berlin time (CET = UTC+1) Meeting will be in the regular Board Meeting Room https://meet.opensuse.org/OSBoard Current Topics: https://code.opensuse.org/board/tickets/issues?status=Open&tags=meeting Board Members: If you cannot participate, please advise by replying to this mail.

3 2

ways to contribute to openSUSE
by Per Jessen 03 Jun '22

03 Jun '22

Just now I happened to stop by https://www.opensuse.org, and noticed this: CONTRIBUTE TO OPENSUSE Be part of our community contributing with any of the following: Code or hardware. Firstly, I appreciate it is written in capitals, but shouldn't it still be "openSUSE" ? Second, code and hardware are the only ways to contribute ?? That seems a bit limited - shouldn't we be a bit more inclusive? I know the overlay that appears once you click "code" has more options, largely copied from here: https://en.opensuse.org/Portal:How_to_participate Maybe it's just me, but when the first reply to "How to contribute" is "code or send us some hardware", that's a bit too limited. "Hardware" is surely not exactly the most common option either ... I honestly don't know what the most common ways are, although I expect code is certainly one. -- Per Jessen, Zürich (27.1°C) Member, openSUSE Heroes

21 95