Bug#814083: marked as done (RFS: kwstyle/1.0.1+git3224cf2-1 [ITA])

2016-03-06 Thread Debian Bug Tracking System
Your message dated Mon, 7 Mar 2016 07:34:40 +
with message-id <20160307073440.gb22...@chase.mapreri.org>
and subject line Re: Bug#814083: RFS: kwstyle/1.0.1+git3224cf2-1 [ITA]
has caused the Debian Bug report #814083,
regarding RFS: kwstyle/1.0.1+git3224cf2-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.)


-- 
814083: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814083
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 "kwstyle"

 * Package name: kwstyle
   Version : 1.0.1+git3224cf2-1
   Upstream Author : Kitware, Inc.
 * URL : https://kitware.github.io/KWStyle/
 * License : BSD-4-clause-like
   Section : devel

  It builds those binary packages:

kwstyle- Style checker for source code

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

  http://mentors.debian.net/package/kwstyle


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

dget -x 
http://mentors.debian.net/debian/pool/main/k/kwstyle/kwstyle_1.0.1+git3224cf2-1.dsc

  You can find the current state of my packaging work at 
https://github.com/eikel/KWStyle-Debian

  Changes since the last upload:

   * New upstream release. Now hosted at https://github.com/Kitware/KWStyle.
   * Fix "FTBFS with GCC 6: no match for" by new upstream release
 (Closes: #811822)
   * New maintainer (Closes: #786984).
   * Remove get-orig-source. Pristine tar can be generated from pristine-tar
 branch.
   * Increase debhelper compatibility to v9.
   * debian/control: Change upstream URL.
   * debian/control: Fix typos in description.
   * debian/control: Set standards version to 3.9.6.
   * debian/copyright: Update after upstream code review and format.
   * debian/copyright: Change source URL.
   * debian/copyright: Add myself to copyright for Debian packaging.
   * debian/rules: Remove workaround for old CMake bug.
   * debian/rules: Do not override default debhelper CMake arguments.
   * Update man page KWStyle(1).

  Regards,
   Benjamin Eikel
--- End Message ---
--- Begin Message ---
On Mon, Mar 07, 2016 at 12:14:10PM +0800, Paul Wise wrote:
> On Sun, 06 Mar 2016 17:16:35 +0100 Benjamin Eikel wrote:
> 
> > I had a look at check-all-the-things. I added a quite simple patch for 
> > adding 
> > KWStyle to it (see attachment). Unfortunately, it does not work out of the 
> > box. KWStyle requires a configuration file that defines the style of your 
> > code 
> > (e.g., use tabs or spaces? How do your identifiers look like? Do you use 
> > spaces around operators?). KWStyle uses this style to check your code. As 
> > this 
> > style is different for nearly every project, it is difficult to provide a 
> > default configuration working in many cases.
> 
> Thanks for the patch, merged!

Thanks for the patch :)

And by myself, I uploaded kwstyle ;)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---


Bug#816968: RFS: broadcom-facetimehd/0.0.1~git20150229.1.8cc44d6 [ITP] -- DKMS driver for Broadcom PCIe cameras

2016-03-06 Thread Nobuhiro Iwamatsu
Hi,

I reviewed your package.

debian/changelog:
 foget colon after "closes". Please add colon.

debian/rules:
  When you build a package, you do not download other source code and
data from the Internet.
  Please remove install-frwr target from debian/rules and remove
firmware-broadcom-facetimehd package.
  If you can remove this target, you change section from non-free to main.
  About how to respond firmware, you can use the same method as
flashplugin-nonfree.

Best regards,
  Nobuhiro


