Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic Build Dependencies (#593)
RPM does not consider provides of SRPM for dependency check. -- 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/593#issuecomment-490965693___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic Build Dependencies (#593)
OK, here is the rebased and squashed patch set. Let's hope not too many things broke during this process... I noticed that we are using the same rpmlib name for indicating that the SRPM has an %generate_buildrequires script (and though needs support for this feature) and that it already contains the results. I've not yet tested this. But I worry about the srpm using this asa self provide - which is probably bad. I'll add some test cases tomorrow. -- 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/593#issuecomment-490963460___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for %patchlist and %sourcelist spec sections (#679)
> Can something similar be used for directories? > E.g. > %patchdir path/mydir No. Package contents need to be explicit to avoid random junk from entering packages. -- 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/679#issuecomment-490911901___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Dependency generator optimization and cleanup (#698)
This basically turns the dependency generation order inside out: previously we ran through the file list one by one, running dependency generators for all types the file was found to match, ie in file:attr:deptype order. Now we do the exact opposite: deptype:attr:file, which allows us to optimize to only expand all those macros once per deptype / attr instead of once per file. Sadly all that is lost in the noise of actually forking + executing those dependency generators, but this is basically a prerequisite for the far more important optimizations, such as (some day) teaching the generators to work on multiple files at once and ultimately, multiple generators in parallel. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/698 -- Commit Summary -- * Refactor dependency generation logic from code to data structure * Reorder dependency generation to run per type, not by file * Optimize exclude handling in dependency generation * Reorder dependency generator to run by type, attr, file * Expand all relevant macros outside the per-file generator busyloop -- File Changes -- M build/rpmfc.c (185) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/698.patch https://github.com/rpm-software-management/rpm/pull/698.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/698 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix memory reading in the expansion of an unfinished macro "{%!" (#694)
Merged #694 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/694#event-2329951760___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix memory reading in the expansion of an unfinished macro "{%!" (#694)
pmatilai approved this pull request. Much better, thanks. -- 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/694#pullrequestreview-235537366___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix memory reading in the expansion of an unfinished macro "{%!" (#694)
The code seems fine, and :+1: for taking the opportunity to refactor. The commit message just needs a bit of love. This is a software, not hardware issue. You're fixing a buffer over-read, or invalid memory access, not memory reading :slightly_smiling_face: (commit 54f24ec summary is equally bad) The word is "refactor", not reflector. And "interrogation point", not mark, but more widely known as a "question mark". And the reproducer is always good to state explicitly where possible, plus the other conditions. Referring to a similar commit doesn't really tell me whether this was also found by memory sanitizer or if this is something that occurs in the wild or... -- 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/694#issuecomment-490778061___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Run binary package generation and file classification in parallel threads (#695)
I just wonder, how this influences the console output. Will it be still always readable or will there happen some output race conditions and it won't be readable anymore? -- 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/695#issuecomment-490771644___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Run binary package generation via thread pools (#226)
Yes, as already mentioned in an earlier comment to this PR: https://github.com/rpm-software-management/rpm/pull/226#issuecomment-425422760 -- 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/226#issuecomment-490763686___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
