Re: RFS: php-xml-beautifier

[Thomas Goirand]

On 12/15/2011 07:44 AM, Mathias Ertl wrote:
> [...] I am still looking for a
> sponsor of the package. For easy reference, here is the git-repo:
>   https://git.fsinf.at/apt/php-xml-beautifier
> ... here is the package on mentors:
>   http://mentors.debian.net/package/php-xml-beautifier
> and you can check it out with this command:
>   dget -x http://mentors.debian.net/debian/pool/main/p/php-xml-
> beautifier/php-xml-beautifier_1.2.2-1.dsc
> 
> greetings, Mati
> 

Hi Mati,

I'll go ahead and sponsor the upload of php-xml-beautifier if you
correct what's below.

1/ pkg-php-tools and missing php-xml-util depends

It's good you've switched to pkg-php-tools, but you've missed something
important:
Depends: ${phppear:Debian-Depends}

Because of this, you've missed the Depends: php-xml-util which is found
automatically by pkg-php-tools if you put the above substitution
variable. I know that as a fact, because I tried myself! :)

2/ debian/copyright

The copyright notice for GPL-3+ is missing important bits that, unless
I'm mistaking, should be there. Other packages I've seen carrying the
GPL3 have a "no warranty disclaimer" and the address of the FSF. I
believe it should be in your debian/copyright too.

The rest of the packaging, to me seems into shape for an upload in SID,
but the above 2 things are blockers.

3/ Using Git for packaging

It'd be great if you were using git-buildpackage and storing your
packaging into Git. A majority of PEAR packages are using it, and most
are stored in /git/pkg-php. Would you care for joining the Alioth group
and maintain this way? (it's not mandatory to team maintain, but I
really recommend it)

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee97dbf.9020...@goirand.fr

Re: [Pkg-fonts-devel] RFS: fonts-play

[Paul Wise]

There is a precompiled Windows binary in the source package:

tools/ttfautohint/ttfautohint002.exe

I note a lot of the tools refer to /usr/local/bin/fontforge, that
should be changed to using env or /usr/bin/fontforge

I wonder if the tools should be packaged separately since future
Google fonts might use them too? Maybe Dave has some advice there.

fontlint complaints to forward upstream:

Play-Bold.ttf
Validation Play-Bold ...Failed
  Self Intersecting Glyph

Play-Regular.ttf
The glyph named mu is mapped to U+00B5.
  But its name indicates it should be mapped to U+03BC.
The glyph named Delta is mapped to U+2206.
  But its name indicates it should be mapped to U+0394.
Validation Play-Regular ...Failed
  Self Intersecting Glyph

Play-Bold.otf
A point in g is outside the font bounding box data.
A point in gcircumflex is outside the font bounding box data.
A point in gbreve is outside the font bounding box data.
A point in gdotaccent is outside the font bounding box data.
A point in gcommaaccent is outside the font bounding box data.
A point in eng is outside the font bounding box data.
Validation Play-Bold ...Failed
  Self Intersecting Glyph
  Bad 'CFF ' table

Play-Regular.otf
The glyph named mu is mapped to U+00B5.
  But its name indicates it should be mapped to U+03BC.
The glyph named Delta is mapped to U+2206.
  But its name indicates it should be mapped to U+0394.
A point in scedilla is outside the font bounding box data.
A point in perthousand.smcp is outside the font bounding box data.
Validation Play-Regular ...Failed
  Self Intersecting Glyph
  Bad 'CFF ' table

Relevant lintian complaints:

P: fonts-play source: source-contains-prebuilt-windows-binary
tools/ttfautohint/ttfautohint002.exe
P: fonts-play source: unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5
I: fonts-play source: debian-watch-file-is-missing
P: fonts-play: no-upstream-changelog
P: fonts-play: data.tar.xz-member-without-dpkg-pre-depends

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6fr6wgn28hdwfr3x-ba4aci_no_j3qngrcrwhtayuh...@mail.gmail.com

