The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which
lets them be used as a Display for another computer. Apple calls it Target
Display Mode, though HP doesn't seem to have a special name for it. This is
really quite useful, I've used an iMac hooked up to a Linux machine
On 15. 10. 2013 at 04:33:08, P J P wrote:
On Monday, 14 October 2013 8:05 PM, Eric H. Christensen
spa...@fedoraproject.org wrote: I believe he is assuming that xchat has
a direct relationship with bluez which, I'm guessing here as I haven't
checked, probably isn't the case. Because bluez
The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which
lets them be used as a Display for another computer. Apple calls it Target
Display Mode, though HP doesn't seem to have a special name for it. This is
really quite useful, I've used an iMac hooked up to a Linux
Hi Jan
thnx. for the progress.
see my question: https://bugzilla.redhat.com/show_bug.cgi?id=1018905#c5
Peter.
On 10/14/2013 06:47 PM, Jan Lieskovsky wrote:
Hello guys,
have submitted review request for scap-security-guide rpm for Fedora:
[1]
Morning,
dnf-0.4.4 is built and out for testing in F20[1] and rawhide. There's
initial Py3 support and a bugfix, see the full story on the DNF blog [2]
and in the release notes [3].
Meanwhile in Anaconda, the DNF Payload is ready for early testing [4].
We'll be glad to hear some feedback.
Thanks Peter. Noticed replied. Will reply / deal with
Zbigniew's comments (c#4) yet too.
Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
- Original Message -
From: Peter Vrabec pvra...@redhat.com
To: Jan Lieskovsky jlies...@redhat.com
Cc:
On Mon, 2013-10-14 at 13:51 +0100, David Woodhouse wrote:
On Mon, 2013-07-15 at 22:26 +0100, David Woodhouse wrote:
On Wed, 2013-05-22 at 05:18 -0400, Martin Sivak wrote:
One thing that doesn't seem to have been covered in the discussion —
what about third-party firstboot modules?
On 13. 10. 2013 at 03:05:20, Alek Paunov wrote:
On 04.10.2013 15:34, Jan Zelený wrote:
If you have any other questions, comments or notes regarding the document,
feel free to to use this list for the discussion.
Where (list threads, wikis, sources) one should seek more details about
the
On 13. 10. 2013 at 22:19:16, Michael Stahnke wrote:
On Fri, Oct 4, 2013 at 5:34 AM, Jan Zelený jzel...@redhat.com wrote:
Hello everyone,
as you might remember I issued a call for RFEs on this list during the
spring. The participation was not bad at all, we have collected so many
data that
On Tuesday, 15 October 2013 12:51 PM, Jan Zelený jzel...@redhat.com wrote:
Even though yum might handle the resolution a little better (and dnf probably
will do that, feel free to check it), the ultimate culprit here is a very
poor
packaging and both dnf and yum have only a limited set of
commit a8d428edc619448e9e5ada497b5fbb755eed5cd0
Author: Petr Písař ppi...@redhat.com
Date: Tue Oct 15 13:58:15 2013 +0200
This package does not work with Perl 5.18 (bug #992690).
.gitignore |5 --
dead.package |1 +
Hi,
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations regarding prelink.
- Here are some measurements (for LibreOffice [2] loading time in
seconds) done using the unSPEC benchmarking suite. These numbers
are repeatable and you are encouraged to try
On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
Hi,
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations regarding prelink.
- Here are some measurements (for LibreOffice [2] loading time in
seconds) done using the unSPEC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This seems to have gone a way from Fedora 20/21 thunderbird.
rpm -q thunderbird
thunderbird-24.0-3.fc21.x86_64
Is this intended? Is this a bug? Is there a setting where I can turn this
back on?
Wasting this screen real estate on a small screen
All,
The (admittedly hacky) dracut-modules-growroot package installs a
dracut script that runs in the pre-pivot stage. It unmounts the root
partition, extends it to the maximum possible size and then tries to
remount it. What I noticed in F20 is that as soon as the
repartitioning finishes (its an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/15/2013 08:41 AM, Daniel J Walsh wrote:
This seems to have gone a way from Fedora 20/21 thunderbird.
rpm -q thunderbird thunderbird-24.0-3.fc21.x86_64
Is this intended? Is this a bug? Is there a setting where I can
turn this back on?
On 15/10/13 13:41, Daniel J Walsh wrote:
This seems to have gone a way from Fedora 20/21 thunderbird.
rpm -q thunderbird
thunderbird-24.0-3.fc21.x86_64
Is this intended? Is this a bug? Is there a setting where I can turn this
back on?
That went away ages ago IIRC. You can get it back
On 10/15/13 at 05:30am, Josh Boyer wrote:
On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations regarding prelink.
...
- For building kernels (using the kernel-bench [3]
In Debian distributions exist file:
/etc/dpkg/origins/default
which is symlink to
/etc/dpkg/origins/debian
with content:
Vendor: Debian
Vendor-URL: http://www.debian.org/
Bugs: debbugs://bugs.debian.org
Do we have some alternative to this in Fedora world?
The goal of this file is to
On Tue, Oct 15, 2013 at 01:15:26PM +0200, Jan Zelený wrote:
Not to be only negative here, take a look at the COPR initiative, I expect
it will solve the problem you are talking about by offering external
repositories that will be easily reachable from Fedora but won't be a part
of the Fedora
On 10/15/2013 03:19 PM, Miroslav Suchý wrote:
In Debian distributions exist file:
/etc/dpkg/origins/default
which is symlink to
/etc/dpkg/origins/debian
with content:
Vendor: Debian
Vendor-URL: http://www.debian.org/
Bugs: debbugs://bugs.debian.org
Do we have some alternative to this
On Tue, Oct 15, 2013 at 03:19:06PM +0200, Miroslav Suchý wrote:
In Debian distributions exist file:
/etc/dpkg/origins/default
which is symlink to
/etc/dpkg/origins/debian
with content:
Vendor: Debian
Vendor-URL: http://www.debian.org/
Bugs: debbugs://bugs.debian.org
Do we have
On Tue, Oct 15, 2013 at 5:55 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
On 10/15/13 at 05:30am, Josh Boyer wrote:
On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
During the development of unSPEC [1] benchmarking suite, I made some
interesting observations
Does anyone actually use the PackageKit service pack or catalog
functionality? If there are no users I'm intending to rip out the
unused and unloved features from GNOME 3.12. Please say now, or
forever hold your peace. Thanks.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
On 10/15/2013 02:47 PM, Juerg Haefliger wrote:
All,
The (admittedly hacky) dracut-modules-growroot package installs a
dracut script that runs in the pre-pivot stage. It unmounts the root
partition, extends it to the maximum possible size and then tries to
remount it. What I noticed in F20
On Tue, 15 Oct 2013, Dhiru Kholia wrote:
In short, we could not distinguish the performance gains of prelink over
the background noise in many (or even most) cases.
So, I was wondering if you are aware of any use-cases where prelink
provides measurable benefits. In would be awesome if you
On 10/15/2013 03:41 PM, Ralf Corsepius wrote:
I think, you are mixing up things.
/etc/dpkg is a package's (dpkg's) config-directory, which may contain whatever
this package considers to be its
configuration.
It's not related to distinguishing OS vendors, at all.
Since that bug 487437 it is
https://bugzilla.redhat.com/show_bug.cgi?id=914310
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
On Tue, Oct 15, 2013 at 10:14:13AM -0400, Paul Wouters wrote:
On Tue, 15 Oct 2013, Dhiru Kholia wrote:
In short, we could not distinguish the performance gains of prelink over
the background noise in many (or even most) cases.
So, I was wondering if you are aware of any use-cases where
https://bugzilla.redhat.com/show_bug.cgi?id=914310
--- Comment #6 from Petr Pisar ppi...@redhat.com ---
Created attachment 812545
-- https://bugzilla.redhat.com/attachment.cgi?id=812545action=edit
Fix ported from upstream
--
You are receiving this mail because:
You are on the CC list for
commit 7a191d76edf3fe2678737b738371b74ac6f8a759
Author: Petr Písař ppi...@redhat.com
Date: Tue Oct 15 16:20:21 2013 +0200
Fix compatibility with ORLite-1.98
...o-the-delete_where-method-for-bulk-deleti.patch | 333
perl-Padre.spec|
On 10/15/2013 02:47 PM, Juerg Haefliger wrote:
All,
The (admittedly hacky) dracut-modules-growroot package installs a
dracut script that runs in the pre-pivot stage. It unmounts the root
partition, extends it to the maximum possible size and then tries to
remount it. What I noticed in F20
Summary of changes:
7a191d7... Fix compatibility with ORLite-1.98 (*)
(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
commit 310fcb80a0e23b133bf21ce6771585b3c939d7c3
Author: Petr Písař ppi...@redhat.com
Date: Tue Oct 15 16:20:21 2013 +0200
Fix compatibility with ORLite-1.98
...o-the-delete_where-method-for-bulk-deleti.patch | 333
perl-Padre.spec|
On Tue, Oct 15, 2013 at 09:48:43AM -0400, Matthew Miller wrote:
We have a number of _related_ things -- /etc/system-release, and the RPM
vendor tag. From the given use case, in fact, I think that the vendor tag
is pretty close. I'm not quite sure what they want to _do_ with it though,
even
https://bugzilla.redhat.com/show_bug.cgi?id=914295
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
External Bug ID|CPAN 914295 |CPAN 86020
--
You are
https://bugzilla.redhat.com/show_bug.cgi?id=914310
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=914310
--- Comment #7 from Fedora Update System upda...@fedoraproject.org ---
perl-Padre-0.90-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-Padre-0.90-10.fc20
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=914310
--- Comment #8 from Fedora Update System upda...@fedoraproject.org ---
perl-Padre-0.90-9.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-Padre-0.90-9.fc19
--
You are receiving this mail
On 10/15/2013 04:23 PM, Juerg Haefliger wrote:
On 10/15/2013 02:47 PM, Juerg Haefliger wrote:
All,
The (admittedly hacky) dracut-modules-growroot package installs a
dracut script that runs in the pre-pivot stage. It unmounts the root
partition, extends it to the maximum possible size and
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, Oct 15, 2013 at 04:54:16PM +0200, Jan Kratochvil 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
Hi,
I apologize for escalating this to devel, but I think that after 6
months it is time this [1] finally got fixed: it is just a matter of
changing the icon name in the desktop file of qt-creator to reflect the
new icon name. This is one of those trivial to fix but very user-visible
issues.
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 10/15/2013 04:38 PM, Michael Schroeder wrote:
On Tue, Oct 15, 2013 at 09:48:43AM -0400, Matthew Miller wrote:
We have a number of _related_ things -- /etc/system-release, and the RPM
vendor tag. From the given use case, in fact, I think that the vendor tag
is pretty close. I'm not quite sure
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, Oct 15, 2013 at 05:11:52PM +0200, Jan Kratochvil wrote:
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
On Ter, 2013-10-15 at 15:19 +0200, Miroslav Suchý wrote:
In Debian distributions exist file:
/etc/dpkg/origins/default
which is symlink to
/etc/dpkg/origins/debian
with content:
Vendor: Debian
Vendor-URL: http://www.debian.org/
Bugs: debbugs://bugs.debian.org
Do we have
I've been kicking this idea around for a bit and have chatted a little
with people on IRC but as we're looking to start up development on
taskbot, I want to have a larger discussion on two issues: where do we
host code and what do we want to use for dev support tools (issue
tracking, code
Hi,
Needing a calendar server for the company, I've ended up packaging the
groupware server SOGo [1], which is a neat MS Exchange alternative. SRPM
of sogo plus deps are here:
http://smani.fedorapeople.org/review/sogo-2.0.7-1.fc21.src.rpm
On Oct 15, 2013, at 2:15 AM, David Airlie airl...@redhat.com wrote:
The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which
lets them be used as a Display for another computer. Apple calls it Target
Display Mode, though HP doesn't seem to have a special name for it.
https://fedorahosted.org/389/ticket/47519
https://fedorahosted.org/389/attachment/ticket/47519/0001-Ticket-47519-memory-leaks-in-access-control.patch
--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com
--
389-devel mailing list
389-de...@lists.fedoraproject.org
On Tue, Oct 15, 2013 at 04:54:16PM +0200, Jan Kratochvil wrote:
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
since OpenSSL in Fedora from now on supports ECDHE
depending software needs to be rebuilt to make use
of it as well as libraries like NSS/GNUTLS should
do the same and depending packages like Firefox
needs a rebuild against refreshed NSS to support
it also on the client side
i made some triage
the prelink default should be banned from the distribution
because this is always the excuse not activate hardening-flags
for packages because PIE binaries are not prelinked and people
still insist it brings great performance gains which is mostly
not true
Am 15.10.2013 14:19, schrieb Dhiru
On Tue, 15 Oct 2013, Reindl Harald wrote:
since OpenSSL in Fedora from now on supports ECDHE
depending software needs to be rebuilt to make use
of it as well as libraries like NSS/GNUTLS should
do the same and depending packages like Firefox
needs a rebuild against refreshed NSS to support
it
On 10/15/13 at 05:11pm, Jan Kratochvil wrote:
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
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
Or maybe Intel would be forthcoming. It's their hardware.
Not in this case. Target display mode is a vendor extension, and
switching it will be vendor specific.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
On 10/14/2013 10:55 AM, Matthew Garrett wrote:
On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote:
Next steps:
- Verify libssp works correctly on 32-bit ARM.
- Look at enhancing the existing support in glibc.
- Add TLS stack guard.
- Add TLS pointer guard.
- Add pointer
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
On 10/14/2013 10:55 AM, Matthew Garrett wrote:
Did the arm32 portions of this end up being completed for F20?
For 32-bit ARM on f20:
- Stack guard:
- Existing glibc support provides stack guard value in global
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
Hi,
sounds amazing.
I could take it up but I can not promise to do so soon.
I have some things on my hands that will need about a month to finish up.
thanks,
On Tue, Oct 15, 2013 at 4:35 PM, Sandro Mani manisan...@gmail.com wrote:
Hi,
Needing a calendar server for the company, I've ended
Am 15.10.2013 19:32, schrieb Jan Kratochvil:
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
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, 2013-10-15 at 19:32 +0200, Jan Kratochvil wrote:
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
On Sun, Oct 6, 2013 at 11:32 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
This is the general problem that IP forwarding is no local setting, and
that the global setting has no inherent concept of ownership or
refcounting.
The proper place for this seems to be firewalld, which should not
On Oct 15, 2013, at 10:36 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
Or maybe Intel would be forthcoming. It's their hardware.
Not in this case. Target display mode is a vendor extension, and
switching it will be vendor
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
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
On Mon, Oct 7, 2013 at 3:47 PM, Richard W.M. Jones rjo...@redhat.com wrote:
Another way to look at it might be: Since a lot of people have libvirt
installed (it's the default isn't it?) and hence forwarding has been
on for many people for a long time, what harm is it causing?
RFC 1812
2.2.8.1
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, Oct 15, 2013 at 10:56 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
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
On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce s...@redhat.com wrote:
Prelink does big disadvantages, otherwise nobody would care.
One is about security, as it negates randomization of addresses,
Most of the security benefit is, AFAICS, not negated by prelink (see
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, 2013-10-15 at 19:56 +0200, Jan Kratochvil wrote:
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
On 10/15/2013 12:53 PM, Matthew Garrett wrote:
On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote:
On 10/14/2013 10:55 AM, Matthew Garrett wrote:
Did the arm32 portions of this end up being completed for F20?
For 32-bit ARM on f20:
- Stack guard:
- Existing glibc support
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
Pointer mangling is useful, but we can roll that change into an update
and it should not in my opinion block F20.
I've filed:
Bug 1019452 - [ARM] Backport pointer mangling support from upstream.
On Tue, 15 Oct 2013, Jan Kratochvil wrote:
I just do not understand why to give up on that negligible optimization when
it brings no disadvantages.
Because you did not my previous email?
- complexity
- complicated prelink blacklists
- complicated cron job exclusion with sysconfig
- FIPS
The lightweight tag 'perl-DateTime-Set-0.33-1.fc21' was created pointing to:
088a2fe... Update to 0.33
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
There is no effective security difference between accessing the randomized
stack guard value from a global variable or a value stored in the dynamic
thread vector.
It is only a performance optimization. The choice of a global
The lightweight tag 'perl-DateTime-Set-0.33-1.fc20' was created pointing to:
088a2fe... Update to 0.33
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
Am 15.10.2013 20:04, schrieb Miloslav Trmač:
On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce s...@redhat.com wrote:
Prelink does big disadvantages, otherwise nobody would care.
One is about security, as it negates randomization of addresses,
Most of the security benefit is, AFAICS, not negated
Am 15.10.2013 19:49, schrieb Jan Kratochvil:
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
Am 15.10.2013 19:54, schrieb Chris Adams:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
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 |
Am 15.10.2013 20:07, schrieb Jan Kratochvil:
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.
you can always point
Am 15.10.2013 19:56, schrieb Jan Kratochvil:
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
On Tue, Oct 15, 2013 at 11:52:41AM -0600, Chris Murphy wrote:
On Oct 15, 2013, at 10:36 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Tue, Oct 15, 2013 at 09:36:32AM -0600, Chris Murphy wrote:
Or maybe Intel would be forthcoming. It's their hardware.
Not in this case. Target
On 10/15/2013 02:27 PM, Jakub Jelinek wrote:
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote:
There is no effective security difference between accessing the randomized
stack guard value from a global variable or a value stored in the dynamic
thread vector.
It is only a
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
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
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 comparison.
Since you keep repeating this one: -O2 vs. -O0 has a significant
performance gain.
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
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
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
Do you really run gnome-open --help 1000 times per
Am 15.10.2013 20:40, schrieb Jan Kratochvil:
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
Am 15.10.2013 20:52, schrieb Jan Kratochvil:
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
Am 15.10.2013 20:54, schrieb Chris Adams:
Once upon a time, Jan Kratochvil jan.kratoch...@redhat.com said:
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 comparison.
Since you keep repeating this one:
Am 15.10.2013 21:05, schrieb Jan Kratochvil:
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
On 10/14/2013 10:08 AM, Florian Weimer wrote:
Is there a write-up somewhere documenting what strategies are
implemented by bcache to keep the SSD and the hard disk contents in
sync even in the event of a sudden power loss?
This is good place to start: http://bcache.evilpiepirate.org/
--
devel
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 are the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d
1 - 100 of 183 matches
Mail list logo
