Closed #829 as completed via #2996.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/829#event-12265396820
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm
Merged #2996 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#event-12265396584
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
- rpmlog(RPMLOG_WARNING
A bigger problem is that this doesn't actually work. As in, add the users into
the groups on install. The "receiving" code does not know to look for these
new provides so they end up being just decoration.
What you don't test does not work, is a good rule of thumb :smile:
--
Reply to this em
Merged #3000 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3000#event-12263647886
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
There's no reason each of these needs to perform their own test setup and
cleanup when they're not even writing anything. Doesn't change what
gets tested, just less useless chatter in the test output.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-softwa
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
- rpmlog(RPMLOG_WARNING
Oh and, a proper commit message for the main change. The how and why are quite
a bit more complicated than "Create Requires/Recommends for both the user and
the group."
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2990#issuecomment-20
@pmatilai commented on this pull request.
> @@ -38,9 +41,10 @@ to weaken these into recommends-dependencies by setting
## Limitations
-At this time, rpm only supports the `u` and `g` directives of sysusers.d
-format and ignores others. If other directives are needed, the package
-will need
@pmatilai commented on this pull request.
> if arg[1] == 'g' then
type = 'group'
elseif arg[1] == 'u' then
type = 'user'
-elseif arg[1] == 'r' or arg[1] == 'm' then
+elseif arg[1] == 'm' and #arg >=3 then
+type = 'usergroup'
'groupmember' might be a m
@pmatilai commented on this pull request.
> +goto continue
+end
+fields = {}
+for w in line:gmatch("%S+") do
+table.insert(fields, w)
+end
+if #fields >= 3 and fields[1] == 'm' then
+ print(string.format('user(%s)\\ngroup(
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
- rpmlog(RPMLOG_WARNING
> `%dnl` already works for this purpose, doesn't it?
It doesn't, because this check happens before macro expansion.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022362161
You are receiving this because you are subscr
Commit e5d7a823c99b84d65ecbf3810b68aab372ef5d14 broke builds relying on libtool
(and no doubt some others as well) because libtool redirects stdin in some of
its tests and this fails if stdin is closed. Instead of closing, pass the
write-only end of the pipe as the stdin to build scriptlets. Thi
Yeah, (looking into) populating SOURCERPM early was what I meant with fixing at
the source. Based on a quick look, you could just move SOURCERPM insertion from
processBinaryFiles() to, say, finalizeSpec() and be done with it with equal
amount of work, without adding duplicate special paths.
--
On that note, don't hesitate to point out shortcomings or other new related
ideas. I'm too close to the source (in both meanings :smile: ) to see clearly,
as the -C example points out.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussio
Oh yup, thanks for filing this! The auto directory patch landed just after the
buildsystem work so it kinda went under the radar, but it should complement the
buildsystem work very nicely indeed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rp
Lets worry about the other stuff separately, this is the thing that hurts the
most by far because it used to work, even if for the wrong reasons.
Making non-comments an error now that we do allow comments is indeed the right
thing to do :+1:
--
Reply to this email directly or view it on GitHu
That would be good so it wont go forgotten, yeah.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8916709
You are receiving this because you are subscribed to this thread.
Message ID:
___
Heh, that's indeed a pretty simple cure for this. The "problem" of course is
that it's inconsistent with the rest of the spec where comments are only
allowed at the beginning of lines, but seeing how widely this is in use and how
many pointless warnings packagers suffer for it... seems well wort
This was fixed in https://github.com/rpm-software-management/rpm/pull/2975, but
GH didn't grok the "Fixes issue ..." syntax it seems.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2974#issuecomment-2020623132
You are receiving this be
Closed #2974 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2974#event-12251524627
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
That's the essence of it, yes.
One thing that did catch my eye:
the %buildsystem_foo_install() and such macros do not take options currently
because they'd be shared across all buildsystems. So eg
`%buildsystem_pyproject_check(e:t)` will not do what you intend, there's no way
to pass options t
This wont fix it for other potential users of archsuffix though.
Let's at least see if there is a way to fix the issue at the source - maybe
archsuffix can do better heuristics than the simple-minded headerIsSource() or
.. something.
--
Reply to this email directly or view it on GitHub:
https:
...and now with docs...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#issuecomment-2019946369
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint m
@pmatilai pushed 4 commits.
b5cb2b48af7293c3b1608b1cef289fed1b14ad2c Use rpmGlobPath(... RPMGLOB_NOCHECK)
for rpmrc reading
d48bf2e1e3e6e3512401e83d04d38eb6807e4480 Sanitize rpmGlob() behavior wrt
non-glob patterns
de0ae1121392e50aa59032e5d2e6d97d65e8bd4f Drop support for compile-time
MACROF
Eep, another thing this is missing: docs.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#issuecomment-2019919241
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai commented on this pull request.
> +}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initMacroPath(const char *confdir)
+{
+const char *xdgconf = getenv("XDG_CONFIG_HOME");
+if (!(xdgcon
@pmatilai commented on this pull request.
> @@ -20,3 +20,41 @@
::continue::
end
}
+
+%__sysusers_recommends() %{lua:
+if rpm.expand('%[0%{?_use_weak_usergroup_deps}]') == '0' then
Argh, indeed. Maybe we should just add a native macro for rpmExpandNumeric(),
it's not like the
@pmatilai commented on this pull request.
> +#ifdef MACROFILES
+static char *initMacroPath(const char *confdir)
+{
+return xstrdup(MACROFILES);
+}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initM
Updated to use ~/.config/rpm directory and take ~/.rpmrc into account as well.
Thanks guys for the feedback!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#issuecomment-2019689559
You are receiving this because you are subscribed to
@pmatilai commented on this pull request.
> @@ -2,6 +2,41 @@
#
AT_BANNER([RPM macros])
+AT_SETUP([macro path])
+AT_KEYWORDS([macros])
+RPMDB_INIT
+
+# .rpmmacros exists
Right, this ... crossed my mind but dismissed it, along with several other
warning bells related to this PR, too busy get
@pmatilai pushed 2 commits.
6ee9eedc9af522bbd0025b0874222477ccf40139 Drop support for compile-time
MACROFILES override
6eaa933386a72d4a5673e7e86969bca679cbb6a8 Support per-user macro configuration
in XDG_CONFIG_HOME
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/29
@pmatilai commented on this pull request.
> +#ifdef MACROFILES
+static char *initMacroPath(const char *confdir)
+{
+return xstrdup(MACROFILES);
+}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initM
@pmatilai commented on this pull request.
> +}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initMacroPath(const char *confdir)
+{
+const char *xdgconf = getenv("XDG_CONFIG_HOME");
+if (!(xdgcon
@pmatilai commented on this pull request.
> +#ifdef MACROFILES
+static char *initMacroPath(const char *confdir)
+{
+return xstrdup(MACROFILES);
+}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initM
It's documented here:
https://rpm-software-management.github.io/rpm/manual/buildsystem.html#supporting-new-build-systems
But closed tickets are not a good place for questions, please open a new thread
in https://github.com/rpm-software-management/rpm/discussions
--
Reply to this email directl
Okay, made you the admin of that repo. Have fun, as they say :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2018081307
You are receiving this because you are subscribed to this thread.
Message ID: _
@pmatilai pushed 3 commits.
ee17de74cf23df317e9c53f259c9bdd483a2ff4d Use rpmGlobPath(... RPMGLOB_NOCHECK)
for rpmrc reading
3b796dc90e819fe7cfaa621cd7e8d4f62c6c517d Sanitize rpmGlob() behavior wrt
non-glob patterns
1172a0f60e336891a86df77de89e3e82d536b39f Support per-user macro configuration
@pmatilai commented on this pull request.
> @@ -20,3 +20,41 @@
::continue::
end
}
+
+%__sysusers_recommends() %{lua:
+if rpm.expand('%[0%{?_use_weak_usergroup_deps}]') == '0' then
Oh and there's indeed a nicer way to do this (I remember you asking about this
but didn't have
@pmatilai commented on this pull request.
> +fields = {}
+for w in line:gmatch("%S+") do
+table.insert(fields, w)
+end
+if #fields >= 3 and fields[1] == 'm' then
+ print(string.format('user(%s)\\ngroup(%s)', fields[2], fields[3]))
+en
@pmatilai commented on this pull request.
> +if rpm.expand('%[0%{?_use_weak_usergroup_deps}]') ~= '0' then
+ return
+end
+for line in io.lines(macros["1"]) do
+if line:sub(1, 1) == '#' then
+goto continue
+end
+fields = {}
+for w in l
Look for per-user macros primarily in ${XDG_CONFIG_HOME}/rpmmacros but fall
back to traditional ~/.rpmmacros iff it exists and there's no config in the
XDG location. As per the XDG spec, if ${XDG_CONFIG_HOME} is not set, it
defaults to ~/.config
Fixes: #2153
You can view, comment on, or merge t
@pmatilai commented on this pull request.
> +if rpm.expand('%[0%{?_use_weak_usergroup_deps}]') ~= '0' then
+ return
+end
+for line in io.lines(macros["1"]) do
+if line:sub(1, 1) == '#' then
+goto continue
+end
+fields = {}
+for w in l
Let me put it this way: if there was a will to move to Rust, maybe sitting out
a few more years waiting for technical matters to sort themselves would be a
meaningful option. That's just not the case.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manageme
If somebody wants to rewrite rpm from scratch in Rust in another 15 years when
I'm retired, be my guest.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8877799
You are receiving this because you are subscrib
There was plenty enough surrounding rpm-sequoia.
Rust is not an option, that is not up to discussion.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8877589
You are receiving this because you are subscribed
As for exceptions: rpm's allocator has the terminate-on-failure behavior, which
in practise means any call to the rpm API could abruptly terminate your
process. Which is not a whole lot different from -fno-exceptions.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-
Specs have no business writing anywhere else than their [designated
%builddir](https://github.com/rpm-software-management/rpm/issues/2078).
%_tmpdir too, but that belongs inside %builddir so it doesn't need special
cleanup, just special setup.
This should be entirely doable with Linux namespac
Yes, people keep bringing up Rust. It's just not a viable option for rpm, for a
multitude of reasons. For starters, it's a show-stopper as a bootstrapping
dependency for something as early in that chain as rpm. I won't go further
because it'd be pointless because of that first reason.
--
Reply
Actually the whole %clean thing seems redundant since
9d35c8df497534e1fbd806a4dc78802bcf35d7cb because everything is under that one
directory and we need to be able to nuke it, no matter what.
Fixing this would be a one-liner to build.c:
```
if (what == RPMBUILD_RMBUILD) {
+ fprintf(f
I'm kinda torn here - this kind of "refer to tags.md" and "compared to v4"
specification feels incomplete and cheating, it seems that it should list each
and every legitimate tag specifically here. OTOH that seems like a lot of
duplication with tags.md and whatnot.
For a "normal" specification,
I guess it's time to move on with the low-level spec:
https://github.com/rpm-software-management/rpm/pull/2988
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8864326
You are receiving this because you are su
The related discussions seem to have run their course, time to start the
"formal" documentation...
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2988
-- Commit Summary --
* Start a v6 format draft doc
-- File Changes --
Million thanks @nwalfield and @teythoon for making this possible!
I can't believe just how much weight this took off my shoulders :feather:
Every software engineer knows some code is more expensive to maintain than
others, but I wonder: how do you measure it? In kilograms? :smile:
--
Reply to
Indeed, rpm.define() calls rpmDefineMacro() which is takes the macro name and
the body as a single line - as you would get in a macro file. It doesn't make
much sense as an API.
IIRC Lua's rpm.define() used that API because the other alternative lacked all
the error checking back in the day, bu
> I'm in favor of an separate project. I'm willing to take maintainership if
> nobody else steps up...
@mlschroe , shall I transfer the ownership of
https://github.com/rpm-software-management/rpmpgp_legacy to you? Otherwise I'll
just archive the thing.
--
Reply to this email directly or view
Closed #2414 as completed via 63e369cd3579114a011d3fd5eafaeafa8b1b2e88.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#event-12183852540
You are receiving this because you are subscribed to this thread.
Message ID:
__
Merged #2986 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2986#event-12183852221
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
And RIP :headstone:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2986#issuecomment-2009417967
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mail
Finally.
See commit messages for details.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2986
-- Commit Summary --
* Prepare to cutting out the internal OpenPGP parser for good
* Split off the internal OpenPGP parser to
@pmatilai commented on this pull request.
> - goto exit;
- }
- if (rstreq(buildRoot, "/")) {
- rpmlog(RPMLOG_ERR, _("%%{buildroot} can not be \"/\"\n"));
- goto exit;
+ if (!spec->buildDir) {
+ /* Grab top builddir on first entry as we'll o
Merged #2984 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#event-12182799253
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Okay, best to just get this out of the way...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2009249611
You are receiving this because you are subscribed to this thread.
Message ID: _
This can be considered accomplished now, just need to maintain the situation
going forward.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2099#issuecomment-2009054656
You are receiving this because you are subscribed to this thread.
Closed #2099 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2099#event-12181400165
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Closed #1090 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1090#event-12181293275
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Actually, makes more sense to just merge this into #567.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1090#issuecomment-2009039428
You are receiving this because you are subscribed to this thread.
Message ID:
The same goes for %license, with a slight difference: while documentation may
sometimes be executable (example scripts), licenses never can. The two are
closely related though so there's no point having separate tickets for the two,
closing #1090 in favor of this.
--
Reply to this email direct
This should be done together with #567.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1090#issuecomment-2009033180
You are receiving this because you are subscribed to this thread.
Message ID: _
This is a sub-case of the more general issue tracked now in #2922, closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1227#issuecomment-2009029344
You are receiving this because you are subscribed to this thread.
Message ID: _
Another case where we'll run into this is if/when we add support for vpath
builds in read-only tree (#2985).
The default `%clean` is a macro now, making this kind of thing easy.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2519#iss
With the new rpm-controlled %builddir from #2078, we now have a safe playground
for all sorts of things that didn't have a place to go before. One such item is
vpath (aka out of tree) builds, whereas rpm traditionally always assumes build
happens inside the source tree. What once was the defacto
Seems I dropped the ball here, sorry. I suppose a custom base image could be
handy.
It doesn't scale though, eg in case we'd want to build rpm-sequoia, popt and ..
say, elfutils from sources to test a new feature before it's packaged in
Fedora.
--
Reply to this email directly or view it on Gi
No particular reason this needs to be in 4.20 exactly. Lets just drop the
milestone, this is a "gets done when it gets done" item really.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2241#issuecomment-2008970624
You are receiving thi
Not going to do major refactoring for this in 4.20, drop the milestone.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2714#issuecomment-2008969429
You are receiving this because you are subscribed to this thread.
Message ID: _
@mlschroe , thoughts on this?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2008964003
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-m
The main package preamble has to come first, the rest of the spec parser is
built on top of that assumption.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8839919
You are receiving this because you are subs
Couple of simple tests added, a whole lot tests skipped when dummy pgp used.
The INSTALL docs hopefully a little saner now :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2006967300
You are receiving this beca
@pmatilai commented on this pull request.
> +return PGPARMOR_NONE;
+}
+
+int pgpPubKeyCertLen(const uint8_t *pkts, size_t pktslen, size_t *certlen)
+{
+return -1;
+}
+
+char * pgpArmorWrap(int atype, const unsigned char * s, size_t ns)
+{
+return NULL;
+}
+
+rpmRC pgpPubKeyLint(const
@pmatilai pushed 1 commit.
6ede5d3ed8081ddcece6a44176ed38863c848e3f Allow building rpm without OpenPGP
support
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984/files/2286b6001d2e3bb09e6efa8a0a02bb0ccdd34880..6ede5d3ed8081ddcece6a44176ed38863c848e3f
You are receivi
@pmatilai pushed 1 commit.
2286b6001d2e3bb09e6efa8a0a02bb0ccdd34880 Allow building rpm without OpenPGP
support
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984/files/2a5c0131cc24c803695bd48bff3742446f90a98a..2286b6001d2e3bb09e6efa8a0a02bb0ccdd34880
You are receivi
This will also need some further tweaks to skip the relevant tests.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2006802381
You are receiving this because you are subscribed to this thread.
Message ID: ___
@pmatilai commented on this pull request.
> @@ -27,8 +27,8 @@ The source for the file utility + library is available from
ftp://ftp.astron.com/pub/file/
You will need a cryptographic library to support digests and
It gets tricky here because now those two are separated in some of the op
All good points, thanks for the review!
As for `pgpVerifySignature[2]()`, I considered returning NOKEY for a softer
impact, but the gotcha is that the sanity check in rpmsinfoInit() causes things
to fail long before you get to call verify. So while adding a "not at home"
lint will of course not
As per the commit message, the intent is to follow-up this with a patch to
split the rpmpgp_legacy directory off the rpm main repo entirely, at which
point #2414 is achieved while letting others to maintain the code if they so
wish.
--
Reply to this email directly or view it on GitHub:
https:/
https://github.com/rpm-software-management/rpm/pull/2984 implements the dummy
PGP option.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2006529326
You are receiving this because you are subscribed to this thread.
Me
For bootstrapping purposes, having rpm depend on Rust is painful, but directing
people to unmaintained crypto code as an alternative is hair-raising. As a
middle ground, let rpm be built without OpenPGP support at all, which at least
gives you a functional rpm and rpm-build even if you can't sig
Finally managed to convince myself that it should be feasible (with reasonable
amount of work) to have a "nopgp" build option by adding a dummy implementation
of the internal PGP interface that just returns -ENOTHOME for everything, and
allow choosing between libgcrypt and openssl for the hash f
Just FWIW, there's now an in-tree tool for looking at low-level package
structure:
https://github.com/rpm-software-management/rpm/blob/master/tools/rpmdump.c
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2965#issuecomment-2005946927
Ever since the RPM upstream reboot in 2006, we've been striving to replace the
old-school, hand-written pointer gymnastics with general purpose APIs in the
codebase. We've come a long way, but all this time we've been dreaming about
richer data structures than C has to offer. Of course in C, you
We've just published our roadmap for the next three years:
https://rpm.org/roadmap
Of course the big thing there is the looming RPM v6.0 on which we can now shed
a lot more light on, so copying it here:
RPM 6.0 release
* Introducing [RPM
v6](https://github.com/rpm-software-management/rpm/discu
Hmm, it seems I misread the report because I thought that's what was happening,
I guess the strange ticket summary set the stage for strange ideas what will
follow.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003
Reopened #2952.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#event-12152413309
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
> So it looks to me like it is not reclaiming the space during --delsign. Where
> or why do we disagree?
>
> It looks to me like the reservation is hard coded. So as long as the rpm that
> was used to build and the one that was used to --delsign is the same it
> should be able to guarantee it,
Merged #2981 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2981#event-12150925799
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2981
-- Commit Summary --
* Bunch of docs formatting cosmetics
-- File Changes --
M docs/manual/queryformat.md (34)
M docs/manual/spec.md (2)
-- Patch Links --
htt
> When I remove the unnecessary 'Requires:' of one package, I found that the
> residual package which is no more required can not br removed when upgrade. I
> tried 'Obsoletes', but I found that it affects other packages that requires
> it.
Impossible to give any detailed response because there
You're instructing rpm to both exclude and include a file. It possibly do both,
so the only reasonable course of action can be erroring out.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003646399
You are receiving
Closed #2952 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#event-12150341988
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
1101 - 1200 of 2663 matches
Mail list logo
