Re: [Rpm-maint] [rpm-software-management/rpm] rpm -q --xml output still broken in git master (#188)
Closed #188. -- 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/188#event-1228824736___ 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 -q --xml output still broken in git master (#188)
Reverted the two problematic changes (commit 7eb620f595486309670797a2436559598ff1f8f0) at least for now, and made it instead do what documentation says: error out consistently on mismatched array sizes (commit 6adef6a3c729fc21ed2254bf2c557c2540995bf1). Plus added a few more testcases (commit 1517c1a721c4ba0706c8f98f41d7f08728cc5165) so next time we change something we're less likely to break stuff. -- 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/188#issuecomment-326186211___ 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)
@ignatenkobrain: tex (with many packages all with few files) isn't the best benchmark to illustrate a parallel packaging speedup. There are a finite number of threads in the thread pool (which you seem not to have reported or controlled for, sigh). Try a benchmark with a few packages with lots of files, perhaps kernel or gcc, where the no. of packages is about the same as the no. of threads in the pool. -- 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-326036010___ 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)
@kanavin, even 8 minutes speedup is good ;) -- 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-325989203___ 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)
@ignatenkobrain The reason we see a lot of speed up in Yocto with this patchset is that building the sources happens outside of rpm, and we only use rpm to do packaging of binaries. If the bulk of the above time is spend building texlive from source then of course the final difference won't be as much. Can you investigate a little bit where the time goes? -- 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-325977144___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
