September 2020 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] New submit request workflow for Jump, publicly available builds
by Lubos Kocman 02 Sep '20

02 Sep '20

Hello openSUSE! I do have some exciting news to share! TLDR: openSUSE Jump builds will be now publicly available, jira.suse.com access for contributors in 5 weeks, OBS submissions against SLE packages will be submitted against Jump and mirrored in IBS. Any updates on request will be then synced outside (bi-directional sync). Proposed workflow received thumbs up from Maintenance and SLE Release Management. https://github.com/openSUSE/CommunitySLEFeatureRequests/blob/master/images/… First, I'd like to announce that we'll start publishing images and FTP trees for openSUSE Jump*, so people can get their hands on. Please be aware that Jump is still in Alpha quality. I expect data to be available later this week as there is still pending work on pontifex by Heroes. https://build.opensuse.org/project/show/openSUSE:Jump:15.2 Second, I've agreed on ETA of 5 weeks for the initial availability of JIRA partner access to openSUSE Contributors (JIRA-722). In this way, we can have transparent handling of feature requests, just like for any other SUSE partner. I hope that this brings some more transparency and self-service for SLE -> openSUSE feature requests. TAM for openSUSE (Lubos) will be in charge of controlling the access. We'll initially have rather a smaller pool of users (initially 10) and will grow it over time based on the popularity. Just FYI: The standard size of the pool for partners is 2, so openSUSE is being taken seriously as a partner here. Second, the proposal of the new submission model for the openSUSE Jump and it's SUSE Linux Enterprise part was accepted well by the Maintenance team and SLE Release management, therefore **I'd like to hear your opinion**. My hard requirement is that we will NOT reject submissions just because it's a submission against an SLE package. My attept to capture is here https://github.com/openSUSE/CommunitySLEFeatureRequests/blob/master/images/… (also available in drawio and png). Log story short, an openSUSE contributor would always submit code against a single project. Let's say openSUSE:Jump:15.2 for now (later Leap). Code submission would then get redirected to a proper origin (Backports, Leap, SLE). The tool for SR redirection is already in place (OBS-59). Origin options: openSUSE Backports (for the majority of Leap packages ~8k), openSUSE Leap (mostly branding packages, patterns, and SLE package forks of packages necessary to keep openSUSE Leap building ~100) SUSE Linux Enterprise (~4k packages, the core) Backports and openSUSE Leap code submissions will have pretty much the same experience as now. With the exception that you'll be able to use just one submit request target for more convenience and reusability as there will be one build used for both Package Hub and Leap. Submissions to SUSE Linux Enterprise will get more transparent. I'd really like to ask you to look at it as a good starting point. I see it as a big improvement from what we have now since you'll be now able to see behind the scenes. This all is constantly happening, you were just not able to see it before. This would be more or less a regular way to update an SLE package. 0) The contributor reports a bug or logs in to jira.suse.com and files a partner feature request for new features. JIRA request can still be created by TAM (Lubos) if there would be any problem (e.g. missing access etc). User (and other openSUSE contributors who requested JIRA access) see updates in JIRA. 1) TAM reviews feature and reject with reasoning or gives it a go and passes it for further evaluation. 1) The contributor submits code against openSUSE:Jump:15.2 (later Leap), optionally references openSUSE Partner JIRA feature (see my note on JIRA access) or a bug 2) openSUSE Release team reviews a new type of review let's refer to it as an "openSUSE Jump" review for now. 3) Approved submissions will get mirrored (OBS-63) from OBS to IBS (Internal SUSE OBS instance) with bi-directional sync on comments, updates for full transparency so the contributor can see progress on the submission by himself. 4) Submission gets processed by SLE Release Management or Maintenance team based on the origin (see my note below). At this point, it's either rejected or passed on staging for pre- integration tests. Reject reasons might be not following (not a full list) Failed code review such as skipping Factory First, mandatory 4 eyes review, etc. Change is past the code-submission deadline Missing approval on a feature, ECO or a missing issue reference Does not meet usual maintenance update criteria such as backward- incompatible update or would require a rebuild of a lot of packages Failed pre-integration testing. The reject reason would be communicated in the submission. Generally, the submission criteria would be the same as any SUSE employee. 5) openSUSE TAM (Lubos) optionally creates an ECO* to get approvals for feature requests in a late development phase or Maintenance updates. 6) Mirrored SR in IBS and Original SR (via bi-directional sync) gets accepted (or rejected). 7) The partner feature request is marked as Done or bug is marked as Resolved. Just one note on SLE Submit requests, which I believe will be a source of many conflicts. Submissions to SUSE Linux Enterprise* are a bit more tricky due to the project inheritance, as packages are coming from older SLE Service Packs, respective its ":Update" projects. That means that it won't be uncommon that the user will be submitting code against for an example openSUSE Leap 15.3 during the Early Alpha phase, however, in the end, it's going to be a submission for SUSE:SLE- 15-SP1:Update. Such submission may require additional ECO* approval or will result in a fork in the latest Service Pack of SLE. So I recommend all users to use "osc origin" to check where does the package come from, to avoid any surprises later on. And the last I'll check our wiki pages and make sure that the content is in alignment with the presented idea. https://en.opensuse.org/openSUSE:Submitting_feature_requests) https://en.opensuse.org/Portal:Leap/SLEFeatureRequests https://github.com/openSUSE/CommunitySLEFeatureRequests/ So what do you think? [0] openSUSE Jump https://en.opensuse.org/Portal:Leap:Jump [1] ECO - https://en.opensuse.org/ECO [2] The submit request will be mirrored in OBS under a different ID etc. but the state of original submission will be Accepted. [3] IBS - SUSE Internal OBS instance, that is used to build SUSE Linux Enterprise Thank you for your time

