Re: RFS: naev

[Vincent Cheng]

> That makes sense, yes - but where can one find the original source archive?
> Below, you are speaking of some upstream changes since 0.5.0, hence there 
> should
> be some newer version of that upstream archive!?

I've just re-uploaded the latest version of Naev (along with my most
up-to-date packaging) to mentors.d.n:
- URL: http://mentors.debian.net/debian/pool/main/n/naev
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/n/naev/naev_0.5.0-1.dsc

> I'm not sure whether anybody other than upstream can help resolving those
> questions!?

I added a brief explanation on these "issues" to Naev's ITP bug report
a few days ago. [1]

As far as I understand, it's not an issue that blocks Naev from
entering the archives (while binaries/executables need to be able to
be built from source code, I don't think policy mandates that images
must be built/rendered from source...if that's the case, an awful lot
of packages currently in Debian would have to tweak their build
system). I recall that this was a hotly-discussed topic a few weeks
back on debian-devel [2], and I understand why it would certainly be
preferable to build everything from source (not just code, but also
graphics, documentation, etc.), but as mentionned in my ITP bug, I
myself currently do not have the technical knowledge required to set
up such a build system for Naev.

I've talked to upstream about this [3], but understandably this issue
isn't one of their priorities at the moment. You can't really blame
them either...would you rather be hacking on an exciting new piece of
code to add a cool new feature to your game, or take on the boring,
time-consuming task of setting up a build system for stuff other than
the code itself? Especially since several other distros/packagers
don't seem to care much about it either?

Personally, I'd prefer to just upload Naev as it currently stands
right now, and work on setting up a build system for all of Naev's
images afterwards and implement it in a later upload, but I'm not a DD
so the final choice isn't really mine. :)

Kind regards,
- Vincent Cheng

[1] http://bugs.debian.org/609295
[2] http://lists.debian.org/debian-devel/2011/06/msg00110.html
[3] http://groups.google.com/group/naev/browse_thread/thread/54835cda1f0b6379
(scroll down to Edgar's reply)


-- 
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/CACZd_tB=4=MYsRdVHw7Payu_cAWx5B=8qyx7nexae+sh-l-...@mail.gmail.com

Re: RFS: naev

[Michael Tautschnig]

Hi again,

> Hi Michael,
> 
> Thanks for the review. Please also consider reviewing my most
> up-to-date packaging in the Debian Games svn repository; my Naev
> packaging at mentors.d.n is heavily outdated at the moment, mostly
> because I'm getting tired of having to upload a 200 MB tarball every
> time I want to make a minor change to my packaging.
> 
> $ svn co svn://svn.debian.org/svn/pkg-games/packages/trunk/naev/
> 

That makes sense, yes - but where can one find the original source archive?
Below, you are speaking of some upstream changes since 0.5.0, hence there should
be some newer version of that upstream archive!?

[...]
> > - In src/, a few files contain copyright and license information. Those
> >  copyright holders (and licenses) are not reflected in debian/copyright.
> 
> Upstream has added copyright/license info to every source file since
> the latest Naev 0.5.0 release, so this shouldn't be an issue.
> 

That update is very much appreciated; however, unless some source files were
removed, there is still a need to update debian/copyright to list all copyright
holders. I will provide more precise input once you let me know where to find
the most recent upstream source.

> > - Your debian/changelog file gives pointers to further potential issues.
> 
> And I'd gladly accept any help in resolving those issues.
> 

I'm not sure whether anybody other than upstream can help resolving those
questions!?

> > Aside these missing bits, it would be preferable if licenses found in
> > /usr/share/common-licenses were not quoted in full; I'm asking for this 
> > because
> > the copyright file is already huge anyhow.
> 
> None of the various Creative Commons licenses (which take up the bulk
> of debian/copyright) are found under /usr/share/common-licenses.
> 

Indeed, sorry for the noise!

Best regards,
Michael



pgpJcLEJoUfrx.pgp
Description: PGP signature

Re: RFS: cmsmadesimple

[Michael Tautschnig]

Hi,

> Dear mentors,
> 
> I am looking for a sponsor for my package "cmsmadesimple".
> 
> * Package name: cmsmadesimple
>   Version : 1.9.4.1-1
>   Upstream Author : Ted Kulp, t...@cmsmadesimple.org
> * URL : http://www.cmsmadesimple.org
> * License : mixed: GPL-2+, GPL-3+, LGPL-2.1, LGPL-3
>   Section : web
> 
> It builds these binary packages:
> cmsmadesimple - scalable content management system
> cmsmadesimple-l10n - scalable content management system - localization files
> #p(lzlG8N>hB.j4
> The package appears to be lintian clean.
> 
> The upload would fix these bugs: 60
> 
[...]

Sorry for taking so long for anyone to respond. Indeed this is a very nice
example of making proper use of existing Debian packages, despite upstream
shipping all the duplicate code. The only remaining point is
modules/Printing/tcpdf/fonts/: it wouldn't occur to me as a surprise to find
this freefont code to be part of some of the *-freefont packages!?

One suggestion for the package install procedure, though: why do you first
install all the files and afterwards remove them again via an override in
debian/rules? Wouldn't it be much cleaner to only install the desired files?

Anyhow, built, signed, and uploaded. But as a new upstream version is already
available, there is a chance for you to update the packaging as well :-)

Thanks a lot for your work,
Michael



pgphBINPNkSjY.pgp
Description: PGP signature

Re: RFS: torrentflux-b4rt

[Michael Tautschnig]

Hi,

> Dear mentors,
> 
> I am looking for a sponsor for my package "torrentflux-b4rt".
> 
> * Package name: torrentflux-b4rt
>   Version : 1.0-beta2-1
>   Upstream Author : Many, listed in copyright file
> * URL : http://tf-b4rt.berlios.de/
> * License : GPL-2.0+
>   Section : web
> 
> It builds these binary packages:
> torrentflux-b4rt - web based transfer control client.
> 
> My motivation for maintaining this package is: I use it myself, it
> offers some very useful functions on top of torrentflux-b4rt, and I
> commit to support it with updates, as time permits.
> 
> The package has one lintian error: postinst-uses-db-input
> I will fix this in a next version, and in fact would like some advice on
> that. Also there is no request-for-packaging bug filed, as far as I know.
> 
[...]

Here's a preliminary review of your package:

- The source package contains several versions of other clients as archives in
  the clients/ directory. For one, this seems strange, as both other clients
  appear to be packaged in Debian. Second, these clients have different
  licenses, which aren't reflected at all in debian/copyright.
