Pulseaudio in F12
by Paulo Cavalcanti
Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving
completely different. Any mixer control I have (master, pcm, front ,,,)
affects
the pulse volume slider (looking at pavucontrol). In the past, pulse only
controlled PCM, I guess.
But the worst point is that there is no more application volume memory.
All applications when launched are at full volume, and this is really
annoying ...
Is this a kind of new feature? Is it configurable?
--
Paulo Roma Cavalcanti
LCG - UFRJ
14 years, 2 months
Multilib help?
by Richard W.M. Jones
Is there better documentation on how multilib works and how to resolve
multilib problems than
http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks ? I
understand that it uses various heuristics before it corrupts files,
but those don't seem to be documented.
I just spent half a day tracking down a problem which turned out to be
because multilib had corrupted a file, and I wish to solve this now
once and for all.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
14 years, 2 months
Re: Purging the F13 orphans
by Toshio Kuratomi
On Thu, Jan 28, 2010 at 09:19:05AM +0200, David Juran wrote:
> On Wed, 2010-01-27 at 17:03 -0800, Jesse Keating wrote:
> > It's that time of the release cycle again, to purge the orphans before
> > we get to feature freeze. Any unblocked orphans will be purged by the
> > feature freeze. A list of unblocked orphans and the broken deps they
> > would cause is at the end of this email.
>
> > Unblocked orphan gnome-common
>
> > Unblocked orphan gtk-sharp
>
> Was gnome-common and gtk-sharp really intended to be orphaned? Removing
> them seem to break quite a lot (large parts of gnome and e.g. f-spot,
> respectively)
>
gnome-common was intended to be orphaned although mclasen said he'd find
someone to maintain it since pieces of gnome depend on it. It's not a high
maintainance package; most anyone can do it... it's just no use to me any
longer so I'm not a good maintainer anymore.
-Toshio
14 years, 2 months
Missing iwl5150-firmware package?
by Jonathan Dieter
Is there some reason we don't have a iwl5150-firmware package? Or
that /lib/firmware/iwlwifi-5150-2.ucode isn't included in
iwl5000-firmware?
Just asking because I was helping someone on #fedora get their Intel
5150ABN working, and it seems that this missing firmware was the reason
it wasn't. The firmware is available from
http://intellinuxwireless.org/?p=iwlwifi&n=downloads.
Jonathan
14 years, 2 months
OpenModelica users wanting to have rpms?
by Christoph Höger
Hi,
if you are an OpenModelica user, you might know that we do not have any
rpms available for fedora.
This might be due to the buildsystem.
I have started converting MetaModelica to autootols to boot-bootstrap
the omc build process.
See github.com/choeger/MetaModelica-autotools
Building the rml compiler and the related libraries was easy, but now I
could need some help and advice on how to build the testcases.
In the original buildsystem from
https://openmodelica.ida.liu.se/svn/MetaModelica there are some examples
with own makefiles, but those refer to the buildsystem itself.
I am not sure how to handle this with automake (obviously it would
require to build the compiler before the tests).
So currently I am wondering if the examples should have a build system
that requires the compiler to be installed, any thoughts?
On the other hand, there are some "style" questions, I'd like to be
answered:
This package builds three slightly different libraries in three differen
flavors: called (librml_plain|librml_mask|librml_diff)(_g|_p|).so
Those flavors only differ by the CFLAGS set upon compilation (_p means
-p, _g -g).
Upstream told me, they require them all, but would this be acceptable?
Is the name rml ok for a library in /usr/lib or shall I
use /usr/lib/rml/ by default? (Same for headers)
What with the name? Is MetaModelica even a good name, if the main binary
is rmlc?
The package builds a compiler driver, essentially a shell script, by
copying some configuration variables into a shell template (mainly how
to invoke cc). Would this be fine as a /usr/bin script?
Feel free to demand any changes, I will discuss this with upstream.
regards
Christoph
14 years, 2 months
Candidate packages for removal due to FTBFS, implications
by Matt Domsch
The following 30 packages, with respective FTBFS bugs, have been open
since the Fedora 11 time frame, and continue to fail to build. These
are the oldest non-building packages in the distribution, everything
else (over 8800) managed to build for Fedora 12 or newer already.
awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628
evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451
geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494
gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780
gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591
Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617
knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487
libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470
ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200
perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749
perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984
perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570
perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964
perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770
perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729
prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64)
python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675
qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688
recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931
skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202
smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362
synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195
unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553
widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430
xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717
xqilla10-1.0.2-6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511599
xqilla-2.1.3-0.6.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511425
If these are removed, the whole list of RPMs to then drop looks like:
------------------------
Removing awn-extras-applets removes these:
awn-extras-applets-devel-0:0.3.2.1-8.fc11.x86_64
awn-extras-applets-devel-0:0.3.2.1-8.fc11.i586
------------------------
Removing evolution-brutus removes these:
evolution-brutus-devel-0:1.2.35-2.fc11.i586
evolution-brutus-devel-0:1.2.35-2.fc11.x86_64
------------------------
Removing geronimo-specs removes these:
geronimo-specs-compat-0:1.0-2.M2.fc10.x86_64
------------------------
Removing gmfsk removes these:
------------------------
Removing gnome-scan removes these:
------------------------
Removing Io-language removes these:
Io-language-devel-0:20071010-10.fc11.i586
Io-language-graphics-and-sound-0:20071010-10.fc11.x86_64
Io-language-postgresql-0:20071010-10.fc11.x86_64
Io-language-extras-0:20071010-10.fc11.x86_64
Io-language-mysql-0:20071010-10.fc11.x86_64
Io-language-devel-0:20071010-10.fc11.x86_64
------------------------
Removing knm_new-fonts removes these:
------------------------
Removing libFoundation removes these:
libFoundation-devel-0:1.1.3-11.fc9.i386
libFoundation-devel-0:1.1.3-11.fc9.x86_64
------------------------
Removing ohm removes these:
ohm-devel-0:0.1.1-9.39.20091215git.fc11.i586
------------------------
Removing perl-AnyEvent-XMPP removes these:
------------------------
Removing perl-Class-InsideOut removes these:
------------------------
Removing perl-Jemplate removes these:
------------------------
Removing perl-MooseX-Traits-Attribute-CascadeClear removes these:
------------------------
Removing perl-RRD-Simple removes these:
------------------------
Removing perl-SVN-Mirror removes these:
------------------------
Removing perl-SVN-Simple removes these:
------------------------
Removing prctl removes these:
------------------------
Removing python-openhpi removes these:
------------------------
Removing qtiplot removes these:
------------------------
Removing recordmydesktop removes these:
qt-recordmydesktop-0:0.3.8-2.fc12.noarch
gtk-recordmydesktop-0:0.3.8-2.fc12.noarch
------------------------
Removing skychart removes these:
------------------------
Removing smarteiffel removes these:
smarteiffel-doc-0:2.3-2.fc9.x86_64
------------------------
Removing synce-kde removes these:
synce-kde-devel-0:0.9.1-4.fc11.i586
synce-kde-devel-0:0.9.1-4.fc11.x86_64
------------------------
Removing unifdef removes these:
------------------------
Removing widelands removes these:
------------------------
Removing xpilot-ng removes these:
------------------------
Removing xqilla10 removes these:
xqilla10-devel-0:1.0.2-6.fc11.x86_64
xqilla10-devel-0:1.0.2-6.fc11.i586
------------------------
Removing xqilla removes these:
dbxml-utils-0:2.4.16-0.5.fc12.x86_64
dbxml-python-0:2.4.16-0.5.fc12.x86_64
dbxml-devel-0:2.4.16-0.5.fc12.x86_64
dbxml-0:2.4.16-0.5.fc12.x86_64
xqilla-devel-0:2.1.3-0.6.fc11.x86_64
xqilla-devel-0:2.1.3-0.6.fc11.i586
dbxml-devel-0:2.4.16-0.5.fc12.i686
qpidd-xml-0:0.5.819819-1.fc13.x86_64
Of these, xqilla looks the most interesting, being used by the
growing-popular qpid work.
I'd like to propose the above list be dropped from the distribution,
prior to Fedora 13 Alpha freeze, unless the package is made to build
in rawhide before that.
Thanks,
Matt
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
14 years, 2 months
New merge review tickets being opened
by Jason L Tibbitts III
Some Red Hat employees are opening new merge review tickets for packages
which were in extras long before the big core-extras merge. It looks
like all of these packages are so old that the reviews predate the use
of Red Hat's bugzilla for the purpose, and so those reviews were either
done on the old mailing list or in the old fedora.us bugzilla (which I
believe has been lost).
No Fedora policy requires that these packages be re-reviewed. The
evidence seems to point to some Red Hat policy requiring review tickets
for these packages, although I can't seem to get a proper answer from
someone who actually knows. Given that the reviewers are currently
overburdened and are barely able to keep up with existing submissions,
plus the fact that we still have a few hundred of the original merge
review tickets still open, I don't think that adding more to the pile is
going to be remotely helpful. If there's a Red Hat policy which
requires this, then Red Hat should be taking care of this instead of
leaving it to the overburdened Fedora community. The fact that there's
been no communication about it only adds insult to injury.
I propose that the 'Product' on these tickets be changed to something
other than 'Fedora' so that they don't appear to be part of any Fedora
process. I'm happy to do that if someone can tell me which component to
use.
Note that I don't necessarily think it's a bad idea that old packages be
revisited at some point, but we just don't have the manpower to do that
right now.
- J<
14 years, 2 months
Anyone else want to maintain alltray?
by Rahul Sundaram
Hi
It is a application that lets you minimize any app to the system tray
and is compatible with GNOME, Xfce, KDE etc. It has a dormant upstream
and I haven't had time to look into all the crash reports from Abrt. If
noone picks it up, I will orphan it in a week.
$ yum info alltray
Loaded plugins: presto, refresh-packagekit
Available Packages
Name : alltray
Arch : i686
Version : 0.70
Release : 4.fc12
Size : 62 k
Repo : fedora
Summary : Dock any application in the tray
URL : http://alltray.sourceforge.net/
License : GPLv2+
Rahul
14 years, 2 months
The road to dropping xdvik
by Jonathan Underwood
Dear All,
We currently ship xdvik as a package separate to texlive (for a
variety of reasons). Looking forward to when we ship texlive-2009,
it'll be built as part of the texlive package build once more.
However, even better would be to drop it entirely, for the following
reasons:
1) It's a legacy piece of software which is barely maintained - a
couple of times a year releases are made with small bugfixes, but
there's no actual development
2) We patch it heavily to bodge in japanese support using a separate
upstream patch from http://sourceforge.jp/projects/xdvi/, but this
patch isn't actively maintained either, and rebasing that patch is a
time sink.
3) The need to incoorporate the japanese patch, and also the desire to
build against the system installed kpathsea shared lib rather than
link statically means we end up hacing the autotools scripts and have
to run autotools during package building, and worse, we have to use
old autotools as the scripts are so crusty.
4) It's one of the few users of the Xaw(3d) toolkit in the repo, and
also requires legacy font support (IIRC).
However, it's not clear to me if okular and evince-dvi provide
equivalent functionality that we're yet in a position to drop xdvik.
Comments? If you use xdvik because other viewers don't give some
particular functionality, it would be helpful if you stated what that
functionality is.
Cheers,
Jonathan
14 years, 2 months
