Re: [gentoo-dev] Ïðèâåò!

Re: [gentoo-dev] Ïðèâåò!

[Collins Richey]

try again in a language we can read/

-- 
Collins Richey
Denver Area
Gentoo_rc5 XFCE

[gentoo-dev] ×âÐéÄâÖ÷»úË͹ú¼Ê¶¥¼¶ÓòÃû£¬ËÍÎåÊ®Õ×ÆóÒµÓÊÏ䣬

[¶¥µãÊý¾Ý]

尊敬的客户，您好！  

    顶点数据在新的一年为企业、个人上网建站推出最新的解决方案，
租用虚拟主机 
       免费赠送国际英文域名(价值100元）

       送5个10M企业级电子邮箱（价值150元） 
  
       虚拟主机转入（自有域名）则优惠60元 
  
       支持ASP/PHP、CGI及简单的数据库程序 
  
　     先开通，后付费，不满意可退款; 

特别推荐：

    50M空间+1国际域名+30M电子邮箱=190元/年
    60M空间+1国际域名+30M电子邮箱=268元/年
    150M空间+1国际域名+50M电子邮箱=350元/年   
    200M空间+1国际域名+50M电子邮箱=450元/年   
    250M空间+1国际域名+50M电子邮箱=480元/年 
  
◆ 注册.com .net .org 英文国际域名100元/年 
  
◆ 注册.com .net .org 中文国际域名300元/年 
  
◆ 注册.cc 英文国际域名380元/年 
  
◆ 注册.com\net\org.cn英文国内域名300元/年 
  
◆ 注册.cn(公司/网络)/中文通用域名280元/年 
  
◆ 注册通用域名 400元/年  

 
    通用网址(网络实名）：
 
    400元/年――全国最低价！！

    企业建站标准型：

    2500元――15个页面（含访客计数器、信息反馈表单、
　　　　　　　 国际域名、200M虚拟主机空间）

    代理将享受更大的优惠条件……

                 
 
    更多优惠方案敬请访问：http://www.129k.com
    
        祝　马年大发!

           
                                厦门三思网络服务有限公司


使用极星邮件群发，无须通过邮件服务器，直达对方邮箱，速度绝对一流！
下载网址：http://love2net.51.net/，更多免费的超酷软件等你来下……

----------------------------------------------------
INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.
----------------------------------------------------

[gentoo-dev] ÷îéíáîéå ÷éòõó !!!

[root]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

                                                       
              ÷ î é í á î é å   ÷ é ò õ ó !!!
		                    
÷ ÷ÁÛÅÍ ÐÉÓØÍÅ, ÏÔÐÒÁ×ÌÅÎÎÏÍ 
ÄÌÑ  webmaster@ldapadministrator.com 
 Sun, 15 Sep 2002 20:15:34 +0200 (added by postmaster@wanadoo.fr)
Ó ÚÁÇÏÌÏ×ËÏÍ " Superatomique d".


	ï â î á ò õ ö å î    ÷ é ò õ ó !!!


   äÏÓÔÁ×ËÁ ÐÉÓØÍÁ ÂÌÏËÉÒÏ×ÁÎÁ.

ðÏÖÁÌÕÓÔÁ ÐÒÏ×ÅÒØÔÅ ÷ÁÛÕ ÓÉÓÔÅÍÕ ÁÎÔÉ×ÉÒÕÓÎÙÍÉ ÓÒÅÄÓÔ×ÁÍÉ
É ÐÏ×ÔÏÒÉÔÅ ÏÔÐÒÁ×ËÕ.

[gentoo-dev] ÷îéíáîéå ÷éòõó !!!

[root]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

                                                       
              ÷ î é í á î é å   ÷ é ò õ ó !!!
		                    
÷ ÷ÁÛÅÍ ÐÉÓØÍÅ, ÏÔÐÒÁ×ÌÅÎÎÏÍ 
ÄÌÑ  webmaster@ldapadministrator.com 
 Sun, 15 Sep 2002 20:15:34 +0200 (added by postmaster@wanadoo.fr)
Ó ÚÁÇÏÌÏ×ËÏÍ " Superatomique d".


	ï â î á ò õ ö å î    ÷ é ò õ ó !!!


   äÏÓÔÁ×ËÁ ÐÉÓØÍÁ ÂÌÏËÉÒÏ×ÁÎÁ.

ðÏÖÁÌÕÓÔÁ ÐÒÏ×ÅÒØÔÅ ÷ÁÛÕ ÓÉÓÔÅÍÕ ÁÎÔÉ×ÉÒÕÓÎÙÍÉ ÓÒÅÄÓÔ×ÁÍÉ
É ÐÏ×ÔÏÒÉÔÅ ÏÔÐÒÁ×ËÕ.

Re: [gentoo-dev]

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Mauch wrote:
> Danny van Dyk wrote:
> 
>>  * profile:
>>    List and switch Gentoo portage profiles. Check if selected
>>    profile is valid in regard to used "ARCH".
> 
> 
> Hmm, have to check this out and see if I can obsolete my own little hack
> for changing profile.

Wasn't available in 0.9.1 but is in 0.9.2.  It currently only shows one
possible valid profile though since of course profiles.desc only shows one per
arch.

Judging by some gentoo-commits.log sed/sort/grep -c-foo there's still quite a
few ppl using 2.0.51.19 so looks like we'll have to wait a little bit before we
can update profiles.desc.

Cheers
- --
The happiest time of a person's life is after his first divorce.
		-- J.K. Galbraith

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCfygoC3poscuANHARAqRgAJ4iobDKJPTOoHVO84+4fhRY3rk3hgCfW2VD
4bohppeFObnQc8ZEH5nuZmA=
=oKFm
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev]

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Sun, 2005-05-08 at 19:53 -0400, Mike Frysinger wrote:
> app-mobile sounds good to me ... then just use metadata.xml to include a 
> 'fuller' description :P

Please don't use app-mobile as it may be confused with mobile computing,
not mobile phones.

Any reason why these packages can not go into app-pda? Most modern
mobile phones can be considered a handheld computer (and many of them
can be thought of as either a phone with integrated PDA - or a PDA with
integrated phone).

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev]

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Henrik Brix Andersen wrote:

