I currently maintains fusioninventory stack in Fedora / EPEL
perl-FusionInventory-Agent-Task-NetDiscovery (to be EOL)
perl-FusionInventory-Agent-Task-NetInventory (new in F18, to be EOL)
perl-FusionInventory-Agent-Task-OcsDeploy (EOL in f17)
perl-FusionInventory-Agent-Task-SNMPQuery (EOL in f18)
Missing (new) package
(which replace Task-NetDiscovery and Task-NetInventory)
Because of lack of time (new job), lack of interest (I don't use it
anymore) and lack of understandind with upstream, this stack need a new
I will also accept a co-maintainer, to work with (for some time)
Else, I plan to orphan this stack and ask to remove packages from
I have had no success whatsoever getting DirectFB to run under F17 as a regular user on my HP laptop.
# yum list DirectFB
I have discussed the problems on the DirectFB mailing list and they direct me back to the distro.
When trying to run any DirectFB command as a regular user I get permission errors like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.5.3 |~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2001-2010 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
(*) DirectFB/Core: Single Application Core. (2012-05-19 15:35)
(*) Direct/Memcpy: Using Generic 64bit memcpy()
(!) DirectFB/core/vt: Error opening `/dev/tty1'!
--> Permission denied
(!) DirectFB/Core: Could not initialize 'system_core' core!
--> A general initialization error occured
(#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured
Even when I go and change the permissions on /dev/ttyX and /dev/fb/0 and then put those into udev rules then I still get
an error about MEDIUMRAW mode.
I am able to run some DirectFB commands as root but that is no good for creating app for general user.
Can anyone, developer, packager, shed some light on why DirectFB will not run on F17 as a regular user?
Join us on irc.freenode.net in #fedora-meeting-1 for this important
meeting, wherein we shall determine the readiness of the Fedora 18 Alpha.
As previously announced last week, we moved Go/No-Go two hours earlier.
Thursday, September 06, 2012 @21:00 UTC (15:00 EDT/21:00 CEST)
"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."
"Verifying that the Release criteria are met is the responsibility of
the QA Team."
For more details about this meeting see:
In the meantime, keep an eye on the Fedora 18 Alpha Blocker list:
Jaroslav Řezník <jreznik(a)redhat.com>
Your Schedule Wrangler
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://www.redhat.com/
test-announce mailing list
As you may have noticed, new ABRT 2.0.12 has recently been pushed to
Fedora. Besides significant changes in reporting workflow, it also uses
the ABRT server to collect what we call uReports (micro-reports).
uReport is a short (usually < 4kB) fingerprint of the crash, with no
private information in it. It contains some basic data (package,
architecture, kernel... NO hostname, NO username etc.), together with a
debuginfo-less backtrace consisting of binary names, build-ids, function
offsets, function names (if available) and some fingerprints helping in
After uploading the uReport to ABRT server, the backtrace is completed
- missing function names, source file names and line numbers are added.
A clustering algorithm is ran periodically on the reports. It searches
for similar uReports and groups them into "Problems". We divide these
into two categories:
1) Hot problems: started appearing recently and happen often. Should be
2) Long-term problems: started appearing long time ago, they do not
happen often, but they are still reported sometimes. There are no
long-term problems yet, as there is some minimal age limit.
After receiving uReport, the server responds whether the problem is
already know or not. In the case it is known, the reporting process
stops and you can see both Bugzilla URL and ABRT Server URL. Otherwise
standard BZ-reporting process continues.
You can browse reports and problems through the webUI
We believe this will help developers to better prioritize their work and
make debugging easier (crashes in common libraries are grouped into a
single problem, for each crash versions of affected
packages/architectures are listed etc.).
Any feedback or RFEs are welcome !
Michal & ABRT Team
mercurial-2.3.1 will not build on f18 because of the python-docutils version.
It does build on f17, and also on f19.
1. Can we update f18 to this version?
2. Is there someway to get mercurial built using some kind of build overide?