...typically to set LDFLAGS, which AFAICS would've gotten the right value
without this.
But the cat is out of the bag for a dozen generations of kittens and their
descendants, and fighting that herd is not a hill I care to die on. So I'll
submit, but @ffesti do add proper background info to the
Ehm, never mind that, this is widely used in Fedora specs. Sigh.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2481#issuecomment-1506410058
You are receiving this because you are subscribed to this thread.
Message ID: __
Well yes, but this data *already is* exported, so why would we need another
variable?
This is how it originally got added to Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=728974
However, I can't find a single trace of that value ever being *used* anywhere
at all! I was under the impressi
@Conan-Kudo requested changes on this pull request.
> @@ -750,11 +750,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
RPM_SOURCE_DIR=\"%{_sourcedir}\"\
RPM_BUILD_DIR=\"%{_builddir}\"\
RPM_OPT_FLAGS=\"%{optflags}\"\
+ RPM_LD_FLAGS=\"%{?build_ldflags}\"\
I
I don't think it's unreasonable for those flags to be exposed out of the gate.
It would certainly be nice if there was an extensible way to add more of them,
but this patch, as it is, is simple and reasonable to mainline.
--
Reply to this email directly or view it on GitHub:
https://github.com/
This is basically done. (CI is failing, because rpm-sequoia 1.4 is not yet
available.) @pmatilai if you are happy, I'll release rpm-sequoia 1.4.
Otherwise, I'm happy to iterate some more.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pul
@nwalfield pushed 1 commit.
b74ad98bbc773bd0a031788d18e659b62160e570 Add pgpVerifySignature2
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2453/files/5498d2b2b84b66d36978aa6cdeccdc543d2d46e8..b74ad98bbc773bd0a031788d18e659b62160e570
You are receiving this because you
Thanks for looking into this!
For rpmugUname() and rpmugGname(), an important side-effect of the caching is
the string storage. That seems necessary to maintain, returning a pointer that
could be invalidated by an unrelated call to the getpw*() etc family of calls
doesn't cut it. Also, the cach
IIRC this hasn't been merged because it opens up the question: what about all
the other related flags, should they also have their own RPM_ variables?
Actually, I wonder if this is needed at all these days, because %build_ldflags
is already exported as LDFLAGS in the build scripts through %set_b
>From https://github.com/rpm-software-management/rpm/discussions/2479
> Files, symlinks, directories are mentioned as file in descriptions of
> problems (file conflicts). It
> it makes debugging difficult especially in case when symlink is going to be
> replaced by directory and the operation fa
Based on downstream Fedora patch
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2481
-- Commit Summary --
* Add RPM_LD_FLAGS to build environment
-- File Changes --
M macros.in (3)
-- Patch Links --
https://github.c
If we chroot(), getpwnam() and friends will still return results from the host
/etc/passwd and related files because of caching. We can't flush the caches
ourselves, so instead, let's open /etc/passwd ourselves in the chroot and
use fgetpwent() and friends to read from it. This makes sure we avo
> Let's stick with the number approach for the alpha and sort out the bigger
> versioning question for the beta
Ack :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2477#issuecomment-1504941632
You are receiving this because
I'd totally forgotten we used alpha in the 4.18 tarball name, in all previous
versions it was just the "raw" 4.x.90 number instead :laughing: Let's stick
with the number approach for the alpha and sort out the bigger versioning
question for the beta (so bumping milestone)
--
Reply to this emai
FWIW, for example this would make a very reasonable ticket on it's own:
> files, symlinks, directories are mentioned as file in descriptions of
> problems (file conflicts)
>
> it makes difficult debugging specially in case when symlink is going to be
> replaced by directory and the operation fai
Linking any and every possible rpm improvement idea to version 6 is exactly
what we DON'T want.
Improvements need to be looked at on their own merits, v6 is primarily about
the package format facelift. From functionality point of view it's just another
release.
As for resilience against power
@j-mracek wrote elsewhere:
I know that this is not exactly about RPM6 format but it is related to a new
major version of RPM.
There are few things in our environment that are painful for our users but it
is not easy to resolve them:
- broken systems
- There are multiple ways how to get to th
I know that this is not exactly about RPM6 format but it is related to a new
major version of RPM.
There are few things in our environment that are painful for our users but it
is not easy to resolve them:
- broken systems
- There are multiple ways how to get to that state and sometimes we ha
> Yup. Perhaps the bigger question is, should rpm _always_ use just the local
> passwd/group files?
Yes, nothing else is useful.
> I'm not sure if rpm needs to take into account nsswitch.
I don't think so. Firstly, it's not well defined what that would even mean. The
host's nsswitch is irrelev
Merged #2478 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2478#event-8982403415
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
We've removed a tonne of obsolete APIs in this release so...
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2478
-- Commit Summary --
* Bump the soname in anticipation of the 4.19 alpha release
-- File Changes --
M CM
21 matches
Mail list logo
