Project

General

Profile

Feature #6507

Package our OpenPGP applet for Debian and maintain it there

Added by intrigeri over 5 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

QA Check:
Feature Branch:
Type of work:
Debian
Blueprint:
Starter:
Yes
Affected tool:
OpenPGP Applet

Description

This piece of software could be useful outside of Tails.

The code currently lives in config/chroot_local-includes/usr/local/bin/gpgApplet in the main Tails Git repository, which is far from ideal for a packager.

If someone wants to tackle this, intrigeri will be glad to take this script out of this repo, and to turn it into a regular independent upstream project.


Related issues

Blocked by Tails - Bug #7968: Tails OpenPGP Applet can't clearsign text including non-ASCII characters Resolved 09/28/2014

History

#1 Updated by intrigeri about 5 years ago

  • Type of work changed from Code to Debian

#2 Updated by nodens almost 5 years ago

  • Assignee set to nodens

Hi,

I'd be happy to help (I'll need a sponsor once the package is made to upload it to debian, though).

What's the status ? I see this is "50% done"...

#3 Updated by intrigeri almost 5 years ago

  • % Done changed from 50 to 0

#4 Updated by intrigeri almost 5 years ago

I'd be happy to help

Awesome! I now realize that this ticket's title is kinda weak: it should really be "Package our OpenPGP applet for Debian and maintain it there". Are you up to maintain the package too, after the initial upload is done? We can possibly team-maintain it, by the way, if you're interested.

(I'll need a sponsor once the package is made to upload it to debian, though).

I can act as a fallback on this one, but if you can find another sponsor, then it's even better for Tails :)
I can ask around for potential sponsors, once there's something that's worth reviewing.

What's the status ?

I don't think anyone has starting working on it.

I see this is "50% done"...

That was a mistake, fixed.

#5 Updated by nodens almost 5 years ago

intrigeri wrote:

I'd be happy to help

Awesome! I now realize that this ticket's title is kinda weak: it should really be "Package our OpenPGP applet for Debian and maintain it there". Are you up to maintain the package too, after the initial upload is done? We can possibly team-maintain it, by the way, if you're interested.

That's how I understood it. Team maintainance seems good to me, I've some experience with packaging but that would be my first official package (beside backports) for a long time. I'm not really a dev, but I know enough perl to find my way around. I even have some ideas to improve it beside packaging but I'm not sure my perl/gtk skills are up to it, we'll see :)

(I'll need a sponsor once the package is made to upload it to debian, though).

I can act as a fallback on this one, but if you can find another sponsor, then it's even better for Tails :)
I can ask around for potential sponsors, once there's something that's worth reviewing.

Great !

What's the status ?

I don't think anyone has starting working on it.

I see this is "50% done"...

That was a mistake, fixed.

I guess the first task would be to "package" this outside the main tail repository (as a proper perl package with Makefile.PL so dh-make-perl will be happy). How do you want to proceed ?

#6 Updated by intrigeri almost 5 years ago

  • Subject changed from Package our OpenPGP applet for Debian to Package our OpenPGP applet for Debian and maintain it there

#7 Updated by intrigeri almost 5 years ago

That's how I understood it.

Great :) Retitled accordingly.

I guess the first task would be to "package" this outside the main tail repository
(as a proper perl package with Makefile.PL so dh-make-perl will be happy). How do you
want to proceed ?

Yes, exactly, the first step is to turn this lone file into a full-blown upstream project. We can create a Git repo for you to this end, so please:

  1. send your OpenPGP public key to
  2. wait for a ACK that it's been imported into the list's keyring
  3. send your SSH pubkey to the same address, in an OpenPGP-signed email; also, tell us what nickname you want to be displayed on the cgit interface / in the URLs

#8 Updated by nodens almost 5 years ago

  • % Done changed from 0 to 20

New git repo is up, real work started.

It will involve some renaming (openpgp-applet / OpenPGP_Applet) and small code modifications (renaming, adjust meta-information and change hardcoded pixmaps path to use File::ShareDir).

#9 Updated by nodens almost 5 years ago

  • % Done changed from 20 to 50
  • Feature Branch set to devel

The code is now usable as an upstream project :

- import code from tails
- Module::Install packaging (Makefile.PL)
- no more hardcoded paths for pixmaps (File::ShareDir)

TBD soon :
add some missing meta-information directly in the script, adjust POD data, add license file and some documentation (install, readme with pointer to tails wiki).

Then the debian packaging starts, it should be a straightforward task.

Cheers,

#10 Updated by nodens almost 5 years ago

  • Feature Branch deleted (devel)

#11 Updated by intrigeri almost 5 years ago

Then the debian packaging starts, it should be a straightforward task.

It would be good if you used the same git-buildpackage workflow as 1. the pkg-perl team uses; and 2. we use for tails-persistence-setup and other Perl code we have. Standardizing such workflows is helpful for other contributors :)

#12 Updated by nodens almost 5 years ago

Packaging done, with license information and documentation. Maybe some review would be in order now ?

We need to discuss the versioning before packaging it for debian : I arbitrarily choose 0.9 as initial version.

Maybe we could simply follow Tails releases, but it would mean changing the version even if there is no change, which seem silly.

I'll look into the git-buildpackage workflow until then.

#13 Updated by nodens almost 5 years ago

  • % Done changed from 50 to 80

#14 Updated by nodens almost 5 years ago

  • % Done changed from 80 to 90

#15 Updated by nodens almost 5 years ago

Package available for review on mentors : http://mentors.debian.net/package/openpgp-applet

#16 Updated by intrigeri almost 5 years ago

  • Assignee changed from nodens to intrigeri
  • Target version set to Tails_1.2
  • % Done changed from 90 to 50
  • QA Check set to Ready for QA

Great! I'll take a look. Lowering a bit the "% Done" figure, since 90% leaves no room at all for whatever improvement the initial reviews will deem necessary.

#17 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to nodens
  • QA Check changed from Ready for QA to Dev Needed

Here's a first (quick) review. Great work! All that follows is mostly nitpicking. Some bits of it are important, still.

  1. I think you forgot to push the pristine-tar branch.
  2. git mv script bin would make this tree more similar to our other Perl ones, which eases maintenance and collaboration
  3. unclear licensing; I suggest to license all this under GPL-1/Artistic (customary in the Perl community), and to document the bits that are licensed otherwise by the corresponding copyright holders
    • some included images are apparently under CC by-sa 2.0, which is documented nowhere
    • README says GPL-1/Artistic
    • LICENSE is GPL-3
    • the packaging is GPL-2+, which makes things even more confusing; how about licensing it under the same terms as the rest of the code?
  4. scripts/openpgp-applet has a COPYRIGHT section, that is about licensing, and not about copyright
  5. It would be good to port this to GTK3, but that's obviously not a blocker :)
  6. If you don't want to use Dist::Zilla, then I don't think we really need to manually maintain a $VERSION variable in the script: we'll have to manually update it in META.yml anyway. (Note that in our other Perl things, Dist::Zilla retrieves the version from a script or module, and generates META.* from that. But maybe M::I's all_from does the same? If so, why do we need to maintain duplicated info in Makefile.PL and in META.yml?) Anyway, I'd rather see you use Dist::Zilla, to keep all these artifacts out of the master branch, and auto-generated when releasing a tarball, if you don't mind.
  7. Shipping Module::Install in Git, really?
  8. Upstream GnuPG::Interface has taken my branch that migrates it to Moo. So, we could replace Any::Moose with Moo in OpenPGP_Applet::GnuPG::Interface, that would make the dependency tree way smaller, and the memory footprint a bit smaller too. For an example of subclassing G::I with Moo, see the parcimonie source code in testing/sid.
  9. Do the paths generated by File::ShareDir respect the FHS and Debian policy?
  10. You'll want to run a spell-checker on the README.
  11. "Tails", not "tails" :)
  12. Was the resulting package tested on current Debian unstable?
  13. The build-dep on perl (>= 5.15.2) will make backporting more painful than it should be. Why is that?
  14. Please add Vcs-Git and Vcs-Browser control fields.
  15. debian/copyright leads me to believe we want to upload this to CPAN. Is it the case?
  16. I think that there should be an upstream Changelog (detected by Lintian). I recommend having Dist::Zilla auto-generated it from Git.
  17. We'll need to find a place to host upstream tarballs, and then add a debian/watch.
  18. I doubt that using a name at the first level of the Perl modules namespace is the best we can do. Maybe instead use the Crypt namespace?

I realize quite a few of the aforementioned problems come straight from the Tails Git repo. I'm sorry about it. Now, when it comes to uploading stuff to Debian, we have to be a bit stricter.

Thanks!

#18 Updated by nodens almost 5 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from nodens to intrigeri
  • QA Check changed from Dev Needed to Info Needed

intrigeri wrote:

Here's a first (quick) review. Great work! All that follows is mostly nitpicking. Some bits of it are important, still.

  1. I think you forgot to push the pristine-tar branch.

Ooops. Corrected.

  1. git mv script bin would make this tree more similar to our other Perl ones, which eases maintenance and collaboration

That's the M::I convention. Moved.

  1. unclear licensing; I suggest to license all this under GPL-1/Artistic (customary in the Perl community), and to document the bits that are licensed otherwise by the corresponding copyright holders
    • some included images are apparently under CC by-sa 2.0, which is documented nowhere

Could you point which ? Or at least tell me how to check myself ?

  • README says GPL-1/Artistic
  • LICENSE is GPL-3

Actually it also has artistic. I wanted to make it gpl-1 + artistic, I picked the wrong file. Corrected.

  • the packaging is GPL-2+, which makes things even more confusing; how about licensing it under the same terms as the rest of the code?

Fine by me. Changed in git.

  1. scripts/openpgp-applet has a COPYRIGHT section, that is about licensing, and not about copyright

Corrected.

  1. It would be good to port this to GTK3, but that's obviously not a blocker :)

I'm not sure I'm up to it, since I'm not familiar with GTK3, it would need quite a bit of reading. I agree, though.

  1. If you don't want to use Dist::Zilla, then I don't think we really need to manually maintain a $VERSION variable in the script: we'll have to manually update it in META.yml anyway. (Note that in our other Perl things, Dist::Zilla retrieves the version from a script or module, and generates META.* from that. But maybe M::I's all_from does the same? If so, why do we need to maintain duplicated info in Makefile.PL and in META.yml?) Anyway, I'd rather see you use Dist::Zilla, to keep all these artifacts out of the master branch, and auto-generated when releasing a tarball, if you don't mind.

M::I does just that. The META.yml is generated by it from the code. I can switch to Dist::Zilla, but I don't have any experience with it, so it may takes a little time. I wish you suggested it sooner, though... Fortunately it seems simple to migrate from M::I to Dist::Zilla. On my TODO list.

  1. Shipping Module::Install in Git, really?

Since it ends up in the tarball (that's the M::I way of doing things, to insure compatibility ), I thought it was best to let it in git to avoid strange thing due to contributors using a different M::I version. Moot point if using D::Z, anyway.

  1. Upstream GnuPG::Interface has taken my branch that migrates it to Moo. So, we could replace Any::Moose with Moo in OpenPGP_Applet::GnuPG::Interface, that would make the dependency tree way smaller, and the memory footprint a bit smaller too. For an example of subclassing G::I with Moo, see the parcimonie source code in testing/sid.

Interesting. I'll look into it.

  1. Do the paths generated by File::ShareDir respect the FHS and Debian policy?

Unclear. I did some research before using it, as it doesn't seem really compliant, but didn't find anything that goes against using these paths. Other packages do use it (@padre for instance), so I guess this is OK.
The alternative is to use some custom build magic to get images installed in /usr/share/pixmaps (at the cost of some portability, probably).

  1. You'll want to run a spell-checker on the README.

Yup. Done.

  1. "Tails", not "tails" :)

