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

[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.