If `local_generator.attr` file exists then `local_generator` created twice. Why
not simply create an empty `local_generator.attr` file instead?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1779258988
You are
@dralley pushed 1 commit.
2d69151aa250d1dde056ed009c0fa644685da01c Remove lead checks other than the
"magic number" check
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2736/files/01ae94b0b1cfa60bbd98d050b40aef36701f7190..2d69151aa250d1dde056ed009c0fa644685da01c
You
Remove checks on the leads signature type and rpm
package format version fields.
closes #2423
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2736
-- Commit Summary --
* Remove lead checks other than the magic number
Closed #2085 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2085#event-10767718055
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Sorry for the late answer! The spec file runs the rpm test suite which needs
fakechroot. It's possible that it is either not available or not working
properly on RISC-V Linux. Note that the current release do use a different
technology for isolating the test suite.
I am closing this as it is
FTR, I've stumbled upon these two recent PRs that somewhat extend the scope of
`--root` and may act as some kind of precedent if we choose to involve macro
configuration, too:
* #2582
* #2503
--
Reply to this email directly or view it on GitHub:
Yeah, it seems that `%_buildhost` might be enough. I'm just starting to work on
this again, so I didn't have time to figure out the details.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1779525256
You are receiving
We are not planning to add such an option. While we have stricter requirement
for the backward compatibility of SRPMs than for normal packages they do not
include backward compatibility for all time. Closing.
--
Reply to this email directly or view it on GitHub:
Closed #2727 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2727#event-10766717419
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
So I think going back to the old behaviour is just not worth the trouble - even
if it may be easy to do code wise. So all that's left is cleaning up the code a
little bit. Not keeping a ticket open for stuff like that - otherwise we had
tickets for each line of RPM code...
--
Reply to this
Closed #2319 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2319#event-10766742033
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The name should imply this is a per-spec thing, so I don't think "find" is
good. "local" is much better, but in rpm context I tend to associate that with
"this host" rather than per package.
"spec" seems accurate, because it is a per-spec thing. But then that makes me
think of dependencies of
Hmm, but just "package" kinda gives the idea that these are the only
dependencies this package will have, which is not the case. "package_local"
maybe?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1778645654
You are
> This is mixing two separate issues. The one originally discussed here is
> about RPM respecting the config/macro files in the target root when
> called with --root. Populating the root with the desired configuration
> is a then a separate matter and one that would need to be discussed on
>
Hmm, on a random sampling (strtok, ls, systemd-inhibit, ssh, bash, auditd,
getopt, grep, xhost, vim), bold was by far the most common style. That's what
"man man" also uses, which one could think of as the "canonical source of
truth" I guess. Italics (or underline as it renders for me) is
@ffesti pushed 1 commit.
557112f44791d499b3a5208329a01846af63f480 Use uniform formatting for SEE ALSO
sections
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2732/files/2449e94632bab36a52bd5cafbff2ac03e86790ed..557112f44791d499b3a5208329a01846af63f480
You are
I don't have a strong opinion. Guess it depends on what pages you sample. I
just switched to bold.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2732#issuecomment-1778994409
You are receiving this because you are subscribed to this
@voxik pushed 1 commit.
33c10c89387b168bceaa93ee2be7c6210a90aa2e Add "local_generator"
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/4b04cc38167dd637c3c1f68bf6d858453ccf24a1..33c10c89387b168bceaa93ee2be7c6210a90aa2e
You are receiving this because you are
Thinking some more, not populating the lead will only hurt compatibility with
*zero* actual benefits. What is beneficial though is not populating the os/arch
information because *that* is not used by any rpm in this millenium, but forces
us to carry these artificial arch/os numbers around.
--
@voxik commented on this pull request.
> char *bn = basename(files[i]);
bn[strlen(bn)-strlen(".attr")] = '\0';
fc->atypes[i] = rpmfcAttrNew(bn);
}
+ fc->atypes[nattrs - 1] = rpmfcAttrNew("local_generator");
The `nfiles` could be used here
@voxik pushed 1 commit.
8a532b24e527f48cc45f7f49fc24d6fc4be39d49 Add "local_generator"
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/33c10c89387b168bceaa93ee2be7c6210a90aa2e..8a532b24e527f48cc45f7f49fc24d6fc4be39d49
You are receiving this because you are
@voxik pushed 1 commit.
61bd40a9df5170da6182e560d172fb16f4e3213b Add "local_generator"
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734/files/8a532b24e527f48cc45f7f49fc24d6fc4be39d49..61bd40a9df5170da6182e560d172fb16f4e3213b
You are receiving this because you are
@dralley , I've come to my senses wrt this now :laughing:
Feel free to submit a PR to drop the checks if you like.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2423#issuecomment-1778852519
You are receiving this because you are
> I have to say, there's beauty to the simplicity of this. Would be even
> simpler if the new generator was added as the last thing to the array I think.
Done. On top of that, I have added also some test case. The other generator
abuses `script.attr` AFAICT. Or shell the other test cases be
After discussing this with the team, we agreed that the idea behind this (to
exclude certain (sub)packages from the build) is actually quite reasonable.
It's just that the proposed way of abusing `%files` for this isn't right. We'd
rather have a preamble item (i.e. alongside `Name:`,
I'll convert this into a Discussion, let's continue there. As soon as a
concrete implementation emerges, we'll create appropriate tickets.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2623#issuecomment-1779155171
You are receiving
@dmnks converted this issue into discussion #2735.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2623#event-10766671691
You are receiving this because you are subscribed to this thread.
Message ID:
27 matches
Mail list logo
