Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah, and anyone else reading this,

Update: qtforkawesome is currently waiting in NEW, and I'm currently
testing the latest upstream syncthingtray.  I haven't moved the project
to the Salsa (old collab-maint) group yet, but you can find it with the
fork relationship on salsa between your work and mine.

Sorry for the delay, the questions in this email were also discussed at
various other sites towards the end of 2021, and I didn't see the need
to send this draft until now.

Hannah Rittich  writes:
> On 21/11/2021 22:13, Nicholas D Steeves wrote:
>
> Currently, the Syncthing sources are neither included in the upstream
> tarballs nor in the upstream git repo. They can be pulled into the
> source tree by using the git submodule, but this does not happen unless
> you do this explicitly.
>
> Nevertheless, to be sure I have added the `submodules = False` to the
> `gbp.conf` file. This ensures that the submodules will never be included
> in a tarball built by gbp.
>
> If this situation changes, we might need to change the git repository to
> the gbp import-orig workflow, but for now we should be able to keep it
> as it is.
>
>> 2) Use a build-system config key to explicitly disable this functionality.
>
> Done.
>

Thanks much appreciated!  The principle here is thus: should the
maintainers disappear, it should be easy for someone else to take up the
baton and resume work with minimal pitfalls.

[snip]

>>> - 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.
>>>
>> 
>> At this time I'm not thinking about this issue; Let's return to this
>> question after the two dependencies have been uploaded.  Policy will
>> need to be consulted
>> 
>>   https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>> 
>> Be it resolved that the current state is indeed the correct direction, a
>> minimum solution is a lintian override.
>
> Okay.
>

The salient questions here are "are they private libraries?" and "do they
have any kind of stable ABI?"  For the former, yes, for practical
purposes, and to the latter, no they don't have any kind of stable ABI.
Thus I've chosen to go with a lintian override.  Various colleagues have
also expressed that it may be necessary to cut these libs from the
system library path...if ftpmasters don't see an issue, no further work
will be required at this time.  It is possible that Policy may one day
prohibit this, but that's a worry for later!

>> Additionally, no Debian package should bundle fonts (or font-icons).
>
> Why? Which part of the policy manual are you referring to? What are your
> concerns regarding pre-rendered icons?
>

This is mostly a question related to martchus-qtforkawesome packaging if
I remember correctly.

Policy § 11.8.5.1 "Fonts of any type supported by the X Window System
must be in a separate binary package from any executables, libraries, or
documentation".  The font-icons hack is an interesting case because
while they're a font they intuitively seem to be icons.  The
'fonts-font-awesome' is the package that fulfills this requirement, and
I remain hopeful that ftpmasters will approve martchus-qtforkawesome
with Syncthing as prior art, even though both packages embed what are
technically fonts.

There's a dialectic between the work people publish, and Policy, and
this case definitely affects Policy.  As for pre-rendering, I'm sure
you've noticed that the majority of documentation overwhelmingly
supports regeneration of everything from the most sourceful form...  For
example, for fonts: TTF, OTF, BDF, PFB, FNT, and WOFF are output
formats, and not source (https://wiki.debian.org/Fonts).  To answer what
you may be thinking, yes, font-icons may only be fonts due the output
format of their build system.

Thus, I suspect that the following loophole exists: If a font-icon
source has a DFSG-free license, this means that another project has the
right to to export the font source into another format, such as SVG.
SVG can be losslessly modified, and thus I believe it could be argued
that SVG may be considered high-quality source, and that the font source
to SVG format conversion is a non-issue.  On the other hand, I don't
think that rasterised icons (lossy) qualify for this loophole when
lossless source is available.  There have been many discussions about
the freeness of lossy graphics on the mailing lists over the years, if
you're interested.

'hope this answers your questions!
Thank you once again for all of your work on this and related
dependencies.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hi Nicholas,

On 21/11/2021 22:13, Nicholas D Steeves wrote:
> Yes, I can create the first two at what will probably be round two of
> the reviews, but I recommend waiting for syncthing-tray, because you may
> prefer a "gbp" style repository for it, for ease of unbundling using
> Files-Excluded.  Syncthing-tray also shouldn't be uploaded until the
> first two packages clear the NEW queue, so there's no rush.
>
> [...]
>
> It looks to me like Martchus is bundling a subset of his fork of
> upstream Syncthing.  This should be excluded from the Debian
> orig.tarball.  This can be done with a script and a source-cleaning git
> branch, plus merging the cleaned tag to debian/main rather than merging
> the upstream tag.  Alternatively, it can be automated by using gbp's
> support for Files-Excluded.

Currently, the Syncthing sources are neither included in the upstream
tarballs nor in the upstream git repo. They can be pulled into the
source tree by using the git submodule, but this does not happen unless
you do this explicitly.

Nevertheless, to be sure I have added the `submodules = False` to the
`gbp.conf` file. This ensures that the submodules will never be included
in a tarball built by gbp.

If this situation changes, we might need to change the git repository to
the gbp import-orig workflow, but for now we should be able to keep it
as it is.

> 2) Use a build-system config key to explicitly disable this functionality.