2016-03-07 5:53 GMT+09:00 Jean Baptiste Favre :
> Package: sponsorship-requests
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Dear mentors,
>
> I am looking for a sponsor for my package "broadcom-facetimehd":
>
> * Package name: broadcom-facetimehd
>   Version : 0.0.1~git20150229.1.8cc44d6
>   Upstream Author : Sven Schnelle 
> * URL : https://github.com/patjak/bcwc_pcie
> * License : GPL2+
>   Section : nonfree/kernel
>   Programming Lang: C
>   Description : dkms source for the Broadcom 1570 PCIe webcam
>Broadcom 1570 PCIe webcam is a device driver to support the Facetime HD
>PCIe webcam found on recent Macbooks.
>
>This package provides the source code for factimehd kernel module and
>makes use of the DKMS build utility to install it for the running
>kernel.
>Needed firmware is provided by firmware-broadcom-pcie-webcam.
>
> It builds those binary packages:
>
>   broadcom-facetimehd-dkms - dkms source for the Broadcom 1570 PCIe webcam
>   firmware-broadcom-facetimehd - Binary firmware for the Broadcom 1570 PCIe 
> webcam
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/broadcom-facetimehd
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/non-free/b/broadcom-facetimehd/broadcom-facetimehd_0.0.1~git20150229.1.8cc44d6.dsc
>
> More information about broadcom-facetimehd can be obtained from 
> https://github.com/patjak/bcwc_pcie.
>
> Changes for the first upload:
>
>   * First package version (Closes #816958)
>
>
> Regards,
> Jean Baptiste Favre
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQJ8BAEBCgBmBQJW3Ji+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC
> NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc3h3YP/2XxxCEPt2/UHTaf49TNfPc3
> Nv3GZitcpOTGNZHSvjl37DxxKtVomyE9vl2KDXo/StrXmqtA/CR94IrC5GlcJgXz
> pi7YZEiqaKXXT0YlWEUqSM0cr8Dat6h22W668haI+Hcve8TsR96LqMamOayjoThu
> pgQpj6gaKfhQ0uF+f3mIACGFQXl8U5/nlaYpKm7VtpHTlGXXnU+zMd2bW9/iAnJv
> 9waSOYozdTjsjz5wXxAKtMnyRn+t6fTGche379nMK6/ndA1mbeMS0vaA3CLB7khu
> n1ly6vEhOLJmnEThS+AGEeAB0ZWEe8O0tAsC+3ysF1KnISMzEOmPqKNvpm7M+g/G
> vxEMu1nRXv2hxIYxZ6+D1dDNgqZ8rB3au691Nho4PkZfTmkDI6vl5Qx3QQyUm+a2
> FSLLQaAcoeLuZWWMO1N+JqRbJHm+C3gWhXoBmpcfpyfit+wRgd0o2124Kvn1CyzF
> jPz2zUcCVhABJL7FoR+0Z7D4qWkG7yBvNLEihfVYbXWuTEUb93gisAKa2kucDKx6
> ami4CEkkDwdc0FmISFRAW0E4gS50WE13Z+03AtLrW1d+TqJQbi72GGl7tTPfV9ij
> zlNhLUmmzYz81CLI/4U0DplPUFeeY9m5M0YJontYBV+0wKHCQCOG4+M58uRqKWjk
> MvjLQv5YfAuAA/KfIqrF
> =HaQp
> -END PGP SIGNATURE-
>



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



Bug#814083: RFS: kwstyle/1.0.1+git3224cf2-1 [ITA]

2016-03-06 Thread Paul Wise
On Sun, 06 Mar 2016 17:16:35 +0100 Benjamin Eikel wrote:

> I had a look at check-all-the-things. I added a quite simple patch for adding 
> KWStyle to it (see attachment). Unfortunately, it does not work out of the 
> box. KWStyle requires a configuration file that defines the style of your 
> code 
> (e.g., use tabs or spaces? How do your identifiers look like? Do you use 
> spaces around operators?). KWStyle uses this style to check your code. As 
> this 
> style is different for nearly every project, it is difficult to provide a 
> default configuration working in many cases.

Thanks for the patch, merged!

It will need some adjustments as a result of me adding the 'manual'
flag, but I'll do those later down the track when I go through all the
checks and flag things as manual where needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part


Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]

2016-03-06 Thread Fernando Toledo
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "aseqjoy"

 * Package name: aseqjoy
   Version : 0.0.1-1
   Upstream Author : Alexander Koenig 
 * URL : https://terminatorx.org/addons
 * License : GPL-2
   Section : sound

  It builds those binary packages:

