Forward-looking defaults aside...
Do you agree with the idea that there should be a single macro to set the
buildtime source (clock/macro/source_date_epoch), and then have a separate flag
for clamping mtimes to buildtime, or am I again missing some finer detail here?
I've nothing against repro
(and fwiw, pulling that path change into 4.19.x makes no difference whatsoever
because the translations should NOT be updated in the branches, and hence
there's no reason to do so)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#i
So with the submodule update done, this can be closed. Sorry @dmnks for
stealing your ticket :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1956028313
You are receiving this because you are subscribed t
Closed #2899 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#event-11871913923
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Well yeah, *ideally* you'd have an official string freeze period with
translation notifications for major releases. And ideally you'd also have
per-release branches for translations because over time they grow different so
you can't safely pull updated translations to stable releases.
Why we ne
Because in rpm < 4.18, we have this silly check in there:
```
if (lead->major < 3 || lead->major > 4) {
*msg = xstrdup(_("unsupported RPM package version"));
return RPMRC_FAIL;
}
```
Putting 6 in the otherwise unused lead would render v6 packages unreadable by a
huge rang
Figuring out what to do with this is one of the next things on my plate.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529580
You are receiving this because you are subscribed to this thread.
Message ID:
There's now also a draft PR that implements mosts of this draft, as far as
package generation goes:
https://github.com/rpm-software-management/rpm/pull/2920
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-852
@pmatilai pushed 2 commits.
30d352e1c188a68fdeb97fd1737d3eba891a19ee Don't populate os and arch in the
lead structure
01df85ccec5c00ebd46802a67fcc53f8274926a3 Bump the rpm version in the lead to 4
for v6 packages
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2920/
This should fairly closely reflect the latest v6 draft just published at
https://github.com/rpm-software-management/rpm/discussions/2919
The focus here is on the generation of v6 format packages, asserting various
aspects of the format is mostly a post 4.20 topic.
You can view, comment on, or me
There's now what should be much closer to final (but isn't yet, certainly)
draft with clarified scope and compatibility info at
https://github.com/rpm-software-management/rpm/discussions/2919
Closing this topic as it has served its purpose and is getting too cluttered to
follow.
Thanks everybod
Closed #2374 as resolved.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rp
Based on the feedback on the [initial
draft](https://github.com/rpm-software-management/rpm/discussions/2374) and
work in the background, here's a major update to the v6 package format draft.
Starting a new topic as the original one is getting bogged down in details that
are no longer relevant.
Coming back to this: to avoid gratuitious compatibility breakage, we can't put
either 0 or 6 in there.
The best we can do is put 4 in there because all of rpm 4.x used 3 as the major
version for alleged LSB compatibility, so it at least differentiates it a bit.
It's not such a terrible lie even
@pmatilai commented on this pull request.
> @@ -21,6 +21,11 @@
#define ALLOWED_CHARS_EVR ALLOWED_CHARS_VERREL "-:"
#define LEN_AND_STR(_tag) (sizeof(_tag)-1), (_tag)
+enum parseStages {
+SPECFILE,
+BUILDSYS,
+GENERATED,
Use some unique prefix on the enum names, makes it easier t
@pmatilai commented on this pull request.
> + if (stage == GENERATED) {
+ switch (tag) {
+ case RPMTAG_SOURCE:
+ case RPMTAG_PATCH:
+ case RPMTAG_NOSOURCE:
+ case RPMTAG_NOPATCH:
+
Just a random observation: Fedora is being used as the example here, but Fedora
does NOT preserve the updates history in the repository, only the first (in the
base repo) and the last are kept. So any of this basically requires maintaining
a local mirror which never deletes packages. And with th
Merged #2916 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2916#event-11848850444
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Details in the commits, but basically add a new test group for package format
matters + a test for v4 package format utilizing rpmdump.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2916
-- Commit Summary --
* Split our r
Merged #2915 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2915#event-11848573139
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Yeah this doesn't seem particularly relevant to rpm itself. But if people want
to use this as a depsolver agnostic place to discuss it, you're welcome to do
so.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncommen
We have the list of tests in cmake, we can just as well generate the master
rpmtests.at file from there.
As the order of tests now depends on the list in tests/CMakeLists.txt, update
it to match the former order in rpmtests.at. As arbitrary as that order is,
people seem to get attached to certa
@pmatilai requested changes on this pull request.
These are all optional dependencies and must remain that way, some of these
dependencies aren't available outside Linux at all. Without the corresponding
cmake options this is a no-go.
--
Reply to this email directly or view it on GitHub:
htt
Merged #2913 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#event-11847031818
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
All your remarks should be covered now, just squashed the fixups in the last
push.
Oh and thanks for the review! I'm not friends with escapes so I conveniently
tend to forget all about them. My main motivation with this one was human
consumption more than computer, but of course if we claim it'
@pmatilai pushed 1 commit.
ce82dcaaa71f990054cb22b72553f6dac05ea433 fixup! Implement --json query format
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913/files/479795192525cd1a282d279215deff7fb7f3e492..ce82dcaaa71f990054cb22b72553f6dac05ea433
You are receiving this
@pmatilai pushed 1 commit.
479795192525cd1a282d279215deff7fb7f3e492 fixup! Implement --json query format
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913/files/34667b308a14992e4fae15a5cc4ce803fddbaa78..479795192525cd1a282d279215deff7fb7f3e492
You are receiving this
There you go, that hopefully covers it. Annoyingly this also easily doubles the
patch size, as these things always do.
Also all this string appending is of course all horribly inefficient, but that
can be improved later.
--
Reply to this email directly or view it on GitHub:
https://github.com
@pmatilai pushed 1 commit.
34667b308a14992e4fae15a5cc4ce803fddbaa78 fixup! Implement --json query format
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913/files/cb102a6dd315c1d89da8f38b6fa83b83f4d1..34667b308a14992e4fae15a5cc4ce803fddbaa78
You are receiving this
Oh, indeed. It's just the kind of dumb luck to miss such characters in the
test-material you try to reparse for validation :sweat_smile: The newlines in
base64Format() was trying to ring some bells but was too busy hacking the rest
of it up.
--
Reply to this email directly or view it on GitHub
The existing --xml output is extremely useful when inspecting oddities but the
format is such an eyesore. JSON is much saner to look at.
Details in the commits and their messages, but the first commits are just
refactoring to make this feasible. The actual feature in the last commit is
quite sm
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, &files) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strl
Allow declaring file attributes from the spec via %_local_file_attrs macro.
This allows enabling file attributes and their dependency generators even if
they are only shipped in the package itself and are not yet installed.
The names need to be separated by colons (:).
Co-authored-by: Florian
%global expands it's the macro body at the time of definition rather than at
the time of use, so it cannot possibly work for the function-like parametric
macros.
I do agree it should raise an error, thanks for reporting.
--
Reply to this email directly or view it on GitHub:
https://github.com/
> As a matter of fact, if I turn this on via:
>
> ```
> echo "Y" > /sys/module/overlay/parameters/redirect_dir
> ```
> the command succeeds
This is an interesting bit that I haven't seen before. That clue reveals what
is no doubt another wonderful rabbithole...
https://www.kernel.org/doc/Documen
I don't know what rpmlint does, it's a separate project.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2875#issuecomment-1943732006
You are receiving this because you are subscribed to this thread.
Message ID:
That said, you can already make rpm ignore unpackaged files. Just flip
%_unpackaged_files_terminate_build to zero.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8464016
You are receiving this because you ar
That's a workflow problem really. Making rpm look the other way is not a
solution.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8463982
You are receiving this because you are subscribed to this thread.
Me
Right. Well, that's exactly why the *packager* needs to decide where those
files belong.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8462949
You are receiving this because you are subscribed to this threa
Yeah, could be a rebase incident. It's dead code anyhow.
Not exactly a bug, but thanks for reporting.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2904#issuecomment-1943317701
You are receiving this because you are subscribed to this
Closed #2904 as completed via 41974f46f90473e395731e22fb2f89c561971e33.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2904#event-11798578252
You are receiving this because you are subscribed to this thread.
Message ID:
__
No.
systemd is widely packaged already, I'd pick up an existing spec as a basis
instead of reinventing the wheel.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8462832
You are receiving this because you ar
Closed #2857 as completed via #2903.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2857#event-11798448522
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
Merged #2903 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2903#event-11798448279
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
This isn't the only place where a misplaced %config can yield weird results
though. I think we should just strip the %config bit out from the file flags
entirely, in rpmfilesPopulate() probably. Kinda like we fixup missing rpmlib()
flags in rpmdsNewPool().
--
Reply to this email directly or vi
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, &files) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strl
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, &files) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strl
Mmm, but with current master the test would be running on Fedora because
there's no native test-suite for Ubuntu? Those matryoshkas as really out to get
us now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-19413597
@pmatilai pushed 1 commit.
3b787e5c375f830180c2e0bc8643cb80c23cc277 Let eBPF ELF files be packaged in
noarch packages
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2902/files/91f4d3fd56c41faa2f21db17f4bdff10cb01d746..3b787e5c375f830180c2e0bc8643cb80c23cc277
You are
eBPF ELF represents a virtual machine where our file colors make no sense at
all. Filter out the color from these files to avoid a "Arch dependent
binaries in noarch package" error from them in noarch packages.
We don't want to pull in clang to the check images just because of this, so
add a pr
Merged #2901 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2901#event-11784881206
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Ninja doesn't support passing environment as command line arguments like
make does, access TESTOPTS through environment instead of the make syntax to
make it work for both generators.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm
Merged #2900 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2900#event-11784582614
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Merged #2898 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2898#event-11784579272
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Solved a bit differently by just dropping the bogus BYPRODUCTS directives:
#2900
Thanks for reporting, and the patch even if it didn't get used as-is!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2820#issuecomment-1940624460
You are
Closed #2820.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2820#event-11784571037
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
BYPRODUCTS is only relevant for Ninja generator which we officially don't
even support, but on which these usages cause Ninja to error out with
"phony target names itself as an input" messages.
I don't remember why exactly I put these BYPRODUCTS in there, but I know it
was NOT to support Ninja
You compile it the same as any autotools software: grab the release tarball
(not git branch), ./configure and so on. The rpm version being several years
older than the distro you'd be compiling it on could cause issues with library
and compiler compatibility and such. Any breakage you get to kee
There hasn't been much direct activity here recently, but doesn't mean no work
has been going on. I'm planning to produce an updated version of the draft in
the coming weeks, but the main point is going to be:
The overriding priority for V6 is the obsolence of V4 crypto. We need a
replacement f
FWIW, this is now (briefly) documented in
https://rpm-software-management.github.io/rpm/manual/format_header.html#immutable-regions
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8439422
You are receiving th
I only remember a couple of tickets where the issue was rpmbuild being
interactive, eg #978.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2898#issuecomment-1938331913
You are receiving this because you are subscribed to this thread.
Yup, there's a lot of related detail which deserves to be documented, but this
must not become a 1000 page packaging guide. My primary goal here is a TLDR
version of the higher level principles behind rpm operation, such as pristine
sources and unattended operation, that you can point the uninit
> Was it ever possible, at any point in the history of RPM, for a RPM package
> to be created without a version or a release?
No. Absolutely not.
A package with empty or missing name, version, release, arch, os, license or
summary tags is simply invalid, and rpm could and should (but apparently
Even max-rpm philosophy section points out that rpm builds are unattended, but
then we do nothing at all to prevent it? I first though maybe this regressed
when we switched the build scripts to use rpmfcExec() a few years ago, but
there wasn't anything before that either. Weird.
You can view, co
Max-rpm has a section on
[philosophy](https://ftp.osuosl.org/pub/rpm/max-rpm/ch-rpm-philosophy.html) but
it's a source one doesn't really want to link to because it's *s* outdated
now. We should have a section explaining the fundamental design principles of
rpm in our reference manual, many
In other words, this all would make a whole lot more sense to me if there was a
switch that decides where the buildtime gets set from
(clock/macro/source_date_epoch), and then the clamping options relate to
*buildtime* and not source_date_epoch. @ffesti mentioned elsewhere that maybe,
instead o
We have `%_buildhost` macro which seems like it should be paired with
`%_buildtime` so adding that seems to make sense, but I guess the latter is
missing because you can set it with SOURCE_DATE_EPOCH if you care. I'd totally
fine with adding `%_buildtime` override if that means tossing the
`?us
Dropping from 4.20, as there's zero benefit to doing so just now. We're not
bumping the soname in 4.20 so we couldn't remove rpmGetArchInfo() /
rpmGetOsInfo() from the API and so we couldn't remove the associated number
data yet either. We've waited this long, we can wait a little more.
--
Rep
Closed #2755 as completed via 7f59c7dd2f4ff1476bec5c59f37babb1fd231e5a.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2755#event-11755075899
You are receiving this because you are subscribed to this thread.
Message ID:
__
Merged #2883 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2883#event-11755075580
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
After mulling on it for a few days, I don't know what *else* we should do with
this really. And, it doesn't seem to be pulling a whole lot of attention
either. Let's just merge.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2883#issuec
@pmatilai commented on this pull request.
> @@ -2413,6 +2414,7 @@ runroot rpm -q --provides -p
> /build/RPMS/noarch/bcondtest-1.0-1.noarch.rpm |
],
[])
+
Couple of unrelated empty lines getting added here and above, and also just
before and between the new tests. It's a good idea to eyeba
Closed #2886.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#event-11754968569
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
Okay this PR served its purpose, lessons learned: not this way, and not just
now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1935490089
You are receiving this because you are subscribed to this thread.
Message ID
Merged #2893 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2893#event-11754933396
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
This started life as pkgdump.c written way back when I needed to analyze some
low-level issues with malformed packages and the like. Since then it's
proven necessary every once in a blue moon, so might as well include it in the
rpm codebase where it may actually be kept up to date and even evolv
> I think the database is abnormal because the verification fails when I run
> the rpm command,
You mean 'rpm --verify'? What errors?
> or the "rpm -qa" command cannot find the kernel package, but the "rpm -q"
> command can find the kernel package. According to the result, the problem is
> ca
Okay, managed to produce one by myself:
> [pmatilai🎩︎localhost ~]$ clang -target bpf -c bpf.c -o bpf.o
> [pmatilai🎩︎localhost ~]$ file bpf.o
> bpf.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), not stripped
So it's an architecture by itself, speced to be always 64bit:
https://www.ietf.
Other ponderings include the per-build directory macro name, should it be just
%builddir without the underscore (instead of %pkgbuilddir)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931865327
You are receiving this
Merged this into a single commit at least for now as the changing paths clashed
in maddening ways in the test-suite on rebases, making simple changes too hard
to bother with.
Buildroot is just BUILDROOT now. I would've used name-version-release.arch for
the per-build directory, but this turns
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ",
@pmatilai pushed 1 commit.
9d19699f6c8dc0c3eeaf8dcea820e76171aac84d Introduce an rpm-controlled per-build
directory
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885/files/80a60aa2bddb78a897e6279891ec58d862d92d74..9d19699f6c8dc0c3eeaf8dcea820e76171aac84d
You are re
The thing is (well, one of the things) is that, foo-1.0/foo-1.0 can mask a bug
or packaging error. The ugly -PKG suffix was absolutely necessary for seeing
which path a thing is actually trying to use when developing this PR, and will
be equally necessary for packagers trying to troubleshoot som
Um, what exactly do you mean by "database being abnormal" then?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931688028
You are receiving this because you are subscribed to this thread.
Message ID: _
AFAICS --target was always wrong from the autoconf cross-compilation
terminology point of view. For what it does in rpm, --host would be closer to
the mark. But outside a autoconf terminology explanation, would anybody ever
guess that --host somehow relates to output architecture and stuff?
--
> Not a fan of the `-PKG` and `-root` suffixes.
The -PKG is ugly for sure, but *some* differentation from the traditional
%setup created directory seems necessary to drive the point across, and make
logs easier to look at. If you just have 'foo-1.0/foo-1.0/' its easy to mix up
etc. NEVRA might
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ",
Nobody knows. See https://github.com/rpm-software-management/rpm/issues/1650
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2889#discussioncomment-8382986
You are receiving this because you are subscribed to this thread.
Message I
Aside from those three-way indiretions making me cringe a bit (not that it
makes any difference here), looks pretty straight-forward to me.
This is one where feedback from active packagers would be useful.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-man
Multiple buildroots could be useful for the the "variant builds" case, but the
arch-os naming doesn't help with *that* at all, the potential benefits I see
are more far fetched. But, it's useful to shake things a bit, it doesn't *have*
to be BUILDROOT just because we've had such a thing in the p
I'll still want to see the "real-world" test cases added to this. The gotchas
and bugs are always in the part that you didn't think needs testing :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929442665
You
@pmatilai commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
globa
One more thing wrt the macro name: I wonder if this is a case where it should
*not* have those leading underscores. The generator itself is full of those,
but the newly added macro here is something directly intended for packager use.
--
Reply to this email directly or view it on GitHub:
https:
@pmatilai commented on this pull request.
> @@ -995,6 +995,25 @@ runroot rpm -qp --requires
> /build/RPMS/noarch/shebang-0.1-1.noarch.rpm|grep -v ^
[])
RPMTEST_CLEANUP
+AT_SETUP([Local dependency generator])
+AT_KEYWORDS([build])
+RPMTEST_CHECK([
+RPMDB_INIT
+
+runroot rpmbuild -bb --quiet
@pmatilai commented on this pull request.
> - bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs = argvSplitString
@pmatilai commented on this pull request.
> - fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+
@pmatilai commented on this pull request.
> - bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs = argvSplitString
> > There are a few memleak fixes
>
> Oh, you mean (some commits from) #2879. Indeed, I somehow ignored this whole
> PR due to it starting with "Add support for ..." 😄 I'll look at those patches
> and see if cherry picking at least some of them would make sense, thanks.
Yup, those. OTOH you cou
@kloczek , this is not about SPECPARTS although if you *look* at the PR, that's
one of the issues that gets solved by this. See #2532 for the background.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929038038
You are
I guess what you mean by "merging" is something entirely different than me &
ffesti think of.
Binary rpm's are immutable end products of a spec which directs rpmbuild to
produce said rpms. Somehow undoing a separation set by the packager is just not
a meaningful operation at all. The only meani
1401 - 1500 of 2663 matches
Mail list logo
