Tails

#4 Updated by intrigeri 2014-07-25 08:18:09

> 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 2014-07-25 08:36:41

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 ?

#7 Updated by intrigeri 2014-07-25 10:07:23

> 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 tails-sysadmins@boum.org
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

#11 Updated by intrigeri 2014-07-27 16:40:04

> 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 2014-07-27 22:51:53

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.

#15 Updated by nodens 2014-07-30 12:08:30

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

#19 Updated by nodens 2014-07-31 19:58:29

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.

#21 Updated by intrigeri 2014-08-01 15:07:18

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.

>> # 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 Feature #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:

• 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.
• see https://labs.riseup.net/code/projects/tails/search?utf8=✓&q=openpgp+applet&scope=&all_words=&all_words=1&titles_only=&titles_only=1&issues=1&changesets=1&commit=Submit, by the way :)

#23 Updated by nodens 2014-08-02 00:35:52

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 !

#26 Updated by intrigeri 2014-08-02 12:04:36

> 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 (alan@boum.org) 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 2014-08-02 14:37:48

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 2014-08-03 10:40:09

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

#34 Updated by intrigeri 2014-08-04 11:27:49

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!

#36 Updated by intrigeri 2014-08-04 13:59:48

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

#41 Updated by intrigeri 2014-08-05 08:23:54

> 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 2014-08-05 09:04:26

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 2014-08-06 16:56:58

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 2014-08-09 15:44:46

> 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 2014-08-15 17:46:18

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.

#50 Updated by nodens 2014-09-29 13:21:21

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

#51 Updated by intrigeri 2014-09-30 20:37:52

nodens wrote:
> About Bug #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 :)

#54 Updated by nodens 2014-11-23 10:32:16

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.

#59 Updated by intrigeri 2015-08-09 09:32:07

Any update on this front?