Re: [Rpm-maint] Add appdata() and application() auto-provides

+ echo application() + echo application(${instfile##*/applications/}) if ! grep -q '^Type=Application$' $instfile; then continue; fi if ! grep -q '^Exec=' $instfile; then continue; fi Shouldn't these pairs of lines be swapped, so that we

[Rpm-maint] installroot and NSS modules

Hi, I'm working on https://mail.gnome.org/archives/ostree-list/2014-January/msg0.html and it has some code that uses yum --installroot. However, the system requires a custom nss-altfiles NSS module that causes /usr/sbin/useradd -r to write to /usr/lib/passwd. But rpm from the host side is

Re: [Rpm-maint] installroot and NSS modules

On Wed, 2014-01-08 at 15:06 -0500, Colin Walters wrote: But rpm from the host side is not correctly detecting these users. I realized after sending this sentence is unclear. More precisely, from the current polkit.spec: %attr(0700,polkitd,root) %dir %{_datadir}/polkit-1/rules.d rpm says

Re: [Rpm-maint] installroot and NSS modules

On Tue, Jan 28, 2014 at 4:16 AM, Panu Matilainen pmati...@laiskiainen.org 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

[Rpm-maint] whitelisting/wrapping script execution

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

[Rpm-maint] fsync and package systems

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?

[Rpm-maint] [PATCH] Add API to completely disable librpm's use of Unix signal handlers

insertions(+) From cb6f9a97baa4022789b469881bbc87aa1fb86697 Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org 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 pattern

Re: [Rpm-maint] whitelisting/wrapping script execution

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 project, I need the ability

Re: [Rpm-maint] [PATCH] Add API to completely disable librpm's use of Unix signal handlers

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 example, rpm-ostree operates

Re: [Rpm-maint] [RFC v5 00/11] RPM: Include and install file signatures

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 key.

[Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)

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

Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)

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

Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)

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

Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)

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

Re: [Rpm-maint] [rpm-software-management/rpm] testing GHPRB (#67)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] heap out of bounds read in copyTdEntry() (#133)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Check return value of uname() (#132)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add a digest on the compressed payload content (#163)

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

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add a digest on the compressed payload content (#163)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro to force fsync() on close() (#187)

@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

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro to force fsync() on close() (#187)

@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

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro to force fsync() on close() (#187)

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___

Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Semaphore CI (#266)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Semaphore CI (#266)

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

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

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

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

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's

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

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

Re: [Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

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

Re: [Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)

> @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

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

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

[Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)

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

[Rpm-maint] [rpm-software-management/rpm] lib/transaction: Don't SEGV in sync if a txn was failed (#319)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)

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

Re: [Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

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:

[Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

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:

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

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

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

[/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

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

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

Re: [Rpm-maint] [rpm-software-management/rpm] luaext/Pexec: optimize setting CLOEXEC (#444)

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:

[Rpm-maint] [rpm-software-management/rpm] COPYING: Minor grammar fixes (#380)

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

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

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

Re: [Rpm-maint] [rpm-software-management/rpm] COPYING: Minor grammar fixes (#380)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Make sure all dependencies for scriptlet are installed before executing them (#436)

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

Re: [Rpm-maint] [rpm-software-management/rpm] RPM must kill all childs on exit (from section?) (#134)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Compress annobin notes (#751)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Fix excessive use of thread local storage (RhBug:1722181) (#759)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Remove "support" for loading keyring from filesystem (#857)

(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:

Re: [Rpm-maint] [rpm-software-management/rpm] Remove "support" for loading keyring from filesystem (#857)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Make database backends self-aware (#910)

> 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___

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Fully shutdown DBUS on systemd_inhibit cleanup (RhBug:1714657)" (#900)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Fully shutdown DBUS on systemd_inhibit cleanup (RhBug:1714657)" (#900)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] 4.16: no longer possible to package invalid symlink (#1159)

> 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:

[Rpm-maint] [rpm-software-management/rpm] option to disable fsync (#1401)

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

Re: [Rpm-maint] [rpm-software-management/rpm] option to disable fsync (#1401)

> 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

Re: [Rpm-maint] [rpm-software-management/rpm] Support ed25519 signatures (#1202)

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

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add database change notification API (#1124)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

> 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

Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

> 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,

Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

> 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

Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

@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

Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

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

Re: [Rpm-maint] [rpm-software-management/rpm] option to disable fsync (#1401)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Document thread-safety of librpm (#1483)

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

Re: [Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out the atexit handler (#1667)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] Add --nocompression option to rpm2archive (#1657)

@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:

[Rpm-maint] [rpm-software-management/rpm] rpm2archive: Support uncompressed output (#1530)

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 of popt arg

Re: [Rpm-maint] [rpm-software-management/rpm] Drag our CI to this decade (#1771)

> 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

Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr

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 OpenSUS

Re: [Rpm-maint] [rpm-software-management/rpm] Document that using assert() is frowned upon (PR #1807)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Allow the transaction ID and installation time to be overridden (PR #1803)

@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

Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr

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

Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr

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 >>

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: detect filesystem capabilities before starting a transaction (Issue #2637)

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:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: allow overriding buildtime and hostname via environment variable (Issue #2603)

> 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

Re: [Rpm-maint] [rpm-software-management/rpm] SOURCE_DATE_EPOCH=0 not clamping file mtime (Issue #2679)

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

Re: [Rpm-maint] [rpm-software-management/rpm] unreproducible `rpmdb.sqlite-shm` (Issue #2219)

> 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

[Rpm-maint] [rpm-software-management/rpm] unreproducible `rpmdb.sqlite-shm` (Issue #2219)

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

Re: [Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (PR #2378)

I referenced this effort in https://marc.info/?l=linux-fsdevel=167794198604510=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. And

Re: [Rpm-maint] [rpm-software-management/rpm] Replace fakechroot with proper container technology (PR #2559)

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:

[Rpm-maint] [rpm-software-management/rpm] docs/users_and_groups: Mention DynamicUser (PR #2558)

Because it really is just better (where its 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

Re: [Rpm-maint] [rpm-software-management/rpm] docs/users_and_groups: Mention DynamicUser (PR #2558)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)

> 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

Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)

> 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