Re: [Rpm-maint] [rpm-software-management/rpm] Flush 20+ year old statfs() jungle, always use standard statvfs() (#1143)

2020-03-30 Thread Florian Festi
Merged #1143 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/1143#event-3177469691___ Rpm-maint mailing list Rpm-mai

Re: [Rpm-maint] [rpm-software-management/rpm] Flush 20+ year old statfs() jungle, always use standard statvfs() (#1143)

2020-03-27 Thread lgtm-com[bot]
This pull request **fixes 1 alert** when merging f2122a151c93c4df0d9c1ac902e2ae88ea3c942e into dd08abdd123947fad6bca2044493e7f68375ffc0 - [view on LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-ec7bc6a97065731db06d29091cf2a54d080f4ed4) **fixed alerts:** * 1 for FIXME

[Rpm-maint] [rpm-software-management/rpm] Flush 20+ year old statfs() jungle, always use standard statvfs() (#1143)

2020-03-27 Thread Panu Matilainen
Unlike that multiple statfs() variants, statvfs() is actually in POSIX 1-2001 already and covers everything we need so there's little point mucking with anything else. statvfs() is what Linux has been using all along anyway this means no change on the primary platform. If this actually regresses s