Done.

> Cool, and of course, no pressure.  The main reason I propose this is
> because it gives you increased autonomy (allows you to upload a set of
> packages without needing a sponsor).  When I had to depend on someone
> for every single upload I was frustrated an demotivated by the long
> waits...because unfortunately it seems that windows of free time often
> don't align, you know?

This is a very good point. Having more autonomy in the long run, seems
to be desirable.

>> - 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.
>>
> 
> At this time I'm not thinking about this issue; Let's return to this
> question after the two dependencies have been uploaded.  Policy will
> need to be consulted
> 
>   https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> 
> Be it resolved that the current state is indeed the correct direction, a
> minimum solution is a lintian override.

Okay.

> Additionally, no Debian package should bundle fonts (or font-icons).

Why? Which part of the policy manual are you referring to? What are your
concerns regarding pre-rendered icons?

Regards,

Hannah

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

P.S.

>> 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.
>>
>
> The definition of "unbundling" depends on the context.  Sometimes it
> means a source package split, but in this case it means deleting
> Marchus' fork from Syncthing-Tray's source.  If it's unused, then this
> shouldn't cause any problems at this time.  If at some point it becomes
> default then it is better for the build to fail loudly rather than link
> against a custom libsyncthing.  At that time the decision becomes: 1)
> depend on Debian's Syncthing source and link it into the expected place,
> or use a build-system config key to point Syncthing-Tray's build system
> to the correct location.  2) Use a build-system config key to explicitly
> disable this functionality.
>

I can't remember what I found when I investigated this, but was it that
libsyncthing.so was used to provide an embedded copy of the Syncthing
server?  If so, it seems to me that the correct course of action is to
forever disable it, because Syncthing Tray should use the
Debian-provided Syncthing (user-specific) systemd service.  In addition
to correctness, in combination with "loginctl enable-linger user" this
allows the Syncthing daemon to continue to run if X crashes (or is
killed), or when the user logs out without shutting down the system.

If Syncthing Tray wants to manage Syncthing daemon startup (ie: other
than the restart and shutdown functionality provided by the web GUI),
then it should use systemctl --user or the dbus interface.  The
behaviour for non-systemd users who use the built-in launcher should be
something like the following the following: Syncthing Tray starts an
unmanaged syncthing daemon using the copy of Syncthing installed from
the bin:syncthing package.

No need to worry about this until after cpp-utilities and qtutilities
uploads of course.



signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

P.S.

>> 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.
>>
>
> The definition of "unbundling" depends on the context.  Sometimes it
> means a source package split, but in this case it means deleting
> Marchus' fork from Syncthing-Tray's source.  If it's unused, then this
> shouldn't cause any problems at this time.  If at some point it becomes
> default then it is better for the build to fail loudly rather than link
> against a custom libsyncthing.  At that time the decision becomes: 1)
> depend on Debian's Syncthing source and link it into the expected place,
> or use a build-system config key to point Syncthing-Tray's build system
> to the correct location.  2) Use a build-system config key to explicitly
> disable this functionality.
>

