[gentoo-user] Re: ZFS wiki confusion

[Remy Blank]

Douglas J Hunley wrote:
> Do you really need to copy the files into the kernel tree?

No, you don't need to do that.

> which seems to pull in the daemon and the kmod so wouldn't the zfs-kmod
> ebuild build against the current kernel and drop in the modules
> directory all by itself much like any of the 100s of FUSE modules do?

Yes, it's enough to simply emerge the packages, and "modprobe zfs" (and
later add "zfs" to /etc/conf.d/modules). Works fine here.

(Not sure what FUSE has to do with it, though. FUSE filesystems don't
install any kernel modules.)

Just ignore the section "Installing into the kernel directory (for
static installs)" on that page, unless you have a very special install
(but then, you probably wouldn't have to ask here).

-- Remy



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Udev 200 : dhcpcd problem + solution

[Mick]

On Monday 01 Apr 2013 02:54:08 Philip Webb wrote:
> I've spent a lot of today trying to fix a glitch in starting 'dhcpcd'
> after upgrading to  udev-200 ; I outlined it in a msg to  gentoo-dev .
> 
> When I tried to start my I/net connection, I got this :
> 
>   root:501 ~> dhcpcd
> dhcpcd[831]: version 5.6.7 starting
> ... [delay]
> ^C
> ... [long delay]
> dhcpcd[831]: no interfaces have a carrier
> dhcpcd[831]: forked to background, child pid 857
> 
> So having killed it, I restarted & had no problem :
> 
>   root:502 ~> dhcpcd
> dhcpcd[866]: version 5.6.7 starting
> dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation
> dhcpcd[866]: enp5s0: rebinding lease of 192.168.1.2
> dhcpcd[866]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1
> dhcpcd[866]: enp5s0: checking for 192.168.1.2
> dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation
> dhcpcd[866]: enp5s0: leased 192.168.1.2 for 86400 seconds
> dhcpcd[866]: forked to background, child pid 884
> 
> Looking at  /var/log/syslog , I saw :
> 
>   13:11:16 dhcpcd[831]: version 5.6.7 starting
>   13:12:16 klogd: r8169 :05:00.0: enp5s0: unable to load firmware patch
> rtl_nic/rtl8168e-3.fw (-2) 13:12:16 klogd: r8169 :05:00.0: enp5s0:
> link down
>   13:12:16 klogd: r8169 :05:00.0: enp5s0: link down
>   13:12:16 klogd: IPv6: ADDRCONF(NETDEV_UP): enp5s0: link is not ready
>   13:12:17 dhcpcd[831]: no interfaces have a carrier
>   13:12:17 dhcpcd[831]: forked to background, child pid 857
>   13:12:17 dhcpcd[857]: received SIGINT, stopping
>   13:12:17 dhcpcd[857]: enp5s0: removing interface
>   13:12:18 klogd: r8169 :05:00.0: enp5s0: link up
>   13:12:18 klogd: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready
>   13:12:34 dhcpcd[866]: version 5.6.7 starting
>   13:12:34 dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation
>   13:12:34 dhcpcd[866]: enp5s0: rebinding lease of 192.168.1.2
>   13:12:34 dhcpcd[866]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1
>   13:12:34 dhcpcd[866]: enp5s0: checking for 192.168.1.2
>   13:12:38 dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation
>   13:12:39 dhcpcd[866]: enp5s0: leased 192.168.1.2 for 86400 seconds
>   13:12:39 dhcpcd[866]: forked to background, child pid 884
> 
> It seems that the new set-up with the device name created by the kernel
> requires the firmware to be built into the kernel.
> This is not mentioned in the recent news item.
> 
> Google led to a Gentoo Forum thread which was unusually helpful (grin):
> 
>   http://forums.gentoo.org/viewtopic-t-899002-start-0.html
> 
> This suggested the lines
> 
>   CONFIG_PREVENT_FIRMWARE_BUILD=y  [NB this is incorrect]
>   CONFIG_FIRMWARE_IN_KERNEL=y
>   CONFIG_EXTRA_FIRMWARE="rtl8168e-2.fw"  [NB I needed '-3']
>   CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> 
> I was using kernel 3.5.3 , so I updated to 3.8.5 & configured it :
> I had to change the 1st line to 'n' -- mb a typo in the original msg --
> & to change  .config  manually to add '/lib/' before 'firmware',
> which 'make menuconfig' insisted on using without allowing editing.
> The compile command is
> 
>   make && make firmware_install && make modules_install
> 
> Once the kernel was compiled + installed & I had rebooted, I got :
> 
>   root:501 ~> dhcpcd
> dhcpcd[834]: version 5.6.7 starting
> dhcpcd[834]: no interfaces have a carrier
> dhcpcd[834]: forked to background, child pid 846
> 
> & despite the 2nd line of output, the connection had been established.
> 
> 'syslog' now reads :
> 
>   dhcpcd[834]: version 5.6.7 starting
>   klogd: r8169 :05:00.0 enp5s0: link down
>   klogd: IPv6: ADDRCONF(NETDEV_UP): enp5s0: link is not ready
>   klogd: r8169 :05:00.0 enp5s0: link down
>   dhcpcd[834]: no interfaces have a carrier
>   dhcpcd[834]: forked to background, child pid 846
>   dhcpcd[846]: enp5s0: waiting for carrier
>   dhcpcd[846]: sit0: unsupported interface type 308, falling back to
> ethernet dhcpcd[846]: sit0: broadcasting for a lease
>   dhcpcd[846]: enp5s0: carrier acquired
>   klogd: r8169 :05:00.0 enp5s0: link up
>   klogd: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready
>   dhcpcd[846]: enp5s0: sending IPv6 Router Solicitation
>   dhcpcd[846]: enp5s0: sendmsg: Cannot assign requested address
>   dhcpcd[846]: enp5s0: rebinding lease of 192.168.1.2
>   dhcpcd[846]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1
>   dhcpcd[846]: enp5s0: checking for 192.168.1.2
>   dhcpcd[846]: enp5s0: sending IPv6 Router Solicitation
>   dhcpcd[846]: enp5s0: sending IPv6 Router Solicitation
>   dhcpcd[846]: enp5s0: leased 192.168.1.2 for 86400 seconds
> 
> I'm not sure what 'sit0' is, but it doesn't seem to affect the outcome.
> 
> HTH others who may face the same problem.

Thanks for sharing this Philip.  I was surprised to see that firmware for NICs 
are meant to be added in this kernel config option.  I thought that this 
config option was only for the video card firmware ...

# cat /usr/

Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack

[Mick]

On Monday 01 Apr 2013 04:37:50 luis jure wrote:
> on 2013-03-31 at 23:05 Michael Mol wrote:
> > On 03/31/2013 10:00 PM, Philip Webb wrote:
> > > There was a good story in 'Guardian' :
> > >   http://www.guardian.co.uk/commentisfree/2013/mar/29/cyberwar-spun-sho
> > >   ddy-journalism
> > 
> > The Gizmodo article that Guardian article lauds irritated the hell out
> > of me. [...]
> > Whether a chunk of Europe dropping offline qualifies as "breaking the
> > Internet" is an interesting question.
> 
> i don't live in europe. i live in a small country in south america. i don't
> read the press and i don't have tv. i'm mostly uncontaminated by the
> debris produced by journalism.
> 
> today i asked my girlfriend if she had also noted that the internet has
> been very slow for the last week or so. perhaps it was a problem with my
> connection. it was she who told me that the problem with the internet had
> been mentioned in the news (unlike me, she does watch tv and read the
> news).
> 
> i'm glad for all the people who weren't affected. but whatever it was, i've
> been suffering the consequences. so i'm more than irritated by the
> assholes minimizing the problem, or treating this as "non-news".

I can't say I had noticed any slowness, more than the usual, but I did notice 
that I could no longer reach a number of websites, like this:

  http://www.nslu2-linux.org

This lasted a day or two and coincided with this 'news' about DDoS, but I 
wasn't aware of it at the time.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

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

[Neil Bothwick]

On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote:

> I still don't understand what's so bad with MAC-based identification? I
> mean, uniqueness defined through MAC Address identity, the system name
> is just a label...

MAC addresses are not human-friendly. It would be OK if you could set up
aliases, so your firewall rules could use enaabbccddeeff while you could
still type eth0.


-- 
Neil Bothwick

Don't just read the Tagline; read the MESSAGE!


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: ZFS wiki confusion

[Neil Bothwick]

On Mon, 01 Apr 2013 10:09:05 +0200, Remy Blank wrote:

> Just ignore the section "Installing into the kernel directory (for
> static installs)" on that page, unless you have a very special install
> (but then, you probably wouldn't have to ask here).

Yes, you only need that if you want the modules built into the
kernel. The zfs and spl sources include scripts to install to any kernel
tree, just unpack each source tarbal, cd into the appropriate directory
and run

./configure --enable-linux-builtin --with-linux=/usr/src/linux
./copy-builtin /usr/src/linux
  
for each.


-- 
Neil Bothwick

I am McCoy of Bo...Damnit! I'm a doctor, not a collective!


signature.asc
Description: PGP signature

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

[Neil Bothwick]

On Sun, 31 Mar 2013 16:19:18 -0400, Tanstaafl wrote:

> > What the article didn't mention was that if you change your interface
> > names, you have to create a new symlink in /etc/init.d and add it to
> > the default runlevel. I'm glad I spotted that one before rebooting:)  
> 
> So, just
> 
> ln -s net.net0 -> net.lo
> 
> Then after reboot, you can rm net.eth0 -> net.lo ?

You also need to "rc-update add net.net0 default"


-- 
Neil Bothwick

WinErr 003: Dynamic linking error - Your mistake is now in every file


signature.asc
Description: PGP signature

Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...

[Neil Bothwick]

On Sun, 31 Mar 2013 16:24:33 -0400, Tanstaafl wrote:

> > No, you only do that if the original is not available. Copy the whole
> > sys-fs/udev directory to your overlay then remove the files you don't
> > need  
> 
> Well, that presupposes I know what files I need and what files I don't 
> need...
> 
> The problem is I don't...
> 
> I can *guess* that all I need is the ebuild file, the files dir, and 
> maybe the Manifest and metadata.xml files...

Just delete the unneeded ebuilds, there may be other unnecessary files
but they won't do any harm (unless your filesystem is already 99% full).

> > and rebuild the manifest.  
> 
> Ok, I've done this, but it still wants to install udev-200... it also 
> mentions, and I confirmed, that udev-171 is masked in 
> /usr/portage/profiles/package.mask, so, presumably, I need to comment 
> these out too?

What you need to do is read man portage. Any changes to files
in /usr/portage will be wiped out next time you sync, you need to make
changes in /etc/portage, as detailed in the man page.


-- 
Neil Bothwick

This is a test of the emergency tagline stealing system.


signature.asc
Description: PGP signature

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

[Michael Mol]

On 04/01/2013 09:12 AM, Neil Bothwick wrote:
> On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote:
> 
>> I still don't understand what's so bad with MAC-based identification? I
>> mean, uniqueness defined through MAC Address identity, the system name
>> is just a label...
> 
> MAC addresses are not human-friendly. It would be OK if you could set up
> aliases, so your firewall rules could use enaabbccddeeff while you could
> still type eth0.
> 
> 

Frankly, I never found 'eth0' to be particularly friendly, either. Hence
why I like naming my interfaces things like 'wan', 'wifilan' and 'wiredlan'.



signature.asc
Description: OpenPGP digital signature

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

[Kevin Chadwick]

On Mon, 1 Apr 2013 14:12:17 +0100
Neil Bothwick  wrote:

> > I still don't understand what's so bad with MAC-based
> > identification? I mean, uniqueness defined through MAC Address
> > identity, the system name is just a label...  
> 
> MAC addresses are not human-friendly. It would be OK if you could set
> up aliases, so your firewall rules could use enaabbccddeeff while you
> could still type eth0.

It used to be dead easy to link the MAC to the device type and number
from dmesg without looking up the MAC to Manufacturer codes. A lot of
useful information seems to have been removed from the linux dmesg?
atleast on 3.2 kernels.

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

[Neil Bothwick]

On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote:

> > MAC addresses are not human-friendly. It would be OK if you could set
> > up aliases, so your firewall rules could use enaabbccddeeff while you
> > could still type eth0.

> Frankly, I never found 'eth0' to be particularly friendly, either. Hence
> why I like naming my interfaces things like 'wan', 'wifilan' and
> 'wiredlan'.

Relative to 'lan' or 'wan', no, but relative to an embedded MAC address?


-- 
Neil Bothwick

I don't know if I can assimilate one more Borg Tagline!


signature.asc
Description: PGP signature

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

[Michael Mol]

On 04/01/2013 09:54 AM, Neil Bothwick wrote:
> On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote:
> 
>>> MAC addresses are not human-friendly. It would be OK if you could set
>>> up aliases, so your firewall rules could use enaabbccddeeff while you
>>> could still type eth0.
> 
>> Frankly, I never found 'eth0' to be particularly friendly, either. Hence
>> why I like naming my interfaces things like 'wan', 'wifilan' and
>> 'wiredlan'.
> 
> Relative to 'lan' or 'wan', no, but relative to an embedded MAC address?

Honestly, with IPv6, I get so accustomed to recognizing the last three
or four octets of MAC addresses, that idea is starting to grow on me,
too! It's like recognizing phone numbers, really. You eventually just
start remembering enough of the thing to be useful.

If the system isn't smart enough to apply a solid semantic name (like my
'wan', 'wifilan' or 'wiredlan'), I'd rather it not try to apply a
semantic name (eth0 or net0) at all. But you're hearing this come from a
C++ programmer turned network admin, so take that with a grain of salt. :)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Difference between --update and --emptytree?

