Re: [gentoo-user] -march=? for this cpu

[Michael Hampicke]

Am 09.04.2013 05:50, schrieb Nilesh Govindrajan:
> I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm
> /proc/cpuinfo = true).
> 
> But something funny, gcc -march=native -mtune=native -v -E - 2>&1
>  
> Using built-in specs.
> COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with:
> /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure
> --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3
> --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
> --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3
> --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man
> --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info
> --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
> --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
> --disable-fixed-point --without-ppl --without-cloog --enable-lto
> --enable-nls --without-included-gettext --with-system-zlib
> --enable-obsolete --disable-werror --enable-secureplt --enable-multilib
> --enable-libmudflap --disable-libssp --enable-libgomp
> --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python
> --enable-checking=release --disable-libgcj --enable-libstdcxx-time
> --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
> --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
> --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3
> p1.11, pie-0.5.2'
> Thread model: posix
> gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
> COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
>  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v -
> -march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt
> -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx
> -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param
> l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic
> ignoring nonexistent directory "/usr/local/include"
> ignoring nonexistent directory
> "/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"
> 
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
>  /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
>  /usr/include
> End of search list.
> # 1 ""
> :1:0: error: CPU you selected does not support x86-64 instruction
> set
> 
> It is returning pentium-m as architecture, which indeed is 32bit. I'm
> presently running the VM with -march=core2, but this is very weird.
> 
> This is the /proc/cpuinfo:
> 
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 2
> model name  : QEMU Virtual CPU version 1.0
> stepping: 3
> microcode   : 0x1
> cpu MHz : 3399.998
> cache size  : 4096 KB
> fpu : yes
> fpu_exception   : yes
> cpuid level : 4
> wp  : yes
> flags   : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx
> cx16 popcnt hypervisor lahf_lm
> bogomips: 6799.99
> clflush size: 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> 
> Any idea what should be the march/mtune value?
> 

I don't have any experience with Hetzner's VMs - I only use their
dedicated machines :)

But as a more generic tip, you should install gentoo in VMs only with
generic optimization. You can not safely rely on what CPU your VM will
get. Maybe in 6 months the host your vm is on crashes, and your vm will
be migrated to a new system with totally different cpu (actual hardware
cpu or the cpu configuration that qemu is going to emulate).

Re: [gentoo-user] -march=? for this cpu

[Walter Dnes]

On Tue, Apr 09, 2013 at 09:20:00AM +0530, Nilesh Govindrajan wrote
> I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm 
> /proc/cpuinfo = true).

  Is "Hetzner" a remote hosting service?  If so, ignore what I say
below, and ask them if their VMs support 64 bits.  The part below is
applicable only if you built the VMs.


> End of search list.
> # 1 ""
> :1:0: error: CPU you selected does not support x86-64 instruction set
> 
> It is returning pentium-m as architecture, which indeed is 32bit. I'm 
> presently running the VM with -march=core2, but this is very weird.

  Is it possible that you built the qemu (or whatever) VM with only 32
bit support?  Assuming you're using qemu, what is the output of...

emerge -pv qemu

If you're using a different VM, list the "emerge -pv" output for it.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-user] -march=? for this cpu

[Nilesh Govindrajan]

I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm 
/proc/cpuinfo = true).


But something funny, gcc -march=native -mtune=native -v -E - 2>&1 


Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: 
/var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure 
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include 
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man 
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info 
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec 
--disable-fixed-point --without-ppl --without-cloog --enable-lto 
--enable-nls --without-included-gettext --with-system-zlib 
--enable-obsolete --disable-werror --enable-secureplt --enable-multilib 
--enable-libmudflap --disable-libssp --enable-libgomp 
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python 
--enable-checking=release --disable-libgcj --enable-libstdcxx-time 
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all 
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 
p1.11, pie-0.5.2'

Thread model: posix
gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - 
-march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt 
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx 
-mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param 
l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic

ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory 
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include"

#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed
 /usr/include
End of search list.
# 1 ""
:1:0: error: CPU you selected does not support x86-64 instruction set

It is returning pentium-m as architecture, which indeed is 32bit. I'm 
presently running the VM with -march=core2, but this is very weird.


This is the /proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 2
model name  : QEMU Virtual CPU version 1.0
stepping: 3
microcode   : 0x1
cpu MHz : 3399.998
cache size  : 4096 KB
fpu : yes
fpu_exception   : yes
cpuid level : 4
wp  : yes
flags   : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx 
cx16 popcnt hypervisor lahf_lm

bogomips: 6799.99
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Any idea what should be the march/mtune value?

--
Nilesh Govindarajan
http://nileshgr.com



smime.p7s
Description: S/MIME Cryptographic Signature

[gentoo-user] Rant/Warning: fun with awesome and lightdm

[Marc Joliet]

Hi list

[ Writing this to a) vent frustration and (spoiler alert ;-) ) b) warn about a
  strange change in x11-wm/awesome (from upstream or Gentoo, I don't know). ]

Well, I just finished debugging an issue that cropped up around mid-march that
I didn't have time to track down properly, mostly because the logs just didn't
reveal anything other than that lightdm-gtk-greeter stopped (well, syslog
correctly says "segfault", but the lightdm log says "quit" (why "quit"?!),
fantastic).

Anyway, the problem was that after some upgrade lightdm-gtk-greeter would
SEGFAULT when starting, so I couldn't log in using lightdm. I could still use
startx though, so it wasn't of immediate importance.

First I thought:

  "Well, it can't be lightdm or lightdm-gtk-greeter, because I upgraded
  those before the last kernel update, so they definitely worked fine before,
  and the upgrade to awesome can't influence lightdm-gtk-greeter, because that's
  started afterwards."

So I went through the packages I upgraded and tried selectively downgrading the
recent upgrades that were also dependencies of lightdm or lightdm-gtk-greeter
(e.g., gettext), but no luck. Google also didn't help, the most interesting
results were things like when the user of the last saved session is deleted
from the system, then lightdm-gtk-greeter would SEGFAULT (unless you pressed
the arrow keys to go down the user list). Fun stuff like that. ( I tried that,
BTW, and it didn't work.)

Several weeks pass, then today I decided to rebuild various things in the hope
that it was a hidden ABI issue or something, but really I was just unthinkingly
flailing around hoping to catch something.

Well, after that I finally tracked it down. I finally tried downgrading to
lightdm-gtk-greeter-1.1.6 (again, it was running fine before so I didn't expect
it to be the problem) and noticed that the "awesome" session was missing from
the dropdown list. So I think "Well, let's find the file responsible for
that.", and the problem was... *drumroll* the awesome upgrade, after all. WTF!?

Well, said upgrade apparently brought a change to the xsession desktop file
located at /usr/share/xsessions/awesome.desktop, namely:

  [Desktop Entry]
  Encoding=UTF-8
  Name=awesome
  Comment=Highly configurable framework window manager
  NoDisplay=true
 this should be false!
  TryExec=awesome
  Exec=awesome
  Type=Application

So because of that, lightdm-gtk-greeter ignored the awesome.desktop xsession
file, resulting in it trying to load the last session which referenced the now
invalid "awesome" session. Then, instead of displaying the next available item,
lightdm-gtk-greeter decided to SEGFAULT instead. Hooray! SEGFAULTs for
EVERYONE! (Of course, why lightdm-gtk-greeter-1.1.6 worked is beyond me, a
regression in 1.3.1 maybe?)

Ahem.

Anyway, changing that line to "NoDisplay=false" fixed things for me and I was
able to upgrade back to lightdm-gtk-greeter-1.3.1-r1.

And instead of going to bed I'm venting in this email. I'll probably sleep
better for it, though (I hope).

But I can't help noticing that of course for *me* the udev-200 update goes just
fine and dandy, the new names I chose (wan0 and lan0) make more sense anyway,
but then a *window manager* upgrade manages to fsck things up in a hard to
track down way!? Just my luck.

So now I get to file a bug and ask why the hell that change was made and by
whom (oh, and I couldn't find related bugs for either lightdm or awesome on
b.g.o). Maybe somebody here knows. But first I'm going to bed (much too late,
BTW).

Weary of travelling rough terrain and in need of rest,
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Mon, Apr 08, 2013 at 11:11:08PM +0100, Neil Bothwick wrote:
> On Mon, 8 Apr 2013 11:20:57 -0500, Bruce Hill wrote:
> 
> > You might not care, but I automatically hit D (delete) in Mutt for
> > every email that's top-posted. Just saying...
> 
> But not until after replying? :P

Well, if I see white text just after the header, it's an automatic D. ;)
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Eth0 interface not found - udev

[Neil Bothwick]

On Mon, 8 Apr 2013 12:12:30 -0600, Joseph wrote:

> If the boys with the servers, with more than two networks cards wants
> to have consistent naming they should have made it optional and not
> push this "new name crap" on everybody. 

It is optional - RTFN!


-- 
Neil Bothwick

Suicide is the most sincere form of self-criticism.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Neil Bothwick]

On Mon, 8 Apr 2013 11:20:57 -0500, Bruce Hill wrote:

> You might not care, but I automatically hit D (delete) in Mutt for
> every email that's top-posted. Just saying...

But not until after replying? :P


-- 
Neil Bothwick

Are Cheerios really doughnut seeds?


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Mon, Apr 08, 2013 at 10:10:09PM +0200, Michael Hampicke wrote:
> > 
> > Hi Michael,
> > 
> > If you have the time, maybe you can post your GrUB setup and a short HOW-TO 
> > do
> > this somewhere. I've often mentioned doing it with LiLO in #gentoo on 
> > Freenode
> > and always get flamed by GrUB fanbois, but to date none has been able to
> > produce how to actually do it with GrUB. Since Gentoo now recommends GrUB
> > rather by default, it might be nice for folks to know how to use this.
> > 
> > Thanks,
> > Bruce
> > 
> 
> This actually is pretty straight forward :) Here's a small sample config
> for grub 0.97. But I'm pretty sure that this will work with grub2 too.
> 
> ### grub.conf ###
> 
> # set default boot entry to prev. saved state:
> default saved
> 
> # seq. order of boot entries
> fallback 1 2 3
> 
> # here are the kernels
> title gentoo 0
> kernel /kernel panic=15
> savedefault fallback
> 
> title gentoo 1
> kernel /kernel panic=15
> savedefault fallback
> 
> title gentoo 2
> kernel /kernel panic=15
> savedefault fallback
> 
> title gentoo 3
> kernel /kernel panic=15
> savedefault fallback
> 
> ### end grub.conf ###
> 
> what I now do is this: set the default boot entry to zero with
> % grub-set-default 0
> 
> On the next reboot this happens:
> 
> grub reads the default: 0
> 
> grub boots entry 0 and sets the default entry to 1 (or 2 according
> to the fallback line in grub.conf)
> 
> If the systems panics, it reboots. But this time grub will load entry 1
> as it is the default now (and so on, and so on).
> 
> If the systems booted successfully and you verified that it actually
> booted the new kernel, you now have to set grub default to 0 with
> grub-set-default.
> You can to this with a small script in /etc/local.d/local.start
> Maybe send the admin a warning that the system has not booted with the
> default kernel. That's up to you :)

Thanks Michael, nice work. I'm going to install Gentoo on some new hardware as
soon as I get some time ... a new HTPC box, hoping that XBMC works better than
the last time ... with probably XFCE as the DE. I'll install GrUB this time
just to learn this setup.

Bruce
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Hampicke]

