Closed #1214.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1214#event-3396480725___
Rpm-maint mailing list
@ignatenkobrain approved this pull request.
LGTM
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Just to add this here, too: ts.addErase returns an error code. False aka 0 is
the erase element could be added and True aka 1 of it can't. DNF is ignoring
this. So the transaction element is not disappearing - it is not created in the
first place. I can't really see where RPM is at fault here.
This fixes installing rpm-plugin-selinux.8 even when using configure
--disable-selinux
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1247
-- Commit Summary --
* only install rpm-plugin-selinux.8 if enabled
-- File
This fixes installing rpm-plugin-selinux.8 even when using configure
--disable-selinux
(cherry picked from commit 35c7190a78488a84155d21bb4e7335ced98bba26)
Basically a backport of pull #1247 …
You can view, comment on, or merge this pull request online at:
The behavior depends on *when* that somebody else does stuff behind your back
though - it can easily happen *after* you added stuff to the transaction, in
which case you indeed don't receive any errors.
This goes to all sorts of other things too: if you assume lockless operation
between
So... rpmtsCheck() should be performed once with the transaction lock held, and
additionally we should check that conditions haven't otherwise changed in the
meanwhile. Including but not limited to packages that are to be erased didn't
go away.
Getting it all done and right is a non-trivial
@pmatilai I've taken a different approach (by re-introducing the pipe), details
in the commit message. Please review when you get a chance. Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
If we went this way then we'd need to add similar conditions for most of the
plugin manuals. I'm not sure it's worth it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Backports to other branches are considered by the team centrally when preparing
releases, we don't generally take PR's on non-master branches. Thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1248.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1248#event-3396645707___
Rpm-maint mailing list
@dmnks pushed 2 commits.
9d638d25afc3f211671ce93192cf99af8a679948 GPG: Switch back to pipe(7) for
signing
c471ad104992c950e42afd12079c67c43642841e GPG: refactor: clean up exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
See https://bugzilla.redhat.com/show_bug.cgi?id=1816123 for initial request.
Using DBus would allow pushing even more information like what packages got
installed/removed etc.
This will be based on DBus signals as we (obviously) won't turn RPM into a
daemon. During the transaction signals are
Lest anybody think this is still open for debate, I'm closing this now.
The landscape is slowly, slowly changing of course and at the time we're about
to become the last autotools dinosaur on the boostrap field then we can look at
the situation again.
--
You are receiving this because you are
Closed #1209.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1209#event-3397804242___
Rpm-maint mailing list
> Ok, good. For now I think we need to concentrate on the fundamental problem
> of architecture dependency. While most architectures today use 4K pages,
> being common doesn't make it arch independent, and then there even are
> architectures where this is configurable (eg aarch64). A noarch
The code would only raise an exception if TransactionSetCore.addErase()
returned an error, but the catch is that with many kinds of argument
types wed silently skip the whole addition because no headers were found.
This looks to be a regression introduced some eleven years ago in
commit
Yes, there may be more holes. But here all these additional checks won't catch
anything unless DNF checks the return value of addErase. As RPM just doesn't
add the transaction element at all there is nothing to check later. One could
argue that rpm should just destroy the transaction but I'd
CMake is not required to bootstrap _openSUSE_. It is required for all other
ones using a libsolv-based package manager. RHEL/Fedora, OpenMandriva, Photon,
etc. require the package manager in the bootstrap cycle, so libsolv is part of
the bootstrap, which means CMake is already there.
--
You
This essentially adds a check ensuring removed packages still exist when
were about to commit to the transaction, ie that nobody removed the
package while we were enjoying the view.
RPMPROB_PKG_INSTALLED is (ab)used for the purpose here - its related to
the package install status anyhow
As the change here is between the libsolv transaction and the creation of the
rpm transaction checking for changes in the database can't really solve the
problems if done within rpm only. DNF could check the database after obtaining
the ts lock, but that's something we allow already - it's just
> That said, if people _really_ think Python is a problem, I'm all in favor of
> CMake here. The rest of the package manager stack maintained in this
> organization uses it. Heck, openSUSE's Zypper uses it!
Weak argument: libzypp/zypper are not needed to bootstrap a distro (but we
already have
Merged #1250 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1250#event-3397654265___
Rpm-maint mailing list
> There are 3 things I'd like to see fixed:
>
> * the traceback should say: `Cannot process Python package version: 0+unknown`
> * the build should abort on errors
> * the version is [actually
> valid](https://www.python.org/dev/peps/pep-0440/#local-version-identifiers)
First and last issue
> I have been thinking a fair bit about this and I see a couple of options:
>
> 1. We could in principle generate signatures for every supported page size.
> This would require adding more tags, ie. one for each page size.
> 2. Do not install signatures if the page size doesn't match the
Since commits [Place file signatures into the signature header where they
belong][1] applied, run `rpm -Kv **.rpm failed if signature header
is larger than 64KB. Here are steps:
1) A unsigned rpm package, the size is 227560 bytes
$ ls -al xz-src-5.2.5-r0.corei7_64.rpm
-rw---. 1 mockbuild 1000
26 matches
Mail list logo