>On Sun, 2005-05-08 at 19:53 -0400, Mike Frysinger wrote:
>  
>
>>app-mobile sounds good to me ... then just use metadata.xml to include a 
>>'fuller' description :P
>>    
>>
>
>Please don't use app-mobile as it may be confused with mobile computing,
>not mobile phones.
>
>Any reason why these packages can not go into app-pda? Most modern
>mobile phones can be considered a handheld computer (and many of them
>can be thought of as either a phone with integrated PDA - or a PDA with
>integrated phone).
>
>
>  
>
I think I will call it app-mobphone.

Please explain what do you understand as "mobile computing". You keep
using this term.
>From what I see in herds.xml, mobile == "Wireless (802.11a/b/g,
bluetooth, etc) related items"

Mobile phones are far from PDAs. I don't see anything you can't do with
a PDA (since it _is_ a computer).
Compared to them, _normal_ mobile phones are very limited devices.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev]

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Mon, 2005-05-09 at 16:21 +0300, Alin Nastac wrote:
> Please explain what do you understand as "mobile computing". You keep
> using this term.
> >From what I see in herds.xml, mobile == "Wireless (802.11a/b/g,
> bluetooth, etc) related items"

http://en.wikipedia.org/wiki/Mobile_computing

> Mobile phones are far from PDAs. I don't see anything you can't do with
> a PDA (since it _is_ a computer).
> Compared to them, _normal_ mobile phones are very limited devices.

My last two mobile phones (Motorola A920 and Motorola E1000) are
symbian-based hand-helds, and they act like a PDA - but I still can't do
the same stuff with my PDA as I can with a PC.

I suggested app-pda because of the metadata.xml description:

        The app-pda category contains software for working with personal
        digital assistants or hand-held computers.

As I've said, I think most modern mobile phones can be considered being
a PDA/hand-held computer.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Linux


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev]

[Sami Samhuri]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

* On Mon May-09-2005 at 03:34:36 PM +0200, Henrik Brix Andersen said:
> On Mon, 2005-05-09 at 16:21 +0300, Alin Nastac wrote:
[...]
> > Mobile phones are far from PDAs. I don't see anything you can't do with
> > a PDA (since it _is_ a computer).
> > Compared to them, _normal_ mobile phones are very limited devices.
> 
> My last two mobile phones (Motorola A920 and Motorola E1000) are
> symbian-based hand-helds, and they act like a PDA - but I still can't do
> the same stuff with my PDA as I can with a PC.

