| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example, the name extracted from a requirement of
"python3.10dist(fonttools[unicode])[>= 4.10]" was sometimes
"python3.10dist(fonttools" instead of the expected
"python3.10dist(fonttools[unicode])".
Code parsing such strings existed in many places, it now exists only
in 2 places, a perl version in Resolve.pm and a C version in URPM.xs.
Both codes used to handle both "foo >= 0" and "foo[>= 0]" but at least
the perl code seems to only call it on provides/conflicts/obsoletes
which are always using the second form so the support for it was
dropped from the perl version for the sake of simplicity.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Thus fixing "invalid line <@provides for huge pkgs"...
The fix in 5.221 was fixing emiting provides in synthesis for pkgs with
lot of provides, but neither URPM or urpmi testsuite uses such a pkg and
didn't catch that having those provides in synthesis would break reading
synthesis.
See commit 950d56e991d307b9b60bde8f51920bee3d1bc61c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale for the high bump:
Fixing the sorting on http://matrix.cpantesters.org/?dist=URPM
We switched to version object because that enables to have test versions to
test on CPAN testers (eg: 5.21.1, 5.21.2, .. .before releasing 5.22).
So we switched from 5.22 to v5.22.
See commit 7677ec9fe63dd33d125d19e1f9225c5b4d6d5f4a
See https://rt.cpan.org/Public/Bug/Display.html?id=127142
However v5.22.0 is less than 5.21 (interepreted as a floating point by perl):
perl -Mversion -E 'say version->new("v5.22")->numify'
5.022000
So we bumped the version from v5.28 to a much higer one.
However commit a58cf629be7e0d0512d6e1fd95c5004fb833c8c3 had a typo.
It clearly says we wanted to bump to v5.212.0, as 5.21 was the greatest
old-style version.
But it actually bumped to v5.122 whereas 5.122000 < 5.21:
$ perl -Mversion -E 'say version->new("v5.122")->numify'
5.122000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale:
when generating synthesys, there's one new pkg whose provides were not
emitted in synthesis because its provides would overflow the static
buffer by 2 bytes:
"buffer overflow: 131074 < 131072 for provides"
Also log when the buffer would be too small instead of silently ignoring
the issue.
The offending package is golang-github-azure-sdk-devel which has 2707
provides which translates to a 131074 characters line in synthesys.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3fac0be4adab0ee63b6473d613982b418cc7ab92 was not enough in iurt
case.
We must also ignore SRPM provides.
Rationale:
Since rpm-4.16+, rpmlib adds NEVR provides for all packages that would
be built into source rpm.
Thus we hit:
"installed package gdb-minimal-10.2-2.mga9.x86_64 is conflicting with gdb-11.1-1.mga9.src"
Because of "Conflicts: gdb-headless[> 10.2-2.mga9]"
Because gdb-11.1-1.mga9.src.rpm provides "gdb-headless = 11.1-1.mga9"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aka gdb.src would be conflicting with gdb-minimal which is required by debugedit:
"The following packages have to be removed for others to be upgraded:
debugedit-5.0-3.mga9.x86_64
(due to missing gdb-minimal)
gdb-minimal-10.2-2.mga9.x86_64
(due to conflicts with gdb-headless[> 10.2-2.mga9])
rpm-build-4.17.0-2.mga9.x86_64
(due to unsatisfied debugedit >= 0.3)"
Which happen because of this deps chain:
rpm-build -> debugedit -> gdb-minimal
Where gdb-minimal conflicts with:
$ rpm -q --conflicts gdb-minimal
gdb-headless < 10.2-2.mga9
gdb-headless > 10.2-2.mga9
Which of course conflicts if urpmi considers the *new* gdb... SRPM...
Sigh...
Extract of urpmi --debug log ala iurt:
selecting gdb-11.1-1.mga9.src
requiring bison,dejagnu,expat-devel,flex,fpc,gcc-gfortran,gcc-objc,gcc-plugins,guile3.0-devel,libbabeltrace-devel,libipt-devel,mpfr-devel,python3-devel,readline-devel[>= 6.2-4],rpm-devel,rust,sharutils,source-highlight-devel,texinfo,texinfo-tex,texlive,xxhash-devel for gdb-11.1-1.mga9.src
chosen lib64rpm-devel-4.17.0-2.mga9.x86_64 for rpm-devel
selecting lib64rpm-devel-4.17.0-2.mga9.x86_64
requiring devel(libcap(64bit)),devel(liblua-5.4(64bit)),devel(libmagic(64bit)),devel(libsqlite3(64bit)),lib64rpm9[== 1:4.17.0-2.mga9],lib64rpmbuild9[== 1:4.17.0-2.mga9],lib64rpmsign9[== 1:4.17.0-2.mga9],rpm[== 1:4.17.0-2.mga9] for lib64rpm-devel-4.17.0-2.mga9.x86_64
(...)
chosen lib64rpmbuild9-4.17.0-2.mga9.x86_64 for lib64rpmbuild9[== 1:4.17.0-2.mga9]
selecting lib64rpmbuild9-4.17.0-2.mga9.x86_64
set_rejected: lib64rpmbuild9-4.16.1.2-5.mga9.x86_64
(...)
installed rpm-build-4.16.1.2-5.mga9.x86_64 is conflicting because of unsatisfied lib64rpmbuild9[== 1:4.16.1.2]
promoting rpm-build-4.17.0-2.mga9.x86_64 because of conflict above
selecting rpm-build-4.17.0-2.mga9.x86_64
set_rejected: rpm-build-4.16.1.2-5.mga9.x86_64
requiring debugedit[>= 0.3] for rpm-build-4.17.0-2.mga9.x86_64
chosen debugedit-5.0-3.mga9.x86_64 for debugedit[>= 0.3]
selecting debugedit-5.0-3.mga9.x86_64
requiring gdb-minimal for debugedit-5.0-3.mga9.x86_64
gdb-minimal-10.2-2.mga9.x86_64 conflicts with already selected package gdb-11.1-1.mga9.src
Because it considered:
$VAR1 = [
'gdb-10.2-2.mga9.x86_64',
'gdb-10.2-2.mga9.i586',
'gdb-11.1-1.mga9.src'
];
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is needed in order to fix build for armv7hl on aarch64
|
|
|
|
|
|
|
| |
v5.28.0 is less than 5.21 (if interepreted as a floating point, which
perl always did).
So in order to to switch from old-style to new-style, we need to use at
least v5.212.0, as 5.21 was the greatest old-style version.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 47cea2a9de59f84e11e78a0bd8c2d4bf4c4a11cb.
Because of:
not ok 12 - no_symlinks
# Failed test 'no_symlinks'
# at t/03kwaility.t line 4.
# Error: This distribution includes symbolic links (symlinks). This is bad, because there are operating systems that do not handle symlinks.
# Details:
# The following symlinks were found: Changes
# Remedy: Remove the symlinks from the distribution.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
force using a version object
rationale:
- 4.12.0.2 < 4.12.90 will wrongly pass
- v4.12.0.2 < 4.12.90 will check as we expect
|
| |
|
| |
|
|
|
|
| |
It got broken in commit 9c8f8e738664f2905e3927e5806bb14da4a5272b (5.24)
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
rationale:
rpm-4.16 adds provides for all generated RPMS to SRPMs, which breaks
urpmi's testsuite (t/superuser--srpm-bootstrapping.t)
See rpm's commit 75ec16e660e784d7897b37cac1a2b9b135825f25
|
|
|
|
| |
by ensuring dumps are always sorted the same way instead of randomly
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|