Am 08.04.2013 21:56, schrieb Bruce Hill:
> On Mon, Apr 08, 2013 at 09:46:28PM +0200, Michael Hampicke wrote:
>>
>> I have something similar with grub (with grub set default, savedefault,
>> fallback). Also most machines have some sort of rescue access with like
>> ipmi serial over lan or a eric card (kvm). But some remote machines
>> don't and rebooting them is always a thrill :) I mean, there are rescue
>> systems that can be invoked via bootp, but you are blind while rebooting.
> 
> Hi Michael,
> 
> If you have the time, maybe you can post your GrUB setup and a short HOW-TO do
> this somewhere. I've often mentioned doing it with LiLO in #gentoo on Freenode
> and always get flamed by GrUB fanbois, but to date none has been able to
> produce how to actually do it with GrUB. Since Gentoo now recommends GrUB
> rather by default, it might be nice for folks to know how to use this.
> 
> Thanks,
> Bruce
> 

This actually is pretty straight forward :) Here's a small sample config
for grub 0.97. But I'm pretty sure that this will work with grub2 too.

### grub.conf ###

# set default boot entry to prev. saved state:
default saved

# seq. order of boot entries
fallback 1 2 3

# here are the kernels
title gentoo 0
kernel /kernel panic=15
savedefault fallback

title gentoo 1
kernel /kernel panic=15
savedefault fallback

title gentoo 2
kernel /kernel panic=15
savedefault fallback

title gentoo 3
kernel /kernel panic=15
savedefault fallback

### end grub.conf ###

what I now do is this: set the default boot entry to zero with
% grub-set-default 0

On the next reboot this happens:

grub reads the default: 0

grub boots entry 0 and sets the default entry to 1 (or 2 according
to the fallback line in grub.conf)

If the systems panics, it reboots. But this time grub will load entry 1
as it is the default now (and so on, and so on).

If the systems booted successfully and you verified that it actually
booted the new kernel, you now have to set grub default to 0 with
grub-set-default.
You can to this with a small script in /etc/local.d/local.start
Maybe send the admin a warning that the system has not booted with the
default kernel. That's up to you :)

HTH

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Mon, Apr 08, 2013 at 09:46:28PM +0200, Michael Hampicke wrote:
> 
> I have something similar with grub (with grub set default, savedefault,
> fallback). Also most machines have some sort of rescue access with like
> ipmi serial over lan or a eric card (kvm). But some remote machines
> don't and rebooting them is always a thrill :) I mean, there are rescue
> systems that can be invoked via bootp, but you are blind while rebooting.

Hi Michael,

If you have the time, maybe you can post your GrUB setup and a short HOW-TO do
this somewhere. I've often mentioned doing it with LiLO in #gentoo on Freenode
and always get flamed by GrUB fanbois, but to date none has been able to
produce how to actually do it with GrUB. Since Gentoo now recommends GrUB
rather by default, it might be nice for folks to know how to use this.

Thanks,
Bruce
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Hampicke]

Am 08.04.2013 18:16, schrieb Bruce Hill:
> On Sun, Apr 07, 2013 at 07:42:23PM +0200, Michael Hampicke wrote:
>>
>> Mike is right, if it's not a dep of another ebuild, you don't need
>> wpa_supplicant. I just upgraded udev to 200 on the last remote box
>> (which is always a bit of a thrill after typing reboot  :-) ).
>> As expected, eth0 came up, everything works fine, wpa_supplicant is not
>> installed.
> 
> Don't know what you guys do for rebooting a headless server blindly like this,
> nor if it would work for the udev/NIC situation. But fwiw, what I've always
> done for new kernels is:
> 
> mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/lilo.conf
> compact
> lba32
> default = Gentoo-def
> boot = /dev/md0
> raid-extra-boot = mbr-only
> map = /boot/.map
> install = /boot/boot-menu.b   # Note that for lilo-22.5.5 or later you
>   # do not need boot-{text,menu,bmp}.b in
>   # /boot, as they are linked into the lilo
>   # binary.
> menu-scheme=Wb
> prompt
> timeout=50
> append="panic=10 nomce dolvm domdadm rootfstype=xfs"
> image = /boot/vmlinuz
> root = /dev/md0
> label = Gentoo
> read-only  # Partitions should be mounted read-only for checking
> image = /boot/vmlinuz.old
> root = /dev/md0
> label = Gentoo-def
> read-only  # Partitions should be mounted read-only for checking
> 
> Then issue "lilo -R Gentoo" or whatever the label of your new kernel, and if
> it boots, you're okay. If not, after 10 seconds of panic, it automatically
> reboots back into the default kernel and you can check logs to see what you've
> broken. (panic=10 append statement and default = Gentoo-def) After you know
> the new kernel works, comment the default line. (NB: You can name them
> differently, etc. It just helps to know before you reboot that if you panic,
> the machine will boot back into the known, good, kernel.) 
> 
> Granted, this might not help with the udev/NIC situation, but it's saved me
> from a few PEBKAC situations, as well as new kernel changes I'd not learned
> until the reboot.
> 

I have something similar with grub (with grub set default, savedefault,
fallback). Also most machines have some sort of rescue access with like
ipmi serial over lan or a eric card (kvm). But some remote machines
don't and rebooting them is always a thrill :) I mean, there are rescue
systems that can be invoked via bootp, but you are blind while rebooting.

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

On Mon, Apr 8, 2013 at 1:53 PM, Canek Peláez Valdés wrote:

> On Mon, Apr 8, 2013 at 1:35 PM, Andrew Hoffman 
> wrote:
> >
> >
> >
> > On Mon, Apr 8, 2013 at 1:30 PM, Canek Peláez Valdés 
> > wrote:
> >>
> >> On Mon, Apr 8, 2013 at 1:10 PM, Andrew Hoffman <
> andy.hoffma...@gmail.com>
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Apr 8, 2013 at 1:02 PM, Canek Peláez Valdés  >
> >> > wrote:
> >> >>
> >> >> On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
> >> >>  wrote:
> >> >> > Canek,
> >> >> > I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
> >> >> >
> >> >> > lapy lib # locate telepathy-glib.pc
> >> >> > /usr/lib/pkgconfig/telepathy-glib.pc
> >> >> > lapy lib # locate dbus-glib-1.pc
> >> >> > /usr/lib/pkgconfig/dbus-glib-1.pc
> >> >> > lapy lib # locate gio-2.0.pc
> >> >> > /usr/lib/pkgconfig/gio-2.0.pc
> >> >> > lapy lib # locate gee-1.0.pc
> >> >> > /usr/lib/pkgconfig/gee-1.0.pc
> >> >> >
> >> >> > How would I tell if they are damaged if that is indeed the case?
> >> >>
> >> >> Don't top-post, please. Sorry, I messed up the files; you don't need
> >> >> the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
> >> >> need:
> >> >>
> >> >> /usr/share/vala/vapi/telepathy-glib.vapi
> >> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> >> >> /usr/share/vala-0.18/vapi/gio-2.0.vapi
> >> >> /usr/share/vala/vapi/gee-1.0.vapi
> >> >>
> >> >> Depending on how many Vala compiler versions you have, you can have
> >> >> several of the second and the third; for example I have:
> >> >>
> >> >> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
> >> >> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
> >> >> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
> >> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> >> >> /usr/share/vala-0.20/vapi/dbus-glib-1.vapi
> >> >>
> >> >> Check if you have the four vapi files, and that the ones for
> >> >> dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
> >> >> compiler.
> >> >>
> >> >> Regards.
> >> >> --
> >> >> Canek Peláez Valdés
> >> >> Posgrado en Ciencia e Ingeniería de la Computación
> >> >> Universidad Nacional Autónoma de México
> >> >>
> >> >
> >> > Guess gmail defaults to top post so its what I use:/
> >> >
> >> > Anyhow I have these files:
> >> >
> >> > lapy lib # locate telepathy-glib.vapi
> >> > /usr/share/vala/vapi/telepathy-glib.vapi
> >> > lapy lib # locate dbus-glib-1.vapi
> >> > /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
> >> > /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
> >> > /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
> >> > /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> >> > lapy lib # locate gio-2.0.vapi
> >> > /usr/share/vala-0.12/vapi/gio-2.0.vapi
> >> > /usr/share/vala-0.14/vapi/gio-2.0.vapi
> >> > /usr/share/vala-0.16/vapi/gio-2.0.vapi
> >> > /usr/share/vala-0.18/vapi/gio-2.0.vapi
> >> > lapy lib # locate gee-1.0.vapi
> >> > /usr/share/vala/vapi/gee-1.0.vapi
> >>
> >> I see the error now. The problem is that the class GLib.Bytes is
> >> defined in glib-2.0.vapi for valac 0.16, 0.18 and 0.20, but not for
> >> valac 0.12 nor 0.14. The latest version of telepahy-glib uses
> >> GLib.Bytes, so it dependencies need to be compiled with a newer
> >> version of valac.
> >>
> >> Can you try to emerge folks as follows:
> >>
> >> VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
> >>
> >> If that fails, what version of telepathy-glib do you have installed?
> >>
> >> Regards.
> >> --
> >> Canek Peláez Valdés
> >> Posgrado en Ciencia e Ingeniería de la Computación
> >> Universidad Nacional Autónoma de México
> >>
> >
> > that did fail:
> >
> > lapy portage # VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
> > Calculating dependencies... done!
> >
>  Verifying ebuild manifests
> >
>  Emerging (1 of 1) dev-libs/folks-0.4.3
> >  * folks-0.4.3.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...
> > [ ok ]
>  Unpacking source...
>  Unpacking folks-0.4.3.tar.bz2 to
>  /var/tmp/portage/dev-libs/folks-0.4.3/work
>  Source unpacked in /var/tmp/portage/dev-libs/folks-0.4.3/work
>  Preparing source in
>  /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
> >  * Fixing OMF Makefiles ...
> > [ ok ]
> >  * Disabling deprecation warnings ...
> > [ ok ]
> >  * Running elibtoolize in: folks-0.4.3/
> >  *   Applying portage/1.2.0 patch ...
> >  *   Applying sed/1.5.6 patch ...
> >  *   Applying as-needed/2.2.6 patch ...
>  Source prepared.
>  Configuring source in
>  /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
> > (removed)
> > checking pkg-config is at least version 0.21... yes
> > checking for GLIB... yes
> > checking for GMODULE... yes
> > checking for GIO... yes
> > checking for DBUS_GLIB... yes
> > checking for GEE... yes
> > checking for TP_GLIB... yes
> > checking for valac... /usr/bin/valac-0.12
> > checking /usr/bin/valac-0.12 is at least version 0.11.6... yes
> > checking for vapigen... /usr/bin/vapigen-0.12
> > checking for  telepathy-glib dbus-glib-1 gio-2.0 gee-1.0 vala bindings...
> > c

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sat, Apr 06, 2013 at 09:40:41PM -0400, Michael Mol wrote:
> 
> /sbin/ip link addr show
> 
> That will tell you the names of your interfaces, as they currently exist.

FWIW that command should be "ip addr show" rather than "ip link addr show",
and no need for full path in later versions (forgetting which version changed
this behavior).
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Canek Peláez Valdés]

