I was just wondering if anyone else is seeing the problems I have on my
laptop with system sounds being very delayed:
Note that F17 on an identical laptop doesn't have these issues, so it
definitely seems to be something F18-ish. The above bug is filed against
pulseaudio, but I realise it could also be alsa or something else ...
suggestions on debugging strategies are very welcome.
All the best,
Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/
Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab
School of Mathematical and Computer Sciences, Heriot-Watt University
Heriot-Watt University is a Scottish charity registered under charity
I don't think that anyone is a huge fan of the current blocker bug
process. I realize that the people most affected by the process are
really busy right now but I also think that it wouldn't be a bad thing
to start a conversation while the process is active and at its most
painful. I don't really want this to devolve into a long flamewar about
how bad the process is (I probably spend more time with the process
than most people, I know it has issues) but I would like to start a
conversation about some of it.
This conversation affects both test@ and devel@, so please try to send
replies to both lists.
I'm trying to think through methods to improve the process but I
ended up with some questions that need more than just my input:
How useful is it to have the blocker votes and conversation in the bug?
I think that it needs to be public, archived and easily accessible from
affected bugs but I'm questioning the value of having conversations
about blocker status within bugzilla comments.
- Do you find the blocker related conversations in bugzilla comments
helpful? Annoying? Don't really care?
- Do you want to be more involved in the blocker process? Less
involved and just notified about status changes?
- Do you vote on blocker status in bug comments?
- Would you vote on blocker status more often if you could easily vote
outside of meetings?
- Do you want to receive status updates on the bugs you vote on, even
if those status updates don't deal directly with blocker status?
Anyhow, helpful thoughts would be appreciated. Hopefully we can improve
the process so that it's less painful for everyone and maybe even more
useful (at the very least, less difficult to understand).
I recently packaged octave-odepkg reviewed and approved for fedora.
I've been able to build it for both f18 and f17, but the rawhide builds
keep failing because of what looks like a broken dep chain:
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed:
# ['/usr/bin/yum-builddep', '--installroot',
Getting requirements for octave-odepkg-0.8.2-2.fc19.src
Error: Package: 6:octave-3.6.3-2.fc19.x86_64 (fedora)
Error: Package: 6:octave-3.6.3-2.fc19.x86_64 (fedora)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
How should I proceed? File a bug against octave for broken deps?
Please only print if necessary.
Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIGhttp://fedoraproject.org/wiki/User:Ankursinhahttp://dodoincfedora.wordpress.com/
I have been working on packaging software into RPMs for my company. These
RPMs create directories in %post into which dependent RPMs install
components. If I yum remove the main package it will be erased first by
yum prior to erasing the dependent packages. When the uninstall scripts
for the dependent packages run, they may fail due to files and directories
being missing that they expect from the main package leaving things in an
inconsistent state. Is this a bug or known behavior we need to account for
in some way?
this proposal was recently linked in various places, so let's formally
This an incremental change, not a major overhaul designed to solve all problems.
The benefits expected from this proposal:
* Making proposed features more visible to Fedora contributors, and
making it easier for Fedora contributors to discuss the feature before
FESCo votes on it.
* Simplifying the process for self-contained features (e.g. individual
package version upgrades)
* Getting FESCo more involved in scheduling and testing of features
with large impact on the rest of the distribution or schedule.
* Making sure some frequently forgotten-about items, like rel-eng
impact, are included in the feature proposal.
For details, please see the proposal at the above-mentioned link.
Marcela Mašláňová, Tomáš Mráz, Jaroslav Řezník, Miloslav Trmač
On 2012-12-02 19:21 (GMT) bugzilla(a)redhat.com composed:
> --- Comment #19 from Chris Murphy ---
> Anaconda should not offer options that are expressly stated as not recommended
> by upstream. The problem is ext4's boot sector is only 512 bytes, which is not
> enough space. The use of --force fragments GRUB, and installs the pieces into
> free space without informing the file system. At any future time the file
> system can step on any one of those block lists and render the system
Upstream screwed up by replacing a bootloading system that can work
acceptably on partitions with one that the very same devs claim cannot.
Fedora should to compensate by providing an alternative to Grub2 that can do
what multiboot users want. Grub2, Grub Legacy and Lilo are not the only
Personally, I can't get Fedora installed the way I want in other regards as
well, so I install it its way, but it _never_ gets to boot that way even
once. Before ever booting it, I undo its boot track damage, and copy its / to
the partition I wanted it on in the first place but wouldn't let me. I
install Grub Legacy on this target, and either use it via chainload, or load
Fedora directly with my master bootloader installed to a different
_partition_, while my MBR as used remains compliant with legacy BIOS, OS/2,
DOS and Windows whether DOS or Windows or OS/2 are even installed.
Changing the boot track without permission is rude, particularly since it
doesn't bother to report it will obliterate what is already there present.
Fedora ought to be able to be put where the user wants it, on a partition
prepared as the user wants it prepared, without any bootloader if that's what
the user wants, and without writing anything to any partition table when it's
unnecessary and unwanted due to all partitioning having been done in advance
(see: Mandriva/Mageia: cmdline option "readonly=1" results in only
"partitioning" to allow selection of mount points for existing partitions).
Anyone who thinks Windows installation is rude or limiting needs to put on a
Fedora hat and look in the mirror.
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/