aseqjoy- Joystick to ALSA MIDI Sequencer Converter

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

  http://mentors.debian.net/package/aseqjoy


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

dget -x
http://mentors.debian.net/debian/pool/main/a/aseqjoy/aseqjoy_0.0.1-1.dsc

  More information about aseqjoy can be obtained from
https://terminatorx.org/addons

  Changes since the last upload:

  fixes lintian warnings and try to hardening


thanks!

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar



Bug#814680: RFS: stp/2.1.2+dfsg-1 [ITP] -- Simple theorem prover

2016-03-06 Thread Marko Dimjašević
Hi all,

On Fri, 2016-02-26 at 17:42 -0800, Afif Elghraoui wrote:
> That's alright, you can go ahead. I would just add that the source for
> the second tarball be documented somewhere or configured to be
> downloaded in debian/watch with a second uscan line. Something like
> the
> following:
> 
> version=4
> 
> opts="dversionmangle=s/\+dfsg\d*$//" \
> https://github.com/stp/stp/tags \
> (?:.*/)?v?(\d[\d\.]*)\.tar\.gz \
> debian
> 
> opts="dversionmangle=s/\+dfsg\d*$//,component=outputcheck" \
> https://github.com/stp/OutputCheck/tags \
> (?:.*/)?v?(\d[\d\.]*)\.tar\.gz \
> ignore uupdate

Thank you Afif for this!

I am not sure what is the cause (maybe incorrect paths in debian/rules),
but when I try to build with gbp like this:

$ BUILDER=pbuilder gbp buildpackage --git-pbuilder -us -uc -j8

it fails because it can't find a helper binary I build along the way
(needed to execute tests):

lit.py: lit.cfg:117: fatal: Cannot find OutputCheck
executable: /build/stp-2.1.2+dfsg/utils/OutputCheck/bin/OutputCheck

However, it does work in a plain pbuilder instance.


Anyhow, I pushed to the repo your version of d/watch to a separate
branch called 'mut-test':

https://anonscm.debian.org/git/debian-science/packages/stp.git/log/?h=mut-test

You can confirm for yourself it fails by e.g. switching to the mut-test
branch and running this:

$ BUILDER=pbuilder gbp buildpackage --git-ignore-branch --git-pbuilder
-us -uc -j8


Any clue what went wrong?

I looked at the tests/query-files/lit.cfg config file/script in
question, but I don't see why it would fail.


-- 
Regards,
Marko Dimjašević  .   University of Utah
https://dimjasevic.net/marko . PGP key ID: 1503F0AA
Learn email self-defense!  https://emailselfdefense.fsf.org


signature.asc
Description: This is a digitally signed message part


Bug#816968: RFS: broadcom-facetimehd/0.0.1~git20150229.1.8cc44d6 [ITP] -- DKMS driver for Broadcom PCIe cameras

2016-03-06 Thread Jean Baptiste Favre
Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

I am looking for a sponsor for my package "broadcom-facetimehd":

* Package name: broadcom-facetimehd
  Version : 0.0.1~git20150229.1.8cc44d6
  Upstream Author : Sven Schnelle 
* URL : https://github.com/patjak/bcwc_pcie
* License : GPL2+
  Section : nonfree/kernel
  Programming Lang: C
  Description : dkms source for the Broadcom 1570 PCIe webcam
   Broadcom 1570 PCIe webcam is a device driver to support the Facetime HD
   PCIe webcam found on recent Macbooks.

   This package provides the source code for factimehd kernel module and
   makes use of the DKMS build utility to install it for the running
   kernel.
   Needed firmware is provided by firmware-broadcom-pcie-webcam.

It builds those binary packages:

  broadcom-facetimehd-dkms - dkms source for the Broadcom 1570 PCIe webcam
  firmware-broadcom-facetimehd - Binary firmware for the Broadcom 1570 PCIe 
webcam

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

http://mentors.debian.net/package/broadcom-facetimehd

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