I can't remember what I found when I investigated this, but was it that
libsyncthing.so was used to provide an embedded copy of the Syncthing
server?  If so, it seems to me that the correct course of action is to
forever disable it, because Syncthing Tray should use the
Debian-provided Syncthing (user-specific) systemd service.  In addition
to correctness, in combination with "loginctl enable-linger user" this
allows the Syncthing daemon to continue to run if X crashes (or is
killed), or when the user logs out without shutting down the system.
IIRC if Syncthing Tray wants to manage Syncthing daemon startup (ie:
other than the restart and shutdown functionality provided by the web
GUI), then it should use systemctl --user or the dbus interface.

This is a problem for post cpp-utilities and post qtutilities upload of
course.


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah,

Once again, sorry for the long delay.  I was also waiting for consensus
at #998165, because source:Description does not yet appear to be
permitted by Debian Policy.

Hannah Rittich  writes:

>> For the "debian" group,

>
> 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?

Yes, I can create the first two at what will probably be round two of
the reviews, but I recommend waiting for syncthing-tray, because you may
prefer a "gbp" style repository for it, for ease of unbundling using
Files-Excluded.  Syncthing-tray also shouldn't be uploaded until the
first two packages clear the NEW queue, so there's no rush.

>> 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.

It looks to me like Martchus is bundling a subset of his fork of
upstream Syncthing.  This should be excluded from the Debian
orig.tarball.  This can be done with a script and a source-cleaning git
branch, plus merging the cleaned tag to debian/main rather than merging
the upstream tag.  Alternatively, it can be automated by using gbp's
support for Files-Excluded.

> 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.
>

The definition of "unbundling" depends on the context.  Sometimes it
means a source package split, but in this case it means deleting
Marchus' fork from Syncthing-Tray's source.  If it's unused, then this
shouldn't cause any problems at this time.  If at some point it becomes
default then it is better for the build to fail loudly rather than link
against a custom libsyncthing.  At that time the decision becomes: 1)
depend on Debian's Syncthing source and link it into the expected place,
or use a build-system config key to point Syncthing-Tray's build system
to the correct location.  2) Use a build-system config key to explicitly
disable this functionality.

> 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.
>

Ok :-) Currently progress here is blocked while waiting for team
feedback on the gopsutil v2 to v3 migration.

>> 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.

Cool, and of course, no pressure.  The main reason I propose this is
because it gives you increased autonomy (allows you to upload a set of
packages without needing a sponsor).  When I had to depend on someone
for every single upload I was frustrated an demotivated by the long
waits...because unfortunately it seems that windows of free time often
don't align, you know?

> 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.
>

Wonderful!  I'm not sure if anyone knows them by heart by the way.
Most people probably just remember where to look something up when to
confirm that someone is currently Policy-compliant or current
best-practises.

> 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 

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

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
  

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah,

Hannah Rittich  writes:

> Hi,
>
> I have created a patch set which allows to specify a prefix for the
> files and directories that are installed into system directories. These
> patches have also been accepted by the upstream author. Thus, the
> packages cpputilities and qtutilities can be installed using a more
> specific naming.
>

Wow!  I'm sorry for holding you back, this is excellent work.

> I have updated the Debian packages for cpp-utilities, qtutilities, and
> Syncthing Tray to include the patches and renamed the source packages.
> The sources are on Salsa.
>
> 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".

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.

There is no need to file an RFS (Request for Sponsorship) for these
three packages, because I've committed to reviewing and sponsoring them.

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.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Alexandre and Hannah,

So sorry for the unreasonably long delay, reply follows inline:

Alexandre Viau  writes:

> Hello Nicholas, Hannah,
>
>> Oh, and Alexandre was my first Debian contact.
>
> Aww. This is giving me Debconf nostalgia <3.
>

That's wonderful to hear <3  I look forward to meeting up again when
the covid situation allows for it :-)

>> I'm CCing you to ask if you'd appreciate help packaging deps for
>> Syncthing 1.18.2,
>
> Help for packaging new dependencies of syncthing is always welcome!
>

Sweet :-)  Distribution of labour FTW ;-)

> I have the habit of keeping a TODO list in the changelog:
> - 
> https://salsa.debian.org/go-team/packages/syncthing/-/blob/b356f757a44765ff2bb1e2a53df6d64b08dbdd25/debian/changelog
>

Nice, that's a great habit which I'm now considering adopting, and thank
you for the link!

