Bug#659894: RFS: minidlna-1.0.23+dfsg-1 (new upstream version)
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "minidlna".
* Package name: minidlna
Version : 1.0.23+dfsg-1
Upstream Author : Justin Maggard
* URL : http://sourceforge.net/projects/minidlna/
* git : git://gitorious.org/debian-pkg/minidlna.git
git-web : https://gitorious.org/debian-pkg/minidlna
* License : GPL-2
Section : net
It builds those binary packages:
minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems
It's another new upstream version, after an unsuccessful RFS for 1.0.22+dfsg-1
(http://lists.debian.org/debian-mentors/2011/12/msg00374.html).
It fixes the following bugs:
* http://bugs.debian.org/650328
('/etc/inid.d/minidlna status' always reports minidlna is not runing)
* http://bugs.debian.org/656010
(Memory leak in current version of Debian package - fixed in main
distribution)
* http://bugs.debian.org/659871
(Please package 1.0.23)
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/minidlna
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.23+dfsg-1.dsc
I would be glad if someone uploaded this package for me.
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/20120214160519.gb3...@marvin.lan
Bug#658204: RFS: bibtool -- tool for BibTeX database manipulation
Hi Jerome,
Jerome Benoit wrote:
> I am looking for a sponsor for my package "bibtool".
>
> * Package name: bibtool
>Version : 2.53-1
>Upstream Author : Gerd Neugebauer
> * URL :
> http://www.gerd-neugebauer.de/software/TeX/BibTool/index.en.html
> * License : GPL-1+
>Section : tex
>
> It builds those binary packages:
>
> bibtool- tool for BibTeX database manipulation
I took a look at your package, here are a few comments:
- debian/preinst has a comment saying it should be removed post-etch;
now seems like it'd be a good time.
- lintian gives a few warnings:
P: bibtool source: source-contains-cvs-control-dir regex-0.12/doc/CVS
P: bibtool source: source-contains-cvs-control-dir regex-0.12/CVS
P: bibtool source: unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5
You may want to get in touch with upstream about that. Also, ideally
regex shouldn't be embedded in the source.
- I'm not sure why you're closing bugs #291134 and #187255 in the
changelog; they're not fixed by this upload in particular, they're
just not considered bugs. I think you should close these bugs
manually and remove those two entries from the changelog.
The second entry ("Features have been either"...) doesn't seem very
useful; either give a brief summary of the changed features, or
remove the entry entirely. The first entry ("New upstream version")
essentially suggests that there are new or extended features, and
users should know to check the upstream changelog already.
(Actually, looking into it, there isn't even an entry for 2.53 in
Changes.xml.)
- In debian/copyright, you list yourself as the sole copyright holder
for the files under debian/*, but you didn't do the packaging from
scratch. What about the copyright of the previous maintainers?
- In the bibtool(1) man page, the FILES section states "none" and the
DIAGNOSTICS section "many"; I think both sections should simply be
removed.
In the SEE ALSO section, the BibTool Manual is referred to as
bibtool.tex, but this file isn't installed on Debian; instead, it
should refer to bibtool.pdf.gz installed in /usr/share/doc/bibtool.
Also, in the .TH header in bibtool.1, something more useful than
"local" (like a date for instance) should be used.
- Have you forwarded your patches for inclusion upstream?
I hope this helps.
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/20120215110517.gb18...@marvin.lan
Bug#658204: RFS: bibtool -- tool for BibTeX database manipulation
Guido van Steen wrote: > > I tried to fix the warnings emitted by lintian, but the lintian on my > > boxdoes not report the one above: > > how can I reproduce this report. > > Use the Lintian version in backports (or in Sid). Do not use the > version in Stable. It is not updated. Yes, and run it with '-IE --pedantic' to get all the warnings. -- 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/20120215183439.ga29...@marvin.lan
Bug#659822: RFS: mpd-sima/0.9.0-1 (New upstream version)
Hi Geoffroy,
Geoffroy Youri Berret wrote:
> I am looking for a sponsor for my package "mpd-sima".
>
> * Package name: mpd-sima
>Version : 0.9.0-1~1.gbp3e591f
>Upstream Author : Jack Kaliko
> * URL : http://codingteam.net/project/sima
> * License : GPLv3
>Section : sound
>
> It builds this binary package:
>
> mpd-sima - Automagically add titles to MPD playlist
I had a look at your package, here are my comments:
- In debian/copyright, since you have a standalone License paragraph
for the GPL-3, you probably want to remove the full text from the
License field of the first Files paragraph.
Also, the license text says "version 3 or any later version"; if
that's the case, you should use GPL-3+; if not, make sure to remove
the "or any later version" part.
And there's a typo in the Source field ("donwload").
- I think the long description could be reworded a little bit; you
mention Python twice and "to feed MPD playlist with artist similar
to your currently playing track" sounds a bit wrong (should be "your
MPD playlist" and "artists" or "tracks from artists", or something
like that.
- In debian/control, Recommends is empty; you should remove it.
- In debian/mpd-sima.postrm, you use awk but you don't Depend on it.
You're also checking if /usr/sbin/deluser is executable and
silently not removing the user if it's not (same thing for
delgroup). Since you Depend on adduser, you should assume these
commands exist, and it should be an error visible to the user if
they don't.
- In debian/mpd-sima.postinst, since mpd-sima is not meant to be run
as root, it might be a good idea to run it after creating the user
and group, as the the mpd-sima user.
On second thought, why even do this during installation? The init
script seems like a better place to do this.
- Regarding debian/wrappers, why not intall the python modules
some place where python can find them by default?
And I think first line should read "#!/bin/sh", as outlined in
debian policy 10.4.
- Finally, a word on the man pages. I'll focus on mpd-sima.cfg.1, but
some of it applies to the other man pages too.
First of all, man pages for configuration files should be in section
5.
The NAME section should contain a _very_short_ description; use the
DESCRIPTION section for full sentences.
There should be a SYNOPSIS section, containing the full path of the
configuration file.
CONFIGURATION FILE should be called DESCRIPTION, and QUEUE MODES
should probably be a subsection of DESCRIPTION.
For the FILES section, see man-pages(7).
EXAMPLES should be called EXAMPLE. It should go after BUGS and
before SEE ALSO (again, see man-pages(7) for the correct order of
sections).
FEEDBACK should be merged with BUGS, I think.
If possible, the AUTHOR and COPYRIGHT sections should be removed
(they can be comments in the source of the man page). See
man-pages(7) for the rationale behind this.
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/20120216115106.ga30...@marvin.lan
Bug#659822: RFS: mpd-sima/0.9.0-1 (New upstream version)
Benoît Knecht wrote: > Geoffroy Youri Berret wrote: > > I am looking for a sponsor for my package "mpd-sima". > > > > * Package name: mpd-sima > >Version : 0.9.0-1~1.gbp3e591f > >Upstream Author : Jack Kaliko > > * URL : http://codingteam.net/project/sima > > * License : GPLv3 > >Section : sound > > > > It builds this binary package: > > > > mpd-sima - Automagically add titles to MPD playlist > > I had a look at your package, here are my comments: > > [...] Just a couple more things: - In debian/mpd-sima.init, you don't handle the "status" command, even though the Usage string indicates it's a valid command. - I'm not sure I understand what debian/clean is for. Are those files really generated by the build process? If so, that's surely a mistake, they're not even installed in the final package. - In debian/rules, you override dh_auto_clean but do not clean the build files yourself. You also install debian/wrappers/*, which appear to be copies of what the upstream Makefile would build; this seems like a rather fragile approach. Overall, I don't see why you can't rely on the upstream Makefile, and I think you should; it'll be much more maintainable that way. 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/20120216132937.gb30...@marvin.lan
Bug#659498: RFS: solarpowerlog -- photovoltaic data logging
Tobias Frost wrote: > I am (still) looking for a sponsor for my package "solarpowerlog". > > As now the boost transition has been completed, it is time to reissue my > request. > See for http://lists.debian.org/debian-mentors/2012/01/msg00012.html for my > last request. > > Changes since my last request: > - removed whitespaces from debian/* > - cleanup debian/changelog > - new upstream version to be fit for libconfig-1.4.8 > - hardeing flags enabled. > - went for short-form debhelper > - compat set to 9 > > dget -x > http://mentors.debian.net/debian/pool/main/s/solarpowerlog/solarpowerlog_0.22.dsc The URL above is broken, the correct one is dget -x http://mentors.debian.net/debian/pool/main/s/solarpowerlog/solarpowerlog_0.22-1.dsc -- 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/20120216142113.gd30...@marvin.lan
Bug#659498: RFS: solarpowerlog -- photovoltaic data logging
Tobias Frost wrote: > Am Donnerstag, den 16.02.2012, 15:33 +0100 schrieb Benoît Knecht: > > And it doesn't build for me in a clean chroot, I get the following error > > (full build log attached): > > well, that's strange... My packages are always pdebuild-checked and I > built it successfully on amd64, i386 and armel. (I'm using pdebuilder, > not cowbuilder) > > I also re-checked again on amd64, even created a new pbuilder > enviroment, but unfortunatly I cannot reproduce this faiure. > > Analyzing your buildlog, there's something strange with ccache: > > ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/7/d: > Permission denied > > Could that be an hint? Damn it, you're absolutely right. I'm so sorry I did this in a hurry and didn't take the time to check if it was a problem on my end. I'll take a deeper look at your package to redeem myself :) 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/20120217104250.ga18...@marvin.lan
Bug#659822: RFS: mpd-sima/0.9.0-1 (New upstream version)
Hi Jakub,
Jakub Wilk wrote:
> * Geoffroy Youri Berret , 2012-02-17, 00:41:
> >>- In debian/mpd-sima.postrm, you use awk but you don't Depend on it.
> >Right, I replaced it with a “grep | cut” alternative.
>
> While I personally don't like awk :P, but if you like it, you _can_
> use it in maintainer scripts without depending on it. awk is (in a
> way) an essential package:
> http://lists.debian.org/debian-mentors/2005/11/msg00193.html
>
> I believe that lintian would yell at you if you had unversioned
> dependency on awk. (And versioned dependency on awk would render
> your package uninstallable. :P)
Interesting. In my package (minidlna), I'm depending on (gawk | mawk),
because I'm using awk in one of the maintainers scripts too; I take it I
should remove it, right? (Yes, I'm trying to get second-hand review for
my package; one of the good things about reviewing other people's
packages :) )
> >>You're also checking if /usr/sbin/deluser is executable and
> >>silently not removing the user if it's not (same thing for
> >>delgroup). Since you Depend on adduser, you should assume these
> >>commands exist, and it should be an error visible to the user if
> >>they don't.
> >Corrected as well.
>
> Err. What Policy §6.5 says: “[…] all ‘postrm’ actions may only rely
> on essential packages and must gracefully skip any actions that
> require the package's dependencies if those dependencies are
> unavailable.”
>
> So checking for existence of /usr/sbin/deluser _is_ the right thing
> if you want to use it. See this however:
> http://lists.debian.org/debian-devel/2012/02/msg00094.html
Yes, I realize now my advice was misleading at best. What I meant is
that you should try running the command anyway, so that the error
becomes visible to the user, but then catch the exit status; something
like:
deluser ${USER} || echo "Removing ${USER} failed."
This way, if the user is watching the output, they will know they need
to remove the user by hand afterwards. Does it make sense? (Again, I'm
doing this in my package, so I'd like to know if that's wrong.)
Of course, as you pointed out, the right thing here might be not
removing the user at all, but I'm interested in the more general
question of showing the failures in maintainers scripts to the user or
not.
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/20120217110129.gb18...@marvin.lan
Bug#659498: RFS: solarpowerlog -- photovoltaic data logging
Hi Tobias,
As promised, here's my review of your package:
- In debian/solarpowerlog.default, you define /etc/solarpowerlog as
the default RUNDIR; what files is your program expecting to find
there, HTML templates? If so, installing some default templates in
/usr/share/solarpowerlog and pointing your program to that directory
seems like a better option.
You also note there that start-stop-daemon is taking care of running
solarpowerlog in the background, but according to
start-stop-daemon(8), "this is a last resort, and is only meant for
programs that either make no sense forking on their own, or where
it's not feasible to add the code for them to do this themselves";
since your program can put itself in the background, you should
rather use that possibility. This way, it will also make sense
checking the exit status of start-stop-daemon in do_start in the
init script, because if you use its '-b' option, it can't determine
if the process failed to execute.
And it'd be best to wrap lines at 80 columns.
- Running uscan tells me:
Processing watchfile line for package solarpowerlog...
Newest version on remote site is 0.21a, local version is 0.22
solarpowerlog: remote site does not even have current version
- I think your short description should read "photovoltaic data
logger", as in "solarpowerlog is a ..."
And in the long description, you wrote "photo-voltaic"; I think you
should stick to the former spelling.
The second paragraph of the long description is missing punctuation.
- In the solarpowerlog(1) man page, the SEE ALSO section appears to be
a subsection of OPTIONS.
Please consider removing the AUTHOR section (see man-pages(7) for an
explanation why).
In DESCRIPTION, I would start with "solarpowerlog tracks and
logs..."; it's not just its purpose, it's what it actually does,
right? Same for the second sentence.
In OPTIONS, you start with "These programs"; why the plural?
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/20120217114850.gc18...@marvin.lan
Bug#659894: RFS: minidlna-1.0.23+dfsg-1 (new upstream version)
Benoît Knecht wrote:
> * Package name: minidlna
>Version : 1.0.23+dfsg-1
>Upstream Author : Justin Maggard
> * URL : http://sourceforge.net/projects/minidlna/
> * git : git://gitorious.org/debian-pkg/minidlna.git
>git-web : https://gitorious.org/debian-pkg/minidlna
> * License : GPL-2
>Section : net
>
> It builds those binary packages:
>
> minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems
I've uploaded an updated version of my package. It fixes a mistake that
lead to the configuration file not being included in the package. It
also improves said configuration file, fixing bug#653221.
I've also implemented a few minor changes based on a conversation with
Jakub Wilk in another thread.
The updated package is available from the same URL as before:
dget -x
http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.23+dfsg-1.dsc
> It fixes the following bugs:
>
> * http://bugs.debian.org/650328
>('/etc/inid.d/minidlna status' always reports minidlna is not runing)
> * http://bugs.debian.org/656010
>(Memory leak in current version of Debian package - fixed in main
> distribution)
> * http://bugs.debian.org/659871
>(Please package 1.0.23)
It fixes one additional bug:
* http://bugs.debian.org/653221
(Does not find files after media_dir configuration change)
--
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/20120217162400.ga19...@marvin.lan
Bug#659894: RFS: minidlna/1.0.24+dfsg-1 -- lightweight DLNA/UPnP-AV server (new upstream version)
retitle 659894 RFS: minidlna/1.0.24+dfsg-1 -- lightweight DLNA/UPnP-AV server (new upstream version) thanks Benoît Knecht wrote: > Benoît Knecht wrote: > > * Package name: minidlna > >Version : 1.0.23+dfsg-1 > >Upstream Author : Justin Maggard > > * URL : http://sourceforge.net/projects/minidlna/ > > * git : git://gitorious.org/debian-pkg/minidlna.git > >git-web : https://gitorious.org/debian-pkg/minidlna > > * License : GPL-2 > >Section : net > > > > It builds those binary packages: > > > > minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems A new upstream version (1.0.24) has been released, which I've packaged and uploaded to mentors: dget -x http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.24+dfsg-1.dsc 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/20120219152857.gc21...@marvin.lan
Bug#658235: RFS: libjreen, the xmpp library (3rd try, 2 months later)
Hi Vsevolod, Vsevolod Velichko wrote: > I am looking for a sponsor for my package "libjreen" (and do this for > the 3rd time, because I've got no answer, neither positive nor > negative since November 2011). > > * Package name: libjreen > Version : 1.0.1-1 > Upstream Author : Ruslan Nigmatullin > * URL : http://qutim.org/jreen > * License : GPL2+ > Section : libs > > It builds those binary packages: > > libjreen-dev - powerful Jabber/XMPP library - development files > libjreen1 - powerful Jabber/XMPP library implemented in Qt/C++ I took a look at your package, here are a few things you may want to look into: - Some warnings from lintian: I: libjreen source: binary-control-field-duplicates-source field "section" in package libjreen1 P: libjreen source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 I: libjreen1: no-symbols-control-file usr/lib/libjreen.so.1.0.1 - In debian/control, your long description repeats the synopsis, and it doesn't consist of full sentences. See [1] for guidelines about writing good descriptions. [1] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc If you're not using a VCS, you should remove those commented-out lines. - In debian/rules, the dh_installchangelogs override isn't needed; debhelper will pick up the upstream changelog automatically. The dh_auto_install override could also be replaced by using debian/.install files (see dh_install(1) for details). - In debian/copyright, you should use the predefined short names for licenses; what you call "MIT/X11 (BSD Like)" is the Expat license. And even though it's more cosmetic than anything, GPL-2.0+ could be replaced by GPL-2+. I'm also not sure your debian/README.source is particularly relevant. First of all, one _should_ care about that copyright in Debian since those files are shipped in the source package (so clauses about distribution of those files certainly apply). If you want to say that the binary package doesn't contain any code from these files, perhaps a Comment in the relevant File paragraph in debian/copyright would be better (as this file is actually installed along with the binary package). I've built your package, but I haven't installed and tested it, so I cannot comment on that. 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/20120220155741.gb26...@marvin.lan
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
block 660125 with 660128 thanks Hi Daniel, Daniel Martí wrote: > I am looking for a sponsor for my package "heybuddy". > > * Package name: heybuddy >Version : 0.2.3-1 >Upstream Author : Jezra Johnson Lickter > * URL : http://www.jezra.net/projects/heybuddy > * License : GPLv3 >Section : net > > It builds those binary packages: > > heybuddy - light identi.ca microblogging client I had a look at your package: - Your watch file doesn't seem to work; I get the following warning: uscan warning: In debian/watch, no matching hrefs for watch line http://launchpad.net/heybuddy/+download http://launchpad.net/heybuddy/.*/heybuddy-(.*)\.tgz - You should drop the update-menus line in debian/postinst, it's already added by debhelper. In the same file, you run compileall unconditionally; I guess it should only run during configure. You do not honor the settings from /etc/python/debian_config [1]. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation These last two issues would be moot if you used dh_python2. - Your debian/rules could be much simpler if you used dh --with python2 $@ possibly with a few overrides. - Why is your man page in section 7? It seems to me it should be in section 1. It's also a bit scarce, it doesn't even tell me how to run heybuddy. If it has no options at all, you should state that fact. And please consider removing the AUTHORS and COPYRIGHT sections (see man-pages(7)). - The man page lists troorl as copyright holder for the 2009-2010 period, but debian/copyright doesn't mention it. - Do you really mean to Recommend both python-gtkspell and aspell? Seems like one spelling utility is enough. I wonder if they shouldn't be downgraded to a Suggests anyway. - Your long description partly repeats the short description; see [2] for guidelines. [2] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc 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/20120221123617.ga12...@marvin.lan
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
Jakub Wilk wrote: > * Benoît Knecht , 2012-02-21, 13:36: > >In the same file, you run compileall unconditionally; I guess it > >should only run during configure. > > What's wrong with running it unconditionally? Nothing wrong per se, it just seemed unnecessary... > As far as I know, none of the Python helpers in the wild create > maintainer script fragments that'd check the first argument. ...but if python helpers do it that way, I guess it's fine then. I didn't know it was the usual behavior, thanks for the heads up. > >You do not honor the settings from /etc/python/debian_config [1]. > > > >[1] > >http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation > > Righto. Implementing byte-compiling is not really straight-forward. > If you do it yourself, there's a great chance you'll do it wrong. > > Apart from the issue mentioned by Benoît: > - Modules are not re-byte-compiled when the default Python version > changes. > - postrm doesn't remove anything (unless /bin/sh is a symlink to > bash, which is not the default these days). Oh, right, good catch. That brings up another point actually, Daniel; both maintainer scripts are missing a #! line, declaring which shell should run them, and you may want to use set -e [2]. [2] http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s6.1 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/20120221204333.ga1...@marvin.lan
Bug#658235: RFS: libjreen, the xmpp library (3rd try, 2 months later)
Vsevolod Velichko wrote: > I'm very thankful for your package review. I've just fixed most of the > things you mentioned. However, there're a couple of moments I'm > unsure. > > > I: libjreen1: no-symbols-control-file usr/lib/libjreen.so.1.0.1 > There was a long "C++ vs symbols" discussion[1] recently with pros and > contras. I suppose, that symbols really doesn't make sense for C++ and > too hard to maintain (just to create the appropriate symbols file, I > have to somehow upload the package with initial .symbols version, wait > for build fails everywhere, collect buildd logs, and only there I'll > be able to create real .symbols file). For example, dpkg-gensymbols > generates 1633 lines of .symbols for this library. > Are you sure that it's really needed? I was merely reporting the lintian output, in case you hadn't seen it (people often run it without any additional flags and miss some relevant warnings); but the severity of this particular tag is 'wishlist', so you can ignore it if it doesn't make sense in your case. > >The dh_auto_install override could also be replaced by using > >debian/.install files (see dh_install(1) for details). > I'm unsure that .install is better solution. The one of mine should > work in most cases, even if one change library and package names, I'll > have to change only a package name in dh_auto_install override. In the > case of .install files there would be more work. Am I right? Well it just seems awfully convoluted for just moving two files; with wildcards, you could achieve the same thing with just one line in libjreen1.install (I'm not sure why you worry about library or package name changes, that shouldn't happen too often, right?) But of course your solution is not wrong, and it's ultimately your decision what to do; I just find it more complex than necessary. > I've uploaded new version to mentors[2], if you agree with my comments > above, could you review and probably sponsor the fixed version, > please? Hmm, I thought it was clear from my email address, but I guess it's not; I'm not a DD, so I can't sponsor your package. I'm just trying to help out however I can, by reviewing other people's packages. > [1] http://lists.debian.org/debian-devel/2012/01/thrd2.html#00671 > [2] > http://mentors.debian.net/debian/pool/main/libj/libjreen/libjreen_1.0.1-1.dsc 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/20120221215553.gb1...@marvin.lan
Re: RFS: bibtool/2.54 (new upstream release) -- tool for BibTeX database manipulation
Hi lina, lina wrote: > On Sat, Feb 25, 2012 at 8:32 PM, lina wrote: > > There is a problem with bibtool (I installed by aptitude install > > bibtool just now) > > > > For the journal = jbioch, > > > > It transformed the Upper case into small case. > > > > supposed to be journal = JBIOCH > > tried building from this one. > dget -x > http://mentors.debian.net/debian/pool/main/b/bibtool/bibtool_2.54+ds-1.dsc > > It still handled it the same. But BibTeX is case insensitive when it comes to string names, and this behavior is documented in the bibtool manual (section A.5, page 27); it can be customized too. -- 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/20120225130424.gc1...@marvin.lan
Re: RFS: bibtool/2.54 (new upstream release) -- tool for BibTeX database manipulation
lina wrote: > On Sat, Feb 25, 2012 at 9:04 PM, Benoît Knecht wrote: > > lina wrote: > >> On Sat, Feb 25, 2012 at 8:32 PM, lina wrote: > >> > There is a problem with bibtool (I installed by aptitude install > >> > bibtool just now) > >> > > >> > For the journal = jbioch, > >> >>> > > >> > It transformed the Upper case into small case. > >> > > >> > supposed to be journal = JBIOCH > >> > >> tried building from this one. > >> dget -x > >> http://mentors.debian.net/debian/pool/main/b/bibtool/bibtool_2.54+ds-1.dsc > >> > >> It still handled it the same. > > > > But BibTeX is case insensitive when it comes to string names, and this > > behavior is documented in the bibtool manual (section A.5, page 27); it > > can be customized too. > > Thanks, I thought the bibtool was used to beautify (format) the > manually build .bib entries. > seems it has lots of functions I don't know. Maybe you're looking for bibclean instead: http://packages.debian.org/squeeze/bibclean 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/20120225135907.gd1...@marvin.lan
Bug#659894: RFS: minidlna/1.0.24+dfsg-1 -- lightweight DLNA/UPnP-AV server (new upstream version)
Hi Ansgar, Ansgar Burchardt wrote: > Benoît Knecht writes: > > dget -x > > http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.24+dfsg-1.dsc > > The package was removed due to a bug in the new debexpo version. Could > you upload it again? Right, I had not realized, thanks. I just re-uploaded it (same URL), taking this opportunity to bump the standards version to 3.9.3 and using debhelper 9. Here's the latest changelog entry: * New upstream version: - Fix playlist browsing with no SortOrder specified - Fix inotify detection of caption file removal - Handle an empty DeviceID from Zyxel media player SOAP request - Fix false positives in playlist caching optimization when we have duplicate file names in different directories - Trim the camera model name extracted from EXIF tags - Add support for user-configurable log level settings - Add DLNA.ORG_FLAGS support * Update the minidlna.conf(5) man page with new options * Update the default minidlna.conf configuration file accordingly * Bump Standards-Version to 3.9.3 - Use /run instead of /var/run by default * Use debhelper compat 9 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/20120301145422.gb24...@marvin.lan
Bug#659894: RFS: minidlna/1.0.24+dfsg-1 -- lightweight DLNA/UPnP-AV server (new upstream version)
Benoît Knecht wrote: > Ansgar Burchardt wrote: > > Benoît Knecht writes: > > > dget -x > > > http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.24+dfsg-1.dsc > > > > The package was removed due to a bug in the new debexpo version. Could > > you upload it again? > > Right, I had not realized, thanks. I just re-uploaded it (same URL), > taking this opportunity to bump the standards version to 3.9.3 and using > debhelper 9. > > [...] I just made one further small correction (still the same URL); the changelog now reads: * New upstream version (Closes: #661259) - Fix playlist browsing with no SortOrder specified - Fix inotify detection of caption file removal - Handle an empty DeviceID from Zyxel media player SOAP request - Fix false positives in playlist caching optimization when we have duplicate file names in different directories - Trim the camera model name extracted from EXIF tags - Add support for user-configurable log level settings - Add DLNA.ORG_FLAGS support * Update the minidlna.conf(5) man page with new options * Update the default minidlna.conf configuration file accordingly * Bump Standards-Version to 3.9.3 - Use /run instead of /var/run by default * Use debhelper compat 9 * Update the DEP-5 Format URL in debian/copyright 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/20120301165052.gi24...@marvin.lan
Bug#662035: RFS: vorbisgain/0.37-1 [ITA] -- add Replay Gain volume tags to Ogg Vorbis files
Hi Daniel, Daniel Martí wrote: > I am looking for a sponsor for my package "vorbisgain" > > * Package name: vorbisgain >Version : 0.37-1 > * URL : http://sjeng.org/vorbisgain.html > * License : GPL-2 >Section : sound > > It builds those binary packages: > > vorbisgain - add Replay Gain volume tags to Ogg Vorbis files I had a look at your package and noted the following issues: - Your debian/copyright is inaccurate. The FSF and Michael Smith are not mentioned anywhere, although they own the copyright on some files. Most files seem to be LGPL, not GPL. You may need to clarify a few things with upstream, if possible; vorbis.c is said to be "distributed under the GNU General Public License, version 2.1" and that "a copy of this license is included with this source", but the GPL-2.1 doesn't exist as far as I know, and the only license included in the source is the LGPL-2.1. You can use 'licensecheck -r --copyright .' to help you get the correct copyright information. You should also add yourself to the debian/* paragraph, and from the changelog, looks like Alessio Treglia should be there too. Upstream-Source isn't a valid field. Use Source. It is also customary to include a bit more of the license text in the License paragraphs. You can find what's usually included at the end of COPYING, from "This library is free software", and changing the last paragraph with "If not, see <http://www.gnu.org/licenses/>". You can then add one last paragraph that reads "On Debian systems, the complete text"... - In debian/rules, you now bypass 'make distclean' entirely. You probably want to call dh_auto_clean first in the override. - The upstream NEWS file should be installed as a changelog, not as documentation. See dh_installchangelogs(1). This will also get rid of a pedantic lintian warning. - In debian/changelog, you mentioned that you bumped the standards version; were any changes required for that? Note it in the changelog. - In the examples about recursion in vorbisgain(1), it would be much clearer if directory names included the suffix '/'. 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/20120304111658.ga21...@marvin.lan
Bug#662026: RFS: shotdetect/1.0.86-1 [ITP]
tags 662026 moreinfo thanks Hi Giulio, Giulio Paci wrote: > I am looking for a sponsor for my package "shotdetect" > > * Package name: shotdetect >Version : 1.0.86-1 >Upstream Author : Johan MATHE > * URL : http://shotdetect.nonutc.fr/ > * License : LGPL-2.1+ >Section : misc > > It builds those binary packages: > > shotdetect - scene change detector You seem to be missing a dependency: [...] checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... none checking for libxml libraries >= ... 2.7.8 found configure: error: xslt-config not found. Please reinstall the libxslt >= 1.1.0 distribution make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 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/20120304231814.gk21...@marvin.lan
Re: Bug#662221
Hi Enas, Enas Gianni wrote: > I made a new upstream release available at > https://sourceforge.net/projects/nauticalmanac/files/ > because I had some problem with the previous release as > detailed with bug #662221, I made some fixes and I closed all the bugs > in the Changelog file. > Hope all the problems was solved and I need the package to be reviewed, > How can I get this? > Please give me some advice Follow the instructions from [1], starting at item 3. Before you upload to mentors, you can check for common mistakes by running lintian -IE --pedantic *.changes where *.changes is the changes file of your package (use lintian from unstable). [1] http://mentors.debian.net/intro-maintainers 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/20120305092343.ga24...@marvin.lan
Bug#662632: RFS: libaio-ocaml/1.0~rc1
retitle 662632 RFS: libaio-ocaml/1.0~rc1 [ITP] -- OCaml bindings for libaio tags 662632 moreinfo thanks Hi Goswin, Goswin von Brederlow wrote: > I am looking for a sponsor for my package "libaio-ocaml" > > * Package name: libaio-ocaml >Version : 1.0~rc1 >Upstream Author : Goswin von Brederlow > * URL : http://forge.ocamlcore.org/projects/libaio-ocaml/ >Vcs-Git : > git://anonscm.debian.org/pkg-ocaml-maint/packages/libaio-ocaml.git >Vcs-Browser : > http://anonscm.debian.org/git/pkg-ocaml-maint/packages/libaio-ocaml.git Vcs-Browser should link to something browsable, like a gitweb or something, if it exists. > * License : LGPL-2.1+ and link execpetion >Section : ocaml > > It builds those binary packages: > > libaio-ocaml - OCaml bindings for libaio (Linux kernel AIO access library) > libaio-ocaml-dev - OCaml bindings for libaio (Linux kernel AIO access > library) You should open an ITP bug and close it in the debian/changelog [1]. > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/libaio-ocaml This page shows a few issues already that you should also fix: no watch file, duplicate short description, and no debian version (i.e. package is native). [1] http://www.debian.org/devel/wnpp/ 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/20120305142528.gk24...@marvin.lan
Bug#662632: RFS: libaio-ocaml/1.0~rc1
Goswin von Brederlow wrote: > Benoît Knecht writes: > > Goswin von Brederlow wrote: > >> [...] > >> > >> The package is native because I am both maintainer and upstream > >> author. Does a watch file make sense for a native package? > > > > That's not what native means. See the third point of [3]. > > It says "should" and not "must" and a native package is just so much > simpler to work with at the current state of the package. Current state > is about 50 upstream releases to 3 debian changes only releases. > That might change in the future and then the package can become > non-native. But for now I feel native is the best way. You're of course free to do as you want, but I maintain that it's a very bad idea, and not doing something right because it's easier to do it wrong will almost certainly turn out to be much more of a mess and a burden than you'd have anticipated. With the path you're choosing, you're essentially making sure that no other distribution will ever package your software. They'd have to sort through every new upstream release to see if anything changed besides debian/; and when they fall behind on the upstream version simply because only Debian-specific stuff has changed, their users will start complaining and they'll have to explain the disparity. And as mentioned in [4], NMUs will be much more complicated. I think it important for any maintainer to clearly differentiate in their mind upstream from Debian, even if they happen to be the same person. Otherwise, you're artificially limiting your software to Debian, which is at the opposite side of what free software should strive for. Of course, I can't sponsor your package either way, so you can completely ignore my advice if you wish. But if I was in the position of sponsoring it, I wouldn't do it based on this point alone (and I kind of hope prospective sponsors feel the same way). I sincerely hope you'll do the right thing here. [3] http://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F [4] http://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2BAC8_directory.3F 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/20120306142202.ga31...@marvin.lan
Bug#662026: RFS: shotdetect/1.0.86-1 [ITP]
Giulio Paci wrote: > thank you for your comment. I updated the package, adding the missing > libxslt1-dev dependency and fixing a couple of other minor issues. A few things to look into: - Your man page is quite thin. Please expand it using full words instead of abbreviations (img, thumb, etc.) and full sentences. Try explaining what each option does. For instance, '-o' takes a path as an argument; to what, a directory or a file? What happens if both and XML file and a thumbnail are to be generated? Likewise, the description of '-s' doesn't help me at all. What is the range of the threshold? Is it a float or an integer? What does it represent? For '-w', what is a waveform? You also need to escape the space between 'January,' and '2012'. - debian/patches/compilation_fixes.patch contains a lot of whitespace fixes, most of them in comments; please remove those to make it easier to understand. - Why are you putting your package in contrib/misc? As far as I can see, it doesn't depend on a non-free package, so the video section seems more appropriate. - ltmain.sh is GPL-2+, and the FSF is its copyright holder; this should be reflected in debian/copyright. Use licensecheck -r --copyright . to make sure you're not missing anything else. - I don't think you should install AUTHORS; it contains a single name, and that information is in debian/copyright already. The NEWS file seems pretty useless as well. The README file is just plain confusing. 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/20120306222505.gh13...@marvin.lan
Bug#662754: RFS: libre-jigsaw/2012.03.04-1 [ITP]
block 660433 with 662754 block 660435 with 662754 merge 661857 662754 thanks Hi Jon, Jon Hulka wrote: > Dear mentors, > > I am looking for a sponsor for my package "libre-jigsaw" > > Package name: libre-jigsaw > Version : 2012.03.04-1 > Upstream Author : Jonathan Hulka > URL : https://github.com/jon-hulka/libre-jig > License : GPL-2 and CC BY-SA 3.0 > Section : games > > It builds those binary packages: > > libre-jigsaw - jigsaw puzzle > libre-jigsaw-pics - jigsaw puzzle (pictures) Please only close #660433 in the changelog, both ITP bugs are now merged and will be closed together. In general, if a bug needs to be closed because it was opened by mistake, just close it manually; there's no need to clutter the changelog with such entries. 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/20120306223646.ga27...@marvin.lan
Bug#662968: RFS: shc/3.8.7-1
tag 662968 moreinfo thanks Hi Vibhav, Vibhav Pant wrote: > I am looking for a sponsor for my package "shc" > > * Package name: shc >Version : 3.8.7-1 >Upstream Author : Francisco Rosales > * URL : http://www.datsi.fi.upm.es/~frosal/sources/ > [there is no such homepage for this program] > * License : GPL-2 >Section : devel > > It builds those binary packages: > > shc - Generic shell script compiler. Building your package in a clean chroot fails during the test phase with the following: dpkg-buildpackage: source package shc dpkg-buildpackage: source version 3.8.7-1 dpkg-buildpackage: source changed by Vibhav Pant dpkg-source --before-build shc-3.8.7 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean make[1]: Entering directory `/tmp/buildd/shc-3.8.7' rm -f *.o *~ *.x.c make[1]: Leaving directory `/tmp/buildd/shc-3.8.7' dh_clean dpkg-source -b shc-3.8.7 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building shc using existing ./shc_3.8.7.orig.tar.gz dpkg-source: info: building shc in shc_3.8.7-1.debian.tar.gz dpkg-source: info: building shc in shc_3.8.7-1.dsc debian/rules build dh build dh_testdir dh_auto_configure dh_auto_build make[1]: Entering directory `/tmp/buildd/shc-3.8.7' cc -Wall -O6 shc.c -o shc *** ¿Do you want to probe shc with a test script? *** Please try... make test make[1]: Leaving directory `/tmp/buildd/shc-3.8.7' dh_auto_test make[1]: Entering directory `/tmp/buildd/shc-3.8.7' *** Compiling script "match" CFLAGS="-Wall -O6 " ./shc -v -f match shc: WARNING!! Scripts of length near to (or higher than) the current System limit on "maximum size of arguments to EXEC", could comprise its binary execution. In the current System the call sysconf(_SC_ARG_MAX) returns -1 bytes and your script "match" is 336 bytes length. shc shll=sh shc [-i]=-c shc [-x]=exec '%s' "$@" shc [-l]= shc opts= shc: cc -Wall -O6 match.x.c -o match.x shc: strip match.x shc: chmod go-r match.x *** Running a compiled test script! *** It must show files with substring "sh" in your PATH... ./match.x sh /usr/sbin/add-shell /usr/sbin/remove-shell /usr/bin/bashbug /usr/bin/chsh /usr/bin/cow-shell /usr/bin/debconf-show /usr/bin/dh_makeshlibs /usr/bin/dh_shlibdeps /usr/bin/dpkg-shlibdeps /usr/bin/gettext.sh /usr/bin/instmodsh /usr/bin/sha1sum /usr/bin/sha224sum /usr/bin/sha256sum /usr/bin/sha384sum /usr/bin/sha512sum /usr/bin/shasum /usr/bin/shred /usr/bin/shuf /usr/bin/unshare /sbin/shadowconfig /sbin/shutdown /bin/bash /bin/dash /bin/rbash /bin/sh /bin/sh.distrib [16419] PAUSED... Hit return! make[1]: *** [make_the_test] Error 1 make[1]: Leaving directory `/tmp/buildd/shc-3.8.7' dh_auto_test: make -j1 test returned exit code 2 make: *** [build] Error 29 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Additionally, you may want to look into the issues reported there: http://mentors.debian.net/package/shc (Run 'lintian -IE --pedantic *.changes' to check for these issues locally.) -- 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/20120307171515.gd28...@marvin.lan
Bug#662968: RFS: shc/3.8.7-1
Vibhav Pant wrote: > I am looking for a sponsor for my package "shc" > > * Package name: shc >Version : 3.8.7-1 >Upstream Author : Francisco Rosales > * URL : http://www.datsi.fi.upm.es/~frosal/sources/ > [there is no such homepage for this program] > * License : GPL-2 >Section : devel > > It builds those binary packages: > > shc - Generic shell script compiler. That short description is so misleading! shc is no compiler at all, but merely an obfuscator; from the man page: shc itself is not a compiler such as cc, it rather encodes and encrypts a shell script and generates C source code with the added expiration capability. [...] shc's main purpose is to protect your shell scripts from modification or inspection. You can use it if you wish to distribute your scripts but don't want them to be easily readable by other people. I find this purpose pointless and evil, and I don't think such software should be in Debian. If it's going to be accepted anyway, at least give it a proper description. 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/20120307173819.ge28...@marvin.lan
Re: qemubuilder - are there precompiled kernel-images with ipv6 and ext3 support built-in
Hi Björn, Björn Esser wrote: > Are there any precompiled kernels for qemubuilder which have built-in > support for ipv6 and ext3 (and probably other nifty stuff) available? > > Even better would be precompiled kernels which use the same > configuration as the debian buildd-network. > > I did some research on the w³ and found nothing but out-dated stuff or > kernels without support for these built-in. Even the kernel images > provided by aurel32 [1] were not really suitable or didn't work at all. > > Or do I really have to compile the kernel-images myself? Can't you just grab and unpack one of the prebuilt debian kernels from the archive? qemubuilder can load an initrd image, so even if ipv6 and ext3 are not built-in, it should work just fine. > I need the images for testing package build on other than x86 / amd64 > arches. If you don't have other architectures available, you could just have your package uploaded and see if it fails to build. If it does, you'll have access to the full log, and then you can ask on one of the dedicated mailing lists; I'm sure there are developers with access to those machines who'd be happy to help. 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/20120314230717.ga14...@marvin.lan
Re: qemubuilder - are there precompiled kernel-images with ipv6 and ext3 support built-in
Björn Esser wrote: > Am 15.03.2012 00:07, schrieb Benoît Knecht: > > Can't you just grab and unpack one of the prebuilt debian kernels > > from the archive? qemubuilder can load an initrd image, so even if > > ipv6 and ext3 are not built-in, it should work just fine. > > The prebuild kernels don't ship any initrd and I'm not sure how to build > a suitable one on a different arch. Maybe there's some guide avail. for > this. Well, that might not be the fastest way, but the following works just fine to generate the initrd; all you need is debootstrap, binfmt-support and qemu-user-static installed (I will assume you want and armel kernel/initrd in this example, but the same should apply for other architectures): debootstrap --arch=armel --foreign --variant=minbase sid rootfs-armel-sid cp /usr/bin/qemu-arm-static rootfs-armel-sid/usr/bin/ chroot rootfs-armel-sid/ debootstrap/debootstrap --second-stage echo "deb ftp://ftp.debian.org/debian/ sid main" >> etc/apt/sources.list apt-get update (You may want to mount /dev, /dev/pts /proc and /sys at this point.) apt-get install linux-image-versatile (And umount anything you mounted here.) exit You should now have and initrd image in rootfs-armel-sid/boot/. > > If you don't have other architectures available, you could just have > > your package uploaded and see if it fails to build. > > I'm no dd so where can I upload and try to build it, but > mentors.debian.net and wait until someone ITS it? Yes, that's what I meant: have someone upload it for you, and then see if anything fails. I don't think it's worth the trouble setting up qemu images for every architecture supported by debian until you know there's a problem, and have an idea of its nature. It might not even be able to do anything about it if the problem is uninstallable dependencies. > > If it does, you'll have access to the full log, and then you can ask > > on one of the dedicated mailing lists; I'm sure there are developers > > with access to those machines who'd be happy to help. > > Where / How to get in touch with those developers? For armel, . I'm sure the other architectures have similar mailing lists. 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/20120316113125.ga6...@marvin.lan
Bug#670851: RFS: plotter/2.2-1[ITP]
Hi Ralf, Ralf Jung wrote: > I am looking for a sponsor for my package "plotter" > > Package name: plotter > Version : 2.2-1 > Upstream Author : Ralf Jung > URL : http://mathespiele.ralfj.de/programm.php?id=25 > License : GPLv2 > Section : math > > It builds those binary packages: > > plotter- Simple Qt-based mathematical function plotter > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/plotter > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/p/plotter/plotter_2.2-1.dsc I took a look at your package; here are a few comments: - In debian/copyright, you have a license paragraph called "GPL-2" that states: "either version 2 of the License, or (at your option) any later version"; so either this paragraph should be called "GPL-2+", or you should correct the text of the license. From the license headers in the source, it seems to be the latter; that's a problem because part of the files in the package are licensed under the GPL-3 or LGPL-3, which are incompatible with the GPL-2 [1]. Please sort it out. [1] http://www.gnu.org/licenses/license-list.html#GNUGPL For the tri-licensed files, see [2] for the correct syntax. [2] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph - The man page is quite short and essentially repeats the long description of the package (which presumably the user has already read before installing the package). It would be more useful to take elements from manual.html and manual_graph.html. Also, please consider removing the AUTHOR section (see man-pages(7)). - You install the German changelog as /usr/share/doc/plotter/changelog.gz, where most users would expect to find an English version; would you consider providing a translation? - In debian/rules, you could avoid overriding dh_install by using a debian/plotter.install file; see dh_install(1). Same for dh_auto_clean, see dh_clean(1). - Your long description should mention how plotter compares to similar programs, such as qtiplot or gnuplot [3]. [3] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc - Please run "wrap-and-sort -as" (or simply "wrap-and-sort" if you prefer) in the root of your package. 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/20120509141917.gb11...@marvin.lan
Bug#670448: RFS: bibtexconv/0.8.16-3 [ITP]
Hi Thomas, Thomas Dreibholz wrote: > I am looking for a sponsor for my package "bibtexconv". BibTeXConv is a > BibTeX > file converter which allows one to export BibTeX entries to other formats, > including customly defined text output. Furthermore, it provides the > possibility to check URLs (including MD5, size and MIME type computations) > and to verify ISBN and ISSN numbers. Examples are provided on the BibTeXConv > website at http://www.iem.uni-due.de/~dreibh/bibtexconv/index.html . > > * Package name: bibtexconv >Version : 0.8.16-3 >Upstream Author : Thomas Dreibholz > * URL : http://www.iem.uni-due.de/~dreibh/bibtexconv/index.html > * License : GPL, version 3 >Section : tex > > It builds those binary packages: > > bibtexconv - BibTeX Converter > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/bibtexconv > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/b/bibtexconv/bibtexconv_0.8.16-3.dsc I took a look at your package: - Build fails in a clean chroot with g++-4.7: [...] dh_auto_build make[1]: Entering directory `/tmp/buildd/bibtexconv-0.8.16' make all-recursive make[2]: Entering directory `/tmp/buildd/bibtexconv-0.8.16' Making all in src make[3]: Entering directory `/tmp/buildd/bibtexconv-0.8.16/src' g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall -DUSE_UTF8 -c -o bibtexconv.o bibtexconv.cc bibtexconv.cc: In function 'unsigned int checkAllURLs(PublicationSet*, const char*, bool)': bibtexconv.cc:254:60: error: 'unlink' was not declared in this scope bibtexconv.cc:285:42: error: 'unlink' was not declared in this scope bibtexconv.cc:287:35: error: 'unlink' was not declared in this scope make[3]: *** [bibtexconv.o] Error 1 make[3]: Leaving directory `/tmp/buildd/bibtexconv-0.8.16/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/bibtexconv-0.8.16' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/bibtexconv-0.8.16' dh_auto_build: make -j1 returned exit code 2 make: *** [build] Error 2 - In debian/copyright, the Format URL is wrong [1]. Although not required, it wouldn't be a bad idea adding an Upstream-Contact field. [1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ ltmain.sh should have its own Files paragraph. - Since you only have one entry in the changelog, version number should be 0.8.16-1. - You may want to use debhelper compat 9. - It looks like src/bibtexconv-odt doesn't use any bashisms, so you could use /bin/sh. That script will fail if $BIBTEX_FILE or $EXPORT_SCRIPT contain spaces though. You would also get a more readable script (and less error-prone) by using "set -e" [2]; for example, you're not checking the exit status of mktemp. [2] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts - bibtexconv(1) states that "the following arguments have to be provided"; it seems unlikely that all of the options are mandatory, so this needs to be clarified. In the synopsis, the usual convention is to put only optional arguments between brackets (the usage line of src/bibtexconv-odt should follow that convention too). Some of the commands are not documented. The examples get wrapped in narrow terminals, in a way that make them invalid shell commands; it would be better to manually wrap them and have continuation lines end with '\'. Do not use a pair of '*' for emphasis (e.g. "*not*"), there are macros for that, such as ".I". Please consider getting rid of the AUTHOR section (see man-pages(7)). The same comments apply to bibtexconv-odt(1). 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/20120509155010.gc11...@marvin.lan
Bug#670851: RFS: plotter/2.2-1[ITP]
Ralf Jung wrote: > > I took a look at your package; here are a few comments: > Thanks a lot for your detailed review! You're welcome! > > - In debian/copyright, you have a license paragraph called "GPL-2" > > that states: "either version 2 of the License, or (at your option) > > any later version"; so either this paragraph should be called > > "GPL-2+", or you should correct the text of the license. From the > > license headers in the source, it seems to be the latter; that's a > > problem because part of the files in the package are licensed under > > the GPL-3 or LGPL-3, which are incompatible with the GPL-2 [1]. > > Please sort it out. > > > > [1] http://www.gnu.org/licenses/license-list.html#GNUGPL > The source files are GPL-2 without "or later", I just copied the wrong > license > header into the copyright file. Then you need to replace the (L)GPL-3 files with some GPLv2-compatible equivalent. > > For the tri-licensed files, see [2] for the correct syntax. > > > > [2] > > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-al > > one-license-paragraph > > > > - The man page is quite short and essentially repeats the long > > description of the package (which presumably the user has already > > read before installing the package). It would be more useful to take > > elements from manual.html and manual_graph.html. Also, please > > consider removing the AUTHOR section (see man-pages(7)). > I did not know that the AUTHOR section is discouraged, sorry - maybe it > should > be removed from the example in > /usr/share/debhelper/dh_make/debian/manpage.1.ex > which is where I got it from (this is the first manpage I wrote). > Is it appropriate to report a bug against dh-make? Sure, reporting it wouldn't be a bad idea. > > - You install the German changelog as > > /usr/share/doc/plotter/changelog.gz, where most users would expect > > to find an English version; would you consider providing a > > translation? > Done. > > > > > - In debian/rules, you could avoid overriding dh_install by using a > > debian/plotter.install file; see dh_install(1). Same for > > dh_auto_clean, see dh_clean(1). > Done for clean. However, in dh_install, I also convert the upstream png icon > to xpm, which is necessary for the entry in menu to work with an icon. > Should I do this in another rule instead? Well, I think it would make sense to do it after dh_auto_build, but it's fine if you want to keep the dh_install override as-is. > > - Your long description should mention how plotter compares to similar > > programs, such as qtiplot or gnuplot [3]. > > > > [3] > > http://www.debian.org/doc/manuals/developers-reference/best-pkging-practic > > es.html#bpp-pkg-desc > > > > - Please run "wrap-and-sort -as" (or simply "wrap-and-sort" if you > > prefer) in the root of your package. > Done. > > When I re-upload the package with the remaining fixes, should I keep the > current version number or should I increase it to 2.2-2 and mention the > fixes > in the changelog? I suppose the latter is right, but I was told to clear the > changelog before the initial upload to mentors, so I figured I'd better ask. >From what I gather, most sponsors prefer the debian version _not_ to be incremented, so that the first upload has only one changelog entry. 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/1e95ee7d-7d97-4a92-a616-d04520912fda@uuid
Bug#672237: RFS: vim-vimerl/1.4.1+git20120509.89111c7-1 [ITP]
Hi Per,
Per Andersson wrote:
> I am looking for a sponsor for my package "vim-vimerl"
>
> * Package name: vim-vimerl
> Version : 1.4+git20120210.89111c7-1
>Upstream Author : Ricardo Catalinas Jiménez
> * URL : http://github.com/jimenezrick/vimerl
> * License : Vim License
> Section : editors
>
> It builds those binary packages:
>
> vim-vimerl - Erlang plugin for Vim
> vim-vimerl-syntax - Erlang syntax for Vim
>
> To access further information about this package, please visit the
> following URL:
>
> http://mentors.debian.net/package/vim-vimerl
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/v/vim-vimerl/vim-vimerl_1.4+git20120210.4c4d1f0-2.dsc
I took a look at your package:
- lintian reports the following:
P: vim-vimerl source: unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5
W: vim-vimerl source: syntax-error-in-dep5-copyright line 27:
Continuation line outside a paragraph.
P: vim-vimerl-syntax: no-upstream-changelog
P: vim-vimerl: no-upstream-changelog
- In debian/control, ${shlibs:Depends} is not defined, just remove it.
- I don't think the upstream README contains any useful information
for debian users (features are in the long description, installation
instructions are irrelevant, and bugs should normally be reported in
debian's BTS), don't install it.
- You should remove the template comments in debian/rules.
- According to uscan, there's a more recent upstream version (1.4.1).
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/1e5d6904-cb65-4b1b-9330-b1bc471ee074@uuid
Re: Is there anyway to prettify long *-Depends: lines?
Paul Elliott wrote: > I have a really long Build-Depends: line. > > Multiple Build-Depends: lines is an error. > > '\' at end of physical lines to put logical lines on multiple physical lines > does not work and is apparently not allowed. > > Most editors and display programs do not display long lines well in a fashion > that is easy to read. > > Is there anyway to prettify these lines? Try wrap-and-sort from the devscripts package. -- 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/3b243583-e1dc-4075-ba86-b8f9bb74aed7@uuid
Bug#670448: RFS: bibtexconv/0.8.16-3 [ITP]
Thomas Dreibholz wrote: > I have created an updated version here (version 0.8.19-1): > http://mentors.debian.net/package/bibtexconv . > > > > I took a look at your package: > > > > - Build fails in a clean chroot with g++-4.7: > > > > [...] > > dh_auto_build > > make[1]: Entering directory `/tmp/buildd/bibtexconv-0.8.16' > > make all-recursive > > make[2]: Entering directory `/tmp/buildd/bibtexconv-0.8.16' > > Making all in src > > make[3]: Entering directory `/tmp/buildd/bibtexconv-0.8.16/src' > > g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall -DUSE_UTF8 -c -o > > bibtexconv.o bibtexconv.cc bibtexconv.cc: In function 'unsigned int > > checkAllURLs(PublicationSet*, const char*, bool)': bibtexconv.cc:254:60: > > error: 'unlink' was not declared in this scope bibtexconv.cc:285:42: error: > > 'unlink' was not declared in this scope bibtexconv.cc:287:35: error: > > 'unlink' was not declared in this scope make[3]: *** [bibtexconv.o] Error 1 > > make[3]: Leaving directory `/tmp/buildd/bibtexconv-0.8.16/src' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/tmp/buildd/bibtexconv-0.8.16' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory `/tmp/buildd/bibtexconv-0.8.16' > > dh_auto_build: make -j1 returned exit code 2 > > make: *** [build] Error 2 > > Fixed. Indeed, builds fine for me now. > > - In debian/copyright, the Format URL is wrong [1]. Although not > > required, it wouldn't be a bad idea adding an Upstream-Contact > > field. > > > > [1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > > Added. > > > > ltmain.sh should have its own Files paragraph. What about that^^^? You also need to mention the OpenSSL exception (there's an example in the "License specification->Syntax" section of [1]. [1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ And it's not clear whether GPL-3 or GPL-3+ applies; the synopsis says GPL-3, but the license text indicates GPL-3+. > > > > - Since you only have one entry in the changelog, version number > > should be 0.8.16-1. > > Fixed. > > > > - You may want to use debhelper compat 9. > > Done. You should specify the versioned dependency as ">= 9" instead of ">= 9.0". > > - It looks like src/bibtexconv-odt doesn't use any bashisms, so you > > could use /bin/sh. > > Changed. > > > > That script will fail if $BIBTEX_FILE or $EXPORT_SCRIPT contain > > spaces though. > > Fixed. It now also processed files with spaces in their names. > > > > You would also get a more readable script (and less error-prone) by > > using "set -e" [2]; for example, you're not checking the exit status > > of mktemp. > > Done. Good, but now it means you should change the "&&" construct. The script will exit if any command fails, so you don't need the long "&&" chain; instead, you should make sure that any command that is allowed to fail is followed by "|| true" or something similar. > > [2] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts > > > > - bibtexconv(1) states that "the following arguments have to be > > provided"; it seems unlikely that all of the options are mandatory, > > so this needs to be clarified. In the synopsis, the usual convention > > is to put only optional arguments between brackets (the usage line > > of src/bibtexconv-odt should follow that convention too). > > Changed. You didn't change the usage line in src/bibtexconv-odt. And in bibtexconv(1), I assume that the bibtex file is a mandatory argument, so it shouldn't be between brackets in the synopsis line. > > Some of the commands are not documented. > > > > The examples get wrapped in narrow terminals, in a way that make > > them invalid shell commands; it would be better to manually wrap > > them and have continuation lines end with '\'. > > Strangely, in the first occurrence of "\\" after .It, man converts "\" to "|" > (i.e. the pipe symbol). I did not find a way to turn this wrong behaviour > off, > therefore I did not add manual wrapping. "\e" will give you a backslash. > > Do not use a pair of '*' for emphasis (e.g. "*not*"), there are > > macros for that, such as ".I". > > Fixed. > > > > Please consider getting rid of the AUTHOR section (see > > man-pages(7)). > > Removed. That's great, thanks. 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/be0a335f-3ac1-4446-8201-7f282cf46c4d@uuid
Re: RFS: ncmpcpp (updated package)
Hi Damien, Damien Leone wrote: > I am looking for a sponsor for the new version 0.5.10 of my package > "ncmpcpp" [0] (currently uploaded version is 0.5.6). > > It builds this binary package: > ncmpcpp - ncurses-based client for the Music Player Daemon (MPD) > > The package appears to be lintian clean. > > The upload would fix bugs 661858, 667294 and 611467 > The package can be found here: > - URL: http://debian.fensalir.fr/ncmpcpp/ > - dget http://debian.fensalir.fr/ncmpcpp/ncmpcpp_0.5.10-1.dsc > > I also would like to apologize for taking so long to update this package. Since I'm the one who was pressing you for a new release, I feel I owe you at least a review, so here it goes: - In debian/changelog, you mention updating the standards version, but not the changes required; if there wasn't any, you should mention that in the changelog. Also, the paths to the last two patches are wrong (missing the "patches" directory). You could also have sub-items for the "New upstream release" entry, detailing which bugs are fixed (right now, it looks like the three bugs are duplicates, and one doesn't know what they correspond to). - Have you forwarded the patches upstream? - It would be great if you could use hardening flags [1], as it's a release goal for wheezy [2]; given the fact that ncmpcpp handles network data, it seems like a prime candidate. [1] http://wiki.debian.org/Hardening [2] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags Using generic debhelper compat 9 would enable hardening flags automatically. - In the man page ncmpcpp(1), CONFIGURATION appears to Using generic debhelper compat 9 would enable hardening flags automatically. - In the man page ncmpcpp(1), CONFIGURATION appears to be a subsection of OPTIONS, which is probably a mistake. - Please consider using the DEP-5 format [3] for debian/copyright. [3] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Thanks for your work on this new package. 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/0831a576-c933-4809-9378-0f5b0161f37b@uuid
Bug#677239: RFS: fractalnow [ITP #673395] -- Fast, advanced fractal generator
tag 677239 moreinfo thanks Hi Marc, Marc Pegon wrote: > I am looking for someone to sponsor my first package "fractalnow". > > * Package name: fractalnow > Version : 0.8.0 > Upstream Author : Marc Pegon > * URL : http://fractalnow.sourceforge.net > * License : LGPL > Programming Lang: C, C++ > Description : Fast, advanced fractal generator > > FractalNow is a fractal generator quite similar to fraqtive (which is in > Debian), but faster and with more options (more formulas, several > coloring > methods, cool stuff like arbitrary float precision, and more!). > Take a look at my nice fractal gallery: > http://fractalnow.sourceforge.net/gallery.html > And some screenshots: > http://fractalnow.sourceforge.net/screenshots.html > > It builds one binary package: > fractalnow -- Fast, advanced fractal generator > > All files required for building package are on sourceforge: > > http://sourceforge.net/projects/fractalnow/files/FractalNow/0.8.0/sources/packaging/debian/ Please provide a direct link to the .dsc file, so that it can be easily downloaded with dget. The best way to do this is uploading your package to mentors [1], following these instructions [2]. [1] http://mentors.debian.net [2] http://mentors.debian.net/intro-maintainers 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/20120625140229.ga27...@marvin.lan
Bug#677935: RFS: cwm/5.1-1 [ITP] -- Lightweight and efficient window manager for X11
Hi James, James McDonald wrote: > I am looking for a sponsor for my package "cwm" > > * Package name: cwm > Version : 5.1-1 > Upstream Author : Christian Neukirchen > * URL : https://github.com/chneukirchen/cwm > * License : ISC > Section : x11 > > It builds those binary packages: > > cwm - Lightweight and efficient window manager for X11 I took a look at your package, here are a few comments: - lintian reports the following warnings: P: cwm source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 I: cwm source: debian-watch-file-is-missing P: cwm: no-upstream-changelog P: cwm: no-homepage-field I: cwm: hyphen-used-as-minus-sign usr/share/man/man5/cwmrc.5.gz:231 I: cwm: hyphen-used-as-minus-sign usr/share/man/man5/cwmrc.5.gz:245 - In debian/copyright, fgetln.c is licensed under the BSD-2-clause license; and instead of repeating the ISC twice, you could factor it out in its own standalone paragraph. Also, the Source header should not point to one particular version. Use the directory where all the tarballs are stored; but if you got it from github, use that URL instead. - In debian/control, why do you depend on dpkg-dev? The package seems to build just fine without it. You should also run wrap-and-sort from devscripts to get the Build-Depends field wrapped and sorted. And if you don't use a VCS for your packaging, you should remove those commented-out lines. Your long description repeats information provided by the short description; see [1] for best practices. It could also be expanded a bit. [1] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc - You could use debhelper compat 9, that should take care of the hardening flags for you. And in debian/rules, you should remove the template comments. - The README doesn't contain useful information for end-users, so you shouldn't install it. 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/20120625150550.gb27...@marvin.lan
Bug#677935: RFS: cwm/5.1-1 [ITP] -- Lightweight and efficient window manager for X11
James McDonald wrote: > On Mon, Jun 25, 2012 at 05:05:50PM +0200, Benoît Knecht wrote: > > I took a look at your package, here are a few comments: > > Thanks for your detailed review! Your remarks are very helpful. You're welcome! I'm glad I could help. > [...] > > > Your long description repeats information provided by the short > > description; see [1] for best practices. It could also be expanded a > > bit. > > I had in fact just repeated the summary from the manpage. I have read the > reference and a few examples and tried to make it more useful. What do you > think? Much better in my opinion. I would remove the last sentence of the first paragraph though (about the code that used to come from 9wm), as it doesn't seem very relevant anymore. The package looks pretty good to me now, so I hope you'll find a sponsor soon. But prehaps you should consider Depending on xserver-xorg (or at least Recommend it, if that makes more sense). You could also Suggest xinit, as it seems like a nice way to start such a minimalistic window manager. And here are a couple more nitpickings, if you feel like fixing those: - In debian/control, the debhelper version dependency should simply be ">= 9" instead of ">= 9.0.0". - And in the same file, the long description contains a few double-spaces. 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/20120626140823.ga6...@marvin.lan
Bug#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
severity 678992 wishlist thanks Hi José, José Luis Segura Lucas wrote: > I am looking for a sponsor for my package "grive" > > * Package name: grive > Version : 0.1.1+20120619git27g55c0f4e-1 > Upstream Author : Matchman Green and Nestal Wan > > * URL : http://www.lbreda.com/grive > * License : GPLv2 >Section : net > > It builds those binary packages: > > grive - Google Drive client for GNU/Linux I took a look at your package: - Since you're packaging a snapshot version, you should adjust your watch file accordingly: Processing watchfile line for package grive... Newest version on remote site is 0.1.1, local version is 0.1.1+20120619git27g55c0f4e grive: remote site does not even have current version - It seems like all the source files of Grive are released under the GPL-2, and not GPL-2+ (according to the license headers in those files). You should correct that in debian/copyright, and using the same formulation as in the license headers seems like a good idea. The license for the debian/* files is said to be GPL-2+, but in the license paragraph it refers to the GPL-3. I couldn't find Matchman Green's name in any of the source files; are you sure they're one of the copyright holders? - debian/README.Debian should be debian/README.source, although I would argue it doesn't contain any useful information at the moment. - In debian/control, the Vcs-Git field is intended for the packaging, not the upstream repository; if you don't have a public git repository for the Debian packaging, remove that line. The long description could be improved; please have a look at [1]. [1] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc Please run wrap-and-sort from the devscripts package to have the Build-Depends field wrapped and sorted (and use ">= 9" for debhelper). - Why do you override the hardening-no-fortify-functions lintian warning? If you have a good reason to do so, you should explain it in a comment in debian/grive.lintian-overrides. - Grive includes a test suite, but it isn't built nor run. - In the grive(1) man page, you should end each item in the DESCRIPTION with punctuation. Mentioning that Grive is "for GNU/Linux systems" doesn't seem very useful; the person reading the man page is most likely doing so from such a system already. Grive shouldn't be italicized (.I) in the DESCRIPTION. Please consider removing the AUTHOR section (see man-pages(7) for details). Also, the REPORT BUGS section should be called BUGS, but I think it should be removed too, as Debian users should use the Debian BTS anyway. 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/20120626153625.gc6...@marvin.lan
Bug#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
José Luis Segura Lucas wrote: > El 26/06/12 17:36, Benoît Knecht wrote: > > I took a look at your package: > First of all, thanks for your quick answer :-) You're welcome :) > > - Since you're packaging a snapshot version, you should adjust your > > watch file accordingly: > > > > Processing watchfile line for package grive... > > Newest version on remote site is 0.1.1, local version is > > 0.1.1+20120619git27g55c0f4e > > grive: remote site does not even have current version > The upstream authors doesn't have this version available as tarball for > download, I had to create the tarball myself. The main differences > between the 0.1.1 stable version and this git commit is only about the > construct system: I have made some suggestions and they included it in > the repository after the 0.1.1 release. I don't know how to write a > watch file for downloading a specific commit from a git repository. Is > it possible? I just meant that you should use something like opts=dversionmangle (see uscan(1)) so that uscan would remove the "+20120619git27g55c0f4e" part before comparing the debian version with the upstream one. But if you're not going to package snapshot versions on a regular basis, maybe that's not necessary. > > - It seems like all the source files of Grive are released under the > > GPL-2, and not GPL-2+ (according to the license headers in those > > files). You should correct that in debian/copyright, and using the > > same formulation as in the license headers seems like a good idea. > > > > The license for the debian/* files is said to be GPL-2+, but in the > > license paragraph it refers to the GPL-3. > > > > I couldn't find Matchman Green's name in any of the source files; > > are you sure they're one of the copyright holders? > Corrected the license issues (upstream to GPL-2, debian/* to GPL-3). > Matchman Green was the original upstream author when I began to follow > this project, but my e-mails and "real" contact with the project was > made through the other author: Nestal Wan. I will contact upstream again > and ask about this. Yeah, it seems best to discuss it with upstream. Regarding the GPL-3 for the packaging, since it's incompatible with the GPL-2, it would be much better if you agreed to GPL-2+ for debian/*; that way, the source package as a whole can be considered GPL-2. > > - debian/README.Debian should be debian/README.source, although I > > would argue it doesn't contain any useful information at the moment. > You are right: it doesn't contain any useful information. I think it is > a "legacy" file from the templates that I have written at the beginning > of the times :-) > > - In debian/control, the Vcs-Git field is intended for the packaging, > > not the upstream repository; if you don't have a public git > > repository for the Debian packaging, remove that line. > Ok, I have it on github, modified. > > The long description could be improved; please have a look at [1]. > > > > [1] > > http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc > > > > Please run wrap-and-sort from the devscripts package to have the > > Build-Depends field wrapped and sorted (and use ">= 9" for > > debhelper). > Do you mean ">=9" instead ">=9.0.0"? If it is, modified in that way. That's what I meant, yes. > > - Why do you override the hardening-no-fortify-functions lintian > > warning? If you have a good reason to do so, you should explain it > > in a comment in debian/grive.lintian-overrides. > I asked in debian-devel and in hardening-wrapper mailing lists about > that. I had this warning and, after checking with hardeining-check I saw > a possible problematic "read" unsafe call. I find it on the upstream > sources and see that it is safe to link against read instead read_chk, > because the always read the "sizeof" the reserved buffer. I will add a > comment about that. Perfect. > > - Grive includes a test suite, but it isn't built nor run. > I used their CMakeLists.txt without any patch or hack. I will ask them > about it and study the viability of adding to the Debian package > generation script and the way to do so. >From a quick look at the CMakeLists.txt, it seems that cppunit needs to be installed in order for the test suite to be built (so I guess you should Build-Depend on libcppunit-dev). Not sure if it means a simple "make test" would run the test suite then; looks like you&#
Bug#673087: RFS: the-powder-toy/78.1-1 [ITP] -- Physics sandbox game
Hi Aditya, Aditya Vaidya wrote: > I am looking for a sponsor for my package "the-powder-toy" > * Package name: the-powder-toy > Version : 78.1-1 > Upstream Author : HardWIRED and respective owners > * URL : http://powdertoy.co.uk/ > > > * License : GPL-3 > Section : games > > It builds those binary packages: > > the-powder-toy - Physics sandbox game > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/the-powder-toy I wanted to review your package, so I tried building it from the git repository mentioned in debian/control [1] using git checkout upstream git checkout pristine-tar git checkout master git-buildpackage --git-pristine-tar --git-pbuilder but it failed with fatal: Path 'the-powder-toy_81.0.orig.tar.bz2.delta' does not exist in 'refs/heads/pristine-tar' pristine-tar: git show refs/heads/pristine-tar:the-powder-toy_81.0.orig.tar.bz2.delta failed gbp:error: Couldn't checkout "the-powder-toy_81.0.orig.tar.bz2": /usr/bin/pristine-tar returned 128 [1] git://github.com/kroq-gar78/The-Powder-Toy_deb.git It also looks like this repository was intended for the ubuntu package, so it probably shouldn't be mentioned in the debian/control file of the debian package. The version you linked to in this request [2] compiles and runs fine, but lintian reports a bunch of issues: W: the-powder-toy source: unknown-field-in-dsc original-maintainer I: the-powder-toy source: debian-watch-file-is-missing I: the-powder-toy: spelling-error-in-binary usr/lib/games/the-powder-toy/powder targetted targeted W: the-powder-toy: hardening-no-fortify-functions usr/lib/games/the-powder-toy/powder W: the-powder-toy: hardening-no-relro usr/lib/games/the-powder-toy/powder P: the-powder-toy: no-upstream-changelog I: the-powder-toy: unknown-field-in-control original-maintainer E: the-powder-toy: menu-icon-not-in-xpm-format usr/share/pixmaps/powdertoy-48.png P: the-powder-toy: maintainer-script-without-set-e postrm P: the-powder-toy: maintainer-script-without-set-e postinst [2] http://mentors.debian.net/debian/pool/main/t/the-powder-toy/the-powder-toy_78.1-1.dsc Since you've obviously kept working on the package, I thought I'd ask you if you wanted to submit a more current version before I go into a deeper review. 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/20120627143724.gb21...@marvin.lan
Bug#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
José Luis Segura Lucas wrote: > El 27/06/12 12:48, Benoît Knecht escribió: > > I just meant that you should use something like opts=dversionmangle (see > > uscan(1)) so that uscan would remove the "+20120619git27g55c0f4e" part > > before comparing the debian version with the upstream one. But if you're > > not going to package snapshot versions on a regular basis, maybe that's > > not necessary. > > Ok, I will take a look again that option of the watch file, I have never > seen before. I'll read carefully uscan man. Actually, Boris' suggestion (cherry-picking the changes you need and including them as patches) is even better, you should consider doing that and dropping the "+20120619git27g55c0f4e" entirely. > > Yeah, it seems best to discuss it with upstream. Regarding the GPL-3 for > > the packaging, since it's incompatible with the GPL-2, it would be much > > better if you agreed to GPL-2+ for debian/*; that way, the source > > package as a whole can be considered GPL-2. > I don't know if there is a reason behind their choice of GPL-2 instead > GPL-3... but I can ask them. If they prefer keeping on GPL-2, I can > accept GPL-2+ for debian/* if it simplifies the licensing issues of the > whole package. Well, I don't think you should ask upstream to change their license to GPL-3; my point was that, as a packager, it is good practice to choose a license that is compatible with upstream's (i.e. equally or more permissive). 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/20120628071229.ga28...@marvin.lan
Bug#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
José Luis Segura Lucas wrote: > El 28/06/12 09:16, José Luis Segura Lucas escribió: > > I have only a questions before uploading the package again to > > mentors.debian.net: which rule I must override on debian/rules to > > execute the unit tests? > > > > Best regards > I can answer myself: overriding the rule dh_auto_test. > > > I had worked into the package today: I use again the stable 0.1.1 > release (no need to use git version on the version upstream number). I > add all the diffs between 0.1.1 and the git version I was using as quilt > patches (more than 2000 lines). The idea was to pick only the specific diffs that solved issues, rather that including all the changes up to that git revision. > I have uploaded to mentors.debian.net again, but deleting the previous > one first, because the upstream version number now is lesser than the > previous one. > > P.S. After uploading to mentors.debian.net I have seen a lintian > informational warning (missing headers on the quilt patches). I describe > it in a few words, but after a "debuild -S -sd" I tried "dput mentors > file.changes" and it doesn't allow me to upload because the package is > already uploaded... > > How can I submit this change to the deb expo? I guess you need to use the -f (--force) option of dput. Alternatively, you can delete the *.upload file. 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/20120628214733.ga21...@marvin.lan
Bug#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
José Luis Segura Lucas wrote: > Forget about all the patches mess. Upstream has released 0.2.0 version, > which makes unnecessary to apply all those patches. > > I just uploaded it to mentors.debian.net [1]. Please, feel free to > comment here or in the grive's page on mentors.debian.net any issue > related to the packaging. > > Benoît, are you interested on sponsor this package? I'm sorry, I can't, I'm not a debian developper; I thought my email address would have made that clear, sorry for giving you the wrong impression. > Thanks in advance and best regards. > > [1] http://mentors.debian.net/package/grive > > -- > José Luis Segura Lucas > > -- 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/20120709142836.gb28...@knecht-b-wifi1.tphys.uni-heidelberg.de
Bug#682781: RFS: minidlna/1.0.25+dfsg-1 -- lightweight DLNA/UPnP-AV server targeted at embedded systems
Package: sponsorship-requests Severity: normal User: sponsorship-reque...@packages.debian.org Usertags: not-for-wheezy, not-fit-for-wheezy Dear mentors, I am looking for a sponsor for my package "minidlna" * Package name: minidlna Version : 1.0.25+dfsg-1 Upstream Author : Justin Maggard * URL : http://sourceforge.net/projects/minidlna/ * License : GPL-2 Section : net It builds those binary packages: minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems As it is not intended for wheezy, I'm targeting experimental. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/minidlna Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.25+dfsg-1.dsc Changes since the last upload: * New upstream version - Fix a couple crash bugs on malformed WAV files - Forcibly tweak the model number for Xbox360 clients, or they might ignore us - Enable all network interfaces by default if none were specified - Add flag to force downscaled thumbnails rather than using embedded ones - Add DirecTV client detection, and fix image resolution issue - Add support for the latest ffmpeg/libav library versions - Fix a potential crash on requests for a resize of a non-existent image - Make DeviceID checking more permissive for Sagem Radio * Update the documentation with new options and various corrections in the following places: - minidlna(1) man page; - minidlna.conf(5) man page; - output of "minidlna -h"; - default configuration file. * Display the user minidlna is running as in the default friendly name * Adapt "Get IP and MAC addresses in a non Linux-specific way" patch to upstream changes * Fix Makefile so that hardening flags are actually passed to the compiler * preinst: Make sure that the home directory exists and is owned by the correct user:group * postrm: Do not remove the minidlna user and group on purge * postrm: During purge, only remove the $HOME directory if it's /var/lib/minidlna; we don't want to mess with home directories if the admin changed the default * postrm: Do not remove the configuration file in the purge case, it has already been removed by dpkg before the script is called * Update period of copyright for debian/* * Replace `...` with $(...) in all maintainer scripts * Do not include scripts specific to the git repository in the debian/ directory in the source package 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/20120725155524.ga31...@marvin.lan
Bug#682781: RFS: minidlna
Hi Bart,
Thanks a lot for your prompt reply.
Bart Martens wrote:
> minidlna-1.0.25+dfsg/debian/copyright :
>
> | Source: http://sourceforge.net/projects/minidlna/files/
> | The icons.c file in the original tarball contained binary blobs of
> possibly
> | unfree images. It has hence been replaced in the DFSG tarball by a file
> | containing the free Debian logo instead. It can be generated from the
> SVG logo
> | using the debian/make_icons.sh script (see the header of that file for
> | instructions).
>
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
>
> | A repackaged .orig.tar.{gz,bz2,xz} should not contain any file that does
> not
> | come from the upstream author(s), or whose contents has been changed by
> you.
>
> So removing files is OK, adding/replacing files not.
You're right, except that in this case, the source would fail to build
if I simply removed icons.c, so I think it falls under the exception
laid out in the footnote [1]:
| As a special exception, if the omission of non-free files would lead
| to the source failing to build without assistance from the Debian
| diff, it might be appropriate to instead edit the files, omitting only
| the non-free parts of them, and/or explain the situation in a
| README.source file in the root of the source tree. But in that case
| please also urge the upstream author to make the non-free components
| easier separable from the rest of the source.
[1]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#ftn.idp20146152
I haven't contacted upstream about it though, but I will do so shortly.
But I now realize, reading the page you pointed to, that the top-level
directory in my orig.tar is improperly named; right now, it's called
minidlna-1.0.25+dfsg, and it should be minidlna-1.0.25+dfsg.orig (or is
it minidlna-1.0.25.orig?). I wonder however, if the goal is to "make it
possible to distinguish pristine tarballs from repackaged ones", if
minidlna-1.0.25+dfsg doesn't make that clear enough already. It's the
default name chosen by git-buildpackage, so if there is agreement that
this isn't a good name, I'll submit a patch to change that.
Thanks again for taking a look at my package; if there are any other
issues (or if you think I didn't address your concerns appropriately),
don't hesitate to let me know.
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/20120726154551.ge2...@marvin.lan
Bug#682781: RFS: minidlna
Bart Martens wrote:
> On Thu, Jul 26, 2012 at 05:45:51PM +0200, Benoît Knecht wrote:
> > Bart Martens wrote:
> > > minidlna-1.0.25+dfsg/debian/copyright :
> > >
> > > | Source: http://sourceforge.net/projects/minidlna/files/
> > > | The icons.c file in the original tarball contained binary blobs of
> > > possibly
> > > | unfree images. It has hence been replaced in the DFSG tarball by a
> > > file
> > > | containing the free Debian logo instead. It can be generated from
> > > the SVG logo
> > > | using the debian/make_icons.sh script (see the header of that file
> > > for
> > > | instructions).
> > >
> > > http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
> > >
> > > | A repackaged .orig.tar.{gz,bz2,xz} should not contain any file that
> > > does not
> > > | come from the upstream author(s), or whose contents has been changed
> > > by you.
> > >
> > > So removing files is OK, adding/replacing files not.
> >
> > You're right, except that in this case, the source would fail to build
> > if I simply removed icons.c, so I think it falls under the exception
> > laid out in the footnote [1]:
> >
> > | As a special exception, if the omission of non-free files would lead
> > | to the source failing to build without assistance from the Debian
> > | diff, it might be appropriate to instead edit the files, omitting only
> > | the non-free parts of them, and/or explain the situation in a
> > | README.source file in the root of the source tree. But in that case
> > | please also urge the upstream author to make the non-free components
> > | easier separable from the rest of the source.
> >
> > [1]
> > http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#ftn.idp20146152
>
> That is about editing the to omit non-free parts, not about adding/replacing
> files.
I'm not sure what you're proposing I should do. The upstream icons.c
contained four binary blobs, each corresponding to a possibly unfree
logo. I can't remove the entire file (or it won't compile) and I can't
replace the binary blobs with empty strings (or it won't run). So I
changed the file as little as possible while ensuring that it leads to a
DFSG-compliant and running program; it just happens to be more or less
the same thing as replacing the entire file, since it contained unfree
data only.
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/20120727131001.ga2...@marvin.lan
Bug#682035: RFS: maxwell/1.2-1 (ITP #662736)
Hi Pedro, Pedro I. Sanchez wrote: > I am looking for a sponsor for my package "maxwell" > > * Package name: maxwell > Version : 1.2-1 > Upstream Author : Sandy Harris > * URL : ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ > * License : GPL v2 > Section : admin > > It builds those binary packages: > > maxwell - Daemon to gather entropy from a timer and feed it to random(4) There are a few lintian warnings that you should fix: P: maxwell source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 W: maxwell: hardening-no-relro usr/bin/maxwell W: maxwell: hardening-no-fortify-functions usr/bin/maxwell P: maxwell: no-upstream-changelog W: maxwell: new-package-should-close-itp-bug According to debian/copyright, the entire source is GPL-2, but only maxwell.c has a header mentioning GPL-2 (and not even the standard GPL header); there's no copy of the GPL included in the package either. You should ask upstream to add license headers to every source file (including the man page), following the instructions in the last section of the GPL [1], and a full copy of the GPL in a LICENSE file. [1] https://www.gnu.org/licenses/gpl-2.0.html Also, the source of Maxwell.pdf is missing. Other than that, the watch file isn't working: uscan warning: Filename pattern missing version delimiters () in debian/watch, skipping: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell\.tgz I haven't looked any further into the package. 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/20120727144517.gc2...@marvin.lan
Bug#678343: RFS: tilem/2.0-1 [ITP]
Hi Albert, Albert Huang wrote: > I am looking for a sponsor for my package "tilem" > > * Package name: tilem >Version : 2.0-1 >Upstream Author : Benjamin Moody and Thibault Duponchelle ( > tilem-de...@sourceforge.net) > * URL : http://lpg.ticalc.org/prj_tilem/ > * License : GPL, LGPL, GFDL >Section : math > > It builds those binary packages: > > tilem - GTK+ TI Z80 calculator emulator Your package build-depends on versions of libticables-dev, libticalcs-dev, libticonv-dev and libtifiles-dev that are not even in debian, which of course means it fails to build. How come? -- 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/20120727151400.gd2...@marvin.lan
Bug#682035: RFS: maxwell/1.2-1 (ITP #662736)
Benoît Knecht wrote: > There are a few lintian warnings that you should fix: > > P: maxwell source: unversioned-copyright-format-uri > http://dep.debian.net/deps/dep5 > W: maxwell: hardening-no-relro usr/bin/maxwell > W: maxwell: hardening-no-fortify-functions usr/bin/maxwell > P: maxwell: no-upstream-changelog > W: maxwell: new-package-should-close-itp-bug > > According to debian/copyright, the entire source is GPL-2, but only > maxwell.c has a header mentioning GPL-2 (and not even the standard GPL > header); there's no copy of the GPL included in the package either. You > should ask upstream to add license headers to every source file > (including the man page), following the instructions in the last section > of the GPL [1], and a full copy of the GPL in a LICENSE file. > > [1] https://www.gnu.org/licenses/gpl-2.0.html > > Also, the source of Maxwell.pdf is missing. > > Other than that, the watch file isn't working: > > uscan warning: Filename pattern missing version delimiters () > in debian/watch, skipping: > ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell\.tgz I forgot to mention one thing. Line 8 of maxwell.8 sets the line length to +8, which leads to a very strange layout. Please remove that line. 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/20120727161305.ge2...@marvin.lan
Bug#682781: RFS: minidlna
Bart Martens wrote: > On Fri, Jul 27, 2012 at 03:10:02PM +0200, Benoît Knecht wrote: > > I'm not sure what you're proposing I should do. > > I sometimes give feedback on a package without proposing a solution. I understand, but since I didn't see a solution myself, I thought I'd ask if you had any suggestions :) > In this case it is, in my opinion, OK to remove the non-free parts from the > upstream tarball, and to ship everything else in the .debian.tar.gz file. I disagree, if that means that the source cannot be built without the *.debian.tar.gz tarball. Out of curiosity, I had a look at the iceweasel package to see how they handled the repackaging, and they also substitute non-free portions with free replacements in a few files. So I think it's more important that the repackaged archive is buildable than to not modify any upstream file (as long as the modifications are documented, of course). 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/20120806145922.gc24...@marvin.lan
RFS: minidlna
Dear mentors, I am looking for a sponsor for my package "minidlna". * Package name: minidlna Version : 1.0.18-1 Upstream Author : Justin Maggard * URL : http://sourceforge.net/projects/minidlna/ * License : GPL-2 and BSD Section : net It builds these binary packages: minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems It compiles and runs fine on amd64 and armel (compiled in a clean chroot). The package appears to be lintian clean. The upload would fix this WNPP bug: 597228 My motivation for maintaining this package is: I've been using this software for a while on and armel machine running debian squeeze. I wanted to upgrade to the latest upstream version, which meant cross-compiling it, and while looking at the various ways to do this, it occured to me that the "right way" was to package it. As I use the software regularly, I can easily try to reproduce bugs, test patches, etc. I've been using debian for a few years now, but only from a user perspective. I think maintaining a package is a great way to get more involved in the project. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/minidlna - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.18-1.dsc I would be glad if someone had a look at it, and could give me some advice on what needs to be done/fixed before it's uploaded into debian. 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/20101015082302.ga21...@debian.lan
Re: RFS: minidlna
Hi, Paul Gevers wrote: > As you target embedded systems, maybe you should contact the emdebian > project [1] to see if you can more easily find a sponsor there. If you > try, but don't find one therer, please don't hesitate to return to this > list. Thanks for your advice. I would think people at emdebian interested in sponsoring a package would be watching this list too though, so I think I'll wait a bit before contacting them directly, and see if a sponsor manifests him-/herself here. I don't want to spread this request over several mailing lists unless it's absolutely necessary. Cheers. > [1] http://www.emdebian.org/support.html -- 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/20101018190211.ga...@debian.lan
Re: RFS: minidlna
Hi, Thanks a lot for your comments, I really appreciate you taking the time. Fernando Lemos wrote: > I'm not a DD or a DM, but here's my (very superficial) review, as I'm > mildly interested in this package. > > * It seems that you are missing Build-Depends on libavcodec-dev and > libavutil-dev. You're absolutely right; I missed it because it wasn't mentioned in the INSTALL file and libavformat-dev pulls both packages as its dependencies (so the pbuilder build did not fail). I fixed it in my git repository [1] and will upload it as version 1.0.18-2 as soon as I'm done with a few more changes (a man page for minidlna.conf and a better configuration file). > * lintian -I is mosly clean, except for: > > I: minidlna: spelling-error-in-binary ./usr/bin/minidlna Psychadelic > Psychedelic > > I believe that's really not a big deal, though (you might want to let > upstream know anyways). Fixed too, thanks. I will send it upstream, along with a few other changes they may want to include. Cheers. --- [1] http://gitorious.org/minidlna/minidlna -- 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/20101019134937.gb3...@debian.lan
Re: RFS: minidlna
Hi, Fernando Lemos wrote: > I'm not a DD or a DM, but here's my (very superficial) review, as I'm > mildly interested in this package. > > * It seems that you are missing Build-Depends on libavcodec-dev and > libavutil-dev. > > * lintian -I is mosly clean, except for: > > I: minidlna: spelling-error-in-binary ./usr/bin/minidlna Psychadelic > Psychedelic > > I believe that's really not a big deal, though (you might want to let > upstream know anyways). I've now uploaded a corrected version (minidlna-1.0.18-2), and forwarded the relevant patches upstream. You can find it at <http://mentors.debian.net/debian/pool/main/m/minidlna>. I'm still looking for a sponsor, so don't hesitate if any of you is interested. Thanks again for your help. -- 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/20101022125318.ga21...@debian.lan
Re: RFS: minidlna
Hi Michael, Thanks a lot for reviewing my package. Michael Tautschnig wrote: > I've reviewed your package, and found the following issues, which should be > corrected: > > - Copyright information in source files is very incomplete. Some of them even > lack any information. Please run licensecheck *.c *.h linux/*.h to get the > complete list. I noticed this too, but I was not sure what I could do to fix it. I guess I'll contact upstream and see if they can add the missing copyright headers. Even if I knew the exact license of each file, I don't think patching them just for debian makes much sense. > - As your postrm and prerm already do, you should only take action in case of > specific states (probably configure only, but not abort-*). You're absolutely right. Fixed in my repository. > - You ship a defaults file, which allows to customize $USER and $GROUP, but > your > scripts don't take this into account. Are you sure about that one? In minidlna.init, I only assign default values to $USER and $GROUP if they are empty (which won't be the case if they where set in the default file). > - Lintian has some information for you (I prefer lintian -iI --pedantic): > I: minidlna: hyphen-used-as-minus-sign usr/share/man/man1/minidlna.1.gz:45 > P: minidlna: maintainer-script-without-set-e postrm > P: minidlna: maintainer-script-without-set-e postinst > P: minidlna: maintainer-script-without-set-e prerm Fixed those too. > Hope this helps, I does help, a lot. I'm always happy getting feedback. Thanks again for taking the time. 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/20101029101046.ga12...@debian.lan
Re: RFS: minidlna
Michael Tautschnig wrote:
> > > - You ship a defaults file, which allows to customize $USER and $GROUP,
> > > but your
> > > scripts don't take this into account.
> >
> > Are you sure about that one? In minidlna.init, I only assign default
> > values to $USER and $GROUP if they are empty (which won't be the case if
> > they where set in the default file).
> >
>
> I'm sorry, I was too imprecise here. I was referring to the {pre,post}inst,
> {pre,post}rm scripts here. These should simply read the defaults file (if
> already available) as well.
Oh I see, thanks for clarifying.
It seems like a clever thing to do in {pre,post}inst: there's no need to
create a default minidlna user:group if something else is already set in
the default file; I'm just unsure if it should create the user:group
found in the default file if they do not exist already (if they do not
exist, they were most likely removed by the user manually, and
re-creating them silently as system users seems like a bad idea).
And in postrm, I would not remove any user:group except
minidlna:minidlna, which was normally created by preinst.
Is this what you had in mind? I'll implement those changes, and upload a
new version soon.
Thanks again for your precious help.
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/20101029121408.gb12...@debian.lan
Re: RFS: minidlna
Hi Michael,
Sorry for the delay, but I've been awfully busy over the week end.
Michael Tautschnig wrote:
> > It seems like a clever thing to do in {pre,post}inst: there's no need to
> > create a default minidlna user:group if something else is already set in
> > the default file; I'm just unsure if it should create the user:group
> > found in the default file if they do not exist already (if they do not
> > exist, they were most likely removed by the user manually, and
> > re-creating them silently as system users seems like a bad idea).
> >
> > And in postrm, I would not remove any user:group except
> > minidlna:minidlna, which was normally created by preinst.
> >
> > Is this what you had in mind? I'll implement those changes, and upload a
> > new version soon.
>
> Well, actually I would have been ok with the naive use&create/remove whatever
> the user specified in defaults; but you're absolutely right, you could and
> should be more careful here. I think it would be fine to abort in case user
> and
> group are not equal to minidlna and do not exist.
I just uploaded a new version (1.0.18-3) [1] that addresses all the
issues you've pointed out to me (except the missing license headers,
I'll ask upstream about that).
I hope I didn't miss anything, but please let me know if there are any
problems left.
Cheers,
--
Benoît Knecht
---
[1] http://mentors.debian.net/debian/pool/main/m/minidlna
--
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/20101103124904.ga26...@debian.lan
Re: RFS: minidlna
Hi Michael, Once again, thanks for your careful review, I greatly appreciate it. Michael Tautschnig wrote: > I've spotted a two more minor issues which you might want to correct > nevertheless as we'll have to wait for the license-header fix anyway > to make this code distributable. > > - Once you get the copyright information for linux/*.h you will want > to add this to debian/copyright as well. Absolutely, thanks for reminding me. > - You can make debian/minidlna.prerm almost empty as the #DEBHELPER# > will be replaced with the proper stopping code anyway (see > debian/minidlna/DEBIAN/prerm after building the package). Great, I didn't know that. I'll fix this right away. For now, I'm waiting for upstream to address the licensing issue, so I won't upload a new version until then. But I'm still fixing things locally and if anyone notices other issues with the package, please do point them out. I'm hoping my next upload will be the one :) Thanks to all who reviewed this package so far (whether they commented here or not). 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/20101105165015.ge12...@debian.lan
Re: RFS: taskcoach - useful task manager - new - python app
Hi Alejandro, Alejandro Garrido Mota wrote: > I am looking for a sponsor for my package "taskcoach". > > [...] > > Also is found in http://github.com/mogaal/taskcoach Just a minor comment: your man page is dated 2008-12-25, but your git repository shows you last changed it on 2010-04-14. You should change the date tag in the man page to reflect that; it will also make it coherent with your debian/copyright file. 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/20101108102039.gb29...@debian.lan
Re: RFS: taskcoach - useful task manager - new - python app
Benoît Knecht wrote: > Hi Alejandro, > > Alejandro Garrido Mota wrote: > > I am looking for a sponsor for my package "taskcoach". > > > > [...] > > > > Also is found in http://github.com/mogaal/taskcoach > > Just a minor comment: your man page is dated 2008-12-25, but your git > repository shows you last changed it on 2010-04-14. You should change > the date tag in the man page to reflect that; it will also make it > coherent with your debian/copyright file. I also suggest you apply the changes below to your man page; it should make it more readable. And you may want to change the SEE ALSO link to point directly to the online documentation [1] (although it would be nice to have a local copy of the user manual too). [1] http://taskcoach.wikispaces.com/Task+Coach+Manual diff --git a/debian/taskcoach.1 b/debian/taskcoach.1 index 3da75ba..695445a 100644 --- a/debian/taskcoach.1 +++ b/debian/taskcoach.1 @@ -1,7 +1,4 @@ .\" Hey, EMACS: -*- nroff -*- -.\" First parameter, NAME, should be all caps -.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection -.\" other parameters are allowed: see man(7), man(1) .TH TASKCOACH 1 "December 25, 2008" .SH NAME taskcoach \- friendly and simple task manager @@ -17,7 +14,7 @@ such as those provided with Outlook or Lotus Notes, do not provide facilities for composite tasks. .SH OPTIONS The application follows the usual GNU command line syntax, with long -options starting with two dashes (`-'). +options starting with two dashes (`\-'). A summary of options is included below. .TP .B \-h, \-\-help @@ -26,14 +23,20 @@ Show summary of options. .B \-v, \-\-version Show version of program. .TP -.B \-i INIFILE, \-\-ini=INIFILE -use the specified INIFILE for storing settings +.BI \-i\ INIFILE ,\ \-\-ini= INIFILE +Use the specified +.I INIFILE +for storing settings. .TP -.B \-l LANGUAGE, \-\-language=LANGUAGE -use the specified LANGUAGE for the GUI (e.g. "nl" or "fr") +.BI \-l\ LANGUAGE ,\ \-\-language= LANGUAGE +Use the specified +.I LANGUAGE +for the GUI (e.g. "nl" or "fr"). .TP -.B \-p POFILE, \-\-po=POFILE -use the specified POFILE for translation of the GUI +.BI \-p\ POFILE ,\ \-\-po= POFILE +Use the specified +.I POFILE +for translation of the GUI. .SH SEE ALSO Official web page: www.taskcoach.org .SH AUTHOR -- 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/20101109000145.gb1...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Hi Noel, Noel David Torres Taño wrote: > On Sábado 18 Septiembre 2010 22:38:23 Noel David Torres Taño escribió: > > Dear mentors, > > > > I am looking for a sponsor for my package "kstars-data-extra-tycho2". > > > > * Package name: kstars-data-extra-tycho2 > > Version : 1.1r1-1 > > Upstream Author : Akarsh Simha, Jason Harris > > * URL : > > http://edu.kde.org/kstars/downloads/tycho2_mag_12.5-1.1.tar.bz2 > > * License : GPL Well, as discussed in bug #597202, it's not really clear why the data would be GPL. The first question is, was the original Tycho 2 catalogue released in the public domain (or a GPL-compatible license). The ADC statement doesn't provide much information in that regard; they say that ADC data is public domain (but go on to say "for scientific use only", which is quite contradictory), and although they were distributing the Tycho 2 catalogue, I very much doubt they are the copyright holder (that would be the ESA). So I think you need to track down the real copyright holder and make sure the data has indeed no copyright. The second question (which is only relevant if the original data set is free) is, did Akarsh Simha and Jason Harris modify this original data set to an extent that would justify a new copyright (did they create an original work out of it; simply modify the data format or filtering out some data is not something that would justify a new copyright). If so, it should be made clear what they did, and the resulting data set can be released under the GPL with both of them as copyright holders. If not, then they are not the copyright holders (and if the original data set is in the public domain, then no one is), and the upstream license should not be GPL. -- 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/20101110170003.ga24...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Benoît Knecht wrote: > Noel David Torres Taño wrote: > > On Sábado 18 Septiembre 2010 22:38:23 Noel David Torres Taño escribió: > > > Dear mentors, > > > > > > I am looking for a sponsor for my package "kstars-data-extra-tycho2". > > > > > > * Package name: kstars-data-extra-tycho2 > > > Version : 1.1r1-1 > > > Upstream Author : Akarsh Simha, Jason Harris > > > * URL : > > > http://edu.kde.org/kstars/downloads/tycho2_mag_12.5-1.1.tar.bz2 > > > * License : GPL > > Well, as discussed in bug #597202, it's not really clear why the data > would be GPL. > > [...] A few more comments: - Your debian/docs file is empty; did you mean to add something there, like README.source for instance? - I don't think you need a patch just to create a Makefile. You can achieve the same result with a debian/install file. - Your debian/rules contains a typo: "%export DH_VERBOSE=1" instead of "#export DH_VERBOSE=1"; I'm also not sure why you're exporting DESTDIR. - You may want to rephrase the description in debian/control; the sentence "Installing this package avoids the need for the users to each one download the catalog for itself" sounds wrong (instead of "itself", I would write "themselves" or "him/herself"). But something like "Installing this package avoids the need for each user to individually download the whole catalog " might be even clearer. I hope this helps. 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/20101110210122.ga25...@debian.lan
Re: RFS: clipit
Hi Cristian,
Cristian Henzel wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "clipit".
>
> * Package name: clipit
> Version : 1.2.1-1
> Upstream Author : Cristian Henzel
> * URL : http://sourceforge.net/projects/gtkclipit/
> * License : GPLv3
> Section : misc
>
> It builds these binary packages:
> clipit - lightweight GTK+ clipboard manager
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 603131
I just did a quick review of your package:
- lintian reports the following two issues, that you might want to fix:
* I: clipit source: debian-watch-file-is-missing
* W: clipit source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
- Your debian/rules file could only contain the default rule; the
changelog is automatically installed.
- You can remove the debian/docs file; these files are automatically
installed.
- In debian/copyright:
* Patterns such as keybinder.{c,h} are not
allowed; you could use keybinder.? instead, or enumerate both file
names.
* I think your Format-Specification should point to a specific
revision, such as [1].
* You could factorize at least the GPL-3+, to avoid repetition (only
mention GPL-3+ throughout the file, and have a standalone License
section at the end).
[1] http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
- You have a patch in debian/patches; since you are the upstream
author, are you going to apply it upstream or is this intentional?
- When compiling the package, I get some warnings from dpkg-shlibdeps
that maybe you could try and fix (see at the very end of this email).
Cheers,
--
Benoît Knecht
---
dpkg-shlibdeps: warning: dependency on libfontconfig.so.1 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libatk-1.0.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libm.so.6 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libgio-2.0.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libgdk_pixbuf-2.0.so.0 could be avoided
if "debian/clipit/usr/bin/clipit" were not uselessly linked against it (they
use none of its symbols).
dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libpango-1.0.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libgmodule-2.0.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libgthread-2.0.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libpangocairo-1.0.so.0 could be avoided
if "debian/clipit/usr/bin/clipit" were not uselessly linked against it (they
use none of its symbols).
dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
dpkg-shlibdeps: warning: dependency on libpangoft2-1.0.so.0 could be avoided if
"debian/clipit/usr/bin/clipit" were not uselessly linked against it (they use
none of its symbols).
--
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/2010100206.gc25...@debian.lan
Re: RFS: clipit
Cristian Henzel wrote:
> I have managed to fix almost all of the problems, beside two. The first
> one being the "dpkg-shlibdeps" warnings. I cannot figure out where they
> come from. When I created the control file, I have only put as
> dependency the following things:
> Build-Depends: debhelper (>= 7.0.50~), libgtk2.0-dev, intltool
> So I am not sure where dpkg-buildpackage takes the other dependencies from.
This is fine. The warning is about ${shlibs:Depends} in Depends. This
variable is expanded to whatever packages are found by looking at the
symbols in the executables. Here, dpkg-shlibdeps is telling you that
you're linking to libraries whose symbols aren't really used by the
executable. To fix it, you'd have to link each executable only to the
libraries it really needs in your upstream Makefile (or maybe you can
use "-Wl,--as-needed").
> The second problem that I'm having is that the package that I provide
> normally on sourceforge, needs to be prepared with ./autogen.sh. This
> script will call autoconf, automake, and some other stuff, to create the
> configure script and the other things that are needed for compiling.
> Now, when I have created the deb package, I have just unpacked the
> tar.gz from sourceforge, ran ./autogen.sh on the extracted folder, and
> then packaged it back up to a tar.gz and used that one as the source
> file. I imagine though that this might not be the correct way to do it,
> so if you could please tell me how exactly this should be done, I would
> appreciate it.
I think debhelper handles autoconf automatically, so you should be able
to use your upstream tarball as is, without running ./autogen.sh
manually.
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/2010124847.ga19...@debian.lan
Re: RFS: clipit
Benoît Knecht wrote:
> Cristian Henzel wrote:
> > I am looking for a sponsor for my package "clipit".
> >
> > * Package name: clipit
> > Version : 1.2.1-1
> > Upstream Author : Cristian Henzel
> > * URL : http://sourceforge.net/projects/gtkclipit/
> > * License : GPLv3
> > Section : misc
> >
> > It builds these binary packages:
> > clipit - lightweight GTK+ clipboard manager
> >
> > The package appears to be lintian clean.
> >
> > The upload would fix these bugs: 603131
>
> I just did a quick review of your package:
>
> [...]
One more thing (not specifically debian-related), about your man page
(doc/clipit.1):
- You use non-standard section names (such as "ACTIONS" and "CLI
EXAMPLES"). You should stick to the standard names described in
man-pages(7), and have subsections if you need more specific names.
- A ".TP" is missing before the "-p, --primary" option.
- (This is mostly nitpicking, so feel free to ignore.) The date is
ambiguous (is it 1st November or 11th January?); the ISO 8601 date is
probably a better choice (2010-11-01, assuming you meant November).
While I'm nitpicking: I'd also use some punctuation at the end of
each item in the OPTIONS section.
- On a less technical note, the examples section would be clearer with
some explanation of each case ("copying from stdin to the clipboard",
"copying argument to the clipboard", etc.)
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/2010140634.gb19...@debian.lan
Re: RFS: icoutils (updated package)
Hi Markus, Markus Schölzel wrote: > I am looking for a sponsor for the new version 0.29.1-0.1 > of my package "icoutils". > > It builds these binary packages: > icoutils - Create and extract MS Windows icons and cursors > > The package appears to be lintian clean. > > The upload would fix these bugs: 511944, 516170, 589377 Since you're fixing a man page typo in this release (bug #516170), do you think you could fix those lintian warnings as well? I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/extresso.1.gz:63 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/extresso.1.gz:64 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:65 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:66 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:83 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:87 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:91 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:107 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:115 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:121 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:163 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz:164 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/icotool.1.gz 12 more occurrences not shown I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:44 I: icoutils: spelling-error-in-manpage usr/share/man/man1/wrestool.1.gz preceeded preceded I: icoutils: spelling-error-in-manpage usr/share/man/man1/wrestool.1.gz preceeded preceded I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:60 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:80 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:85 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:174 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:175 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:176 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:177 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:178 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz:182 I: icoutils: hyphen-used-as-minus-sign usr/share/man/man1/wrestool.1.gz 2 more occurrences not shown There are also two lintian --pedantic warnings that should be easy enough to fix: P: icoutils: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: icoutils: no-homepage-field 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/2010164630.ga20...@debian.lan
Re: RFS: clipit
Hi again, Cristian Henzel wrote: > I have managed to get rid of the dpkg-shlibdeps warning by using the > flag '-Wl,--as-needed'. I have also solved the autogen.sh problem by > overriding dh_clean like this: > > override_dh_clean: > dh_clean > ./autogen.sh You should override dh_auto_configure instead, like so: override_dh_auto_configure: ./autogen.sh dh_auto_configure > [...] > > The only problems (at least as far as I can tell) left right now are > that autogen.sh asks for user input when running (this is because of > gettext) This is indeed an issue, the build process should not require user input. I don't know how to fix it though, I'll need to have a closer look; or maybe someone else can be of assistance. > and I'm not sure if this is allowed, that a pretty big patchfile gets > created because of the extra files that autogen.sh creates This should be solved by not calling ./autogen.sh at the end of the clean target. > I have also fixed the problems with the manpage and have made a new > upstream release to include all of the changes. Great, thanks! > Regarding your comment: > > > This is mostly nitpicking, so feel free to ignore. > > I have to say that I appreciate every constructive comments and I thank > you very much for your patience and the great help. You're very welcome. And thank _you_ very much for packaging this software! 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/2010194447.ga2...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Hi Noel, Noel David Torres Taño wrote: > On Miércoles 10 Noviembre 2010 21:01:22 Benoît Knecht escribió: > > Benoît Knecht wrote: > > [...] > > > > - I don't think you need a patch just to create a Makefile. You can > >achieve the same result with a debian/install file. > > > > [...] > > Thanks for your comments. I was trying to get things on that way, but I've > found no information at all in the Policy about debian/install . Where can I > found info about it? In the dh_install(1) man page, and in the Debian New Maintainers' Guide <http://www.debian.org/doc/maint-guide/ch-dother.en.html#s-install>. 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/20101112141647.gb6...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Hi Noel, Noel David Torres Taño wrote: > On Miércoles 10 Noviembre 2010 21:01:22 Benoît Knecht escribió: > [...] > > [...] > > > > - I don't think you need a patch just to create a Makefile. You can > >achieve the same result with a debian/install file. > > > > - Your debian/rules contains a typo: "%export DH_VERBOSE=1" instead of > >"#export DH_VERBOSE=1"; I'm also not sure why you're exporting > >DESTDIR. > > > > [...] > > Done. New version uploaded. You still have a patch in debian/patches creating a Makefile, and you are exporting DESTDIR in debian/rules although it works without it just as well. > Is the package ready? I'm most interested in the postinst since it is the > point I'm trying to achieve. I'll try and have a look at postinst later, but I'm not very familiar with debconf or the kstarsrc syntax, so I'll be of little assistance I'm afraid. 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/20101112164724.ge6...@debian.lan
Re: RFS: libgis - virtual globe library
Hi Andy, Andy Spencer wrote: > I am looking for a sponsor for my package "libgis". > > * Package name: libgis > Version : 0.4.1-1 > Upstream Author : Andy Spencer (myself) > * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki > * License : GPL-3+ > Section : science > > It builds these binary packages: > libgis - A Virtual Globe library > libgis-bin - Example programs for libgis > libgis-dev - Development files for libgis > libgis-doc - HTML documentation for libgis I didn't really look at your package yet, but I just wanted to point out that you're not closing any bugs with this release. You're supposed to file a bug against WNPP (Work-Needing and Prospective Packages) and note in the debian/changelog entry that this package would be closing that bug. See [1] for details about the procedure. [1] http://www.debian.org/devel/wnpp/ 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/20101113092203.ga3...@debian.lan
Re: RFS: libgis - virtual globe library
Hi Andy,
Andy Spencer wrote:
> I am looking for a sponsor for my package "libgis".
>
> * Package name: libgis
> Version : 0.4.1-1
> Upstream Author : Andy Spencer (myself)
> * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki
> * License : GPL-3+
> Section : science
>
> It builds these binary packages:
> libgis - A Virtual Globe library
> libgis-bin - Example programs for libgis
> libgis-dev - Development files for libgis
> libgis-doc - HTML documentation for libgis
I had a closer look at your package, and additionally to David's
comments, I noticed the following:
- In debian/control, libgis-bin should depend on ${shlibs:Depends}
instead of listing all the libraries explicitly. And I don't think
libgis-doc should Depend on libgis (but it could Recommend it, and
libgis could Suggest libgis-doc).
- In debian/docs, remove the ChangeLog entry; it is installed and
gzipped automatically.
- You should delete debian/lintian.txt (after reading it :-) ).
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/20101113102747.gb3...@debian.lan
Re: RFS: icoutils (updated package)
Markus Schölzel wrote: > May you want to have a look at > - URL:http://mentors.debian.net/debian/pool/main/i/icoutils > - > dgethttp://mentors.debian.net/debian/pool/main/i/icoutils/icoutils_0.29.1-0.2.dsc > > Now there should not come up I: or P: warnings anymore. You seem to have a debian directory inside the debian directory (debian/debian), not sure how that happened. Other than that it seems okay, although I cannot comment on the software itself, I didn't try to run it. 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/20101113141314.gc3...@debian.lan
Re: RFS: 9menu (updated package, Second try)
Hi, epsilon wrote: > I am looking for a sponsor for the new version 1.8-4 > of my package "9menu". > > It builds these binary packages: > 9menu - Creates X menus from the shell You can further simplify your debian/rules file by letting debhelper know what to do through files in debian/ instead of overrides. For example, instead of overriding dh_clean, you can list additional files to be removed in debian/clean. Same thing for dh_installman and dh_installdocs. 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/20101113142557.gd3...@debian.lan
Re: RFS: pycam
Hi Lars,
Lars Kruse wrote:
> I am looking for a sponsor for my package "pycam".
>
> * Package name: pycam
> Version : 0.4-1
> Upstream Author : Lode Leroy, Lars Kruse (that's me)
> * URL : http://pycam.sourceforge.net
> * License : GPL3
> Section : python
>
> It builds these binary packages:
> pycam - CAM program & library written in Python
Here are the few issues I spotted in your package:
- You have debian/{postinst,prerm} scripts, but they do not do
anything. You should just delete them.
- In debian/copyright, there is no email address for either of the
maintainers (and Sebastian Kuzminsky's email is not formatted
correctly). While you're at it, you should also add yourself to the
packaging copyright.
You may also want to use the DEP-5 format [1] for that file.
[1] http://dep.debian.net/deps/dep5/
- lintian -I gives the following warnings:
I: pycam source: quilt-patch-missing-description
00.remove_windows_install_script.patch
I: pycam source: quilt-patch-missing-description
01.remove-superfluous-files-from-doc.patch
I: pycam source: debian-watch-file-is-missing
and these three about the man page:
I: pycam: spelling-error-in-manpage usr/share/man/man1/pycam.1.gz
paramters parameters
I: pycam: hyphen-used-as-minus-sign usr/share/man/man1/pycam.1.gz:248
I: pycam: hyphen-used-as-minus-sign usr/share/man/man1/pycam.1.gz:261
It would be nice if you could fix them.
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/20101113175722.ga31...@debian.lan
Re: RFS: pycam
Hi Lars, Lars Kruse wrote: > [...] > > > I: pycam: spelling-error-in-manpage usr/share/man/man1/pycam.1.gz > > [...] > > I fixed these spelling mistakes upstream. The changes will go into the debian > package of the next release of PyCAM. > btw: what did you do to generate these spelling warnings? I could not find any > reference to a spell checker in lintian ... I simply ran lintian -I on the .deb file, I don't think there's anything special to do to get these warnings; maybe you're using an older version (I have 2.4.3)? > I guess, now the package should be in a good shape. > I would be happy, if anybody would be willing to upload it. I can't upload it, but I'm sure someone else will. Good luck! 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/20101116083337.ga7...@debian.lan
Re: RFS: webhoneypot
Benoît Knecht wrote:
> Hi Christian,
>
> Christian Pohl wrote:
> > I am looking for a sponsor for my package "webhoneypot".
> >
> > * Package name: webhoneypot
> > Version : 0.1.123
> > Upstream Author : Johannes Ulrich
> > * URL : http://code.google.com/p/webhoneypot/
> > * License : GPL-2
> > Section : web
> >
> > It builds these binary packages:
> > webhoneypot - DShield Web Honeypot Project
> >
> > The upload would fix these bugs: 595907
>
> I didn't look at your package yet, but lintian reports a few issues that
> you should definitely fix:
>
> I: webhoneypot source: missing-debian-source-format
> P: webhoneypot source: direct-changes-in-diff-but-no-patch-system
> apache/webhoneypot and 5 more
> I: webhoneypot source: no-complete-debconf-translation
> I: webhoneypot source: debian-watch-file-is-missing
> W: webhoneypot source: non-native-package-with-native-version
> W: webhoneypot source: debhelper-but-no-misc-depends webhoneypot
> W: webhoneypot source: dh-clean-k-is-deprecated
> W: webhoneypot source: out-of-date-standards-version 3.8.0 (current is
> 3.9.1)
>
> You can get a detailed description of these messages by running:
>
> lintian -iI --pedantic webhoneypot_0.1.123.dsc
OK, so I had a closer look at your package, and here are a few more
comments:
- lintian reports these warnings on the binary package (run
lintian -iI --pedantic webhoneypot_0.1.123_${arch}.deb
for details):
I: webhoneypot: unused-debconf-template
webhoneypot/note_enable_apache_config
I: webhoneypot: using-first-person-in-description line 5: we
I: webhoneypot: using-first-person-in-description line 5: We
I: webhoneypot: using-first-person-in-description line 7: We
I: webhoneypot: using-first-person-in-description line 7: we
I: webhoneypot: using-first-person-in-description line 8: we
I: webhoneypot: using-first-person-in-description line 9: we
I: webhoneypot: copyright-with-old-dh-make-debian-copyright
W: webhoneypot: script-not-executable
./usr/share/webhoneypot/update/update-templates.php
P: webhoneypot: maintainer-script-without-set-e config
W: webhoneypot: package-contains-upstream-install-documentation
usr/share/doc/webhoneypot/INSTALL.gz
- Your debian/rules file could be greatly simplified if you make use of
debhelper's default behavior. For example, you can use a
debian/install file and let dh_install copy the files automatically
instead of overriding the install target. See [1] and the debhelper
documentation for details.
[1] http://www.debian.org/doc/maint-guide/ch-dother.en.html
- I'm not very familiar with debconf, but it doesn't seem like you're
doing anything with it in debian/{pre,post}inst. If it's intentional,
you should remove those files. The same goes for webhoneypot.config.
- debian/README.debian should be word wrapped at around 80 chars.
- Please consider using DEP-5 [2] format for your debian/copyright
file.
[2] http://dep.debian.net/deps/dep5/
I hope this helps.
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/20101116155212.gb7...@debian.lan
Re: RFS: gts (updated package)
Hi Ruben,
Ruben Molina wrote:
> I am looking for a sponsor for the new version 0.7.6+darcs101112-1
> of my package "gts".
>
> It builds these binary packages:
> libgts-0.7-5 - library to deal with 3D computational surface meshes
> libgts-bin - utility binaries for libgts
> libgts-dbg - debugging symbols for libgts
> libgts-dev - development files for libgts
> libgts-doc - documentation for libgts
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 554757
I've just built your package and got the following warning:
dpkg-gencontrol: warning: Depends field of package libgts-doc: unknown
substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: Depends field of package libgts-dev: unknown
substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: Depends field of package libgts-dbg: unknown
substitution variable ${shlibs:Depends}
It's completely harmless, but it's also quite easy to fix. It's probably
not worth re-uploading just to fix this, but if you have to make more
substantial changes or in the next release, think about fixing that one
too.
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/20101117210148.ga9...@debian.lan
Re: RFS: triggerhappy
Hi Stefan, Stefan Tomanek wrote: > I am looking for a sponsor for my package "triggerhappy". > > * Package name: triggerhappy > Version : 0.1.3-1 > Upstream Author : Stefan Tomanek > * URL : http://github.com/wertarbyte/triggerhappy > * License : GPL > Section : admin > > It builds these binary packages: > triggerhappy - global, user and session independent hotkey daemon > > The package appears to be lintian clean. lintian -I --pedantic actually gives a few warnings: I: triggerhappy source: debian-watch-file-is-missing W: triggerhappy: description-starts-with-leading-spaces I: triggerhappy: init.d-script-does-not-provide-itself /etc/init.d/triggerhappy P: triggerhappy: no-upstream-changelog I: triggerhappy: spelling-error-in-manpage usr/share/man/man1/thd.1.gz seperated separated I: triggerhappy: spelling-error-in-manpage usr/share/man/man1/thd.1.gz appropiate appropriate I'm also wondering if "admin" is the right section for your package; "utils" maybe? And although it is not required, using DEP-5 format [1] for your debian/copyright file might be a good idea. [1] http://dep.debian.net/deps/dep5/ Well, it's a rather superficial review, but I hope it's helpful anyway. Oh and one last thing (keep in mind I didn't look into your package very thoroughly, so forgive me if it's a silly question), I saw in your changelog that you introduced an option to drop root privileges; why aren't you using it by default? From a security point of view, it would of course be preferable, but maybe there's another reason not to do it? 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/20101117235955.gb9...@debian.lan
Re: RFS: webhoneypot
Hi Christian,
Christian Pohl wrote:
> I've gone through the messages and uploaded the new package to
> mentors.debian.net.
> Could you check it?
Thanks for the corrections you made. I still have a few comments though:
- lintian isn't completely happy yet:
I: webhoneypot: using-first-person-in-description line 5: we
I: webhoneypot: using-first-person-in-description line 5: We
I: webhoneypot: using-first-person-in-description line 7: We
I: webhoneypot: using-first-person-in-description line 7: we
I: webhoneypot: using-first-person-in-description line 8: we
I: webhoneypot: using-first-person-in-description line 9: we
P: webhoneypot: no-upstream-changelog
W: webhoneypot: script-not-executable
./usr/share/webhoneypot/update/update-templates.php
W: webhoneypot: maintainer-script-empty preinst
- You don't seem to have taken Ansgar's remark into account ("I would
not expect packages to install a virtual host configuration in
/etc/apache2"...)
- There's an empty debian/webhoneypot.linitian-overrides file; delete
it.
- Your debian/watch file is empty too; you should fix it or remove it.
- man/webhoneypot.conf.1 should be in section 5.
- Several of your files have trailing whitespace or extra newlines at
the end (at least
debian/{README.debian,control,prerm,rules,postrm,patches/debian-changes-0.1.r123-1}
do); it would be nice to clean that up.
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/20101118173231.ga31...@debian.lan
Re: RFS: python-pygene
Hi Mathieu, Mathieu Negri wrote: > I am looking for a sponsor for my package "python-pygene". > > * Package name: python-pygene > Version : 0.2.1-1 > Upstream Author : David McNab > * URL : http://www.freenet.org.nz/python/pygene/ > * License : GPL2 > Section : python > > It builds these binary packages: > python-pygene - simple python genetic algorithms/programming library > > The package appears to be lintian clean. > > The upload would fix these bugs: 592962 I had a look at your package, and just have a few comments: - Documentation takes the biggest part of this package. How about making it separate (python-pygene-doc), so that it can be installed only if needed? - demo_fractal.py has a small typo that prevents it from running properly: File "./demo_fractal.py", line 72 ) ^ SyntaxError: invalid syntax (It should be a '}' instead.) - The word wrap in the bullet list in your debian/control file doesn't look right; for example, in the second bullet point, "dimentional" should be aligned with "Several". - patches/debian-changes-0.2.1-1 only creates a file called fold.txt, which contains the same information as debian/control and is not included in the package; I guess it's a mistake. 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/20101118181546.gb31...@debian.lan
Re: RFS: webhoneypot
Hi Christian, Christian Pohl wrote: > I am looking for a sponsor for my package "webhoneypot". > > * Package name: webhoneypot > Version : 0.1.123 > Upstream Author : Johannes Ulrich > * URL : http://code.google.com/p/webhoneypot/ > * License : GPL-2 > Section : web > > It builds these binary packages: > webhoneypot - DShield Web Honeypot Project > > The upload would fix these bugs: 595907 I didn't look at your package yet, but lintian reports a few issues that you should definitely fix: I: webhoneypot source: missing-debian-source-format P: webhoneypot source: direct-changes-in-diff-but-no-patch-system apache/webhoneypot and 5 more I: webhoneypot source: no-complete-debconf-translation I: webhoneypot source: debian-watch-file-is-missing W: webhoneypot source: non-native-package-with-native-version W: webhoneypot source: debhelper-but-no-misc-depends webhoneypot W: webhoneypot source: dh-clean-k-is-deprecated W: webhoneypot source: out-of-date-standards-version 3.8.0 (current is 3.9.1) You can get a detailed description of these messages by running: lintian -iI --pedantic webhoneypot_0.1.123.dsc 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/20101116140608.ga7...@debian.lan
Re: RFS: triggerhappy [fixed mistake in URL]
Hi Stefan, Stefan Tomanek wrote: > I am looking for a sponsor for my package "triggerhappy". > > * Package name: triggerhappy > Version : 0.1.6-1 > Upstream Author : Stefan Tomanek > * URL : http://github.com/wertarbyte/triggerhappy/ > * License : GPL > Section : utils > > It builds these binary packages: > triggerhappy - global, user and session independent hotkey daemon > > The package appears to be lintian clean. I see you've now opened a bug for your package (#603842), but you still need to close it in your changelog. And it should be an ITP bug owned by you, not an RFP. Besides that, I still believe it would be best to run the daemon as a regular system user by default, and let the user decide if root privileges are required (with a commented-out option in /etc/default/triggerhappy with some explanation about when and why it should be run as root, for example). And this is not a big deal, but I think it's worth mentioning anyway: your man pages have a "OPTIONS AND ARGUMENTS" header, whereas man-pages(7) recommends simply using "OPTIONS"; you may want to change that in order to be more consistent with most man pages. 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/20101121225441.ga8...@debian.lan
Re: RFS: triggerhappy [fixed mistake in URL]
Stefan Tomanek wrote: > Dies schrieb Benoît Knecht (benoit.kne...@fsfe.org): > > > I see you've now opened a bug for your package (#603842), but you still > > need to close it in your changelog. And it should be an ITP bug owned by > > you, not an RFP. > > I opened that bug before I uploaded the package here, hoping that someone > else might pick up that torch :-) I understand :) But now that you're packaging it, you should let people know by retitling the bug to ITP and setting yourself as the bug owner (otherwise someone else might start working on it too, only to discover the work has already been done). And don't forget to add "(Closes: #603842)" to your changelog. > > Besides that, I still believe it would be best to run the daemon as a > > regular system user by default, and let the user decide if root > > privileges are required (with a commented-out option in > > /etc/default/triggerhappy with some explanation about when and why it > > should be run as root, for example). > > Do you think "nobody" would be sufficient, or should triggerhappy create > a dedicated user account for that? I guess "nobody" is okay, unless the daemon needs to access files that should only be read-/writable by it. 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/20101121231102.gb8...@debian.lan
Re: RFS: triggerhappy [fixed mistake in URL]
Stefan Tomanek wrote: > Dies schrieb Benoît Knecht (benoit.kne...@fsfe.org): > > > I understand :) But now that you're packaging it, you should let people > > know by retitling the bug to ITP and setting yourself as the bug owner > > (otherwise someone else might start working on it too, only to discover > > the work has already been done). And don't forget to add "(Closes: > > #603842)" to your changelog. > > Hm, for some reason the BTS did not retitle the report, although it processed > the ownership change, do you know what I did wrong? As a matter of fact, I do :) You retitled it to the exact same title it already has: retitle 603842 RFP: triggerhappy -- a system-wide hotkey and input event daemon Change that to: retitle 603842 ITP: triggerhappy -- a system-wide hotkey and input event daemon and it should work just fine. 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/20101122083623.ga21...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Hi Noel, Noel David Torres Taño wrote: > On Viernes 12 Noviembre 2010 16:47:24 Benoît Knecht escribió: > [...] > > I'll try and have a look at postinst later, but I'm not very familiar > > with debconf or the kstarsrc syntax, so I'll be of little assistance I'm > > afraid. > > > Dear Benoît: > > Have you been able to do the check? Sorry, I had completely forgotten; thanks for reminding me. So first thing first. I tried installing your package using piuparts, and got the following error while running 'dpkg -i kstars-data-extra-tycho2_1.1r1-2_all.deb': Selecting previously deselected package kstars-data-extra-tycho2. (Reading database ... 6131 files and directories currently installed.) Unpacking kstars-data-extra-tycho2 (from .../kstars-data-extra-tycho2_1.1r1-2_all.deb) ... Setting up kstars-data-extra-tycho2 (1.1r1-2) ... /var/lib/dpkg/info/kstars-data-extra-tycho2.postinst: 39: cannot create /etc/kde4/kstarsrc: Directory nonexistent dpkg: error processing kstars-data-extra-tycho2 (--install): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: kstars-data-extra-tycho2 (Since your package doesn't depend on any kde4 stuff, you need to make sure /etc/kde4 exists.) Regarding debconf, you should make sure that you're not prompting the user when it's not necessary, so your postinst should take into account which parameter is passed to it; see [1] for details. [1] http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscriptprompt Along the same idea (minimizing user prompting), I think it would be a good idea to read kstarsrc and see if action/get_data is already set; if it is, don't prompt the user. Also, it would be better to just edit that file instead of overwriting it. Finally, I think the default for kstars-data-extra/kstarsrc-does-not-exist should be false (you don't want to create that configuration file and lock downloads without the user explicitly deciding to do so). 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/20101122111421.gb21...@debian.lan
Re: RFS: ifupdown-scripts-wa
Hi Stefan, Stefan Tomanek wrote: > I am looking for a sponsor for my package "ifupdown-scripts-wa". > > * Package name: ifupdown-scripts-wa > Version : 0.4.2 > Upstream Author : Stefan Tomanek > * URL : https://github.com/wertarbyte/ifupdown-scripts/ > * License : GPLv3 > Section : admin > > It builds these binary packages: > ifupdown-scripts-wa - Additional ifupdown scripts for configuring network > devices > > The package appears to be lintian clean. You should get in touch with the maintainer of ifupdown, Anthony Towns . And FYI, lintian reports the following: W: ifupdown-scripts-wa source: out-of-date-standards-version 3.8.1 (current is 3.9.1) W: ifupdown-scripts-wa: latest-debian-changelog-entry-changed-to-native 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/20101122140856.ga4...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Hi Noel, Noel David Torres Taño wrote: > On Lunes 22 Noviembre 2010 11:14:21 Benoît Knecht escribió: > > (Since your package doesn't depend on any kde4 stuff, you need to make > > sure /etc/kde4 exists.) > > Yes. I relied implicitly in having at least kstars itself installed. Which is > the best way to fix it? It can be (to my knowledge) a patch with the > directory > empty, or a command in debian/rules or debian/preinst creating it. What about skipping the debconf stuff if that directory doesn't exist? It doesn't really make sense changing the kstars configuration if it's not even installed, does it? > > [...] > > > > Along the same idea (minimizing user prompting), I think it would be a > > good idea to read kstarsrc and see if action/get_data is already set; if > > it is, don't prompt the user. Also, it would be better to just edit that > > file instead of overwriting it. > > I think I will not be able to do that on a first iteration (I'm not a genial > programmer). If the package enters without this, I will myself set this as a > wishlist bug. If you require it, I will work hard for it. I'm not in a position of requiring anything, these are all just suggestions (I'm not a DD and I can't upload your package). 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/20101123224520.ga21...@debian.lan
Re: RFS: minidlna
Benoît Knecht wrote: > For now, I'm waiting for upstream to address the licensing issue, so I > won't upload a new version until then. But I'm still fixing things > locally and if anyone notices other issues with the package, please do > point them out. I'm hoping my next upload will be the one :) So finally, here it is: I've uploaded version 1.0.18-4 of minidlna. The license headers have been added upstream (in CVS, so for now it's a patch in debian/patches), I've clarified the copyright status of each file in debian/copyright, and I've made a few tweaks to the maintainer scripts. There are a few other minor changes, please see the changelog. All piuparts tests are successful, and I've tested the program itself on both amd64 and armel. 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/20101123225418.gb21...@debian.lan
Re: RFS: kstars-data-extra-tycho2 (third try)
Noel David Torres Taño wrote: > On Martes 23 Noviembre 2010 22:45:20 Benoît Knecht escribió: > > I'm not in a position of requiring anything, these are all just > > suggestions (I'm not a DD and I can't upload your package). > > I thought you were :) I'm sorry for the confusion. As I'm not writing from a @debian.org address, I assumed people knew I'm not a DD. But perhaps I should make that fact clearer in the future... 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/20101123230858.gc21...@debian.lan
Re: RFS: stx-btree (updated package)
Hi Ury, Ury Stankevich wrote: > I am looking for a sponsor for the new version 0.8.3-3 > of my package "stx-btree". > > It builds these binary packages: > stx-btree-demo - b+tree implementation in c++, demo program > stx-btree-dev - b+tree implementation in c++ > stx-btree-doc - b+tree implementation in c++, doxygen documentation > > The package appears to be lintian clean. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/s/stx-btree > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/s/stx-btree/stx-btree_0.8.3-3.dsc > > I would be glad if someone uploaded this package for me. Just one quick remark: Have a look at your debian/patches/debian-changes-0.8.3-3, I don't think it does what you intended to do (it creates 10_fix-configure-wxwindows.diff and series in stx-btree-0.8.3/patches/). 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/20101126110956.ga31...@debian.lan
Re: RFS: gts (updated package) - 2nd try
Hi Ruben, Ruben Molina wrote: > I am looking for a sponsor for the new version 0.7.6+darcs101112-1 > of my package "gts". > > It builds these binary packages: > libgts-0.7-5 - library to deal with 3D computational surface meshes > libgts-bin - utility binaries for libgts > libgts-dbg - debugging symbols for libgts > libgts-dev - development files for libgts > libgts-doc - documentation for libgts > > The package appears to be lintian clean. > > The upload would fix these bugs: 554757 Out of curiosity, why does debian/manpages contain identical copies of the upstream doc/manpages/*.1 man pages? I noticed because I wanted to submit a bug about some formatting mistakes. I'm working on a patch for that, and I think it would make sense to patch the upstream files, but then I found out that they are not included in the binary package and debian/manpages/*.1 are used instead. 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/20101130155626.gb23...@debian.lan
Re: RFS: minidlna
Hi Michael, Michael Tautschnig wrote: > Package looks fine, thanks a lot! I have just uploaded your package, but it > will > have to wait in NEW until ftp-masters find the time to review the package. > Please bear in mind that we are in freeze and ftp-masters are likely busy with > other work in preparation of squeeze, so this review process might take a bit > longer than usual. And thank *you* for uploading my package! I understand it will take so time to be processed, there's certainly a lot of work to be done for squeeze and new packages are obviously not a priority, so that's fine. > Just one question regarding your most recent changes: Why did you remove the > AUTHORS sections from man pages? I just followed a recommendation from man-pages(7): "Use of an AUTHORS section is strongly discouraged. Generally, it is better not to clutter every page with a list of (over time potentially numerous) authors; if you write or significantly amend a page, add a copyright notice as a comment in the source file." It seemed sensible to me, so that's what I did. Thanks again for the reviews and the upload. You've been very helpful and it's really motivating to take part in a project with great people like you. 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/20101203002104.ga10...@kenny.lan
Re: RFS: free42
Hi Jean, Jean Schurger wrote: > I am looking for a sponsor for my package "free42". > > * Package name: free42 > Version : 1.4.66-1 > Upstream Author : Thomas Okken > * URL : http://thomasokken.com/free42/ > * License : GPL2 > Section : misc > > It builds these binary packages: > free42 - HP42S Emulator > > The package appears to be lintian clean. After applying the fix suggested by Etienne, I managed to build your package. I did not review it yet, but there are a few lintian warnings you may want to have a look into: I: free42 source: binary-control-field-duplicates-source field "section" in package free42 I: free42 source: debian-watch-file-is-missing I: free42: extended-description-is-probably-too-short P: free42: no-homepage-field W: free42: new-package-should-close-itp-bug W: free42: binary-without-manpage usr/bin/free42bin W: free42: binary-without-manpage usr/bin/free42dec I: free42: desktop-entry-contains-encoding-key /usr/share/applications/free42bin.desktop:2 Encoding W: free42: desktop-entry-invalid-category Categories=GTK /usr/share/applications/free42bin.desktop I: free42: desktop-entry-contains-encoding-key /usr/share/applications/free42dec.desktop:2 Encoding W: free42: desktop-entry-invalid-category Categories=GTK /usr/share/applications/free42dec.desktop (You can get details about these messages by running 'lintian -iI --pedantic' on your .changes file.) 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/20101208160600.gb10...@lin51.tphys.uni-heidelberg.de
Re: RFS: daisy-player
Hi Paul, Paul Gevers wrote: > I am looking for a reviewer and sponsor for my package "daisy-player". > > * Package name: daisy-player > Version : 5.3.1-1 > Upstream Author : Jos Lemmens > * URL : http://web.inter.nl.net/users/lemmensj/ > * License : GPL-2 > Section : sound > > It builds these binary packages: > daisy-player - player for DAISY Digital Talking Books > daisy-player-dbg - daisy-player debugging symbols I've not tested the program (I don't have any DAISY media), but I have a few comments about the packaging: - In debian/copyright, you need a standalone License section for the GPL-2+, and the short name for the GPL version 2 is GPL-2 (see http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135). - Read debian/README.source :) - Your debian/watch file does not work. - This is not really about packaging, but I think it's worth mentioning anyway. I find the man page a bit confusing is the way it lists the "keyboard commands" (is there not a better term for that, BTW): they're all preceded by a dash, which gives the impression they're command line options. And the second paragraph of the DESCRIPTION section contains a few underlined words that shouldn't be (or it should use the exact same syntax as in the SYNOPSIS section). I also think it's best to stick with the section names defined in man-pages(7) (that is, make SCREEN and KEYBOARD COMMANDS subsections of DESCRIPTION). - The license header in daisy-player.c doesn't say which version of the GPL applies (whereas debian/copyright says it's GPL-2+) and the FSF address is wrong (you can use the licensecheck utility to check the license headers). Also, what is copyright information about error.mp3 doing there? 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/20101210131322.ga4...@kenny.lan
Re: RFS: daisy-player
Hi Paul, Paul Gevers wrote: > Thanks for the review. And thanks for your work on this package. > [...] > > I will upload a new version, but as I understand it (please tell me if I > am wrong) upstream needs to fix his license header before I can do that > with any hope for uploading. I'd say yes, although in this case the file seems to have a valid free license and is distributable; still, I think it's best to clarify which version of the GPL applies and not make assumptions about that. > (For future fixes do you prefer to have the debian version incremented > or the initial -1?) Well I'm not a DD, so take my advice with a grain of salt, but my preference is to increase the debian version every time I make a new version of the package public; this way, it's always clear which version is being reviewed, and it avoids having different versions of a package with the same version number floating around. It makes even more sense if you're using git, because you don't want to move your tags when you make a new release; you should just create a new tag corresponding to a new version number. That being said, I don't think there is any rule forcing you to do that one way or the other, and I know some people prefer increasing the debian version only for versions entering the archive. 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/20101211144556.ga7...@kenny.lan
Re: RFS: gts (updated package)
Hi Ruben, Ruben Molina wrote: > I included Benoît's patch, and reuploaded my package to mentors: > http://mentors.debian.net/debian/pool/main/g/gts/gts_0.7.6+darcs101112-1.dsc You got the bug number wrong in debian/changelog :) It's actually #605493. 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/20101212211422.ga17...@debian.lan
Re: RFS: gts (updated package)
Ruben Molina wrote:
> El dom, 12-12-2010 a las 22:14 +0100, Benoît Knecht escribió:
> > > I included Benoît's patch, and reuploaded my package to mentors:
> > > http://mentors.debian.net/debian/pool/main/g/gts/gts_0.7.6+darcs101112-1.dsc
> >
> > You got the bug number wrong in debian/changelog :) It's actually
> > #605493.
>
> Thanks Benoît.
> Reuploaded.
I'm sorry, I hope it doesn't sound like I'm relentlessly trying to find
flaws in your uploads, but now you have two '#' instead of one:
"Closes: ##605493"
instead of
"Closes: #605493".
Don't worry, third time's a charm :)
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/20101212214643.gb17...@debian.lan