dget -x 
http://mentors.debian.net/debian/pool/non-free/b/broadcom-facetimehd/broadcom-facetimehd_0.0.1~git20150229.1.8cc44d6.dsc

More information about broadcom-facetimehd can be obtained from 
https://github.com/patjak/bcwc_pcie.

Changes for the first upload:

  * First package version (Closes #816958)


Regards,
Jean Baptiste Favre

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJW3Ji+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC
NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc3h3YP/2XxxCEPt2/UHTaf49TNfPc3
Nv3GZitcpOTGNZHSvjl37DxxKtVomyE9vl2KDXo/StrXmqtA/CR94IrC5GlcJgXz
pi7YZEiqaKXXT0YlWEUqSM0cr8Dat6h22W668haI+Hcve8TsR96LqMamOayjoThu
pgQpj6gaKfhQ0uF+f3mIACGFQXl8U5/nlaYpKm7VtpHTlGXXnU+zMd2bW9/iAnJv
9waSOYozdTjsjz5wXxAKtMnyRn+t6fTGche379nMK6/ndA1mbeMS0vaA3CLB7khu
n1ly6vEhOLJmnEThS+AGEeAB0ZWEe8O0tAsC+3ysF1KnISMzEOmPqKNvpm7M+g/G
vxEMu1nRXv2hxIYxZ6+D1dDNgqZ8rB3au691Nho4PkZfTmkDI6vl5Qx3QQyUm+a2
FSLLQaAcoeLuZWWMO1N+JqRbJHm+C3gWhXoBmpcfpyfit+wRgd0o2124Kvn1CyzF
jPz2zUcCVhABJL7FoR+0Z7D4qWkG7yBvNLEihfVYbXWuTEUb93gisAKa2kucDKx6
ami4CEkkDwdc0FmISFRAW0E4gS50WE13Z+03AtLrW1d+TqJQbi72GGl7tTPfV9ij
zlNhLUmmzYz81CLI/4U0DplPUFeeY9m5M0YJontYBV+0wKHCQCOG4+M58uRqKWjk
MvjLQv5YfAuAA/KfIqrF
=HaQp
-END PGP SIGNATURE-



Bug#791463: Quick review

2016-03-06 Thread Pali Rohár
On Sunday 06 March 2016 10:24:05 Andrew Shadura wrote:
> On 6 March 2016 at 09:50, Pali Rohár  wrote:
> >> > It is because "debian/rules clean" calls only "bmake clean"
> >> > which does not delete autogenerated file Makefile. That is
> >> > deleted by another target "bmake cleandir".
> >> > 
> >> > So version 20150606-2 still does not work for udfclient.
> >> > 
> >> > Now I think that I should stay with my implementation which is
> >> > working instead experimenting with --buildsystem=bmake..
> >> 
> >> For that, there's debian/clean, where you delete the autogenerated
> >> file, just as you'd do if you had autoconf+gmake.
> > 
> > But should not be cleandir part of that --buildsystem=bmake? Or why
> > not?
> 
> You're actually very right in this, I'm going to implement that right
> now.

Now I tested bmake version 20160220-2 and looks like it is working... 
Should I upload new version to mentors?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.


Bug#816919: RFS: newsbeuter/2.9-1 [ITA]

2016-03-06 Thread Nikos Tsipinakis
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "newsbeuter"

* Package name: newsbeuter
  Version : 2.9-1
  Upstream Author : Andreas Krennmair 
* URL : https://github.com/akrennmair/newsbeuter
* License : MIT
  Section : net

It builds those binary packages:

   newsbeuter - text mode rss feed reader with podcast support
   newsbeuter-dbg - debugging symbols for newsbeuter

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

  http://mentors.debian.net/package/newsbeuter


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

   dget -x 
http://mentors.debian.net/debian/pool/main/n/newsbeuter/newsbeuter_2.9-1.dsc

Changes since the last upload:

  * New upstream release. (Closes: #776728)
  * Fix sefault when downloading podcasts.
  * Bumped standards to 3.9.7
  * Updated watch file.
  * New maintainer.

Best Regards,
 Nikos Tsipinakis



Bug#814083: RFS: kwstyle/1.0.1+git3224cf2-1 [ITA]

2016-03-06 Thread Mattia Rizzolo
control: tag -1 pending

On Sun, Mar 06, 2016 at 01:07:10PM +0100, Benjamin Eikel wrote:
> I worked on all the points on your list and pushed my changes to the 
> aforementioned GitHub repository. Please review them and give feedback.

everything's cool for me now.
I can't upload right now because I'm on a shitty network, etc, etc.
I'll do later today or tomorrow at most.

Anyway, I'd like to ask you for a thing: we have this nifty package in
debian, check-all-the-things [0], which runs a huge number of linters
and checkers and whatnot over a directory, proving a huge report.  The
maintainer asked if I'm able to provide a patch adding a check based on
KWStyle; I tried it (clearly, I never heard of this thing before your
RFS) but didn't succed in producing a readable output.  Given that I
hope you are able to use this tool, would like to spend some minutes
working on a patch for it?  It's really easy, see doc/README [1] for
kind of short instruction; basically, it's just adding a paragraph in
data/c [2], just glancing over this file is enough to have an idea of
what is needed :)


[0] links:
https://tracker.debian.org/pkg/check-all-the-things
https://packages.debian.org/experimental/check-all-the-things
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git
[1]
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git
[2]
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/c

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#814083: RFS: kwstyle/1.0.1+git3224cf2-1 [ITA]

2016-03-06 Thread Benjamin Eikel
Hi Mattia,

On Wednesday 02 March 2016 13:16:14 Mattia Rizzolo wrote:
> control: owner -1 !
> control: tag -1 moreinfo
> 
> Hi Benjamin!
> 
> On Sat, Feb 06, 2016 at 07:15:04PM +0100, Benjamin Eikel wrote:
> >   I am looking for a sponsor for my package "kwstyle"
> 
> Cool, I'm available to review and sponsor this :)

thank you for the interest in sponsoring the package!

> 
> >   You can find the current state of my packaging work at
> >   https://github.com/eikel/KWStyle-Debian
> yay, git!  I'll work with that, everything is easier with git.
> Since you don't seem to have access to collab-maint, I'm happy to repush
> there everything once this upload is done :)
> I'm sadly not willing to advocate for collab-maint access in this case.
> 
> 
> Let's start the fun!
> 
> * This is a nice update, cool work!
> * please revert b6963ab31cd4dddb922471da7ae190790c7ed2b2, cme did the
>   right thing, the current version of policy is 3.9.7.
> * in d/rules those lines are useless, please remove them:
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
>   You should read debhelper(7), in particular the changes done with
>   compat level 9.
> * unused-file-paragraph-in-dep5-copyright paragraph at line 192
>   + that's because those files are also reported on the next paragraph,
> with different copyright; please meld the paragraphs
> * can you consider enabling hardening buildflags?
> * at the end of the iteration please bump the changelog entry