One has slipped... I did pay attention but not enough ;)

  1. Was the resulting package tested on current Debian unstable?

Of course : I'm using it right now on my laptop, which happens to run sid and is up to date.

  1. The build-dep on perl (>= 5.15.2) will make backporting more painful than it should be. Why is that?

I think so, too, but as ExtUtils::MakeMaker is included in Perl after 5.12.2, dh-make-perl did put this requirement to avoid the added dependancy. Moot point if migrating to D::Z.

  1. Please add Vcs-Git and Vcs-Browser control fields.

Done.

  1. debian/copyright leads me to believe we want to upload this to CPAN. Is it the case?

Nope. Leftover from dh-make-perl, removed.

  1. I think that there should be an upstream Changelog (detected by Lintian). I recommend having Dist::Zilla auto-generated it from Git.

That would be great, I'll be looking into it. Any pointers ?

  1. We'll need to find a place to host upstream tarballs, and then add a debian/watch.

I actually removed the watch file since I couldn't figure where the tarball would/should be hosted.
How about using dl.amnesia.boum.org like Tails' isos ? Sounds feasible ?
If it is to be a standalone, upstream project, however, it should have its own page, even minimal, with changelog, version history etc, though this could all be on Tails' website.

  1. I doubt that using a name at the first level of the Perl modules namespace is the best we can do. Maybe instead use the Crypt namespace?

Crypt sounds right, I'm not sure how it impacts the packaging. I'd need to test a bit, good candidate for a feature branch ;)

I realize quite a few of the aforementioned problems come straight from the Tails Git repo. I'm sorry about it. Now, when it comes to uploading stuff to Debian, we have to be a bit stricter.

Agreed, that's what I signed for after all... I won't be as available in the future as I was this week, though. Some of these might take some time.

#19 Updated by nodens almost 5 years ago

Arrgh. Replying inline messed the numbering and it didn't show in preview, sorry about that.

To make it short :
1-5,10-12,14-15 -> done.
See my answer for 6-9,13,16-18.

#20 Updated by intrigeri almost 5 years ago

  • Related to Feature #7711: Port the OpenPGP applet to GTK+ 3 added

#21 Updated by intrigeri almost 5 years ago

First, congrats for all the "done" and "corrected" bits!

some included images are apparently under CC by-sa 2.0, which is documented nowhere

Could you point which ? Or at least tell me how to check myself ?

I discovered those by running git grep -i license as part of my standard initial review process.

  1. It would be good to port this to GTK3, but that's obviously not a blocker :)

I'm not sure I'm up to it, since I'm not familiar with GTK3, it would need quite a bit of reading. I agree, though.

Filed #7711, then.

M::I does just that. The META.yml is generated by it from the code.

Ah, then META.yml shouldn't live in the master Git branch, then, right? Instead, it would be generated at release time, be part of the upstream tarball, and as such imported into the upstream branch, and in turn into the debian one.

I can switch to Dist::Zilla, but I don't have any experience with it, so it may takes a little time.

No big hurry. This would be a great bonus, but it can wait, and is no blocker to the initial upload IMO.

I wish you suggested it sooner, though...

I'm pretty sure I've mentioned / suggested it on IRC a few days ago. Possibly under the "dzil" name, though, and probably as an off-topic point in an unrelated discussion, without stressing it out enough. I'm sorry.

Shipping Module::Install in Git, really?

Since it ends up in the tarball (that's the M::I way of doing things, to insure compatibility ), I thought it was best to let it in git to avoid strange thing due to contributors using a different M::I version.

Ah, I see. So we basically have to choose between:

  • If we drop these files from Git: taking the risk that the tarball for release N bundles M::I version X, while the tarball for release N+1 bundles M::I version Y (!= X).
  • If we keep these files in Git: taking the risk that we don't think of updating it regularly enough, and then hit incompatibilities between the old bundled version of M::I and the rest of the (evolving) Perl environment.

I'm not sure which one of those is worse. What do respected, well-known CPAN dists do? (It would be good to look at dists that are actually collective work, and are thus exposed to the first potential problem described above.)

Note that for all our other Perl things, we've never bundled M::I in the master Git branch, and I don't remember it causing any problem.

Do the paths generated by File::ShareDir respect the FHS and Debian policy?

Unclear. I did some research before using it, as it doesn't seem really compliant, but didn't find anything that goes against using these paths. Other packages do use it (@padre for instance), so I guess this is OK.

OK. I see no open bug about it against the padre package in Debian, so let's ignore it for now.

You'll want to run a spell-checker on the README.

Yup. Done.

Great. Also: s/gnome/GNOME/.

Was the resulting package tested on current Debian unstable?

Of course : I'm using it right now on my laptop, which happens to run sid and is up to date.

\o/

What desktop environment are you testing in?

(By the way, IIRC this program is not really an applet: we use a notification icon, which is Bad™. E.g. under GNOME Shell, I guess the icon appears in the notification area, which is Wrong™. A later step would be to convert it to a real applet, with a backend and some JS + dbus bits to work fine in GNOME3. Ask Alan if you want more info on that one.)

The build-dep on perl (>= 5.15.2) will make backporting more painful than it should be. Why is that?

I think so, too, but as ExtUtils::MakeMaker is included in Perl after 5.12.2, dh-make-perl did put this requirement to avoid the added dependancy.

I think the right way to do it, then, is to use a dependency like perl (>= 5.15.2) | $PACKAGE, replacing $PACKAGE with the package that shipped ExtUtils::MakeMaker before.

Please add Vcs-Git and Vcs-Browser control fields.

Done.

There should be only one Vcs-Git field, and I think it should be the HTTPS one:

Vcs-Git: https://git-tails.immerda.ch/nodens/openpgp-applet/ -b debian

debian/copyright leads me to believe we want to upload this to CPAN. Is it the case?

Nope. Leftover from dh-make-perl, removed.

I cannot see this change.

I think that there should be an upstream Changelog (detected by Lintian). I recommend having Dist::Zilla auto-generated it from Git.

That would be great, I'll be looking into it. Any pointers ?

Sure: https://git-tails.immerda.ch/iuk/tree/dist.ini#n93

We'll need to find a place to host upstream tarballs, and then add a debian/watch.

I actually removed the watch file since I couldn't figure where the tarball would/should be hosted.
How about using dl.amnesia.boum.org like Tails' isos ? Sounds feasible ?

Could be done, but only Tails release managers can upload there.

If it is to be a standalone, upstream project, however, it should have its own page,
even minimal, with changelog, version history etc, though this could all be on
Tails' website.

I'd rather not add (more) binary blobs to the main Tails Git repo, and that's where the website sources live.

The cheapest way to do it initially would be to consider that the Tails APT repo is the canonical place where the .orig.tar.gz files live: this way, whenever you/I/someone tags an upstream release, and we build and upload a package to our APT repo, the upstream tarball is uploaded as well without any special effort. Once the package is in Debian, the Debian archive can be used this way too. However, I doubt we can have a watch file track this, and it's a bit ugly.

Longer-term, we'll want a minimal dedicated homepage for this project, that whoever does the upstream work on can upload files to. I say let's wait and see how the project is shaped, who's working on it upstream, before we go that far.

Fair enough?

I doubt that using a name at the first level of the Perl modules namespace is the
best we can do. Maybe instead use the Crypt namespace?

Crypt sounds right, I'm not sure how it impacts the packaging. I'd need to test
a bit, good candidate for a feature branch ;)

