Overview
Request 752366 superseded
- update to rpm-4.15.1
- Created by mlschroe
- In state superseded
- Supersedes 749859
- Superseded by 754693
- Open review for openSUSE:Factory:Staging:N
Can we maybe make the /usr/lib -> /usr/libexec move in a 2nd step? RPM 4.15 with the parallel processing would be very nice to have - but with the libexecdir move will likely take 'forever'
Yeah, I suppose we could. I really want to get the new python dependency generator in ASAP for helping with supporting openSUSE as a target for upstream project CI, among other things.
Request History
mlschroe created request
- update to rpm-4.15.1
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
staging-bot set openSUSE:Factory:Staging:N as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:N"
staging-bot accepted review
Picked "openSUSE:Factory:Staging:N"
dimstar accepted review
superseded by 754693
Really?
Yes, obsoletes do not look at provides, thus the name part must be a valid package name.
Was that always the case? So those obsoletes simply did not have any effect? Or was this something zypp could handle in plus for us? I somewhat have the feeling like this did work
No, that was always the case (actually I'm lying, it's that way since 2010).
ok, that's always 'forever' - I'll try to find more cases with Obsoletes:.*( in spec files
> find -maxdepth 2 -name *.spec -exec grep -H "Obsoletes.*(" {} \; ./000release-packages/openSUSE-release.spec:Obsoletes: product_flavor(%{product}) < 20191202 ./libstorage-ng/libstorage-ng.spec:Obsoletes: libstorage %(echo `seq -s " " -f "libstorage%.f" 9`) ./glu/glu.spec:# O/P since 12.3. This Obsoletes is special (since glu is in fact Mesa), ./gtk2-engines/gtk2-engines.spec:# FIXME: On new version, change <= Obsoletes to < (last checked: 2.20.2) ./gtkspell/gtkspell.spec:# FIXME: Replace Obsoletes <= version with Obsoletes < version in libgtkspell0 subpackage on update (after 2.0.16) ./patterns-base/patterns-base.spec:Obsoletes: pattern() = readonly_root_tools ./libart_lgpl/libart_lgpl.spec:# NOTE: on upgrade to a new upstream version, change the Obsoletes from <= to < (here and in baselibs.conf) ./libglade2/libglade2.spec:# NOTE: on upgrade to a new upstream version, change the Obsoletes from <= to < (here and in baselibs.conf) ./libidl/libidl.spec:# NOTE: on upgrade to a new upstream version, change the Obsoletes from <= to < (here and in baselibs.conf) ./openssl/openssl.spec:Obsoletes: pkgconfig(libssl) < %{version} ./openssl/openssl.spec:Obsoletes: pkgconfig(libopenssl) < %{version} ./openssl/openssl.spec:Obsoletes: pkgconfig(libcrypto) < %{version} ./openssl/openssl.spec:Obsoletes: pkgconfig(openssl) < %{version} ./snapper/snapper.spec:Obsoletes: %(echo `seq -s " " -f "libsnapper%.f" $((4 - 1))`) ./libyui-ncurses-pkg/libyui-ncurses-pkg.spec:Obsoletes: %(echo `seq -s " " -f "libyui-ncurses-pkg%.f" $(expr %{so_version} - 1)`) ./libyui-qt-pkg/libyui-qt-pkg.spec:Obsoletes: %(echo `seq -s " " -f "libyui-qt-pkg%.f" $(expr %{so_version} - 1)`)Not that bad neither... should be fixable
[ 53s] error: Package perl-Test-CPAN-Meta: invalid utf-8 encoding in Changelogtext: - updated to 0.25
ok, that seems in line with what createrepo_c is heading too - but we have 12k packages with a chance to trip over this. I'm looking forward to it being broken (/sarcasm)
No need to worry, rpm shouldn't even see this. OBS' changelog2spec converter must only write valid utf8.
but it doesn't :)
e.g. https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:N/termcap/standard/x86_64
(I already submitted a fix for the packages I found with invalid changelogs - so we should be good for now)
Yeah, I know. We need to change the converter in obs-build.
(but the packages with broken utf8 need to be fixed anyway!)
Neither me nor the python maintainers are very happy with what the py-dep-generator produces here.
i.e, it introduces cycles between python-setuptools and python-six; other distros work around that by using embedded six in setuptools for example
Pardon my ignorance, but what exactly has changed with the update?
Possible...
in any case, it results in a lot of packages having a requires python3.7dist(six) - but this provides is not added to python3-six (as we can't pull in python3-setuptools there - this in turn would result in a cycle, as python3-setuptools BuildRequires -six)
so in essence: for the dep generator to be working properly, it has a too large dep chain it tries to pull in
What possibly could work is 'manually injecting the missing provides' into -six - to get thins moving, with the risk that formats change and the provides goes out-of-sync
/me debugged a bit - actually, what made the dep scanner not work before was
So we have a python script without any shebang - it's attempted to be executed as a bash script - yay
> /usr/lib/rpm/pythondistdeps.py /usr/lib/rpm/pythondistdeps.py: line 12: from: command not found /usr/lib/rpm/pythondistdeps.py: line 13: from: command not found /usr/lib/rpm/pythondistdeps.py: line 14: from: command not found /usr/lib/rpm/pythondistdeps.py: line 15: from: command not found /usr/lib/rpm/pythondistdeps.py: line 16: from: command not found /usr/lib/rpm/pythondistdeps.py: line 17: from: command not found /usr/lib/rpm/pythondistdeps.py: line 20: syntax error near unexpected token `(' /usr/lib/rpm/pythondistdeps.py: line 20: `opts, args = getopt('The current submission contains:
and the patch newly replaces /usr/bin/python with /usr/bin/python3 - thus actually having a valid python script that can be executed
I.e. is this because of the fix for the following issue? https://github.com/rpm-software-management/rpm/issues/664
Statement from the python maintainers:
13:31 < scarabeus> yea i can see it was a dumb bug but still I would rather propose not having the generator for now and introduce it when we can really review it 13:31 < scarabeus> ie after 3.8 is in TW and py2 removal is on the way 13:31 < scarabeus> we could add it to trello and basically work on it at some pointThis would basically mean to also serialize the fixing of pythondistdeps for after 4.15 is merged - and focus on the remaining issues to get the version update itself merged