- There need not be an RFP filed, but an ITP is desirable. The intend-to-package
  will ensure that a wider audience notices the interest in packaging this
  software and people interested in that may step up.
- debian/rules: your override of dh_installdebconf has a weird comment: "# Don't
  touch the postrm script" - why exactly should that not happen? override of
  dh_fixperms: you should move the chown to the postinst, i.e., after unpacking
  on the target system, not in the package build.
- Could you please me more specific on the kind of advice you need for the
  postinst-uses-db-input warning? The point here is that db_input calls should
  happen in torrentflux-b4rt.config, not postinst!?

Hope this helps,
Michael



pgpch9ESYIF2v.pgp
Description: PGP signature

Re: RFS: naev

[Vincent Cheng]

Hi Michael,

Thanks for the review. Please also consider reviewing my most
up-to-date packaging in the Debian Games svn repository; my Naev
packaging at mentors.d.n is heavily outdated at the moment, mostly
because I'm getting tired of having to upload a 200 MB tarball every
time I want to make a minor change to my packaging.

$ svn co svn://svn.debian.org/svn/pkg-games/packages/trunk/naev/

> - What about the file in build/?

Added it to debian/copyright in svn, thanks!

> - The contents of dat/ is a bit dangerous: the font files appear to lack the
>  sources that they were generated from!?

This is already addressed in svn; naev now depends on ttf-freefont and
links to the fonts contained in that package.

> - In src/, a few files contain copyright and license information. Those
>  copyright holders (and licenses) are not reflected in debian/copyright.

Upstream has added copyright/license info to every source file since
the latest Naev 0.5.0 release, so this shouldn't be an issue.

> - Your debian/changelog file gives pointers to further potential issues.

And I'd gladly accept any help in resolving those issues.

> Aside these missing bits, it would be preferable if licenses found in
> /usr/share/common-licenses were not quoted in full; I'm asking for this 
> because
> the copyright file is already huge anyhow.

None of the various Creative Commons licenses (which take up the bulk
of debian/copyright) are found under /usr/share/common-licenses.

Thanks again for your review!

Kind regards,
- Vincent Cheng


--
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/caczd_tdqhk8p+t9-z40-wb2sr6jm5bf52qezu5ew18otnop...@mail.gmail.com

Re: RFS: naev

[Michael Tautschnig]

Hi,

> I am looking for a sponsor for my packages "naev" and "naev-data".
> 
> * Package name: naev, naev-data
>   Version : 0.4.2-1
>   Upstream Author : Edgar Simo "bobbens" 
> Nikola Whallon <6.satur...@gmail.com>
> Josiah Schwartfeger
> Deiz
> Bas Fournier "BTAxis" 
> * URL : http://code.google.com/p/naev/
> * License : code - GPL-3 ; data - public domain,
>   GPLv2, GPLv3, CC-By (and -SA) 3.0
>   Programming Lang: C, Lua
>   Section : games
>   Description : 2D space trading combat game
> 
[...]

I've taken a look at this package and would really hope for further input from
the Games team, as they might be much more experienced with the mix of licenses
that occurs when packaging graphics and sound files together with the source
code.

My main focus of this reviewing round was the copyright file; it is already very
helpful to be in DEP-5 format, but I'm afraid it's still incomplete:

- What about the file in build/?
- The contents of dat/ is a bit dangerous: the font files appear to lack the
  sources that they were generated from!?
- In src/, a few files contain copyright and license information. Those
  copyright holders (and licenses) are not reflected in debian/copyright.
- Your debian/changelog file gives pointers to further potential issues.

Aside these missing bits, it would be preferable if licenses found in
/usr/share/common-licenses were not quoted in full; I'm asking for this because
the copyright file is already huge anyhow.

Hope this helps,
Michael



pgpeTYC9cZQAS.pgp
Description: PGP signature

Re: RFS: wmmixer

[Michael Tautschnig]

Hi,

[...]
> 
> Can you check the package again.
> 

I've got a few questions concerning your changes, which aren't necessarily bugs,
but at least I'd like to see the rationale.

- The most recent policy version is 3.9.2; why did you update to 3.9.1 only?
- Why has the priority been changed to extra?
- What is the upstream status of your patches, have you forwarded them/tried to
  contact upstream?

Minor improvements to be made:
- You don't need to build-depend on quilt.
- No need for "include /usr/share/quilt/quilt.make" in debian/rules
- debian/watch only holds a comment, that doesn't really help uscan to check the
  status. Could you make that a proper watch file?

Concerning your question for getting rid of binary-arch in debian/rules: please
see the man pages of dh_installchangelogs, etc. You will find that mostly you
may specify the upstream files in debian/. files, e.g., for
dh_installexamples use debian/wmmixer.examples. If that option isn't available,
use overrides, e.g., override_dh_installchangelogs.

Please provide some information on the questions I've posed above and please
take a look at the possible improvements. Then your package should be ready to
be uploaded.

Hope this helps,
Michael



pgplV9xr0WrkI.pgp
Description: PGP signature

Re: RFS: mosquitto

[Michael Tautschnig]

Hi Roger,

[...]

Thanks a lot for updating your package. I've reviewed your changes and it looks
mostly fine, except for one issue:

> 
> Lintian run as "lintian -iIE --pedantic" gives the following output:
> 
> W: mosquitto source: debhelper-overrides-need-versioned-build-depends
> (>= 7.0.50~)
[...]

Instead of copy-pasting this lintian warning, you should have addressed it :-/ -
could you please fix that and re-upload to mentors? I will then happily sponsor
your upload.

Best regards,
Michael



pgp9IqWQbNLQg.pgp
Description: PGP signature

dfsg tarball and non-dfsg version number

[Anton Martchukov]

On Sat, Jul 09, 2011 at 02:57:20PM -0700, Hamish wrote:
> +dfsg into version name:
> as our build will be bit-for-bit identical to one built from a non-
> stripped version of the source (the only difference between the
> source tarballs being unused mac/windows dirs), I don't see a
> point in adding the +dfsg to the binary package version, it
> clutters for no reason. (if pbuilder method has issues, then fix
> pbuilder...)

Does anybody have a clue if it will build by autobuilder fine?

When debian changelog lists version 2.4.708 and corresponding
tarball is opencpn_2.4.708+dfsg.orig.tar.gz since some
non-dfsg binaries has been stripped off.

E.g. pbuilder fails to find the tarball unless version in
changelog is changed to 2.4.708+dfsg.

Thanks.

-- 
Anton Martchukov
http://www.martchukov.com


-- 
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/20110709225248.ga9...@deneb.ru-spb-hm.net.martchukov.com

RFS: mosquitto

