Re: [Rpm-maint] [rpm-software-management/rpm] work with lua 5.3 without compat mode (#169)
> In general we want to keep rpm buildable on recent RHEL which in this case > means RHEL-7, and that in turn means Lua 5.1. But compat stuff for older than > that can go, as far as I'm concerned. In that case I recommend you depend on https://github.com/keplerproject/lua-compat-5.3/ there. I'm not sure how you want to introduce that dependency? I often do it with a git subtree. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/169#issuecomment-284964810___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] work with lua 5.3 without compat mode (#169)
In general we want to keep rpm buildable on recent RHEL which in this case means RHEL-7, and that in turn means Lua 5.1. But compat stuff for older than that can go, as far as I'm concerned. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/169#issuecomment-284964031___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for ARM 64bit (aarch64) - Add arm32 and arm64 macros (#173)
@pmatilai Yes, That starts to worry me as well.
Then how about
```
# arm: obsolete. Please do not use %arm to determine %arm32.
%arm %{arm32}
%arm_all %{arm32} %{arm64}
```
?
Compared to the current commit, this makes ARM look ugly, however, at least, we
won't break the current "incorrectly written" codes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/173#issuecomment-284963991___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for ARM 64bit (aarch64) - Add arm32 and arm64 macros (#173)
I've no objections except that the cat is out of the bag already: existing
users of %{arm} are, out of necessity, relying on it to mean just the 32bit arm
versions. Changing that to include aarch64 would almost certainly break stuff
and force people to change what's been working for years.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/173#issuecomment-284962391___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add support for ARM 64bit (aarch64) - Add arm32 and arm64 macros (#173)
Arm 64bit architectures have been around for a while and we'd like to
distinguish arm32 vs arm64 in spec files as well. The usage of %arm macro is
not that rare: in RPM .spec files of my working set (tizen.org), there are 112
occurrences of aarch64 and 163 occurrences of %arm or %{arm}.
Signed-off-by: MyungJoo Ham
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/173
-- Commit Summary --
* Add support for ARM 64bit (aarch64) - Add arm32 and arm64 macros
-- File Changes --
M macros.in (10)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/173.patch
https://github.com/rpm-software-management/rpm/pull/173.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/173
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] work with lua 5.3 without compat mode (#169)
@Conan-Kudo in that case there is code that can be stripped out. e.g. the stuff inside ``` #if (LUA_VERSION_NUM < 502) || defined(LUA_COMPAT_MODULE) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/169#issuecomment-284941483___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] work with lua 5.3 without compat mode (#169)
For what it's worth, I don't think we should have compatibility shims. I'd be fine with having this merged and bumping the requirement in configure to Lua 5.3. Fedora has been using Lua 5.3 with RPM for a while now, and as far as I know, there haven't been any ill effects in doing so. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/169#issuecomment-284941330___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Retrofitting a format version on *.rpm packaging. (#172)
When originally written, the rpmlead contained information used to identify a *.rpm. Twenty years later, most of the rpmlead information is de facto and ad hoc and historical. Progress using other information, like rpmlib(...) tracking dependencies, has managed to associate new "features" (actually "incompatibilities") with an installer that can handle the incompatibilities. There are also magic numbers associated with each of the 4 components in a *.rpm package (I assume that the new rpmarchive payload has an associated magic, but likely doesn't change format version). (aside) In fact, a tracking dependency would have avoided the last version 3->4 format version change that caused LSB to dictate that all *.rpm packages MUST be version 3. *shrug* Tracking dependencies implicitly assume that a Header (with magic) can be loaded, and do not provide a mechanism by which signature/metadata headers can be changed to, say, add a new data type to a Header, which would prevent a header being loaded, which prevents a tracking dependency from being checked. Fundamental sorts of signature/metadata changes might need format versioning (and additional magic as well as tracking dependencies etc) to be handled correctly, unlike changes to a payload format or payload checksum or adding RichDependencies (to name a few incompatibilities that have been finessed through other means). I can certainly devise a means to add a new data type to a Header, or replace a Header with a different container structure (*.deb or *.xar sections in files in a wrapper archive), or even by deliberately changing the rpmlead version++, or even by adding a different *.rpm suffix naming. But the core problem remains: There is nothing but de facto and ad hoc techniques available to change *.rpm format. I think its time to talk about an orderly way to change RPM format rather than waiting for error reports to arrive. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/172___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debugedit.c patches (#171)
I have tested the current rpm4 debugedit within the Yocto Project environment -without- the patch, with the known binary doing cross-compiled work (little to big endian) and have not been able to reproduce the issue. Either debugedit has had a tweak over the years or elfutils has had a bug fixed. (The original defect being resolved by this patch set was related to the "shdr.sh_type" being in the binary endian, not the running system endian.) So it appears there is no need for the specific patch related: https://patchwork.openembedded.org/patch/46887 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/171#issuecomment-284739345___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %include breaks if space is included in path (#125)
Closed #125. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/125#event-989476566___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %include breaks if space is included in path (#125)
Fixed in commit 9d38b2f6d92ef982db2488462619a780c9b87973 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/125#issuecomment-284709515___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Fixed in commit 5adc56897b9da5dac49701f704ef54390db57c59 but that actually depends on the three preceding macro changes, there are all sorts of funnies involved. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/127#issuecomment-284709287___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parametric macro arguments are not expanded (#127)
Closed #127. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/127#event-989475151___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
