July 2022 - openSUSE Project - openSUSE Mailing Lists

[Notice] - openSUSE Regular Board election 2021
by Ariez Vachha - openSUSE 01 Nov '22

01 Nov '22

Dear openSUSE members, openSUSE Board Election 2021 [1] It's time to elect new Board members to fill empty seats on the openSUSE Board. There are two seats for election in accordance per our normal election cycle. This is a regular election as defined in our Election Rules [2] ## Phase 0 01 November 2021 - Announcement of the Board Election 2021 - Call for Nominations and Applications for Board candidacy - Membership drive 22 November 2020 - Nominations and Applications for Board candidacy close ## Phase 1 22 November 2021 - Announcement of the final list of candidates - Campaign begins - Membership drive continues, opportunity to apply for openSUSE Membership, but members will only be eligible to vote and not run as a candidate ## Phase 2 13 December 2021 - Ballots open: Please cast your vote during this time - Campaign continues 30 December 2021 - Ballots close 31 December 2021 - Announcement of results To stand for a position in the openSUSE Board please send an email to: * project(a)lists.opensuse.org and * election-officials(a)lists.opensuse.org If a member would like to nominate another member, please inform the Election Committee and the officials will contact the nominee to ask whether they would like to run as a Board candidate. Only openSUSE members are eligible to run for openSUSE Board openings in accordance with the Eligibility and Validity section of our Election Rules [2]. The Election Committee [3] are hereby calling for Nominations & Applications for the openSUSE Board. [1] https://en.opensuse.org/openSUSE:Board_election [2] https://en.opensuse.org/openSUSE:Board_election_rules [3] Members: Ish Sookun, Edwin Zakaria and Ariez Vachha. -- Regards, The Election Committee election-officials(a)lists.opensuse.org

3 5

https://en.opensuse.org/Portal:Teams
by Gerald Pfeifer 16 Aug '22

16 Aug '22

Hi folks, by chance I ran into https://en.opensuse.org/Portal:Teams and noticed a couple of oddities (= historical artefacts?) * There is a team "Community Council" listed, which "Solves internal and external conflicts and communication issues". I never heard of that, and indeed following the link it ... redirects to the Board page. => This team best should be removed to reduce possible confusion, alas I don't know how to? The page appears to be generated automatically? Who can help? * The "openSUSE team at SUSE" as such does not exist any longer. And the links is borken. => Same as above; how do we get rid of that entry on that page? * Ditto for https://en.opensuse.org/openSUSE:Openfate_screening (which should be removed) and its entry on that page under the label of "openFATE screening". Any help (or pointers) would be lovely - thank you! Gerald

2 2

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

01 Aug '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.

2 1

Community Meeting/ALP WG: Week 30
by ddemaio 28 Jul '22

28 Jul '22

Hi all, The ALP Work Group (WG) will take place tomorrow at 14:30 UTC. The Community Meeting will be on Thursday at 19:00 UTC. Both meetings will be 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. You can find the Community Meeting notes from last week at https://etherpad.opensuse.org/p/weeklymeeting20220721 One key thing from that to highlight is we were asked to reserve the Z-Bau in advance of next year's openSUSE Conference. We were given a timeframe between May 25 - 29 to reserve the venue. To add to the topics of the conference, please remember of the Call for Papers for the openSUSE.Asia Summit is open until July 31. LOGO Yes, We need a logo from this year's openSUSE.Asia Summit. Find out how to submit your logo idea at https://news.opensuse.org/2022/07/01/osa-cfl/ v/r Doug

2 1

openSUSE on Linux Saloon
by Luna Jernberg 28 Jul '22

28 Jul '22

openSUSE on the Linux Saloon video podcast in 2 weeks: openSUSE on Linux Saloon 23-24th June

2 3

openSUSE Leap on Linux Saloon
by Luna Jernberg 28 Jul '22

28 Jul '22

https://www.youtube.com/watch?v=HejPzBYSExk The latest Linux Saloon episode is about openSUSE Leap

1 0

[opensuse-project] zypper refresh takes double time for update/leap/15.x/sle/ than all others combined
by Felix Miata 26 Jul '22

26 Jul '22

