On Tue, 27 Mar 2012, Kevin Kofler wrote:
> My proposal is to just stop using release codenames NOW, including removing
> the name for Fedora 17
The names are useless. I can't even remember them because they seem
so arbitrary. At least the names on Ubuntu give you some indication of
which is older/newer.
If names are really needed, make them based on the most important
new features of the release. For instance, if F18's main new feature
would be a new integrity meassurement system, you can call the release
Sherlock Holmes :P Or if the next release would allow ECC, you can call
the release Elliptic Conundrum :P
I'm trying to write a yum plug-in: wait-for-kmod
For quite a few users, the kmods from RPMFusion are a must. Take
broadcom wireless for example. Now, the kmods generally lag the kernel
updates by a few hours: people who do update their systems in this
interval are left without wireless/display etc. on reboot.
We see this issue regularly in #fedora, each time a kernel update is
pushed. The plug-in will make yum skip a updating the kernel if it sees
that the corresponding kmods are not yet available for update.
I think this needs to be added in the postresolve slot, but I'm not
adept enough at the yum API yet. I have looked at the API: I spent most
of yesterday doing it. I think tsInfo is the way to go:
- Get the currently running kernel
- Get a list of installed kmods
- In postresolve hook
- check if the transaction set has kernel marked for update
- if yes, check if all installed kmods have updates too
- if all kmods aren't being updated, remove kernel from transaction
Could someone please confirm if this is the way to go? I'd be grateful
if any implementation specifics could also be given. (I was referring to
the fedorakmod plug-in in the yum-utils, but it seems to be grossly
outdated API wise)
This discussion started on the "board" list yet I know a lot of developers have an opinion on the topic.
The deadline for F18 name ideas is almost over but the discussion is still valid. Join the board list and speak up! Fedora is supposed to be community driven, take the wheel.
----- Forwarded Message -----
From: "Jaroslav Reznik" <jreznik(a)redhat.com>
To: "Fedora community advisory board" <advisory-board(a)lists.fedoraproject.org>
Sent: Friday, March 23, 2012 9:14:36 AM GMT -06:00 US/Canada Central
Subject: Connotation analysis for Fedora Project codenames
there's ongoing discussion about the connotation analysis
of Fedora Project code names (so not only for Fedora itself
but other sub-projects too) started by Rajesh Ranjan (thanks
It's a right time to get an input from community as there's
currently running Fedora 18 codename process .
As Rajesh posted to Fedora Board Track ticket, connotation is
"the emotional and imaginative association for a word, where
denotation is the strict dictionary meaning of a word."
Current process for selecting next code name is - community
members suggests the name, there's publicly accessible list for
everyone, then Board goes through the suggested names list to
remove the clear examples of names breaking the policy (yeah,
usually it's one search term in Google to find out the name has
to be ruled out, but that's Board deal ;-) and this list is
sent to Red Hat legal for proper legal review. Then the voting
is opened for everyone with valid FAS account and only names
that passed the process are allowed.
In Fedora we believe in freedom and openness, we don't have to
stick to the strict "corporate-like| rules but on the other hand we
should respect our community and we don't want to offend anyone
Usually, we use the common sense to rule out offending stuff but
also we (and Board neither) don't have a degree in sociology, politics,
religion and our geek culture is also from the another universe :).
As I already pointed out - the process is open. Anybody can step
into in the early phase of naming selection and comment the
potential problems. And I believe the Board members will think
about the concerns raised (at least me ;-).
So personally I'd like to avoid any strict rule/policy as it could
hurt our community, we don't have a proper set of skills to do
the full analysis during the Board turn and I really hope with help
provided by community we can avoid the naming problems in the
future - just we need your, community, input.
PS: I like Christoph's comment in ticket - that as an international
project we should be proud of our diversity. It is a chance and
a burden at the same time, Fedora will face this problem often and
we can do our best to respect others and their views.
advisory-board mailing list
I am diagnosing a bug/odditywith a python library that uses Pyrex and
other oddities. In the course of that, I have installed python.i686 on
my F16 x86_64 system, and I'm trying to run it and... no dice!
According to rpm, python.x86_64 and python.i686 both own
/usr/bin/python and /usr/bin/python2.7 . Those binaries are 64 bits.
Googling around, I cannot find any clue on how to run the 32 bit
Had optimistically assumed that I'd find python.i686 stashed somewhere
when I looked at rpm -ql python.686 ...
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
At the moment the GNOME updates in Fedora are a bit of chaotic affair.
They mostly work, but only because of people like mclasen who spend
hours and hours building packages and putting everything together
manually. For 3.3.92 I experimented doing a mega-update and trying to
get all the 3.3.92 builds in one place, and working with kalev on a
google spreadsheet to make sure everything was built in good time, and
nothing was left behind.
For the GNOME 3.4.0 release, I'm asking people to copy this pattern,
and try to get all the builds into *one* update rather than 90% of the
builds in one mega-update and then 10% in random updates that other
people have filed. If this works, I'm intending to do the 3.4.1 update
as one update as well.
So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92
upstream release and is about to have a 3.4.0 release, please build
the package like normal, but don't file an update. Instead add the
build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgy...
and then I'll pick up the build for the mega update.
Hopefully this makes the updates system easier to QA, as GNOME is more
and more interconnected, and it' just not possible to QA updates when
you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version
There will be a "GNOME Shell Software Rendering" Test Day on Thursday!
Here's an introduction from Vitezslav Humpa, who's in charge of this event from QA perspective:
This week brings a second installment of Fedora Test Day targeting GNOME 3. This time we will focus on software rendering providing a full GNOME session purely by means of the CPU. Nowadays with most of personal computers capable of hardware 3D acceleration this might seem unnecessary. But let's not forget a whole lot of us who have capable but yet unsupported hardware and get stuck with the Fallback mode.
And this is not the only case. In addition to computers with obsolete graphics there are VM hypervisors like KVM or VirtualBox that don't support full 3D yet. Fedora can also run on many kinds of less usual devices like tablets or netbooks that don't have free (or even proprietary) drivers ready.
Simply said, our goal is to make sure that no matter what hardware you are running your Fedora on, you will always get the user experience you are entitled to - a full GNOME desktop.
Do you have an older PC? Netbook? Or do you like to play with the latest of the latest in VM, where it won't "break" your computer? Even if not, please help us test the GNOME Shell software rendering by following few test cases and catching a few bugs - after all, as always with Fedora, you'll be doing that for yourself :-)
Time: all day
test-announce mailing list
I am Alex Chernyakhovsky. I am currently a 2nd-year student at the
Massachusetts Institute of Technology, studying Electrical Engineering and
Computer Science. I am a long-time user of Red Hat Linux, Fedora, and Red
Hat Enterprise Linux.
I greatly admire the work the Fedora contributors do, and for the longest
time have wanted to participate beyond simply reporting bugs. I now wish
to become a Fedora Packager, and finally have the opportunity to do so. I
have packaged "Mosh: the mobile shell". The review request can be found