Re: [ANOUNCE] Debtemplate

2016-10-21 Thread Dmitry Bogatov 

> FYI: The reviewer is assigned to pull requests on GitHub but there is no
> progress since then.
> I think that it is better to improve such a thing on server side

Not for me. I live in tty and consider using web-applications as last
resort to solving any task. That is the reason why `debrequest'
(new, I believe better name to debtemplate) was born.

> (mentors.d.n) because there is no need to install an extra package and
> it can get more feedback.  Anyway, currently there is no hope that
> pull requests are merged and deploy, it is reasonable to improve known
> problem in client side (debtemplate), let's go ahead!

Looking for sponsor.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpa5WmtPjS6v.pgp
Description: PGP signature

Re: lintian: spelling

2016-10-21 Thread Ben Finney 
Jerome BENOIT  writes:

> Hi,
>
> On 21/10/16 12:56, Ben Finney wrote:
> > I would suggest:
> > 
> > :param int max_no_dec: number of rounds we allow [FIXME] to be stuck.
> > 
> > where “[FIXME]” must be replaced with something explicit. Is it “the
> > program”? “the network connection”? Some other party? It's not
> > specified, and I think Lintian is correct to complain.
>
> [FIXME] is certainly an obscure loop that is meant to stop any
> convergence that goes out of control.

Could that be broadened simply to “the function”?

> I guess that we can over come it through a passive sentence:

For documentation, passive sentences are almost certainly worse (less
clear, more ambiguous) than explicitly naming the active parties.

>   :param int max_no_dec: number of rounds allowed to be stuck.

How about:

:param int max_no_dec: number of rounds the function is allowed to be stuck.

Thank you for working to improve the software.

-- 
 \   “Anyone who puts a small gloss on [a] fundamental technology, |
  `\  calls it proprietary, and then tries to keep others from |
_o__)   building on it, is a thief.” —Tim O'Reilly, 2000-01-25 |
Ben Finney

Re: lintian: spelling

2016-10-21 Thread Ben Finney 
Jerome BENOIT  writes:

> Before all, thanks for your constructive replies.
>
> On 21/10/16 21:34, Ben Finney wrote:
> > *Some* party is allowed to be stuck, but the current phrasing
> > doesn't say what; the description should be clear and say what that
> > party is.
>
> We are dealing here with a well known algorithm in the involved field.
> So the `party' is implicitly the algorithm. I have to confess that I am
> not familiar with this very algorithm. But the context let me think that
> it is a convergent algorithm and that the involved parameter is meant to
> control (numerical) convergence that goes out of control, what is a usual
> safeguard technique so to speak. 

This seems to be overthing the question far too much.

I'll state it simply again: Please fill in the “” in the text:

:param int max_no_dec: number of rounds we allow  to be stuck.

That will make the statement clearer, by removing an ambiguous unstated
party in the statement.

-- 
 \“Members of the general public commonly find copyright rules |
  `\implausible, and simply disbelieve them.” —Jessica Litman, |
_o__)  _Digital Copyright_ |
Ben Finney

Re: lintian: spelling

2016-10-21 Thread Jerome BENOIT 
Hi,