On Mon, Apr 8, 2013 at 1:35 PM, Andrew Hoffman  wrote:
>
>
>
> On Mon, Apr 8, 2013 at 1:30 PM, Canek Peláez Valdés 
> wrote:
>>
>> On Mon, Apr 8, 2013 at 1:10 PM, Andrew Hoffman 
>> wrote:
>> >
>> >
>> >
>> > On Mon, Apr 8, 2013 at 1:02 PM, Canek Peláez Valdés 
>> > wrote:
>> >>
>> >> On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
>> >>  wrote:
>> >> > Canek,
>> >> > I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
>> >> >
>> >> > lapy lib # locate telepathy-glib.pc
>> >> > /usr/lib/pkgconfig/telepathy-glib.pc
>> >> > lapy lib # locate dbus-glib-1.pc
>> >> > /usr/lib/pkgconfig/dbus-glib-1.pc
>> >> > lapy lib # locate gio-2.0.pc
>> >> > /usr/lib/pkgconfig/gio-2.0.pc
>> >> > lapy lib # locate gee-1.0.pc
>> >> > /usr/lib/pkgconfig/gee-1.0.pc
>> >> >
>> >> > How would I tell if they are damaged if that is indeed the case?
>> >>
>> >> Don't top-post, please. Sorry, I messed up the files; you don't need
>> >> the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
>> >> need:
>> >>
>> >> /usr/share/vala/vapi/telepathy-glib.vapi
>> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.18/vapi/gio-2.0.vapi
>> >> /usr/share/vala/vapi/gee-1.0.vapi
>> >>
>> >> Depending on how many Vala compiler versions you have, you can have
>> >> several of the second and the third; for example I have:
>> >>
>> >> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.20/vapi/dbus-glib-1.vapi
>> >>
>> >> Check if you have the four vapi files, and that the ones for
>> >> dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
>> >> compiler.
>> >>
>> >> Regards.
>> >> --
>> >> Canek Peláez Valdés
>> >> Posgrado en Ciencia e Ingeniería de la Computación
>> >> Universidad Nacional Autónoma de México
>> >>
>> >
>> > Guess gmail defaults to top post so its what I use:/
>> >
>> > Anyhow I have these files:
>> >
>> > lapy lib # locate telepathy-glib.vapi
>> > /usr/share/vala/vapi/telepathy-glib.vapi
>> > lapy lib # locate dbus-glib-1.vapi
>> > /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
>> > /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
>> > /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
>> > /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> > lapy lib # locate gio-2.0.vapi
>> > /usr/share/vala-0.12/vapi/gio-2.0.vapi
>> > /usr/share/vala-0.14/vapi/gio-2.0.vapi
>> > /usr/share/vala-0.16/vapi/gio-2.0.vapi
>> > /usr/share/vala-0.18/vapi/gio-2.0.vapi
>> > lapy lib # locate gee-1.0.vapi
>> > /usr/share/vala/vapi/gee-1.0.vapi
>>
>> I see the error now. The problem is that the class GLib.Bytes is
>> defined in glib-2.0.vapi for valac 0.16, 0.18 and 0.20, but not for
>> valac 0.12 nor 0.14. The latest version of telepahy-glib uses
>> GLib.Bytes, so it dependencies need to be compiled with a newer
>> version of valac.
>>
>> Can you try to emerge folks as follows:
>>
>> VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
>>
>> If that fails, what version of telepathy-glib do you have installed?
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> that did fail:
>
> lapy portage # VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
> Calculating dependencies... done!
>
 Verifying ebuild manifests
>
 Emerging (1 of 1) dev-libs/folks-0.4.3
>  * folks-0.4.3.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...
> [ ok ]
 Unpacking source...
 Unpacking folks-0.4.3.tar.bz2 to
 /var/tmp/portage/dev-libs/folks-0.4.3/work
 Source unpacked in /var/tmp/portage/dev-libs/folks-0.4.3/work
 Preparing source in
 /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
>  * Fixing OMF Makefiles ...
> [ ok ]
>  * Disabling deprecation warnings ...
> [ ok ]
>  * Running elibtoolize in: folks-0.4.3/
>  *   Applying portage/1.2.0 patch ...
>  *   Applying sed/1.5.6 patch ...
>  *   Applying as-needed/2.2.6 patch ...
 Source prepared.
 Configuring source in
 /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
> (removed)
> checking pkg-config is at least version 0.21... yes
> checking for GLIB... yes
> checking for GMODULE... yes
> checking for GIO... yes
> checking for DBUS_GLIB... yes
> checking for GEE... yes
> checking for TP_GLIB... yes
> checking for valac... /usr/bin/valac-0.12
> checking /usr/bin/valac-0.12 is at least version 0.11.6... yes
> checking for vapigen... /usr/bin/vapigen-0.12
> checking for  telepathy-glib dbus-glib-1 gio-2.0 gee-1.0 vala bindings...
> configure: error: Package requirements were not met: telepathy-glib
>  dbus-glib-1
>  gio-2.0
>  gee-1.0
>
> warning: D-Bus GLib is deprecated, use GDBus
> telepathy-glib.vapi:1326.36-1326.45: error: The type name `GLib.Bytes' could
> not be found
>
> Consider adjusting the XDG_DATA_DI

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

On Mon, Apr 8, 2013 at 1:35 PM, Andrew Hoffman wrote:

>
>
>
> On Mon, Apr 8, 2013 at 1:30 PM, Canek Peláez Valdés wrote:
>
>> On Mon, Apr 8, 2013 at 1:10 PM, Andrew Hoffman 
>> wrote:
>> >
>> >
>> >
>> > On Mon, Apr 8, 2013 at 1:02 PM, Canek Peláez Valdés 
>> > wrote:
>> >>
>> >> On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
>> >>  wrote:
>> >> > Canek,
>> >> > I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
>> >> >
>> >> > lapy lib # locate telepathy-glib.pc
>> >> > /usr/lib/pkgconfig/telepathy-glib.pc
>> >> > lapy lib # locate dbus-glib-1.pc
>> >> > /usr/lib/pkgconfig/dbus-glib-1.pc
>> >> > lapy lib # locate gio-2.0.pc
>> >> > /usr/lib/pkgconfig/gio-2.0.pc
>> >> > lapy lib # locate gee-1.0.pc
>> >> > /usr/lib/pkgconfig/gee-1.0.pc
>> >> >
>> >> > How would I tell if they are damaged if that is indeed the case?
>> >>
>> >> Don't top-post, please. Sorry, I messed up the files; you don't need
>> >> the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
>> >> need:
>> >>
>> >> /usr/share/vala/vapi/telepathy-glib.vapi
>> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.18/vapi/gio-2.0.vapi
>> >> /usr/share/vala/vapi/gee-1.0.vapi
>> >>
>> >> Depending on how many Vala compiler versions you have, you can have
>> >> several of the second and the third; for example I have:
>> >>
>> >> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> >> /usr/share/vala-0.20/vapi/dbus-glib-1.vapi
>> >>
>> >> Check if you have the four vapi files, and that the ones for
>> >> dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
>> >> compiler.
>> >>
>> >> Regards.
>> >> --
>> >> Canek Peláez Valdés
>> >> Posgrado en Ciencia e Ingeniería de la Computación
>> >> Universidad Nacional Autónoma de México
>> >>
>> >
>> > Guess gmail defaults to top post so its what I use:/
>> >
>> > Anyhow I have these files:
>> >
>> > lapy lib # locate telepathy-glib.vapi
>> > /usr/share/vala/vapi/telepathy-glib.vapi
>> > lapy lib # locate dbus-glib-1.vapi
>> > /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
>> > /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
>> > /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
>> > /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> > lapy lib # locate gio-2.0.vapi
>> > /usr/share/vala-0.12/vapi/gio-2.0.vapi
>> > /usr/share/vala-0.14/vapi/gio-2.0.vapi
>> > /usr/share/vala-0.16/vapi/gio-2.0.vapi
>> > /usr/share/vala-0.18/vapi/gio-2.0.vapi
>> > lapy lib # locate gee-1.0.vapi
>> > /usr/share/vala/vapi/gee-1.0.vapi
>>
>> I see the error now. The problem is that the class GLib.Bytes is
>> defined in glib-2.0.vapi for valac 0.16, 0.18 and 0.20, but not for
>> valac 0.12 nor 0.14. The latest version of telepahy-glib uses
>> GLib.Bytes, so it dependencies need to be compiled with a newer
>> version of valac.
>>
>> Can you try to emerge folks as follows:
>>
>> VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
>>
>> If that fails, what version of telepathy-glib do you have installed?
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>>
> that did fail:
>
> lapy portage # VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
> Calculating dependencies... done!
>
> >>> Verifying ebuild manifests
>
> >>> Emerging (1 of 1) dev-libs/folks-0.4.3
>  * folks-0.4.3.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...
> [ ok ]
> >>> Unpacking source...
> >>> Unpacking folks-0.4.3.tar.bz2 to
> /var/tmp/portage/dev-libs/folks-0.4.3/work
> >>> Source unpacked in /var/tmp/portage/dev-libs/folks-0.4.3/work
> >>> Preparing source in
> /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
>  * Fixing OMF Makefiles ...
> [ ok ]
>  * Disabling deprecation warnings ...
> [ ok ]
>  * Running elibtoolize in: folks-0.4.3/
>  *   Applying portage/1.2.0 patch ...
>  *   Applying sed/1.5.6 patch ...
>  *   Applying as-needed/2.2.6 patch ...
> >>> Source prepared.
> >>> Configuring source in
> /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
> (removed)
> checking pkg-config is at least version 0.21... yes
> checking for GLIB... yes
> checking for GMODULE... yes
> checking for GIO... yes
> checking for DBUS_GLIB... yes
> checking for GEE... yes
> checking for TP_GLIB... yes
> checking for valac... /usr/bin/valac-0.12
> checking /usr/bin/valac-0.12 is at least version 0.11.6... yes
> checking for vapigen... /usr/bin/vapigen-0.12
> checking for  telepathy-glib dbus-glib-1 gio-2.0 gee-1.0 vala bindings...
> configure: error: Package requirements were not met: telepathy-glib
>  dbus-glib-1
>  gio-2.0
>  gee-1.0
>
> warning: D-Bus GLib is deprecated, use GDBus
> telepathy-glib.vapi:1326.36-1326.45: error: The type name `GLib.Bytes'
> could not be found
>
> Co

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Randy Barlow]

On Sun, 2013-04-07 at 21:49 -0500, Andrew Hoffman wrote:

> I have been able to resolve many issues by re-emerging mesa and
> manualy listing the packages RR wants to emerge but i have now just
> Folks left failing to emerge.

I reported a bug about folks just last week:

https://bugs.gentoo.org/show_bug.cgi?id=464500

-- 
Randy Barlow

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Pandu Poluan]

On Apr 8, 2013 11:17 PM, "Bruce Hill" 
wrote:
>
> On Sun, Apr 07, 2013 at 07:42:23PM +0200, Michael Hampicke wrote:
> >
> > Mike is right, if it's not a dep of another ebuild, you don't need
> > wpa_supplicant. I just upgraded udev to 200 on the last remote box
> > (which is always a bit of a thrill after typing reboot  :-) ).
> > As expected, eth0 came up, everything works fine, wpa_supplicant is not
> > installed.
>
> Don't know what you guys do for rebooting a headless server blindly like
this,
> nor if it would work for the udev/NIC situation. But fwiw, what I've
always
> done for new kernels is:
>
> mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/lilo.conf
> compact
> lba32
> default = Gentoo-def
> boot = /dev/md0
> raid-extra-boot = mbr-only
> map = /boot/.map
> install = /boot/boot-menu.b   # Note that for lilo-22.5.5 or later you
>   # do not need boot-{text,menu,bmp}.b in
>   # /boot, as they are linked into the lilo
>   # binary.
> menu-scheme=Wb
> prompt
> timeout=50
> append="panic=10 nomce dolvm domdadm rootfstype=xfs"
> image = /boot/vmlinuz
> root = /dev/md0
> label = Gentoo
> read-only  # Partitions should be mounted read-only for checking
> image = /boot/vmlinuz.old
> root = /dev/md0
> label = Gentoo-def
> read-only  # Partitions should be mounted read-only for checking
>
> Then issue "lilo -R Gentoo" or whatever the label of your new kernel, and
if
> it boots, you're okay. If not, after 10 seconds of panic, it automatically
> reboots back into the default kernel and you can check logs to see what
you've
> broken. (panic=10 append statement and default = Gentoo-def) After you
know
> the new kernel works, comment the default line. (NB: You can name them
> differently, etc. It just helps to know before you reboot that if you
panic,
> the machine will boot back into the known, good, kernel.)
>
> Granted, this might not help with the udev/NIC situation, but it's saved
me
> from a few PEBKAC situations, as well as new kernel changes I'd not
learned
> until the reboot.