I have a symbian phone as well (Nokia 3595, at least I'm pretty sure
Nokia's run symbian) but it does not act like a PDA. Luckily I also have
a PDA (i-Mate PDA2K, aka O2 XDA IIs, MDA III, and so on...) which acts
as a phone. Needless to say these devices are far from similar.

> I suggested app-pda because of the metadata.xml description:
> 
>         The app-pda category contains software for working with personal
>         digital assistants or hand-held computers.
> 
> As I've said, I think most modern mobile phones can be considered being
> a PDA/hand-held computer.

The latest and greatest phones can almost be considered PDAs, I agree.
But they are not the norm yet. I mean, my phone can run Java
applications and has GPRS but that's about as far as it goes. My PDA,
well it has everything from BlueTooth and 802.11b to GPRS, GSM (850,
900, 1800, 1900) as well as an internal 128M flash memory and a 512M SD
card in the expansion slot. It even has a slide-out keyboard.  This
thing is more powerful than most PCs 10 years ago. They are converging,
but PDAs are advancing at an astonishing rate since they're geared
towards power users and geeks. Phones aren't moving as fast since for
the average person they just want a phone that makes and receives calls.
Does the average person use Gentoo? Probably not, but I still think they
are very different beasts for now and should be kept separate.

I am aware that mobile phones outside of North America are much more
advanced (in general) so perhaps this is the cause of this little
disagreement. I don't have a really strong opinion either way, but I
thought I'd throw in my user's perspective.

-- 
Sami Samhuri

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev]

[Chris]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

unsubscribe

[-- Attachment #2: Type: text/html, Size: 13 bytes --]

[gentoo-dev]

[Ser Gio]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Fri, 14 Jul 2006 00:19:44 +0200
Jakub Moc <jakub@gentoo.org> wrote:

> Ser Gio wrote:
> > Hello,
> >
> > Why does x11-libs/gtk+-2.8.19 has the "X" useflag? The ebuild
> > doesn't look like it's using it.
> >
> > thanks,
> > Sérgio
>
> Because virtualx.eclass has it in IUSE and the ebuild inherits it.

Yes, i noticed that. But, for the enduser, the X flag in gtk+ is useless
right? So, is it a bug?

Regards,
Sérgio Martins

[-- Attachment #2: Type: text/html, Size: 596 bytes --]

Re: [gentoo-dev]

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Ser Gio wrote:
> On Fri, 14 Jul 2006 00:19:44 +0200
> Jakub Moc <jakub@gentoo.org <mailto:jakub@gentoo.org>> wrote:
> 
>> Ser Gio wrote:
>> > Hello,
>> >
>> > Why does x11-libs/gtk+-2.8.19 has the "X" useflag? The ebuild
>> > doesn't look like it's using it.
>> >
>> > thanks,
>> > Sérgio
>>
>> Because virtualx.eclass has it in IUSE and the ebuild inherits it.
> 
> Yes, i noticed that. 

So, why do you ask?

> But, for the enduser, the X flag in gtk+ is useless right? So, is it a bug?

No, it's not gtk+ ebuild bug. Feel free to submit portage patch to avoid
this. ;)


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev]

[Steev Klimaszewski]

On Fri, 2006-07-14 at 01:02 +0100, Ser Gio wrote:
> On Fri, 14 Jul 2006 00:19:44 +0200
> Jakub Moc <jakub@gentoo.org> wrote:
> 
> > Ser Gio wrote:
> > > Hello,
> > > 
> > > Why does x11-libs/gtk+-2.8.19 has the "X" useflag? The ebuild 
> > > doesn't look like it's using it.
> > > 
> > > thanks,
> > > Sérgio
> > 
> > Because virtualx.eclass has it in IUSE and the ebuild inherits it.
> 
> Yes, i noticed that. But, for the enduser, the X flag in gtk+ is
> useless right? So, is it a bug? 
> 
> Regards,
> Sérgio Martins

Actually, as of 2.10, gtk+ CAN be built without X and using the
framebuffer, so you can build gtk+ apps against the framebuffer (using
them, is another story... although I hear GIMP works)  so having it
there isn't necessarily useless.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev]

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

On Thursday 13 July 2006 20:13, Steev Klimaszewski wrote:
> Actually, as of 2.10, gtk+ CAN be built without X and using the
> framebuffer, so you can build gtk+ apps against the framebuffer (using
> them, is another story... although I hear GIMP works)  so having it
> there isn't necessarily useless.

s/necessarily//
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev]

[Alexander Rauth]

unsubscribe  gentoo-dev

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev]

[Alexey Savelyev]

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev]

[Kazi Ferdous]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 5 bytes --]

[gentoo-dev]

[Tobias Klausmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1899 bytes --]

Hi, 

