Bug#443065: locales: Prompts to replace locale.alias on upgrade
Package: locales Version: 2.6.1-5 Severity: wishlist When I upgrade locales I am being prompted to accept changes to locale.alias, a file which I have never to my knowledge edited. Reviewing the diff appears to support my recollection here. I'm guessing that this is as a result of moving locales.alias into /etc - it would be much nicer if this change were handled non-interactively. --- /etc/locale.alias 2004-08-09 20:05:03.0 +0100 +++ /etc/locale.alias.dpkg-new 2007-09-17 00:55:42.0 +0100 @@ -1,5 +1,5 @@ # Locale name alias data base. -# Copyright (C) 1996,1997,1998,1999,2000,2001 Free Software Foundation, Inc. +# Copyright (C) 1996-2001,2003 Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -26,8 +26,8 @@ # it with the rest of us. Send it using the `glibcbug' script to # [EMAIL PROTECTED] -bokmal no_NO.ISO-8859-1 -bokmE5l no_NO.ISO-8859-1 +bokmal nb_NO.ISO-8859-1 +bokmål nb_NO.ISO-8859-1 catalanca_ES.ISO-8859-1 croatian hr_HR.ISO-8859-2 czech cs_CZ.ISO-8859-2 @@ -38,7 +38,7 @@ eesti et_EE.ISO-8859-1 estonian et_EE.ISO-8859-1 finnish fi_FI.ISO-8859-1 -franE7aisfr_FR.ISO-8859-1 +français fr_FR.ISO-8859-1 french fr_FR.ISO-8859-1 galego gl_ES.ISO-8859-1 galician gl_ES.ISO-8859-1 @@ -58,7 +58,9 @@ korean.euc ko_KR.eucKR ko_KR ko_KR.eucKR lithuanian lt_LT.ISO-8859-13 -norwegian no_NO.ISO-8859-1 +no_NO nb_NO.ISO-8859-1 +no_NO.ISO-8859-1 nb_NO.ISO-8859-1 +norwegian nb_NO.ISO-8859-1 nynorsknn_NO.ISO-8859-1 polish pl_PL.ISO-8859-2 portuguese pt_PT.ISO-8859-1 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.22-2-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy ii libc6 [glibc-2.6-1] 2.6.1-4GNU C Library: Shared libraries locales recommends no packages. -- debconf information: * locales/default_environment_locale: en_GB.UTF-8 * locales/locales_to_be_generated: en_GB ISO-8859-1, en_GB.UTF-8 UTF-8, de_DE.UTF-8 UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#196189: Is There Really Any Cheap Hoooodia?
The hdia plant in the Kalahari Desert could become the newest weapon in the war against obesity. According to C.B.S. Hdia Gorrdoonnii Diet Pills is the Fastest, Most Effective weightreduction Supplement Available for fast results 1.Hdia gordonii is herbul -- it is not a drug. 2.Hdia has appetite suppressant abilities. 3.Hdia tricks the brain into thinking you've eaten. 4.Hdia gordonii is not a stimulant. 5.Safe for most people. 6.NO side effects. Key results of Hdia reported include a reduced interest in food, delay in the time after eating before hunger sets in again, feeling full more quickly, and a general feeling of well-being. http://neilsdre.blogspot.com/ visit this site for complete analysis. Information on the people involved in making films at the NFB To a practised eye a review of a draft Confidentiality Agreement needn't take that long. A good commercial lawyer should be able to identify the 10-20% and advise of any tweaks that may be required. If your bargaining power is weak, you will at least sign with knowledge of the consequences.How long can you glue your eyes to the road for a long journey? It can be boring... very boring. Tired, exhausted, shattered but still driving towards your destination. You always plan for a safe journey, but somethings don't always go according to plan. Your car breaks down or an accident occurs. Now this is more devastating on a motorway than on a normal street road and the last thing that will cross your mind is a road accident claimallaswithhappyIn the first instinct, you'll think how could it have happened or how stupid that other person was. You wish it didn't happen. Secondly, you're injured, and thirdly, it's going to take a couple of hours before your family finds out...Anyway back to the scene, you're concerned about other lives involved in the accident. Whilst this is happening, people at the back of the traffic don't have a clue about what's happened 3 miles up.The police, fire brigade and ambulance crew have just zoomed past them and now they know it's going to be a couple of hours wait. Windows go up, air conditioning is activated and the music plays... Now this wasn't plannedAccidents happen in the thousands that we don't even know locally sometimes. But people are either seriously injured and are suffering. At the time they just want to recover peacefully. But that is not always the case. Once a claim management company hears about the accident, the who, what and where, they rush to investigate.Then you'll hear all kind of crap, to get you to sign some papers for your injury, car and recovery. 95% of the time it's a blag (lie)allaswithhappy Then they'll either follow you to the hospital or find out where you live. But since the incident is in such tension, claim companies nagging at you, police breathalysing you and all the noise is giving you aheadache... sorry, migraine. You just want peace and quiet. A road accident is never the same...therefore a road accident claim can never be the same. It's unique. But you can get companies saying the same thing to you as they did at the previous accident scene. We'll do this for you and this is what you'll get paid out. Think about it...If a person has received amount in compensation, does that really mean that you will get the same? I doubt itallaswithhappy It's a selling technique. That person might have been a female, twice as old as you, wears glasses, has a hearing aid and this list could go on... Don't give in to these people, seek specialist advice first before signing anything, even to your insurance company. The insurance company looks after their pockets and claim management companies after theirs. It's your road accident claim, so think before you actallaswithhappy Claims don't get settled over night or in a couple of weeks as some might say. 'We'll settle your case in 4 months'. Tempting, isn't it? It takes time for the investigation to complete from your GP (for the extent of injuries), police (record of the accident, but not always compulsory) and the most time consumers, the insurance companies. The people who pay youallaswithhappy Letters going backward and forth, take time but some panel of solicitors can mutually work together to speed up the process. Solicitors who specialise in accident cases and have excellent knowledge are able to pursue quickly in these matters. You can make a road traffic accident compensation claim even if you are a passenger, cyclist or pedestrian. Make a wise choice and don't fall for 'tricks'allaswithhappyA car accident is never the same, similar but never the same. So logically a car accident claim can never be the same. Accidents do on the other hand occur in the millions every year, however making a successful compensation claim is difficult to get right if you don't make the right moves.All Car Accidents Are Unique There's one thing you need to beware of and
Re: glibc's getaddrinfo() sort order
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): I'm not familiar with how getaddrinfo() has been implemented in the past I think this is an important point. If you're not familiar with the history then perhaps I can help explain. hostname-to-address lookups have up to recently generally been done with gethostbyname. The addresses from gethostbyname are ordered as they were returned by the nameserver (unless special configuration is made locally to override this, which is rarely done). When multiple addresses are available for a single lookup, special code in all widely-deployed nameservers arranges to rotate or round-robin the returned addresses: each enquirer gets a new ordering. This is so that a single service name can be made to refer to a number of physical network interfaces (perhaps on different hosts) and the load shared across them. This is known as DNS based load balancing. If the protocol is one like mail, where callers can be expected to try multiple addreses if the first doesn't work, this gives you a failover as well. So far so good. (For clarify, it is the above round-robin functionality that I am arguing ought to be preserved.) gethostbyname can theoretically support IPv6 but it can only return one address type per call. While there is a way to embed an IPv4 address in an IPv6 address, for circumstances like these, there is no clear way to tell gethostbyname that the calling application (and the rest of the stack on which the application relies) will cope with getting a pile of AF_INET6 back rather than AF_INET. Therefore for IPv6, a new interface was needed. The interface (defined in RFC3493 s6.1 and its predecessors) is getaddrinfo. It has several new features most of which aren't relevant here. The critical new feature is this: getaddrinfo allows the application to specify whether it wants to get only IPv4 addresses or IPv6 addresses as well, and if getting mixed addresses, whether to encode then as AF_INET or as `v6-mapped' AF_INET6 (ie, the 32 bits of IPv4 address padded with a specific prefix to make up an IPv6 address, where the prefix means no actually this is not an IPv6 address but an IPv4 address and should be used with IPv4). Combined with various other new facilities, this makes it reasonably straightforward to convert an IPv4-only application to be IPv6-capable. So, in summary: getaddrinfo is intended to replace gethostbyname. However, additionally, it was realised that if getaddrinfo can return a mixture of IPv4 and v6 addresses it was necessary to specify in what order they ought to be returned. When RFC3484 was written its authors evidently felt that the best way to do this was to define a comparison function over all addresses, which would define which address was to be preferred. Heedless of the effect on the DNS round-robin functionality I describe above, the authors of RFC3484 specified (s6 rule 9) that all addresses should be sorted by proximity to the host making the choice - where proximity is defined as the length of the common initial address prefix. This may have been a disputed but arguable definition of real network proximity for IPv6 in at the time 3484 was written. But it is clear now that it is not such a measure in the real IPv6 internet, and it has never been such a measure in the IPv4 internet. So RFC3484 s6 rule 9 is just wrong, because the reasons behind it do not apply any more if they ever did. However, it's worse than that: rule 9 is trying to change the behaviour of existing systems. If we agree with rule 9 it ought to apply just as well to applications using gethostbyname. All existing applications using gethostbyname are not in compliance with rule 9. It would perhaps be possible to modify gethostbyname to sort addresses according to RFC3484 s5 and s6. But would it be a good idea ? No, obviously not. It would change the behaviour of all of the applications which currently use gethostbyname. Currently such applications pick addresses at random (according to the DNS round robin). Rule 9 would have applications pick them according to longest-common-prefix. This would destroy the DNS based load balancing arrangements. What about getaddrinfo ? Well, there is no reason why a change in API (to add additional richness needed for new functionality) should so radically change the behaviour. And indeed, we see that indeed the DNS load balancing of our own servers has been broken by this change ! That is, applications are changed from using non-rule-9 gethostbyname to rule-9 getaddrinfo, and the servers experience wildly unbalanced load and break. The RFC tries to make getaddrinfo return a predictable ordering in the face of random orderings from DNS. That seems a perfectly reasonable way to define a function in the abstract; though certainly the ordering it comes up with can be criticised. It is not reasonable for the RFC to attempt to specify that the addresses be returned in a predictable
Re: glibc's getaddrinfo() sort order
On Tue, Sep 18, 2007 at 03:33:51PM +0100, Ian Jackson wrote: Anthony Towns writes (Re: glibc's getaddrinfo() sort order): I'm not familiar with how getaddrinfo() has been implemented in the past I think this is an important point. If you're not familiar with the history then perhaps I can help explain. hostname-to-address lookups have up to recently generally been done with gethostbyname. Right, gethostbyname I am familiar with (along with the corresponding DNS round-robin behaviour), and changing its behaviour is certainly unreasonable. [...] So far so good. (For clarify, it is the above round-robin functionality that I am arguing ought to be preserved.) [...] However, additionally, it was realised that if getaddrinfo can return a mixture of IPv4 and v6 addresses it was necessary to specify in what order they ought to be returned. When RFC3484 was written its authors evidently felt that the best way to do this was to define a comparison function over all addresses, which would define which address was to be preferred. Heedless of the effect on the DNS round-robin functionality I describe above, the authors of RFC3484 specified (s6 rule 9) that all addresses should be sorted by proximity to the host making the choice - where proximity is defined as the length of the common initial address prefix. So if getaddrinfo() has always behaved in this way, I don't see a great deal of justification in changing it. The bug log indicated that there were pre-rfc implementations of getaddrinfo() that behaved more like gethostbyname() at least wrt round-robin DNS; but I've got no way of verifying that. This may have been a disputed but arguable definition of real network proximity for IPv6 in at the time 3484 was written. But it is clear now that it is not such a measure in the real IPv6 internet, and it has never been such a measure in the IPv4 internet. I hadn't seen any indication it was disputed for IPv6 prior to your mail. The patch in glibc only affected IPv4 addresses, for that matter. So RFC3484 s6 rule 9 is just wrong, because the reasons behind it do not apply any more if they ever did. To give an analogy to the lines I'm thinking along: the definition of tm_year in the tm struct in time.h is wrong, years since 1900 should be years since 0 AD, but the spec says otherwise, so programs simply need to deal with that historical craziness. That's not quite the same here, in that the spec does (by my reading) explicitly allow implementors to not behave in that way, but if you're coding to the spec you certainly can't rely on DNS round-robin being passed through an invocation of getaddrinfo(). However, it's worse than that: rule 9 is trying to change the behaviour of existing systems. If we agree with rule 9 it ought to apply just as well to applications using gethostbyname. All existing applications using gethostbyname are not in compliance with rule 9. The RFC specifies the behaviour of getaddrinfo(), not gethostbyname(), so doesn't affect any apps that solely use gethostbyname(). So no, it shouldn't be applied to other functions anymore than the definition of tm_year should mean we count from 1900 in every year related function. I think we can safely say that Rule 9 isn't useful for IPv4 addresses. I'm not sure that's true or not for IPv6 addresses -- it certainly seems an inappropriately hierarchial way of viewing a network that's connected much more ... fluidly than that, at any rate. But even if Rule 9 is completely useless and counterproductive, it's still the standard for that function, which, afaics, we should be meeting. What about getaddrinfo ? Well, there is no reason why a change in API (to add additional richness needed for new functionality) should so radically change the behaviour. Agreed in principle, but this is a rule the RFC should've followed; since they haven't, I'm not convinced we should. It is not reasonable for the RFC to attempt to specify that the addresses be returned in a predictable ordering when the established behaviour, relied on throughout the internet for decades, has been that the addresses are _not_ returned in a predictable order. Again, I agree with that, but the RFC *has* done that. I'd say it's more important that getaddrinfo() on Debian behave the same as on other operating systems, than that it behave in the same way as other functions. I can only take the RFC's assertion as to getaddrinfo()'s proper behaviour though; I don't have a more direct idea how getaddrinfo() behaves in previous versions of Debian, other Linux distros, other libcs, Windows, etc. This argument is an argument for accepting any crap that comes out of glibc upstream. No, it's an argument for accepting any crap that comes out of the Internet standards process. :-/ As I have demonstrated above, the RFC is wrong, inconsistent with existing practice, It's certainly inconsistent with gethostbyname()'s existing
Re: glibc's getaddrinfo() sort order
On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote: Heedless of the effect on the DNS round-robin functionality I describe above, the authors of RFC3484 specified (s6 rule 9) that all addresses should be sorted by proximity to the host making the choice - where proximity is defined as the length of the common initial address prefix. So if getaddrinfo() has always behaved in this way, I don't see a great deal of justification in changing it. The bug log indicated that there were pre-rfc implementations of getaddrinfo() that behaved more like gethostbyname() at least wrt round-robin DNS; but I've got no way of verifying that. glibc is the only implementation I know of that does this. I've attached a small test program. The results are: sarge: libc6 2.3.2.ds1-22sarge5: random order etch: libc6 2.3.6.ds1-13etch2: ordered results On other implementations I'm aware of is in libbind. You'll need to run configure with the --enable-libbind for that. It doesn't reorder it. I don't know of any of the other libcs in debian actually provide getaddrinfo(), but I doubt they'll reorder. There are also lots of applications that have a wrapper around gethostbyname() in case the libc doesn't provide it. It's highly unlikely any of those will do any reordering. This may have been a disputed but arguable definition of real network proximity for IPv6 in at the time 3484 was written. But it is clear now that it is not such a measure in the real IPv6 internet, and it has never been such a measure in the IPv4 internet. I hadn't seen any indication it was disputed for IPv6 prior to your mail. The patch in glibc only affected IPv4 addresses, for that matter. I've also stated that it might not work properly for IPv6. It's likely that something in the same /32 is close network wise, it's even more likely for /48 and /64, but you probably don't want to go below the /32. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
I've attached a small test program. The results are:
sarge: libc6 2.3.2.ds1-22sarge5: random order
etch: libc6 2.3.6.ds1-13etch2: ordered results
Maybe I should attach it.
Kurt
#include sys/types.h
#include sys/socket.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
int main()
{
struct addrinfo *res, *p, hints;
hints.ai_flags = 0;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
getaddrinfo(0.pool.ntp.org, ntp, hints, res);
for (p = res; p; p = p-ai_next)
{
if (p-ai_family == AF_INET)
{
char ip[INET_ADDRSTRLEN];
if (inet_ntop(p-ai_family,
(*(struct sockaddr_in *)p-ai_addr).sin_addr,
ip, sizeof(ip)) != NULL)
{
printf(%s\n, ip);
}
}
}
freeaddrinfo(res);
return 0;
}
Re: glibc's getaddrinfo() sort order
Anthony Towns writes (Re: glibc's getaddrinfo() sort order): So if getaddrinfo() has always behaved in this way, I don't see a great deal of justification in changing it. The bug log indicated that there were pre-rfc implementations of getaddrinfo() that behaved more like gethostbyname() at least wrt round-robin DNS; but I've got no way of verifying that. I don't know whether or not there were previous versions of getaddrinfo with the same behaviour as gethostbyname, but that is the wrong way of looking at it. getaddrinfo wasn't in widespread use until the recent efforts to support IPv6. Did you miss the bits where I said that * getaddrinfo is supposed to replace gethostbyname * applications are being changed t call getaddrinfo instead of gethostbyname ? There are only three possibilities: (a) It is correct that the behaviour of applications (and hence of hosts) should be changed to comply with rule 9. (b) Application behaviour should not change; getaddrinfo should behave the same way as gethostbyname. (c) Application behaviour should not change but getaddrinfo should comply with rule 9. Applications should therefore not be changed to use getaddrinfo instead of gethostbyname. Which of these are you proposing ? RFC3484 says (a) but is wrong for the reasons I have explained. (b) is my view. (c) is obviously unreasonable. Anthony Towns writes (Re: glibc's getaddrinfo() sort order): All existing applications using gethostbyname are not in compliance with rule 9. The RFC specifies the behaviour of getaddrinfo(), not gethostbyname(), Nonsense. It doesn't specify the behaviour of any such API at all. RFCs like this one specify the behaviour of _hosts_. That is, it specifies what kind of packets the host should emit and accept, on what interfaces. There is nothing in RFC3484 that limits its application to getaddrinfo rather than gethostbyname. There is discussion in s8 which suggests some possible behaviours of getaddrinfo as an `implementation strategy' for RFC3484 - but note that our getaddrinfo doesn't do what s8 suggests (because s8 is barking mad). If you agree with RFC3484 s8 then you ought to conclude that similar changes ought to be made to other internal interfaces which do the same job as getaddrinfo. so doesn't affect any apps that solely use gethostbyname(). So no, it shouldn't be applied to other functions anymore than the definition of tm_year should mean we count from 1900 in every year related function. This business about tm_year is a complete red herring. In fact, you've got my argument completely backwards. If someone wrote in a standards document that tm_year should be zero at 0AD (whatever that means) rather than 1900AD, what should we do ? Well, the answer would be obvious: we should continue to do what we have done forever, so as not to change the meaning of existing infrastructure: zero at 1900AD. This is what RFC3484 s6 is doing. It is trying to change the meaning of existing deployments of multiple IPv4 addresses in the global DNS. I think we can safely say that Rule 9 isn't useful for IPv4 addresses. Are you happy then that we should mandate that the Debian libc maintainer should change our libc accordingly ? I'm not sure that's true or not for IPv6 addresses -- it certainly seems an inappropriately hierarchial way of viewing a network that's connected much more ... fluidly than that, at any rate. But even if Rule 9 is completely useless and counterproductive, it's still the standard for that function, which, afaics, we should be meeting. It is NOT THE STANDARD as I have previously pointed out. An IETF working group proposed that it ought to become the standard but 1. the standard has not advanced further 2. that was in a time when IPv6 addressing structure was understood very differently. To justify my point 2, that RFC3484 predates substantial changes in the IPv6 addressing architecture: Site-local addresses are one of the key features that motivates the rules in RFC3484. These were deprecated by RFC3879 (status: PROPOSED) and this was confirmed in RFC4291 (status: DRAFT). (The standards track goes PROPOSED - DRAFT - STANDARD.) DNS for IPv6 was originally intended to be supported with A6, DNAME and bitstring labels according to RFC2874. This was originally Standards Track and was designed to support rapid and continuous renumbering. With the publication of RFC3363 (s1.1) and supported by the arguments in RFC3364, 2874 was moved to EXPERIMENTAL (ie, off the Standards Track), because rapid and continuous renumbering is no longer planned. Ie, the addressing and numbering arrangements for IPv6 have changed significantly since 3484 was written. That could well be why 3484 hasn't progressed. What about getaddrinfo ? Well, there is no reason why a change in API (to add additional richness needed for new functionality) should so radically change the behaviour. Agreed in principle, but this is a rule
Re: glibc's getaddrinfo() sort order
On Tue, Sep 18, 2007 at 07:18:40PM +0100, Ian Jackson wrote: There are only three possibilities: (a) It is correct that the behaviour of applications (and hence of hosts) should be changed to comply with rule 9. (b) Application behaviour should not change; getaddrinfo should behave the same way as gethostbyname. (c) Application behaviour should not change but getaddrinfo should comply with rule 9. Applications should therefore not be changed to use getaddrinfo instead of gethostbyname. No, there aren't. A fourth possibility is: (d) Applications should use getaddrinfo(), and if the ordering behaviour it uses is not desired, they should use an ordering that is desired. Since we're at the point where you're yelling at me about how I'm not listening, I won't reply further. Cheers, aj signature.asc Description: Digital signature
Re: glibc's getaddrinfo() sort order
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote: On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote: So if getaddrinfo() has always behaved in this way, I don't see a great deal of justification in changing it. [...] glibc is the only implementation I know of that does this. Windows implementations would seem like the other candidate, given the Microsoft Research at the top of that RFC. Cheers, aj signature.asc Description: Digital signature
Bug#249122: Local representatives wanted. Successful international company is looking for talented people. No investment is needed.
Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: [EMAIL PROTECTED] 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with money muls In your brain right now, a motor protein called kinesin is shuttling vesicles loaded with neurotransmitters to the synapses in your brain, allowing you to read this. While some researchers are trying to make similar molecular motors scoot around and throw switches on electronic chips, it's hardly certain these motors can ever do better than the electrical contacts that are routinely used today. The future of biological nanotechnology may not be clear, but what is, says Professor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
* Ian Jackson ([EMAIL PROTECTED]) [070918 16:35]: So RFC3484 s6 rule 9 is just wrong, because the reasons behind it do not apply any more if they ever did. I have some stanza from the dns-operations list: http://lists.oarci.net/pipermail/dns-operations/2007-September/002028.html | Either it [RFC3484] should be corrected or declared Historic. Denic is the german domainnames authority, and they usually know what they do (especially Peter Koch does). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 442247 to libc6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.8 reassign 442247 libc6 Bug#442247: CVE-2007-4840 multiple errors in iconv function Warning: Unknown package 'glibc-2.6-1' Bug#442250: CVE-2007-4840 multiple errors in iconv function Warning: Unknown package 'glibc-2.6-1' Bug reassigned from package `glibc-2.6-1' to `libc6'. 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]
Processed: reassign 442250 to libc6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.8 reassign 442250 libc6 Bug#442250: CVE-2007-4840 multiple errors in iconv function Bug#442247: CVE-2007-4840 multiple errors in iconv function Bug reassigned from package `libc6' to `libc6'. 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]
Processed: Re: Bug#442250: [PHP-DEV] CVE-2007-4840
Processing commands for [EMAIL PROTECTED]: tag 442250 + wontfix Bug#442250: CVE-2007-4840 multiple errors in iconv function Tags were: security Bug#442247: CVE-2007-4840 multiple errors in iconv function Tags added: wontfix 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#442247: Bug#442250: [PHP-DEV] CVE-2007-4840
tag 442250 + wontfix
thanks
On Tue, Sep 18, 2007 at 09:48:55PM +, sean finney wrote:
iconv_t
iconv_open (const char *tocode, const char *fromcode)
{
char *tocode_conv;
char *fromcode_conv;
size_t tocode_len;
size_t fromcode_len;
__gconv_t cd;
int res;
/* Normalize the name. We remove all characters beside alpha-numeric,
'_', '-', '/', '.', and ':'. */
tocode_len = strlen (tocode);
tocode_conv = (char *) alloca (tocode_len + 3);
=
so it's not surprising that big strings could end up being problematic...
OTOH the caller should check those are likely charsets. I mean calling
iconv_open with strhings that are longer than a few octets is completely
silly. The longest charset the libc recognize is 22 chars long, 32 if
you append //TRANSLIT to it.
mallocing for that is completly silly, and the caller should do some
basic sanitizing first.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpPAaR4kjGGb.pgp
Description: PGP signature
Time Zone change in Caracas zoneinfo
Hello fellas Venezuelan Linuxers may need an update of TZDATA Effective at September 24 there will be a change of official timezone for Venezuela (zoneinfo/America/Caracas) from -4:00 UTC to -4:30 UTC (no daylight saving) You can see a rendition of this new at: http://today.reuters.com/news/articlenews.aspx?type=oddlyEnoughNewsstoryid=2007-08-24T121349Z_01_N23289803_RTRUKOC_0_US-VENEZUELA-TIME.xml Cesar A. Villanueva Rodriguez Hardware Operating Systems Coordinator Ph: (+58 212) 7062500 / Ext. 5427 Mobile: (+58 416) 925.4559 www.smartmatic.com The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#175025: If you want to make a carrier in a successful company - we are proud to invite you in our business.
Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: [EMAIL PROTECTED] 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with money muls To study single molecules, Block has pioneered the use of optical tweezers, tiny laser-based tractor beams that produce miniscule piconewton forces to drag around molecules and allow measurements of displacements on the order of a nanometer. You can stop and stall molecules, w follow their motion. Recently, we've studied the backtracking of RNA polymerase: when it makes a mistake, it can actually back up by five bases, scoop off the wrong thing and start again, says Block. While biological nanotechnology hasn't even arrived at its infancy yet, says Block, biological nanoscience is a very exciting place to be right now, because the techniques now exist to truly study proteins, and we're learning so much about them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#65458: Home based employment opportunities for talented people. No investment needed, no sign-up fees.
Big international commercial organization is seeking of talented, honest, reliable representatives in different regions. Because of developing of our business the organization is proposing to you to become its part. You can work part time or full time. Requirements: Internet Connection Basic knowledge of PC Honesty Reliability Basic knowledge of marketing is a plus. If you want to get an opportunity to make a career, to earn some extra money, to gain new experience during the work, you should send us the following information to: [EMAIL PROTECTED] 1) Full name 2) Contact phone numbers 3) Languages 4) Part time job/Full time No investments needed to start working with us. The preference is given to employees with knowledge of foreign languages. Thank you and we are looking forward to cooperate in long term base with you. P.S. This job is not associated with money muls Here's To Biology: Nature's Own Nanomachines Dr. Steve Block, Biology and Applied Physics -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