Yes :)

Also:

#22 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to nodens
  • QA Check changed from Info Needed to Dev Needed

#23 Updated by nodens almost 5 years ago

intrigeri wrote:

some included images are apparently under CC by-sa 2.0, which is documented nowhere

Could you point which ? Or at least tell me how to check myself ?

I discovered those by running git grep -i license as part of my standard initial review process.

Oh, OK. The SVG files, of course. I assume the PNG files are generated from the SVG, so I set the license for all. However, there is an issue with CC-BY-SA 2.0 : it is not considered DFSG-compatible... Do we own the copyright for the pixmaps ? If we do, we could relicense it under the 3.0 version, which is DFSG compatible. If we don't, we need to make new icons (or upload to non-free). They seem based on an old version of the tango theme. Remaking them using a more recent one would work (tango is now public domain). I'm not really qualified for that, I hope some contributors are :)

M::I does just that. The META.yml is generated by it from the code.

Ah, then META.yml shouldn't live in the master Git branch, then, right? Instead, it would be generated at release time, be part of the upstream tarball, and as such imported into the upstream branch, and in turn into the debian one.

I can switch to Dist::Zilla, but I don't have any experience with it, so it may takes a little time.

No big hurry. This would be a great bonus, but it can wait, and is no blocker to the initial upload IMO.

I'll make a feature/DistZilla branch. Meanwhile, removing META.

Since it ends up in the tarball (that's the M::I way of doing things, to insure compatibility ), I thought it was best to let it in git to avoid strange thing due to contributors using a different M::I version.

Ah, I see. So we basically have to choose between:

  • If we drop these files from Git: taking the risk that the tarball for release N bundles M::I version X, while the tarball for release N+1 bundles M::I version Y (!= X).
  • If we keep these files in Git: taking the risk that we don't think of updating it regularly enough, and then hit incompatibilities between the old bundled version of M::I and the rest of the (evolving) Perl environment.

I'm not sure which one of those is worse. What do respected, well-known CPAN dists do? (It would be good to look at dists that are actually collective work, and are thus exposed to the first potential problem described above.)

Note that for all our other Perl things, we've never bundled M::I in the master Git branch, and I don't remember it causing any problem.

I didn't find a dist that matches all these with a quick research. I don't think using a different Module::Install version between release is too big a deal, as there is nothing special in the Makefile.PL, no custom code, etc. Not including Inc/ seems the best for now. I removed it from the master branch (will move to D::Z anyway).

You'll want to run a spell-checker on the README.

Yup. Done.

Great. Also: s/gnome/GNOME/.

Ooops again. There was one left.

Was the resulting package tested on current Debian unstable?

Of course : I'm using it right now on my laptop, which happens to run sid and is up to date.

\o/

What desktop environment are you testing in?

GNOME Shell.

(By the way, IIRC this program is not really an applet: we use a notification icon, which is Bad™. E.g. under GNOME Shell, I guess the icon appears in the notification area, which is Wrong™. A later step would be to convert it to a real applet, with a backend and some JS + dbus bits to work fine in GNOME3. Ask Alan if you want more info on that one.)

There are no applets in GNOME3, only extensions ;)
I think that's the correct way to go for this program (though I don't know JS and have no experience with dbus services). I actually thought about it before beginning working on the packaging, but didn't think I could do anything usable quickly.