glibc 2.9 uses a different way to implement getaddrinfo() which
triggers a race condition in most (if not all) Netfilter
firewalls that use connection tracking. glibc does nothing wrong
per se, it just triggers the condition. (technical details here:
http://marc.info/?l=linux-netdev&m=123304473331445)

Since glibc 2.9 fires off two udp packets (a query for the A
record and one for the AAAA record), a race condition is
triggered in Netfilter (see URL). This has been acknowledged by
several people and I can reproduce it (relatively) reliably in
our LAN with all Gentoo boxes that have 2.9.

Why am I bringing this up here? Well, I figure that eventually,
2.9 (or some other version with equivalent code) will become
stable and we'll get lots of bug reports from people who run into
this. Since they can not simply backdate to 2.7 for various
reasons *and* they might be unable to fix a packetfilter (because
it might not be their own), this might become very ugly.

The Kernel/Netfilter devs (probably) are aware now of the issue
since I mailed them - but it's not all that easy to fix. On top
of that, even if it was fixed in (say) 2.6.28.3 and 2.6.29, this
does not mean that it's deployed out there and it might be very
hard for our users to get some firewall guy to update their
kernel when this is perceived as glibc's or our fault (plus the
widespread "ricer" cliché about Gentoo users; I've gotten an
idiotic reply to that effect already).

I don't have any experience with glibc upstream but pestering
them about this out of the blue might only cause a flame war
between kernel and glibc folks. Thus, I'm asking you, my fellow
devs (and the glibc and kernel teams specifically), what you
think is the best idea/course of action.

Regards,
Tobias
(Blackb|rd)
-- 
printk("Cool stuff's happening!\n")
        linux-2.4.3/fs/jffs/intrep.c

Re: [gentoo-dev]

[Peter Alfredsen]

[Mike: This looks like your field of expertise]
On Tue, 27 Jan 2009 16:47:50 +0100
Tobias Klausmann <klausman@gentoo.org> wrote:

> Hi, 
> 
> glibc 2.9 uses a different way to implement getaddrinfo() which
> triggers a race condition in most (if not all) Netfilter
> firewalls that use connection tracking. glibc does nothing wrong
> per se, it just triggers the condition. (technical details here:
> http://marc.info/?l=linux-netdev&m=123304473331445)
[...]
> I don't have any experience with glibc upstream but pestering
> them about this out of the blue might only cause a flame war
> between kernel and glibc folks. Thus, I'm asking you, my fellow
> devs (and the glibc and kernel teams specifically), what you
> think is the best idea/course of action.

The connection with IPv6 leads me to believe that this is
http://bugs.gentoo.org/250468
http://sourceware.org/bugzilla/show_bug.cgi?id=7060

Mike has added a patch to Gentoo's patchset but hasn't bumped the
revision yet. It does look spectacularly hacky, though :-)

Anyway, if this is your problem, it looks like upstream is already
working on it and that we just need to *prod* Mike a bit to get a fix
into the tarball.

/PA

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Tobias Klausmann]

Hi! 

(fixed the subject)

On Tue, 27 Jan 2009, Peter Alfredsen wrote:
> [Mike: This looks like your field of expertise]
> On Tue, 27 Jan 2009 16:47:50 +0100
> Tobias Klausmann <klausman@gentoo.org> wrote:
> 
> > glibc 2.9 uses a different way to implement getaddrinfo() which
> > triggers a race condition in most (if not all) Netfilter
> > firewalls that use connection tracking. glibc does nothing wrong
> > per se, it just triggers the condition. (technical details here:
> > http://marc.info/?l=linux-netdev&m=123304473331445)
> [...]
> > I don't have any experience with glibc upstream but pestering
> > them about this out of the blue might only cause a flame war
> > between kernel and glibc folks. Thus, I'm asking you, my fellow
> > devs (and the glibc and kernel teams specifically), what you
> > think is the best idea/course of action.
> 
> The connection with IPv6 leads me to believe that this is
> http://bugs.gentoo.org/250468
> http://sourceware.org/bugzilla/show_bug.cgi?id=7060

I doubt it: sometimes the lookups work, as this race is very
timing-critical. When experimenting, I had to go below 50
microseconds between the two packets to actually trigger it plus
the forwarding machines always were multicore. Also, the content
is irrelevant. I implemented this myself sending the payloads
with sendto() and it didn't matter if I sent the A or AAAA query
first.

That said, without seeing a tcpdump from those people with the
error described in those two bugs, I can not rule it out.

On the wire between the client and the firewall, this happens:

a packet 1 is sent
b packet 2 is sent
c answer 1 is received
d answer 2 is received

Sometimes d doesn't happen because b is lost in the firewall
along the way (where the race condition happens). 

> Mike has added a patch to Gentoo's patchset but hasn't bumped the
> revision yet. It does look spectacularly hacky, though :-)
> 
> Anyway, if this is your problem, it looks like upstream is already
> working on it and that we just need to *prod* Mike a bit to get a fix
> into the tarball.

