I have been wondering what else we might want to generate automatically (from
the files). But looking through the tags I didn't find anything else (except
may be %changelog). Just noting here in case anyone else wonders.
--
You are receiving this because you are subscribed to this thread.
I would not expect such generators asking for more than 200-300 files. If that
would help, we can force it to be passed at once, so that you don't have to
initialize many things multiple times.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
This would require to query the rpmdb during build. I wonder what the
implications would be (except being pretty slow). I was worried about
bootstrapping at first but I guess we can just ignore files not found in the
rpmdb - or if there is no rpmdb found at all.
--
You are receiving this
Will you guys please discuss and perform any separation of language support in
a separate SR, please?!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ffesti commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
OK , there's a #if defined(__linux__) && defined(__i386__) branch just
below with its own
Good question, I've no idea. @ffesti?
--
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/1071#issuecomment-587491783___
Rpm-maint
Conan-Kudo commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
Wait nope, there's a `cpuid()` implementation for i386 right below...
--
You are receiving this
ffesti commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
Hmm, shouldn't the #if match up with the one around is_ryzen or be more general?
--
You are receiving
Conan-Kudo commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
You're right, this was accidentally broken when I rebased it again...
--
You are receiving this
Refactor the custom exec context setting code to look like setexecfilecon()
in case the real one is not available to eliminate pesky behavioral
differences between the two cases.
This fixes a concrete bug of libselinux setexecfilecon() returning with
an error when security_getenforce() returns
Okay, the difference is rpm's own code doing:
```
if (rc && security_getenforce() < 1)
rc = RPMRC_OK;
```
versus libselinux setexecfilecon() doing:
```
if (rc < 0 && security_getenforce() == 0)
rc = 0;
```
When inside bare chroot with no /sys etc mounts,
I didn't plan to push more commits, but now that you ask:
Does it really make sense to have the symlinks of already installed packages in
the `symlinks` hash? If a symlink is deleted on disk, the code will ignore it
anyway (see the "Ignore already removed (by eg %pretrans) links" comment). If
> I'm trying to make dir -> symlink-to-dir transactions work in the easy cases,
> I think this will be fixed with the changes as well
Wow. Good luck with that :grin:
As for the slashes, I seem to recall looking at reducing them but something
preventing that, perhaps some "hidden" dependency
Ok, looking at the history of flush_io and the potential to do more with it in
the future I think just keeping both of those macros is the way to go.
As auto detection for now is Linux only there is no perspective to get rid of
these macros and just always "do the right thing(tm)" as people with
As most of these changes are incorporated into the original PR I am closing
this one.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1066.
--
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/1066#event-3046235283___
Rpm-maint mailing list
@ffesti one another thing which needs to be backported is definitely
15b296c324794d288750136b3b4f3350c3d0b8c7
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
17 matches
Mail list logo