[Roger Light]

Dear mentors,

I am looking for a sponsor for my package "mosquitto". It has already
been sponsored once - this is an updated version. The new version
fixes bug 632589 and bumps the upstream version to the latest version.

* Package name: mosquitto
 Version : 0.11.3-1
 Upstream Author : Roger Light 
* URL : http://mosquitto.org/
* License : BSD
 Section : net

It builds these binary packages:
libmosquitto0 - MQTT version 3.1 client library
libmosquitto0-dev - MQTT version 3.1 client library, development files
libmosquittopp0 - MQTT version 3.1 client C++ library
libmosquittopp0-dev - MQTT version 3.1 client C++ library, development files
mosquitto - MQTT version 3.1 compatible message broker
mosquitto-clients - Mosquitto command line clients
python-mosquitto - MQTT version 3.1 client library, python bindings

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/mosquitto
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/m/mosquitto/mosquitto_0.11.3-1.dsc

Lintian run as "lintian -iIE --pedantic" gives the following output:

W: mosquitto source: debhelper-overrides-need-versioned-build-depends
(>= 7.0.50~)
N:
N:The override targets facility in debhelper, involving debian/rules
N:targets that begin with "override_dh_", was introduced in a later
N:version of debhelper than the package Build-Depends on. The package
N:Build-Depends should be updated to require at least debhelper 7.0.50.
N:Giving the version followed by ~ is recommended so that backports will
N:satisfy the dependency.
N:
N:lenny was released with debhelper version 7.0.15, so every package that
N:assumes a newer version should explicitly declare so for the sake of
N:lenny backports.
N:
N:Refer to the dh(1) manual page for details.
N:
N:Severity: normal, Certainty: certain

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

Thanks,

Roger


-- 
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/cah7zdycadthhqxmxrx9d2o9gv7tk_gori7hzl+bvkvvndut...@mail.gmail.com

Re: Bug#538067: RFS: opencpn

[Hamish]

Anton wrote:
> 1. Since we are using dfsg tarball I think the version
> should include "+dfsg" otherwise my pbuilder fails to find
> the tarball. I have added this to changelog.

+dfsg into version name:
as our build will be bit-for-bit identical to one built from a non-
stripped version of the source (the only difference between the
source tarballs being unused mac/windows dirs), I don't see a
point in adding the +dfsg to the binary package version, it
clutters for no reason. (if pbuilder method has issues, then fix
pbuilder...)

instead of putting the new tarballs in svn, the latest idea is to
put their md5sum in svn and put the tarball at 
  http://pkg-grass.alioth.debian.org/tarballs/
