https://www.phoronix.com/scan.php?page=news_item=GCC-11-x86-64-Feature-Levels
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
The names `%bcond_with` and `%bcond_without` are based the inner workings of
the macros. They describe the inverse of their default; anecdotal evidence
sugests that this is quite confusing in practice. I personally always have to
stop and think when using/reviewing them.
This PR adds the macro
@pmatilai does this look okay? I understand it isn’t high priority, but it
makes the API that little bit safer.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@radosroka pushed 1 commit.
9b36cd27e0442c3e8dd2eb391bed7aab237b7e90 Added fapolicyd plugin
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai does this revised version look good?
--
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/1492#issuecomment-768385550___
> Let's say not forgotten, just drowned in the mass. This is good to go so no
> harm in pinging, it's one down even if many to go.
>
> For the future, I'd say submitting fewer patches at once would probably work
> better. Too many at once and the pipe just gets clogged :sweat_smile:
@radosroka pushed 1 commit.
83b75dbe12a8d778089c01e0fd9f3e08fc0fe02e Added fapolicyd plugin
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
The reason I am asking is that I am working on (not yet published) Rust
bindings to a small part of the RPM API. Rust requires that safe code not be
able to invoke undefined behavior. Is it safe to `fork()` and then perform an
RPM transaction in the child process, even if the parent was
@pmatilai commented on this pull request.
> +(void) close(fapolicyd_state.fd);
+
+fapolicyd_state.fd = -1;
+}
+
+
+static rpmRC fapolicyd_psm_pre(rpmPlugin plugin, rpmte te)
+{
+if (fapolicyd_state.fd == -1)
+goto end;
+
+if (rpmteType(te) == TR_ADDED)
+
Some minor stylistic nits, but other that it seems quite fine to me now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> +if (!S_ISFIFO(s.st_mode)) {
+rpmlog(RPMLOG_DEBUG, "File: %s exists but it is not a pipe!\n",
state->fifo_path);
+goto bad;
+}
+
+/* keep only file's permition bits */
+mode_t mode = s.st_mode &
@pmatilai commented on this pull request.
> +};
+
+static struct fapolicyd_data fapolicyd_state = {
+.fd = -1,
+.installed_package = -1,
+.changed_files = 0,
+.fifo_path = "/run/fapolicyd/fapolicyd.fifo",
+};
+
+static rpmRC open_fifo(struct fapolicyd_data* state)
+{
+int fd
@pmatilai commented on this pull request.
> +
+static rpmRC open_fifo(struct fapolicyd_data* state)
+{
+int fd = -1;
+struct stat s;
+
+fd = open(state->fifo_path, O_RDWR);
+if(fd == -1) {
+rpmlog(RPMLOG_DEBUG, "Open: %s -> %s\n", state->fifo_path,
strerror(errno));
+
@pmatilai commented on this pull request.
> +/* send a signal that transaction is over */
+(void) write_fifo(_state, "1\n");
+/* flush cache */
+(void) write_fifo(_state, "2\n");
+}
+
+ end:
+return RPMRC_OK;
+}
+
+static rpmRC
Closed #1218.
--
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/1218#event-4255632401___
Rpm-maint mailing list
With #1419 merged now, I'm considering this done.
This will be in rpm 4.17, to be released in the spring. Other than that I wont
make any predictions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1419 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/1419#event-4255618529___
Rpm-maint mailing list
Since there are no further comments...
--
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/1419#issuecomment-768255053___
Rpm-maint
Feel free to close or repurpose this issue, but note that the docs situation is
confusing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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/issues/1519#issuecomment-768214704___
Rpm-maint mailing list
No, %if is strictly a spec construct. You can evaluate against the arch macros
though, eg
`%[ "%{_target_cpu}" == "x86_64" ? 1 : 0]`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Related question: There is no `%ifarch` expression, right? E.g. `%{arch:a b c
d}`/`%{narch:a b c d}` to evaluate to 0/1.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for the pointers.
--
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/1519#issuecomment-768200993___
Rpm-maint mailing
...such as those in the release notes (expressions section):
https://rpm.org/wiki/Releases/4.16.0
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The expression section could also use some more concrete examples...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Try the in-tree documentation instead:
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/macros.md
We'll need to have the rpm.org content pointing to the in-tree documenation
sooner than later...
--
You are receiving this because you are subscribed to this thread.
Reply to
I was searching for it in https://rpm.org/user_doc/macros.html but found
nothing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Well yes, most people will find the going along a running transaction a bit too
much when not just the current directory but also the root can change and
whatnot.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1496 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/1496#event-4254775253___
Rpm-maint mailing list
Let's say not forgotten, just drowned in the mass. This is good to go so no
harm in pinging, it's one down even if many to go.
For the future, I'd say submitting fewer patches at once would probably work
better. Too many at once and the pipe just gets clogged :sweat_smile:
Anyway, thanks for
31 matches
Mail list logo
