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

2015-10-27 Thread Gianfranco Costamagna
Hi,

(let me say, based on your answers I have difficulties in understanding how 
possibly
your first package can be so good :) )

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


well, first there is a dh_auto_install step, where everything is moved to 
debian/tmp
(via DESTDIR), and then a dh_install where packages are split

(you mention an exception of the rule, and I agree with you on that point)

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

true

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


true

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


actually you are completely right, but I guess is a matter of taste :)

Let me assume in the future you will like to split the package, that way
I guess you might just tweak the dh_install and nothing more
(but as soon as there is no automatic install by running "make install"
they are both equivalent)

>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 ;)


I guess the politically correct way is:
install in dh_auto_install everything into debian/tmp, and add an .install file
to make sure files are moved into dh_install.

that way a future package split will be easier
(this is how I would do it, but if you don't want to do I can live happy to)

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


let me know whenever you have something to look at :)
(the above discussion is obviously not a showstopper, because I guess it is 
just a matter of
knowing how your package will evolve)

cheers,

G.



Re: restund in debian

2015-10-27 Thread Gianfranco Costamagna
Hi, please open an RFS bug if you want to find a sponsor.

Anyway, I looked at the package.

the packaging rules file is really hacky, but looks good!

I would appreciate a more sane upstream packaging system, but your workaround
looks really nice ;)

do you mind opening an RFS bug?

cheers,

G.





Il Martedì 27 Ottobre 2015 0:54, Simon Josefsson  ha 
scritto:
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



Re: restund in debian

2015-10-27 Thread Simon Josefsson
tis 2015-10-27 klockan 11:15 + skrev Gianfranco Costamagna:
> Hi, please open an RFS bug if you want to find a sponsor.
> 
> Anyway, I looked at the package.
> 
> the packaging rules file is really hacky, but looks good!
> 
> I would appreciate a more sane upstream packaging system, but your workaround
> looks really nice ;)

Thanks for looking at it.  Yeah, upstream's custom make script aren't
the simplest for packaging, but at least they aren't complex to
understand.  I'm a DD so I will upload it when I feel comfortable with
the packaging.

/Simon

> 
> do you mind opening an RFS bug?
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> 
> Il Martedì 27 Ottobre 2015 0:54, Simon Josefsson  ha 
> scritto:
> 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: This is a digitally signed message part


Re: cowbuilder/pbuilder: require newer version from experimental

2015-10-27 Thread Alex Mestiashvili
On 10/27/2015 03:11 PM, Ole Streicher wrote:
> Hi,
>
> to build an "experimental" version of one of my packages, I need to
> specify a package that is in unstable (1.0.5-1) and in experimental
> (1.1~b1-1), and I need the experimental version here.
>
> With "cowbuilder --login --save-after-login", I have put the
> "experimental" distribution into /etc/apt/sources.list:
>
> (chroot) # cat /etc/apt/sources.list
> deb http://ftp.de.debian.org/debian/ sid main
> deb http://ftp.de.debian.org/debian experimental main
>
> and I did "sudo cowbuilder --update" afterwards. When I then do a 
> "cowbuilder --login", I can install the needed version manually:
>
> (chroot) # apt-get install python-astropy-helpers=1.1~b1-1
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following extra packages will be installed: [...]
>
> However, when I now try to use this to build my package, it does not
> work:
>
> $ pdebuild
> [...]
> This package is uninstallable
> Dependency is not satisfiable: python-astropy-helpers (>= 1.1~)
> [...]
>
> The package I am trying to build is python-astropy, from the alioth git:
>
> http://anonscm.debian.org/cgit/debian-astro/packages/python-astropy.git/tree/?h=experimental
>
> What could be the cause that the dependency is not satisfied from
> experimental here?
>

Hi,
may be a "cowbuilder --update" is missing ?

Alternatively one can try to inject a local package as described here:
https://wiki.debian.org/PbuilderTricks

Best regards,
Alex



Re: cowbuilder/pbuilder: require newer version from experimental

2015-10-27 Thread Ole Streicher
Alex Mestiashvili  writes:
>> What could be the cause that the dependency is not satisfied from
>> experimental here?

> may be a "cowbuilder --update" is missing ?

No; I did this. I also tested that I can install it manually (with
"apt-get python-astropy-helpers=1.1~b1-1").

Best regards

Ole



Re: cowbuilder/pbuilder: require newer version from experimental

2015-10-27 Thread gregor herrmann
On Tue, 27 Oct 2015 15:11:08 +0100, Ole Streicher wrote:

> What could be the cause that the dependency is not satisfied from
> experimental here?

I'm using a preferences file in my experimental chroots:

# cat /var/cache/pbuilder/amd64/experimental-base.cow/etc/apt/preferences
Package: *
Pin: release a=experimental
Pin-Priority: 101 


Maybe this helps in your case as well.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Pink Floyd: Shine On You Crazy Diamond (Parts 6-9)


signature.asc
Description: Digital Signature


Bug#803160: RFS: conman/0.2.7-1 [ITP]

2015-10-27 Thread ChangZhuo Chen
On Tue, Oct 27, 2015 at 10:32:54PM +0800, Yao-Po Wang wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "conman"


Please help to fix the following lintian warning:

I: conman source: unused-file-paragraph-in-dep5-copyright paragraph at line 
5

