Re: Sponsor for popfile
On Tue, Jul 29, 2003 at 15:57 -0300, Lucas Wall wrote: > Hi! > > I'm looking for a sponsor. I have the following package ready for > examination: > > POPFile is an email classification tool with a Naive Bayes classifier, > a POP3 proxy and a web interface. It runs on most platforms and with > most email clients. > > package: http://www.kadath.com.ar/popfile/ > upstream: http://popfile.sourceforge.net > > Thanks! > > K. Hello Lucas, After a quick check, I've found the following problems with your package: · The package is not lintian clean yet. · In debian/changelog, there is no 'closes #203349' to close ITP bug #203349. · In debian/control, the short description shouldn't start with 'An' and end with '.', see [1]. [1] http://www.debian.org/doc/developers-reference/ch-best-pkging-practices..en.html#s-bpp-pkg-synopsis Regards, Aníbal Monsalve Salazar -- .''`. Debian GNU/Linux | Building 28C : :' : Free Operating System | Monash University VIC 3800 `. `' http://debian.org/| Australia `- | pgp0.pgp Description: PGP signature
Re: ITA wmakerconf, wmakerconf-data (will need a sponsor)
Kevin B. McCarty wrote: > > I am adopting wmakerconf and wmakerconf-data packages -- I've already > debianized the newest upstream versions (2.9 and 0.80.0 respectively) and > fixed a few outstanding bugs. Being a non-maintainer, I'll need a sponsor > -- would anyone like to volunteer? i have agreed to sponsor these packages. -john
Re: tagging bugs "woody"?
Andreas Metzler wrote: > Frank Kuster wrote: > >users working with Debian woody often do not look at archived bugs when > >reporting bugs on a package. Therefore it is likely that bugs that have > >long been fixed in unstable, but will never be in woody will be reported > >multiple times again. I have been a victim of this problem myself. > Imvvvho this a matter of personal taste, and the manual (the part I > snipped) can be taken as guideline instead of as bible. Personaly I'd > keep only these bugs open which _really_ get reported at least twice, > otherwise the BTS is to messy for me to work with. I believe there are many people that look for bugs, won't find them, but won't report them either. Even if people do not report a bug it benefits from from being able to see the bug in the BTS. In this way the BTS acts as a knowledge database. Therefore I would like to see bugs in stable kept open until the next stable fixes them. I realize there are technical issues to be resolved in the BTS in this area. Bob pgpNM2Lb6tWoX.pgp Description: PGP signature
Re: Control fields for libraries and programs depending on them
On Tue, Jul 29, 2003 at 08:06:38PM -0400, Neil Roeth wrote: > Suppose there is a package foobar that depends on a library libfoo. AIUI, > whenever the SONAME changes, the library name should change, so I expect > this to evolve as libfoo1, libfoo2, etc. What are the proper control > fields (Depends, Conflicts, Replaces, Provides) for these packages? If I > understand correctly, the idea of having different package names for > libfoo when the SONAME changes is so that libfoo1 and libfoo2 can coexist. > So, does that mean they should not conflict, and that there should be no > Replaces or Provides fields in the libfoo2 refering to libfoo1? Yes. You can find many examples in the packages in the archive. > I am particularly interested in the case where foobar and libfoo1 are > installed, and a new version of foobar is released that depends upon > libfoo2. Should upgrading foobar cause libfoo2 to be installed, but also > leave libfoo1 installed, since some other package might depend upon it? Upgrading foobar will require that libfoo2 be installed; it should not have any direct effect on libfoo1 (though aptitude, for example, will automatically remove libfoo1 if it only existed to satisfy foobar's dependency). -- - mdz
Re: ITA wmakerconf, wmakerconf-data (will need a sponsor)
Kevin B. McCarty wrote: > > I am adopting wmakerconf and wmakerconf-data packages -- I've already > debianized the newest upstream versions (2.9 and 0.80.0 respectively) and > fixed a few outstanding bugs. Being a non-maintainer, I'll need a sponsor > -- would anyone like to volunteer? i have agreed to sponsor these packages. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tagging bugs "woody"?
Andreas Metzler wrote: > Frank Kuster wrote: > >users working with Debian woody often do not look at archived bugs when > >reporting bugs on a package. Therefore it is likely that bugs that have > >long been fixed in unstable, but will never be in woody will be reported > >multiple times again. I have been a victim of this problem myself. > Imvvvho this a matter of personal taste, and the manual (the part I > snipped) can be taken as guideline instead of as bible. Personaly I'd > keep only these bugs open which _really_ get reported at least twice, > otherwise the BTS is to messy for me to work with. I believe there are many people that look for bugs, won't find them, but won't report them either. Even if people do not report a bug it benefits from from being able to see the bug in the BTS. In this way the BTS acts as a knowledge database. Therefore I would like to see bugs in stable kept open until the next stable fixes them. I realize there are technical issues to be resolved in the BTS in this area. Bob pgp0.pgp Description: PGP signature
Control fields for libraries and programs depending on them
Suppose there is a package foobar that depends on a library libfoo. AIUI, whenever the SONAME changes, the library name should change, so I expect this to evolve as libfoo1, libfoo2, etc. What are the proper control fields (Depends, Conflicts, Replaces, Provides) for these packages? If I understand correctly, the idea of having different package names for libfoo when the SONAME changes is so that libfoo1 and libfoo2 can coexist. So, does that mean they should not conflict, and that there should be no Replaces or Provides fields in the libfoo2 refering to libfoo1? I am particularly interested in the case where foobar and libfoo1 are installed, and a new version of foobar is released that depends upon libfoo2. Should upgrading foobar cause libfoo2 to be installed, but also leave libfoo1 installed, since some other package might depend upon it? -- Neil Roeth
Re: Control fields for libraries and programs depending on them
On Tue, Jul 29, 2003 at 08:06:38PM -0400, Neil Roeth wrote: > Suppose there is a package foobar that depends on a library libfoo. AIUI, > whenever the SONAME changes, the library name should change, so I expect > this to evolve as libfoo1, libfoo2, etc. What are the proper control > fields (Depends, Conflicts, Replaces, Provides) for these packages? If I > understand correctly, the idea of having different package names for > libfoo when the SONAME changes is so that libfoo1 and libfoo2 can coexist. > So, does that mean they should not conflict, and that there should be no > Replaces or Provides fields in the libfoo2 refering to libfoo1? Yes. You can find many examples in the packages in the archive. > I am particularly interested in the case where foobar and libfoo1 are > installed, and a new version of foobar is released that depends upon > libfoo2. Should upgrading foobar cause libfoo2 to be installed, but also > leave libfoo1 installed, since some other package might depend upon it? Upgrading foobar will require that libfoo2 be installed; it should not have any direct effect on libfoo1 (though aptitude, for example, will automatically remove libfoo1 if it only existed to satisfy foobar's dependency). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Control fields for libraries and programs depending on them
Suppose there is a package foobar that depends on a library libfoo. AIUI, whenever the SONAME changes, the library name should change, so I expect this to evolve as libfoo1, libfoo2, etc. What are the proper control fields (Depends, Conflicts, Replaces, Provides) for these packages? If I understand correctly, the idea of having different package names for libfoo when the SONAME changes is so that libfoo1 and libfoo2 can coexist. So, does that mean they should not conflict, and that there should be no Replaces or Provides fields in the libfoo2 refering to libfoo1? I am particularly interested in the case where foobar and libfoo1 are installed, and a new version of foobar is released that depends upon libfoo2. Should upgrading foobar cause libfoo2 to be installed, but also leave libfoo1 installed, since some other package might depend upon it? -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sponsor for popfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I'm looking for a sponsor. I have the following package ready for examination: POPFile is an email classification tool with a Naive Bayes classifier, a POP3 proxy and a web interface. It runs on most platforms and with most email clients. package: http://www.kadath.com.ar/popfile/ upstream: http://popfile.sourceforge.net Thanks! K. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) iD8DBQE/JsOBaPMPuwG2iykRAmWoAJ4sEycnYBtiMK5YHvDogbSa8qc+owCdF4YN x3x7p0KM/HlI3/UidcdEOco= =C8VF -END PGP SIGNATURE-
Re: tagging bugs "woody"?
On 29.07.03 15:20 Frank Küster wrote: users working with Debian woody often do not look at archived bugs when reporting bugs on a package. Therefore it is likely that bugs that have long been fixed in unstable, but will never be in woody will be reported multiple times again. Therefore on debian-tetex-maint@lists.debian.org it was suggested to keep such bugs open. The "fixed" tag is appropriate for this, I assume. However, for people using unstable it would be nice to point out that the bug doesn't apply to them (and if they find similar behavior, it's a new bug). But is tagging it "woody" conformant with Debian practice? In http://www.de.debian.org/Bugs/Developer [...] Imvvvho this a matter of personal taste, and the manual (the part I snipped) can be taken as guideline instead of as bible. Personaly I'd keep only these bugs open which _really_ get reported at least twice, otherwise the BTS is to messy for me to work with. Tagging them as "fixed,woody" sounds wrong to me, they'll be listed as "closed in NMU" and will probably be rereported again. cu andreas
Sponsor for popfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I'm looking for a sponsor. I have the following package ready for examination: POPFile is an email classification tool with a Naive Bayes classifier, a POP3 proxy and a web interface. It runs on most platforms and with most email clients. package: http://www.kadath.com.ar/popfile/ upstream: http://popfile.sourceforge.net Thanks! K. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) iD8DBQE/JsOBaPMPuwG2iykRAmWoAJ4sEycnYBtiMK5YHvDogbSa8qc+owCdF4YN x3x7p0KM/HlI3/UidcdEOco= =C8VF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vimoutliner
On 2003-07-29, 01:35 GMT, Colin Watson wrote: > On Mon, Jul 28, 2003 at 11:20:29PM +0200, Matej Cepl wrote: >> I have created a package for vimoutliner. Is there anybody who would >> like to sponsor me? > [...] >> All relevant files are on >> ftp://ftp.ceplovi.cz/data/www/ceplovi/matej/progs/debian/ > > I'd be happy to, but: > > $ lftp ftp://ftp.ceplovi.cz/data/www/ceplovi/matej/progs/debian/ > cd: Access failed: 550 /data/www/ceplovi/matej/progs/debian: No such file > or directory Somebody else stepped up to the plate and uploaded for me. Thanks anyway. Matej -- Matej Cepl, GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
Re: tagging bugs "woody"?
On 29.07.03 15:20 Frank Küster wrote: users working with Debian woody often do not look at archived bugs when reporting bugs on a package. Therefore it is likely that bugs that have long been fixed in unstable, but will never be in woody will be reported multiple times again. Therefore on [EMAIL PROTECTED] it was suggested to keep such bugs open. The "fixed" tag is appropriate for this, I assume. However, for people using unstable it would be nice to point out that the bug doesn't apply to them (and if they find similar behavior, it's a new bug). But is tagging it "woody" conformant with Debian practice? In http://www.de.debian.org/Bugs/Developer [...] Imvvvho this a matter of personal taste, and the manual (the part I snipped) can be taken as guideline instead of as bible. Personaly I'd keep only these bugs open which _really_ get reported at least twice, otherwise the BTS is to messy for me to work with. Tagging them as "fixed,woody" sounds wrong to me, they'll be listed as "closed in NMU" and will probably be rereported again. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vimoutliner
On 2003-07-29, 01:35 GMT, Colin Watson wrote: > On Mon, Jul 28, 2003 at 11:20:29PM +0200, Matej Cepl wrote: >> I have created a package for vimoutliner. Is there anybody who would >> like to sponsor me? > [...] >> All relevant files are on >> ftp://ftp.ceplovi.cz/data/www/ceplovi/matej/progs/debian/ > > I'd be happy to, but: > > $ lftp ftp://ftp.ceplovi.cz/data/www/ceplovi/matej/progs/debian/ > cd: Access failed: 550 /data/www/ceplovi/matej/progs/debian: No such file or > directory Somebody else stepped up to the plate and uploaded for me. Thanks anyway. Matej -- Matej Cepl, GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC 138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tagging bugs "woody"?
Hi, users working with Debian woody often do not look at archived bugs when reporting bugs on a package. Therefore it is likely that bugs that have long been fixed in unstable, but will never be in woody will be reported multiple times again. Therefore on debian-tetex-maint@lists.debian.org it was suggested to keep such bugs open. The "fixed" tag is appropriate for this, I assume. However, for people using unstable it would be nice to point out that the bug doesn't apply to them (and if they find similar behavior, it's a new bug). But is tagging it "woody" conformant with Debian practice? In http://www.de.debian.org/Bugs/Developer it says regarding the tags with distribution names: , | The latter five tags are intended to be used mainly for release | critical bugs, for which it's important to know which distributions | are affected to make sure fixes (or removals) happen in the right | place. ` Would it still be in order to use the tag woody, now that woody has long been released? TIA, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: ITA: yadex -- WAD file editor for doom-style WADs
On Mon, Jul 28, 2003 at 08:28:32AM +, Thomas Viehmann wrote: hi, > Try "lintian -i". You've probably left "Author(s):" in there. As it is > decidable > whether there's one or many copyright holders, you should either erase the > "(s)" or > just remove parantheses, depending on what follows. fixed, so what's the next step ? can someone take a look at my package ? Thanks Fred -- --- Unix - where you can throw the manual on the keyboard and get a command
tagging bugs "woody"?
Hi, users working with Debian woody often do not look at archived bugs when reporting bugs on a package. Therefore it is likely that bugs that have long been fixed in unstable, but will never be in woody will be reported multiple times again. Therefore on [EMAIL PROTECTED] it was suggested to keep such bugs open. The "fixed" tag is appropriate for this, I assume. However, for people using unstable it would be nice to point out that the bug doesn't apply to them (and if they find similar behavior, it's a new bug). But is tagging it "woody" conformant with Debian practice? In http://www.de.debian.org/Bugs/Developer it says regarding the tags with distribution names: , | The latter five tags are intended to be used mainly for release | critical bugs, for which it's important to know which distributions | are affected to make sure fixes (or removals) happen in the right | place. ` Would it still be in order to use the tag woody, now that woody has long been released? TIA, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITA: yadex -- WAD file editor for doom-style WADs
On Mon, Jul 28, 2003 at 08:28:32AM +, Thomas Viehmann wrote: hi, > Try "lintian -i". You've probably left "Author(s):" in there. As it is decidable > whether there's one or many copyright holders, you should either erase the "(s)" or > just remove parantheses, depending on what follows. fixed, so what's the next step ? can someone take a look at my package ? Thanks Fred -- --- Unix - where you can throw the manual on the keyboard and get a command -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor vs. Developer Process?
* Rene Engelhard <[EMAIL PROTECTED]> [2003-07-29 01:31]: > > > You won't be approved with no package in the archive. > > > > bullshit > > It _is_ so. > Definitely. If you want to join Debian as a package maintainer, there is clearly no good reason for not having a package in the archive. Only that way we can see how applicants respond to bug reports, etc. -- Martin Michlmayr [EMAIL PROTECTED]
Re: RFS: pose - Palm OS Emulator (5th -and last- try)
Hi Matt. Matthew Palmer ([EMAIL PROTECTED]) wrote: >In the case of software for Palmpilots and whatnot, unless a DD has >compatible hardware, they can't test it. (Incidentally, if someone really >wants to get pose in, they can donate a Palm to me and I'll happily test and >sponsor). POSE is an emulator. You can happily test and sponsor without a palm. (You need ROMs, though, but that shouldn't be too much of a problem.) Cheers T.
Re: Sponsor vs. Developer Process?
* Rene Engelhard <[EMAIL PROTECTED]> [2003-07-29 01:31]: > > > You won't be approved with no package in the archive. > > > > bullshit > > It _is_ so. > Definitely. If you want to join Debian as a package maintainer, there is clearly no good reason for not having a package in the archive. Only that way we can see how applicants respond to bug reports, etc. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
On Sat, 26 Jul 2003 14:42:48 +0900, Junichi Uekawa <[EMAIL PROTECTED]> wrote: >> Lintian, however, can't know that this particular library usually is >> preloaded, not linked to. Hence the override. > >If its use is going to be something like that, please don't put it in >/usr/lib. That's what the lintian warning is about. Where should it be put instead? Please notice that this can potentially be preloaded early, hence it is currently in /lib. Greetings Marcc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: RFS: pose - Palm OS Emulator (5th -and last- try)
Hi Matt. Matthew Palmer ([EMAIL PROTECTED]) wrote: >In the case of software for Palmpilots and whatnot, unless a DD has >compatible hardware, they can't test it. (Incidentally, if someone really >wants to get pose in, they can donate a Palm to me and I'll happily test and >sponsor). POSE is an emulator. You can happily test and sponsor without a palm. (You need ROMs, though, but that shouldn't be too much of a problem.) Cheers T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