The bug is in the kernel, not glibc. The latter just triggers it
because the newer resolver has a more aggressive timing. Note
that I think that what the glibc guys did is a *good* idea. It
just happens to rub Netfilter the wrong way.

Regards,
Tobias

-- 
printk("Cool stuff's happening!\n")
        linux-2.4.3/fs/jffs/intrep.c

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Mike Frysinger]

On Tuesday 27 January 2009 11:59:46 Tobias Klausmann wrote:
> On Tue, 27 Jan 2009, Peter Alfredsen wrote:
> > On Tue, 27 Jan 2009 16:47:50 +0100 Tobias Klausmann wrote:
> > > glibc 2.9 uses a different way to implement getaddrinfo() which
> > > triggers a race condition in most (if not all) Netfilter
> > > firewalls that use connection tracking. glibc does nothing wrong
> > > per se, it just triggers the condition. (technical details here:
> > > http://marc.info/?l=linux-netdev&m=123304473331445)
> >
> > [...]
> >
> > > I don't have any experience with glibc upstream but pestering
> > > them about this out of the blue might only cause a flame war
> > > between kernel and glibc folks. Thus, I'm asking you, my fellow
> > > devs (and the glibc and kernel teams specifically), what you
> > > think is the best idea/course of action.
> >
> > The connection with IPv6 leads me to believe that this is
> > http://bugs.gentoo.org/250468
> > http://sourceware.org/bugzilla/show_bug.cgi?id=7060
>
> I doubt it: sometimes the lookups work, as this race is very
> timing-critical. When experimenting, I had to go below 50
> microseconds between the two packets to actually trigger it plus
> the forwarding machines always were multicore. Also, the content
> is irrelevant. I implemented this myself sending the payloads
> with sendto() and it didn't matter if I sent the A or AAAA query
> first.
>
> That said, without seeing a tcpdump from those people with the
> error described in those two bugs, I can not rule it out.

the referenced bug generally deals with broken nameservers that cant handle 
the type of requests that glibc sends out (the requests are correct according 
to the relevant standards/RFCs, but apparently many DNS servers out there 
screw up with it due to the ipv4/ipv6 combo).

the referenced thread seems to indicate even more the issue is in the 
netfilter code.

> On the wire between the client and the firewall, this happens:
>
> a packet 1 is sent
> b packet 2 is sent
> c answer 1 is received
> d answer 2 is received
>
> Sometimes d doesn't happen because b is lost in the firewall
> along the way (where the race condition happens).

does this affect actual userspace behavior ?  in other words, does this lead 
to lost lookups and errors from the resolver ?
-mike

[gentoo-dev] Re: Race condition in Netfilter triggered by glibc 2.9

[Duncan]

Mike Frysinger <vapier@gentoo.org> posted
200901282125.52845.vapier@gentoo.org, excerpted below, on  Wed, 28 Jan
2009 21:25:50 -0500:

>> On the wire between the client and the firewall, this happens:
>>
>> a packet 1 is sent
>> b packet 2 is sent
>> c answer 1 is received
>> d answer 2 is received
>>
>> Sometimes d doesn't happen because b is lost in the firewall along the
>> way (where the race condition happens).
> 
> does this affect actual userspace behavior ?  in other words, does this
> lead to lost lookups and errors from the resolver ?

Some of this is beyond my comprehension level, but I've seen interesting 
lookup behavior that is at minimum, rather nicely coincidental.

Specifically, from my machine (running a local caching bind, with 
netfilter on both the machine itself and on my OpenWRT based router), 
doing host lookups on second level domains (cox.com in my case) with MX 
entries works fine, while lookups on third level domains unlikely to have 
MX entries (www.cox.com) return the A record right away, then timeout on 
the MX entry.  AFAIK this is fairly new behavior, apparently quite 
coincident with my installation of glibc-2.9 (_p20081201_r1, currently), 
as IIRC, it formerly returned fine, without waiting for the timeout.

dig -tMX has the same behavior, while a simple dig (A record only) does 
not.

I stumbled across this while investigating after someone (running another 
distribution, no local DNS server) on the local Cox Unix newsgroup 
complained about the response time to www.cox.com.  We traced it down to 
long resolve times and checking them I noted this issue.  I initially 
chalked it up to DNS weirdness on their part and that may indeed be part 
or all of it, but reading this, it sure looks coincidentally similar and 
the timing seems right, at least here (I've no idea what his glibc 
version is or whether he's running netfilter based firewalls either on 
his machine or router, I asked, but don't have a reply yet).

I have not noted any particular delays other than with host/dig -tMX 
myself, but I suspect that may be because I'm running a local bind and it 
mitigates the issue under normal operating conditions.

As I said, it's enough above my head to have no real idea whether this is 
connected or not, but it sure seems coincidental if not.  I'm posting 
because it seems it might help answer the "Does this affect actual 
userspace behavior?" bit.

I can't help feeling a bit uncomfortable with the discussion here as it's 
too much like a normally discouraged bug discussion on the main dev 
list.  So if people want to take the discussion to a bug, post the bug 
link and I'll be happy to CC myself. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Tobias Klausmann]

Hi! 

On Wed, 28 Jan 2009, Mike Frysinger wrote:
> > On the wire between the client and the firewall, this happens:
> >
> > a packet 1 is sent
> > b packet 2 is sent
> > c answer 1 is received
> > d answer 2 is received
> >
> > Sometimes d doesn't happen because b is lost in the firewall
> > along the way (where the race condition happens).
> 
> does this affect actual userspace behavior ?  in other words,
> does this lead to lost lookups and errors from the resolver ?

The most visible effect (and the way we found out about it first)
is a 5s hang on ssh connects. Thing is: how long that timeout is
is program dependant (whatever they use in select()). A recvfrom() 
simply hangs. I wrote a simple C program to do what glibc does
(simplified for brevity):

sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_IP);
connect(sockfd, tgt->ai_addr, tgt->ai_addrlen);
sendto(sockfd, payload1, sizeof(payload1), 0, tgt->ai_addr, tgt->ai_addrlen); 
sendto(sockfd, payload2, sizeof(payload2), 0, tgt->ai_addr, tgt->ai_addrlen); 
recvfrom(sockfd, buf, sizeof(buf), 0, &addr, &fromlen);
recvfrom(sockfd, buf, sizeof(buf), 0, &addr, &fromlen);

payload1 and 2 are an A and a AAAA request for the same name,
respectively. That second recvfrom() hangs indefinitely in the
error case. Here's the full program for those interested:

http://eric.schwarzvogel.de/~klausman/dnstest2.c.txt

It'd be easy to put in a call to select and make the program
timeout as glibc does instead of simply hanging. Note that for an
actual test in your environment, you'll probably have to change
the payloads and line 44.

Here's the tcpdump of the error case:
09:42:53.614905 IP 192.168.0.2.39355 > 192.168.22.9.53: 64583+[|domain]
09:42:53.614920 IP 192.168.0.2.39355 > 192.168.22.9.53: 61812+[|domain]
09:42:53.615623 IP 192.168.22.9.53 > 192.168.0.2.39355: 64583[|domain]

Or, if you prefer tshark:

0.000000 192.168.0.2 -> 192.168.22.9  DNS Standard query A eric.schwarzvogel.de
0.000015 192.168.0.2 -> 192.168.22.9  DNS Standard query AAAA eric.schwarzvogel.de
0.000667  192.168.22.9 -> 192.168.0.2 DNS Standard query response A 194.97.4.250

As you can see, timing on the two queries is very close. glibc
usually is in the 20-50 microsecond range on this machine, my
little program can get as low as 5 microseconds. "Correct" timing
of course depends on a myriad of variables including load on the
packetfilter, kernel version there etc etc.

A "quickfix" would indeed be using two different ports for the
queries - but the bug in Netfilter would still be there.

Regards,
Tobias

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Thursday 29 January 2009 03:47:48 Tobias Klausmann wrote:
> Hi!
>
> On Wed, 28 Jan 2009, Mike Frysinger wrote:
> > > On the wire between the client and the firewall, this happens:
> > >
> > > a packet 1 is sent
> > > b packet 2 is sent
> > > c answer 1 is received
> > > d answer 2 is received
> > >
> > > Sometimes d doesn't happen because b is lost in the firewall
> > > along the way (where the race condition happens).
> >
> > does this affect actual userspace behavior ?  in other words,
> > does this lead to lost lookups and errors from the resolver ?
>
> The most visible effect (and the way we found out about it first)
> is a 5s hang on ssh connects.

this is why i turn off dns lookup in all my sshd_config's (well, not because 
of this bug, but because DNS lookup on ssh can cause annoying delays).  plus, 
that info is largely useless: for the logged attempts from "bad" people, the 
dns is usually screwed up / wrong / unavailable anyways.

