Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

[Cornelius Kölbel]

Hi Daniel,

what do you need me to do?
As the poster of RFS do I need to take action?

Thanks
Cornelius


Am Sonntag, den 25.10.2015, 22:00 +0100 schrieb Daniel Stender:
> My idea with this would be, close the RFS for now, then file RFP and
> wishlist-please-update bugs with blocks against the ITP as a todo list.
> 
> Needs some aforestation, when everything is available privacyidea goes into
> NEW. Like said, I think I've seen that most of the packages are group 
> maintained
> (with Python group in Maintainers field), that's good.
> 
> Daniel
> 



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

Bug#801213: marked as done (RFS: python-privacyidea/2.7-1 [ITP])

[Debian Bug Tracking System]

Your message dated Mon, 26 Oct 2015 11:33:28 +0100
with message-id <1445855608.4229.33.camel@puckel>
and subject line No Sponsor needed
has caused the Debian Bug report #801213,
regarding RFS: python-privacyidea/2.7-1 [ITP]
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.)


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

 * Package name: python-privacyidea
   Version : 2.7-1
   Upstream Author : cornel...@privacyidea.org
 * URL : http://privacyidea.org
 * License : AGPLv3
   Section : python

It builds a long list of binary packages (maybe to many):

privacyidea-all - two-factor authenticaion system. This is a metapackage
to install
privacyidea-apache-client - Auth Module for Apache Server to
authenticate with OTP
privacyidea-apache2 - 2FA system. This is a meta package to install with
apache2
privacyidea-nginx - 2FA system. This is a meta package to install with
nginx
privacyidea-otrs - OTRS module for privacyIDEA, OTP authentication
privacyidea-pam - PAM module for privacyIDEA, OTP authentication
privacyidea-radius - FreeRADIUS module for privacyIDEA, OTP
authentication
privacyidea-simplesamlphp - SimpleSAMLphp module for privacyIDEA to do
two factor authenticat
python-privacyidea - two-factor authentication system e.g. for OTP
devices

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

  http://mentors.debian.net/package/python-privacyidea


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

dget -x
http://mentors.debian.net/debian/pool/main/p/python-privacyidea/python-privacyidea_2.7-1.dsc

privacyIDEA is a sophisticated solution for managing all kinds of two
factor authentication devices like HOTP, TOTP tokens, TiQR, U2F, Google
Authenticator, SSH keys, X509 certs...
More information can be found at the project page
https://privacyidea.org or at the github repo
https://github.com/privacyidea/privacyidea



Thanks a lot and kind regards
Cornelius
--- End Message ---
--- Begin Message ---
Close the request-for-sponsor sind Daniel Stender will create the
package and take care about uploading.



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

Re: Package upload successful but not processed

[Gianfranco Costamagna]

Hi, let me know if you need a sponsor.

quick review:

- priority should be optional I guess
- copyright is outdated, and also
"repackaged to exclude copies of jquery, bootstrap, elycharts and raphael"
needs an update

- watch file should point to the get-orig-source target (look e.g. to 
virtualbox package)
or maybe use the files-excluded copyright feature to automagically have a dfsg 
package

optional

- I would appreciate running minifyjs (or whatever is called) to recreate the 
jquery.min.js at build time

cheers,

G.


Il Domenica 25 Ottobre 2015 17:34, Andreas Moog  ha 
scritto:
Hello there,

I am a Debian Maintainer and wanted to upload a new release of a package I
have upload rights to. The upload seemed successful:

"nzbget_16.0+dfsg-1_amd64.changes uploaded successfully to localhost"

but I didn't receive a second message that the upload was accepted, nor that
it was declined. Then I noticed that my gpg key was expired, so I changed the
expiry date and sent the key to keyring.debian.org. I then tried 2 more times
to upload the package, but same result (no accept or decline mail).

It's totally possible that I made a mistake with the uploads, but I need help
to find out what I did wrong.

Thanks for your support!

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

[Cornelius Kölbel]

close 801213

