Re: RFS: sqlline
Ok with me. On both parts. :) Best regards, // Ola On Mon, Aug 04, 2008 at 09:34:18PM +0200, Damien Raude-Morvan wrote: Le Monday 04 August 2008 06:47:41 Ola Lundqvist, vous avez écrit : Hi I have two comments on this package. 1) Please consider to name the package sqlline-java or similar. Not strictly necessary but it do not clutter the namespace as much. :) AFAIK (and i'm not currently a DD :), and as said in [1], Java program are ordinary programs, from the user point of view so I dont see the need of appending -java to package name. For example, we don't append -python to every python program (take GRAMPS or apt-listchanges). We don't need to clutter package's names with programming language :) 2) Do not strip the .orig.tar.gz file unless strictly necessary. In this case I can not see that it is necessary. It would be good to ask upstream if it is possible to release one version without GPL references... If that is necessary is up to the ftp masters to decide though when accepting the package. You're right, it's best to get a new release from upstream without GPL crufts but Marc Prud'hommeaux (upstream author) answer to me : Unfortunately, I'm not going to have any time to make a new SQLLine release in the near future correcting the issue of the license file. So for now, I'll revert to pristine upstream tarball and make a note in debian/README.source. Is it ok for you ? [1] http://www.debian.org/doc/packaging-manuals/java-policy/x86.html -- Damien Raude-Morvan / www.drazzib.com -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: liboauth-php
On Mon, 04 Aug 2008 23:43:02 +1000 Ben Finney [EMAIL PROTECTED] wrote: The package doesn't seem to be correctly described by this synopsis. The package is not a protocol; it's a PHP library. Perhaps a better synopsis would be: PHP library implementing the OAuth secure authentication protocol Of course, you're right. Fix uploaded to the same place. :) Cheers, -- Daniel Watkins (Odd_Bloke) signature.asc Description: PGP signature
Re: upstream has license which is an edited GPL
On Mon, Aug 04, 2008 at 11:40:19PM +1000, Ben Finney wrote: Stanislav Maslovski [EMAIL PROTECTED] writes: One thing that I have to note also that after this standard header the author writes: For more details see the file COPYING. which is the changed GPL. I would expect the explicit word of the license grant For more details see the file COPYING to indicate the explicit wishes of the copyright holder, and hence have significance in determining what the license is. In this particular case of CDDE I believe that the author simply made a mistake. That was, perhaps, his first project under GPL. He did not realize that the GPL preamble and appendix were inseparable parts of the GPL document. For instance, his project page on Freshmeat [1] explicitely states that CDDE 0.2.0 is under GPL. The fact that he did not change any of GPL terms and conditions in his edited license and kept the name of the license intact also shows this. It might be that, since the copyright holder has explicitly referenced that document for specific terms, you cannot legally just substitute the correct GPL document in place of their copyright-violating document. Of course, you cannot legally redistribute the copyright-violating document either. I am still waiting for his reply. If he does not answer, I think a possible solution is to fork, assuming that the upstream is MIA and then correcting his mistake. [1] http://freshmeat.net/projects/cdde/ -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Fwd] bug #292231 - fixed in upstream, pending 412 days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 re all, i posted the following help request to debian-devel and was pointed out to debian-mentors. apologies to whoever received it twice now, i'm learning and can't browse many webpages from a very slow connection. thanks for your kind help - - Forwarded message from jaromil [EMAIL PROTECTED] - Date: Tue, 5 Aug 2008 12:43:30 +0800 From: jaromil [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: bug #292231 - fixed in upstream, pending 412 days re all, scroll down for bug references, here it follows human written desc: the manpage was fixed about 400 days ago and communicated to mantainer (also in cc:). mantainer Christian stated he would fix it but doesn't, still now he is too busy. i am in contact with another debian neo-mantainer Luca (also in cc:) and myself i can co-mantain as upstream author, we offered to Christian to add us as co-mantainers and he agrees but then cannot do it. we are blocked as he cannot add us apparently for no time, even if received clear instructions from Luca. how we proceed from that? package hasciicam is dropping out of lenny because of this. thanks for your kind help - - Forwarded message from DDPOMail robot [EMAIL PROTECTED] - From: DDPOMail robot [EMAIL PROTECTED] To: Denis Rojo [EMAIL PROTECTED] Subject: Possible problems in your Debian packages === hasciicam: (you are subscribed on the PTS) = 1 bug(s) that should be fixed for the next Debian release: - - #292231 http://bugs.debian.org/292231 [NONFREE-DOC:GFDL1.1] making the entire manpage invariant is not consistent with the DFSG = Not in testing for 412 days. If things don't change, it won't be part of lenny! See http://release.debian.org/migration/testing.pl?package=hasciicam - - End forwarded message - - -- Jaromil, dyne.org developer, http://jaromil.dyne.org GPG: 779F E8B5 47C7 3A89 4112 64D0 7B64 3184 [ B534 0B5E ] - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFImCuhe2QxhLU0C14RAgkTAJ4uSh17tRIMlNf2wTMKWsjdiVvEbQCg2DwZ dVokPmF0OnmmRur0D64CNFk= =C12Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lintian warning messages
I am getting quite a few lintian warnings that I would like to quell. Do we have any best practices on how to deal with these messages? W: package: debian-copyright-line-too-long -- As I understand it long lines are now OK. I am following the new, proposed guidelines for the copyright file (http://wiki.debian.org/Proposals/ CopyrightFormat) and it almost guarantees long lines. W: package: script-non-executable -- Since this is a scripted web application (RoR) there are quite a few scripts that are not executable directly in the shell. Can I turn this warning off for these files? W: package: extra-license-file -- There are several LICENSE files scattered throughout the package and I have documented them in the copyright file. Do I need to do anything with these? Should I remove them or is there a way to ignore them? W: package: embedded-javascript-library -- Basically, prototype.js (versions 1.6.0.1 1.5.0) is being used in several places. Obviously it would be best to depend on the libjs-prototype package and remove the embedded versions. Once I get upstream using a single version of prototype do I just remove the original prototype.js files and symlink to the package version? W: package: package-contains-empty-directory -- Some of these are necessary (cache, assets, etc.) and some aren't (test). Can I turn these off? Thanx! Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
Richard Hurt escreveu: W: package: script-non-executable -- Since this is a scripted web application (RoR) there are quite a few scripts that are not executable directly in the shell. Can I turn this warning off for these files? If the scripts are not directly executable, you can remove the #!interpreter line from them. That should make the warning go away. It would be better to talk with upstream so he does that. Meanwhile, patches can be used, but I don't think this warning is grave enough to make that a necessity. W: package: extra-license-file -- There are several LICENSE files scattered throughout the package and I have documented them in the copyright file. Do I need to do anything with these? Should I remove them or is there a way to ignore them? If they are common licenses, they shouldn't be part of the resulting package. If the package uses make install and they are installed as part of that, you can rm them after that line so they do not appear in the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
Hi Richard, On Tuesday 5 August 2008 14:02, Richard Hurt wrote: I am getting quite a few lintian warnings that I would like to quell. Do we have any best practices on how to deal with these messages? W: package: debian-copyright-line-too-long -- As I understand it long lines are now OK. I am following the new, proposed guidelines for the copyright file (http://wiki.debian.org/Proposals/ CopyrightFormat) and it almost guarantees long lines. This warning has been scratched from the upcoming Lintian version so I would not worry about it. W: package: script-non-executable -- Since this is a scripted web application (RoR) there are quite a few scripts that are not executable directly in the shell. Can I turn this warning off for these files? Maybe you could find out why this warning is triggered. Probably, these scripts have shebang lines (#!/usr/bin/ruby perhaps?) but are not executable. That doesn't match, as the shebang line is useless if the script is not executable. So if they're not going to be executed on the shell anyway, upstream can remove those shebang lines. That said, I don't think it's necessary to be going through the effort to make a Debian-specific patch to the source for that. W: package: extra-license-file -- There are several LICENSE files scattered throughout the package and I have documented them in the copyright file. Do I need to do anything with these? Should I remove them or is there a way to ignore them? Just remove them when building the package (e.g. doing rm in debian/rules somewhere after the dh_install). It's useless cruft that we do not want to see installed on user's systems. In general it's worth the effort to put extra commands in your debian/rules file if that causes less unnecessary things on the user's system - a package is rarely built but after that installed on many systems. W: package: embedded-javascript-library -- Basically, prototype.js (versions 1.6.0.1 1.5.0) is being used in several places. Obviously it would be best to depend on the libjs-prototype package and remove the embedded versions. Once I get upstream using a single version of prototype do I just remove the original prototype.js files and symlink to the package version? Yes, that would probably work fine. Until then, just keep the warning to remind you and others that this isn't done yet. W: package: package-contains-empty-directory -- Some of these are necessary (cache, assets, etc.) and some aren't (test). Can I turn these off? You can remove the unnecessary ones (similar to the licence files above) and add overrides for the needed ones. cheers, Thijs pgpRQUMn2JWr6.pgp Description: PGP signature
Re: Lintian warning messages
Hi Dne Tue, 5 Aug 2008 08:02:28 -0400 Richard Hurt [EMAIL PROTECTED] napsal(a): I am getting quite a few lintian warnings that I would like to quell. Do we have any best practices on how to deal with these messages? W: package: debian-copyright-line-too-long -- As I understand it long lines are now OK. I am following the new, proposed guidelines for the copyright file (http://wiki.debian.org/Proposals/ CopyrightFormat) and it almost guarantees long lines. This will be dropped from next lintian version, you can safely ignore this check (see http://bugs.debian.org/491302). W: package: script-non-executable -- Since this is a scripted web application (RoR) there are quite a few scripts that are not executable directly in the shell. Can I turn this warning off for these files? It is a cgi? Then it should be executable. If not, they should not start with #!/something. W: package: extra-license-file -- There are several LICENSE files scattered throughout the package and I have documented them in the copyright file. Do I need to do anything with these? Should I remove them or is there a way to ignore them? All licenses should be in single place in debian/copyright, anything else is not needed. W: package: embedded-javascript-library -- Basically, prototype.js (versions 1.6.0.1 1.5.0) is being used in several places. Obviously it would be best to depend on the libjs-prototype package and remove the embedded versions. Once I get upstream using a single version of prototype do I just remove the original prototype.js files and symlink to the package version? Something like this. W: package: package-contains-empty-directory -- Some of these are necessary (cache, assets, etc.) and some aren't (test). Can I turn these off? Yes, add override for these. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
RFS: CLAM, C++ library for audio and music
CLAM, C++ library for audio and music is a development framework for audio and music applications. It provides lot of high level algorithms to analyze and manipulate audio. They can be combined -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scrot (updated package)
On Monday 04 August 2008 02:13:30 Ben Finney wrote: George Danchev [EMAIL PROTECTED] writes: --cut-- Advice given here needs to be carefully examined for dogma, and a clear line needs to be maintained between you should do this and this is one way to do it. I'm guessing here -- Have you ever thought that this could be an advice given by a sponsor who prefers the things the way he asked and at the end he is responsible to fix any potential breakages subsequently found ? Ever thought he wants his life easier? So get back safely to the ground and forget about any dogmas, except the ones found in debian policy. I'm correcting the false implication that put the changes in a series of patches in debian/patches and build depend on quilt is somehow mandatory, or even that it's recommended practice. That flies directly in the face of DevRef 6.2.1 Best Packaging Practices. Should I be in dount or I'm better not ;-) In fact, anything that generates the Debian source format is fine, and there are perfectly valid ways that don't involve the use of a series of patches in debian/patches and build depend on quilt. That's *one* way, but I disagree that it should be recommended without alternatives as Anibal's message did. Your alternative as currently being performed leads to deeply hidden and silent changes to the upstream code and is proven as a very bad practice by some recent security disasters. Note that 3.0 (git) will improve the readability and changeset identification (since it brings more information with the surce package itself, but still one should fight the history) but it is not allowed/ready yet. Note, that I'm not against VCS, I'm against their abusage and the distribution of unreadable and sometimes dangerous bits. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: desktop-data-model
On Tuesday 05 August 2008 02:42:59 Robert Collins wrote: On Mon, 2008-08-04 at 21:29 +0200, Vincent Bernat wrote: OoO En ce début de soirée du mercredi 23 juillet 2008, vers 21:37, Julien Lavergne [EMAIL PROTECTED] disait : I am looking for a sponsor for my package desktop-data-model. Hi Julien! You are adding org.freedesktop.od.Engine.service. Put it in debian/ directory instead and use debian/rules or *.install files to put it in the right place. It is better that your diff.gz only contains changes to debian/ directory. Urgh, I find this assertion really quite annoying, and seeing it in two consecutive . Jumping through hoops to keep the diff contained in debian harms reviewability as much as having arbitrary changes scattered over the source tree. Urgh, this is quite immature assertion, really. Could you please elaborate how to extract separate changes from your latter (all-in-all) diff.gz (since that is what Debian officially releases) and do you need any hints how to do it with the former diff.gz (I hope you don't)? Really, we want things to be as clear as possible; and if that means changes outside the debian directory, then *that is fine*. We're not just writing meta-data to install software in a debian package (though that is a fine goal to be aiming for), we're fixing such bugs as needed to have the software work well on debian (or at least however many bus a particular DD feels up to fixing :)). Good, but think about the ease of reviewing and human time spent in such a process. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd] bug #292231 - fixed in upstream, pending 412 days
OoO Pendant le temps de midi du mardi 05 août 2008, vers 12:29, jaromil [EMAIL PROTECTED] disait : i posted the following help request to debian-devel and was pointed out to debian-mentors. apologies to whoever received it twice now, i'm learning and can't browse many webpages from a very slow connection. Hi! If you want package to be in Lenny, you should prepare an NMU correcting debian/copyright to say that the manual page is also licensed under GFDL with no invariant and point to the correct CVS commit stating this. Any other change is likely to be rejected due to the current freeze. For the future, if you want to be maintainer, you will need to ask Christian to orphan the package. If he is not able to, you need to ask qa to orphan the package with the facts that the maintainer is not available any more. If you just try to hijack the package, it will be more difficult to find a sponsor for it. -- panic(CPU too expensive - making holiday in the ANDES!); 2.2.16 /usr/src/linux/arch/mips/kernel/traps.c pgpEqdCMJjCWw.pgp Description: PGP signature
RFS: CLAM, C++ library for audio and music
(I am sorry, my previous mail to the list fled from my computer without my consent ;-) Here is the full one.) Package: clam Description: CLAM, C++ library for audio and music License: GPL v2 or higher CLAM, C++ library for audio and music is a development framework for audio and music applications. It provides lot of high level algorithms to analyze and manipulate audio. They can be combined in a graphical way using the NetworkEditor application or by C++ programming. It integrates backends to Ladspa, Jack, PortAudio, OSC, libsndfile, libmad, libogg... so that those libraries and technologies can be seen in a common interface. Some algorithms included in the libraries are: Tonal (chord) analysis, Sinusoidals + residual analysis and transformations, spectral analysis and transformations, realtime spatialization algorithms (ambisonics, hrtfs...), guitar effects, rhythm analysis... Web page: http://clam.iua.upf.edu/ Screenshots: http://clam.iua.upf.edu/wikis/clam/index.php/Development_screenshots A tour on the graphical tool usage: http://iua-share.upf.edu/wikis/clam/index.php/Network_Editor_tutorial Upstream team has been packaging them for a long time and we would like to get them into debian repositories, so we are requesting for an sponsor. Last versions of the debian packages can be found there: http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots/ David Garcia Garzon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: Second try for twiki-ldapcontrib, new upstream version - Re: RFS: twiki-ldapcontrib - LDAP services for TWiki
Dear mentors, I am looking for a sponsor for my package twiki-ldapcontrib. * Package name: twiki-ldapcontrib Version : 2.99.5-1 Upstream Author : Michael Daum [EMAIL PROTECTED] * URL : http://twiki.org/cgi-bin/view/Plugins/LdapContrib * License : GNU GPL Section : web It builds these binary packages: twiki-ldapcontrib - LDAP services for TWiki Description: LDAP services for TWiki . This package offers basic LDAP services for TWiki and offers authentication of TWiki users by binding to an LDAP server as well as incorporate LDAP user groups into TWiki's access control. . Take a look at http://twiki.org/cgi-bin/view/Plugins/LdapContrib for more info. The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/twiki-ldapcontrib - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/twiki-ldapcontrib/twiki-ldapcontrib_2.99.5-1.dsc FYI, I previously filed an ITP : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48 for this package. Some more details about this packaging are available from : http://picoforge.int-evry.fr/projects/twldapdeb/ I would be glad if someone uploaded this package for me. Kind regards Olivier Berger Le vendredi 05 octobre 2007 à 13:22 +0200, Olivier Berger a écrit : Dear mentors, I am looking for a sponsor for my package twiki-ldapcontrib. * Package name: twiki-ldapcontrib Version : 1.11-1 Upstream Author : Michael Daum [EMAIL PROTECTED] * URL : http://twiki.org/cgi-bin/view/Plugins/LdapContrib * License : GNU GPL Section : web It builds these binary packages: twiki-ldapcontrib - LDAP services for TWiki The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/twiki-ldapcontrib - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/twiki-ldapcontrib/twiki-ldapcontrib_1.11-1.dsc I previously filed an ITP : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48 for this package. Some more details about this packaging are available from : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Picoforge/Web/TwikiLdapcontribDeb . I would be glad if someone uploaded this package for me. Kind regards Olivier Berger -- Olivier BERGER [EMAIL PROTECTED] http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bzr-cvsps-import
OoO En cette soirée bien amorcée du lundi 04 août 2008, vers 22:53, Jelmer Vernooij [EMAIL PROTECTED] disait : I think that most things in Build-Depends are not needed for the clean rule, so you can move them in Build-Depends-Indep (and just keep cdbs and debhelper). Fixed. Please Build-Depends-Indep on python, even if it is currently an indirect dependency. For bzr-stats, you need to move python from Build-Depends to Build-Depends-Indep since it is not used on cleaning. To avoid a lintian warning, you should provide a debian/watch file with just a comment about, for example, the URL to upstream repository. Fixed. You put a real debian/watch file. However, since you are tracking a bzr branch, this is a bit useless. Just put some comments in it instead of a real URL: # This package uses the following bzr branch: # http:// Like you did for bzr-stats in fact. Well, this may be a bit late since some packages have already been sponsored, but since all those plugins are rather small, you could bundle them in a single package (like gnus-bonus-el for example). This will be a bit harder to follow upstream since there is no mechanism to track several upstreams but this will ease your work in finding a sponsor, I think and will allow you to ship more plugins once you will get an upload with DM field enabled. I am not sure this is something encouraged or something to avoid. Maybe some people will give better advices here about this. Even if it's all inside a single source package, it would still be necessary for the package to go through NEW whenever a new binary package is added. Putting the multiple plugins into the same binary package is probably a bad idea since they each have different dependencies. I was thinking about one source package and one binary package. No need to go through NEW then. But you are right about dependencies. -- /* * For moronic filesystems that do not allow holes in file. * We may have to extend the file. */ 2.4.0-test2 /usr/src/linux/fs/buffer.c pgptg1FaJ09mm.pgp Description: PGP signature
Re: Re: RFS: python-otr
Hi, uploaded the new package to mentors, URLs are still the same: http://mentors.debian.net/debian/pool/main/p/python-otr/python-otr_0.2.1-1.dsc * please add python-otr-dbg package (check DPMT[1] repository for examples) Fixed * Priority: extra - why not optional? Fixed * please remove all files generated by running tests in clean rule (yeah, I know, you're not running tests at build time, but I am :-) Fixed, unless there were more than python-otr-0.2.1/otr.py and python-otr-0.2.1/otr_wrap.c * fix debian/watch (check `uscan --report --verbose`) Woops, had a broken link on the website, thanks for the hint. * Vcs-Bzr and Vcs-Browser should point to debian stuff Fixed * Off-the-Record should appear somewhere in long description, IMO Ack, fixed. * consider joining DPMT[2] Not sure whether this is appropriate, since I (currently) don't intend to do too much packaging. Sorry, I forgot to note that I'm not subscribed to mentors, so it would be best to keep me CC'ed. Thanks, Kjell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
Eduardo M KALINOWSKI wrote: If the scripts are not directly executable, you can remove the #!interpreter line from them. That should make the warning go away. It would be better to talk with upstream so he does that. If I were upstream and was pestered by a distribution to remove the hashbang lines that I add to all code files as a matter of course (because it's the most portable way to tell editors what type of code it is), and their rationalle was that an internal tool in the distribution was complaining about it, I'd be hard pressed to not laugh in their face. Lintian has overrides so that you can turn off this type of warning, which is useful in detecting scripts that were accidentially not installed executable, but that has a large number of false positives. -- see shy jo signature.asc Description: Digital signature
Re: [Fwd] bug #292231 - fixed in upstream, pending 412 days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bonnesoir Vincent, (i'm at GMT+7) y merci pour l'assistance On Tue, Aug 05, 2008 at 06:35:34PM +0200, Vincent Bernat wrote: Hi! If you want package to be in Lenny, you should prepare an NMU correcting debian/copyright to say that the manual page is also licensed under GFDL with no invariant and point to the correct CVS commit stating this. i don't really know NMU but the commit is here http://git.dyne.org/index.cgi?url=hasciicam/commit/id=40bcb3a0e84f03952e1b51b6e77f0f877b91a1d4 (it passed so much time that in the meantime we moved to svn and git) Any other change is likely to be rejected due to the current freeze. no other change meant right now For the future, if you want to be maintainer, you will need to ask Christian to orphan the package. If he is not able to, you need to ask qa to orphan the package with the facts that the maintainer is not available any more. If you just try to hijack the package, it will be more difficult to find a sponsor for it. what a kafkian situation, considering i wrote the code and i'm keen to adapt the licensing to debian! now i'm seriously reconsidering to be involved in all this. i hope Luca has some more patience. thanks anyway and happy hacking ciao - -- Jaromil, dyne.org developer, http://jaromil.dyne.org GPG: 779F E8B5 47C7 3A89 4112 64D0 7B64 3184 [ B534 0B5E ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFImIkBe2QxhLU0C14RAjoOAKDkEnW5sC1qltCAoMckvRf4VI/eZACgwbVU BAdgmr23I+aJSo5tj9FZC3c= =i52u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: esteidutil
On Thu, Jul 31, 2008 at 3:48 PM, Kaido Kert [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 10:45 PM, Piotr Ożarowski [EMAIL PROTECTED] wrote: [Kaido Kert, 2008-07-30] I have sent RFS for this package twice, and have not gotten any bit of feedback yet. Can anyone at least point me to what i am missing ? I'd say it's due to this md5sum problem (.dsc file points to different upstream sources tarball). If not, then most probably there are no DDs with such card (so they cannot test if this app. works). Thanks for the input. Sorry, i had indeed messed up with the source.tar, fixed now to the exact same copy on sf.net and reuploaded. Anyone ? -kert
Re: [Fwd] bug #292231 - fixed in upstream, pending 412 days
OoO Pendant le repas du mardi 05 août 2008, vers 19:08, jaromil [EMAIL PROTECTED] disait : If you want package to be in Lenny, you should prepare an NMU correcting debian/copyright to say that the manual page is also licensed under GFDL with no invariant and point to the correct CVS commit stating this. i don't really know NMU but the commit is here http://git.dyne.org/index.cgi?url=hasciicam/commit/id=40bcb3a0e84f03952e1b51b6e77f0f877b91a1d4 (it passed so much time that in the meantime we moved to svn and git) I though that you wanted to do the NMU yourself. Do you seek for someone else to do it? I can do it if you wish. For the future, if you want to be maintainer, you will need to ask Christian to orphan the package. If he is not able to, you need to ask qa to orphan the package with the facts that the maintainer is not available any more. If you just try to hijack the package, it will be more difficult to find a sponsor for it. what a kafkian situation, considering i wrote the code and i'm keen to adapt the licensing to debian! now i'm seriously reconsidering to be involved in all this. i hope Luca has some more patience. Well, I am sorry for this situation but dealing with inactive maintainers has always been a difficult task in Debian. -- panic(mother...); 2.2.16 /usr/src/linux/drivers/block/cpqarray.c pgpEnmF3IKsa2.pgp Description: PGP signature
Re: Re: RFS: bluemindo
Hi, sorry for beeing late with replying. Had been a bit busy the days when we where on this, and forgotten it over this. Mea culpa, but just as a hint for the future: Its not bad to send a reminder after some days. After all people in the project are just people, so things like this may happen otherwise. I would have send a reminder, after having waited a bit more, though. Good, except that I miss a It was downloaded from .. sentence in the human readable part. It should be ok now. Thank you for your help :) Best regards, Thibaut GIRKA. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFS: bzr-cvsps-import
Hi Vincent, Am Dienstag, den 05.08.2008, 18:55 +0200 schrieb Vincent Bernat: OoO En cette soirée bien amorcée du lundi 04 août 2008, vers 22:53, Jelmer Vernooij [EMAIL PROTECTED] disait : I think that most things in Build-Depends are not needed for the clean rule, so you can move them in Build-Depends-Indep (and just keep cdbs and debhelper). Fixed. Please Build-Depends-Indep on python, even if it is currently an indirect dependency. For bzr-stats, you need to move python from Build-Depends to Build-Depends-Indep since it is not used on cleaning. I've added a build-dependencies on python, since lintian yells at me if I add a build-depends-indep: E: bzr-avahi source: clean-should-be-satisfied-by-build-depends python | python-dev | python-all | python-all-dev | python2.4 | python2.4-dev | python2.5 | python2.5-dev I guess it may be using ./setup.py clean to do the clean, which would require python. To avoid a lintian warning, you should provide a debian/watch file with just a comment about, for example, the URL to upstream repository. Fixed. You put a real debian/watch file. However, since you are tracking a bzr branch, this is a bit useless. Just put some comments in it instead of a real URL: # This package uses the following bzr branch: # http:// Like you did for bzr-stats in fact. Fixed. I've uploaded new versions to mentors.debian.net. Cheers, Jelmer -- Jelmer Vernooij [EMAIL PROTECTED] - http://samba.org/~jelmer/ Jabber: [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: RFS: bzr-cvsps-import
OoO Pendant le repas du mardi 05 août 2008, vers 19:55, Jelmer Vernooij [EMAIL PROTECTED] disait : I've uploaded new versions to mentors.debian.net. Hi Jelmer! I have uploaded both of them. -- BOFH excuse #172: pseudo-user on a pseudo-terminal pgpaIavRtg99h.pgp Description: PGP signature
Re: Re: RFS: python-otr
[Kjell Braden, 2008-08-05] * Priority: extra - why not optional? Fixed I changed Priority to extra in -dbg package and uploaded it -- http://people.debian.org/~piotr/sponsor pgpohIH0VGoFY.pgp Description: PGP signature
Re: Lintian warning messages
Michal Čihař [EMAIL PROTECTED] writes: Richard Hurt [EMAIL PROTECTED] napsal(a): W: package: package-contains-empty-directory -- Some of these are necessary (cache, assets, etc.) and some aren't (test). Can I turn these off? Yes, add override for these. Lintian does not warn about empty directories in /var. I suspect that your empty directories (particularly cache) may be in the wrong place according to the FHS for what the package will put in them. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
Joey Hess wrote: Eduardo M KALINOWSKI wrote: If the scripts are not directly executable, you can remove the #!interpreter line from them. That should make the warning go away. It would be better to talk with upstream so he does that. If I were upstream and was pestered by a distribution to remove the hashbang lines that I add to all code files as a matter of course (because it's the most portable way to tell editors what type of code it is), and their rationalle was that an internal tool in the distribution was complaining about it, I'd be hard pressed to not laugh in their face. If the policy suggestion that leads to that lintian warning is so unreasonable, it might as well be taken off the policy. Lintian has overrides so that you can turn off this type of warning, which is useful in detecting scripts that were accidentially not installed executable, but that has a large number of false positives. Except, perhaps, from scripts which end up installed in the directories in the path. For scripts that are not in the path (and even if the execute bit set can only be executed with extra measures from the user) it should not matter whether they have a shebang or not. -- BOFH excuse #312: incompatible bit-registration operators Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
Eduardo M KALINOWSKI wrote: If the policy suggestion that leads to that lintian warning is so unreasonable, it might as well be taken off the policy. I'm not aware of any such thing in policy. -- see shy jo signature.asc Description: Digital signature
Re: Lintian warning messages
Joey Hess wrote: Eduardo M KALINOWSKI wrote: If the policy suggestion that leads to that lintian warning is so unreasonable, it might as well be taken off the policy. I'm not aware of any such thing in policy Then maybe the lintian warning could be removed. -- BOFH excuse #376: Budget cuts forced us to sell all the power cords for the servers. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warning messages
Eduardo M KALINOWSKI [EMAIL PROTECTED] writes: Joey Hess wrote: Eduardo M KALINOWSKI wrote: If the policy suggestion that leads to that lintian warning is so unreasonable, it might as well be taken off the policy. I'm not aware of any such thing in policy Then maybe the lintian warning could be removed. The Lintian warning frequently catches scripts that were supposed to be executable but don't have correct permissions, as Joey says. There are already exceptions in Lintian for libraries for some scripting languages. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: bluemindo
On Sun, Aug 3, 2008 at 2:58 PM, Patrick Schoenfeld
[EMAIL PROTECTED] wrote:
Now I'm satisfied with your package, except the missing sentence in the
copyright file. So I'm recommending to upload the package to my
Application Manager Paul.
Paul, is this package ready for upload in your opinion, or is there
something to add from your side? As a reminder: The package in question
is [1].
Thibaut, the initial owner of the ITP was Luca Falavigna
[EMAIL PROTECTED], is there any reason you've hijacked it?
Usually it is a good idea to write some message in the bug log if you
take over an ITP from someone else.
It is a good idea to document authorship and purpose in the patch headers.
Please send the manual page, patches upstream if you haven't yet.
You are missing a depends on gstreamer0.10-plugins-base so it can start:
bluemindo
Traceback (most recent call last):
File ./bluemindo.py, line 106, in module
gst = GStreamer()
File /usr/share/bluemindo/src/media/gstreamer.py, line 41, in __init__
self.player = gst.element_factory_make('playbin', 'bluemindo')
gst.ElementNotFoundError: playbin
Package looks good otherwise.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
