Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)
There's also an alternative way to buffer all rpmlog() output. If rust has some reasonable XML support, then data can be exported from a header into whatever structure you wish rather effortlessly. E.g. try "rpm -q --xml bash". The --xml is just a queryformat disguised as a CLI option using a popt alias. Per-tag queryformats could be used. -- 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-381822461___ 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)
Overriding qva->qva_showpackage with a short routine that does str = headerFormat() is what I was recalling having 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/issues/429#issuecomment-381815368___ 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)
Ah my bad: yes, the output is delivered to stout/stderr. And yes rpmcliQuery. Meanwhile, all the output for each header ends up in a single buffer and a single fprintf iirc. So it would not be hard to deliver the headerFormat output for each header through a callback. Delivery of textual info from rpmcliQuery would make bindings rather easy. -- 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-381811098___ 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)
> Thanks for the update, but I've been asking NOT to drag in the entire > lua-compat thing Right. Which is why I've asked *many* times (including via email and IRC) how to introduce a new dependency for rpm. > If you need a place to stick the actually required "~20 lines" of > compat-macros/inline functions, I suppose rpmio/rpmlua.h could be used for > that, it's an internal header anyway. I don't think this is a good path: it would make it hard to merge in upstream changes of lua-compat-5.3 as well as require that people who change code to use new lua functions add in new definitions. > the integration should be along the lines of "download latest version from , > unpack and (re)run configure, enjoy". Okay. so that's all that is required for adding a dependency? -- 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-381785133___ 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 where is `rpmQuery` defined? (is it `rpmcliQuery`?) This is all I could find, and it wasn't immediately obvious how to read results from it: http://ftp.rpm.org/api/4.12.0.1/group__rpmcli.html#ga2dbfa3886628a79646b2c286ea5c56d9 -- 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-381684450___ 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)
Again, look at headerFormat() bindings which is kind of like asprintf(3) for headers and you can then parse the string into whatever rust types you wish within rust. I previously suggested you might want to bind the high level rpmQuery() same as the CLI rpm --query --queryformat ... command to avoid having to use a match iterator or headers (which would be used only in rpmQuery). -- 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-381645193___ 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)
See lib/rpmtag.h: where the tags are defined. The usual type is appended in the comment. There is also rpm -vv --querytags which displays the known tags and types (if RPM4 doesn't display the types, then an RFE is appropriate) -- 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-381640962___ 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)
Garrison "... possibly with count 1". Specifically a RPM_CHAR_TYPE returns a pointer to data and count is the number of chars in that array. A CHAR scalar is returned as an array with count 1, ditto for INT* types. -- 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-381639532___ 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 I am not... definitely good to know as the current code is bogus. What'd be really helpful in regard to testing tag data is a tag type which corresponds to each of the tag data types, particularly arrays/vectors of the integer types. -- 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-381638452___ 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)
(After perusing the td.rs code: perhaps I am misreading some assertions) Hmmm ... you do realize that only BIN/STRING/I18NSTRING types are scalars? Specifically, that means that CHAR and INT* types return a pointer to an array with count items. Of course BIN is an array of octets, and STRING is an array of chars: but CHAR and INT* are arrays possibly of size 1. -- 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-381632025___ 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)
@pmatilai using "owned" memory instead of borrowed, in Rust terminology, is an alternative, and one that could potentially eliminate any possible use-after-free vulnerabilities. However, building zero copy APIs on top of things like `HEADERGET_MINMEM` is something of Rust's raison d'etre, and one for which it has a number of neat tricks, like the `StreamingIterator` I was using previously. That approach would cause the compiler to reject any programs where the match iterator's `next()` method is called while there are still references sourced from the previous header are still alive. I'm not sure in what other languages something like that is even possible, especially as a compile-time guarantee. The PR I just linked goes from the very conservative memory model I was just describing to one that makes many more assumptions which I'm not entirely sure are correct. As you note I may be incorrectly handling string arrays. Perhaps there's a happy medium that more tightly bounds the lifetimes and then makes fewer assumptions. I can at least guarantee the following in the current binding based on the Rust lifetimes: - Nothing will ever outlive the global transaction set - MatchIterators acquire a global mutex and do not release it until they have been "dropped" - Headers increment the reference count with `headerLink` and do not decrement it until they are "dropped". They are `!Sync` and `!Send` (i.e. not thread safe or moveable between threads) and therefore "pinned" to the thread in which they are created (the same goes for MatchIterators) - Tag data is guaranteed to never outlive the header from which it is fetched, ensuring the header's reference count is never decremented (via `headerFree`) until there are no longer references to its tag data (this is enforced via a [Rust lifetime](https://github.com/iqlusion-io/crates/blob/master/rpmlib/src/td.rs#L11) but is a fairly similar approach to what you'd use in a GC'd language by having tag data mark the header from which it is fetched). > FWIW, I don't see a reason why the bindings could not be "hosted" in the > rpm-software-management group, it'd be only a good thing to have these things > under the same umbrella. That'd be great. I've been thinking about splitting the current code into its own repo and relicensing it as LGPL 2.1+ to move towards 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/issues/429#issuecomment-381610231___ 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)
I'd really recommend avoiding HEADERGET_MINMEM entirely because of all the hidden implications, just use HEADERGET_ALLOC always so you can trust the data isn't going to vanish or move underneath you, like n3npq said you need to manage unallocation anyway for string arrays. As for handling tag data, you probably don't want to expose rpmtd to rust directly but convert to native representation - that's what the "native" python bindings do. I started adding an actual python binding for the rpmtd object at some point and it just didn't make any sense at all. Encoding generally speaking anybody's guess, but packages built with rpm >= 4.13.0 carry RPMTAG_ENCODING with value of "utf-8" if the strings in the package were all valid utf-8. FWIW, I don't see a reason why the bindings could not be "hosted" in the rpm-software-management group, it'd be only a good thing to have these things under the same umbrella. -- 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-381572167___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: make rpm object ref counting atomic (#431)
This is an identical duplicate of #430, closing. -- 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/431#issuecomment-381564764___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: make rpm object ref counting atomic (#431)
Closed #431. -- 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/431#event-1575986977___ 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)
Oh, and in case it turns out it's not "~20 lines" but "~2000 lines" (as in: the full compat-lua thing *is* required in practise): in no case do we want the compat-lua code imported into rpm git. If the entire compat-lua is required, the integration should be along the lines of "download latest version from , unpack and (re)run configure, enjoy". -- 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-381564514___ 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)
Thanks for the update, but I've been asking NOT to drag in the entire lua-compat thing. If you need a place to stick the actually required "~20 lines" of compat-macros/inline functions, I suppose rpmio/rpmlua.h could be used for that, it's an internal header anyway. -- 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-381560993___ 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)
My largely uneducated take in this is... how about we just forget the exception clause about specialized environments and just define armv8 in rpm to mean standard armv8? -- 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-381556571___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