I worked on all the points on your list and pushed my changes to the 
aforementioned GitHub repository. Please review them and give feedback.

Kind regards
Benjamin

signature.asc
Description: This is a digitally signed message part.


Bug#791463: Quick review

2016-03-06 Thread Pali Rohár
On Sunday 06 March 2016 10:28:31 Pali Rohár wrote:
> On Sunday 06 March 2016 10:24:05 Andrew Shadura wrote:
> > On 6 March 2016 at 09:50, Pali Rohár  wrote:
> > >> > It is because "debian/rules clean" calls only "bmake clean"
> > >> > which does not delete autogenerated file Makefile. That is
> > >> > deleted by another target "bmake cleandir".
> > >> > 
> > >> > So version 20150606-2 still does not work for udfclient.
> > >> > 
> > >> > Now I think that I should stay with my implementation which is
> > >> > working instead experimenting with --buildsystem=bmake..
> > >> 
> > >> For that, there's debian/clean, where you delete the
> > >> autogenerated file, just as you'd do if you had autoconf+gmake.
> > > 
> > > But should not be cleandir part of that --buildsystem=bmake? Or
> > > why not?
> > 
> > You're actually very right in this, I'm going to implement that
> > right now.
> 
> Ok, but first please check which target should be really tried to be
> called and in which order... I think on some freebsd system (when
> using bmake?) is cleandir called two times. But I'm not sure.