> Thing is: how long that timeout is
> is program dependant (whatever they use in select()). A recvfrom()
> simply hangs. I wrote a simple C program to do what glibc does
> (simplified for brevity):
> ...

so glibc will not trigger hangs, just delays in some cases.

> A "quickfix" would indeed be using two different ports for the
> queries - but the bug in Netfilter would still be there.

sure, the bug still exists in netfilter (kernel).  but if we can easily 
mitigate the effects seen by applications using glibc's resolver code, that 
seems sane to me.  i havent perused the glibc resolver code in a while ... do 
you know if it can easily be tweaked to use different ports, or would such a 
change be invasive ?  if the latter, well i guess we'll have to suck it up.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Tobias Klausmann]

Hi! 

On Thu, 29 Jan 2009, Mike Frysinger wrote:
> > The most visible effect (and the way we found out about it
> > first) is a 5s hang on ssh connects.
> 
> this is why i turn off dns lookup in all my sshd_config's
> (well, not because of this bug, but because DNS lookup on ssh
> can cause annoying delays).  plus, that info is largely
> useless: for the logged attempts from "bad" people, the dns is
> usually screwed up / wrong / unavailable anyways.

It's not on the daemon side but the client side. If you don't
want to remember the IPs of all the hosts you might want to ssh
into (at close to 3000, I don't), the client will have to make
DNS lookups. Those are what delays the connection.

> > Thing is: how long that timeout is is program dependant
> > (whatever they use in select()). A recvfrom() simply hangs. I
> > wrote a simple C program to do what glibc does (simplified
> > for brevity): ...
> 
> so glibc will not trigger hangs, just delays in some cases.

Yup. Still: write a wrapper around ssh that will delay connects
by five seconds on 50% of the cases. Use it for two or more weeks
at work. That's how annoying it really is.

> > A "quickfix" would indeed be using two different ports for the
> > queries - but the bug in Netfilter would still be there.
> 
> sure, the bug still exists in netfilter (kernel).  but if we
> can easily mitigate the effects seen by applications using
> glibc's resolver code, that seems sane to me.  i havent perused
> the glibc resolver code in a while ... do you know if it can
> easily be tweaked to use different ports, or would such a
> change be invasive ?  if the latter, well i guess we'll have to
> suck it up.

I tried understanding what glibc 2.9 does regarding dns lookups,
but since it involves a rather complex (and probably quite
clever) queueing mechanism, I'm not quite sure I wouldn't break
more than I fix in doing so.

Regards,
Tobias

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Tobias Klausmann]

