Your if<space>( style is now inconsistent with the endif(.
Code LGTM

update comment as well

FTR: this could technically still dupe with smbc native NT1 listing, except smbc would list workgroups while we list services, so this should generally not be duplicative information.

Yep. I'm 100% certain of this. The library in fact has no API that returns a complete URL or anything near a complete URL. It's using dirent-inspired API to let us iterate/stat paths and only ever returns paths relative to whatever input it got, from those paths we then compose the actual output URLs again.

ping

ping

use qvector instead of list

ping

In D27804#621988, @sitter wrote:

In D27804#621970, @thiago wrote:

Still want to see that round-trip.

But why? Converting an smbcUrl to a QUrl would literally be useless code.

I wouldn't terribly mind a second pair of eyes.

Looks alright to me now. 👍

In D27980#625840, @zzag wrote:

I'm not sure whether this is useful, but libdrm has an API to enumerate devices.

LGTM for when the kcrash diff is ready.

Paging @dfaure for expert input.
Is that global static qbytearray safe? Should we make it a q_global_static to comply with our library policy? Any objections to the diff?

In D21466#625834, @apol wrote:

So yes, Discover will notify about updates. That doesn't mean it should be shown here too.

To clarify: the options as I understand them are:

In D27973#626226, @aacid wrote:

In D27973#625703, @sitter wrote:

Looks reasonable.
Do you think it'd make sense to mark the remaining classes deprecated? If the long term goal is to drop the lib entirely and have people use musicbrainz directly I figure we should communicate that.

I agree and disagree :)

I think libkcddb needs to die, since it's basically built around the cddb service which is shutting down, i mean the musicbrainz support was optional until this change.

Otherwise I'm not sure if suggesting people to use libmusicbrainz directly is the best idea and maybe we need something intermediate? I mean if you look at MusicBrainzLookup::calculateDiscId that's something i wouldn't want everyone to have to implement themselves

Tested fuse and it works as expected. Code looks reasonable, but I have little expertise with this class.
@feverfew probably ought to comment as well since he introduced the fuse code.

Unit test? (:

Probably should also get added to one of the parser tests to make sure it doesn't fall on the face.

Looks reasonable.
Do you think it'd make sense to mark the remaining classes deprecated? If the long term goal is to drop the lib entirely and have people use musicbrainz directly I figure we should communicate that.

• rebase
• move transfer impls to cpp
• new unpop function to make the ring usage more consistent and make sure neither thread can overtake the other
• new test for transfer tech. notably simulating imbalance in processing speed of the ring threads
• segment now constructs from the file size instead of the segment size. this centralizes segment size code in the segment
• make all transfers use a segment constructed with the relevant file size to get "smart" size calculation everywhere (ring buffer continues only for copyget and get)

Yeah, the repo also needs adding to some binary-factory-tooling file. And I guess the build should be green first on neon, last thing I know they were stuck in some Qt migration limbo and not building. Them not building on neon makes it hard to move ^^

switch to indexOfMethod, also construct a signature from the slotname. indexOf requires a normalized signature (e.g. save(QVariantMap))

In D27871#623593, @bruns wrote:

In D27871#623542, @sitter wrote:

In D27871#622933, @bruns wrote:

Can you also mention why errno == EGAIN does not have to be handled ("EAGAIN could only happen iff the file where opened with O_NONBLOCK. All other seek errors are fatal.").

I do not understand what that means.

Previously, EAGAIN was handled explicitly (although the implementation was wrong). Why is it fine to not handle it? This belongs in the commit message.

In D27873#623582, @bruns wrote:

Please correct the comment in the code - it depends on the server SFTP implementation.

Neat. I am Mostly just waiting for a test at this point.

LGTM. Does anyone have final comments?

In D27871#622933, @bruns wrote:

Can you also mention why errno == EGAIN does not have to be handled ("EAGAIN could only happen iff the file where opened with O_NONBLOCK. All other seek errors are fatal.").