Hi Fedora users, developers and friends!
today Fedora 19 was branched from Rawhide. That means testing season begins now and will continue till Fedora 19 Final Release, which may be (or may not be) on 2013-06-25. Please, fasten your seatbelts, fire up your virtual or baremetal machines and enjoy this crash testing ride with us.
Before Alpha will (or won't) be ready on 2013-04-16, we have prepared some Test Days for you. Starting this Thursday with KDE 4.10  with one major innovation. You are invited to try how new KDE 4.10  stuff not only using Fedora 19 Live test images, but also from updates-testing repository on your current Fedora stable installation, including both Fedora 18 and Fedora 17 releases. For first time, you can test new version of whole KDE platform before it rolls up and in as an stable update for your Fedora!
Well, you may already know about and use Bodhi with karma voting process. But Test Day provides an opportunity to actually talk to developers before KDE 4.10 reaches stable updates and interactively report, explore, debug and fix your issues (or at least find workarounds for the time being). Together we can make this update less painful for everyday Fedora KDE users.
Join IRC #fedora-test-day on FreeNode and ask QA or developers for help, if you get into trouble. We can try to find workarounds and help you with debugging. Please report all bugs under appropriate component preferably at upstream bugzilla https://bugs.kde.org/ regarding common KDE 4.10 issues or Red Hat bugzilla http://bugzilla.redhat.com/ if you have problems with Fedora distribution integration. You can also report other Fedora bugs not related to this Test Day. Feel free to ask on IRC, if you don't know against which component or on what bugzilla you should fill the report.
See you in Bugzilla!
Desktop QE, Red Hat Brno
Freenode nick: Martix
Your self-appointed Fedora 19 Test Day Wrangler.
> Von: Máirín Duffy
> On 03/12/2013 08:30 AM, Fabian Deutsch wrote:
> > What about pulling the message stuff into plymouth and using dracut to
> > trigger a reboot which shows the grub menu? Something along the lines:
> > "Press ESC to see deatils or 'b' to enter the bootloader"
> This is an interesting idea, but I don't think plymouth makes it any
> easier to display CJK & Indic glyphs. (Please someone more technical
> tell me if I'm wrong here, I vaguely remember this being an issue when
> we wanted to add a messagse to fedup)
I hoped that it would be easier to localize plymouth compared to grub2. In
addition to that we'd also get rid of problems resulting of the
interaction between grub2 s gfx stack and the kernel/plymouth, and last but
not least we wouldn't need to maintain a theme for grub.
as decided on yesterday's (2013-03-13) FESCo meeting , we are going to restart
the Rawhide Bugzilla Rebase process . Historically, it was tight to the Branch
day, but to give you more time to adjust your bugs, it will happen no sooner than
in one week from now - it means 2013-03-21.
We will be automatically changing the version for most rawhide bugs to Fedora 19.
This will result in regular bugs reported against rawhide during the Fedora 19
development cycle being changed to version '19' instead of their current
assignment, 'rawhide'. This is to align with the branching of Fedora 19 from
rawhide and to more accurately tell where in the lineage of releases the bug
was last reported. As the process wasn't followed for several releases, more
bugs than the Fedora 19 development cycle will be hit, but this will lead to
Bugzilla cleanup once Fedora 19 will hit End of Life.
Note that this procedure does not apply to bugs that are open for the 'Package
Review' component or bugs that have the ''FutureFeature'' or ''Tracking''
keywords set. They will stay open as rawhide bugs indefinitely.
If your Tracker bug does not contain ''Tracking'' keyword, please update it, so
the bug is not accidentally closed.
If you do not want your bugs changed to version '19', add the ''FutureFeature''
Please, let me know in case of any concerns/objections.
devel-announce mailing list
as per , I'd like to propose some patches for F19 comps. These patches are
splitting group called Development Tools into several smaller groups. The
purpose of this email is to find out if there is something fundamentally wrong
with the change (except for the fact that it is change).
These are key points about the patch set:
1. There should be only small visible impact to users. Currently the only tool
that is commonly using comps is anaconda and that uses the "Developer
workstation" environment. This group will contain all groups that were created
by the split to ensure maximal similarity to the old state of things.
2. All in all, the Development Tools group needed a huge cleanup, as it
contained a lot of different tools and/or devel packages but many times these
were only fractions of development environments necessary for the particular
purpose. These tools are mostly still avaiable in other groups, like C
development, Electronic Lab, ...
3. The current idea for Developer Tools group is to contain just tools that
are common/usable for development of most programming languages
4. This should bring only the "big picture change". No need to discuss what
particular packages should be in which group. That can be tuned any time
5. More groups targeted at specific areas should be created and/or reviewed
soon-ish. Among them:
feel free to suggest more development-related areas that you would like to
The goal of this effort is to start a process which would lead to more usable
comps, so users will be able (and more importantly encouraged) to simply use
for example yum to install these environments. By that time, these
environments should be cleaned up, in case user wants to install just specific
type of devel env, not the entire "Developer Workstation"
On Wed Mar 13 00:32:09 UTC 2013 Máirín Duffy wrote:
"Displaying information geared towards power users by default is
intimidating / confusing to less-knowledgeable users."
Surely if our target audience / user base is those who have a
capability / interest in contributing then we shouldn't be looking to
dumb the boot experience down - that would probably be a reasonable
choice for Mint or Ubuntu but I fail to see why it's a good one for
I've encountered a problem.
Today my gnome-settings-daemon crashed and I tried to use abrt to
feedback.After retracing abrt let me to see the environ...cmdline...and
When I clicked the backtrace tab I found it contains too many lines...Some
are hidden. But when I tried to see lines hidden by clicking arrow down,
abrt itself crashed.
This also happened in gedit. If I want to see more lines outside of current
textspace it will crash.
Please fix.My system is totally updated.
Got problems with Windows? - ReBoot
Got problems with Linux? - Be Root
Ambassador/Contributor of Fedora Project and many others.