Re: [gentoo-user] pgo not selected for firefox 18
I had noticed it a while ago, it appears to be hardmasked: # Jory A. Pratt anar...@gentoo.org (15 Dec 2012) # PGO is known to be busted with most configurations www-client/firefox pgo I never had a single problem with it, so I'm going to unmask it and see if anything breaks. I just commented that out in /usr/portage/profiles/base/package.use.mask and it compiled fine with pgo and lto using 4.7.2. Ricey...
[gentoo-user] gnustep-base/gnustep-base-1.24.0-r1 fails to merge.....
Hi people! After updating my entire world I have problems emergeing gnustep-base (revdep-rebuild). I get the error on the screen and I am not getting smart how to solve it, and ideas?!: checking whether objc really works... no I don't seem to be able to use your Objective-C compiler to produce working binaries! Please check your Objective-C compiler installation. If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc can be found by the dynamic linker - usually that requires you to play with LD_LIBRARY_PATH or /etc/ld.so.conf. Please refer to your compiler installation instructions for more help. configure: error: The Objective-C compiler does not work or is not installed properly.
Re: [gentoo-user] Re: LVM hangs at startup
On Thu, Jan 10 2013, Sascha Cunz wrote: Am Donnerstag, 10. Januar 2013, 13:52:58 schrieb Stefan G. Weichinger: Am 10.01.2013 12:49, schrieb Stefan G. Weichinger: Does anyone else see boot problems as well? I re-configured my kernel and rebooted ... system stops/waits at Setting up the Logical Volume Manager. OK, turned off box and chose an older kernel to get things running again, but it stops there even with other untouched kernels. Maybe it is related to the latest udev update? Downgraded to udev-196-r1, system boots again. Gotta check what to re-emerge after upgrading to udev-197. S After an `emerge -1 lvm2` my systems were booting again, without downgrading udev. HTH, Sascha It did indeed help. My system hung at boot during LVM. Thankfully a cntl-C finished the book, then emerge -1 lvm2; reboot and all is well. Thanks for posting. allan
[gentoo-user] udev-197 moves from /usr/lib to /lib
This seems to me like very happy news indeed, but I'm interested in contrary opinions. There's a recent thread discussing how udev-197 breaks lvm2, but that's a trivial fix once you know about it. The problem is caused because many apps including lvm2 install their udev config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the first place IMO) and they should instead now go in /lib/udev/rules.d/. All you need to do is to re-emerge all of those packages *after* installing udev-197 and the config scripts will go in the correct place. You should do this before rebooting the machine because lvm2 won't work until its udev scripts are in the correct directory. Doesn't this seem to fix the problem with booting a separate /usr partition?
[gentoo-user] Re: gnustep-base/gnustep-base-1.24.0-r1 fails to merge.....
On 01/11/2013 05:24 AM, Tamer Higazi wrote: Hi people! After updating my entire world I have problems emergeing gnustep-base (revdep-rebuild). I get the error on the screen and I am not getting smart how to solve it, and ideas?!: checking whether objc really works... no I don't seem to be able to use your Objective-C compiler to produce working binaries! Please check your Objective-C compiler installation. If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc can be found by the dynamic linker - usually that requires you to play with LD_LIBRARY_PATH or /etc/ld.so.conf. Please refer to your compiler installation instructions for more help. configure: error: The Objective-C compiler does not work or is not installed properly. Didn't know anyone still uses objective-c :) Do you have the objc useflag set? The purpose is to add objective-c support to gcc.
Re: [gentoo-user] gnustep-base/gnustep-base-1.24.0-r1 fails to merge.....
2013/1/11 Tamer Higazi th9...@googlemail.com Hi people! After updating my entire world I have problems emergeing gnustep-base (revdep-rebuild). I get the error on the screen and I am not getting smart how to solve it, and ideas?!: checking whether objc really works... no I don't seem to be able to use your Objective-C compiler to produce working binaries! Please check your Objective-C compiler installation. If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc can be found by the dynamic linker - usually that requires you to play with LD_LIBRARY_PATH or /etc/ld.so.conf. Please refer to your compiler installation instructions for more help. configure: error: The Objective-C compiler does not work or is not installed properly. Can you compile other programs? If you updated gcc don't forget to switch your version with gcc-config. -- Mit freundlichen Grüßen / Best regards Randolph Maaßen
Re: [gentoo-user] pgo not selected for firefox 18
Am 11.01.2013 13:00, schrieb Adam Carter: I had noticed it a while ago, it appears to be hardmasked: # Jory A. Pratt anar...@gentoo.org mailto:anar...@gentoo.org (15 Dec 2012) # PGO is known to be busted with most configurations www-client/firefox pgo I never had a single problem with it, so I'm going to unmask it and see if anything breaks. I just commented that out in /usr/portage/profiles/base/package.use.mask and it compiled fine with pgo and lto using 4.7.2. Ricey... I guess you didn't have problems because you haven't used stable GCC. pgo was broken in gcc-4.5 since firefox-16 See https://bugs.gentoo.org/show_bug.cgi?id=439244 Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Tue, Jan 8, 2013 at 7:22 PM, Dale rdalek1...@gmail.com wrote: SNIP I have a better question. Why is a 82 year old woman using Gentoo? If she installed Gentoo, updated Gentoo then she must be able to do something with Gentoo, right? Dale Sorry for this Dale, but if this list gets to the end of the year and finds a less well thought out question than the one you just asked then I'll be surprised. Unfortunately I won't be here to read it if it comes along. To answer your question Dale, that 82 year old woman uses Gentoo because it's what I put on her laptop. It's the perfect OS for someone who does limited web browsing browser-based email. (GMail/Hotmail) With that I bid this list goodbye. I made it almost 10 years on the list, and have run Gentoo almost exclusively for longer than that. Yeah, I've loaded and tried other distros along the way, Fedora, Funtoo are the two I remember, but none have compared. This list has helped me to no end and I thank everyone for that. Should anyone want to get in touch please do. (FirstLast@gmail) Cheers goodbye, Mark
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 9:04 AM, walt w41...@gmail.com wrote: This seems to me like very happy news indeed, but I'm interested in contrary opinions. There's a recent thread discussing how udev-197 breaks lvm2, but that's a trivial fix once you know about it. The problem is caused because many apps including lvm2 install their udev config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the first place IMO) and they should instead now go in /lib/udev/rules.d/. All you need to do is to re-emerge all of those packages *after* installing udev-197 and the config scripts will go in the correct place. You should do this before rebooting the machine because lvm2 won't work until its udev scripts are in the correct directory. I dealt with this yesterday and was a little annoyed that the note detailing this didn't include an example of *how* to identify which packages needed re-emerged. I figured it out, but i can forsee a lot of pain on this front from the general user base (everyone on this list shouldn't have a problem with it, imho). Doesn't this seem to fix the problem with booting a separate /usr partition? I was wondering the same thing. It would seem to.. -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: douglasjhunley.com G+: http://goo.gl/sajR3
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
Mark Knecht wrote: On Tue, Jan 8, 2013 at 7:22 PM, Dale rdalek1...@gmail.com wrote: SNIP I have a better question. Why is a 82 year old woman using Gentoo? If she installed Gentoo, updated Gentoo then she must be able to do something with Gentoo, right? Dale Sorry for this Dale, but if this list gets to the end of the year and finds a less well thought out question than the one you just asked then I'll be surprised. Unfortunately I won't be here to read it if it comes along. To answer your question Dale, that 82 year old woman uses Gentoo because it's what I put on her laptop. It's the perfect OS for someone who does limited web browsing browser-based email. (GMail/Hotmail) With that I bid this list goodbye. I made it almost 10 years on the list, and have run Gentoo almost exclusively for longer than that. Yeah, I've loaded and tried other distros along the way, Fedora, Funtoo are the two I remember, but none have compared. This list has helped me to no end and I thank everyone for that. Should anyone want to get in touch please do. (FirstLast@gmail) Cheers goodbye, Mark But she doesn't do the updates, you do. Why is she worried about breaking something when I would hope you would test things to make sure it works. If my Mom were to start using a computer, she's about to be 80, she would not be doing any updates or anything. I would be doing that and fixing whatever breaks in the process. The question is a good question since most people that age are not likely to be running Gentoo Linux and doing the updates themselves. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 11/01/13 16:04, walt wrote: This seems to me like very happy news indeed, but I'm interested in contrary opinions. There's a recent thread discussing how udev-197 breaks lvm2, but that's a trivial fix once you know about it. The problem is caused because many apps including lvm2 install their udev config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the first place IMO) and they should instead now go in /lib/udev/rules.d/. All you need to do is to re-emerge all of those packages *after* installing udev-197 and the config scripts will go in the correct place. You should do this before rebooting the machine because lvm2 won't work until its udev scripts are in the correct directory. Running this command (all in one line): emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) should re-emerge all packages that still have files there. After that, /usr/lib/udev should no longer exist. If it still does, then there are files in it that don't belong to any package. Check them manually and delete them as needed or move them over. Then delete /usr/lib/udev.
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
Am 11.01.2013 16:14, schrieb Nikos Chantziaras: Running this command (all in one line): emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) should re-emerge all packages that still have files there. After that, /usr/lib/udev should no longer exist. If it still does, then there are files in it that don't belong to any package. Check them manually and delete them as needed or move them over. Then delete /usr/lib/udev. phew, that lists quite a list of packages here: [ebuild R] sys-fs/fuse-2.9.2 [ebuild R] media-gfx/sane-backends-1.0.23 [ebuild R] sys-apps/hwids-20130108 [ebuild R] media-sound/alsa-utils-1.0.26-r1 [ebuild R] media-libs/libmtp-1.1.5 [ebuild R] media-libs/libgphoto2-2.5.0 [ebuild R] sys-fs/ntfs3g-2012.1.15-r2 [ebuild R] sys-libs/libosinfo-0.2.2 [ebuild R] net-wireless/crda-1.1.2-r4 [ebuild R] sys-fs/mdadm-3.2.6 [ebuild R] x11-drivers/nvidia-drivers-310.19 [ebuild R] sys-auth/consolekit-0.4.5_p20120320-r1 [ebuild R] x11-misc/colord-0.1.26-r1 [ebuild R] sys-power/upower-0.9.19 [ebuild R] sys-fs/udisks-1.0.4-r4 [ebuild R] app-admin/system-config-printer-common-1.3.12 [ebuild R] sys-fs/udisks-2.0.91 [ebuild R] net-print/hplip-3.12.11 [ebuild R] net-wireless/bluez-4.101-r5 [ebuild R] net-misc/networkmanager-0.9.6.4 [ebuild R] sys-fs/udev-init-scripts-19 [ebuild R] net-wireless/gnome-bluetooth-3.6.1 [ebuild R] media-sound/pulseaudio-3.0 USE=(-neon) [ebuild R] app-emulation/qemu-1.2.1 USE=(-selinux) [ebuild R] app-emulation/vmware-modules-271.1-r1 Stefan
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 8:04 AM, walt w41...@gmail.com wrote: This seems to me like very happy news indeed, but I'm interested in contrary opinions. There's a recent thread discussing how udev-197 breaks lvm2, but that's a trivial fix once you know about it. The problem is caused because many apps including lvm2 install their udev config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the first place IMO) and they should instead now go in /lib/udev/rules.d/. All you need to do is to re-emerge all of those packages *after* installing udev-197 and the config scripts will go in the correct place. You should do this before rebooting the machine because lvm2 won't work until its udev scripts are in the correct directory. Doesn't this seem to fix the problem with booting a separate /usr partition? No, because the problem has never been in udev (nor systemd, for that matter). It fixes how *Gentoo* packages udev; probably the devs read the following comment from Lennart (note it was written almost a month ago): https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3 Certainly, =sys-fs/udev-171-r9 didn't use --with-rootprefix in the ebuilds. That's the reason Greg and many others were so dubious about eudev: one of the primary reasons for the fork to exist is supposedly to support a separate /usr without an initramfs... but that has *always* been supported by udev. And systemd, for that matter. systemd/udev prints a warning if it doesn't finds /usr at early boot, but both work in such configuration without any problem (if configured properly by the distribution, which apparently in Gentoo's case wasn't true). So, no, it doesn't fix the separate /usr problem, because that has never been a problem of udev nor systemd. And it's not going to be fixed by eudev either, for the same reason. But it fixes how udev it's packaged in Gentoo, which is very good news. I haven't upgraded, since I need systemd-197 also (which wasn't yet in the tree yesterday), and I don't use LVM, but I'm wondering if the LVM problem happens when you use an initramfs. I'm guessing it doesn't, since udev should read rules from /lib/udev/rules.d AND /usr/lib/udev/rules.d. 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: udev-197 moves from /usr/lib to /lib
Am 11.01.2013 16:14, schrieb Nikos Chantziaras: Running this command (all in one line): emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) should re-emerge all packages that still have files there. After that, /usr/lib/udev should no longer exist. If it still does, then there are files in it that don't belong to any package. Check them manually and delete them as needed or move them over. Then delete /usr/lib/udev. on my thinkpad I had app-laptop/laptop-mode-tools which had its 99-mode-laptop-mode.rules in /usr/lib/udev/rules.d even after re-emerging. moved that file manually ... Should that be filed as a bug? Stefan
[gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 11/01/13 19:51, Stefan G. Weichinger wrote: Am 11.01.2013 16:14, schrieb Nikos Chantziaras: Running this command (all in one line): emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) should re-emerge all packages that still have files there. After that, /usr/lib/udev should no longer exist. If it still does, then there are files in it that don't belong to any package. Check them manually and delete them as needed or move them over. Then delete /usr/lib/udev. on my thinkpad I had app-laptop/laptop-mode-tools which had its 99-mode-laptop-mode.rules in /usr/lib/udev/rules.d even after re-emerging. moved that file manually ... Should that be filed as a bug? Most probably yes.
[gentoo-user] Gigabyte wont boot
Hello, First system build with a Gigabyte mobo. I never got a motherboard install book and cannot seem to find any docs on installing a new 990FXA-UD3 with a FX8350 and ram installed. Everything is new and I have built many PCs before I got the new system put together physically. I'm trying to boot into the bios. The Blueray burner opens and closes and I put the newest liveDVD inside but no boot. No signal to the monitor. The fans all run, the BR burner opens and closes, but the motherboard will not boot. I first tried a known good pci video card (ATI) and now a new fanless video card (ASUS Direct CU Silent Radeon HD 7750). I tried different slots with the video cards. Is there a listing of jumpers or other install tips that I can find somewhere for this mobo? I meticulously connected everything, as this is not my first RODEO. I've never had a new mobo in the box without the little install guide book.bummer . ideas?wikis?docs? James
Re: [gentoo-user] Gigabyte wont boot
James wrote: Hello, First system build with a Gigabyte mobo. I never got a motherboard install book and cannot seem to find any docs on installing a new 990FXA-UD3 with a FX8350 and ram installed. Everything is new and I have built many PCs before I got the new system put together physically. I'm trying to boot into the bios. The Blueray burner opens and closes and I put the newest liveDVD inside but no boot. No signal to the monitor. The fans all run, the BR burner opens and closes, but the motherboard will not boot. I first tried a known good pci video card (ATI) and now a new fanless video card (ASUS Direct CU Silent Radeon HD 7750). I tried different slots with the video cards. Is there a listing of jumpers or other install tips that I can find somewhere for this mobo? I meticulously connected everything, as this is not my first RODEO. I've never had a new mobo in the box without the little install guide book.bummer . ideas?wikis?docs? James I would start here: http://www.gigabyte.us/products/product-page.aspx?pid=3996#manual That should get you a manual. That should help a bit anyway. Does it beep? If so, is it the normal beep or a error code beep? If error code, then check to see if it sheds light on the problem. I would also unplug, give the connectors a good looking over then plug it back up. I'd do that for everything I could. It may also help to reset the BIOS too. There should be a jumper pretty close to the battery or just remove the battery for a little while, overnight maybe. It could be that it has some garbage or something in it from sitting on a shelf, shipping jiggle etc etc. The only other thing I can think of, does the BIOS version support that CPU? I have always wondered what would happen if you put a CPU on a mobo that the BIOS doesn't support but would with a newer BIOS. I *think* the BIOS version is on the box with the serial number and such. Hope that helps. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 01/11/2013 09:14 AM, Nikos Chantziaras wrote: On 11/01/13 16:04, walt wrote: This seems to me like very happy news indeed, but I'm interested in contrary opinions. There's a recent thread discussing how udev-197 breaks lvm2, but that's a trivial fix once you know about it. The problem is caused because many apps including lvm2 install their udev config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the first place IMO) and they should instead now go in /lib/udev/rules.d/. All you need to do is to re-emerge all of those packages *after* installing udev-197 and the config scripts will go in the correct place. You should do this before rebooting the machine because lvm2 won't work until its udev scripts are in the correct directory. Running this command (all in one line): emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) should re-emerge all packages that still have files there. After that, /usr/lib/udev should no longer exist. If it still does, then there are files in it that don't belong to any package. Check them manually and delete them as needed or move them over. Then delete /usr/lib/udev. Thanks for the command line tip. I wasn't aware of the /lib/ move and would've had a handful of problems had I not read the list.
[gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 01/11/2013 07:14 AM, Nikos Chantziaras wrote: emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) qfile stopped working for me many weeks ago and I wish I could get it working again. All the other portage utils work normally, though. Any idea how to fix it?
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On Fri, 11 Jan 2013 11:52:14 -0800 walt w41...@gmail.com wrote: On 01/11/2013 07:14 AM, Nikos Chantziaras wrote: emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo =$p; done) qfile stopped working for me many weeks ago and I wish I could get it working again. All the other portage utils work normally, though. Any idea how to fix it? Error messages please -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 1/11/2013 09:14, Nikos Chantziaras wrote:
On 11/01/13 16:04, walt wrote:
This seems to me like very happy news indeed, but I'm interested in
contrary
opinions. There's a recent thread discussing how udev-197 breaks
lvm2, but
that's a trivial fix once you know about it.
The problem is caused because many apps including lvm2 install their udev
config scripts in /usr/lib/udev/rules.d/ (where they never belonged in
the
first place IMO) and they should instead now go in /lib/udev/rules.d/.
All you need to do is to re-emerge all of those packages *after*
installing
udev-197 and the config scripts will go in the correct place.
You should do this before rebooting the machine because lvm2 won't
work until
its udev scripts are in the correct directory.
Running this command (all in one line):
emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
echo =$p; done)
should re-emerge all packages that still have files there. After that,
/usr/lib/udev should no longer exist. If it still does, then there are
files in it that don't belong to any package. Check them manually and
delete them as needed or move them over. Then delete /usr/lib/udev.
Or, without a loop (easier to read and type, IMHO):
qfile -Cvq /usr/lib/udev | awk '{print =$1}' | xargs emerge -pv
or, using gentoolkit instead of portage-utils (slower, but will not fail
if the installed version of a package no longer exists):
equery belongs -n /usr/lib/udev | xargs emerge -pv
--
♫Dustin
Re: [gentoo-user] Gigabyte wont boot
On 2013-01-11 19:48, James wrote: Is there a listing of jumpers or other install tips that I can find somewhere for this mobo? I meticulously connected everything, as this is not my first RODEO. I've never had a new mobo in the box without the little install guide book.bummer . Are you sure it's a new mobo and not a replacement that someone had problems with and RMA'd it (and you got it instead)? I've had one of those... I've never seen a mobo without the install manual. It may of course also be brand new and still be D.O.A. Or some other parts may be faulty/incompatible (memory modules would be my first guess)... Btw, there seems to be two revisions of the mobo in question. At Gigabytes homepage you can find manuals for both. Best regards Peter K
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
Or, just:
:; find /var/db/pkg -name CONTENTS | xargs -0 grep -l /usr/lib/udev/ | awk -F/
'{print = $5 / $6}' | xargs emerge -pv
which should be fastest.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-user] Re: Gigabyte wont boot
Dale rdalek1967 at gmail.com writes: http://www.gigabyte.us/products/product-page.aspx?pid=3996#manual I got a second identical mobo delivered today, so now I have a book. Check the connectors to the Front panel, all is correct. The mobo is Rev. 1.1. Swapped out ram, too, just to test. Does it beep? NO. Would that suggest a dead mobo? The little speaker is attached but does not beep or anything.. The power supply is plugged into the mobo correctly. It's a new power supply and cables. If so, is it the normal beep or a error code beep? If error code, then check to see if it sheds light on the problem. I would also unplug, give the connectors a good looking over then plug it back up. I'd do that for everything I could. Yep, verified wiring 3 times. Might have a bad cable, so I'm going to replace them all one at a time and see if that makes any difference. The mobo is just not even trying to boot. No video signal to monitor. It may also help to reset the BIOS too. There should be a jumper pretty close to the battery or just remove the battery for a little while, overnight maybe. It could be that it has some garbage or something in it from sitting on a shelf, shipping jiggle etc etc. I shorted the 2 pins on the clr_cmos header, per the book for 4 second. That did not help. It was suppose to reset to factory defaults. . The only other thing I can think of, does the BIOS version support that CPU? I have always wondered what would happen if you put a CPU on a mobo that the BIOS doesn't support but would with a newer BIOS. I *think* the BIOS version is on the box with the serial number and such. The book does say the processor must be installed. This mobo is for the fx8350 so something is bad. I'm gonna build up the second machine and see what happens This mobo appears to be borked, right out of the box. any other ideas? James
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
James Cloos schrieb am 11.01.2013 21:30:
Or, just:
:; find /var/db/pkg -name CONTENTS | xargs -0 grep -l /usr/lib/udev/ | awk
-F/ '{print = $5 / $6}' | xargs emerge -pv
which should be fastest.
-JimC
Or emerge -av /usr/lib/udev. See man emerge 1
--
Regards
Daniel
signature.asc
Description: OpenPGP digital signature
[gentoo-user] Re: Gigabyte wont boot
pk peterk2 at coolmail.se writes: Are you sure it's a new mobo and not a replacement that someone had problems with and RMA'd it (and you got it instead)? Newegg said it was new I've had one of those... I've never seen a mobo without the install manual. It may of course also be brand new and still be D.O.A. Or some other parts may be faulty/incompatible (memory modules would be my first guess)... Ram is as spec'd: G.skill Ares F-1866C10D-16BAB. 4 modules all slots full summing to 32G. I think the mobo is BORKED Btw, there seems to be two revisions of the mobo in question. At Gigabytes homepage you can find manuals for both. This one is rev 1.1 I've got the parts to build 3 systems, so I'll move on to the second one. Get it to work and verify the compoents, one system at a time. If all else fails, it's the mobo or the CPU. Which of the 2 will be hard to pinpoint without a hassle. Looks like Newegg passed me a turd or 2.. James
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
[...] But it fixes how udev it's packaged in Gentoo, which is very good news. I haven't upgraded, since I need systemd-197 also (which wasn't yet in the tree yesterday), and I don't use LVM, but I'm wondering if the LVM problem happens when you use an initramfs. I'm guessing it doesn't, since udev should read rules from /lib/udev/rules.d AND /usr/lib/udev/rules.d. I don't use an initramfs but neither do i have a separate /usr. Still, lvm2 hung after the udev upgrade. So it probably did _not_ search the old location. Though, after pressing ^C, lvm2 terminated and some fall back mechanism kicked in and the system worked just fine - i.e. was able to mount the lvm volumes. I'm actually not sure what that means (or which system was responsible for that fall back). Sascha
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz sascha...@babbelbox.org wrote:
[...]
But it fixes how udev it's packaged in Gentoo, which is very good
news. I haven't upgraded, since I need systemd-197 also (which wasn't
yet in the tree yesterday), and I don't use LVM, but I'm wondering if
the LVM problem happens when you use an initramfs. I'm guessing it
doesn't, since udev should read rules from /lib/udev/rules.d AND
/usr/lib/udev/rules.d.
I don't use an initramfs but neither do i have a separate /usr. Still, lvm2
hung after the udev upgrade. So it probably did _not_ search the old location.
You are right, the code in udev only searches for one prefix. All the
other commands the other members of the list have been mentioning
would be necessary for all the people needing udev rules to boot.
I believe this is a kinda serious bug in the packaging. And it's
really easy to fix: the following patch should cover all the udev
Gentoo users:
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index bb57d2a..027750a 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1602,6 +1602,8 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)
rules-dirs = strv_new(/etc/udev/rules.d,
/run/udev/rules.d,
+ /usr/lib/rules.d,
+ /lib/rules.d,
UDEVLIBEXECDIR /rules.d,
NULL);
if (!rules-dirs) {
I thought Gentoo had a patch like that. It's necessary, since not
every package will install rules in /lib.
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] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 4:03 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz sascha...@babbelbox.org wrote:
[...]
But it fixes how udev it's packaged in Gentoo, which is very good
news. I haven't upgraded, since I need systemd-197 also (which wasn't
yet in the tree yesterday), and I don't use LVM, but I'm wondering if
the LVM problem happens when you use an initramfs. I'm guessing it
doesn't, since udev should read rules from /lib/udev/rules.d AND
/usr/lib/udev/rules.d.
I don't use an initramfs but neither do i have a separate /usr. Still, lvm2
hung after the udev upgrade. So it probably did _not_ search the old
location.
You are right, the code in udev only searches for one prefix. All the
other commands the other members of the list have been mentioning
would be necessary for all the people needing udev rules to boot.
I believe this is a kinda serious bug in the packaging. And it's
really easy to fix: the following patch should cover all the udev
Gentoo users:
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index bb57d2a..027750a 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1602,6 +1602,8 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)
rules-dirs = strv_new(/etc/udev/rules.d,
/run/udev/rules.d,
+ /usr/lib/rules.d,
+ /lib/rules.d,
UDEVLIBEXECDIR /rules.d,
NULL);
if (!rules-dirs) {
I thought Gentoo had a patch like that. It's necessary, since not
every package will install rules in /lib.
I hit click too quickly: Gentoo *does* include a patch like the one I presented:
From d2a922619a466c47a88ff11aea43bc2dbb4ea324 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= mgo...@gentoo.org
Date: Fri, 13 Jul 2012 16:15:14 +0200
Subject: [PATCH 1/2] udev: add /lib/udev/rules.d to rules directories
This adds /lib if split-usr is enabled
to the directories where udev searches for rules.d.
This is needed if split-usr is enabled because some software still
installs rules in /lib/udev/rules.d.
---
src/udev/udev-rules.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index e6f0f5d..f6b0c01 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1603,6 +1603,9 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)
rules-dirs = strv_new(/etc/udev/rules.d,
/run/udev/rules.d,
UDEVLIBEXECDIR /rules.d,
+#ifdef HAVE_SPLIT_USR
+ /lib/udev/rules.d,
+#endif
NULL);
if (!rules-dirs) {
log_error(failed to build config directory array);
--
It should be in udev-197-patches-1.tar.bz2 (it is in
udev-196-patches-1.tar.bz2). So Gentoo *does* read the rules from /lib
if the patch is present. If that's the case, the problem with LVM is
not because it can't read the rules.
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] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 4:07 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Fri, Jan 11, 2013 at 4:03 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz sascha...@babbelbox.org wrote:
[...]
But it fixes how udev it's packaged in Gentoo, which is very good
news. I haven't upgraded, since I need systemd-197 also (which wasn't
yet in the tree yesterday), and I don't use LVM, but I'm wondering if
the LVM problem happens when you use an initramfs. I'm guessing it
doesn't, since udev should read rules from /lib/udev/rules.d AND
/usr/lib/udev/rules.d.
I don't use an initramfs but neither do i have a separate /usr. Still, lvm2
hung after the udev upgrade. So it probably did _not_ search the old
location.
You are right, the code in udev only searches for one prefix. All the
other commands the other members of the list have been mentioning
would be necessary for all the people needing udev rules to boot.
I believe this is a kinda serious bug in the packaging. And it's
really easy to fix: the following patch should cover all the udev
Gentoo users:
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index bb57d2a..027750a 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1602,6 +1602,8 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)
rules-dirs = strv_new(/etc/udev/rules.d,
/run/udev/rules.d,
+ /usr/lib/rules.d,
+ /lib/rules.d,
UDEVLIBEXECDIR /rules.d,
NULL);
if (!rules-dirs) {
I thought Gentoo had a patch like that. It's necessary, since not
every package will install rules in /lib.
I hit click too quickly: Gentoo *does* include a patch like the one I
presented:
From d2a922619a466c47a88ff11aea43bc2dbb4ea324 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= mgo...@gentoo.org
Date: Fri, 13 Jul 2012 16:15:14 +0200
Subject: [PATCH 1/2] udev: add /lib/udev/rules.d to rules directories
This adds /lib if split-usr is enabled
to the directories where udev searches for rules.d.
This is needed if split-usr is enabled because some software still
installs rules in /lib/udev/rules.d.
---
src/udev/udev-rules.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index e6f0f5d..f6b0c01 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1603,6 +1603,9 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)
rules-dirs = strv_new(/etc/udev/rules.d,
/run/udev/rules.d,
UDEVLIBEXECDIR /rules.d,
+#ifdef HAVE_SPLIT_USR
+ /lib/udev/rules.d,
+#endif
NULL);
if (!rules-dirs) {
log_error(failed to build config directory array);
--
It should be in udev-197-patches-1.tar.bz2 (it is in
udev-196-patches-1.tar.bz2). So Gentoo *does* read the rules from /lib
if the patch is present. If that's the case, the problem with LVM is
not because it can't read the rules.
OK, I downloaded the patchset for 197, and it dropped the patch that
supported both locations for rules.d. I don't understand why, it's a
simple patch, and given that (most) Gentoo users have their rules
files in both /lib and /usr/lib, don't having it will break a lot of
systems (as we can see at the moment).
Just to be clear: no change in udev caused the LVM problem. The Gentoo
ebuild dropped a patch that it's necessary, and that it was included
in previous versions. A bug should be filled explaining that
0001-udev-add-lib-udev-rules.d-to-rules-directories.patch should be
added again to the patchset; I would do it, but can't right now.
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] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote No, because the problem has never been in udev (nor systemd, for that matter). It fixes how *Gentoo* packages udev; probably the devs read the following comment from Lennart (note it was written almost a month ago): https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3 The systemd defenders are using separate /usr as a wookie defense in an attempt to divert attention form the main issue. Separate /usr is actually a secondary issue. The main issue is whether or not we get systemd rammed down our throats. Lennart and Kay are the people responsible for scaring others into mdev and/or eudev. First Kay... http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html We promised to keep udev properly *running* as standalone, we never told that it can be *build* standalone. And that still stands. We never claimed, that all the surrounding things like documentation always fully match, if only udev is picked out of systemd. I would welcome if people stop reading that promise into the announcement, it just wasn't written there. And then Lennart... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.) Lennart -- Lennart Poettering - Red Hat, Inc. The only assumption I'm making is that Kay and Lennart aren't lying. Kay tells us that we may eventually not be able to build udev standalone; i.e. we may have to build systemd in order to run udev. Gentoo users are familiar with cascading dependancies which tend to bloat our systems, as well as introducing additional points of failure. Lennart goes one step further and looks forward to the day that we may not be able to run udev without running systemd. For those of us who do not want to build, let alone run, systemd, these 2 messages are more than sufficient justification for the eudev fork. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On Fri, 11 Jan 2013 15:30:54 -0500
James Cloos cl...@jhcloos.com wrote:
Or, just:
:; find /var/db/pkg -name CONTENTS | xargs -0 grep -l /usr/lib/udev/
| awk -F/ '{print = $5 / $6}' | xargs emerge -pv
which should be fastest.
The original command runs quicker than the time it takes to parse
your's by eye :-)
I'm asking myself what is more valuable - insanely cheap cpu cycles or
this here human's drinking time. And I already know the answer, doubly
so as it's a once-off one-liner :-)
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 06:04:01AM -0800, walt wrote: This seems to me like very happy news indeed, but I'm interested in contrary opinions. There's a recent thread discussing how udev-197 breaks lvm2, but that's a trivial fix once you know about it. The problem is caused because many apps including lvm2 install their udev config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the first place IMO) and they should instead now go in /lib/udev/rules.d/. All you need to do is to re-emerge all of those packages *after* installing udev-197 and the config scripts will go in the correct place. You should do this before rebooting the machine because lvm2 won't work until its udev scripts are in the correct directory. Doesn't this seem to fix the problem with booting a separate /usr partition? So, what you're telling us is that those shmart fellers who've been messing up the init system That Just Works (TM) since at least last March, are finally getting back to where they were with the last sane version of udev? mingdao@server ~ $ eshowkw sys-fs/udev Keywords for sys-fs/udev: | | u | | a a p s | n | | l m h i m m p s p | u s | r | p d a p a 6 i p c 3 a x | s l | e | h 6 r p 6 8 p p 6 9 s r 8 | e o | p | a 4 m a 4 k s c 4 0 h c 6 | d t | o ---+---+-+--- 141-r1 | ~ ~ ~ + ~ ~ ~ ~ ~ ~ ~ ~ ~ | # 0 | gentoo 146-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 149 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 151-r4 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 164-r2 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo [I]171-r9 | + + + + + + ~ + + + + + + | o | gentoo 171-r10 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o | gentoo 195 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 196-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 197 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | # | gentoo 197-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o | gentoo | o o o o o o o o o o o o o | o | gentoo mingdao@server ~ $ ls -l /lib/udev/rules.d/ total 100 -r--r--r-- 1 root root 6539 Feb 20 2012 10-dm.rules -r--r--r-- 1 root root 1286 Jul 7 2010 11-dm-lvm.rules -r--r--r-- 1 root root 1011 Nov 13 2009 13-dm-disk.rules -rw-r--r-- 1 root root 742 Nov 18 16:46 30-kernel-compat.rules -rw-r--r-- 1 root root 349 Nov 18 16:46 40-gentoo.rules -rw-r--r-- 1 root root 764 Nov 18 16:46 42-qemu-usb.rules -rw-r--r-- 1 root root 219 Nov 18 16:46 50-firmware.rules -rw-r--r-- 1 root root 3777 Nov 18 16:46 50-udev-default.rules -rw-r--r-- 1 root root 392 Nov 18 16:46 60-cdrom_id.rules -rw-r--r-- 1 root root 672 Nov 18 16:46 60-persistent-alsa.rules -rw-r--r-- 1 root root 2457 Nov 18 16:46 60-persistent-input.rules -rw-r--r-- 1 root root 889 Nov 18 16:46 60-persistent-serial.rules -rw-r--r-- 1 root root 1423 Nov 18 16:46 60-persistent-storage-tape.rules -rw-r--r-- 1 root root 5565 Nov 18 16:46 60-persistent-storage.rules -rw-r--r-- 1 root root 785 Nov 18 16:46 60-persistent-v4l.rules -rw-r--r-- 1 root root 1973 Feb 20 2012 64-md-raid.rules -rw-r--r-- 1 root root 254 Nov 18 16:46 75-probe_mtd.rules -rw-r--r-- 1 root root 657 Nov 18 16:46 80-drivers.rules -rw-r--r-- 1 root root 280 Nov 18 16:46 90-network.rules -r--r--r-- 1 root root 492 Nov 1 2009 95-dm-notify.rules -rw-r--r-- 1 root root 155 Nov 18 16:46 95-udev-late.rules -rw-r--r-- 1 root root 28 Oct 14 20:42 99-fuse.rules -rw-r--r-- 1 root root 51 Dec 30 10:32 99-ntfs3g.rules mingdao@server ~ $ ls -l /usr/lib/udev/ ls: cannot access /usr/lib/udev/: No such file or directory Hmm ... maybe someone can replace Kay and Lennart and Do It Right (TM). -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Gigabyte wont boot
On Fri, Jan 11, 2013 at 06:48:44PM +, James wrote: Hello, First system build with a Gigabyte mobo. I never got a motherboard install book and cannot seem to find any docs on installing a new 990FXA-UD3 with a FX8350 and ram installed. Everything is new and I have built many PCs before I got the new system put together physically. I'm trying to boot into the bios. The Blueray burner opens and closes and I put the newest liveDVD inside but no boot. No signal to the monitor. The fans all run, the BR burner opens and closes, but the motherboard will not boot. I first tried a known good pci video card (ATI) and now a new fanless video card (ASUS Direct CU Silent Radeon HD 7750). I tried different slots with the video cards. Is there a listing of jumpers or other install tips that I can find somewhere for this mobo? I meticulously connected everything, as this is not my first RODEO. I've never had a new mobo in the box without the little install guide book.bummer . ideas?wikis?docs? James Dale gave you a link to the manufacturer's webpage for your board. Never used a Blueray and don't know how well it's supported by the LiveDVD you're using. I've been very pleased with SystemRescueCD[1], and booting off USB [2] which is faster than a ROM drive anyway. [1] http://www.sysresccd.org/Download [2] http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Re: udev-197 moves from /usr/lib to /lib
On 12/01/13 00:33, Walter Dnes wrote: On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote No, because the problem has never been in udev (nor systemd, for that matter). It fixes how *Gentoo* packages udev; probably the devs read the following comment from Lennart (note it was written almost a month ago): https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3 [...] For those of us who do not want to build, let alone run, systemd, these 2 messages are more than sufficient justification for the eudev fork. This is about udev, not eudev. Obviously, people using udev don't care about the systemd dependency (if they do, they should switch to eudev) *and* expect separate /usr to work, because upstream udev works just fine with it.
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 4:33 PM, Walter Dnes waltd...@waltdnes.org wrote: On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote No, because the problem has never been in udev (nor systemd, for that matter). It fixes how *Gentoo* packages udev; probably the devs read the following comment from Lennart (note it was written almost a month ago): https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3 The systemd defenders are using separate /usr as a wookie defense in an attempt to divert attention form the main issue. Separate /usr is actually a secondary issue. The main issue is whether or not we get systemd rammed down our throats. Lennart and Kay are the people responsible for scaring others into mdev and/or eudev. Ubuntu wants systemd even less than Gentoo. I will not be surprised if Gentoo makes systemd the recommended default before Ubuntu. And yet, Ubuntu doesn't want to fork udev, and actually a Canonical employee has git access to the udev/systemd tree. 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: Gigabyte wont boot
James wrote: Dale rdalek1967 at gmail.com writes: http://www.gigabyte.us/products/product-page.aspx?pid=3996#manual I got a second identical mobo delivered today, so now I have a book. Check the connectors to the Front panel, all is correct. The mobo is Rev. 1.1. Swapped out ram, too, just to test. That's a start. lol Does it beep? NO. Would that suggest a dead mobo? The little speaker is attached but does not beep or anything.. The power supply is plugged into the mobo correctly. It's a new power supply and cables. It should beep even if everything is fine. I think mine gives one long beep when all is good but do NOT take that as golden. It's been over 3 months since I rebooted. I can't recall exactly. If so, is it the normal beep or a error code beep? If error code, then check to see if it sheds light on the problem. I would also unplug, give the connectors a good looking over then plug it back up. I'd do that for everything I could. Yep, verified wiring 3 times. Might have a bad cable, so I'm going to replace them all one at a time and see if that makes any difference. The mobo is just not even trying to boot. No video signal to monitor. I would remove anything I could and see if it beeps. First, get it to beep tho. Unless it is dead, it should have some sort of beep. Remove all but one stick of ram, video card, drives and anything else. Basically, mobo itself, CPU and a stick of memory. The only other thing I can think of, does the BIOS version support that CPU? I have always wondered what would happen if you put a CPU on a mobo that the BIOS doesn't support but would with a newer BIOS. I *think* the BIOS version is on the box with the serial number and such. The book does say the processor must be installed. This mobo is for the fx8350 so something is bad. I'm gonna build up the second machine and see what happens This mobo appears to be borked, right out of the box. any other ideas? James Yea, it has to have a CPU on it to make it do something. My thought was, what if the version of BIOS that is installed does not support the specific CPU you have on there. I know that mine will support a lot of CPUs IF it has the latest version of BIOS. If it still had the BIOS that came on it, it does not see the newer CPUs. I would have to upgrade the BIOS first then upgrade. If all else fails, maybe it is dead. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] udev-197 moves from /usr/lib to /lib
On Fri, Jan 11, 2013 at 05:33:30PM -0500, Walter Dnes wrote: The systemd defenders are using separate /usr as a wookie defense in an attempt to divert attention form the main issue. Separate /usr is actually a secondary issue. The main issue is whether or not we get systemd rammed down our throats. Lennart and Kay are the people responsible for scaring others into mdev and/or eudev. First Kay... And then Lennart... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html For those of us who do not want to build, let alone run, systemd, these 2 messages are more than sufficient justification for the eudev fork. If only it were as easy to fork a government. -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Redux: Any UPS recommendations?
On 01/10/2013 04:21 PM, Walter Dnes wrote: On Tue, Jan 08, 2013 at 08:01:47AM -0500, Walter Dnes wrote I got an APC Back-UPS BX1300G-CN from the local Staples. No worry whatsoever about overloading this baby. I'm currently running a torture test with the monitor, the modem, and both PC's running. They're both doing an update. I set things up so that both are building gcc at the same time. Even so, the load indicator is only lighting up 2 of 5 bars, indicating approximately 40% of max load. It might've been a different story years ago back in the days of the Pentium 4 or AMD space heaters, plus add-on video cards. Being the geek that I am, I did RTFM the docs that came with the UPS. It has an option to decide how much to allow voltage to vary before switching over to battery power. I selected the narrowest range, i.e. the sensitive electronics setting. One question about the configuration of apcupsd; what do I have to do get it to execute /usr/sbin/hibernate when hydro is out, and the battery is running low? I've never used hibernate. I would imagine that that apcupsd would have a hook. I googled quickly and found an ArchWiki article that discusses it. Apparently you can create a symlink and apcupsd will use it rather than the usual shutdown process. Disclaimer: I have not tried it myself. Dan
Re: [gentoo-user] pgo not selected for firefox 18
On Fri, Jan 11, 2013 at 8:24 AM, Florian Philipp li...@binarywings.net wrote:
Am 11.01.2013 13:00, schrieb Adam Carter:
I had noticed it a while ago, it appears to be hardmasked:
# Jory A. Pratt anar...@gentoo.org mailto:anar...@gentoo.org (15
Dec 2012)
# PGO is known to be busted with most configurations
www-client/firefox pgo
I never had a single problem with it, so I'm going to unmask it and
see if anything breaks.
I just commented that out in /usr/portage/profiles/base/package.use.mask
and it compiled fine with pgo and lto using 4.7.2. Ricey...
I guess you didn't have problems because you haven't used stable GCC.
pgo was broken in gcc-4.5 since firefox-16
See https://bugs.gentoo.org/show_bug.cgi?id=439244
Regards,
Florian Philipp
For what it's with, it's working here with gcc-4.6 and firefox-18:
[ebuild R] sys-devel/gcc-4.6.3:4.6 USE=cxx fortran graphite
gtk mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build
-doc (-fixed-point) -gcj -go (-hardened) (-libssp) -multislot -nopie
-nossp -objc -objc++ -objc-gc {-test} -vanilla 20 kB
[ebuild R] www-client/firefox-18.0::mozilla USE=alsa
custom-cflags custom-optimization dbus gstreamer jit libnotify pgo
startup-notification system-sqlite -bindist -debug -minimal (-selinux)
-wifi LINGUAS=-af -ak -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca
-cs -csb -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX
-et -eu -fa -ff -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr
-hu -hy_AM -id -is -it -ja -kk -km -kn -ko -ku -lg -lij -lt -lv -mai
-mk -ml -mr -nb_NO -nl -nn_NO -nso -or -pa_IN -pl -pt_BR -pt_PT -rm
-ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -ta_LK -te -th -tr -uk -vi
-zh_CN -zh_TW -zu 0 kB
