wsdd

wsdd copied to clipboard

Hello, Not an issue but I just couldn't find an mail address for my request.

I have created files to generate a wsdd Debian package. The package installs wsdd as service unit. wsdd's command line parameters are configurable by the file /etc/wsdd.conf. It would be my pleasure to contribute this to wsdd.

regards Felix

Thanks for your work, Felix. Is your package available anywhere?

There has been a discussion on the Ubuntu Bugtracker to include wsdd in that distro. In the third comment it is argued that a Debian package may would make more sense. So it might be a good opportunity for you to jump in and fill that gap.

From my side, I would prefer to not include any distro-specific package in this repo in order to have a clean separation for what is the pure software source code and what are packages for specific distros. Correct me if I'm wrong, but I think that this is the usual way to go.

In that sense, I'd like to notice that I already maintain an unofficial Gentoo package which I try to push into the distro. For Arch there is also a user-contributed package. So, the Debian (und Ubuntu) community may welcome your contribution...

Hello christgau,

Is your package available anywhere?

Yes, the package is currently available in this repository https://pkg.ltec.ch/public.

There has been a discussion on the Ubuntu Bugtracker to include wsdd in that distro. In the third comment it is argued that a Debian package may would make more sense. So it might be a good opportunity for you to jump in and fill that gap.

Thanks for this link. Probably that's in fact the way to go ahead for a wsdd Debian package.

From my side, I would prefer to not include any distro-specific package in this repo in order to have a clean separation for what is the pure software source code and what are packages for specific distros. Correct me if I'm wrong, but I think that this is the usual way to go.

Agreed. It makes sense to keep the source code for package creation away from the wsdd source code. Especially since there are quiet a few different packaging systems around.

regards, Felix

Is your package available anywhere?

Yes, the package is currently available in this repository https://pkg.ltec.ch/public.

Thanks for providing the link.

There has been a discussion on the Ubuntu Bugtracker to include wsdd in that distro. In the third comment it is argued that a Debian package may would make more sense. So it might be a good opportunity for you to jump in and fill that gap.

Thanks for this link. Probably that's in fact the way to go ahead for a wsdd Debian package.

That really sounds good 😉

I'll keep that ticket open and assign it to you. It might be a good place to keep everyone informed of your progress in pushing a package for wsdd to Debian (or Ubuntu).

What about a ppa on launchpad?

What about a ppa on launchpad?

From what I know launchpad PPAs are more or less directly related to Ubuntu. I would prefer to see wsdd in the official Debian repository.

Funny I was thinking about the same kind of thing. Do you have the source code for the package itself available?

Funny I was thinking about the same kind of thing. Do you have the source code for the package itself available?

What do you mean by "source code for the package itself"? You can look at the source code I wrote to create the deb package by downloading the *.deb file from the link above and inspecting it with an archive manager. Please note: my code does not at all comply with the Debian Policy Manual.

Sorry, I accidentally closed the issue.

@fxrb FYI: I've added a note to the readme in the feat/discovery that is very like to be merged into master at some point in the future. The readme now references your packages for Ubuntu/Debian. Do feel fine with that?

Yes, I'm perfectly fine that.

Great & Thanks.

Hi. I'm trying to use the linked debian repo on my raspberry pi but it is not working because the armhf architecture is not supported.

Seeing as how it's just python code and the architecture doesn't actually matter, could you add an armhf supported architecture there?

The code runs fine on my raspberry pi, would just like to have a packaged up version.

I have added the armhf architecture to the repository and made the wsdd package available for all architectures supported by the repository. Note that this might activate updates for already installed wsdd packages for all other architectures.

Hey there! Thank you @christgau for this awesome creation, I am new to the linux world and was able to get his working on my new Ubuntu server install.

I was curious @fxrb, could I use the Ubuntu repo you setup for Ubuntu "Bionic" with the current version of Ubuntu server I'm using: "Focal" (20.04). I hope this question makes sense and i posted it in the right place. Thank you both again for making this possible!

No worries your question makes sense and is posted at the right place.

An update from Ubuntu 18.04 to 20.04 of my development machine (and others in the company) will happen according to Focal Fossa Release Notes:

From 18.04, upgrades will not be enabled until approximately the date of the 1st 20.04 point release at the end of July.

So this will be the earliest point in time our Debian/Ubuntu repository will be update by the new codename for Ubuntu 20.04 (Focal Fossa).

Meanwhile this workaround could help:

