(Except I think that code is still not used by dnf because it dates to the
PackageKit C vs yum Python days?)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Also worth noting https://github.com/rpm-software-management/libdnf/issues/43
(libdnf auto-injects `/etc/pki/rpm-gpg`)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ideally we don't want to have to carry a revert to gain the functionality back
for the Yocto Project. Is there something else that can be done here other
than to remove the code, such as an option with with in the configuration to
allow it to continue to function as it does today?
--
You
Conan-Kudo requested changes on this pull request.
> @@ -68,12 +68,6 @@ static const int typeSizes[16] = {
0
};
-enum headerSorted_e {
-HEADERSORT_NONE= 0,/* Not sorted */
-HEADERSORT_OFFSET = 1,/* Sorted by offset (on-disk format) */
-HEADERSORT_INDEX = 2,
Yes this is actively used by the Yocto Project. It allows us to have a single
location in the system that contains all of the software keys, and can be
updated dynamically by authorized systems/components. Having to load keys
(manually) into the rpm database, makes it very difficult to
This looks very cool! I've not had a chance to look at it in-depth, but the
first pass looks pretty good!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(cc: @mhatle @kanavin)
--
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/857#issuecomment-535604121___
Rpm-maint mailing list
Closed #866.
--
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/866#event-2665980647___
Rpm-maint mailing list
Don't pull this yet; once I added a test case I realized there's still
something wrong with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@vathpela pushed 1 commit.
99f643c6b8d17ebe99d397f4fa91d2955deecc64 Make "%patchlist -f patches" work.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
headerExport() is the only thing that needs offset sorting, theres no
point messing up with the header itself for this when we can just sort a copy
instead. No visible functional changes, but makes headerExport() a read-only
operation to the header, as it should be.
You can view, comment on, or
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/869
-- Commit Summary --
* Add the marker to the appropriate expression error messages
-- File Changes --
M rpmio/expression.c (15)
M tests/rpmmacro.at (2)
--
After more than two years in development and half a year in testing,
RPM 4.15.0 is finally here!
Highlights include:
- Faster builds on SMP via parallelization
- Dynamic build dependencies
- Support for %elif, %elifos and %elifarch statements in spec
- Caret version operator (the opposite of
Merged #867 into rpm-4.15.x.
--
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/867#event-2664615553___
Rpm-maint mailing list
I don't think deltarpm would be able to make use of this global source file
hash.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this is a compose problem, not rpm problem: it'd be wrong for rpm to
encode some arch-specific knowledge into that noarch package, when that
arch-limitation could go away at any time (by that extra package becoming
available on that arch). Another line of thought is what dnf did
For the record, there have been some reports of builds hanging during
classification on systems with large number of CPUs using file 5.36 which where
fixed by updating to 5.37. Another workaround is to set %_smp_build_nthreads to
a smaller number, ultimately 1 to make the whole classification
Merged #868 into master.
--
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/868#event-2664406306___
Rpm-maint mailing list
Merged #862 into master.
--
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/862#event-2664403059___
Rpm-maint mailing list
pmatilai approved this pull request.
Thanks. The danger with including the command at all is that people will think
the command failed, but considering I don't think anybody has ever *seen* this
fail in the first place, maybe we can live with the "danger" :D
--
You are receiving this
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/868
-- Commit Summary --
* Update CREDITS for last years new contributors
-- File Changes --
M CREDITS (16)
-- Patch Links --
Actually scratch that, this needs a CREDITS update...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Commit message is corrected according to @pmatilai's comment.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 1 commit.
75ec68392ece1006f1543bd556f64199257b6b32 Add an error message when rpm fails
to open a pipe for shell expansion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Pull updated translations from Zanata, bump version to final.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/867
-- Commit Summary --
* Preparing for rpm 4.15.0 final
-- File Changes --
M configure.ac (2)
M
Right, I noticed but forgot to mention setting mb->error becoming redundant,
thanks.
As for the error message, if you grep around a bit you'll notice that the
common pattern for these things is:
::
...where is a file name or similar, and in this case it'd be the macro,
and is the
@pavlinamv pushed 1 commit.
e2677384cde95e69e14979ccac8936874c376652 Add an error message when rpm fails
to open a pipe for shell expansion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
On yet another related note, there a case or two for having a global hash for
the individual files, with no payload induced foobar in it. One case is having
a true "source id" calculated from all the files in an src.rpm, that would be
also planted on any binaries built from these sources. This
Removed unnecessary "mb->error = 1;" line.
--
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/862#issuecomment-535370536___
29 matches
Mail list logo
