fixing a woody-only bug?
Hi! Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. But the upload has been rejected bu Katie: Rejected: Unknown distribution `woody-proposed-updates'. Thank you for you help.
Re: fixing a woody-only bug?
On Wed, Jul 28, 2004 at 07:36:43AM +0200, Magosányi Árpád (mag) wrote: Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. But the upload has been rejected bu Katie: Rejected: Unknown distribution `woody-proposed-updates'. The two names for this suite are proposed-updates and stable. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: fixing a woody-only bug?
On 2004-07-28 Magosányi Árpád (mag) [EMAIL PROTECTED] wrote: Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. [...] No, stable. Afaict from developers reference. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Debian vs RedHat init script
Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript (maintained upstream), I edited Debian template, to match the functionality provided by the RedHat initscript. Because of this, I have, now, two copies of initscripts (RedHat and Debian), which my sponsor, thinks, is redundant. The initscripts differ quite a bit, and I am not sure, if one format can be converted to another, using simple commands (and thus, be able to maintain just one copy). How do the other packages, get around this? I would be glad, if you would point me to specific packages, that have a (upstream maintained) RedHat specific initscript within the package source. Regards, -- Chirag Kantharia, [EMAIL PROTECTED] pgpfZVSDC0yBB.pgp Description: PGP signature
Re: Debian vs RedHat init script
On Wednesday 28 July 2004 10.09, Chirag Kantharia wrote: [init scripts] Hi, You may want to have a look at the LSB spec - I bet it does say something about init scripts. I haven't looked myself, yet, but it is on my TODO list - I have written a Debian-specific init script for postgrey, but I think I'd like to make it lsb-compatible, so upstream could distribute it (makes the diff smaller, and perhaps the RPM maintainer could use the same...) Current prerelease of the LSB 2.0 spec has something on http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core/iniscrptfunc.html, but I'd have to read and understand it really well, and also look at how much of it Debian offers (with or without lsb package). Haven't looked at the 1.3 spec. greetings -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org pgpwb0aj9tIeY.pgp Description: signature
Re: RFS: Folding@home
Nick Lewycky [EMAIL PROTECTED] wrote: If there any sane way to autodetect a network connection? I'm strongly adverse to hassling anybody with extra debconf questions. I'll agree to a debconf question for it only if there's no good way to handle online and offline cases automatically. (This includes systems that might be set up to dial on outgoing connection attempts. However it detects the network should not trigger such a mechanism.) Don't ask me... Well, perhaps route can do the trick. I'm not sure, but I think even in a non-connected dialup system there has to be some connection between the default route and the to-be connection. On an ISDN system, there's a network device up even if not connected, but I'm not sure for normal ppp connections. - there's no documentation. At least you should try to (get permission to) include the command line options in http://folding.stanford.edu/console-userguide.html. [...] I don't get it. What would you want it to do if you ran it from the commandline? Well, e.g. -queueinfo would be interesting, -verbosity might be useful, -forceSSE or -forceasm might be better on certain systems, etc. If you do manage to get it running, it will proceed to download a new machinedependent.dat, create a queue directory, download its FahCore*.exe files, and leave all this crap in the directory you ran it from. Not pretty. That's bad. But one could create a wrapper script in /usr/bin #!/bin/sh FAHDIR=/var/lib/folding EXECUTABLE=ForgotTheFancyName cd $FAHDIR $EXECUTABLE $* You can't reconfigure it, since you aren't running it as the fahclient user in the /var/lib/fahclient directory. You can't ask it for its queue information for the same reason. So the wrapper would have to change it's UID - probably a case for a perl script. I don't have any experience with such stuff, but there was a discussion on this a while ago here in the group. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: CDBS warning
Hallo Sebastien, * Sebastien Bacher [EMAIL PROTECTED] [2004-07-28 12:30]: i saw other packages build with cdbs, which had these warning too? does anyone know, what it is? No idea on the warning, but afaik they are here for all my packages and I don't have a problem to build them. To be honest I've not tried to look on what do that, I just don't care since it works ... does it break your build ? no, but i think it would be better if i know it :) thanks nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: CDBS warning
Hallo Andreas, * Andreas Metzler [EMAIL PROTECTED] [2004-07-28 12:31]: i switched my packages to cdbs and i think it is very good. but i have one problem, in the build process i get this warning: /usr/share/cdbs/1/rules/buildcore.mk:59: DEB_BUILD_MAKE_TARGET is a deprecated variable [...] http://bugs.debian.org/cdbs #256079: cdbs: please remove deprecated warning - it's scary thanks, its good to know that i am not the onlyone with this problem. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Hallo Pierre, * Pierre HABOUZIT [EMAIL PROTECTED] [2004-07-28 12:31]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS i read it. it think i read all documentation in the web about cdbs. sebastian said, that the upstream sources are faulty. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Hallo Sebastien, * Sebastien Bacher [EMAIL PROTECTED] [2004-07-28 12:31]: i change my package gtksee to cdbs and have the problem, that the makefile doesn't uses the $(DESTDIR) variable. Then it tries in make install to install .mo-files in /usr/ instead of $(DESTDIR)/usr without cdbs this is no problem and it installs it correctly. i put two logs of the build process with and without cdbs in the attachment, it would be nice, if someone can have a look on it. you find the package without cdbs on: http://nico.f-451.net/debian/gtksee/no_cdbs/ and the package with cdbs: http://nico.f-451.net/debian/gtksee/cdbs/ Your orig.tar.gz has wrong permissions. oh thanks for the hint. BTW it's not a problem. CDBS do its job fine, that's the upstream system that is faulty: $ make install DESTDIR=/tmp .. /usr/bin/install: cannot remove `/usr/share/locale/fr/LC_MESSAGES/gtksee.mo': Permission denied installing fr.gmo as /usr/share/locale/fr/LC_MESSAGES/gtksee.mo /usr/bin/install: cannot remove `/usr/share/locale/es/LC_MESSAGES/gtksee.mo': Permission denied installing es.gmo as /usr/share/locale/es/LC_MESSAGES/gtksee.mo ... etc thats the problem i mean. do you have an idea how to fix it? my skills on autoconf are not so high i think. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: Debian vs RedHat init script
On Wed, Jul 28, 2004 at 11:57:02AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: | Current prerelease of the LSB 2.0 spec has something on | http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core/iniscrptfunc.html, | but I'd have to read and understand it really well, and also look at | how much of it Debian offers (with or without lsb package). Haven't | looked at the 1.3 spec. Hi Adrian Thanks for the url. I'm not sure how that solves my problem. As I understand you, I need to convince the upstream maintainer to switch to LSB style initscript. I can try doing that. The initscript has some weird function, which might be optionally used by the user, to exchange ssh keys, so that the dump is copied to the server using ssh (scp). The function has no place in the initscript, but RedHat prefers to do it, that way. I've placed that key exchange, as part of postinst. If, for some reason, the upstream maintainer doesn't wish to modify the initscript, to adhere to LSB recommendations, then, do I have an alternative way to resort to? Regards, -- Chirag Kantharia, [EMAIL PROTECTED] pgpBvT1W3m30m.pgp Description: PGP signature
Re: problems with cdbs
Le mercredi 28 juillet 2004 à 12:43 +0200, Nico Golde a écrit : thats the problem i mean. do you have an idea how to fix it? my skills on autoconf are not so high i think. Apparently it worked because the debian/rules used make install prefix= instead of DESTDIR= I'll have a look on the build system today and let you know. Cheers, Sebastien Bacher
Re: problems with cdbs
On Wed, Jul 28, 2004 at 12:41:58PM +0200, Nico Golde wrote: Hallo Pierre, * Pierre HABOUZIT [EMAIL PROTECTED] [2004-07-28 12:31]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS i read it. it think i read all documentation in the web about cdbs. sebastian said, that the upstream sources are faulty. regards nico well, S. Bacher said : Apparently it worked because the debian/rules used make install prefix= instead of DESTDIR= so In your debian/rules using cdbs I guess you have to do that : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) prefix=$(DEB_DESTDIR) (default is : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) ) it was in the doc, in the section I mentionned to you -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Debian vs RedHat init script
Chirag Kantharia [EMAIL PROTECTED] schrieb: Because of this, I have, now, two copies of initscripts (RedHat and Debian), which my sponsor, thinks, is redundant. The initscripts differ quite a bit, and I am not sure, if one format can be converted to another, using simple commands (and thus, be able to maintain just one copy). I would not see a problem in the duplication. If the differences are really so big that a patch does not make sense, I would just ignore the old one. Whether you replace it by your init script (diff is in the diff.gz) or keep your script in debian and use debian/rules to copy it over the redhatish original in debian/tmp/... is just a matter of taste, I'd say. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Debian vs RedHat init script
This one time, at band camp, Chirag Kantharia said: Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript (maintained upstream), I edited Debian template, to match the functionality provided by the RedHat initscript. Because of this, I have, now, two copies of initscripts (RedHat and Debian), which my sponsor, thinks, is redundant. The initscripts differ quite a bit, and I am not sure, if one format can be converted to another, using simple commands (and thus, be able to maintain just one copy). How do the other packages, get around this? I would be glad, if you would point me to specific packages, that have a (upstream maintained) RedHat specific initscript within the package source. One of my packages (clamav) comes with init scripts for both RedHat and Suse. I leave them as is in the source tarball, and just don't put them in the distributed .debs. There are many ways to do this, but I've found the easiest is to have the normal `make install` go to debian/tmp, and then pick what you want out of there to go to the respective package directories. HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgplQYpqIs8Fq.pgp Description: PGP signature
Re: Debian vs RedHat init script
On Wednesday 28 July 2004 12.55, Chirag Kantharia wrote: On Wed, Jul 28, 2004 at 11:57:02AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: Thanks for the url. I'm not sure how that solves my problem. As I understand you, I need to convince the upstream maintainer to switch to LSB style initscript. I can try doing that. The initscript has Yes, that was my idea - so everybody can use the same init script. some weird function, which might be optionally used by the user, to exchange ssh keys, so that the dump is copied to the server using ssh (scp). The function has no place in the initscript, but RedHat As far as I see it, an lsb compliant init script can still do whatever it wants as long as it does the right things for the start/stop/... arguments, so that shouldn't be a problem. (And you don't have to use that part, after all) prefers to do it, that way. I've placed that key exchange, as part of postinst. If, for some reason, the upstream maintainer doesn't wish to modify the initscript, to adhere to LSB recommendations, then, do I have an alternative way to resort to? I guess just keep your own init script. You may want to document in README.Debian that the ssh key functionality of the RH script is done differently, just in case the Debian package is used by a user used to the other script. greetings -- vbi -- Email returned to sender -- insufficient voltage. pgpfqbuTnrQxy.pgp Description: signature
Re: problems with cdbs
#include hallo.h * Pierre HABOUZIT [Tue, Jul 27 2004, 11:19:22PM]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS I think, CDBS restricts too much, simply dangerous hocus pocus. For example, I still don't see how to run a special program directly after dh_libdeps has been run (not before and not after the whole package built). I also cannot see how to override the whole install rule of debian/rules (or anything similar to that inside of the CDBS internals). Regards, Eduard. -- The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in the terrible in-between.-- Centauri Emperor, Babylon 5 - The Coming Of Shadows signature.asc Description: Digital signature
Re: problems with cdbs
On Wed, Jul 28, 2004 at 03:22:19PM +0200, Eduard Bloch wrote: #include hallo.h * Pierre HABOUZIT [Tue, Jul 27 2004, 11:19:22PM]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS I think, CDBS restricts too much, simply dangerous hocus pocus. For example, I still don't see how to run a special program directly after dh_libdeps has been run (not before and not after the whole package built). I also cannot see how to override the whole install rule of debian/rules (or anything similar to that inside of the CDBS internals). Well, I guess cdbs aim is not to remove the fully made by hand with dh_* debian/rules but to simplify its writing for non-pathological cases. I use it since a few month, for kde apps, and web apps, and I find that the resulting debian/rules are really really readable, and don't have the lot of noise a non-cdbs rules has. btw nobody force you to use it ;p -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] signature.asc Description: Digital signature
RFTS: irda-utils
hi folks... as my current sponsor has to renew his gpg-key and the freeze for sarge is about to happen in the foreseeable future, i hereby put a request for a temporary sponsor for the package irda-utils. some important things have changed from -4 to -5, so i believe to need a couple of uploads to the archive until irda-utils will be fit for sarge. Name: irda-utils License: GPL Short description: IrDA management and handling utilities Long description: This package contains userspace utilities to manage and handle infrared devices. It includes irattach, findchip, irdadump, irdaping and irpsion5. OBEX tools are removed since 0.9.5. If you need to use IrOBEX, use openobex-apps package. . Authors: Dag Brattli [EMAIL PROTECTED] and Jean Tourrilhes [EMAIL PROTECTED] Homepage: http://irda.sourceforge.net Obtainable from: deb http://mentors.debian.net/debian unstable main contrib non-free thanks in advance, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: RFTS: irda-utils
hello.. 10 minutes after i sent this, i got my account @debian.org... so forget about the sponsor thing, but you might have a look at it, anyway. :) bye, sebastian * Sebastian Henschel [EMAIL PROTECTED] [2004-07-28 16:21 +0200]: as my current sponsor has to renew his gpg-key and the freeze for sarge is about to happen in the foreseeable future, i hereby put a request for a temporary sponsor for the package irda-utils. some important things have changed from -4 to -5, so i believe to need a couple of uploads to the archive until irda-utils will be fit for sarge. Name: irda-utils License: GPL Short description: IrDA management and handling utilities Long description: This package contains userspace utilities to manage and handle infrared devices. It includes irattach, findchip, irdadump, irdaping and irpsion5. OBEX tools are removed since 0.9.5. If you need to use IrOBEX, use openobex-apps package. . Authors: Dag Brattli [EMAIL PROTECTED] and Jean Tourrilhes [EMAIL PROTECTED] Homepage: http://irda.sourceforge.net Obtainable from: deb http://mentors.debian.net/debian unstable main contrib non-free -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: fixing a woody-only bug?
Hallo Magosányi, * Magosányi Árpád (mag) [EMAIL PROTECTED] [2004-07-28 12:32]: Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. But the upload has been rejected bu Katie: Rejected: Unknown distribution `woody-proposed-updates'. do you read this: Packages uploaded to stable need to be compiled on systems running stable, so that their dependencies are limited to the libraries (and other packages) available in stable; for example, a package uploaded to stable that depends on a library package that only exists in unstable will be rejected. Making changes to dependencies of other packages (by messing with Provides or shlibs files), possibly making those other packages uninstallable, is strongly discouraged. The Release Team (which can be reached at debian-release@lists.debian.org) will regularly evaluate the uploads in stable-proposed-updates and decide if your package can be included in stable. Please be clear (and verbose, if necessary) in your changelog entries for uploads to stable, because otherwise the package won't be considered for inclusion. Developers Reference 5.5.1 regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Hallo Pierre, * Pierre HABOUZIT [EMAIL PROTECTED] [2004-07-28 18:25]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS i read it. it think i read all documentation in the web about cdbs. sebastian said, that the upstream sources are faulty. well, S. Bacher said : Apparently it worked because the debian/rules used make install prefix= instead of DESTDIR= sorry, maybe i am blind, he wrotes this: Your orig.tar.gz has wrong permissions. BTW it's not a problem. CDBS do its job fine, that's the upstream system that is faulty: $ make install DESTDIR=/tmp .. /usr/bin/install: cannot remove `/usr/share/locale/fr/LC_MESSAGES/gtksee.mo': Permission denied installing fr.gmo as /usr/share/locale/fr/LC_MESSAGES/gtksee.mo /usr/bin/install: cannot remove `/usr/share/locale/es/LC_MESSAGES/gtksee.mo': Permission denied installing es.gmo as /usr/share/locale/es/LC_MESSAGES/gtksee.mo ... etc so In your debian/rules using cdbs I guess you have to do that : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) prefix=$(DEB_DESTDIR) ah thanks. (default is : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) ) it was in the doc, in the section I mentionned to you i had an offline copy, this was apparent outdated. next time i use the online version. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: package with more than one license: logwatch
Frank Küster wrote: Willi Mann [EMAIL PROTECTED] wrote: For the general problems associated with different licenses in one package, you might find a look at http://bugs.debian.org/218105 informative. (Although I hope that your package isn't as mixed as ours). Thanks. Can anyone tell me please if attached copyright file is OK? What I'm unsure about is if it's enough to list all the mentioned names in the package or do I have to do the painful act of working out who owns a copyright on which of the many scripts? That's the way to go. Of course you have to make sure that this is legally possible at all (is any linking done?). Logwatch's language is perl. It mostly does cat logfile | filter1 | filter2 | filter3 ... But why do you think, linking would be a problem? Public Domain and X11 are both GPL-compatible. Willi This package was debianized by Willi Mann [EMAIL PROTECTED] on Wed, 12 Nov 2003 20:14:15 +0100. It was downloaded from ftp://ftp.kaybee.org/pub/linux/logwatch-5.1.tar.gz Logwatch consists of many individual scripts. Most of them were written by Kirk Bauer [EMAIL PROTECTED], who is also the maintainer of logwatch. Other authors and contributors: --- Dariusz Nierada [EMAIL PROTECTED] David Golden [EMAIL PROTECTED] Eric Moret [EMAIL PROTECTED] Fabrizio Zeno Cornelli [EMAIL PROTECTED] Gerald Teschl [EMAIL PROTECTED] James Wysynski [EMAIL PROTECTED] Jim O'Halloran [EMAIL PROTECTED] Joe Digilio [EMAIL PROTECTED] Kenneth Porter [EMAIL PROTECTED] Lars Skjærlund [EMAIL PROTECTED] Luuk de Boer [EMAIL PROTECTED] Luuk de Boer [EMAIL PROTECTED] Manuel Mitnyan [EMAIL PROTECTED] M. B. Heath [EMAIL PROTECTED] Michael Romeo [EMAIL PROTECTED] Michael Stovenour [EMAIL PROTECTED] Mike Tremaine [EMAIL PROTECTED] Osma Ahvenlampi [EMAIL PROTECTED] Pawe? Go?aszewski [EMAIL PROTECTED] Pawel Jarosz [EMAIL PROTECTED] Sean Boran [EMAIL PROTECTED] Simon Liddington [EMAIL PROTECTED] Simon Liddington [EMAIL PROTECTED] S. Schimkat www.schimkat.dk Sven Conrad [EMAIL PROTECTED] Sven Conrad [EMAIL PROTECTED] Willi Mann [EMAIL PROTECTED] (Note that this is a semi-autogenerated list. See README.Debian for more information.) Licenses: - Except for a few scripts, logwatch is distributed under the permissive X11 license. The exceptions: scripts/services/clamav-milter: GPL scripts/services/rt314: Public Domain Text of the licenses: - X11 license: -BEGIN LICENSE -- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. --END LICENSE-- GPL: -BEGIN LICENSE -- This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 dated June, 1991. This package is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. --END LICENSE--
Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
Hi, given the current sarge deadline and the opinions expressed by some of the release team a full amd64 port in sarge is not going to happen. So lets move on. What else can we do for amd64 users? We have a fully working i386 port which works on amd64 systems too. What we need most now is support for: 1. Kernel support for amd64 to run 32/64 bit binaries I want to upload a kernel-image-2.6.7-amd64 to i386. That would be along the same lines as the sparc64 or s390x kernel image in sparc or s390 respectively. So nothing new there. 2. Support to run dynamically linked 64 binaries (e.g. from SuSe/RH) What is needed is a /lib64 and /usr/lib64 directory with the core libraries. There already is a ia32-libs packages doing the reverse for ia64 and pure64. This just reverses the roles. Again nothing new. 3. Support to compile 64 bit binaries The kernel and libs need to be compiled somewhere. They could be build on pure64 and uploaded to i386 without problems but it would be nicer if they could be build under sarge i386 itself. This could be eigther a cross compiler (like the rest of the cross tool packages) or a 64bit native compiler. I tend to the later even if that restricts building those packages to an actual amd64 system. Thesource for the toolchain is already in sarge so no GPL problems even if (3) is scratched. So who is willing to sponsor the following packages: kernel-image-2.6.7-amd64 amd64-libs amd64-libs-dev gcc-3.3-amd64 gcc-3.4-amd64 binutils-amd64 None of those are base or standard so there is no must be today rush. But it still needs to be rushed a bit. MfG Goswin
Re: Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
Goswin von Brederlow wrote: Hi, given the current sarge deadline and the opinions expressed by some of the release team a full amd64 port in sarge is not going to happen. So lets move on. What else can we do for amd64 users? What about maintaining a stable repository for amd64 on alioth alongside the official sarge one? Thiemo
Re: Debian vs RedHat init script
Adrian 'Dagurashibanipal' von Bidder wrote: Thanks for the url. I'm not sure how that solves my problem. As I understand you, I need to convince the upstream maintainer to switch to LSB style initscript. I can try doing that. The initscript has Yes, that was my idea - so everybody can use the same init script. To use lsb init scripts in Debian, you need to have the lsb package installed. I don't think that we want to have debian packages depending on lsb, for one thing it pulls in lots of other stuff. I've also discovered that supposedly lsb compliant distributions violate its init script policy in various ways which can be quite hard to work around in an lsb init script, but YMMV there. -- see shy jo signature.asc Description: Digital signature
100% Gua-rantee 0r M0ney Back! vW
Debian-laptop-request Volumizer Doubles, Triples, Quadruples and MORE! ... not just volume of ejaculate, but intensity and power of 0rgasms. IT WILL ABSOLUTELY BLOW YOUR MIND Enjoy a bigger, more impressive load of cum ejaculation. Experience orgasms that go on and on..and on! Best sexual experiences of a lifetime are here n0w! http://sizeit1.com/vol/?a=07 re m0ve: http://sizeit1.com/rvm/ Q[20-60
RFS: gbuffy (adopted)
Hi all,
I'm looking for a sponsor to upload a new gbuffy version for me. I've
decided to adopt the gbuffy package since it is in bad shape, I use it
every day and I wouldn't like it to be removed from Debian. The wnpp
bug is #242096.
This version cleans up the packaging a little and, most importantly,
fixes a nasty segfault (#241371) which makes the package if not
unusable, at least quite user unfriendly. After this version has
entered testing, I plan to introduce some features myself, since
upstream is dead.
The package description follows, and the changes file is attached. If
you finally decide to sponsor me, please pass -v0.2.6-5 to debuild
or dpkg-buildpackage in order to get all un-uploaded versions listed.
Any other input of course appreciated.
gbuffy_0.2.6-8 is available in mentors.debian.net:
http://mentors.debian.net/debian/pool/main/g/gbuffy/gbuffy_0.2.6-8.dsc
http://mentors.debian.net/debian/pool/main/g/gbuffy/gbuffy_0.2.6-8.diff.gz
the orig.tar.gz package may be fetched from any Debian mirror, e.g.:
http://ftp.es.debian.org/debian/pool/main/g/gbuffy/gbuffy_0.2.6.orig.tar.gz
thanks.
Package: gbuffy
Priority: optional
Section: mail
Version: 0.2.6-8
Description: A GTK+-based, XBuffy-like multiple mailbox biff program
GBuffy will poll multiple mailboxes for new mail. It will list the
number of new messages in each mailbox you configure. It will also
highlight the mailboxes which have new mail. Pressing the left mouse
button on a mailbox with new mail will display the Sender and Subject
of each new message. Additionally, GBuffy will display the X-Face
header for messages which have them. Pressing the middle mouse button
on a mailbox will launch the configured command, generally a command
to read the mailbox with your favorite mailreader. Pressing the right
mouse button will bring up the configure menu.
.
GBuffy is currently capable of watching MBOX, MMDF, Maildir and MH
Folders. This version also supports IMAP4rev1 and NNTP with XOVER
mailboxes. Support for an external program for notification is
planned.
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
-- Oscar Hammerstein II
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 29 Jul 2004 05:26:16 +0200
Source: gbuffy
Binary: gbuffy
Architecture: source i386
Version: 0.2.6-8
Distribution: unstable
Urgency: low
Maintainer: Adeodato Simó [EMAIL PROTECTED]
Changed-By: Adeodato Simó [EMAIL PROTECTED]
Description:
gbuffy - A GTK+-based, XBuffy-like multiple mailbox biff program
Closes: 241371 241372 242096
Changes:
gbuffy (0.2.6-8) unstable; urgency=low
.
* debian/rules:
- wipe out commented stuff for building gbuffy-gnome.
- move DH_COMPAT to debian/compat.
- general cleanup.
* removed debian/gbuffy{_applet.desktop,-gnome.menu,.gnorba}.
* debian/copyright: added copyright notice for files from mutt.
* debian/control: list myself as the package maintainer. (Closes: #242096)
.
gbuffy (0.2.6-7) unstable; urgency=low
.
* debian/patches: removed 20_convert-charset, which is quite untested, in
order to make a version suitable to enter sarge and stay there for quite a
long time.
* debian/control: removed Build-Depends on xlibs-dev.
.
gbuffy (0.2.6-6) unstable; urgency=low
.
* debian/control:
+ remove obsolete Build-Depends on libgnome-dev, since the gnome version
is no longer built.
+ bumped Standards-Version to 3.6.1 (no changes required).
* debian/patches/:
+ updated 10_libwings to avoid crashing after adding a new mailbox.
(Closes: #241371, #241372)
+ added 20_convert-charset, to convert RFC 2047 decoded strings to the
local charset (scratch-an-itch patch).
* debian/copyright: updated download URL.
* debian/menu: use the full path in the command.
Files:
9f91d572d82dbefa1af056747b2dbfa8 627 mail optional gbuffy_0.2.6-8.dsc
e0b82b6601b1acb7d214c7221f1c0b48 5853 mail optional gbuffy_0.2.6-8.diff.gz
8a484ebef8a5f10eeda2fdf9627db7c4 69630 mail optional gbuffy_0.2.6-8_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iEYEARECAAYFAkEIbscACgkQTxqZjtpq5iEU+wCgsozjKNTMMmk7eirE5C2bq5ai
lNsAoMi0yhM/eHXfgKjNVQDiINORg8vt
=6oDp
-END PGP SIGNATURE-
fixing a woody-only bug?
Hi! Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. But the upload has been rejected bu Katie: Rejected: Unknown distribution `woody-proposed-updates'. Thank you for you help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fixing a woody-only bug?
On Wed, Jul 28, 2004 at 07:36:43AM +0200, Magosányi Árpád (mag) wrote: Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. But the upload has been rejected bu Katie: Rejected: Unknown distribution `woody-proposed-updates'. The two names for this suite are proposed-updates and stable. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: fixing a woody-only bug?
On 2004-07-28 Magosányi Árpád (mag) [EMAIL PROTECTED] wrote: Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. [...] No, stable. Afaict from developers reference. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian vs RedHat init script
Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript (maintained upstream), I edited Debian template, to match the functionality provided by the RedHat initscript. Because of this, I have, now, two copies of initscripts (RedHat and Debian), which my sponsor, thinks, is redundant. The initscripts differ quite a bit, and I am not sure, if one format can be converted to another, using simple commands (and thus, be able to maintain just one copy). How do the other packages, get around this? I would be glad, if you would point me to specific packages, that have a (upstream maintained) RedHat specific initscript within the package source. Regards, -- Chirag Kantharia, [EMAIL PROTECTED] pgpXKaiEDX1n6.pgp Description: PGP signature
Re: Debian vs RedHat init script
On Wednesday 28 July 2004 10.09, Chirag Kantharia wrote: [init scripts] Hi, You may want to have a look at the LSB spec - I bet it does say something about init scripts. I haven't looked myself, yet, but it is on my TODO list - I have written a Debian-specific init script for postgrey, but I think I'd like to make it lsb-compatible, so upstream could distribute it (makes the diff smaller, and perhaps the RPM maintainer could use the same...) Current prerelease of the LSB 2.0 spec has something on http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core/iniscrptfunc.html, but I'd have to read and understand it really well, and also look at how much of it Debian offers (with or without lsb package). Haven't looked at the 1.3 spec. greetings -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org pgpx2CIUajs4x.pgp Description: signature
Re: RFS: Folding@home
Nick Lewycky [EMAIL PROTECTED] wrote: If there any sane way to autodetect a network connection? I'm strongly adverse to hassling anybody with extra debconf questions. I'll agree to a debconf question for it only if there's no good way to handle online and offline cases automatically. (This includes systems that might be set up to dial on outgoing connection attempts. However it detects the network should not trigger such a mechanism.) Don't ask me... Well, perhaps route can do the trick. I'm not sure, but I think even in a non-connected dialup system there has to be some connection between the default route and the to-be connection. On an ISDN system, there's a network device up even if not connected, but I'm not sure for normal ppp connections. - there's no documentation. At least you should try to (get permission to) include the command line options in http://folding.stanford.edu/console-userguide.html. [...] I don't get it. What would you want it to do if you ran it from the commandline? Well, e.g. -queueinfo would be interesting, -verbosity might be useful, -forceSSE or -forceasm might be better on certain systems, etc. If you do manage to get it running, it will proceed to download a new machinedependent.dat, create a queue directory, download its FahCore*.exe files, and leave all this crap in the directory you ran it from. Not pretty. That's bad. But one could create a wrapper script in /usr/bin #!/bin/sh FAHDIR=/var/lib/folding EXECUTABLE=ForgotTheFancyName cd $FAHDIR $EXECUTABLE $* You can't reconfigure it, since you aren't running it as the fahclient user in the /var/lib/fahclient directory. You can't ask it for its queue information for the same reason. So the wrapper would have to change it's UID - probably a case for a perl script. I don't have any experience with such stuff, but there was a discussion on this a while ago here in the group. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: CDBS warning
Hallo Andreas, * Andreas Metzler [EMAIL PROTECTED] [2004-07-28 12:31]: i switched my packages to cdbs and i think it is very good. but i have one problem, in the build process i get this warning: /usr/share/cdbs/1/rules/buildcore.mk:59: DEB_BUILD_MAKE_TARGET is a deprecated variable [...] http://bugs.debian.org/cdbs #256079: cdbs: please remove deprecated warning - it's scary thanks, its good to know that i am not the onlyone with this problem. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Hallo Pierre, * Pierre HABOUZIT [EMAIL PROTECTED] [2004-07-28 12:31]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS i read it. it think i read all documentation in the web about cdbs. sebastian said, that the upstream sources are faulty. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Hallo Sebastien, * Sebastien Bacher [EMAIL PROTECTED] [2004-07-28 12:31]: i change my package gtksee to cdbs and have the problem, that the makefile doesn't uses the $(DESTDIR) variable. Then it tries in make install to install .mo-files in /usr/ instead of $(DESTDIR)/usr without cdbs this is no problem and it installs it correctly. i put two logs of the build process with and without cdbs in the attachment, it would be nice, if someone can have a look on it. you find the package without cdbs on: http://nico.f-451.net/debian/gtksee/no_cdbs/ and the package with cdbs: http://nico.f-451.net/debian/gtksee/cdbs/ Your orig.tar.gz has wrong permissions. oh thanks for the hint. BTW it's not a problem. CDBS do its job fine, that's the upstream system that is faulty: $ make install DESTDIR=/tmp .. /usr/bin/install: cannot remove `/usr/share/locale/fr/LC_MESSAGES/gtksee.mo': Permission denied installing fr.gmo as /usr/share/locale/fr/LC_MESSAGES/gtksee.mo /usr/bin/install: cannot remove `/usr/share/locale/es/LC_MESSAGES/gtksee.mo': Permission denied installing es.gmo as /usr/share/locale/es/LC_MESSAGES/gtksee.mo ... etc thats the problem i mean. do you have an idea how to fix it? my skills on autoconf are not so high i think. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Le mercredi 28 juillet 2004 à 12:43 +0200, Nico Golde a écrit : thats the problem i mean. do you have an idea how to fix it? my skills on autoconf are not so high i think. Apparently it worked because the debian/rules used make install prefix= instead of DESTDIR= I'll have a look on the build system today and let you know. Cheers, Sebastien Bacher
Re: problems with cdbs
On Wed, Jul 28, 2004 at 12:41:58PM +0200, Nico Golde wrote: Hallo Pierre, * Pierre HABOUZIT [EMAIL PROTECTED] [2004-07-28 12:31]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS i read it. it think i read all documentation in the web about cdbs. sebastian said, that the upstream sources are faulty. regards nico well, S. Bacher said : Apparently it worked because the debian/rules used make install prefix= instead of DESTDIR= so In your debian/rules using cdbs I guess you have to do that : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) prefix=$(DEB_DESTDIR) (default is : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) ) it was in the doc, in the section I mentionned to you -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Debian vs RedHat init script
Chirag Kantharia [EMAIL PROTECTED] schrieb: Because of this, I have, now, two copies of initscripts (RedHat and Debian), which my sponsor, thinks, is redundant. The initscripts differ quite a bit, and I am not sure, if one format can be converted to another, using simple commands (and thus, be able to maintain just one copy). I would not see a problem in the duplication. If the differences are really so big that a patch does not make sense, I would just ignore the old one. Whether you replace it by your init script (diff is in the diff.gz) or keep your script in debian and use debian/rules to copy it over the redhatish original in debian/tmp/... is just a matter of taste, I'd say. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Debian vs RedHat init script
This one time, at band camp, Chirag Kantharia said: Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript (maintained upstream), I edited Debian template, to match the functionality provided by the RedHat initscript. Because of this, I have, now, two copies of initscripts (RedHat and Debian), which my sponsor, thinks, is redundant. The initscripts differ quite a bit, and I am not sure, if one format can be converted to another, using simple commands (and thus, be able to maintain just one copy). How do the other packages, get around this? I would be glad, if you would point me to specific packages, that have a (upstream maintained) RedHat specific initscript within the package source. One of my packages (clamav) comes with init scripts for both RedHat and Suse. I leave them as is in the source tarball, and just don't put them in the distributed .debs. There are many ways to do this, but I've found the easiest is to have the normal `make install` go to debian/tmp, and then pick what you want out of there to go to the respective package directories. HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpFOudYTtm7o.pgp Description: PGP signature
Re: Debian vs RedHat init script
On Wednesday 28 July 2004 12.55, Chirag Kantharia wrote: On Wed, Jul 28, 2004 at 11:57:02AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: Thanks for the url. I'm not sure how that solves my problem. As I understand you, I need to convince the upstream maintainer to switch to LSB style initscript. I can try doing that. The initscript has Yes, that was my idea - so everybody can use the same init script. some weird function, which might be optionally used by the user, to exchange ssh keys, so that the dump is copied to the server using ssh (scp). The function has no place in the initscript, but RedHat As far as I see it, an lsb compliant init script can still do whatever it wants as long as it does the right things for the start/stop/... arguments, so that shouldn't be a problem. (And you don't have to use that part, after all) prefers to do it, that way. I've placed that key exchange, as part of postinst. If, for some reason, the upstream maintainer doesn't wish to modify the initscript, to adhere to LSB recommendations, then, do I have an alternative way to resort to? I guess just keep your own init script. You may want to document in README.Debian that the ssh key functionality of the RH script is done differently, just in case the Debian package is used by a user used to the other script. greetings -- vbi -- Email returned to sender -- insufficient voltage. pgpSMrdQPc83d.pgp Description: signature
Re: problems with cdbs
#include hallo.h * Pierre HABOUZIT [Tue, Jul 27 2004, 11:19:22PM]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS I think, CDBS restricts too much, simply dangerous hocus pocus. For example, I still don't see how to run a special program directly after dh_libdeps has been run (not before and not after the whole package built). I also cannot see how to override the whole install rule of debian/rules (or anything similar to that inside of the CDBS internals). Regards, Eduard. -- The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in the terrible in-between.-- Centauri Emperor, Babylon 5 - The Coming Of Shadows signature.asc Description: Digital signature
Re: problems with cdbs
On Wed, Jul 28, 2004 at 03:22:19PM +0200, Eduard Bloch wrote: #include hallo.h * Pierre HABOUZIT [Tue, Jul 27 2004, 11:19:22PM]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS I think, CDBS restricts too much, simply dangerous hocus pocus. For example, I still don't see how to run a special program directly after dh_libdeps has been run (not before and not after the whole package built). I also cannot see how to override the whole install rule of debian/rules (or anything similar to that inside of the CDBS internals). Well, I guess cdbs aim is not to remove the fully made by hand with dh_* debian/rules but to simplify its writing for non-pathological cases. I use it since a few month, for kde apps, and web apps, and I find that the resulting debian/rules are really really readable, and don't have the lot of noise a non-cdbs rules has. btw nobody force you to use it ;p -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] signature.asc Description: Digital signature
RFTS: irda-utils
hi folks... as my current sponsor has to renew his gpg-key and the freeze for sarge is about to happen in the foreseeable future, i hereby put a request for a temporary sponsor for the package irda-utils. some important things have changed from -4 to -5, so i believe to need a couple of uploads to the archive until irda-utils will be fit for sarge. Name: irda-utils License: GPL Short description: IrDA management and handling utilities Long description: This package contains userspace utilities to manage and handle infrared devices. It includes irattach, findchip, irdadump, irdaping and irpsion5. OBEX tools are removed since 0.9.5. If you need to use IrOBEX, use openobex-apps package. . Authors: Dag Brattli [EMAIL PROTECTED] and Jean Tourrilhes [EMAIL PROTECTED] Homepage: http://irda.sourceforge.net Obtainable from: deb http://mentors.debian.net/debian unstable main contrib non-free thanks in advance, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: RFTS: irda-utils
hello.. 10 minutes after i sent this, i got my account @debian.org... so forget about the sponsor thing, but you might have a look at it, anyway. :) bye, sebastian * Sebastian Henschel [EMAIL PROTECTED] [2004-07-28 16:21 +0200]: as my current sponsor has to renew his gpg-key and the freeze for sarge is about to happen in the foreseeable future, i hereby put a request for a temporary sponsor for the package irda-utils. some important things have changed from -4 to -5, so i believe to need a couple of uploads to the archive until irda-utils will be fit for sarge. Name: irda-utils License: GPL Short description: IrDA management and handling utilities Long description: This package contains userspace utilities to manage and handle infrared devices. It includes irattach, findchip, irdadump, irdaping and irpsion5. OBEX tools are removed since 0.9.5. If you need to use IrOBEX, use openobex-apps package. . Authors: Dag Brattli [EMAIL PROTECTED] and Jean Tourrilhes [EMAIL PROTECTED] Homepage: http://irda.sourceforge.net Obtainable from: deb http://mentors.debian.net/debian unstable main contrib non-free -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: fixing a woody-only bug?
Hallo Magosányi, * Magosányi Árpád (mag) [EMAIL PROTECTED] [2004-07-28 12:32]: Please tell me how to fix a woody-only bug. I know that the uploaded version should only contain the fix. I thought that the distribution in changelog should be woody-proposed upgrades. But the upload has been rejected bu Katie: Rejected: Unknown distribution `woody-proposed-updates'. do you read this: Packages uploaded to stable need to be compiled on systems running stable, so that their dependencies are limited to the libraries (and other packages) available in stable; for example, a package uploaded to stable that depends on a library package that only exists in unstable will be rejected. Making changes to dependencies of other packages (by messing with Provides or shlibs files), possibly making those other packages uninstallable, is strongly discouraged. The Release Team (which can be reached at [EMAIL PROTECTED]) will regularly evaluate the uploads in stable-proposed-updates and decide if your package can be included in stable. Please be clear (and verbose, if necessary) in your changelog entries for uploads to stable, because otherwise the package won't be considered for inclusion. Developers Reference 5.5.1 regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: problems with cdbs
Hallo Pierre, * Pierre HABOUZIT [EMAIL PROTECTED] [2004-07-28 18:25]: please read [1], especialy section called : Advanced customisation https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS i read it. it think i read all documentation in the web about cdbs. sebastian said, that the upstream sources are faulty. well, S. Bacher said : Apparently it worked because the debian/rules used make install prefix= instead of DESTDIR= sorry, maybe i am blind, he wrotes this: Your orig.tar.gz has wrong permissions. BTW it's not a problem. CDBS do its job fine, that's the upstream system that is faulty: $ make install DESTDIR=/tmp .. /usr/bin/install: cannot remove `/usr/share/locale/fr/LC_MESSAGES/gtksee.mo': Permission denied installing fr.gmo as /usr/share/locale/fr/LC_MESSAGES/gtksee.mo /usr/bin/install: cannot remove `/usr/share/locale/es/LC_MESSAGES/gtksee.mo': Permission denied installing es.gmo as /usr/share/locale/es/LC_MESSAGES/gtksee.mo ... etc so In your debian/rules using cdbs I guess you have to do that : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) prefix=$(DEB_DESTDIR) ah thanks. (default is : DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(DEB_DESTDIR) ) it was in the doc, in the section I mentionned to you i had an offline copy, this was apparent outdated. next time i use the online version. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: package with more than one license: logwatch
Frank Küster wrote: Willi Mann [EMAIL PROTECTED] wrote: For the general problems associated with different licenses in one package, you might find a look at http://bugs.debian.org/218105 informative. (Although I hope that your package isn't as mixed as ours). Thanks. Can anyone tell me please if attached copyright file is OK? What I'm unsure about is if it's enough to list all the mentioned names in the package or do I have to do the painful act of working out who owns a copyright on which of the many scripts? That's the way to go. Of course you have to make sure that this is legally possible at all (is any linking done?). Logwatch's language is perl. It mostly does cat logfile | filter1 | filter2 | filter3 ... But why do you think, linking would be a problem? Public Domain and X11 are both GPL-compatible. Willi This package was debianized by Willi Mann [EMAIL PROTECTED] on Wed, 12 Nov 2003 20:14:15 +0100. It was downloaded from ftp://ftp.kaybee.org/pub/linux/logwatch-5.1.tar.gz Logwatch consists of many individual scripts. Most of them were written by Kirk Bauer [EMAIL PROTECTED], who is also the maintainer of logwatch. Other authors and contributors: --- Dariusz Nierada [EMAIL PROTECTED] David Golden [EMAIL PROTECTED] Eric Moret [EMAIL PROTECTED] Fabrizio Zeno Cornelli [EMAIL PROTECTED] Gerald Teschl [EMAIL PROTECTED] James Wysynski [EMAIL PROTECTED] Jim O'Halloran [EMAIL PROTECTED] Joe Digilio [EMAIL PROTECTED] Kenneth Porter [EMAIL PROTECTED] Lars Skjærlund [EMAIL PROTECTED] Luuk de Boer [EMAIL PROTECTED] Luuk de Boer [EMAIL PROTECTED] Manuel Mitnyan [EMAIL PROTECTED] M. B. Heath [EMAIL PROTECTED] Michael Romeo [EMAIL PROTECTED] Michael Stovenour [EMAIL PROTECTED] Mike Tremaine [EMAIL PROTECTED] Osma Ahvenlampi [EMAIL PROTECTED] Pawe? Go?aszewski [EMAIL PROTECTED] Pawel Jarosz [EMAIL PROTECTED] Sean Boran [EMAIL PROTECTED] Simon Liddington [EMAIL PROTECTED] Simon Liddington [EMAIL PROTECTED] S. Schimkat www.schimkat.dk Sven Conrad [EMAIL PROTECTED] Sven Conrad [EMAIL PROTECTED] Willi Mann [EMAIL PROTECTED] (Note that this is a semi-autogenerated list. See README.Debian for more information.) Licenses: - Except for a few scripts, logwatch is distributed under the permissive X11 license. The exceptions: scripts/services/clamav-milter: GPL scripts/services/rt314: Public Domain Text of the licenses: - X11 license: -BEGIN LICENSE -- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. --END LICENSE-- GPL: -BEGIN LICENSE -- This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 dated June, 1991. This package is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. --END LICENSE--
Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
Hi, given the current sarge deadline and the opinions expressed by some of the release team a full amd64 port in sarge is not going to happen. So lets move on. What else can we do for amd64 users? We have a fully working i386 port which works on amd64 systems too. What we need most now is support for: 1. Kernel support for amd64 to run 32/64 bit binaries I want to upload a kernel-image-2.6.7-amd64 to i386. That would be along the same lines as the sparc64 or s390x kernel image in sparc or s390 respectively. So nothing new there. 2. Support to run dynamically linked 64 binaries (e.g. from SuSe/RH) What is needed is a /lib64 and /usr/lib64 directory with the core libraries. There already is a ia32-libs packages doing the reverse for ia64 and pure64. This just reverses the roles. Again nothing new. 3. Support to compile 64 bit binaries The kernel and libs need to be compiled somewhere. They could be build on pure64 and uploaded to i386 without problems but it would be nicer if they could be build under sarge i386 itself. This could be eigther a cross compiler (like the rest of the cross tool packages) or a 64bit native compiler. I tend to the later even if that restricts building those packages to an actual amd64 system. Thesource for the toolchain is already in sarge so no GPL problems even if (3) is scratched. So who is willing to sponsor the following packages: kernel-image-2.6.7-amd64 amd64-libs amd64-libs-dev gcc-3.3-amd64 gcc-3.4-amd64 binutils-amd64 None of those are base or standard so there is no must be today rush. But it still needs to be rushed a bit. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
Goswin von Brederlow wrote: Hi, given the current sarge deadline and the opinions expressed by some of the release team a full amd64 port in sarge is not going to happen. So lets move on. What else can we do for amd64 users? What about maintaining a stable repository for amd64 on alioth alongside the official sarge one? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian vs RedHat init script
Adrian 'Dagurashibanipal' von Bidder wrote: Thanks for the url. I'm not sure how that solves my problem. As I understand you, I need to convince the upstream maintainer to switch to LSB style initscript. I can try doing that. The initscript has Yes, that was my idea - so everybody can use the same init script. To use lsb init scripts in Debian, you need to have the lsb package installed. I don't think that we want to have debian packages depending on lsb, for one thing it pulls in lots of other stuff. I've also discovered that supposedly lsb compliant distributions violate its init script policy in various ways which can be quite hard to work around in an lsb init script, but YMMV there. -- see shy jo signature.asc Description: Digital signature
100% Gua-rantee 0r M0ney Back! vW
Debian-laptop-request Volumizer Doubles, Triples, Quadruples and MORE! ... not just volume of ejaculate, but intensity and power of 0rgasms. IT WILL ABSOLUTELY BLOW YOUR MIND Enjoy a bigger, more impressive load of cum ejaculation. Experience orgasms that go on and on..and on! Best sexual experiences of a lifetime are here n0w! http://sizeit1.com/vol/?a=07 re m0ve: http://sizeit1.com/rvm/ Q[20-60
RFS: gbuffy (adopted)
Hi all,
I'm looking for a sponsor to upload a new gbuffy version for me. I've
decided to adopt the gbuffy package since it is in bad shape, I use it
every day and I wouldn't like it to be removed from Debian. The wnpp
bug is #242096.
This version cleans up the packaging a little and, most importantly,
fixes a nasty segfault (#241371) which makes the package if not
unusable, at least quite user unfriendly. After this version has
entered testing, I plan to introduce some features myself, since
upstream is dead.
The package description follows, and the changes file is attached. If
you finally decide to sponsor me, please pass -v0.2.6-5 to debuild
or dpkg-buildpackage in order to get all un-uploaded versions listed.
Any other input of course appreciated.
gbuffy_0.2.6-8 is available in mentors.debian.net:
http://mentors.debian.net/debian/pool/main/g/gbuffy/gbuffy_0.2.6-8.dsc
http://mentors.debian.net/debian/pool/main/g/gbuffy/gbuffy_0.2.6-8.diff.gz
the orig.tar.gz package may be fetched from any Debian mirror, e.g.:
http://ftp.es.debian.org/debian/pool/main/g/gbuffy/gbuffy_0.2.6.orig.tar.gz
thanks.
Package: gbuffy
Priority: optional
Section: mail
Version: 0.2.6-8
Description: A GTK+-based, XBuffy-like multiple mailbox biff program
GBuffy will poll multiple mailboxes for new mail. It will list the
number of new messages in each mailbox you configure. It will also
highlight the mailboxes which have new mail. Pressing the left mouse
button on a mailbox with new mail will display the Sender and Subject
of each new message. Additionally, GBuffy will display the X-Face
header for messages which have them. Pressing the middle mouse button
on a mailbox will launch the configured command, generally a command
to read the mailbox with your favorite mailreader. Pressing the right
mouse button will bring up the configure menu.
.
GBuffy is currently capable of watching MBOX, MMDF, Maildir and MH
Folders. This version also supports IMAP4rev1 and NNTP with XOVER
mailboxes. Support for an external program for notification is
planned.
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
-- Oscar Hammerstein II
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 29 Jul 2004 05:26:16 +0200
Source: gbuffy
Binary: gbuffy
Architecture: source i386
Version: 0.2.6-8
Distribution: unstable
Urgency: low
Maintainer: Adeodato Simó [EMAIL PROTECTED]
Changed-By: Adeodato Simó [EMAIL PROTECTED]
Description:
gbuffy - A GTK+-based, XBuffy-like multiple mailbox biff program
Closes: 241371 241372 242096
Changes:
gbuffy (0.2.6-8) unstable; urgency=low
.
* debian/rules:
- wipe out commented stuff for building gbuffy-gnome.
- move DH_COMPAT to debian/compat.
- general cleanup.
* removed debian/gbuffy{_applet.desktop,-gnome.menu,.gnorba}.
* debian/copyright: added copyright notice for files from mutt.
* debian/control: list myself as the package maintainer. (Closes: #242096)
.
gbuffy (0.2.6-7) unstable; urgency=low
.
* debian/patches: removed 20_convert-charset, which is quite untested, in
order to make a version suitable to enter sarge and stay there for quite a
long time.
* debian/control: removed Build-Depends on xlibs-dev.
.
gbuffy (0.2.6-6) unstable; urgency=low
.
* debian/control:
+ remove obsolete Build-Depends on libgnome-dev, since the gnome version
is no longer built.
+ bumped Standards-Version to 3.6.1 (no changes required).
* debian/patches/:
+ updated 10_libwings to avoid crashing after adding a new mailbox.
(Closes: #241371, #241372)
+ added 20_convert-charset, to convert RFC 2047 decoded strings to the
local charset (scratch-an-itch patch).
* debian/copyright: updated download URL.
* debian/menu: use the full path in the command.
Files:
9f91d572d82dbefa1af056747b2dbfa8 627 mail optional gbuffy_0.2.6-8.dsc
e0b82b6601b1acb7d214c7221f1c0b48 5853 mail optional gbuffy_0.2.6-8.diff.gz
8a484ebef8a5f10eeda2fdf9627db7c4 69630 mail optional gbuffy_0.2.6-8_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iEYEARECAAYFAkEIbscACgkQTxqZjtpq5iEU+wCgsozjKNTMMmk7eirE5C2bq5ai
lNsAoMi0yhM/eHXfgKjNVQDiINORg8vt
=6oDp
-END PGP SIGNATURE-