> I am not very territorial with my TODO list. Feel free to steal as
> many tasks as you like. If it ever runs out, I am sure we can add even
> more things to it ;).
>

Haha, oh my!  I will have to wait to respond until a window when I have
more time/energy ;-)  Regrettably, both have been in short supply this
last month.

> At the time of writing this email, there are three things that need to be 
> done:
> - Bump the version of github.com/shirou/gopsutil/v3/disk in Debian
> - Package github.com/AudriusButkevicius/recli
> - Package github.com/flynn-archive/go-shlex
>

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/

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!


Humble regards,
Nicholas


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah,

I'm sorry for the unreasonably long delay. (this was a draft from
late Sept) Reply follows inline:

Hannah Rittich  writes:
>
> I think a prefix would be nicer, and I think it should not be too hard
> to add configuration name prefix switch. I would like to check if this
> is a feasible option. In case it is not too much work and the upstream
> author is willing to merge those changes, we could get a proper prefix
> to the package name. Otherwise, I would suggest to stick with a suffix
> for ease of maintenance.
>

Agreed, and I just noticed that I missed your Oct 5th email which
addresses this directly.  Once again, sorry, you deserve more timely
replies.

>> Wow!  Yes, I will definitely sponsor your work :-)  How do you feel
>> about comaintaining these packages in the "debian" group (used to be
>> called collab-maint)?
>
> I am happy to share the responsibility with a team. Would that mean any
> additional obligations for me?
>

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

>> Syncthing for Debian tends to lag behind upstream, and we'll need to 
>> ignore or remove the embedded copy of libsyncthing in Syncthing
>> Tray. In terms of long-term maintenance it looks like Syncthing Tray
>> updates will need to block for Syncthing (and its new deps) uploads.
>> I forget if I uploaded the packages or not, but at some point I
>> worked on packaging new Golang deps for Syncthing, and it wasn't as
>> difficult as I had expected.  I'll wait for Alexandre's ACK before
>> asking you if you're also interested in Golang packaging ;-)
>
> 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

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hi,

I have created a patch set which allows to specify a prefix for the
files and directories that are installed into system directories. These
patches have also been accepted by the upstream author. Thus, the
packages cpputilities and qtutilities can be installed using a more
specific naming.

I have updated the Debian packages for cpp-utilities, qtutilities, and
Syncthing Tray to include the patches and renamed the source packages.
The sources are on Salsa.

How do we proceed now?

Regards,

Hannah

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hi Nicholas,
hi Alexandre,

Am 27.09.21 um 03:27 schrieb Nicholas D Steeves:
> By the way, is this your first Debian contribution?  If so, welcome! :-)

It is, indeed, besides some bug reports. Thank you.

> So option #1 is patching the library, and not using a different package
> name at the dpkg level.  I wonder about namespacing the dependencies'
> names at the dpkg level, without patching the library?  Eg:
> src:marchus-cpp-utilities (which generates
> bin:marchus-libc++utilities5).  What do you think?  I think this would
> be less confusing to users/devs, and I feel like it's likely that there
> will be a cpp-utilities from glibc or LLVM somewhere in the future.
> What I mean by "confusing" is I really don't think that it's appropriate
> for a helper library to grab such an authoritative name, except in
> Flatpaks, and such containerised packages, of course! ;-)  If #3 ever
> becomes a real issue, I hope that our popcon stats will help convince
> upstream to DTRT.

So. I managed to get the configuration name feature that the upstream
author mentioned in the GitHub issue to work. It is possible to add
arbitrary suffixes to the library name, the include directories and the
CMake config files. This should avoid any name conflicts. The sources
are on Salsa.

I think a prefix would be nicer, and I think it should not be too hard
to add configuration name prefix switch. I would like to check if this
is a feasible option. In case it is not too much work and the upstream
author is willing to merge those changes, we could get a proper prefix
to the package name. Otherwise, I would suggest to stick with a suffix
for ease of maintenance.

> Wow!  Yes, I will definitely sponsor your work :-)  How do you feel
> about comaintaining these packages in the "debian" group (used to be
> called collab-maint)?

I am happy to share the responsibility with a team. Would that mean any
additional obligations for me?