In debian/copyright, the later section will supersede the former
section. Since you put '*' in second section, any content in first
section will be supersede. So you shall put '*' in first section, and
let the following sections supersede it.

For Vcs-* fields, you can put it to https://alioth.debian.org/ instead
of github.



-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D


signature.asc
Description: PGP signature


Re: cowbuilder/pbuilder: require newer version from experimental

2015-10-27 Thread Rebecca N. Palmer
Have you tried creating a new chroot that uses experimental?  This at 
least used to work, and given that package downgrades are not supported, 
keeping separate chroots may be a better idea in the long run than 
switching one back and forth.

https://wiki.debian.org/PbuilderTricks#How_to_build_for_different_distributions

There are tools to help manage multiple chroots in ubuntu-dev-tools, 
though I don't use them myself:

https://wiki.ubuntu.com/PbuilderHowto#Using_pbuilder-dist_to_manage_different_architectures_and_distro_releases



Bug#803187: RFS: drumgizmo/0.9.8.1-1 ITP

2015-10-27 Thread Víctor Cuadrado Juan
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: drumgizmo
  Version : 0.9.8.1-1
  Upstream Author : Bent Bisballe Nyeng ,
Jonas Suhr Cristensen ,
Lars Muldjord 
* URL : http://www.drumgizmo.org
* License : GPL-2+ and GPL-3
  Section : sound

It builds this binary package:

  drumgizmo  - Audio sampler plugin and stand-alone app that simulates
  a real drum kit

Using Drumgizmo and any of the already recorded drum kits by the
community[1], in conjuction with a midi entrance and already existent audio
plugins one can achieve the quality level of real drum kit recording.

DrumGizmo fills the void that exists in FOSS for drum samplers that use
real recordings of drum kits (ala privative software such as BFD3,
Addictive Drums, and the like).

As I use it, I intend to maintain it alone as this software
doesn't develop fast, but I'm open to be in a packaging team.


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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/d/drumgizmo/drumgizmo_0.9.8.1-1.dsc



[1]: http://www.drumgizmo.org/wiki/doku.php?id=kits

Regards,

-- 
Víctor Cuadrado juan

--
E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature


Re: Package upload successful but not processed

2015-10-27 Thread Jakub Wilk

* Tomasz Buchert , 2015-10-25, 17:50:
this happened to me as well. When your key is expired you don't get 
*anything* back, it's just like that. Moreover it takes some time for 
your key to be included in the keyring: the new keyring is uploaded 
once every one/two months [1].


To clarify, ftp-master doesn't use the debian-keyring package. It uses 
the active Debian keyring, which may be updated more frequently.


The active Debian keyring is available in /srv/keyring.debian.org/ on 
some *.debian.org machines; so if you are a DD, you check status of the 
key:


jwilk@master:~$ gpg --keyring 
/srv/keyring.debian.org/keyrings/debian-maintainers.gpg --list-keys 'Andreas 
Moog' | head -n1
pub   4096R/74DE6624 2011-05-15 [expires: 2016-10-16]

Oh, apparently the keyring has been just updated, so Andreas should be 
able to upload again. :-)


--
Jakub Wilk



cowbuilder/pbuilder: require newer version from experimental

2015-10-27 Thread Ole Streicher
Hi,

to build an "experimental" version of one of my packages, I need to
specify a package that is in unstable (1.0.5-1) and in experimental
(1.1~b1-1), and I need the experimental version here.

With "cowbuilder --login --save-after-login", I have put the
"experimental" distribution into /etc/apt/sources.list:

(chroot) # cat /etc/apt/sources.list
deb http://ftp.de.debian.org/debian/ sid main
deb http://ftp.de.debian.org/debian experimental main

and I did "sudo cowbuilder --update" afterwards. When I then do a 
"cowbuilder --login", I can install the needed version manually:

(chroot) # apt-get install python-astropy-helpers=1.1~b1-1
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed: [...]

However, when I now try to use this to build my package, it does not
work:

$ pdebuild
[...]
This package is uninstallable
Dependency is not satisfiable: python-astropy-helpers (>= 1.1~)
[...]

The package I am trying to build is python-astropy, from the alioth git:

http://anonscm.debian.org/cgit/debian-astro/packages/python-astropy.git/tree/?h=experimental

What could be the cause that the dependency is not satisfied from
experimental here?

Best regards

Ole



Bug#803160: RFS: conman/0.2.7-1 [ITP]

2015-10-27 Thread Yao-Po Wang
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 Package name: conman
 Version : 0.2.7-1
 Upstream Author : Chris Dunlap 
 URL : https://github.com/dun/conman
 License : GPL3
 Section : comm
 Programming Lang: C
 Description : ConMan: The Console Manager

ConMan is a serial console management program designed to support a large
number of console devices and simultaneous users.

It builds those binary packages:

  conman - serial console management program.

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

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


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

  dget -x http://mentors.debian.net/debian/pool/main/c/conman/conman_0.2.7-1.dsc


Regards,

 Yao-Po Wang

-- 
blue119/Yao-Po Wang
who am I: https://tw.linkedin.com/in/yaopowang
Key fingerprint = B460 C1D7 6A10 6832 80AE  FEEE 2EED D0C8 E6A6 C7C0


signature.asc
Description: PGP signature