The workaround I use is to use the TopIcons extension (https://extensions.gnome.org/extension/495/topicons/) to move all legacy tray icons to the top panel. This is a good solution from a user point of view, since it Just Works®.

The build-dep on perl (>= 5.15.2) will make backporting more painful than it should be. Why is that?

I think so, too, but as ExtUtils::MakeMaker is included in Perl after 5.12.2, dh-make-perl did put this requirement to avoid the added dependency.

I think the right way to do it, then, is to use a dependency like perl (>= 5.15.2) | $PACKAGE, replacing $PACKAGE with the package that shipped ExtUtils::MakeMaker before.

Agreed. When I tried to search for it, though, I couldn't find this package. It didn't seem to exist in wheezy. It is not really an issue because everything needed by module::install is in inc/ : this is a quirk of the dependency detection by dh-make-perl (you usually don't ship a module you require in your code).
I changed the dependency to the perl >= 5.10

Please add Vcs-Git and Vcs-Browser control fields.

Done.

There should be only one Vcs-Git field, and I think it should be the HTTPS one:

I misinterpreted the More than one different VCS may be specified for the same package in the Debian Policy. Corrected.

debian/copyright leads me to believe we want to upload this to CPAN. Is it the case?

Nope. Leftover from dh-make-perl, removed.

I cannot see this change.

Oops. Corrected.

I think that there should be an upstream Changelog (detected by Lintian). I recommend having Dist::Zilla auto-generated it from Git.

That would be great, I'll be looking into it. Any pointers ?

Sure: https://git-tails.immerda.ch/iuk/tree/dist.ini#n93

We'll need to find a place to host upstream tarballs, and then add a debian/watch.

I actually removed the watch file since I couldn't figure where the tarball would/should be hosted.
How about using dl.amnesia.boum.org like Tails' isos ? Sounds feasible ?

Could be done, but only Tails release managers can upload there.

If it is to be a standalone, upstream project, however, it should have its own page,
even minimal, with changelog, version history etc, though this could all be on
Tails' website.

I'd rather not add (more) binary blobs to the main Tails Git repo, and that's where the website sources live.

The cheapest way to do it initially would be to consider that the Tails APT repo is the canonical place where the .orig.tar.gz files live: this way, whenever you/I/someone tags an upstream release, and we build and upload a package to our APT repo, the upstream tarball is uploaded as well without any special effort. Once the package is in Debian, the Debian archive can be used this way too. However, I doubt we can have a watch file track this, and it's a bit ugly.

Quite. This could work as a short-term solution, however.

Longer-term, we'll want a minimal dedicated homepage for this project, that whoever does the upstream work on can upload files to. I say let's wait and see how the project is shaped, who's working on it upstream, before we go that far.

Fair enough?

How about using an external services for tarballs meanwhile ? They'd need to be signed, of course. We could even import the upstream branch on github and use their tarball generation system, but then there is the signature issue. It wouldn't be an issue for the debian packaging, since the release process would involve signed tags and no external tarballs, though.

Also:

  • OpenPGP_Applet is a fine name for computer consumption, but I think that "OpenPGP Applet" is a better one for humans', e.g. in the package description.

I corrected this where it seemed to make sense (description in POD and debian package).

I'll wait for your input (especially about the license stuff) before making a new release.

By the way, should I sign the release tags with my key ?

Thanks for your comments !

#24 Updated by nodens almost 5 years ago

  • Assignee changed from nodens to intrigeri
  • QA Check changed from Dev Needed to Info Needed

#25 Updated by nodens almost 5 years ago

  • Related to Bug #7406: OpenPGP Applet system tray icon should be themable added

#26 Updated by intrigeri almost 5 years ago

Oh, OK. The SVG files, of course. I assume the PNG files are generated from the SVG, so I set the license for all.

No idea. I think Alan added the PNG files as part of his work on the Windows camouflage, so you'll want to ask him () where these files come from.

However, there is an issue with CC-BY-SA 2.0 : it is not considered DFSG-compatible...

Ooops. I think these files were initially imported from seahorse-plugins 2.30.1-3 (commit df9d7209). I've checked its source, and it indeed lacks provision for the license these files are under.

Do we own the copyright for the pixmaps ?

We don't.

Note that rgrep 'by-sa/2\.0' /usr/share/icons/*/scalable, on my sid system, shows a lot of files, shipped by 6 different packages (gitg, gnome-codec-install, gnome-themes-extras, liferea-data, network-manager-gnome and soundconverter).

Is there's a distro-wide effort to report such DFSG violations and/or to ask the copyright holders to relicense their work under CC-BY-SA 3.0?

If we don't, we need to make new icons (or upload to non-free). They seem based on an old version of the tango theme. Remaking them using a more recent one would work (tango is now public domain). I'm not really qualified for that, I hope some contributors are :)

I do hope we can have these icons relicensed, and would rather investigate it first.

Not including Inc/ seems the best for now. I removed it from the master branch (will move to D::Z anyway).

Great.

What desktop environment are you testing in?

GNOME Shell.

Great: this will likely be our target platform for Tails/Jessie (either the Real Thing™, or the set of extensions that are called the Classic mode in GNOME ~3.10+).

I think that's the correct way to go for this program (though I don't know JS and have no experience with dbus services). I actually thought about it before beginning working on the packaging, but didn't think I could do anything usable quickly.

Yes, this can wait.

The workaround I use is to use the TopIcons extension (https://extensions.gnome.org/extension/495/topicons/) to move all legacy tray icons to the top panel. This is a good solution from a user point of view, since it Just Works®.

OK, great. Let's reconsider this once we have decided whether we ship Classic mode or the Real™ Shell.

Agreed. When I tried to search for it, though, I couldn't find this package. It didn't seem to exist in wheezy. It is not really an issue because everything needed by module::install is in inc/ : this is a quirk of the dependency detection by dh-make-perl (you usually don't ship a module you require in your code). I changed the dependency to the perl >= 5.10

OK, good.

The cheapest way to do it initially would be to consider that the Tails APT repo is the canonical place where the .orig.tar.gz files live: this way, whenever you/I/someone tags an upstream release, and we build and upload a package to our APT repo, the upstream tarball is uploaded as well without any special effort. Once the package is in Debian, the Debian archive can be used this way too. However, I doubt we can have a watch file track this, and it's a bit ugly.

Quite. This could work as a short-term solution, however.

Longer-term, we'll want a minimal dedicated homepage for this project, that whoever does the upstream work on can upload files to. I say let's wait and see how the project is shaped, who's working on it upstream, before we go that far.

Fair enough?

How about using an external services for tarballs meanwhile ? They'd need to be signed, of course.

Short-term, an Alioth project seems to be the fastest and cheapest solution to this problem.
Longer term, I think we can quite easily (and quickly) get an ikiwiki set up on openpgp-applet.boum.org.

By the way, should I sign the release tags with my key ?

Yes, please :)

Thanks for your comments !

Thanks a lot for your work! It's a real pleasure to work with you :)

#27 Updated by nodens almost 5 years ago

intrigeri wrote:

Do we own the copyright for the pixmaps ?

We don't.

Note that rgrep 'by-sa/2\.0' /usr/share/icons/*/scalable, on my sid system, shows a lot of files, shipped by 6 different packages (gitg, gnome-codec-install, gnome-themes-extras, liferea-data, network-manager-gnome and soundconverter).

Is there's a distro-wide effort to report such DFSG violations and/or to ask the copyright holders to relicense their work under CC-BY-SA 3.0?

None that I know of currently.
Regarding those packages, I suspect that the maintainer might not be aware that the images are licensed differently, because it is not advertised by upstream.

From what I can see, this is usually considered as a Serious bug by Debian. Such images should be removed or replaced, or the package moved to non-free.

Short-term, an Alioth project seems to be the fastest and cheapest solution to this problem.
Longer term, I think we can quite easily (and quickly) get an ikiwiki set up on openpgp-applet.boum.org.

OK
(I won't create the Alioth project since it should be created by a DD).

Thanks for your comments !

Thanks a lot for your work! It's a real pleasure to work with you :)

Pleasure's mine :)

#28 Updated by intrigeri almost 5 years ago

Is there's a distro-wide effort to report such DFSG violations and/or to ask the copyright holders to relicense their work under CC-BY-SA 3.0?

None that I know of currently.
Regarding those packages, I suspect that the maintainer might not be aware that the images are licensed differently, because it is not advertised by upstream.

I think so, too.

From what I can see, this is usually considered as a Serious bug by Debian.

Yes. Probably ignored for Wheezy, and quite possibly ignored for Jessie due to the imminent freeze and the fact it's not a new problem, but still.

Care to email debian-devel@ about it?

Such images should be removed or replaced, or the package moved to non-free.

I think the option of having the copyright holders relicense their creation under CC-BY-SA 3.0 should not be disregarded.

(I won't create the Alioth project since it should be created by a DD).

Really? I believe that all you need is to have an Alioth account.

#29 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to nodens
  • QA Check changed from Info Needed to Dev Needed

#30 Updated by nodens almost 5 years ago

  • Blocked by Bug #7742: Non-DFSG compliant images in the Tails OpenPGP Applet added

#31 Updated by nodens almost 5 years ago

  • Assignee changed from nodens to intrigeri
  • QA Check changed from Dev Needed to Info Needed

intrigeri wrote:

Is there's a distro-wide effort to report such DFSG violations and/or to ask the copyright holders to relicense their work under CC-BY-SA 3.0?

None that I know of currently.
Regarding those packages, I suspect that the maintainer might not be aware that the images are licensed differently, because it is not advertised by upstream.

I think so, too.

From what I can see, this is usually considered as a Serious bug by Debian.

Yes. Probably ignored for Wheezy, and quite possibly ignored for Jessie due to the imminent freeze and the fact it's not a new problem, but still.

Care to email debian-devel@ about it?

https://lists.debian.org/debian-devel/2014/08/msg00073.html

I also created #7742, since it could take some time, and I'd like to continue to use this request for the code-related issues. I assigned it to you so you'd see it and can correct if needed, since I'm not yet really familiar with tails bug/feature workflow. ;)

Meanwhile I'll continue working on the other issues.

Such images should be removed or replaced, or the package moved to non-free.

I think the option of having the copyright holders relicense their creation under CC-BY-SA 3.0 should not be disregarded.

Yes, that would be the best, of course.

(I won't create the Alioth project since it should be created by a DD).

Really? I believe that all you need is to have an Alioth account.

According to the Debian wiki and what I could find, a guest account cannot see a project creation approved if it's not directly relate to Debian. Only a DD can : https://wiki.debian.org/Alioth#Policy

Other sources seem to confirm this.

Cheers

#32 Updated by nodens almost 5 years ago

  • Related to deleted (Bug #7406: OpenPGP Applet system tray icon should be themable)

#33 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to nodens
  • QA Check changed from Info Needed to Dev Needed

nodens wrote:

https://lists.debian.org/debian-devel/2014/08/msg00073.html

\o/

I also created #7742, since it could take some time, and I'd like to continue to use this request for the code-related issues.

\o/

According to the Debian wiki and what I could find, a guest account cannot see a project creation approved if it's not directly relate to Debian. Only a DD can : https://wiki.debian.org/Alioth#Policy

I've just registered https://alioth.debian.org/projects/openpgp-applet/. What's your Alioth guest account?

#34 Updated by intrigeri almost 5 years ago

Also, again: please use Vcs-Git: https://git-tails.immerda.ch/nodens/openpgp-applet/ -b debian: it has a valid SSL cert, which is not the case for https://git.tails.boum.org/. Thanks!

#35 Updated by nodens almost 5 years ago

  • Assignee changed from nodens to intrigeri
  • QA Check changed from Dev Needed to Info Needed

intrigeri wrote:

nodens wrote:

According to the Debian wiki and what I could find, a guest account cannot see a project creation approved if it's not directly relate to Debian. Only a DD can : https://wiki.debian.org/Alioth#Policy

I've just registered https://alioth.debian.org/projects/openpgp-applet/. What's your Alioth guest account?

nodens-guest

Also, again: please use Vcs-Git: https://git-tails.immerda.ch/nodens/openpgp-applet/ -b debian: it has a valid SSL cert, which is not the case for https://git.tails.boum.org/. Thanks!

Corrected.

#36 Updated by intrigeri almost 5 years ago

I've just registered https://alioth.debian.org/projects/openpgp-applet/. What's your Alioth guest account?

nodens-guest

I've added you to the Alioth project.

#37 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to nodens
  • QA Check deleted (Info Needed)

#38 Updated by nodens almost 5 years ago

  • Assignee changed from nodens to intrigeri
  • QA Check set to Dev Needed

#39 Updated by nodens almost 5 years ago

  • Assignee changed from intrigeri to nodens

#40 Updated by nodens almost 5 years ago

  • % Done changed from 50 to 60

Just migrated to Dist::Zilla in feature/DistZilla.

Seems to work nicely, including the Changes generation. There is only one version for now so I'll need to sleep on it and test a bit more.

Also, it'll require some changes to the debian packaging (build depends, and a patch to remove the xclip requiresexternal which makes no sense at build time, but is nice to have in the upstream distribution).

Next : move namespace to Crypt in feature/CryptNamespace, replace Any::Moose with Moo in feature/UseMoo, merge features, release 0.8.1 and set up the alioth project properly with a minimalist page + debian packaging with the required adjustements.

#41 Updated by intrigeri almost 5 years ago

Just migrated to Dist::Zilla in feature/DistZilla.

Yay! I don't see this branch, but I see commit 9904cb41 that does the same on the master branch.

#42 Updated by nodens almost 5 years ago

Sorry, forgot to push it last night (needed sleep) and messed up my merge this morning (needed coffee)... Still learning to master git ;)

#43 Updated by nodens almost 5 years ago

Just pushed the feature/CryptNamespace branch.
Note that I didn't rename the distribution, so the pixmaps still live in /usr/share/perl5/auto/share/dist/OpenPGP_Applet/.

#44 Updated by intrigeri almost 5 years ago

Just pushed the feature/CryptNamespace branch.

Great! I see it's been merged into master.

Note that I didn't rename the distribution, so the pixmaps still live in /usr/share/perl5/auto/share/dist/OpenPGP_Applet/.

Should be fine, I guess, unless there are documented best practices about how module and dist names should be aligned.

Unrelated: may I ask you to be a tiny bit more verbose in commit messages sometimes? E.g. "add AutoPrereqs to dist.ini" doesn't tell me much that I can't see by looking at the diff: specifically, it doesn't tell me why we want this plugin.

+use strict;
use Any::Moose;

That's not needed, as Moose enables strict itself. It indicates a perlcritic lacking the appropriate configuration. See perlcritic.rc in our iuk Git repository.

The master branch history is a bit complicated to follow, due to back'n'forth between moving to the Crypt namespace and back. In the future, it's better to do these experiments in topic branches, and merged those (possibly squashed to clean up history) into master only when fully ready :)

To end with, feature/UseMoo needs to depend on a recent-enough version of GnuPG::Interface, that has my migration to Moo patch included (that is, 0.50). I doubt that AutoPrereqs will guess it, even if it understands Moo's extends syntax.

That's all for today! Great work :)

#45 Updated by nodens almost 5 years ago

intrigeri wrote:

Just pushed the feature/CryptNamespace branch.

Great! I see it's been merged into master.

Since I had some troubles with branching/merging while working on several things at once, as you noticed, at this point it was easier to merge it in master and work from there.

Note that I didn't rename the distribution, so the pixmaps still live in /usr/share/perl5/auto/share/dist/OpenPGP_Applet/.

Should be fine, I guess, unless there are documented best practices about how module and dist names should be aligned.

Perl distributions / Module naming is known to be inconsistent. E.g. LWP -> libwww-perl...

Unrelated: may I ask you to be a tiny bit more verbose in commit messages sometimes? E.g. "add AutoPrereqs to dist.ini" doesn't tell me much that I can't see by looking at the diff: specifically, it doesn't tell me why we want this plugin.

That's a good advice. I'll try :)

+use strict;
use Any::Moose;

That's not needed, as Moose enables strict itself. It indicates a perlcritic lacking the appropriate configuration. See perlcritic.rc in our iuk Git repository.

OK, corrected.

The master branch history is a bit complicated to follow, due to back'n'forth between moving to the Crypt namespace and back. In the future, it's better to do these experiments in topic branches, and merged those (possibly squashed to clean up history) into master only when fully ready :)

I aggree. I'm still adjusting to working properly with git and did some mistakes. Fortunately I was the only one to work on this code... I'll improve, promise ! :)

To end with, feature/UseMoo needs to depend on a recent-enough version of GnuPG::Interface, that has my migration to Moo patch included (that is, 0.50). I doubt that AutoPrereqs will guess it, even if it understands Moo's extends syntax.

Right. Added in the code so that AutoPrereqs catches it. That's actually the reason I chose to use Autoprereqs, so we don't have to maintain the version requirement both in the code (which is a good thing to do) and the dist.ini.

#46 Updated by nodens over 4 years ago

  • % Done changed from 60 to 70

Getting there...

  • added a branch for new, DFSG-free pixmaps (see #7742)
  • imported i18n stuff in feature/add_i18n branch

for i18n, I have the same issue than for the pixmaps initially : There is nothing in Dist::Zilla to install the .mo files in the proper place.
I think the best way to deal with it would be to use Locale::TextDomain and bundle the .mo files using File::ShareDir (mimicking padre on this as well).

@intrigeri, what do you think ?
Also, how about merging the feature/useMoo branch ?

Beside i18n stuff, still TBD before submitting the source package for review to Holger for sponsoring :
  • create minimalist project page on alioth and host tarball there (for watch file)
  • release first public version and update the debian packaging, getting ready for a first upload.

Cheers,

#47 Updated by nodens over 4 years ago

  • Assignee changed from nodens to intrigeri
  • QA Check changed from Dev Needed to Info Needed

#48 Updated by intrigeri over 4 years ago

  • Blocked by Bug #7968: Tails OpenPGP Applet can't clearsign text including non-ASCII characters added

#49 Updated by intrigeri over 4 years ago

  • Target version deleted (Tails_1.2)

#50 Updated by nodens over 4 years ago

About #7968, this is an important issue, but should it really "block" the debian-related work ?

#51 Updated by intrigeri over 4 years ago

nodens wrote:

About #7968, this is an important issue, but should it really "block" the debian-related work ?

IMO, this piece of software is not suitable for a Debian stable release without that serious bug fixed. So, if we upload it to Debian before the bug is fixed, IMO a RC bug should be filed immediately against it to block its migration to testing. Keeping the corresponding Redmine ticket as blocking is a good way to avoid forgetting to do so, but if you have a better way, I'm fine with it too :)

#52 Updated by intrigeri over 4 years ago

  • Assignee changed from intrigeri to nodens
  • QA Check changed from Info Needed to Dev Needed

nodens wrote:

for i18n, I have the same issue than for the pixmaps initially : There is nothing in Dist::Zilla to install the .mo files in the proper place.
I think the best way to deal with it would be to use Locale::TextDomain and bundle the .mo files using File::ShareDir (mimicking padre on this as well).

For our other Perl apps, we don't bother and instead install the MO files via debian/rules. I've hesitated a few times to use File::ShareDir or similar instead, but the fact that files then land into non-standard directories such as /usr/share/perl5/auto/share/dist/$DIST/locale/ has always felt wrong, so I never did it. But really, I don't mind, if you prefer to do it this way (and have the l10n files be installed by the dist on non-Debian OS).

Also, how about merging the feature/useMoo branch ?

ACK, once this branch removes equivalent_modules = Any::Moose from perlcritic.rc.

Great work!

#53 Updated by intrigeri over 4 years ago

  • Related to Bug #8051: OpenPGP Applet is unusable on GNOME Shell added

#54 Updated by nodens over 4 years ago

Back to work !

i18n is in shape in feature/add_i18n (messed up with git again and had to do a bit of history rewriting...).

Next : finally adjust perlcritic.rc (a debian package won't build since the tests won't pass in the current shape).

Still need to work on the project site.

#55 Updated by intrigeri over 4 years ago

  • Blocked by Bug #8310: Convert OpenPGP Applet into a proper GNOME Shell extension added

#56 Updated by nodens over 4 years ago

  • Related to Bug #8319: OpenPGP Applet: Add a confirmation dialog on exit added

#57 Updated by nodens over 4 years ago

  • Related to Bug #7406: OpenPGP Applet system tray icon should be themable added

#58 Updated by BitingBird over 4 years ago

  • Affected tool set to OpenPGP Applet

#59 Updated by intrigeri almost 4 years ago

Any update on this front?

#60 Updated by nodens almost 4 years ago

  • Assignee changed from nodens to intrigeri
  • QA Check changed from Dev Needed to Info Needed

Actually, there is, as I (finally) resumed (really) working on it this weekend.

I plan to release 0.9 soon (I hope today, this week for sure). I'm testing a new package right now : there are still a few quirks with my translation import from the main repo, but the rest looks OK (when the package is in debian we will be able to change the translation workflow and skip this part).

The first post on alioth mailing list along a minimal webpage will follow, probably using pkg-perl project model at first with links to Tails' wiki. I'd love to use ikwiki on alioth and import the relevant pages, but I'd really like to have something ready for debconf15, so it'll have to wait a bit since I never used ikwiki before (unless I have some help on that front).

Regarding versioning : If you're OK with it, I plan to use 0.9.1 and so on until the porting to gtk3 is complete, then 1.x, and maybe 2.x once we finally have a real app with a dbus backend (gnome extension and regular applet can then use the dbus extension). But this is the future. What do you think ?

#61 Updated by intrigeri almost 4 years ago

  • Blocked by deleted (Bug #8310: Convert OpenPGP Applet into a proper GNOME Shell extension)

#62 Updated by nodens almost 4 years ago

  • Assignee changed from intrigeri to nodens
  • % Done changed from 70 to 90

Update: making good progress with intrigeri. The packaging is almost done.

#63 Updated by nodens almost 4 years ago

  • QA Check changed from Info Needed to Dev Needed

#64 Updated by nodens almost 4 years ago

  • Related to deleted (Bug #8051: OpenPGP Applet is unusable on GNOME Shell)

#65 Updated by nodens almost 4 years ago

  • Related to deleted (Feature #7711: Port the OpenPGP applet to GTK+ 3)

#66 Updated by nodens almost 4 years ago

  • Related to deleted (Bug #8319: OpenPGP Applet: Add a confirmation dialog on exit)

#67 Updated by nodens almost 4 years ago

  • Related to deleted (Bug #7406: OpenPGP Applet system tray icon should be themable)

#68 Updated by nodens almost 4 years ago

  • Blocked by deleted (Bug #7742: Non-DFSG compliant images in the Tails OpenPGP Applet)

#69 Updated by nodens almost 4 years ago

  • Blocked by deleted (Bug #7968: Tails OpenPGP Applet can't clearsign text including non-ASCII characters)

#70 Updated by intrigeri almost 4 years ago

  • Blocked by Bug #7742: Non-DFSG compliant images in the Tails OpenPGP Applet added

#71 Updated by intrigeri almost 4 years ago

  • Blocked by Bug #7968: Tails OpenPGP Applet can't clearsign text including non-ASCII characters added

#72 Updated by intrigeri almost 4 years ago

  • Type of work changed from Debian to Wait

It's now in the NEW queue: https://ftp-master.debian.org/new.html

#73 Updated by intrigeri over 3 years ago

  • QA Check deleted (Dev Needed)

#74 Updated by intrigeri over 3 years ago

  • Blocked by deleted (Bug #7742: Non-DFSG compliant images in the Tails OpenPGP Applet)

#75 Updated by intrigeri over 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (nodens)
  • % Done changed from 90 to 100
  • Type of work changed from Wait to Debian

It's now in testing/sid :)

#76 Updated by intrigeri over 3 years ago

  • Target version set to Tails_1.6

Also available in: Atom PDF