8 10

[opensuse-factory] Some missing path in $PATH when using sudo
by Marco Varlese 01 Sep '20

01 Sep '20

Hello All, I would like to share something with you which I was not aware of until this morning, and forgive me if this was known to most. The $PATH is missing /usr/local/bin and /usr/local/sbin paths; one thing I don't like about it is that there is an obvious different experience between "sudo" vs "su -". In fact, the latter does actually have the paths in the env variable. A possible workaround is to go with "sudo -i" which would preserve the user paths but may not necessarily be the user-experience we may want to give to new adopters: imagine the situation when somebody just starts playing with the OS, finding some instructions over the internet and try to execute them to see "what happens". :) So, here's the dilemma: would it make sense to add the two (missing) aforementioned paths to the sudoer's secure_path? I would welcome that as a better UX. Thanks for your consideration. Cheers, Marco -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Lifting restriction of Boolean Deps in Tumbleweed
by Dominique Leuenberger / DimStar 01 Sep '20

01 Sep '20

Dear Packagers and Devs, As we recently switched the rpm payload compression format to zstd, we had to give up 'zypper dup' compatibility from Leap < 15.2 to Tumbleweed. As we gave up on this compatibility, it is now time to also lift the limitation of using boolean dependencies. So far we only accepted boolean deps on Recommends: and Supplements: tags, but not on Requires:, as zypper dup could end up not being able to upgrade. Feel free to use those tags if they help you. Cheers, Dominique Boolean Deps Documentation: https://rpm.org/user_doc/boolean_dependencies.html

2 1

[opensuse-factory] Re: [opensuse-support] Re: openSUSE Tumbleweed installation blocked by "Wrong Digest" error
by S. 01 Sep '20

01 Sep '20

>> Warning: Digest verification failed for file 'susedata.xml.gz' >> [/var/tmp/AP_0xlApxLV/repodata/susedata.xml.gz] > And this is the problem, the file is bad Yes, this appears to be the real problem. I checked that they haven't changed their repo signing key, as I have a backup copy of it and I checked it against the current one. Could it be that they signed `susedata.xml.gz` with the wrong key? I don't really understand PGP all that well... But the repo contents are indeed still downloadable if you know the exact path/name. For example: https://download.nvidia.com/opensuse/tumbleweed/repodata/susedata.xml.gz The problem is that Zypper won't accept it and it throws those scary errors. > and there is nothing we can do about it but report in bugzilla and wait. Did anybody already file a bug? This started late last week, I believe on Friday. It feels like they made a late Friday mistake and then took the weekend off and haven't noticed the problem yet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0