On 09/17/2015 06:40 PM, John Harrigan wrote:
On Thu, Sep 17, 2015 at 12:51:36PM -0500, rhubarbpie...@gmail.com wrote:
I run simple scripts when building LFS that sound a beep to draw my
attention at completion or errors. Unfortunately, alsa interrupts echo -e
"\a" so I must disable alsa on my host. That works, but there's probably a
better way so I don't lose sound while building LFS. How can I execute
"echo -e "\a" with alsa enabled?
I've tried snd-pcsp, snd_dummy, and a beep utility without success. I'm
probably missing something simple. How can I sound a beep when building LFS
with alsa enabled?
Playing a sound file with mpg123 would be an acceptable alternative, which I
do when building BLFS. But how when I'm building LFS? I've tried linking
host programs with no success.
This is a kludge but it might be sufficient until you find a real solution.
What you can do is touch a file in the build environment whenever you
detect your error condition and use inotifywait to monitor that file from
the host environment.
While you're building LFS inside the chroot environment, you would touch
/tmp/error-alert whenever you hit your error condition.
From the host environment you would be running the following loop:
while true; do inotifywait $LFS/tmp/error-alert >/dev/null 2>&1; [ $? ] &&
mpg123 error-sound.wav; done
I haven't tested this in a real LFS build environment but I tested it in
a simple chroot and a sound would play whenever I touched the file in the
chroot. N.B. I had to create the error-alert file before kicking off the
while loop.
Thank you, a good idea. I had roughly the same thought of looping on
the host side shortly after posting and just tested it successfully.
I simply begin a script on the host side before su -lfs and executing
lfs .bash_profile. That script periodically checks /lfs/sources for
files generated as the scripts finish. Upon finding a file, the host
script deletes the file, beeps, and resumes checking for files on
/lfs/sources.
Under my old method, lfs scripts would sound a simple beep(s) and wait
for input. Now, they write an empty file and wait for input. The empty
file causes the host "beep" script to execute. I then check the lfs
side. Additionally, the lfs scripts generate different files by script
and status. By using mpg123 and generating different file names, the
host "beep" script can play a different sound(s) using different volumes.
Sometimes just voicing a problem helps. Ken's point that "the whole
purpose of chroot in LFS is to isolate you from the host" was very good
and set me to thinking. They are separate programmatically, but the
host can read LFS and vice versa. Running a host "beeps" script is
perhaps hokey, but easy and simple. At the end of my LFS build I
generate "finished" which causes the host script to exit.
So my, yours, or perhaps a combination of both methods solves my
problem. My testing was minimal and didn't consist of a full LFS build,
but I don't anticipate insurmountable problems. Building LFS 7.8 will
be a complete test.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