See: http://www.freebsd.org/cgi/man.cgi?build(7)

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.


Bug#791463: Quick review

2016-03-06 Thread Pali Rohár
On Sunday 06 March 2016 10:24:05 Andrew Shadura wrote:
> On 6 March 2016 at 09:50, Pali Rohár  wrote:
> >> > It is because "debian/rules clean" calls only "bmake clean"
> >> > which does not delete autogenerated file Makefile. That is
> >> > deleted by another target "bmake cleandir".
> >> > 
> >> > So version 20150606-2 still does not work for udfclient.
> >> > 
> >> > Now I think that I should stay with my implementation which is
> >> > working instead experimenting with --buildsystem=bmake..
> >> 
> >> For that, there's debian/clean, where you delete the autogenerated
> >> file, just as you'd do if you had autoconf+gmake.
> > 
> > But should not be cleandir part of that --buildsystem=bmake? Or why
> > not?
> 
> You're actually very right in this, I'm going to implement that right
> now.

Ok, but first please check which target should be really tried to be 
called and in which order... I think on some freebsd system (when using 
bmake?) is cleandir called two times. But I'm not sure.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.


Bug#791463: Quick review

2016-03-06 Thread Andrew Shadura
On 6 March 2016 at 09:50, Pali Rohár  wrote:
>> > It is because "debian/rules clean" calls only "bmake clean" which
>> > does not delete autogenerated file Makefile. That is deleted by
>> > another target "bmake cleandir".
>> >
>> > So version 20150606-2 still does not work for udfclient.
>> >
>> > Now I think that I should stay with my implementation which is
>> > working instead experimenting with --buildsystem=bmake..
>>
>> For that, there's debian/clean, where you delete the autogenerated
>> file, just as you'd do if you had autoconf+gmake.
>
> But should not be cleandir part of that --buildsystem=bmake? Or why not?

You're actually very right in this, I'm going to implement that right now.

-- 
Cheers,
  Andrew



Bug#816192: RFS: python-proselint/0.3.5-1 [ITP] -- A prose linter

2016-03-06 Thread Paul Wise
On Sun, Feb 28, 2016 at 11:53 PM, Víctor Cuadrado Juan wrote:

> I am looking for a sponsor for my package "python-proselint"
...
> Proselint aggregates knowledge about best practices in writing from world's
> greatest writers and editors, and makes it accessible by giving suggestions in
> the form of a linter for prose.

This sounds useful, thanks for packaging it.

Here is a review:

I can't find a copy of the BSD license grant in the upstream tarball
at all, only in PKG-INFO and setup.py. I'm not sure this is good
enough for ftp-master approval. Please talk to upstream about
including a license grant in a README or in setup.py or something.
They have a LICENSE.md file in their github repository so they
probably just forgot to include it and README.md and other files in
the source distribution.

The upstream test system assumes proselint is installed instead of
testing the code in the source tree.

The proselint command when installed prints a lot of exceptions.

It would be great if upstream would sign their releases using OpenPGP.

https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
https://help.riseup.net/en/security/message-security/openpgp/best-practices

I'm not sure you need separate Python 2 and Python 3 packages. Are
there any users of the proselint Python module apart from the
proselint command-line tool? If not I would just create a proselint
binary package that uses Python 3.

Either way you definitely do not need proselint and proselint3
command-line tools, since they offer identical functionality.

If you decide on a proselint package, it should be Section: text, not
Section: python.

I would suggest to forward the manual page upstream. If they want to
have the manual page automatically generated, the options I know of
include sphinx and sphinxcontrib-autoprogram or
python3-sphinx-argparse.

Upstream may want to add shell completion, which can be done
automatically using python3-argcomplete.

You may want to wrap and sort the debian/ packaging to make diffs
easier to read. I use this:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma --verbose