Personally, I always try to install *any* Linux server on top of Xen (in my
case, XenServer). That way, I got a remote "console" always.

Rgds,
--

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

On Mon, Apr 8, 2013 at 1:30 PM, Canek Peláez Valdés wrote:

> On Mon, Apr 8, 2013 at 1:10 PM, Andrew Hoffman 
> wrote:
> >
> >
> >
> > On Mon, Apr 8, 2013 at 1:02 PM, Canek Peláez Valdés 
> > wrote:
> >>
> >> On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
> >>  wrote:
> >> > Canek,
> >> > I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
> >> >
> >> > lapy lib # locate telepathy-glib.pc
> >> > /usr/lib/pkgconfig/telepathy-glib.pc
> >> > lapy lib # locate dbus-glib-1.pc
> >> > /usr/lib/pkgconfig/dbus-glib-1.pc
> >> > lapy lib # locate gio-2.0.pc
> >> > /usr/lib/pkgconfig/gio-2.0.pc
> >> > lapy lib # locate gee-1.0.pc
> >> > /usr/lib/pkgconfig/gee-1.0.pc
> >> >
> >> > How would I tell if they are damaged if that is indeed the case?
> >>
> >> Don't top-post, please. Sorry, I messed up the files; you don't need
> >> the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
> >> need:
> >>
> >> /usr/share/vala/vapi/telepathy-glib.vapi
> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> >> /usr/share/vala-0.18/vapi/gio-2.0.vapi
> >> /usr/share/vala/vapi/gee-1.0.vapi
> >>
> >> Depending on how many Vala compiler versions you have, you can have
> >> several of the second and the third; for example I have:
> >>
> >> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
> >> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
> >> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
> >> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> >> /usr/share/vala-0.20/vapi/dbus-glib-1.vapi
> >>
> >> Check if you have the four vapi files, and that the ones for
> >> dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
> >> compiler.
> >>
> >> Regards.
> >> --
> >> Canek Peláez Valdés
> >> Posgrado en Ciencia e Ingeniería de la Computación
> >> Universidad Nacional Autónoma de México
> >>
> >
> > Guess gmail defaults to top post so its what I use:/
> >
> > Anyhow I have these files:
> >
> > lapy lib # locate telepathy-glib.vapi
> > /usr/share/vala/vapi/telepathy-glib.vapi
> > lapy lib # locate dbus-glib-1.vapi
> > /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
> > /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
> > /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
> > /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> > lapy lib # locate gio-2.0.vapi
> > /usr/share/vala-0.12/vapi/gio-2.0.vapi
> > /usr/share/vala-0.14/vapi/gio-2.0.vapi
> > /usr/share/vala-0.16/vapi/gio-2.0.vapi
> > /usr/share/vala-0.18/vapi/gio-2.0.vapi
> > lapy lib # locate gee-1.0.vapi
> > /usr/share/vala/vapi/gee-1.0.vapi
>
> I see the error now. The problem is that the class GLib.Bytes is
> defined in glib-2.0.vapi for valac 0.16, 0.18 and 0.20, but not for
> valac 0.12 nor 0.14. The latest version of telepahy-glib uses
> GLib.Bytes, so it dependencies need to be compiled with a newer
> version of valac.
>
> Can you try to emerge folks as follows:
>
> VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
>
> If that fails, what version of telepathy-glib do you have installed?
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>
>
that did fail:

lapy portage # VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-libs/folks-0.4.3
 * folks-0.4.3.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...
  [ ok ]
>>> Unpacking source...
>>> Unpacking folks-0.4.3.tar.bz2 to
/var/tmp/portage/dev-libs/folks-0.4.3/work
>>> Source unpacked in /var/tmp/portage/dev-libs/folks-0.4.3/work
>>> Preparing source in
/var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
 * Fixing OMF Makefiles ...
  [ ok ]
 * Disabling deprecation warnings ...
  [ ok ]
 * Running elibtoolize in: folks-0.4.3/
 *   Applying portage/1.2.0 patch ...
 *   Applying sed/1.5.6 patch ...
 *   Applying as-needed/2.2.6 patch ...
>>> Source prepared.
>>> Configuring source in
/var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3 ...
(removed)
checking pkg-config is at least version 0.21... yes
checking for GLIB... yes
checking for GMODULE... yes
checking for GIO... yes
checking for DBUS_GLIB... yes
checking for GEE... yes
checking for TP_GLIB... yes
checking for valac... /usr/bin/valac-0.12
checking /usr/bin/valac-0.12 is at least version 0.11.6... yes
checking for vapigen... /usr/bin/vapigen-0.12
checking for  telepathy-glib dbus-glib-1 gio-2.0 gee-1.0 vala bindings...
configure: error: Package requirements were not met: telepathy-glib
 dbus-glib-1
 gio-2.0
 gee-1.0

