More obvious explanation of the meaning of m_isReciprocal

Added an inverse test with initial value in MPG

1. Tweaked conversion factor to match those used by Google online converter
2. Added test to convert l/100 km to other representations and back

Tabs vs spaces

Did this just get lost in the pipe or should I consider the patch rejected?

Changed the KIO error code from ERR_INTERNAL to more specific ERR_CANNOT_RMDIR.

Ah, sorry, apparently there is ERR_CANNOT_RMDIR and ERR_COULD_NOT_RMDIR which translate to the same value with the latter being deprecated. I'll update the patch to use ERR_CANNOT_RMDIR.

Well, this (https://api.kde.org/frameworks/kio/html/deprecated.html#_deprecated000015) marks KIO::ERR_COULD_NOT_RMDIR as deprecated. Is there an alternative I should use instead?

@elvisangelaccio: OK, what do I have to do?

Thanks. Can you commit this for me as I don't have commit rights?

What is the status on upstreaming this? Is there anything else you need from me to finish this off?

In D8387#157778, @ngraham wrote:

Do you have commit access? If not, I'll be happy to commit this once some more of the folks who have made comments have also signed off on a final version.

• Check against a range of affected versions
• Small stylistic changes

Tabs/spaces issue

Detect versions of libsmbclient libraries that are considered broken and apply the workaround only for those.

In D8387#157502, @ngraham wrote:

So am I correct that this patch does the following:

• If you go to a real password-protected samba server, without this patch you are totally screwed; with it, you are correctly offered a chance to enter your credentials
• If you go to an invalid address that doesn't exist, without this patch you are told that; with it, you are erroneously offered a credentials window, making you think that the address is real
  
  If so, is there any other way to check whether the server address is valid besides getting back EEXIST?

Oh, of course, call it the "Friday evening attention level". Link to upstream report is not a part of the comment in the source.

This looks reasonable to me. As far as I could test smb:/ and smb:// are now handled in the same fashion.

The guideline suggests that a developer should not apply for a dev account if they do not intend to contribute over a longer period of time. As much as I'd like to help out as much as I can I'd prefer to not open a dev account to push these patches through.

• Use more universal xi18n()
• Use a less technical description of the error

I know, but I prefer to reserve the struct keyword for C-only code.

Update to match the dependent patch

Check for the error code explicitly and report an error from reportWarning() method

Update to match changes in https://phabricator.kde.org/D6662

Instead of hardwiring ENOENT and ENOTDIR errnos provide a more generic function that will generate a warning if any from a list of errors occurs.

As far as I can tell I have no issues with unwritable directories anymore. Note that this patch introduces a small behavior change, when browse_stat_path() encounters ENOENT or ENOTDIR, there is a warning displayed if browse_stat_path() is called from stat(). If it gets called from the listDir() loop, the error is ignored silently. Previous behavior displayed the warning in both cases. I suppose that treating ENOENT and ENOTDIR as an error from stat() and displaying a warning from listDir() would make more sense. I'd prefer to submit this as a separate patch if possible.

Change the logic of browse_stat_path() instead of working around its current behavior.

Okay, I will try to rework this in a more sensible way.

Explain the need for the empty if in the loop.

In D6617#123993, @elvisangelaccio wrote:

What if we make browse_stat_path() return the error code if there is an error or 0 otherwise? This way the caller can choose whether to call finished() or reportError() + error(). The ignore_errors argument would also become useless.

Fix indentation issue.

I'd rather commit under my primary phabricator email if you can view it.

v2. The code now tries to leverage GLX_MESA_query_renderer when it is available and falls back to the old-fashioned probing otherwise. As for some of the suggestions by Martin:

Fair enough, I'll give it another go. Would it make sense to follow this with a trivial NULL -> nullptr patch to keep the code in this file consistent?

In D5947#122926, @broulik wrote:

Do you have commit access? Otherwise I can push this on your behalf so it doesn't get lost. Thanks.