[Paul Hartman]

On Sun, Mar 31, 2013 at 8:09 AM, Walter Dnes  wrote:
>> What do you mean by sane depclean? Are there any problems with
>> --depclean that I am not aware of?
>
>   emerge -p --depclean
>
> generates dire warnings.  I keep a previous version of the kernel
> (gentoo-sources) as a fallback, and --depclean wants to remove that,
> which I want to keep.

Quoted below is a solution that was posted to this list a few years
ago, I use it for exactly that situation: to prevent kernels from ever
getting depcleaned.

On Thu, Jun 11, 2009 at 11:45 AM, Mike Kazantsev  wrote:
>> So, my question: Is there a way to tell depclean to never remove *any*
>> version of gentoo-sources?
>
> That's where portage-2.2 sets find another use.
> Just add following set to /usr/share/portage/config/sets.conf:
>
>   [kernels]
>   class = portage.sets.dbapi.OwnerSet
>   world-candidate = False
>   files = /usr/src
>
> And append "@kernels" line to /var/lib/portage/world_sets
> Now any installed (even with -1) kernel should be safe from ravenous
> depclean.

Hope that helps!

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

[»Q«]

On Sun, 31 Mar 2013 18:37:07 + (UTC)
"Nuno J. Silva (aka njsg)"  wrote:

> On 2013-03-31, Dale  wrote:
> > Nuno J. Silva (aka njsg) wrote:
> >> On 2013-03-31, Dale  wrote:
> >>> Pandu Poluan wrote:
> 
> 
>  Since it's obvious that upsteam has this "my way or the highway"
>  mentality, I'm curious about whether eudev (and mdev) exhibits
>  the same behavior...
> 
> >>> I synced yesterday and I didn't see the news alert.   Last eudev
> >>> update was in Feb. so I *guess* not.  It seems to be a "udev"
> >>> thing.  That is why I mentioned eudev to someone else that was
> >>> having this issue with a server setup. 
> >> I'd guess eudev will eventually do the same, although I hope that,
> >> it being a separate codebase, makes it easier to adopt some
> >> solution like the old rule generator, instead of using udev's
> >> approach.
> >>
> >> The udev upstream may have its issues, but there's actually a
> >> point in removing this, the approach there was so far was just a
> >> dirty hack.
> >>
> >
> >
> > Thing is, it works for me.  The old udev worked, eudev works but
> > I'm not sure what hoops I would have to go through to get the new
> > udev working, most likely the same ones others here are going
> > through now.  For once, I'm not having to deal with some broken
> > issue.  < knock on wood > 
> >
> > My current uptime is about 190 days.  May hit it still but I'm
> > certainly hoping I don't. 
> 
> And, at least now, I have got enough knowledge to know whether it
> affects me or not. But the sad thing is that I got most of that
> knowledge *after* the first of these versions without the old script
> was stabilized.

