Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 1, 2013 2:10 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 31/03/2013 20:26, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com 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, It's more accurate to say it worked by accident rather than by design. (Sort of like how the power utility gets power to your house - if yours is anything like mine I get power despite their best efforts to not give me any ...) Anyway, the old method sucked and it sort of works for you and I because we don't add anything ourselves that trip it up. But this new method... geez lads, I just dunno. How do Windows, Mac and Android deal with this stuff? They don't seem to have any device naming problems, so what is the magic solution in use on those platforms? I'm not sure about Macs and Android, but with Windows it all happens based on MAC address. I found about it quite accidentally; I had exported a VM from XenServer and imported it to a different host. By default, XenServer assigns a new, random MAC for imported VMs. Windows saw this and proceeded to initialize a new NIC. When I tried setting the IP settings, it complained that the settings are currently being used by an invisible NIC. So, I shut down the VM, restored the old MAC, and the prior settings reappeared. Rgds, --
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 21:34:51 +0100, Kevin Chadwick wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Fair point but wouldn't that be only if you plug in two of the same type that the names may switch? According to Flameyes' blog, if you have only one adaptor, its name will change according to the port used, which is a rather different definition of persistent than I have been used to. -- Neil Bothwick All mail what i send is thoughly proof-red, definately! signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Mon, 01 Apr 2013 03:02:51 +0200, Volker Armin Hemmann wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. congratulation, you just found another reason why today's udev sucks. I take no credit for it, Flameyes pointed that one out. -- Neil Bothwick Not one shred of evidence supports the notion that life is serious. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: I find the OpenBSD method of different names like fxp0 usefuk You can emulate that with suitable (e)udev rules. -- Neil Bothwick Computers are like Old Testament gods; lots of rules and no mercy. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Apr 1, 2013 1:54 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 31 Mar 2013 21:34:51 +0100, Kevin Chadwick wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Fair point but wouldn't that be only if you plug in two of the same type that the names may switch? According to Flameyes' blog, if you have only one adaptor, its name will change according to the port used, which is a rather different definition of persistent than I have been used to. -- Neil Bothwick All mail what i send is thoughly proof-red, definately! True, that. 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... Rgds, --
[gentoo-user] Re: ZFS wiki confusion
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
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/src/linux/.config | grep EXTRA_FIRMWARE CONFIG_EXTRA_FIRMWARE=radeon/R600_rlc.bin radeon/R700_rlc.bin
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
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
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
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
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...
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
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
On Mon, 1 Apr 2013 14:12:17 +0100 Neil Bothwick n...@digimed.co.uk 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
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
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?
On Sun, Mar 31, 2013 at 8:09 AM, Walter Dnes waltd...@waltdnes.org 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 mk.frag...@gmail.com 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
On Sun, 31 Mar 2013 18:37:07 + (UTC) Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com 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 https://wiki.gentoo.org/wiki/Udev/upgrade 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
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
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
On Mon, Apr 1, 2013 at 9:16 AM, Neil Bothwick n...@digimed.co.uk 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
On Mon, Apr 1, 2013 at 9:09 PM, Michael Mair-Keimberger m.mairkeimber...@gmail.com 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
Am 01.04.2013 18:59, schrieb Nilesh Govindrajan: On Mon, Apr 1, 2013 at 9:09 PM, Michael Mair-Keimberger m.mairkeimber...@gmail.com 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
On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com 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
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 rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com 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
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 rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com 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
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
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
