Hi Dirk,
Am 10.01.22 um 12:58 schrieb Dirk Müller:
> On Montag, 10. Januar 2022 11:19:48 CET Simon Lees wrote:
>
>> In the past we have shipped similar updates to rpm-macros into the
>> Update repo and not released them to customers then with the updates
>> repo enabled they can still be used for builds. That is probably the
>> best solution to this problem or we update the wiki to indicate these
>> features don't exist in 15.3.
> untili recently we used to have devel:languages:python:backports:fixups to
> address python 3.6 issues in devel:languages:python:backports.
>
> I've been maintaining that for at least a year, if not two years, and kept
> things building in devel:languages:python:backports for 15.3.
>
> coming back from a two day vacation, I notice that all my projects have been
> deleted links, all the CI jobs have been red, and the project configuration has
> been completely changed, and now hundreds to thousands of build failures.
>
> Is there any chance that I can get back a working setup please? what issue has
> been tried to be solved with the changes and how can I get a state that works?
See my initial post about an explanation why you see "deleted" entries
in your projects. (I include :backports:fixups into the definition of
"your"). TL;DR: An overeager user managed to get his wish granted that
stuff got deleted. The restoration afterwards did not fix your now
broken projects.
You think can fix them by adjusting your meta configuration to
<repository name="15.3">
<path project="devel:languages:python:backports" repository="15.3"/>
<arch>x86_64</arch>
</repository>
<repository name="15.4">
<path project="devel:languages:python:backports" repository="15.4"/>
<arch>x86_64</arch>
</repository>
Also, as discussed in the thread, you probably want paths to the :Update
repos either in your projects or in d:l:p:backports directly.
- Ben
Am 09.01.22 um 05:13 schrieb Simon Lees:
>
> On 1/9/22 09:53, Matěj Cepl wrote:
>> Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a):
>>> The crucial part is the
>>>
>>> <path project="devel:languages:python:backports" repository="15.3"/>
>>>
>>> which is still missing in devel:languages:python.
>> Why should we put backports into regular devel project? I thought that
>> point of 15.3 repository in d:l:p is to show what is buildable on the
>> regular real Leap 15.3.
> The real main purpose was Leap users used to add d:l:p to there systems
> which would cause them to break in strange ways because it would always
> pull in packages that wouldn't work on there system.
>
> So Leap builds were disabled in d:l:p and backports was created just to
> have modules built against the actual python in leap so users could get
> the newer versions of the modules that would work with the distro python
> which generally breaks less things.
>
> In neither the use case you or I described is there a need for d:l:p to
> include d:l:p:backports so I also don't understand the use case, so what
> exactly is broken and how does this change fix it. On the other hand not
> having the Update target in 15.3 can cause issues. I'd use the following
> for example.
>
> <repository name="openSUSE_Backports_SLE-15-SP3">
> <path project="openSUSE:Backports:SLE-15-SP3:Update"
> repository="standard"/>
> <path project="openSUSE:Backports:SLE-15-SP3" repository="standard"/>
> <arch>x86_64</arch>
> </repository>
>
Starting at the point in time before the user's request started to break
everything, the question is rather, "why should we remove backports from
the regular devel project"?
Look at the "SLE_15_SP2". That's the state 15.3 also had before the
breakage. Remember the mentioned "deleted" entries, which you removed in
the meantime.
If you want to change policy and remove :backports these are some
consequences, visible in the current state:
1. All the packages directly in d:l:p use the current development state,
meant for Factory.
2. All packages outside of d:l:p, even those in d:l:p:numeric and most
importantly d:l:p:Factory are not considered.
3. Because of 2. python-rpm-macros is back at the old version from plain
15.3, which does not support newer features such as python_compile or
support for rewriting runtime rich boolean rpm dependencies. Reopen
boo#1887474.
4. The obs resolver cannot interpret the rich boolean dependencies using
the '%python' syntax in BuildRequires, because the prjconf from
:backports is not inherited.
The mix of 1. and 2. makes the SLE/Leap repositories in d:l:p totally
useless.
3. and 4. means that all specfiles using those features fail for SLE/Leap.
With all the "Python 3.6 is EOL" and "We don't want to support packages
for both 3.6 and 3.10 at the same time", maybe it is better to just
disable all SLE and Leap repositories in d:l:p*. Devel projects outside
of those namespace can use plain 15.3 or *:Update and see if it works
with the system shipped packages. If not, they have to maintain their
own set of backported packages compatible with each other. Sorry, Axel.
- Ben
* @Adrian: Why does the web interface not include :Update?
On 1/10/22 19:19, Matěj Cepl wrote:
> Dne 10. 01. 22 v 8:37 Simon Lees napsal(a):
>> Something along the lines of users kept adding d:l:p to there Leap
>> setups which would then cause unintended consequences as extra packages
>> would be swapped and many things would break. d:l:p then disabled
>> publishing for Leap to prevent this but some people inside SUSE needed
>> this and some people in the community weren't that happy, so backports
>> was created to 1. as Matej said meet the need of the people inside SUSE
>> and 2. to make it less likely that users who installed this repo would
>> completely break there systems.
>
> Let me suggest this two-fold solution:
>
> 1. We will stop publishing packages from Leap/SLE repositories of d:l:p.
> If you want to pull from d:l:p:* you have d:l:p:backports for it.
>
> 2. If there is any consensus, what should be added to project
> configuration of d:l:p:backports, I will gladly add it, just with the
> caveats mentioned before (absolutely not maintenance aside from running
> backports_repo.py from time to time, so that the packages there are just
> a mirror of packages in Factory).
>
> Any thoughts?
Sounds reasonable to me, from memory this resembles the setup we had
when backports was first created.
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Am Sonntag, 9. Januar 2022, 23:09:29 CET schrieb Matěj Cepl:
> Dne 09. 01. 22 v 5:13 Simon Lees napsal(a):
> > The real main purpose was Leap users used to add d:l:p to there systems
> > which would cause them to break in strange ways because it would always
> > pull in packages that wouldn't work on there system.
>
> That's the purpose I emphatically do not want to support. Devel projects
> are devel projects because they are for development of packages for
> Factory. That's it.
I feel this as well.
I try the following approach: include
<path project="openSUSE:Leap:15.3:Update" repository="standard"/>
as build target for 15.3, branch packages as required and potentially keep
them in an older state (supporting Py 3.6). Disable build for these packages
and other repos, namely TW.
This is not ideal, but at least allows to keep a working set of packages...
Cheers
Axe
Am Sonntag, 9. Januar 2022, 05:13:14 CET schrieb Simon Lees:
> In neither the use case you or I described is there a need for d:l:p to
> include d:l:p:backports so I also don't understand the use case, so what
> exactly is broken and how does this change fix it. On the other hand not
> having the Update target in 15.3 can cause issues. I'd use the following
> for example.
>
> <repository name="openSUSE_Backports_SLE-15-SP3">
> <path project="openSUSE:Backports:SLE-15-SP3:Update"
> repository="standard"/>
> <path project="openSUSE:Backports:SLE-15-SP3" repository="standard"/>
> <arch>x86_64</arch>
> </repository>
I tried different setups, but I always end up with unresolveables. Looks like
the Leap 15.3 setup was fixed to death (kaputt repariert as we say in DE)
I have opened
https://bugzilla.opensuse.org/show_bug.cgi?id=1194422
for this
Cheers
Axel
> On 1/9/22 09:53, Matěj Cepl wrote:
>> Dne 08. 01. 22 v 13:03 Ben Greiner napsal(a):
>> The crucial part is the
>>
>> <path project="devel:languages:python:backports" repository="15.3"/>
>>
>> which is still missing in devel:languages:python.
>
> Why should we put backports into regular devel project? I thought that
> point of 15.3 repository in d:l:p is to show what is buildable on the
> regular real Leap 15.3.
>
> The real main purpose was Leap users used to add d:l:p to there systems
> which would cause them to break in strange ways because it would always
> pull in packages that wouldn't work on there system.
So Leap builds were disabled in d:l:p and backports was created just to
have modules built against the actual python in leap so users could get
the newer versions of the modules that would work with the distro python
which generally breaks less things.
In neither the use case you or I described is there a need for d:l:p to
include d:l:p:backports so I also don't understand the use case, so what
exactly is broken and how does this change fix it. On the other hand not
having the Update target in 15.3 can cause issues. I'd use the following
for example.
<repository name="openSUSE_Backports_SLE-15-SP3">
<path project="openSUSE:Backports:SLE-15-SP3:Update"
repository="standard"/>
<path project="openSUSE:Backports:SLE-15-SP3" repository="standard"/>
<arch>x86_64</arch>
</repository>
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello,
Unfortunately, many builds for SLE and Leap in devel projects are
currently broken. This is a result from some back and forth changes of
enabled repositories in devel:languages:python:backports, which needs to
be corrected in a consistent way.*
Some history:
devel:languages:python:backports had several repositories for the
SLE/Leap 15 family enabled:
- SLE_15
- SLE_15_SP1
- SLE_15_SP2
- SLE_15_SP3
- openSUSE_Leap_15.2
- openSUSE_Leap_15.3
- (openSUSE_Leap_15.4, not sure if this ever existed)
- 15.3
- 15.4
Because of the unification between SLE and Leap from 15.3 onwards, some
of these are identical duplicates but create the duplicate workload for
the obs servers (all of Factory in this case!). So some time ago, there
was a survey and poll how newly enabled projects should name their
single SLE15SP3/Leap_15.3 repositories, and the decision was "15.3". I
can't find the reference right now. Unfortunately there is no guideline
or wiki page about it, only some mailinglist post. There was also a
discussion on the packaging ML earlier last month, without a clear
guideline.
As a consequence, the web interface only lets you create one "15.3"
repository, no matter on which distribution checkmark of the SLE/Leap
family you click:
<repository name="15.3">
<path project="openSUSE:Leap:15.3" repository="standard"/>
<arch>x86_64</arch>
</repository>
Now, devel:languages:python, some of the subprojects there and possible
other devel projects outside of this namespace had
devel:languages:python:backports in their path like this:
<repository name="15.3">
<path project="devel:languages:python:backports"
repository="TARGETREPO"/>
<path project="openSUSE:Leap:15.3" repository="standard"/>
<arch>x86_64</arch>
</repository>
Unfortunately, among projects, TARGETREPO was not used consistently as
"15.3" but used a variant of the duplicates above.
Enter some user** who wanted to get "his" project fixed. His request:
"Please delete the duplicates, please use openSUSE_Leap_15.3 as the
proper name." His request was granted by the project maintainer.
Unfortunately, this broke all the devel projects which used one of the
deleted repositories 15.3, including devel:languages:python. The meta
configuration now read:
<repository name="15.3">
<path project="deleted" repository="deleted" />
<path project="openSUSE:Leap:15.3" repository="standard"/>
<arch>x86_64</arch>
</repository>
Now, just re-adding 15.3 does not fix the "deleted" entries. You have to
fix it manually. So my request to fix the path entries and use the repo
names found by consensus was understood as to revert the previous users'
request and recreate the "15.3" and "15.4" repositories in
d:l:p:backports. On the other hand, openSUSE_Leap_15.3 and similar have
been removed again (as they would indeed be duplicates). Now of course
those projects having had those repositories in their path also have the
"deleted" entries, while those from the previous deleted still have it too.
In order to fix things and get consistent, I propose that all
maintainers of devel projects making use of
devel:languages:python:backports, devel:languages:python and any
transitive projects check their repository configuration and adjust
accordingly. In my eyes, the correct entries would be for all of them:
<repository name="15.3">
<path project="devel:languages:python:backports" repository="15.3"/>
<path project="openSUSE:Leap:15.3" repository="standard"/>
<arch>x86_64</arch>
</repository>
<repository name="15.4">
<path project="devel:languages:python:backports" repository="15.4"/>
<path project="openSUSE:Leap:15.4" repository="standard"/>
<arch>x86_64</arch>
</repository>
- Ben
[1]
https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/threa…
* Although the value of d:l:p:backports is vanishing fast anyway. Most
packages in Factory have already dropped or will drop soon support for
Python 3.6.
** name intentionally omitted, this is not a blame post but a request to
get the technical situation corrected.
HI!
Currently many Python packages cannot build on Tumbleweed and Factory
because of
"nothing provides python310-pytest"
Yes, I could work around this by explicitly skipping build for Python
3.10. But this needs modification of each .spec file.
Any solution for this?
Ciao, Michael.