Hi! 

On Thu, 29 Jan 2009, Tobias Klausmann wrote:
> I tried understanding what glibc 2.9 does regarding dns lookups,
> but since it involves a rather complex (and probably quite
> clever) queueing mechanism, I'm not quite sure I wouldn't break
> more than I fix in doing so.

Apparently, it's enough to not export gethostbyname4() to fix
this.

I'll try building a glibc-2.9_p20081201-r1 plus this patch:
http://pasky.or.cz/~pasky/dev/glibc/glibc-2.10-dns-no-gethostbyname4.diff

If it works, I'll test drive it for a while and report back.

Regards,
Tobias

-- 
        if(ct<0)
                ct=2;        /* Shit happens.. */
        linux-2.6.6/drivers/net/wan/z85230.c

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Tobias Klausmann]

Hi! 

On Mon, 02 Feb 2009, Tobias Klausmann wrote:
> If it works, I'll test drive it for a while and report back.

I've been running a patched glibc-2.9_p20081201-r1 for a week
now. Nothing broke and I've been unable to trigger the lost
packet syndrome by using getaddrinfo(). I was still able to
produce it by sending UDP packets myself, but that was to be
expected.

So in essence, the patch I mentioned "works". We could use it
should we want to have a glibc 2.9. On the bug mentioned earlier
(where I got the patch from), one of the glibc guys mentions that
more work is planned for the resolver part of glibc, so this
whole ordeal may pass us.

Regards,
Tobias

-- 
printk("NONONONOO!!!!\n");
        linux-2.6.6/drivers/atm/zatm.c

Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9

[Mike Frysinger]