On 21/10/16 12:56, Ben Finney wrote:
> Jakub Wilk  writes:
> 
>> [Disclaimer: I'm not a native speaker of English.]
> 
> (Credential: I am a native speaker of English.)
> 
>>> :param int max_no_dec: number of rounds we allow to be stuck
>>
>> Lintian complains about "allow to" because "allow" requires an object,
> 
> Yes, “allow” requires at least three referents: the party who grants
> allowance, the actions allowed, and the party to whom allowance is
> granted.
> 
> Example:
> 
> “Alice allows Bob to sit”.
> 
> “Alice”, “to sit”, “Bob” are the three terms functionining in the
> grammar of the main verb “to allow”.
> 
> As is usual with natural language, many usages leave implicit some of
> those terms.
> 
> Example:
> 
> “allowed to sit”
> 
> is a phrase that leaves both parties out. It functions as:
> 
> “ allowed  to sit”
> 
>> and in most cases[*] this object goes between "allow" and "to". But
>> here, "number of rounds" is the object.
> 
> That is incorrect; “number of rounds” is not a direct part of the
> grammar of “to allow”.
> 
> Rather “number of rounds” is part of the grammar of the descriptor
> “stuck”; in this case, “stuck for ‘max_no_dec’ number of rounds”.
> 
> Thus the verb phrase “stuck for ‘max_no_dec’ number of rounds” is
> distributed across the sentence. That is not bad, but it does make the
> grammar more difficult for non-Anglophones to parse.
> 
> 
> So a full explicit grammar of this statement would be:
> 
> We allow  to be stuck for ‘max_no_dec’ rounds.
> 
> Lintian is, correctly IMO, complaining because the statement leaves
> unknown the party to whom the action is allowed.
> 
>> We allow $max_no_dec rounds to be stuck.
> 
> That is not grammatical; it implies “rounds [to be stuck]” is the party
> to whom allowance is granted. That is not what this sentence means, so
> the phrasing should not imply that.
> 
> I would suggest:
> 
> :param int max_no_dec: number of rounds we allow [FIXME] to be stuck.
> 
> where “[FIXME]” must be replaced with something explicit. Is it “the
> program”? “the network connection”? Some other party? It's not
> specified, and I think Lintian is correct to complain.

[FIXME] is certainly an obscure loop that is meant to stop any convergence that 
goes out of control.
I guess that we can over come it through a passive sentence:

:param int max_no_dec: number of rounds allowed to be stuck.

This change silences lintian.

Jerome


>

Re: lintian: spelling

2016-10-21 Thread Jerome BENOIT 
Before all, thanks for your constructive replies.

On 21/10/16 21:34, Ben Finney wrote:
> Octavio Alvarez  writes:
> 
>> On 10/21/2016 04:56 AM, Ben Finney wrote:
>>> I would suggest:
>>>
>>> :param int max_no_dec: number of rounds we allow [FIXME] to be stuck.
>>>
>>> where “[FIXME]” must be replaced with something explicit. Is it “the
>>> program”? “the network connection”? Some other party? It's not
>>> specified, and I think Lintian is correct to complain.
>>
>> What about:
>>
>> :param int max_no_dec: number of rounds we allow being stuck
> 
> Still far too ambiguous. Why not just *explicitly* state what party is
> granted the allowance?
> 
> *Some* party is allowed to be stuck, but the current phrasing doesn't
> say what; the description should be clear and say what that party is.

We are dealing here with a well known algorithm in the involved field.
So the `party' is implicitly the algorithm. I have to confess that I am
not familiar with this very algorithm. But the context let me think that
it is a convergent algorithm and that the involved parameter is meant to
control (numerical) convergence that goes out of control, what is a usual
safeguard technique so to speak. 


> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

Bug#841646: marked as done (RFS: libtcod/1.6.1+dfsg-1 -- graphics and utility library for roguelike developers)

2016-10-21 Thread Debian Bug Tracking System 
Your message dated Sat, 22 Oct 2016 00:40:32 +0200
with message-id <20161021224032.ga9...@angband.pl>
and subject line Re: Bug#841646: RFS: libtcod/1.6.1+dfsg-1 -- graphics and 
utility library for roguelike developers
has caused the Debian Bug report #841646,
regarding RFS: libtcod/1.6.1+dfsg-1 -- graphics and utility library for 
roguelike developers
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
841646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841646
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libtcod".

The main change since the last upload was the introduction of a new
"python-libtcod" package that offers Python bindings for libtcod.

Since I am relatively new to Python packaging, I would appreciate it
if someone could review the changes pertaining to the Python package
in particular.

Thank you!

Changes since the last upload:

   * New upstream release.
   * Fix debian/watch.
   * Update patches:
  - Remove 0001-Use-global-zlib.h.patch (fixed upstream).
  - Rewrite 0002-Fix-soname.patch as 00-fix-makefile.patch.
  - Remove 0003-Fix-spelling-errors.patch (fixed upstream).
  - Remove 0005-Fix-warnings.patch (fixed upstream).
  - Rename patch 0004-Fix-cppcheck.patch as 01-fix-cppcheck.patch.
   * Update symbols file.
   * Adjust debian/rules.
   * Update debian/copyright.
   * Install upstream changelog.
   * Add the python-libtcod package.
   * Add patch 02-python-multiarch.patch to help the Python wrapper find
 libtcod.so in /usr/lib//.
   * Add debian/clean file and override_dh_auto_clean target in debian/rules.

Further information:

* Package name: libtcod
  Version : 1.6.1+dfsg-1
  Upstream Author : Richard Tew 
* URL : https://bitbucket.org/libtcod/libtcod
* License : BSD-3
  Section : libs

It builds those binary packages:

  libtcod-dev - development files for the libtcod roguelike library
  libtcod0 - graphics and utility library for roguelike developers
  python-libtcod - Python bindings for the libtcod library

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libtcod

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtcod/libtcod_1.6.1+dfsg-1.dsc

Regards,
 Fabian Wolff
--- End Message ---
--- Begin Message ---
On Fri, Oct 21, 2016 at 07:27:50PM +0200, Fabian Wolff wrote:
> I am looking for a sponsor for my package "libtcod".
> 
> The main change since the last upload was the introduction of a new
> "python-libtcod" package that offers Python bindings for libtcod.
> 
> Since I am relatively new to Python packaging, I would appreciate it
> if someone could review the changes pertaining to the Python package
> in particular.

> Changes since the last upload:
> 
>* New upstream release.
>* Fix debian/watch.
>* Update patches:
>   - Remove 0001-Use-global-zlib.h.patch (fixed upstream).
>   - Rewrite 0002-Fix-soname.patch as 00-fix-makefile.patch.
>   - Remove 0003-Fix-spelling-errors.patch (fixed upstream).
>   - Remove 0005-Fix-warnings.patch (fixed upstream).
>   - Rename patch 0004-Fix-cppcheck.patch as 01-fix-cppcheck.patch.
>* Update symbols file.
>* Adjust debian/rules.
>* Update debian/copyright.
>* Install upstream changelog.
>* Add the python-libtcod package.
>* Add patch 02-python-multiarch.patch to help the Python wrapper find
>  libtcod.so in /usr/lib//.
>* Add debian/clean file and override_dh_auto_clean target in debian/rules.

Uploaded.

Looks good as far as I can tell, although it might be good to have someone
well-versed with Python to have a second look.

As this needs to go through NEW, I've chosen armhf as the sacrificial
non-source-only arch.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.--- End Message ---

Bug#841660: RFS: budgie-desktop/10.2.8-1

2016-10-21 Thread foss.freedom 
Hi Gianfranco

  quite correct data/icons/* was marked as CC-BY-SA-4.0 in
debian/copyright ... my bad.  Have corrected this to CC-BY-SA-3.0

The "Copyright (C) GNOME Shell Developers (Heavy inspiration, logic
theft)" is the text in wm/keyboard.vala and wm/ibus.vala - both of
these are in the debian/copyright file.  I've now split ikey's
copyright line and "GNOME Shell Developers" onto separate lines in
debian/copyright for both wm/keyboard.vala and wm/ibus.vala

D

On 21 October 2016 at 21:21, Gianfranco Costamagna
 wrote:
> control: tags -1 moreinfo
> control: owner -1 !
>
> Hi,
>
>> dget -x 
>> https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.8-1.dsc
>
>
>>1. I noticed on mentors.debian.net that the watch file failed - this
>>is very strange since nothing has changed for months now - is there a
>>bug on mentors at the moment causing the watch to fail?
>
>
> IIRC yes
>
>
>>2. ran check-all-the-things - this did not find anything new from>previous 
>>uploads
>
>
> ok
>
>>3. ran lintian -i -I on the sources - no new items listed in previous uploads
>
> ok
>
>>- to reiterate - current linitian items are known upstream
>>budgie-desktop.  relnow, bindnow will be resolved once the VALA stuff
>>is recoded to C
>>- rpath is necessary due to upstream GNOME GTK_3.22 private mutter API changes
>>- the patches added are upstream budgie-desktop released since v10.2.8
>>- bugs found after release that are necessary for ibus capability on
>
>>debian/ubuntu
>
> ok
>
>>  Changes since the last upload:
>>
>>  * New upstream release
>>- GTK+3.22 fixes
>>- new places indicator
>>- new ibus indicator
>>- refreshed panel icons
>>- updated translations
>>- general fixes for the desktop
>>  * Packaging changes:
>>- Drop all now obsolete previous patches named 000*
>>- add new build dependency libibus-1.0-dev
>>- Updated debian/copyright with revised info for new source files
>>- add recommendation to install gnome-screensaver; screenlock capability
>>  in budgie-desktop does not work without this package
>>  * add patch upstream patch to allow the ibus applet to compile:
>>  0001-Lower-the-ibus-requirement-to-1.5.11-for-our-Debuntu.patch
>>  * add patch to ensure ibus is connected correctly if already running
>>  0002-wm-ibus-Always-try-to-use-an-existing-ibus-daemon-if.patch
>>
>
>
>
> blockers:
>
> missing licenses (cc-by-sa3.0)
> + * Copyright (C) GNOME Shell Developers (Heavy inspiration, logic theft)
>
> (vala^^)
>
> other stuff seems good
>
> G.

Re: lintian: spelling

2016-10-21 Thread Ben Finney 
Octavio Alvarez  writes:

> On 10/21/2016 04:56 AM, Ben Finney wrote:
> > I would suggest:
> > 
> > :param int max_no_dec: number of rounds we allow [FIXME] to be stuck.
> > 
> > where “[FIXME]” must be replaced with something explicit. Is it “the
> > program”? “the network connection”? Some other party? It's not
> > specified, and I think Lintian is correct to complain.
>
> What about:
>
> :param int max_no_dec: number of rounds we allow being stuck

Still far too ambiguous. Why not just *explicitly* state what party is
granted the allowance?

*Some* party is allowed to be stuck, but the current phrasing doesn't
say what; the description should be clear and say what that party is.

-- 
 \   “Kissing a smoker is like licking an ashtray.” —anonymous |
  `\   |
_o__)  |
Ben Finney