Is update/leap/15.3/sle/ the most populous, containing more packages than any other? What else could account for this obvious sloth, twice the time to refresh sle than all others combined? Behavior is similar for 15.4, since farther back than I can remember, probably since 15.3 was originally released. # zypper lr Repository priorities in effect: (See 'zypper lr -P' for details) 72 (raised priority) : 1 repository 90 (raised priority) : 1 repository 99 (default priority) : 7 repositories # | Enabled | GPG Check | URI --+---------+-----------+------------------------------------------------------------------------ 1 | Yes | ( p) Yes | http://silk.apana.org.au/rpm-opensuse15-unstable-dev 2 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.3/ 3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.3/ 4 | Yes | (r ) Yes | http://download.opensuse.org/distribution/leap/15.3/repo/non-oss/ 5 | Yes | (r ) Yes | http://download.opensuse.org/distribution/leap/15.3/repo/oss/ 6 | Yes | (r ) Yes | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_Leap_15.3/Essentials 7 | Yes | (r ) Yes | http://download.opensuse.org/update/leap/15.3/oss/ 8 | Yes | (r ) Yes | http://download.opensuse.org/update/leap/15.3/backports/ 9 | Yes | (r ) Yes | http://download.opensuse.org/update/leap/15.3/non-oss/ # time zypper ref Repository 'FCL' is up to date. Retrieving repository 'KDE3' metadata ......................................................[done] Building repository 'KDE3' cache ...........................................................[done] Retrieving repository 'Mozilla' metadata ...................................................[done] Building repository 'Mozilla' cache ........................................................[done] Repository 'NonOSS' is up to date. Repository 'OSS' is up to date. Retrieving repository 'PackmanE' metadata ..................................................[done] Building repository 'PackmanE' cache .......................................................[done] Retrieving repository 'Update' metadata ....................................................[done] Building repository 'Update' cache .........................................................[done] Retrieving repository 'UpdateBP' metadata ..................................................[done] Building repository 'UpdateBP' cache .......................................................[done] Retrieving repository 'UpdateNonOSS' metadata ..............................................[done] Building repository 'UpdateNonOSS' cache ...................................................[done] All repositories have been refreshed. real 0m27.997s user 0m2.711s sys 0m0.890s # zypper lr Repository priorities in effect: (See 'zypper lr -P' for details) 72 (raised priority) : 1 repository 90 (raised priority) : 1 repository 99 (default priority) : 8 repositories # | Enabled | GPG Check | URI ---+---------+-----------+------------------------------------------------------------------------ 1 | Yes | ( p) Yes | http://silk.apana.org.au/rpm-opensuse15-unstable-dev 2 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.3/ 3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.3/ 4 | Yes | (r ) Yes | http://download.opensuse.org/distribution/leap/15.3/repo/non-oss/ 5 | Yes | (r ) Yes | http://download.opensuse.org/distribution/leap/15.3/repo/oss/ 6 | Yes | (r ) Yes | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_Leap_15.3/Essentials 7 | Yes | (r ) Yes | http://download.opensuse.org/update/leap/15.3/oss/ 8 | Yes | (r ) Yes | http://download.opensuse.org/update/leap/15.3/backports/ 9 | Yes | (r ) Yes | http://download.opensuse.org/update/leap/15.3/non-oss/ 10 | Yes | ( p) Yes | http://download.opensuse.org/update/leap/15.3/sle/ # time zypper ref Repository 'FCL' is up to date. Repository 'KDE3' is up to date. Repository 'Mozilla' is up to date. Repository 'NonOSS' is up to date. Repository 'OSS' is up to date. Repository 'PackmanE' is up to date. Repository 'Update' is up to date. Repository 'UpdateBP' is up to date. Repository 'UpdateNonOSS' is up to date. Retrieving repository 'UpdateSLE' metadata .................................................[done] Building repository 'UpdateSLE' cache ......................................................[done] All repositories have been refreshed. real 1m2.752s user 0m23.481s sys 0m2.810s # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

3 3

Reminder: All SLE 15 SP5 feature requests need to be evaluated until 29th July (this Friday)
by Lubos Kocman 25 Jul '22

25 Jul '22

Hello openSUSE! To start on a positive note, this deadline does not apply for Community/Leap only changes, which do not require any changes on the SLE side. There, we have time until the Beta code submission deadline next year. So this deadline is really for Leap changes that are otherwise blocked by SLES or generally any update requests to SLES. These requests need to be evaluated (in jira) and moved to engineering, which means to be approved by SLES product and project management. I went through all community requested features in *code-o-o, and so far, all should be processed. Each of Leap 15.5 features touching SLE packages should have linked Jira (done by me). Please reach out to me if I missed your feature. If you have anything last minute, then please report it in code-o-o, provide quick summary (see mdadm update request as an *example) why is the change needed and reach out to me as quickly as possible. Otherwise, PM might not get to evaluate it on time, and it will be tracked as a late feature. Late feature is not a big deal, but it also might simply not be approved later on, especially if it's a more significant change. Keep in mind that 15.5/15 SP5 is expected to be a conservative release. Let's rather be on the safe side, report it early. Leap 15.5 has not yet bugs in *Bugzilla, so checking for any "masked feature request" was quick. (Original 15.5 early planning call) https://lists.opensuse.org/archives/list/project@lists.opensuse.org/thread/… Thank you very much for your understanding Lubos Kocman openSUSE Leap Release Manager [0]https://en.opensuse.org/openSUSE:Roadmap [1]https://code.opensuse.org/leap/features/issues [2]https://code.opensuse.org/leap/features/issue/82 [3]https://bugzilla.opensuse.org/buglist.cgi?cmdtype=dorem&remaction=run&nam…

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 24 Jul '22

