Re: Q on fixed-in-experimental
Colin Watson wrote: On Thu, Apr 20, 2006 at 02:18:15AM +0200, Laszlo Boszormenyi wrote: On Thu, 2006-04-20 at 00:14 +0100, Neil Williams wrote: When a bug is tagged fixed-in-experimental, does that bug number still have to appear in debian/changelog for the next upload to unstable or will the BTS be updated when the package in experimental is replaced? It has to appear in changelog. I know how to filter the BTS to show bugs with these tags, just wondering if it's automated. Can't be automated. An automatic system can't figure out if the fix is still in the package or maybe dropped from the unstable upload due to cause other problems. To clarify, it still has to appear in debian/changelog, but it doesn't have to be in the most recent version; leaving it in the version where you fixed the problem is good enough. together with -v to dpkg-buildpackage / debuild so the bugs actually get into the Closes: line of the .changes so they actually get closed. Regards, Rene signature.asc Description: Digital signature
Re: Q on fixed-in-experimental
On Thu, Apr 20, 2006 at 12:14:58AM +0100, Neil Williams wrote: When a bug is tagged fixed-in-experimental, does that bug number still have to appear in debian/changelog for the next upload to unstable or will the BTS be updated when the package in experimental is replaced? I know how to filter the BTS to show bugs with these tags, just wondering if it's automated. fixed-in-experimental is just an informative tag, and doesn't have any functional consecquence; it is really obsoleted by versioning, which does. If you mail [EMAIL PROTECTED] with a Version: $v pseudoheader, where v is the version in experimental, and later upload to unstable a version derived from the version in experimental, the BTS will consider that bug fixed in sid, too. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building rpms on debian system?
On Wed, 19 Apr 2006, Ek Zindagoi wrote: I would like to build rpms on a debian system for use on a redhat system. Can I do that on a debian system ? As a short-term solution, you can cheat by making a Debian package and using alien --to-rpm. However, if anyone tries to put your RPMs into one of their repositories, they can run into problems: http://sourceforge.net/forum/forum.php?thread_id=1313775forum_id=209131 Oooh... and, seizing an opportunity to push that particular package... An old ITP, fresh release. mentors.debian.net, kbtin, clean packaging, no dependencies other than libc. I guess that the lack of source RPMs is not a problem here, too :p Happy hacking, Adam -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: drawterm
Hello- I have prepared a package for drawterm, and I am seeking a sponsor. Package name: drawterm License: Lucent Public License, version 1.02 Description: graphical terminal for remotely accessing Plan 9 systems drawterm is used to access a Plan 9 CPU server over the network and start up a session with the rio windowing system. Closes: #298340 Upstream author: Russ Cox [EMAIL PROTECTED] URL: http://swtch.com/drawterm The binary package is available here: http://moduli.net/debian/binary/ and source package in this directory: http://moduli.net/debian/source/. Or to install with apt-get or the like, put this in your sources.list: deb http://moduli.net/debian binary/ deb-src http://moduli.net/debian source/ The package is lintian and linda clean. Thank you! Nick signature.asc Description: Digital signature
Linda warnings about manpages in my packages
Hi Folk, I've three packages: denyhosts-python2.3 denyhosts-python2.4 denyhosts-common the binaries are stored in packages -python2.X but the manpage (common to alla packages) is stored in denyhosts-common. Now, i've this linda reports: # linda -i denyhosts-python2.3_2.3-2_all.deb Linda: Running as root, dropping to nobody. E: denyhosts-python2.3; No manual page for binary denyhosts. The binary displayed doesn't have a corresponding manual page, while Policy dictates that every binary in /bin, /sbin, /usr/bin, /usr/sbin, /usr/games and /usr/X11R6/bin requires a manual page. # linda -i denyhosts-python2.4_2.3-2_all.deb Linda: Running as root, dropping to nobody. E: denyhosts-python2.4; No manual page for binary denyhosts. The binary displayed doesn't have a corresponding manual page, while Policy dictates that every binary in /bin, /sbin, /usr/bin, /usr/sbin, /usr/games and /usr/X11R6/bin requires a manual page. What is, in your opinion, the right way to operate? Can I ignore these linda warning? Cheers, -- Marco Bertorello System Administrator Linux Registered User #319921 pgpovbZ2iUK8b.pgp Description: PGP signature
Re: Linda warnings about manpages in my packages
On 4/20/06, Marco Bertorello [EMAIL PROTECTED] wrote: Hi Folk, I've three packages: denyhosts-python2.3 denyhosts-python2.4 denyhosts-common the binaries are stored in packages -python2.X but the manpage (common to alla packages) is stored in denyhosts-common. E: denyhosts-python2.3; No manual page for binary denyhosts. The binary E: denyhosts-python2.4; No manual page for binary denyhosts. The binary What is, in your opinion, the right way to operate? Make both -py2.3 and py2.4 packages depend on -common, document this in the changelog. Can I ignore these linda warning? I guess you could. Add a linda override file for each of the -py2.x packages, install them in the corresponding packages, document and forget. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: Linda warnings about manpages in my packages
Hi, On Thu, 20 Apr 2006, Marco Bertorello wrote: denyhosts-python2.3 denyhosts-python2.4 denyhosts-common the binaries are stored in packages -python2.X but the manpage (common to alla packages) is stored in denyhosts-common. Why would you have a binary in -python2.3 *and* in -python2.4 ? And why can't you simply provide a single package an you make the choice to use either python2.3 or python2.4 ? I don't see the gain of having two versions of the same application just to work with two different python version... (it's different for Python modules because the user must be able to use the modules with the Python version of its choice) If your application works with python2.3 (default python version for the moment), then you use that and you're done. Once python2.4 is the default, you update your package to work with python 2.4 and you're done. And if you believe that the modules are useful for the end-user, then the current packaging make sense (bin and manpages in -common and modules in -python2.X). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC/RFS: paythyme and thyme, UK payroll application and supporting library
Hi Would appreciate any feedback on these related packages. Paythyme uses the database library and other helpers provided by thyme. Packages are lintian/linda clean and build with pbuilder. Sponsor also sought. * Package name: paythyme Version : 20050502 Upstream Author : Thyme Software Limited [EMAIL PROTECTED] * URL : http://www.paythyme.org * License : GPL Programming Lang: C, Python Description : desktop payroll application This is a payroll application for UK based companies. It handles tax calculations and related administration tasks. http://mentors.debian.net/debian/pool/main/p/paythyme/ * Package name: thyme Version : 2.6.4 Upstream Author : Thyme Software Limited [EMAIL PROTECTED] * URL : http://clocksoft.co.uk/development-tools/ * License : GPL, LGPL Programming Lang: C, Python Description : python application development framework Thyme is a python rapid application development environment. It provides a python interface to ISAM database files aswell as wrappers for various Qt objects. http://mentors.debian.net/debian/pool/main/t/thyme/ Thanks Tristan Hill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings about manpages in my packages
On Thu, 20 Apr 2006, Steve Langasek wrote: denyhosts-python2.3/2.4 do contain a python module. If and when the Great Python Reorganization finally happens, this ought to be a single denyhosts package depending on python ( 2.3), python ( 2.5). This can already be done with python-support (provided that the code isn't specific to a python version). Since the package installs public modules, it seems to me that putting the modules and the app in a single package is the wrong solution. We have plenty of modules which are packaged only for the current version of python in Debian and it's not wrong. This wouldn't be worse. And the maintainer really needs to think if the modules are meant to be public or not ... because I see no documentation of the modules, so I wonder why we need to provide them for two python versions. However, trying to make the application package auto-switch between two different versions of python is also the wrong solution. Indeed. In the meantime, the current packages have an RC bug, #361085, about the fact that denyhosts-comon *does* include a binary that tries to support both versions of python, but without appropriate dependencies to ensure a consistent python configuration. Given the info that I've read here, if I were the maintainer I would have a single package denyhost with everything packaged for the default version. If I wanted to provide the modules for another python version I would use python-support. Check http://wiki.debian.org/DebianPythonFAQ for some info about how to use python-support. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnash (FSF Free Flash Player)
--- Paul Wise [EMAIL PROTECTED] escribió:
Some comments:
Thanks a lot for your comments on the package, they have been really useful!!
* debian/control: gnash is not binNMUable due to libgnash-dev
strictly depending on libgnash0 (= ${Source-Version}).
What should I do in this case? just depend on libgnash0 without the version?
wasn't they going to solve this problem in some way?
* debian/control: about mozilla-dev, generally, xulrunner is being
moved to these days, is that something that is possible for the
plugin? I'd love to be able to try this in galeon/epiphany.
I haven't ever had a look at xulrunner but it seems to be interesting. The
plugin should be compatible with any browser that supports mozilla plugins I
guess. Is there a standard way to handle that?
* debian/rules: might want to use a more standard patch system
than something homegrown. I'd suggest quilt or dpatch. The patch
target doesn't seem to be used or do anything.
I'm using that just because as I'm depending on CVS version it's much easier
to be using patches, but I plan to remove that when a release version appears,
so I don't wanna complicate it much.
I've fixed a lot of things, I guess the packages are almost finished for now.
I just have to know what to do with a lintian warning:
W: klash: binary-or-shlib-defines-rpath ./usr/lib/kde3/libklashpart.so
/usr/lib:/usr/share/qt3/lib
N:
N: The binary or shared library defines the `RPATH'. Usually this is a
N: bad thing. Most likely you will find a Makefile with a line like:
N: gcc test.o -o test -Wl,--rpath
N: or
N: gcc test.o -o test -R/usr/local/lib
N: Please contact debian-devel@lists.debian.org if you have questions
N: about this.
N:
./usr/lib/kde3/libklashpart.so is a plugin for konqueror, an it seems to
depend on the libraries at /usr/share/qt3/lib. As this is the first konqueror
plugin I package, I don't know if it's something usual or not. Does somebody
out there have a hint?
Greetings and lots of thanks,
Miry
__
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnash (FSF Free Flash Player)
On Fri, 2006-04-21 at 00:49 +0200, Miriam Ruiz wrote:
* debian/control: gnash is not binNMUable due to libgnash-dev
strictly depending on libgnash0 (= ${Source-Version}).
What should I do in this case? just depend on libgnash0 without the version?
wasn't they going to solve this problem in some way?
I'm not sure exactly, but there was a thread recently about this. I
think making the relation = would do it. Otherwise, you can use
dpkg-parsechangelog and sed to create a new variable, which you pass to
dh_gencontrol using -V (and use that in the control file).
* debian/control: about mozilla-dev, generally, xulrunner is being
moved to these days, is that something that is possible for the
plugin? I'd love to be able to try this in galeon/epiphany.
I haven't ever had a look at xulrunner but it seems to be interesting. The
plugin should be compatible with any browser that supports mozilla plugins I
guess. Is there a standard way to handle that?
Not really sure, I'd suggest asking the xulrunner/firefox/galeon/etc
maintainers. There may be an l.d.o or l.alioth.d.o list for that.
W: klash: binary-or-shlib-defines-rpath ./usr/lib/kde3/libklashpart.so
/usr/lib:/usr/share/qt3/lib
snip
./usr/lib/kde3/libklashpart.so is a plugin for konqueror, an it seems to
depend on the libraries at /usr/share/qt3/lib. As this is the first konqueror
plugin I package, I don't know if it's something usual or not. Does somebody
out there have a hint?
On my unstable system, /usr/share/qt3/lib only contains symlinks to
files in /usr/lib, so presumably you can turn off the rpath with no ill
effects. I don't know if this is the correct thing to do, I'd suggest
asking on the debian qt/kde list about it.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: RFC: gnash (FSF Free Flash Player)
On Fri, Apr 21, 2006 at 12:49:35AM +0200, Miriam Ruiz [EMAIL PROTECTED] wrote: * debian/control: about mozilla-dev, generally, xulrunner is being moved to these days, is that something that is possible for the plugin? I'd love to be able to try this in galeon/epiphany. I haven't ever had a look at xulrunner but it seems to be interesting. The plugin should be compatible with any browser that supports mozilla plugins I guess. Is there a standard way to handle that? If you want the plugin built with xulrunner with any browser (including the current firefox and mozilla), you'll have to not link against the xulrunner libraries. The symbols will be already loaded by the browser anyway, so there won't be a symbol resolution problem. But if you link, there will be two version of the same symbols in memory and big problems. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
