Bug#711234: minidlna: New upstream (1.1.0) version available
Hi Rogério, Rogério Brito wrote: Can you update this? I see that your gitorious repository hasn't seen updates in almost 1 year. I've updated the gitorious repository with the latest work that I've done. I'm still waiting on upstream to confirm the copyright status of a few new files, and then I'll submit the package on mentors. In the meantime, if anyone wants to try out this new version, you can do git clone git://gitorious.org/debian-pkg/minidlna.git git checkout dfsg git checkout debian/1.1.0+dfsg git-buildpackage --git-upstream-branch=dfsg --git-debian-branch=debian/1.1.0+dfsg Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711234: Tried the git build. Error at install
Eric Valette wrote: /var/lib/dpkg/info/minidlna.postinst: ligne45: Erreur de syntaxe près du symbole inattendu « ;; » Right, thanks for testing. Should be fixed now. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 Harrissandyinch...@gmail.com * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 jmagg...@users.sourceforge.net * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671807: /bin/ln: misleading error messages
Michael Below wrote: ln has a misleading german error message when trying to create a link in a directory that is not accessible: ln -s /usr/lib/sflphone/plugins/libevladdrbook.so . ln: Symbolischen Verknüpfung „./libevladdrbook.so“ konnte angelgt werden: Keine Berechtigung It says something like symbolic link could be created: no permission which is obviously garbage, please insert the word nicht (=not) after konnte. Plus some minor typos: It should be Symbolische not Symbolischen and angelegt not angelgt. This has been fixed upstream in version 8.17. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620907: policycoreutils: fixfiles does not relabel contents of btrfs subvolumes
severity 620907 important
found 620907 2.1.10-9
thanks
John Pham wrote:
The fixfiles script seems unable to relabel anything in btrfs
subvolumes. This appears to be due to the contents of subvolumes not
counting as being on a filesystem of type 'btrfs', according to find
which is called by this script.
Actually, the problem seems to be in /sbin/setfiles.
I have a btrfs file system mounted on /, with subvolumes /home,
/home/user, /usr, /tmp, /var and /etc. The fixfiles script uses the
get_rw_labeled_mounts function to find out on which filesystems to act,
and on my system, that function returns:
/
/boot
/dev
/dev/pts
/run
/run/lock
/run/shm
/sys
So fixfiles proceeds to call
setfiles -q -p -F /etc/selinux/default/contexts/files/file_contexts /
which correctly sets the contexts in / and its subdirectories, except
for the subvolumes listed above (I tried re-running it by hand, and
indeed it doesn't work). Running setfiles on the subvolumes explicitly
does work though, i.e.
setfiles -q -p -F /etc/selinux/default/contexts/files/file_contexts /home
fixes the contexts in /home (but not /home/user, one needs to run
setfiles on it explicitly too).
So as far as this bug is concerned, I see two solutions:
- Either fix setfiles to recurse into btrfs subvolumes;
- Or modify fixfiles so that if a filesystem listed by
get_rw_labeled_mounts is btrfs-formated, it uses
btrfs subvolume list ${FS}
to find out the paths of the subvolumes and pass them to setfiles
explicitly.
Cheers,
--
Benoît Knecht
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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'd have to run ./unittest by hand. - 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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 match...@gmail.com and Nestal Wan m...@nestal.net * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
Stepan Golosunov wrote:
26.06.2012 в 00:59:50 +0200 Benoît Knecht написал:
Benoît Knecht wrote:
Stepan Golosunov wrote:
rtorrent 0.8.6-1 used to be crashing every several weeks for
me. (Though I do not actually remember whether there were
std::bad_alloc messages. I thought so but several recent crashes in
squeeze had basic_string::resize messages.)
After upgrading to wheezy rtorrent started to crash much more
often. Either immediately after start or about half an hour later,
often with the messed up *** glibc detected *** rtorrent: corrupted
double-linked list: 0x094c7a18 *** messages, requiring reset in the
terminal to get readable output from any subsequent command.
Running rtorrent under valgrind appears to prevent crashes.
After recompiling libtorrent 0.12.9-3 with DEB_BUILD_OPTIONS=nostrip
I get the following:
[...]
I've been running rtorrent/libtorrent 0.8.9/0.12.9 for months without
such problems, but I don't use DHT and you apparently do. So just to see
what might be the differences, could you please post your rtorrent.rc?
If you have anything unusual in there, maybe you could try and see if
the crash happens with a minimal rtorrent.rc too.
rtorrent 0.9.2 and libtorrent 0.13.2 are now in testing, could you give
them a try and report back here on the result? Also consider what I
mentioned above about rtorrent.rc.
rtorrent 0.9.2-1 crashed upon start several times when I tried it
couple of weeks ago. (Today it did not crash yet, but this seems to be
the usual behavior when I am trying to reproduce crash for the bug
report.)
By the way, changes like this in libtorrent's configure look
suspicious:
int main() {
-struct kevent ev[2], ev_out[2];
+struct kevent ev2, ev_out2;
struct timespec ts = { 0, 0 };
-int pfd[2], pty[2], kfd, n;
-char buffer[9001];
+int pfd2, pty2, kfd, n;
+char buffer9001;
if (pipe(pfd) == -1) return 1;
-if (fcntl(pfd[1], F_SETFL, O_NONBLOCK) == -1) return 2;
-while ((n = write(pfd[1], buffer, sizeof(buffer))) ==
sizeof(buffer));
-if ((pty[0]=posix_openpt(O_RDWR | O_NOCTTY)) == -1) return 3;
-if ((pty[1]=grantpt(pty[0])) == -1) return 4;
-EV_SET(ev+0, pfd[1], EVFILT_WRITE, EV_ADD | EV_ENABLE, 0, 0,
NULL);
-EV_SET(ev+1, pty[1], EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0,
NULL);
+if (fcntl(pfd1, F_SETFL, O_NONBLOCK) == -1) return 2;
+while ((n = write(pfd1, buffer, sizeof(buffer))) ==
sizeof(buffer));
+if ((pty0=posix_openpt(O_RDWR | O_NOCTTY)) == -1) return 3;
+if ((pty1=grantpt(pty0)) == -1) return 4;
+EV_SET(ev+0, pfd1, EVFILT_WRITE, EV_ADD | EV_ENABLE, 0, 0,
NULL);
+EV_SET(ev+1, pty1, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0,
NULL);
if ((kfd = kqueue()) == -1) return 5;
if ((n = kevent(kfd, ev, 2, NULL, 0, NULL)) == -1) return 6;
-if (ev_out[0].flags EV_ERROR) return 7;
-if (ev_out[1].flags EV_ERROR) return 8;
-read(pfd[0], buffer, sizeof(buffer));
+if (ev_out0.flags EV_ERROR) return 7;
+if (ev_out1.flags EV_ERROR) return 8;
+read(pfd0, buffer, sizeof(buffer));
+if ((n = kevent(kfd, NULL, 0, ev_out, 2, ts)) 1) return 9;
+return 0;
+ }
All brackets around array indexes are lost in c snippets.
This has been fixed upstream already, but I don't think it has anything
to do with this bug.
My .rtorrent.rc contains this:
bind = …
port_range = …-…
#port_range = …-…
check_hash = yes
directory = …
http_proxy =
encoding_list = utf-8
encryption = allow_incoming,try_outgoing
peer_exchange = yes
session = …
dht = auto
dht_port = …
There are usually several dozens of torrents from jamendo in the session
directory.
Thanks for the additional information. I'll try to reproduce this bug,
but I'll have to get DHT working first.
One more thing: Have you seen this bug happening if you only have a few
active torrents? How many are several dozens? Are they all active?
Cheers,
--
Benoît Knecht
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675713: rtorrent: does not recommend rtpg-www or rtgui
Hi, aafuentes wrote: the package does not remommend the rtpg-www or rtgui, guis for rtorrent found in the repositories Well, for sure they shouldn't be Recommended (installed by default). Maybe Suggested; I'll keep that in mind for the next release. Thanks for the report. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 pe.m...@free.fr * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 chneukirc...@gmail.com * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)
Hi Max, Max Power wrote: After uprading from rtorrent 0.8.9 (previous unstable version) rtorrent is not able to start again with the error message: rtorrent: symbol lookup error: rtorrent: undefined symbol: _ZN7torrent11thread_base8m_globalE I have no clue what this means or what I could do against it. Can you please post the output of ldd $(which rtorrent) and see if it lists libtorrent.so.14? It should point to /usr/lib/x86_64-linux-gnu/libtorrent.so.14, so can you check if it exists on your system and links to libtorrent.so.14.0.4 in the same directory (and that the latter is readable)? Also, do you have multiarch-support installed? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)
Max Power wrote:
Output from ldd $(which rtorrent)
linux-vdso.so.1 = (0x7fff54fe5000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f0fccb28000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5
(0x7f0fcc8ff000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f0fcc6f9000)
libcurl.so.4 = /usr/lib/x86_64-linux-gnu/libcurl.so.4
(0x7f0fcc48e000)
libtorrent.so.14 = /usr/local/lib/libtorrent.so.14
(0x7f0fcc1b2000)
libxmlrpc_server.so.3 = /usr/local/lib/libxmlrpc_server.so.3
(0x7f0fcbfab000)
libxmlrpc.so.3 = /usr/local/lib/libxmlrpc.so.3 (0x7f0fcbd94000)
libxmlrpc_util.so.3 = /usr/local/lib/libxmlrpc_util.so.3
(0x7f0fcbb9)
libxmlrpc_xmlparse.so.3 = /usr/local/lib/libxmlrpc_xmlparse.so.3
(0x7f0fcb983000)
libxmlrpc_xmltok.so.3 = /usr/local/lib/libxmlrpc_xmltok.so.3
(0x7f0fcb767000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f0fcb46)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f0fcb1dd000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f0fcafc7000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f0fcadab000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0fcaa23000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0fca81f000)
libidn.so.11 = /usr/lib/x86_64-linux-gnu/libidn.so.11
(0x7f0fca5eb000)
libssh2.so.1 = /usr/lib/x86_64-linux-gnu/libssh2.so.1
(0x7f0fca3c1000)
liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
(0x7f0fca1b2000)
libldap_r-2.4.so.2 = /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
(0x7f0fc9f62000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f0fc9d59000)
libgssapi_krb5.so.2 =
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x7f0fc98c8000)
libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7f0fc9501000)
librtmp.so.0 = /usr/lib/x86_64-linux-gnu/librtmp.so.0
(0x7f0fc92e7000)
libz.so.1 = /usr/lib/libz.so.1 (0x7f0fc90d)
libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26
(0x7f0fc8e0f000)
/lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11
(0x7f0fc8b91000)
libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2
(0x7f0fc897a000)
libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3
(0x7f0fc848d000)
libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
(0x7f0fc8263000)
libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2
(0x7f0fc805f000)
libkrb5support.so.0 =
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
libkeyutils.so.1 = /lib/libkeyutils.so.1 (0x7f0fc7c53000)
libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3
(0x7f0fc7a42000)
libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x7f0fc782f000)
libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x7f0fc762c000)
As you can see it points to /usr/local/lib/libtorrent.so.14 which point to
/usr/local/lib/libtorrent.so.14.0.1 in the same directory.
I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
/usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown reason
it's not linked correctly. Any idea on how to fix this?
Just try removing /usr/local/lib/libtorrent.so.14{,.0.1}, which I guess
you compiled and installed there yourself at some point.
Cheers,
--
Benoît Knecht
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)
Benoît Knecht wrote:
Max Power wrote:
Output from ldd $(which rtorrent)
linux-vdso.so.1 = (0x7fff54fe5000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f0fccb28000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5
(0x7f0fcc8ff000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f0fcc6f9000)
libcurl.so.4 = /usr/lib/x86_64-linux-gnu/libcurl.so.4
(0x7f0fcc48e000)
libtorrent.so.14 = /usr/local/lib/libtorrent.so.14
(0x7f0fcc1b2000)
libxmlrpc_server.so.3 = /usr/local/lib/libxmlrpc_server.so.3
(0x7f0fcbfab000)
libxmlrpc.so.3 = /usr/local/lib/libxmlrpc.so.3 (0x7f0fcbd94000)
libxmlrpc_util.so.3 = /usr/local/lib/libxmlrpc_util.so.3
(0x7f0fcbb9)
libxmlrpc_xmlparse.so.3 = /usr/local/lib/libxmlrpc_xmlparse.so.3
(0x7f0fcb983000)
libxmlrpc_xmltok.so.3 = /usr/local/lib/libxmlrpc_xmltok.so.3
(0x7f0fcb767000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f0fcb46)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f0fcb1dd000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f0fcafc7000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f0fcadab000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0fcaa23000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0fca81f000)
libidn.so.11 = /usr/lib/x86_64-linux-gnu/libidn.so.11
(0x7f0fca5eb000)
libssh2.so.1 = /usr/lib/x86_64-linux-gnu/libssh2.so.1
(0x7f0fca3c1000)
liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
(0x7f0fca1b2000)
libldap_r-2.4.so.2 = /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
(0x7f0fc9f62000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f0fc9d59000)
libgssapi_krb5.so.2 =
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x7f0fc98c8000)
libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7f0fc9501000)
librtmp.so.0 = /usr/lib/x86_64-linux-gnu/librtmp.so.0
(0x7f0fc92e7000)
libz.so.1 = /usr/lib/libz.so.1 (0x7f0fc90d)
libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26
(0x7f0fc8e0f000)
/lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11
(0x7f0fc8b91000)
libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2
(0x7f0fc897a000)
libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3
(0x7f0fc848d000)
libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
(0x7f0fc8263000)
libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2
(0x7f0fc805f000)
libkrb5support.so.0 =
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
libkeyutils.so.1 = /lib/libkeyutils.so.1 (0x7f0fc7c53000)
libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3
(0x7f0fc7a42000)
libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x7f0fc782f000)
libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x7f0fc762c000)
As you can see it points to /usr/local/lib/libtorrent.so.14 which point to
/usr/local/lib/libtorrent.so.14.0.1 in the same directory.
I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
/usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown reason
it's not linked correctly. Any idea on how to fix this?
Just try removing /usr/local/lib/libtorrent.so.14{,.0.1}, which I guess
you compiled and installed there yourself at some point.
Actually, you should remove all of the files listed in the output of ldd
that are in /usr/local/lib, as otherwise they will be used instead of
the versions shipped in Debian and eventually cause issues like this
one.
--
Benoît Knecht
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
Benoît Knecht wrote: Stepan Golosunov wrote: rtorrent 0.8.6-1 used to be crashing every several weeks for me. (Though I do not actually remember whether there were std::bad_alloc messages. I thought so but several recent crashes in squeeze had basic_string::resize messages.) After upgrading to wheezy rtorrent started to crash much more often. Either immediately after start or about half an hour later, often with the messed up *** glibc detected *** rtorrent: corrupted double-linked list: 0x094c7a18 *** messages, requiring reset in the terminal to get readable output from any subsequent command. Running rtorrent under valgrind appears to prevent crashes. After recompiling libtorrent 0.12.9-3 with DEB_BUILD_OPTIONS=nostrip I get the following: [...] I've been running rtorrent/libtorrent 0.8.9/0.12.9 for months without such problems, but I don't use DHT and you apparently do. So just to see what might be the differences, could you please post your rtorrent.rc? If you have anything unusual in there, maybe you could try and see if the crash happens with a minimal rtorrent.rc too. And if you have time, it would be great if you could test 0.9.2/0.13.2 from [1,2], or even straight from upstream's git repositories [3,4]. [1] git://git.debian.org/git/collab-maint/rtorrent.git [2] git://git.debian.org/git/collab-maint/libtorrent.git [3] git://github.com/rakshasa/rtorrent.git [4] git://github.com/rakshasa/libtorrent.git I can prepare and send you binary packages for 0.9.2/0.13.2 if you need me to. rtorrent 0.9.2 and libtorrent 0.13.2 are now in testing, could you give them a try and report back here on the result? Also consider what I mentioned above about rtorrent.rc. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675915: rtorrent: Does not proceed w/ slow torrents on resume (after suspend).
tag 675915 moreinfo thanks Hi Sthu, Sthu wrote: I'm using testing. On resume, after host has been suspended, rtorrent does not resume downloading of a slow torrent. Only when I press ^K, ^S - it continues downloading. What do you mean by slow torrent? Do some torrents resume downloading properly (without the need for ^K ^S)? Does rtorrent connect to a tracker successfully on those torrents? Are there peers listed on the slow torrents? How long do you wait before hitting ^K ^S? Is your network responsive on the host right after resume? Could you also try with 0.9.2-1? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675076: dd ignores SIGUSR1 to output statistics
tags 675076 unreproducible moreinfo severity 675076 minor thanks WozZa XiNg wrote: dd if=/dev/zero of=/dev/null kill -USR1 11683 So you're saying it doesn't output any statistics upon receiving SIGUSR1, right? Well, granted I'm running coreutils 8.13-3.2 (and not 8.13-3.1 as you do, but I don't see any relevant differences in the changelog), this works just as advertised for me: $ dd if=/dev/zero of=/dev/null pid=$! $ kill -USR1 $pid 7566780+0 records in 7566779+0 records out 3874190848 bytes (3.9 GB) copied, 3.28482 s, 1.2 GB/s So there's probably something else wrong with your system. Are you sure you're using dd from Debian's coreutils? debsum errors in your bug report suggest you may not have a clean install. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
Hi Stepan, Stepan Golosunov wrote: rtorrent 0.8.6-1 used to be crashing every several weeks for me. (Though I do not actually remember whether there were std::bad_alloc messages. I thought so but several recent crashes in squeeze had basic_string::resize messages.) After upgrading to wheezy rtorrent started to crash much more often. Either immediately after start or about half an hour later, often with the messed up *** glibc detected *** rtorrent: corrupted double-linked list: 0x094c7a18 *** messages, requiring reset in the terminal to get readable output from any subsequent command. Running rtorrent under valgrind appears to prevent crashes. After recompiling libtorrent 0.12.9-3 with DEB_BUILD_OPTIONS=nostrip I get the following: [...] I've been running rtorrent/libtorrent 0.8.9/0.12.9 for months without such problems, but I don't use DHT and you apparently do. So just to see what might be the differences, could you please post your rtorrent.rc? If you have anything unusual in there, maybe you could try and see if the crash happens with a minimal rtorrent.rc too. And if you have time, it would be great if you could test 0.9.2/0.13.2 from [1,2], or even straight from upstream's git repositories [3,4]. [1] git://git.debian.org/git/collab-maint/rtorrent.git [2] git://git.debian.org/git/collab-maint/libtorrent.git [3] git://github.com/rakshasa/rtorrent.git [4] git://github.com/rakshasa/libtorrent.git I can prepare and send you binary packages for 0.9.2/0.13.2 if you need me to. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671891: rtorrent: New upstream version (0.9.2/0.13.2) [package proposal]
So I've now pushed my changes to the alioth repositories; I hope everything is in order. I made a few further adjustments, one of which is that now the test suite is run at build time, which I think is a great improvement. I don't know why it didn't work before, I'm just glad it works now. If one of you could check that everything works on your system too, add me as an uploader, tag the final revision as debian/0.9.2-1 and build and upload the package, that would be great! Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671891: rtorrent: New upstream version (0.9.2/0.13.2) [package proposal]
Benoît Knecht wrote:
So I've now pushed my changes to the alioth repositories; I hope
everything is in order.
I made a few further adjustments, one of which is that now the test
suite is run at build time, which I think is a great improvement. I
don't know why it didn't work before, I'm just glad it works now.
If one of you could check that everything works on your system too, add
me as an uploader, tag the final revision as debian/0.9.2-1 and build
and upload the package, that would be great!
Oh and for completeness, here are the debdiffs:
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4
lrwxrwxrwx root/root /usr/lib/x86_64-linux-gnu/libtorrent.so.14 -
libtorrent.so.14.0.4
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/lib/libtorrent.so.14.0.1
lrwxrwxrwx root/root /usr/lib/libtorrent.so.14 - libtorrent.so.14.0.1
Control files: lines which differ (wdiff format)
Installed-Size: [-945-] {+1094+}
{+Multi-Arch: same+}
{+Pre-Depends: multiarch-support+}
Version: [-0.12.9-3-] {+0.13.2-1+}
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/include/torrent/data/download_data.h
-rw-r--r-- root/root /usr/include/torrent/download/group_entry.h
-rw-r--r-- root/root /usr/include/torrent/tracker_controller.h
-rw-r--r-- root/root /usr/include/torrent/utils/log.h
-rw-r--r-- root/root /usr/include/torrent/utils/log_buffer.h
-rw-r--r-- root/root /usr/include/torrent/utils/ranges.h
-rw-r--r-- root/root /usr/include/torrent/utils/signal_bitfield.h
-rw-r--r-- root/root /usr/include/torrent/utils/thread_base.h
-rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/pkgconfig/libtorrent.pc
lrwxrwxrwx root/root /usr/lib/x86_64-linux-gnu/libtorrent.so -
libtorrent.so.14.0.4
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/include/torrent/thread_base.h
-rw-r--r-- root/root /usr/lib/pkgconfig/libtorrent.pc
lrwxrwxrwx root/root /usr/lib/libtorrent.so - libtorrent.so.14.0.1
Control files: lines which differ (wdiff format)
Depends: libsigc++-2.0-dev, libtorrent14 (= [-0.12.9-3)-] {+0.13.2-1)+}
Version: [-0.12.9-3-] {+0.13.2-1+}
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: libc6 (= [-2.2.5),-] {+2.4),+} libcurl3 (= [-7.16.2-1),-]
{+7.16.3),+} libgcc1 (= 1:4.1.1), libncursesw5 (= 5.6+20070908),
libsigc++-2.0-0c2a (= 2.0.2), libstdc++6 (= 4.6), libtinfo5, libtorrent14,
libxmlrpc-core-c3
Installed-Size: [-1261-] {+1426+}
Version: [-0.8.9-2-] {+0.9.2-1+}
Bug#543357: libtorrent11: Cannot start a torrent backup, after stopping it.
severity 543357 normal tag 543357 unreproducible thanks Hi Michel, Michel Lavie wrote: After a recent update, libtorrent11 got upgraded(libtorrent11 0.12.4+tit-1 - 0.12.5-2). But after the upgrade, I cannot start a torrent backup with(Control-s) after stopping it with(Control-d). Even if I restart rtorrent the same thing happens. To start the torrent backup I need to remove the stopped torrent(Control-d) and re add it. I just tried reproducing this bug with libtorrent from testing (0.12.9-3), but it works fine for me. Can you try and see if you can still reproduce this bug with that version? Thanks. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672599: /bin/cp: wishlist: --progress needed
merge 672599 185152 thanks Ubuntu6226 wrote: CP is really amazing, and such as so greatly powerful, fast, reliable ... a switch --progress would be greatly awaited and helpful for all. Please check wget for a progress bar, reliable, if needed. Duplicate of #185152, #284514, #389326, #457983 and #566944. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 jimenezr...@gmail.com
* 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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671891: rtorrent: New upstream version (0.9.2/0.13.2) [package proposal]
Hi Rogério, Rogério Brito wrote: I'm in a hurry now and will reply properly latter, but I just wanted to send a quick note. On May 9, 2012, at 9:42 AM, Benoît Knecht wrote: So I now have access to the repositories on alioth (thanks to Rogério), and if no one objects, I will push the changes from gitorious to alioth in a day or so. If you think any changes are required before I go ahead with the merge, please let me know before then. Can you please change the branches before committing them to alioth? I would like to have something uniform to work with. Sure, I will only push upstream, pristine-tar and master, the other branches were just temporary. If you can't do that, then I think that I will spare 2 or 3 hours this weekend to work with libtorrent/rtorrent (well, since my git-fu is improving, I may not need all that time, but my computers are slow). If you'd like to review the changes more thouroughly before I commit anything, I can wait until this week-end for your ACK. But it shouldn't take hours; the structure is what git-buildpackage (with pristine-tar) would expect, and you can quickly see what I've changed by doing git log master..gitorious/master (assuming that master is in sync with the alioth repository, and that you've defined a remote called gitorious for my gitorious repository). Let me know if anything's unclear. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671891: rtorrent: New upstream version (0.9.2/0.13.2) [package proposal]
Benoît Knecht wrote: Rogério Brito wrote: On Mon, May 7, 2012 at 6:21 PM, Benoît Knecht benoit.kne...@fsfe.org wrote: [...] But at the time, I took a shot at packaging what was then the unstable version of rtorrent, and put the result on gitorious [1,2] (in a debian/0.9.0 branch for rtorrent, and a debian/0.13.0 branch for libtorrent). [1] git://gitorious.org/debian-pkg/rtorrent.git [2] git://gitorious.org/debian-pkg/libtorrent.git I am looking at your packaging of rtorrent right now and it is very good, with just one observation: to be more consistent with what has been done and also to be more consistent with what tools like git-buildpackage expect, it would be good we kept the following things: * the upstream source in the upstream branch (automatically done when you call git-import-orig). * the potential differences in a tarball taken from upstream and what is generated from the upstream branch in a branch called pristine-tar (automatically done when you call git-import-orig --pristine-tar). * the specific debian changes in the master branch of the repository. Then, debian/0.9.0-1 or someting would change from being branches to being tags (automatically done when you call git-buildpackage --git-pristine-tar --git-tag). Tags like upstream/0.9.0 will be automatically created by the previous calls to git-import-orig. Can you do those changes? If you don't, then I think that I can. I think that's pretty much what I did, except that I used a separate branch instead of master; I thought it would make things easier if, after review, you wanted to selectively merge changes on top of master (I should have explained that, sorry). But since you say the changes are okay, I've now merged debian/0.9.2 (respectively debian/0.13.2) into master, so that the packages can be built without specifying --git-debian-branch. The repositories should now be in a state where the upstream, pristine-tar and master branches can simply be pulled in the alioth repository. But please let me know if I missed anything. So I now have access to the repositories on alioth (thanks to Rogério), and if no one objects, I will push the changes from gitorious to alioth in a day or so. If you think any changes are required before I go ahead with the merge, please let me know before then. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 p...@ralfj.de 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 dre...@iem.uni-due.de * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671891: rtorrent: New upstream version (0.9.2/0.13.2) [package proposal]
Hi Rogério, Rogério Brito wrote: On Mon, May 7, 2012 at 6:21 PM, Benoît Knecht benoit.kne...@fsfe.org wrote: A few months ago, after I did some triaging on rtorrent's bugs, Rogério asked if I was interested in helping out with the package's maintenance. I said yes, but after that nothing really happened (I think a few mails were lost between him and me, and I haven't insisted since). First of all, I am very sorry to not have replied earlier. In the past 2 months I have barely slept, since my wife was in the end of her pregnancy (with all the troubles that this emcompasses) and now our son is sucking all of our time (including our time to sleep). No problem, and congratulations to you and your wife on your baby boy! Second, you should have insisted. :) I would have sent you an status update earlier. :) Yes, I know; I guess I got distracted with other stuff too... Well in the end, it looks like it will all work out. But at the time, I took a shot at packaging what was then the unstable version of rtorrent, and put the result on gitorious [1,2] (in a debian/0.9.0 branch for rtorrent, and a debian/0.13.0 branch for libtorrent). [1] git://gitorious.org/debian-pkg/rtorrent.git [2] git://gitorious.org/debian-pkg/libtorrent.git I am looking at your packaging of rtorrent right now and it is very good, with just one observation: to be more consistent with what has been done and also to be more consistent with what tools like git-buildpackage expect, it would be good we kept the following things: * the upstream source in the upstream branch (automatically done when you call git-import-orig). * the potential differences in a tarball taken from upstream and what is generated from the upstream branch in a branch called pristine-tar (automatically done when you call git-import-orig --pristine-tar). * the specific debian changes in the master branch of the repository. Then, debian/0.9.0-1 or someting would change from being branches to being tags (automatically done when you call git-buildpackage --git-pristine-tar --git-tag). Tags like upstream/0.9.0 will be automatically created by the previous calls to git-import-orig. Can you do those changes? If you don't, then I think that I can. I think that's pretty much what I did, except that I used a separate branch instead of master; I thought it would make things easier if, after review, you wanted to selectively merge changes on top of master (I should have explained that, sorry). But since you say the changes are okay, I've now merged debian/0.9.2 (respectively debian/0.13.2) into master, so that the packages can be built without specifying --git-debian-branch. The repositories should now be in a state where the upstream, pristine-tar and master branches can simply be pulled in the alioth repository. But please let me know if I missed anything. BTW, lintian is complaining about NMU version number, so don't forget to either add me as a maintainer or change the version number accordingly before uploading anything. Thanks again for your help and advice. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661858: ncmpcpp: New upstream version (0.5.10)
Hi, Any news on this bug? With 0.5.10 being out [1], the debian version is now quite a bit behind, and it would be great to get an up-to-date version in before the freeze. [1] http://unkart.ovh.org/ncmpcpp/ncmpcpp-0.5.10.tar.bz2 Incidentally, 0.5.10 also fixes RC bug #667294. As I said before, I'd be happy to help; I'm already maintaining a package in debian, so I'm not completely clueless. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670933: Ctrl-q do not quit program
tag 670933 unreproducible thanks Hi Juhapekka, Juhapekka Tolvanen wrote: man page says, that pressing Ctrl-q should quit this program. In reality, absolutely nothing happens, when I do so. I run rtorrent always under GNU Screen. Does it have any effect for this bug? I also run rtorrent in screen, but I never had this problem. Can you try running rtorrent outside of screen, hit Ctrl-q and see what happens? Maybe your screen configuration uses Ctrl-q for something, in which case Ctrl-a Ctrl-q might work in screen. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670712: rtorrent: Ratio loss
tag 670712 moreinfo thanks Hi, anonymous coward wrote: Sometimes rtorrent loses the ratio across restarts. Seems random. After a shutdown and restart, the ratio will be 0.0 on some torrents that had a higher ratio. This ratio reset does not impact all torrents at once -- the ratio is preserved for some torrents. Do you mean a shutdown and restart of the whole machine, or just rtorrent? How do you quit rtorrent? Can you check in your session directory that you have a .torrent, .rtorrent and .libtorrent_resume file for each torrent that should get restored, and that they're all readable by the user running rtorrent? Also, I guess the ratio is computed from the total_uploaded value in the .rtorrent files; can you check if it's missing or if it's set to 0 in the files corresponding to the torrents with a null ratio? Have you tried 0.8.9 from testing? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668807: the severity should be reduced
severity 668807 minor thanks Hi, marc.carter-ceqo...@cool.fr.nf wrote: After further investigation, the example usage does not conform to the latest (apparently newly changed) syntax. That is, a -- is now needed before addresses. So the correct command would be: mutt -a $HOME/.bashrc -s trying to send a file -- mym...@email.com simply sending a file and then it works. However, this is still a bug, because the error report is inaccurate and misleading. Mutt reports No recipients specified, when in fact there are recipients. Mutt should give accurate feedback, and say that the -- is missing. This is a minor issue, so the priority should probably be downgraded. I don't even think this is a bug at all. According to mutt(1): When attaching single or multiple files, separating filenames and recipient addresses with -- is mandatory, e.g. mutt -a image.jpg -- addr1 or mutt -a img.jpg *.png -- addr1 addr2. The -a option must be placed at the end of command line options. So the correct command line would be (in bash): mutt -s trying to send a file -a $HOME/.bashrc -- mym...@email.com simply sending a file The error message is as clear as can be; if you omit --, mutt considers mym...@email.com to be a filename, and then there's no recipient specified after that. As the syntax is properly documented, I think this bug should be closed; in the meantime, I'm lowering its severity to minor. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671891: rtorrent: New upstream version (0.9.2/0.13.2) [package proposal]
Source: rtorrent Severity: wishlist Hi, A few months ago, after I did some triaging on rtorrent's bugs, Rogério asked if I was interested in helping out with the package's maintenance. I said yes, but after that nothing really happened (I think a few mails were lost between him and me, and I haven't insisted since). But at the time, I took a shot at packaging what was then the unstable version of rtorrent, and put the result on gitorious [1,2] (in a debian/0.9.0 branch for rtorrent, and a debian/0.13.0 branch for libtorrent). [1] git://gitorious.org/debian-pkg/rtorrent.git [2] git://gitorious.org/debian-pkg/libtorrent.git Now that 0.9.2/0.13.2 is out and considered stable upstream, I've packaged it for unstable (essentially just imported the new upstream version on top of my 0.9.0/0.13.0 package) and put it on gitorious as well (branches debian/0.9.2 and debian/0.13.2). It compiles and runs fine on amd64 at least, and fixes the following bugs: * http://bugs.debian.org/667361 ftbfs with GCC-4.7 (apparently fixed upstream, no patch was required) * http://bugs.debian.org/649959 log.execute option doesn't work (fixed in 0.9.0 already) * http://bugs.debian.org/671582 Please enable hardening build flags (fixed by using debhelper compat 9) I'd be glad if someone could take a look and perhaps merge it on alioth and upload it. If everything's fine, please consider adding me as an uploader (I'm not a DM, so I'd still need someone to sponsor my uploads) and let me join collab-maint [3] (I need a DM or DD to send an email to n...@debian.org; my username is bknecht-guest). [3] http://lists.debian.org/debian-devel-announce/2012/01/msg6.html Thanks in advance. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665437: wishlist: editing the msg content (attached)
Hi, yelloprotoss wrote: I create an email to send with m then I type my emailto, subject, and message. using nano then I save the message content with this nano. OK now email is ready to be sent I just have to press y to make it sent ohhh... I just noticed that my message content with with some mistakes. I wanna modify it ... too bad. Mutt does not allow that or it is not display on the top of the screen (into status blue bar) how to edit it I cannot edit ... buuu I don't understand, I can edit a message about to being sent by pressing e; maybe you have different bindings, you can check by pressing ? right before you send you message and look for the edit-message command. Would you please add some more info on the top of hte screen to edit like with E if possible. Oh, so is your bug report about just adding more information into the top bar, or do you think there's some functionality missing? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663721: dovecot-antispam: [PATCH] antispam.7: Put the dspam backend config options in the correct subsection
Package: dovecot-antispam
Version: 2.0-2
Severity: minor
Tags: upstream, patch
Hi,
The antispam(7) man page contains an example configuration, with
subsections for backend-specific options. But part of the options for
the dspam backend somehow ended up in the crm114 section.
The patch below fixes that, as well as minor cut-and-paste typo in a comment.
Upstream may want to refresh the online version [1] as well.
[1] http://johannes.sipsolutions.net/files/antispam.html
Cheers,
--
Benoît Knecht
diff --git a/antispam.7 b/antispam.7
index 5e33e4c..6c9ff01 100644
--- a/antispam.7
+++ b/antispam.7
@@ -1,4 +1,4 @@
-.TH ANTISPAM 7 15 October 2007
+.TH ANTISPAM 7 13 March 2012
.SH NAME
antispam \- The dovecot antispam plugin.
@@ -206,6 +206,11 @@ plugin {
# semicolon-separated list of blacklisted results, case insensitive
# antispam_dspam_result_blacklist = Virus
+# semicolon-separated list of environment variables to set
+# (default unset i.e. none)
+# antispam_dspam_env =
+# antispam_dspam_env = HOME=%h;USER=%u
+
#=
# pipe plugin
#
@@ -247,7 +252,7 @@ plugin {
antispam_crm_binary = /bin/false
# antispam_crm_binary = /usr/share/crm114/mailreaver.crm
-# semicolon-separated list of extra arguments to dspam
+# semicolon-separated list of extra arguments to crm114
# (default unset i.e. none)
# antispam_crm_args =
# antispam_crm_args = --config=/path/to/config
@@ -257,11 +262,6 @@ plugin {
# antispam_crm_env =
# antispam_crm_env = HOME=%h;USER=%u
-# semicolon-separated list of environment variables to set
-# (default unset i.e. none)
-# antispam_dspam_env =
-# antispam_dspam_env = HOME=%h;USER=%u
-
# NOTE: you need to set the signature for this backend
antispam_signature = X-CRM114-CacheID
--
1.7.9.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663251: rm(1): Unnecessary escape before = in the manual
Hi Bjarni, Bjarni Ingi Gislason wrote: From groff: standard input:16: warning: escape character ignored before `=' standard input:25: warning: escape character ignored before `=' Patch: --- rm.1 2012-03-08 23:42:47.0 + +++ rm.1.new 2012-03-08 23:44:27.0 + @@ -13,7 +13,7 @@ [...] rm.1 is generated at build time by man/help2man from the output of 'rm --help' and the contents of man/rm.x (all paths relative to the topmost directory in the coreutils tarball). Can you resend a patch against man/rm.x instead? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663131: New upstream version (0.1.0)
Benoît Knecht wrote: zathura 0.1.0 has been released a few weeks ago [1][2]. It would be great if you could package it. [...] [1] http://pwmt.org/projects/zathura/download/ [2] http://pwmt.org/projects/zathura/download/zathura-0.1.0.tar.gz I see that libgirara, a new dependency of zathura, is already in experimental; note that zathura-pdf-poppler [3] will also need to be package in order for zathura to do anything useful. Should I open an RFP bug, or are you already on it? [3] http://pwmt.org/projects/zathura/download/zathura-pdf-poppler-0.1.0.tar.gz Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663131: New upstream version (0.1.0)
Jakub Wilk wrote: * Benoît Knecht benoit.kne...@fsfe.org, 2012-03-08, 21:22: zathura 0.1.0 has been released a few weeks ago [1][2]. It would be great if you could package it. [...] [1] http://pwmt.org/projects/zathura/download/ [2] http://pwmt.org/projects/zathura/download/zathura-0.1.0.tar.gz I see that libgirara, a new dependency of zathura, is already in experimental; note that zathura-pdf-poppler [3] will also need to be package in order for zathura to do anything useful. Should I open an RFP bug, or are you already on it? We're going to build zathura and zathura-pdf-poppler from the same source package. No need to file RFP. Okay, great! Looking forward to trying out this new version... Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663131: New upstream version (0.1.0)
Source: zathura Severity: wishlist Hi, zathura 0.1.0 has been released a few weeks ago [1][2]. It would be great if you could package it. Here's the upstream changelog: zathura-0.1.0 (2012/02/21): * Complete rewrite of zathura * Uses the girara interface library * Plugin system for different document types * Better configuration * Quickmarks * and much more [1] http://pwmt.org/projects/zathura/download/ [2] http://pwmt.org/projects/zathura/download/zathura-0.1.0.tar.gz Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 fro...@fi.upm.es * 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 vibh...@gmail.com 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 fro...@fi.upm.es * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662632: RFS: libaio-ocaml/1.0~rc1
Goswin von Brederlow wrote: Benoît Knecht benoit.kne...@fsfe.org 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 jon.hu...@gmail.com 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572367: rtorrent: Unsnubbing doesn't seem to work
forwarded 572367 https://github.com/rakshasa/rtorrent/issues/37 thanks sacrificial-spam-addr...@horizon.com wrote: Could you please try version 0.8.9 in wheezy and see if this bug is still present? As of Version: 0.8.9-2 with libtorrent14 Version: 0.12.9-3 it's still there. (I'm running sid rather than wheezy; I figure for this purpose that's not a problem.) 4 peers, each receiving 20 k/s, were snubbed for a second, then immediately unsnubbed, and their rates have gone to 0 and stayed there. If I kick them off, they reconnect and start transferring again. Thanks a lot for checking this. I've forwarded it upstream, let's see what they say. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635700: rtorrent: Could not open/bind port for listening: Address family not supported by protocol
tags 635700 moreinfo thanks Hi Nikita, Nikita A Menkovich wrote: $ rtorrent rtorrent: Could not open/bind port for listening: Address family not supported by protocol [...] I don't see this issue with rtorrent 0.8.9-2 on a 3.1.0-1 kernel, with IPv6 enabled and configured on my network. Could you try and see if you can reproduce the issue with rtorrent 0.8.9? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572367: rtorrent: Unsnubbing doesn't seem to work
Benoît Knecht wrote: sacrificial-spam-addr...@horizon.com wrote: Could you please try version 0.8.9 in wheezy and see if this bug is still present? As of Version: 0.8.9-2 with libtorrent14 Version: 0.12.9-3 it's still there. (I'm running sid rather than wheezy; I figure for this purpose that's not a problem.) 4 peers, each receiving 20 k/s, were snubbed for a second, then immediately unsnubbed, and their rates have gone to 0 and stayed there. If I kick them off, they reconnect and start transferring again. Thanks a lot for checking this. I've forwarded it upstream, let's see what they say. In case you're not following the upstream ticket: Would you be able to build libtorrent [1] and rtorrent [2] from source, in their latest revision from github, and see if the issue is still there? [1] git://github.com/rakshasa/libtorrent.git [2] git://github.com/rakshasa/rtorrent.git Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647140: rtorrent: Please provide a way to load a config file from different locations
Hi Florian, Florian Ragwitz wrote: By default, rtorrent either loads its configuration file from ~/.rtorrent.rc, or doesn't load it at all in the presence of the -n switch. I tend to have more than one rtorrent instance running for the same user, all of which might need different configuration options. Specifying all options for one instance using -o and -O tends to be complicated, especially with big-ish configurations. I'd love having a way to have multiple separate configuration files I can use for the individual rtorrent instances, be it through a command-line switch that allows specifying a config file path, or a config key that causes a config file to be loaded from a path specified as its value. $ rtorrent -c ~/.rtorrent.rc.foo $ rtorrent -o load_config=~/.rtorrent.rc.foo I think what you're suggesting exists already. The config key is 'import' or 'try_import' (the former failing on invalid input, while the latter doesn't). If you don't want the default configuration file to be read, you need to use '-n' too, otherwise rtorrent will read both: $ rtorrent -n -o import=~/.rtorrent.rc.foo Can you try it and see if it really does what you think it should? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572367: rtorrent: Unsnubbing doesn't seem to work
sacrificial-spam-addr...@horizon.com wrote: In case you're not following the upstream ticket: I'm not; I don't even know where their bug tracker is. Oh sorry, the link was in a previous mail; here it is again, if you're interested: https://github.com/rakshasa/rtorrent/issues/37 Would you be able to build libtorrent [1] and rtorrent [2] from source, in their latest revision from github, and see if the issue is still there? Done. Exact git commits are libtorrent ff60f659e3270b995c1df7cec991aec43b62b29f rtorrent d25c4b25aec09d19ae10941f7e22b97b00a94bfc I've only let the connection sit choked for 5 minutes or so, but here: IP UP DOWN PEER CT/RE/LO QSDONE REQ SNUB FAILED * 78.180.99.43 0.00.075.1 r /cn/ci 0/016 uTorrent 3.0.0.0 203.161.79.192 0.00.0163.8 r /Cn/cn 0/0 100 uTorrent 1.8.5.0 24.142.56.27 0.00.0163.8 r /Cn/cn 0/0 100 uTorrent 1.8.5.0 68.60.53.4 0.00.0163.8 r /Cn/cn 0/0 100 uTorrent 1.8.5.0 95.34.190.1850.00.0163.8 r /Cn/cn 0/0 100 uTorrent 3.1.2.0 68.231.118.970.00.0163.8 r /cn/ci 0/0 100 uTorrent 3.0.0.0 14.201.139.177 0.00.0163.8 r /Cn/cn 0/0 100 uTorrent 3.0.0.0 71.127.1.172 0.00.00.0R /Cn/cn 0/098 uTorrent 3.1.2.0 80.202.31.1470.00.00.0R /Cn/cn 0/0 100 uTorrent 2.2.0.0 109.224.133.220 0.00.0163.8 r /Cn/cn 0/0 100 uTorrent 3.1.2.0 68.114.141.450.00.0163.8 r /Cn/cn 0/0 100 uTorrent 1.8.2.0 That first peer was receiving data at a good clip before I briefly choked it with *. If I kick, it'll reconnect in a few seconds and start downloading... * 78.180.99.43 11.8 0.068.3 r /ci/ui 13/0 16 uTorrent 3.0.0.0 Wow, that was fast! Thanks again for your great feedback, I'll let upstream know. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483677: rtorrent: Incomplete and outdated documentation
retitle 483677 rtorrent: Incomplete and outdated documentation thanks The documentation of rtorrent is quite outdated. The manual page has not been updated in almost 3 years, and even then it was far from covering all the aspects of rtorrent. Since we have quite a bit of individual reports that boil down to documentation issues, I will use this bug to track them. What we'll need in the end is rtorrent(1) and rtorrent.rc(5) man pages, and a good example configuration file. Upstream knows about the problem [1] but lacks the time to tackle the issue themselves, so any help is more than welcome. [1] https://github.com/rakshasa/rtorrent/issues/24 Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 goswin-...@web.de * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618275: rtorrent: DHT error: Address not af_inet
tag 618275 moreinfo thanks Hi Thorsten, Rogério Brito wrote: On Apr 24 2011, Thorsten Glaser wrote: Sorry, I still get the error on a machine with both IPv4 and IPv6. “l” (Log) shows: (20:11:05) DHT error: Address not af_inet Can you provide any further details? Are you using any BSD? What architecture? Under what conditions do you see the error? Any other comments? You reopened this bug almost a year ago; now that 0.8.9 is in testing, could you try it and see if the bug still occurs? If so, please provide the details Rogério asked for. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611337: rtorrent: Crashes on ready torrents removal, randomly.
Sthu Deus wrote: Benoît Knecht wrote: Sthu Deus wrote: rtorrent crashes with Randomly rtorrent: DownloadList::confirm_finished(...) download-resume_flags() != ~uint32_t(). Package: rtorrent randomly, - I believe on ready torrents removal with ^d ^d. I can't reproduce this issue on rtorrent/0.8.9-2; can you try that version and see if it also fails for you (it's in wheezy)? I do not use it much now-days, but use still. For now (in wheezy) it did not crash as yet. If it ever will - I'll make it known. How long have you been running 0.8.9 without a crash? (Trying to figure out if I can close this bug or if you just started testing it.) Thanks for your feedback. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572367: rtorrent: Unsnubbing doesn't seem to work
tags 572367 moreinfo thanks Hi, sacrificial-spam-addr...@horizon.com wrote: Toggling peer snubbing off with * seems to leave that peer permanently choked, even when it wakes up and starts feeding me data. The only way I can find to bring the connection back to life is to kick off the peer and let it reconnect. Could you please try version 0.8.9 in wheezy and see if this bug is still present? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 johan.ma...@tremplin-utc.net * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497001: rtorrent ignores urls starting with Http
Marc Lehmann wrote: [...] It shouldn't be that 13 years after it has been superseded you still quote from that rfc, especially not to ignore valid bug reports. You are wasting mine and your time with this that could have been used to improve debian. Right. I promise I won't waste my time with this anymore. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649959: rtorrent: log.execute option doesn't work
tags 649959 fixed-upstream thanks This bug has been fixed upstream in version 0.9.0, which was released in December 2011. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
tags 599913 moreinfo thanks Hi, I never had this problem with rtorrent, but it sure sounds like an out-of-memory issue. Submitter, does this also happen with 0.8.9 (in wheezy)? How much RAM does your system have? And how much of it is used by rtorrent? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619207: rtorrent: enable_trackers=no/yes does not work in new version
severity 619207 minor thanks Jellal Hernandez wrote: Latest upgrade deleted important commands from rtorrent command mode! C-X enable_trackers=yes / C-X enable_trackers=no result in following error message: Command enable_trackers does not exist This prevents user from turning off/on trackers globally which is very useful if user only wants to connect to a few trackers because other trackers are slow/return errors/or time out. Please restore deleted convenience feature. Since this is a documentation bug, I'm downgrading its severity to 'minor'. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611337: rtorrent: Crashes on ready torrents removal, randomly.
tag 611337 unreproducible thanks Hi Sthu, Sthu Deus wrote: rtorrent crashes with Randomly rtorrent: DownloadList::confirm_finished(...) download-resume_flags() != ~uint32_t(). Package: rtorrent randomly, - I believe on ready torrents removal with ^d ^d. I can't reproduce this issue on rtorrent/0.8.9-2; can you try that version and see if it also fails for you (it's in wheezy)? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531299: rtorrent: Doesn't accept self-signed certificates
fixed 531299 0.8.9-1 thanks Starting with rtorrent/0.8.9-1, you can use 'network.http.ssl_verify_peer.set=0' to prevent rtorrent from verifying certificates. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497001: rtorrent ignores urls starting with Http
severity 497001 minor thanks Marc Lehmann wrote: rtorrent ignores tracker urls starting with Http even thought it supports the http protocol. editing the torrent into a lowercase http makes it detect the tracker. background: uri scheme names are case insensitive, and worse, actual torrent files do contain tracker urls with mixed and upper case scheme parts (i don't know if bittorrent meta files have additional specificaitons that force scheme names to lowercase, but I doubt it). Well, that's not entirely accurate. According to RFC 1738 [1], section 2.1: Scheme names consist of a sequence of characters. The lower case letters a--z, digits, and the characters plus (+), period (.), and hyphen (-) are allowed. So torrent files using Http are actually invalid (and I've never encountered one of these). The same section goes on like this, though: For resiliency, programs interpreting URLs should treat upper case letters as equivalent to lower case in scheme names (e.g., allow HTTP as well as http). but that's a should, not a must. So I'm downgrading the severity to minor, and I'd suggest the maintainer closes it as wontfix. [1] http://www.ietf.org/rfc/rfc1738.txt Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620328: on_finished config option no longer recognized
severity 620328 minor thanks That's a documentation issue, so I'm downgrading it to minor. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645061: rtorrent: Kernel panic on high traffic
tags 645061 moreinfo thanks Hi Andrei, Andrei Popescu wrote: [...] Now i compiled xmlrpc-c, libtorrent, rtorrent from source I used xmlrpc-c latest SVN trunk, libtorrent-0.12.9, rtorrent-0.8.9. With those after a system reboot and limiting rtorrent's memory usage to 400MB, the server is running fine for about 4 hours Now that 0.8.9 is in testing, have you tried it? Does that version work for you, or only your custom build? -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628567: rtorrent: no rtorrentrc example file
severity 628567 minor thanks Thorsten Glaser wrote: There is no rtorrent.rc example file any more. This is important as it’s used as basis for customisation, and contains option lists and settings possible. That's purely a documentation issue, and doesn't affect rtorrent's behavior in Debian (it certainly doesn't break anything), so I'm downgrading it to minor. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515273: rtorrent: Read past initial payload after incoming encrypted handshake
tags 515273 moreinfo unreproducible thanks Kurt Roeckx wrote: I've just had rtorrent quit on me 2 times with the following message: rtorrent: Read past initial payload after incoming encrypted handshake I had this in my .rtorrentrc: encryption=allow_incoming,enable_retry I'm running rtorrent/0.8.9-2 with encryption enabled, and never had this issue. Has anyone been able to reproduce it on a recent version of rtorrent? -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515273: rtorrent: Read past initial payload after incoming encrypted handshake
Kurt Roeckx wrote: On Fri, Mar 02, 2012 at 04:14:10PM +0100, Benoît Knecht wrote: tags 515273 moreinfo unreproducible thanks Kurt Roeckx wrote: I've just had rtorrent quit on me 2 times with the following message: rtorrent: Read past initial payload after incoming encrypted handshake I had this in my .rtorrentrc: encryption=allow_incoming,enable_retry I'm running rtorrent/0.8.9-2 with encryption enabled, and never had this issue. Has anyone been able to reproduce it on a recent version of rtorrent? I still have the same thing in my config file, and I haven't seen this in ages. Which version of rtorrent are you running now, if I may ask? -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 benoit.kne...@fsfe.org 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 benoit.kne...@fsfe.org 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661858: ncmpcpp: New upstream version (0.5.8)
Source: ncmpcpp Version: 0.5.6-2 Severity: wishlist Dear Maintainer, Please consider packaging ncmpcpp 0.5.8 [1], which was released in October 2011. Let me know if you need any help, in case you're too busy right now. [1] http://unkart.ovh.org/ncmpcpp/ncmpcpp-0.5.8.tar.bz2 Thanks in advance. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661259: minidlna: Please package 1.0.24
tag 661259 pending thanks Hi Eric, Eric Valette wrote: I know 1.0.23 is on its way but 1.0.24 is now out. I've packaged it already; it was actually on mentors [1] when 1.0.23+dfsg-1 got uploaded, but due to some negligence on my part, my sponsor didn't see it. [1] http://mentors.debian.net/package/minidlna Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 je...@jezra.net * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
Jakub Wilk wrote: * Benoît Knecht benoit.kne...@fsfe.org, 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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/package.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653221: Does not find files after media_dir configuration change
tag 653221 pending thanks David Mohr wrote: On Tue, 14 Feb 2012 16:40:30 +0100, Benoît Knecht wrote: David Mohr wrote: I also encountered this bug. At the very least, this should be mentioned in a README.Debian. This behavior is documented in minidlna.conf(5). IMHO, and this may not be completely according to the manual, README.Debian should make the users live easier. Sure it's in the man page, but wouldn't it be worth the small effort to make it easily accessible if that saves the average user some time? OK, so I've added a comment in the default minidlna.conf, warning users that changing media_dir should be followed by a complete rebuild of the database. Now they'd have to try pretty hard not to see this piece of information... Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 euroeles...@yandex.ru * 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/package.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 jmagg...@users.sourceforge.net * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659822: RFS: mpd-sima/0.9.0-1 (New upstream version)
Hi Jakub,
Jakub Wilk wrote:
* Geoffroy Youri Berret ef...@azylum.org, 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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 jmagg...@users.sourceforge.net
* 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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 g...@gerd-neugebauer.de * 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