Re: RFS: v3c-2.4.0-01

[Philip Ashmore]

On 13/12/11 23:30, Etienne Millon wrote:

* Philip Ashmore  [111214 00:08]:

I've filed an ITP against WNPP for this package.

I've also uploaded my packages to mentors.debian.net.

The dsc file is:
http://mentors.debian.net/debian/pool/main/v/v3c/v3c_2.4.0-01-1.dsc

Regards,
Philip Ashmore


Hello,

I am not a DD so I can't sponsor you, but I had a look at your package:

   - first of all, it does not build in a sid chroot. A quick glance at
 the build log seems to reveal that libtool is missing :

v3c/v3c.mak:164: Setting the build mode to default [debug]
v3c/v3c.mak:188: *** New configuration (will save).
/tmp/buildd/v3c-2.4.0-01/v3c/v3c_mak.sh: 739: 
/tmp/buildd/v3c-2.4.0-01/v3c/v3c_mak.sh: libtool: not found
[v3c_mak.sh] You need to install libtool - take a look at README.
make[1]: *** [configure.ac] Error 1

   - the source package has a lot of lintian warnings (when you run
 lintian -I v3c_2.4.0-01-1.dsc, no warnings should appear. Add -i
 to have longer descriptions). Most of them seem easy to fix,
 though.

   - debian/control :

 - both short and extended descriptions are not enough. If I don't
   already know what v3c does, this is what is supposed to inform
   me :)

 - does v3c-doc really need graphviz and doxygen at runtime ?

   - debian/changelog : please explain that this is an initial release
 and that it closes your ITP bug, as explained in the new
 maintainer's guide.

   - I don't think that debian/*.in should be there.