> Syncthing for Debian tends to lag behind upstream, and we'll need to 
> ignore or remove the embedded copy of libsyncthing in Syncthing
> Tray. In terms of long-term maintenance it looks like Syncthing Tray
> updates will need to block for Syncthing (and its new deps) uploads.
> I forget if I uploaded the packages or not, but at some point I
> worked on packaging new Golang deps for Syncthing, and it wasn't as
> difficult as I had expected.  I'll wait for Alexandre's ACK before
> asking you if you're also interested in Golang packaging ;-)

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?

> Your work looks excellent, and I don't expect to find any issues, but
> I'll need to take time to carefully examine everything, do some QA
> tests, and make sure the paperwork-type stuff is all in order.  Also,
> we don't need to wait to unbundle libsyncthing before uploading
> cpp-utilities and qtutilities (ideally prefixed with 'martchus-' at
> the dpkg level), and those packages will need to migrate through the
> NEW queue before Syncthing Tray can be uploaded.
As I have mentioned above. I'll try to brush up the package with respect
to the naming. I'll keep you updated.

Regards,

Hannah

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Alexandre Viau]

Hello Nicholas, Hannah,

> Oh, and Alexandre was my first Debian contact.

Aww. This is giving me Debconf nostalgia <3.

> I'm CCing you to ask if you'd appreciate help packaging deps for
> Syncthing 1.18.2,

Help for packaging new dependencies of syncthing is always welcome!

I have the habit of keeping a TODO list in the changelog:
- 
https://salsa.debian.org/go-team/packages/syncthing/-/blob/b356f757a44765ff2bb1e2a53df6d64b08dbdd25/debian/changelog

I am not very territorial with my TODO list. Feel free to steal as
many tasks as you like. If it ever runs out, I am sure we can add even
more things to it ;).

At the time of writing this email, there are three things that need to be done:
- Bump the version of github.com/shirou/gopsutil/v3/disk in Debian
- Package github.com/AudriusButkevicius/recli
- Package github.com/flynn-archive/go-shlex

Cheers,

--
Alexandre Viau
av...@debian.org

On Sun, 26 Sept 2021 at 21:33, Nicholas D Steeves  wrote:
>
> Hi Hannah!
>
> Reply follows inline.
>
> Hi Alexandre!
>
> I'm CCing you to ask if you'd appreciate help packaging deps for
> Syncthing 1.18.2, because the working copy of Syncthing Tray that Hannah
> prepared has an embedded copy of this version's libsyncthing that should
> be unbundled.
>
> Hannah Rittich  writes:
>
> > Hey Nicholas,
> >
> > nice to hear that you are still interested.
> >
>
> Yes, definitely!  Long ago Alexandre Viau (Syncthing maintainer in
> Debian) convinced me of the usefulness of Syncthing, and a more friendly
> and convenient UI for our KDE Plasma users is *long overdue*.  Oh, and
> Alexandre was my first Debian contact.  By the way, is this your first
> Debian contribution?  If so, welcome! :-)
>
> > I have read this BTS entry, as well as the related GitHub issue [1].
> > Indeed, libc++utilities and libqtutilities are quite generic names. I
> > think, there are three ways to deal with this.
> >
> > 1.  Rename the libraries. Build a package for each one.
> > 2.  Build a syncthingtray package that includes the libraries and
> > installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use
> > of the multiple tarball support.
> > 3.  Acceptance. Keep the names as they are. Build a package for each
> > one.
> >
> > The three approaches have pros and cons.
> >
> > 1.  + More specific package name.
> > - More work: requires changing the build process and changes to
> >   upstream might be necessary.
> > - Increases long term maintenance cost, since higher complexity
> >   increases the chance of errors.
> > - Can break on updates, if upstream does not want to include the
> >   changes.
> >
> > 2.  + A hypothetical name collision is avoided.
> > o Probably less work than 1.
> > - Additional work: requires a more complicated build process.
> > - Increases long term maintenance cost, since higher complexity
> >   increases the chance of errors.
> > - Libraries cannot be used by other packages. (The author has other
> >   applications that might be of interest. They use the same
> >   libraries.)
> >
> > 3.  + Much simpler than 1. and 2.
> > + Debian package is very close to the upstream package.
> > + Low maintenance cost and more stable build process.
> > - A hypothetical name collision can occur.
> >
> > I, would suggest option 3. A name collision, at this point, is just
> > hypothetical, while the drawbacks of the other options are real.
> >
> > I have checked the package database and there is currently no name
> > collision with these package names, and the Debian Policy
> > Manual just requires a name to be unique in Debian [2], which they are.
> >
> > Furthermore, the chance of a name collision is rather small. Yes,
> > libc++utilities is a rather generic name. However, for the same reason
> > you are concerned about the name, most people will not consider to use
> > such a generic name for a project; it is actually a bold move to choose
> > such a name. In case a more important package needs this name, however,
> > the packages can still be renamed. Hence, I do not see a reason to
> > significantly increase the effort of packaging when there is no concrete
> > reason to do so at the moment. There is the saying "done is better than
> > perfect."
> >
> > If you insist, one could add a section to the README.Debian file that
> > the package will be renamed in case the name is needed by a more
> > important package.
> >
>
> So option #1 is patching the library, and not using a different package
> name at the dpkg level.  I wonder about namespacing the dependencies'
> names at the dpkg level, without patching the library?  Eg:
> src:marchus-cpp-utilities (which generates
> bin:marchus-libc++utilities5).  What do you think?  I think this would
> be less confusing to users/devs, and I feel like it's likely that there
> will be a cpp-utilities from glibc or LLVM somewhere in the future.
> What I mean by "confusing" is I really don't think that it's appropriate
> 

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah!

