I'm new to music management in Fedora. I'm trying to rip a CD to MP3
format using Sound Juicer in F15. When I open SJ, it pops up a dialog
The currently selected audio profile is not available on your
and offers me a chance to Quit or Change Profile. If I try to change
profile, the CD is opened and the preferences window opens. The CD
Drive selector is blank, but choosing it lists the only CD drive in the
machine. After selecting that, the selector remains blank, which seems
But the real problem is, the Output Format selector lists no options at
all. I expected some options available by default, as described in the
help for SJ.
Any idea what I've done wrong?
Clemson University Mathematical Sciences
mjs AT clemson DOT edu
It is common knowledge that one does not need to reboot for updates to take
effect in GNU Linux.
However, in actual practice, this is not so. I could cite many examples, but
this should suffice:
On Sunday evening, I installed a new updates-testing version of mesa and then I
suspended the machine for the night. The following Monday morning (yesterday),
I resumed the machine and suspended it again around noon. I again resumed the
machine at about suppertime and _powered_ _it_ _down_ about 2 hours later. An
hour or two after that, I powered it back up and the mesa testing update turned
out to be bad and I was not able to log in. I did not know which program was at
fault, because the bad program had been installed over 24 hours prior, but was
only showing itself to be bad after a power off.
Could someone explain how reboots are not needed in Linux for updates to
_take_, given the evidence to the contrary.
As the subject says I cannot recompile grub. Everytime I get "checking
whether the C compiler works... no". I explicitely installed all
packages from http://kojipkgs.fedoraproject.org/packages/grub/0.97/74.fc15/data/logs/x8...
and have attached those in the packages.log file. The only thing
that's missing is the glibc32 package but it conflicts with
glibc-2.14-2.i686. As you can see from the attached build.log the
error arises in the middle of the compilation. What am I missing?
Whenever I try to put my laptop into either suspend or hibernate mode
(i.e., close the lid when not plugged in) the laptop _seems_ to be
trying to go to sleep but never quite gets there. The battery light
stays on, the sleep light (crescent moon) light blinks, but there's no
disk activity and the power light stays on.
And nothing short of holding the power button down and forcing a power
off works for bringing the laptop back out of htis state.
Any ideas on what I should or could do to get suspend to work again?
It's a PITA to have to hard shutdown the laptop when I accidentally shut
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
Hi. I've searched release notes, bugzilla and news archives for an
answer to this, but haven't found one. I have found one other query on
fedoraforum, but no solution. (
I started installing f14 on a machine (P4, 2GB ram, 30GB free on 75GB
HD, 1st partition is WinXP). I use manual setup of partitions, as I have
always done, planning to use the following approximate scheme:
sda1 - primary - ntfs - 45 GB - winXP
sda2 - primary - ext2 - 200 MB - /boot
sda5 - extended - ext4 - 7 GB - /home
sda6 - extended - swap - 2 GB - [swap]
sda7 - extended - ext4 - 20 GB - /
It seems that anaconda overrides my choice of not ticking the 'create
primary partition' box in the 'add partition' dialog, making all three
first partitions created primary. This means that both /boot and either
/home or / would be primary partitions.
- 'Olde' knowledge says that only one primary partition can be visible
to the system at one time. Is this not longer true?
- If still true, the system wouldn't be able to see the home or root
partition, would it?
- If the behaviour is by design, what is the reasoning behind it? Is
it better than letting the admin decide?
I haven't yet tried partitioning with fdisk first, but will try to do
that tomorrow. Hopefully it will be a usable workaround.
Have a nice weekend,
We were talking the other day, people were mentioning the bugs they got
back from bugzilla recently marked as:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
People were saying that the same problem got the same message a year
ago, but it said "Fedora 11" that time. So I have a suggestion, if no
one in the support group looks at a bug in 180 days, close it with a
DONTCARE status and tell the submitter that no one could be bothered to
even look at the bug in half a year. And do the same thing if a bug sits
in NEEDINFO for six months, if no one responds in that length of time
they probably no longer care.
Users have this unrealistic view that there is a queue of bugs and they
get fixed in the order submitted. The truth is that if you don't hear in
a month you probably won't ever hear unless someone else reports it and
triage catches that they are dups. That doesn't always happen, one of
the bugs I had with FC10 was reported as WONTFIX at EOL, and when I
tried to reproduce it found that it had been fixed months before and no
one bothered to update the bug.
Finally, if someone reports a bug in an app, and the tester finds that
it's supposed to work that way, if the documentation says it works some
other way don't change it to NOTABUG, change it to a documentation bug.
If the conflicting documentation is mentioned in the bug report, take a
minute and get it resolved. Please?
My occasional rant when I look at all the time I wasted reporting bugs...
We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination. -me, 2010
I'm running f14-x86_64 but have a need for a f14.i686 kernel package
(kernel-18.104.22.168-45.fc14.i686). I'd also like to unpack it but not into
its default locations.
That leaves me with two questions:
How do I download it without installing it?
How do I unpack it into a safe location (such as /test)?
Been fiddling with yum and had no luck.
i m trying to install f13 on a computer with cobbler and pxe but when i
boot the network card is not detected.
i would like to update the initrd image file with updated modules
Does anybody have a pointer on how to do that?
Thanks in advance for any help
i need to build a rpm package with debuginfo, this is the default result on
my Fedora 10, but on Fedora 14, rpmbuild didn't build a debuginfo package,
it is invalid to put "%define debug_package 1" in spec file, anybody knows
how to enable this? Thank in advance.