Overview
Request 754693 superseded
- update to rpm-4.15.1
- Created by mlschroe
- In state superseded
- Supersedes 752366
- Superseded by 755872
[ 47s] error: line 55: Illegal char ')' (0x29) in: Obsoletes: pkgconfig(libssl) < 1.1.1d [ 47s] error: line 55: Only package names are allowed in Obsoletes: Obsoletes: pkgconfig(libssl) < 1.1.1d
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
dimstar_suse@zeus:~/Documents/osc/openSUSE:Factory/rpm> cat pythondistdeps.diff --- ./scripts/pythondistdeps.py.orig 2018-08-08 13:40:18.173941320 +0000 +++ ./scripts/pythondistdeps.py 2018-10-16 09:30:49.271004917 +0000 @@ -1,4 +1,3 @@ -#!/usr/bin/python # -*- coding: utf-8 -*- # # Copyright 2010 Per Øyvind Karlsen <proyvind@moondrake.org>
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:
- Fix shebang for pythondistdeps.py to use Python 3 + Modify patch: pythondistdeps.diff
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 point
This 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
Request History
mlschroe created request
- update to rpm-4.15.1
dimstar_suse set openSUSE:Factory:Staging:N as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:N"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:N"
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
dimstar accepted review
staging-bot declined review
sr#755845 has newer source and is from the same project
staging-bot declined request
sr#755845 has newer source and is from the same project
superseded by 755872
almost there.. just a few more failures:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:N/apache-ivy/standard/x86_64 CC @scarabeus_iv
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:N/glusterfs/standard/x86_64 CC @jengelh
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:N/geronimo-specs/standard/x86_64 CC @scarabeus_iv
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:N/salt/standard/x86_64 CC @PSuarezHernandez