1. download the wsdd_0.5.0_all.deb file from https://pkg.ltec.ch/public/pool/main/w/wsdd
2. right click the downloaded file and see if there is an option to install it (with QApt Package Installer, for instance)
3. if 2. does not work, use dpkg to install the downloaded file

Good luck, Felix

Thank you so much for the quick reply!

I will wait for the new repo (i think im saying that right) to come online, and thank you for the knowlege on why there is a wait time ( Focal Fossa Release Notes https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/Kubuntu). In the meantime i have installed it manually and it is working perfectly!

Thank you again for your help and expertise!

Joel

On Sun, Jun 7, 2020 at 3:36 AM fxrb [email protected] wrote:

No worries your question makes sense and is posted at the right place.

An update from Ubuntu 18.04 to 20.04 of my development machine (and others in the company) will happen according to Focal Fossa Release Notes https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/Kubuntu:

From 18.04, upgrades will not be enabled until approximately the date of the 1st 20.04 point release at the end of July.

So this will be the earliest point in time our Debian/Ubuntu repository will be update by the new codename for Ubuntu 20.04 (Focal Fossa).

Meanwhile this workaround could help:

1. download the wsdd_0.5.0_all.deb file from https://pkg.ltec.ch/public/pool/main/w/wsdd
2. right click the downloaded file and see if there is an option to install it (with QApt Package Installer, for instance)
3. if 2. does not work, use dpkg to install the downloaded file

Good luck, Felix

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/christgau/wsdd/issues/19#issuecomment-640194513, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP3WG5RWCUEN5ICAPO6AERDRVNURFANCNFSM4I5YHATA .

The repository has been updated to make wsdd v0.6.1 available for Ubuntu 20.04 (Focal Fossa).

Thank you so much for the update! I appreciate the follow up!

On Sun, Sep 13, 2020 at 5:45 AM fxrb [email protected] wrote:

The repository has been updated to make wsdd v0.6.1 available for Ubuntu 20.04 (Focal Fossa).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/christgau/wsdd/issues/19#issuecomment-691667249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP3WG5VMR6Q2O6JBDDFWSDDSFS5INANCNFSM4I5YHATA .

Would you be able to add support for the arm64 architecture?

https://www.raspberrypi.org/blog/latest-raspberry-pi-os-update-may-2020/

I have added the armhf architecture to the repository and made the wsdd package available for all architectures supported by the repository. Note that this might activate updates for already installed wsdd packages for all other architectures.

Error Message on pi4 running 64bit beta raspbian OS Buster: N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://pkg.ltec.ch/public buster InRelease' doesn't support architecture 'arm64'

I'd also like to suggest that the Read.Me contain instructions for the debian package on how to add the repository key:

You may also add the public key to the trusted ones on your system. # curl -L https://pkg.ltec.ch/public/conf/ltec-ag.gpg.key | sudo apt-key add -

Cheers!

I have extended the architecture list by arm64 for the buster distribution.

I have extended the architecture list by arm64 for the buster distribution.

Thank you so much! Works like a charm! Installed on Raspbian OS 64bit beta, and when run in a terminal, the pi4 showed up in the the network of my Windows 10 Home client.

Cheers!

pi@pi4:~ $ wsdd
2020-10-31 20:52:05,976:wsdd WARNING(pid 942): no interface given, using all interfaces

Ubuntu on Raspberry Pi 4? Okay, I have extended the architecture list by arm64 for the focal distribution.

Ubuntu on Raspberry Pi 4?

Seems to be possible https://ubuntu.com/download/raspberry-pi

Can't proceed to update I've added public key I'm running Ubuntu 20.04

Edit: Ok so it doesn't accept connection trhough proxy, disabled proxy and it worked

Quoting https://github.com/christgau/wsdd/issues/19#issuecomment-544123776:

Funny I was thinking about the same kind of thing. Do you have the source code for the package itself available?

What do you mean by "source code for the package itself"? You can look at the source code I wrote to create the deb package by downloading the *.deb file from the link above and inspecting it with an archive manager. Please note: my code does not at all comply with the Debian Policy Manual.

@fxrb - I assume that @iandonnelly was referring to the source debian directory that contains the Debian packaging config and files.

You suggest that unpacking the deb file will reveal the "source code [you] wrote", but unless you are using some particularly arcane method to produce your packages, then I doubt that's actually the case.

