Re: [Rpm-maint] [rpm-software-management/rpm] rpm 4.19 multi x86-64 arch versions (Discussion #2825)
Again, these are just (sub)architectures, and as always, the arch is present in the rpm package file name. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2825#discussioncomment-8076099 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
> Yup. The dependency is tracking the use of syntax that will create a package > that won't work quite right with versions of rpm before 3.0.3. ... >Not a bug. The dependency is written with <= so that the range is closed, as >>= would make the implicit promise "forever". Meanwhile, since the matching >capability is `Provides: rpmlib(VersionedDependencies) = 3.0.3-1` there's only >a single point covered by the overlapping dependency ranges. It makes some sense, but it's definitely counterintuitive. The first statement isn't entirely true because of the "or equals". The second statement almost doesn't matter, because rpm presents the exact versions anyway. And if RPM presents them as a list of capabilities, then why not just match on the capabilities rather than dragging version numbers into it? I guess to make error messages more informative -- assuming that is taken advantage of. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8073170 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm 4.19 multi x86-64 arch versions (Discussion #2825)
Ok so in order to install on cpus of different levels, I need to produce rpms of differnet levels. The level is encoded in the rpm file name? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2825#discussioncomment-8071570 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 3 commits. f161a47fa0ff1349acfd5fa62a58fc2b88a3650d Update format documentation in the manual e452eab72b4df2c9ae8ad8bbcc8a9a2acf1c2b0f Merge header regions document into format document 9f3185cb7bf13f78ad557116325fe75c452944e6 Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/04496586ad15ce3f0fcb724bd69376a6c1386e7d..9f3185cb7bf13f78ad557116325fe75c452944e6 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > @@ -264,3 +256,101 @@ could start at byte 589, byte that is an improper > boundary for an INT32. As a result, 3 null bytes are inserted and the date for the SIZE actually starts at byte 592: "00 09 9b 31", which is 629553). +### Immutable header regions I kept any changes to this document in a separate commit so they can be more easily reviewed. There's plenty of room for improvement still, but this seems halfway reasonable? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1811898925 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > # Package format -This document describes the RPM file format version 3.0, which is used -by RPM versions 2.1 and greater. The format is subject to change, and -you should not assume that this document is kept up to date with the -latest RPM code. That said, the 3.0 format should not change for -quite a while, and when it does, it will not be 3.0 anymore :-). +This document describes the RPM file format version 4.0. The format is subject Done. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1446541624 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. cbebd9eccf2d57132c676a5b14996e8616e4d42b Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/64b4c81b4ae9d1599084676d1a8f999bfc11abfc..cbebd9eccf2d57132c676a5b14996e8616e4d42b You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 3 commits. 1ece805fc54d31715afdc56c7dbb0d35a82863bd Update format documentation in the manual 73403c2ad734c2b816c0f881ac2e822b13bbf7ab Merge header regions document into format document 64b4c81b4ae9d1599084676d1a8f999bfc11abfc Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/c579fbf1a914f96fa14465acec97390197740f54..64b4c81b4ae9d1599084676d1a8f999bfc11abfc You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > # Package format -This document describes the RPM file format version 3.0, which is used -by RPM versions 2.1 and greater. The format is subject to change, and -you should not assume that this document is kept up to date with the -latest RPM code. That said, the 3.0 format should not change for -quite a while, and when it does, it will not be 3.0 anymore :-). +This document describes the RPM file format version 4.0. The format is subject I can add some descriptions of the immutable region. I believe that's documented somewhere, maybe it's worth merging into this document. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1446446353 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
How would that work exactly? Add a `%doc(README)` to replace `%readme`? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8067851 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Strange behavior for multilib (Issue #2837)
The issue was originally reported on DNF5. The problem is that upgrade of `B-1-1.i686` result in RPM in removal of `B-2-2.x86_64` and `B-1-1.x86_64`. The issue is reproducible from commandline, API (Python DNF, C DNF5). The behavior caused for DNF4 complains in callbacks, but DNF5 correctly fails. Not nicely, but it is less problematic then removal of all packages `b.x86_64`. Package `B` does not require anything and provides only `B`. ``` #rpm -q --root=/tmp/dnf_ci_installroot_eajo9b5c B B-1-1.i686 B-2-2.x86_64 B-1-1.x86_64 # rpm -U --root=/tmp/dnf_ci_installroot_eajo9b5c B-2-2.i686.rpm # rpm -q --root=/tmp/dnf_ci_installroot_eajo9b5c B B-2-2.i686 ``` _Originally posted by @j-mracek in https://github.com/rpm-software-management/dnf5/issues/518#issuecomment-1883115076_ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2837 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@dmnks commented on this pull request. > +without the parenthesis defaults to configuration. In other words, +these two lines are exactly equivalent: + +``` +BuildOption: --enable-fu +BuildOption(conf): --enable-fu +``` + +Passing these per-section options to the actual buildsystem of the +package is the responsibility of the buildsystem specific macros. + +3) Complex packages can have things like multiple build systems, in +which case you might want to invoke the macros manually, eg. + +``` +%buildsystem_autotools_build Oh! I like that. Good idea. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#discussion_r1446105078 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
Oh. Any resemblance to Flatpak is purely coincidental, I swear :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1883072742 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@pmatilai commented on this pull request. > +without the parenthesis defaults to configuration. In other words, +these two lines are exactly equivalent: + +``` +BuildOption: --enable-fu +BuildOption(conf): --enable-fu +``` + +Passing these per-section options to the actual buildsystem of the +package is the responsibility of the buildsystem specific macros. + +3) Complex packages can have things like multiple build systems, in +which case you might want to invoke the macros manually, eg. + +``` +%buildsystem_autotools_build Yup. It's ugly, but we really need to namespace those macros so it can't be helped much. For the case of multiple buildsystems in a single package that is. For just manually invoking a random snippet from an active BuildSystem I do have a solution: macro aliases, where you only need to say `%buildsystem_build` to manually invoke the right thing. That was part of an earlier version but left it out because the need for that case is much lower in this new, properly declarative system. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#discussion_r1446101484 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
Also, bonus points for being (perhaps accidentally) consistent with Flapak's naming (`BuildSystem` vs `buildsystem`): https://github.com/flathub/io.gitlab.osslugaru.Lugaru/blob/5580684b5524ddd63d289bbc06cc0305eae189b5/io.gitlab.osslugaru.Lugaru.json#L21 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1883062130 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@dmnks commented on this pull request. > +without the parenthesis defaults to configuration. In other words, +these two lines are exactly equivalent: + +``` +BuildOption: --enable-fu +BuildOption(conf): --enable-fu +``` + +Passing these per-section options to the actual buildsystem of the +package is the responsibility of the buildsystem specific macros. + +3) Complex packages can have things like multiple build systems, in +which case you might want to invoke the macros manually, eg. + +``` +%buildsystem_autotools_build ... but ok, actually thinking about it (not just blindly looking), it's not rocket science - `%buildsystem` is the general namespace, `_autotools` is the build system name and `_build` is, well, the section name. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#discussion_r1446093990 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@dmnks commented on this pull request. > +without the parenthesis defaults to configuration. In other words, +these two lines are exactly equivalent: + +``` +BuildOption: --enable-fu +BuildOption(conf): --enable-fu +``` + +Passing these per-section options to the actual buildsystem of the +package is the responsibility of the buildsystem specific macros. + +3) Complex packages can have things like multiple build systems, in +which case you might want to invoke the macros manually, eg. + +``` +%buildsystem_autotools_build To elabore a bit (since I was quite unspecific above), what I mean by "verbose" is that this macro name consists of 3 separate parts, each of which I'm surely going to need to look up every time I use them (which, again, shouldn't be too often) :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#discussion_r1446092953 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@dmnks commented on this pull request. > +without the parenthesis defaults to configuration. In other words, +these two lines are exactly equivalent: + +``` +BuildOption: --enable-fu +BuildOption(conf): --enable-fu +``` + +Passing these per-section options to the actual buildsystem of the +package is the responsibility of the buildsystem specific macros. + +3) Complex packages can have things like multiple build systems, in +which case you might want to invoke the macros manually, eg. + +``` +%buildsystem_autotools_build This is probably the least favorite part of mine, in terms of verbosity, but I suppose it can be tweaked later. Also, it's not the common happy path anyway so, as a packager needing an advanced/non-standard build procedure, once you open the lid and peek inside, you're already on your own anyway :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1811152919 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
> I personally hate whenever I need to look up the correct syntax for line > breaks in a config format OK, maybe this point is moot since I guess the line break syntax really is actually the SPEC's native one... but you get the point :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1883051653 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
I'm a bit late to the :tada: but as far as the overall solution, I'm giving the tag-based variant (`BuildSystem:`) implemented here a :+1: . I'm also giving a :+1: to the shorter Build* namespace (the Auto prefix really had to go :smile:). It looks to me like the cleanest and most flexible variant of all those mentioned [previously](https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794302784), too. In particular, the possibility to interleave these with the other tags (such as `BuildRequires:`) makes it pretty neat as you can cluster those together if they're part of a conditional (as mentioned in the linked comment). I personally hate whenever I need to look up the correct syntax for line breaks in a config format, this alleviates that problem since you just declare multiple of these tags. Yes, it's a bit noisy but somehow reminds me of CMake (as you also mentioned previously) and I guess I've developed the Stockholm syndrome already because I kinda like (or rather, don't mind) it too much :laughing: As for the technical side of things, no opinion yet, I'm going to look at that next. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1883049845 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@voxik commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. > Oh, we have a confirmed rpm-maint reader. I've suspected nobody looks at that > anymore because volume and format... At least my rumbling was good for something :see_no_evil: Yes, rpm-maint is the most consumable format allowing to follow what is going on with RPM. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445992798 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@pmatilai commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. Ack, I thought they should be forwarded along with all the other traffic. And, if not then it should at least be possible. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445989261 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@voxik commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. > Just FTR, I dislike the discussions, mainly because I read everything through > rpm-maint ML and the discussions are not forwarded there AFAICT. Hm, checking the archives, I was wrong. I might change my mind, sorry for the nose. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445986728 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@pmatilai commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. Oh, we have a confirmed rpm-maint reader. I've suspected nobody looks at that anymore because volume and format... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445986274 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Have templates for ticket creation (Issue #2752)
Closed #2752 as completed via #2836. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2752#event-11429242342 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2836)
Merged #2836 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2836#event-11429242051 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@voxik commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. Just FTR, I dislike the discussions, mainly because I read everything through rpm-maint ML and the discussions are not forwarded there AFAICT. And I don't know if there is any meaningful way to subscribe to discussions, but I don't see any on the first look. IOW they might look like the best tool for the team or project members, but IMHO, they prevent collaboration in wider community. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1445974565 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
Closed #2823. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#event-11428661154 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
*urgs* this was created as branch in the main repo by the GH UI (and though can't be force pushed...). Created an new PR from my private repo. Closing this here. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#issuecomment-1882841796 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2836)
Updated version of #2836 which was created as branch in the main repo by the GH UI (and though can't be force pushed...) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2836#issuecomment-1882838761 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2836)
Have a bit of structure for the bug reports to tell people what information is expected/necessary. Point people to discussions for RFEs and have RFE tickets only be created after a course of action has been decided on. Resolves: #2752 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2836 -- Commit Summary -- * Create Issue templates for Bug reports and RFEs -- File Changes -- A .github/ISSUE_TEMPLATE/bug_report.md (32) A .github/ISSUE_TEMPLATE/feature_request.md (22) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2836.patch https://github.com/rpm-software-management/rpm/pull/2836.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2836 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove cycles from CMake dependency graph (PR #2820)
Right, I remember encountering this pattern somewhere. Always looked like one of those cmake WTFs for me, which is probably why I tried to find some other way to do it. And as such, it was probably always for the worse. I'll accept changing this for correctness, but note that we officially only support "make" based builds as per INSTALL. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2820#issuecomment-1882664462 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove cycles from CMake dependency graph (PR #2820)
@pmatilai commented on this pull request.
> @@ -434,17 +434,17 @@ function(add_tarball targetname namever treeish)
set(distname ${tarname}.bz2)
set(docname ${namever}-doc.${distfmt})
- add_custom_target(${docname}
- DEPENDS man apidoc
+ file(GLOB man_pages docs/man/*.[1-8])
What's the reason for this? AFAICS the tarball gets updated on man page changes
as it is, through the "man" target.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2820#pullrequestreview-1810685786
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > +they store can be found [here](signatures_digests.md). + +RPM v4 packages are expected to contain at least one of SHA1HEADER or SHA256HEADER +tags, providing a cryptographic digest of the main header, and may contain one +or both of the PAYLOADDIGEST and PAYLOADDIGESTALT tags, providing a cryptographic +digest of the package payload in the compressed and uncompressed forms, respectively. + +If the package has been cryptographically signed using OpenPGP, an RSAHEADER or +DSAHEADER tag ought to be present, which contains an OpenPGP signature of the +package header. Which tag is present depends on which of the two (supported) +OpenPGP algorithms was used at signing time. Using a key based upon the RSA +algorithm to sign the package will result in the signature being stored in the +RSAHEADER tag, whereas the use of the EdDSA (ed25519) algorithm will use the +DSAHEADER tag instead. The name of the DSAHEADER tag is a historical artifact, +it originally referred to the long-obsolete DSA algorithm but was later reused +for EdDSA (ed25519) signatures. Possible? Technically yes but it doesn't make it any more right or any easier for the user, only more confusing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445797752 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request.
> @@ -435,7 +435,7 @@ typedef enum rpmSigTag_e {
RPMSIGTAG_RESERVEDSPACE = 1008,/*!< internal space reserved for signatures
*/
RPMSIGTAG_BADSHA1_1= RPMTAG_BADSHA1_1, /*!< internal Broken
SHA1, take 1. */
RPMSIGTAG_BADSHA1_2= RPMTAG_BADSHA1_2, /*!< internal Broken
SHA1, take 2. */
-RPMSIGTAG_DSA = RPMTAG_DSAHEADER, /*!< internal DSA header
signature. */
+RPMSIGTAG_DSA = RPMTAG_DSAHEADER, /*!< internal EdDSA header
signature. */
Ditto here, DSA or EdDSA.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1810668926
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > Tag Name | Value| Type | Description --|--|--| -Dsaheader | 267 | bin | OpenPGP DSA signature of the header (if thus signed) -Longsigsize | 270 | int64| Header+payload size if > 4GB. +Dsaheader | 267 | bin | OpenPGP EdDSA signature of the header (if thus signed) This needs to be "DSA or EdDSA" really, EdDSA is a *very* new addition in the v4 timescale. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1810668237 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > +unique tags (just like the Header). Details about these tags and the > information +they store can be found [here](signatures_digests.md). + +RPM v4 packages are expected to contain at least one of SHA1HEADER or SHA256HEADER +tags, providing a cryptographic digest of the main header, and may contain one +or both of the PAYLOADDIGEST and PAYLOADDIGESTALT tags, providing a cryptographic +digest of the package payload in the compressed and uncompressed forms, respectively. + +If the package has been cryptographically signed using OpenPGP, an RSAHEADER or +DSAHEADER tag ought to be present, which contains an OpenPGP signature of the +package header. Which tag is present depends on which of the two (supported) +OpenPGP algorithms was used at signing time. Using a key based upon the RSA +algorithm to sign the package will result in the signature being stored in the +RSAHEADER tag, whereas the use of the EdDSA (ed25519) algorithm will use the +DSAHEADER tag instead. The name of the DSAHEADER tag is a historical artifact, +it originally referred to the long-obsolete DSA algorithm but was later reused It's not a historical artifact in the context of package format, there exists mountains of DSA signed rpm v4 content. That the algorithm is now obsolete is of little consequence when we're describing a format with a timespan of > 15 years. But yes, EdDSA and DSA share the same tag. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1810658045 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > -header structure: - -``` - NameTag Header Type - --- - SIZE1000INT_32 - MD5 1001BIN - PGP 1002BIN -``` - -The MD5 signature is 16 bytes, and the PGP signature varies with -the size of the PGP key used to sign the package. - -As of RPM 2.1, all packages carry at least SIZE and MD5 signatures, -and the Signature section is padded to a multiple of 8 bytes. +"Header-style" signatures (denoted by signature type 5 in the Lead), use the Rpm doesn't look at the lead except for the magic, so it's totally irrelevant. Even rpm v3 only supported header-style signatures IIRC. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445781579 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > ``` 0008: 00 01 72 70 6d 2d 32 2e..rpm-2. ``` -The next two bytes (8-9) form an int16 that indicates the architecture -the package was built for. While this is used by file(1), the true -architecture is stored as a string in the Header. See, lib/misc.c for -a list of architecture->int16 translations. In this case, 1 == i386. No wonder, the arch translations have been in the declarative rpmrc config file for over twenty years. This is one of the docs thats *so old* it makes you wonder if its worth trying to patch it up... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445778572 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > @@ -23,17 +23,20 @@ package file is divided in 4 logical sections: . Payload -- compressed archive of the file(s) in the package (aka "payload") ``` -All 2 and 4 byte "integer" quantities (int16 and int32) are stored in -network byte order. When data is presented, the first number is the -byte number, or address, in hex, followed by the byte values in hex, -followed by character "translations" (where appropriate). +All 2 and 4 byte "integer" quantities (int16 and int32) are stored in network +byte order (big-endian). When data is presented, the first number is the byte +number, or address, in hex, followed by the byte values in hex, followed by +character "translations" (where appropriate). I'd not touch the wrapping because it makes it difficult to see the actual content change. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445775312 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@pmatilai commented on this pull request. > # Package format -This document describes the RPM file format version 3.0, which is used -by RPM versions 2.1 and greater. The format is subject to change, and -you should not assume that this document is kept up to date with the -latest RPM code. That said, the 3.0 format should not change for -quite a while, and when it does, it will not be 3.0 anymore :-). +This document describes the RPM file format version 4.0. The format is subject This does not describe v4 file format, so we should not bump the number either. For v4, the by far most important item is the immutable region and that is not even mentioned anywhere here. Not surprising since most of the content is from the initial commit in 1996 (cdd4c29192131e1b6a3369b10f324928336a63da) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445773446 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm 4.19 multi x86-64 arch versions (Discussion #2825)
The arch levels are not a new feature, just new sub-architectures. Think i386 getting expanded to i486, i586 and i686 back then, and similar levels exist on arm already. The rpm arch only works as package level differentiator and to ensure you can't install a package eg for level 4 on a level 3 host. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2825#discussioncomment-8061837 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
%readme as a spec directive may be obsolete, but there's no reason to drop support for the virtual file attribute. On the contrary, if it was properly integrated with %doc it would be nice to 'rpm --show-readme mypackage' instead of having to chase around in /usr/share/doc. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8061782 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
