Processed: your mail
Processing commands for [EMAIL PROTECTED]: tag 344148 moreinfo Bug#344148: X.org crashes on my computer with latest libc6 update There were no tags set. Tags added: moreinfo End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344358: using db for groups in nsswitch.conf creates double groups (fwd)
reassign 344358 glibc thanks I believe the submitter is complaning about libc behaviour here, not about defaults in base-files. Reassigning accordingly. -- Forwarded message -- From: Ron Peterson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 21 Dec 2005 22:03:11 -0500 Subject: Bug#344358: using db for groups in nsswitch.conf creates double groups Package: base-files Version: 3.1.2 Debian Sarge If I'm not mistaken, if you use db lookups for groups in nsswitch.conf, followed by files, this leads to double group membership. For example, when my nsswitch.conf contains: group: db files ...and after I've updated the database files in /var/lib/misc, I find that any group membership specified in /etc/group is reported twice by the 'groups' command. The effect isn't noticable unless you log in again, of course. If logging in via ssh, the ssh daemon has to be restarted. We discovered this quite by accident trying to track down an issue with Tru64 file locking in directories having no permissions for 'other' on nfs mounts from linux, but that's another story... Best. -- Ron Peterson Network Systems Manager Mount Holyoke College http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1op=vindex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Bug#344358: using db for groups in nsswitch.conf creates double groups (fwd)
Processing commands for [EMAIL PROTECTED]: reassign 344358 glibc Bug#344358: using db for groups in nsswitch.conf creates double groups Bug reassigned from package `base-files' to `glibc'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign to libc6
Processing commands for [EMAIL PROTECTED]: reassign 344146 libc6 2.3.5-8.1 Bug#344146: grep dumps core on LANG=ja_JP.EUC-JP Bug reassigned from package `grep' to `libc6'. retitle 344146 re_search(3) dumps core Bug#344146: grep dumps core on LANG=ja_JP.EUC-JP Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Wed, Dec 21, 2005 at 06:08:04PM +0100, Marco d'Itri wrote: I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. An algorithm is buggy if it does not match the specification. I see no description about the lookup order wrt. multiple protocols, so the behaviour is conformant to the documentation. Also note that resolv.conf(5) explicitely says that using search lines may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Dec 23, Gabor Gombas [EMAIL PROTECTED] wrote: I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. An algorithm is buggy if it does not match the specification. I see no Yet another very peculiar definition from you. description about the lookup order wrt. multiple protocols, so the behaviour is conformant to the documentation. While this may be true, it does not make it less than a bug. Also note that resolv.conf(5) explicitely says that using search lines may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. Which is true, but does not mean that the current behaviour is correct and should not be changed. -- ciao, Marco signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Wed, Dec 21, 2005 at 10:42:03AM -0800, Edward Buck wrote: On the first point, I (and thus my company) use search lines in combination with LAN-only DNS subdomains for internal address management. It allows us to use internal IP addresses for hosts without fiddling with /etc/hosts. All our host subdomains are managed in DNS. A LOT of scripts, i.e. for backup, rsync, load balancing, use short hostnames that get their address information from internal DNS zones, a process that depends on the search functionality in /etc/resolv.conf. My personal opinion is that this is wrong, and now you are trying to paper over an initial design flaw. Should you had a policy to always use full host names everywhere, you'd not have this problem now. In my experience relying on lookup service configuration is never good. To give you an idea of impact, I was recently greeted with an e-mail from a DNS service provider that I use saying that I was getting close to my query quota. It surprised me that I got this e-mail because I was never close to hitting the quota before. It turns out that 90% of the queries were coming from 1 server where I unwittingly added the domain to the search path! Well, resolv.conf(5) says about search lines that they will generate a lot of network traffic if the servers for the listed domains are not local. You should not add a search line for a domain not server by a local name server. In most cases this can be solved by installing a local caching-only name server. On the subject of work-arounds, I'm not having much luck finding one without recompiling glibc, which is not a good option IMO. If anyone has any ideas on this, please let me know. Did you try apt-get install bind9 and putting nameserver 127.0.0.1 in /etc/resolv.conf? You can also try lwresd libnss-lwres if you need something smaller, or djbdns if you like its author :-) This may reduce your DNS traffic even more than changing the lookup order in glibc would. Of course you have to pay with some memory and a little CPU usage. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Fri, Dec 23, 2005 at 01:31:16AM +0100, Marco d'Itri wrote: Yet another very peculiar definition from you. Well, that's the first thing thaught in programming theory here. If the algorithm matches the specification, then it is correct. If the specification does not cover something, then the algorithm is free to choose whatever behaviour it prefers. Of course, a correct algorithm is not neccessarily the best. Bubblesort is correct since the traditional sorting specification does not put constraints on the number of comparisons, but there is a reason people prefer to use qsort when there are more than a handful of elements :-) Which is true, but does not mean that the current behaviour is correct and should not be changed. Then convince upstream to change the current behaviour. Or write a patch, and convince the Debian glibc team that Debian should diverge from upstream behaviour. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Processed: .
Processing commands for [EMAIL PROTECTED]: reassign 344481 apache,php4,rrdtool,libc6 Bug#344481: php4-rrdtool: Use of RRD extensions (graph only?) causes Apache to segfault Bug reassigned from package `php4-rrdtool' to `apache,php4,rrdtool,libc6'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344481: Mysterious crash in php4-rrdtool
On Thu, Dec 22, 2005 at 04:45:25PM -0800, Steve Langasek wrote:
On Fri, Dec 23, 2005 at 01:09:31AM +0100, Artur R. Czechowski wrote:
The rrd_graph_options() gets a string with parameters. The begin if this
string is (at least in my case, but this is common value in rrdtools):
--start -2d
The rrd_graph_options calls getopt_long to split parameters into tokens.
You can see the code in rrdtool's sources, file rrd_graph.c, line 2965.
getopt_long reckognises the --start parameter correctly and, according to
struct option returns opt as s. But, for some strange reasons, it sets
optarg for NULL.
Erm, don't you need to write --start=-2d if you want an optarg that begins
with a hyphen?
No. The s: in optstring and 1 as a second value in {start,1,0,'s'} always
makes next token a parameter.
Try to compile and run following example:
#include stdio.h
#include getopt.h
struct option opt[] = {
{letter-a,1,0,'a'},
{letter-b,1,0,'b'},
{0,0,0,0}
};
int main(int argc,char **argv) {
int idx,c;
while((c=getopt_long(argc,argv,a:b:,opt,idx))!=EOF)
printf(option: %c, optarg: %s\n,c,optarg);
};
It gives:
[EMAIL PROTECTED]:/tmp/g$ ./gol --letter-a -2d
option: a, optarg: -2d
[EMAIL PROTECTED]:/tmp/g$ ./gol -a -2d
option: a, optarg: -2d
Anyway, I don't see where any of the other packages you've mentioned are
providing a broken implementation of getopt_long. Shouldn't you check where
this broken function is coming from, and file the bug there?
Wish I know how to do it. Simple grep in sources gives no results.
That's why it is so mysterious to me and I am asking for help at wider
auditorium.
Because only apache/php4(module) is a problematic combination I suspect
an apache. If it is sufficient for you I have no objections against
reassigning this bug to apache package.
Best regards
Artur
--
Beowulf here http://www.messagelabs.com/home/default.asp they say that
spam is more than 50% of email...
Beowulf let's start some flames in -devel!
* Beowulf writes something about Sarge not being released
/from #debian-devel/
signature.asc
Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Gabor Gombas wrote: On Wed, Dec 21, 2005 at 06:08:04PM +0100, Marco d'Itri wrote: I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. An algorithm is buggy if it does not match the specification. I see no description about the lookup order wrt. multiple protocols, so the behaviour is conformant to the documentation. In this case, the algorithm does not match the specification. Therefore, it's a bug. Quoting the man page: Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. IPv6 queries are not excluded from this description. The fact is that with this bug, resolver queries with MORE than ndots are ALWAYS attempted using each component of the search path. Yes, the queries are IPv6 but that does not matter. If you read further down the man page: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. There's no ambiguity in the term 'absolute query'. A lookup for the IPv6 address example.com.domain.in.search.path is NOT an initial absolute query no matter how you look at it. Also note that resolv.conf(5) explicitely says that using search lines may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. The author of that man page did not have this bug in mind when he wrote that. If he did, the search functionality would have been removed. Yes, using the search line causes more network traffic than not using it. But this bug causes WAY more network traffic than a proper functioning search line. As I said in a previous e-mail, FreeBSD's resolver does it the correct way. Debian should follow suit, regardless of whether glibc developers consider this a bug (I'd be surprised if they thought it wasn't). Also, keep in mind that even if you DON'T use the search line at all and simply have 'domain example.com' in resolv.conf, which most users have by convention, then you're STILL having extraneous queries. I checked this too. Every resolver query your system ever makes will also look for an record of example.com.example.com even when example.com exists! How is that not a bug? Regards, Ed Gabor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#153022: Private Invite From Kristy Please join us
You have been invited to join our dating network by Kristy http://www.yummydating.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344481: Mysterious crash in php4-rrdtool
On Fri, Dec 23, 2005 at 02:44:21AM +0100, Artur R. Czechowski wrote:
On Thu, Dec 22, 2005 at 04:45:25PM -0800, Steve Langasek wrote:
On Fri, Dec 23, 2005 at 01:09:31AM +0100, Artur R. Czechowski wrote:
The rrd_graph_options() gets a string with parameters. The begin if this
string is (at least in my case, but this is common value in rrdtools):
--start -2d
The rrd_graph_options calls getopt_long to split parameters into tokens.
You can see the code in rrdtool's sources, file rrd_graph.c, line 2965.
getopt_long reckognises the --start parameter correctly and, according to
struct option returns opt as s. But, for some strange reasons, it sets
optarg for NULL.
Erm, don't you need to write --start=-2d if you want an optarg that begins
with a hyphen?
No. The s: in optstring and 1 as a second value in {start,1,0,'s'} always
makes next token a parameter.
Ok.
Anyway, I don't see where any of the other packages you've mentioned are
providing a broken implementation of getopt_long. Shouldn't you check where
this broken function is coming from, and file the bug there?
Wish I know how to do it. Simple grep in sources gives no results.
That's why it is so mysterious to me and I am asking for help at wider
auditorium.
Break on rrd_graph_options, step into getopt_long, run bt to see what lib it
says it's in.
Because only apache/php4(module) is a problematic combination I suspect
an apache. If it is sufficient for you I have no objections against
reassigning this bug to apache package.
I'd rather see some analysis to show where the bug actually belongs instead
of guessing and reassigning.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
