* Package name    : screencloud
  Version         : 1.1.6
  Upstream Author : Olav Sortland Thoresen <olav.s.th@gmail.com>
* URL             : http://www.screencloud.net (online service)
http://www.github.com/olav-st/screencloud (source)
* License         : GPL2 or any later version
  Programming Lang: C++ / Qt
  Description     : easy to use screenshot tool

Screencloud allows taking a screenshot of the full screen, a window or a
manually selected screen region. It offers various advanced settings like
adding a delay before taking the screenshot, hotkeys, and optionally sharing
the screenshot through (S)FTP, the screencloud online service or similar
services.


Relevant information (similar packages, reason for RFP etc.):

Shutter offers the same features and quite a bit more. I'm a little concerned
about the future of shutter though, as it still depends on Gtk2 and other
gnome2 libraries and there's not much activity in the usptream bzr repository.
At the same time, screencloud still depends on Qt4. There's some activity in
the upstream git repo though, and I imagine porting from Qt4 to Qt5 is easier
than porting from Gtk2 to Gtk3 and libgnome2-* to whatever the new libraries
are called.

While screencloud is less feature-rich than shutter, it has a nicer user
interface and is less overwhelming for the average user. I prefer it over
shutter and would therefore love to see it in Debian.

Caveats:

- Screencloud apparently downloads a list of sharing plugins and offers them
  for "installation" on first start. This is almost certainly not ideal for
  packaging in Debian, it probably has security implications as well. This
  functionality should probably be patched out of the eventual Debian package
  and desired plugins should be included with the package.

- Likewise, there's a check for updates in the preferences dialog and an
  automatic update check. It should probably be patched out of the package,
  too.

- Since the tool was created by the owner of the screencloud online service, it
  advertises creating an account there to share screenshots. While this seems
  to be completely optional and the tool is open source and very useful even
  without having an account, it may or may not conflict with some Debian
  policies.

- There might be more caveats related to the "proprietary open source" nature
  of this software.

Hello again,

I actually tried to do this myself as a fun little "improve Debian
packaging skills" project, and it kind-of works already. It requires two
fixes for the pythonqt package (patches filed).

There is a github repository where plugins are downloaded from by
screencloud, and I just added the master HEAD of that repository as a
second upstream tarball for the package. This appears not to be 100%
supported by git-buildpackage, but I think I managed to work my way
around the limitations (see below).

One issue is that those plugins have bundled source copies of python
libraries, which in turn have source copies of other python libraries
(the .tar.xz is 1.4 MB). For some of those plugins the license situation
might be dangerous (i.e. missing NOTICES file and missing LICENSE file
for an Apache 2.0 project, only the source files indicate the license
and sure enough, it looks like the source directory was probably ripped
out of the library github repo).

Also, I'm not sure if PNG is the correct "source" format for all of the
included image files in the orig tarball. Some of them are screenshots,
so that's hopefully DFSG-ok, but a few look like the preferred form for
modification might not be PNG. Just to clarify, in order for the package
to be okay for Debian, those files must be removed from the orig
tarball? It's not enough to not add them to the binary deb package?

Since upstream doesn't really use tarballs (they are only created by
github on-the-fly as a side effect of tagging), I fetched the upstream
tag to a local "upstream" branch and the upstream screencloud-plugins
master branch to a local "upstream-plugins" branch. I then branched
"master" off of "upstream", did the debian work there and added the
"upstream-plugins" branch as a "./plugins" git-subtree to "master". I
also use the "single-debian-patch" option. I added a script to prepare
an "orig-plugins" tarball from the "upstream-plugins" branch. Now, when
I run git-buildpackage, it generates an orig tarball from the "upstream"
branch and the debian tarball containing a patch with differences
between master and upstream[-plugins]. Is that okay, since there is
nothing like an upstream "pristine" tarball? Only pristine git tags, and
in the case of the -plugins repo, not even tags. Git master HEAD seems
to be the current plugins "release" at all times.

I think I'll upload the package to an Ubuntu PPA and a public git repo
once I'm happy with it, so someone who likes the software can pick it up
and improve the license/dfsg/general Debian policy situation. I'm not
sure what exactly needs to be done in that area and how to dfsg-modify
my way of keeping upstream sources in branches instead of tarballs.
Maybe just add commits to those branches? Hm. I've already fixed all the
lintian warnings, but the man page might need some language help from
someone with proper English skills. :-)

Cheers,
Florian