grub linuxefi initrdefi
by Chris Murphy
Is it the responsibility of grubby, or the kernel rpm, when writing out an updated grub.cfg, to include initrdefi? And are these commands applicable on all (U)EFI?
After updating an EFI booting Mac to 3.7.4-204, I get a brief message from GRUB saying that the kernel must be loaded first, then a kernel panic. The new menu entry for this kernel uses linuxefi, but it uses initrd not initrdefi as the other entries do.
If I manually edit the grub.cfg to use initrdefi, I don't get this error or panic. And grub2-mkconfig also produces a grub.cfg using initrdefi. Therefore it appears the lack of this command causes boot failure, but I'd like to know what component the bug should be filed against.
Chris Murphy
11 years, 2 months
F19: system-config-kickstart
by Gene Czarcinski
Much is made of the great new anaconda introduced in Fedora 18. But,
this great new anaconda completely broke system-config-kickstart because
old-anaconda code used but s-c-k disappeared.
Obviously there was little or no testing of s-c-k or perhaps nobody uses
it and/or nobody cares.
https://bugzilla.redhat.com/show_bug.cgi?id=859928
Perhaps there needs to be a F19 Feature which either fixes it or
eliminates this package. The current situation is just plain ridiculous.
A lot of what s-c-k did involved software selection. Perhaps the s-c-k
interface for this needs to borrow from the "Package Manager" rather
than anaconda.
Gene
11 years, 2 months
ARM arches in F19 and forward.
by Dennis Gilmore
Hi all,
This is just a note for a wider audience. the Fedora ARM has dropped
support for software floating point going forward, we will only be
building hardware floating point binaries from Fedora 19 on. it was
discussed at FUDCon and on the arm list the FUDCon notes
https://fedoraproject.org/wiki/Architectures/ARM/Meetings/FUDCon_Lawrence...
show that we were going to look at having F19 be the last softfp
supporting release after further thought and discussion we are dropping
from F19 and F18 will be the last release supporting sfp so those with
sfp only devices, which the only supported ones are kirkwood based
devices like the guruplug will get software support for about 1 year
more.
The Raspberry Pi will be supported by the efforts at Seneca College
with armv6hl it will support hardware floating point.
Longer term we will start to support aarch64
Regards
Dennis
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Fedora ARM weekly status meeting 2013-01-30
by Paul Whalen
This weeks Fedora ARM status meeting will take place today (Wednesday Jan 30th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm
Current items on the agenda:
0) Status of ACTION items from previous meeting
1) Problem packages
2) F18 final RC planning
3) Mass Rebuild - Does anything need to be done?
4) Your topic here!
If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting.
Paul
11 years, 2 months
Static Analysis: tweaks to data model and added cpychecker support
by David Malcolm
Short version:
Updates to "mock-with-analysis" [1]:
(a) changes to the data model
(b) cpychecker support added
Longer version:
I've been hacking on "mock-with-analysis", my tool for running static
code analysis as a side-effect within a regular srpm rebuild (see [1]).
I've tweaked the data model (the "firehose" XML format [2]): before, we
were outputting one XML file every time an analysis tool found a
problem. This approach doesn't capture coverage: we wouldn't know which
tools were run on which code. So I've reworked things so that each XML
file represents a run of an analysis tool on a source file, and contains
zero or more issues (all in a common XML format). It also can contain
stats e.g. the wall-clock time of how long the analysis tool on that
file. We probably should extend it to capture other metadata like what
arguments were passed to GCC (e.g. the -W options).
I've also been working on the "cpychecker" analyser [3] that's part of
my gcc-python-plugin. This is an analyzer for C code. It looks for
common mistakes in usage of the CPython extension API, such as
reference-counting bugs.
The "firehose" branch of the gcc-python-plugin [4] now uses the firehose
Python API as the internal representation format within cpychecker, and
can thus "natively" emit XML files in our format, and I've hooked it up
in mock-with-analysis so it gets run on all C code.
So the mock-with-analysis prototype now has the following run in a mock
build:
* cppcheck
* clang-analyzer
* gcc warnings
* cpychecker
You can see an example of the output here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethto...
As before, it's the results from mock, with a new "static-analysis"
directory containing XML result files, and any source files mentioned in
the results (grep for "FAKE-GCC" in the build.log to see copious debug
spew from the analysis tools). The raw XML results can be seen here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethto...
though most of them are empty (most source files had no issues).
To make things slightly easier to read, I wrote a primitive HTML
summarizer, and you can see the (ugly) result here:
http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethto...
Note though that this output is really just for debugging. (In
particular, it's violating my #1 UI requirement, which is that any time
I see an analysis report, I want to also see the *code* so that a
developer can easily determine if she needs to act on the report -
though the sources have been captured - it's just a case of writing a
nice UI to this).
(Note that this version of cpychecker can emit reports showing a trace
of execution needed to reach certain error, and this makes it into the
XML - it's just that no such errors were present in this rpm).
Next steps are to try running it on more packages, to make things more
robust, and to build a good UI (e.g. to present a comparative view of
two builds: "what new warnings appeared?" etc).
If you're interested in getting involved, I've started making a list of
things to try here:
https://fedoraproject.org/wiki/StaticAnalysis#Tasks_seeking_volunteers
Dave
[1] see
http://lists.fedoraproject.org/pipermail/devel/2013-January/176872.html
and https://github.com/fedora-static-analysis/mock-with-analysis
[2] https://github.com/fedora-static-analysis/firehose
[3] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html
[4]
http://git.fedorahosted.org/cgit/gcc-python-plugin.git/log/?h=firehose
11 years, 2 months
Proposed F19 Feature: New firstboot
by Jaroslav Reznik
= Features/NewFirstboot =
https://fedoraproject.org/wiki/Features/NewFirstboot
Feature owner(s): Martin Sivák <msivak(a)redhat.com>
This feature proposes new initial setup application with better integration to
the NewUI anaconda and to Gnome Initial Experience.
== Detailed description ==
Since the Anaconda installer moved to the NewUI Hub and Spoke concept, we can
reuse much of it's architecture and screens in the after reboot configuration
utility -- initial-setup. So the idea behind the firstboot replacement is that
we will have a new app that will use the same Hub and Spoke model and the same
API as Anaconda.
This will give us the possibility of letting the user configure his system
either during the package extraction or after reboot (important for OEMs). It
will also allow other teams (power management, security team, IPA) to prepare
their own screens for Anaconda and initial-setup and so further enhancing the
user experience.
Anaconda, initial-setup and Gnome Inital Experience will communicate to ensure
the screens are not shown multiple times. So for example the root password
setup or user creation process will be done only in one place, depending on
the installed system.
The old Firstboot will still stay as a fallback in case somebody still has his
old Firstboot plugins he needs to use.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: MEMSTOMP
by Jaroslav Reznik
= Features/MEMSTOMP =
https://fedoraproject.org/wiki/Features/MEMSTOMP
Feature owner(s): Jeff Law <law(a)redhat.com>
Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly
detect certain library calls which result in undefined behaviour due to
overlapping memory arguments.
== Detailed description ==
MEMSTOMP is a DSO which can be preloaded by an application to detect calls to
library routines with overlapping memory arguments. Specifically MEMSTOMP will
detect calls to the following routines with overalapping memory arguments:
[w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy,
stp[n]cpy
While valgrind can detect these cases, using a DSO such as MEMSTOMP can be
significantly faster.
The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited
to the backtrace code which is not thread safe and may need to be
disabled/rewritten.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months