Another sad thing is that if you want to find out about the option to
keep the old-style naming rules, Udev/upgrade page
 just links to bug 453494,
so instead of a guide, users get to read a bug entry with 94 comments
(and counting).

I went with the new persistent names because it seemed simpler and
because there was relatively clearer information about how it should be
done.

Once upon a time, for an upgrade like this, Gentoo would have produced
a guide summarizing the pros and cons of the two courses of actions
along with a recipe for each one.  (Or if not a recipe, at least a list
of all the considerations needed for each path.)

Re: [gentoo-user] Unable to compile chromium 26

[Michael Mair-Keimberger]

Look at bug 463550 [1]..

Either you downgrade to app-accessibility/speech-dispatcher-0.7.1-r2 or use 
the patch which is pointed out at the bug.

mike


1) https://bugs.gentoo.org/show_bug.cgi?id=463550


On Monday 01 April 2013 20:57:43 Nilesh Govindrajan wrote:
> I'm unable to compile chromium.
> It somewhere exits with not able to find libspeechd.h, but it exists
> in /usr/include/speech-dispatcher.
> 
> I have attached build log. Can anybody tell what's going wrong?
> 
> --
> Nilesh Govindrajan
> http://nileshgr.com

Re: [gentoo-user] Udev 200 : dhcpcd problem + solution

[Philip Webb]

130401 Mick wrote:
> On Monday 01 Apr 2013 02:54:08 Philip Webb wrote:
>> I've spent a lot of today trying to fix a glitch in starting 'dhcpcd'
>> after upgrading to  udev-200 ; I outlined it in a msg to  gentoo-dev .
 -- details snipped --
> Thanks for sharing this Philip.
> I was surprised to see that firmware for NICs 
> are meant to be added in this kernel config option.
> I thought that this config option was only for the video card firmware.
> 
>   # cat /usr/src/linux/.config | grep EXTRA_FIRMWARE
> CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/R700_rlc.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
> 
> In my /lib/firmware I have:
> 
>   # ls -la /lib/firmware/
> total 1448
> drwxr-xr-x  5 root root4096 Sep 14  2012 .
> drwxr-xr-x 14 root root   12288 Mar 31 09:26 ..
> drwxr-x---  2 root root4096 Feb  4  2012 b43
> drwxr-xr-x  2 root root4096 Sep 14  2012 intel-ucode
> -rw-r--r--  1 root root 1451687 Sep 14  2012 microcode.dat
> drwxr-xr-x  2 root root4096 Dec 31 09:58 radeon
> 
> and from dmesg I can see that all of these get loaded
> *without* being defined in the CONFIG_EXTRA_FIRMWARE= ...
> On this box in any case I do not have sys-kernel/linux-firmware installed,
> but have installed x11-drivers/radeon-ucode for the video card
> and net-wireless/b43-fwcutter for the wireless NIC.
> Are you saying that the correct way to go about this
> is to uninstall these packages
> and instead define the firmware in the kernel in CONFIG_EXTRA_FIRMWARE= ?
> PS. I'm currently running kernel-3.7.10-gentoo.

No, if your way works, keep doing it.
I installed 'linux-firmware' long ago, but may not have used it since.

I was faced with the peculiar problem I described,
ie after updating to  udev-200  & following the news-item advice
the 1st attempt at 'dhcpcd' stalled, but a 2nd attempt always worked.
Not wanting to face this delay every time I reboot,
I investigated with the results described.
'dhcpcd' is now noticeably quicker than with  <= udev-197
& the new kernel naming system seems a small general improvement,
so my advice wb to update to  udev-200  & then solve any other problems.

I assume the underlying problem for me was
that the kernel took time trying to find the firmware
& meanwhile the Dhcpcd process went to sleep or froze.
Now that the firmware is compiled into the kernel, there's no delay.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Re: ZFS wiki confusion

[Douglas J Hunley]

On Mon, Apr 1, 2013 at 9:16 AM, Neil Bothwick  wrote:

> On Mon, 01 Apr 2013 10:09:05 +0200, Remy Blank wrote:
>
> > Just ignore the section "Installing into the kernel directory (for
> > static installs)" on that page, unless you have a very special install
> > (but then, you probably wouldn't have to ask here).
>
> Yes, you only need that if you want the modules built into the
> kernel. The zfs and spl sources include scripts to install to any kernel
> tree, just unpack each source tarbal, cd into the appropriate directory
> and run
>
> ./configure --enable-linux-builtin --with-linux=/usr/src/linux
> ./copy-builtin /usr/src/linux
>
> for each.
>
>
ah! so the 'static' is a reference to non-modular kernel builds. got it.

-- 
Douglas J Hunley (doug.hun...@gmail.com)
Twitter: @hunleyd   Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

Re: [gentoo-user] Unable to compile chromium 26

[Nilesh Govindrajan]

On Mon, Apr 1, 2013 at 9:09 PM, Michael Mair-Keimberger
 wrote:
> Look at bug 463550 [1]..
>
>
>
> Either you downgrade to app-accessibility/speech-dispatcher-0.7.1-r2 or use
> the patch which is pointed out at the bug.
>
>
>
> mike
>
>
>
>
>
> 1) https://bugs.gentoo.org/show_bug.cgi?id=463550
>
>
>
>
>
> On Monday 01 April 2013 20:57:43 Nilesh Govindrajan wrote:
>
>> I'm unable to compile chromium.
>
>> It somewhere exits with not able to find libspeechd.h, but it exists
>
>> in /usr/include/speech-dispatcher.
>
>>
>
>> I have attached build log. Can anybody tell what's going wrong?
>
>>
>

Thanks a lot.
It's a bit weird that I couldn't find it when I searched for "chromium" on bgo.

Re: [gentoo-user] Unable to compile chromium 26

[Volker Armin Hemmann]

Am 01.04.2013 18:59, schrieb Nilesh Govindrajan:
> On Mon, Apr 1, 2013 at 9:09 PM, Michael Mair-Keimberger
>  wrote:
>> Look at bug 463550 [1]..
>>
>>
>>
>> Either you downgrade to app-accessibility/speech-dispatcher-0.7.1-r2 or use
>> the patch which is pointed out at the bug.
>>
>>
>>
>> mike
>>
>>
>>
>>
>>
>> 1) https://bugs.gentoo.org/show_bug.cgi?id=463550
>>
>>
>>
>>
>>
>> On Monday 01 April 2013 20:57:43 Nilesh Govindrajan wrote:
>>
>>> I'm unable to compile chromium.
>>> It somewhere exits with not able to find libspeechd.h, but it exists
>>> in /usr/include/speech-dispatcher.
>>> I have attached build log. Can anybody tell what's going wrong?
> Thanks a lot.
> It's a bit weird that I couldn't find it when I searched for "chromium" on 
> bgo.
>
>
ALL chromium

search in bugzillas really really sucks.

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

[William Hubbs]

On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
> Nuno J. Silva (aka njsg) wrote:
> > On 2013-03-31, Dale  wrote:
> >> Nuno J. Silva (aka njsg) wrote:
> >>> On 2013-03-31, Dale  wrote:
>  Pandu Poluan wrote:
> >
> > Since it's obvious that upsteam has this "my way or the highway"
> > mentality, I'm curious about whether eudev (and mdev) exhibits the
> > same behavior...
> >
>  I synced yesterday and I didn't see the news alert.   Last eudev update
>  was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>  why I mentioned eudev to someone else that was having this issue with a
>  server setup. 
> >>> I'd guess eudev will eventually do the same, although I hope that, it
> >>> being a separate codebase, makes it easier to adopt some solution like
> >>> the old rule generator, instead of using udev's approach.
> >>>
> >>> The udev upstream may have its issues, but there's actually a point in
> >>> removing this, the approach there was so far was just a dirty hack.
> >>>
> >>
> >> Thing is, it works for me.  The old udev worked, eudev works but I'm not
> >> sure what hoops I would have to go through to get the new udev working,
> >> most likely the same ones others here are going through now.  For once,
> >> I'm not having to deal with some broken issue.  < knock on wood > 
> >>
> >> My current uptime is about 190 days.  May hit it still but I'm certainly
> >> hoping I don't. 
> > And, at least now, I have got enough knowledge to know whether it
> > affects me or not. But the sad thing is that I got most of that
> > knowledge *after* the first of these versions without the old script was
> > stabilized.
> >
> 
> 
> I switched to eudev when the separate /usr thing popped up.  While I am
> watching this thread and sort of taking mental notes, I'm hoping this is
> not a eudev thing, even in the future. 

You know that both udev and eudev have exactly the same issue with
separate /usr right?

The problem there isn't in the udev code, but it has to do with what is
happening in rules that other packages install.

William



pgpMndIm0sIM4.pgp
Description: PGP signature

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

[Michael Mol]

On 04/01/2013 03:26 PM, William Hubbs wrote:
> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
>> Nuno J. Silva (aka njsg) wrote:
>>> On 2013-03-31, Dale  wrote:
 Nuno J. Silva (aka njsg) wrote:
> On 2013-03-31, Dale  wrote:
>> Pandu Poluan wrote:
>>>
>>> Since it's obvious that upsteam has this "my way or the highway"
>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>> same behavior...
>>>
>> I synced yesterday and I didn't see the news alert.   Last eudev update
>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>> why I mentioned eudev to someone else that was having this issue with a
>> server setup. 
> I'd guess eudev will eventually do the same, although I hope that, it
> being a separate codebase, makes it easier to adopt some solution like
> the old rule generator, instead of using udev's approach.
>
> The udev upstream may have its issues, but there's actually a point in
> removing this, the approach there was so far was just a dirty hack.
>

 Thing is, it works for me.  The old udev worked, eudev works but I'm not
 sure what hoops I would have to go through to get the new udev working,
 most likely the same ones others here are going through now.  For once,
 I'm not having to deal with some broken issue.  < knock on wood > 

 My current uptime is about 190 days.  May hit it still but I'm certainly
 hoping I don't. 
>>> And, at least now, I have got enough knowledge to know whether it
>>> affects me or not. But the sad thing is that I got most of that
>>> knowledge *after* the first of these versions without the old script was
>>> stabilized.
>>>
>>
>>
>> I switched to eudev when the separate /usr thing popped up.  While I am
>> watching this thread and sort of taking mental notes, I'm hoping this is
>> not a eudev thing, even in the future. 
> 
> You know that both udev and eudev have exactly the same issue with
> separate /usr right?
> 
> The problem there isn't in the udev code, but it has to do with what is
> happening in rules that other packages install.

As I recall, the problem is where the ebuild choses to install the code.
Putting the udev code under /usr forces the issue on systems where it
would otherwise not be an issue.

Putting the udev code under / avoids that issue, but opens up the system
to the "silently fail" thing upstream liked to use as the basis of
"separate /usr is broken"

So, there are three conceivable configurations (initramfs notwithstanding):

1. With systems which don't require /usr binaries before /usr would be
mounted, separate /usr is not a problem.

2. With systems which require /usr binaries for some features before
/usr would be mounted, those features will silently fail.

3. With systems which require /usr binaries to mount /usr, all hell
breaks loose.

Putting the udev code under /usr moves all udev systems from group 2
into group 3. In a sense, this fixes those systems because the admin is
forced to address the silent failures he was previously unaware of. It
also means pissing off a bunch of people who had features silently
failing...but they probably didn't know or care about those features in
the first place.

It also moves all systems from group 1 into group 3...which is simply wrong.

So long as eudev keeps its install path at / instead of /usr, admins in
group 1 will probably be perfectly happy.



signature.asc
Description: OpenPGP digital signature

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

[Dale]

Michael Mol wrote:
> On 04/01/2013 03:26 PM, William Hubbs wrote:
>> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
>>> Nuno J. Silva (aka njsg) wrote:
 On 2013-03-31, Dale  wrote:
> Nuno J. Silva (aka njsg) wrote:
>> On 2013-03-31, Dale  wrote:
>>> Pandu Poluan wrote:

 Since it's obvious that upsteam has this "my way or the highway"
 mentality, I'm curious about whether eudev (and mdev) exhibits the
 same behavior...

>>> I synced yesterday and I didn't see the news alert.   Last eudev
update
>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing. 
That is
>>> why I mentioned eudev to someone else that was having this issue
with a
>>> server setup.
>> I'd guess eudev will eventually do the same, although I hope that, it
>> being a separate codebase, makes it easier to adopt some solution
like
>> the old rule generator, instead of using udev's approach.
>>
>> The udev upstream may have its issues, but there's actually a
point in
>> removing this, the approach there was so far was just a dirty hack.
>>
>
> Thing is, it works for me.  The old udev worked, eudev works but
I'm not
> sure what hoops I would have to go through to get the new udev
working,
> most likely the same ones others here are going through now.  For
once,
> I'm not having to deal with some broken issue.  < knock on wood >
>
> My current uptime is about 190 days.  May hit it still but I'm
certainly
> hoping I don't.
 And, at least now, I have got enough knowledge to know whether it
 affects me or not. But the sad thing is that I got most of that
 knowledge *after* the first of these versions without the old
script was
 stabilized.

>>>
>>>
>>> I switched to eudev when the separate /usr thing popped up.  While I am
>>> watching this thread and sort of taking mental notes, I'm hoping this is
>>> not a eudev thing, even in the future.
>>
>> You know that both udev and eudev have exactly the same issue with
>> separate /usr right?
>>
>> The problem there isn't in the udev code, but it has to do with what is
>> happening in rules that other packages install.
>
> As I recall, the problem is where the ebuild choses to install the code.
> Putting the udev code under /usr forces the issue on systems where it
> would otherwise not be an issue.
>
> Putting the udev code under / avoids that issue, but opens up the system
> to the "silently fail" thing upstream liked to use as the basis of
> "separate /usr is broken"
>
> So, there are three conceivable configurations (initramfs
notwithstanding):
>
> 1. With systems which don't require /usr binaries before /usr would be
> mounted, separate /usr is not a problem.
>
> 2. With systems which require /usr binaries for some features before
> /usr would be mounted, those features will silently fail.
>
> 3. With systems which require /usr binaries to mount /usr, all hell
> breaks loose.
>
> Putting the udev code under /usr moves all udev systems from group 2
> into group 3. In a sense, this fixes those systems because the admin is
> forced to address the silent failures he was previously unaware of. It
> also means pissing off a bunch of people who had features silently
> failing...but they probably didn't know or care about those features in
> the first place.
>
> It also moves all systems from group 1 into group 3...which is simply
wrong.
>
> So long as eudev keeps its install path at / instead of /usr, admins in
> group 1 will probably be perfectly happy.
>


+1  Happy I am.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack

[Volker Armin Hemmann]

Am 01.04.2013 01:12, schrieb walt:
> Any of you admin types out there have any grumpy thoughts about this
> article? :)  Is it really just marketing BS from cloudflare, or is it
> solid stuff?
>
> http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
>
>
>
well, it was bad for spamhaus and London's inet traffic was higher than
normal - and that was it. No danger, no slowdowns (apart from LINX)
but the media made a huge fuss about it.

If it helps to take down spammer friendly hosters, it was worth it.

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

[Peter Humphrey]

On Monday 01 April 2013 20:51:45 Michael Mol wrote:

--->8

> So, there are three conceivable configurations (initramfs
> notwithstanding):

What a fine word! It's a while since I saw it last.

> 1. With systems which don't require /usr binaries before /usr would be
> mounted, separate /usr is not a problem.

I'm in that group, I'm glad to be able to say. The most important para to me 
in the news item was: "The feature can also be completely disabled using 
net.ifnames=0 on the kernel command line." I just added that to my grub.conf 
entries and I sail blissfully on with eth0. Of course this is a simple 
desktop box with a static network topology; on a less simple setup things 
would differ. Maybe I've left a hostage to fortune, but it'll do for now.

--->8

-- 
Peter