24 Jul '22

Jiri Slaby <jslaby(a)suse.cz> writes: > On 05. 07. 22, 17:46, Dan Čermák wrote: >> we have mostly focused this week's meeting on how the ALP Desktop is >> going to look like and how we can dispel fears around flatpaks and >> containers when it comes to the ALP desktop. > > I have never looked into this container stuff in more detail. But one of > the concerns I was always afraid of was how this behaves WRT shared > libraries and their memory footprint? IOW, containers kill the purpose > of shlibs completely and one has to hold all of the versions (per each > container on the top of ones from the base system) in memory, right? > This sounds as if using static libraries. A small follow up on this one, more in the context of flatpaks though. The question has been raised, whether flatpaks sharing a runtime would benefit from memory deduplication of shared libraries in the common runtime. The short answer is: yes. The longer and much more elaborate answer can be found in this great reply from upstream: https://github.com/flatpak/flatpak/issues/4997#issuecomment-1192616912 So as long as we don't stop dynamically linking, there shouldn't be any huge memory penalties for flatpak applications. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP Git-Packaging-Workflow group created
by Neal Gompa 21 Jul '22

21 Jul '22

On Wed, Jul 20, 2022 at 8:44 AM Jan Engelhardt <jengelh(a)inai.de> wrote: > > > On Wednesday 2022-07-20 14:13, Dirk Müller wrote: > > > >* Exploration of the Git Hosting options (run by me) openSUSE already has some > >experience with Pagure.io (used by https://code.opensuse.org/ for example) and > >GitHub (used by various openSUSE projects under https://github.com/openSUSE) > >as well as some projects also in GitLab (used by a few community efforts as > >well as SUSE-internally for hosting) so we explored another option named > >Gitea, which is now available to the community under > >https://gitea.opensuse.org/. > > gitea with the lfs approach works well. > > I wonder how the ipfs symlinks stored in pagure would be handled. > Fuse mount, or another global hook like git-lfs? > Right now, we don't have any blob storage system attached to Pagure. We can do whatever we want for this. Fedora's Dist-Git setup[0] leverages a wrapper tool called fedpkg[1] built on the rpkg[2] framework. We don't have to do it the same way, but there are a lot of nice things from having a swiss army knife tool for packaging. We have this today with OBS through osc, for example. After working with Git-LFS for years for normal development, I'm not a huge fan of it. A couple of issues I have with LFS: * It's incredibly difficult to mirror LFS, and there's no straightforward way to do it with git repos, given how the integration works * LFS easily breaks when modifications occur across forks, and it's difficult to identify the problems there and fix them There are other issues that happen specific to LFS server implementations. For example, GitLab's implementation imposes ACLs on each blob which makes it difficult for forks made by non-members to work reliably. GitHub's implementation has issues where smudging can be broken when doing complex merges that have LFS objects touched. For some of the awkwardness around Dist-Git, these problems don't happen because it's a transparent blob cache and the only thing written to Git is a plain text file with the filename and checksum, which is used as the blob reference. Authorization to upload and download those blobs is controlled by packager ACLs or whatever you wish to use to control that, making it effectively global, so it works properly across forks, or even cross-server forks. With my downstream hat, that's also useful if I'm building patched derivative packages, because I can use the Dist-Git server references even without my own Git repo on my own Git server. It makes CI and all kinds of other things easier too. [0]: https://github.com/release-engineering/dist-git [1]: https://pagure.io/fedpkg [2]: https://pagure.io/rpkg > >* Exploration of the history import from the SUSE and openSUSE build service > >source history [...] > >Your feedback on the history import quality and how it could be made > >better is very much > >appreciated. > > I would make the case that OBS history is not particularly interesting > for its messages, because (a) we have had .changes files, > (b) the SVN-ish nature of the OBS SCM meant that you can't go back > and edit messages or commits, so there is little incentive to write > up much if you missed it in the first commit. The history is better than nothing because things like Git blame work reasonably okay. When Bernhard was working on the original setup, he didn't bother because it was a read-only setup. If we transition to Git, we probably want the attribution and messages to be more accurate because the Git history is useful for working through the package's development. It would also open the door for things like rpmautospec to be used in the future[3]. [3]: https://docs.pagure.org/Fedora-Infra.rpmautospec/ -- 真実はいつも一つ！/ Always, there's only one truth!

3 3