Re: RFS: bindfs (bugfix upload, pre-approved by release team)
On Sunday 31 August 2008 08:30:03 Eugene V. Lyubimkin wrote: > Hi -mentors! > > I am looking for a uploader for the new version 1.8-1 > of my package "bindfs". > > My usual sponsor for this package, Kapil Hari Paranjape, seems to be busy > now. I want for pre-approved by release team upload of new version 1.8-1 of > package to reach testing ASAP, so I am seeking for uploader. > > It builds these binary packages: > bindfs - mirrors or overlays a local directory with altered permissions Okay, I found the release team reaction along with the diff. Could you please remove quilt from build-depends since it is unneeded, and I will sponsor. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 08:24:13 Eugene V. Lyubimkin wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.01-3 > of my package "exiftags". My previous sponsor, Anibal Monsalve Salazar, > seems to be busy for more than week, so I am seeking for uploader or new > usual sponsor for this package. Ok, thanks for fixing an RC. Builds fine per autobuilders (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules binary (as per policy), probalby because of missing binary-arch and binary-indep targets ? Try to fix it, or I'll have a look more closer look tonight... of course sponsors with more time are welcome to beat me on that line ;-) -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bindfs (bugfix upload, pre-approved by release team)
George Danchev wrote: > On Sunday 31 August 2008 08:30:03 Eugene V. Lyubimkin wrote: >> Hi -mentors! >> >> I am looking for a uploader for the new version 1.8-1 >> of my package "bindfs". >> >> My usual sponsor for this package, Kapil Hari Paranjape, seems to be busy >> now. I want for pre-approved by release team upload of new version 1.8-1 of >> package to reach testing ASAP, so I am seeking for uploader. >> >> It builds these binary packages: >> bindfs - mirrors or overlays a local directory with altered permissions > > Okay, I found the release team reaction along with the diff. Could you please > remove quilt from build-depends since it is unneeded, and I will sponsor. > This change is safe for me, but for release team? This change will also lead to change debian/rules not to use 'patch' and 'unpatch' targets. -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: RFS: exiftags (updated package)
George Danchev wrote: > On Sunday 31 August 2008 08:24:13 Eugene V. Lyubimkin wrote: >> Dear mentors, >> >> I am looking for a sponsor for the new version 1.01-3 >> of my package "exiftags". My previous sponsor, Anibal Monsalve Salazar, >> seems to be busy for more than week, so I am seeking for uploader or new >> usual sponsor for this package. > > Ok, thanks for fixing an RC. Builds fine per autobuilders > (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules binary > (as per policy), probalby because of missing binary-arch and binary-indep > targets ? Try to fix it, or I'll have a look more closer look tonight... of > course sponsors with more time are welcome to beat me on that line ;-) > Builds fine in my pbuilder. binary-arch and binary-indep are defined by debhelper v7. -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: RFS: freeguide (updated package)
OoO Lors de la soirée naissante du lundi 28 juillet 2008, vers 17:10, Daniel Watkins <[EMAIL PROTECTED]> disait : > I am looking for a sponsor for the new version 0.10.7-1 > of my package "freeguide". This upload will see me take over > maintainership of freeguide (#441947). It is the first step towards > moving freeguide into main, now that OpenJDK is available. Hi Daniel! I think that you should Build-Depends-Indep on openjdk-6-jdk | java2-sdk instead of just java2-sdk which is a virtual package. What is missing to move to main? There are some files that are modified outside of debian/ directory. You should consider using a patch management system to track those changes. Seems fine otherwise. Maybe you will package the new upstream release? There is lintian warning: I: freeguide: desktop-entry-contains-encoding-key /usr/share/applications/freeguide.desktop:5 Encoding -- /* After several hours of tedious analysis, the following hash * function won. Do not mess with it... -DaveM */ 2.2.16 /usr/src/linux/fs/buffer.c pgpaySt6XaLbl.pgp Description: PGP signature
Re: RFS: sitebar (updated package)
OoO En ce début de soirée du mardi 29 juillet 2008, vers 21:12, Carlos
Eduardo Sotelo Pinto <[EMAIL PROTECTED]> disait :
> - dget
> http://mentors.debian.net/debian/pool/main/s/sitebar/sitebar_3.3.9-1.1.dsc
It seems that you removed the package from mentors.
--
panic("Lucy in the sky");
2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c
pgpQZxADP160R.pgp
Description: PGP signature
Re: RFS: atmailopen (2nd attempt - updated description)
OoO En cette soirée bien amorcée du jeudi 28 août 2008, vers 22:29, Giuseppe Iuculano <[EMAIL PROTECTED]> disait : >> Somefiles haveadifferent license.Forexample, >> libs/Atmail/spellChecker.php. The license given as URL is non-free. You >> will need to work with upstream to sort this out. Check all files >> individually. The license which is in the headers is more important than >> the one in LICENSE file. > Upstream fixes this issue in SVN, so I repackaged Atmail svn > revision(48) I don't remember if those files were here on last upload, but there are a lot of files with non DFSG-free licenses: ./libs/PEAR/Mail/smtp.php: PHP (v2.02) ./libs/PEAR/DB.php: PHP (v3.0) ./libs/PEAR/Net/SMTP.php: PHP (v2.02) ./libs/PEAR/Net/Socket.php: PHP (v2.0) ./libs/PEAR/DB/mysqli.php: PHP (v3.0) ./libs/PEAR/DB/common.php: PHP (v3.0) ./libs/PEAR/DB/mssql.php: PHP (v3.0) ./libs/PEAR/DB/sqlite.php: PHP (v3.0) ./libs/PEAR/DB/mysql.php: PHP (v3.0) ./libs/PEAR/Mail.php: PHP (v2.02) ./libs/PEAR/PEAR.php: PHP (v3.0) Moreover, there are a lot of files which are released with a license different of Apache 2.0 license. Even if those are free licenses and even if you don't ship any of those files in the Debian package, you should cite them in debian/copyright. You can also just exclude all those files from orig.tar.gz. In this case, put "dfsg" somewhere in the version string (1.02+svn48.dfsg-1) for example. And you should add a note in README.source on how to get the source package from SVN (and, better, add an appropriate target in debian/rules like get-orig-source). >> You introduce a debconf templates. I see that you already have some >> translations. However, I don't find your call for translations. Until >> lenny is released, this is better to ask for translations before >> releasing new debconf templates: >> http://www.perrier.eu.org/weblog/2008/07/15#anti-l10n-cabal > Lenny is frozen, and atmailopen is not yet in Debian, should I run > podebconf-report-po ? I think that you can. Those templates are unlikely to change until the upload is ready. Other remarks: * php5 depends on php5-cgi (as an alternative), so you can just depend on php5. * "$popimap_debug_file='/tmp/popimap_debug'" can lead to symlink attacks. Use something in /var/log/atmailopen. If this is enabled by default, don't forget to add a rule in logrotate. * the binary-arch seems to be missing in debian/rules Seems fine otherwise. -- /* James M doesn't say fuck enough. */ 2.4.3 linux/net/core/netfilter.c pgpQrEihywkNl.pgp Description: PGP signature
RFS: wmaker-data (updated package)
Dear mentors, My usual sponser said me that he's very busy actually. I am looking for a sponsor for the new version 0.9~3-3 of my package "wmaker-data". Please note that last version in archive is 0.9~2-2 and take it in account when reading changelog. Since I've moved to 3.0 (quilt) format, please review it very carefully. It builds these binary packages: wmaker-data - several free icons for use with WindowMaker and others The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/w/wmaker-data - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/w/wmaker-data/wmaker-data_0.9~3-3.dsc I would be glad if someone uploaded this package for me. Kind regards Noel David Torres Taño signature.asc Description: This is a digitally signed message part.
Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 10:00:44 Eugene V. Lyubimkin wrote: > George Danchev wrote: > > On Sunday 31 August 2008 08:24:13 Eugene V. Lyubimkin wrote: > >> Dear mentors, > >> > >> I am looking for a sponsor for the new version 1.01-3 > >> of my package "exiftags". My previous sponsor, Anibal Monsalve Salazar, > >> seems to be busy for more than week, so I am seeking for uploader or new > >> usual sponsor for this package. > > > > Ok, thanks for fixing an RC. Builds fine per autobuilders > > (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules > > binary (as per policy), probalby because of missing binary-arch and > > binary-indep targets ? Try to fix it, or I'll have a look more closer > > look tonight... of course sponsors with more time are welcome to beat me > > on that line ;-) > > Builds fine in my pbuilder. binary-arch and binary-indep are defined by > debhelper v7. Eugene, this is not enough, your `binary-arch' should build a binary package to a given architecture, but it fails because it does not depend on `build' target (where policy 4.9. says it should), thus `patch' target was also not being called as well. To fix that you should add: binary-arch: build install -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vbackup
Hello again, I'm replying to a message that wasn't originally sent to me (right?) so excuse the threading problem. I've seen the message using google groups while attempting to submit a new RFS for the latest version. I've uploaded the final 0.1.6 version of vbackup to mentors.debian.net (along with my page and freshmeat) so it is time to send an RFS (but I'm not sending a new one). I'm replying to the "old" thread available here: http://groups.google.com/group/linux.debian.devel.mentors/browse_frm/thread/32d30bff736b5819/e8addbd84213ce91?#e8addbd84213ce91 > OoO En ce début d'après-midi ensoleillé du samedi 26 juillet 2008, vers > > 15:59, Stefanos Harhalakis <[EMAIL PROTECTED]> disait : > > I am looking for a sponsor for my package "vbackup". > > > > * Package name: vbackup > > Version : 0.1.6pre1-1 > > Upstream Author : Stefanos Harhalakis (me) > > * URL : http://www.it.teithe.gr/~v13/ > > * License : GPLv3 > > Section : admin > > It builds these (not-so-)binary packages: > > vbackup - A modular backup utility > > Hi Stefanos! > > Your GPG key is signed by nobody. You should try to get some people > (preferably related to Debian) to sign your key. Indeed but that is (was?) a really low-priority issue, so I haven't done anything for it yet. Is there > Put the manual page in the debian/ directory. This ensures that all > modifications for Debian are constrained into this directory. And use > dh_installman to install it. This avoids to modify Makefile.am and > Makefile.in. I've extended and included the man page in the original source code so there is no need to have a debian specific one any more. > Your Depends line in debian/control is empty. Are you sure you don't > need any non essential package? From the description, I suppose that you > need something to do MySQL and PostgreSQL database. Well, that's something that I can't answer. vbackup uses xfsdump, mdadm, lvm2, postgresql-common, mysql-common etc but doesn't actually require any of them. One can have xfsdump only while another one can have postgresql-common only. I've included them as Suggests. Is this correct? Appart from those, to my knowledge, vbackup doesn't need anything non-essential. > It seems that debian/watch is not able to catch the latest version. That happened because it wasn't actually uploaded (SVN server was down). It should be OK right now. > debian/copyright says GPLv2 while COPYING says GPLv3. Most files say > GPLv2, so debian/copyright seems to be correct. Thanks for the bug report :-). My intention is to make everything available under GPLv3. I don't find this to be an urgent issue so I'll keep it for the next version. In the mean time I believe that it is acceptable to have parts of vbackup available as GPLv2. After all this is a modular backup program where every module-script can have its own license. > You should also correct those lintian warnings: > I: vbackup: hyphen-used-as-minus-sign usr/share/man/man8/vbackup.8.gz:32 > W: vbackup: doc-base-unknown-section vbackup:6 admin I believe that they are fixed since "lintian -I" doesn't produce any errors/warnings/infos and mentors.debian.net says the same thing. > Maybe you should ship a minimal configuration like saving /etc and dpkg > database. Usualy, it is better to have a package that is directly > usable. But it is up to you to see if this is revelant here. In the 0.1.6 version I've added a configuration wizard which can create a working basic configuration. This is now the recommended way to start using vbackup and it also mentioned as such in the README and the man page. p.s: please CC any replies to me too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bindfs (bugfix upload, pre-approved by release team)
On Sunday 31 August 2008 09:49:05 Eugene V. Lyubimkin wrote: > George Danchev wrote: > > On Sunday 31 August 2008 08:30:03 Eugene V. Lyubimkin wrote: > >> Hi -mentors! > >> > >> I am looking for a uploader for the new version 1.8-1 > >> of my package "bindfs". > >> > >> My usual sponsor for this package, Kapil Hari Paranjape, seems to be > >> busy now. I want for pre-approved by release team upload of new version > >> 1.8-1 of package to reach testing ASAP, so I am seeking for uploader. > >> > >> It builds these binary packages: > >> bindfs - mirrors or overlays a local directory with altered > >> permissions > > > > Okay, I found the release team reaction along with the diff. Could you > > please remove quilt from build-depends since it is unneeded, and I will > > sponsor. > > This change is safe for me, but for release team? This change will also > lead to change debian/rules not to use 'patch' and 'unpatch' targets. Yes, it is safe; quilt has no business here as a build-dependency wasting autobuilders and other builders time to install and deinstall. Worst, that might leave a worrisome impression to the reader of any patches not being applied by accident. For the protocol, please, complete that and show them the diff, and CC: to me. Thanks. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: exiftags (updated package)
George Danchev wrote: > On Sunday 31 August 2008 10:00:44 Eugene V. Lyubimkin wrote: >> George Danchev wrote: >>> Ok, thanks for fixing an RC. Builds fine per autobuilders >>> (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules >>> binary (as per policy), probalby because of missing binary-arch and >>> binary-indep targets ? Try to fix it, or I'll have a look more closer >>> look tonight... of course sponsors with more time are welcome to beat me >>> on that line ;-) >> Builds fine in my pbuilder. binary-arch and binary-indep are defined by >> debhelper v7. > > Eugene, > this is not enough, your `binary-arch' should build a binary package to > a > given architecture, but it fails because it does not depend on `build' target > (where policy 4.9. says it should), thus `patch' target was also not being > called as well. To fix that you should add: binary-arch: build install > George, I might missed something. Both 'dpkg-buildpackage -b' and 'dpkg-buildpackage -B' work, in both cases patches are applied and binary packages are built correctly. Where do you got the error? -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 20:25:57 Eugene V. Lyubimkin wrote: > George Danchev wrote: > > On Sunday 31 August 2008 10:00:44 Eugene V. Lyubimkin wrote: > >> George Danchev wrote: > >>> Ok, thanks for fixing an RC. Builds fine per autobuilders > >>> (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules > >>> binary (as per policy), probalby because of missing binary-arch and > >>> binary-indep targets ? Try to fix it, or I'll have a look more closer > >>> look tonight... of course sponsors with more time are welcome to beat > >>> me on that line ;-) > >> > >> Builds fine in my pbuilder. binary-arch and binary-indep are defined by > >> debhelper v7. > > > > Eugene, > > this is not enough, your `binary-arch' should build a binary package to > > a given architecture, but it fails because it does not depend on `build' > > target (where policy 4.9. says it should), thus `patch' target was also > > not being called as well. To fix that you should add: binary-arch: build > > install > > George, I might missed something. Both 'dpkg-buildpackage -b' and > 'dpkg-buildpackage -B' work, in both cases patches are applied and binary > packages are built correctly. Where do you got the error? ... you are relying on dpkg-buildpackage to call `build' for you. `build' resp. `patch' were not called as in: $ fakeroot debian/rules binary dh binary-indep dh binary-arch dh_testdir -a dh_auto_configure -a dh_auto_build -a make[1]: Entering directory `/home/danchev/download/debian/exiftags-1.01' cc -o exiftags.o -c exiftags.c [CUT the object files creation] make[1]: Leaving directory `/home/danchev/download/debian/exiftags-1.01' dh_auto_test -a dh_testroot -a dh_prep -a dh_installdirs -a dh_auto_install -a make[1]: Entering directory `/home/danchev/download/debian/exiftags-1.01' cp exiftags exifcom exiftime /home/danchev/download/debian/exiftags-1.01/debian/exiftags/usr/local/bin cp: target `/home/danchev/download/debian/exiftags-1.01/debian/exiftags/usr/local/bin' is not a directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/danchev/download/debian/exiftags-1.01' dh_auto_install: command returned error code 512 make: *** [binary-arch] Error 1 -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bindfs (bugfix upload, pre-approved by release team)
George Danchev wrote: > On Sunday 31 August 2008 09:49:05 Eugene V. Lyubimkin wrote: >> George Danchev wrote: >>> On Sunday 31 August 2008 08:30:03 Eugene V. Lyubimkin wrote: Hi -mentors! I am looking for a uploader for the new version 1.8-1 of my package "bindfs". [snip] It builds these binary packages: bindfs - mirrors or overlays a local directory with altered permissions >>> Okay, I found the release team reaction along with the diff. Could you >>> please remove quilt from build-depends since it is unneeded, and I will >>> sponsor. >> This change is safe for me, but for release team? This change will also >> lead to change debian/rules not to use 'patch' and 'unpatch' targets. > > Yes, it is safe; quilt has no business here as a build-dependency wasting > autobuilders and other builders time to install and deinstall. Worst, that > might leave a worrisome impression to the reader of any patches not being > applied by accident. For the protocol, please, complete that and show them > the diff, and CC: to me. Thanks. > Ok. Done, re-uploaded. http://mentors.debian.net/debian/pool/main/b/bindfs/bindfs_1.8-1.dsc -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: RFS: exiftags (updated package)
George Danchev wrote: > On Sunday 31 August 2008 20:25:57 Eugene V. Lyubimkin wrote: >> George Danchev wrote: >>> On Sunday 31 August 2008 10:00:44 Eugene V. Lyubimkin wrote: George Danchev wrote: > Ok, thanks for fixing an RC. Builds fine per autobuilders > (dpkg-buildpackage -B), but fails to build with fakeroot debian/rules > binary (as per policy), probalby because of missing binary-arch and > binary-indep targets ? Try to fix it, or I'll have a look more closer > look tonight... of course sponsors with more time are welcome to beat > me on that line ;-) Builds fine in my pbuilder. binary-arch and binary-indep are defined by debhelper v7. >>> Eugene, >>> this is not enough, your `binary-arch' should build a binary package to >>> a given architecture, but it fails because it does not depend on `build' >>> target (where policy 4.9. says it should), thus `patch' target was also >>> not being called as well. To fix that you should add: binary-arch: build >>> install >> George, I might missed something. Both 'dpkg-buildpackage -b' and >> 'dpkg-buildpackage -B' work, in both cases patches are applied and binary >> packages are built correctly. Where do you got the error? > > ... you are relying on dpkg-buildpackage to call `build' for you. > `build' resp. `patch' were not called as in: > > $ fakeroot debian/rules binary [cut build log] Ok, thanks, I finally understood you. Fixed, re-uploaded to mentors.d.o. http://mentors.debian.net/debian/pool/main/e/exiftags/exiftags_1.01-3.dsc. -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
[uploaded] Re: RFS: exiftags (updated package)
On Sunday 31 August 2008 21:07:55 Eugene V. Lyubimkin wrote: --cut-- > [cut build log] > Ok, thanks, I finally understood you. Fixed, re-uploaded to mentors.d.o. > http://mentors.debian.net/debian/pool/main/e/exiftags/exiftags_1.01-3.dsc. Thanks, uploaded will get to you in several hours. -- pub 4096R/0E4BD0AB 2003-03-18 signature.asc Description: This is a digitally signed message part.
Re: RFS: libxmpp-php
On Sun, 24 Aug 2008 19:55:41 -0500 Raphael Geissert <[EMAIL PROTECTED]> wrote: > >> And, I see you have a patch in debian/patches but you are not > >> applying it and running the test suite at build time (making the > >> phpunit b-d completely useless). > > D'oh! This has been fixed. Thanks to line-ending issues, there is > > now another patch that is applied before the test fixes so that > > they apply cleanly. > > Have you forwarded your patches to upstream? Not as yet, it is on my TODO list. > > > >> Please fix those issues and try to examine it by yourself and fix > >> any issues. > > I believe this to be a much improved package. It package can be > > found on mentors.debian.net: > > - URL: http://mentors.debian.net/debian/pool/main/l/libxmpp-php > > - Source repository: deb-src http://mentors.debian.net/debian > > unstable main contrib non-free - dget > > debian/rules: > You are missing a dependency on 'unpatch' at the clean target (makes > the package FTBFS twice in a row), and policy dictates that there > should be a binary-arch target even if the package is arch: all. Fixed and fixed. > debian/examples: > webclient_example.php is useless, so it should not be installed. Fixed. > tests/XMPPHP/*.php > Not packaging related, but: > > buildd's don't have access to any external resource (or if they do, > you should *not* rely on their availability), so if the test requires > an external connection to succeed you should consider it as a "will > always fail". I've patched these tests out, to be safe. > debian/changelog: > I see an inconsistency between the revision number in the package and > the one at the repository: Yup, I screwed it up. The updated package uses a more recent HEAD (revision 53) and, I believe, its correct revno and can be found at: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libxmpp-php - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libxmpp-php/libxmpp-php_0~svn53-1.dsc Cheers, Dan -- Daniel Watkins (Odd_Bloke) signature.asc Description: PGP signature
Re: RFS: freeguide (updated package)
Hi Vincent, Thanks for the review. On Sun, 31 Aug 2008 11:48:14 +0200 Vincent Bernat <[EMAIL PROTECTED]> wrote: > I think that you should Build-Depends-Indep on openjdk-6-jdk | > java2-sdk instead of just java2-sdk which is a virtual package. Fixed. > What is missing to move to main? I'm not sure, which is why I haven't done it yet. I wanted to get the irrelevant changes to the packaging out of the way so I could focus on that, which is what this upload is about. > There are some files that are modified outside of debian/ directory. > You should consider using a patch management system to track those > changes. Oops, not sure how that happened. I've switched to using dpatch now. > Seems fine otherwise. Maybe you will package the new upstream release? There was an issue with 0.10.8 which meant that upstream didn't want it packaged. Once a good release happens, I will. :) > There is lintian warning: > I: freeguide: > desktop-entry-contains-encoding-key > /usr/share/applications/freeguide.desktop:5 > Encoding Fixed. The updated package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/f/freeguide - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/f/freeguide/freeguide_0.10.7-1.dsc Cheers, Dan -- Daniel Watkins (Odd_Bloke) signature.asc Description: PGP signature
Re: RFS: atmailopen (2nd attempt - updated description)
Vincent Bernat ha scritto: > You can also just exclude all those files from orig.tar.gz. In this > case, put "dfsg" somewhere in the version string (1.02+svn48.dfsg-1) for > example. And you should add a note in README.source on how to get the > source package from SVN (and, better, add an appropriate target in > debian/rules like get-orig-source). > Done > > I think that you can. Those templates are unlikely to change until the > upload is ready. Done. > > Other remarks: > * php5 depends on php5-cgi (as an alternative), so you can just depend >on php5. > * "$popimap_debug_file='/tmp/popimap_debug'" can lead to symlink >attacks. Use something in /var/log/atmailopen. If this is enabled by >default, don't forget to add a rule in logrotate. > * the binary-arch seems to be missing in debian/rules Fixed. Reuploaded on mentors, thanks. Giuseppe Iuculano. signature.asc Description: OpenPGP digital signature
RFS: pacpl
Dear mentors, I am looking for a sponsor for my package "pacpl". * Package name: pacpl Version : 4.0.3-1 Upstream Author : Philip Lyons <[EMAIL PROTECTED]> * URL : http://pacpl.sourceforge.net * License : GPL-3 Section : sound It builds these binary packages: pacpl - a multi-purpose audio converter/ripper/tagger script Long Description: Perl Audio Converter is a tool for converting multiple audio types from one format to another using various external encoders/decoders. . It supports the following audio formats: AAC, AC3, AIFF, APE, AU, AVR, BONK, CAF, CDR, FAP, FLA, FLAC, IRCAM, LA, LPAC, M4A, MAT, MAT4, MAT5, MMF, MP2, MP3, MP4, MPC, MPP, NIST, OFR, OFS, OGG, PAC, PAF, PVF, RA, RAM, RAW, SD2, SF, SHN, SMP, SND, SPX, TTA, VOC, W64, WAV, WMA, and WV. . It can also convert audio from the following video extensions: RM, RV, ASF, DivX, MPG, MKV, MPEG, AVI, MOV, OGM, QT, VCD, SVCD, M4V, NSV, NUV, PSP, SMK, VOB, FLV, and WMV. . Pacpl also includes a CD ripping function with CDDB support, batch conversion, tag preservation for most supported formats, independent tag reading/writing, and extensions for Amarok, Dolphin, D3lphin and Konqueror. The upload would fix these bugs: 492666 (ITP). Please check ITP for a resume about my work with upstream author which led to a new pacpl release more suitable for Debian packaging. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pacpl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pacpl/pacpl_4.0.3-1.dsc I would be glad if someone reviewed and uploaded this package for me. Thanks, Cristian signature.asc Description: Digital signature
Re: WNPP #495959 : dhcp_probe software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Wise a écrit : > Another hacky solution would be to get the Debian libnet maintainer to > build two variants of libnet, one with the patch (for dhcp-probe) and > one without (for everyone else). > > Ultimately the proper solution is for libnet to get a new upstream > release; please work with libnet upstream to make this happen so you > can package dhcp-probe. > Thanks for these two answer. I saw that libnet has no official maintainer so i think i will download upstream code (RC version) and i will package it (even if it's my first package and it isn't recommended). After libnet package was buildt, i'll can package dhcp_probe... Is it a correct solution according to state of each package ? Thanks in advance. - -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIu3QpjcKpXFc/7oYRAkzdAJ9HGySGAHWCYBRg+BZM5OHZ09+xqQCfaLUW iZ75jz5GgDrHTJP0TU02V10= =YrxF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WNPP #495959 : dhcp_probe software
On Mon, Sep 1, 2008 at 12:48 PM, Laurent Guignard <[EMAIL PROTECTED]> wrote: > I saw that libnet has no official maintainer so i think i will download > upstream code (RC version) and i will package it (even if it's my first > package and it isn't recommended). Actually David Paleino intends to adopt it, has prepared a new package and is probably looking for a sponsor: http://packages.qa.debian.org/libn/libnet.html http://bugs.debian.org/483710 Probably isn't a good idea to hijack his adoption. > Is it a correct solution according to state of each package ? No, work with upstream until they are confident enough to release a new stable version (instead of an RC). Then you can ask David Paleino to package the new version for Debian. Finally you can work on dhcp_probe. Alternatively you could ask David to package the libnet RC release for experimental and then upload dhcp_probe to experimental. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: netmon-applet (updated package)
On Thu, 2008-08-28 at 21:51 +0300, George Danchev wrote: > On Thursday 28 August 2008 17:17:20 Stephan Peijnik wrote: > > Dear mentors, > > > > I am looking for a sponsor for the new version 0.4-12 > > of my package "netmon-applet". > > Hello, > here are some comments, you might want to address: > > 1) debian/copyright lacks important information - linux-data.c is copyrighted > by another person, but not mentioned in the copyright file. > > 2) update upstream URL in debian/copyright, or better convert to machine > interpretable copyright format [1] > > 3) code duplication since linux-data.c has been borrowed from xnetload, which > is already in Debian -- anti security, but the impact is in fact very low in > that case. Btw, why this package should stay in Debian, when we have > xnetload, sharing more or less the same functionality ? > > 4) changes to the upstream code, which are now applied in a combined fashion > by diff.gz are best to be broken up in logical diffs and comunicated > upstream. No gain in removing unused variables from gnome-ui.c:netmon_draw(), > there are quite some more left, so leave them to upstream to clean as they > find fit, some like to leave unused vars as a reminder ;-) > > [1] http://wiki.debian.org/Proposals/CopyrightFormat Thanks for your input George. As noted by Josselin Mouette in Bugreport #335916 dropping netmon-applet completely seems like a good idea though, so I am putting this package back in orphaned status. Regards, Stephan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
