Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

2017-09-06 Thread Panu Matilainen
Defaulting to off would be as good as not existing. I already reverted it from 4.14 as it needs more time to bake, which is what git master is for. Not reverting ATM. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

2017-09-06 Thread Panu Matilainen
Closed #318. -- 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/318#event-1238168421___ Rpm-maint mailing list Rpm-maint@lists.rpm.o

Re: [Rpm-maint] [rpm-software-management/rpm] add support for premacros.d, complementing --predefine (#304)

2017-09-06 Thread Jeff Johnson
There's surely prettier syntax that can be achieved, or alternative syntaxes similar to what make does with conditional sections. E.g. `%{!?_arch_x86_64:#}%foo bar` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: htt

Re: [Rpm-maint] [rpm-software-management/rpm] add support for premacros.d, complementing --predefine (#304)

2017-09-06 Thread Jeff Johnson
There's another approach to conditionalize macro definitions from configuration by permitting existence tests in the first field. Most of the usage cases that have been reported to me are based on arch/os/platform, and the selection is being done by putting (some value) of arch in path to selec

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Colin Walters
https://github.com/rpm-software-management/rpm/pull/318 -- 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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#commitcomment-24120847

[Rpm-maint] [rpm-software-management/rpm] Revert "Sync disks at the end of transactions (RhBug:1461765)" (#318)

2017-09-06 Thread Colin Walters
This reverts commit b7a869f0f322cbe428e78150f2c175abea4c8c4b. This would need to be at a minimum configurable, and default to off for compatibility with software like rpm-ostree that is already taking care of all of this. You can view, comment on, or merge this pull request online at: https://g

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Colin Walters
BTW, see also https://github.com/ostreedev/ostree/pull/1049 -- 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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#commitcomment-24120807

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Colin Walters
rpm-ostree also has its own `syncfs()` calls and we definitely don't want librpm doing 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/commit/b7a869f0f322cbe428e78150f2c175a

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Jeff Johnson
See issue #258 for faster (and better: includes cache invalidation) than sync(2). -- 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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b

[Rpm-maint] RPM 4.14.0 release candidate 1 released!

2017-09-06 Thread Panu Matilainen
"... but what happened to the beta?", I hear you ask. Well, we skipped it. To cut to the chase, the highlights since the alpha include: - Support for 'unless' rich dependencies - Ensure header is present in callback events - Macro argument quoting changed to be much more compatible - Experiment

Re: [Rpm-maint] [rpm-software-management/rpm] Python bindings from builddir are not used in tests (#265)

2017-09-06 Thread Panu Matilainen
Yup - if you build with a --prefix different from the python used that happens. Fixed by commit 4bb954086af48d0661e4a930d31517226e39db7b -- 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-managem

Re: [Rpm-maint] [rpm-software-management/rpm] Python bindings from builddir are not used in tests (#265)

2017-09-06 Thread Panu Matilainen
Closed #265. -- 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/265#event-1237001347___ Rpm-maint mailing list Rpm-maint@lists.rpm

[Rpm-maint] [rpm-software-management/rpm] Forbid 'if' richops in 'or' context and 'unless' richops in 'and' con… (#317)

2017-09-06 Thread Michael Schroeder
…text Guide users to the correct operator instead. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/317 -- Commit Summary -- * Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context -- File Changes --

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread ニール・ゴンパ
AFAIK, Docker is dumb and passes everything through to the host filesystem to handle. So, yes... -- 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/commit/b7a869f0f322cbe428e78150f

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Panu Matilainen
But... a sync() from within a container does sync() on the entire host? Really? -- 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/commit/b7a869f0f322cbe428e78150f2c175abea4c8c4b#co

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Panu Matilainen
The problem with opt-in is that exactly nobody is going to configure it so it's as good as useless. -- 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/commit/b7a869f0f322cbe428e781

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Igor Gnatenko
It wouldn't, because RPM within docker doesn't know where it runs. So I would rather for opt-in for this feature -- 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/commit/b7a869f0f

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Panu Matilainen
Disabling the sync automatically on chroot installations would be fine by me. Would that cover the dockerd 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/commit/b7a869f0f

Re: [Rpm-maint] [rpm-software-management/rpm] Sync disks at the end of transactions (RhBug:1461765) (b7a869f)

2017-09-06 Thread Michael Schroeder
Eek, that's horrible. Please add a way (macro) to disable this. Calling sync() hurts very much for big servers with huge disks and a big buffer cache. I get that's it's somewhat acceptable for software installation on the server (syncfs would still be much nicer so that data partitions don't get