| 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:
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Their rpm is patched for weak deps.
An alternative would be to have a better check
|
|
|
|
|
|
| |
we were always defaulting to gzip format, whatever is the decompressor
specified in the archive
bug introduced in commit 18723d2d47f9e069667753703c12ba5139661957
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Resolves: mga#15350
|
| |
|
|
|
|
|
|
|
| |
Signatures can't be verified as pubkeys are not available, the code
ignores it but that broke with rpm 4.14 (mga#21886).
Switch to using rpmtsSetVSFlags and rpmReadPackageFile which should
work with older versions too.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 87dbde4f3b078173e53cd45cac000c2d2751b370.
Rationale: rpm got fixed
We could just initialize header to NULL but rpmReadPackageFile() is
supposed to always set a correct value, so keep as it in order to catch
another future perl regression
|
|
|
|
|
| |
This is a rpm-4.14 regression where rpmReadPackageFile() no longer
initialize the header when the pkg is corrupted
|
|
|
|
| |
it's now possible since perl-5.26.0-8.mga7
|
|
|
|
| |
This reverts commit 12ff33c3fbf1dfc2dce60f6a75bb546ca3bf6735.
|
|
|
|
| |
thus breaking support for rpm <= 4.13
|
| |
|
|
|
|
| |
rationale: we don't set any private data with rpmlogSetCallback()
|
|
|
|
|
|
| |
by reverting a bit of commit b0cd1853933d8c68610c9e173721525c6a17e8ce
that should have gone with along:
commit b5249dafb882fbc105f05853c80fd30503d57a3f
|
|
|
|
| |
use rpmTagGetValue() to get the char* name of the tag
|
| |
|
|
|
|
|
|
| |
thus enabling to report size of >4Gb packages (however insane this is):
rpmlib uses the old small tag for small packages and the new big tag for
big packages (mga#19571)
|
|
|
|
| |
Thus we use 64bit for package size on 32bit too, thanks to Math::Int64
|
|
|
|
| |
previously it was missing on 32bit arches
|
| |
|
| |
|
|
|
|
|
| |
RPMPROB_OBSOLETE was added in rpm-4.9.0 (5 years ago) but wasn't handled
until now
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for at least 12 years, since swiching rpm to 4.2
(see commit 60031191b7012fdfe8e1af6bd43ff9b36b0c5825)
$trans->check() failed to actually report issues
rationale: rpmtsCheck() only actually return !0 if it fails to open
rpmdb...
in order to check if any problem was found by rpmtsCheck(), one must call
retrieving the problem set with rpmtsProblems()
rpmtsCheck() success only means that the resolution was successfully
attempted for all packages in the set, which isn't that usefull...
this might help mga#15350...
|
| |
|
| |
|
|
|
|
| |
that's no more needed...
|
|
|
|
|
| |
This callback will be fired before each pkg being installed/removed
Needs rpm >= rpm-4.13.0-0.rc1.28
|
| |
|
|
|
|
| |
thus fixing unknown package name on erases (mga#15032)
|
| |
|
|
|
|
| |
fix a warning spot by Angelo Naselli
|
|
|
|
|
|
| |
this is needed after using POPi
bug introduced in commit 4294365db5d78909ae5a490e0714db379502cd80
|
|
|
|
| |
unlike recommends_nosense, it returns version too
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix by Panu Matilainen
When rpmlog() occurs, it now grabs a read/write lock on the log context
depending on whether it needs to save the log or not. The callback
executes while the context lock is held, so when one call
rpmlogMessage() or pretty much any rpmlog-related function from the
callback, it'll try to lock the context again. Which is okay as long as
rpmlog() only needed a read-lock on the context. However if it has a
write-lock then attempting to grab a read-lock for rpmlogMessage()
fails, but due to the largely missing error handling in rpmlog.c it
falls through to crash and burn.
The only reason we need to call rpmlogMessage() is that the callback
does not match the callback function type in rpm >= 4.6:
typedef int (*rpmlogCallback) (rpmlogRec rec, rpmlogCallbackData data);
We shouldn't call that from log callback.
We can avoid the issue by using rpmlogRecMessage() instead of
rpmlogMessage() inside the callback. These are not the same,
rpmlogRecMessage() returns the message of the *current* log event,
whereas rpmlogMessage() returns the last *saved* log event. Which might
not exist, might be from an earlier event or it might be the current
event.
...and it'll not only work in all rpm >= 4.6 versions, but also give
the actual log message at hand, instead of something that might have
happened in the past.
|
|
|
|
| |
aka having @recommends@ lines instead of @suggests@ ones
|
| |
|