Obviously unpacking the deb file will show the files used to install the software (some which may have even been explicitly created by you), but not all. You do note that your package isn't compatible with Debian policy, so perhaps your packaging files are simple (and your method of building packages dramatically different to what I've experienced) and that's exactly what is included in your deb? Although, I note that the systemd service file from your package does not match the one here in the repo. So you must at least have a separate copy of that somewhere?!

Regardless, I agree with @iandonnelly. Even if what is in the deb file is exactly what is in your packaging source code (which I'd be surprised by), in the spirit of open source and collaboration, the packaging should be publicly available. Ideally IMO it should be via a repo here on GH, so that others can see it at a glance and potentially even improve it (perhaps to the point where it is compliant with Debian policy and can be included in Debian default repos, and by extension will land in Ubuntu's too?!).

I note too that OpenMediaVault have a fork of the code, in which they include a debian directory. They build a Debian package (wsdd_0.6.2-1_all.deb) from it. So it's not as new as your package, but they have published their source.

Ideally IMO it should be via a repo here on GH, so that others can see it at a glance and potentially even improve it (perhaps to the point where it is compliant with Debian policy and can be included in Debian default repos, and by extension will land in Ubuntu's too?!).

I would highly appreciate and support such an initiative and joint efforts.

Quoting #19 (comment):

Funny I was thinking about the same kind of thing. Do you have the source code for the package itself available?

What do you mean by "source code for the package itself"? You can look at the source code I wrote to create the deb package by downloading the *.deb file from the link above and inspecting it with an archive manager. Please note: my code does not at all comply with the Debian Policy Manual.

@fxrb - I assume that @iandonnelly was referring to the source debian directory that contains the Debian packaging config and files.

Unfortunately @iandonnelly never answered my question so we don't know. If so it would be 'DEBAIN' and not 'debian' as the package is a binary package using Binary package control files. Source packages share another purpose but I'm not going into further details here.

You suggest that unpacking the deb file will reveal the "source code [you] wrote", but unless you are using some particularly arcane method to produce your packages, then I doubt that's actually the case.

Your doubts are unfounded. Unpacking the deb file will also reveal an archive named control.tar.xz which contains all control files from the 'DEBIAN' directory used for packaging. We use a handcrafted bash script to generate deb packages (not only for wsdd). This script does compressing, stripping, etc. and finally also uses dpkg-deb to build the package. If you call this arcane, well, okay.

Obviously unpacking the deb file will show the files used to install the software (some which may have even been explicitly created by you), but not all.

Actually unpacking the deb file will show all files.

You do note that your package isn't compatible with Debian policy, so perhaps your packaging files are simple (and your method of building packages dramatically different to what I've experienced) and that's exactly what is included in your deb?

Yes.

Although, I note that the systemd service file from your package does not match the one here in the repo. So you must at least have a separate copy of that somewhere?!

There is no such thing as a "separate copy somewhere", why should that be the case? The file you found in the package, that differs from the one you find in the wsdd repository here, is a file I added or modified. So you got the source in your hands! QED.

Regardless, I agree with @iandonnelly. Even if what is in the deb file is exactly what is in your packaging source code (which I'd be surprised by), in the spirit of open source and collaboration, the packaging should be publicly available. Ideally IMO it should be via a repo here on GH, so that others can see it at a glance and potentially even improve it (perhaps to the point where it is compliant with Debian policy and can be included in Debian default repos, and by extension will land in Ubuntu's too?!).

Agreed. As I'm also contributing to the LINUX and the U-Boot project I'm quite familiar with the "spirit of open source and collaboration". Getting a package compliant with the Debian policy however is not a snap. And yes, for a package conforming with the Debian policy there will be a bunch of "other" files not included in the deb file. But as already stated: my actual wsdd package is not compliant with the Debian policy.

I note too that OpenMediaVault have a fork of the code, in which they include a debian directory. They build a Debian package (wsdd_0.6.2-1_all.deb) from it. So it's not as new as your package, but they have published their source.

Why not clone that repository then and just replace the wsdd.py script? I personally doubt it will be that simple but it could be worth a try :wink: .

FWIW whilst I'm far from an expert, I'm fairly familiar with Debian packaging. I maintain a repo myself. Many of our packages should be Debian compliant, but some certainly aren't (we we tweak the source code in non-standard ways).

I have always intended to get more involved with official Debian packaging, but I never seem to have the spare cycles to fill in the knowledge gaps I have.

[...] it would be 'DEBAIN' and not 'debian' as the package is a binary package using Binary package control files.

