Re: [Rpm-maint] [rpm-software-management/rpm] RFC: Limit build parallelism by available memory too, add tunables (#804) (#821)
> Yeah, known. Missing/wrong arguments to built-in macros are wildly > inconsistent in how they behave, some emit errors, some just fail silently > etc. Evidently better way is to emit an error. -- 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/821#issuecomment-526562551___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support libgrypt as crypto library (#826)
Seems we should get rid of AM_PATH_LIBGCRYPT ;( -- 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/826#issuecomment-526559914___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Correct and update Query formats documentation (#827)
- in a majority of examples in manual the text after the --queryformat
argument is in double quotes - thus it does not look good to wrote
that A query format is passed to RPM after the --queryformat
argument, and normally should be enclosed in single quotes.
- in case of:
rpm -qa -i --queryformat %{NAME} %{SIZE}\n
-i is not ignored, so this is omitted in the text.
- language correction
- added name of file with the list of all formatting tags,
- package dev is not reachable now, so replaced by nss,
all tags are now written in capital letters,
%{FILEVERIFYFLAGS:hex} looks better then %{FILEVERIFYFLAGS}
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/827
-- Commit Summary --
* Correct and update Query formats documentation
-- File Changes --
M doc/manual/queryformat (23)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/827.patch
https://github.com/rpm-software-management/rpm/pull/827.diff
--
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/827
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: Limit build parallelism by available memory too, add tunables (#804) (#821)
> * The expansion of macro %{getmem:virt}" finishes with an error. It is
> because getmem returns 0. This is caused by the fact that function
> getmem_virt returns SIZE_MAX. After dividing by 1024^2 it is still to high to
> fit into return_type of getmem (unsigned int).
Right. I probably only tested this in 32bit context where its more relevant.
There might be more similar issues lurking (it's only an RFC for a reason)
>
> * If there is a wrong parameter after '%{getmem:' , then no warning or
> error is emitted
Yeah, known. Missing/wrong arguments to built-in macros are wildly inconsistent
in how they behave, some emit errors, some just fail silently etc.
> * Why you use a new type of built-in macro synatx %{getmem:} instead of
> something close to the existing built-in macros like %getmem_avail?
It's not a new syntax, it's a built-in with an argument like several others. I
don't see a point of adding multiple macros that all return different aspects
of the same thing, that's what a parameter is for. Purely a matter of style of
course.
--
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/821#issuecomment-526558715___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: Limit build parallelism by available memory too, add tunables (#804) (#821)
I tested this PR on my laptop.
- The expansion of macro %{getmem:virt}" finishes with an error. It is because
getmem returns 0. This is caused by the fact that function getmem_virt returns
SIZE_MAX. After dividing by 1024^2 it is still to high to fit into return_type
of getmem (unsigned int).
- If there is a wrong parameter after '%{getmem:' , then no warning or error is
emitted
- Why you use a new type of built-in macro synatx %{getmem:} instead of
something close to the existing built-in macros like %getmem_avail?
--
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/821#issuecomment-526549042___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Support libgrypt as crypto library (#826)
Choice is good ;) You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/826 -- Commit Summary -- * Support libgrypt as crypto library -- File Changes -- M configure.ac (16) M rpmio/Makefile.am (6) A rpmio/digest_libgcrypt.c (404) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/826.patch https://github.com/rpm-software-management/rpm/pull/826.diff -- 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/826 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
Yeah, a behavior change this big would've needed to be in the alpha already, because it's bound to break a bunch of creative macros here and there. -- 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/313#issuecomment-526523412___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use an erase element to delete packages with same NEVRA (#770)
Yeah, traditionally --install is not allowed to erase anything, which (to me at least) makes sense most of the time. But like you note, with --replacepkgs the old header will be removed no matter what, so an erase element does seem a sane thing to do. It's a behavior change that might cause some surprises in tooling that does not expect the erasure element though. -- 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/770#issuecomment-526522437___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
I guess fixing this is too late for 4.15.0? -- 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/313#issuecomment-526517883___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use an erase element to delete packages with same NEVRA (#770)
It's trivial to change the code to also add an erase element for --install if the NEVRA is the same. (It's actually also what libsolv expects). I didn't do it because I read in some old thread that you don't like erases with 'rpm --install'. (The old header will get replaced anyway, so an erase would IMHO be the sane thing.) -- 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/770#issuecomment-526514965___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use an erase element to delete packages with same NEVRA (#770)
Just for the record, this also fixes the case where a package with self-conflict fails with -Uvh --replacepkgs style reinstall (https://bugzilla.redhat.com/show_bug.cgi?id=1693212) As expected it doesn't deal with -ivh --replacepkgs in the same case (of self-conflicts), which is a rather annoying corner-case. -- 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/770#issuecomment-526497030___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