Reply follows inline.

Hi Alexandre!

I'm CCing you to ask if you'd appreciate help packaging deps for
Syncthing 1.18.2, because the working copy of Syncthing Tray that Hannah
prepared has an embedded copy of this version's libsyncthing that should
be unbundled.

Hannah Rittich  writes:

> Hey Nicholas,
>
> nice to hear that you are still interested.
>

Yes, definitely!  Long ago Alexandre Viau (Syncthing maintainer in
Debian) convinced me of the usefulness of Syncthing, and a more friendly
and convenient UI for our KDE Plasma users is *long overdue*.  Oh, and
Alexandre was my first Debian contact.  By the way, is this your first
Debian contribution?  If so, welcome! :-)

> I have read this BTS entry, as well as the related GitHub issue [1].
> Indeed, libc++utilities and libqtutilities are quite generic names. I
> think, there are three ways to deal with this.
>
> 1.  Rename the libraries. Build a package for each one.
> 2.  Build a syncthingtray package that includes the libraries and
> installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use
> of the multiple tarball support.
> 3.  Acceptance. Keep the names as they are. Build a package for each
> one.
>
> The three approaches have pros and cons.
>
> 1.  + More specific package name.
> - More work: requires changing the build process and changes to
>   upstream might be necessary.
> - Increases long term maintenance cost, since higher complexity
>   increases the chance of errors.
> - Can break on updates, if upstream does not want to include the
>   changes.
>
> 2.  + A hypothetical name collision is avoided.
> o Probably less work than 1.
> - Additional work: requires a more complicated build process.
> - Increases long term maintenance cost, since higher complexity
>   increases the chance of errors.
> - Libraries cannot be used by other packages. (The author has other
>   applications that might be of interest. They use the same
>   libraries.)
>
> 3.  + Much simpler than 1. and 2.
> + Debian package is very close to the upstream package.
> + Low maintenance cost and more stable build process.
> - A hypothetical name collision can occur.
>
> I, would suggest option 3. A name collision, at this point, is just
> hypothetical, while the drawbacks of the other options are real.
>
> I have checked the package database and there is currently no name
> collision with these package names, and the Debian Policy
> Manual just requires a name to be unique in Debian [2], which they are.
>
> Furthermore, the chance of a name collision is rather small. Yes,
> libc++utilities is a rather generic name. However, for the same reason
> you are concerned about the name, most people will not consider to use
> such a generic name for a project; it is actually a bold move to choose
> such a name. In case a more important package needs this name, however,
> the packages can still be renamed. Hence, I do not see a reason to
> significantly increase the effort of packaging when there is no concrete
> reason to do so at the moment. There is the saying "done is better than
> perfect."
>
> If you insist, one could add a section to the README.Debian file that
> the package will be renamed in case the name is needed by a more
> important package.
>

