Simo Sorce s...@redhat.com writes:
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If yum
freaks out for *whatever* reason I want to be there with an
emergency shell open [...] I've been saved more than once by a
Hi Davide -
dblistsub-fedora wrote:
[...] I am considering using one of the above to see if they can
usefully substitute the practice of peppering code with tracing
statements (logging or performance analysis are not the focus). As I
would be a beginner in any of them, I was curious about
Debarshi Ray rishi...@lostca.se writes:
[...] You don't think that it is a problem that our downstreams
might inadvertently end up violating the GPL by shipping GPLv3 code
that links to non-free software? [...]
It is not *our* problem.
- FChE
--
devel mailing list
dwalsh writes:
[only the $subject]
# stap -e 'probe syscall.open {
if(substr(filename,0,5) == /proc) {
println(pid(), , execname(), , filename)
print_ubacktrace()
} }' -d /usr/lib*/libc-*.so
(Repeat with more -d /usr/bin/foo as stap advises.)
- FChE
--
devel mailing list
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.
- FChE
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Tomasz Torcz to...@pipebreaker.pl writes:
[...] Can we get some definite numbers?
Yeah, not enough of those going around. A quick test with systemtap,
a typical pointer/datastructure-heavy program, on same x86-64 machine,
compiled with -m64 and -m32, same workload. It parses
mjg59 wrote:
[...] If you have any applications that need to be 64-bit (ie,
anything that is going to need more than 4GB of address space, which
is very different from needing more than 4GB of RAM) then you need
to have two copies of your libraries and suddenly your memory
benefits have
drago01 drag...@gmail.com writes:
[...] Can x32 run i686 software (multilib) ? Because not being
able to run existing software might be a reason for many to want
such a host.
x32 is not a different cpu architecture. It's a software ABI to run
on x86-64, especially suited for smaller-memory
kevin.kofler wrote:
[...] There is no room left on the KDE live image for installing
any sort of debugging information by default. [...]
What are the live-image spins' plans as to management of future
growth? At what point, if ever, do they intend to abandon the CD-ROM
format limits?
-
notting wrote:
[...]
2) It will also make it easier to do things like system wide profiling,
userspace dynamic probes and causual debugging.
However, the Scope: is only gdb and rpm. Wouldn't said tools also need
changes? Would this be done in libdwarf, or similar?
[...]
Profiling
Horst H. von Brand vonbr...@inf.utfsm.cl writes:
[...]
Please go with (3), keeping generated files in git is just dumb.
Please don't demean those who do it for well-considered reasons.
- FChE
--
devel mailing list
devel@lists.fedoraproject.org
[...]
If your package meets the following criteria you MUST enable the PIE compiler
flags:
[...]
* Your package runs as root.
[...]
If this is meant to cover administrative binaries that have no
privilege escalation pieces of their own, merely run by root, then
what makes them different
ajax wrote:
[...]
If this is meant to cover administrative binaries that have no
privilege escalation pieces of their own, merely run by root, then
what makes them different from any other /bin/* program that a root
process might invoke?
It's not meant to cover that. That phrasing is
dwalsh wrote:
[...] deny_ptrace will be DISABLED for F17. Already checked in. [...]
Note that the selinux-policy rpm update that corrects this has not yet
been pushed to any yum update/-testing channels. It would be a shame
if the f17 beta spin went out with this bug.
John Reiser jrei...@bitwagon.com writes:
[...]
According to this bugzilla Comment
https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27
Fedora 17 Alpha turned on denyPtrace (as default) by mistake.
That's not how I read #c27. The flag was turned off during alpha by
mistake and that it
Reindl Harald h.rei...@thelounge.net writes:
libmicrohttpd seems to be broken due gnutls changes and
was not rebuilt for decades as also the autotests are
disabled in the src.rpm [...]
i see also in the (few) fedora-openvas packages
disable gnutls pacth, enable gnutls patch multiple times
Roman Rakus rra...@redhat.com writes:
How are fedora with grub2 users supposed to set up crashkernel kernel
argument? [...]
Does GRUB_CMDLINE_LINUX=crashkernel=auto in /etc/default/grub work,
followed by grub2-mkconfig?
- FChE
--
devel mailing list
devel@lists.fedoraproject.org
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes:
[...]
What is wrong with
#!/usr/bin/env interpreter
from technical POV?
It's more wordy.
It makes it impossible to pass an interpreter argument.
It will execute slower.
- FChE
--
devel mailing list
devel@lists.fedoraproject.org
Adam Williamson awill...@redhat.com writes:
[...]
But that's still going to require some kind of sensible handling of the
case where one monitor is roughly 100dpi and the other is roughly
200dpi, unless we simply say 'you can't do that, all your displays have
to be in the same DPI Category'.
Adam Williamson awill...@redhat.com writes:
[...]
There's a big difference between having the upstream, who knows their
configure script inside and out,
That's a very bold assertion. ;-) Many upstream developers just copypaste
their configure.ac scripts together [...]
Yeah, autotools
Tom Lane t...@redhat.com writes:
Hmm ... so what should I do with mysql? Since approximately forever,
upstream has recommended using -fno-exceptions (and also
-felide-constructors -fno-rtti) in CXXFLAGS. [...]
-fexceptions / -frtti are essentially harmless, so I am curious why
they were
tgl wrote:
[...] I think the only near-term fix is to turn off dtrace support
in mysql. [...]
We'll do one better; we'll add a hack to sys/sdt.h to make mysql build
and respin systemtap today or tomorrow.
But the real issue here is that systemtap has got to be more chary of
what they
Hi -
FYI, rawhide received a new build of systemtap-1.4 yesterday. (f13
and f14 may get it too, subject to update policy interest). Beyond
its direct users, it affects those packages that build with the
sys/sdt.h markers. A subsequent rebuild of these will switch to the
new sys/sdt.h
Pierre-Yves pin...@pingoured.fr writes:
[...]
I have been looking into the review #668863 in which the packager for
this library (who also happens to be upstream) is actually removing the
flag -fexceptions from $RPM_OPT_FLAGS in the %build.
[...]
- Upstream does not want to have this flag
Ric Wheeler rwhee...@redhat.com writes:
[...] Various drives perform better or worse with file system, fine
grained discard support so not all will see a performance hit.
Could the system run benchmarks to determine whether its own drives
fall into this category?
- FChE
--
devel mailing
Daniel J Walsh dwa...@redhat.com writes:
[...]
So if you create a directory in the postinstall of an rpm, the directory
will be created as var_run_t (rule 1), rpm has SELinux intelligence
built in, but since you did this in postinstall, rpm command does not
know you did it. You will have
Miloslav =?UTF-8?Q?Trma=C4=8D?= m...@volny.cz writes:
[...] If the system integrates everything into one process, the
only remaining troubleshooting mechanisms are integrated logging
[...], debugger [...] and systemtap (only a little better than a
debugger, and not available for most
Kevin Kofler kevin.kof...@chello.at writes:
[...]
Actually, I think WONTFIX is a bad choice of resolution here, UPSTREAM or,
in the specific case of the reporter refusing to file an upstream bug,
INSUFFICIENT_DATA is IMHO a better choice.
... or FEDORA_MAINTAINER_PATCH_ROBOT_TOO_BUSY.
-
Roland McGrath rol...@redhat.com writes:
It's normal to get a single foo-debuginfo package from a foo.src.rpm.
Please explain exactly why this is a problem for you.
One possible reason is RPM-level conflicts between concurrently
installed multilib debuginfo RPMs, such as glibc.i686 and
Matthew Garrett mj...@srcf.ucam.org writes:
[...]
[...] But still, the sensible path is to make
reasonable accommodations for this sort of thing. Let's face it, if
we're waiting on Sony or HP to fix this, we'll be waiting a while.
Or, alternatively, we can actually look into the problem
Jeff Spaleta jspal...@gmail.com writes:
[...]
Stating something like this clearly on login install would be nice,
not just for this MALLOC_PERTURB_ change but in general.
Doesn't this whole discussion about debugging versus performance also
apply to F13 pre-release testing as well.. and
Michal Nowak mno...@redhat.com writes:
Past months I spent investigating `gold' - the new GNU linker
and how it now works with stock Fedora packages.
[...]
Do your scripts provide some evidence of exciting speedups with gold?
- FChE
--
devel mailing list
devel@lists.fedoraproject.org
Panu Matilainen pmati...@laiskiainen.org writes:
[...]
Oh yes. Even just a big red REGRESSION button that stops the update from
automatically entering stable no matter what the karma votes happen to be
would be a definite improvement. [...]
Just for completeness, please let's be cautious
James Antill ja...@fedoraproject.org writes:
[...]
...but they have almost no options if they are happy to stay with
the software that they have.
Doesn't just not running random/unrestricted yum update exactly
encode that option?
No, for two reasons:
1. The user is often informed,
Bruno Wolff III br...@wolff.to writes:
A couple of problems. Which packages are downloaded from mirrors is not
currently available to Fedora. [...]
Would it be crazy to reorganize the mirror system in such a way that
normally download http requests come to fedoraproject.org, but are
redirected
Peter Jones pjo...@redhat.com writes:
[...] You weren't elected FESCo Monitor; the guy who comes and
tells the mailing list whenever FESCo is discussing something you
think is scary. [...]
One need not be elected to do that. Anyone reading the public
fesco irc logs may do the same without
James Antill ja...@fedoraproject.org writes:
[...]
Probably the saddest thing about this giant flamewar you've started is
[...]
For what it's worth, I have seen no lack of courtesy from Kevin Kofler
in this thread, so the accusation of flamewarism would be more
appropriately directed to
Jiri Moskovcak jmosk...@redhat.com writes:
Such log would be nice, but it might take some time (even days) before
the app crashes again and I can imagine that could generate quite a
large log :-/ Maybe if it would store just last few syscalls...
Sure, some circular logging, the last few
101 - 138 of 138 matches
Mail list logo
