Re: RFS: QA Upload -- quiteinsanegimpplugin
Barry deFreese wrote: Since I did quiteinsane I figured it was only right to fix up quiteinsanegimplugin. Fixes 1 bug and some package clean-up / standards updates. Including fixing up similar debian/copyright issues to quiteinsane. Uploaded. Thanks! Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Config files which are writable by www-data
Hi Matt, Matthew Palmer schrieb: Well, don't do that, then. Ship the template files somewhere else, and then copy them into /var if they're not already there. that is probably the best solution. I think I will put them in /usr/share/doc/ldap-account-manager/examples and copy them from there to /var. The files are ASCII but changing them with a text editor makes no sense. Thanks a lot for your help. Best regards Roland signature.asc Description: OpenPGP digital signature
Re: RFS: python-twitter
[Mauro Lizaur, 2008-02-09 11:43] - dget http://mentors.debian.net/debian/pool/main/p/python-twitter/python-twitter_0.5-1.dsc * it should be Architecture: all package, not any + build your package in binary-indep + remove dh_makeshlibs, dh_shlibdeps (BTW: you've missed dh_strip) from rules + you can remove all build rule content (leave it empty) + move as many packages as you can from Build-Depends to Build-Depends-Indep * FTBFS (dh_install: python-twitter missing files (debian/tmp/*), aborting) * bump python-support required version to = 0.6.4 or make sure (in debian/rules) that .egg directory has the right name * remove hashbang from twitter.py (via patch or using sed in debian/rules) * s/python/Python in long desc. * remove (s) from Upstream Author(s) in debian/copyright (there's only one author listed there) * add dh_compress -X.py in binary-indep rule * consider installing scripts from examples directory in /usr/bin/ (without .py in file name) * use `lintian -i python-twitter_*.changes` before sending RFS mail -- http://people.debian.org/~piotr/sponsor.txt pgpmaDBoMGvVc.pgp Description: PGP signature
Re: Config files which are writable by www-data
On Sun, Feb 10, 2008 at 12:02:02PM +0100, Roland Gruber wrote: Matthew Palmer schrieb: Well, don't do that, then. Ship the template files somewhere else, and then copy them into /var if they're not already there. that is probably the best solution. I think I will put them in /usr/share/doc/ldap-account-manager/examples and copy them from there to /var. Except that the contents of /usr/share/doc must not be relied upon for the proper functioning of your package. Somewhere under /usr/share/l-a-m is the correct place for these sorts of things. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dictconv (5th try)
Hi, On sab, 2008-02-09 at 19:22 +, Neil Williams wrote: [CUT] Francesco - I notice this is the 5th try for this package. I don't remember seeing a long description, maybe that would help? Yes, of course: Description: convert a dictionary file type in another dictionary file type Currently, it supports converting from Babylon glossaries, Freedict dictionaries, Sdictionary dictionaries and Stardict dictionaries to DICT dictionaries, plain text dictionaries and StarDict dictionaries. More file types will be added in new versions. I've found it very useful converting babylon dictionaries, now I can use these in stardict... Cheers, francesco -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Config files which are writable by www-data
Hi Matt, Matthew Palmer schrieb: Except that the contents of /usr/share/doc must not be relied upon for the proper functioning of your package. Somewhere under /usr/share/l-a-m is the correct place for these sorts of things. but when I copy the files at install time (postinst) then /usr/share/doc should be no problem? If the administrator deletes the files in /usr/share/doc afterwards then my application will have no problems. Best regards Roland signature.asc Description: OpenPGP digital signature
Re: RFS: dictconv (5th try)
Hi David, On sab, 2008-02-09 at 20:04 +0100, David Paleino wrote: 1) why is it Priority: extra? Put it Priority: optional, if there is no specific reason to put it as extra; I don't know what happened here... I'll fix this in the next upload to mentors. thanks for the comments. Cheers, francesco -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
RFS: lisaac (updated package)
Dear mentors, I am looking for a sponsor and feedback for the new version 1:0.13-1 of my package lisaac. It builds these binary packages: lisaac - Object-oriented language base on prototype lisaac-common - Arch-independent part for lisaac lisaac-doc - Documentation for lisaac lisaac-mode - Emacs mode for editing Lisaac programs The package appears to be lintian clean. The upload would fix these bugs: 434920, 440426, 463065 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/lisaac - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/lisaac/lisaac_0.13-1.dsc I would be glad if someone uploaded this package for me. Kind regards Picca Frédéric
RFS: stormbaancoureur
Hi folks, I know I've been asking for a lot of uploads lately but I would REALLY appreciate if someone could look at this one for me. This is the third new upstream I've packaged that hasn't been uploaded yet. Upstream was gracious enough to replace the potentially non-free engine.tga so this one should be good to go. http://mentors.debian.net/debian/pool/main/s/stormbaancoureur/stormbaancoureur_2.1.1-1.dsc Thanks as always!! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: uncrustify (updated package) (second try)
Dear mentors, I am looking for a sponsor for the new version 0.43-1 of my package uncrustify. It builds these binary packages: uncrustify - C, C++, C#, D, Java and Pawn source code beautifier The package appears to be lintian clean. The upload would fix these bugs: 461631 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/uncrustify - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/uncrustify/uncrustify_0.43-1.dsc I would be glad if someone uploaded this package for me. Kind regards Johann Rudloff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Long descriptions in RFS emails.
Just a note for everyone - I will now ignore any RFS that does not include the long description for the package. It doesn't matter how many times you ping, without a long description posted to *this* list, I will no longer waste time either asking for one or reviewing your package and your RFS is likely to be deleted without any further action. http://people.debian.org/~codehelp/#sponsor -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Config files which are writable by www-data
Am 2008-02-09 10:09:13, schrieb Roland Gruber: Hi all, I am the maintainer of ldap-account-manager and got bug 462192. The problem is that my application provides a set of default templates for user creation. These files must be editable via the application itself and therefore reside in /var/ldap-account-manager. But the files are overwritten on every package installation because they are not treated as config files in Debian's sense. Now I think about moving the files to /etc. But Debian policy sais that files in /etc should be owned by root and writable only by the user. So what can I do? Would it be ok to assign these files to group www-data and allow the group write access? Or would it be better to own them by www-data and not root? Was there not a debian/conffiles or something similar? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Lintian: outdated-autotools-helper-file
Hi *, I'm packaging gnome-translate (ITP #292909), and everything builds fine. A lintian check on the .changes file throws: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 N: N: The referenced file has a time stamp older than year 2004 and the N: package does not build-depend on autotools-dev or automake and N: therefore apparently does not update it. This usually means that the N: source package will not work correctly on all currently released N: architectures. N: E: gnome-translate source: outdated-autotools-helper-file config.sub 2003-07-04 What am I supposed to do? I believe that Build-Depending on autotools-dev | automake is not sufficient, as it seems that those files won't be updated anyways. Should I update them manually? This will introduce those changes in the .diff.gz outside the debian/ dir (and, AFAICT, keeping only debian/ into the .diff.gz is The Right Thing). Any suggestion is very welcome. Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Config files which are writable by www-data
Roland Gruber [EMAIL PROTECTED] writes: Matthew Palmer schrieb: Except that the contents of /usr/share/doc must not be relied upon for the proper functioning of your package. Somewhere under /usr/share/l-a-m is the correct place for these sorts of things. but when I copy the files at install time (postinst) then /usr/share/doc should be no problem? If the administrator deletes the files in /usr/share/doc afterwards then my application will have no problems. No, you're not allowed to reference /usr/share/doc from maintainer scripts. dpkg may be modified to not install /usr/share/doc at all. You should ship them in /usr/share/package and add a symlink in /usr/share/doc if desired. See Policy 12.3. -- 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: outdated-autotools-helper-file
On Sun, 10 Feb 2008 13:40:07 -0600 Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: Build-Depend on autotools-dev, move the ofending files aside and put the new copy in thier place before running ./configure, copy the originals back at the end of clean. Autotools-dev's documentation contains an explanation for all this dance, and code snippets, IIRC. Many thanks to you and Henrique (Gracias / Obrigado) :) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Lintian: outdated-autotools-helper-file
On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote: Hi *, I'm packaging gnome-translate (ITP #292909), and everything builds fine. A lintian check on the .changes file throws: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 What am I supposed to do? I believe that Build-Depending on autotools-dev | automake is not sufficient, as it seems that those files won't be updated anyways. Should I update them manually? This will introduce those changes in the .diff.gz outside the debian/ dir Build-Depend on autotools-dev, move the ofending files aside and put the new copy in thier place before running ./configure, copy the originals back at the end of clean. Autotools-dev's documentation contains an explanation for all this dance, and code snippets, IIRC. signature.asc Description: Digital signature
Re: Lintian: outdated-autotools-helper-file
On Sun, 10 Feb 2008, David Paleino wrote: I'm packaging gnome-translate (ITP #292909), and everything builds fine. A lintian check on the .changes file throws: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 N: N: The referenced file has a time stamp older than year 2004 and the N: package does not build-depend on autotools-dev or automake and N: therefore apparently does not update it. This usually means that the N: source package will not work correctly on all currently released N: architectures. N: E: gnome-translate source: outdated-autotools-helper-file config.sub 2003-07-04 What am I supposed to do? I believe that Build-Depending on autotools-dev | automake is not sufficient, as it seems that those files won't be updated anyways. Should I update them manually? This will introduce those changes in the .diff.gz outside the debian/ dir (and, AFAICT, keeping only debian/ into the .diff.gz is The Right Thing). Any suggestion is very welcome. Read autotools-dev's README file, it has recipes for what you want (that won't even increase diff size). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-twitter
On Feb 10, 2008 9:37 AM, Piotr Ożarowski [EMAIL PROTECTED] wrote: [Mauro Lizaur, 2008-02-09 11:43] - dget http://mentors.debian.net/debian/pool/main/p/python-twitter/python-twitter_0.5-1.dsc * it should be Architecture: all package, not any + build your package in binary-indep + remove dh_makeshlibs, dh_shlibdeps (BTW: you've missed dh_strip) from rules + you can remove all build rule content (leave it empty) + move as many packages as you can from Build-Depends to Build-Depends-Indep * FTBFS (dh_install: python-twitter missing files (debian/tmp/*), aborting) * bump python-support required version to = 0.6.4 or make sure (in debian/rules) that .egg directory has the right name * remove hashbang from twitter.py (via patch or using sed in debian/rules) * s/python/Python in long desc. * remove (s) from Upstream Author(s) in debian/copyright (there's only one author listed there) * add dh_compress -X.py in binary-indep rule * consider installing scripts from examples directory in /usr/bin/ (without .py in file name) * use `lintian -i python-twitter_*.changes` before sending RFS mail -- http://people.debian.org/~piotr/sponsor.txt Thanks Piotr for the advices, i'll check this things and will reuplopad it. Regards, Mauro
Re: RFS: uncrustify (updated package) (second try)
Hi, since I left it out in the previous mail, I add some description of the package to my RFS: uncrustify: C, C++, C#, D, Java and Pawn source code beautifier Uncrustify is a highly configurable source code formatter. It aligns preprocessor define's, assigments, arithmetics and is able to fix spacing between operators. The bug that will be fixed by the upload appears, because the current version of uncrustify in the archive is too old, so it can't be used with UniversalIndentGUI (a GUI for several source code indenters) which is in Debian, too. The locations of the package: - URL: http://mentors.debian.net/debian/pool/main/u/uncrustify - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/uncrustify/uncrustify_0.43-1.dsc Johann Rudloff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: talkfilters
Dear mentors, I am looking for a sponsor for my package talkfilters. * Package name: talkfilters Version : 2.3.8-1 Upstream Author : Various, see #465086 * URL : http://www.hyperrealm.com/main.php?s=talkfilters * License : GPL-2, PD Section : games It builds these binary packages: libtalkfilters-dbg [1] - convert English text into humorous dialects - debug symbols libtalkfilters-dev - convert English text into humorous dialects - headers libtalkfilters1 - convert English text into humorous dialects - libraries talkfilters - convert English text into humorous dialects The GNU Talk Filters are filter programs that convert ordinary English text into text that mimics a stereotyped or otherwise humorous dialect. These filters have been in the public domain for many years, but now for the first time they are provided as a single integrated package. The filters include: austro, b1ff, brooklyn, chef, cockney, drawl, dubya, fudd, funetak, jethro, jive, kraut, pansy, pirate, postmodern, redneck, valspeak and warez. Each program reads from standard input and writes to standard output. The package is lintian clean, but has two overrides: talkfilters: package-section-games-but-has-usr-bin talkfilters: info-document-missing-dir-section usr/share/info/talkfilters.info.gz The first because there's just one tool in /usr/bin/, wrap, with its own manpage. All the other binaries belong to /usr/games. The latter is because I don't really know how to fix it :) The upload would fix #465086 The package can be found at the usual location: http://mentors.debian.net/debian/pool/main/t/talkfilters/talkfilters_2.3.8-1.dsc I would be glad if someone uploaded this package for me. Kindly, David [1] it contains both debugging symbols for libtalkfilters1 and talkfilters. Should I make separate -dbg packages, is it ok, or should I call it talkfilters-dbg? -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: uncrustify (updated package) (second try)
Am Sonntag, 10. Februar 2008 15:57:45 schrieb Johann Rudloff:
Dear mentors,
I am looking for a sponsor for the new version 0.43-1
of my package uncrustify.
It builds these binary packages:
uncrustify - C, C++, C#, D, Java and Pawn source code beautifier
The package appears to be lintian clean.
I'll sponsor you after some issues are fixed:
- remove config.{sub|guess} in clean target
- you forgot to mention in changelog that you added a Homepage tag to
debian/control
- you forgot to mention that you removed autotools-dev as Build-Dep
- you forgot to mention that you changed the manpage
I found these issues after a very quick check by diffing your new version
with the old one.
Greetings
Winnie
--
.''`. Patrick Winnertz [EMAIL PROTECTED]
: :' : GNU/Linux Debian Developer
`. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: This is a digitally signed message part.
Re: Lintian: outdated-autotools-helper-file
On Sun, 10 Feb 2008 23:10:20 +0100 Adam Borowski [EMAIL PROTECTED] wrote: On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz wrote: Build-Depend on autotools-dev, move the ofending files aside and put the new copy in thier place before running ./configure, copy the originals back at the end of clean. Or, instead of saving the originals, just delete them. dpkg-source ignores all deletions. That's great, I can safely remove all that [ -f ... ] || cp ... dance from my debian/rules. Thank you! David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Lintian: outdated-autotools-helper-file
Am Sonntag, den 10.02.2008, 17:30 -0200 schrieb Henrique de Moraes Holschuh: On Sun, 10 Feb 2008, David Paleino wrote: I'm packaging gnome-translate (ITP #292909), and everything builds fine. A lintian check on the .changes file throws: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 [..] Read autotools-dev's README file, it has recipes for what you want (that won't even increase diff size). I wrote a report against lintian to add a reference to the README in the long description. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Long descriptions in RFS emails.
Neil Williams [EMAIL PROTECTED] writes: Just a note for everyone - I will now ignore any RFS that does not include the long description for the package. It doesn't matter how many times you ping, without a long description posted to *this* list, I will no longer waste time either asking for one or reviewing your package and your RFS is likely to be deleted without any further action. A good policy except that I'd recommend you respond to at least some of them to say *why* you think they're worth ignoring. Many people posting to this list cannot be expected to know your policy since they're here for the first time. I agree in the main with the majority of your sponsoring considerations, and I'd love for prospective maintainers to be educated on them as good practice. -- \ “Sittin’ on the fence, that’s a dangerous course / You | `\ can even catch a bullet from the peace-keeping force” —Dire | _o__) Straits, _Once Upon A Time In The West_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz wrote: On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 What am I supposed to do? I believe that Build-Depending on autotools-dev | automake is not sufficient, as it seems that those files won't be updated anyways. Should I update them manually? This will introduce those changes in the .diff.gz outside the debian/ dir Build-Depend on autotools-dev, move the ofending files aside and put the new copy in thier place before running ./configure, copy the originals back at the end of clean. Or, instead of saving the originals, just delete them. dpkg-source ignores all deletions. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
Adam Borowski wrote: On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz wrote: On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 What am I supposed to do? I believe that Build-Depending on autotools-dev | automake is not sufficient, as it seems that those files won't be updated anyways. Should I update them manually? This will introduce those changes in the .diff.gz outside the debian/ dir Build-Depend on autotools-dev, move the ofending files aside and put the new copy in thier place before running ./configure, copy the originals back at the end of clean. Or, instead of saving the originals, just delete them. dpkg-source ignores all deletions. Quoting the Debian Policy, section 4.9 Main building script: debian/rules[1] clean This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. So according to the policy the clean target must put the original files back on place. [1]http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: talkfilters
Please see http://kitenet.net/~joey/code/filters/talkfilters-email : | How did you manage to get valspeak, postmodern, pansy, and fudd, whose | authors are unknown to be GPLed? According to the info page, | | While all of these filters have been available in one form or | another in the public domain for many years, the original authors of | some of the filters are unknown. Reasonable attempts were made to find | the authors and obtain written permission to repackage the filters as | GNU software, but in some cases they could not be located. | | It seem to me questonable to slap the GPL and a FSF copyright on a file | just because it is being distributed about the net. So I have some | doubts about the validity of the copyright of some of the talkfilters. I | would not be comfortable putting them in the Debian distribution with | thieir copyright in this state. :-/ Its maintainer never responded to that message. Also, your package conflicts with many of the files contained in the filters package. -- see shy jo signature.asc Description: Digital signature
RFS: iolanguage
Dear mentors, I am looking for a sponsor for my package iolanguage. * Package name: iolanguage Version : 20080209-1 Upstream Author : Steve Dekorte [EMAIL PROTECTED] * URL : http://www.iolanguage.com/ * License : Revised BSD Section : interpreters It builds these binary packages: iolanguage - The Io programming language iolanguage-asyncrequest - The AsyncRequest addon for the Io language iolanguage-bignum - The BigNum addon for the Io language iolanguage-blowfish - The Blowfish addon for the Io language iolanguage-box - The Box addon for the Io language iolanguage-cairo - The Cairo addon for the Io language iolanguage-cgi - The CGI addon for the Io language iolanguage-continuedfraction - The ContinuedFraction addon for the Io language iolanguage-curses - The Curses addon for the Io language iolanguage-dbi - The DBI addon for the Io language iolanguage-doc - Documentation for Io programming language iolanguage-editline - The EditLine addon for the Io language iolanguage-flux - The Flux addon for the Io language iolanguage-flux-data - The Flux addon's data files iolanguage-fnmatch - The Fnmatch addon for the Io language iolanguage-font - The Font addon for the Io language iolanguage-hdb - The HDB addon for the Io language iolanguage-image - The Image addon for the Io language iolanguage-interpreter - The Io programming language interpreter iolanguage-libsndfile - The Libxml2 addon for the Io language iolanguage-libxml2 - The LibSndFile addon for the Io language iolanguage-lzo - The LZO addon for the Io language iolanguage-md5 - The MD5 addon for the Io language iolanguage-mysql - The MySQL addon for the Io language iolanguage-notificationcenter - The NotificationCenter addon for the Io language iolanguage-opengl - The OpenGL addon for the Io language iolanguage-postgres - The Postgres addon for the Io language iolanguage-postgresql - The PostgreSQL addon for the Io language iolanguage-python - The Python addon for the Io language iolanguage-qdbm - The QDBM addon for the Io language iolanguage-random - The Random addon for the Io language iolanguage-range - The Range addon for the Io language iolanguage-rational - The Rational addon for the Io language iolanguage-readline - The ReadLine addon for the Io language iolanguage-regex - The Regex addon for the Io language iolanguage-samplerateconverter - The SampleRateConverter addon for the Io language iolanguage-sha1 - The SHA1 addon for the Io language iolanguage-socket - The Socket addon for the Io language iolanguage-soundtouch - The SoundTouch addon for the Io language iolanguage-sqldatabase - The SqlDatabase addon for the Io language iolanguage-sqlite - The SQLite addon for the Io language iolanguage-sqlite3 - The SQLite3 addon for the Io language iolanguage-standalone - The Io programming language interpreter (standalone version) iolanguage-syslog - The Syslog addon for the Io language iolanguage-systemcall - The SystemCall addon for the Io language iolanguage-taglib - The TagLib addon for the Io language iolanguage-thread - The Thread addon for the Io language iolanguage-user - The User addon for the Io language iolanguage-uuid - The UUID addon for the Io language iolanguage-zlib - The Zlib addon for the Io language libiovmall0 - The Io programming language virtual machine library libiovmall0-dev - Development file for the Io programming language The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/iolanguage - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/iolanguage/iolanguage_20080209-1.dsc The package builds upon previous work by Bram Neijt [EMAIL PROTECTED]. It is co-maintained together with Danya Alexeyevsky [EMAIL PROTECTED]. I would be glad if someone uploaded this package for me. Kind regards Jonas Eschenburg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Long descriptions in RFS emails.
On Mon, 2008-02-11 at 08:37 +1100, Ben Finney wrote: Neil Williams [EMAIL PROTECTED] writes: Just a note for everyone - I will now ignore any RFS that does not include the long description for the package. It doesn't matter how many times you ping, without a long description posted to *this* list, I will no longer waste time either asking for one or reviewing your package and your RFS is likely to be deleted without any further action. A good policy except that I'd recommend you respond to at least some of them to say *why* you think they're worth ignoring. The debian-mentors FAQ does recommend more than the bare bones of the RFS already. My sponsoring requirements are also linked from the debian-mentors pages. I have been responding to at least some of these inadequate RFS emails in the past. I do not have the time to continue. I feel it is more appropriate to simply ignore badly formed RFS emails en masse. Many people posting to this list cannot be expected to know your policy since they're here for the first time. I can and do expect that people using debian-mentors for the first time follow the advice on the debian-mentors FAQ. The FAQ specifies that the template is insufficient, yet I continue to see RFS emails that are no better than the template. Mentors has, IMHO, again become a dumping ground for inadequate packages from lazy maintainers, wasting sponsoring/reviewing time on packages that are poorly prepared, sometimes not even lintian clean and where maintainers do not appear to care about preparing an RFS beyond filling in some gaps in a template. I am glad to work with those maintainers who stand out from such a dire crowd and I will continue to do so. Those who take some time over the preparation of packages and show some level of effort in at least applying the principles of the FAQ deserve my support and as I have limited time, I therefore choose to prioritise my support to those who take the time to do the work. Those who cannot be bothered to follow a link and who appear to be able to little more than join the dots do not deserve my time. Sorry. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Bug#465086: RFS: talkfilters
On Sun, 10 Feb 2008 17:48:43 -0500 Joey Hess [EMAIL PROTECTED] wrote: Please see http://kitenet.net/~joey/code/filters/talkfilters-email : | How did you manage to get valspeak, postmodern, pansy, and fudd, whose | authors are unknown to be GPLed? According to the info page, | | While all of these filters have been available in one form or | another in the public domain for many years, the original authors of | some of the filters are unknown. Reasonable attempts were made to find | the authors and obtain written permission to repackage the filters as | GNU software, but in some cases they could not be located. | | It seem to me questonable to slap the GPL and a FSF copyright on a file | just because it is being distributed about the net. So I have some | doubts about the validity of the copyright of some of the talkfilters. I | would not be comfortable putting them in the Debian distribution with | thieir copyright in this state. :-/ Its maintainer never responded to that message. I did not notice that discrepancy between the info page and the copyright headers. In my debian/copyright [1] I tried to catch the most information possible. But I admit I did not try to contact upstream, sorry. Also, your package conflicts with many of the files contained in the filters package. Sure, sorry for that. Is there any chance for filter to provide a libfilters library to interface with? I've packaged talkfilters because it was a possible use of libtranslate [2] [3], but that's not really necessary. I could try to patch it so that it uses your filters package, but that would need a library to use. In the meanwhile, I'll rebuild libtranslate disabling support for talkfilters, so that it (together with gnome-translate) can be uploaded. Thank you for spotting the problem, David [1] http://svn.debian.org/wsvn/collab-maint/deb-maint/talkfilters/trunk/debian/copyright?op=filerev=0sc=0 -- I'll remove the whole package from SVN if needed. [2] http://bugs.debian.org/292907 [3] http://bugs.debian.org/418329 -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: talkfilters
On Sun, Feb 10, 2008 at 10:08:29PM +0100, David Paleino wrote: talkfilters - convert English text into humorous dialects The GNU Talk Filters are filter programs that convert ordinary English text into text that mimics a stereotyped or otherwise humorous dialect. These filters have been in the public domain for many years, but now for the first time they are provided as a single integrated package. The filters include: austro, b1ff, brooklyn, chef, cockney, drawl, dubya, fudd, funetak, jethro, jive, kraut, pansy, pirate, postmodern, redneck, valspeak and warez. Each program reads from standard input and writes to standard output. Too bad, there's a lot of file conflicts with Joey Hess' filters which serve the same purpose. In fact, filters which conflict are either very same files or reimplementations of those due to license problems. Another issue is, the sources have been mostly gathered from random Usenet posts instead of being confirmed to be really in public domain. We had filters-nonfree in Debian for years, then they were either liberated, reimplemented or dropped. Mark Lindner's package lists many of authors as (unknown), what, together with these source files having no author attributions but just a GPL boilerplate, puts some doubts whether they are not simply copied together. I would really discuss this with Joey Hess first, he can shed a lot of light on the issue. I don't know the details, he does. And third thing, the claim that now for the first time they are provided as a single integrated package is obviously invalidated by Debian's filters being here since 1996 while Mark Lindner's talkfilters seem to be dated 1998, judging by the first ChangeLog entry. Just my two zorkmids... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libtranslate
Dear mentors, I am looking for a sponsor for my package libtranslate. * Package name: libtranslate Version : 0.99-1 Upstream Author : Jean-Yves Lefort [EMAIL PROTECTED] * URL : http://www.nongnu.org/libtranslate * License : BSD-3 Section : libs It builds these binary packages: libtranslate-bin - command line translator libtranslate-dbg - library for translating text and web pages - debug symbols libtranslate-dev - development files for libtranslate libtranslate-doc - documentation for libtranslate libtranslate0 - library for translating text and web pages libtranslate is a library for translating text and web pages between natural languages. Its modular infrastructure allows the implementation of new translation services separately from the core library. The modular infrastructure of the long description refers to the fact that libtranslate can be easily expanded: all the translation services are, in fact, stored in a XML file. And the manpage clearly explains how to implement new services! :) The library supports two modules: generic and talkfilters. The talkfilters module is currently disabled, because of copyright issues with its contents (please see #465086 for further info, it's my ITP for talkfilters). If the issues are solved in future, the module will be enabled. The original source code provides a /usr/bin/translate program, which conflicted with translate's homonymous (please see #464034). Upstream and I agreed to rename the binary to ntranslate [1]. I believe that the relative package could also be called ntranslate instead of libtranslate-bin; please tell me what you think about this. The package is lintian (1.23.45) clean. The upload would fix ITPs #292907 and #418329 The package can be found on mentors.debian.net: http://mentors.debian.net/debian/pool/main/l/libtranslate/libtranslate_0.99-1.dsc I would be glad if someone uploaded this package for me. Regards, David [1] http://lists.debian.org/debian-devel/2008/02/msg00421.html -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Bug#465086: RFS: talkfilters
David Paleino wrote: Is there any chance for filter to provide a libfilters library to interface with? I've packaged talkfilters because it was a possible use of libtranslate [2] [3], but that's not really necessary. I could try to patch it so that it uses your filters package, but that would need a library to use. filters has programs written some in perl and some in lex, so that's not really possible to do a shared library. The talkfilters frankly seem like a better implementation, if they would only not be so apparently cavalier about copyright. -- see shy jo signature.asc Description: Digital signature
Re: RFS: talkfilters
On Mon, 11 Feb 2008 00:12:28 +0100 Adam Borowski [EMAIL PROTECTED] wrote: Too bad, there's a lot of file conflicts with Joey Hess' filters which serve the same purpose. In fact, filters which conflict are either very same files or reimplementations of those due to license problems. Please see the ITP bug for talkfilters, #465086. Joey already contacted me, and I wasn't aware of his package (my fault, sorry :(). I've already asked him if he could make a library to be used as interface for other programs (like the pacakge I prepared does). In the meanwhile, I've prepared a stripped-down version of libtranslate (just posted the RFS), which has talkfilters support enabled. We can always enable them later, with Joey's package! ;) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Long descriptions in RFS emails.
Neil Williams [EMAIL PROTECTED] writes: On Mon, 2008-02-11 at 08:37 +1100, Ben Finney wrote: A good policy except that I'd recommend you respond to at least some of them to say *why* you think they're worth ignoring. Those who take some time over the preparation of packages and show some level of effort in at least applying the principles of the FAQ deserve my support and as I have limited time, I therefore choose to prioritise my support to those who take the time to do the work. A reasonable position. Well, thanks for making your policies available for reference by others, and for keeping them up to date. -- \“We have to go forth and crush every world view that doesn't | `\believe in tolerance and free speech.” —David Brin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#465086: RFS: talkfilters
On Sun, Feb 10, 2008 at 06:17:55PM -0500, Joey Hess wrote: David Paleino wrote: Is there any chance for filter to provide a libfilters library to interface with? I've packaged talkfilters because it was a possible use of libtranslate [2] [3], but that's not really necessary. I could try to patch it so that it uses your filters package, but that would need a library to use. There's always pipe() and exec()... filters has programs written some in perl and some in lex, so that's not really possible to do a shared library. ... and yacc, and pure C. Yet, all are either in a form of C (9) or Perl (15), so in theory one could link a Perl interpreter to it. Yet, IMHO the complexity isn't worth it. Creating a process costs less than loading the translation data for a real language anyway, and keeps it possible to write filters in Python (bleh) or Ada... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
Raphael Geissert [EMAIL PROTECTED] writes: Quoting the Debian Policy, section 4.9 Main building script: debian/rules[1] clean This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. So according to the policy the clean target must put the original files back on place. This Policy dictate as written is pretty widely ignored and (IMO) is somewhat hard to defend in several of its implications. We haven't figured out what to say instead, but deleting the files is fairly common right now. See http://bugs.debian.org/397939 for some additional discussion. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Help with watch file -- pre-release upstream versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi mentors, What's the usual way of handling preX upstream version numbers in watch files? I'm having trouble because uscan considers 1.0pre3 newer than 1.0. Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHr6OsGJRwVVqzMkMRAkGJAJ9vz5f/dhC35Himh3yVF//w4PLXdQCdGSbo mZRhO3+yq2PIqkwxA4iNWvQ= =3dvl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: QA Upload -- mma - Musical Midi Accompaniment generator
Hi, Just an upload to set QA to maintainer and bring standards, et al up to date. Package should really probably be removed but we can see if someone adopts it first I suppose. http://mentors.debian.net/debian/pool/main/m/mma/mma_0.12-2.dsc MMA creates midi tracks for a soloist to perform over from a user supplied file containing chords and MMA directives. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help with watch file -- pre-release upstream versions
Hi, Székelyi Szabolcs wrote: What's the usual way of handling preX upstream version numbers in watch files? I'm having trouble because uscan considers 1.0pre3 newer than 1.0. Perhaps mangling the upstream version to use the tilde (~) as a separator? But I don't really know if uscan even recognizes it... Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Help with watch file -- pre-release upstream versions
Székelyi Szabolcs [EMAIL PROTECTED] writes: What's the usual way of handling preX upstream version numbers in watch files? I'm having trouble because uscan considers 1.0pre3 newer than 1.0. opts=uversionmangle=s/pre/~pre/ -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFS: python-twitter
On Feb 10, 2008 9:37 AM, Piotr Ożarowski [EMAIL PROTECTED] wrote: * it should be Architecture: all package, not any + build your package in binary-indep + remove dh_makeshlibs, dh_shlibdeps (BTW: you've missed dh_strip) from rules + you can remove all build rule content (leave it empty) + move as many packages as you can from Build-Depends to Build-Depends-Indep * FTBFS (dh_install: python-twitter missing files (debian/tmp/*), aborting) * bump python-support required version to = 0.6.4 or make sure (in debian/rules) that .egg directory has the right name * remove hashbang from twitter.py (via patch or using sed in debian/rules) * s/python/Python in long desc. * remove (s) from Upstream Author(s) in debian/copyright (there's only one author listed there) * add dh_compress -X.py in binary-indep rule * consider installing scripts from examples directory in /usr/bin/ (without .py in file name) * use `lintian -i python-twitter_*.changes` before sending RFS mail Hello Piotr, i did all the changes you've recommended me to do. Btw, i added a few lines to install the examples in /usr/bin (one of them is a mini client) the FTBFS bug was because of i forgot to remove an (old) install file. I used pbuilder to test that it actually builds OK and it and worked fine, also i did used lintian to test the changes file and is clean well, here is the url: http://mentors.debian.net/debian/pool/main/p/python-twitter/python-twitter_0.5-1.dsc if you see anything else that i should work on, just tell me. Thanks, Mauro -- BEGIN GEEK CODE BLOCK Version: 3.12 GCM/O d-dpu$ s-:- a--a+++$ C+++ LU P+ L++ E W+++ N !o K w O !M !V PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e h!h-- rr+++ y+ END GEEK CODE BLOCK
Re: Long descriptions in RFS emails.
On Sunday 10 February 2008 10:13:50 am Neil Williams wrote: Just a note for everyone - I will now ignore any RFS that does not include the long description for the package. It doesn't matter how many times you ping, without a long description posted to *this* list, I will no longer waste time either asking for one or reviewing your package and your RFS is likely to be deleted without any further action. http://people.debian.org/~codehelp/#sponsor I actually thought anything that's not part of the template would be considered cruft, thus I avoided adding anything extra to any RFS I sent. I also avoided writing an RFS that didn't look like the template since I thought the template was all the information any sponsor would need and in a format that's easily readable by anyone. Perhaps it's best to include where the description and other information should go. I'm thinking something like: From: maintainer's name [EMAIL PROTECTED] To: debian-mentors@lists.debian.org Subject: RFS: package -- short description Dear mentors, I am looking for a sponsor for my package package. * Package name: package Version : version Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : section Description : long description . . . Reason: In case the long description is not the appropriate place for a reason, maybe a reason section could be added, describing why this package should be included in Debian (example: it helps these Debian users, it's needed by this other useful package, etc.). It builds these binary packages: binary-package - binary package short description next-binary-package - next binary package short description . . . The package appears to be lintian clean. The upload would fix these bugs: XX . . . The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/package - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/package/package_version.dsc Note: Any special notes that a sponsor (or anyone) would need to be aware of should probably go here. I would be glad if someone uploaded this package for me. Kind regards maintainer's name Also, the update template should probably include the Reason section right before the section where it lists the binary packages that are built. Here a maintainer should add stuff like: Reason: This is a new upstream. It fixes a security issue that allowed this and that. etc. . . . -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: deejayd
Dear mentors, I am looking for a sponsor for my package deejayd. * Package name: deejayd Version : 0.6.3-1 Upstream Author : Mickaël Royer [EMAIL PROTECTED] * URL : http://mroy31.dyndns.org/~roy/projects/deejayd/ * License : GPL Section : sound It builds these binary packages: deejayd- Network media player daemon deejayd-client - Client library to access the deejayd server deejayd-gstreamer - Deejayd GStreamer backend deejayd-webui - Web interface for deejayd deejayd-xine - Deejayd XINE backend djc- Command line basic client to the deejayd server The package appears to be lintian clean. The upload would fix these bugs: 463973 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/deejayd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/deejayd/deejayd_0.6.3-1.dsc I would be glad if someone uploaded this package for me. Cheers, Alexandre