So option #1 is patching the library, and not using a different package
name at the dpkg level.  I wonder about namespacing the dependencies'
names at the dpkg level, without patching the library?  Eg:
src:marchus-cpp-utilities (which generates
bin:marchus-libc++utilities5).  What do you think?  I think this would
be less confusing to users/devs, and I feel like it's likely that there
will be a cpp-utilities from glibc or LLVM somewhere in the future.
What I mean by "confusing" is I really don't think that it's appropriate
for a helper library to grab such an authoritative name, except in
Flatpaks, and such containerised packages, of course! ;-)  If #3 ever
becomes a real issue, I hope that our popcon stats will help convince
upstream to DTRT.

> In any case, I have taken the liberty to create an MVP (minimum viable
> packaging) for Syncthing Tray and the required libraries [3], which can
> be improved upon.
>
> What are your thoughts?
>

Wow!  Yes, I will definitely sponsor your work :-)  How do you feel
about comaintaining these packages in the "debian" group (used to be
called collab-maint)?

Syncthing for Debian tends to lag behind upstream, and we'll need to
ignore or remove the embedded copy of libsyncthing in Syncthing Tray.
In terms of long-term maintenance it looks like Syncthing Tray updates
will need to block for Syncthing (and its new deps) uploads.  I forget
if I uploaded the packages or not, but at some point I worked on
packaging new Golang deps for Syncthing, and it wasn't as difficult as I
had expected.  I'll wait for Alexandre's ACK before asking you if you're
also interested in Golang packaging ;-)

Hannah, thank you 

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hey Nicholas,

nice to hear that you are still interested.

I have read this BTS entry, as well as the related GitHub issue [1].
Indeed, libc++utilities and libqtutilities are quite generic names. I
think, there are three ways to deal with this.

1.  Rename the libraries. Build a package for each one.
2.  Build a syncthingtray package that includes the libraries and
installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use
of the multiple tarball support.
3.  Acceptance. Keep the names as they are. Build a package for each
one.

The three approaches have pros and cons.

1.  + More specific package name.
- More work: requires changing the build process and changes to
  upstream might be necessary.
- Increases long term maintenance cost, since higher complexity
  increases the chance of errors.
- Can break on updates, if upstream does not want to include the
  changes.

2.  + A hypothetical name collision is avoided.
o Probably less work than 1.
- Additional work: requires a more complicated build process.
- Increases long term maintenance cost, since higher complexity
  increases the chance of errors.
- Libraries cannot be used by other packages. (The author has other
  applications that might be of interest. They use the same
  libraries.)

3.  + Much simpler than 1. and 2.
+ Debian package is very close to the upstream package.
+ Low maintenance cost and more stable build process.
- A hypothetical name collision can occur.

I, would suggest option 3. A name collision, at this point, is just
hypothetical, while the drawbacks of the other options are real.

I have checked the package database and there is currently no name
collision with these package names, and the Debian Policy
Manual just requires a name to be unique in Debian [2], which they are.

Furthermore, the chance of a name collision is rather small. Yes,
libc++utilities is a rather generic name. However, for the same reason
you are concerned about the name, most people will not consider to use
such a generic name for a project; it is actually a bold move to choose
such a name. In case a more important package needs this name, however,
the packages can still be renamed. Hence, I do not see a reason to
significantly increase the effort of packaging when there is no concrete
reason to do so at the moment. There is the saying "done is better than
perfect."

If you insist, one could add a section to the README.Debian file that
the package will be renamed in case the name is needed by a more
important package.

In any case, I have taken the liberty to create an MVP (minimum viable
packaging) for Syncthing Tray and the required libraries [3], which can
be improved upon.

What are your thoughts?

Regards,

Hannah

[1]: https://github.com/Martchus/cpp-utilities/issues/16

[2]:
https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name

[3]: https://salsa.debian.org/rittich/packaging-syncthingtray

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Hi Hannah,

Hannah Rittich  writes:

