Re: [Tails-dev] Tails Clock v0.4 - Update

Borrar esta mensaxe

Responder a esta mensaxe
Autor: Kevin C. Krinke
Data:  
Para: tails-dev
Asunto: Re: [Tails-dev] Tails Clock v0.4 - Update
Hola!

On 2013-11-06 8:42 AM, intrigeri wrote:
> JFTR, 0.22 won't be based on Wheezy: these images have 0.22 in their
> name only to indicated that the feature/wheezy branch is currently
> based on the code that will be called 0.22 in December. The nightly
> builds based on the devel branch are much closer to what
> 0.22 will be, so better not call "0.22" images built from
> feature/wheezy.


Sure, I just grabbed the first nightly I could find and saw it mentioned
in another thread so figured may as well test there too!

> So, I've tested this in a Tails/Wheezy image, and it works fine for
> me. Congrats!


Awesome!

> Various nitpicking follows:


:)

> * .config/tailsclock/settings reads:
>      # DO NOT EDIT - This file is overwritten automatically. #
>   May I ask why? Isn't manual configuration supported?
>   When / why would manual configuration be overwritten?


Whenever a configuration option is changed in the prefs dialog, the
entire file is re-written. #LazyProgramming

Should I do something different there?

> * .config/tailsclock/timezone could use a newline at the end of the
> file.


Will do.

> * "key: value" would look better to me than "key:value", and be closer
> to YAML iirc.


#LazyProgramming, #WillFix

> * When the locale doesn't support AM/PM, why not simply hide the
> config option in the prefs dialog, instead of locking it?
> That may be only me, but I generally feel weird when I'm shown some
> piece of UI that I can't interact with.


I'm not a fan of hidden options just because my locale doesn't support
the feature. In any case, I'm not tied to any particular choice on the
matter. If it feels odd to see them greyed out; #WillFix.

> * Is it on purpose that a logfile is always created? I understand it's
> useful at development time, but we won't want to ship with this in
> production, will we? (Printing to STDERR would seem just fine to me,
> so that logs land into ~/.xsession-errors, just like every other
> similar message from a desktop software.)


For some unknown reason, printing to stderr did not show up for me in
~/.xsession-errors.

As for why debug is on by default, right now I'd like to ensure that
when someone tests and has a bug with the formatting or whatnot, they've
got something they can add to the bug report.

0.5 will be a bugfix build without debugging and if that's all good then
we'll finalize and jump to a 1.0 actual release.

> * Please use dh-autoreconf in the Debian packaging.


Will do.

> * Please Depend: ${python:Depends}


Will do.

> * Please uncomment and update Vcs-Git and Vcs-Browser.


Will do.

> * Replace GPL-3.0+ with GPL-3+ in debian/copyright.


Will do.

> * Please upgrade to compat level 9 (debhelper 9 is in
> squeeze-backports, so no need to use an older compat version).


Will do.

> * Please reformat debian/* with "cme fix dpkg" (needed tools are in
> the libconfig-model-dpkg-perl package).


Will do.

> * s/Gnome/GNOME/ in the package description.


Will do.

> * Please fix the package description so that it doesn't lie about the
> available options, and the supported version of GNOME (the rest of
> the packaging is GNOME3-specific)


Will do.

> * No need to have separated "debian/*" and "*" sections in
> debian/copyright, since the copyright holder and license are
> the same. "*" will be enough :)


Will do.

> * Why ship a NEWS file? It seems obsolete.


autotools complained, lintian complained. Will remove :)


Cheers!

--
Kevin C. Krinke <kevin@???>
GnuPG - 851662D2 - 0x18C67F61851662D2
http://kevin.c.krinke.ca/851662D2.asc