Am Montag, den 26.10.2015, 11:01 +0100 schrieb Daniel Stender:
> On 26.10.2015 10:47, Cornelius Kölbel wrote:
> > Hi Daniel,
> > 
> > what do you need me to do?
> > As the poster of RFS do I need to take action?
> > 
> > Thanks
> > Cornelius
> > 
> > Am Sonntag, den 25.10.2015, 22:00 +0100 schrieb Daniel Stender:
> >> My idea with this would be, close the RFS for now, then file RFP and
> >> wishlist-please-update bugs with blocks against the ITP as a todo list.
> >>
> >> Needs some afforestation, when everything is available privacyidea goes 
> >> into
> >> NEW. Like said, I think I've seen that most of the packages are group 
> >> maintained
> >> (with Python group in Maintainers field), that's good.
> >>
> >> Daniel
> 
> Yes, I didn't closed it because it's not my bug, that should do the reporter.
> 
> I've made a "afforestation" before for Prospector, there were ... I think ... 
> more
> than ten things outdated or not available. I'm going to help with uploads in 
> the groups,
> and I would really see Privacyidea in Debian at the year's turn (depends on 
> how long
> the missing packages are going to be in NEW), for Debian 9 there's nothing 
> against it.
> I'm on it (owner of the ITP bug)!
> 
> Best,
> Daniel
> 

-- 


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

Re: conditionally require dependency

[Nico Schlömer]

Thanks again, Josch!

The least painful thing for us to maintain is certainly the templating
idea. I now created a control.in, rules.in, ready to serve as templates for
the generation of the proper rules, control files. envsubst helps in
getting the templates values in [1].

Cheers,
Nico

[1]
https://bitbucket.org/fathomteam/moab/pull-requests/137/clean-up-debian-folder/diff#chg-debian/GNUmakefile



On Mon, Oct 26, 2015 at 8:55 AM Johannes Schauer  wrote:

> Hi Nico,
>
> Quoting Nico Schlömer (2015-10-26 00:47:54)
> > particularly those which have been released a while ago and are closed
> > to adding now packages now.
>
> packages can be added via backports.
>
> > > - if you were talking about a *build* dependency, then you can generate
> > these
> > >   before building by having a debian/control.in and turning that into
> the
> > >   right debian/control depending on what you want to build
> >
> > Good idea. I'll look into it.
>
> remember that the other way I mentioned, having different git branches for
> different target distributions would also apply for your use case.
>
> > >  - alternatively, if you were talking about a *build* dependency you
> > could use
> > >build profiles to selectively enable or disable build dependencies
> >
> > Never heard of it. I'll check it out as well.
>
> This would work technically but there is no accepted way to do this in
> practice
> yet in Debian or Ubuntu. Build profiles allow you to select or unselect
> build
> dependencies depending on conditions you specify in the Build-Depends
> line. So
> technically it would be possible to say that a build dependency should
> only be
> used if the profiles "debian" and "unstable" are active and then when you
> build
> your source package you would have to take care to have the right profiles
> active per build with the DEB_BUILD_PROFILES environment variable or with
> the
> -P option to dpkg-buildpackage. There is more info on
> https://wiki.debian.org/BuildProfileSpec But remember that at this point
> this
> would just be another hack! While build profiles can be used this way to
> support multiple distributions and releases with a single debian/control
> file,
> there is not yet any decision (or even the attempt to have it) of how the
> build
> profiles should be named for this use case.
>
> cheers, josch
>

Re: Problem uploading gccintro-es

[davidam]

El 23/10/15 a las 17:46, Herbert Parentes Fortes Neto (hpfn) escribió:
> Hi,
>
>>
>> I've upload my debian package gccintro-es with dput, my dput.cfg is:
>>
>> [mentors]
>> fqdn = mentors.debian.net
>> incoming = /upload
>> method = http
>> allow_unsigned_uploads = 0
>> progress_indicator = 2
>> # Allow uploads for UNRELEASED packages
>> allowed_distributions = .*
>>
>> The upload process was successful and now says:
>>
>> $ dput mentors gccintro-es_1.0-1_amd64.changes
>> Package has already been uploaded to mentors on mentors.debian.net
>> Nothing more to do for gccintro-es_1.0-1_amd64.changes
>>
>> How can I see my debian package?
>>
>> In http://mentors.debian.net/packages/index doesn't appear. What's
>> happenning?
>>
>> lintian doesn't report errors or warnings in my package.
>>
>
> Did you received the email from mentors confirming ?
>
>
> regards,
>

Not, I didn't.

Re: conditionally require dependency

[Johannes Schauer]

Hi Nico,

Quoting Nico Schlömer (2015-10-26 00:47:54)
> particularly those which have been released a while ago and are closed
> to adding now packages now.

packages can be added via backports.

> > - if you were talking about a *build* dependency, then you can generate
> these
> >   before building by having a debian/control.in and turning that into the
> >   right debian/control depending on what you want to build
> 
> Good idea. I'll look into it.

remember that the other way I mentioned, having different git branches for
different target distributions would also apply for your use case.

> >  - alternatively, if you were talking about a *build* dependency you
> could use
> >build profiles to selectively enable or disable build dependencies
> 
> Never heard of it. I'll check it out as well.

