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]
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 > ./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: Linda warnings about manpages in my packages
On Thu, Apr 20, 2006 at 10:34:04PM +0200, Raphael Hertzog wrote: > 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). Ah, in that case this would be my recommendation here... > > 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. The part I object to is including an app and a public module in a single package -- particularly one that happens to come with an init script as this one does. If it's a public module, it should be its own package. If it's not supposed to be a public module, it shouldn't be in a public directory, and then there's no reason to provide more packages than just the application package. > 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. Yes, agreed. > > 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. Agreed on both counts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
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: 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: Linda warnings about manpages in my packages
On Thu, Apr 20, 2006 at 09:30:52PM +0200, Raphael Hertzog wrote: > 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) 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). 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. > 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. 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. However, trying to make the application package auto-switch between two different versions of python is also the wrong solution. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
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
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]
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
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
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
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=1313775&forum_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]
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]