Bug#841660: RFS: budgie-desktop/10.2.8-1

2016-10-21 Thread Gianfranco Costamagna 
control: tags -1 moreinfo
control: owner -1 !

Hi,

> dget -x 
> https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.8-1.dsc


>1. I noticed on mentors.debian.net that the watch file failed - this
>is very strange since nothing has changed for months now - is there a
>bug on mentors at the moment causing the watch to fail?


IIRC yes


>2. ran check-all-the-things - this did not find anything new from>previous 
>uploads


ok

>3. ran lintian -i -I on the sources - no new items listed in previous uploads

ok

>- to reiterate - current linitian items are known upstream
>budgie-desktop.  relnow, bindnow will be resolved once the VALA stuff
>is recoded to C
>- rpath is necessary due to upstream GNOME GTK_3.22 private mutter API changes
>- the patches added are upstream budgie-desktop released since v10.2.8
>- bugs found after release that are necessary for ibus capability on

>debian/ubuntu

ok

>  Changes since the last upload:
>
>  * New upstream release
>- GTK+3.22 fixes
>- new places indicator
>- new ibus indicator
>- refreshed panel icons
>- updated translations
>- general fixes for the desktop
>  * Packaging changes:
>- Drop all now obsolete previous patches named 000*
>- add new build dependency libibus-1.0-dev
>- Updated debian/copyright with revised info for new source files
>- add recommendation to install gnome-screensaver; screenlock capability
>  in budgie-desktop does not work without this package
>  * add patch upstream patch to allow the ibus applet to compile:
>  0001-Lower-the-ibus-requirement-to-1.5.11-for-our-Debuntu.patch
>  * add patch to ensure ibus is connected correctly if already running
>  0002-wm-ibus-Always-try-to-use-an-existing-ibus-daemon-if.patch
>