This would work technically but there is no accepted way to do this in practice
yet in Debian or Ubuntu. Build profiles allow you to select or unselect build
dependencies depending on conditions you specify in the Build-Depends line. So
technically it would be possible to say that a build dependency should only be
used if the profiles "debian" and "unstable" are active and then when you build
your source package you would have to take care to have the right profiles
active per build with the DEB_BUILD_PROFILES environment variable or with the
-P option to dpkg-buildpackage. There is more info on
https://wiki.debian.org/BuildProfileSpec But remember that at this point this
would just be another hack! While build profiles can be used this way to
support multiple distributions and releases with a single debian/control file,
there is not yet any decision (or even the attempt to have it) of how the build
profiles should be named for this use case.

cheers, josch


signature.asc
Description: signature

Re: Available locales in a buildd

[Gianfranco Costamagna]

Hi,

developer=jwilk

No Jakub, thanks to $developer for writing the tool :)



cheers,


G.




Il Domenica 25 Ottobre 2015 22:30, Jakub Wilk  ha scritto:
* Jakub Wilk , 2015-10-04, 18:24:
>If someone packaged localehelper[0] (hint, hint), then you could 
>replace these 5 lines with simple:
>
>localehelper LC_ALL=en_US.UTF_8 dh_auto_build

localehelper is now available in unstable. Thanks to Jonathan Ulrich 
Horn and Gianfranco Costamagna for making it happen.


-- 
Jakub Wilk

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Am 26.10.2015 um 19:00 schrieb Gianfranco Costamagna:
> Hi, the packaging looks good to me (note: I didn't do a full review)

Hi, thanks for looking at my package!

> however I don't like your dh_auto_install target override.
> 
> dh_auto_install should install into debian/tmp, not into debian/package.

I installed into debian/package because "man dh_auto_install" told me
that "[...]the files are installed into debian/package/ if there is only
one binary package. In the multiple binary package case, the files are
instead installed into debian/tmp/ [...]".
Although there is no reason given why it should be debian/package in one
case and debian/tmp in the other. What's the difference?

> I propose you to use dh_install like this:
> 
> override_dh_install:
> 
> DESTDIR=$(CURDIR)/debian/gnome-twitch ninja -C build install
> 
> what do you think?

I overrode dh_auto_install because that is where "normally" (when using
autotools for example) the "make install" stage of the process is
executed, right?
And the "ninja install" command would be my equivalent of that "make
install".
After that, I thought, dh_install could be used to install files that
were not picked up by the call to make (or ninja in my case).

If that is not the case, what difference does overriding dh_install make
in contrast to overriding dh_auto_install? Both seem to produce a
working package for me.

Also, the command you proposed would also install into
debian/gnome-twitch, but at the top you said I should be installing into
debian/tmp? I'm a little confused ;)

> you could also use MAKE=ninja and
> $(MAKE) during the calls, to keep it simple and possible to easily change the 
> build system.

While writing an answer to this, I just realized that make also takes
the -C option, I didn't know that before.
So yes, that would probably be a good idea, I'll do that.

--
Tim

Re: restund in debian

[Simon Josefsson]

I have prepared a Debian package for the latest 0.4.14 release of
"libre", and have uploaded it to Debian Mentors:

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

For reference, upstream homepage and ITP bug links:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636272
  http://www.creytiv.com/re.html

Please review the package, I want it to be in perfect condition!
Anything that appears sub-optimal is something I want to learn about.

As you can see, the build system is ad-hoc, which is always a challenge
for shared libraries.  I'm not certain the way the soname, symbol list,
and everything around the shared library part is kosher.

A temporary git repository for the packaging exists.  I plan to move
this to alioth before proper upload to Debian, hoping to make this a
pkg-voip team maintained package.

  https://github.com/jas4711/libre-dpkg

/Simon


signature.asc
Description: PGP signature

Bug#798990: marked as done (RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP)

[Debian Bug Tracking System]

Your message dated Mon, 26 Oct 2015 12:13:34 + (UTC)
with message-id <201743322.4550988.1445861614414.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy 
files via FTP
has caused the Debian Bug report #798990,
regarding RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP
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.)


-- 
798990: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798990
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package "webdeploy":
 
 * Package name : webdeploy
 Version : 1.0-1
 Upstream Author : Daniel Bailey d...@nielbailey.com
 * URL : http://bitofahack.com/projects/webdeploy/
 * License : GPL v3+
 Section : web
 
 webdeploy is a really simple program for deploying changed and new files