('get_latest_from_git.sh' now updated in svn with details about
that which I hadn't checked in)


> 2. src/nmea0183/* plugins/*/src/nmea0183/* have the
> following:
...
> So it is not clear which license it is under now? If it is
> BSD than which clause version and why GPL header? If it has
> been relicensed to GPL than I am not sure if it is
> possible to do so providing the given statement from author?

We went through this one a couple weeks ago, I believe that Dave
has the answer &/or has been in contact with the author ..


> 3. plugins/grib_pi/src/Grib* plugins/grib_pi/src/Iso*
> plugins/grib_pi/src/ZuFile
> are taken fron ZyGrib and licensed as GPL-3+. Our code is
> GPL-2+ and I think it is not backward compatible. However as
> I understand this item is a plugin, so maybe it is ok, but
> not sure. 

if bundled as a single distribution transparently to the user
it is a single work and just calling a library a plugin does not
get you some magic exemption from the GPL.

IIRC GPL3 for zygrib is a rather new feature, I wonder if the
code was taken before or after that change? If new, I probably
have an old gpl2 tarball of it around somewhere.


> Beside this there are some less hard issues:
> 
> 6. Plugins are still installed to /usr/lib/opencpn
> although empty directory /usr/lib/opencpn_plugins is being
> created.

I will investigate and fix that today.
(I thought I had already taken care of that, maybe I missed
something or the new beta changes in a way I didn't expect)


Also I need to double check the dispersion of the provided docs
after the upstream path change there.


thanks,
Hamish


-- 
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/1310248640.19707.yahoomailclas...@web110004.mail.gq1.yahoo.com

Re: Bug#538067: RFS: opencpn

[Anton Martchukov]

On Sat, Jun 18, 2011 at 07:29:52AM -0700, Hamish wrote:
> an update on ITP progress for the OpenCPN software (opencpn.org).

Another update about OpenCPN package. 

debian directory in svn is updated to build against 2.4.708,
there where problems with tinyxml patch and I fixed them.

1. Since we are using dfsg tarball I think the version
should include "+dfsg" otherwise my pbuilder fails to find
the tarball. I have added this to changelog.

Main thing is that I have produce DEP-5 compilant copyright
file:

http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/debian/copyright?view=markup

I believe there are missing items and issues still. So we
need to review this. But after that copyright things should
be clear for everybody, even for robots. Particular items
that I have questions:

2. src/nmea0183/* plugins/*/src/nmea0183/* have the following:

 *   Copyright (C) 2010 by Samuel R. Blackburn, David S Register
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or *
 *   (at your option) any later version.

 *   S Blackburn's original source license:*
 * "You can use it any way you like."  *
 *   More recent (2010) license statement: *
 * "It is BSD license, do with it what you will"   *

So it is not clear which license it is under now? If it is
BSD than which clause version and why GPL header? If it has
been relicensed to GPL than I am not sure if it is possible
to do so providing the given statement from author?

3. plugins/grib_pi/src/Grib* plugins/grib_pi/src/Iso* plugins/grib_pi/src/ZuFile
are taken fron ZyGrib and licensed as GPL-3+. Our code is
GPL-2+ and I think it is not backward compatible. However as
I understand this item is a plugin, so maybe it is ok, but
not sure. 

4. Image files. We need to add them to the copyright file
and understand their licenses and copyright owners.

5. Any other exceptions in source code. Will need to check
for them and add to copyright file.

Beside this there are some less hard issues:

6. Plugins are still installed to /usr/lib/opencpn although
empty directory /usr/lib/opencpn_plugins is being created.

7. Lintian proposes to register the documentation with
doc-base. I am going to study it, but does it make any sense
for our package?

Thanks.

-- 
Anton Martchukov
http://www.martchukov.com


-- 
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/20110709195248.gb3...@deneb.ru-spb-hm.net.martchukov.com

Re: Nitpicking: you are doing it wrong

[Raphael Hertzog]

On Sat, 09 Jul 2011, Thomas Goirand wrote:
> My point to give arguments about not using dh was *not* to start a troll
> thread about what is best practices. It was simply to tell that there
> are some arguments for and against using dh, and as a consequence, I
> found very bad to write in this list that not using dh was a bad idea.

Not using dh for a new package is a bad idea IMO.

Sure enough, you can do the packaging once without dh to force you to
learn the commands and what's going on. That's fine.

But then when you're doing the packaging that you want to submit to
Debian, it's best to use dh because the package will be more maintainable
on the long run (for all the good reasons that have already been given).

I don't share at all the 2 arguments that you listed against dh:
- performance is not a real problem, the few seconds of build time are
  neglible even for small package, 5 seconds more in a build doesn't
  change much compared to the time you have invested in creating the
  package
- readability, I find the override very good to point out what's special
  in the package (you would not notice in a normal debhelper package
  that a dh_foo call has been moved in the list)

Of course, it's not a requirement at the debian level. But that's not a
good reason to not recommend it to newcomers. They don't have the required
experience to know what's best for them. Thus we should point them towards
something largely accepted and recommended.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110709190517.gd30...@rivendell.home.ouaza.com

Re: RFS: usb-imagewriter

[Kilian Krause]

Hi Fabrizio,

On Fri, Jul 08, 2011 at 01:07:04PM +0200, Fabrizio Regalli wrote:
> On Fri, 2011-07-08 at 13:03 +0200, Fabrizio Regalli wrote:
> > On Fri, 2011-07-08 at 12:58 +0200, Fabrizio Regalli wrote:
> > > Dear mentors,
> > > 
> > > I am looking for a sponsor for my package "usb-imagewriter".
> > > 
> > > * Package name: usb-imagewriter
> > >   Version : 0.1.3-1
> > >   Upstream Author : Oliver Grawert 
> > > * URL : https://launchpad.net/usb-imagewriter
> > > * License : GPL-1
> > 
> > Is GPL-2, sorry.
> > Give me a minute to change it on package.
> 
> Finished.
> Thank you and sorry for mistake.

Reviewing your package I find a bit of chat on the ITP bug yet no notion if
that "problem" of using Ubuntu logo has yet been solved and how. 

Your short description might benefit from adding that this uses GNOME (at
least python-gnome2).

Just to make sure it doesn't go unnoticed: your debian/copyright uses DEP-5
(rev. 135). Latest is 174. I hope this does reflect your intention.
And just to be complete about this, the URL doesn't check out as is.

The manpage is .. uhm, extremely brief. Sure that's all you want to tell
your users? And even looking at the webpage indicated there doesn't
substantially yield more information IMHO.

The implementation of build-stamp in debian/rules is screwed. The stamp is
generated *before* the build target is even started. For a personal choice
I'd vote for switching this to dh-style as it'll become much nicer that way.
As Ubuntu is a "special" upstream though, I'd also vote for using a shared
approach that both Debian and Ubuntu can live with and share the same code.
That being said have you already pushed your modifications to debian/rules
back upstream? What did upstream have to say about this?

Your patch wasn't sent upstream. Is there a reason for this? Does Ubuntu not
have the required command? AFAICS they also pull in the gksu via Depends for
their versions.

Or is it because the package is no longer maintained upstream? Last commit
is from 2009.

Comparing with the Ubuntu package you've dropped "XS-Python-Version: all" -
why? This is a header that's preferred by the Python Policy.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: xxxterm (2nd attempt)

[Kilian Krause]

Hi Luis,

On Fri, Jul 08, 2011 at 07:17:06PM +0100, Luis Henriques wrote:
> Ok, so I re-worked the package and uploaded a new version into mentors:
> 
> dget http://mentors.debian.net/debian/pool/main/x/xxxterm/xxxterm_1.399-1.dsc

Thanks!

Even though I've not found a debian/copyright info for *.png and *.desktop
files I'll sponsor your package as is. Please try to clarify what license
upstream intended for them (probably ISC too) and document that
appropriately (or even better have them ship a LICENSE file in their
tarball). Let's see what FTPmasters will have to say.

Further I'm still finding lintian moaning about:
I: xxxterm: hyphen-used-as-minus-sign usr/share/man/man1/xxxterm.1.gz:70
I: xxxterm: hyphen-used-as-minus-sign usr/share/man/man1/xxxterm.1.gz:71
I: xxxterm: hyphen-used-as-minus-sign usr/share/man/man1/xxxterm.1.gz:748
E: xxxterm: menu-icon-not-in-xpm-format usr/share/pixmaps/xxxtermicon32.png

So you may still want to patch your manpage accordingly.

The last one I personally don't consider a show-stopper here as
http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.7 reads
"should".

Thus, built, signed, uploaded.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: libpar2 (reupload to Debian)

[Andreas Moog]

On 07/09/2011 04:26 PM, Kilian Krause wrote:

>> Updated package pushed to git://git.debian.org/collab-maint/libpar2.git
>> and available at mentors:
>> dget
http://mentors.debian.net/debian/pool/main/l/libpar2/libpar2_0.2-2.dsc
>
> that version still seems to lack that mentioned fix.

Mentors doesn't seem to process uploads at the moment. You can use

dget http://people.ubuntu.com/~amoog/libpar2_0.2-2.dsc

to get a updated package.

Thanks and sorry for causing so much work.

 Andreas




signature.asc
Description: OpenPGP digital signature

Re: Nitpicking: you are doing it wrong

[Leo "costela" Antunes]

On 09/07/11 13:53, Thomas Goirand wrote:
> If you are writing that using dh is more easy than using "normal" debhelper,
> then I don't agree, it's not always the case. I've seen many overly
> complicated
> packages with tons of dh_overwrite_* stuff, which makes the work flow very
> complicated and barely readable.

You're missing the point again: of course you can make dh rules
unreadable. The point is that it's easier to write *more* readable rules
*most* of the time. Mind you: nobody ever said *always*.
It's like Joey Hess mentioned in another mail in the thread: when used
correctly, the override targets make it clearer where the package
actually needed special treatment, which means I don't have to look for
the proverbial needle in the haystack when reading a potentially big
rules file; it's already explicitly there for me to see.


> I'm not bying into the legend that a dh using package is more easy to
> maintain.

Legend? Maybe I'm reading too much into it, but it really sounds like
you have an emotional grudge against dh.
But we seem to be discussing two different and unrelated things here:
1) maintainability
2) understanding of the underlying system

I say they're unrelated because it's irrelevant to the first point if
the maintainer knows how a tool works as long as he knows how to use it
to overcome possible problems and the end-package quality remains the same.

I'll address the first point here and the second as a response a bit
further down.
What makes a package easier to maintain must be judged by the ease with
which a different DD can make contributions to it, because the
maintainer him/herself is way too used to the code to make objective
observations (you probably remember why you used this or that, so it
shouldn't seem complex to you). I also assume that starting from
scratch, without any prejudice, it's *at least* as easy to learn to use
dh_* helpers as dh short style (again: we're discussing just the first
point here; no understanding necessary at this point).
Now, all things being equal you want to do an NMU. If it's your average
package with just one important but small detail, you might very well
open the rules file, parse its ~100 lines, not see the detail, try to
make whatever change you wanted to make, have it blow up in your face
and finally go back to the rules file and read it more carefully.
Why did you miss the detail? Because it's easier to miss something in
~100 lines of almost-always-identical code (where you skim more then
read), than in 10 lines of code where the only thing is an override
target telling you *exactly* what you should pay attention to.
To make matters a bit worse, dh_* style encourages a bit of cruft: since
the lines have to be there anyway, you have less incentive to clean up
after yourself and remove arguments which aren't needed anymore (like
old -X arguments for files that aren't installed anymore). This may not
have any impact on the final package, but it adds up to the things
people unfamiliar with the code will try to keep in mind, even if it's
unimportant, making the job of understanding the rules file a bit harder.

Of course these arguments highlight a *small* difference in
maintainability and are in no way reason for me to go out screaming for
people to re-upload everything with dh short style, but it's reason
enough for a so inclined sponsor to ask potential sponsorees "please use
a shorter rules file where possible because I don't want to have to
parse ~100 lines of almost-standard dh_* example code to make sure I'm
not doing something stupid whenever I want to change something"


> As for the performance, it's quite obvious that dh is doing so many useless
> debhelper calls. Just read what you see on screen.

Yes, that's obvious, but does it cost you more than a couple of seconds
per build? No.
In that case, these mere seconds are more then worth it making a more
readable package for your average DD. (again, I can't stress it enough:
I'm not saying it's a "one size fits all" solution, but use it where it
works).
You make it sound like these extra dh_ calls have some impact besides
irritating you on a pure "quest for theoretical elegance" level, which
they don't.


> I hope you didn't miss-read me. I do push for using debhelper, but not dh,
> which I have reasons to dislike. One of the most obvious reason is that
> people
> are going to just rely on things they don't understand. It's hiding a
> complexity
> that people HAVE to understand. CDBS is even worth than dh in this regard.

And here I address the second point mentioned earlier.
This argument is also a dud. It's equally easy for a maintainer to use
dh_* or dh short style without knowing what's going on underneath. I
know I did this with dh_* almost 10 years ago. You can simply copy one
of the example dh-make rules files and semi-blindly hack away at it
until it compiles and generates a lintian-clean package. You don't
automatically gain more knowledge about the system simply because you

Re: RFS: libpar2 (reupload to Debian)

[Kilian Krause]

Hi Andreas,

On Sat, Jul 09, 2011 at 03:50:11PM +0200, Andreas Moog wrote:
> On 07/09/2011 12:38 AM, Andreas Moog wrote:
> [...]
> > Or, what would be even easier, I could just ignore the lintian warning
> > for now, file a wishlist bug against the package once it's built and go
> > from there with the (future) cleaned up api?
> 
> After a small discussion on IRC, this is what I will do.
> 
> Updated package pushed to git://git.debian.org/collab-maint/libpar2.git
> and available at mentors:
> dget http://mentors.debian.net/debian/pool/main/l/libpar2/libpar2_0.2-2.dsc

that version still seems to lack that mentioned fix.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Nitpicking: you are doing it wrong

[Scott Howard]

On Fri, Jul 8, 2011 at 6:55 AM, Jakub Wilk  wrote:
> Don't get me wrong, in my opinion (some of) these things are "good". But
> making a big fuss about them is not helping anybody. It only distracts
> attention from things that are important, and creates false impression that
> they are somehow crucial for high quality packages. I can assure, they are
> not.

Getting back to the original point for a second, I think that it has
been shown that there are no "right" or "wrong" nitpicks (at least in
the list that you posted.) I originally wasn't trying to post a
reference implementation for sponsorship but just give examples and
reasons as to why those nitpicks might not be "wrong." Sponsors/DDs
are well aware that there are multiple ways of handling a package for
sponsorship. People asking for sponsorship are allowed to disagree
with comments during a review, and being able to communicate the
disagreement and work with a sponsor is a sign of maturity (someone
that might be good to start the NM process.)

One of the great things about sponsorship is that it is a case by case
basis: each sponsor, sponsoree, and package has different levels of
comfort, skill sets, and requirements. In some cases, the listed
nitpicks are crucial for a high quality package, and in some cases
they are, at best, an exercise in packaging (which, for many new
contributors, may be quite useful.) At worst, to an experienced
contributor, those nitpicks are a waste of time, but an experienced
contributor should already have a good working relationship with a
sponsor that wouldn't require all of that for an upload. A "cold call"
request for sponsorship on -mentors will most likely have many
nitpicks (some may even be contradictory: one sponsor may say no
dh/cdbs while another may ask you to use dh/cdbs.) The requester's job
is to take those reviews and work with their sponsor to do what's
right for that package (and that sponsor.)

Regards,
Scott


-- 
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/CANg8-dBi2G=FzpW3UVnLSNOXwZLEqAGb5NCuHMVDJ0u=jm0...@mail.gmail.com

Re: RFS: xnoise (2nd try)

[Alessandro Ghedini]

Hi,

On Fri, Jul 08, 2011 at 04:02:08PM +0200, shuerhaaken wrote:
> I am looking for a sponsor for my package "xnoise".
> 
> * Package name: xnoise
>   Version : 0.1.26-1
>   Upstream Author : Jörn Magens 
> * URL  : http://code.google.com/p/xnoise/
> * License: GPLv2+
>   Section : x11
> 
> It builds these binary packages:
> xnoise - media player for Gtk+
> xnoise-dev - media player for Gtk+ (development files)
> 
> The package appears to be lintian clean.
> 
> The upload would fix these bugs: 632932

Here are some comments on your package, note that I'm not a DD, hence I 
cannot sponsor your package:

- debian/control:
  + You don't need to manually add libraries to the Depends field: that's 
  what the ${shlibs:Depends} variable is made for. It gets replaced at build
  time with the libraries used and their versions.
  + At some point the long description states "There is are plugins 
  available.", I think there's a typo in there :)
  + There's another typo in the descriptions, "Gstreamer" should be 
  "GStreamer".
  + The package Build-Depends on debhelper (>= 7.0.50). Given that this is 
  the first version of the package I think it may be a good idea to start
  with debhelper (>= 8) (that's the recommended version). Don't forget to 
  bump also debian/compat.
  + Are those versioned Build-Depends (apart from the debhelper one) really
  needed (so that the package won't build if the versions are not 
  satisfied)? If not, please drop them. They make more difficult to backport
  packages.
  + IMHO the Section should be "sound" instead of "x11".
  + xnoise-dev Depends on xnoise (>= 0.1.25). If your intent is to depend 
  on the newer version of xnoise, something like (= ${binary:Version}) 
  would be better, so that the version gets updated after each build and 
  you don't need to update it manually.
  + It may be a good idea to split the plugins in a separate package,
  something like xnoise-plugins. It would move some of the Depends out of 
  the main package, so that users are not forced to install them all if not
  needed. You may then Suggests or Recommends it from the main package.

- debian/copyright:
  + You may want to use the DEP5 "Machine-readable debian/copyright" 
  format [0]. It's not a requirement but it's highly appreciated by most 
  sponsors :)
  + You should use a versioned path for the license:
  "/usr/share/common-licenses/GPL-2" not "/usr/share/common-licenses/GPL".

- debian/rules:
  + The comments at the beginning of the file are not needed, please remove
  them.
  + As Joachim suggested, you may want to use a debian/xnoise.manpages file
  instead of manually overriding dh_installman.
  + The package Build-Depends on autotools-dev but it is not used. You 
  should add "--with autotools-dev" on the "dh $@" line.

- debian/xnoise.install:
  + This lists "usr/lib/xnoise/*.so", isn't that file better installed in
  the -dev package?

- debian/watch:
  + You may want to use the googlecode.debian.net redirector. Something like
http://googlecode.debian.net/p/xnoise/xnoise-(\d+.*)\.tar\.bz2

Note that there may be something more that I miseed.

Cheers

[0] http://dep.debian.net/deps/dep5/

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


-- 
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/20110709135408.ga14...@pc-ale.fastwebnet.it

Re: RFS: libpar2 (reupload to Debian)

[Andreas Moog]

On 07/09/2011 12:38 AM, Andreas Moog wrote:
[...]
> Or, what would be even easier, I could just ignore the lintian warning
> for now, file a wishlist bug against the package once it's built and go
> from there with the (future) cleaned up api?

After a small discussion on IRC, this is what I will do.

Updated package pushed to git://git.debian.org/collab-maint/libpar2.git
and available at mentors:
dget http://mentors.debian.net/debian/pool/main/l/libpar2/libpar2_0.2-2.dsc

Thanks,

 Andreas



signature.asc
Description: OpenPGP digital signature

Re: Nitpicking: you are doing it wrong

[Gergely Nagy]

Thomas Goirand  writes:

> On 07/09/2011 05:14 AM, Gergely Nagy wrote:
>> I believe that when someone knows the underlying system, using helpers
>> is the way to go, because it makes not only your task easier, it also
>> makes it easier for others to understand the packaging.
>>   
> We were talking about mentoring, and you are talking about someone "who
> knows the underlying system", and we should generalize and push them to
> use dh because of that. Isn't there is something wrong here?

I thought we were talking about sponsoring. Which is not the same as
mentoring. There are people who have good knowledge of debian package
building, yet, are sponsored.

But even if it's one's first package, I'd rather push them towards dh as
a starting point, becuase that's _simple_. Getting to know the
underlying system takes time, and when you expose a new contributor to
that, he might very well run away.

In short, one needs to find out on a case by case basis which would be
better. I see no point pushing someone who already has 10+ packages in
Debian towards dh7, when he'd much rather just be done with it and use
dh8.

On the other hand, when someone's obviously inexperienced, and makes
silly mistakes, explaining that mistake, and suggesting to play with dh7
(or even helper less) to understand the system better might be a good
approach.

But neither fits all cases.

>> NMUing something with a complex, home-built debian/rules is a pain in
>> the backside at best.
>>   
> Come on! It's not. Most debian/rules using debhelper (and not CDBS or dh)
> looks nearly the same, with very little tweaks.

Most dh7 packages look similar enough, yes. Those are the least of one's
worries, though.

Nor do these fall under the 'complex, home-built debian/rules' category.

>> I don't know about you, but for 5 seconds, I'm not going to give up
>> convenience.
>>   
> It really depends. If the package is really small, and if it takes 6
> seconds in total
> to build, then skipping 5 seconds is a win. If it takes anyway 2
> minutes, then
> yes, I don't care about 5 seconds.

5 seconds never matters. Ever. Not even if that 5 seconds is 90% of the
build time. It won't stall the buildds, it won't make any difference at
all.

>> Then again, the beauty of Debian is that people are allowed to tailor
>> their packaging to their own liking (as long as it conforms to
>> policy... sadly a debian/rules written in SHOOP does not). There's
>> arguments for and against both helper-using and helper-less packaging,
>> neither is a silver bullet.
>>   
> My point to give arguments about not using dh was *not* to start a troll
> thread about what is best practices. It was simply to tell that there
> are some
> arguments for and against using dh,

Agreed, there are arguments for and against dh. There's more for it than
against it, though, and if one chooses to use dh, in the vast majority
of cases, he shouldn't be discouraged, in my opinion.

> For this, Jakub is 100% right. At best, this would be a sponsor
> requirement (and for sure, it wont be mine, which is only to not use
> CDBS which I don't understand).
>
> So don't take me wrong. I'm not vouching *against* dh, in some cases I
> agree it might be convenient, but just not always, and at the end,
> it's more a mater of preferences.

We seem to agree then, it's just our preferences lying on other sides of
the fence ;)

-- 
|8]


-- 
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/87tyavboau@luthien.mhp

Re: RFS: qasmixer

[Ansgar Burchardt]

Hi,

"Sebastian H."  writes:
>> You should now get a mail from the archive that your package is NEW and will
>> require FTPmaster approval before officially listed in the archive.
>
> Got it and found the package in the NEW queue.
> http://ftp-master.debian.org/new.html
>
> It shows "source" and "i386" which is fine for (my) netbook(s).
> I wonder though, will there be an amd64 package at some point?

Packages get build for all architectures after they reach the archive,
ie. after NEW.  You can see the build status and logs at [1] (also
linked from the PTS [2]).

Regards,
Ansgar

[1] 
[2] 


-- 
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/85vcvby7mv@tsukuyomi.43-1.org

Re: Nitpicking: you are doing it wrong

[Thomas Goirand]

On 07/09/2011 05:14 AM, Gergely Nagy wrote:
> I believe that when someone knows the underlying system, using helpers
> is the way to go, because it makes not only your task easier, it also
> makes it easier for others to understand the packaging.
>   
We were talking about mentoring, and you are talking about someone "who
knows the underlying system", and we should generalize and push them to
use dh because of that. Isn't there is something wrong here?
> NMUing something with a complex, home-built debian/rules is a pain in
> the backside at best.
>   
Come on! It's not. Most debian/rules using debhelper (and not CDBS or dh)
looks nearly the same, with very little tweaks.
> And yes, one does sacrifice a lot of control on the altar of
> convenience. But I don't see that as a problem, there's nothing wrong
> with convenience. And while useless helper scripts add to the build
> time, that load is negligible.
>
> Even on the slowest machine I could get my hands on (emulated armel,
> with ~256Mb memory, running on an dual-core amd64 host, along with 4
> other VMs), the difference between using dh $@ and explicit dh_*
> commands on an average package was about 3 seconds. Completely getting
> rid of debhelper and doing everything by hand made it 2 more seconds
> faster.
>
> I don't know about you, but for 5 seconds, I'm not going to give up
> convenience.
>   
It really depends. If the package is really small, and if it takes 6
seconds in total
to build, then skipping 5 seconds is a win. If it takes anyway 2
minutes, then
yes, I don't care about 5 seconds.

> Then again, the beauty of Debian is that people are allowed to tailor
> their packaging to their own liking (as long as it conforms to
> policy... sadly a debian/rules written in SHOOP does not). There's
> arguments for and against both helper-using and helper-less packaging,
> neither is a silver bullet.
>   
My point to give arguments about not using dh was *not* to start a troll
thread about what is best practices. It was simply to tell that there
are some
arguments for and against using dh, and as a consequence, I found very bad
to write in this list that not using dh was a bad idea. People like
different
things, and using a helper like dh or CDBS should *not* be a requirement
written in this list. For this, Jakub is 100% right. At best, this would
be a
sponsor requirement (and for sure, it wont be mine, which is only to not
use CDBS which I don't understand).

So don't take me wrong. I'm not vouching *against* dh, in some cases I agree
it might be convenient, but just not always, and at the end, it's more a
mater
of preferences.

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/4e1843d4.7000...@debian.org

Re: Nitpicking: you are doing it wrong

[Thomas Goirand]

On 07/09/2011 05:41 AM, Leo "costela" Antunes wrote:
> On 08/07/11 22:23, Thomas Goirand wrote:
>   
>> On 07/08/2011 08:47 PM, Scott Howard wrote:
>> 
>>> Right now, the general consensus is the dh and cdbs produce
>>> debian packages that are easier to maintain in the long run (if the
>>> sponsor has to take over maintenance of the package or if NMUs are
>>> required in the future.)
>>>   
>> I really would like you to explain WHERE you saw such a consensus.
>> When it goes down to myself, I would *not* sponsor a package that
>> is using either dh or CDBS, because I like to be in the control and see
>> what's going on. I believe that CDBS/dh is hiding what's necessary to
>> do a good packaging, and is calling too many unnecessary helpers,
>> which slows down the build process. Also, with dh_override_*, if you
>> have a lot of them, it soon becomes unreadable. That's only my opinion
>> though, but I suspect that I might not be the only one to think this way.
>> In anyways, I don't see at all a consensus here!!!
>> 
> Seeing what's going on is important for learning and for debugging.
> Thankfully debugging with dh is pretty mature, should you happen to need
> it (don't really know about cdbs), but having to read a non-dh-using
> rules file to understand exactly what happens when and why can be a lot
> of work and shouldn't be imposed on your fellow DDs if you don't have a
> good reason for it (curiosity and a micro-management tendency are not
> good reasons; funky non-standard build-systems are)
>
> Please use dh/cdbs/whatever other means necessary to make your packaging
> work easy to read and understand. Don't make the packaging more complex
> for other people just because you want to "know what's going on". That
> sounds awfully like NIH[0].
> You never know who might have to NMU it, make QA uploads, etc and even
> you yourself might find it pretty hard to remember why you did something
> in this particular fashion, when it actually could just as well be done
> in a more common way.
> Not using these tools goes against your own advice here[1]: you're
> making the life of other developers who have to look at your code harder
> for no reason.
> Or to put it more succinctly in your own words: "otherwise, you have no
> rules at all and it's a mess".
>
> And your performance argument seems like a dud unless you can provide
> some evidence that you actually save a significant amount of time by not
> using dh/cdbs/whatever during package builds (and by significant I mean
> more than just a couple of seconds per build).
>
> Cheers
>   
If you are writing that using dh is more easy than using "normal" debhelper,
then I don't agree, it's not always the case. I've seen many overly
complicated
packages with tons of dh_overwrite_* stuff, which makes the work flow very
complicated and barely readable.

I'm not bying into the legend that a dh using package is more easy to
maintain.

As for the performance, it's quite obvious that dh is doing so many useless
debhelper calls. Just read what you see on screen.

I hope you didn't miss-read me. I do push for using debhelper, but not dh,
which I have reasons to dislike. One of the most obvious reason is that
people
are going to just rely on things they don't understand. It's hiding a
complexity
that people HAVE to understand. CDBS is even worth than dh in this regard.

On 07/09/2011 07:09 PM, Bernhard R. Link wrote:

> But please also do not use anything you do not understand.
> I my eyes the normal dh_* scripts are a good middle ground in being
> high level enough to not hide the big picture in details while still
> being transparent enough to know what's going on. Especially having
> the calls to upstream's build system in such files explicitly listed
> makes it easy to check they are called the proper way.
> Using dh or cdbs means it needs quite some knowledge to be sure it
> is done right.

Exactly!!! And while I'm not pushing you to like or use this type of
packaging,
I don't see why you should push me for another one.

Thomas


-- 
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/4e18414d.70...@debian.org

Re: RFS: qasmixer

[Sebastian H.]

Hi Kilian


The whole point for the 0.12.1 release was to make Debian
integration smoother. Since most things seem to work now I've
uploaded the tarball to the SF project page. uscan still doesn't
find it but that's probably because the SF mirrors are not
synchronized, yet.


Yes, that's to be expected with the sf.net qa wrapper.


It's there now and uscan feels lucky.
http://qa.debian.org/watch/sf.php/qasmixer


And just for the record, sf.net itself still reads:
"Looking for the latest version? Download Release version 0.11.0 (173.4 KB)"

Funny, eh? ;-)


Thanks for the hint. That was actually a missing tag in the SF file 
dialog. Fixed.



There's no specific reason for the hardcoded dependencies.
I just didn't know how great the automatic dependency resolution
works and put in some libraries of which I knew QasMixer would play
along with well. They're gone now.


Excellent. Just like I thought it was meant to be. And yes, that's the magic
you want to have stuff packaged for. ;-)


Indeed :)


Built, Signed, Uploaded.


Thanks a lot for the support! :)


You should now get a mail from the archive that your package is NEW and will
require FTPmaster approval before officially listed in the archive.


Got it and found the package in the NEW queue.
http://ftp-master.debian.org/new.html

It shows "source" and "i386" which is fine for (my) netbook(s).
I wonder though, will there be an amd64 package at some point?

Best,
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/4e1836d0.1070...@gmx.de

Re: Nitpicking: you are doing it wrong

[Bernhard R. Link]

* Leo costela Antunes  [110708 23:41]:
> Please use dh/cdbs/whatever other means necessary to make your packaging
> work easy to read and understand. Don't make the packaging more complex
> for other people just because you want to "know what's going on".

But please also do not use anything you do not understand.
I my eyes the normal dh_* scripts are a good middle ground in being
high level enough to not hide the big picture in details while still
being transparent enough to know what's going on. Especially having
the calls to upstream's build system in such files explicitly listed
makes it easy to check they are called the proper way.
Using dh or cdbs means it needs quite some knowledge to be sure it
is done right.

> You never know who might have to NMU it, make QA uploads, etc and even
> you yourself might find it pretty hard to remember why you did something
> in this particular fashion, when it actually could just as well be done
> in a more common way.

In my experience with modifying packages locally cdbs and dh are quite
a pain, as too many things are done automatically so that small changes
can require quite a big diff.

Bernhard R. Link


-- 
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/20110709110910.ga2...@pcpool00.mathematik.uni-freiburg.de

Re: how to get people to run lintian on their packages

[Jakub Wilk]

* Arno Töll , 2011-07-09, 11:13:

Automatically running code from random people sounds rather risky to me.

...
And now you're even giving them root rights!  I suppose this is out of 
the question.


Well, this is not necessarily a problem. There are enough possibilities 
to come over this problem, similarly to the official Debian build 
infrastructure (sbuild/wanna-build).


Ahem. Our buildd infrastructure might not not be a best example of doing 
things securely.


--
Jakub Wilk


--
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/20110709094100.ga7...@jwilk.net

Re: how to get people to run lintian on their packages

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Sven,

On 09.07.2011 10:36, Sven Joachim wrote:
> On 2011-07-09 10:20 +0200, Reijo Tomperi wrote:
> Automatically running code from random people sounds rather risky to me.
...
> And now you're even giving them root rights!  I suppose this is out of
> the question.

Well, this is not necessarily a problem. There are enough possibilities
to come over this problem, similarly to the official Debian build
infrastructure (sbuild/wanna-build).

I guess this is more a problem of someone implementing it, rather than a
technical one. I believe, Asheesh would certainly accept such a thing
for the Debexpo project. Or not, since this requires quite a lot of
resources.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOGBvJAAoJEMcrUe6dgPNtSGQQAK+dLdTkyjRwha42ZmJrvbT+
C3bWVlXeGFzXlnwLzDzaZbS56srWqqWYOP8RMrlxlDYnKOUH6leqpHc4IHb/T20W
ugoDJE6xVt5HBI/PcKiabbC/AxqyUbH06Cy0QzOY1wllNhmUjB1WzU1eJqKD8Gje
oevYG3ThYvl7RpZsHXzqin1riBPJfNCkYGP1IZQokA0einGxifZXyS4IUEIldfu1
Z3iL3uOBZIElNvpua1UfU35aKaiYOO2tsyRvMOsBZLtwh2YX/q6aUK5mMfhxkEKe
Ara7jC+NPyLu7Ol6xWv1AscHfw9jwBu1SyaG7HqVtkXCm0ZuKxVgDUlMDnNpZXkk
ukhz+PGrG5kStJrQE9EZxA8pWJXD70t5h+MIjmAhCHsgUuvzHcwbzPT5xH13rbce
tIBSTZQ/rVyZkCPzVImc5U26USOVRle52HOKYk2Eh1rSGy0DZBFnOrfXBDkzty87
bDMs4ku+em7EPL7GEcuygApbgx0t2JXZVEMsRHKSC8exLvcT0Ia8WahTUzR7BL0r
W8baiPYoQpIk8ntw6/FdITrz7RyHIcqcDhim/8A3IhO3avD+heQNM4PW9QY3bnJp
NcEwLjTDGem/761RcALEhsedQODOaLnTzNszCs8cd+oaiFmtf03SW/ESh+O0hRUf
LmmEGsc4gIQWt5mrjc8i
=gmbK
-END PGP SIGNATURE-


-- 
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/4e181bc9.7060...@toell.net

Re: how to get people to run lintian on their packages

[Reijo Tomperi]

 Sven Joachim wrote:


And now you're even giving them root rights!  I suppose this is out of
the question.


Is it impossible to setup a sandbox where this is done? Isolate it from 
everything, except from some trivial output mechanism which will give 
the results back to service.


--
Reijo


--
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/4e181a03.2010...@users.sourceforge.net

Re: how to get people to run lintian on their packages

[Sven Joachim]

On 2011-07-09 10:20 +0200, Reijo Tomperi wrote:

> We could have a service where we submit the package. That service will
> then run some checks for it. E.g.
> - building the package

Automatically running code from random people sounds rather risky to me.

> - lintian check.
> - install & uninstall

And now you're even giving them root rights!  I suppose this is out of
the question.

Cheers,
   Sven


-- 
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/87iprbx334@turtle.gmx.de

Re: how to get people to run lintian on their packages

[Reijo Tomperi]

 Paul Tagliamonte wrote:


We do have part of the upload on m.d.n, I have a hunch it'd be fairly
simple to actually run Lintian on it, and report the status of the
package.


I second this.

We could have a service where we submit the package. That service will 
then run some checks for it. E.g.

- building the package
- lintian check.
- install & uninstall

The service could then send email to submitter where it would either 
list errors found from the package or instructions what to do next to 
request for sponsoring (or uploading directly if user has permissions). 
Instructions could include e.g. an url to a webpage which will tell on 
first sight if the package is error free or if there are errors, it 
would list them.


If done properly, this could reduce the work of the mentors and 
sponsors. E.g. it could give instructions how to fix the most common 
problems or at least give url to a tutorial that explains it.


It might not work for all packages, but it would for most I guess?

--
Reijo


--
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/4e180f40.2010...@users.sourceforge.net