I'm seeing a disturbing amount of calls to subprocess functions with
shell=True or where equivalent Python functions could be used, please
send upstream a patch to avoid using subprocess or call functions from
it without using shell=True. Forking subprocesses is more expensive
than handling it in Python and using shell=True can be potentially
dangerous so it is a bad habit to get into even if it is safe where
used in proselint (if it is not, they need to issue some security
advisories). The Process Identifier Preservation Society will thank
you!

http://bonedaddy.net/pabs3/log/2014/02/17/pid-preservation-society/
http://oss-security.openwall.org/wiki/disclosure/cve

No need for shell=True:

out = subprocess.check_output("proselint --version", shell=True)
subprocess.call("proselint --debug >/dev/null", shell=True)

Potentially dangerous depending on the arguments:

out = subprocess.check_output("proselint {}".format(fullpath), shell=True)
subprocess.call("{} {}".format("open", fullpath), shell=True)
subprocess.call("proselint {} >/dev/null".format(filepath), shell=True)

Use the python equivalents instead:

subprocess.call("find . -name '*.pyc' -delete", shell=True)
subprocess.call("rm -rfv proselint/cache > /dev/null && mkdir -p
{}".format(os.path.join(os.path.expanduser("~"), ".proselint")),
shell=True)

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

Automatic checks:

build:

I: pybuild base:184: cd
/build/python-proselint-0.3.5/.pybuild/pythonX.Y_2.7/build; python2.7
-m unittest discover -v
/bin/sh: 1: proselint: not found

[(1, 15, 'garner.dates', u"When specifying a date range, write 'from X to Y'.")]
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored
I: pybuild base:184: cd
/build/python-proselint-0.3.5/.pybuild/pythonX.Y_3.5/build; python3.5
-m unittest discover -v
/bin/sh: 1: proselint: not found

lintian:

P: python-proselint source: debian-watch-may-check-gpg-signature
X: python3-proselint: library-package-name-for-application usr/bin/proselint3
X: python3-proselint: application-in-library-section python usr/bin/proselint3
P: python3-proselint: no-upstream-changelog
X: python-proselint: library-package-name-for-application usr/bin/proselint
X: python-proselint: application-in-library-section python usr/bin/proselint
P: python-proselint: no-upstream-changelog

check

Bug#791463: Quick review

2016-03-06 Thread Pali Rohár
On Sunday 06 March 2016 08:59:53 Andrew Shadura wrote:
> On 6 March 2016 at 01:20, Pali Rohár  wrote:
> > First dpkg-buildpackage call works, but calling it secondary fails
> > with:
> > 
> > dpkg-source: info: local changes detected, the modified files are:
> >  udfclient-0.8.1/Makefile
> > 
> > It is because "debian/rules clean" calls only "bmake clean" which
> > does not delete autogenerated file Makefile. That is deleted by
> > another target "bmake cleandir".
> > 
> > So version 20150606-2 still does not work for udfclient.
> > 
> > Now I think that I should stay with my implementation which is
> > working instead experimenting with --buildsystem=bmake..
> 
> For that, there's debian/clean, where you delete the autogenerated
> file, just as you'd do if you had autoconf+gmake.

But should not be cleandir part of that --buildsystem=bmake? Or why not?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.


Bug#791463: Quick review

2016-03-06 Thread Andrew Shadura
On 6 March 2016 at 01:20, Pali Rohár  wrote:
> First dpkg-buildpackage call works, but calling it secondary fails with:
>
> dpkg-source: info: local changes detected, the modified files are:
>  udfclient-0.8.1/Makefile
>
> It is because "debian/rules clean" calls only "bmake clean" which does
> not delete autogenerated file Makefile. That is deleted by another
> target "bmake cleandir".
>
> So version 20150606-2 still does not work for udfclient.
>
> Now I think that I should stay with my implementation which is working
> instead experimenting with --buildsystem=bmake..

For that, there's debian/clean, where you delete the autogenerated
file, just as you'd do if you had autoconf+gmake.

-- 
Cheers,
  Andrew