Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)
I think this makes most sense (and is what I implemented in the original patch): armv8l == old ABI compatible with armv7l armv8hl == old hardfloat EABI compatible with armv7hl armv8hnl == armv8hl + neon, compatible with armv7hnl armv8hcnl == armv8hnl + crypto extensions ILP32, if properly implemented, probably needs a new name (if not a variant of aarch64, given it's closer to aarch64 than to armv7hnl? I'd be leaning towards aarch64_32 or something like that) -- 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/425#issuecomment-382123819___ 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 armv8* arch variants to rpmrc.in (#425)
@pmatilai someone brought to my attention today there is various confusion as to what 'armv8' actually means (for a package type). Does it mean traditional 32-bit ABI using instructions available on an 'ARMv8' processor? or does it mean using ILP32 ABI using all of the aarch64 instructions? In the former case, the ABI is compatible with armv7 and older.. in the later case, it's a new ABI. If you can make it clear ARMv8 is just the compatible with everything else version -- then it's just another marker... someone can add something new for ilp32 mode, if it is ever implemented. -- 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/425#issuecomment-382121817___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)
@tarcieri: I am not particularly fond of XML either, but using headerFormat() queryformat to export data from a header simplifies bindings for what is usually desired: masses of RO metadata about rpm packages, an entirely well understood programming technique. Note that rpm -q --xml is also WYSIWYG, and displays everything in a header, if you wish to familiarize yourself with rpm package metadata. -- 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/429#issuecomment-382025752___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)
@n3npq can't say I'm super thrilled with the prospects of replacing access to an in-memory data structure with something based on XML >As for handling tag data, you probably don't want to expose rpmtd to rust >directly but convert to native representation [...] > Worse, any data addition to a header can make the data retrieved with > HEADERGET_MINMEM invalid behind your back. HEADERGET_MINMEM should really be > considered a historical leftover and an rpm internal thing at best, it's not > something you want to build anything on. Alright, perhaps I can take a step back from the reference-based stuff and take a look at creating "owned" values... although my preferred way to do that in Rust would be for Rust to make a copy itself, as opposed to having rpm allocate the memory and me having to call rpm again to free it. That way Rust owns the memory and I can leverage Rust's built-in destructors. This was my original plan when I was using a `StreamingIterator`: make `Header` and `rpmtd` access internal to the library only, and expose a real Rust `Iterator` which makes copies of the data it iterates over when exposing them to the end user of the library. -- 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/429#issuecomment-382019238___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Permit applications to append tags to headers simply (#432)
The discussions about AUTOINSTALL are the basis for this RFE. The obscure callback to re-read a package header should be reworked to permit tags to be simply added (note added, not replaced) by applications when desired. The simplest (I.e. least intrusive) interface I can think of is to save all tags appended to an immutable region when added to a transaction, including the renumbered merged signature tags, as well as any tags appended by an application, and re-appending those tags after the existing callback to reload a header. Unlike the proposed patch to carry an additional "tag bag" container when a package is added to a transaction, the operation should be done internally to rpmlib to insure proper filtering (and possible renumbering as in signature tagnos) of values, and to avoid proliferating nearly redundant API's in rpmlib. RPM is already carrying merged signature tags appended to the metadata header, so this RFE is proposing little more than using the header added to the transaction as a reference, rather than the package signature header, to determine what tags should be appended to the metadata header. -- 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/432___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts: add brp-mangle-shebangs (#344)
Thanks. -- 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/344#issuecomment-381957380___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts: add brp-mangle-shebangs (#344)
Closed #344. -- 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/344#event-1578577920___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts: add brp-mangle-shebangs (#344)
Added to rpm-extras instead, as a part of bringing Fedora brp-scripts in: https://github.com/rpm-software-management/rpm-extras/commit/273bb7004cda560a234a299c06636b762184e03e Further discussion + refinement can be handled on that side, closing this one. -- 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/344#issuecomment-381957010___ 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 brp helper scripts from mandriva's spec-helper (#122)
Added the brp scripts to the rpm-extras repo. Further discussion and refinement can happen there. Closing the PR here. -- 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/122#issuecomment-381924876___ 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 brp helper scripts from mandriva's spec-helper (#122)
Closed #122. -- 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/122#event-1578364709___ 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)
And I've been telling you what I want: pull the bare minimum required compat magic into rpm. Remember the compatibility requirement for Lua is not a permanent thing but a relatively short-term thing (1-2 years at most) and there's so little change in our Lua department, new additions are hardly a concern. I'd like to see what the "~20 lines of copy-paste" would look like in reality before considering external dependencies. -- 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-381921157___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)
@tarcieri , headers exist outside database iterators and such, and you really dont want to require keeping potentially huge headers (tens of megabytes possibly) in memory just in order to remember, say, a name of a package. Worse, any data addition to a header can make the data retrieved with HEADERGET_MINMEM invalid behind your back. HEADERGET_MINMEM should really be considered a historical leftover and an rpm internal thing at best, it's *not* something you want to build anything on. -- 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/429#issuecomment-381909280___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
