Of course everybody is reading the FHS selectively, isn't that what standards
are for...
Anyway, I'm not breaking 20+ years of compatibility (again, the /usr/lib/rpm
path is hardcoded in LOTS of packages and other software out there) just
because. I've expressed what would be acceptable to rpm,
Closed #298.
--
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/298#event-1209769103___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
This seems like a highly Fedora specific thing to me, and as such it belong to
Fedora alone.
If other distros start following suite then perhaps we can reconsider.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gith
Closed #302.
--
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/302#event-1209779625___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Thanks for clarification.
--
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/302#issuecomment-323019966___
Rpm-maint mailing list
R
@n3npq : well this is a pleasant surprise. Thank you!
@Conan-Kudo : testing for Packages.mdb existence doesn't make LMDB create it.
AFAICS the "data.mdb" name is hardwired in LMDB unless MDB_NOSUBDIR is used,
and using that would introduce other unnecessary complications. I can fix that
when co
Closed #128 via ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72.
--
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/128#event-1209931565___
Rpm-maint mailing
Closed #281 via ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72.
--
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/281#event-1209931563_
Closed #291.
--
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/291#event-1209933863___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Merged manually as of commit ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72
Again, thank you @n3npq for the backend and @Conan-Kudo for the final tweaks!
--
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-softw
Merged as of commit ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72. Thank you!
--
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/281#issuecomment-323041479
@pmatilai Thank you for reviewing it!
--
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/291#issuecomment-323041501___
Rpm-maint mai
>From @n3npq:
> UUID's will be the starting point for a RPM+LMDB implementation used as
> header retrieval keys.
It didn't seem like you used this with the LMDB implementation
(ed9de1992f5e1c23e8d8dbd61325a1e0070f2c72), though you mention it as a starting
point. I'm guessing you're not currentl
Yes this will force changes to some existing macros, that is unavoidable.
There are basically two ways to deal with it, which:
a) escape macros in the arguments to prevent expansion, eg %%{nil}
b) adjust the parametrized macro itself, eg in some situations it would be more
natural to test for the
This PR includes several factors. Sorry for that.
What I want to know is
1. Do we like starting style check?
1.1. Use `flake8`?
2. Do we like starting a unit test by `pytest`?
3. Do we use `tox`? (`tox` is a little bit magic.)
--
You are receiving this because you are subscribed to this thre
Ok will try. I'm wonderng how my hackich sending of parameter's parameter
(%%1) will work Running test build with
https://src.fedoraproject.org/rpms/java-9-openjdk/c/6dd07923a5203651059e28f4c1422a2d862e2d84?branch=f27
now. TY!
--
You are receiving this because you are subscribed to this
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/304
-- Commit Summary --
* add support for premacros.d, complimenting --predefine
-- File Changes --
M lib/rpmrc.c (17)
-- Patch Links --
https://github.com/rpm-softwa
@proyvind pushed 227 commits.
6b6b507 Drop dead-on-arrival untrustedkeys formatting from signature checking
886c417 Add a test for non-verbose signature check output
7de6172 Drop missing key formatting from non-verbose signature checking output
7488d88 Drop the ambiguous and bogus RSA/DSA algo
rebased..
--
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/190#issuecomment-323117737___
Rpm-maint mailing list
Rpm-maint@lists.rp
Pre-macros (and --predefine) aren't the right implementations: either an RPM
invocation can read its own configuration or it can't.
Playing semantic games with goose-loosen CLI options adds complexity for no
gain: all that is happening under the hood is that some macros are read before
others.
Code duplication (and refactoring) are the least of the problems with the
current RPM backend.
There is no concept of a "transaction" or "durability" in the current RPM
backend.
And the existing INIT_CDB Berkeley DB model implemented has been tortured
beyond belief or reason.
Anything that LM
Thank you for that. But it seems that the CI test is not run for this PR..
--
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/190#issuecomment-323131071___
FWIW, "data.mdb" can be renamed to "Packages.mdb" in LMDB
by adding a flag and passing the file path, not the directory path, when
opening.
Not worth the effort (and adds confusion: "Packages" is the name of a
database/table within "data.mdb" not the name of the file).
Note that Berkeley DB al
Causing a full stop failure during expansion raises expectations to provide
better RPM error messages, or behave more gracefully.
The expectations often cannot be met because macro expansion is context free
(by design).
Debugging a macro expansion that is exiting is often harder than printing
Changing indices to be octets (rather than integers) is a prerequisite to using
UUID's as a join key.
There are many problems (endianness, exposure of hdrNum/tagNum in the RPM API)
that need to be solved to use a UUID as an octet string for LMDB (and for BDB).
See other issues for work-in-progr
Meanwhile this patch adds a --queryformat modifier to generate UUID's from tag
values, which is an entirely orthogonal and mostly non-intrusive usage case
than converting hdrNum/tagNum to an octet string.
--
You are receiving this because you are subscribed to this thread.
Reply to this email d
I have to say that I agree with @n3npq on this. I don't even use `--predefine`
as it is, because it's a bit strange.
--
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/304#is
On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
> On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
> > On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote:
> >> The subtle test is too subtle for its own good, this patch breaks
> >> thirty six testcases on 32bit architectu
On 08/17/2017 11:28 PM, Dmitry V. Levin wrote:
On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen wrote:
The subtle test is too subtle for its own good, this patch breaks
thir
29 matches
Mail list logo