blockers:

missing licenses (cc-by-sa3.0)
+ * Copyright (C) GNOME Shell Developers (Heavy inspiration, logic theft)

(vala^^)

other stuff seems good

G.

Bug#841660: RFS: budgie-desktop/10.2.8-1

2016-10-21 Thread foss.freedom 
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "budgie-desktop"

 * Package name: budgie-desktop
   Version : 10.2.8-1
   Upstream Author : i...@solus-project.com
 * URL : https://github.com/solus-project/budgie-desktop
 * License : LGPL-2.1/GPL2.0
   Section : x11

  It builds those binary packages:

budgie-core - Core package for Budgie-Desktop
 budgie-core-dev - Development package for budgie-desktop
 budgie-desktop - Desktop package for budgie-desktop
 budgie-desktop-doc - documentation files for the budgie-desktop
 gir1.2-budgie-desktop-1.0 - GNOME introspection library for budgie-desktop
 libbudgie-plugin0 - Plugin library for budgie-desktop
 libbudgietheme0 - Theme library for budgie-desktop
 libraven0  - Raven library for budgie-desktop

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/budgie-desktop


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.8-1.dsc

Notes:
1. I noticed on mentors.debian.net that the watch file failed - this
is very strange since nothing has changed for months now - is there a
bug on mentors at the moment causing the watch to fail?
2. ran check-all-the-things - this did not find anything new from
previous uploads
3. ran lintian -i -I on the sources - no new items listed in previous uploads

 - to reiterate - current linitian items are known upstream
budgie-desktop.  relnow, bindnow will be resolved once the VALA stuff
is recoded to C
- rpath is necessary due to upstream GNOME GTK_3.22 private mutter API changes
- the patches added are upstream budgie-desktop released since v10.2.8
- bugs found after release that are necessary for ibus capability on
debian/ubuntu


  Changes since the last upload:

  * New upstream release
- GTK+3.22 fixes
- new places indicator
- new ibus indicator
- refreshed panel icons
- updated translations
- general fixes for the desktop
  * Packaging changes:
- Drop all now obsolete previous patches named 000*
- add new build dependency libibus-1.0-dev
- Updated debian/copyright with revised info for new source files
- add recommendation to install gnome-screensaver; screenlock capability
  in budgie-desktop does not work without this package
  * add patch upstream patch to allow the ibus applet to compile:
  0001-Lower-the-ibus-requirement-to-1.5.11-for-our-Debuntu.patch
  * add patch to ensure ibus is connected correctly if already running
  0002-wm-ibus-Always-try-to-use-an-existing-ibus-daemon-if.patch


  Regards,
   David Mohammed

Bug#839725: marked as done (uptimed: 0.4.0+git20150923.6b22106-1 [ITA])

2016-10-21 Thread Debian Bug Tracking System 
Your message dated Fri, 21 Oct 2016 21:09:40 +0200
with message-id <1477076980.16164.0.ca...@debian.org>
and subject line Re: Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]
has caused the Debian Bug report #839725,
regarding uptimed: 0.4.0+git20150923.6b22106-1 [ITA]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
839725: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839725
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Hello

I'm looking for an sponsor of my package uptimed,
I want to adopt this package after it was orphaned by the previous
maintainer #830765