Where in debian/rules can I insert a command to delete the debian/*.in 
files?


 http://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog

That's it for the moment !

Have a nice day,

Regards,
Philip Ashmore


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee95457.4090...@philipashmore.com

Re: RFS: php-xml-beautifier

[Mathias Ertl]

Hi!

On Friday, December 09, 2011 09:15:54 PM Thomas Goirand wrote:
> On 12/09/2011 08:46 PM, Mathias Ertl wrote:
> > I already joined the mailinglist there and enjoy the spam that comes in
> > there every day ;-). I did however file a join-request on their Alioth
> > homepage. I can only hope they approve the request.
> 
> I'd suggest sending a private mail to the admins of the project.

I am sorry to say that so far I have received no response. 

> >> Last, why did you choose GPL-3+ for your packaging work, when upstream
> >> has chosen a more relaxed BSD 2 clause?
> > 
> > Because I think its a good license. Is that a problem? I am happy to
> > choose something different or the same as the package, if there are any
> > customs or conventions I am not aware about.
> 
> There's no problems per say, I believe everyone is free to release the work
> it does in Debian in the license of its choice if it's DFSG free, but I
> just feel
> weird to have just a few files needed for the packaging to be more
> restrictive
> than the ones from the original authors itself.
> 
> Said in another way: your choice of licensing is legally valid inside
> Debian,
> but it wouldn't be mine. I'd adopt the license of upstream, especially
> if it's
> the BSD license. IMHO, software with multiple licenses are a pain when
> writing debian/copyright files.

Ok, So I will leave it at that in the hopes that it won't stop anybody from 
sponsoring the package.

> > That being said, I still look for a sponsor for that package! ;-)
> 
> Please ping me in few days if I didn't get time to review again and nobody
> else stood up (I'm going to sleep now, I'm too tired to start packaging
> reviews ...).

Nobody else stood up, so I'm pinging you again! :-). I am still looking for a 
sponsor of the package. For easy reference, here is the git-repo:
https://git.fsinf.at/apt/php-xml-beautifier
... here is the package on mentors:
http://mentors.debian.net/package/php-xml-beautifier
and you can check it out with this command:
dget -x http://mentors.debian.net/debian/pool/main/p/php-xml-
beautifier/php-xml-beautifier_1.2.2-1.dsc

greetings, Mati

-- 
me on twitter: @mathiasertl | soup: http://soup.er.tl
I only read plain-text mail!  I prefer signed/encrypted mail!


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

Re: DEP-5 versioned URI / Lintian complains

[Russ Allbery]

Daniel Stender  writes:

> For the very next of my commits,

> 1) what URI should I give to the very next commits, and should I just
> just disregard the Lintian complain

For right now, I would ignore the complaint and use an unversioned URL,
since so far as I can tell there is no versioned URL currently available
that takes you straight to the current text of the document.  However, I
may have missed something.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwgmzqtw@windlord.stanford.edu

RFS: nanoflann

[Jose Luis Blanco]

Dear mentors,
I am looking for a sponsor for my package "nanoflann", for which I'm
also the upstream author.

This is its basic info:
* Package name: nanoflann
  Version : 1.1.0-1
  Upstream Author : Jose Luis Blanco Claraco 
* URL : http://code.google.com/p/nanoflann/
* License : BSD
  Programming Lang: C++
  Description : C++ header-only fork of the FLANN library for KD-trees
  Section         : science
It mainly consists in a ".hpp" file + a ".pc" file for pkg-config, so
its only generated packge is:  libnanoflann-dev - C++ header-only fork
of the FLANN library for KD-trees

To access further information about this package, please visit the
following URL:  http://mentors.debian.net/package/nanoflann
Alternatively, one can download the package with dget using this
command:  dget -x
http://mentors.debian.net/debian/pool/main/n/nanoflann/nanoflann_1.1.0-1.dsc
I would be glad if someone uploaded this package for me.


Some discussion about the application/utility of this package already
started in the ITP bug page:
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652103

so I think anyone interested could give it a look if wondering what
would be this package used for.


Thanks in advance for your time.
Cheers,
JL


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAZP6f=jKZO72rBs2aDnZvCfdwoL7uLchYxVmSQvŽmfwFy=w...@mail.gmail.com

Re: Bug#620960: RFS: inspircd

[Guillaume Delacour]

Le samedi 03 décembre 2011 à 11:39 +0100, Jan Lübbe a écrit :
> Hi!

Hi,

> 
> On Tue, 2011-11-01 at 22:00 +0100, Guillaume Delacour wrote: 
> > To access further information about this package, please visit the 
> > following URL:
> > 
> >   http://mentors.debian.net/package/inspircd
> > 
> > Alternatively, one can download the package with dget using this command:
> > 
> >   dget -x 
> > http://mentors.debian.net/debian/pool/main/i/inspircd/inspircd_2.0.5-1.dsc
> 
> It seems you've replaced that package with a new one on 2011-11-30. Did
> you want to that one uploaded, too?

Yes, the package on mentors (2011-11-30) is the package i want to upload
in the archive (i've forgot to include some stuff a few days ago and
regenerate/reupload it on mentors).

> 
> From the changelog it seems that you intend to maintain it as a pkg-irc
> team member, so I'd offer to review and upload it if you don't find a
> sponsor in your team.

Absolutely yes, i didn't find any sponsor on the team (which have really
only a few active members and not all are DD). I think we have to update
inspircd before Wheezy freeze unless it will be removed as obsolete
version.

> 
> Best regards,
> Jan
> 
> 
> 
> 

-- 
Guillaume Delacour 


signature.asc
Description: Ceci est une partie de message numériquement signée

RFS: wmweather+

[Martin Stigge]

Dear mentors,

Since my usual sponsor (martin f. krafft) seems to be busy these days I
will broaden this RFS and am looking for a sponsor for my package
"wmweather+".

 * Package name: wmweather+
   Version : 2.13-1
   Upstream Author : Brad Jorsch
 * URL : http://sourceforge.net/projects/wmweatherplus/
 * License : GPLv2
   Section : x11

The new package fixes two bugs from BTS of which one is RC. It further
updates to current packaging practices (source format 3.0, VCS in
collab-maint, ...) and fixes some lintian warnings. It's now again
lintian clean.

Available on mentors.debian.net:

  http://mentors.debian.net/package/wmweather%2B
  dget -x 
http://mentors.debian.net/debian/pool/main/w/wmweather+/wmweather+_2.13-1.dsc

I would be glad if someone uploaded this package for me. Thanks in
advance!

Regards,
Martin


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

Re: RFS: qastools

[Sebastian H.]

>>> A few comments about your man pages:
>>>
>>>   - Your .TH line is "wrong" (you shouldn't use the command name and
>>> section number a second time after the date); have a look at
>>> /usr/share/man/man7/man-pages.7.gz for a better example.
>>>
>>>   - qasconfig and qashctl don't take any options; please adjust their
>>> SYNOPSIS accordingly.
>>>
>>>   - "SEE ALSO provides a comma-separated list of related man pages,
>>> ordered by section number and then alphabetically by name" (see
>>> man-pages(7)); please also indicate the section number in
>>> parentheses following the name.
>>>
>>>   - In qasconfig(1), you list qasconfig in the SEE ALSO section, intead
>>> of (presumably) qashctl(1).
>>>
>>>   - Please consider removing the AUTHOR section from all three man
>>> pages, as advised in man-pages(7). It wouldn't hurt having copyright
>>> information for the man page in a comment header though.
>>
>> Ok, I've done some changes on the manpages and uploaded a new package.
>> Does this look better now?
> 
> Much better, thanks. Although I don't think you should have removed the
> SYNOPSIS section entirely in qasconfig(1) and qashctl(1); just show the
> command without "[OPTION]...".

Ok, I'll put it back in that way then.

> Also, you can probably drop the README from the binary package, it
> only contains information about building and installing the software
> from source (see debian policy 12.3).

Right, that file isn't too useful for users.

I'll upload a multi package version tomorrow.

Regards,
Sebastian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee8f8c0.9070...@gmx.de

Re: [Pkg-fonts-devel] RFS: fonts-play

[Christian PERRIER]

(CC'ing you just in case, though I think you're subscribed to pkg-fonts-devel)

Quoting Martin Erik Werner (martinerikwer...@gmail.com):
> Dear mentors and pkg-fontsers,
> 
> I am looking for a sponsor for my package "fonts-play".


I added it to my TODO list as I'm now sponsoring most of the font
packages maintained under the team's umbrella.

Please feel free to ping me in case it falls under the pile...:)

Interesting that you used git for packaging. I think it opens the
opportunity for those in the team who would like to use it rather than
SVN (which is used for other packages maintained by pkg-fonts), to
switch to git.

Help in importing the current SVN repo in git would be
appreciated. Most font packages in pkg-fonts SVN use an
svn-buildpackage style layout.




signature.asc
Description: Digital signature

Re: RFS: qastools

[Sebastian H.]

>>> So? It's difficult for me to get your point when you're asking questions
>>> without making any statement. I'd be grateful if you could clarify.
>>
>> Depending on the answers, my statements would be different. In general,
>> I see to 'primary' reasons for a package split in a package with kind of
>> related utilities:
>>
>> 1) Some of the utilities are real big
>> 2) Some of the utilities has real big dependencies
>>
>> Each package split does also come with a overhead.
>>
>> And I think based on your answer, the qastools splitting doesn't fully
>> make sense.
> 
> Except in this case they are already split (qasconfig and qasmixer are
> already in Debian); so what we're talking about is whether it makes
> sense to put them together now.
> 
> Looking at popcon for qasconfig and qasmixer, it seems that a fair
> amount of users only have one of the packages installed (83 vs. 128
> users, respectively), so in my view it's a good idea to keep them
> separated, so that the users who chose not to install both packages
> still have that possibility.

I'm favor of splitting into per-application packages, too.

IMO from an end user perspective it's nicer to be able to pick just the
applications you need.
Also QasMixer is probably the most useful application in this
collection. A quick search for the term "mixer" wouldn't reveal it
in case of a single qastools package.


Sebastian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee8f657.2040...@gmx.de

Re: RFS: qastools

[Benoît Knecht]

Sebastian H. wrote:
> > A few comments about your man pages:
> > 
> >   - Your .TH line is "wrong" (you shouldn't use the command name and
> > section number a second time after the date); have a look at
> > /usr/share/man/man7/man-pages.7.gz for a better example.
> > 
> >   - qasconfig and qashctl don't take any options; please adjust their
> > SYNOPSIS accordingly.
> > 
> >   - "SEE ALSO provides a comma-separated list of related man pages,
> > ordered by section number and then alphabetically by name" (see
> > man-pages(7)); please also indicate the section number in
> > parentheses following the name.
> > 
> >   - In qasconfig(1), you list qasconfig in the SEE ALSO section, intead
> > of (presumably) qashctl(1).
> > 
> >   - Please consider removing the AUTHOR section from all three man
> > pages, as advised in man-pages(7). It wouldn't hurt having copyright
> > information for the man page in a comment header though.
> 
> Ok, I've done some changes on the manpages and uploaded a new package.
> Does this look better now?

Much better, thanks. Although I don't think you should have removed the
SYNOPSIS section entirely in qasconfig(1) and qashctl(1); just show the
command without "[OPTION]...".

Also, you can probably drop the README from the binary package, it
only contains information about building and installing the software
from source (see debian policy 12.3).

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111214191326.gb24...@marvin.lan

DEP-5 versioned URI / Lintian complains

[Daniel Stender]

Hi guys,

I've got a unknown-copyright-format-uri Lintian complain for a versioned DEP-5 
URI like:
http://anonscm.debian.org/viewvc/dep/web/deps/dep5/?pathrev=220

but a URI like:
http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?rev=220
passes through, although that URI gets redirected to:
http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=revision&revision=220
... ending in a "Unknown location: /web/deps/dep5.mdwn" on the web

For the very next of my commits,

1) what URI should I give to the very next commits, and should I just just 
disregard the Lintian
complain

2) anyway, I've picked what I've found being the latest rev. of DEP5 (220), is 
that best practice?

Thx in advance for any pointers,
Daniel Stender


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee8bff4.4070...@danielstender.com

Re: RFS: qastools

[Sebastian H.]

> A few comments about your man pages:
> 
>   - Your .TH line is "wrong" (you shouldn't use the command name and
> section number a second time after the date); have a look at
> /usr/share/man/man7/man-pages.7.gz for a better example.
> 
>   - qasconfig and qashctl don't take any options; please adjust their
> SYNOPSIS accordingly.
> 
>   - "SEE ALSO provides a comma-separated list of related man pages,
> ordered by section number and then alphabetically by name" (see
> man-pages(7)); please also indicate the section number in
> parentheses following the name.
> 
>   - In qasconfig(1), you list qasconfig in the SEE ALSO section, intead
> of (presumably) qashctl(1).
> 
>   - Please consider removing the AUTHOR section from all three man
> pages, as advised in man-pages(7). It wouldn't hurt having copyright
> information for the man page in a comment header though.

Ok, I've done some changes on the manpages and uploaded a new package.
Does this look better now?

http://mentors.debian.net/package/qastools
dget -x
http://mentors.debian.net/debian/pool/main/q/qastools/qastools_0.16.1-1.dsc

(This is called 0.16.1 but it's not official yet for that I can still
fix problems.)

Sebastian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee8bf1c.5020...@gmx.de

Re: RFS: qastools

[Benoît Knecht]

Sune Vuorela wrote:
> On 2011-12-13, Benoît Knecht  wrote:
> > So? It's difficult for me to get your point when you're asking questions
> > without making any statement. I'd be grateful if you could clarify.
> 
> Depending on the answers, my statements would be different. In general,
> I see to 'primary' reasons for a package split in a package with kind of
> related utilities:
> 
> 1) Some of the utilities are real big
> 2) Some of the utilities has real big dependencies
> 
> Each package split does also come with a overhead.
> 
> And I think based on your answer, the qastools splitting doesn't fully
> make sense.

Except in this case they are already split (qasconfig and qasmixer are
already in Debian); so what we're talking about is whether it makes
sense to put them together now.

Looking at popcon for qasconfig and qasmixer, it seems that a fair
amount of users only have one of the packages installed (83 vs. 128
users, respectively), so in my view it's a good idea to keep them
separated, so that the users who chose not to install both packages
still have that possibility.

Cheers,

-- 
Benoît Knecht


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111214150622.ga24...@marvin.lan

RFS: fonts-play

[Martin Erik Werner]

Dear mentors and pkg-fontsers,

I am looking for a sponsor for my package "fonts-play".

My reason for packaging this font is that the game "Red Eclipse" (ITPed by me)
utilises it, and I plan on using fonts-play as a (build-(long story))dependency
for redeclipse-data.

 * Package name: fonts-play
   Version : 1.002+20111214.1-1
   Upstream Authors: Jonas Hecksher
   : Dave Crossland
 * URL : 
http://code.google.com/p/googlefontdirectory/source/browse/play/
 * License : OFL-1.1 for font, Apache-2.0 for font-generation scripts
   Section : fonts

It builds those binary packages:

fonts-play - minimalistic sans serif typeface

The package is available at debexpo/mentors:

  http://mentors.debian.net/package/fonts-play
  dget -x 
http://mentors.debian.net/debian/pool/main/f/fonts-play/fonts-play_1.002+20111214.1-1.dsc

Alternatively the source is kept in git at:

  http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-play.git;a=tree
  git clone git://git.debian.org/pkg-fonts/fonts-play.git

I have contacted Dave Crossland about the origin of the font, and he confirmed
that it was basically thrown over the wall from PlayType https://playtype.com/
(no longer mentioning it at all) to Google.

The patched-in makefiles are my attempt at contributing a fairly general build
method for all googlefontdirectory ttf fonts, (when i asked for one Dave pointed
out that none existed, and i was free to contribute one,) hence why they are a
bit excessive for only one font, but I'm using them now in the package to have
things setup correctly if they get implemented upstream.

The package is lintian and pbuilder clean, and has a get-orig-source target
which you may want to avoid on a slow connection (the GFD mercurial repo is
> 400MB)

I would be glad if someone uploaded this package for me.

Kind regards,

--
Martin Erik Werner ("arand") 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1Rapsv-Rq-8S@mell

Re: RFS: qastools

[Sune Vuorela]

On 2011-12-14, Sebastian H.  wrote:
> I've made a quick build.
>
> qastools-common_0.16.1-1_all.deb   23988 bytes
> qastools-qasconfig_0.16.1-1_amd64.deb  61768 bytes
> qastools-qashctl_0.16.1-1_amd64.deb   274986 bytes
> qastools-qasmixer_0.16.1-1_amd64.deb  309520 bytes
>
> versus
>
> qastools_0.16.1-1_amd64.deb 651262 bytes

My conclusion here would be to not split.

/Sune


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjehbo7.p7v.nos...@sshway.ssh.pusling.com

Re: RFS: qastools

[Sebastian H.]

Am 13.12.2011 20:22, schrieb Sune Vuorela:
> On 2011-12-13, Benoît Knecht  wrote:
>> Sebastian H. wrote:
 Why regroup qasmixer and qasconfig into one package? Wouldn't it be
 better having them Recommend each other? It doesn't seem like an
 improvement forcing users to install both tools instead of giving them
 the choice. But maybe I'm missing something.
>>>
>>> The short answer is, it makes package maintenance much easier and
>>> is less error prone.
>>
>> I see the point of having one source package for all the tools, but you
>> could still make several binary packages from there (as alsa-tools does,
>> though not for every single utility I must admit).
> 
> What's the size of these packages? what's their dependencies?
> 
> A quick look from here looks like they are qtgui apps that uses
> libasound ?

I've made a quick build.

qastools-common_0.16.1-1_all.deb   23988 bytes
qastools-qasconfig_0.16.1-1_amd64.deb  61768 bytes
qastools-qashctl_0.16.1-1_amd64.deb   274986 bytes
qastools-qasmixer_0.16.1-1_amd64.deb  309520 bytes

versus

qastools_0.16.1-1_amd64.deb 651262 bytes

Dependencies for qastools-qasmixer (same for the other two apps).
For qastools it's the same without qastools-common.

libasound2 (>> 1.0.24.1),
libc6 (>= 2.2.5),
libgcc1 (>= 1:4.1.1),
libqt4-network (>= 4:4.5.3),
libqt4-svg (>= 4:4.5.3),
libqtcore4 (>= 4:4.7.0~beta1),
libqtgui4 (>= 4:4.6.2), libstdc++6 (>= 4.2.1),
qastools-common

Sebastian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee8abbe.10...@gmx.de

Re: RFS: qastools

[Sebastian H.]

>>> I haven't looked into the details, but I don't think you need to patch
>>> your CMakelists.txt at all. Simply use debian/${package}.install files
>>> to tell debhelper which files belong to which binary package (see
>>> dh_install(1)).
>>
>> That's looks even easier.
>> But together with the manpage fixes I think reasonable to do a 0.16.1
>> release. It can also introduce build arguments to cmake which tells it
>> which applications to build. That way no debian/* quirks should be
>> neccessary. Please considers this RFS frozen until then.
> 
> I'm not sure I see how you would actually implement that in
> debian/rules; but of course I was only suggesting one way to do it, and
> if you think there's better way, by all means do it :)

Aww, nevermind, I had the misconception that every package would have an
own debian/ directory...
Of course debian/${package}.install would be the way to go.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee8abd7.3050...@gmx.de

Re: RFS: qastools

[Sune Vuorela]

On 2011-12-13, Benoît Knecht  wrote:
> So? It's difficult for me to get your point when you're asking questions
> without making any statement. I'd be grateful if you could clarify.

Hi

Depending on the answers, my statements would be different. In general,
I see to 'primary' reasons for a package split in a package with kind of
related utilities:

1) Some of the utilities are real big
2) Some of the utilities has real big dependencies

Each package split does also come with a overhead.

And I think based on your answer, the qastools splitting doesn't fully
make sense.

/Sune


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjegvf2.p7v.nos...@sshway.ssh.pusling.com

Re: RFS: qastools

[Boris Pek]

Hi,

>>  What's the size of these packages? what's their dependencies?
>
> qasmixer is 1400 kB (give or take), and is around 230 kB. You can see
> their dependency with 'apt-cache depends qasmixer qasconfig'.
>
>>  A quick look from here looks like they are qtgui apps that uses
>>  libasound ?
>
> So? It's difficult for me to get your point when you're asking questions
> without making any statement. I'd be grateful if you could clarify.

Just for a note:
1) If you make one package it affects only users of this package.
2) It you make few packages it affects all Debian users: they will download
more larger package index on each update.

So it should be a good reason to split the package...

Best regards,
Boris


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/463801323856...@web4.yandex.ru

Re: RFS: qastools

[Ansgar Burchardt]

Benoît Knecht  writes:
>> > I see the point of having one source package for all the tools, but you
>> > could still make several binary packages from there (as alsa-tools does,
>> > though not for every single utility I must admit).
>> 
>> What's the size of these packages? what's their dependencies?
>
> qasmixer is 1400 kB (give or take), and is around 230 kB. You can see
> their dependency with 'apt-cache depends qasmixer qasconfig'.

Which means there is probably no real need to split it into multiple
packages.  Doing so just increases the Packages index (which is already
quite large).

Ansgar


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vmfecyl@deep-thought.43-1.org