ITO: tkirc
Hello developers and soon-to-be developers, I've switched to irssi and don't know much about Tcl/Tk. Someone of you can probably do a better job with tkirc, so i wish to give it away. I'll gladly sponsor if needed. Packages of tkirc 2.42, still needing a bit of testing, can be found from http://master.debian.org/~pa/tkirc/. If no-one wants to take over, i will upload them shortly. -- P.A. Knuutila [EMAIL PROTECTED] 363C ACE2 0A4F DE7E B67A 0223 C53B 932B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please help updating calendar
On Sun, 10 Sep 2000, Julian Gilbey wrote: On Sun, Sep 10, 2000 at 03:54:13AM +0300, Shaul Karl wrote: If there are no fixed events then everything should go in the yearly files. The events are fixed. The main point is that the Jewish calendar is based on the motion of the moon, so that a regular Jewish year is 354 days long (Yet there are years with an extra month and maybe other mechanisms to compensate for that). But as far as I know every Jewish event could be calculated in advance. In this context, fixed = have a set Gregorian date. So there are no fixed events in the Jewish calendar. Julian And events in the Wicca 'calendar' are based on the solstices and equinoxes and would not be fixed either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please help updating calendar
On Mon, Sep 11, 2000 at 09:34:41PM -0700, [EMAIL PROTECTED] wrote: On Sun, 10 Sep 2000, Julian Gilbey wrote: On Sun, Sep 10, 2000 at 03:54:13AM +0300, Shaul Karl wrote: If there are no fixed events then everything should go in the yearly files. The events are fixed. The main point is that the Jewish calendar is based on the motion of the moon, so that a regular Jewish year is 354 days long (Yet there are years with an extra month and maybe other mechanisms to compensate for that). But as far as I know every Jewish event could be calculated in advance. In this context, fixed = have a set Gregorian date. So there are no fixed events in the Jewish calendar. Julian And events in the Wicca 'calendar' are based on the solstices and equinoxes and would not be fixed either. Instead of doing this every year, why not write small programs to generate a new Wiccan calendar and a new Jewish calendar (and parts of the Christian calendar) each year? Not that I have the knowledge to do so . . . -- David Starner - [EMAIL PROTECTED] http/ftp: dvdeug.dhis.org And crawling, on the planet's face, some insects called the human race. Lost in space, lost in time, and meaning. -- RHPS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71237: cdparanoia: cannot use cdparanoia 'out of the box' as a non-root user.
On Mon, 11 Sep 2000, Dale E. Martin wrote: Basically, cdparanoia requires use of 'scsi-generic' (/dev/sg*) when reading from SCSI cdrom drives. /dev/sg device nodes are created with root.root ownership and mode 0600. Which is correct - you definitely want tight access on your devices. As relaxing permissions in general on /dev/sg* would create more of a potential security risk for SCSI-based systems, and there is no constant mapping between [/dev/scd*] and [/dev/sg*], cdparanoia should be made suid root and should drop root privelages after determining which /dev/sg* device to use and opening said device. Such checking should also be made after a permission check of the /dev/scd* device. I'm not sure I agree with your solution. cdparanoia runs fine (AFAIK) if you go set the permissions on the appropriate device correctly. The basic solution that I've used on my own systems is to change the ownership of the appropriate sg* and scd* devices to the audio group, set the permissions to 0660, and then added myself (and anyone else needing access on shared machines) to the audio group. The problem I have here is that the 'appropriate device' is not guarenteed to stay constant with respect to the SCSI bus and ID, the way IDE devices are for example. On my system (I believe this is actually the default) scd devices are group audio, perm 0660, and my cdripper account is in the audio group. Currently, I have two hard drives and two cdrom drives in this machine. The hard drives are at IDs 0 and 1, and the cdrom drives are at IDs 5 and 6. ID: generic: 0 sg0 1 sg1 5 sg2 6 sg3 Now I want to connect an external hard drive to my machine, so I have more storage space for my music collection. I set this drive to ID 3. ID: generic: 0 sg0 1 sg1 3 sg2 5 sg3 6 sg4 Notice that now my external hard drive has access by audio group through the generic device, and my second cdrom drive is no longer accessable by the audio group. Basically, cdparanoia and the installer scripts cannot depend on a fixed mapping between the scd device and the sg device. On the other hand, I believe this will be a moot point under devfs. Granted, this isn't so simple for newbie users but it works without running cdparanoia suid root, which would generally be considered a Bad Thing. Perhaps the right answer is a post install that figures out the devices to use (via cdparanoia itself) and then asks who needs to be able to run it. That would be more work then I currently have time for, but I would entertain any solution that was offered. -- System Information Debian Release: 2.2 Kernel Version: Linux heathen 2.2.17-usb-trelos #1 Fri Aug 4 21:11:48 PDT 2000 i586 unknown Versions of the packages cdparanoia depends on: ii libcdparanoia0 3a9.7-2 Shared libraries for cdparanoia (runtime lib) I will be updating the package this week as I've received several bug reports, including one about source dependencies and a couple that I've been putting off for some time. I'll be putting some info in Readme.Debian about IDE/SCSI emulation, and I'll also note the solution that I've suggested here. Comments welcome. I'm not subscribed to debian-devel so please Cc me on any replies. Thanks, Dale -- +-- pgp key available ---+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer | | [EMAIL PROTECTED]|http://www.clifton-labs.com | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Best way to depend on an xserver but conflict with XF86 v4 ?
I have a package (utah-glx) which needs can be used only on a XF86 3.3.6 server. How can I express this ? Depends: xserver(4.0) does not work since xserver is a virtual package. I found: Depends: xserver Conflicts: xfree86-common(=4.0) to be working. Is it the right way (or a good enough way) ? Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
determining if we're using db.h from libc6 or libdb2?
Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Thanks, Darren -- [EMAIL PROTECTED]http://www.daft.com/~torin/ [EMAIL PROTECTED][EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Fri, Sep 08, 2000 at 12:28:54AM +0200, Gregor Hoffleit wrote: Indeed. A dependency may also mean that the package is a binary extension module for the Python interpreter which will be linked dynamically with the interpreter (at some time, when the module is imported). In this case, if the module contains GPL code, I would currently stay away from distributing it with a dependency on Python 1.6. For the record: python-gnome, -gtk, -gdk-imlib and -glade are LGPL so should be okay with python 1.6 I presume. Note that the current packages are neither source nor binary compatible with a newer python. Thanks Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting current keymap
On Fri, Sep 08, 2000 at 07:39:04PM +0200, Yann Dirson wrote: Probably this should be discussed here and if noone objects changed ASAP, so that any problems get caught quickly. Don't change that. Beginners would be very confused if the keytable is not working as expected. Not everybody can work with a US keyboard table if the need arises. Debian should try to get more user friendly instead of getting uglier I think. Thanks Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71107: [wmono@debian.org: Re: RFC: removal of libqt1g from woody]
reopen 71107 retitle 71107 Explorer is unmaintained and should be removed thanks On Sun, Sep 10, 2000 at 03:27:00AM +1200, Michael Beattie wrote: It's orphaned. And has been for about 7 months. The maintainer should be debian-qa, but it has not been reset to that. ...that would explain it. :) righto then, if people come to a consensus, file a bug on ftp.d.o to get it moved to project/orphaned/, removed, or have the maintainer overriden. Please move it to orphaned. It's neither maintained in Debian nor upstream and the homepage is dead. We have enough file manager in the dist. If a new version appears we can still add it to potato with a Replaces: explorer and that's it. Greetings Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, 11 Sep 2000, Mark Brown wrote: This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. Is it realy so much easier? I do not have experiences with maintaining patched software. But I experienced for example, that I had to made major changes to apply a patch for a 2.0.30 kernel to a debianiced 2.0.36 kernel. And with I the software I develop, there is seldom one patch that would not collide with an other. I imagine it much easier to have the orginal code and the debian code, where I can get from one to the other through one diff. Correct me, if I err, but when you have an code with two patches and want to change patch 1 to an newer version of this, wouldn't you need to change patch 2 then, too? Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Tue, Sep 12, 2000 at 11:42:32AM +0200, Bernhard R. Link wrote: On Mon, 11 Sep 2000, Mark Brown wrote: This only works, if the diff's are independend or one diff is diff are on the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. Is it realy so much easier? I do not have experiences with maintaining patched software. But I experienced for example, that I had to made major changes to apply a patch for a 2.0.30 kernel to a debianiced 2.0.36 kernel. And with I the software I develop, there is seldom one patch that would not collide with an other. I imagine it much easier to have the orginal code and the debian code, where I can get from one to the other through one diff. Correct me, if I err, but when you have an code with two patches and want to change patch 1 to an newer version of this, wouldn't you need to change patch 2 then, too? Generally, you don't have a problem with colliding patches. Even when you do have some overlap, it's not all that difficult. After all, we are only talking 5 - 20 patches on average, not 50 - 100. Most patches are small and in the form of security fix or get rid of compiler warnings etc.. Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. I think aside of one diff or many diffs a list of patches done to the code and where you got them from is a good thing to have in every package. Most patches are done by the maintainer, or submitted as bug reports. Those are listed in the changelog, but even then, it doesn't help dereference the patched source to it's individual patches. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: determining if we're using db.h from libc6 or libdb2?
On Tue, Sep 12, 2000 at 12:46:02AM -0700, Darren/Torin/Who Ever... wrote: Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Keep it at db.h, since in a few days, it wont matter. Db2 is getting removed from glibc, and your only choice will be db.h or db2/db.h from libdb2 (both the same file, just db.h is the default place). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting current keymap
12.09.2000 pisze Torsten Landschoff ([EMAIL PROTECTED]): Don't change that. Beginners would be very confused if the keytable is not working as expected. Not everybody can work with a US keyboard table if the need arises. Debian should try to get more user friendly instead of getting uglier I think. Setting keymap _before_ /usr is mounted is an interesting approach to the system boot schema design, because include statements are in most keymap files (what can result in broken keymap). Keyboard mapping should be set up early, but _after_ /usr partition is mounted. best regards, Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] ``I may not be totally perfect, but parts of me are excellent.'' -- Ashleigh Brilliant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71237: cdparanoia: cannot use cdparanoia 'out of the box' as a non-root user.
The problem I have here is that the 'appropriate device' is not guarenteed to stay constant with respect to the SCSI bus and ID, the way IDE devices are for example. On my system (I believe this is actually the default) scd devices are group audio, perm 0660, and my cdripper account is in the audio group. Currently, I have two hard drives and two cdrom drives in this machine. The hard drives are at IDs 0 and 1, and the cdrom drives are at IDs 5 and 6. ID: generic: 0 sg0 1 sg1 5 sg2 6 sg3 Now I want to connect an external hard drive to my machine, so I have more storage space for my music collection. I set this drive to ID 3. ID: generic: 0 sg0 1 sg1 3 sg2 5 sg3 6 sg4 Notice that now my external hard drive has access by audio group through the generic device, and my second cdrom drive is no longer accessable by the audio group. Basically, cdparanoia and the installer scripts cannot depend on a fixed mapping between the scd device and the sg device. I think that's even more of an argument for not having automated lookups occuring. I.e. you want to know what you're doing to be accessing raw SCSI devices. That's simply my opinion of course... I can see how you arrived at the solution that you did now though. So far, you're the only person that's sent me email advocating SUID root. Would documenting that as a solution, and describing how to do it in Readme.Debian, along with the other approaches/problems be sufficient in your opinion? On the other hand, I believe this will be a moot point under devfs. I brought this up once on debian devel. A lot of people are very anti-devfs. I still haven't ever played with it and have no opinion of my own on it. Later, Dale -- +-- pgp key available ---+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer | | [EMAIL PROTECTED]|http://www.clifton-labs.com | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dualing banjos
Hi, I saw your ad about sheet music for this. Could you please send it to me? I did find it on olga.net but it looks incomplete. Cheers Marty __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: devfsd permissions and makedev permissions coordination
On Sep 11, Daniel Jacobowitz [EMAIL PROTECTED] wrote: This is obviously wrong, ttys must have 620 permissions (or 600 if you don't want people talk(1)ing to you, but I think the default should be to allow it). For ttys owned by a shell that's true, but it's set up by login(1), not MAKEDEV (or devfsd). For other ttys (vcs, not serial etc.), the current If you use open(1) you get 666 ttys. This is a problem IMO. Sounds to me like a bug in open(1) then, no? Does it at least chown() them to the user opening them? Yes, because this is what it's expected to do. But I see no good reason for devfsd to create devices with insecure permissions. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to depend on an xserver but conflict with XF86 v4 ?
Previously Philippe Troin wrote: I have a package (utah-glx) which needs can be used only on a XF86 3.3.6 server. How can I express this ? Depends: xserver(4.0) does not work since xserver is a virtual package. What should work with dpkg 1.7.0 once that is ready if someone makes xserver a versioned provide. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpERDOj2ca0C.pgp Description: PGP signature
Re: Getting current keymap
Hi Miros/law! On Tue, 12 Sep 2000, Miros/law `Jubal' Baran wrote: 12.09.2000 pisze Torsten Landschoff ([EMAIL PROTECTED]): Don't change that. Beginners would be very confused if the keytable is not working as expected. Not everybody can work with a US keyboard table if the need arises. Debian should try to get more user friendly instead of getting uglier I think. Setting keymap _before_ /usr is mounted is an interesting approach to the system boot schema design, because include statements are in most keymap files (what can result in broken keymap). Keyboard mapping should be set up early, but _after_ /usr partition is mounted. This may be correct from a technical POV. But it can be a horror for a user. e.g. the fsck on /usr fails and the user has to correct this problem by manually running fsck and what else. Having to enter the root password (that should contain special chars after all) with a keyboard layout you're not used to and without echoing can be /really/ difficult, if it is possible at all for our user. I think setting the keymap as early as possible is a good thing. yours, peter -- PGP encrypted messages preferred. http://www.cosy.sbg.ac.at/~ppalfrad/ [please CC me on lists] pgp2ss9PfFDLu.pgp Description: PGP signature
Re: gettextized console-apt
On Tue, Sep 12, 2000 at 04:16:04AM +1100, Patrick Cole [EMAIL PROTECTED] wrote: I have added gettext-support to console-apt. The gettextized console-apt can print multi-lingual messages. Could you merge it into console-apt? Looks good Kiwamu, although it didn't compile when I did ./configure --with-included-gettext, but I did fix it, just a mix up about where it was looking for config.h. Thank you. :- You may wish to gettext-ise the cvs version (CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/deity; cvs co capt) as it will replace the the current stable version in the near future. I'll try it. -- Tokyo Metropolitan University Kiwamu Okabe Mail: [EMAIL PROTECTED] URL: http://silica.eei.metro-u.ac.jp/~kiwamu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scsh (Was: Re: My orphaned packages.)
On 11 Sep 2000, Karl M. Hegbloom wrote: Daniel == Daniel Kobras [EMAIL PROTECTED] writes: Daniel On 10 Sep 2000, Karl M. Hegbloom wrote: `scsh' ought to be taken over by someone who actually uses it. I've not even looked at it in over a year. Daniel If nobody objects I'd like to do this together with Martin Daniel Gasbichler who wrote a fair part of scsh 0.6. But me Daniel having just applied for Debian maintainership this will Daniel take some time... I also have an adoption offer from Georg Bauer (Cc'd), who I responded to on the attached message, telling him that if he contacts the new maintainer team and has a working `scsh' package, he can have it. Since you are teaming with Martin Gasbichler, and since Martin is a co-author of Scsh, I'd say that puts you two in as most qualified to handle the package. (Daniel? Please forward this mail to Martin.) Perhaps the three of you could team? What do you all think? Sounds good to me. Martin is on vacation for a couple of days but I'm sure we can work out a scheme everyone's confident with as soon as he's back. The big problem IMHO however being that neither of us is registered as a developer so far. I'd be happy to work on debs for a recent version of scsh but we'd really need some maintainer to adopt the package until my appliance gets through. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scsh (Was: Re: My orphaned packages.)
On 00-09-12 Daniel Kobras wrote: On 11 Sep 2000, Karl M. Hegbloom wrote: Daniel == Daniel Kobras [EMAIL PROTECTED] writes: Daniel On 10 Sep 2000, Karl M. Hegbloom wrote: `scsh' ought to be taken over by someone who actually uses it. I've not even looked at it in over a year. Daniel If nobody objects I'd like to do this together with Martin Daniel Gasbichler who wrote a fair part of scsh 0.6. But me Daniel having just applied for Debian maintainership this will Daniel take some time... I also have an adoption offer from Georg Bauer (Cc'd), who I responded to on the attached message, telling him that if he contacts the new maintainer team and has a working `scsh' package, he can have it. Since you are teaming with Martin Gasbichler, and since Martin is a co-author of Scsh, I'd say that puts you two in as most qualified to handle the package. (Daniel? Please forward this mail to Martin.) Perhaps the three of you could team? What do you all think? Sounds good to me. Martin is on vacation for a couple of days but I'm sure we can work out a scheme everyone's confident with as soon as he's back. The big problem IMHO however being that neither of us is registered as a developer so far. I'd be happy to work on debs for a recent version of scsh but we'd really need some maintainer to adopt the package until my appliance gets through. You don't need a package maintainer to adopt the package for getting a new package uploaded. A sponsor for you and Martin would be enough to upload the package to the archive. Do you already are in the NM-Queue (nm.debian.org)? Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFA: Gmp3 - Adopt it or remove it right away?
Package: wnpp Severity: normal Hello! It isn't supported upstream anymore. Homepage is gone, mail to author bounces. Gmp3 isn't very nice and a little bit buggy for me. I don't have the knowledge and time to work at the source and don't feel like trying, either. If someone wants to jump in, now is the right time to do it. I would suggest to remove Gmp3 from Debian. There are nice players out there and Gmp3 isn't very functional compared to the other programs. What should I do? I didn't orphan it right now because I am willing to do some uploads, apply patches or do other changes if someone provides information how to do it. I won't do this forever though. bye Florian -- Florian Hinzmann private: [EMAIL PROTECTED] Debian: [EMAIL PROTECTED] PGP-Key fingerprint: DD 61 74 34 04 FB 8A BD 43 54 83 38 0C 82 EF B1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scsh (Was: Re: My orphaned packages.)
On Tue, 12 Sep 2000, Christian Kurz wrote: You don't need a package maintainer to adopt the package for getting a new package uploaded. A sponsor for you and Martin would be enough to upload the package to the archive. Okay, sorry, wrong wording. That's what I had in mind. Someone to take the scsh package and put it up for us. In fact, it's the very procedure Joey Hess and I follow for noflushd. Do you already are in the NM-Queue (nm.debian.org)? Yes. I had just applied when I saw Karl's mail about orphaned scsh. Thanks, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dualing banjos
marty macdonald wrote: So far, the Linux kernel only supports single, not dual banjos. There is, however, a patch available that will make the 2.2 kernel support up to 15 banjos. The 2.4 kernel, of course, will support any number of banjos. (Well, 65535, but who needs more than that?) :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71237: cdparanoia: cannot use cdparanoia 'out of the box' as a non-root user.
On Tue, 12 Sep 2000, Dale E. Martin wrote: The problem I have here is that the 'appropriate device' is not guarenteed to stay constant with respect to the SCSI bus and ID, the way IDE devices are for example. On my system (I believe this is actually the default) scd devices are group audio, perm 0660, and my cdripper account is in the audio group. Currently, I have two hard drives and two cdrom drives in this machine. The hard drives are at IDs 0 and 1, and the cdrom drives are at IDs 5 and 6. ID: generic: 0 sg0 1 sg1 5 sg2 6 sg3 Now I want to connect an external hard drive to my machine, so I have more storage space for my music collection. I set this drive to ID 3. ID: generic: 0 sg0 1 sg1 3 sg2 5 sg3 6 sg4 Notice that now my external hard drive has access by audio group through the generic device, and my second cdrom drive is no longer accessable by the audio group. Basically, cdparanoia and the installer scripts cannot depend on a fixed mapping between the scd device and the sg device. I think that's even more of an argument for not having automated lookups occuring. I.e. you want to know what you're doing to be accessing raw SCSI devices. That's simply my opinion of course... I can see how you arrived at the solution that you did now though. So far, you're the only person that's sent me email advocating SUID root. Would documenting that as a solution, and describing how to do it in Readme.Debian, along with the other approaches/problems be sufficient in your opinion? On the other hand, I believe this will be a moot point under devfs. I brought this up once on debian devel. A lot of people are very anti-devfs. I still haven't ever played with it and have no opinion of my own on it. I haven't played with or looked at devfs yet either, but what I have heard indicates that device naming (outside the /dev/ compatibility entries) should be closer in style to Solaris device naming, in particular where bus-based devices are named with the bus # and ID #. Anyway, I would suggest that, if cdparanoia is set suid root, it do whatever device consistancy checking it does, open the particular generic device it needs, then drop suid privelages. The administrator should be asked if cdparanoia should be installed suid root, with the default to be NO. debconf could ask something like the following: cdparanoia is by default not installed SUID root. This is normally a good thing, because a bug in the cdparanoia executable or the kernel SCSI system could conceivably lead to cdparanoia accessing a non-cdrom device and potentially causing data corruption. However, if you wish to allow normal users access to extract audio using SCSI cdrom drives, then you should install cdparanoia SUID root. If you do not have any SCSI cdrom drives you should answer NO here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dualing banjos
On Tue, 12 Sep 2000, Keith G. Murphy wrote: So far, the Linux kernel only supports single, not dual banjos. There is, however, a patch available that will make the 2.2 kernel support up to 15 banjos. The 2.4 kernel, of course, will support any number of banjos. (Well, 65535, but who needs more than that?) :-) Although both Solaris and windows 2000 currently outpace Linux in sheer numbers of banjos supported a key point to consider is Linux is more portable. You can build a beowulf cluster that supports foghorns, bagpipes and cats in heat along with your banjos. A team at IBM is currently trying to port the Linux Kernel to Britney Spears but it is highly experimental and the system may never be stable under such hostile conditions. -- Jaldhar H. Vyas [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dualing banjos
On Tue, Sep 12, 2000 at 10:51:23AM -0500, Keith G. Murphy [EMAIL PROTECTED] was heard to say: The 2.4 kernel, of course, will support any number of banjos. (Well, 65535, but who needs more than that?) :-) No-one needs more than 640 kilobytes of memory... Daniel -- /- Daniel Burrows [EMAIL PROTECTED] -\ | You see, I've already stolen the spork of wisdom | |and the spork of courage.. together with the spork | |of power, they form the mighty...TRI-SPORK! -- Fluble | \--- (if (not (understand-this)) (go-to http://www.schemers.org)) / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting current keymap
On Tue, Sep 12, 2000 at 01:34:49PM +0200, Miros/law `Jubal' Baran wrote: Setting keymap _before_ /usr is mounted is an interesting approach to the system boot schema design, because include statements are in most keymap files (what can result in broken keymap). Keyboard mapping should be set up early, but _after_ /usr partition is mounted. That's why the includes are assembled into a self-contained keymap which is stored in /etc. BTW: The correct approach to this would be to have a kernel with the right keymap as the default :) cu Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71237: cdparanoia: cannot use cdparanoia 'out of the box' as a non-root user.
On Tue, Sep 12, 2000 at 07:48:14AM -0400, Dale E. Martin wrote: I can see how you arrived at the solution that you did now though. So far, you're the only person that's sent me email advocating SUID root. Would documenting that as a solution, and describing how to do it in Readme.Debian, along with the other approaches/problems be sufficient in your opinion? In general, it is a bad idea to set the setuid bit on programs that were not designed to be so. Most programs written for use without elevated privileges contain bugs and potential security holes that could lead to problems if they are made setuid. I would not recommend this method as a solution to Debian users. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting current keymap
12.09.2000 pisze Torsten Landschoff ([EMAIL PROTECTED]): That's why the includes are assembled into a self-contained keymap which is stored in /etc. Only if you use pre-supplied keymaps. When you use customized ones[1] it's not that easy. BTW: The correct approach to this would be to have a kernel with the right keymap as the default :) The best way to achieve this would be /lib/modules/telepathy.o ;-) best regards, Jubal [1] like me, another keys for mode_switch ([LWin/Menu], not [Alt]), some extra characters directly from keyboard (FYI, I have german QWERTZ keyboard with QWERTY polish layout and umlauts with mode_switch + usual umlaut place on german keyboard). And I WANT MORE KEYS. 105 isn't too many. ;-) -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] In a crisis, you will choose the worst possible course of action. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: RFA: Gmp3 - Adopt it or remove it right away?
It isn't supported upstream anymore. Homepage is gone, mail to author bounces. Gmp3 isn't very nice and a little bit buggy for me. I don't have the knowledge and time to work at the source and don't feel like trying, either. I say ditch it. No sense filling up Debian with dead code. Especially when there are a billion mp3 players. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#71237: cdparanoia: cannot use cdparanoia 'out of the box' as a non-root user.
On Mon, 11 Sep 2000 [EMAIL PROTECTED] wrote: The problem I have here is that the 'appropriate device' is not guarenteed to stay constant with respect to the SCSI bus and ID, the way IDE devices are for example. On my system (I believe this is actually the default) scd devices are group audio, perm 0660, and my cdripper account is in the audio group. Currently, I have two hard drives and two cdrom drives in this machine. The hard drives are at IDs 0 and 1, and the cdrom drives are at IDs 5 and 6. ID: generic: 0 sg0 1 sg1 5 sg2 6 sg3 Now I want to connect an external hard drive to my machine, so I have more storage space for my music collection. I set this drive to ID 3. ID: generic: 0 sg0 1 sg1 3 sg2 5 sg3 6 sg4 Notice that now my external hard drive has access by audio group through the generic device, and my second cdrom drive is no longer accessable by the audio group. To circumvent this problem, you could use the scsidev package to create the appropriate nodes in /dev/scsi/ and set permissions on them. These permissions will be preserved on reboots. The major and minor device numbers will be adjusted if necessary at every reboot. /dev/scsi/sgh24-6c00c0i3l0 will always point at LUN 0 of the device with ID 3 on bus 0 of the SYM5c8xx scsi-adapter at memory address 6c000. You do need to run scsidev again if you add scsi devices while Linux is running, though. Remco -- qn195-66-31-144: 7:55pm up 7 days, 20:09, 11 users, load average: 1.02, 1.21, 1.40 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
digest version broken?
I was getting both user and devel as digests, and both went quiet. I subscribed to both as digest again, in case I'd been knocked off the list, and still nothing, so I subscribed as non-digest and I'm getting email, enough that it should have kicked out a digest, but still no digest. Looks like digests are broken, could someone fix please? Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Restarting Build on a Package
This is a stupid question, but I've never figured it out: Is there a way to restart a build of a package *AND* still be able to generate the source tarball and diff? I've tried the -nc option to dpkg-buildpackage, but it always omits the orig.tar.gz. I'm trying to bootstrap a program that takes quite a while to build, and if it dies during configuration and I have to rebuild it again I'm going to pull my hair out. Thanks, -Brent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scsh (Was: Re: My orphaned packages.)
Daniel == Daniel Kobras [EMAIL PROTECTED] writes: Daniel On 11 Sep 2000, Karl M. Hegbloom wrote: Daniel == Daniel Kobras [EMAIL PROTECTED] writes: Daniel On 10 Sep 2000, Karl M. Hegbloom wrote: `scsh' ought to be taken over by someone who actually uses it. I've not even looked at it in over a year. Daniel If nobody objects I'd like to do this together with Martin Daniel Gasbichler who wrote a fair part of scsh 0.6. But me Daniel having just applied for Debian maintainership this will Daniel take some time... I also have an adoption offer from Georg Bauer (Cc'd), who I responded to on the attached message, telling him that if he contacts the new maintainer team and has a working `scsh' package, he can have it. Since you are teaming with Martin Gasbichler, and since Martin is a co-author of Scsh, I'd say that puts you two in as most qualified to handle the package. (Daniel? Please forward this mail to Martin.) Perhaps the three of you could team? What do you all think? Daniel Sounds good to me. Martin is on vacation for a couple of days but I'm sure Daniel we can work out a scheme everyone's confident with as soon as he's Daniel back. The big problem IMHO however being that neither of us is registered Daniel as a developer so far. I'd be happy to work on debs for a recent version Daniel of scsh but we'd really need some maintainer to adopt the package until my Daniel appliance gets through. Georg Bauer wrote back saying that he thinks you and Martin are more qualified, and thus should maintain the Scsh package. What stage of the new maintainer process are you in? Do you have working packages of Scsh done yet? Perhaps I can look them over and upload them for you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Restarting Build on a Package
Brent Fulgham [EMAIL PROTECTED] writes: I'm trying to bootstrap a program that takes quite a while to build, and if it dies during configuration and I have to rebuild it again I'm going to pull my hair out. While you're trying to perfect the deb script, why don't you use 'debian/rules build' directly, and then when you're confident you've got it right go through the whole rigamarole... Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: determining if we're using db.h from libc6 or libdb2?
Ben Collins, in an immanent manifestation of deity, wrote: On Tue, Sep 12, 2000 at 12:46:02AM -0700, Darren/Torin/Who Ever... wrote: Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Keep it at db.h, since in a few days, it wont matter. Db2 is getting removed from glibc, and your only choice will be db.h or db2/db.h from libdb2 (both the same file, just db.h is the default place). Well, I was hoping to have a general solution because that version of glibc2 is still going to be used for a while. I have systems that will stay at potato until about a month after woody has been released. Others must be in the same position. I know that I could go trolling through the headers but I'd prefer a documented solution to a cobbled solution. BTW, the reason that I need this is to get openldap 2 to run on i386. It took me about two hours to figure out that it was including the headers for db2.4 (in glibc2) while using the library from db2.7. The error looks like: slapadd: ldbm_db_errcall(): == DB_DUPSORT requires DB_DUP slapadd: Could not open/create id2entry.dbb Darren -- [EMAIL PROTECTED]http://www.daft.com/~torin/ [EMAIL PROTECTED][EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dualing banjos
Thanks for the e-mail. But what about the effect of have a super conducting di-lithium crystal sub-lattice? Wouldn't this resonate and cause multi variable vibrations down to the molecular level? I mean, the whole thing here is to show the ultimate differences between the Linux kernel and the kernels found when using multiple banjos. This research was supported by Dr. Rimulak in his infamous Kernal VS Banjo - A Duality?. This is a must read! Howard Subject: Re: dualing banjos --- Jaldhar H. Vyas [EMAIL PROTECTED] wrote: On Tue, 12 Sep 2000, Keith G. Murphy wrote: So far, the Linux kernel only supports single, not dual banjos. There is, however, a patch available that will make the 2.2 kernel support up to 15 banjos. The 2.4 kernel, of course, will support any number of banjos. (Well, 65535, but who needs more than that?) :-) Although both Solaris and windows 2000 currently outpace Linux in sheer numbers of banjos supported a key point to consider is Linux is more portable. You can build a beowulf cluster that supports foghorns, bagpipes and cats in heat along with your banjos. A team at IBM is currently trying to port the Linux Kernel to Britney Spears but it is highly experimental and the system may never be stable under such hostile conditions. -- Jaldhar H. Vyas [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
