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
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
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:
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
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
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
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
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:
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
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.
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
@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
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 --
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
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
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
>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
@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
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:
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:
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
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:
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
@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
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
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:
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
27 matches
Mail list logo
