Many ports open by default
I suspect it's already been discussed before, so I'll ask instead of flaming. (See! I can learn!) Why does a server automatically get run just because it's installed? For instance, portmap is installed by default whether you're using NFS or not, and bnetd runs even if I just installed the package for bnchat. Shouldn't the default be to not run daemons unless they are explicitly enabled, like an "exit" at the beginning of all daemon-starting init scripts that must be commented out? -- Dwayne C. Litzenberger - [EMAIL PROTECTED] pgpuOuSLMGM6c.pgp Description: PGP signature
libdb3.so and libdb-3.so
Hi, I wonder why libdb3 package includes /usr/lib/libdb3.so.3.0.2 , /usr/lib/libdb-3.so , however libdb3-dev package includes /usr/lib/libdb3.so . Which (libdb3/libdb-3) is the more appropriate name to link libdb3, when I use libdb3 with my package ? IMHO, 2 link name of (libdb3, libdb-3) leads some future confusion. We should unite their name into `libdb3', and remove `libdb-3.so'...? Regards, -- GOTO Masanori
°í±Þ¾×¼¼¼¸®¸¦ ±¹³»ÃÖÀú ´ýÇÎ °¡°Ý¿¡ ÆǸÅÇÕ´Ï´Ù
¹Ù»Ú½Å ½Ã°£¿¡ ¸ÞÀÏÀ» µå·Á Á˼ÛÇÕ´Ï´Ù. ¡¡ °í±Þ¾×¼¼¼¸®¸¦ ±¹³»ÃÖÀú ´ýÇÎ °¡°Ý¿¡ ÆǸÅÇÕ´Ï´Ù. ¸Ó¸®ÇÉ,¸ñ°ÉÀÌ,ÆÈÂîµî 100¿©°¡Áö ÀÌ»óÀÇ ¼±¸íÇÑ »çÁø°ú °¡°ÝÇ¥ http://www.vivi.co.kr/ ¡¡ »çÁøÀ» Ŭ¸¯Çϼ¼¿ä ¡¡ 8055-4000¿ø(¼Û·áÆ÷ÇÔ) 8054-3000¿ø(¼Û·áÆ÷ÇÔ) 4010-3700¿ø(¼Û·áÆ÷ÇÔ) 8039-3000¿ø(¼Û·áÆ÷ÇÔ) 8024-6000¿ø(¼Û·áÆ÷ÇÔ) 3009-3400¿ø(¼Û·áÆ÷ÇÔ) ¿À½ºÆ®¸®¾Æ ¼öÀÔ ¶óÀνºÅæÀ» »ç¿ëÇÕ´Ï´Ù. ÀÌ-¸ÞÀÏ º»»ç,°øÀå : °æ±âµµ Æ÷õ±º °¡»ê¸é °¨¾Ï¸® 515-1 ÀüÈ: 031-535-6995 Æѽº: 031-535-6994 »ç¾÷ÀÚµî·Ï¹øÈ£: 112-03-23802
Re: RFC: English translation list
On Sun, 29 Apr 2001, Joey Hess wrote: > What I am proposing is a new list, similar in scope to the other l10n > lists, where developers can bring text they need a clean English version > of (be the original in some other language, or their best try in > English), and get a good English translation back. I think that would be a very good idea. I've found myself needing grammar help from time to time (and I am also known to do terrible things to prepositions :P), and I'm sure many other non-native English speakers find themselves in such trouble often. Also, I've seen very criptic/bogus text in package descriptions, README files and manpages... and I'm not even that good at English, so I'm pretty sure I didn't notice half of them. A central place to exert some help in that area would benefit Debian, I think. > I'm offline so I'm not sure what a proper list name would be, probably > either debian-english or debian-i18n-english, or debian-l10n-english or > whatever parallels the other lists for other language translations. I'd prefer -18n-english or -10n-english, to avoid a dangerous parallel to the various debian- lists used for user support. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: kernel-{image,headers} package bloat
Herbert Xu wrote: > With properly constructed dependencies, finding matching packages shouldn't > be an issue. Please also consider that if the user were to compile his own > kernel, he would face the problem of having to recompile the modules > packages if they're needed. Please explain how properly constructed dependancies can help a user find the right alsa and pcmcia modules packages out of a list of what will surely be near to a hundred modules packages. -- see shy jo
Re: analysis of package dependencies
Matt Zimmerman wrote: > I believe it is debfoster that works the way you described, while deborphan > merely finds installed library packages that do not satisfy any dependencies. You're right of course. -- see shy jo
FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org
Anyone have a clue? - Forwarded message from Jimmy Richards <[EMAIL PROTECTED]> - From: Jimmy Richards <[EMAIL PROTECTED]> Date: Thu, 26 Apr 2001 15:24:53 -0600 To: debian-user@lists.debian.org Subject: Popularity-contest submission doesn't go through to [EMAIL PROTECTED] Hi All, I was wondering if I need to file a bug report on the popularity-contest pacakge or not. I really don't know very much about e-mail address issues, but I think I have my MTA configured ok. Hopefully someone can help point me in the right direction by having a look at the error message below... *** A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: [EMAIL PROTECTED]: unknown local-part "apenwarr-survey" in domain "klecker.debian.org" -- This is a copy of the message, including all the headers. -- Return-path: Received: from myhostname.my.isp.com [10.11.12.13] (root) by klecker.debian.org with esmtp (Exim 3.12 1 (Debian)) id 14sm7Y-0002Vr-00; Thu, 26 Apr 2001 06:47:48 -0700 Received: from myhostname.my.isp.com ([EMAIL PROTECTED] [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with +ESMTP id f3QDlYZ2018784 for <[EMAIL PROTECTED]>; Thu, 26 Apr 2001 07:47:34 +-0600 Received: (from [EMAIL PROTECTED]) by myhostname.my.isp.com (8.12.0.Beta7/8.12.0.Beta7/Debian +8.12.0.Beta7-1) id f3QDkJuS015600 for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:46:19 -0600 Date: Thu, 26 Apr 2001 07:46:19 -0600 From: root <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> Subject: popularity-contest submission To: undisclosed-recipients:; POPULARITY-CONTEST-0 TIME:988292785 ID:44c9075bfc7f6356ca7ff48477d0b64f 988292831 987655771 grep /bin/egrep *** I hope someone can help with this. I have tried to use poularity-conetest since I have installed Debian about 4 months or so ago, but my submission has never gotten through. But this time I installed sendmail and even though I don't understand a lot about it's configuration yet, I think I have it configured correctly. I am just an end user on the @home cable service, and seem to have sendmail working correctly for such use, afiak. Thank s lot for looking at this error, Jimmy Richards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- see shy jo
RFC: English translation list
English is Debian's de-facto language -- all of our developers have at least some proficiency it it, and all are required to create English documents, such as package descriptions, man pages, debconf templates, README.Debian files, and so on. But we're not all native English speakers, and sometimes it shows. While I am not proficient enough in any other language to check for sure, I suspect that the overall of the translations that exist in other languages are often of higher and more consistent quality than much of the text they translate[1]. After all, many of these English texts are themselves translations from the original in the native language of the author. What I am proposing is a new list, similar in scope to the other l10n lists, where developers can bring text they need a clean English version of (be the original in some other language, or their best try in English), and get a good English translation back. I'm offline so I'm not sure what a proper list name would be, probably either debian-english or debian-i18n-english, or debian-l10n-english or whatever parallels the other lists for other language translations. -- see shy jo [1] Of course, it often goes the other way too. Easy to make a bad translation..
Re: Are build-dependancies mandatory?
Marcin Owsiany <[EMAIL PROTECTED]> writes: > On Fri, Apr 27, 2001 at 06:00:07AM -0500, BugScan reporter wrote: > > > > Package: cvs (debian/main) > > Maintainer: Eric Gillespie, Jr. <[EMAIL PROTECTED]> > > 95263 missing build dependency > > The policy says: > > A source package may declare a dependency or a conflict > on a binary package. > > Then why is missing build dependency considered an RC bug? > I know build-depends is a good thing, but shouldn't the policy > be changed then? Hmm, it also says (in section 2.4.2): (emphasis mine) Source packages _should_ specify which binary packages they require to be installed or not to be installed in order to build correctly. ... _If_ build-time dependencies are specified, it _must_ be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). So officially, completely missing build-depends is a normal bug; incomplete build-depends is RC. Is this an inconsistency with the above quote from section 7.6, which uses the word "may"? -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: Conflict: libgb
> As the sgb maintainer, it would probably have been wise to email me as > well ([EMAIL PROTECTED] would do). I just happened to see the > email Hi.. sorry, I completely didn't think of it (as with so many other things this last week, which has been a complete disaster but anyway..). > Anyway, is the Gnome Basic library "standard" (in some vague sense of > the word)? Do people expect it to be installed with that name? It's still very preliminary at the moment. My understanding is that it's not "standard" but wishes eventually to be an alternate [VB-compatible] standard. Scripting already exists for Gnome but I understand the plan is to allow VB scripting for apps similar to that which exists for the Other office suite. I'll mail the gb list and enquire further. Of course there are no packages in Debian which use Gnome Basic either, since this is its first packaging. Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee What we have got is a dead carcass, swinging in the breeze, but nobody will cut it down to replace him. - Paul Keating, on John Howard
Re: (OT) Storage (8*IDE HDs) any experiences?
> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes: Russell> That sounds like a really bad idea to me. Russell> In a regular setup the IDE controller and the drive get Russell> power from the same source. So if the signals on the Russell> cable have more current going one way than the other then Russell> the difference will be made up on the 0V line on the PSU. Russell> If you have separate PSU's then the difference will go Russell> through other lines of the data cable. This is something Russell> that is likely to be fatal to drives and motherboards. Russell> But if you try it please let me know how it works. ;) Another thing to watch out for is timing differences. Eg. if you turn on one power supply before the other. Or if one power supply generates good power before the other. I would assume (hope!) the original poster plans to run both power supplies from the same central switch, in order to minimise problems here. Designers of the interface need to take into consideration if it is going to be used for external devices powered by external power or internal devices. A number of factors need to be taken into account ranging from internal delays in the power supply, logic levels, cable length vs cable quality vs speed of communication vs reliability of communication, ground loops, etc. So, while the above might be OK for an SCSI interface for external devices, I strongly suspect when designing IDE that they made the assumption it would only be used for the one power supply. Hence I wouldn't like to try it, unless I didn't care about reliability and/or potentially wrecking the hard disks. Even if it works today, will it work tomorrow? -- Brian May <[EMAIL PROTECTED]>
Re: Conflict: libgb
On Sat, Apr 28, 2001 at 02:24:15AM -0500, Ben Burton wrote: > > Hi. I am currently packaging Gnome Basic (ITP: #94328) which wishes to > install /usr/lib/libgb.* and /usr/lib/libgbrun.*. > > After searching through the debian package directory it appears that package > sgb also installs /usr/lib/libgb.*. Gnome Basic is unrelated to package sgb > and the libraries have completely different functionalities. Hi! As the sgb maintainer, it would probably have been wise to email me as well ([EMAIL PROTECTED] would do). I just happened to see the email Anyway, is the Gnome Basic library "standard" (in some vague sense of the word)? Do people expect it to be installed with that name? I have no idea how many people are already linking their programs to libgb (the Stanford GraphBase version), so I am a little nervous about changing the name. There are no packages in Debian which use it, however, so it might not be so terrible to change it. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: (OT) Storage (8*IDE HDs) any experiences?
On Sun, Apr 29, 2001 at 10:14:35AM +0200, Russell Coker wrote: > In a regular setup the IDE controller and the drive get power from the same > source. So if the signals on the cable have more current going one way than > the other then the difference will be made up on the 0V line on the PSU. If > you have separate PSU's then the difference will go through other lines of > the data cable. I don't see why. Nor is this any different to any external drives. You have a hefty ground connection between the power supplies anyway (the mains, plus the metal case acting as ground). Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Gnome bug 94684
On Sun, Apr 29, 2001 at 03:22:22PM +0200, Raphael Hertzog wrote: > Because it regularly happens that the bug is ignored upstream and then the > BTS gets bloated with upstream bugs, making it more difficult to manage > the bugs that are really Debian related. But upstream or not, those are still bugs in the Debian package. I think they should stay in the Debian BTS if reported that way. Use tags to make the bug list more manageable. regards Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: configuring ISA PnP devices with kernel 2.4 & isapnptools
On Sun, Apr 29, 2001 at 03:28:53PM -0400, Steve M. Robbins wrote: > I would greatly value other's experience with PnP cards. I have just > one, myself, and only just installed a 2.4 kernel on Friday to see > what the new interface is like. It took me most of the evening to > figure out how to re-create the old configuration. Me too; I just upgraded a box last weekend (to 2.4) and had this break. I used isapnp as a module, and didn't notice that the userspace isapnp still worked, as the kernel module redid the configuration. I read the documentation in the kernel sources about the /proc/isapnp and couldn't make it do anything useful at all. I needed to do some manual configuration because the default configuration made a PnP ISA Ethernet card conflict with a non-PnP serial port. I never could work out how to do stuff with /proc/isapnp; it always told me I had the wrong device ID. So I think a nicer interface to /proc/isapnp would be nice -- not just for backwards compatibility reasons! In the end I found the reserve irq option on the isapnp module, so I didn't need to actually force the PnP card to particular resources. It IS nice the way the other drivers work with the PnP driver to get the card resources in 2.4. regards Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Gnome bug 94684
On Sun, Apr 29, 2001 at 03:44:45PM -0500, Steve Langasek wrote: [...] > Whereas all bugs may be created equal, all bug reports are not. If an > upstream developer receives a bug report from a Debian developer with whom she > has a good working relationship, she's reasonably assured that the bug report > has been confirmed as a real bug, has been researched, and includes, if not a > patch, at least an analysis that will help the upstream fix the problem. I'm I agree, of course. But it has been discussed, that an debian developer, finding an upstream bug should report it directly upstream without bothering the developer responsible for the package. My point was (or should have been) that a debian developer should IMHO report the bug to the debian-package too, exactly like a mere user would. It helps a mere user when he finds a bug in the bugtracking-system and the bug is both a debian-bug as a upstream-bug. (And bugs existing upstream should not be closed in debian). -- CU, Patrick. "Never run on auto-pilot" - The Pragmatic Programmer pgpfbm7Ck2ZJA.pgp Description: PGP signature
Re: Gnome bug 94684
Hi Patrick, On Sun, 29 Apr 2001, Patrick von der Hagen wrote: > On Thu, Apr 26, 2001 at 02:09:51PM +0800, zhaoway wrote: > [...] > > upstream issue? I agree that if you're a noname random clueless mere > > user then the package maintainer shouldn't just close this usibility > > bug blindly. > Well, actually I am a noname random clueless mere user. > But I don't seen, why a bug-report made by a debian-developer should be > treated differently? Whereas all bugs may be created equal, all bug reports are not. If an upstream developer receives a bug report from a Debian developer with whom she has a good working relationship, she's reasonably assured that the bug report has been confirmed as a real bug, has been researched, and includes, if not a patch, at least an analysis that will help the upstream fix the problem. I'm not saying that all Debian developers always produce such thorough reports, nor that mortal users cannot produce bug reports of this quality; but most users lack experience in submitting good bug reports, and Debian maintainers, at least, know what a bad bug report looks like. :) If the upstream maintainer knows by looking at the mail header that the bug report from [EMAIL PROTECTED] is of quality, and suspects that the other bug says "Your software doesn't compile on AIX: please fix it", which bug report do you think she will look at first? :) Steve Langasek postmodern programmer
postgresql and libssl - Bug#95146
I have to reiterate a query about what to do with postgresql in view of its now being linked with libssl. Since this question is currently being referred to legal advice, do you want me to move postgresql into non-us, which will force any packages depending on it into non-us too, or should I leave it alone pending resolution of the legal question? (I do not propose to do anything to remove the ssl code from PostgreSQL.) -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "And he said to them all, If any man will come after me, let him deny himself, and take up his cross daily, and follow me." Luke 9:23
Re: Are build-dependancies mandatory?
[EMAIL PROTECTED] (Rahul Jain) writes: > maybe there should be meta-packages for packages that have embedded version > numbers like that. In the general case, yes. In this case, there is no need for one, since the package in question is build-essential, and so need not be listed in a build dependency. I've run into a number of cases where the build dependency for some other library that is not build-essential is tied to a specific version. It is hard to tell quickly if those are "mistakes", or if the package really depends on a particular version. So, for now, such packages get marked as 'failed' and left to rot until/unless they are needed to fill some dependency... > Or maybe the build-dep on libstdc++2.10-dev indicates that > the package relies on some g++ brokenness ;) Heh. That would be frightening. So far, the fix for all the packages I have tried is to just ignore that build dependency and build against a current version of libstdc++. Bdale
Re: kernel-{image,headers} package bloat
On Sun, Apr 29, 2001 at 10:34:03AM +0800, zhaoway wrote: > > i vote for alot of binary kernels. but i'd rather see someone comes > out will better ideas. if we are voting here, i'd vote for the very minimul number of stock kernels. if someone wants something more tuned, then roll your own, or the wonderful idea of some automated hardware detector that tunes a very nice kernel, along with the required modules (alsa, pcmcia, lids, crypto) -john
Re: configuring ISA PnP devices with kernel 2.4 & isapnptools
On Sun, Apr 29, 2001 at 10:27:59AM +1000, Herbert Xu wrote: > On Sat, Apr 28, 2001 at 07:52:38PM -0400, Steve M. Robbins wrote: > > > > What is already handled by modutils? Loading the isa-pnp module? > > Configuring the PnP cards? > > Sorry, I wasn't talking about the same thing as you. But, what you want to > do can and should be done through modutils. By inserting a post-install > statement into a file in /etc/modutils, you can execute arbitrary commands > everytime the isapnp module is loaded. Okay, so one can arrange to have cards configured when the isa-pnp module is loaded, by using a "post-install" statement. I hadn't thought of that. Is that what folks normally do for PnP cards? There isn't any kind of formal standard for hardware configuration that I can find --- I looked in Debian policy, Filesystem Hierarchy Standard, and Linux Standards Base. What is the best current practice? The immediate problem that I am facing is: what should the init script for isapnptools do? The status quo is: * if /proc/isapnp exists, the script does nothing, * otherwise isapnp runs (if its config file exists) The check for /proc/isapnp is there to detect kernel support for PnP configuration (added in kernel 2.3.something). I can think of two problems with this approach. 1. This assumes that the user has actually re-worked the system configuration to use the /proc/isapnp interface. If not, then upon the first boot into kernel 2.4, the system may be in a bad state (i.e. some cards not configured). 2. This does not detect isa-pnp compiled as a kernel module, since the /proc file does not exist until the module is loaded, and that happens *after* isapnp init script runs. I think that issue #2 is not a real problem. I believe that running the isapnptools' isapnp *and* also using the kernel's /proc/isapnp interface (when the isa-pnp module gets loaded) is harmless. The worst that will happen is that the card may be configured twice.[1] If true, then I am inclined to remove the check for /proc/isapnp in the init script. Hence isapnptools would continue to configure the card after the user upgrades to kernel 2.4, until she re-works the configuration to use the /proc/isapnp interface. This would alleviate issue #1. I would greatly value other's experience with PnP cards. I have just one, myself, and only just installed a 2.4 kernel on Friday to see what the new interface is like. It took me most of the evening to figure out how to re-create the old configuration. An upgrade to 2.4 shouldn't break a working system this badly! I'd really like a way to ease this transition for others. Is there, for example, a script to translate /etc/isapnp.conf into the new form? Thanks, -Steve 1. Of course this is bad if the two configs differ, but that would be caused by explicit user action. I am more concerned about someone installing a 2.4 kernel and getting surprised.
searching for Bill Geddes [Mailer-Daemon@master.debian.org: Mail delivery failed: returning message to sender]
Hi, Looks like another one of those Maintainer fields broken by hp/agilent split or whatever it was... - Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> - Delivery-date: Sun, 29 Apr 2001 20:05:26 +0200 X-Failed-Recipients: [EMAIL PROTECTED] From: Mail Delivery System <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Mail delivery failed: returning message to sender Date: Sun, 29 Apr 2001 13:03:47 -0500 This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: [EMAIL PROTECTED]: unrouteable mail domain "col.hp.com" -- This is a copy of the message, including all the headers. -- Return-path: <[EMAIL PROTECTED]> Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian)) id 14tvXr-00025m-00; Sun, 29 Apr 2001 13:03:43 -0500 Subject: Bug#32517: vrms doesn't report any non-free packages Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] Orignal-Sender: [EMAIL PROTECTED] Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Bill Geddes <[EMAIL PROTECTED]> Resent-Date: Sun, 29 Apr 2001 18:03:42 GMT Resent-Message-ID: <[EMAIL PROTECTED]> Resent-Sender: [EMAIL PROTECTED] X-Debian-PR-Message: report 32517 X-Debian-PR-Package: vrms X-Debian-PR-Keywords: X-Loop: [EMAIL PROTECTED] Received: via spool by [EMAIL PROTECTED] id=B32517.9885642932555 (code B ref 32517); Sun, 29 Apr 2001 18:03:42 GMT To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Sun, 29 Apr 2001 18:10:31 +0100 Sender: [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] I think this bug is actually a result of the dpkg bugs 54529, 58106, 59440, 60973, 63101 (merged), and it should probably be merged with those or closed. [Basically, dpkg isn't correctly updating the Section header, so obviously vrms hasn't got a chance of doing the Right Thing.] It's also the same as the vrms merged-bug cluster 53155, 57693, 57766, 78633, 84280. I think you should merge 32517 with those, and then reassign the whole lot to dpkg and merge them together with the dpkg bugs. Peter Maydell - End forwarded message - -- Digital Electronic Being Intended for Assassination and Nullification
Re: debbugs can now send bug mails to someone different than the maintainer
On Wed, Apr 25, 2001 at 01:31:19PM +0200, Raphael Hertzog wrote: > It would be great to have an automated system where one could subscribe to > bugs for a particular package without having all the hassles of filling a > bug and waiting an answer. And having something automated would allow me > to unsubscribe for the vacation and subscribe again after and so on. > > I'd like to help for some packages I know well, but don't want to > subscribe to -bugs-dist to actually get bugs. I agree that a system like this would be nice, but until that day, you can subscribe to debian-bugs-dist and use procmail to filter everything but packages you are interested in. The configuration should be trivial. -- - mdz
Re: Intent to package intel-rng-tools.
On Sun, Apr 29, 2001 at 10:32:59AM +0530, Viral wrote: > > As long as it isn't too bothersome for you, would you mind explaining why > > the kernel doesn't activate it by default? Or why it isn't a `make config' > > option? And why is a daemon needed for it? > > No, its not bothersome to explain. This extract comes from 2.4.4's > Documentation/i810_rng.txt. I also read about the decision of > moving the rng to userland, but I can't find that now. Do you know if there is any work related to merging the various rng daemons? From various announcements about sound-entropyd and egd (http://www.lothar.com/tech/crypto/), I get the feeling that a lot of work is being duplicated w.r.t. proper hashing and entropy verification. dave...
Re: Keysigning request in New York City
I will be back in the NYC area on May 16th, if no one else has signed your key by then, I will do it. On Sun, Apr 29, 2001 at 12:33:39PM -0400, Jimmy Kaplowitz wrote: > Hi, I have recently started maintaining a Debian package for Althea, an IMAP > email client for GTK+. That package, thanks to the sponsorship of current > Debian developer Bas Zoetekouw <[EMAIL PROTECTED]>, is now in unstable. I > would > like to become a Debian developer so that I can upload that package by myself, > so is there anyone in the New York City area who can sign my GPG key? > > Please CC me on any replies, for until I have time to set up a procmail filter > that works with Maildir and separates out messages from this list, I am not > subscribed to debian-devel. > > Thanks. > > - Jimmy Kaplowitz > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- ;; ;; Matthew Danish email: [EMAIL PROTECTED] ;; ;; GPG public key available from:'finger [EMAIL PROTECTED]' ;; ;; pgp6mMRhDL62G.pgp Description: PGP signature
Keysigning request in New York City
Hi, I have recently started maintaining a Debian package for Althea, an IMAP email client for GTK+. That package, thanks to the sponsorship of current Debian developer Bas Zoetekouw <[EMAIL PROTECTED]>, is now in unstable. I would like to become a Debian developer so that I can upload that package by myself, so is there anyone in the New York City area who can sign my GPG key? Please CC me on any replies, for until I have time to set up a procmail filter that works with Maildir and separates out messages from this list, I am not subscribed to debian-devel. Thanks. - Jimmy Kaplowitz [EMAIL PROTECTED]
Re: Gnome bug 94684
On Thu, Apr 26, 2001 at 02:09:51PM +0800, zhaoway wrote: [...] > upstream issue? I agree that if you're a noname random clueless mere > user then the package maintainer shouldn't just close this usibility > bug blindly. Well, actually I am a noname random clueless mere user. But I don't seen, why a bug-report made by a debian-developer should be treated differently? Imagine Developer A responsible for a certain package and Developer B finding an upstream bug. If B reports directly to upstream, the bug won't show up in the buglist of the debian-package. Two days later I find the same bug and will open it in the Bugtracking-System. Developer A will report it upstream now, so upstream will get two bug-reports. Personally I see no advantage of upstream getting two reports for one bug instead of one. For me it would have been better, if Developer B had reported it to the debian bugtracking system instead of reporting it to upstream, since the upstream-bug is clearly a debian-bug too. And now Developer A decides "It's not my fault" and closes the bug. A week later, someone else hits the same bug, looks at the bug-tracking system, checks that he has the most recent package and finds out that there is no open bug fitting his problem. So he opens a new one, because the bug DOES exist. Developer A closes it again. A third user might open it again. (to be continued) So IMHO a bug is a bug, no matter who reports it. And if it is closed without being fixed that's just plain wrong, it just might be reported again and again. And by being closed and opend again and again, people reporting the bug will get frustraded. I know people who say "I reported bugs, spending time invesigating which package to blame (which is not always clear) and perhaps writing and sending a patch. The bug-reports and fixes were just ignored, I never even got an answer why they didn't use my patches or close the bug some other way. So it was a waste of time and I don't waste my time any more." Well, they were not talking about debian-bugs, but that is what is at stake: a developer ignoring bugs might one day find out that people don't care to give him bug-reports or spend less time giving him good bug-reports. But I am just a mere user, so perhaps you should just ignore my posting? -- CU, Patrick. "Never run on auto-pilot" - The Pragmatic Programmer pgpbV5WWOcvZd.pgp Description: PGP signature
[Mailer-Daemon@master.debian.org: Mail delivery failed: returning message to sender]
Hi, The [EMAIL PROTECTED] address causes occasional bounces every now and then, and it seems to be due to connectivity problems (connection timing out, every time). Incidentally, this particular message was _from_ the same address, but that isn't so every time, bug reports get lost. Please don't expect us at [EMAIL PROTECTED] to forward these mails all the time. Instead move your mail to a more reliable mail host. (This mail is CC:ed to -devel since my two last mails directly to Takuo haven't produced _any_ response.) - Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> - Delivery-date: Sun, 29 Apr 2001 02:08:29 +0200 X-Failed-Recipients: [EMAIL PROTECTED] From: Mail Delivery System <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Mail delivery failed: returning message to sender Date: Sat, 28 Apr 2001 19:06:54 -0500 This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: [EMAIL PROTECTED]: Connection timed out: retry timeout exceeded -- This is a copy of the message, including all the headers. -- Return-path: <[EMAIL PROTECTED]> Received: from gecko by master.debian.org with local (Exim 3.12 1 (Debian)) id 14teim-0002wL-00; Sat, 28 Apr 2001 19:05:52 -0500 Subject: Bug#94926: oaf: Fails to unpack Reply-To: [EMAIL PROTECTED] (Takuo KITAME), [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] (Takuo KITAME) Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Takuo KITAME <[EMAIL PROTECTED]> Resent-Date: Sun, 29 Apr 2001 00:05:51 GMT Resent-Message-ID: <[EMAIL PROTECTED]> Resent-Sender: [EMAIL PROTECTED] X-Debian-PR-Message: report 94926 X-Debian-PR-Package: oaf X-Debian-PR-Keywords: unreproducible X-Loop: [EMAIL PROTECTED] Received: via spool by [EMAIL PROTECTED] id=B94926.9885021068717 (code B ref 94926); Sun, 29 Apr 2001 00:05:51 GMT Date: Sun, 29 Apr 2001 08:55:00 +0900 Message-ID: <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] (Takuo KITAME) To: Thomas Conway <[EMAIL PROTECTED]>, [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) Organization: Northeye.ORG X-URL: http://northeye.org/ MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] > On Mon, 23 Apr 2001 10:06:07 +1000 > "TC" == Thomas Conway <[EMAIL PROTECTED]> wrote... TC> Package: oaf TC> Version: N/A TC> Severity: critical TC> Hi oaf_0.6.5_5_i386.deb seems to be broken. Please show me error message. If not, I'll close the Bug. -- Takuo KITAME. - End forwarded message - -- Digital Electronic Being Intended for Assassination and Nullification
Re: ITP: darj - arj archive unpacking tool
On Thu, Apr 26, 2001 at 01:10:48PM +0300, Richard Braakman wrote: > (I filed this as bug#95252, but used X-Debian-CC instead of X-Debbugs-CC. > Strange... I remember it being X-Debian-CC once.) It was, a couple of years ago. :) It was renamed in debbugs because other people started using it and it wouldn't make sense to make X-$foo-CC for each new installation, I think. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Gnome bug 94684
On Thu, Apr 26, 2001 at 02:09:51PM +0800, zhaoway wrote: > You guys are getting more and more bureaucratic. That's sad. > > That said, why don't you report the bug directly to the upstream, instead > of insisting on this (bureaucratic) procedure of reporting bugs to > [upstream] There is (should be) something different with maintainers forwarding bugs to upstream authors. When a Debian maintainer reports a bug to the upstream, the upstream knows that the bug report has been examined and evaluated, and most likely reproduced. It's more likely that the upstream people will pay more attention to that bug, since they know someone has bothered to analyze the problem already to make it easier for them. One other thing -- when the Debian maintainer has been working for some time with the upstream maintainer(s), s/he may know things like emails which are more often read or people among the upstream that might be more acceptive to an idea than others. Sure, that's cheating, but if it's for a worthy cause... :) > while both of you debian developers are pretty sure it's an upstream > issue? There's a bit of a psychological difference from the upstream standpoint when an individual user (whether he is a Debian developer or not) approaches them and asks them to do something that they might not like (keeping compatibility), and when the person who industriously maintains packages of their software approaches them and asks them the same. The end result won't always be different, of course. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Gnome bug 94684
Le Sat, Apr 28, 2001 at 09:20:59PM -0700, Alexander Hvostov écrivait: > > You guys are getting more and more bureaucratic. That's sad. > > Bureaucracy is integral to an organization such as Debian. you're going to > have to learn to live with it. Certainly not. We have rules to follow, but that's not bureaucracy. And one of the first rule is the maintainer is the one who decides for his package. It's a pity we have to keep all those upstream bugs in the Debian BTS when there's an upstream BTS. Each maintainer should be able to decide if he wants to keep the upstream forwarded bug. I'd like to be able to close those upstream bugs by sending a mail to [EMAIL PROTECTED] giving the reference of the bugs submitted to the upstream BTS. Because it regularly happens that the bug is ignored upstream and then the BTS gets bloated with upstream bugs, making it more difficult to manage the bugs that are really Debian related. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguez sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: debbugs can now send bug mails to someone different than the maintainer
Le Tue, Apr 24, 2001 at 04:25:16AM -0500, [EMAIL PROTECTED] écrivait: > This is useful, when the real maintainer is doing the upload, and dinstall > compares the uploader to the real maintainer, but an entire list of people > should actually get the bug reports. It would be great to have an automated system where one could subscribe to bugs for a particular package without having all the hassles of filling a bug and waiting an answer. And having something automated would allow me to unsubscribe for the vacation and subscribe again after and so on. I'd like to help for some packages I know well, but don't want to subscribe to -bugs-dist to actually get bugs. Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguez sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: (OT) Storage (8*IDE HDs) any experiences?
On Sat, Apr 28, 2001 at 11:50:26PM +0200, Andreas Bombe wrote: > The IBM SCSI disk I have here has a jumper to delay spin up depending on > SCSI ID so that an array of those would spin up sequentially if they all > had those jumper set (and different IDs, which they need anyway). Sorry I missed the start of the thread. I would suggest you to buy a simple IDE-to-SCSI Raid Appliance. You don't have the trouble with sizing the Power supply. You get a neat chasis with plug-able disks and you also get the speed of SCSI and the ability to plug it into every server you desire. The prices are quite reasonable. I asume you need it at work, cause more than 4x36GB isnt realy needed for private persons, even if they have a large mp3 archive :) BTW: I would suggest to use only Master-Disks on those IDE Channels, since those are much faster. One IDE-to-SCSI Solutoin I saw had 8 IDE Channels for 8 Disks, so no slave needs to be used. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: (OT) Storage (8*IDE HDs) any experiences?
On Sunday 29 April 2001 06:48, Brandon High wrote: > On Sat, Apr 28, 2001 at 11:50:26PM +0200, Andreas Bombe wrote: > > The IBM SCSI disk I have here has a jumper to delay spin up depending on > > SCSI ID so that an array of those would spin up sequentially if they all > > had those jumper set (and different IDs, which they need anyway). Maybe > > there are IDE drives built with RAIDs in mind offering some similar > > option? > > I doubt it, but with a sufficiently large case (or small power supply) it > may be possible to stick a 2nd (or 3rd) power supply in. Drives could be > plugged into the second PS while the MB is powered off of the primary PS. That sounds like a really bad idea to me. In a regular setup the IDE controller and the drive get power from the same source. So if the signals on the cable have more current going one way than the other then the difference will be made up on the 0V line on the PSU. If you have separate PSU's then the difference will go through other lines of the data cable. This is something that is likely to be fatal to drives and motherboards. But if you try it please let me know how it works. ;) -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: [RP] Re: Lightweight Web browsers
On Sun, Apr 29, 2001 at 03:39:48PM +0800, zhaoway wrote: > Nay, I haven't ever done even once -geometry thingy. Always > maximise. Why not? Those apps can't do it sucks. :) (Though I'd really > hope ratpoison could come over it, maybe a container alike applet for > things such as Gimp etc.? Ie a lightweight xnest + a lightweight > window manager(!!) would be helpful.) ohh my god, plus things as 9menu > this ohh, this. ;) i never did understand why people create applications like the gimp. i hated it the first time i encountered visual basic. let's clone deluxe paint instead and never-ever touch that over featured multi window toolkit parent! what stops you from using Xnest and twm inside rp? > P.S. ratpoison really rocks, but please pay less attention on how you > could kill the mouse. effort on this direction seldom gains IMHO. nah! i thought so myself when i started running rp, but now i have realized. the rat is evil and bad. almost as evil as emacs and bash.
Re: Gnome bug 94684Subject: Re: Gnome bug 94684
On Sun, Apr 29, 2001 at 03:39:42PM +0800, zhaoway wrote: > > Bureaucracy is integral to an organization such as Debian. > > I beg to disagree. :) Maybe we need a subcommitte to determine the validity of that statement ;) -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--||--||-|--|-|-|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
Re: Are build-dependancies mandatory?
On Sun, Apr 29, 2001 at 01:30:44AM -0600, Bdale Garbee wrote: > I'd be tempted to agree with you, except... > > I've spent quite a bit of time recently dealing with packages that include an > explicit build dependency on "libstdc++2.10-dev". This is not necessary since > it is a dependency for an item in build-essential, and is in fact called out > explicitly in the build-essential documentation. It breaks the ability to > build the package with gcc-3.0. That will matter to everyone eventually, and > matters to hppa and ia64 right now. maybe there should be meta-packages for packages that have embedded version numbers like that. Or maybe the build-dep on libstdc++2.10-dev indicates that the package relies on some g++ brokenness ;) -- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--||--||-|--|-|-|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
Re: ITP: darj - arj archive unpacking tool
On Sat, Apr 28, 2001 at 09:36:28PM -0700, Alexander Hvostov wrote: > Why not put the core into a library (libdarj.so or something)? This > sounds like something that could be used by a multitude of programs > (eg, Nautilus). This would also allow you to make one program that > wraps the library and behaves like a proper unix utility, and then > another that mimics unarj. I've been thinking about that. Unfortunately a library is harder to write. For example, darj simply exits if it runs out of memory, and this simplifies the internal interfaces a great deal. But it's not polite in a library. I will consider this after finishing the unarj clone. I'm a fan of refactoring :) I'll have a much better idea of what should go into the library after I've designed two different tools that use it. > Are you planning to make a compressor at some point? I imagine if you > can figure out the format well enough to extract from it, it wouldn't > be much harder to be able to create/modify archives as well. A compressor tends to be much harder to write than a decompressor, actually. And I don't think arj as an archive format has much going for it these days -- it's designed for msdos file attributes and file types. It can't represent symbolic links, for example. So, no, I don't intend to write a compressor. Richard Braakman
Re: Gnome bug 94684
> Bureaucracy is integral to an organization such as Debian. I beg to disagree. :) -- http://sourceforge.net/projects/dim .. Debian Chinese Input Method http://sourceforge.net/projects/cdlinux .. Debian running on Live! CDs http://njlug.sourceforge.net NanJing GNU/Linux User Group http://people.debian.org/~zw .. XEmacs Screenshots
Re: Lightweight Web browsers
> Oh I know about ratpoison :) Of course one can always do the 'xterm' > style of window managing (ie, extensive use of the -geometry option > :) Nay, I haven't ever done even once -geometry thingy. Always maximise. Why not? Those apps can't do it sucks. :) (Though I'd really hope ratpoison could come over it, maybe a container alike applet for things such as Gimp etc.? Ie a lightweight xnest + a lightweight window manager(!!) would be helpful.) ohh my god, plus things as 9menu this ohh, this. ;) P.S. ratpoison really rocks, but please pay less attention on how you could kill the mouse. effort on this direction seldom gains IMHO. -- http://sourceforge.net/projects/dim .. Debian Chinese Input Method http://sourceforge.net/projects/cdlinux .. Debian running on Live! CDs http://njlug.sourceforge.net NanJing GNU/Linux User Group http://people.debian.org/~zw .. XEmacs Screenshots
Re: Proposing task-debian
Hi, On Sun, Apr 29, 2001 at 03:38:04AM +0200, Christian Hammers wrote: > Recently I found two packages, debsig-verify and apt-listchanges only by > coincidence because I read in a mailing list about them. Generally, I like the idea of a task-debian metapackage, because I also just discovered some useful tools by mere accident. However, please do not make such a task-package depend on debsig-verify, because after the installation of this program you cannot install any debpackage with dpkg, dselect or apt anymore, because dpkg by default uses debsig-verify when it is installed, but debsig-verify refuses to recognize any package as correctly signed (at least with the default configuration)!!! Cheers, Guenter -- Linux: Who needs GATES in a world without fences?
Re: Are build-dependancies mandatory?
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > Bdale Garbee <[EMAIL PROTECTED]> writes: > > > It isn't *quite* that simple. Explicit build dependencies should only be > > for packages that are neither essential nor build-essential. > > But it's entirely harmless to mention them; this is an area where it's > better to err on the side of liberality than frugality. I'd be tempted to agree with you, except... I've spent quite a bit of time recently dealing with packages that include an explicit build dependency on "libstdc++2.10-dev". This is not necessary since it is a dependency for an item in build-essential, and is in fact called out explicitly in the build-essential documentation. It breaks the ability to build the package with gcc-3.0. That will matter to everyone eventually, and matters to hppa and ia64 right now. Admittedly, a dependency on, say, 'gzip' is less likely to cause problems in the future than the libstdc++ thing... but I'd rather see people craft Build-Depends correctly and minimally. Bdale
Re: Are build-dependancies mandatory?
On Sat, Apr 28, 2001 at 11:29:20PM -0700, Thomas Bushnell, BSG wrote: > Bdale Garbee <[EMAIL PROTECTED]> writes: > > > It isn't *quite* that simple. Explicit build dependencies should only be > > for packages that are neither essential nor build-essential. > > But it's entirely harmless to mention them; this is an area where it's > better to err on the side of liberality than frugality. Not always. libc6, for example, is libc6.1 on Alpha. I'm sure the Hurd people have a few of their own examples. Since all the essential* and build-essential packages are listed in the build-essential package, it's easy to check if you aren't sure. * The essentials list is a little old, and it includes ldso and update, which apparently aren't build-essential anymore. Bug-report time . . . -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org "I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored." - Joseph_Greg
Re: Are build-dependancies mandatory?
Bdale Garbee <[EMAIL PROTECTED]> writes: > It isn't *quite* that simple. Explicit build dependencies should only be > for packages that are neither essential nor build-essential. But it's entirely harmless to mention them; this is an area where it's better to err on the side of liberality than frugality.
Re: (OT) Storage (8*IDE HDs) any experiences?
hi ya... might be easier/cheaper to use a simple RC delay to deliver power to the IDE disks before the motherboard actually gets the "power up" - remember that the atx powersupply has a "power-ok" signal to tell the motherboard go ahead and power up... ( aka the power switch ) each ide disks takes about 1Amp at 12v to sping up the drive... and most atx powersupply is on that borderline at 8 drives.. 4-drives is no big issue you can fit 2 power supply into a 1U chassis if you used 8"x8" sized atx motherboards... one of the 1u cases...put a power supply in the front and another at the back. ( kinda funky ) c ya alvin On Sat, 28 Apr 2001, Brandon High wrote: > On Sat, Apr 28, 2001 at 11:50:26PM +0200, Andreas Bombe wrote: > > The IBM SCSI disk I have here has a jumper to delay spin up depending on > > SCSI ID so that an array of those would spin up sequentially if they all > > had those jumper set (and different IDs, which they need anyway). Maybe > > there are IDE drives built with RAIDs in mind offering some similar > > option? > > I doubt it, but with a sufficiently large case (or small power supply) it may > be possible to stick a 2nd (or 3rd) power supply in. Drives could be plugged > into the second PS while the MB is powered off of the primary PS. >
Re: Intent to package intel-rng-tools.
> As long as it isn't too bothersome for you, would you mind explaining why > the kernel doesn't activate it by default? Or why it isn't a `make config' > option? And why is a daemon needed for it? No, its not bothersome to explain. This extract comes from 2.4.4's Documentation/i810_rng.txt. I also read about the decision of moving the rng to userland, but I can't find that now. Introduction: The i810_rng device driver is software that makes use of a special hardware feature on the Intel i8xx-based chipsets, a Random Number Generator (RNG). In order to make effective use of this device driver, you should download the support software as well. Download the latest version of the "intel-rng-tools" package from the i810_rng driver's official Web site: http://sourceforge.net/projects/gkernel/ -- And if your head explodes with dark forebodings too, I'll see you on the dark side of the moon.
