Beginning of today "package-cleanup --orphans" reports
thunderbird-3.1.10-1.fc14.i686 as orphan in F14.
"yum clean all; yum list thunderbird" reports thunderbird-3.1.9-2.fc14
as newest thunderbird package in the repositories. However, at one point
in time thunderbird-3.1.10-1.fc14.i686 must have been available in the
repos, too (I don't have updates-testing enabled.).
It looks like that the following happened:
There were two updates in bodhi:
which contains thunderbird 3.1.10-1 and which was pushed to stable on
which contains thunderbird 3.1.9-2 (and thunderbird-lightning) and which
was pushed to stable on 2011-04-30 23:21:39.
So the 2nd update has superseded the first update to thunderbird 3.1.10.
For all who have updated to thunderbird 3.1.10 during the small time
window when it was available in the mirrors, the thunderbird package is
now an "orphan" on their systems.
Please can the maintainers of thunderbird push thunderbird 3.1.10 again?
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
= Weekly KDE Summary =
Time: 2011-05-03 15:00 UTC
Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-05-03
Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2011-05-03/kde-
Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2011-05-03/kde-
= Participants =
* Kevin Kofler
* Jaroslav Reznik
* Lukas Tinkl
* Than Ngo
* Radek Novacek
= Agenda =
topics to discuss:
* Fedora 15 status
* 4.6.3 status
* bluedevil drags in pulseaudio
= Summary =
Fedora 15 status (jreznik, 15:06:49)
* F15 deadline is very soon (jreznik, 15:13:38)
* kde-plasma-nm is in a relatively good shape except VPN support  (jreznik,
* nm-compat issues - not everything is implemented there, we have to hide some
features in current snapshots (or use older ones + backport) (jreznik, 15:16:09)
* we are going to use knm in F15 with documented known bugs and guide how to use
nm-applet (jreznik, 15:24:16)
* ACTION: jreznik to document VPN issues as known bug (jreznik, 15:26:41)
4.6.3 (jreznik, 15:27:26)
* AGREED: not to push 4.6.3 to F15, release it as 0-day update (jreznik,
* reasons are: kdeedu is still not yet ready, few days for testing and fixing
possible regressions (jreznik, 15:40:49)
* regarding  Kevin_Kofler is going to go with upstream's menu structure as
than suggested (jreznik, 15:47:15)
bluedevil drags in pulseaudio (jreznik, 15:48:18)
* Bluedevils needs pulseaudio-module-bluetooth to support audio features
correctly (jreznik, 16:03:27)
* we consider creating -core subpackage with real functionality and bluedevil
metapackage that pulls required packages (jreznik, 16:05:17)
= Next Meeting =
= Links =
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
NSS 3.12.10 is coming out soon from upstream. I have updated NSPR and NSS in Rawhide to NSPR_4_8_8_BETA3 and NSS_3_12_10_BETA1, respectively. Any feedback on these would be greately appreciated.
I sent a request to docs ml but I did not receive any response. I also
do not see any related stuff in documentation
To whom should I go with this? (I'd do it myself if I only knew
English well and I would be Fedora dev :))
W dniu 22 kwietnia 2011 19:00 użytkownik Jared K. Smith
> 2011/4/22 Michał Piotrowski <mkkp4x4(a)gmail.com>:
>> I believe that users should be warned about problem described here
>> It seems to me that it would be appropriate to write about it in
>> "Known Issues" in release notes.
> Thanks for the note.
> The suggestion that we add this to the "Known Issues" section of the
> release notes sounds very reasonable to me. Have you asked the Docs
> team to add it.
> As the thread on the systemd-devel list (linked from the bug report
> you opened) suggests, there are *many* ways that local users can cause
> a local DoS by consuming resources. And yes, I agree that quota
> support for tmpfs is probably a good long-term solution, but I think
> we can all reasonably agree that quota support isn't going to be
> written and tested in time for Fedora 15, and that it's not worth
> postponing the release of Fedora 15 to wait for quota support.
> Documenting it is the next best course of action, I think.
> Jared Smith
> Fedora Project Leader
Hi, a user of rakarrack was getting startup exception SIGILL .
Seems the config/make/compile process for this app checks CPU capability
of the machine it is being compiled on, and applies optimisations that
are available on that processor.
The user has a much older processor.
Upstream suggest  that distros could add a script to detect runtime
CPU, and call the appropriately compiled executable.
To do that in rpm, I think I would need to call configure a second time.
Also, the new compile would overwrite the first compile, so it doesn't
seem that easy.
Any suggestions on a way forward ?
[Why when I run rakarrack I receive a "Illegal Instruction" message?]
I'm testing a netbook using the F15 Beta Live image. That netbook has
a Broadcom BCM4313 wifi chipset, of which I can find several problem
reports and the same number of answers, with or without success reports.
The lspci -v output (I've zeroed the S/N in the output):
02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g LP-PHY (rev 01)
Subsystem: Device 1a3b:2047
Flags: bus master, fast devsel, latency 0, IRQ 10
Memory at fbffc000 (64-bit, non-prefetchable) [size=16K]
Capabilities:  Power Management version 3
Capabilities:  Vendor Specific Information: Len=78 <?>
Capabilities:  MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities:  Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Capabilities:  Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [16c] Power Budgeting <?>
- Can I get this chip working (as a test) using the Live USB-stick, so
that I can verify the correct working without actually installing
Fedora on the disk? (Wired Ethernet is working to retrieve external
stuff when needed.)
- Is this chipset expected to start working without any additional
tweaks during the F15 life cycle?
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
Hi fellow Fedorans.
Recently, AutoQA has been introduced to catch typical problems early in
the update process. In general, I appreciate that effort, but currently
I find myself in a phase of conditioning ignorance towards AutoQA,
essentially because it is drowning me in irrelevant information. The
current case why I'm writing is
Here are two ideas to make AutoQA relevant, less time-consuming, and
more helpful. In short: good QA is always quiet, only if there is a
problem it communicates.
- Post only errors
It is common, for example, in automated build or continuous integration
systems to send out emails only on errors. Similar goes for Unix tools,
which tend to be quiet if everything is ok, and only bother you with
output if something is not. Therefore, I propose to have AutoQA messages
posted only in case that there has been an error.
- Accumulate error messages
An email is sent for every single comment to Bodhi. In the case of
AutoQA, it causes one email per platform. It increases the load of email
tremendously to deal with, which in turn makes me ignore it. Therefore,
I propose to accumulate messages for all platforms. Combined with the
earlier proposal, the states for all platforms should be collected by an
intermediate node, and if and only if a test failed on any of the
platforms, one message with all status messages is posted to the update.
On a related note: it'd be much appreciated if Bodhi would provide an
option to get a daily digest with all comments of all the packages I'm
I hope the fine folks of the AutoQA effort take these proposals into
account when proceeding in the development of the system and help me to
stop ignorance from taking over.
Tim Niemueller <tim(a)niemueller.de> www.niemueller.de
Imagination is more important than knowledge. (Albert Einstein)
-----BEGIN PGP SIGNED MESSAGE-----
a few minutes ago I ran into two issues regarding bodhi feedback
- - I tried to submit feedback via fedora-easy-karma and got a 500
internal server error.
- - afterwards I submitted my vote via web interface and (probably)
bodhi - 2011-05-03 04:28:44 (karma 0)
This update has been pushed to testing
bodhi - 2011-05-03 06:45:29 (karma 0)
Critical path update approved
mrunge (proventesters) - 2011-05-03 06:45:29 (karma 1)
This fixes 698533 for me. thank you
Why the critpath-approve first, (who was the second vote)?
was my vote counted twice? (probably). :-/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----