Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing
Hi Nicholas,
For the "debian" group, no additional obligations, and no interference
from evolving team policies which you may or may not appreciate. The
undocumented (as far as I know) conventions of this group are as
follows:
1. All DDs have commit access (as a rule rather than convention)
2. If necessary, most DDs will usually file patches on the BTS, or
might submit an MR if they're enabled
3. Even though all DDs have commit access, uploads for NMUs follow the
usual conventions. So only NMUs for RC bugs in the case of
unresponsive maintainers. It's a fair expectation that in time you'll
be granted permissions to upload, should you wish to pursue the
"Debian Maintainer" role.
https://wiki.debian.org/DebianMaintainer
I am fine with that. So, that means, someone with the right permissions
needsto create the repositories martchus-cpp-utilities,
martchus-qtutilities andsyncthing-tray in the Debian group on Salsa and
give me the permission to push
to these repos, right?
I am a bit confused here. I though libsyncthing is a part of Syncthing
Tray. I could not find the sources anywhere else. Are they actually part
of some other package? Where do I find the sources?
I think these links will be enough for you to figure it out:
https://martchus.no-ip.biz/gitea/Martchus/syncthingtray/commit/6ab7662a649bb10edb1a15e8da542aca87317fa1
https://github.com/Martchus/syncthingtray/tree/master/libsyncthing
https://github.com/Martchus/syncthing/tree/0b016895447adea3e8537f27cff045cabf5c128a
https://github.com/syncthing/syncthing
I am still confused here. What I have found out (correct my, if I am wrong):
1. The upstream source of libsynthing is the Syncthing Tray repository.
2. The library libsyncthing.so is still considered experimental and
therefore not built by default. Hence, the syncthingtray binary
package does not contain a libsyncthing.so or anything similar.
Considering these points, I do not know, what you mean by "unbundling
libsyncthing". Since, the upstream source of libsyncthing is the
Syncthing Tray there should be no other source package for libsyncthing,
and since libsyncthing is not built (and IMHO shouldn't, because it is
still experimental) there is no libsyncthing.so that could be unbundled
from the binary package.
Hannah, so these are fair game if you're interested in Golang. As
dependencies for Syncthing, I think it would be best if these go
under Debian Go Packaging Team maintenance if you decide to work on
them. Oh, and to indirectly answer your question about team
maintenance... There is a rule in Debian: No one can force you work
on anything. Also, we have a social contract and a CoC, so if
someone tries to guilt/shame you into doing work, that's wrong too!
https://wiki.debian.org/SponsoredMaintainer
https://go-team.pages.debian.net/
Let me put it that way: I am not interestend in Golang per se, but I'd
like to see recent versions of Syncthing in Debian, and if I can help by
Golang packaging, I might be interested.
The thing is, like most of us, I am more limited with respect to time
than with respect to motivation. I guess, I can pick up some packaging
tasks here and there, but for now I cannot promise to allocate much time
for this.
If your eventual objective is "Debian Maintainer" or "Debian
Developer" status, then it may be useful to cultivate a rapport with
another DD, because you'll need two advocates for the application.
It's totally optional, of course!
Haven't though about that, TBH. My current motivation is just to bring
Syncthing Tray into Debian, but being a maintainer could be something I
could be interested in.
How do we proceed now?
Have you read any of the New Maintainer Docs, and Debian Policy? Are
you familiar with Lintian? Expectations for all uploads are that
they're Policy-compliant, DFSG-free, and Lintian-clean. It's also
worth reading the ftpmaster "Reject FAQ for Debian's NEW-Queue".
I know the Debian New Maintainers' Guide and the Debian Policy Manual. I
have digested them to a decent degree (it is a large amount of text),
but I wouldn't claim knowing them by heart.
Regarding lintian, I am using sbuild, so I am using lintian and I am
also confident that the dependencies are correctly specified.
The current lintian warnings/errors I have are
- in all three packages the "unreleased-changes" warning, which I'll
remove once the packages are ready for upload.
- in all three packages the "source: unknown-field Description" warning
is shown. This is considered a false positive of lintian and will
change in a new release. See #998115.
- in the syncthingtray package the "package-name-doesnt-match-sonames
libsyncthingconnector1.1.10 libsyncthingmodel1.1.10
libsyncthingwidgets1.1.10". Since these are quite specific libraries
that are only used for Syncthing Tray, I do not see a point in
making separate binary packages for each of them. Hence, I would
suggest to ignore these warnings for now.
First, file ITP (Intent to Package) bug reports for the two
dependencies using their prefixed source package names. You will
close these bugs in each package's first changelog entry. This is
required. Yes, I was lazy and didn't file ITPs for cpp-utilities,
qtutilities--even though I was working on them. Yes, I should have
filed them.
Done. See #998178 and #998179.
There is no need to file an RFS (Request for Sponsorship) for these
three packages, because I've committed to reviewing and sponsoring
them.
Cool.
You'll also need to do a formal copyright review which is (infamously)
not fun for most people. I've already done the reviews on my copies,
so if you'd like to skip this for these three packages, I'm completely
ok with it and can just merge my work. Formal copyright reviews are
also part of the basic skill-set for Debian packaging work. Part of
this also requires identifying binary blobs, embedded copies, and
assets of questionable origin.
https://www.debian.org/social_contract
https://wiki.debian.org/DebianFreeSoftwareGuidelines
https://wiki.debian.org/DFSGLicenses
Let me know if you prefer to do a copyright review on these packages,
or save it for another time.
I have created the debian/copyright to my best knowledge. If I am
interpreting <https://wiki.debian.org/CopyrightReview> correctly, the
review should be done by someone other than me, I guess. Hence, if you
have time for the review, that would be awesome.
I have seen your feature request on Qt ForkAwesome
<https://github.com/Martchus/qtforkawesome/issues/2>. I was wondering,
why it would be necessary to do runtime font rendering, instead of
pre-rendering the icons. Qt ForkAwesome allows you to specify the font
file to use at build time. Hence, fonts-fork-awesome would then just be
a build dependency. Currently, fonts-fork-awesome does not, however,
include all necessary files. I have sent a patch to the maintainer
(#998147).
The current state of the packages is on Salsa
<https://salsa.debian.org/rittich/packaging-syncthingtray>, as always.
From what I have understood, once the copyright review is done, the
packages should be ready for upload, right? So, let me know if there is
anything left to do.
Regards
Hannah
Reply to: