RFS: dtc-xen (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.3.0-1 of my package dtc-xen. It's been now a long time that I'm searching for a sponsor, as my old sponsor decided to stop sponsoring completely. It builds these binary packages: dtc-xen- SOAP daemon and scripts to allow control panel management for Xen dtc-xen-firewall - A small firewall script for your dom0 The package appears to be lintian clean. The upload would fix these bugs: 418254, 419213, 421517, 422126, 422326, 422332, 422514, 423609, 424882, 431705 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dtc-xen - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dtc-xen/dtc-xen_0.3.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards Thomas Goirand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libsbc (updated package) [4th try to find a sponsor]
Dears mentors,
2007/8/9, Krzysztof Burghardt [EMAIL PROTECTED]:
2007/7/28, Krzysztof Burghardt [EMAIL PROTECTED]:
I am looking for a sponsor for the new version 0.0cvs20070728-1
of my package libsbc.
It builds these binary packages:
libsbc-dev - Development files for subband codec (SBC) library
libsbc0- Subband codec (SBC) library
sbcinfo- Subband codec (SBC) analyzer
The package appears to be lintian clean.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libsbc
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libsbc/libsbc_0.0cvs20070728-1.dsc
I would be glad if someone uploaded this package for me.
I'm still looking for sponsor. This is really small library and
changes aren't too big:
* New upstream checkout
* Add debian/get-orig-source.sh
* Add autotools clean rules
* Fixed dependency to use ${binary:Version} instead of ${Source-Version}
* Changed package build rules to not ignore make clean return code
Maybe this time I find a sponsor :)
Best regards,
--
Krzysztof Burghardt [EMAIL PROTECTED]
http://www.burghardt.pl/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
Hey Christoph, First off, thanks for the reply. On 9/24/07, Christoph Haas [EMAIL PROTECTED] wrote: On Mon, Sep 24, 2007 at 09:56:57AM +0200, liran tal wrote: I am looking for a sponsor for my package daloradius. * Package name: daloradius Version : 0.9.3 Upstream Author : Liran Tal [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/daloradius This URL is not mentioned in debian/copyright and/or debian/control. I will add the webpage address to the debian/copyright. Is there a webpage tag to add in the debian/control file or should I simply add it to the description? The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/daloradius - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/daloradius/ daloradius_0.9.3.dsc The package just contains the usr directory from the upstream tarball. That's right. There is just the usr directory. The application is actually located on /usr/share/daloradius Is this not ok? should there be other directories? You also built your package as a native package (no orig.tar.gz + diff.gz). Right. I tried placing an orig.tar.gz tarball actually which contained the package but dpkg-source complained on some errors which I can't remember at the moment but at that time it seemed that I was simply doing something wrong. Please give the package some more love. Creating Debian packages is unfortunately non-trivial. I did find it somewhat cumbersome to get this package as it is to build with as little lintian warnings and errors as possible. Though Debian-Love is always present in my heart :-) Since you are also the upstream I suggest you ask a fellow Debian developer to create the package for you. Or file a WNPP bug to find someone to create a package (`reportbug wnpp`). Uhmm, I will check the 'reportbug wnpp' indeed although I thought that this would be the place to get the package sponsored - i.e receiving help from a Debian maintainer/developer to help build this package and upload it to Debian's repositories. Regards, Liran.
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
On Tue, Sep 25, 2007 at 09:22:33AM +0200, liran tal wrote: I will add the webpage address to the debian/copyright. Is there a webpage tag to add in the debian/control file or should I simply add it to the description? No. I think what Christoph wants you to do is add Homepage: http://...; in the intial section of the control file as a field, below Build-Depends, Section etc. Since you are also the upstream I suggest you ask a fellow Debian developer to create the package for you. Or file a WNPP bug to find someone to create a package (`reportbug wnpp`). Uhmm, I will check the 'reportbug wnpp' indeed although I thought that this would be the place to get the package sponsored - i.e receiving help from a Debian maintainer/developer to help build this package and upload it to Debian's repositories. If you are intent on being the Debian package maintainer, thisis the right place and people will guide you here. All the best! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
Hi, Liran... On Tue, Sep 25, 2007 at 09:22:33AM +0200, liran tal wrote: On 9/24/07, Christoph Haas [EMAIL PROTECTED] wrote: On Mon, Sep 24, 2007 at 09:56:57AM +0200, liran tal wrote: I am looking for a sponsor for my package daloradius. * Package name: daloradius Version : 0.9.3 Upstream Author : Liran Tal [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/daloradius This URL is not mentioned in debian/copyright and/or debian/control. I will add the webpage address to the debian/copyright. Is there a webpage tag to add in the debian/control file or should I simply add it to the description? At the end of the description with two spaces as indentation. It's also a good idea to use it as a control field. Concrete proposal: Source: daloradius Section: admin Priority: optional Maintainer: Liran Tal [EMAIL PROTECTED] Standards-Version: 3.6.2 --- this is outdated - please use 3.7.2 Build-Depends: debhelper (= 4.1.0) Homepage: http://sourceforge.net/projects/daloradius Package: daloradius Architecture: any Depends: apache, php, php-db, php-pear Suggests: freeradius (= 1.1.0), php5-mysql Description: An advanced RADIUS web management application aimed at managing hotspots and general-purpose ISP deployments. daloRADIUS features user management, graphical reporting, accounting, a billing engine and integrates with GoogleMaps for geo-locating. . Homepage: http://sourceforge.net/projects/daloradius Your Description should start with a one-line short description that is shown in package lists. The lines beginning with the second line may contain a longer description. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/daloradius - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/daloradius/ daloradius_0.9.3.dsc The package just contains the usr directory from the upstream tarball. That's right. There is just the usr directory. The application is actually located on /usr/share/daloradius Is this not ok? should there be other directories? Please read on the difference between native versus non-native packages. Your package should contain an .orig.tar.gz which is basically the tarball that you release and have your users download. Then you start packaging your software by adding a debian/ directory. The various tools like dpkg-buildpackage/debuild will create a Debian package and move all the changes you did for the Debian package into a .diff.gz file. That was it's much easier to find out if the orig.tar.gz matches the official release of your software and what changes have been done to create the Debian package from it. Right. I tried placing an orig.tar.gz tarball actually which contained the package but dpkg-source complained on some errors which I can't remember at the moment but at that time it seemed that I was simply doing something wrong. Perhaps. dh_make will print out warnings if it doesn't find the orig.tar.gz in the right place. I did find it somewhat cumbersome to get this package as it is to build with as little lintian warnings and errors as possible. Though Debian-Love is always present in my heart :-) :) Since you are also the upstream I suggest you ask a fellow Debian developer to create the package for you. Or file a WNPP bug to find someone to create a package (`reportbug wnpp`). Uhmm, I will check the 'reportbug wnpp' indeed although I thought that this would be the place to get the package sponsored - i.e receiving help from a Debian maintainer/developer to help build this package and upload it to Debian's repositories. My intent when suggesting this was not to discourage you from creating the Debian package. Packaging work is just non-intuitive at the beginning and it's often faster to find someone who is familiar with it. But I'd even more welcome it if you learned the last subtle details of packaging. :) I really didn't mean to offend. I'd suggest you spend some time with these documents btw: http://www.us.debian.org/doc/manuals/maint-guide/index.en.html http://www.us.debian.org/doc/debian-policy/ Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
On 9/25/07, Christoph Haas [EMAIL PROTECTED] wrote: Hi, Liran... At the end of the description with two spaces as indentation. It's also a good idea to use it as a control field. Concrete proposal: Your Description should start with a one-line short description that is shown in package lists. The lines beginning with the second line may contain a longer description. Thanks I have corrected these issues. That's right. There is just the usr directory. The application is actually located on /usr/share/daloradius Is this not ok? should there be other directories? Please read on the difference between native versus non-native packages. Your package should contain an .orig.tar.gz which is basically the tarball that you release and have your users download. Then you start packaging your software by adding a debian/ directory. The various tools like dpkg-buildpackage/debuild will create a Debian package and move all the changes you did for the Debian package into a .diff.gz file. That was it's much easier to find out if the orig.tar.gz matches the official release of your software and what changes have been done to create the Debian package from it. I tried placing an orig.tar.gz tarball actually which contained the package but dpkg-source complained on some errors Perhaps. dh_make will print out warnings if it doesn't find the orig.tar.gz in the right place. Alright so it seems the last thing to resolve is this native package issue... I will try first to put my original package tarball (renamed to orig.tar.gz) in the outer directory to where I build the package and give it another shot. I have some questions regarding the package building though which concerns the orig.tar.gz I think... The way I build the package is having in the daloradius-0.9.3/ directory the debian/ and the usr/ directories where the usr/ occupies in the full path of usr/share/daloradius my package files (the php stuff and everything). in debian/rules what I do is cp daloradius-0.9.3/usr to daloradius-0.9.3/debian/usr Is this ok? I'm asking because I think that having the orig.tar.gz makes dpkg-source think that it's suppose to copy it over to the daloradius-0.9.3/debian dir but I'm not entirely sure. My intent when suggesting this was not to discourage you from creating the Debian package. Packaging work is just non-intuitive at the beginning and it's often faster to find someone who is familiar with it. But I'd even more welcome it if you learned the last subtle details of packaging. :) I really didn't mean to offend. Indeed it is easier to find someone to do the job and I would probably not be offended if one of the maintainers around here would take it on himself to build the package for me and upload it to Debian to save me the time of grasping everything as long as I later learn how the packaging process is done so I can later build package myself and help others, new debian-comers to deal with such issues themselves. (Also, I've put it on my mind that once I get this package built I'm definitely putting an *updated* step by step guide to building a pacakge as I can stress how important that is. I'd suggest you spend some time with these documents btw: http://www.us.debian.org/doc/manuals/maint-guide/index.en.html http://www.us.debian.org/doc/debian-policy/ I did give the new maintainers guide a try although the document I think misses the point in through-out the text. Just my note on it, but I think it's way too much theoretical and doesn't provide actual examples and hands-on experience. This is why I think new maintainers find it hard to package. Plus, there is too much documentation out there which is out-dated and talks about tools like deb-make or alike which causes very much confusion and you end up feeling like a mouse in a maze. Thanks alot for all the feedback and help! Regards, Liran.
Re: RFS: pingus (updated package)
Uhm, ok, someone else uploaded this package in the meantime. The points I raised in the previous e-mail are still worth fixing in the next upload. And I'd still like answers to: - There is a lintian override installed, which isn't documented in the changelog. Why is it needed? (In other words, what rare situation do you have here, which warrants an override instead of a lintian bug?) - During build, it reports: * XInput support: disabled. Is that intentional? Do we miss input devices such as game pads because of this? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
Hey Kumar, On 9/25/07, Kumar Appaiah [EMAIL PROTECTED] wrote: On Tue, Sep 25, 2007 at 09:22:33AM +0200, liran tal wrote: I will add the webpage address to the debian/copyright. Is there a webpage tag to add in the debian/control file or should I simply add it to the description? No. I think what Christoph wants you to do is add Homepage: http://...; in the intial section of the control file as a field, below Build-Depends, Section etc. If you are intent on being the Debian package maintainer, thisis the right place and people will guide you here. All the best! Thanks Kumar I've applied the necessary changes. Hopefully someone would be glad to help me build the package the right way and we will find it soon in Debian's repositories :) Thanks, Liran.
Re: Building a package for a web application
liran tal wrote: I've uploaded everything to: http://daloradius.sourceforge.net/packages/debpkg/ From a quick glance: * daloradius_0.9.3.tar.gz includes the immediate subdirs debian/ and usr/ - you should really avoid trying to create a 'native' package. * Wrong 'Architecture:' in debian/control * Incorrect spacing and indentation of description in debian/control * Incorrect punctuation in debian/control * Missing Homepage: line in debian/control * Missing ITP number from debian/changelog * Old debhelper debian/compat compatibility number * 'apache' and 'php' as dependencies is probably not what you want * Freeradius should probably not be a Suggests: * Why does it create a database called 'radius'? Why can't this be the same name of your package? Do you have to create it at all? * Lots of pointless and incorrect stuff in debian/rules. For example, build-stamp ends up in /usr/share/daloradius. * Documentation in /usr/share/daloradius (eg. FAQS, etc.) Regards, -- Chris Lamb GPG: 0x634F9A20 signature.asc Description: PGP signature
RFS: tesseract (updated package), third time lucky, I hope
Dear mentors, I am looking for a sponsor for the new version 2.01-1 of tesseract, plus the eight language packages, tesseract-eng, tesseract-deu, tesseract-deu-f, tesseract-nld, tesseract-spa, tesseract-por, tesseract-ita, tesseract-fra It builds these binary packages: tesseract - The well-known OCR engine first developed by HP and now taken over by Google The upload would close Bug#434152. 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/tesseract - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract/tesseract_2.01-1.dsc The languages packages are: - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-deu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-deu/tesseract-deu_2.00-1.dsc The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-deu-f - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-deu-f/tesseract-deu-f_2.01-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-eng - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-eng/tesseract-eng_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-fra - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-fra/tesseract-fra_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-ita - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-ita/tesseract-ita_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-nld - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-nld/tesseract-nld_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-spa - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-spa/tesseract-spa_2.00-1.dsc The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-por - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-por/tesseract-por_2.01-1.dsc I would be glad if someone uploaded this package for me. Regards Jeff Ratcliffe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dtc (updated package)
Hi, Thomas Goirand wrote: I am looking for a sponsor for the new version 0.26.4-1 of my package dtc. It's been now a long time that I'm searching for a sponsor, as my old sponsor decided to stop sponsoring completely. Oh yay, I can foresee a lot of fun. dtc is also used for the device tree compiler, a compiler that creates OpenFirmware device trees on systems that do not use OF (passing a device tree is a requirement for current Linux on powerpc). Does your package contain a binary named dtc? Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing transition stuff in debhelper scripts after which time?
Hi, Justin Pryzby wrote: You can drop such things in uploads to unstable after they're included in a stable release. Upgrades across releases are not tested and are officially not supported though AFAIK the reasons are largely undocumented. I think it's roughly the same situation as for downgrades: It would nevertheless be a nice thing if people would not deliberately break upgrades just because there is no requirement for upgrades anymore. To be honest, I was pretty annoyed when I had to switch my unstable system to stable when sarge came out in order to get the kernel version that was regarded as the new minimum to install further versions, and there was not even a safeguard in place that made sure that unstable-unstable upgrades crossing the kernel version in stable at this time were correctly rejected. . maintainer scripts may not support things; this is basically so maintainers are allowed to drop support for ancient things and not have unmanagably large and difficult to test, unmaintanble cruft; However you can create sections in the maintainer scripts, with the first section being active only if the last configured version (which you are told) is lower than the stable version, doing an upgrade to whatever the stable version expected, and the next section going from there to the current state. Since both of these are supposed to be idempotent on their own, this is no more difficult to maintain than a version that only supports upgrades from the latest stable. . Package control file; including in particular the dependency fields: Conflicts, Depends, Provides (?), Pre-Depend plus Replaces. Dependencies on versions earlier than [old]stable are often dropped. It's only unfortunate that control files afaik still don't support comments to document why the versions and things were there with which to being. I'd only drop things that are relevant only to stuff older than oldstable; I believe we could make an automated check for that (i.e. leave everything as it is, unless the versioned dependency will always be met even in oldstable). The dependency fields help a lot in telling the package manager that it should not try something that is unsupported. Debian's renowned stability across upgrades doesn't come from nowhere. . The package itself; eg. it might contain logic to upgrade the format of its datafiles but not for every historic version and bugs therein. It might make sense to have a Pre-Conflicts (for lack of a better word) field that could be used to say this package does not support upgrades from versions earlier than x. I'm not entirely confident current conflict resolvers could handle such a situation gracefully though. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
On Tue, Sep 25, 2007 at 10:47:19AM +0200, liran tal wrote: I have some questions regarding the package building though which concerns the orig.tar.gz I think... The way I build the package is having in the daloradius-0.9.3/ directory the debian/ and the usr/ directories where the usr/ occupies in the full path of usr/share/daloradius my package files (the php stuff and everything). in debian/rules what I do is cp daloradius-0.9.3/usr to daloradius-0.9.3/debian/usr Is this ok? I'm asking because I think that having the orig.tar.gz makes dpkg-source think that it's suppose to copy it over to the daloradius-0.9.3/debian dir but I'm not entirely sure. Actually, the recommended way to copy files from your upstream source location to the debian/package directory would be to use dh_install. Even better than calling dh_install directly from rules would be to use an install file in the debian/ directory which has things of the form upstream file/directory destination For example, for the package foo, if I want to install foo-1.2/bar/file1 to /usr/share/foo/bar file1, my install file woul have an entry like: bar/file1 usr/share/foo Or if you want to copy the directory foo-1.2/common-files to /usr/share/foo/common-files, you can add an entry like: common-files usr/share/foo etc. Read man dh_install for details. Also dh_installdocs, dh_installexamples and dh_installwhatever for more nie stuff. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
Thanks Kumar, will do. On 9/25/07, Kumar Appaiah [EMAIL PROTECTED] wrote: On Tue, Sep 25, 2007 at 10:47:19AM +0200, liran tal wrote: I have some questions regarding the package building though which concerns the orig.tar.gz I think... The way I build the package is having in the daloradius-0.9.3/ directory the debian/ and the usr/ directories where the usr/ occupies in the full path of usr/share/daloradius my package files (the php stuff and everything). in debian/rules what I do is cp daloradius-0.9.3/usr to daloradius-0.9.3/debian/usr Is this ok? I'm asking because I think that having the orig.tar.gz makes dpkg-source think that it's suppose to copy it over to the daloradius-0.9.3/debian dir but I'm not entirely sure. Actually, the recommended way to copy files from your upstream source location to the debian/package directory would be to use dh_install. Even better than calling dh_install directly from rules would be to use an install file in the debian/ directory which has things of the form upstream file/directory destination For example, for the package foo, if I want to install foo-1.2/bar/file1 to /usr/share/foo/bar file1, my install file woul have an entry like: bar/file1 usr/share/foo Or if you want to copy the directory foo-1.2/common-files to /usr/share/foo/common-files, you can add an entry like: common-files usr/share/foo etc. Read man dh_install for details. Also dh_installdocs, dh_installexamples and dh_installwhatever for more nie stuff. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+OqFSd75awtatOcRAo0ZAJ9cD/cYgG92Ph3TWhmkUhQwy+LqCACfR6cr lDKc2DdSh/Mg2rsu2drrQ3M= =ucvX -END PGP SIGNATURE-
Re: RFS: dtc (updated package)
Simon Richter wrote: Hi, Thomas Goirand wrote: I am looking for a sponsor for the new version 0.26.4-1 of my package dtc. It's been now a long time that I'm searching for a sponsor, as my old sponsor decided to stop sponsoring completely. Oh yay, I can foresee a lot of fun. dtc is also used for the device tree compiler, a compiler that creates OpenFirmware device trees on systems that do not use OF (passing a device tree is a requirement for current Linux on powerpc). Does your package contain a binary named dtc? Simon No, it doesn't have any binaries that you need to call on the shell. It runs without any daemon, it's a bunch of sh scripts and php scripts. As my package entered Unstable quite a long time ago, maybe it's possible to have the device tree compiler using another package name? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autoconfigurable package: how to build two configurations?
On Sun, Sep 23, 2007 at 06:50:02PM -0500, Steve M. Robbins wrote: Hello, Are there any examples of a package that builds two binary packages, each from a distinct run of configure? My specific case is soqt, which provides a Qt interface to Coin (OpenInventor). There is a sentiment [1] that I provide packages for Qt3 as well as packages for Qt4. I believe that I need to run the autoconf-generated configure script twice and build each configuration in its own build directory. I'd like to see a package that does this already. Preferably, one that uses cdbs. The dev-ref (still) uses vim as an example afaik. A good goal would be to reduce duplication of code within the rules file. Justin References [0] http://lists.debian.org./debian-mentors/2007/05/msg00069.html
Menu transition - status of doc-base?
Hi, Some weeks ago, the menu transition was announced. The doc-base system uses the sections defined in the menu policy for their own Section: field. But may I already use the new menu sections (Applications instead of Apps, ...) in .doc-base files? I checked the Wiki and the original thread about the transition but didn't find an answer to this question. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Menu transition - status of doc-base?
On Tue, Sep 25, 2007 at 04:33:28PM +0200, Daniel Leidert wrote: Some weeks ago, the menu transition was announced. The doc-base system uses the sections defined in the menu policy for their own Section: field. But may I already use the new menu sections (Applications instead of Apps, ...) in .doc-base files? I checked the Wiki and the original thread about the transition but didn't find an answer to this question. My lintian 1.23.34 already complains for Apps etc. So, I guess you should use Applications/ Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: php-net-pop3
I've updated the package, including patches to attempt to fix some upstream bugs. URL: http://mentors.debian.net/debian/pool/main/p/php-net-pop3/ Source repository: deb-src http://mentors.debian.net/debian unstable main dget http://mentors.debian.net/debian/pool/main/p/php-net-pop3/php-net-pop3_1.3.6-2.dsc [EMAIL PROTECTED] (Mark A. Hershberger) writes: I am looking for a sponsor for my package php-net-pop3. * Package name: php-net-pop3 ITP : 441651 Version : 0.11.4 Upstream Author : Damian Alejandro Fernandez Sosa * URL : http://pear.php.net/package/Net_POP3 * License : BSD Section : web Description : Provides a POP3 class to access POP3 server. Support all POP3 commands including UIDL listings, APOP authentication, DIGEST-MD5 and CRAM-MD5 using optional Auth_SASL package It builds these binary packages: php-net-pop3 - a PHP class to access POP3 servers The package appears to be lintian clean. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vidalia
On 星期二 25 九月 2007, Vern Sun wrote: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vidalia - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vidalia/vidalia_0.0.14-2.dsc have you ever uploaded to somewhere? if not, it should be vidalia_0.0.14-1, but not vidalia_0.0.14-2 Zhengpeng Hou signature.asc Description: This is a digitally signed message part.
Re: RFS: vidalia
I'm not a DD and can't sponsor uploads. However I looked at your package and have a comment. Thanks for commenting, I made a little bit changes like, * Build on Sid * Use a watch file * Add XS-Vcs-Browser, XS-Vcs-SVN, Homepage in control file * Clear the debian/rules, delete the commands that are commented out * Fix debian/copyright with reviewing the licenses used by different pieces of code. The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vidalia - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vidalia/vidalia_0.0.14-2.dsc I would be glad if someone uploaded this package for me. Kind regards -- Vern 2007-09-25 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Menu transition - status of doc-base?
Am Dienstag, den 25.09.2007, 20:20 +0530 schrieb Kumar Appaiah: On Tue, Sep 25, 2007 at 04:33:28PM +0200, Daniel Leidert wrote: Some weeks ago, the menu transition was announced. The doc-base system uses the sections defined in the menu policy for their own Section: field. But may I already use the new menu sections (Applications instead of Apps, ...) in .doc-base files? I checked the Wiki and the original thread about the transition but didn't find an answer to this question. My lintian 1.23.34 already complains for Apps etc. So, I guess you should use Applications/ Does it really complain about Apps in a doc-base file? The menu transition itself is already handled in lintian, but I cannot find a check for the section in doc-base files. I also cannot find any file in /usr/share/doc-base, that uses the new sections defined in the latest menu policy. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Menu transition - status of doc-base?
On Tue, Sep 25, 2007 at 06:13:37PM +0200, Daniel Leidert wrote: Does it really complain about Apps in a doc-base file? The menu transition itself is already handled in lintian, but I cannot find a check for the section in doc-base files. I also cannot find any file in /usr/share/doc-base, that uses the new sections defined in the latest menu policy. I agree with you on this one. Only meny issues are flagged by lintian, and I am not aware of doc-base files. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: tesseract (updated package), third time lucky, I hope
Jeffrey, On Tue, Sep 25, 2007 at 11:29:35AM +0200, Jeffrey Ratcliffe wrote: I am looking for a sponsor for the new version 2.01-1 of tesseract, plus the eight language packages, tesseract-eng, tesseract-deu, tesseract-deu-f, tesseract-nld, tesseract-spa, tesseract-por, tesseract-ita, tesseract-fra I may have missed something so bear with me. Currently there are two packages in unstable: tesseract-ocr - Command line OCR tool tesseract-ocr-data - Command line OCR tool data From #434152 I see that the tesseract-ocr* maintainer knows about the new package. But why the name change? Is this the same software? Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tesseract (updated package), third time lucky, I hope
On 25/09/2007, Christoph Haas [EMAIL PROTECTED] wrote: I may have missed something so bear with me. Currently there are two packages in unstable: tesseract-ocr - Command line OCR tool tesseract-ocr-data - Command line OCR tool data From #434152 I see that the tesseract-ocr* maintainer knows about the new package. But why the name change? Is this the same software? The package name is still tesseract-ocr. v1 was English-only, hence only one data package. v2 is multilingual - and therefore one data package per language. Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tesseract (updated package), third time lucky, I hope
On Tue, Sep 25, 2007 at 08:37:31PM +0200, Jeffrey Ratcliffe wrote: On 25/09/2007, Christoph Haas [EMAIL PROTECTED] wrote: I may have missed something so bear with me. Currently there are two packages in unstable: tesseract-ocr - Command line OCR tool tesseract-ocr-data - Command line OCR tool data From #434152 I see that the tesseract-ocr* maintainer knows about the new package. But why the name change? Is this the same software? The package name is still tesseract-ocr. v1 was English-only, hence only one data package. v2 is multilingual - and therefore one data package per language. Alright, I was blind. Should have looked closer at debian/control. :) Why are the include files packages in /usr/include/tesseract? Sounds like that should rather go into a tesseract-ocr-dev package. Or is it really needed to run tesseract? Regarding the language packages: what do they need autoconfig files (config.guess, config.sub) for? IMHO the description of the language packages doesn't sound english enough (although I'm not an englishman either). Perhaps instead of tesseract-ocr data for German you could use something along Data files to make tesseract recognize german images? Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tesseract (updated package), third time lucky, I hope
On 25/09/2007, Christoph Haas [EMAIL PROTECTED] wrote: Why are the include files packages in /usr/include/tesseract? Sounds like that should rather go into a tesseract-ocr-dev package. Or is it really needed to run tesseract? I must admit that I am fairly inexperienced at packaging, and I more or less used the v1 diff as a template and just made mods to get it lintian clean. I see your point, though. I assume it is possible simultaneously to make the -ocr and -ocr-dev packages, just defining which files go in which package. I thought defining .install files would do the trick, but I am having no luck. Would you mind giving me some pointers? Regarding the language packages: what do they need autoconfig files (config.guess, config.sub) for? Which autoconfig files? I don't see these. IMHO the description of the language packages doesn't sound english enough (although I'm not an englishman either). Perhaps instead of tesseract-ocr data for German you could use something along Data files to make tesseract recognize german images? I am English, but I am prepared to change it. How about tesseract-ocr language files for German text? Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tesseract (updated package), third time lucky, I hope
On Tue, Sep 25, 2007 at 11:13:32PM +0200, Jeffrey Ratcliffe wrote: On 25/09/2007, Christoph Haas [EMAIL PROTECTED] wrote: Why are the include files packages in /usr/include/tesseract? Sounds like that should rather go into a tesseract-ocr-dev package. Or is it really needed to run tesseract? I must admit that I am fairly inexperienced at packaging Don't worry. and I more or less used the v1 diff as a template and just made mods to get it lintian clean. I see your point, though. I assume it is possible simultaneously to make the -ocr and -ocr-dev packages, just defining which files go in which package. I thought defining .install files would do the trick, but I am having no luck. Would you mind giving me some pointers? You would need to remove the debian/tmp/usr/include files or just run 'make' instead of 'make install' and copy the files manually. Regarding the language packages: what do they need autoconfig files (config.guess, config.sub) for? Which autoconfig files? I don't see these. zcat tesseract-deu_2.00-1.diff.gz | grep ^-- Looks like remains from the default debian/rules template. IMHO the description of the language packages doesn't sound english enough (although I'm not an englishman either). Perhaps instead of tesseract-ocr data for German you could use something along Data files to make tesseract recognize german images? I am English, but I am prepared to change it. How about tesseract-ocr language files for German text? Great. Kindly Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xawtv (updated package)
2007/9/23, Florian Ernst [EMAIL PROTECTED]: I'm really glad someone picked this up, so I'm indeed quite interested in long-term sponsoring of this package as long as it's needed. Thanks already for all your work! Great! I'm having big troubles in getting my packages uploaded. Some of them wait for sponsor for over a month. However, I noticed the previous two uploads have been signed by different DDs. Quite often people sponsoring a package will also sponsor further updates, so you won't need to ask again for a new sponsor. I take it they were doing (for one reason or another) some one-shot sponsoring? Just wondering... As I said it be great to have one sponsor for all my packages (or at last sponsor for one of them). You are first who propose to sponsor further upload. The package appears to be lintian and pbuilder clean. lintian 1.23.34, when run against my _i386.changes, reports otherwise. Well, the one repeated warning (partially-translated-question) isn't severe at all in this case, but you should take a look at the informational tags as well (lintian --display-info ...changes), especially possible-non-posix-code-in-maintainer-script. I'm not sure, but probably this can be removed soon as devfsd is no longer in unstable. I would be glad if someone uploaded this package for me. Hmmm, I don't know how serious the issue with NV-GLX and DGA is, but I'd recommend documenting how to use XAWTV_USE_DGA for the end-user before shipping your xawtv.sh as a wrapper. Then I'll gladly sponsor your packaging, and on to further updates. :) Not very but while every geek know if his drivers supports DGA, and can prepare alias for himself including -nodga in command line. This change is targeted to normal users. If they have some nvidia cards and proprietary drivers xawtv will not start showing mysterious X protocol request failed error. Users are confused by this error and often asks for solution (i.e. -nodga). I forgot to add one simple patch and as you know xawtv fail to create widget. This is fixed now. Also I add a xawtv.NEWS to document XAWTV_USE_DGA environment variable. Fixed packaged uploaded to mentors.d.n. Regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vidalia
On 25/09/2007, Zhengpeng Hou [EMAIL PROTECTED] wrote: On 星期二 25 九月 2007, Vern Sun wrote: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vidalia - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vidalia/vidalia_0.0.14-2.dsc have you ever uploaded to somewhere? if not, it should be vidalia_0.0.14-1, but not vidalia_0.0.14-2 That depends on the sponsor's decision, please search in the [EMAIL PROTECTED] archive for the long discussion about package versions to see everybody's opinion about that subject. Zhengpeng Hou -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition
