Bug#119528: Reorder Notification By world-pills.com
Good Day We deliver to you very fast - and that is a promise. Visit The Site Now world-pills.com nfwyckwpwn wVnfHDOFNZwvtXYEbOGwMjyTDuAeDV loathing club's lowest conclude Gorham defective microsecond's Atreus blackbody Sandburg manifolds gerundive launderer fits colt's battleship incarnation's Beograd indignity demitting flea butter incomputable encase Gorham balking disassembled lowboy butter minimum apprentice influentially alligators baking legality applicable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Too busy to go back to school,{} but need a University {}Degree{} to get ahead?
In just 2 years you can have a masters degree from a national university.
A better job, more income and a better life can all be yours in just 2 years.
No books to buy, no classes to go to, and no entrance exams.
Learn in your own home at your own pace. We supply all the study materials, all
you have to do is study and complete 2 tests per month.
{diplom9} Anytime {Numberdiplom} {Perioddiplom}
Call the number below for more information:
Dial Instantly +1 (831) 3O0 66 43
Live All The Time
-
cyclorama collimate aversion affinity armenian burro delectate catherine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373779: libc6: assertion failure in gconv_db.c with smbclient
Package: libc6 Version: 2.3.999.2-4 Severity: normal # smbclient smbclient: gconv_db.c:232: __gconv_release_step: Assertion `step->__end_fct == ((void *)0)' failed. Aborted # This does not happen with 2.3.6-9. The bug seems to occur while loading shared libraries as different options to smbclient don't change the behaviour and strace shows some library loading stuff before. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii tzdata2006g-2Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373781: resolver fails if CNAME points to A record in non-authoritative domain
Package: libc6 Version: 2.3.2.ds1-22sarge3 Severity: normal [this problem exists in libc6 all through unstable] I set up our internal DNS server to answer a query for gluck.mydebian.org with a CNAME for gluck.debian.org. However, I cannot access it: piper:~> host gluck.mydebian.org gluck.mydebian.orgCNAME gluck.debian.org gluck.debian.org A 192.25.206.10 piper:~> ping gluck.mydebian.org ping: unknown host gluck.mydebian.org The reason seems to be that the CNAME response does not contain the A record, and the resolver doesn't bother to go out to resolve the name pointed to by the CNAME. This is what happens if I resolve a CNAME outside of my own network, so my DNS server is caching/recursing only: 192.168.20.21 -> 192.168.20.1 DNS Standard query A ftp.ch.debian.org 192.168.20.1 -> 192.168.20.21 DNS Standard query response CNAME debian.ethz.ch A 129.132.86.196 Notice how the answer includes the A record. This is what happens if the CNAME is resolved internally, but the A record has to be resolved externally (or the other way around, CNAME externally and A record internally): 192.168.20.21 -> 192.168.20.1 DNS Standard query A gluck.mydebian.org 192.168.20.1 -> 192.168.20.21 DNS Standard query response CNAME gluck.debian.org Note the lack of A record. Arguably, my DNS server (maradns) is at fault here, for it fails to do the work the way one might expect. But in either case, the local resolver *should* be able to cope with the situation, just like the `host' utility: 192.168.20.21 -> 192.168.20.1 DNS Standard query A gluck.mydebian.org 192.168.20.1 -> 192.168.20.21 DNS Standard query response CNAME gluck.debian.org 192.168.20.21 -> 192.168.20.1 DNS Standard query A gluck.debian.org 192.168.20.1 -> 192.168.20.21 DNS Standard query response A 192.25.206.10 ... which means that if all it gets is a CNAME in response to request of (almost) any type, it should repeat the request for the same type with the new name, IMHO. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP)
Re: Cleaning up kernel's headers for userspace
On Mon, 2006-04-24 at 12:45 +0100, David Woodhouse wrote: > The Linux kernel makes a complete abortion of exporting stuff to > userspace in its headers. I'm trying to clean this up -- I've > implemented a 'make headers_install' in the kernel tree which copies out > selected headers which are supposed to be user-visible, and runs them > through unifdef if appropriate. > > I've also added a 'make headers_check' which currently only does a > primitive check that the exported headers don't try to include anything > which _wasn't_ selected for inclusion, but hopefully can be extended to > check that each header is compilable on its own, and check for namespace > pollution, etc. > > I've also committed a few fixes so that the PowerPC kernel actually > passes the 'make headers_check'. This is all in a git tree at > git://git.infradead.org/~dwmw2/headers-2.6.git -- browsable at > http://git.infradead.org/?p=users/dwmw2/headers-2.6.git > > As maintainers for glibc and/or kernel headers in various distributions, > I'd like to solicit your feedback, and possibly also your assistance. > Does this look like it's going to address your needs and give you > something which you can just drop into /usr/include/ and use as it is? > If not, what's wrong with it and what can we do about it? > > If all is well with the approach, I'd like to get it merged upstream and > then get started on actually cleaning up the crap which is exported, now > that 'make headers_install' actually puts it somewhere we can see it in > context. Update I've been shipping the output of this in Fedora's development tree for a while, and the upcoming Fedora Core 6 test 1 has been entirely built against it. I'm fairly happy with its current state. Since 2.6.17 is due for release imminently, I hope to send it to Linus fairly shortly too -- so I'm asking once again for feedback. The feedback was generally positive before, but it was early days. Now that it's taken shape, I'd like more specifics -- is there anything about this which makes it unsuitable for your use? Anything which you think we should change? Other comments? At some point in the fairly near future I'd like to tighten up the list of files we 'export' -- removing asm/atomic.h in particular, since it's absolutely broken for anyone in userspace. But I don't want to enforce policy like that (which some nutters might actually object to) in the first pass. Let's get the mechanism in place first... -- dwmw2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344481: Need other to be fixed
severity 344481 important block 330197 by 344481 thanks I see no reason to keep #344481 as serious until there is no known reason of #330197. -- "Nasz bohater często siada przed komputerem i myśli" recenzja http://czat.zlotemysli.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Need other to be fixed
Processing commands for [EMAIL PROTECTED]: > severity 344481 important Bug#344481: php4-rrdtool: Use of RRD extensions (graph only?) causes Apache to segfault Severity set to `important' from `serious' > block 330197 by 344481 Bug#330197: php4-rrdtool: Use of RRD extensions (graph only?) causes Apache to segfault Was not blocked by any bugs. Blocking bugs added: 344481 > 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]
