On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote:
Various projects have been adding AM_SILENT_RULES from Automake to
their Makefiles for developer convenience; the goal being that they
see warnings more easily.
It is inconvenient as one can no longer easily reproduce the compilation for
On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote:
the goal being that they see warnings more easily.
You should make -Werror default instead, by compiling packages without -Werror
various bugs creep in which would be much easier fixed before the compilation.
Regards,
Jan
--
devel
On Tue, 09 Aug 2011 19:14:27 +0200, Adam Jackson wrote:
If you're volunteering to fix and/or paper over all the spurious
warnings gcc and glibc introduce with every phase of the moon, then
sure.
Yes, I do it for my component, GDB has -Werror default in development phases
upstream. It cleans
On Tue, 09 Aug 2011 19:16:54 +0200, Matthew Garrett wrote:
Never, ever ship software with -Werror enabled.
I agree - for source distribution. Yes, GDB releases have -Werror turned off.
It's a development-only
option. You have no idea what gcc will decide is a warning in future, so
it's
On Tue, 09 Aug 2011 19:39:55 +0200, Kalev Lember wrote:
Please reread the whole message; this passage only reasons why various
UPSTREAMS have chosen to use silent rules. The patch is all about
globally enabling the verbose mode, exactly the same you were proposing
in the kernel ticket.
OK,
On Tue, 09 Aug 2011 19:45:15 +0200, Matthew Garrett wrote:
If a package fails to build in a mass rebuild because -Werror was enabled
then that's additional work for several people to fix something that may not
have ever actually been broken.
99% of warnings will not lead to user visible bugs.
On Sat, 20 Aug 2011 20:31:55 +0200, John Reiser wrote:
Anaconda requires 768MB, and more (=1GB) if there is no swap partition.
[...]
Use the installer that is available on a Live spin, instead of using
anaconda.
This reduces the memory requirements by 128MB:
On Fri, 02 Sep 2011 23:02:04 +0200, Adam Williamson wrote:
about the 'fedora' branch of upstream glibc.
GDB uses a similar style for the merged patchsets in the Archer repository:
http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-archer.patch;hb=f16
Given that this
On Sat, 01 Oct 2011 13:33:13 +0200, drago01 wrote:
but the suspend does not work on desktop argument is simply not true
Not replying to metoo/flames but neither suspend nor hibernate worked reliably
for me through years on notebook (T60). Depending on BIOS and kernel versions
the former or
On Mon, 03 Oct 2011 17:34:45 +0200, Bastien Nocera wrote:
I'm not sure how we can make DPI magically be correct in gazillions of
broken displays' EDID.
If not blacklisting then whitelisting them, you have the community. This is
X.org's task, though.
Regards,
Jan
--
devel mailing list
On Sun, 09 Oct 2011 18:20:56 +0200, Christoph Wickert wrote:
I already gave a reason why we should maintain these packages as RPM,
but unfortunately you have trimmed that part of my mail: There is no way
to install and manage extensions globally for all users on a computer.
There is also no
On Sat, 26 Nov 2011 23:40:58 +0100, Gregory Maxwell wrote:
Here is what my F14 laptop has:
http://people.xiph.org/~greg/packagekit.png
It can be configured to only show end-user graphical applications
That's not enough. I use my grandfather unaffected by prior MS-Windows
experience as a
On Sun, 27 Nov 2011 02:26:44 +0100, Jan Kratochvil wrote:
(3) He is not going to wait for installation of new games to try them.
He wants to just click and run the game - like he does with Flash games,
immediately.
I have no problem running there:
yum --setopt
Hi,
Could Koji provide all the available versions of packages in a repository?
Even http://koji.fedoraproject.org/static-repos/ indexes only the latest
package versions there. Also f14 is not available there.
--
On Mon, 13 Sep 2010 21:42:02 +0200, Kevin Fenzi wrote:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic.
I find this
On Sun, 26 Sep 2010 19:58:05 +0200, Bruno Wolff III wrote:
On Sun, Sep 26, 2010 at 10:40:22 -0700, John Reiser jrei...@bitwagon.com
wrote:
Compiled code for minimum(), maximum(), etc. suffers from a compiler bug:
https://bugzilla.redhat.com/show_bug.cgi?id=634757-O1 wrong-code by
On Mon, 27 Sep 2010 19:53:09 +0200, seth vidal wrote:
On Mon, 2010-09-27 at 13:48 -0400, Gregory Maxwell wrote:
When will the Fedora project begin recommending x86_64 as the
preferred option on the relevant hardware?
i686 will run on x86_64 and i686 machines and on the overwhelming
On Sun, 24 Oct 2010 10:45:38 -0400, Mark Bidewell wrote:
Sorry if this has been discussed, but has there every been discussion
of a dual 32/64-bit install media?
/usr/bin/mkbiarch is included in livecd-tools-034-2.fc14 upwards:
On Sun, 07 Nov 2010 00:36:58 +0100, Vaclav Mocek wrote:
I have read some articles about the Cold Boot Attacks and I am
wondering whether my Fedora box is protected against such kinds of
attack, at least to some extent.
If you have physical access to the box there is no security left.
On Sun, 11 Nov 2012 18:39:29 +0100, Reindl Harald wrote:
please no - O2 is a performance improvement while minidebuginfo is
the opposite, not only bloating the size, also bloadting the data
to laod from disk
FYI minidebuginfo does not affect loading from disk (mostly) in any way.
See 'readelf
Hi,
as elfutils package is going to contain unwinder in its next release orphaning
the libunwind library.
https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 26 Nov 2012 12:23:16 +0100, Mat Booth wrote:
Won't you need to retire it when elfutils obsoletes it?
The development is not yet at that point, it may happen later:
(1) elfutils needs to integrate it and get released first (January/February),
being worked on with Mark Wielaard:
On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
So are you not orphaning libunwind until that is merged into the
upstream kernel?
To get the terminology right:
I am 'orphaning' it now. Later it may be 'obsolsted'.
If I should keep it formally maintaining I could. But factically it
On Mon, 26 Nov 2012 15:22:08 +0100, Jan Kratochvil wrote:
On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
So are you not orphaning libunwind until that is merged into the
upstream kernel?
To get the terminology right:
I am 'orphaning' it now. Later it may be 'obsolsted'.
Probably
On Mon, 26 Nov 2012 23:44:24 +0100, Lennart Poettering wrote:
On Mon, 26.11.12 11:23, Mat Booth (fed...@matbooth.co.uk) wrote:
On 24 November 2012 07:40, Jan Kratochvil jan.kratoch...@redhat.com wrote:
Hi,
as elfutils package is going to contain unwinder in its next release
On Tue, 27 Nov 2012 02:48:00 +0100, Toshio Kuratomi wrote:
But these are just implementation. Ideally we want every package that gets
released to the users to have a maintainer that is watching bug reports and
attempting to fix anything serious.
There are serious bugs so that some cases are
On Fri, 23 Nov 2012 10:56:24 +0100, Andrew Haley wrote:
On 11/13/2012 10:23 PM, Kevin Kofler wrote:
Kevin Fenzi wrote:
Sometimes things aren't ideal for one group in favor of another.
WHAT group is actually in favor of MiniDebugInfo? It has one single person
as the feature owner. ABRT
On Thu, 27 Dec 2012 14:30:25 +0100, Ilyes Gouta wrote:
file /usr/bin/gdbus-codegen from install of
glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package
glib2-devel-2.32.4-2.fc17.x86_64
Not addressing here.
file /usr/share/glib-2.0/gdb/glib.pyc from install of
On Thu, 27 Dec 2012 16:09:51 +0100, Antonio wrote:
My internet connection implicates an outdoor antenna equipped with a
management software that includes a firewall (as well as other
services like NAT, UPnP, DDNS, ...);
After trying to workaround this and that ISP/WiFi router I have found most
On Wed, 16 Jan 2013 13:18:19 +0100, Richard W.M. Jones wrote:
So there are a couple of issues with btrfs which I believe absolutely
must be fixed before it can become the default (both affect
virtualization, coincidentally):
It affects also compilation, GDB was rebuilding for 10-15 minutes
On Wed, 16 Jan 2013 04:12:29 +0100, xning wrote:
Shall we should modify '-g' to '-g3' to have gcc save the macro
info? So when we install *-debuginfo packages, we can look up a
macro definition, just like we can look up a function definition.
That would be great, I have not found any official
On Fri, 18 Jan 2013 23:57:38 +0100, Rahul Sundaram wrote:
I wouldn't read it that rigidly. Its more along the lines of, its more
helpful to file bug reports and post them for discussions because its
easier to keep track of.
I have already filed enough stopper Bugs for btrfs and nothing
On Mon, 28 Jan 2013 09:22:16 +0100, Nikos Roussos wrote:
True. Or others might consider it productive. Same goes for all Desktop
environments. That's why I said that I see no real argument here for
changing our default desktop.
Could we make a web poll for preferred desktop and make the top
On Mon, 18 Jan 2010 09:06:13 +0100, Jiri Moskovcak wrote:
On 01/17/2010 06:49 PM, Camilo Mesias wrote:
This is a good point, the users shouldn't really have to install
debuginfo for a one-off use. It would be better for a central server
or service to have access to all the debuginfo files
On Mon, 18 Jan 2010 09:18:11 +0100, Jiri Moskovcak wrote:
On 01/17/2010 05:57 PM, Christoph Wickert wrote:
5. Instead of hashes the missing debuginfo packages should be
listed with n-v-r, so people can install them manually.
This could be a problem. ABRT determines the required
On Mon, 18 Jan 2010 11:19:29 +0100, Jiri Moskovcak wrote:
On 01/18/2010 11:17 AM, Jan Kratochvil wrote:
Currently ABRT can at least run `rpm -qf MAIN_EXECUTABLE
ALL_GDB_INFO_SHARED_DISPLAYED LIBRARIES FILENAMES' and report these nvrs in
the Bugzilla bugreport before such build-id - nvr
On Wed, 28 Aug 2013 06:48:24 +0200, Jon Miller wrote:
How do the experts build the i686 x86_64 packages? (I did notice the Build
Host varies between the two, so I'm wondering if I need to build a 32bit
Fedora 18 instance to repeat this build process?)
With some packages it is possible to run:
On Thu, 12 Sep 2013 10:42:20 +0200, Peter Lemenkov wrote:
I'm afraid that's just adds additional work for maintainers w/o any
visible benefits.
The benefits are the stable Fedora release does not break 3rd party
applications during its deployment/lifecycle.
Let's move further instead of
On Sat, 14 Sep 2013 11:56:26 +0200, Richard W.M. Jones wrote:
/usr/lib/debug/.build-id/da/39a3ee5e6b4b0d3255bfef95601890afd80709.debug
which is a symlink to:
/usr/lib/debug/.dwz/ocaml-pcre-7.0.2-5.fc21.x86_64
[...]
/usr/lib/debug/.build-id/da/39a3ee5e6b4b0d3255bfef95601890afd80709.debug
On Sat, 14 Sep 2013 14:17:28 +0200, Richard W.M. Jones wrote:
What I didn't understand is what these /usr/lib/debug/.dwz/* files
are. Are they related to some files that we're building and how?
It is the dwz (=debuginfo size optimizer) option -m:
-m FILE --multifile FILE
[...] create
On Sat, 14 Sep 2013 23:53:53 +0200, Richard W.M. Jones wrote:
On Sat, Sep 14, 2013 at 02:21:45PM +0200, Jan Kratochvil wrote:
It is the dwz (=debuginfo size optimizer) option -m:
-m FILE --multifile FILE
[...] create ELF object FILE and put debugging information duplicated
On Sun, 15 Sep 2013 01:39:00 +0200, Frank Ch. Eigler wrote:
But anyway, pure content-based build-ids are IMHO misguided (since they
presume non-conflict from external coincedences), thus my salting
proposal/patch in BZ1002341.
The fix is in debugedit. This means that use of dwz in non-rpm
On Sat, 21 Sep 2013 20:12:41 +0200, Phil Dobbin wrote:
I was wondering as to why Ananconda has no facility to overwrite a
distro already present on the target machine. I've studied it
apart from destroying the existing partition with GParted there
seems to be no other way (this happens on 18
On Sun, 22 Sep 2013 03:21:32 +0200, Reindl Harald wrote:
now we have exactly what i said will happen: users in trouble does not know
how to
boot the still installed older kernel because they never learned that there
are
more than one because they never faced it as all the years before
My
On Sun, 22 Sep 2013 18:24:45 +0200, Reindl Harald wrote:
Am 22.09.2013 18:13, schrieb Jan Kratochvil:
My grandfather still believes those are multiple _different_ Fedora
installations, each having different games/files. As he has also CentOS
menu
item there having multiple Fedora items
On Tue, 15 Oct 2013 16:21:01 +0200, Daniel P. Berrange wrote:
To justify removing it, we just need to collect data to show that those
performance benefits no longer exist, with current hardware and software
combination in Fedora. That is what this email thread is seeking to confirm.
There is
On Tue, 15 Oct 2013 16:59:59 +0200, Daniel P. Berrange wrote:
I wouldn't read that as saying that prelink is slowing down startup,
rather that the benefit of prelink is so small as to be indistinguishable
from the background noise.
That's the problem we even disagree how to read the numbers.
On Tue, 15 Oct 2013 17:04:05 +0200, Matthew Miller wrote:
But, since prelink presents other problems on its own,
Prelinked system is a good test for tools like GDB, elfutils and others they
can properly handle the displacements of sections/segments.
This is something that ELF does not forbid so
On Tue, 15 Oct 2013 18:27:23 +0200, Dhiru Kholia wrote:
In spite of this fact, I believe that they are enough to demonstrate
that prelink is not resulting in any big gains anymore.
Nobody says prelink brings _big_ gains. It is just a negligible performance
and negligible battery optimization
On Tue, 15 Oct 2013 19:42:25 +0200, Reindl Harald wrote:
* look at the amount of updates and how they hit prelinked libraries until
prelink ran again
* look at the lsof | grep DEL | grep /usr output caused by prelink
Sorry I do not see what disadvantage is it?
* look at the wasted cycles
On Tue, 15 Oct 2013 19:50:44 +0200, Simo Sorce wrote:
Many tools need to juggle the fact these binaries have been changed, and
make checkers more complex and prone to faults.
So let's build the whole system with -O0 and we can throw away most of
compilers and half of debuggers, which are all
On Tue, 15 Oct 2013 19:54:21 +0200, Chris Adams wrote:
Now you are wasting a chunk of RAM, as it can't be shared between
non-prelinked and prelinked bins/libs.
OK, yes. I believe with RAM prices and therefore RAM sizes nowadays you will
still have overall better system performance with
On Tue, 15 Oct 2013 19:54:15 +0200, Reindl Harald wrote:
have fun in distinct between prelink caused needs-restarting or real
This is a bug of update system it does not know if an updated service needs
restarting or not.
your notebooks are running 24 hours a day?
really?
OT: Yes, really. I
On Tue, 15 Oct 2013 20:24:06 +0200, Reindl Harald wrote:
Am 15.10.2013 20:07, schrieb Jan Kratochvil:
This is a bug of update system it does not know if an updated service needs
restarting or not.
you can always point with your finger somewhere else
the better way is solve the root cause
On Tue, 15 Oct 2013 20:25:10 +0200, Paul Wouters wrote:
- complexity
- complicated prelink blacklists
- complicated cron job exclusion with sysconfig
You can always make your software development life more simple by giving up on
some useful feature. That -O2 vs. -O0 build is a good
On Tue, 15 Oct 2013 20:54:06 +0200, Chris Adams wrote:
Since you keep repeating this one: -O2 vs. -O0 has a significant
performance gain. The message that started this thread indicates that
prelink may not have a significant gain anymore. If that's the case,
than _any_ effort is not worth
On Tue, 15 Oct 2013 21:08:40 +0200, Reindl Harald wrote:
Am 15.10.2013 21:05, schrieb Jan Kratochvil:
It depends, for example in this case prelink saves 33% of time (and
battery):
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
where
On Tue, 15 Oct 2013 21:10:34 +0200, Chris Adams wrote:
Do you really run gnome-open --help 1000 times per reasonable unit of
time (or ever)? Please stop using bogus comparisons and highly
contrived tests. They do nothing to help your argument.
The goal of this example was to show that in a
On Tue, 15 Oct 2013 21:59:13 +0200, Paul Wouters wrote:
On Tue, 15 Oct 2013, Jan Kratochvil wrote:
Disable/uninstall prelink for FIPS.
I tried that. I submitted a patch for prelink to un-prelink on
de-install in %preun. It has been ignored by you for over a year and
I seriously had
On Tue, 15 Oct 2013 22:12:00 +0200, Matthew Miller wrote:
On Tue, Oct 15, 2013 at 09:05:03PM +0200, Jan Kratochvil wrote:
i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help
/dev/null;i=$[$i+1];done
I hope we can all agree that this is not useful example.
Explained
On Tue, 15 Oct 2013 23:51:18 +0200, Dridi Boukelmoune wrote:
$ rpm -V libreoffice-core
prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1
Repeating for the third time in this thread:
This is a known prelink Bug and you can find the single line fix/workaround
there:
On Wed, 16 Oct 2013 09:20:02 +0200, Dridi Boukelmoune wrote:
I understand, but what bothers me isn't the prelink bug but prelink
itself being installed by default (for what it does regardless of the
bug).
What exactly bothers you? It (generally) speeds up programs startup.
As a summary I see
On Wed, 16 Oct 2013 11:56:44 +0200, Florian Weimer wrote:
So even in that totally artificial case, we gain very little,
considering the trouble that prelink is.
After all the discussion I have listed the current known issues:
prelink performance gains [summary]
On Wed, 16 Oct 2013 14:45:00 +0200, Reindl Harald wrote:
why waste time and energy to fix things with little to no benefit
IIRC compiler team spends 1.5 year to get 1% of performane gain.
Here you have almost ready feature with up to ... questionable but it is in
a range of percents in some real
On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote:
prelink throws rocks at a lot of packages that have to check the
integrity of the shared libraries they are using. It provides no real
useful way of assisting in those tasks,
It provides 'prelink -y' only for exactly that purpose.
There
On Thu, 17 Oct 2013 16:28:07 +0200, Josh Boyer wrote:
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote:
On Thu, 17 Oct 2013, Jan Kratochvil wrote:
I agree there remains some work on prelink itself and some packages
around to make prelink relevant again
I don't
On Fri, 25 Oct 2013 01:07:15 +0200, Adam Williamson wrote:
generate the SRPM and do 'koji build --scratch fXX blah.src.rpm' , where
You would have to rpmbuild -bs *.spec first to get blash.src.rpm.
It is done all by: fedpkg build --scratch --srpm
The problem is that it uploads the whole
On Sun, 24 Nov 2013 16:50:51 +0100, Sandro Mani wrote:
A nice solution to ensure consistency could be to have each
debuginfo package require the exact version of the base package
installed. Since the debuginfo package however cannot know which
base (sub)package it should depend on, I wonder
On Tue, 26 Nov 2013 11:39:38 +0100, Sandro Mani wrote:
Here is a quick and dirty spec implementing the idea I described:
[1]. From what I can see it behaves correctly with any combination
of packages and subpackages installed. Am I missing something?
[1]
On Sun, 29 Dec 2013 13:17:49 +0100, Richard Fearn wrote:
On 29 December 2013 11:29, Brendan Jones brendan.jones...@gmail.com wrote:
Thanks. I had tried this but still no core in the executing directory. Now
I'm not sure where they are going - certainly nowhere in $HOME.
Could be a couple
On Tue, 16 Nov 2010 18:57:19 +0100, Karel Klic wrote:
Dne 16.11.2010 11:04, Nicolas Mailhot napsal(a):
Le Lun 15 novembre 2010 23:51, Karel Klic a écrit :
Major advantage of the retrace server is that you can get a good
backtraces even from unfresh coredumps.
And why can't this be done
Hello,
filed month+ ago:
https://bugzilla.redhat.com/show_bug.cgi?id=643296
Simple fix of memory corruption affecting various applications incl. Firefox.
Completed Policy for nonresponsive package maintainers there, got an
off-list reply but still no fix commit or commit rights
On Sat, 20 Nov 2010 22:24:46 +0100, Miloslav Trmač wrote:
The packages have an automated test suite. I test the code
changes as applied the main branch. I test the final update RPMs
rebuilt locally my system.
Given all this testing, I'm not going to spend time testing the
particular
On Sat, 20 Nov 2010 22:42:57 +0100, Miloslav Trmač wrote:
I personally can say that the week-long delay significantly diminishes
my enjoyment of backporting patches into existing Fedora releases.
Being able to spend 30 minutes fixing a bug for an user and getting an
immediate feeling of
On Sat, 20 Nov 2010 22:52:51 +0100, Kevin Fenzi wrote:
but I think it might be good to get a few
motivated maintainers for the fedora package.
Also think so.
Twinkle sound is choppy when using pulseaudio, the details are not important
here as I have not even filed it when the pulseaudio Bugs
On Sun, 21 Nov 2010 01:52:02 +0100, Ray Strode wrote:
On Sat, Nov 20, 2010 at 4:52 PM, Kevin Fenzi ke...@scrye.com wrote:
Completed Policy for nonresponsive package maintainers there, got an
off-list reply but still no fix commit or commit rights approval.
Lennart is surely around...
I
On Mon, 22 Nov 2010 00:32:38 +0100, Matt McCutchen wrote:
On Sat, 2010-11-20 at 23:09 +0100, Jan Kratochvil wrote:
One has to give up on backporting new fixes to ever get any delivered.
That's not true. You can continue committing fixes and running builds
in Koji; just don't submit another
On Thu, 09 Dec 2010 20:39:24 +0100, Jiri Moskovcak wrote:
On 12/09/2010 07:46 PM, Adam Jackson wrote:
I have trouble following what you're saying here. At what point does
one need to read the whole debuginfo file?
I'm referring to this:
On Thu, 09 Dec 2010 17:10:49 +0100, David Malcolm wrote:
Another gratuitous me too, see:
https://fedoraproject.org/wiki/Talk:Features/RetraceServer
Detailed description:
[...] User sends the coredump [...]
Do you intend to make it default for Fedora?
So far I thought it is not acceptable
On Mon, 21 Feb 2011 10:36:05 +0100, Panu Matilainen wrote:
A more likely candidate for new dependencies appearing is that rpm now
collects dependencies from perl's use base qw syntax, which older
versions did not.
filed now as:
https://bugzilla.redhat.com/show_bug.cgi?id=679014
On Mon, 21 Feb 2011 15:22:48 +0100, Ralf Corsepius wrote:
On a second thought - May-be it would be more suitable for perl to parse
the *.pods, such XS-modules normally are accompanied with?
As discussed in
[Bug 679014] rpmbuild: Perl excessive auto-Requires
On Tue, 22 Feb 2011 06:57:20 +0100, Ralf Corsepius wrote:
On a more abstract level one may consider perl's META.yml-machinery to
be a package dependency tracking machinery of its own, in parallel to
rpm's dependency tracking machinery, with the essentially the same
issues, problems and
On Thu, 24 Feb 2011 09:28:10 +0100, Karel Klic wrote:
I have written a script which checks the completeness and correctness of the
debuginfo packages.
Thanks, it would be great to run it automatically like the `Broken deps'
checker.
Regarding the report below: it is interesting that
On Fri, 04 Mar 2011 14:07:51 +0100, Neal Becker wrote:
got removed, and a useless debuginfo replaced it.
The repositories are never in sync, it was tracked by:
Debug info RPMs do not require exact maching binary rpm
https://bugzilla.redhat.com/show_bug.cgi?id=151598
with some
Hi,
just tried -ffunction-sections -Wl,--gc-sections on F15 xulrunner and got
libxul.so 24947928 - 23631640 (5.28% gain) and it still works.
ld.gold --icf is a different optimization but that one requires gold.
Are there some serious Bugs why Fedora is not using it?
Thanks,
Jan
--
devel
On Thu, 24 Mar 2011 17:06:09 +0100, Adam Jackson wrote:
For example, if I'm the X server, I have a bunch of symbols exported
from the binary that the drivers are expected to call, but that are
never called from the server itself. Does marking a function
__attribute__((visibility(default)))
On Sun, 27 Mar 2011 11:22:48 +0200, gia...@gmail.com wrote:
I'm trying to rebuild a package with an autotools based toolchain and
it's failing because they use -Werror and gcc 4.6 spits out few new
warnings on the code.
You should fix those erors and and submit them upstream.
Now, is it
On Mon, 28 Mar 2011 16:55:35 +0200, Karel Klíč wrote:
I have observed GDB displaying wrong source file lines when stepping through
a program several times, and I think such a check could discover some
issues.
Could you provide a reproducer? How it could be fixed by the package
maintainer?
If
On Tue, 12 Apr 2011 20:16:45 +0200, Jeff Garzik wrote:
While I don't care about accelerated X support, this hardware darned
well better continue working in an it works 2D display mode. VESA or
whatever is fine.
VESA is not fine, ancient Free drivers are debuggable code when something
On Tue, 12 Apr 2011 22:09:36 +0200, Matthew Garrett wrote:
In any case, it's vital that VESA work given that it's the only
way to bring up hardware that's newer than the install image -
increasing its test coverage can only be a good thing.
It does not make sense to test VESA as we cannot
On Sun, 01 May 2011 22:31:42 +0200, Kevin Kofler wrote:
Yes, all the packages which have WORKING support for SSE etc. in Fedora do
that. See e.g.
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/solid/solid/backends/shared/cpufeatures.cpp
On Mon, 02 May 2011 17:24:53 +0200, Kevin Kofler wrote:
Jan Kratochvil wrote:
There is the STT_GNU_IFUNC feature implemented for it - the indirect is
handled by linker without an additional indirect overhead if applied for a
shared library function. For apps it works in a similar way
On Sat, 11 Jun 2011 19:30:10 +0200, Michael Cronenworth wrote:
As for the subject at hand, -I- find VB a far inferior solution when it
comes to SMP and IO (disk/network) performance.
With the latest VB and the SATA controller I see faster performance in the
VM over bare hardware.
This is
On Sun, 12 Jun 2011 13:19:23 +0200, Jared K. Smith wrote:
We were able to work through all the technical issues with the
proposal, and Release Engineering has created Multi-Desktop LiveDVD
images for Fedora 15. They even auto-detect whether you're on an i386
or x86_64 platform, but of course
On Sun, 12 Jun 2011 14:16:41 +0200, John Reiser wrote:
1GB USB flash storage often can be scavenged for no monetary cost.
2GB USB flash storage more often costs real money.
I got my 2GB flash for free, I do not find this 1GB-2GB difference relevant,
the availability also differs according to
On Sun, 12 Jun 2011 15:49:18 +0200, Christoph Wickert wrote:
* It is still a new technology and only got a very limited amount
of testing [1]. It was not tested during the release cycle at
all but only last minute. Making it default would IMHO be to
risky.
It is
On Tue, 12 Jul 2011 15:22:53 +0200, Richard Shaw wrote:
I'm trying to remotely download a package from a koji scratch build
but it doesn't work.
# curl -L -O
http://koji.fedoraproject.org/koji/getfile?taskID=3192896name=BackupPC-3.2.1-1.fc14.src.rpm
Scratch download links should be direct
On Sat, 09 Jul 2011 09:08:20 +0200, Amit Saha wrote:
0 Stray cats were added..
Was wondering what's the background?
/usr/share/doc/man-db-*/man-db-manual.*
Regards,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote:
I just wrote a new Feature proposal for shipping minimal debug info by
default:
https://fedoraproject.org/wiki/Features/MiniDebugInfo
The several choices is missing the primary possibility of no debug info
needed at the client side
On Mon, 07 May 2012 16:34:27 +0200, Jakub Jelinek wrote:
For bug reporting, you don't need to upload core files, if all you want
is to augment backtraces with symbol info and perhaps line info, then
all you can do is just upload backtraces without symbol info/line info,
supply the relevant
1 - 100 of 360 matches
Mail list logo
