RFS: python-dmidecode
Dear mentors, I am looking for a sponsor for my package python-dmidecode. Package name : python-dmidecode Version : 2.10-1 Upstream Author : Nima Talebi URL : http://projects.autonomy.net.au/dmidecode/ License : GNU GPL v3 Section : python It builds 1 binary package: python-dmidecode - Python Extension Module for DMIDecode The package appears to be lintian clean. The upload would fix these bugs: 509169 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/python-dmidecode - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/python-dmidecode/python-dmidecode_2.10-1.dsc I would be glad if someone uploaded this package for me. Kind regards Nima Talebi
Re: RFS: libabstract-ruby
On Sun, 21 Dec 2008 08:47:25 +0100
Salvatore Bonaccorso salvatore.bonacco...@gmail.com wrote:
Note, I'm only correcting the reply from Salvatore - I have no
intention of helping with the package any further or of offering any
sponsorship.
http://people.debian.org/~codehelp/#lang
I noticed that you still use Standards-Version 3.6.2. If I'm right,
the current policy version is 3.8.0.1.
No, just 3.8.0
Here is the further lintian output on the package, done with
lintian -I libabstract*ch*
(note: you can check it with lintian -iI libabstract*ch* to have more
informative output):
I: libabstract-ruby source: debian-watch-file-is-missing
This is only informational, it's not required. But since the
download URL seems to be
http://rubyforge.org/frs/download.php/9171/abstract_1.0.0.tar.bz2
it should be not to bad to add a debian/watch file if possible.
Most sponsors require a working watch file where one is missing.
W: libabstract-ruby source: debhelper-but-no-misc-depends libabstract-ruby
The help text of lintian says here:
N:The source package uses debhelper but it does not use ${misc:Depends} in
N:the given binary package's debian/control entry. This is required so the
N:dependencies are set correctly in case the result of a call to any of
N:the dh_ commands cause the package to depend on another package.
N:
N:Refer to the debhelper(7) manual page for details.
N:
N:Severity: normal; Certainty: certain
Add ${misc:Depends} to the Depends line of the binary package(s) in
debian/control, exactly as lintian instructs you to do.
W: libabstract-ruby1.8: description-synopsis-might-not-be-phrased-properly
W: libabstract-ruby1.9: description-synopsis-might-not-be-phrased-properly
W: libabstract-ruby: description-synopsis-might-not-be-phrased-properly
You can leave the . (dot) at the end of the phrase.
You *must* leave out the dot at the end of the short description.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpTFRDPLrJka.pgp
Description: PGP signature
Re: ITS: xf86-input-tslib (updated package)
Neil Williams codeh...@debian.org (19/12/2008):
I'm only mentioning this as a caution - I don't consider it a
practical problem for these particular changes to these particular
packages. Once Lenny is released and we migrate both tslib and the
xorg driver into unstable and thence into testing, it would be best if
either the build-depends change was reverted or that the driver had a
stricter dependency on that version of tslib by using this change in
debian/control for the binary package:
- Depends: ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}
+ Depends: libts-0.0-0 (= 1.0-5), ${shlibs:Depends}, ${misc:Depends},
${xserver:Depends}
That's ugly. Use shlibs.local (Policy §8.6.5) instead.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: ITS: xf86-input-tslib (updated package)
On Sun, Dec 21, 2008 at 9:37 PM, Cyril Brulebois k...@debian.org wrote:
Neil Williams codeh...@debian.org (19/12/2008):
- Depends: ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}
+ Depends: libts-0.0-0 (= 1.0-5), ${shlibs:Depends}, ${misc:Depends},
${xserver:Depends}
That's ugly. Use shlibs.local (Policy §8.6.5) instead.
If that is nessecary, you have EPIC FAIL. Go back and start again.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Re: ITS: xf86-input-tslib (updated package)
On Sun, 21 Dec 2008 23:32:15 +0900
Paul Wise p...@debian.org wrote:
On Sun, Dec 21, 2008 at 9:37 PM, Cyril Brulebois k...@debian.org
wrote:
Neil Williams codeh...@debian.org (19/12/2008):
- Depends: ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}
+ Depends: libts-0.0-0 (= 1.0-5), ${shlibs:Depends},
${misc:Depends}, ${xserver:Depends}
That's ugly. Use shlibs.local (Policy §8.6.5) instead.
If that is nessecary, you have EPIC FAIL. Go back and start again.
I didn't mention it at the time, but tslib uses symbols so there was
little chance that an shlibs bump would be necessary. There were two
options:
1. The build-dep had been bumped for artificial reasons (which turned
out to be true)
2. testing with 1.0-4 had identified bugs (unreported to the BTS) that
disappeared with 1.0-5 due to the patches implemented in 1.0-5. These
patches did not add new symbols or modify any symbols, the patches
affect internal code within existing symbols. This can change
behaviour, (and therefore bugs), but does not mean an shlibs bump. (In
the event, this was not the reason for the build-dep bump.)
I was merely clarifying that if [2] had been the reasoning that merely
altering the build-dep would not have had the desired effect of
preventing these bugs from re-appearing in the case of any failed
migration of tslib alongside the xorg driver.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpIay7rmOzOx.pgp
Description: PGP signature
Considering package removal [glademm]
As I have never requested removal of an package I'm asking here for some opinions to make sure my thoughts are reasonable. Any comments are welcome! =3D=3D=3D=3D=3D Some Data: * Popcon inst: 359 * Open Bugs: 6 =3D normal * Last upstream release: May 2005 * priority: optional * Section: devel =3D=3D=3D=3D=3D I'm currently maintaining glademm, which is an sourcecode generator producing C++ sources from glade files. While doing so I'm currently going through the pieces upstream left unreleased. However I'm in serious doubt this is worth the trouble. First of all, glademm is unmaintained upstream for years. While this would not be an reason for removal on it's own I see it as an hint. Furthermore the way glademm works is deprecated (as is glade as an code generator) and should be replaced by libglade(mm). It is impossible in debian to create C Sources from glade (C being the =C2=ABoriginal=C2=BB G= TK language) but it's still possible to create C++ Sources. Well glademm's functionality is quite limited, too. Accoring to actual code =C2=ABgnome2 support is still experimental=C2=BB but in debian it is= actually broken (#126054 for example) (it requires libbonobomm which is not available). Doing some simple gtk2 stuff however works (with some limitations, see bugpage). One of the reasons to go backporting some more recent commits was some bug fixed there (see #335696). But while doing so I realised nearly all test in the testsuit currently fail. While I will certainly be able to at least fix the now present gettext problem it will cause considerable work. Regards Christoph Egger --=20 /\ ASCII Ribbon : GPG-Key ID: 0x0372275D \ /Campaign : X against HTML : Working for Debian / \ in eMails : http://www.debian.org/ -- /\ ASCII Ribbon : GPG-Key ID: 0x0372275D \ /Campaign : X against HTML : Working for Debian / \ in eMails : http://www.debian.org/ signature.asc Description: OpenPGP digital signature
Re: Considering package removal [glademm]
On Sun, 21 Dec 2008 20:59:33 +0100 Christoph Egger christoph.eg...@gmx.de wrote: As I have never requested removal of an package I'm asking here for some opinions to make sure my thoughts are reasonable. Any comments are welcome! Some Data: * Popcon inst: 359 * Open Bugs: 6 = normal * Last upstream release: May 2005 * priority: optional * Section: devel I'm currently maintaining glademm, which is an sourcecode generator producing C++ sources from glade files. While doing so I'm currently going through the pieces upstream left unreleased. However I'm in serious doubt this is worth the trouble. To remove a package, file a bug against ftp.debian.org using the template of any other RM bugs in the same list. There are no RC bugs in glademm - do you need to remove glademm from Lenny or can removal wait until after the Lenny release? (You can still file the bug, but be clear about whether it needs to be done in Lenny.) First of all, glademm is unmaintained upstream for years. While this would not be an reason for removal on it's own I see it as an hint. It is - as is your reluctance as maintainer. One of the reasons to go backporting some more recent commits was some bug fixed there (see #335696). But while doing so I realised nearly all test in the testsuit currently fail. While I will certainly be able to at least fix the now present gettext problem it will cause considerable work. With a dead upstream, it might simply be easier to remove the package. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpQGWTadiC3X.pgp Description: PGP signature
Considering package removal [glademm]
As I have never requested removal of an package I'm asking here for some opinions to make sure my thoughts are reasonable. Any comments are welcome! =3D=3D=3D=3D=3D Some Data: * Popcon inst: 359 * Open Bugs: 6 =3D normal * Last upstream release: May 2005 * priority: optional * Section: devel =3D=3D=3D=3D=3D I'm currently maintaining glademm, which is an sourcecode generator producing C++ sources from glade files. While doing so I'm currently going through the pieces upstream left unreleased. However I'm in serious doubt this is worth the trouble. First of all, glademm is unmaintained upstream for years. While this would not be an reason for removal on it's own I see it as an hint. Furthermore the way glademm works is deprecated (as is glade as an code generator) and should be replaced by libglade(mm). It is impossible in debian to create C Sources from glade (C being the =C2=ABoriginal=C2=BB G= TK language) but it's still possible to create C++ Sources. Well glademm's functionality is quite limited, too. Accoring to actual code =C2=ABgnome2 support is still experimental=C2=BB but in debian it is= actually broken (#126054 for example) (it requires libbonobomm which is not available). Doing some simple gtk2 stuff however works (with some limitations, see bugpage). One of the reasons to go backporting some more recent commits was some bug fixed there (see #335696). But while doing so I realised nearly all test in the testsuit currently fail. While I will certainly be able to at least fix the now present gettext problem it will cause considerable work. Regards Christoph Egger --=20 /\ ASCII Ribbon : GPG-Key ID: 0x0372275D \ /Campaign : X against HTML : Working for Debian / \ in eMails : http://www.debian.org/ signature.asc Description: OpenPGP digital signature
Re: Considering package removal [glademm]
Hi! Thanks for your reply. Neil Williams schrieb: On Sun, 21 Dec 2008 20:59:33 +0100 Christoph Egger christoph.eg...@gmx.de wrote: As I have never requested removal of an package I'm asking here for some opinions to make sure my thoughts are reasonable. Any comments are welcome! Some Data: * Popcon inst: 359 * Open Bugs: 6 = normal * Last upstream release: May 2005 * priority: optional * Section: devel I'm currently maintaining glademm, which is an sourcecode generator producing C++ sources from glade files. While doing so I'm currently going through the pieces upstream left unreleased. However I'm in serious doubt this is worth the trouble. To remove a package, file a bug against ftp.debian.org using the template of any other RM bugs in the same list. There are no RC bugs in glademm - do you need to remove glademm from Lenny or can removal wait until after the Lenny release? (You can still file the bug, but be clear about whether it needs to be done in Lenny.) Jup I know the procedure, I was more in trouble wether it is reasonable. There is no need I guess to have this done for lenny. First of all, glademm is unmaintained upstream for years. While this would not be an reason for removal on it's own I see it as an hint. It is - as is your reluctance as maintainer. I do become automatically upstream maintainer as debian maintainer of dead software? Interesting way of looking at it. One of the reasons to go backporting some more recent commits was some bug fixed there (see #335696). But while doing so I realised nearly all test in the testsuit currently fail. While I will certainly be able to at least fix the now present gettext problem it will cause considerable work. With a dead upstream, it might simply be easier to remove the package. I thought so, the intention of this mail was to get sure it was reasonable which I assert by your answer. Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0x0372275D \ /Campaign : X against HTML : Working for Debian / \ in eMails : http://www.debian.org/ signature.asc Description: OpenPGP digital signature
Re: Considering package removal [glademm]
Christoph Egger christoph.eg...@gmx.de (21/12/2008): Jup I know the procedure, I was more in trouble wether it is reasonable. There is no need I guess to have this done for lenny. You can propose/ask for opinion on debian...@. Mraw, KiBi. signature.asc Description: Digital signature
php-nexista
Hello, I've just uploaded the latest version (0.2.4) of php-nexista, a sponsor would be great! Any feedback would be appreciated as well. This packaging was done with dh-make-php, which is a terrific tool. I originally made a pear package, so making a debian package was a piece of cake. Thanks in advance. - Albert -- http://www.docunext.com/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php-nexista
On Sun, Dec 21, 2008 at 05:42:52PM -0500, Albert Lash wrote: I've just uploaded the latest version (0.2.4) of php-nexista, a sponsor would be great! Any feedback would be appreciated as well. How about a link to the dsc? This packaging was done with dh-make-php, which is a terrific tool. I originally made a pear package, so making a debian package was a piece of cake. Is this a new package needing a new sponsor or an updated package, in which case asking your original sponsor first is good manners? -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: php-nexista
On Sun, Dec 21, 2008 at 05:42:52PM -0500, Albert Lash wrote: I've just uploaded the latest version (0.2.4) of php-nexista, a sponsor would be great! Any feedback would be appreciated as well. IANADD and can't upload for you, but I can give you some feedback to get it into shape for a sponsor. At the moment there are some severe problems with it: You have three lintian warnings because you haven't used your full name as the maintainer and in the changelog, and because your tag line in the changelog doesn't match your name and email in your debian/control file. You haven't specified your ITP bug number in debian/changelog. debian/control: you should be working to standards version 3.8.0. See [1] for a checklist. You should use your full name in debian/copyright (just as if you were making a legal assertion to it). debian/README.Debian: again, use your full name. debian/rules: get rid of comment cruft, like the fact that this is a sample script. Your watch file doesn't work [2]. These are fundamental problems and need fixing before a sponsor will consider your package. If you need help, you're welcome to ask for it. [1] /usr/share/doc/debian-policy/upgrading-checklist.txt [2] man uscan -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: backintime (new)
Dear mentors, I am still seeking a sponsor for backintime, but in the meantime I have also updated to the new upstream version. You can find the new dsc at [1], all the other details are as in my original mail. Thanks in advance. [1] http://mentors.debian.net/debian/pool/main/b/backintime/backintime_0.8.18-2.dsc -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
RFS: ming (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:0.4.2-1.1 of my package ming. It builds these binary packages: libming-dev - Library to generate SWF (Flash) Files (development files) libming-util - Library to generate SWF (Flash) Files - Utilities libming1 - Library to generate SWF (Flash) Files libswf-perl - Ming (SWF) module for Perl ming-fonts-dejavu - Ming format DejaVue Fonts ming-fonts-opensymbol - Ming format Opensymbol Fonts php5-ming - Ming module for php5 python-ming - Ming (SWF) module for Python The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/ming - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/ming/ming_0.4.2-1.1.dsc I would be glad if someone uploaded this package for me. Kind regards Hámorszky Balázs -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ming (updated package)
On Mon, Dec 22, 2008 at 10:19 AM, Balázs Hámorszky bal...@gmail.com wrote: I am looking for a sponsor for the new version 1:0.4.2-1.1 of my package ming. Did you try to contact the maintainer before preparing this NMU? You didn't document any of the debian/ changes in the debian/changelog file. -- bye, pabs http://wiki.debian.org/PaulWise