uptimed is an old package (in debian since '99) it has many bugs open,
I fixed some bugs but others I wasn't able to reproduce them,
so my plan is to upload to experimental
and contact the reporters to see if they/I can reproduce the bugs then fix
them.

I want to upload to experimental to check if it builds reproducibly in all 
Debian architectures.
Be aware that I'll request another upload latter for unstable.

debian/rules and packaging in general was polished, modernized, and uploaded
to collab-maint

this is the changelog

uptimed (1:0.4.0+git20150923.6b22106-1) experimental; urgency=medium

  * New maintainer, thanks Thibaut Varene for your previous
work (Closes: #830765)
  * Packaging is now maintained in collab-maint using a git repo
  * Packaging an snapshot from upstream
  * Packaging using git tags instead of tarballs
  * Change dh compat to level 9. No changes were needed
  * Build depend on debhelper 9 and dh-autoreconf
  * Update Homepage field on debian/control (Closes: #806456)
  * Handle missing /etc/uptimed.conf (Closes: #680419)
  * Simplify uptimed init.d script, restart unconditionally on uptimed
postinst
  * Match the location of the $PIDFILE in the init script and the daemon
configuration (Closes: #336922) (LP: #482629)
  * Create /run/uptimed via a tmpfile on systemd systems
  * Change the default interval to save the database from 300 to 3600 seconds
  * Bump Standards-Version to 3.9.8. No changes were needed
  * Override 2 lintian warnings (unused-debconf-template)
  * Remove perl dependency on libuptimed0 and libuptimed-dev, perl-base is
enough
  * Change watch file to look at github
  * Update uptimed's service file, to start after the time is in sync,
it still may fail if systemd-timesyncd.service is not in use
  * Update uptimed's service to provide uptimed's documentation
  * More modern debian/rules
  * Print a warning on debconf when reducing MAX_RECORDS (Closes: #573232)
  * Add pristine-tar to git repo

 -- gustavo panizzo   Tue, 04 Oct 2016 15:58:19 +0800


git repo can be found here

git.debian.org:/git/collab-maint/uptimed.git

built package can be found on mentors
https://mentors.debian.net/debian/pool/main/u/uptimed/uptimed_0.4.0+git20150923.6b22106-1.dsc


thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Thu, 20 Oct 2016 10:21:16 +0800 gustavo panizzo 
wrote:
> On Wed, Oct 19, 2016 at 08:43:31PM +0200, Tobias Frost wrote:
> > Hi Gustavo,
> > 
> > Am Mittwoch, den 19.10.2016, 14:15 +0800 schrieb gustavo panizzo:
> > > On Sun, Oct 16, 2016 at 10:35:42AM +0200, Tobias Frost wrote:
> > > > 
> > > > Please fix the lintian error, the d/copyright and then I'll
upload.
> > > > The *.la can be fixed in a subsequent upload, but maybe you can
> > > > include
> > > > it already in the revised packages.
> > > 
> > > 
> > > I've pushed to alioth, please take a look
> > > 
> > 
> > Please recheck, I can't see the changes here.
> 
> sorry about that. Can you try again?
> 
> thanks!
> 
> -- 
> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
> 
> keybase: https://keybase.io/gfa

Uploaded, many thanks!

--
tobi--- End Message ---

Re: lintian: spelling

2016-10-21 Thread Octavio Alvarez 
On 10/21/2016 04:56 AM, Ben Finney wrote:
> I would suggest:
> 
> :param int max_no_dec: number of rounds we allow [FIXME] to be stuck.
> 
> where “[FIXME]” must be replaced with something explicit. Is it “the
> program”? “the network connection”? Some other party? It's not
> specified, and I think Lintian is correct to complain.

What about:

:param int max_no_dec: number of rounds we allow being stuck



-- 
Octavio.

Bug#841646: RFS: libtcod/1.6.1+dfsg-1 -- graphics and utility library for roguelike developers

2016-10-21 Thread Fabian Wolff 
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libtcod".

The main change since the last upload was the introduction of a new
"python-libtcod" package that offers Python bindings for libtcod.

Since I am relatively new to Python packaging, I would appreciate it
if someone could review the changes pertaining to the Python package
in particular.

Thank you!

Changes since the last upload:

   * New upstream release.
   * Fix debian/watch.
   * Update patches:
  - Remove 0001-Use-global-zlib.h.patch (fixed upstream).
  - Rewrite 0002-Fix-soname.patch as 00-fix-makefile.patch.
  - Remove 0003-Fix-spelling-errors.patch (fixed upstream).
  - Remove 0005-Fix-warnings.patch (fixed upstream).
  - Rename patch 0004-Fix-cppcheck.patch as 01-fix-cppcheck.patch.
   * Update symbols file.
   * Adjust debian/rules.
   * Update debian/copyright.
   * Install upstream changelog.
   * Add the python-libtcod package.
   * Add patch 02-python-multiarch.patch to help the Python wrapper find
 libtcod.so in /usr/lib//.
   * Add debian/clean file and override_dh_auto_clean target in debian/rules.

Further information:

* Package name: libtcod
  Version : 1.6.1+dfsg-1
  Upstream Author : Richard Tew 
* URL : https://bitbucket.org/libtcod/libtcod
* License : BSD-3
  Section : libs

It builds those binary packages:

  libtcod-dev - development files for the libtcod roguelike library
  libtcod0 - graphics and utility library for roguelike developers
  python-libtcod - Python bindings for the libtcod library

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libtcod

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtcod/libtcod_1.6.1+dfsg-1.dsc

Regards,
 Fabian Wolff

Bug#841536: marked as done (hdparm/9.50+ds-1)

2016-10-21 Thread Debian Bug Tracking System 
Your message dated Fri, 21 Oct 2016 17:12:00 +
with message-id <76967b40-1ee6-131a-ce7d-fb8819f58...@thykier.net>
and subject line Re: hdparm/9.50+ds-1
has caused the Debian Bug report #841536,
regarding hdparm/9.50+ds-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
841536: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841536
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: mailatgo...@gmail.com

Dear mentors,

 I am looking for a sponsor for my package "hdparm":

* Package name: hdparm
  Version : 9.50
  Upstream Author : Mark Lord 
* URL : http://sourceforge.net/projects/hdparm/files/hdparm/
* License : hdparm
  Section : Admin

  It builds following binary packages:
   - hdparm

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/hdparm

Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/h/hdparm/
hdparm_9.50+ds-1.dsc

More information about hdparm can be obtained from
  https://anonscm.debian.org/cgit/collab-maint/hdparm.git

Changes since last upload:

  * New upstream version 9.50+ds
  * Refresh quiet_sequrity_freeze.patch and update spelling.patch
  * Update copyright years

Best regards,
Alex
--- End Message ---
--- Begin Message ---
Niels Thykier:
> [...]
> 
> Hi Alex,
> 
> Thanks for your contribution.
> 
> Have you informed upstream about the following compiler warning?
> """
> [... misleading indentation warning]
> """
> 
> Other minor nits:
>  * Spelling error in hdparm binary "Removeable" -> "Removable"
>- NB: Upstream is inconsistent with the spelling, but seems to prefer
>  the "Removable" variant.
>  * Upstream's build system hardcodes -j2 on "make all" and the packaging
>uses that without any respect to DEB_BUILD_OPTIONS
>- Given the small size and low parallel limit, I don't think it is a
>  huge issue (but it would have been for other packages).
>  * The debian/hdparm.preinst file appears to be redundant (its replaced
>by the debian/hdparm.maintscript)
> 
> Thanks,
> ~Niels
> 

And uploaded:

"""
[...]
Logging into host ssh.upload.debian.org as nthykier
Uploading hdparm_9.50+ds-1.dsc
Uploading hdparm_9.50+ds.orig.tar.xz
Uploading hdparm_9.50+ds-1.debian.tar.xz
Uploading hdparm_9.50+ds-1_source.changes
"""

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#841536: hdparm/9.50+ds-1

2016-10-21 Thread Niels Thykier 
Control: tags -1 moreinfo

On Fri, 21 Oct 2016 14:46:32 +0200 Alex Mestiashvili
 wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-Cc: mailatgo...@gmail.com
> 
> Dear mentors,
> 
>  [...]
> 
> Best regards,
> Alex


Hi Alex,

Thanks for your contribution.

Have you informed upstream about the following compiler warning?
"""
hdparm.c: In function 'process_dev':
hdparm.c:2256:2: warning: this 'if' clause does not guard...
[-Wmisleading-indentation]
  if (!quiet)
  ^~
hdparm.c:2258:3: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
   if (do_drive_cmd(fd, args, 0)) {
   ^~
"""

I checked it seems benign, so I am not blocking the upload on this.  The
code in question being:


"""
if (security_freeze) {
__u8 args[4] = {ATA_OP_SECURITY_FREEZE_LOCK,0,0,0};
if (!quiet)
^^^ (should be 1 tab further in)
printf(" issuing security freeze command\n");
^^ (should be 1 tab further in as well)
if (do_drive_cmd(fd, args, 0)) {
err = errno;
perror(" HDIO_DRIVE_CMD[...] failed");
}
}

"""

Other minor nits:
 * Spelling error in hdparm binary "Removeable" -> "Removable"
   - NB: Upstream is inconsistent with the spelling, but seems to prefer
 the "Removable" variant.
 * Upstream's build system hardcodes -j2 on "make all" and the packaging
   uses that without any respect to DEB_BUILD_OPTIONS
   - Given the small size and low parallel limit, I don't think it is a
 huge issue (but it would have been for other packages).
 * The debian/hdparm.preinst file appears to be redundant (its replaced
   by the debian/hdparm.maintscript)

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Bug#791724: RFS: w1retap/1.4.4-1 [ITP] -- Data logger for 1-Wire weather sensors

2016-10-21 Thread Thomas Stewart 
Hi Gianfranco,

Thanks again for another review and the suggestions you made! I have
made a number of the fixes you suggested and have tried to explain my
choices below. I have just uploaded a fresh version of the package to
http://mentors.debian.net/package/w1retap. 

If you have any further comments they would really be appreciated,
alternatively if you think that the package is ready would you be
willing to sponsor the upload?


On 15 Oct 2016, at 11:10, Gianfranco Costamagna wrote:
> >The plugin packages contain .so files, the --noscripts option stops an
> >ldconfig run when installing. Without it I get a lintian useless
> >ldconfig run warnings.
> 
> well, I usually don't care about such warnings, but I wonder if somewhen
> in the future the package starts shipping an external shared library
> and ldconfig won't be run because of this.
> (I'm not asking to change this, just wondering about a possible future
> side effect, and please note I have no clues about the possibilities
> of this scenario, and probably lintian will complain in such case)
> 

I think w1retap is in maintenance mode, so this is currently unlikely.
However I'll keep it in mind in the future.


> >I did run all of the above and found some issues. Some of the issues
> >seemed to be more related to actual upstream development rather than
> >packaging. Most notably predicable file creation in /tmp, which is
> >fixed in the above mentioned movetmp.patch. Did you spot anything
> >else that needing fixing?
> 
> mmm movetmp.patch... 
> 
> -w1->tmpname = "/tmp/.w1retap.dat";
> +w1->tmpname = "/var/lib/w1retap/.w1retap.dat";
> 
> I don't think using /var/lib for tmp stuff is something 
> 
> this is a log, isn't /var/log something better?
> (with some logrotate stuff)
>

The /var/lib/w1retap directory contains the location for the default
w1retap data log file. If I were to record the data to PostgreSQL or
MySQL the actual data would end up somewhere else under /var/lib too.
Given that the data will be sensor readings (temperature, windspeed,
rainfall, etc) I would not expect this data to be rotated.

The ".w1retap.dat" file contains the last successful data reading. This
data can then be read by various other programs or scripts that only
want current readings (eg the current outside temperature). I think /tmp
is not the correct place to store it and I think that it does not fit
well into /var/log either. This is why I changed it to /var/lib.

 
> additional little points:
> - please enable hardening if possible, according to blhc 
> http://debomatic-amd64.debian.net/distribution#unstable/w1retap/1.4.4-1/blhc
> somebody is overriding flags
> 
> - 
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
> 
> 
> ^^ this is useless now
> 

I removed the above and I think the buildflags or the include was
overriding the flags. The build now includes "-fPIE
-fstack-protector-strong -Wformat -Werror=format-security" when
building.


> - why the upstream build system is creating all this stuff in /usr/bin?

Dallas Semiconductor Corp (now Maxim Integrated) created the 1-wire
standard and devices. They created a software release (confusingly
called libusblinux300.tar.gz) to interface with the devices. The idea
was to enable anyone to make use of the devices quickly without
restrictions. It was this software that was used to create the w1retap
project.

The upstream build system continues to create the sample utilities that
were included in the original software release. While these utilities
may be useful for w1retap development, to my knowledge they are not
required to actually run a w1retap setup. This is why I've not packaged
those extra binary's.


> - doc might be split easily into a w1retap-doc package
> 

Good idea, I've split it out and created w1retap-doc. This nicely
reduced the size of the main w1retap deb file. This also prompted me to
install another useful script called w1sensors.


> usr/lib/*/w1retap/libw1common.so*
> usr/lib/*/w1retap/libw1csv.so*
> usr/lib/*/w1retap/libw1file.so*
> usr/lib/*/w1retap/libw1serial.so*
> usr/lib/*/w1retap/libw1usb.so*
> usr/lib/*/w1retap/libw1xml.so*
> 
> what about a single
> usr/lib/*/w1retap/lib*.so* entry?
> 

I do like that shorter version, however that glob will match all the
available plugins. So it would also include mondo, mysql, odbc, etc.
For example libw1mongo.so.0 would be packaged in w1retap and
w1retap-mongo. I can't see a simple way to get around this.


> - why systemd as runtime dependency?
>

That looks like my mistake, I thought I needed to depend on it given
that I'm shipping a service file that starts the main daemon with
systemd. I have removed that dependency.


> - with compat 10 you can avoid --parallel and --with autoreconf
> 

Excellent, I've changed to compat 10.

> this should be enough for now (and probably now the review is complete)
> 
> last thing about your patch
> 
> -w1->rcfile = strdup("/etc/default/w1retap");
> +w1->rcfile

Bug#841375: [pkg-go] Bug#841375: RFS: golang-gopkg-square-go-jose.v1/1.1.0-1~bpo8+1

2016-10-21 Thread Peter Colberg 
Hi Tim,

Thanks for the quick uploads to jessie-backports.

Regarding the sponsorship process, I think RFS bugs are always
closed manually by the sponsoring DD, rather than by editing the
changelog after the sponsorship request. I have now force-pushed
updated debian/ tags; in case you kept copies of the repositories
on your local machine, you can update them with `git fetch --tags`.

Peter

Bug#841366: RFS: task-spooler/1.0-1

2016-10-21 Thread Alexander Inyukhin 
Thanks for helpful review.

I have uploaded the corrected package.


On Wed, Oct 19, 2016 at 06:48:16PM -0700, Sean Whitton wrote:
> Dear Alexander,
> 
> Some minor comments on your changelog entries.
> 
> On Wed, Oct 19, 2016 at 11:59:31PM +0300, Alexander Inyukhin wrote:
> >* New upstream version 1.0
> 
> It's superfluous to say "1.0" since the version number is two lines above.

Ok. This one comes from gbp.

> >
> >* Update patches
> 
> What do you mean?  Do you mean refresh them so they apply to the new
> upstream version?  It's conventional to write "Refresh patches" in that
> case.

Ok.

> >* Change homepage to http://viric.name/soft/ts/
> 
> Why?  Did the upstream site move?
> 
> If you write "Update homepage" it's implied that they moved it.

Technically, it is not a movement. Both addresses are working.
This address becomes the preferred one and it has been used in announcements
for a while.

Bug#841536: hdparm/9.50+ds-1

2016-10-21 Thread Alex Mestiashvili 
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: mailatgo...@gmail.com

Dear mentors,

 I am looking for a sponsor for my package "hdparm":

* Package name: hdparm
  Version : 9.50
  Upstream Author : Mark Lord 
* URL : http://sourceforge.net/projects/hdparm/files/hdparm/
* License : hdparm
  Section : Admin

  It builds following binary packages:
   - hdparm

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/hdparm

Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/h/hdparm/
hdparm_9.50+ds-1.dsc

More information about hdparm can be obtained from
  https://anonscm.debian.org/cgit/collab-maint/hdparm.git

Changes since last upload:

  * New upstream version 9.50+ds
  * Refresh quiet_sequrity_freeze.patch and update spelling.patch
  * Update copyright years

Best regards,
Alex

Re: lintian: spelling

2016-10-21 Thread Ben Finney 
Jakub Wilk  writes:

> [Disclaimer: I'm not a native speaker of English.]

(Credential: I am a native speaker of English.)

> > :param int max_no_dec: number of rounds we allow to be stuck
>
> Lintian complains about "allow to" because "allow" requires an object,

Yes, “allow” requires at least three referents: the party who grants
allowance, the actions allowed, and the party to whom allowance is
granted.

Example:

“Alice allows Bob to sit”.

“Alice”, “to sit”, “Bob” are the three terms functionining in the
grammar of the main verb “to allow”.

As is usual with natural language, many usages leave implicit some of
those terms.

Example:

“allowed to sit”

is a phrase that leaves both parties out. It functions as:

“ allowed  to sit”

> and in most cases[*] this object goes between "allow" and "to". But
> here, "number of rounds" is the object.

That is incorrect; “number of rounds” is not a direct part of the
grammar of “to allow”.

Rather “number of rounds” is part of the grammar of the descriptor
“stuck”; in this case, “stuck for ‘max_no_dec’ number of rounds”.

Thus the verb phrase “stuck for ‘max_no_dec’ number of rounds” is
distributed across the sentence. That is not bad, but it does make the
grammar more difficult for non-Anglophones to parse.


So a full explicit grammar of this statement would be:

We allow  to be stuck for ‘max_no_dec’ rounds.

Lintian is, correctly IMO, complaining because the statement leaves
unknown the party to whom the action is allowed.

> We allow $max_no_dec rounds to be stuck.

That is not grammatical; it implies “rounds [to be stuck]” is the party
to whom allowance is granted. That is not what this sentence means, so
the phrasing should not imply that.

I would suggest:

:param int max_no_dec: number of rounds we allow [FIXME] to be stuck.

where “[FIXME]” must be replaced with something explicit. Is it “the
program”? “the network connection”? Some other party? It's not
specified, and I think Lintian is correct to complain.

-- 
 \ “Books and opinions, no matter from whom they came, if they are |
  `\ in opposition to human rights, are nothing but dead letters.” |
_o__)  —Ernestine Rose |
Ben Finney

Re: lintian: spelling

2016-10-21 Thread Eduardo M KALINOWSKI 

On Sex, 21 Out 2016, Jakub Wilk wrote:

[Disclaimer: I'm not a native speaker of English.]

* Jerome BENOIT , 2016-10-21, 01:36:
is there a list where we can deal on how correct spelling error as  
detected by lintian ?


For the curious. In the source, there is the sentence:

:param int max_no_dec: number of rounds we allow to be stuck


Lintian complains about "allow to" because "allow" requires an  
object, and in most cases[*] this object goes between "allow" and  
"to". But here, "number of rounds" is the object. IOW, this line  
could be paraphrased as:


We allow $max_no_dec rounds to be stuck.


Perhaps also "number of rounds allowed to be stuck".
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: lintian: spelling

2016-10-21 Thread Jakub Wilk 

[Disclaimer: I'm not a native speaker of English.]

* Jerome BENOIT , 2016-10-21, 01:36:
is there a list where we can deal on how correct spelling error as detected by 
lintian ?


For the curious. In the source, there is the sentence:

:param int max_no_dec: number of rounds we allow to be stuck


Lintian complains about "allow to" because "allow" requires an object, and 
in most cases[*] this object goes between "allow" and "to". But here, "number 
of rounds" is the object. IOW, this line could be paraphrased as:


We allow $max_no_dec rounds to be stuck.

I'm not sure if there's a way to fix Lintian to avoid this kind of false 
positives. Maybe debian-l10n-english@ would know?



[*] I've seen dozens (or maybe even hundreds) of instances of "allow(s) to" 
when spell-checking random software, and it's the first time I see when it's 
not a mistake.


--
Jakub Wilk

Bug#841270: (no subject)

2016-10-21 Thread Paul Wise 
On Fri, Oct 21, 2016 at 3:37 PM, Dmitry Bogatov wrote:

> Cons:
>   - `debrequest' is written in Python3. Including it into `devscripts', 
> written
>  in Perl would not facilate code reuse and will complicate maintainace.
>  Depends, whether anyone in devescrips team can/want maintain python3 
> code.

devscripts already contains Python 3 code.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#841270: RFS: debrequest/0.2 ITP

2016-10-21 Thread Gianfranco Costamagna 
control: tags -1 moreinfo

>It might be more useful to add this to `devscripts` or some other
>existing package rather than adding a new package.



tagging moreinfo until devscripts developers gives us their opinion

G.

Bug#841270: (no subject)

2016-10-21 Thread Dmitry Bogatov 
Fcc: +sent
Subject: Re: Bug#841270: RFS: debrequest/0.2 ITP
In-reply-to: <1476954418.4434.8.ca...@43-1.org>
References:  
<1476954418.4434.8.ca...@43-1.org>
Comments: In-reply-to Ansgar Burchardt 
   message dated "Thu, 20 Oct 2016 11:06:58 +0200."
Sign: Yes


[2016-10-20 11:06] Ansgar Burchardt 
> It might be more useful to add this to `devscripts` or some other
> existing package rather than adding a new package.

Pros:
  - `debrequest' is developer tool, and probably will be installed only with
 `devscripts', so from user perspective making it part of `devscripts' is
 right thing.
Cons:
  - `debrequest' is written in Python3. Including it into `devscripts', written
 in Perl would not facilate code reuse and will complicate maintainace.
 Depends, whether anyone in devescrips team can/want maintain python3 code.

Added devscripts-devel@ into thread. Your opinions, devscripts maintainers?

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.