AFAIK, it should be debian (i.e. lower case) in the package source. I'm talking about the source code that is used to generate the Debian binary &/or source packages (as you rightly point out, the source package will include the debian directory from the package build source code). By convention, the DEBIAN directory in the binary package is generated (from the debian directory) by the package building process.

Unpacking the deb file will also reveal an archive named control.tar.xz which contains all control files from the 'DEBIAN' directory used for packaging.

Yeah, while I was trying to work out what you'd done, I compared the contents of your package against the contents of the OpenMediaVault one.

FWIW, you may already be aware, but IMO a quicker/easier way to unpack deb packages (rather than using ar and tar) is:

dpkg-deb -R <pkg>.deb <tmp_dir>

Or if you just want the contents of control.tar.xz (or control.tar.gz as the case may be):

dpkg-deb -e <pkg>.deb <tmp_dir>

We use a handcrafted bash script to generate deb packages (not only for wsdd). This script does compressing, stripping, etc. and finally also uses dpkg-deb to build the package. If you call this arcane, well, okay.

Ah ok. This note that you've scripted a manual package construction process, certainly explains things. :smile:

Sorry I didn't mean to offend by my use of 'arcane', but I would argue that unless you are publishing the custom script(s) that you use to produce your packages (or at least explaining the process in detail) your custom build process is arcane by definition:

arcane (ɑːˈkeɪn/)

adjective:

understood by few; mysterious or secret.

:wink:

With that knowledge, I totally get why your package isn't compliant with Debian policy!

I would urge you to look into the use of "proper" package building tools, such as sbuild, pbuilder, git-buildpackage, or even dpkg-buildpackage (from dpkg) and debuild (from devscripts), etc (there's quite a few; AFAIK most are wrappers around pbuilder or sbuild). That way, so long as you set up your source directory correctly (particularly the rules & *.install files in the debian dir), most of the work is automagical.

FYI we use pbuilder for our package building, although we have a custom wrapper around it (called deckdebuild) which leverages overlayfs to build the package within a copy-on-write chroot of a local pre-existing buildroot.

Agreed. As I'm also contributing to the LINUX and the U-Boot project I'm quite familiar with the "spirit of open source and collaboration".

Ok cool. Again, apologies if my comment caused offence. It didn't occur to me that you were essentially building packages in a completely custom way.

Getting a package compliant with the Debian policy however is not a snap. And yes, for a package conforming with the Debian policy there will be a bunch of "other" files not included in the deb file. But as already stated: my actual wsdd package is not compliant with the Debian policy.

Trying to build a package compliant with Debian policy using custom scripts would certainly be a nightmare! But if you instead use one of the many existing tools within Debian, then most of the hard work is done for you and it'll be a whole lot easier... :wink:

Why not clone that repository then and just replace the wsdd.py script? I personally doubt it will be that simple but it could be worth a try :wink: .

Funny you suggest that... :smile: And yeah, it is that simple! :smile:

After I posted here the other day, I more-or-less did that. FYI I created a new repo with master branch tracking master of this repo, and a openmediavault-master branch tracking master of the OpenMediaVault repo (which includes teh debian dir). I then created a new turnkey-packaging branch (forked from openmediavault-master). In that branch, I rebased on the most recent release of wsdd (i.e. I rebased on the v0.6.4 tag in master) and made a few packaging tweaks.

As I've mentioned, I'm certainly no packaging expert, so I'm sure that there are plenty more improvements to be made... (E.g. I don't actually think that I need to explicitly be installing dh-exec when using debhelper >= 12; most of my experience is with debhelper <= 10). There are also more opinionated changes (to the packaging code provided by OpenMediaVault) that I'd like to make, such as either moving/renaming /usr/sbin/wsdd.py to /usr/sbin/wsdd, or perhaps putting wsdd.py in /usr/lib and symlinking /usr/sbin/wsdd but it's not too bad as is IMO.

Because of the way that the source dir is constructed (i.e. debian dir added to upstream source in a third party fork), this is still not really acceptable into Debian. (Although FWIW if @christgau included the debian directory, then it'd probably be reasonable to consider it a "native" Debian package source and it'd be good to go as is I reckon, not withstanding perhaps a few debian tweaks...).

If you are at all interested in the package that I built (from my fork - with the tweaked debian dir - using the pbuild wrapper I mentioned earlier - you can find it here.

Can we get updates for Ubuntu on "groovy" and "hirsute" (20.10 and 21.04)? I got a Pi 4 and a few x86-64 VMs with 20.10 and I'll be going to 21.04 as soon as they fix the EFI issues.

The repository will support LTS versions only, so no.