warning: D-Bus GLib is deprecated, use GDBus
telepathy-glib.vapi:1326.36-1326.45: error: The type name `GLib.Bytes'
could not be found

Consider adjusting the XDG_DATA_DIRS environment variable if you
installed bindings in a non-standard prefix.


!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/dev-libs/folks-0.4.3/work/folks-0.4.3/config.log
 * ERROR: dev-l

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Pandu Poluan]

On Apr 9, 2013 12:32 AM, "Jarry"  wrote:
>
> On 08-Apr-13 19:19, Michael Mol wrote:
>>
>> On 04/08/2013 12:28 PM, Bruce Hill wrote:
>>>
>>> On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:

 On Sat, 6 Apr 2013 22:35:22 -0400
 Nick Khamis  wrote:
>
> As for /sbin/ip. I have no such command.


 I'd recommend installing and becoming familiar with the iproute2
 package. I personally find the tools it delivers to be more intuitive
 than the older tools, and I *think* they are considered to obsolote
some
 tools, such as ifconfig.
>>>
>>>
>>> Ack to Randy's. FWIW: http://inai.de/2008/02/19
>>
>>
>> That page has a handy list at the end. I've gone back to the page twice
>> today...bookmarked.
>
>
> Maybe time to update our Gentoo Handbook to use "ip" instead
> of "ifconfig/route" so that users could get used to it right
> during installation...
>
>
> Jarry
> --
>

TBH, the first time I learnt about iproute2 -- about 3 or 4 years ago --  I
no longer use ifconfig.

It's so similar to Cisco IOS commands structure that I immediately took a
liking to it. (Less cognitive dissonance going back and forth between Linux
and Cisco routers).

Rgds,
--

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Canek Peláez Valdés]

On Mon, Apr 8, 2013 at 1:10 PM, Andrew Hoffman  wrote:
>
>
>
> On Mon, Apr 8, 2013 at 1:02 PM, Canek Peláez Valdés 
> wrote:
>>
>> On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
>>  wrote:
>> > Canek,
>> > I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
>> >
>> > lapy lib # locate telepathy-glib.pc
>> > /usr/lib/pkgconfig/telepathy-glib.pc
>> > lapy lib # locate dbus-glib-1.pc
>> > /usr/lib/pkgconfig/dbus-glib-1.pc
>> > lapy lib # locate gio-2.0.pc
>> > /usr/lib/pkgconfig/gio-2.0.pc
>> > lapy lib # locate gee-1.0.pc
>> > /usr/lib/pkgconfig/gee-1.0.pc
>> >
>> > How would I tell if they are damaged if that is indeed the case?
>>
>> Don't top-post, please. Sorry, I messed up the files; you don't need
>> the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
>> need:
>>
>> /usr/share/vala/vapi/telepathy-glib.vapi
>> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> /usr/share/vala-0.18/vapi/gio-2.0.vapi
>> /usr/share/vala/vapi/gee-1.0.vapi
>>
>> Depending on how many Vala compiler versions you have, you can have
>> several of the second and the third; for example I have:
>>
>> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
>> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
>> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
>> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
>> /usr/share/vala-0.20/vapi/dbus-glib-1.vapi
>>
>> Check if you have the four vapi files, and that the ones for
>> dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
>> compiler.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> Guess gmail defaults to top post so its what I use:/
>
> Anyhow I have these files:
>
> lapy lib # locate telepathy-glib.vapi
> /usr/share/vala/vapi/telepathy-glib.vapi
> lapy lib # locate dbus-glib-1.vapi
> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> lapy lib # locate gio-2.0.vapi
> /usr/share/vala-0.12/vapi/gio-2.0.vapi
> /usr/share/vala-0.14/vapi/gio-2.0.vapi
> /usr/share/vala-0.16/vapi/gio-2.0.vapi
> /usr/share/vala-0.18/vapi/gio-2.0.vapi
> lapy lib # locate gee-1.0.vapi
> /usr/share/vala/vapi/gee-1.0.vapi

I see the error now. The problem is that the class GLib.Bytes is
defined in glib-2.0.vapi for valac 0.16, 0.18 and 0.20, but not for
valac 0.12 nor 0.14. The latest version of telepahy-glib uses
GLib.Bytes, so it dependencies need to be compiled with a newer
version of valac.

Can you try to emerge folks as follows:

VALA_MIN_API_VERSION="0.16" emerge dev-libs/folks

If that fails, what version of telepathy-glib do you have installed?

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Eth0 interface not found - udev

[Joseph]

On 04/08/13 04:36, Stroller wrote:



The new naming scheme, however, is much less intuitive. Where originally I just 
immediately use eth0, now I have to enumerate the monikers first, because even 
between servers of the same model (let's say, HP's DL360 G7), the PCI 
attachment point might differ.


I agree. However, attempts to solve this in kernel (I think *several* of them), 
which would have allowed the eth0, ethX namespaces to be retained, were 
rejected. See [3].

I believe that HP shared involvement in this - I think they collaborated with 
Dell on how the BIOS would declare the NICs in a way that would be available to 
the kernel.

Stroller.


Well, if HP had an involvement in it, I'm not surprised we got screw-up with 
this naming; sarcasm.
If they could only put/assign a "chip/serial number" and ask us to pay the way 
they do with their printer cartridges they would do it :-/

If the boys with the servers, with more than two networks cards wants to have consistent naming they should have made it optional and not push this "new name crap" on 
everybody. 


--
Joseph

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

On Mon, Apr 8, 2013 at 1:02 PM, Canek Peláez Valdés wrote:

> On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
>  wrote:
> > Canek,
> > I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
> >
> > lapy lib # locate telepathy-glib.pc
> > /usr/lib/pkgconfig/telepathy-glib.pc
> > lapy lib # locate dbus-glib-1.pc
> > /usr/lib/pkgconfig/dbus-glib-1.pc
> > lapy lib # locate gio-2.0.pc
> > /usr/lib/pkgconfig/gio-2.0.pc
> > lapy lib # locate gee-1.0.pc
> > /usr/lib/pkgconfig/gee-1.0.pc
> >
> > How would I tell if they are damaged if that is indeed the case?
>
> Don't top-post, please. Sorry, I messed up the files; you don't need
> the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
> need:
>
> /usr/share/vala/vapi/telepathy-glib.vapi
> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.18/vapi/gio-2.0.vapi
> /usr/share/vala/vapi/gee-1.0.vapi
>
> Depending on how many Vala compiler versions you have, you can have
> several of the second and the third; for example I have:
>
> /usr/share/vala-0.12/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.14/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.16/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.18/vapi/dbus-glib-1.vapi
> /usr/share/vala-0.20/vapi/dbus-glib-1.vapi
>
> Check if you have the four vapi files, and that the ones for
> dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
> compiler.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>
>
Guess gmail defaults to top post so its what I use:/

Anyhow I have these files:

lapy lib # locate telepathy-glib.vapi
/usr/share/vala/vapi/telepathy-glib.vapi
lapy lib # locate dbus-glib-1.vapi
/usr/share/vala-0.12/vapi/dbus-glib-1.vapi
/usr/share/vala-0.14/vapi/dbus-glib-1.vapi
/usr/share/vala-0.16/vapi/dbus-glib-1.vapi
/usr/share/vala-0.18/vapi/dbus-glib-1.vapi
lapy lib # locate gio-2.0.vapi
/usr/share/vala-0.12/vapi/gio-2.0.vapi
/usr/share/vala-0.14/vapi/gio-2.0.vapi
/usr/share/vala-0.16/vapi/gio-2.0.vapi
/usr/share/vala-0.18/vapi/gio-2.0.vapi
lapy lib # locate gee-1.0.vapi
/usr/share/vala/vapi/gee-1.0.vapi

Looks to be correct.

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Walter Dnes]

On Mon, Apr 08, 2013 at 08:19:23AM -0500, Andrew Hoffman wrote
> I also tried this: emerge gobject-introspection =dev-lang/vala-0.12.1-r1
> dbus =dev-lang/vala-0.18.1 dbus-glib libgee telepathy-glib
> all of which merged successfully
> Folks still failed

  The python setup appears to be OK from your "emerge --info".  There
are 2 last desparate straws to clutch at...

1) Set MAKEOPTS="-j1" and try to emerge folks.  If that fails...

2) emerge world && emerge folks
"emerge world" will pick up build-time dependancies that revdep-rebuild
doesn't catch.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Canek Peláez Valdés]

On Mon, Apr 8, 2013 at 12:54 PM, Andrew Hoffman
 wrote:
> Canek,
> I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64
>
> lapy lib # locate telepathy-glib.pc
> /usr/lib/pkgconfig/telepathy-glib.pc
> lapy lib # locate dbus-glib-1.pc
> /usr/lib/pkgconfig/dbus-glib-1.pc
> lapy lib # locate gio-2.0.pc
> /usr/lib/pkgconfig/gio-2.0.pc
> lapy lib # locate gee-1.0.pc
> /usr/lib/pkgconfig/gee-1.0.pc
>
> How would I tell if they are damaged if that is indeed the case?

Don't top-post, please. Sorry, I messed up the files; you don't need
the pkgconfig files (*.pc), you need the Vala API files (*.vapi). You
need:

/usr/share/vala/vapi/telepathy-glib.vapi
/usr/share/vala-0.18/vapi/dbus-glib-1.vapi
/usr/share/vala-0.18/vapi/gio-2.0.vapi
/usr/share/vala/vapi/gee-1.0.vapi

Depending on how many Vala compiler versions you have, you can have
several of the second and the third; for example I have:

/usr/share/vala-0.12/vapi/dbus-glib-1.vapi
/usr/share/vala-0.14/vapi/dbus-glib-1.vapi
/usr/share/vala-0.16/vapi/dbus-glib-1.vapi
/usr/share/vala-0.18/vapi/dbus-glib-1.vapi
/usr/share/vala-0.20/vapi/dbus-glib-1.vapi

Check if you have the four vapi files, and that the ones for
dbus-glib-1 and gio-2.0 exists for all your versions of the Vala
compiler.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

Canek,
I have those files in /usr/lib/pkgconfig I do not have a /usr/lib64

lapy lib # locate telepathy-glib.pc
/usr/lib/pkgconfig/telepathy-glib.pc
lapy lib # locate dbus-glib-1.pc
/usr/lib/pkgconfig/dbus-glib-1.pc
lapy lib # locate gio-2.0.pc
/usr/lib/pkgconfig/gio-2.0.pc
lapy lib # locate gee-1.0.pc
/usr/lib/pkgconfig/gee-1.0.pc

How would I tell if they are damaged if that is indeed the case?

-Andy



On Mon, Apr 8, 2013 at 12:45 PM, Canek Peláez Valdés wrote:

> On Mon, Apr 8, 2013 at 8:19 AM, Andrew Hoffman 
> wrote:
> > I also tried this: emerge gobject-introspection =dev-lang/vala-0.12.1-r1
> > dbus =dev-lang/vala-0.18.1 dbus-glib libgee telepathy-glib
> > all of which merged successfully
> > Folks still failed
>
> Do you have the following files in your system?
>
> /usr/lib64/pkgconfig/telepathy-glib.pc
> /usr/lib64/pkgconfig/dbus-glib-1.pc
> /usr/lib64/pkgconfig/gio-2.0.pc
> /usr/lib64/pkgconfig/gee-1.0.pc
>
> One of those is missing or with the wrong information, according to your
> logs.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>
>

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Canek Peláez Valdés]

On Mon, Apr 8, 2013 at 8:19 AM, Andrew Hoffman  wrote:
> I also tried this: emerge gobject-introspection =dev-lang/vala-0.12.1-r1
> dbus =dev-lang/vala-0.18.1 dbus-glib libgee telepathy-glib
> all of which merged successfully
> Folks still failed

Do you have the following files in your system?

/usr/lib64/pkgconfig/telepathy-glib.pc
/usr/lib64/pkgconfig/dbus-glib-1.pc
/usr/lib64/pkgconfig/gio-2.0.pc
/usr/lib64/pkgconfig/gee-1.0.pc

One of those is missing or with the wrong information, according to your logs.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Jarry]

On 08-Apr-13 19:19, Michael Mol wrote:

On 04/08/2013 12:28 PM, Bruce Hill wrote:

On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:

On Sat, 6 Apr 2013 22:35:22 -0400
Nick Khamis  wrote:

As for /sbin/ip. I have no such command.


I'd recommend installing and becoming familiar with the iproute2
package. I personally find the tools it delivers to be more intuitive
than the older tools, and I *think* they are considered to obsolote some
tools, such as ifconfig.


Ack to Randy's. FWIW: http://inai.de/2008/02/19


That page has a handy list at the end. I've gone back to the page twice
today...bookmarked.


Maybe time to update our Gentoo Handbook to use "ip" instead
of "ifconfig/route" so that users could get used to it right
during installation...

Jarry
--
___
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/08/2013 12:28 PM, Bruce Hill wrote:
> On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:
>> On Sat, 6 Apr 2013 22:35:22 -0400
>> Nick Khamis  wrote:
>>> As for /sbin/ip. I have no such command.
>>
>> I'd recommend installing and becoming familiar with the iproute2
>> package. I personally find the tools it delivers to be more intuitive
>> than the older tools, and I *think* they are considered to obsolote some
>> tools, such as ifconfig.
> 
> Ack to Randy's. FWIW: http://inai.de/2008/02/19
> 

That page has a handy list at the end. I've gone back to the page twice
today...bookmarked.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Eth0 interface not found - udev

[Bruce Hill]

On Sun, Apr 07, 2013 at 10:35:28PM +0700, Pandu Poluan wrote:
> 
> AFAICT, on-board NICs have sequential MAC Adresses, with the one labeled
> "Port 1" has the smallest MAC Address. So far, *all* Linux distros I've
> used on a server will reliably name "Port X" as "eth$((X-1))". So it's
> never a puzzle as to which port bears which "ethX" moniker.

My SuperMicro has the lower MAC wired to ID1 and the higher MAC to ID2:

[   11.691830] tg3 :03:00.0: eth0: Tigon3 [partno(BCM95721) rev 4101] (PCI 
Express) MAC address 00:d0:68:0b:87:67
[   11.691985] tg3 :03:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[0])
[   11.692192] tg3 :03:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] 
TSOcap[1]
[   11.692340] tg3 :03:00.0: eth0: dma_rwctrl[7618] dma_mask[64-bit]
[   11.699283] tg3 :02:00.0: eth1: Tigon3 [partno(BCM95721) rev 4101] (PCI 
Express) MAC address 00:d0:68:0b:87:66
[   11.699439] tg3 :02:00.0: eth1: attached PHY is 5750 (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[0])
[   11.699591] tg3 :02:00.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] 
TSOcap[1]
[   11.699738] tg3 :02:00.0: eth1: dma_rwctrl[7618] dma_mask[64-bit]

Which is precisely the reason for me using 70-persistent-net.rules since
Gentoo was installed on it back in 2011. My ethernet cable is plugged into
ID1, or MAC address 00:d0:68:0b:87:66, and /etc/conf.d/net must know which
eth* that was assigned.

> The new naming scheme, however, is much less intuitive. Where originally I
> just immediately use eth0, now I have to enumerate the monikers first,
> because even between servers of the same model (let's say, HP's DL360 G7),
> the PCI attachment point might differ.

My old brain has chosen to stick with "intuitive", which really just means
"what you have become accustomed to", whatever that might be individually.

> Granted, Linux SysAdmins *are* expected to understand the vagaries of
> Linux, but it's still a great inconvenience.

And therein lies the rub ... systemd has overtaken udev and changed the
nomenclature.
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:
> On Sat, 6 Apr 2013 22:35:22 -0400
> Nick Khamis  wrote:
> > As for /sbin/ip. I have no such command.
> 
> I'd recommend installing and becoming familiar with the iproute2
> package. I personally find the tools it delivers to be more intuitive
> than the older tools, and I *think* they are considered to obsolote some
> tools, such as ifconfig.

Ack to Randy's. FWIW: http://inai.de/2008/02/19
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sun, Apr 07, 2013 at 01:29:20PM -0400, Nick Khamis wrote:
> After psyching myself and everyone else for the udev 200 update, it
> failed on compile phase! We are using hardened server, and error
> message (which I am transferring over manually) is:
> 
> The specific snippet of code:
> die econf failed
> 
> 
> This thing is not going easy
> 
> 
> N.
> 
> On 4/7/13, Tanstaafl  wrote:
> > On 2013-04-07 9:38 AM, Nick Khamis  wrote:
> >> Double checking the udevd version we are running 171. Not sure if we
> >> should be effected yet? I confess, I did a world upgrade and walked
> >> away.
> >
> > Well, hopefully you learned a valuable lesson. I cannot even *fathom*
> > the *idea* of doing a world update on a remote server without going
> > through each and every package to be updated, reading every news item I
> > could find, etc etc ad nauseum, and googling if any systems critical to
> > booting (like udev) are involved.
> >
> > For me, world updates are usually very small because I keep my server
> > updated weekly. I generally sync every day, checking what packages are
> > available, then once that update has been available/unchanged for 3 or 4
> > days, I update it... waiting even a bit longer (and googling for issues)
> > if the package(s) are critical system packages.
> >
> > Admittedly, doing it this way manually wouldn't work for anyone managing
> > more than a few servers, although I imagine it could be scripted by one
> > with the knowledge/desire.
> >
> > But seriously - there has been so much noise about the whole udev
> > situation in the last months (6+?) that you should really be kicking
> > yourself that you did that.
> >
> >

You might not care, but I automatically hit D (delete) in Mutt for every email
that's top-posted. Just saying...
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sun, Apr 07, 2013 at 07:42:23PM +0200, Michael Hampicke wrote:
> 
> Mike is right, if it's not a dep of another ebuild, you don't need
> wpa_supplicant. I just upgraded udev to 200 on the last remote box
> (which is always a bit of a thrill after typing reboot  :-) ).
> As expected, eth0 came up, everything works fine, wpa_supplicant is not
> installed.

Don't know what you guys do for rebooting a headless server blindly like this,
nor if it would work for the udev/NIC situation. But fwiw, what I've always
done for new kernels is:

mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/lilo.conf
compact
lba32
default = Gentoo-def
boot = /dev/md0
raid-extra-boot = mbr-only
map = /boot/.map
install = /boot/boot-menu.b   # Note that for lilo-22.5.5 or later you
  # do not need boot-{text,menu,bmp}.b in
  # /boot, as they are linked into the lilo
  # binary.
menu-scheme=Wb
prompt
timeout=50
append="panic=10 nomce dolvm domdadm rootfstype=xfs"
image = /boot/vmlinuz
root = /dev/md0
label = Gentoo
read-only  # Partitions should be mounted read-only for checking
image = /boot/vmlinuz.old
root = /dev/md0
label = Gentoo-def
read-only  # Partitions should be mounted read-only for checking

Then issue "lilo -R Gentoo" or whatever the label of your new kernel, and if
it boots, you're okay. If not, after 10 seconds of panic, it automatically
reboots back into the default kernel and you can check logs to see what you've
broken. (panic=10 append statement and default = Gentoo-def) After you know
the new kernel works, comment the default line. (NB: You can name them
differently, etc. It just helps to know before you reboot that if you panic,
the machine will boot back into the known, good, kernel.) 

Granted, this might not help with the udev/NIC situation, but it's saved me
from a few PEBKAC situations, as well as new kernel changes I'd not learned
until the reboot.
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Michael Mol]

On 04/08/2013 12:04 PM, Bruce Hill wrote:
> On Sun, Apr 07, 2013 at 09:31:43PM +0100, Neil Bothwick wrote:
>> On Sun, 07 Apr 2013 13:16:45 -0400, Tanstaafl wrote:
>>
>>> "If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
>>> symlink to /dev/null,"
>>>
>>> The first can obviously be taken quite literally, while the second just 
>>> might actually require a tiny bit of thought - ie, 'hmmm, wonder if
>>> they mean literally 'empty', or just nothing in it that does anything?
>>
>> Even if that were reasonable, how are you supposed to know which they
>> mean? You guessed right and now have the benefit of hindsight, that does
>> not justify ambiguous or inaccurate instructions.
> 
> Ack!
> 
> Empty means a zero byte file ... always has, and if the idiots who have
> started systemd and taken over udev have somehow managed to change that, then
> we are not going to be able to trust ANYTHING they ever write again, without a
> new dictionary to define their terms. (Sounds like the present POTUS,
> Congress, and Supreme Court in the U.S.)
> 
> Personally I don't now, nor have ever, trusted Kay and Lennart. I depend upon
> WilliamH to keep the ship afloat as we sail through the udev murk...
> 

The phrase is "kernel-tinted glasses".




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sun, Apr 07, 2013 at 09:31:43PM +0100, Neil Bothwick wrote:
> On Sun, 07 Apr 2013 13:16:45 -0400, Tanstaafl wrote:
> 
> > "If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
> > symlink to /dev/null,"
> > 
> > The first can obviously be taken quite literally, while the second just 
> > might actually require a tiny bit of thought - ie, 'hmmm, wonder if
> > they mean literally 'empty', or just nothing in it that does anything?
> 
> Even if that were reasonable, how are you supposed to know which they
> mean? You guessed right and now have the benefit of hindsight, that does
> not justify ambiguous or inaccurate instructions.

Ack!

Empty means a zero byte file ... always has, and if the idiots who have
started systemd and taken over udev have somehow managed to change that, then
we are not going to be able to trust ANYTHING they ever write again, without a
new dictionary to define their terms. (Sounds like the present POTUS,
Congress, and Supreme Court in the U.S.)

Personally I don't now, nor have ever, trusted Kay and Lennart. I depend upon
WilliamH to keep the ship afloat as we sail through the udev murk...
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sun, Apr 07, 2013 at 05:00:17PM +, Grant Edwards wrote:
> On 2013-04-07, Tanstaafl  wrote:
> > On 2013-04-07 6:55 AM, Neil Bothwick  wrote:
> >> On Sat, 06 Apr 2013 17:14:00 -0400, Tanstaafl wrote:
> >>
>  Well, in my case 80-net-names-slot.rules was neither empty,
>  nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
> >>>
> >>> Well... even I know enough to reason that 'empty' in this context means
> >>> no UNcommented lines. Comments are just that, and if there are no
> >>> UNcommented lines, then nothing is active, hence it is effectively
> >>> 'empty'.
> >>
> >> But not actually empty. If you are correct, and I suspect you are, then
> >> the news item is poorly worded. No effective content is not the same as
> >> no content at all.
> >
> > Oh, I agree that it was poorly worded, I was just pointing out that it 
> > was kind of silly to take quite it so literally...
> 
> OK, so parts of the news item are not to be taken literally, and other
> parts are.  Perhaps it would be wise to mark the sections so we can
> tell the difference?  ;)
> 
> > Every sysadmin knows (or should know) that a config file full of
> > nothing but comments isn't going to do *anything* other than provide
> > whatever defaults the program is designed to use in such a case.
> 
> It's entirely possible for udev (or any other program) to check
> whether a file is empty or not and behave differently depending on
> that test.  And if it is explicitly stated that something depends on a
> file being "empty", that's what I assume was indended.  Of course it's
> possible to determine via experimentation that "nothing but comments"
> produces the same behavior as "empty".  Of course we all figured that
> out after we realized that udev wasn't behaving as was described in
> the news entry and started reading other documentation.

I'll give you all one more to chew on ... this LAN has 5 comps running udev,
upgraded from 171 > 197 > 200, and NONE of them EVER has this mysterious
/etc/udev/rules.d/80-net-name-slot.rules file. If it was there sometime during
these upgrades, and was removed, it was automatically removed and not manually
by me using rm to do so.
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Eth0 interface not found - udev that little slut!!!!!

[Bruce Hill]

On Sun, Apr 07, 2013 at 09:12:15AM +0800, William Kenworthy wrote:
> > 
> > Steady on, old chap!  By "it" I was meaning the general inconvenience
> > all round occasioned by the changes between udev-{197,200}.  Not
> > everybody encountered this.  For example Dale, and Walt D. didn't have
> > to do anything.  But pretty much everybody else did.
> > 
> > 
> 
> I didnt get hit either either, but ("STRONG" hint") ... I use eudev, so
> dies Dale and I believe Walt uses mdev.  Time for those in server
> environments to jump ship?
> 
> It may hit us eventually, but at the moment its :)

I didn't "get hit" by this either, and am still using udev. I went from 171 to
197 to 200 and all's still well on the 5 Gentoo boxen left on this LAN.
Granted, only 3 of them have multiple NICs, and only one is using multiple
ethernet cables atm.
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
> 
> The significance is that the kernel determines the eth* name order.
> Right now, you are lucky in that the order is what you think it should
> be, but if something changes in the kernel causing your cards to be
> initialized in a different order, you will not be allowed to swap them
> around in the eth* name space, e.g. eth1 can't become eth0 or visa
> versa.
> 
> That is why it is recommended that you use something like net0, net1,
> etc for your interface names.
> 
> William

This doesn't seem consistent with my experience. The reason that I edited the
70-persistent-net.rules file to begin with is to make the NICs whatever eth* I
wanted, regardless of the order the kernel loaded them. Since the modules are
built-in, and both NICs use the same module, I think this won't change.

The server has two built-in NICs. One is being used to connect it to the
switch, and the other is not in use (backup). One has ID 1 and the other ID 2.
The kernel was loading the one with the higher MAC address first, and the
lower MAC address second. The lower MAC number is the one with the stamp ID 1
on the back of the server, so I edited the rules file to load it always as
eth1 so my /etc/conf.d/net can use static IPs (like everything wired on the
LAN); because the ethernet cable is connected from ID 1 to the switch. Thus:

server ~ # dmesg | grep -i eth
[   11.691830] tg3 :03:00.0: eth0: Tigon3 [partno(BCM95721) rev 4101] (PCI 
Express) MAC address 00:d0:68:0b:87:67
[   11.691985] tg3 :03:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[0])
[   11.692192] tg3 :03:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] 
TSOcap[1]
[   11.692340] tg3 :03:00.0: eth0: dma_rwctrl[7618] dma_mask[64-bit]
[   11.699283] tg3 :02:00.0: eth1: Tigon3 [partno(BCM95721) rev 4101] (PCI 
Express) MAC address 00:d0:68:0b:87:66
[   11.699439] tg3 :02:00.0: eth1: attached PHY is 5750 (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[0])
[   11.699591] tg3 :02:00.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] 
TSOcap[1]
[   11.699738] tg3 :02:00.0: eth1: dma_rwctrl[7618] dma_mask[64-bit]
[   82.703869] tg3 :02:00.0: eth1: Link is up at 1000 Mbps, full duplex
[   82.703875] tg3 :02:00.0: eth1: Flow control is off for TX and off for RX
server ~ # cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:d0:68:0b:87:66", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:d0:68:0b:87:67", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
KERNEL=="eth*", NAME="eth0"

server ~ # ip addr show
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:d0:68:0b:87:67 brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:d0:68:0b:87:66 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.3/24 brd 192.168.100.255 scope global eth1


The Linux router has 3 NICs in use. Two of them are identical Intel cards. It
controls 3 networks, and there's a backup NIC of the same brand. So it's
important for me to know the assignment of them, and again,
70-persistent-net.rules allows me to keep the ordered according to MAC
address:

router log # zgrep -i eth* kern.log-20130326.gz
Mar 25 18:31:47 router kernel: [1.434939] pata_amd :00:06.0: setting 
latency timer to 64
Mar 25 18:31:47 router kernel: [1.436360] e1000e: Intel(R) PRO/1000 Network 
Driver - 1.9.5-k
Mar 25 18:31:47 router kernel: [1.437229] e1000e :02:00.0: 
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic 
conservative mode
Mar 25 18:31:47 router kernel: [1.540889] e1000e :02:00.0: eth0: (PCI 
Express:2.5GT/s:Width x1) 68:05:ca:03:05:50
Mar 25 18:31:47 router kernel: [1.541039] e1000e :02:00.0: eth0: 
Intel(R) PRO/1000 Network Connection
Mar 25 18:31:47 router kernel: [1.541185] e1000e :02:00.0: eth0: MAC: 
3, PHY: 8, PBA No: E46981-007
Mar 25 18:31:47 router kernel: [1.542263] e1000e :03:00.0: 
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic 
conservative mode
Mar 25 18:31:47 router kernel: [1.644050] e1000e :03:00.0: eth1: (PCI 
Express:2.5GT/s:Width x1) 68:05:ca:03:05:5d
Mar 25 18:31:47 router kernel: [1.644196] e1000e :03:00.0: eth1: 
Intel(R) PRO/1000 Network Connection
Mar 25 18:31:47 router kernel: [1.644345] e100

Re: [gentoo-user] Pidgin, gtalk and jingle

[Kvothe Tech]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Google voice uses ulaw g7.11 only if I remember rigbt Google talk/chat allows a 
few more but jingle isn't one of them.

Nilesh Govindrajan  wrote:

>On Apr 8, 2013 9:07 PM, "Michael Hampicke" 
>wrote:
>>
>> Am 08.04.2013 17:20, schrieb Michael Mol:
>> > So, I'm trying to verify whether or not Pidgin can talk to Google
>Voice
>> > on my laptop. When searching around for instructions, I get the
>> > impression that this is supposed to "just work", and I don't see
>much in
>> > the way of people actually having difficulty with it.
>> >
>> > In my case, if someone calls me, my gmail tab rings at me, my phone
>> > rings at me, but Pidgin doesn't so much as twitch.
>> >
>> > Has anyone else had this working on Gentoo?
>> >
>> > Here's what I'm working with:
>> >
>> > net-im/pidgin-2.10.7-r1 was built with the following:
>> > USE="dbus doc gnutls gstreamer gtk (multilib) ncurses
>networkmanager nls
>> > python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
>> > -groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl
>-zephyr"
>> > ABI_X86="64"
>> >
>>
>> I never got this to work either. I tried google-voice-calling ( :-) )
>> myself from my android phone to pidgin on the work station and got
>> nothing. Also I cannot make outgoing calls from pidgin to my android
>phone.
>>
>
>Same here. It seems Google Talk uses some different protocol unlike
>pidgin
>which uses jingle. Pidgin to pidgin calling works.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iQJBBAEBCAArBQJRYuWTJBxLdm90aGUgVGVjaCA8a3ZvdGhlQGt2b3RoZXRlY2gu
Y29tPgAKCRDpajPkVlu7Ohb6D/92SoWGESXD+zMvdjl0yBzuv2QSThHkCP1sBcyQ
OwHpWi6rJl4OefSONX52MacRqjfjdKwa+OXQEnAZXWItfTW/RzdVlGNZJwwSvhHE
tWRlTaShVV6zV/zp1E0oDsmktS3slVh3UgkuxkWJ6rTrLtZguZgoXQtKFPo+ydbx
ftvZLXHVoFTX/2BKR14pC7CIizCRH28ujFHMTqDPJtT6e1ZMdT7oAT9h3pA8eHyc
1KBJntm1yr9cK6E+Z5iKWRdYin64HvMOcbMg8sCkpL1qgyQqdJHBL/NRVmtYQySq
Dqpuc3tznjLST51duuatXlY98EmpFNFDoFaW+JVNfKMqA23EFOKFV9QUyqkP+6s7
Z1MCyl9mqzjHYvj7g5BjVcUqSLh62ikz+hVbJVCRSmc5bEIXssjF4uOVtQK6fUen
x2+xNk1eIJdT6rkBUd6OBXIiwLiKEaA0I/ldyZcXGgui+HSqjGzeEAy/pISUvDzk
zzAdQYSPD1++qI5mlG7oMD6yQzokqTgAsgCyP00+ou5CBYd87xyu9TLz+Jwdi3Ef
h9nTBapv5ukGsQ5gFA8OkzGiwuVhTADlm8rDwn2Fp8utAko69f1o1JcTKBPa7GqN
gD+rKO5U6Fxbno+4tnBFVlIvik9PYG6+9Ch5sOv6M1vSEB5ATx4ziXtknwlpjj1p
TfvbyQ==
=TwYR
-END PGP SIGNATURE-

Re: [gentoo-user] Pidgin, gtalk and jingle

[Michael Mol]

On 04/08/2013 11:39 AM, Nilesh Govindrajan wrote:
> On Apr 8, 2013 9:07 PM, "Michael Hampicke"  > wrote:
>>
>> Am 08.04.2013 17:20, schrieb Michael Mol:
>> > So, I'm trying to verify whether or not Pidgin can talk to Google Voice
>> > on my laptop. When searching around for instructions, I get the
>> > impression that this is supposed to "just work", and I don't see much in
>> > the way of people actually having difficulty with it.
>> >
>> > In my case, if someone calls me, my gmail tab rings at me, my phone
>> > rings at me, but Pidgin doesn't so much as twitch.
>> >
>> > Has anyone else had this working on Gentoo?
>> >
>> > Here's what I'm working with:
>> >
>> > net-im/pidgin-2.10.7-r1 was built with the following:
>> > USE="dbus doc gnutls gstreamer gtk (multilib) ncurses networkmanager nls
>> > python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
>> > -groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl -zephyr"
>> > ABI_X86="64"
>> >
>>
>> I never got this to work either. I tried google-voice-calling ( :-) )
>> myself from my android phone to pidgin on the work station and got
>> nothing. Also I cannot make outgoing calls from pidgin to my android
> phone.
>>
> 
> Same here. It seems Google Talk uses some different protocol unlike
> pidgin which uses jingle. Pidgin to pidgin calling works.
> 

On my wife's workstation (running Windows), I'm told it works; pidgin
tells her someone's calling when someone calls her google voice number.
(She ignores it, though, since she doesn't actively use Pidgin for voice.)

So Pidgin is capable of talking to Google's variant on XMPP-Jingle, but
for whatever reason it doesn't seem to work on Gentoo, from the sound of it.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

On 04/08/2013 11:04 AM, Bruce Hill wrote:
> On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
>> On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
>>> On 2013-04-05 4:11 PM, William Hubbs  wrote:
 On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> Just dealing with one server and my Linux router, they've been updated to
> sys-fs/udev-200 and are both still using the same
> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a 
> year,
> which was working with udev-171.

 Do you have your network interface drivers built into the kernel or are
 they modules?
>>>
>>> I'm very interested in the significance of this question...
>>>
>>> My server is module free, so all drivers are built into the kernel.
>>
>> The significance is that the kernel determines the eth* name order.
>> Right now, you are lucky in that the order is what you think it should
>> be, but if something changes in the kernel causing your cards to be
>> initialized in a different order, you will not be allowed to swap them
>> around in the eth* name space, e.g. eth1 can't become eth0 or visa
>> versa.
>>
>> That is why it is recommended that you use something like net0, net1,
>> etc for your interface names.
> 
> Thanks for your reply. After 10 years of eth* it's going to be hard to make a
> change until the kernel does this, also.

No kidding. There's almost 30 years' documentation out there that
assumes 'eth0' is the interface you care about, except in cases where
you care about 'eth0' and 'eth1'.

As far as the kernel namespace issue...there needs to be a different
namespace between what the kernel defines and what udev can control; at
the moment, if you define your own NIC names (say, wan1, wan2), there's
a chance that a kernel driver will stomp on it if you start using a card
that has a driver that likes that numbering scheme.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Pidgin, gtalk and jingle

[Nilesh Govindrajan]

On Apr 8, 2013 9:07 PM, "Michael Hampicke"  wrote:
>
> Am 08.04.2013 17:20, schrieb Michael Mol:
> > So, I'm trying to verify whether or not Pidgin can talk to Google Voice
> > on my laptop. When searching around for instructions, I get the
> > impression that this is supposed to "just work", and I don't see much in
> > the way of people actually having difficulty with it.
> >
> > In my case, if someone calls me, my gmail tab rings at me, my phone
> > rings at me, but Pidgin doesn't so much as twitch.
> >
> > Has anyone else had this working on Gentoo?
> >
> > Here's what I'm working with:
> >
> > net-im/pidgin-2.10.7-r1 was built with the following:
> > USE="dbus doc gnutls gstreamer gtk (multilib) ncurses networkmanager nls
> > python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
> > -groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl -zephyr"
> > ABI_X86="64"
> >
>
> I never got this to work either. I tried google-voice-calling ( :-) )
> myself from my android phone to pidgin on the work station and got
> nothing. Also I cannot make outgoing calls from pidgin to my android
phone.
>

Same here. It seems Google Talk uses some different protocol unlike pidgin
which uses jingle. Pidgin to pidgin calling works.

Re: [gentoo-user] Pidgin, gtalk and jingle

[Michael Hampicke]

Am 08.04.2013 17:20, schrieb Michael Mol:
> So, I'm trying to verify whether or not Pidgin can talk to Google Voice
> on my laptop. When searching around for instructions, I get the
> impression that this is supposed to "just work", and I don't see much in
> the way of people actually having difficulty with it.
> 
> In my case, if someone calls me, my gmail tab rings at me, my phone
> rings at me, but Pidgin doesn't so much as twitch.
> 
> Has anyone else had this working on Gentoo?
> 
> Here's what I'm working with:
> 
> net-im/pidgin-2.10.7-r1 was built with the following:
> USE="dbus doc gnutls gstreamer gtk (multilib) ncurses networkmanager nls
> python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
> -groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl -zephyr"
> ABI_X86="64"
> 

I never got this to work either. I tried google-voice-calling ( :-) )
myself from my android phone to pidgin on the work station and got
nothing. Also I cannot make outgoing calls from pidgin to my android phone.

[gentoo-user] Pidgin, gtalk and jingle

[Michael Mol]

So, I'm trying to verify whether or not Pidgin can talk to Google Voice
on my laptop. When searching around for instructions, I get the
impression that this is supposed to "just work", and I don't see much in
the way of people actually having difficulty with it.

In my case, if someone calls me, my gmail tab rings at me, my phone
rings at me, but Pidgin doesn't so much as twitch.

Has anyone else had this working on Gentoo?

Here's what I'm working with:

net-im/pidgin-2.10.7-r1 was built with the following:
USE="dbus doc gnutls gstreamer gtk (multilib) ncurses networkmanager nls
python spell tk xscreensaver zeroconf (-aqua) -debug -eds -gadu
-groupwise -idn -meanwhile -perl -prediction -sasl -silc -tcl -zephyr"
ABI_X86="64"



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
> On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
> > On 2013-04-05 4:11 PM, William Hubbs  wrote:
> > > On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> > >> Just dealing with one server and my Linux router, they've been updated to
> > >> sys-fs/udev-200 and are both still using the same
> > >> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a 
> > >> year,
> > >> which was working with udev-171.
> > >
> > > Do you have your network interface drivers built into the kernel or are
> > > they modules?
> > 
> > I'm very interested in the significance of this question...
> > 
> > My server is module free, so all drivers are built into the kernel.
> 
> The significance is that the kernel determines the eth* name order.
> Right now, you are lucky in that the order is what you think it should
> be, but if something changes in the kernel causing your cards to be
> initialized in a different order, you will not be allowed to swap them
> around in the eth* name space, e.g. eth1 can't become eth0 or visa
> versa.
> 
> That is why it is recommended that you use something like net0, net1,
> etc for your interface names.

Thanks for your reply. After 10 years of eth* it's going to be hard to make a
change until the kernel does this, also.

Bruce
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.   

   
Q: Why is top-posting such a bad thing? 

   
A: Top-posting. 

   
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] gcc-4.5.4 failed (install phase)

[Joseph]

On 04/08/13 09:47, cov...@ccs.covici.com wrote:

Markos Chandras  wrote:


On 8 April 2013 02:13, Joseph  wrote:
> I'm getting an error re-compiling gcc-4.5.4
>
> o _dim_i16.o _dim_r4.o _dim_r8.o _dim_r10.o _dim_r16.o _atan2_r4.o
> _atan2_r8.o _atan2_r10.o _atan2_r16.o _mod_i4.o _mod_i8.o _mod_i16.o
> _mod_r4.o _mod_r8.o _mod_r10.o _mod_r16.o misc_specifics.o dprod_r8.o
> f2c_specifics.o
> libtool: link: /usr/i686-pc-linux-gnu/bin/ranlib .libs/libgfortran.a
> libtool: link: ( cd ".libs" && rm -f "libgfortran.la" && ln -s
> "../libgfortran.la" "libgfortran.la" )
> true  DO=all multi-do # make
> make[3]: Leaving directory
> 
`/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/i686-pc-linux-gnu/libgfortran'
> make[2]: Leaving directory
> 
`/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/i686-pc-linux-gnu/libgfortran'
> make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build'
> /var/tmp/portage/sys-devel/gcc-4.5.4/work/build
> /var/tmp/portage/sys-devel/gcc-4.5.4/work/gcc-4.5.4
> cp: cannot stat
> ‘/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/gcc/doc/*.info’: No such
> file or directory

This is because of texinfo-5.1. There was already a bug about it

https://bugs.gentoo.org/show_bug.cgi?id=464008

Please sync your tree and try again


I had a couple of more things which broke -- gcc 4.7.2 and
speech-dispatcher 0.7.1-r1.


No, I wasn't effected by texinfo-5.1 as I use texinfo-4.x
According to another developer: There was a regression introduced in the 
toolchain.eclass. It is fixed again, so re-sync and re-emerge fix it.

--
Joseph

Re: [gentoo-user] gcc-4.5.4 failed (install phase)

[covici]

Markos Chandras  wrote:

> On 8 April 2013 02:13, Joseph  wrote:
> > I'm getting an error re-compiling gcc-4.5.4
> >
> > o _dim_i16.o _dim_r4.o _dim_r8.o _dim_r10.o _dim_r16.o _atan2_r4.o
> > _atan2_r8.o _atan2_r10.o _atan2_r16.o _mod_i4.o _mod_i8.o _mod_i16.o
> > _mod_r4.o _mod_r8.o _mod_r10.o _mod_r16.o misc_specifics.o dprod_r8.o
> > f2c_specifics.o
> > libtool: link: /usr/i686-pc-linux-gnu/bin/ranlib .libs/libgfortran.a
> > libtool: link: ( cd ".libs" && rm -f "libgfortran.la" && ln -s
> > "../libgfortran.la" "libgfortran.la" )
> > true  DO=all multi-do # make
> > make[3]: Leaving directory
> > `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/i686-pc-linux-gnu/libgfortran'
> > make[2]: Leaving directory
> > `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/i686-pc-linux-gnu/libgfortran'
> > make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build'
> > /var/tmp/portage/sys-devel/gcc-4.5.4/work/build
> > /var/tmp/portage/sys-devel/gcc-4.5.4/work/gcc-4.5.4
> > cp: cannot stat
> > ‘/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/gcc/doc/*.info’: No such
> > file or directory
> 
> This is because of texinfo-5.1. There was already a bug about it
> 
> https://bugs.gentoo.org/show_bug.cgi?id=464008
> 
> Please sync your tree and try again

I had a couple of more things which broke -- gcc 4.7.2 and
speech-dispatcher 0.7.1-r1.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

I also tried this: emerge gobject-introspection =dev-lang/vala-0.12.1-r1
dbus =dev-lang/vala-0.18.1 dbus-glib libgee telepathy-glib
all of which merged successfully
Folks still failed


On Mon, Apr 8, 2013 at 7:12 AM, Andrew Hoffman wrote:

> lapy andy # cat /var/lib/layman/make.conf
> PORTDIR_OVERLAY="
> /var/lib/layman/gamerlay
> /var/lib/layman/games
> /var/lib/layman/java-overlay
> $PORTDIR_OVERLAY
> "
>
> I attached the other logs.
>
> I also remerged libgee no change
>
> Thanks,
> -Andy
>
>
> On Sun, Apr 7, 2013 at 11:50 PM, Walter Dnes wrote:
>
>> On Sun, Apr 07, 2013 at 09:49:57PM -0500, Andrew Hoffman wrote
>>
>> > I have also rebuilt telepathy-glib debus-glib and gio with no change
>> > in folks. gee does not appear to be a package.
>>
>>   I tried...
>>
>> USE="vala vapigen introspection" emerge -pv folks
>>
>> on my system.  It gives...
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild  N ] dev-libs/gobject-introspection-1.32.1  USE="-doc
>> -doctool {-test}" 0 kB
>> [ebuild  N ] dev-lang/vala-0.12.1-r1:0.12  USE="vapigen {-test}"
>> 2,233 kB
>> [ebuild  N ] sys-apps/dbus-1.6.8  USE="X -debug -doc (-selinux)
>> -static-libs {-test}" 1,885 kB
>> [ebuild  N ] dev-lang/vala-0.18.1:0.18  USE="vapigen {-test}" 0 kB
>> [ebuild  N ] dev-libs/dbus-glib-0.100.2  USE="-debug -doc
>> -static-libs {-test}" 732 kB
>> [ebuild  N ] dev-libs/libgee-0.6.7  USE="introspection" 494 kB
>> [ebuild  N ] net-libs/telepathy-glib-0.20.1-r1  USE="introspection
>> vala -debug {-test}" PYTHON_TARGETS="python2_7 -python2_5 -python2_6" 3,668
>> kB
>> [ebuild  N ] dev-libs/folks-0.4.3  USE="-debug" 621 kB
>>
>>   I think that "gee" refers to dev-libs/libgee.  Can you give the output
>> of "emerge --info"?  I notice that you also have the line...
>>
>> source /var/lib/layman/make.conf
>>
>> ...in your make.conf.  It may be over-riding stuff in your regular
>> make.conf.  "emerge --info" will tell us what you have in total.
>> But a listing of /var/lib/layman/make.conf might still help us.
>>
>>   Another potential issue... in my make.conf I have...
>>
>> PYTHON_TARGETS="python2_7"
>> PYTHON_SINGLE_TARGET="python2_7"
>>
>> YES!!! I need both of them.  I don't see them in your make.conf, unless
>> they're in the /var/lib/layman/make.conf
>>
>> --
>> Walter Dnes 
>> I don't run "desktop environments"; I run useful applications
>>
>>
>

Re: [gentoo-user] dev-libs/folks-0.4.3 fails to emerge

[Andrew Hoffman]

lapy andy # cat /var/lib/layman/make.conf
PORTDIR_OVERLAY="
/var/lib/layman/gamerlay
/var/lib/layman/games
/var/lib/layman/java-overlay
$PORTDIR_OVERLAY
"

I attached the other logs.

I also remerged libgee no change

Thanks,
-Andy


On Sun, Apr 7, 2013 at 11:50 PM, Walter Dnes  wrote:

> On Sun, Apr 07, 2013 at 09:49:57PM -0500, Andrew Hoffman wrote
>
> > I have also rebuilt telepathy-glib debus-glib and gio with no change
> > in folks. gee does not appear to be a package.
>
>   I tried...
>
> USE="vala vapigen introspection" emerge -pv folks
>
> on my system.  It gives...
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild  N ] dev-libs/gobject-introspection-1.32.1  USE="-doc -doctool
> {-test}" 0 kB
> [ebuild  N ] dev-lang/vala-0.12.1-r1:0.12  USE="vapigen {-test}" 2,233
> kB
> [ebuild  N ] sys-apps/dbus-1.6.8  USE="X -debug -doc (-selinux)
> -static-libs {-test}" 1,885 kB
> [ebuild  N ] dev-lang/vala-0.18.1:0.18  USE="vapigen {-test}" 0 kB
> [ebuild  N ] dev-libs/dbus-glib-0.100.2  USE="-debug -doc -static-libs
> {-test}" 732 kB
> [ebuild  N ] dev-libs/libgee-0.6.7  USE="introspection" 494 kB
> [ebuild  N ] net-libs/telepathy-glib-0.20.1-r1  USE="introspection
> vala -debug {-test}" PYTHON_TARGETS="python2_7 -python2_5 -python2_6" 3,668
> kB
> [ebuild  N ] dev-libs/folks-0.4.3  USE="-debug" 621 kB
>
>   I think that "gee" refers to dev-libs/libgee.  Can you give the output
> of "emerge --info"?  I notice that you also have the line...
>
> source /var/lib/layman/make.conf
>
> ...in your make.conf.  It may be over-riding stuff in your regular
> make.conf.  "emerge --info" will tell us what you have in total.
> But a listing of /var/lib/layman/make.conf might still help us.
>
>   Another potential issue... in my make.conf I have...
>
> PYTHON_TARGETS="python2_7"
> PYTHON_SINGLE_TARGET="python2_7"
>
> YES!!! I need both of them.  I don't see them in your make.conf, unless
> they're in the /var/lib/layman/make.conf
>
> --
> Walter Dnes 
> I don't run "desktop environments"; I run useful applications
>
>
andy@lapy ~ $ sudo su
lapy andy # revdep-rebuild -p
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries broken by a package update
 * will be emerged.

 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Collecting complete LD_LIBRARY_PATH
 * Generated new 2_ldpath.rr
 * Checking dynamic linking consistency
[ 11% ]  *   broken /usr/bin/empathy (requires libtelepathy-logger.so.2)
 *   broken /usr/bin/empathy-accounts (requires libtelepathy-logger.so.2)
 *   broken /usr/bin/empathy-debugger (requires libtelepathy-logger.so.2)
[ 15% ]  *   broken /usr/bin/gnome-contacts (requires libebook-1.2.so.13
libedataserver-1.2.so.16)
[ 43% ]  *   broken 
/usr/lib/evolution/3.4/plugins/liborg-freedesktop-Tracker-evolution-plugin.so 
(requires libcamel-1.2.so.33
libedataserver-1.2.so.16
libemail-engine.so
libemail-utils.so
libeshell.so)
 *   broken /usr/lib/folks/32/backends/eds/eds.so (requires libebook-1.2.so.13
libedataserver-1.2.so.16)
[ 50% ]  *   broken /usr/lib/gnome-documents/libgdprivate-1.0.so (requires 
libevdocument3.so.4
libevview3.so.3
libgdata.so.13)
 *   broken /usr/lib/gnome-shell/libgnome-shell.so (requires libgcr-base-3.so.1
libgnome-menu-3.so.0
libtelepathy-logger.so.2)
[ 62% ]  *   broken /usr/lib/libfolks-eds.so.25.7.1 (requires libebook-1.2.so.13
libedataserver-1.2.so.16)
[ 70% ]  *   broken /usr/lib/libsushi-1.0.so.0.0.0 (requires libevdocument3.so.4
libevview3.so.3)
[ 76% ]  *   broken /usr/lib/nautilus-sendto/plugins/libnstempathy.so (requires 
libtelepathy-logger.so.2)
[ 91% ]  *   broken /usr/libexec/empathy-auth-client (requires 
libtelepathy-logger.so.2)
 *   broken /usr/libexec/empathy-av (requires libtelepathy-logger.so.2)
 *   broken /usr/libexec/empathy-call (requires libtelepathy-logger.so.2)
[ 92% ]  *   broken /usr/libexec/gd-tracker-gdata-miner (requires 
libgdata.so.13)
[ 95% ]  *   broken /usr/libexec/gnome-shell-calendar-server (requires 
libebook-1.2.so.13
libecal-1.2.so.11
libedataserver-1.2.so.16
libedataserverui-3.0.so.1)
[ 100% ] 
 * Generated new 3_broken.rr
 * Assigning files to packages
 *   /usr/bin/empathy -> net-im/empathy
 *   /usr/bin/empathy-accounts -> net-im/empathy
 *   /usr/bin/empathy-debugger -> net-im/empathy
 *   /usr/bin/gnome-contacts -> gnome-extra/gnome-contacts
 *   
/usr/lib/evolution/3.4/plugins/liborg-freedesktop-Tracker-evolution-plugin.so 
-> app-misc/tracker
 *   /usr/lib/folks/32/backends/eds/eds.so -> dev-libs/folks
 *   /usr/lib/gnome-documents/libgdprivate-1.0.so -> gnome-extra/gnome-documents
 *   /usr/lib/gnome-shell/libgnome-shell.so -> gnome-base/gnome-shell
 *   /usr/lib/libfolks-eds.so.25.7.1 -> dev-libs/folks
 *   /usr/lib/libsushi-1.0.so.0.0.0 -> gnome-extra/sushi
 *   /usr/lib/nautilus-sendto/plugins/libnstempathy.so -> net-im/empathy

Re: [gentoo-user] gcc-4.5.4 failed (install phase)

[Markos Chandras]

On 8 April 2013 02:13, Joseph  wrote:
> I'm getting an error re-compiling gcc-4.5.4
>
> o _dim_i16.o _dim_r4.o _dim_r8.o _dim_r10.o _dim_r16.o _atan2_r4.o
> _atan2_r8.o _atan2_r10.o _atan2_r16.o _mod_i4.o _mod_i8.o _mod_i16.o
> _mod_r4.o _mod_r8.o _mod_r10.o _mod_r16.o misc_specifics.o dprod_r8.o
> f2c_specifics.o
> libtool: link: /usr/i686-pc-linux-gnu/bin/ranlib .libs/libgfortran.a
> libtool: link: ( cd ".libs" && rm -f "libgfortran.la" && ln -s
> "../libgfortran.la" "libgfortran.la" )
> true  DO=all multi-do # make
> make[3]: Leaving directory
> `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/i686-pc-linux-gnu/libgfortran'
> make[2]: Leaving directory
> `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/i686-pc-linux-gnu/libgfortran'
> make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.4/work/build'
> /var/tmp/portage/sys-devel/gcc-4.5.4/work/build
> /var/tmp/portage/sys-devel/gcc-4.5.4/work/gcc-4.5.4
> cp: cannot stat
> ‘/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/gcc/doc/*.info’: No such
> file or directory

This is because of texinfo-5.1. There was already a bug about it

https://bugs.gentoo.org/show_bug.cgi?id=464008

Please sync your tree and try again

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang