Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

FYI: %setup permits multiple tar balls be unpacked into a buildsubdir. Using a parameterized %setup() strips off arguments. At some point, you are better off just not using %setup at all. Expand into shell commands that unpack (or checkout) whatever you wish. There's also little reason why you

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

@nim-nim: you can likely already do this, provided you have some means to overload %setup before the invocation in the spec file. Macros are expanded before %setup is processed. So a definition like %define setup %%setup -c -n whatever will append (actually interpose, but you can use a

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

@nim-nim OTOH, note that builds on a public branch (i.e. no authorization), downloaded through https/ssh (so small chance of maliciously modified), on a tagged/documented check-in located in an upstream VCS repository, are entirely maintainable, as well as being consistent with RPM's goals of

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

The example is %define setup() %%setup %{?_setup_args} -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

Read about parametrized macros in rpm installed docs (used to be /usr/share/doc/rpm-X.Y/macros, perhaps still is). Basically a parameterized macro will parse all options/arguments to EOL into she'll-like transient macro names. -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

Finally -- overloading %setup like above is a hackers pathway away from reproducible builds into insanity. JMNSHO ... (aside) The real problem -- never well supported, but entirely achievable -- is How to build from a VCS checkout (not a tarball) with minimal hassle? This requires additional

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: macro for checking endianess (#365)

Note also that adding an additional "informative" rpm macro to distro configuration is utterly trivial (if that is all you wish) and documenting the usage in distro packaging policy building a usage case. Magically (and portably) detecting endianness within rpm build is trickier: consider

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: macro for checking endianess (#365)

Presumably you are talking about an rpm macro since there are already C macros in . I fail to see how knowing machine endianness in an rpm macro assists with packaging: patches could (and likely SHOULD) be written to include and test with a C macro rather than optionally applying a patch. If

Re: [Rpm-maint] [rpm-software-management/rpm] Fail to check signature (#270)

TL;DR The 2nd headerReload() appends RPMSIGTAG_PADDING into a contiguous PROT_READ block. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Fail to check signature (#270)

Several points: 1) Your check for repackaged packages is what is running afoul of (what is obscurely known as) a "dribble", a tag appended to an immutable region, which is commonly found in repackaged packages (with a doubly linked upgrade chain tag appended) and in rpmdb headers (signature

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)

The literal request to append %setup_args (or %patch_args, same deal) to %setup/%patch is utterly trivial configuration: overload the existing %setup or %patch macros-in-C with any macro definition you wish. Meanwhile, that isn't going to do anything very useful since neither %setup nor %patch

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

The right place to fix conflicting names/usages between C and Python is in rpm python's init.py. FWIW, each of those values is just a bit mask, you could easily create names in mock. As easily, you could stop disabling signature/digest checking. -- You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

The problem with probes (like your patch) is that RPM is attempting to run a dependency assertion checker whose values are known at the end of an installation, not at the beginning, by also checking added packages. Since a /sys path is dependent on both a kernel capability as well as the mount

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

You are asking about how file dependencies work? The requirement I suggested would be matched by an explicit Provides:, (not a path), in a kernel package that is capable of uefi? That "works" (in the sense that it is all that RPM4 has ever done, matching R <-> P assertions contained in

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

See the cpuinfo() (which parses /proc/cpuinfo) or the sysconf() (which can detect whether NPTL is used) namespaces as example probes in RPM5. There is also a class of probes implemented as RWX() letter combinations as a thin wrapper onto access(2) calls on a path that would work for

Re: [Rpm-maint] [rpm-software-management/rpm] Implement configurable, mandatory signature/digest verify level for rpm -K (ac280c4)

Congratulations on a nice job! I could quibble with details and approach, but replacing the insanity of "best effort" verification with a configurable policy driven mechanism is a HGE amount of work. Been there, done that ;-) -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

There is (perhaps) a way to use the context of the dependency assertion resolution to choose between two means of dependency resolution: 1) a namespace encapsulated virtual provide (think: Provides: system(EFI) in some package) 2) a Boolean valued dependency probe function (think: your

Re: [Rpm-maint] How to generate GNU make dependency file for a SPEC file automatically?

y to spew the Makefile dependencies. Disclaimer: I haven't looked at the code, nor am I Python programmer. I'm just trying to remove the need to unpack the *.rpm payload. hth 73 de Jeff > > > > 2018-03-27 3:31 GMT+02:00 Jeff Johnson <n3...@me.com>: >> >>

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

Sure it's easy to remove an underscore to adapt to picky pylint. Here are several reasons for not doing so: 1) this is ancient legacy code copied from yum, whose devels wished speed and considered header digest/signature checking slow. In fact, disabling file digests is far more expensive.

Re: [Rpm-maint] How to generate GNU make dependency file for a SPEC file automatically?

> On May 13, 2018, at 2:31 PM, Jeff Johnson <n3...@me.com> wrote: > > > >> On May 11, 2018, at 7:31 AM, Francesco <francesco.monto...@gmail.com> wrote: >> >> Hi Jeff, Hi all, >> I'm resuming this (old) topic in case somebody is interested, I cr

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

Then use the constant in rpm (w the leading underscore that means something different to Python than C) to create whatever name you wish in init.py. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Expose _RPMVSF_NOSIGNATURES and _RPMVSF_NODIGESTS (#440)

Again: you could easily stop disabling signature/digest checks in mock. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] Proposal for rpmbuild patch

> On May 17, 2018, at 1:38 PM, Francesco wrote: > > Hi all, > [I posted a similar proposal under the thread "How to generate GNU make > dependency file for a SPEC file automatically?" but I'm reposting here with a > better subject] > > Proposal: add a new

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

@svpv: good for ROSA, and conversations with me might be partly responsible for the choice. Using the same epoch when one value is missing has the distinct advantages (aka "epoch promotion") enumerated below: 1) entirely consistent behavior with what the Debian Borg enclave advocates 2) epoch

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

One last comment on missing values in EVR tuple S ... Whatever scheme is implemented for RPM comparison with missing values, the following pathological dependency with all values missing SHOULD behave naturally: Requires: foo >= :- -- You are receiving this because you are subscribed to

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

Extreme or not, RPM is expected to deal with missing values (not only optional/missing epoch) sanely and intuitively, you aren't the first to complain. Fix the issue and *SOLVE* the engineering problem(s) instead of 1) claiming that "epoch promotion" doesn't "work" with clear history to the

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

Good riddance: Ptooey! There is one last improvement that might be attempted. RPM invokes gpg to sign plaintext blobs from packaging. Because of the handoff to a gpg helper, it is possible for a signature to be undertaken on a digest (like MD2/RIPEMD etc) that the rpm internal gpg signature

[Rpm-maint] [rpm-software-management/rpm] RFE: use kernel/keyutils key rings as a backing store for rpm keyrings (#454)

One of the problems with having secrets like passwords/privkeys within application memory is the risk of loss through a segfault core dump or /dev/mem /proc snooping. Complete opaque isolation to prevent loss can be attempted with TPM and/or other attached hardware, or by handing off signing

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

And to partially answer why MD2/RIPEMD were implemented: MD2 as one of the first digests used is (or was) universally available in all backends (including gpg) RIPEMD has (or had) usage cases in *BSD systems, and in Europe, with OS/continental chauvinistic attachment to the algorithm. It was

[Rpm-maint] [rpm-software-management/rpm] RFE: permit HMAC-XXX for digest XXX (#455)

While we are on the topic of message digests ... Much development time in RPM is spent handling multiple digests as well as moving away from older digest algorithms like MD2/MD5/SHA1 towards longer (and slower) SHA2 algorithms. While the rate of forward progress is mostly determined by

[Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#456)

Another lurking/lingering RFE digest issue RPM traditionally used MD5 file digests, long since generalized to use SHA256 (or other) digest from rpmbuild macro configuration. Digest verification can also be enabled/disabled using %verify/%defverify. Adding a string->value table for

[Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#457)

Another lurking/lingering RFE digest issue RPM traditionally used MD5 file digests, long since generalized to use SHA256 (or other) digest from rpmbuild macro configuration. Digest verification can also be enabled/disabled using %verify/%defverify. Adding a string->value table for

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: permit HMAC-XXX for digest XXX (#455)

As always I can provide pointers to code, and can do an implementation if interested. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

Presumably the "basic parameters" validation you are referring to is makeSigTag() in sign/rpmgensig.c where the returned signature is parsed and values are sanity checked. That check will not prevent a signature using, say, MD2 from being added to a package. The hash (and signing) algorithms

Re: [Rpm-maint] [rpm-software-management/rpm] check that libcrypto supports MD2 (#453)

Removing MD2 everywhere -- BeeCrypt, NSS, and OpenSSL -- in wrappers should be done for consistency: but that's perhaps out-of-scope for this OpenSSL specific pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] check that libcrypto supports MD2 (#453)

OpenSSL requires MD2 because BeeCrypt in RPM unconditionally supplied MD2, feature parity. BeeCrypt implemented MD2 because -- at the time -- MD2 was still used but already known broken, legacy (and standard) compatibility. RPM implemented MD2 because it was there, feature completeness. The

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

You are 15+ years too late to discussions about EVR comparison. Panu wasn't even much of a participant: I was. I summarized the issue above. A choice was necessary between 2 possible schemes for supplying a default value for a missing epoch. I made that choice when I implemented the code.

Re: [Rpm-maint] [rpm-software-management/rpm] check that libcrypto supports MD2 (#453)

What is the RPM need for checking if OpenSSL supports MD2? MD2 was broken a long time ago, and has few redeeming values as a cryptographic hash: e.g. MD2 is pig slow. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

Dependencies are compared sequentially across the set {E,V,R} and 2 .GT. 0 That is what is implemented, and the RPM comparison is working exactly as expected. That isn't a bug. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#457)

Closed #457. -- 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/457#event-1702456413___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for librpm (#429)

See #456 which might have minor ramifications for your project. Meanwhile you should attempt to handle RPMTAG_FILEDIGESTS general by looking at RPMTAG_FILEDIGESTALGO{,S} to determine what digest was used, and dispatching to the appropriate routine within Python code. In practice, SHA256 is

[Rpm-maint] [rpm-software-management/rpm] RFE: actually implement --nomanifest* while installing packages. (#458)

This is an extension of #437 ... I apologize for not being sufficiently specific before. There are 2 code paths that will read manifest files recursively. One (newer) code path uses lib/rpmgi.c and honors a query/verify disabler. The other (older) code path is through lib/rpminstall.c needs to

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

Ornamenting epoch values with explicit magic like '*' is irrelevant to this discussion about how a missing epoch in tar = 1.28 should compare to an explicit epoch in tar = 2:1.26. For starters, epoch is a digit string followed by a ':', and '*' is a non-numeric character that pretends at DWIM

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

@rpm-maint: the sole reason for the existence of epoch (and its higher precedence in the comparison order of {E,V,R}) is to preserve upgradeability when either upstream has made an inconvenient choice of version, or the packager/distro has decided to revert to an older version. This has

Re: [Rpm-maint] [rpm-software-management/rpm] Rip out partial support for unused MD2 and RIPEMD160 digests (ff4b911)

Can you point me at validating basic parameters please? If you were actually explicitly testing for permitted/implemented digest algorithms, then your patch would include the removal of MD2/RIPEMD160 there as well. I also looked at the code and saw nothing that tests for "supported" (by rpm)

Re: [Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

It is possible to construct failing counter examples for either obvious choice of missing epoch. Your "strong recollection" cannot be analyzed further. Truly I made the change at the time to simplify what I had to type multiple times a day doing support: Missing epoch is identical to 0

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement per-file digests (#457)

Apologies for the fat finger duplicate. -- 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/457#issuecomment-400458728___

Re: [Rpm-maint] [rpm-software-management/rpm] RPM -V lacks support for place holder packages or wildcards (#451)

The tag=pattern syntax is undocumented for a reason: the implementation as a filter through a match iterator is clunky and low performing. Lots of headers are loaded, tags retrieved, pattern applied, and most headers are discarded. The better implementation is to apply patterns directly to keys

[Rpm-maint] [rpm-software-management/rpm] RFE: add a way to access the installed NVRA and install time without accessing an rpmdb (#459)

There are many programs/applications that wish simple information about installed software, e.g. the HOST-MIB in net-snmp, or security checkers cross referencing to CVEs, where linking to rpm libraries and Berkeley DB are mind-numbing overkill. One simple solution to supplying essentially "rpm

[Rpm-maint] [rpm-software-management/rpm] RFE: differentiate file and directory dependencies using a trailing '/' (#439)

-- 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/439___ Rpm-maint mailing list Rpm-maint@lists.rpm.org

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Add --nomanifests disabler (#437)

Good. Meanwhile I suggest you look at the refactored lib/rpminstall.c tryReadManifest(). There is no logic there preventing the call. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: differentiate file and directory dependencies using a trailing '/' (#439)

RPM has only path and directory dependencies, largely because the path canonicalization in rpmCleanPath() always strips a trailing '/' character. Luckily, the (arguably hacky) fix is not very complicated. 1) always over allocate paths by 1 byte to accomodate a trailing '/' (if necessary. 2)

Re: [Rpm-maint] [rpm-software-management/rpm] Provide a way to opt out from automagic Python bytecompilation (#434)

@Conan-Kudo: And "Who maintains RPM?" Expecting C programmers to maintain a shell script to make Python packaging easy and uniform in several distro's is an exercise in politics, not engineering. Handing the script to either Python programmers or distro QA engineers is far likelier to get

Re: [Rpm-maint] [rpm-software-management/rpm] Proposal for default init.lua (#321)

@jasontibbitts: apologies if you have interpreted "serious" as a criticism of your personal efforts That wan not my intent. Meanwhile, your suggested patch -- the only positive suggestion of what you wish -- is little more than force loading a number of modules based on globbed names,

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: give some freshness to brp scripts (#308)

@Conan-Kudo There is nothing stopping 3: add script to SourceN: and invoke as %SOURCEn 4) change the macros that specify what scripts to run (but that is what is being claimed "clunky" when in fact what is desired of rpm is lazy DWIM) -- You are receiving this because you are subscribed to

Re: [Rpm-maint] [rpm-software-management/rpm] Fix sigheader generation for big archives (#379)

headerSizeof() is expensive: you are better off doing more careful arithmetic. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: give some freshness to brp scripts (#308)

@Conan-Kudo: Providing an additional directory where brp scripts might be found doesn't address conditionalizing which brp scripts are run dynamically. Its rather easy to add Yet Another Directory of brp scripts (augmenting PATH), but its rather harder to determine which scripts to run. There

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: '!=' vercmp operator (#376)

FWIW, there are no negated dependencies at all in RPM4. E.g. Requires: !foo == bar being rendered as Conflicts: foo == bar (with similar for other operators). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: '!=' vercmp operator (#376)

Use Conflicts: with ==. -- 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/376#issuecomment-355361870___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

There's several ways to solve a renaming: pick you poison wrto your packaging policy. Add a Provides: for the F26 name to the F27 package (or vide versa). You can also add a file dependency, or add a Newer! Better! Besetest! name to both packages/modules. -- You are receiving this because

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

@AdamWill so there is the problem of what I would call dueling package managers, and it's unclear (particularly because of ever changing incompatibilities in python) what solution(s) should be pursued by rpm. By all means, use pypi (or apt or ...) if that is what one wishes. Blaming rpm for

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

Truly rpm-python should be split off to its own project in the eco system, published to pypi, and whatever else is desired, rather than blaming rpm developers for Newer! Better! Bestest! Python (and depsolvers) changes. That was the original plan back in 2006 or so, just no round 'tuits. RPM

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

Correction: PEP 345 appears to have a Provides-Dist: tag to handle virtual packages bundled together. Using existing functionality wisely (assuming implemented) would seem to be the best way forward. Providing two egg-info files to handle the change seems rather hacks. -- You are receiving

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

If the name isn't used (what I called "informative"), then there should be no difference in loading behavior (unless there is some silly (imho) check on metadata consistency, in which case 2 egg-info files is the only way to deal with what has already been released). The actual failure mode

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

The key issue here is "What is the failure mode?". If setup tools is constructing module paths from egg-info Name: directives (which is rather deficient) then there is no solution available (AFAICT) except to feed a Name: directive in some alternative egg-info file. If Name: is purely

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

FWIW, rpm permits virtual package names, where a Provides: is treated identically to a package NEVR. This was deliberately (and incompletely) ripped out of Obsoletes: in Fedora -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on

Re: [Rpm-maint] [rpm-software-management/rpm] Python module's name changed unnecessarily, making it impossible to express dependencies on it (#373)

@AdamWill I fail to see how 2 names is better than one, particularly since there seems to be no already implemented mechanism within egg-info to deal with multiple names (and the claim afaict is that the functionality is deemed unnecessary). -- You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Track and log failures when loading macro files (f7aff11)

For extra credit: The line number (and the current type of definition like RMIL_MACROFILES) might reasonably be attached to each macro definition, perhaps by masking to avoid changing rpmDefine() in the API. Otherwise add additional int arguments to rpmDefine() -- You are receiving this

Re: [Rpm-maint] [rpm-software-management/rpm] Disable redefinition or undefinition of a built-in macro (9343ecd)

If you are going to add a hard wired validation table for builtin macros, then you might as well use the same table for dispatching during macro expansion. Possibly better would be to add a builtin flag to defined macros and treat as all other macros are treated, thereby permitting builtin

Re: [Rpm-maint] [rpm-software-management/rpm] Track and log failures when loading macro files (f7aff11)

Abusing the negative level macro definition as an index into files from which definitions were read, with an associated file name table, as well as the modest change to display the file name(s) where macros are defined, is likely more useful than detecting errors while loading/defining a macro.

Re: [Rpm-maint] [rpm-software-management/rpm] Checks for Obsoletes (#385)

Nagware to effect policy is usually just an annoyance. There are arguable cases (in renaming) where versionless or greater than are perfectly sensible. Also: Obsoletes: (after installation) are essentially Conflicts: and should be treated similarly if you insist on adding nagware. -- You are

Re: [Rpm-maint] [rpm-software-management/rpm] Add an API for libsolv, libdnf, et al to use to check if rpmdb has changed and trivially get path to rpmdb (#388)

Presumably the desired rpm API is some Boolean valued function that returns the value "changed" with minimal hassle. What isn't clear is what changed means: time stamp since ... ? package count has changed since ... ? digest on files composing an rpmdb? There is certainly existing prior art in

Re: [Rpm-maint] [rpm-software-management/rpm] Add an API for libsolv, libdnf, et al to use to check if rpmdb has changed and trivially get path to rpmdb (#388)

Presumably the desired rpm API is some Boolean valued function that returns the value "changed" with minimal hassle. What isn't clear is what changed means: time stamp since ... ? package count has changed since ... ? digest on files composing an rpmdb? There is certainly existing prior art in

Re: [Rpm-maint] [rpm-software-management/rpm] Moving from rpm-3.0.X to latest version 4.13.0.2 (#384)

Yes, db1 is no longer supported in rpm (for like the last 15y). Meanwhile -- if you _REALLY_ insist on rpm database compatibility -- you could possibly do the conversion by installing several (perhaps 3, possibly 2) versions of rpm and doing rpm --rebuilddb. You would be in for some serious

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement wrapper for posix.fork()+posix.exec() (#389)

@ignatenkobrain: Um not, implements, but embeds. lposix.c was a concatenation of the lua posix module available at the time. Note the "posix." name spacing. Perhaps it's time to upgrade the lua posix module and eliminate bloat? -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

If you are going to sign "mutable" %config files, you might as well sign %ghost files as well (by signing the hash of the null string). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

One might well ask: Why sign any "mutable" file? The (rather inchoate) answer supplied in the original RFE for signing %config files is (iiuc) was 1) so that IMA policy can be written against %config files and 2) so that %config files in a package will have an ima signature in an xattr. The

Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)

@pmatilai: yup, DB_RECOVER requires configuring Berkeley DB when opening correctly in order to use. Hint: execing dbXY_recover on an idle database (already protected by an exclusive write lock) fixes stale locks. Performing that operation when needed, not every 15 minutes with a Facebook fork

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

Yes --replacefiles just sets a transaction flag bit (equivalent to ".*" but there are no patterns involved). By "disable", I mean build all packages without %config or %ghost, avoiding the need for special handling, and simplifying ima appraisals on embedded devices (the example given in

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

@nim-nim: "... define the best dynamic BR strategy over time" is *EXACTLY* the chicken-egg problem mentioned by @ffesti. Think a bit ... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)

@jayzmh: the issue with dcrpm is the costly detection and possibly imperfect analysis of "bad actors" not how often db_recover is run. dcrpm is treating a symptom rather than solving the root cause of whatever problem exists. -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)

Um, *this* issue is about RPM behavior on OS X and a sandbox policy prohibiting writes. Open an issue with details with details about your Facebook problems if you wish. The output of db_stat showing the state of locks is usually the starting point to identifying the root cause. -- You are

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

FYI: MaximumRPM was written in 1997 and does not begin to define the necessary semantics to implement signatures on mutable files in a useful way. There have been several changes in both %config/%ghost handling since 1997. Q: What use is it to IMA policies to have a pre-packaged signature on a

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

There is also the run-time variant of the previous build-time configuration: use a macro to define a mask that is applied to rpmfiFFlags() return value before testing for RPMFILE_CONFIG. A global per-system (or per-transaction) AND mask (defaulted to 0x) could be generally useful in

Re: [Rpm-maint] [rpm-software-management/rpm] Also apply signatures to config files (#374)

There is a very simple macro %define %config %{nil} which -- when added to rpmbuild configuration -- achieves an ima signature on every file without any fuss whatsoever. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Request to apply IMA signatures to files even if deemed a configuration file (#364)

I have read #364, the basis of which is a belief that security policies like ima should be set by the end user, not the packager. An imperfect implementation in rpm to generate ima signatures that are invalid when %config files are altered seems a pointless mechanism to generate useless false

Re: [Rpm-maint] [rpm-software-management/rpm] Request to apply IMA signatures to files even if deemed a configuration file (#364)

I have read #364, the basis of which is a belief that security policies like ima should be set by the end user, not the packager. An imperfect implementation in rpm to generate ima signatures that are invalid when %config files are altered seems a pointless mechanism to generate useless false

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement wrapper for posix.fork()+posix.exec() (#389)

These are RFE's for the lua posix module (and should be implemented/patched there), not for RPM. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

If -- as this RFE seems to assume -- you are going to limit the implementation to "... (Rust, Python, golang) ..." that have alternative non-specfile means to specify BuildRequires, then all known rpm build systems will require a change to augment the installed files with newly discovered

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

Contrarian examples are trivial to devise. Consider an autoconf based generated file that builds if (and only if) certain files are detected. None of those BuildRequires can be automated and generated during a spec file parse with a pipe/file redirection. The only solution (I can see) is an

Re: [Rpm-maint] [rpm-software-management/rpm] Rpm query causes corruption in the file-backed mmaped bdb regions (#232)

Guesses are worthless, particularly when you haven't the time to identify your problem. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement fast mode for getting EVR (#392)

Then you are stuck: it's your workload, not the rpmspec parser implementation, that is the root cause. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RPM_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

(from memory) I think I fixed this problem 4-5 years ago in RPM5 (like rpm-5.4.15? I forget). The MD5 tag length (and RPM_BIN_TYPE in general) includes padding (if present) to the next tag. The bug only shows up if the next tag needs to be aligned. The real fix wasn't hard, but was rather

Re: [Rpm-maint] [rpm-software-management/rpm] RPM_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

Good: identical problem accessing RPM_BIN_TYPE "drips" (i.e. signature tags appended to an immutable region). The problem is in the API access, not in the format, so no painful hacky retrofit will be needed. It sure would be nice to see the 1-line fix pushed back through "supported" platforms

Re: [Rpm-maint] [rpm-software-management/rpm] rpmio.c: In Fread(buf, size, nmemb, FD), require size be 1 (#400)

FWIW, you idiomatic code *never* worked with unmatched RPM4 sources including rpm-4.0 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] rpmio.c: In Fread(buf, size, nmemb, FD), require size be 1 (#400)

Yes, the "clone" of fread/write is imperfect and always returns the no. of bytes rather than nitems. The flaw certainly hasn't stopped Fread/Fwrite from being both used and useful everywhere in rpm this century. There's more needed than just your patch. FYI: RPM5 rpmio returns nitems just as

Re: [Rpm-maint] [rpm-software-management/rpm] Should python(abi) be provided by the interpreter or something else? (#395)

The python(abi) requirement was originally invented to associate a *.py script in a package with an interpreter package. Most of the Requires: are automatically generated from *.py files (which ultimately determines how the Provides: should be added). Detailed dependency semantics involving

Re: [Rpm-maint] [rpm-software-management/rpm] lua: add rpm.execute() (#390)

The real flaw with looping over close(fdno) before exec in rpm is that it masks the root cause of the problem: applications that are not setting FD_CLOEXEC. The loop also prevents an application from intentionally passing an open fdno to a child of rpm (if that is/was intended). I'd suggest

Re: [Rpm-maint] [rpm-software-management/rpm] RPM_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

(I'm sure you know this) NEVRA isn't unique even if commonly used, and pkgid is the only candidate for a unique id available for almost all *.rpm packages ever built without painful retrofits. The SHA1 hdrid is likelier to be noticed sooner because it maps directly into "what git does"' but a

Re: [Rpm-maint] [rpm-software-management/rpm] RPM_BIN_TYPE get wrong length if HEADERIMPORT_FAST is used (#398)

@pmatilai: au contraire, the MD5 of the original package is the only "universal" (in the sense of being present all the way back to RPM2) precomputed identifier for a *.rpm package if/when converted to a UUIDv3 (see the query format issue) to be (eventually) used as a database key rather than

<    1   2   3   4   5   6   7   >