from a local directory to an FTP server. It is easy to use and configure
and is not tied to any VCS. It is designed to be useful even when you are
not using a VCS. I believe this will make it desirable over packages such
as git-ftp (https://packages.debian.org/jessie/git-ftp) in situations
where a full VCS is not desired.

The source package is available here:
 http://bitofahack.com/projects/webdeploy/

webdeploy is also on github here:
https://github.com/danieljabailey/webdeploy

This is my first package. It's probably got issues I need to sort, I just don't 
know what they are yet.
 
 Regards,
 Daniel Bailey
--- End Message ---
--- Begin Message ---
Hi, Built, thanks for your contribution to Debian!

cheers,
G.




Il Domenica 25 Ottobre 2015 15:36, Daniel Bailey  ha 
scritto:



Okay, I have now [after a busy week] added a watch file and uploaded the 
package again. The mentors page now shows that the package is the latest 
upstream version.

Dan.


On 19/10/15 20:36, Gianfranco Costamagna wrote:

mmm you need one anyway... 
>I can help you writing one, or you can just look at the uscan manpage (or 
>debian wiki for uscan) and you will find many examples.
>
>
>you might stop being interested in the debian packaging (or find it too 
>difficult to maintain), you might become MIA... people might adopt the package 
>if being orphaned, so having a watch file will guarantee the continuity of the 
>project (Debian side)
>
>
>cheers,
>
>
>G.
>
>
>Sent from Yahoo Mail on Android
>
> 
>From:"Daniel Bailey" 
>Date:Mon, 19 Oct, 2015 at 21:15
>Subject:Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP
>
>
>Okay, I have added a homepage.
>I see there is also a watch file warning.
>Do I need to have a watch file?
>As I am both the developer and the package
  maintainer, I suppose I don't 
>need one?
>
>Dan.
>
>
>On 19/10/15 13:04, Gianfranco Costamagna
   wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi Daniel,
>>
>> sorry for the late answer, I guess the
   package is ready, but I found a
>> little issue
>>
>> P: webdeploy: no-homepage-field
>> N:
>> N:This non-native package lacks a
   Homepage field. If the package
>> has an
>> N:upstream home page that contains
   useful information or resources
>> for the
>> N:end user, consider adding a
   Homepage control field to
>> debian/control.
>> N:
>> N:Refer to Debian Policy Manual
   section 5.6.23 (Homepage) for detail
>> s.
>> N:
>> N:Severity: pedantic, Certainty:
   possible
>> N:
>> N:Check: fields, Type: binary,
   udeb, source
>> N:
>>
>>
>> can you please add the Homepage field
   to control file?
>>
>> we have no watch file, no homepage in
   control/copyright files, seems
>> that people won't be able to find
   updates and find the upstream website.
>>
>> cheers,
>>
>> G.
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>>
   
iQIcBAEBCAAGBQJWJNxSAAoJEPNPCXROn13ZGdsQAMuXXbTwzWmme9h+vD1OWaCA
>>
   
mvJ5CEVCxBWd8xQvrbMvDU/nePbT0swCyUU4ZFt7acaTVu1Ku23DMVwWxSoIgRWK
>>
   
ljECs/KO6TDohDW6aoPg7t9oCSYTcrb4mMnYg/PzFhB0H/tm2irWPbbY0QamBOhe
>>
   
ZvfZFUMvwrYdSS3gcJMJ1vmgjdVC6OJBEXOwNOOo2JA0VcFEAaygYaNuy55O5/6o
>>
   
sGXdr68kuDO62ZDr/3djXsFtj5yASZuVFFHmePmHXs5Yu7mK4RhTmnlchHkzzvta
>>
   
FzKaaw5OGZ5qbsC1c4sFV2vkfl8PeYfaC3HwnEUsgT2DkM4eWc1D/iRCCj3TaMg8

Bug#803069: RFS: python-tzlocal/1.2-2 -- tzinfo object for the local timezone

[Edward Betts]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: python-tzlocal
   Version : 1.2-2
   Upstream Author : Lennart Regebro 
 * URL : https://github.com/regebro/tzlocal
 * License : CC0
   Section : python

It builds those binary packages:

  python-tzlocal - tzinfo object for the local timezone
  python3-tzlocal - tzinfo object for the local timezone (Python 3 version)

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

  http://mentors.debian.net/package/python-tzlocal

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/python-tzlocal/python-tzlocal_1.2-2.dsc

Changes since the last upload:

  * Update Vcs-* control headers.
  * The reproducible builds projects sets TZ=UTC which causes the test suite
to fail. This is fixed by adding 'unexport TZ' to debian/rules.

-- 
Edward.

Bug#802902: RFS: vconnectstand/2.0.1 ITP

[Gianfranco Costamagna]

Control: owner -1 !
Control: tags -1 moreinfo

Hi

I looked at the mentors page.
https://mentors.debian.net/package/vconnectstand

please fix the warnings/errors on that page, and then remove the moreinfo
tag, and I'll look at it again

showstoppers:
1) please use an ITP bug and close in changelog
2) the package shouldn't be native, but quilt format instead
3) add a watch file, and point to the correct source location
...