> Hey Nicholas,
>
> I wanted to ask whether you are still working on packaging 
> syncthingtray. If not, I would offer to do the packaging.
>
> Regards,
> Hannah

Thank you for your interest, and yes, I would appreciate a comaintainer
:-), and agree that it is better to collaborate than to work on
something alone.  Also, I freely concede that I've taken much too long
to fulfill this ITP.

How do you propose to solve the C++utilities/cpp-utilities issue?  I
worry that it's unsuitable for installation to the global/system
namespace, and I was unable to limit this using something like:

  -DCONFIGURATION_NAME:STRING="martchus" \
  -DCONFIGURATION_PACKAGE_SUFFIX:STRING="martchus" \
  -DCONFIGURATION_TARGET_SUFFIX:STRING="martchus"

I also wonder if this might be a use-case for uscan's multiple tarball
support, and if it would be better if these upstream dependencies
(c++utilities, qtutilities, and qtforkawesome) were bundled.  Ie, maybe
using uscan's multiple tarball support, plus a Debian-specific variation
of: 
  
https://github.com/Martchus/syncthingtray/blob/master/README.md#building-this-straight

?

Let me know what you think!
Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hey Nicholas,

I wanted to ask whether you are still working on packaging 
syncthingtray. If not, I would offer to do the packaging.


Regards,
Hannah

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Status update: I've deferred the question of Webkit vs Web Engine and
am working on Martchus' prerequisite libraries, starting with
"c++utilities" aka "cpputilities".  I will need to consult with
someone more how to package this for Debian such that it doesn't make
such a huge namespace grab, or at least get an ACK that this would be
ok.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
Control: tags -1 + moreinfo

Package name: syncthingtray
Version : 0.7.1
Upstream Author : Martchus 
URL : https://github.com/Martchus/syncthingtray
License : GPL-2+
Programming Lang: C++ and QML
Description : a tray applet, plasmoid, and Dolphin integration for Syncthing

Long descriptions have yet to be written, because I haven't yet
decided if we should also provide a light variant that doesn't depend
on Qt Webkit or Web Engine.  The source package would need to be built
twice to do this, and I'd like to target this in the future rather
than right now.  When the plasmoid is declared stable I think that it
might be reasonable for it to provide syncthingtray and conflict with
it, so that syncthingtray can provide the light version.  This might
require a third binary package that contains only a few shared files.
Please let me know what you think!

Here is my WIP copy:

Package: syncthingtray
...
Description: Tray applet for Syncthing
 This package provides quick access to the most frequently used
 Syncthing features. It cannot yet add or remove shared folders or
 manage Device IDs by itself; however, it provides access to the
 official web UI from its system tray icon using Qt WebEngine.
 .
 It enables Syncthing notifications via Qt if possible and falls back
 to D-Bus notifications if necessary, shows the status of the
 Syncthing systemd unit, and can start or stop Syncthing using this
 unit. Of course the tray application can be configured to
 automatically start Syncthing.
 .
 Additionally it features a simple command line utility called
 syncthingctl that can check Syncthing status, trigger
 rescan/pause/resume/restart, and wait for idle before doing
 something.

Package: plasma-syncthing
...
Description: Dolphin integration for Syncthing
 This package contains a KIO plugin that displays the synchronisation
 status of a directory and makes the following Syncthing actions
 available in Dolphin:
   * Rescan selected items
   * Rescan entire Syncthing directory
   * Pause/resume Syncthing directory
 .
 It also contains an experimental implementation of syncthingtray
 as a KDE Plasma 5 Plasmoid rather than as a tray application.

I believe that this package is useful because deeper desktop
integration makes it easier to transition from Dropbox to Syncthing.
One of the reasons I'd like to start with KDE integration is because
I'm disappointed with how poorly Dropbox is integrated into it.

I will start using syncthingtray as soon as I've packaged it, and have
tagged this bug moreinfo until I've had a chance to thoroughly test
it.  To the best of my knowledge no existing package provides this
functionality for Syncthing; however, it is similar to dropboxd's tray
applet.

If this proposal is well received then collab-maint seems most
appropriate, otherwise I'll probably maintain it on the KDE Addons
Team.  I will need a sponsor for the initial upload.

Sincerely,
Nicholas