I came across
https://github.com/microsoft/rpmoci/blob/47443c4312505222460dfcd185308db7153897bb/src/lockfile/build.rs#L173
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2219#issuecomment-2303007254
You are receiving this because you a
> so I think this should be either a default thing in rebuilddb
On this topic, it would be a nontrivial hit to the ergonomics of default
container builds if we really start telling people to do:
`RUN dnf -y install foo && dnf clean all && rpm --fix-database`
So probably what should happen is d
@ffesti the issue I mentioned at Devconf.cz
That said...now that I'm digging in again to reproducible builds,
https://github.com/containers/buildah/issues/5592 is higher on my radar, but
this is probably in the top 5.
--
Reply to this email directly or view it on GitHub:
https://github.com/rp
> As such, moving to C++ now will probably make it harder to move to Rust later.
Well, maybe. My original comment here remember was about how we very
intentionally moved rpm-ostree to "C compiling as C++" explicitly to bridge
with cxx.rs. This...kind of worked in some ways, and definitely didn
> For starters, it's a show-stopper as a bootstrapping dependency for something
> as early in that chain as rpm.
(Threading this) do you have a link to these discussions? There's a *ton* of
work on bootstrapping Rust (and systems in general) on self-hosting
OSes/distributions. The [GUIX
one]
I have some experience with this; we did a similar thing in rpm-ostree starting
around https://github.com/coreos/rpm-ostree/pull/2336#issuecomment-739556744
The rationale there was actually to aid porting to Rust, because we could use
https://cxx.rs/
There were a lot of things there, see various
ostree always uses zero for mtime of files it writes because there are no
timestamps in the file format at all. And in order to have sharing via
hardlinks, there's then the question of what time to apply to that inode.
If there was a way in a Unix filesystem to have no timestamp at all, we'd
d
> But people consider both BUILDTIME and BUILDHOST very useful for figuring out
> where/when/who exactly build a package.
For Fedora using Koji, there is always exactly one Koji build for a given
NEVRA, and the server side metadata contains the build host.
--
Reply to this email directly or vi
xref https://github.com/containers/storage/pull/1608
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2637#issuecomment-1699140774
You are receiving this because you are subscribed to this thread.
Message ID:
It's worth noting that rpm-ostree has been isolating individual scripts (e.g.
`%post`) with bwrap for a long time now. That's distinct from the test suite
only usage here, but just FYI.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2
Well, the doc is talking all about sysusers.d, which is (today) only
implemented by systemd...
I coincidentally recently did https://github.com/ostreedev/ostree/pull/2914
which updates the ostree equivalent of this section, and intentionally talked
about `DynamicUser=yes` there because it entir
Because it really is just better (where it's possible to use).
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2558
-- Commit Summary --
* docs/users_and_groups: Mention DynamicUser
-- File Changes --
M docs/manual/use
I referenced this effort in
https://marc.info/?l=linux-fsdevel&m=167794198604510&w=2 - my PoV is that the
rpm-cow effort makes some sense. I thought a lot though about hard requiring
reflinks for ostree though and determined it was not viable. There are too
many people that use e.g. ext4. An
> The existence of .sqlite-shm is required for read-only WAL mode to work at
> all (a very important use-case being queries by regular users), see
> https://www.sqlite.org/wal.html#read_only_database
I find this weird - because unprivileged code can't write directly to the
database, what practi
This is a followup to
https://github.com/rpm-software-management/rpm/commit/71456f2fc09900a027a33dc3d6d75c69a9b39488
which is about generating bit-for-bit reproducible images (container/disk) that
include an RPM database.
At the time, the person working on that PR was looking at RHEL8 (BDB forma
On Mon, Jan 3, 2022, at 2:44 AM, Panu Matilainen wrote:
> On 12/16/21 16:41, Colin Walters wrote:
>
>> I didn't wake up one day and say "hey you know what, today I'm going to move
>> the rpm database just for fun". Neither, for that matter did the Op
On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote:
> * Chris Murphy:
>
>> Fedora 36 seems like a good time to do this. What do you think?
>
> It's a bit odd to locate a database under /usr that isn't pre-built and
> installed.
Why is that odd?
> I guess in theory there could be system
On Thu, Dec 9, 2021, at 10:11 AM, Chris Murphy wrote:
>> The change is not so simple. It is not only the movement of files from one
>> location to another one. We store more types of data in that location -
>> history database (sqlite), module failsafe data (yamls). In future we will
>> stor
I think this is a nuanced topic. Very recently, I started regretting an
assertion we added in rpm-ostree (not a library, but a daemon providing a
service, so acts like a library in some ways). It's tangentially related to
rpm actually, over here: https://github.com/coreos/rpm-ostree/pull/3183
@cgwalters commented on this pull request.
Thank you so much for working on this!
> @@ -1296,3 +1296,30 @@ rpmtxn rpmtxnEnd(rpmtxn txn)
}
return NULL;
}
+
+#define FAKE_CLOCK_INITIALIZED (1<<0)
+#define FAKE_CLOCK_ACTIVE (1<<1)
+
+static int _fakeClockState = 0;
+static time_t _fa
> OK, so this is strange. The dnf update command in the image fails with
> getaddrinfo() thread failed to start, see the CI logs below. I can reproduce
> this locally, but with Docker only.
https://bugzilla.redhat.com/show_bug.cgi?id=1958474 probably.
--
You are receiving this because you are
Related discussion of this over here
https://github.com/ostreedev/ostree/pull/2260
--
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/1598#issuecomment-872509233___
Big picture I'd summarize this as: You're proposing a big alternative way to
handle RPMs that only works on reflink-enabled filesystems.
But the basic fact is that there's widespread use of non-reflink filesystems
(ext4, older xfs) on Linux in general. Even if this code was 100% complete and
t
This seems related to
https://github.com/rpm-software-management/rpm/commit/56f49d7f5af7c1c8a3eb478431356195adbfdd25
- in rpm-ostree for example the atomicity of the rpmdb is also done alongside
the filesystem too - if we don't have a `SIGINT` handler then we shouldn't have
an `atexit` handler
@cgwalters approved this pull request.
Gave this a quick test and it works for me.Thanks!
--
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/1657#pullrequestreview-64589
See https://github.com/coreos/rpm-ostree/issues/2458
Basically it'd be inefficient for rpm-ostree to use rpm2archive today because
it always compresses the output which we'd need to immediately uncompress again.
I looked at patch for this but got slightly lost in learning the ins&outs of
popt ar
FWIW in rpm-ostree we reimplement most of the RPM install path for multiple
reasons (among them we "snapshot" multiple RPM versions into ostree commits as
part of implementing transactional updates, we want to sandbox scripts etc.)
but another big reason is that we simply cannot have librpm call
There's a recent [change to add volatile to
overlayfs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c86243b090bc)
which will mostly mitigate this, although overlayfs isn't available to
unprivileged code paths right now.
I guess in the end it is easier to just ch
> Are you aware of https://github.com/kjn/nosync
Looks like the same as what I mentioned above originally:
> I know about things like libeatmydata but the problem of course is that
> librpm is linked into the same process (rpm-ostree) as the code that is doing
> the ostree commit.
--
You ar
For rpm-ostree, we rely on ostree for transactionality - ostree does fsync (or
not) per its configuration.
As best I can tell, rpm doesn't offer an API to disable its use of fsync (for
the database or for writing files, though I only really care about the former).
There are references to `nofs
> imposes its own signal handling on users when the db is open
Can turn that off since 56f49d7f5af7c1c8a3eb478431356195adbfdd25 right?
> and our ABI hasn't been particularly stable historically
Maintaining C shared libraries is indeed extremely hard. I've messed up in the
past and only just ba
Just to echo
https://github.com/rpm-software-management/rpm/pull/1255#issuecomment-645103007
here - inotify is used today for e.g. `/usr/share/applications` - when you e.g.
`zypper/apt/yum/whatever install firefox` that's how the desktops pick up the
change.
As far as portability, there are alr
> This isn't just for dnf's benefit. It's a mechanism that anybody who needs to
> do so is free to listen, and everybody else can ignore.
Speaking as a former DBus maintainer upstream here and I have written many DBus
APIs...
It seems dramatically simpler to me to go with the inotify approach,
> Well, we add this on request of the DNF team that need to be notified if
> something else (rpm cli) changes the rpmdb underneath their daemon.
Ah, I see. Well, nothing else can/should be changing the rpmdb on rpm-ostree
based systems (see also https://github.com/coreos/rpm-ostree/pull/1789 w
@cgwalters commented on this pull request.
> +state->logging = 1;
+
+/* ...don't log test transactions */
+if (rpmtsFlags(ts) & (RPMTRANS_FLAG_TEST|RPMTRANS_FLAG_BUILD_PROBS))
+ state->logging = 0;
+
+/* ...don't log chroot transactions */
+if (!rstreq(rpmtsRootDir(ts),
Is there any coordination between this and the work to add dbus to libdnf in
https://github.com/rpm-software-management/libdnf/pull/941 for example?
For rpm-ostree we are already a DBus daemon, and having multiple other
libraries in the stack also going out and talking to DBus is going to be a b
Just to xref, in ostree we recently merged an ed25519 signing system too: see
https://github.com/ostreedev/ostree/issues/1233
and https://github.com/ostreedev/ostree/pull/1878
The main motivation apparently is that GPG being lgplv3 and carrying the patent
clauses is problematic for some people m
Just to xref, since this one was closed the current plan is for rpm-ostree to
wrap rpm, instead of having rpm wrap rpm-ostree:
https://github.com/coreos/rpm-ostree/pull/1789
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> This is, however, a regression and places us in a difficult situation wrt
> packaging our tests.
You can just ship a tarball of this stuff instead right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/
> Make database backends self-aware
:cold_sweat:
--
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/910#issuecomment-544540645___
Maybe key off `rpmsqSetInterruptSafety()`? I don't think mock calls that yet
but it probably should.
--
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/900#issuecomment-54269
Oh wow. Is there a way for me to unconditionally turn this off in rpm-ostree?
Since our upgrades are always offline+transactional we never need it.
More generally, it seems like this plugin should be a no-op if we're installing
into a root != `/` for e.g. the mock case right?
--
You are rece
(Except I think that code is still not used by dnf because it dates to the
PackageKit C vs yum Python days?)
--
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/857#issuecommen
Also worth noting https://github.com/rpm-software-management/libdnf/issues/43
(libdnf auto-injects `/etc/pki/rpm-gpg`)
--
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/857#is
LGTM. Regarding
> The __thread uses in rpmsq don't make sense at all in reality, so better
> revert and rethink from scratch.
I don't know what all is writing/reading to those variables but, global mutable
statics are basically always wrong. In Rust for example a common pattern is
`lazy_sta
Can you keep the commit message title to < 80 chars? And move the text from
the PR description into the commit message as well.
Seems OK to me but: why don't the compilers do this by default?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or v
Keep in mind that if rpmbuild itself used container features it'd heavily
overlap with tools like `mock` - and while recursive containerization does
work, it really requires both ends to be ready for it.
See also https://github.com/projectatomic/bubblewrap/issues/284
--
You are receiving this
At a quick glance anyways, your code looks fine to me.
--
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/444#issuecomment-389980176
glib code here:
https://gitlab.gnome.org/GNOME/glib/blob/487b1fd20c5e494366a82ddc0fa6b53b8bd779ad/glib/gspawn.c#L1207
Also worth looking at what systemd does.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
FWIW, in rpm-ostree today we lay out all files before executing scripts. Then
we execute all `%pre`, then `%post` and `%posttrans`. Becuase of the `%pre`
-> passwd dependency, we then do chowns after `%pre`. Also, [speaking of
dependency loops and
scripts](https://github.com/projectatomic/r
More followup, just a FYI. Note that in this PR the whole of
/usr/lib/sysimage is just usr_t:
https://github.com/fedora-selinux/selinux-policy-contrib/pull/43
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-m
Updated :arrow_up: to use your suggestion - though can you help me understand:
what's the difference between "RPM" and "its source code"? Documentation?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rp
I was looking at this file in the context of dnf/rpm-ostree integration:
https://github.com/rpm-software-management/dnf/pull/991#issuecomment-355587679
The incorrect use of "it's" was distracting; I ended up rewording the initial
sentence to be more direct.
The second hunk is another grammar fix.
FYI:
https://src.fedoraproject.org/rpms/filesystem/pull-request/3
and
https://github.com/projectatomic/rpm-ostree/pull/1142
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[/me moves to center of thread, pulls out defibrillation machine, *zzzt* *zzzt*]
On Thu, Oct 26, 2017, at 04:59 AM, Richard Brown wrote:
>
> As we're pressed on time, openSUSE will be going right ahead and moving it's
> rpmdb to /usr/lib/sysimage/rpm as
> fast as possible
I assume this was done?
On Wed, Oct 18, 2017, at 06:56 AM, Panu Matilainen wrote:
> I don't see /usr/lib as a *good* place for this, but if a new top level
> directory in /usr seems too much then maybe /usr/lib/sysimage or such
I'm OK with /usr/lib/sysimage.
> As Neal pointed out, there's dpkg and the other package
On Thu, Oct 12, 2017, at 07:18 AM, Panu Matilainen wrote:
>
> Rpm is not the only data of this kind, I can think of at least one other
> similar need (SWID) and almost certainly there are more. Why not give
> this data a place of its own? Something like
>
> /usr/sysimage
Hm...creating a new su
On Tue, Oct 10, 2017, at 03:41 PM, Richard Brown wrote:
> On 2017-10-10 20:05, Colin Walters wrote:
>
> > My opinion here boils down to: if rpm upstream is happy with
> > /usr/lib/rpmdb,
> > I'm happy to do the work of changing rpm-ostree to use that.
>
> That
On Mon, Oct 9, 2017, at 11:25 AM, Richard Brown wrote:
> The discussion currently boils down to either copying rpm-ostree and placing
> our rpmdb in /usr/share/rpm, or
> locating it in /usr/lib/rpmdb
I definitely like the "db" suffix, makes it less of a potential naming clash if
librpm decided
> @cgwalters: This patch looks very specific to RPM-OSTree. Is there not a
> better, more general way to do this?
More general to...other image systems that happen to use rpm? Possibly. As
far as I'm aware though rpm-ostree is fairly unique in the way it's a hybrid
image/package system. I g
BTW, down the line I'd like to extend this ostree-detection functionality a bit
more so that e.g. `rpm -V` understands that timestamps are different, and
that's OK.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gi
In active use? I don't think there's that many. Certainly the original bug
report was from someone using dnf.
I just don't understand the logic for pushing this directly into librpm without
even making it configurable after all of the feedback from people using librpm
for higher level tools
Hi @herrold - I read your comment a few times and I'm confused...isn't that
what my patch is doing?
BTW, it's easy to try an rpm-ostree based system, see
https://getfedora.org/atomic/ and https://pagure.io/workstation-ostree-config
for example. One thing I'd note though is that the rpm databas
Down the line, it's likely that for rpm-ostree based systems we'll
install an interceptor for `/usr/bin/rpm` to redirect at least things
like local package installs. There's a lot of work to do for
that, so in the meantime let's help admins out by giving them a
helpful error message.
You can view,
This PR rolls in https://github.com/rpm-software-management/rpm/pull/319
After:
```
# rpm -e atomic
error: This system is managed by rpm-ostree
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Read-only file
system)
```
This is still a WIP/RFE - the code here isn't pretty obviousl
I was actually testing a change to better handle `rpm -e atomic` on Fedora
Atomic Host, wondering why my patch was crashing, but in fact it was the
recently added sync code in master.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/p
Anyone (including you) could trivially submit a patch to dnf or whatever to
call `sync` after transactions and have that ship to users pretty quickly if
that's what you want. That'd address the original bug report, no?
Why should this be hardcoded in librpm?
--
You are receiving this because
Or stated another way, if you change dnf it'd feel for the vast majority of
people that it defaults to on, and do so pretty quickly. Right?
--
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-man
https://github.com/rpm-software-management/rpm/pull/318
--
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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#commitcomment-24120847
This reverts commit b7a869f0f322cbe428e78150f2c175abea4c8c4b.
This would need to be at a minimum configurable, and default to off for
compatibility with software like rpm-ostree that is already taking care of all
of this.
You can view, comment on, or merge this pull request online at:
https://g
BTW, see also https://github.com/ostreedev/ostree/pull/1049
--
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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#commitcomment-24120807
rpm-ostree also has its own `syncfs()` calls and we definitely don't want
librpm doing it.
--
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/commit/b7a869f0f322cbe428e78150f2c175a
> all file operations are durable (in the sense that all installed files are
> known written to disk).
Right now many real world systems rely on files written by scripts (for
example, the bootloader configuration, `/etc/ld.so.cache`, etc.); librpm as
designed today doesn't have visibility into
cgwalters commented on this pull request.
> @@ -0,0 +1,49 @@
+FROM fedora
+MAINTAINER Igor Gnatenko
+
+WORKDIR /opt/rpm
+COPY . .
+
+RUN echo -e "deltarpm=0\ninstall_weak_deps=0\ntsflags=nodocs" >>
/etc/dnf/dnf.conf
+RUN dnf -y update
+RUN dnf -y install \
Which calls into this:
https://gith
cgwalters commented on this pull request.
> @@ -0,0 +1,49 @@
+FROM fedora
+MAINTAINER Igor Gnatenko
+
+WORKDIR /opt/rpm
+COPY . .
+
+RUN echo -e "deltarpm=0\ninstall_weak_deps=0\ntsflags=nodocs" >>
/etc/dnf/dnf.conf
+RUN dnf -y update
+RUN dnf -y install \
In some [PAPR](https://github.com/pr
Just a note to remember that for generating new roots (i.e. not inplace
upgrades), we can just let SIGINT kill us. For rpm-ostree, every operation is
a new root, so we [turn off rpm's SIGINT
completely](https://github.com/projectatomic/rpm-ostree/commit/ddf2227ae9a7d91b8e7e580dbe8c5d21120d24d6)
@n3npq Regarding full-system durability - I'm the maintainer of
https://github.com/projectatomic/rpm-ostree/ which uses
https://github.com/ostreedev/ostree/ to implement full-system transactional
updates. Every change (package install, update) is atomic. libostree
currently [stages objects pe
@jaymzh But are your tests with a kernel with the writeback changes or not? It
looks like this commit?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e34cbd307477ae07c5d8a8d0bd15e65a9ddaba5c
Which offhand appears to be in v4.10. Ah yes, [kernelnewbies has a
link
Isn't this https://lwn.net/Articles/682582/ ?
--
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/187#issuecomment-294231945___
Rpm-m
Okay, but that'd also be caught by MD5, right? So...do we expect every package
system to verify *both* the rpm-md checksum and this one? Running SHA256 or
whatever *is* pretty cheap, I know.
Perhaps enough people rely on "untrusted rpm-md fetched over http + GPG signed
RPMs" that we have to f
In practice though, people shouldn't be using raw `rpm` to install RPMs. They
should (and 90% of the time are) using a higher level system like zypper, yum,
or rpm-ostree.
These systems all consume "rpm-md/yum" metadata, which obviously today has a
checksum over the content, which can be ver
Need to check if this happens before GPG verification.
--
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/133#issuecomment-275155371__
Under what conditions? An aggressive seccomp policy?
--
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/132#issuecomment-274226643_
I think the solution is to not try to improve RPM here, just do what everyone
in the world that hit this has done: move to generating specs via a better
build system.
Examples:
- [Yocto/OpenEmbeded](https://www.yoctoproject.org/)
- [Clear Linux autospec](https://github.com/clearlinux/autospec
Any chance you could set up Jenkins against e.g. your personal fork of the repo
and test things there first?
---
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/67#issuecomment
Note I don't care about transaction locking - everything rpm-ostree does is
always atomic. We create a new (hardlinked) tree, then a new rpmdb from
scratch every time.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/52#issuecomment-1745
I ended up storing lead/sig/header in the ostree commit, then checking it out
as a tempfile and passing it back to librpm. So we can close this.
Long term, I think what I really want is to make `rpmdbOpen` and `rpmdbAdd`
public. Then I can stay out of the business of writing to the db and deal
Closed #52.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/52#event-524294958___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Ideally, we just let `mmap()` handle that. That's what OSTree does for
metadata by default. It'd probably work for packed RPMs as well...except in
practice we byteswap in `regionSwab()` so require a writable mapping =/ For
OSTree, GVariant handles a lot of this automatically for interior data
I'm working on some custom rpm-ostree code to "install" rpms by
unpacking them with libarchive (since this can be a lot safer than
invoking librpm - my process has total control over writes), then just
using librpm to update the database via _JUSTDB.
However, it appears that for some reason that i
Is there a reason for `runImmedFileTriggers` not to chroot?
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/43#issuecomment-170393488___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lis
Looks sane to me, FWIW.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/34#issuecomment-158985853___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
On Tue, Jan 27, 2015, at 10:04 AM, f...@linux.vnet.ibm.com wrote:
> IMA-appraisal, upstreamed in linux-3.7, enforces local file integrity based on
> a known 'good' value stored as an extended attribute 'security.ima'. Labeling
> the filesystem is currently done post install using a local private ke
On Tue, Feb 17, 2015, at 07:07 AM, Florian Festi wrote:
> Sorry, for the last response. DevConf takes its toll...
>
> On 01/23/2015 04:07 AM, Colin Walters wrote:
> > Numerous consumers of librpm use it in a pattern where they're
> > constructing fresh chroots. For ex
On Wed, Aug 13, 2014, at 07:12 AM, bmorb...@redhat.com wrote:
> This ensures that rebuilds of an srpm result in the same .py{c,o} files,
> even if the source files were modified during the build.
> This should make the builds of most python packages reproducible.
I like the idea here. Timestamps
transaction. We could change
librpm to automatically delete /etc/ld.so.cache and force the
search-all-the-paths mode of the dynamic linker until the end. I doubt
anyone would notice the difference.
On Wed, Apr 23, 2014, at 08:13 AM, Colin Walters wrote:
> Hi,
>
> For the rpm-ostree projec
hanged, 18 insertions(+)
From cb6f9a97baa4022789b469881bbc87aa1fb86697 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Thu, 22 Jan 2015 17:57:14 -0500
Subject: [PATCH] Add API to completely disable librpm's use of Unix signal
handlers
Numerous consumers of librpm use it in a patter
Hi,
See: https://bugs.freedesktop.org/show_bug.cgi?id=70366
TL;DR: Should triggers like ldconfig, gtk-update-icon-cache, and
update-mime-database:
1) Not fsync, and honor an environment variable like
PKGSYSTEM_ENABLE_FSYNC
2) Do fsync, and honor PKGSYSTEM_DISABLE_FSYNC
3) Something else?
Hi,
For the rpm-ostree project, I need the ability to whitelist scriptlets.
There are a few reasons for this, but the most critical is that due to
the way OSTree uses hardlinks, and because I can't assume I have
copy-on-write links, I need to know that scriptlets will cleanly break
hardlinks
On Tue, Jan 28, 2014 at 4:16 AM, Panu Matilainen
wrote:
Rpm 4.6 - 4.11.0 are buggy on non-trivial nsswitch setups due to my
less-than-brilliant idea (wish I knew what I was thinking at the
time...) See
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=abbf4897db217b4977b4c21eb09929c797ee015d.
1 - 100 of 103 matches
Mail list logo