Re: [gentoo-user] beep
On Wednesday, April 15, 2015 12:25:03 AM lee wrote: Hi, when the pcspkr module (or how it's called; I haven't compiled atm) is loaded, somehow the built-in speaker is used to sometimes beep. There also seems to be the option to play this beep via the sound card --- which usually sounds nicer. How is this done? Do I need to load a different module for that, or does it require to use some sort of additional software? If you mean how to configure the kernel for it then just load the right module. I remember seeing a PC Speaker Emulation or similar module but I can't find it now so it may be gone. Anyways, this only applies to the console (VT). Software just writes the BEL character (0x07) to it's terminal (stdout) to play a beep. You can also open /dev/console directly and play this character or use ioctl calls to play sounds with different frequencies and duration but this requires root privileges. Modern desktop terminal emulators will already be using the sound card to play the BEL character. On KDE for example you can choose any sound file to play or just show a notification. -- Fernando Rodriguez
[gentoo-user] RDMA over cephfs
RDMA over infiband is all the rage, for folks with deep pockets. RDMA over cephfs is now in ceph.0.94 ; a version bump request has been filed. ceph-0.93 can be found here (overlay) [1] xmw /var/lib/layman/xmw Some excellent reading, including how to rapidly deploy a cephfs (3) node test cluster, can be found here: http://marc.info/?l=ceph-develm=142844009930093w=2 http://ceph.com/docs/master/start/quick-ceph-deploy/#add-an-rgw-instance mesos + cephfs yields a very fast, FOSS cluster for gentoo, and it's ripe for testing by the adventuresome. Happy clustering! James
Re: [gentoo-user] Machine completely broken; Ncursed!
On Saturday, April 11, 2015 10:22:09 AM Alan Grimes wrote: My machine is so completely broken right now I can't open any new terminal sessions. This is because I stupidly tried to toggle tinfo useflag in a desperate attempt to get everything in my portage tree working again. Why now did nothing in my portage tree build? It wasn't building for two reasons: 1. My machine is not correctly configured to build 32 bit executables, mainly because I cannot find a 32 bit version of ncurses that ld is willing to acknowledge the existence of. 2. LD cannot find ncurses, -- It simply can't, in 64 bit mode either. That is the only error message it ever gives and vast amount of effort spent in sessions over the last year and a half have failed to find any solution. I only installed Gentoo on this machine four and a half years ago so it's hard to imagine what could have gotten this royally foobar in such a short period. I am an enthuseastic supporter of multilib, I even tried to set it up myself but failed due, once again, to ncurses. I was running my system as usual, running updates every week or two, no major issues since the libav clusterfuck a few months ago. (Libav is a cult not a software project). The ncurses problem has been a low-level issue for a long time but, with tinfo set, 99% of packages worked. And then portage did two things. 1. It masked emul-linux -- A move that I support, it's time to see that go. 2. It sent out a profile that sets variable ABI_x86 with 32 bit enabled. ALARM: ABI_x86 should be set in exactly one place: /etc/portage/make.conf and nowhere else. But, nevertheless, ABI_x86 WAS set which broke the profile because my system cannot compile 32 bit executables. =( I tried the no-multilib profile but it didn't have a number of essential useflags and was foobar. Right now my system is completely unusable and will need fresh stage3 packages followed by an emerge emptytree to recover. But before I can do that, I need a sane profile and to know that the person who pushed out the changes to portage, obviously without any testing whatsoever, that broke my system so comprehensively is tortured, executed, butchered, and then cremated. This is probably what happened: 1. You have ncurses and emul-linux libraries installed. Everything's good. 2. You come up with this genius idea: LDFLAGS=-lncurses 3. You uninstalled emul-linux (including 32-bit ncurses). Now you need to rebuild ncurses BUT YOU'RE LINKING IT AGAINST ITSELF. This fails because you don't have 32-bit ncurses (may fail even if you did, not sure). 4. Since you're linking everything against ncurses everything 32-bit fails. Duh! You could've probably fixed it by just removing that LDFLAGS line and rebuilding ncurses. -- Fernando Rodriguez
Re: [gentoo-user] Re: Machine completely broken; Ncursed!
On Tue, 14 Apr 2015 22:09:34 -0500, »Q« wrote: I don't want to advocate for *-. I don't recommend it to anybody. I don't particularly want to argue about how good/bad/ugly it is with anybody, but it's it's tough not to argue when people are telling me I'm causing myself problems and I'm not seeing any such problems. That's fair enough. I have no problem with your using -*, it's your system. Advocating it is another matter, but you're not doing that. -- Neil Bothwick Velilind's Laws of Experimentation: 1. If reproducibility may be a problem, conduct the test only once. 2. If a straight line fit is required, obtain only two data points. pgpaWbgXspQGV.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Is this a new kernel bug? Or not.
walt w41...@gmail.com wrote: it tries to read from the floppy and prints an error message to the console No. The kernel does not do this. It is either udev or some other part of your init system which does this. mount at a bash prompt, and then spams the screen with errors about /dev/fd0. And again it is not the kernel. Obviously, it is the bashcomp shell scripts which do it in some case, here. Could/should kernel patch number 38 really introduce new behavior? It might toggle that for some reason e.g. /dev/fd0 was not visible or accessible before. (Or at least not in the way how udev and bashcomp expected to access it.)
