Package Details: wsdd 0.6.4-1

Git Clone URL: https://aur.archlinux.org/wsdd.git (read-only, click to copy)
Package Base: wsdd
Description: A Web Service Discovery (WSD) host daemon for SMB/Samba.
Upstream URL: https://github.com/christgau/wsdd
Licenses: MIT
Submitter: fryfrog
Maintainer: fryfrog (jgottula)
Last Packager: fryfrog
Votes: 10
Popularity: 3.09
First Submitted: 2019-04-03 15:45
Last Updated: 2021-03-09 17:52

Dependencies (1)

Required by (0)

Sources (3)

Latest Comments

1 2 Next › Last »

fryfrog commented on 2021-06-14 22:39

You're a co-maintainer and I think all your ideas so far are fantastic, I'll poke around in some of my other packages and see if they make sense there too! :)

jgottula commented on 2021-06-14 22:22

@fryfrog Yeah I guess I'd be onboard with being a co-maintainer.

jgottula commented on 2021-06-14 22:21

@fryfrog One other thing... it would be nice if the systemd service file used the EnvironmentFile= directive with a file, e.g. /etc/conf.d/wsdd, as the main way to customize the parameters to the executable (such as --workgroup).

As it is currently, overriding just the workgroup parameter means I have to make a systemd unit override stub file that wipes out the whole ExecStart= line from the main unit file and replaces that entire line with a different one with my changes to it. And that's a little less than ideal, because if the ExecStart= line of this package ends up changing at some point (let's say for example that it dropped --shortlog), there's no mechanism (like a .pacnew file) that would alert me to the fact that my override file needs an update to its ExecStart= line to stay in-step with the main unit file. Whereas an /etc/conf.d/wsdd file could take care of that situation much more tidily, via /etc/conf.d/wsdd.pacnew showing up if the package's default parameters change.

(You probably know what you're doing; but if you aren't already familiar with how to set this sort of thing up, the samba package is a decent enough example: check out the EnvironmentFile= and ExecStart= lines in /usr/lib/systemd/system/smb.service, plus the /etc/conf.d/samba file.)

fryfrog commented on 2021-06-14 21:26

@jgottula: Sounds like you know what you're doing, would you like to be a co-maintainer?

jgottula commented on 2021-06-14 21:09

@fryfrog Just a couple of heads-up notices for whenever the the next upstream version is released:

  1. Commit 0d2faa67 presumably means that the wsdd.service file can be updated to use DynamicUser=yes and we can just ditch the wsdd.sysusers file entirely. (And actually, I guess in theory that change could be rolled in right now as a pkgrel bump, if desired, since it only concerns the systemd files and doesn't have any specific requirements against the wsdd code itself.)

  2. Commit cffedb2b (re: GitHub issue #113) makes it so wsdd now attempts to load the defusedxml module; if it cannot, then it fallback-imports the default xml module. So, at the very least, we'll need optdepends=('python-defusedxml: improved security against malicious XML'). And there's an argument to be made that it should perhaps just plain be a mandatory dependency; both because it's security-related, and because the python-defusedxml package adds a pretty minimal burden: it's right there in the extra repo and it has no additional package dependencies of its own.

nakinney commented on 2020-07-15 03:00

Nice! My Windows box can now see my shares without having to used SMB 1.0. Thank you for adding this to AUR!

TomaszGasior commented on 2019-08-04 19:05

@fryfrog I had enabled both smb and wsdd service in systemd. Also, I didn't mean upstream update but your broken service file. For NOW I have no issue, service with your *.service file starts properly but previously wsdd service was not able to start properly because of error which does not occur for now. I will keep wsdd enabled, I hope problem won't occur anymore. Sorry for delayed response.

fryfrog commented on 2019-07-22 19:41

That's... not a lot of useful data. Did you remember to enable it as well as start it?

The differences between the 0.3 and 0.4 versions were very minimal, some minor wants/after, using less log output and not having the --workgroup option. The only real changes I do on top of the built in is specify the right user (since the package creates it) and add a --workgroup WORKGROUP so that users know to over ride it if needed.

Good luck.

TomaszGasior commented on 2019-07-22 19:31

The main difference is that original service unit works after reboot, your does not work.

fryfrog commented on 2019-07-22 19:31

@TomaszGasior, the original would have been pulled from its service file so I've just basically done the same. Let me know if there was something specific you thought was better.