usb-modeswitch/usb-modeswitch-data must be updated (hardware related)
by Xose Vazquez Perez
https://bugzilla.redhat.com/show_bug.cgi?id=728680
https://bugzilla.redhat.com/show_bug.cgi?id=625004
== usb-modeswitch-1.2.0 ==
Version 1.2.0, 2011/10/23
Added QisdaMode for Qisda H21 (thanks to Chi-Hang Long for the code);
dispatcher can now be installed with an embedded interpreter, so that
Tcl is no longer required; added command line options for binary
program
to accept configuration data via stdin or as a long string parameter -
this fixes the bug with non-writable temporary file during boot;
reversed skipping of pre-switching delay, which has caused problems;
fixed potential buffer overflow (thanks to Rafael Silva for the find);
get first interface right even on some broken devices (thanks to
Alexander Gordeev for the patch); increased post-switch delay before
driver binding to avoid conflict with usb-storage
-----------------------------------------------------------------------------
== usb-modeswitch-data-20111023 ==
20111023:
Added devices: C-motech CDU-685a, Qisda H21 "Flying Beetle" (needs
program version >= 1.2.0)
20111012:
Added devices: AnyDATA APE-540H, ZTE MF192 (new variant)
20111007:
Added devices: Alcatel OT X220L, Nokia CS-19, Huawei ET302, 3GO 3GO11
HSUPA, Novatel MC545, ZTE AC682, ZTE MF820 4G LTE, Philips PicoPix 1020
(LED projector); added some ZTE target IDs; modded udev rules to
include
"change" as trigger event
20110805:
Added devices: Vodafone/Huawei K4510 & K4511, Vodafone/ZTE K3770-Z,
K3772-Z and K4510-Z (thanks to Andrew Bird); five Option HSO modems;
Cisco Valet AM10 (use with program version >= 1.1.9)
12 years, 5 months
Suggest 744217 blocker for F16
by Jes Sorensen
Hi,
I realize this is last minute, but I just realized this wasn't marked as
a blocker already, and I am still pretty new to the Fedora package process.
I would like to recommend this one being accepted as a blocker for F16:
https://bugzilla.redhat.com/show_bug.cgi?id=744217
The bug in question is related to BIOS raid, in particular when
installing root on the raid device. The previous mdadm package has a bug
in it which prevents dirty raids from being assembled at boot, which is
fixed in mdadm-3.2.2-12. This affects both booting from the install
image and installed systems!
The problem is particularly nasty since if one configures a new BIOS
raid, it will be marked dirty straight away and install will be
impossible. In addition, if one has a clean raid and upgrades or
installs to it, but then manages to dirty it, boot will no longer be
possible and one cannot run updates. In other words, a zero-day fix
would be highly suboptimal.
Thanks,
Jes
12 years, 5 months
how to block grub2 update?
by Michał Piotrowski
Hi,
I would like to know if it is possible to block grub2 update? I tried
to use versionlock but unfortunately this does not work. Do anyone
knows some other effective way to block this update?
--
Best regards,
Michal
http://eventhorizon.pl/
12 years, 5 months
synergy-plu, synergy, and gnome3
by Laine Stump
The version of synergy-plus currently in Fedora doesn't work well with
gnome3; I had noticed this because I couldn't get the mouse past the
menubar to an alternate screen configured to be "north", but there are
other problems as well:
http://synergy-foss.org/tracker/issues/2958
Since the synergy package is orphanedin Fedora, I was going to file a
bug against synergy-plus pointing at the above report/patch, but then I
saw that synergy-plus and synergy have re-merged, and the project will
be called simply "synergy" in the future.
So, I'm wondering 1) which package I should file the bug against, and 2)
if we're going to switch back to synergy from synergy-plus, what needs
to be done (and by who) in the packages to make that happen.
12 years, 5 months
Upcoming elections for FAmSCo, FESCo, and the Fedora Board
by Jared K. Smith
One of the things I like most about Fedora is the orderly way in which
people are able to move in and out of leadership positions within our
community. Each development cycle, we have a set of elections for the
steering committees and for the Fedora Board. The next election cycle
is nearly upon us, so I'd like to take this opportunity to share the
details of the upcoming elections with you.
As quick reminder, the nomination period for this election cycle will
open on 25 October 2011, and will close promptly on 5 November 2011 at
23:59:59 UTC. The full elections schedule, along with more details
about the elections, can be found at
https://fedoraproject.org/wiki/Elections
I strongly encourage you to consider running for an open position in
one of the elections. This is one way to serve your fellow community
members and help move Fedora forward at the same time. Additionally,
I'm looking for a few volunteers to help with the coordination of the
candidate questionnaires and town hall meetings. If you're willing to
help, please let me know.
== Fedora Board ==
This election cycle will fill two elected seats for the Board (seats
E1 and E2). Prior to the election I will also announce the first of
two appointed seat in this cycle (seats A1 and A2), with the second
appointment announcement to follow after the election. For more
information on nominations, and the process refer to:
https://fedoraproject.org/wiki/Board_nominations
https://fedoraproject.org/wiki/Board/Elections
https://fedoraproject.org/wiki/Board/History
== FESCo ==
This cycle will also see four candidates elected to open seats in the
Fedora Engineering Steering Committee. For information on the
nominations and elections:
https://fedoraproject.org/wiki/FESCo_election_policy
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
== FAmSCo ==
This election cycle will also see candidates elected to fill all all
seven seats on the Fedora Ambassadors Steering Committee. For more
information, refer to:
https://fedoraproject.org/wiki/FAmSCo_election_rules
https://fedoraproject.org/wiki/FAmSCo_elections
https://fedoraproject.org/wiki/FAmSCo_election_2011_nominations
== Candidate Questionnaire and Town Hall meetings ==
Additionally, the nomination period also serves as the time for the
community to present questions to be posed to candidates. If you wish
to ask questions to be answered by candidates, you can add them at
https://fedoraproject.org/wiki/F17_elections_questionnaire. Candidates
will have the questions posed to them and responses made available to
the community before the voting period begins.
As we get closer to the elections, we will try to schedule several
Town Hall Meetings in IRC to help you get to know the candidates
better, and to ask them additional questions.
As always, I'm thankful to those who have given their time, talents,
and abilities to serve the Fedora community.
--
Jared Smith
Fedora Project Leader
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
12 years, 5 months
Trouble building for rawhide on F15
by Michael Cronenworth
It's been some time since I've had to build a Fedora package, but when I
tried today I'm having some trouble.
$ rpm -q fedpkg
fedpkg-0.5.9.2-2.fc15.noarch
$ git branch
* master
$ fedpkg build
Could not initiate build: Unknown build target: dist-rawhide
Any ideas?
12 years, 5 months
Systemd conversion versus updates in back Fedora branches
by Tom Lane
The current packaging guidelines require packages that update from sysv
init scripts to systemd scripts to provide conversion triggers that are
fired on the basis of an NVR comparison:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migra...
That is, we assume that we know that all releases with NVR < some-cutoff
use initscripts and all releases with NVR >= same-cutoff use systemd.
The comments in the above-linked page acknowledge that this means it's
impossible to upgrade the package to a newer upstream release in
pre-systemd Fedora branches. (You can't just move the cutoff value
forward, because then an upgrade in F16 or later will mistakenly re-fire
the update trigger.)
I'm really getting to the point where that's a completely unacceptable
restriction. I've already blown off one mysql bug-fix release in F15
because of this restriction, and I see they just released another one
that I'll be unable to ship in F15 because the systemd guys failed to do
their homework, and there are likely to be several more before F15 dies.
The idea I have at the moment is to ignore the advice to check package
version, and instead have the triggerun script check to see whether the
mysql sysv initscript file is present. I wonder whether anyone else has
dealt with this and has working scriptlets?
regards, tom lane
12 years, 5 months