Tested locally with mystery package that shall not be named
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2906#issuecomment-1943236369
You are receiving this because you are subscribed to this thread.
Message ID: ___
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2903#pullrequestreview-1879061365
You are receiving this because you are subscribed to this thread.
Message ID: __
For hacking on systemd, I'm looking into building rpms from upstream sources.
Because we're building from upstream sources, there are naturally unpackaged
files depending on how the %files directives are handled. I would like to
assign any unpackaged upstream files that haven't been explicitly a
I would agree about the redirect_dir nogo in the rpm case as there must be a
reason why it's disabled by default (I cannot figure out what's the tradeoff)
and you don't have control on what mount options are used anyway.
--
Thomas HUMMEL
--
Reply to this email directly or view it on GitHub:
h
Sorry I think my replies somehow crossed yours.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncomment-8456601
You are receiving this because you are subscribed to this thread.
Message ID:
_
Well, my understanding is that data is actually copied when copy-up is
triggered (which of course happens only if you somehow modify lower or merge
data or metadata). Overlayfs has some `xattr` tricks to present to the user in
the merged layer the most "transparent/consistent" things as possible
To answer the question: We really shouldn't!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2906#issuecomment-1942018096
You are receiving this because you are subscribed to this thread.
Message ID: _
%config is only allowed for regular files and links. While rpmbuild won't
produce package with other files with %config other tools might. Handle these
cases gracefully by ignoring the %config flag.
Resolves: #2890
You can view, comment on, or merge this pull request online at:
https://github
This is suspicious as they assign different values. @pmatilai do you want to
have a closer look?
Could be a rebasing artifact between fb13f7fd9e and 318efbaec8. Probably by
changing the order those two are aplied.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-so
Hmm, it seems like OverlayFS indeed does a full copy up (there's the `metacopy`
feature that only does that for the metadata).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncomment-8456485
You are receiving this be
> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the atomi
> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the atomi
Well, I'm no expert either but my understanding is that for instance a tool
like `mv` would first try `rename()` and if it returns `EXDEV` it will
workaround by copying data.
So, to me the main difference is the atomicity: when you set an `xattr` to the
orignal dir then `rename()` the copied up
Looking at the OverlayFS
[docs](https://docs.kernel.org/filesystems/overlayfs.html#renaming-directories)
some more, specifically at the section covering `redirect_dir`, it mentions the
following (emphasis mine):
> return EXDEV error: this error is returned by rename(2) when trying to move a
>
Right, that is a valid question, although I'm no expert on OverlayFS so can't
really answer that.
The only "explanation" (as to why EXDEV is issued on a `rename(2)` call) that
I've found is the following excerpt from a comment in the OverlayFS
[code](https://github.com/torvalds/linux/blob/v4.8
@ffesti commented on this pull request.
> if (rpmGlob(attrPath, NULL, &files) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strlen
Oh ok thanks for your answer.
Well I'm not sure about the drawback on turning on redirect_dir on the host as
a workaround.
Thanks for your help
--
Thomas HUMMEL
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncom
Yup, this is a known issue, see
https://github.com/rpm-software-management/rpm/issues/2355.
The thing is, even if this would be possible to work around, we don't want to
have any such filesystem-specific code in RPM.
Now, thinking about it more, this might in fact be something to handle in an
Hello,
[I'm not sure this is the right place to post such a question, feel free to
redirect me if needed.]
using `RPM version 4.19.1` on `Fedora release 39 (Thirty Nine)` or `RPM version
4.14.3` on `Red Hat Enterprise Linux release 8.8 (Ootpa)`, I experienced that I
could not successfully run
OK, I was a bit vague above, so to clarify:
What I did was:
1. Ran an Ubuntu-based container (with `toolbox`)
2. Installed all the RPM deps in it
3. Built the latest RPM checkout in it
4. Created an image from it (with `podman commit`)
5. Ran the test-suite against *that* image (instead of the def
Nah, I *was* running it on Ubuntu (by setting up a container manually) :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1941652244
You are receiving this because you are subscribed to this thread.
Message ID: _
https://github.com/rpm-software-management/rpm/blob/34cb5ee92276058f68f6d3fb1c345b22992c28a8/lib/rpmfi.c#L332
This row duplicates the settings of the i variable for several lines above.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/29
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, &files) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strl
OK, removed one underscore from the macro name, rewrite the init code and added
two test cases that deal with already installed file attributes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1941456054
You are receivin
@ffesti pushed 1 commit.
e1dea8eafaf3f4da91e7ba132f9e953eec3a9665 Add more test cases
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/7c64e73308a328d3aad40c118024f799503bc96f..e1dea8eafaf3f4da91e7ba132f9e953eec3a9665
You are receiving this because you are su
@ffesti pushed 1 commit.
7c64e73308a328d3aad40c118024f799503bc96f Local File Attrs: Remove one
underscore
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/ab3a293498ec59129d3551e76e444e964b9f0985..7c64e73308a328d3aad40c118024f799503bc96f
You are receiving th
Mmm, but with current master the test would be running on Fedora because
there's no native test-suite for Ubuntu? Those matryoshkas as really out to get
us now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-19413597
In any case, #2883 is now merged. We can always tweak this later, at least
before the first public release carrying this feature.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2754#discussioncomment-8452948
You are receiving this
@ffesti pushed 1 commit.
7023620eb258af338b1e53b3806b8f66ad9384d7 Local File Attrs: Remove one
underscore
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/fb9b6ec25e2e72daa7944175e64c2928104cd016..7023620eb258af338b1e53b3806b8f66ad9384d7
You are receiving th
@ffesti pushed 1 commit.
fb9b6ec25e2e72daa7944175e64c2928104cd016 Local File Attrs: Remove one
underscore
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/5ff3074187b888f9ff62416d9495fe36f7890468..fb9b6ec25e2e72daa7944175e64c2928104cd016
You are receiving th
> One more thing wrt the macro name: I wonder if this is a case where it should
> _not_ have those leading underscores. The generator itself is full of double
> underscore names, but the newly added macro here is something directly
> intended for packager use in a spec. I dunno, it may even be m
We now use our own script (sysuser.sh) instead of systemd's
systemd-sysusers.
Resolves: #2857
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2903
-- Commit Summary --
* Adjust User/Group handling Documentation
-- File Ch
@pmatilai pushed 1 commit.
3b787e5c375f830180c2e0bc8643cb80c23cc277 Let eBPF ELF files be packaged in
noarch packages
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2902/files/91f4d3fd56c41faa2f21db17f4bdff10cb01d746..3b787e5c375f830180c2e0bc8643cb80c23cc277
You are
eBPF ELF represents a virtual machine where our file colors make no sense at
all. Filter out the color from these files to avoid a "Arch dependent
binaries in noarch package" error from them in noarch packages.
We don't want to pull in clang to the check images just because of this, so
add a pr
@dmnks pushed 3 commits.
eb16077ce74cad62c6017aedc7bbae14c154fd5c Replace MKTREE_NATIVE with
MKTREE_MODE in cmake
b2a80b40b15e30405c7d109109971b392972214e Hybrid mode
38f1e0927b27f5a082f60927c1d85b1dc93d8999 Dockerfile
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull
I've just tried this with the latest RPM snapshot on master and this checksum
test still fails, even with commit a0553eb38a01772254cd48fef7ad116294cf801a in
place. This time, though, the payload is identical (as confirmed with
`rpm2cpio` and `diff`). Strange...
--
Reply to this email directly
Merged #2901 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2901#event-11784881206
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Ninja doesn't support passing environment as command line arguments like
make does, access TESTOPTS through environment instead of the make syntax to
make it work for both generators.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm
38 matches
Mail list logo
