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 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 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 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, 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 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 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 Sun, 11 Aug 2013 09:25:37 +0200, Jan Kratochvil wrote:
neither Ekiga nor Linphone can make a call with http://voocall.cz SIP
provider. It works with Twinkle. (All F-18.)
Ekiga Bug with pcaps: https://bugzilla.gnome.org/show_bug.cgi?id=705783
Linphone Bug with pcaps: https
, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
On Tue, 12 Mar 2013 02:03:16 +0100, Jared K. Smith wrote:
I *once* had Ekiga working, but it gave me so many problems a few years ago
that I had given up on it.
Exactly. I even bugreported multiple SIP incompatibilities and got them
On Mon, 05 Aug 2013 20:38:27 +0200, Mario Ceresa wrote:
--
-- vtk-devel-6.0.0-7.fc20.x86_64
Error: Package:
3:texlive-dvips-bin-svn30088.0-0.3.20130608_r30832.fc20.1.x86_64 (build)
Requires: texlive-kpathsea-lib = 3:2013-0.3.20130608_r30832.fc20
Installing:
On Mon, 05 Aug 2013 09:47:02 +0200, Richard W.M. Jones wrote:
I'm BuildRequiring the following:
BuildRequires: texlive-texconfig, texlive-latex-bin-bin, texlive-dvips-bin
BuildRequires: texlive-metafont-bin, texlive-cm, texlive-ec
BuildRequires: texlive-preprint, texlive-cm-super,
On Mon, 05 Aug 2013 17:44:31 +0200, Peter Oliver wrote:
Does anyone know if there's way for me to force Koji to build a noarch
package on ARM??
Koji should run each noarch package on every arch (or arm + 1 non-arm) to
catch various packaging bugs. At least during mass rebuilds.
Jan
--
devel
On Sun, 28 Jul 2013 21:36:54 +0200, Ville Skyttä wrote:
On the other hand with doc-only subpackages
I personally think that it would often make sense to install into the
main package's docdir instead of creating a separate dir, e.g. for a
package named foo, IMO it's better to have all docs in
On Mon, 29 Jul 2013 17:58:19 +0200, Ville Skyttä wrote:
If it should be /usr/share/doc/gdb/ then rpm macros need to be changed first
accordingly to s/-doc$// on the directory name.
I don't think that's desirable.
And a reason why?
Therefore currently keeping the path
On Mon, 29 Jul 2013 20:38:21 +0200, Björn Persson wrote:
I'm not convinced that there is a real need to give each subpackage its
own directory in /usr/share/doc.
For example -devel subpackage documentation is typically not interesting for
a user searching normal documentation.
Moreover one
On Thu, 25 Jul 2013 10:03:57 +0200, Panu Matilainen wrote:
On 07/25/2013 10:52 AM, Jamie Nguyen wrote:
Today, the %configure macro swallowed a backslash linking the next line,
[...]
Looks like breakage caused by the recent libtool-related hardening
hackery in redhat-rpm-config
On Mon, 17 Jun 2013 17:09:57 +0200, Dan Mashal wrote:
if I'm doing anything Android related (or other various things) I must use
sun jdk/jre.
Is it filed/tracked/known?
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 11 Jun 2013 13:37:09 +0200, Peter Hatina wrote:
cpio: wireshark-1.2.15/asn1/x509if/packet-x509if-dis-tab.c: Cannot stat:
No such file or directory
[...]
Does find-debuginfo.sh get confused, or where do those non-existing
files come from?
They come from #line cpp directives which get
On Tue, 11 Jun 2013 15:59:15 +0200, Richard W.M. Jones wrote:
Interesting .. that explains a bug in OCaml builds too:
In fact this bug is very common across packages, there was an attempt to check
all the debuginfos and possibly file Bugs but it has never been finished:
Bugs in debuginfo
On Tue, 04 Jun 2013 16:19:17 +0200, Martin Milata wrote:
I noticed that the MiniDebugInfo files in Fedora 19
(F18 too) have different ELF program header tables than the
corresponding binaries and separate debuginfo files:
MiniDebugInfo files are symbol files only, they are not intended for
On Wed, 05 Jun 2013 16:25:27 +0200, John Reiser wrote:
On 06/05/2013 05:42 AM, Jan Kratochvil wrote:
Segments are irrelevant for symbols.
There is a problem with objdump and MiniDebugInfo and gdb treating ElfXX_Phdr
records as don't care. The problem is that other parts of the debugging
On Thu, 30 May 2013 11:25:36 +0200, Björn Persson wrote:
Looking through the manuals of GDB, GCC and Make, I get a seemingly
random mixture with some paragraphs in a Courier-like font with a fixed
line length, and some paragraphs in a variable-width sans-serif font
and adapting to the width of
On Sat, 30 Mar 2013 21:05:08 +0100, Thomas Meyer wrote:
I already have the debuginfo packages installed:
This was explained by Rex Dieter, it is due to -g1 used from webkitgdb.spec:
# Build with -g1 on all platforms to avoid running into 4 GB ar format limit
#
On Sat, 30 Mar 2013 13:03:22 +0100, Thomas Meyer wrote:
I encounter this crash in eclipse:
https://bugzilla.redhat.com/show_bug.cgi?id=928783
In the backtrace is:
#6 0x7fffbe51c92e in WebKit::core () from /lib64/libwebkitgtk-1.0.so.0
No locals.
#7 0x7fffbe4ef8f8 in
On Tue, 12 Mar 2013 02:03:16 +0100, Jared K. Smith wrote:
On Mon, Mar 11, 2013 at 7:02 PM, Richard W.M. Jones rjo...@redhat.com wrote:
Has Fedora *ever* had a functional soft-phone? I ask this because I
have tried many, and none of them *ever* worked
[...]
I've successfully used Twinkle for
On Fri, 08 Mar 2013 11:30:35 +0100, Michael Scherer wrote:
I am pretty sure that linux-atm is likely unused by residential users in
2013. ( ie, it kinda need some specific hardware to be used, my internet
access use it but that's the modem job to do it, I just interface it
with plain ethernet
On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote:
On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote:
[...]
==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
==11843==at 0x4A06409: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote:
==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
==11843==at 0x4A06409: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11843==by 0x38EAC861F9: strdup (strdup.c:42)
==11843==
On Thu, 07 Mar 2013 14:20:40 +0100, Mark Wielaard wrote:
It is kind of funny that gcc generates better/fuller
debuginfo with higher optimizations these days.
There is even -Og for debugging as the best of -O0 and -O2 but I do not have
much practical experience with it yet.
Jan
--
devel
On Thu, 14 Feb 2013 13:03:41 +0100, Daniel J Walsh wrote:
Any know of a way to build a customized search into firefox. Basically I want
to setup a search pull down which is hard coded to a particular site.
[...]
I use many such pre-set searches - make a bookmark with:
Location:
On Mon, 04 Feb 2013 14:16:58 +0100, Martin Sourada wrote:
Big +1. What will an unsuspecting user think when he downloads, burns
and tries Fedora on 32bit machine? That it's broken,
From what I have reports even Fedora 32-bit does not boot on such machines
because nobody tests the bleeding edge
On Mon, 04 Feb 2013 15:23:45 +0100, Ralf Corsepius wrote:
On 02/04/2013 02:42 PM, Jan Kratochvil wrote:
From what I have reports even Fedora 32-bit does not boot on such machines
because nobody tests the bleeding edge Fedora kernels on such obsolete
hardware.
Could you provide more details
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 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 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 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 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 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
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 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
On Mon, 16 Jul 2012 09:30:47 +0200, Tomas Mraz wrote:
Definitely not a bug. If it is a bug of anything then of the prelink
script that it does not check the battery status.
OK, it depends whether you want to make some configuration of cron which
scripts should or should not be run on battery or
On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
And I wouldn't be so presumptions as to state authoritatively what
is or is not a bug, in something whose purpose is not known to me.
Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
process not being able to
On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote:
It took me a while to figure out why my daemon kept breaking all the
time, when it couldn't stat its /proc/self/exe any more.
This is a bug of the daemon. While it is already suspicious it needs to mess
with /proc/self/exe stat works
On Sun, 15 Jul 2012 15:50:39 +0200, Reindl Harald wrote:
only prelink is good with zero benefit?
Yes, without that zero benefit. prelink has provable startup performance
improvement and runtime memory savings.
i did not notice ever any benfit of prelink even by
starting large applications
On Sun, 15 Jul 2012 19:37:26 +0200, Reindl Harald wrote:
you must start openoffice damned often that the benfit beats out
the overhead of the /etc/cron.daily/prelink
When you prelink it nightly on AC and run it at least once on battery, the
saving has been done.
to beat the battery drain of
On Thu, 12 Jul 2012 15:09:05 +0200, Darryl L. Pierce wrote:
I think if those packages are languishing, it's like
the packager was already notified and chose not to push.
Package goes into testing with the goal to get into stable. Therefore by
default it should go into stable when it gets
On Tue, 19 Jun 2012 23:37:43 +0200, Daniel J Walsh wrote:
Yes allowing any user to list/read any content in your home dir would be a bad
default.
Why? It would be different default, it would be the default that always has
been that way on UNIces. It is useful to learn how other users have
On Fri, 15 Jun 2012 05:03:59 +0200, Jens Petersen wrote:
Well I tend to agree: it would be the least surprising behaviour for most
fedora packagers.
Though I understand the point about keeping rpmbuild generic -
I don't see how pulling in redhat-rpm-config would break generic rpms?
Surely
On Wed, 13 Jun 2012 11:12:18 +0200, Xavier Bachelot wrote:
I was able to fix the same multilib issue with the html files by modifying
the footer to not include the timestamp,
Could you suggest how in:
popt-devel.i586 conflicts with popt-devel.x86_64
On Sat, 02 Jun 2012 18:53:14 +0200, Kevin Kofler wrote:
Unfortunately, this also only works once the package is actually pushed to
updates-testing. That's of course because yum still pulls it from updates-
testing (yum cannot pull directly from Koji as the required metadata is not
there),
On Sat, 26 May 2012 12:50:31 +0200, Richard W.M. Jones wrote:
- You're in IRC or email, and all the bug reporter has given you is a
random copy and paste from their terminal. They don't care to open
a bug; they don't much care about anything except getting a fix.
Minidebuginfo would
On Thu, 24 May 2012 09:28:16 +0200, Alexander Larsson wrote:
However, the whole thing is useless unless we agree that we want to
enable this by default. It seems some people like the idea, whereas
others disagree that its worth the increased binary size. It doesn't
look like either side is
On Thu, 24 May 2012 11:07:06 +0200, Alexander Larsson wrote:
2) The results of the MiniDebugInfo is not perfect, and
there is a theoretically perfect approach. So we should not
spend time/energy/space/bits/whatever on the non-perfect
appraoch.
However, the perfect approach has
On Thu, 24 May 2012 15:34:28 +0200, Alexander Larsson wrote:
I don't think there has to be a specific problem. In fact, I think
Fedora shouldn't really care what *my* problem is. What is interesting
is: I have this feature; It has a certain cost (increase in size) and it
gives certain
On Thu, 24 May 2012 16:35:57 +0200, Frank Ch. Eigler wrote:
jan.kratochvil wrote:
If your feature does not solve any problem it is just a bloat.
This overstates the case. Alex's proposal clearly solves some problems.
This is just about wording.
My reaction was to:
I don't think
On Thu, 24 May 2012 19:20:15 +0200, Casey Dahlin wrote:
Just go do it. See who actually shows up to stop you.
I am sure this is significant enough distro change to require FESCo decision.
Regards,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
On Thu, 24 May 2012 21:53:48 +0200, Miloslav Trmač wrote:
So, where to go from here? For the gdb change, I think the ideal case
would be to push the gdb support upstream (I have no idea what
upstream thinks, though), second best is to convince Jan and Sergio.
I have no problems accepting the
On Tue, 22 May 2012 06:23:56 +0200, Jesse Keating wrote:
So that the NVR- hash mapping needs to be done by 'fedpkg verrel' which
(a) requires network connectivity contradicting GIT local repo, (b) is slow.
Hrm, in what way does it require network connectivity? gitbuildhash
does require
On Mon, 21 May 2012 18:47:05 +0200, Stanislav Ochotnicky wrote:
i.e. there was no empty line so git chucked them all into subject when
generating mails. Now they do:
line one
- line two
- line three
There is primarily missing the first line:
* Mon May 14 2012 Jan Kratochvil jan.kratoch
On Tue, 08 May 2012 15:03:28 +0200, Alexander Larsson wrote:
Take this post for instance:
https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ
+
On Tue, 08 May 2012 15:10:28 +0200, Gerd Hoffmann wrote:
Wrong. From /me you don't get abrt reports at all, because abrt simply
is a
On Wed, 09 May 2012 09:27:57 +0200, Alexander Larsson wrote:
So, having at least some level of quality local backtraces will still be
good even if ABRT becomes better.
Some new option is always good.
Questionable is what should be the default. IMO ABRT Retrace Server should be
the default one
On Wed, 09 May 2012 10:35:16 +0200, Gerd Hoffmann wrote:
Server-based trace generation requires uploading a potentially large
core file (which probably can be reduced using mozilla-like minidumps).
mozilla-like minidumps would bring us unusable backtraces due to other
reasons such as GDB Pretty
On Wed, 09 May 2012 13:32:08 +0200, Jiri Moskovcak wrote:
As for the bandwidth limitations when using ABRT - I hope Lennart's
core stripping library might help here.
But this degrades backtrace quality again as I have shown in:
On Wed, 09 May 2012 13:33:29 +0200, Alexander Larsson wrote:
That would means 43Mb larger
I guess you mean 43MB and not 5MB.
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 08 May 2012 08:34:57 +0200, Alexander Larsson wrote:
Its true that that is all the information you need from the
process/core. But you need to have the rest of the information availible
*somewhere*, such as on a global retrace server or just having it
locally in the minidebuginfo. The
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
On Mon, 07 May 2012 17:15:17 +0200, Alexander Larsson wrote:
* They don't work offline, or before/after the network is up
+
* Its problematic to use a retrace server during early boot, or e.g. in
non-session apps like a daemon
/var/spool/abrt/ stores them for later GUI upload, it already
On Mon, 07 May 2012 17:29:12 +0200, Jakub Jelinek wrote:
On Mon, May 07, 2012 at 05:25:29PM +0200, Jan Kratochvil wrote:
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
On Mon, 07 May 2012 17:40:18 +0200, Lennart Poettering wrote:
on the individual machine,
There is no backing reason for this requirement. It does not matter where.
without having to keep coredumps,
Core dump currently always have to be shortly stored on the disk anyway, even
for using
On Mon, 07 May 2012 18:10:17 +0200, Colin Walters wrote:
My experience is otherwise; just look at how the kernel works in
practice. People often post stack traces to the list, and it's
certainly not uncommon for problems to be fixed just based on this data.
Linux kernel is not generalizable
On Mon, 07 May 2012 22:24:15 +0200, Bill Nottingham wrote:
4) I disagree with the contention that this should all be done via the
retrace server. For the retrace server to work, you have to have
all of the following:
- all relevant binaries and DSOs built in Fedora
When we are considering
On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote:
Everybody who builds OSes or appliances, and who needs to supervise a
large number of systems, and hosts, wants stacktraces that just work,
and don't require network access or any complex infrastructure.
Yes, they work for me.
On Mon, 07 May 2012 23:36:04 +0200, Lennart Poettering wrote:
I mean, just think of this: you have a pool of workstations to
administer. It's all the same machines, with the same prepared OS
image.
Then I probably use readonly /usr/lib/debug over NFS.
Now, with your logic this would either
On Wed, 11 Apr 2012 22:46:17 +0200, Ryan Lewis wrote:
Having stack frame pointers enabled within libraries is extremely
valuable for profiling.
Frame pointers are useless, every Fedora binary has .eh_frame full unwind info
thanks to -fasynchronous-unwind-tables and oprofile can properly unwind
On Tue, 10 Apr 2012 04:41:46 +0200, Kevin Kofler wrote:
Mozilla plugins is usually a euphemism for proprietary crap, most often
Flash. We cannot package that in Fedora.
So if there is the easy installability of proprietary crap like Mozilla
plugins why aren't also the repositories like
On Tue, 10 Apr 2012 11:40:14 +0200, drago01 wrote:
rpm packages do not magically fix security issues. A vulnerability in
a plugin can be exploited by an attacker regardless how the plugin got
installed. (rpm or not).
This is still unrelated to the point whether Fedora is a Free distro or not
On Tue, 10 Apr 2012 11:32:38 +0200, Matej Cepl wrote:
Yes, it would be nice ... except there are so many addons to package
Fedora also does not have about 2 packages that Debian has. Does it mean
we should give up on Fedora and switch to Debian because we would have to make
2 packages
On Tue, 10 Apr 2012 11:37:58 +0200, drago01 wrote:
We don't even have a package installation gui that does not suck i.e
is usable for most users.
Going to a website and click install this addon is way easier from a
users pov.
Keeping pre-installed MS-Windows on the computer is also way
On Tue, 10 Apr 2012 15:07:45 +0200, Kevin Kofler wrote:
Jan Kratochvil wrote:
This is still unrelated to the point whether Fedora is a Free distro or
not (it is not due to Linux firmwares - this part is known). So why isn't
Flash + acroread etc. also installed by default or be available
On Mon, 09 Apr 2012 17:56:06 +0200, Paul Wouters wrote:
Only if you man the helpdesk for answering why users cannot install
adblock in firefox.
Do you mean mozilla-adblockplus-1.3.10-4.fc16.noarch? And if it is so wanted
feature let it be installed in default Fedora installation and nobody will
On Sun, 08 Apr 2012 22:50:21 +0200, Tom Lane wrote:
A possible compromise that might allow software developers to live
with the setting would be if the default excluded gdb
Counterargument in some that Bug was then the attacker can spawn GDB instead
of using PTRACE_ATTACH in that process
On Tue, 13 Mar 2012 15:17:01 +0100, James Antill wrote:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/ch-httpd.html#S2-HTTPD-V2-DIFF-RPM
...but upstream explicitly requested that we change it.
Where is that request? I see more upstream is pushing the httpd
On Mon, 19 Mar 2012 00:52:40 +0100, Reindl Harald wrote:
* this is a VIRTUAL MACHINE
* the installation falls back to text install
This is tracked as:
https://bugzilla.redhat.com/show_bug.cgi?id=782995
http://lists.fedoraproject.org/pipermail/devel/2012-March/163675.html
Use
On Fri, 16 Mar 2012 20:46:16 +0100, Martin Langhoff wrote:
Argh, that could be. But our kernel is a custom built rpm,
You have a bug for Fedora there, in the core file by readelf -l:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
[...]
LOAD
On Fri, 16 Mar 2012 11:16:51 +0100, Jim Meyering wrote:
That works very well. However, the base64 output in my first log was
corrupt, due to some asynchronous output (stderr about job completion)
that was emitted in the middle of the big base64 block.
Adding the sync; sleep 10 part below
On Fri, 16 Mar 2012 12:01:59 +0100, Jim Meyering wrote:
However, I would suggest that any make check-spawned process that
does not terminate is a test script bug that should be fixed upstream,
I agree. New testcases are reviewed with this rule in mind. But the existing
testcases are handled
On Thu, 15 Mar 2012 21:18:16 +0100, Martin Langhoff wrote:
we are facing a very strange Python segfault in an OLPC build, based
on F14, for XO-1.5 (I know, do you remember _that_ far ago?).
[...]
Full error msg from gdb at http://fpaste.org/YqGv/
All those GDB messages mean your system
On Thu, 15 Mar 2012 22:31:58 +0100, Martin Langhoff wrote:
Well, that should just not be. The machine that fails, and my machine
have both been installed from the same disk image, which gets written
to disk with a process equivalent to dd.
And both machines pass rpm -Va just fine. So the
On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
I suspect the answer is 'no', but is is possible to access or download
the build directory of a failed build, on the Fedora Koji servers?
GDB (and GCC) tar and uuencode their testsuite results into build.log:
* Mon Jun 21 2004
201 - 300 of 360 matches
Mail list logo
