@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:
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:
@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
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
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
>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
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 --
If we chroot(), getpwnam() and friends will still return results from the host
/etc/passwd and related files because of caching. We cant flush the caches
ourselves, so instead, lets open /etc/passwd ourselves in the chroot and
use fgetpwent() and friends to read from it. This makes sure we
> 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
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
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
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
> 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
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
Weve 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
Technically it's not much of an issue, our alphas have traditionally been
versioned (both the tarball and project version) x.y-1.90 anyway. So 90 means
alpha already, 91 can just as well mean beta. Rc is a "problem" because you'd
really want to have it at the final number already, but clearly
19 matches
Mail list logo