On Monday 09 February 2009 04:33:54 Tobias Klausmann wrote:
> On Mon, 02 Feb 2009, Tobias Klausmann wrote:
> > If it works, I'll test drive it for a while and report back.
>
> I've been running a patched glibc-2.9_p20081201-r1 for a week
> now. Nothing broke and I've been unable to trigger the lost
> packet syndrome by using getaddrinfo(). I was still able to
> produce it by sending UDP packets myself, but that was to be
> expected.
>
> So in essence, the patch I mentioned "works". We could use it
> should we want to have a glibc 2.9. On the bug mentioned earlier
> (where I got the patch from), one of the glibc guys mentions that
> more work is planned for the resolver part of glibc, so this
> whole ordeal may pass us.

that patch is already in the glibc patchset, i just havent released it yet.  
guess i could do that this weekend.
-mike

[gentoo-dev]

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 12 bytes --]

unsubscribe

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev]

[Jérémie Klein]

www.medicationsshop.refytopls.com

[gentoo-dev]

[ragavender rao]

I had been working in python codes past two years from the third year
of my college. I want to know what are the steps that has to be taken
for changing the code in the CVS and how to commit.though I had
browsed regarding this am not able to get clear picture kindly send me
any link or details reg this.
           thanks

[gentoo-dev]

[James Ausmus]

http://vanelura.t35.com/

[gentoo-dev]

[Shalom Ben-Zvi]

[gentoo-dev]

[teravice]

When everything else fails, read the instructions...

[gentoo-dev]

[Paige Thompson]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

There's a bunch of hype about ubuntu for the power 8 (new power 8 Tyan boards which apparently exist but i cant find them anywhere.) I thought gentoo always had a power fork anyway, not sure what the big deal is. I really wish i could find a board and cpu though.

 They need to release some for sale soon as in like now.
-- 
Sent from my Android device with K-9 Mail.

[-- Attachment #2: Type: text/html, Size: 388 bytes --]

[gentoo-dev]

[Pacho Ramos]

Hi!

We found out that pulseaudio ebuild was modified by QA without QA
talking to the maintainers (gnome team) and without considering/updating
the relevant bugzilla issue at
https://bugs.gentoo.org/show_bug.cgi?id=519530

In that link it's explained a bit more why the ebuild was written in
that way and the problems we try to avoid. We have then hardmasked that
version until it's discussed THERE how to handle that situations.

And would really appreciate that next time we are even notified about a
change is going to be committed and don't need to see it in
packages.gentoo.org (well, in my case I am not all the time on IRC...
but I read the mail often and, also, Gilles and Leio can also be
contacted on IRC. You can also simply send a mail to the alias and give
us at least some days of timeout).

Thanks a lot

Re: [gentoo-dev]

[Anthony G. Basile]

On 12/05/14 05:59, Pacho Ramos wrote:
> Hi!
>
> We found out that pulseaudio ebuild was modified by QA without QA
> talking to the maintainers (gnome team) and without considering/updating
> the relevant bugzilla issue at
> https://bugs.gentoo.org/show_bug.cgi?id=519530
>
> In that link it's explained a bit more why the ebuild was written in
> that way and the problems we try to avoid. We have then hardmasked that
> version until it's discussed THERE how to handle that situations.
>
> And would really appreciate that next time we are even notified about a
> change is going to be committed and don't need to see it in
> packages.gentoo.org (well, in my case I am not all the time on IRC...
> but I read the mail often and, also, Gilles and Leio can also be
> contacted on IRC. You can also simply send a mail to the alias and give
> us at least some days of timeout).
>
> Thanks a lot
>
>

I don't know the policy (I will read the relevant docs later) but its 
seems to me to make good sense that, if it is not an emergency (ie the 
tree is broken), that QA first inform the maintainer in a bug report 
which can then be peer reviewed.  QA can make mistakes (as in this case) 
and that's okay if there is discussion.  If it is an emergency, then I 
would think QA should take the action of least interference to unbreak 
the tree.

Bikeshed time ...

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev]

[fredrik]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 251 bytes --]

[gentoo-dev]

[fredrik]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]




[-- Attachment #2: Type: text/html, Size: 381 bytes --]

[gentoo-dev]

[Fredrik Frodlund]

[gentoo-dev]

[Mike Kaliman]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 23 bytes --]

[gentoo-dev]

[Marek Szuba]

With many thanks to ulm for having pointed this out. Not that while this
patch does indeed change the eclass behaviour for the established EAPI 7
rather than for the new EAPI 8, it does so in a way I deem non-intrusive
enough to allow this - the only case where something is actually removed
from DEPEND is when Fortran is only required by tests. Not to mention
that, ahem, there is considerable room for improvement as far as the
uptake of EAPI 7+ among consumers of this eclass is concerned.