some other stuff.

cheers,

G.




Il Sabato 24 Ottobre 2015 23:12, Samuel Thibault  ha 
scritto:
Hello Tobias,

Take care, when using the debian bug tracker, not to introduce any
spurious spaces.  Your report got ignored by the bot just because the
mail was starting with

  Package: sponsorship-requests
  Severity: wishlist

instead of


Package: sponsorship-requests
Severity: wishlist

I resent the mail with the fixed format, so it's now submitted.

Samuel

Bug#803069: marked as done (RFS: python-tzlocal/1.2-2 -- tzinfo object for the local timezone)

[Debian Bug Tracking System]

Your message dated Mon, 26 Oct 2015 16:49:50 + (UTC)
with message-id <384308087.4815012.1445878190614.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#803069: RFS: python-tzlocal/1.2-2 -- tzinfo object for 
the local timezone
has caused the Debian Bug report #803069,
regarding RFS: python-tzlocal/1.2-2 -- tzinfo object for the local timezone
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.)


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

Dear mentors,

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

 * Package name: python-tzlocal
   Version : 1.2-2
   Upstream Author : Lennart Regebro 
 * URL : https://github.com/regebro/tzlocal
 * License : CC0
   Section : python

It builds those binary packages:

  python-tzlocal - tzinfo object for the local timezone
  python3-tzlocal - tzinfo object for the local timezone (Python 3 version)

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

  http://mentors.debian.net/package/python-tzlocal

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/python-tzlocal/python-tzlocal_1.2-2.dsc

Changes since the last upload:

  * Update Vcs-* control headers.
  * The reproducible builds projects sets TZ=UTC which causes the test suite
to fail. This is fixed by adding 'unexport TZ' to debian/rules.

-- 
Edward.
--- End Message ---
--- Begin Message ---
Hi, I was looking for your mail since your first upload on mentors :)


I monitor mentors and packages previously sponsored for RC bugs ;)

Built, thanks for your contribution to Debian!

(I did a source only upload, let's see how it goes)


cheers,

G.


Il Lunedì 26 Ottobre 2015 16:45, Edward Betts  ha scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: python-tzlocal
   Version : 1.2-2
   Upstream Author : Lennart Regebro 
* URL : https://github.com/regebro/tzlocal
* License : CC0
   Section : python

It builds those binary packages:

  python-tzlocal - tzinfo object for the local timezone
  python3-tzlocal - tzinfo object for the local timezone (Python 3 version)

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

  http://mentors.debian.net/package/python-tzlocal

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/python-tzlocal/python-tzlocal_1.2-2.dsc

Changes since the last upload:

  * Update Vcs-* control headers.
  * The reproducible builds projects sets TZ=UTC which causes the test suite
to fail. This is fixed by adding 'unexport TZ' to debian/rules.

-- 
Edward.--- End Message ---

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Gianfranco Costamagna]

Control: owner -1 !

Hi, the packaging looks good to me (note: I didn't do a full review)however I 
don't like your dh_auto_install target override.

dh_auto_install should install into debian/tmp, not into debian/package.

I propose you to use dh_install like this:

override_dh_install:

DESTDIR=$(CURDIR)/debian/gnome-twitch ninja -C build install

what do you think?

you could also use MAKE=ninja and
$(MAKE) during the calls, to keep it simple and possible to easily change the 
build system.



note: I didn't try to install and test, I'll do as soon (together with a full 
copyright review)
as soon as the above is fixed/answered


Il Sabato 24 Ottobre 2015 9:39, Tim Dengel  ha 
scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnome-twitch"

* Package name: gnome-twitch
  Version : 0.1.0-1
  Upstream Author : Vincent Szolnoky 
* URL : https://github.com/Ippytraxx/gnome-twitch
* License : GPL-3+
  Section : video

It builds those binary packages:

  gnome-twitch - GNOME Twitch app for watching Twitch.tv streams without
a browser

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

http://mentors.debian.net/package/gnome-twitch


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

  dget -x
http://mentors.debian.net/debian/pool/main/g/gnome-twitch/gnome-twitch_0.1.0-1.dsc


Regards,
   Tim Dengel