Re: Yum dependency resolving & remove_leaf_only

[Jan Zelený]

On 15. 10. 2013 at 04:33:08, P J P wrote:
> > On Monday, 14 October 2013 8:05 PM, Eric H. Christensen
> >  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 affects something that
> > xchat depends on xchat is getting thrown into the pile of things that
> > will break without bluez.  Dependencies aren't always 1:1...
> 
>Yes, I understand that Xchat is not directly dependent on bluez; It is
> being a victim of associative dependency, something like
> 
> bluez <= gnome-bluetooth(libgnome-bluetooth-applet.so.0) <= gnome-shell <=
> libnotify.so.4 <= xchat
> 
> 
> My original question was if this is due to a packaging error  or  if yum's
> dependency resolving algorithm is at fault. Because with
> remove_leaf_only=1, if you try to remove individual packages,
> 
> # yum remove bluez,
> # yum remove gnome-bluetooth
> # yum remove pulseaudio-module-bluetooth
> 
> None of  them work. But if you try to remove all 3 together
> 
> # yum remove gnome-bluetooh bluez pulseaudio-module-bluetooth
> 
> Yum prompts you to remove bluez  ->
> https://lists.fedoraproject.org/pipermail/devel/2013-October/190101.html

Yum's behavior is absolutely correct, it even reports you reasons why it 
doesn't uninstall individual packages (in general none of them is a leaf 
package).

In this particular case the problem is also the circular dependency between 
bluez and gnome-bluetooth [1]. At this point I'm not sure about pulseaudio-
module-bluetooth but I suspect something similar going on there.

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 options what to do 
in such cases. Usually both do the right thing, as yum did in this case.

Thanks
Jan


[1]
$ repoquery --whatrequires gnome-bluetooth | grep bluez | tail -n 1
bluez-0:4.101-9.fc19.x86_64
$ repoquery --whatrequires bluez | grep gnome-bluetooth | tail -n 1
gnome-bluetooth-1:3.8.2.1-1.fc19.x86_64




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[David Airlie]

> 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 at a
> previous job, and it's awesome to switch between the two machines when
> you've only got space for one display on the desk. The feature is invoked by
> a fairly non-standard keyboard combination. Here is a video illustrating
> what I mean (
> http://www.youtube.com/watch?feature=player_detailpage&v=Y7_OZgBX8kQ#t=60 ),
> note how he switches the iMac from being the display for the MacBook to
> being an iMac again via keyboard shortcut (sort of off-screen).
> 
> However, this feature is only implemented in OS X and Windows (via HP's My
> Display application) on the iMac and Z1 respectively. Which means that if,
> for example, a Z1 has Linux as the primary OS, the Z1 cannot currently be
> used as a monitor for a laptop or another computer (via Target Display
> Mode). As far as I've been able to discover, Target Display Mode does not
> exist under any flavor of Linux.
> 
> What would it take to support this in Fedora? Is this a Desktop-centric
> feature for Gnome/KDE/Cinnamon, or is this something that would/should be
> part of the Linux kernel itself? I don't think it's directly part of a
> graphics driver (at least on Windows, since HP released My Display as a
> separate program), but again I'm not sure.

You'd have to reverse engineer or ask HP/Apple what they actually do for this
to work.

then implement that.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review Request: scap-security-guide - Security guidance and baselines in SCAP formats

[Peter Vrabec]

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] https://bugzilla.redhat.com/show_bug.cgi?id=1018905

The goal of the Fedora scap-security-rpm project is:
* provide primary SCAP protocol content for oscap / scap-workbench,
   intended for use for scanning of Fedora systems,

* package existing RHEL6 / JBossEAP5 / RHEL5 SSG content into
   Fedora's rpm too (so RHEL6 / JBossEAP5 / RHEL5 guests could
   be scanned from Fedora host too) - this is to be implemented yet
   in upcoming versions,

* the SCAP content is to be based on:
   - transformation of existing upstream SCAP security guide:
 [2] https://fedorahosted.org/scap-security-guide/

 rules for Red Hat Enterprise Linux 6 to Fedora,
   - creation of new (Fedora specific) rules which would
 align with the development / application of new features
 in Fedora with intention the created rules to be later
 transformed back (once validated) into SSG upstream for
 use in subsequent versions of Red Hat Enterprise Linux


Above link [1] provides referencing / initial SPEC file and source
RPM package with SCAP XML content as it got transformed from existing
RHEL6 content.

Subsequent rules, remediation scripts (and above mentioned RHEL6 / JBossEAP5 /
RHEL5 content) to come in future package versions.

Please review.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

dnf-0.4.4 released

[Ales Kozumplik]

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,
Ales

[1] 
https://admin.fedoraproject.org/updates/FEDORA-2013-19064/dnf-0.4.4-1.fc20

[2] http://dnf.baseurl.org/?p=41
[3] http://akozumpl.github.io/dnf/release_notes.html#id15
[4] http://dnf.baseurl.org/?p=45
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Review Request: scap-security-guide - Security guidance and baselines in SCAP formats

[Jan Lieskovsky]

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" 
> To: "Jan Lieskovsky" 
> Cc: devel@lists.fedoraproject.org, "Josh Bressers" , 
> "Shawn Wells" 
> Sent: Tuesday, October 15, 2013 11:34:21 AM
> Subject: Re: Review Request: scap-security-guide - Security guidance and 
> baselines in SCAP formats
> 
> 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] https://bugzilla.redhat.com/show_bug.cgi?id=1018905
> >
> > The goal of the Fedora scap-security-rpm project is:
> > * provide primary SCAP protocol content for oscap / scap-workbench,
> >intended for use for scanning of Fedora systems,
> >
> > * package existing RHEL6 / JBossEAP5 / RHEL5 SSG content into
> >Fedora's rpm too (so RHEL6 / JBossEAP5 / RHEL5 guests could
> >be scanned from Fedora host too) - this is to be implemented yet
> >in upcoming versions,
> >
> > * the SCAP content is to be based on:
> >- transformation of existing upstream SCAP security guide:
> >  [2] https://fedorahosted.org/scap-security-guide/
> >
> >  rules for Red Hat Enterprise Linux 6 to Fedora,
> >- creation of new (Fedora specific) rules which would
> >  align with the development / application of new features
> >  in Fedora with intention the created rules to be later
> >  transformed back (once validated) into SSG upstream for
> >  use in subsequent versions of Red Hat Enterprise Linux
> >
> >
> > Above link [1] provides referencing / initial SPEC file and source
> > RPM package with SCAP XML content as it got transformed from existing
> > RHEL6 content.
> >
> > Subsequent rules, remediation scripts (and above mentioned RHEL6 /
> > JBossEAP5 /
> > RHEL5 content) to come in future package versions.
> >
> > Please review.
> >
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskovsky / Red Hat Security Technologies Team
> >
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?

[Vratislav Podzimek]

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?
> > > > 
> > > > For an install on a corporate machine we have a firstboot module which
> > > > asks for the Active Directory credentials, joins the Samba domain,
> > > > obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
> > > > those in NetworkManager, adds a local user with the appropriate
> > > > username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
> > > > 
> > > > With firstboot gone, what form should our plugin take?
> > > > 
> > > 
> > > Firstboot stays available in RHEL for this reason (legacy plugins).
> > > Fedora modules will probably have to be updated. At least that was the
> > > plan. It is very easy to write a new module with the new API. Ping
> > > vpodzime, he has a development guide.
> > 
> > Thanks. Delayed response... I've finally got everything else working
> > nicely on Fedora 19 and I'm looking at this. I see firstboot is still
> > available, but it doesn't seem to *work*.
> > 
> > First it wants python-ethtool to be installed but didn't have the
> > appropriate dependency, and then it's still using pygtk while my own
> > code has been updated to pygobject and gtk3. (Which was done because
> > some other code I was *importing* had been upgraded, so I couldn't mix
> > the two. I don't think you get far with pygtk these days, do you?)
> > 
> > So I'm guessing that it's probably not worth looking at firstboot any
> > harder, and I should proceed straight to using initial-setup.
> 
> In the absence of the promised documentation for initial-setup, I ended
> up using firstboot anyway. I backported my code to pygtk2 again, and
> filed a bug for the missing dependencies in the packaging.
> 
> The bug has now been closed on the basis that firstboot is deprecated
> and replaced by initial-setup, but I *still* don't see any sign of the
> long-promised documentation. Or even any example 'skeleton' of a
> standalone module to start from. Is there any prospect of that happening
> any time soon, please?
Sorry, I'd replied in the bugreport [1] before I saw this thread going
on.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=984932

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Software management: Call for RFEs results!

[Jan Zelený]

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 DB aspects of the plan, e.g.:
> 
>   * A1: Delta metadata in yum and dnf (format, replication mechanism)

We have an early proof of concept of this one but the final design is still not 
100% clear so there is no information on this. I'm CCing Zdenek who is working 
on delta metadata, feel free to ask him about the details.

>   * B1-4: New format of rpmdb (db engine, schema, relation with the
> future yum/dnf db)

This is in even more early stages. Currently Jan Silhan (CCed) is working on 
this. If you have any suggestions/requirements, feel free to start the 
discussion. This topic has also been discussed several months ago on rpm-maint 
list [1], however the scope was much more narrow.

[1] http://lists.rpm.org/pipermail/rpm-maint/2013-April/003520.html

Thanks
Jan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Software management: Call for RFEs results!

[Jan Zelený]

On 13. 10. 2013 at 22:19:16, Michael Stahnke wrote:
> On Fri, Oct 4, 2013 at 5:34 AM, Jan Zelený  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 it took us several months to discuss and process it.
> > 
> > Now I have some results for you. Attached to this email you can find a
> > strategy document that a) outlines the strategy that we will commit to in
> > the next 3-5 years and b) contains all the RFEs that were recognized as
> > valid RFEs and were accepted to be implemented as a part of our strategy.
> > 
> > Please note that the rest of the RFEs from the discussion was also
> > evaluated but most likely rejected. If your RFE is not on the list, you
> > can drop me an email and I'll tell you more specific reasons why we
> > decided not to put it on the list.
> > 
> > If you have any other questions, comments or notes regarding the document,
> > feel free to to use this list for the discussion.
> > 
> > Thanks
> > Jan
> > 
> > PS: I'll be AFK for the weekend so I'll comment on your replies on Monday
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> First off, thanks for this. I'm glad some people are really trying to
> look at the path forward.   I'm also sorry I missed your RFE then.
> High traffic-lists sometimes get skipped over :(
> 
> 
> I like the goals of the paper. My main concerns is this addresses
> technical issues that are already in play.  It doesn't address several
> items that are not technical issues which IMHO, is the main reason RPM
> isn't used for everything.
> 
> Developers don't do deployments with RPM...at least not inside Fedora.
> Anything sane is actually against Packaging Guidelines. So that
> becomes a problem, and developers skip it. If  developers (or
> operations people) are savvy enough to make RPMs, they are used once
> and not shared because they wouldn't get accepted into Fedora/EPEL.
> 
> Also, sometimes developers/deployments need multiple versions of
> things installed.

This horse has been beaten enough. See [1] for advice how to package multiple 
versions of one package. That's the best we can do and that's also the best we 
consider being *reasonably* maintainable.

> Is there a an effort that complements this one on the policy/non-technical
> side?

Well, if you have some problems with Fedora packaging policy, I suggest 
communicating your ideas to the Fedora Packaging Committee. If your request is 
really reasonable, I'm sure they'll reflect it in the policy. However the 
problem usually is that developers have very different idea of reasonable than 
distribution maintainers because both groups have very different goals.

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 
itself. The content of these repositories will be governed by the same law as 
Fedora packages are (SW patents, ...) but technical policies should be a lot 
less strict.

Would that address your concerns?

Thanks
Jan

[1] http://rpm.org/wiki/PackagerDocs/MultipleVersions
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Yum dependency resolving & remove_leaf_only

[P J P]

> On Tuesday, 15 October 2013 12:51 PM, Jan Zelený  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 options what to do 
> in such cases.

Yeah, true.
---
Regards
   -Prasad
http://feedmug.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-MooseX-TrackDirty-Attributes/f20] This package does not work with Perl 5.18 (bug #992690).

[Petr Pisar]

commit a8d428edc619448e9e5ada497b5fbb755eed5cd0
Author: Petr Písař 
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 +
 perl-MooseX-TrackDirty-Attributes.spec |   95 
 sources|1 -
 4 files changed, 1 insertions(+), 101 deletions(-)
---
diff --git a/dead.package b/dead.package
new file mode 100644
index 000..ba77d13
--- /dev/null
+++ b/dead.package
@@ -0,0 +1 @@
+This package does not work with Perl 5.18 (bug #992690).
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

prelink performance gains

[Dhiru Kholia]

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 "unSPEC" to do
  independent validation of these numbers.

  - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797,
1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink)

  - hkario (modern SSD based system, cache intact): (2.155, 2.121, 2.101, 2.299
with prelink), (2.311, 2.052, 2.047, 2.037 without prelink)

  - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901,
8.993, 9.075, 9.448, 9.489 without prelink)

  - danpb (T530): I see basically no measurable difference in times with or
without prelink - quite a lot of variation, but all in same ballpark,
(8.374, 7.849, 8.457, 7.673, 7.608, 8.031, 8.350, 8.183, 7.381 with
prelink), (7.366, 8.009, 7.500, 7.949, 8.208, 8.351, 7.849, without
prelink).

- For building kernels (using the "kernel-bench" [3] component of unSPEC
  suite), prelink saved <= 250 ms over the non-prelink environment
  (which took 1m19.138s). hkario even reports worse performance numbers
  for the prelink environment. Additionally, we have specialized
  softwares like ccache and distcc to solve long-compilation-time
  problems.

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 could run
"unSPEC" on your systems and report back the numbers.

"unSPEC" is easy to use and doesn't take much time (or steps) to run.
For more information, please see the following links.

References:

[1] https://github.com/kholia/unSPEC
[2] https://github.com/kholia/unSPEC/tree/master/LibreOffice
[3] https://github.com/kholia/unSPEC/tree/master/kernel-bench

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Josh Boyer]

On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia  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" benchmarking suite. These numbers
>   are repeatable and you are encouraged to try "unSPEC" to do
>   independent validation of these numbers.
>
>   - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797,
> 1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink)
>
>   - hkario (modern SSD based system, cache intact): (2.155, 2.121, 2.101, 
> 2.299
> with prelink), (2.311, 2.052, 2.047, 2.037 without prelink)
>
>   - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901,
> 8.993, 9.075, 9.448, 9.489 without prelink)
>
>   - danpb (T530): I see basically no measurable difference in times with or
> without prelink - quite a lot of variation, but all in same ballpark,
> (8.374, 7.849, 8.457, 7.673, 7.608, 8.031, 8.350, 8.183, 7.381 with
> prelink), (7.366, 8.009, 7.500, 7.949, 8.208, 8.351, 7.849, without
> prelink).
>
> - For building kernels (using the "kernel-bench" [3] component of unSPEC
>   suite), prelink saved <= 250 ms over the non-prelink environment
>   (which took 1m19.138s). hkario even reports worse performance numbers
>   for the prelink environment. Additionally, we have specialized
>   softwares like ccache and distcc to solve long-compilation-time
>   problems.

I wouldn't expect building kernels to be a great thing to use to
measure performance benefits of prelink.  A kernel build is basically
just calling gcc and ld over and over, and those two things themselves
have relatively few libraries involved.  So your numbers match what I
would expect in this case, but I don't think it's really and accurate
testcase.  Prelink isn't intended to reduce compilation times.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

There used to be a way to minimize the address section on Thunderbird

[Daniel J Walsh]

-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 is painful.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJdN/oACgkQrlYvE4MpobP4ywCeJfE6JbZ7bvSJ3ZVkek+jki4x
xIYAn1D3iZCNs/j8Dgf3Xgm/1GGQyq4s
=8Lhn
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Automounting of the root partition in the initramfs

[Juerg Haefliger]

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 sfdisk command), something
automatically remounts the root partition and the growroot script
fails when it tries to mount the already mounted partition.

Can somebody shed some light on what is happening and why the root
partition is automatically remounted and if I can rely on that and not
have the growroot script try to remount it?

Thanks
...Juerg
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: There used to be a way to minimize the address section on Thunderbird

[Stephen Gallagher]

-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?
> 
> Wasting this screen real estate on a small screen is painful.
> 


What address section do you mean? A screenshot might help.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJdOxMACgkQeiVVYja6o6PqgwCfaZ24oZ4RoWzBjmna1iDy+gxV
ga0Ani2fWwhs1jqy87T1j660RFpgXo85
=lM9e
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: There used to be a way to minimize the address section on Thunderbird

[Tom Hughes]

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 with the CompactHeader 
plugin:


https://addons.mozilla.org/en-US/thunderbird/addon/compactheader/

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Dhiru Kholia]

On 10/15/13 at 05:30am, Josh Boyer wrote:
> On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia  wrote:
> > During the development of "unSPEC" [1] benchmarking suite, I made some
> > interesting observations regarding prelink.
> > ...
> > - For building kernels (using the "kernel-bench" [3] component of unSPEC
> >   suite), prelink saved <= 250 ms over the non-prelink environment
> >   (which took 1m19.138s). hkario even reports worse performance numbers
> >   for the prelink environment. Additionally, we have specialized
> >   softwares like ccache and distcc to solve long-compilation-time
> >   problems.
>
> I wouldn't expect building kernels to be a great thing to use to
> measure performance benefits of prelink.  A kernel build is basically
> just calling gcc and ld over and over, and those two things themselves
> have relatively few libraries involved.  So your numbers match what I
> would expect in this case, but I don't think it's really and accurate
> testcase.  Prelink isn't intended to reduce compilation times.

Hi Josh,

Good points.

Please see http://lwn.net/Articles/341244/ page. In particular, "Note,
also small but frequently used apps benefit. I run gcc etc a lot and
like every single saved cycle."

I just wanted to quantify these kinds of use-cases too. Does this make
sense?

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Alternative to Debian origins?

[Miroslav Suchý]

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 difference vendor. See:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487437
for more details.
Then dpkg-vendor(1) works with this information.

For example Ubuntu point the symlink to
/etc/dpkg/origins/ubuntu with content:
Vendor: Ubuntu
Vendor-URL: http://www.ubuntu.com/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Parent: Debian

I am only aware of:
  /etc/*-release
which is not perfect equivalent.

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Software management: Call for RFEs results!

[Matthew Miller]

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 itself. The content of these repositories will be governed
> by the same law as Fedora packages are (SW patents, ...) but technical
> policies should be a lot less strict.
> Would that address your concerns?

I won't speak for Michael, but I think the answer is no. COPRs fills a need,
but it's _too_ wild west (no package signatures, for example). We need to
support multiple language runtimes and native upstream packaging *in*
Fedora.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Alternative to Debian origins?

[Ralf Corsepius]

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 in Fedora world?

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.



  /etc/*-release
which is not perfect equivalent.

That's what the LSB mandates to identify an OS's vendor. Debian and 
Ubuntu also have them (os-release, lsb-release).


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Alternative to Debian origins?

[Matthew Miller]

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 some alternative to this in Fedora world?
> The goal of this file is to difference vendor. See:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487437
> for more details.

We don't have anything like that, but something equivalent might be useful
for split Fedora products -- "vendor" would be the wrong word, though.

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 having read the debian bugs. What do _you_ want to do with it?
 



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Josh Boyer]

On Tue, Oct 15, 2013 at 5:55 AM, Dhiru Kholia  wrote:
> On 10/15/13 at 05:30am, Josh Boyer wrote:
>> On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia  wrote:
>> > During the development of "unSPEC" [1] benchmarking suite, I made some
>> > interesting observations regarding prelink.
>> > ...
>> > - For building kernels (using the "kernel-bench" [3] component of unSPEC
>> >   suite), prelink saved <= 250 ms over the non-prelink environment
>> >   (which took 1m19.138s). hkario even reports worse performance numbers
>> >   for the prelink environment. Additionally, we have specialized
>> >   softwares like ccache and distcc to solve long-compilation-time
>> >   problems.
>>
>> I wouldn't expect building kernels to be a great thing to use to
>> measure performance benefits of prelink.  A kernel build is basically
>> just calling gcc and ld over and over, and those two things themselves
>> have relatively few libraries involved.  So your numbers match what I
>> would expect in this case, but I don't think it's really and accurate
>> testcase.  Prelink isn't intended to reduce compilation times.
>
> Hi Josh,
>
> Good points.
>
> Please see http://lwn.net/Articles/341244/ page. In particular, "Note,
> also small but frequently used apps benefit. I run gcc etc a lot and
> like every single saved cycle."
>
> I just wanted to quantify these kinds of use-cases too. Does this make
> sense?

Sure, if you take the "save every cycle I can approach".  It's all
relative to your point of view.  I was just noting that a common
Fedora user wouldn't necessarily expect prelink to help with
compilation times.  Even a crazy kernel developer like me doesn't
expect that.  I can be very impatient when it comes to dealing with
machines, but even I can't notice 250ms ;).

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

PackageKit service pack and catalog functionality

[Richard Hughes]

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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Automounting of the root partition in the initramfs

[Harald Hoyer]

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 is that as soon as the
> repartitioning finishes (its an sfdisk command), something
> automatically remounts the root partition and the growroot script
> fails when it tries to mount the already mounted partition.
> 
> Can somebody shed some light on what is happening and why the root
> partition is automatically remounted and if I can rely on that and not
> have the growroot script try to remount it?
> 
> Thanks
> ...Juerg
> 

Oh, that is systemd, because it generates a unit file from the kernel command
line called sysroot.mount, which is required by the following systemd targets.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Paul Wouters]

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 could run
"unSPEC" on your systems and report back the numbers.


Please take prelink behind the barn and shoot it. Thanks.

Every year people point out how obsoleted it is, yet we can't get seem
to rid of it.

The amount of time I've wasted on prelink in combination with FIPS is
something another decade of prelink speed gains isn't going to compensate
me for. I think /etc/prelink.conf.d along with the cron job and its
sysconfig override is an overengineered solution (and ugly because any
blacklist package has to own the directory of prelink too)

How can we have this discussion? We have had reports of numbers showing
no real gain. We know it affects ASLR negatively and complicates FIPS
engineering.

Why haven't we at least reached a compromise where prelink is _optional_
and not installed per default? It seems currently to be part of the
fedora live install (and the rhel workstation installs)

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Alternative to Debian origins?

[Miroslav Suchý]

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 presented in base-files package:
$ dpkg -L base-files |grep origins
/etc/dpkg/origins
/etc/dpkg/origins/debian

I agree that the path is quite misleading.


/etc/*-release
which is not perfect equivalent.


That's what the LSB mandates to identify an OS's vendor. Debian and Ubuntu also 
have them (os-release, lsb-release).


Debian have /etc/debian_version, lsb-release does not give useful output on my 
Debian system.

Well, I'm not saying that we must have it. I'm just helping to port some Debian 
package to Fedora and we hit this one.
Honestly, I heard about it for the first time. And I was not aware that Debian 
have something like this.
If Fedora does not have it, we can guess it, or hardcode it. I just thought 
that I would ask the elders :)


Well looking at content of fedora-release, there is interesting file /etc/os-release, nicely parse-able and supported 
across distributions. And if we add there HOME_URL= and BUG_REPORT_URL according to

  http://www.freedesktop.org/software/systemd/man/os-release.html#HOME_URL=
we will be functionally complete to origins/debian and complain to standards at 
the same time.
I filed BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1019344

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 914310] perl-Padre: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=914310

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=cqmCv8k4Cq&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: prelink performance gains

[Daniel P. Berrange]

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 prelink
> >provides measurable benefits. In would be awesome if you could run
> >"unSPEC" on your systems and report back the numbers.
> 
> Please take prelink behind the barn and shoot it. Thanks.
> 
> Every year people point out how obsoleted it is, yet we can't get seem
> to rid of it.
> 
> The amount of time I've wasted on prelink in combination with FIPS is
> something another decade of prelink speed gains isn't going to compensate
> me for. I think /etc/prelink.conf.d along with the cron job and its
> sysconfig override is an overengineered solution (and ugly because any
> blacklist package has to own the directory of prelink too)
> 
> How can we have this discussion? We have had reports of numbers showing
> no real gain. We know it affects ASLR negatively and complicates FIPS
> engineering.
> 
> Why haven't we at least reached a compromise where prelink is _optional_
> and not installed per default? It seems currently to be part of the
> fedora live install (and the rhel workstation installs)

This mail is just a pre-cursor to proposing it be removed. When prelink
was added by default, the justification was the performance benefits to
startup. 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. So assuming no one comes forward to show some
incredible benefit(s) of prelink, a proposal to kill it by default
will surely follow.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 914310] perl-Padre: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=914310



--- Comment #6 from Petr Pisar  ---
Created attachment 812545
  --> https://bugzilla.redhat.com/attachment.cgi?id=812545&action=edit
Fix ported from upstream

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=NMeHTgsoR1&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Padre] Fix compatibility with ORLite-1.98

[Petr Pisar]

commit 7a191d76edf3fe2678737b738371b74ac6f8a759
Author: Petr Písař 
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|   15 +-
 2 files changed, 346 insertions(+), 2 deletions(-)
---
diff --git 
a/Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch 
b/Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch
new file mode 100644
index 000..531b474
--- /dev/null
+++ b/Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch
@@ -0,0 +1,333 @@
+From dd579f8ce7ba1a26fb1c67bb9d82765251eacd54 Mon Sep 17 00:00:00 2001
+From: Petr Pisar 
+Date: Tue, 15 Oct 2013 15:48:26 +0200
+Subject: [PATCH] Migrating to the delete_where method for bulk deletion to
+ align with ORLite 2.0
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is r18434 ported to 0.90 because ORLite-1.98 removed support for
+static delete() method.
+
+
+
+Signed-off-by: Petr Písař 
+---
+ lib/Padre/DB/LastPositionInFile.pm|  2 +-
+ lib/Padre/DB/Session.pm   | 30 ++
+ lib/Padre/DB/SyntaxHighlight.pm   |  4 ++--
+ lib/Padre/Wx/ActionLibrary.pm |  2 +-
+ lib/Padre/Wx/Dialog/Bookmarks.pm  |  4 +---
+ lib/Padre/Wx/Dialog/SessionManager.pm |  2 +-
+ lib/Padre/Wx/Dialog/SessionSave.pm| 20 ++--
+ lib/Padre/Wx/Main.pm  | 34 --
+ lib/Padre/Wx/Menu/File.pm |  4 ++--
+ t/60-db.t |  2 +-
+ 10 files changed, 53 insertions(+), 51 deletions(-)
+
+diff --git a/lib/Padre/DB/LastPositionInFile.pm 
b/lib/Padre/DB/LastPositionInFile.pm
+index 3fb72e4..fc358b4 100644
+--- a/lib/Padre/DB/LastPositionInFile.pm
 b/lib/Padre/DB/LastPositionInFile.pm
+@@ -83,7 +83,7 @@ sub set_last_pos {
+   my $position = shift;
+ 
+   my $transaction = Padre::Current->main->lock('DB');
+-  $class->delete( 'where name = ?', $file );
++  $class->delete_where( 'name = ?', $file );
+   $class->create(
+   name => $file,
+   position => $position,
+diff --git a/lib/Padre/DB/Session.pm b/lib/Padre/DB/Session.pm
+index 2fc08ba..1f9f3f9 100644
+--- a/lib/Padre/DB/Session.pm
 b/lib/Padre/DB/Session.pm
+@@ -10,12 +10,16 @@ package Padre::DB::Session;
+ use 5.008;
+ use strict;
+ use warnings;
++use Padre::Current ();
+ 
+ our $VERSION = '0.90';
+ 
+ my $PADRE_SESSION = 'padre-last';
+ 
+ sub last_padre_session {
++  my $class   = shift;
++  my $transaction = Padre::Current->main->lock('DB');
++
+ 
+   # find last padre session
+   my ($padre) = Padre::DB::Session->select(
+@@ -24,19 +28,21 @@ sub last_padre_session {
+   );
+ 
+   # no such session, create one
+-  if ( not defined $padre ) {
+-  $padre = Padre::DB::Session->new(
++unless ( defined $padre ) {
++$padre = $class->create(
+   name=> $PADRE_SESSION,
+   description => 'Last session within Padre',
+   last_update => time,
+   );
+-  $padre->insert;
+   }
++
+   return $padre;
+ }
+ 
+ sub clear_last_session {
+-  my $class = shift;
++my $class   = shift;
++my $transaction = Padre::Current->main->lock('DB');
++
+ 
+   # Find last padre session (shortcut if none)
+   my ($padre) = Padre::DB::Session->select(
+@@ -45,27 +51,19 @@ sub clear_last_session {
+   ) or return;
+ 
+   # Remove any files in the session
+-  Padre::DB::SessionFile->delete(
+-  'where session = ?',
+-  $padre->id,
+-  );
++Padre::DB::SessionFile->delete_where( 'session = ?', $padre->id );
+ 
+   # Remove the session itself
+-  Padre::DB::Session->delete(
+-  'where name = ?',
+-  $PADRE_SESSION,
+-  );
++$padre->delete;
+ 
+   return;
+ }
+ 
+ sub files {
+-  my ($self) = @_;
+-  my @files = Padre::DB::SessionFile->select(
++Padre::DB::SessionFile->select(
+   'where session = ?',
+-  $self->id
++  shift->id,
+   );
+-  return @files;
+ }
+ 
+ 1;
+diff --git a/lib/Padre/DB/SyntaxHighlight.pm b/lib/Padre/DB/SyntaxHighlight.pm
+index 5420157..38453ca 100644
+--- a/lib/Padre/DB/SyntaxHighlight.pm
 b/lib/Padre/DB/SyntaxHighlight.pm
+@@ -20,8 +20,8 @@ sub set_mime_type {
+   my $module= shift;
+ 
+   my $transaction = Padre::Current->main->lock('DB');
+-  $class->delete(
+-  'where mime_type = ?', $mime_type,
++  $class->delete_where(
++  'mime_type = ?', $mime_type,
+   );
+   $class->create(
+   mime_type => $mime_ty

Re: Automounting of the root partition in the initramfs

[Juerg Haefliger]

> 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 is that as soon as the
>> repartitioning finishes (its an sfdisk command), something
>> automatically remounts the root partition and the growroot script
>> fails when it tries to mount the already mounted partition.
>>
>> Can somebody shed some light on what is happening and why the root
>> partition is automatically remounted and if I can rely on that and not
>> have the growroot script try to remount it?
>>
>> Thanks
>> ...Juerg
>>
>
> Oh, that is systemd, because it generates a unit file from the kernel command
> line called sysroot.mount, which is required by the following systemd targets.

That's what I thought. So I can rely on that? Did that change for F20?
I don't remember seeing that behaviour with F19.

...Juerg
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Padre/f20] Fix compatibility with ORLite-1.98

[Petr Pisar]

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Padre/f19] Fix compatibility with ORLite-1.98

[Petr Pisar]

commit 310fcb80a0e23b133bf21ce6771585b3c939d7c3
Author: Petr Písař 
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|   15 +-
 2 files changed, 346 insertions(+), 2 deletions(-)
---
diff --git 
a/Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch 
b/Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch
new file mode 100644
index 000..531b474
--- /dev/null
+++ b/Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch
@@ -0,0 +1,333 @@
+From dd579f8ce7ba1a26fb1c67bb9d82765251eacd54 Mon Sep 17 00:00:00 2001
+From: Petr Pisar 
+Date: Tue, 15 Oct 2013 15:48:26 +0200
+Subject: [PATCH] Migrating to the delete_where method for bulk deletion to
+ align with ORLite 2.0
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is r18434 ported to 0.90 because ORLite-1.98 removed support for
+static delete() method.
+
+
+
+Signed-off-by: Petr Písař 
+---
+ lib/Padre/DB/LastPositionInFile.pm|  2 +-
+ lib/Padre/DB/Session.pm   | 30 ++
+ lib/Padre/DB/SyntaxHighlight.pm   |  4 ++--
+ lib/Padre/Wx/ActionLibrary.pm |  2 +-
+ lib/Padre/Wx/Dialog/Bookmarks.pm  |  4 +---
+ lib/Padre/Wx/Dialog/SessionManager.pm |  2 +-
+ lib/Padre/Wx/Dialog/SessionSave.pm| 20 ++--
+ lib/Padre/Wx/Main.pm  | 34 --
+ lib/Padre/Wx/Menu/File.pm |  4 ++--
+ t/60-db.t |  2 +-
+ 10 files changed, 53 insertions(+), 51 deletions(-)
+
+diff --git a/lib/Padre/DB/LastPositionInFile.pm 
b/lib/Padre/DB/LastPositionInFile.pm
+index 3fb72e4..fc358b4 100644
+--- a/lib/Padre/DB/LastPositionInFile.pm
 b/lib/Padre/DB/LastPositionInFile.pm
+@@ -83,7 +83,7 @@ sub set_last_pos {
+   my $position = shift;
+ 
+   my $transaction = Padre::Current->main->lock('DB');
+-  $class->delete( 'where name = ?', $file );
++  $class->delete_where( 'name = ?', $file );
+   $class->create(
+   name => $file,
+   position => $position,
+diff --git a/lib/Padre/DB/Session.pm b/lib/Padre/DB/Session.pm
+index 2fc08ba..1f9f3f9 100644
+--- a/lib/Padre/DB/Session.pm
 b/lib/Padre/DB/Session.pm
+@@ -10,12 +10,16 @@ package Padre::DB::Session;
+ use 5.008;
+ use strict;
+ use warnings;
++use Padre::Current ();
+ 
+ our $VERSION = '0.90';
+ 
+ my $PADRE_SESSION = 'padre-last';
+ 
+ sub last_padre_session {
++  my $class   = shift;
++  my $transaction = Padre::Current->main->lock('DB');
++
+ 
+   # find last padre session
+   my ($padre) = Padre::DB::Session->select(
+@@ -24,19 +28,21 @@ sub last_padre_session {
+   );
+ 
+   # no such session, create one
+-  if ( not defined $padre ) {
+-  $padre = Padre::DB::Session->new(
++unless ( defined $padre ) {
++$padre = $class->create(
+   name=> $PADRE_SESSION,
+   description => 'Last session within Padre',
+   last_update => time,
+   );
+-  $padre->insert;
+   }
++
+   return $padre;
+ }
+ 
+ sub clear_last_session {
+-  my $class = shift;
++my $class   = shift;
++my $transaction = Padre::Current->main->lock('DB');
++
+ 
+   # Find last padre session (shortcut if none)
+   my ($padre) = Padre::DB::Session->select(
+@@ -45,27 +51,19 @@ sub clear_last_session {
+   ) or return;
+ 
+   # Remove any files in the session
+-  Padre::DB::SessionFile->delete(
+-  'where session = ?',
+-  $padre->id,
+-  );
++Padre::DB::SessionFile->delete_where( 'session = ?', $padre->id );
+ 
+   # Remove the session itself
+-  Padre::DB::Session->delete(
+-  'where name = ?',
+-  $PADRE_SESSION,
+-  );
++$padre->delete;
+ 
+   return;
+ }
+ 
+ sub files {
+-  my ($self) = @_;
+-  my @files = Padre::DB::SessionFile->select(
++Padre::DB::SessionFile->select(
+   'where session = ?',
+-  $self->id
++  shift->id,
+   );
+-  return @files;
+ }
+ 
+ 1;
+diff --git a/lib/Padre/DB/SyntaxHighlight.pm b/lib/Padre/DB/SyntaxHighlight.pm
+index 5420157..38453ca 100644
+--- a/lib/Padre/DB/SyntaxHighlight.pm
 b/lib/Padre/DB/SyntaxHighlight.pm
+@@ -20,8 +20,8 @@ sub set_mime_type {
+   my $module= shift;
+ 
+   my $transaction = Padre::Current->main->lock('DB');
+-  $class->delete(
+-  'where mime_type = ?', $mime_type,
++  $class->delete_where(
++  'mime_type = ?', $mime_type,
+   );
+   $class->create(
+   mime_type => $mime_ty

Re: Alternative to Debian origins?

[Michael Schroeder]

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 having read the debian bugs. What do _you_ want to do with it?

IMHO it's about selecting different features at package build time.
As rpm supports macros, you would test some macro, e.g. %fedora_version
or %_vendor.

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX Products GmbH,  GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 914295] perl-MIME-Lite-HTML: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=914295

Petr Pisar  changed:

   What|Removed |Added

External Bug ID|CPAN 914295 |CPAN 86020



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=TebXfWEzqM&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 914310] perl-Padre: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=914310

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Padre-0.90-10.fc21



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=2tRJY8PUdr&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 914310] perl-Padre: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=914310



--- Comment #7 from Fedora Update System  ---
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 because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=Oml31ArXRO&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 914310] perl-Padre: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=914310



--- Comment #8 from Fedora Update System  ---
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 because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=2BBDQyuYu8&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Automounting of the root partition in the initramfs

[Harald Hoyer]

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 then tries to
>>> remount it. What I noticed in F20 is that as soon as the
>>> repartitioning finishes (its an sfdisk command), something
>>> automatically remounts the root partition and the growroot script
>>> fails when it tries to mount the already mounted partition.
>>>
>>> Can somebody shed some light on what is happening and why the root
>>> partition is automatically remounted and if I can rely on that and not
>>> have the growroot script try to remount it?
>>>
>>> Thanks
>>> ...Juerg
>>>
>>
>> Oh, that is systemd, because it generates a unit file from the kernel command
>> line called sysroot.mount, which is required by the following systemd 
>> targets.
> 
> That's what I thought. So I can rely on that? Did that change for F20?
> I don't remember seeing that behaviour with F19.
> 
> ...Juerg
> 

Well, it "should" be the same in F19. Maybe some internal ordering of the units
changed.

You can rely on it, as long as the kernel command line contains a valid "root="
in the form of:

root=/dev/...
root=LABEL=...
root=UUID=...
root=PARTUUID=...
root=PARTLABEL=...

which "should" be always the case, except for network dhcp booting, where the
dhcp "root-path" can determine the root.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 missing some statistics behind it such as deviation computation.
And 4 tests/numbers seem to be too few to compute any real statistics.

Some numbers in the initial mail even show as if prelink is slowing down the
startup.  Technically I do not understand how it can happen and IMHO rather
the numbers are bogus.  If there is a proven performance degradation it would
be good to know the reason.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Matthew Miller]

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 is missing some statistics behind it such as deviation computation.
> And 4 tests/numbers seem to be too few to compute any real statistics.

But, since prelink presents other problems on its own, I think the bar is
pretty low here. Even though prelink is currently in, the burden of proof
should be on demonstrating its continued usefulness, and the threshold for
that should be be higher than marginal noise. When in doubt, let's go for
smaller and more simple.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Bug 950189: Missing icon for qt-creator

[Sandro Mani]

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. (I'd be happy to fix it myself, but asking for commit rights for 
this one tiny issue seems a bit excessive?)


Thanks,
Sandro


[1] https://bugzilla.redhat.com/show_bug.cgi?id=950189
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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.  There aren't
enough numbers (+their stats).


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Alternative to Debian origins?

[Ralf Corsepius]

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 what they want to _do_ with it though,
even having read the debian bugs. What do _you_ want to do with it?

IMHO it's about selecting different features at package build time.
As rpm supports macros, you would test some macro, e.g. %fedora_version

That's a SUSE-ism. Fedora's rpm utilizes %fedora.

or %_vendor.


3rd parties often override %_vendor, so this would not work well.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 tools no longer compatible with
non-zero file address base may have problems in future if someone wants to use
them that way for example on some embedded system.

But another opinion can be s/he should fix them her/himself if s/he needs such
a feature.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Daniel P. Berrange]

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 noise.
> 
> That's the problem we even disagree how to read the numbers.  There aren't
> enough numbers (+their stats).

Well if no one can come up with a way to produce numbers that clearly
demonstrate that prelink is useful we should ditch it, regardless due
to the complexity / downsides it causes.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Alternative to Debian origins?

[Sérgio Basto]

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 some alternative to this in Fedora world?
> 
> The goal of this file is to difference vendor. See:
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487437
> for more details.
> Then dpkg-vendor(1) works with this information.
> 
> For example Ubuntu point the symlink to
> /etc/dpkg/origins/ubuntu with content:
> Vendor: Ubuntu
> Vendor-URL: http://www.ubuntu.com/
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Parent: Debian
> 
> I am only aware of:
>/etc/*-release
> which is not perfect equivalent.


Hi, 
I'm the current maintainer of dpkg, since other 2 are unresponsive , 
I'm consider add patch on
https://bugzilla.redhat.com/show_bug.cgi?id=973832 
for F20. 
But, now ,I'm very busy in my work , I just can read this thread and
apply patch later night or tomorrow . 

Best regards
-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Code Hosting, Development Tools and Open Source

[Kamil Paral]

> 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 review etc.).

My thoughts:

* We should avoid self-hosting as much as possible. If we consider something 
self-hosted, it should be far better than something managed by a third-party.

* Anonymous viewing is a must for an open-source.

* FAS integration is ideal, but not strictly necessary, if we use a widely 
popular service (like github). If we force people to create an account in our 
self-hosted service just to report a bug, we won't receive many bug reports.

As you described Phabricator, it doesn't seem to be ready yet (no anonymous 
viewing, no FAS integration). I might have misunderstood something, but were 
you considering to implement that? That doesn't sound as a few days task. If 
the two issues were not there, I'd like to give it a try, it definitely sounds 
interesting.

I like Github, but it really might be too simplified for our use cases. I 
haven't studied these advanced tasks like moving a bug report to a different 
project, but it seems you have. (On the other hand, does Trac support this 
particular task?). It might be a good idea to ask fedora-infra guys about their 
experience.

Fedorahosted + Reviewboard is far from ideal. Lately you and Martin have been 
using it the most, so I think you're the best people to say whether we want to 
stay with it or move away from it. Thanks very much for investigating this.
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Anyone else using and interested in co-maintaining sogo?

[Sandro Mani]

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
http://smani.fedorapeople.org/review/sope-2.0.7-1.fc21.src.rpm
http://smani.fedorapeople.org/review/lasso-2.3.6-1.fc21.src.rpm

I think the packages are pretty decent and fit for inclusion into 
Fedora, and they might well be of interest to other people. However, I 
am hestitant to post them for review since Objective-C and GNUStep are 
not really known territory for me, and I'm also rather unexperienced 
with stuff like LDAP.


So, anyone who would like to see these in Fedora and is willing to help 
out if things go wrong?


Thanks,
Sandro


[1] http://www.sogo.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Chris Murphy]

On Oct 15, 2013, at 2:15 AM, David Airlie  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. This is
>> really quite useful, I've used an iMac hooked up to a Linux machine at a
>> previous job, and it's awesome to switch between the two machines when
>> you've only got space for one display on the desk. The feature is invoked by
>> a fairly non-standard keyboard combination. Here is a video illustrating
>> what I mean (
>> http://www.youtube.com/watch?feature=player_detailpage&v=Y7_OZgBX8kQ#t=60 ),
>> note how he switches the iMac from being the display for the MacBook to
>> being an iMac again via keyboard shortcut (sort of off-screen).
>> 
>> However, this feature is only implemented in OS X and Windows (via HP's My
>> Display application) on the iMac and Z1 respectively. Which means that if,
>> for example, a Z1 has Linux as the primary OS, the Z1 cannot currently be
>> used as a monitor for a laptop or another computer (via Target Display
>> Mode). As far as I've been able to discover, Target Display Mode does not
>> exist under any flavor of Linux.
>> 
>> What would it take to support this in Fedora? Is this a Desktop-centric
>> feature for Gnome/KDE/Cinnamon, or is this something that would/should be
>> part of the Linux kernel itself? I don't think it's directly part of a
>> graphics driver (at least on Windows, since HP released My Display as a
>> separate program), but again I'm not sure.
> 
> You'd have to reverse engineer or ask HP/Apple what they actually do for this
> to work.
> 
> then implement that.

Or maybe Intel would be forthcoming. It's their hardware.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] please review: Ticket 47519 - memory leaks in access control

[Mark Reynolds]

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
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: prelink performance gains

[Daniel P. Berrange]

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 Fedora. That is what this email thread is seeking to confirm.
> 
> There is missing some statistics behind it such as deviation computation.
> And 4 tests/numbers seem to be too few to compute any real statistics.
> 
> Some numbers in the initial mail even show as if prelink is slowing down the
> startup.  Technically I do not understand how it can happen and IMHO rather
> the numbers are bogus.  If there is a proven performance degradation it would
> be good to know the reason.

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.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora and ECDHE: now supported in OpenSSL

[Reindl Harald]

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 today
_

openssl:
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108

nss-softokn
https://bugzilla.redhat.com/show_bug.cgi?id=1019244

nss
https://bugzilla.redhat.com/show_bug.cgi?id=1019245

firefox
https://bugzilla.redhat.com/show_bug.cgi?id=1019247

thunderbird:
https://bugzilla.redhat.com/show_bug.cgi?id=1019249

httpd:
https://bugzilla.redhat.com/show_bug.cgi?id=1019251

dovecot:
https://bugzilla.redhat.com/show_bug.cgi?id=1019253

postfix:
https://bugzilla.redhat.com/show_bug.cgi?id=1019254

openssh:
https://bugzilla.redhat.com/show_bug.cgi?id=1019256

dbmail:
https://bugzilla.redhat.com/show_bug.cgi?id=1019259




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 Kholia:
> 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 "unSPEC" to do
>   independent validation of these numbers.
> 
>   - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797,
> 1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink)
> 
>   - hkario (modern SSD based system, cache intact): (2.155, 2.121, 2.101, 
> 2.299
> with prelink), (2.311, 2.052, 2.047, 2.037 without prelink)
> 
>   - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901,
> 8.993, 9.075, 9.448, 9.489 without prelink)
> 
>   - danpb (T530): I see basically no measurable difference in times with or
> without prelink - quite a lot of variation, but all in same ballpark,
> (8.374, 7.849, 8.457, 7.673, 7.608, 8.031, 8.350, 8.183, 7.381 with
> prelink), (7.366, 8.009, 7.500, 7.949, 8.208, 8.351, 7.849, without
> prelink).
> 
> - For building kernels (using the "kernel-bench" [3] component of unSPEC
>   suite), prelink saved <= 250 ms over the non-prelink environment
>   (which took 1m19.138s). hkario even reports worse performance numbers
>   for the prelink environment. Additionally, we have specialized
>   softwares like ccache and distcc to solve long-compilation-time
>   problems.
> 
> 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 could run
> "unSPEC" on your systems and report back the numbers.
> 
> "unSPEC" is easy to use and doesn't take much time (or steps) to run.
> For more information, please see the following links.
> 
> References:
> 
> [1] https://github.com/kholia/unSPEC
> [2] https://github.com/kholia/unSPEC/tree/master/LibreOffice
> [3] https://github.com/kholia/unSPEC/tree/master/kernel-bench



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora and ECDHE: now supported in OpenSSL

[Paul Wouters]

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 also on the client side


Is there an updated page about ECC in Fedora? What ECC
curves are allowed? What implementations?

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Dhiru Kholia]

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 problem we even disagree how to read the numbers.  There aren't
> enough numbers (+their stats).

Jan,

Yes, the numbers I posted have zero "scientific" value and are simply
crude measurements.

In spite of this fact, I believe that they are enough to demonstrate
that prelink is not resulting in any big gains anymore.

Even if these numbers don't demonstrate that, they should *at least*
make us doubt prelink's relevance. I am going to quote Matthew on this,
"Even though prelink is currently in, the burden of proof should be on
demonstrating its continued usefulness, and the threshold for that
should be be higher than marginal noise. When in doubt, let's go for
smaller and more simple".

"unSPEC" is super easy to run and you are encouraged to get all the
numbers and stats you need.

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Matthew Garrett]

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
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

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 mangle/demangle support.
>> - Enhance aarch64 to support the same set of features.
> 
> 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
variable and is used by existing runtime. Regression tests are
passing in glibc testsuite. Verified working. Upstream verified
that global variable is the best compromise for performance across
all 32-bit ARM targets (TLS will be too slow in the average case).

- Pointer mangling:
  - Not supported.

Upstream glibc 2.19 summary:

- Stack guard support already present using global variable.

- Will have pointer encryption support using global variable, 
  and could be a candidate for backport to f20.
 
  ~~~
  commit b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8
  Author: Will Newton 
  Date:   Wed Aug 7 13:55:30 2013 +0100

ARM: Add pointer encryption support.

Add support for pointer encryption in glibc internal structures in C
and assembler code. Pointer encryption is a glibc security feature
described here:

https://sourceware.org/glibc/wiki/PointerEncryption

The ARM implementation uses global variables instead of thread pointer
relative accesses to get the value of the pointer encryption guard
because accessing the thread pointer can be very expensive on older
ARM cores.
  ...
  ~~~

Do we need pointer mangling? If so then we need someone to file an
f20 specific bug so the glibc team can look at backporting the fix.
I won't commit to it until I review exactly what might need changing.

Cheers,
Carlos.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

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
> variable and is used by existing runtime. Regression tests are
> passing in glibc testsuite. Verified working. Upstream verified
> that global variable is the best compromise for performance across
> all 32-bit ARM targets (TLS will be too slow in the average case).

What's the effective difference in security between this and the 
existing ports?

> - Pointer mangling:
>   - Not supported.

Do we ship it in the x86 ports?

> Upstream glibc 2.19 summary:
> 
> - Stack guard support already present using global variable.
> 
> - Will have pointer encryption support using global variable, 
>   and could be a candidate for backport to f20.

Cool. This is a runtime change, right? There's no requirement for a 
rebuild to take advantage of it?

> Do we need pointer mangling? If so then we need someone to file an
> f20 specific bug so the glibc team can look at backporting the fix.
> I won't commit to it until I review exactly what might need changing.

The aim was for parity of important features, but it doesn't seem like 
we've ever advertised pointer guard as a Fedora feature so I'm not 
personally that worried.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 performance
and negligible battery optimization nowadays.

I just do not understand why to give up on that negligible optimization when
it brings no disadvantages.

The disagreement here is whether it brings some disadvantages or not.

So the discussion should rather be if the average (default) user faces the
claimed disadvantages or not (*), and therefore whether prelink should be
installed by default or not.


(*)
I find there for example a problem that nightly prelink will run even if you
are currently running on battery.  But that affects more cron scripts and it
is a cron bug, not prelink bug.


> "unSPEC" is super easy to run and you are encouraged to get all the
> numbers and stats you need.

I intentionally do not post the numbers but it seems to me prelink does bring
negligible performance (and battery) gain for LibreOffice on my system.
It is just difficult to measure if you do not trust LD_DEBUG=statistics.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Anyone else using and interested in co-maintaining sogo?

[Frankie Onuonga]

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  wrote:

> 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
> http://smani.fedorapeople.org/**review/sope-2.0.7-1.fc21.src.**rpm
> http://smani.fedorapeople.org/**review/lasso-2.3.6-1.fc21.src.**rpm
>
> I think the packages are pretty decent and fit for inclusion into Fedora,
> and they might well be of interest to other people. However, I am hestitant
> to post them for review since Objective-C and GNUStep are not really known
> territory for me, and I'm also rather unexperienced with stuff like LDAP.
>
> So, anyone who would like to see these in Fedora and is willing to help
> out if things go wrong?
>
> Thanks,
> Sandro
>
>
> [1] http://www.sogo.nu/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
> Fedora Code of Conduct: 
> http://fedoraproject.org/code-**of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 performance
> and negligible battery optimization nowadays.
> 
> I just do not understand why to give up on that negligible optimization when
> it brings no disadvantages.
> 
> The disagreement here is whether it brings some disadvantages or not.
> 
> So the discussion should rather be if the average (default) user faces the
> claimed disadvantages or not (*), and therefore whether prelink should be
> installed by default or not.

* 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
* look at the wasted cycles of running prelink itself and compare to the gain

in the past on notebooks i hated prelink and god bless the maintainer which
removed the prelink-require out of rkhunter which was pervert

most of the time i noticed the weak performance while prelink ran
between that i got alarmed all the time by rkhunter-notifies
*because* i should prelink this and that file

hence - at the end of the day prelink itself consumed more CPU
and did more harm as it ever could have gained performance





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 disadvantage is it?


> * look at the wasted cycles of running prelink itself and compare to the gain

the cycles of prelink happen during night when nobody waits for anything.
The gain happens when user waits until the program starts.


> in the past on notebooks i hated prelink and god bless the maintainer which
> removed the prelink-require out of rkhunter which was pervert
> 
> most of the time i noticed the weak performance while prelink ran
> between that i got alarmed all the time by rkhunter-notifies
> *because* i should prelink this and that file

Sorry I do not see how is rkhunter related and what is the disadvantage.

If you mean that prelink ever runs while you sit at the computer then it is
a bug in cron, not in prelink.  /etc/cron.daily/mlocate has a similar problem.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Simo Sorce]

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 a negligible performance
> and negligible battery optimization nowadays.
> 
> I just do not understand why to give up on that negligible optimization when
> it brings no disadvantages.

Prelink does big disadvantages, otherwise nobody would care.
One is about security, as it negates randomization of addresses,
modification of binaries in itself is pretty perverse to gain just
imperceptible performance gains. Many tools need to juggle the fact
these binaries have been changed, and make checkers more complex and
prone to faults.

In general prelink makes things more complex for negligible gains, its
worth is highly questionable.

> The disagreement here is whether it brings some disadvantages or not.

I just hope you are not saying that there is a doubt there are
disadvantages.

The real question here is whether advantages supersede disadvantges, and
given the only advantage seem to be performance and it is lost in noise,
I hardly see how the advantages are enough to justify using it these
days.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: sysctl behavior for docker-io

[Miloslav Trmač]

On Sun, Oct 6, 2013 at 11:32 PM, Lennart Poettering
 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 only
control the individual sysctl, but also the more detailed forwarding
semantics (i.e. the application should request a specific, fairly
high-level forwarding scenario ("do a NAT of all traffic from
$this_ethernet and $this_wifi to $that ethernet"), and the firewall
should manage both iptables and sysctl.

I guess this is suggestion wouldn't be currently met with universal
approval, would it?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Chris Murphy]

On Oct 15, 2013, at 10:36 AM, Matthew Garrett  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 specific.


Too bad. I wonder if this switching extension is being obfuscated from reverse 
engineering with these "smart" cables Apple's producing.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Chris Adams]

Once upon a time, Jan Kratochvil  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
> 
> Sorry I do not see what disadvantage is it?

If you install updates, reboot, and log in, you are running
non-prelinked binaries/libraries.  If you don't log out (just lock
screen or suspend for example), when you next use the system after
prelink has run, new programs will use the prelinked bins/libs.  Now you
are wasting a chunk of RAM, as it can't be shared between non-prelinked
and prelinked bins/libs.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: sysctl behavior for docker-io

[Miloslav Trmač]

On Mon, Oct 7, 2013 at 3:47 PM, Richard W.M. Jones  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 Embedded Routers
>
> The embedded router feature seems to make building a network easy, but 
>it has a number of hidden pitfalls:
>
> (1) If a host has only a single constituent-network interface, it should not 
> act as a router.
>
> For example, hosts with embedded router code that gratuitously forward 
> broadcast packets or datagrams on the same net often cause packet avalanches.

I'm almost certain that some other RFC requires forwarding for
~workstations to be opt-in, but I couldn't find it.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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
compilers and half of debuggers, which are all needlessly complex and prone to
faults due to -O2.  Do we want to build simple system or good system?


> In general prelink makes things more complex for negligible gains, its
> worth is highly questionable.

I am aware of it, I have spent a lot of time making tools prelink compatible.
But even compilers have very complex parts for negligible gains.


> I just hope you are not saying that there is a doubt there are
> disadvantages.

I really have not yet seen any valid one.


> The real question here is whether advantages supersede disadvantges, and
> given the only advantage seem to be performance and it is lost in noise,

I would not say it is lost in noise but let's say it is not big.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 prelink.

I understand you may find a machine low on RAM where the overall performance
with prelink will be lower.  That is a special case, not an average user.
You can uninstall prelink on such underpowered machine.

I have no numbers to back my performance guess above.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Josh Boyer]

On Tue, Oct 15, 2013 at 10:56 AM, 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 away most of
> compilers and half of debuggers, which are all needlessly complex and prone to
> faults due to -O2.  Do we want to build simple system or good system?
>
>
>> In general prelink makes things more complex for negligible gains, its
>> worth is highly questionable.
>
> I am aware of it, I have spent a lot of time making tools prelink compatible.
> But even compilers have very complex parts for negligible gains.
>
>
>> I just hope you are not saying that there is a doubt there are
>> disadvantages.
>
> I really have not yet seen any valid one.
>
>
>> The real question here is whether advantages supersede disadvantges, and
>> given the only advantage seem to be performance and it is lost in noise,
>
> I would not say it is lost in noise but let's say it is not big.

The definition of negligible (the word you keep using to describe the
performance benefits is:

"so small or unimportant as to be not worth considering; insignificant."

That is exactly the same as "lost in noise".

Perhaps you want to use some word other than negligible to describe
the performance benefits, because right now your argumentation is very
confusing.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Miloslav Trmač]

On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce  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
https://lists.fedoraproject.org/pipermail/devel/2013-April/181376.html
and following).
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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.


> your notebooks are running 24 hours a day?
> really?

OT: Yes, really.  I use it with remote display+keyboard as a workstation.


> and try what happens if there where some updates and prelink did
> not run before the next rkhunter startip -> you get alarm mails

This is a known prelink Bug:
-y has false mismatches
https://bugzilla.redhat.com/show_bug.cgi?id=666143

Just the evil Fedora Bugs autoclose has already closed it but it is still
valid.  I have provided even a single line fix there.


> there are people wich shut down or suspend machines when they are not in use
> how do you imagine the cronjob run while they are not in use for this
> *majority* of users?

These users really should uninstall prelink as they cannot use it.
BTW all my servers run 24x7.


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Simo Sorce]

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 away most of
> compilers and half of debuggers, which are all needlessly complex and prone to
> faults due to -O2.  Do we want to build simple system or good system?

This comparison makes no sense, and you know it.

If you want to negate others arguments so not to have to address them
suit yourself.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

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 provides stack guard value in global
>> variable and is used by existing runtime. Regression tests are
>> passing in glibc testsuite. Verified working. Upstream verified
>> that global variable is the best compromise for performance across
>> all 32-bit ARM targets (TLS will be too slow in the average case).
> 
> What's the effective difference in security between this and the 
> existing ports?

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 variable vs. 
DTV offset has only to do with the speed of access of the stack guard.

>> - Pointer mangling:
>>   - Not supported.
> 
> Do we ship it in the x86 ports?

We do.

>> Upstream glibc 2.19 summary:
>>
>> - Stack guard support already present using global variable.
>>
>> - Will have pointer encryption support using global variable, 
>>   and could be a candidate for backport to f20.
> 
> Cool. This is a runtime change, right? There's no requirement for a 
> rebuild to take advantage of it?

That is correct. It is only an internal glibc change that does not
require any rebuilds for applications to take advantage of this.
The pointer mangling is hidden from the application.

>> Do we need pointer mangling? If so then we need someone to file an
>> f20 specific bug so the glibc team can look at backporting the fix.
>> I won't commit to it until I review exactly what might need changing.
> 
> The aim was for parity of important features, but it doesn't seem like 
> we've ever advertised pointer guard as a Fedora feature so I'm not 
> personally that worried.

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.
https://bugzilla.redhat.com/show_bug.cgi?id=1019452

Cheers,
Carlos.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

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.
> https://bugzilla.redhat.com/show_bug.cgi?id=1019452

Great. Thanks, Carlos!

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Paul Wouters]

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 foot-bullets
- reduced alsr

Other people added:

- battery drain (i dont care if its cron or not, without prelink no
  drain)
- sluggish systems when prelink is updating
- additional ram use when logged in for a long time

So far you seem to say "those are not prelink bugs".

Just the FIPS issue for me (speaking as a member of the Red Hat Security
Group) is enough to say that if the gains are too small to measure, that
it's time for Ocam's Razor and not make our systems needlesly complex.

Furthermore, in the past I've indicated that we should have support for
systems booted in FIPS mode with fips=1, where though libraries and
programs that could not be prelinked should be unprelinked, as the
sysadmin specifically told us (via fips=1) that they value security over
speed gains)

prelink has served us in the past. It's time to let it go.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-1.fc21

[Paul Howarth]

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jakub Jelinek]

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 variable vs. 
> DTV offset has only to do with the speed of access of the stack guard.

DTV access is of course going to be expensive, after all, that is a function
call, the question was about reserving a word at fixed constant offset from
the TLS base and how expensive that is vs. global variable access.
For soft FP I guess global variable access must win, for -mtp=cp15
]it depends on how fast the mrc instruction is.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-1.fc20

[Paul Howarth]

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
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: prelink performance gains

[Reindl Harald]

Am 15.10.2013 20:04, schrieb Miloslav Trmač:
> On Tue, Oct 15, 2013 at 7:50 PM, Simo Sorce  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
> https://lists.fedoraproject.org/pipermail/devel/2013-April/181376.html
> and following).

try to understand what you read there

* update installed
* prelink doe *one time* randomization

until the next update/full prelink there is no randomization

because prelink a lot of binaries are not PIE code

* update
* reboot
* applications are running
* prelink does the one time randomization
* the apps are still running and not randomized at all





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 disadvantage is it?

have fun in distinct between prelink caused "needs-restarting" or real

>> * look at the wasted cycles of running prelink itself and compare to the gain
> 
> the cycles of prelink happen during night when nobody waits for anything.
> The gain happens when user waits until the program starts.

your notebooks are running 24 hours a day?
really?

>> in the past on notebooks i hated prelink and god bless the maintainer which
>> removed the prelink-require out of rkhunter which was pervert
>>
>> most of the time i noticed the weak performance while prelink ran
>> between that i got alarmed all the time by rkhunter-notifies
>> *because* i should prelink this and that file
> 
> Sorry I do not see how is rkhunter related and what is the disadvantage.

well, read what rkhunter does
it verifies file integrity
wonderful idea have a software default touching the binaries

and try what happens if there where some updates and prelink did
not run before the next rkhunter startip -> you get alarm mails

> If you mean that prelink ever runs while you sit at the computer then it is
> a bug in cron, not in prelink. /etc/cron.daily/mlocate has a similar problem

there are people wich shut down or suspend machines when they are not in use
how do you imagine the cronjob run while they are not in use for this
*majority* of users?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

Am 15.10.2013 19:54, schrieb Chris Adams:
> Once upon a time, Jan Kratochvil  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
>>
>> Sorry I do not see what disadvantage is it?
> 
> If you install updates, reboot, and log in, you are running
> non-prelinked binaries/libraries.  If you don't log out (just lock
> screen or suspend for example), when you next use the system after
> prelink has run, new programs will use the prelinked bins/libs.  Now you
> are wasting a chunk of RAM, as it can't be shared between non-prelinked
> and prelinked bins/libs

*and* because prelink is the reason *not* build a lot of packages
with position independent code because it can't be prelinked and
the excuse is that prelink itself does a little randomization
in the case you reboot after updates and login you have pretty
well *disabled ASLR at all* until re-login after prelink did
it's job

from security point of view prelink is nothing else than a
nightmare and it stands in the way get the whole distribution
hardened

for what gain?
for one where you can't make a distinct between prelink optimization
our typical noise on a multi-threaded operating system?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 with your finger somewhere else
the better way is solve the root cause

>> your notebooks are running 24 hours a day?
>> really?
> 
> OT: Yes, really.  I use it with remote display+keyboard as a workstation.

as i often enough heard here: the world is not turning around you

>> and try what happens if there where some updates and prelink did
>> not run before the next rkhunter startip -> you get alarm mails
> 
> This is a known prelink Bug:
>   -y has false mismatches
>   https://bugzilla.redhat.com/show_bug.cgi?id=666143
> 
> Just the evil Fedora Bugs autoclose has already closed it but it is still
> valid.  I have provided even a single line fix there.

you can always point with your finger somewhere else
the better way is solve the root cause

>> there are people wich shut down or suspend machines when they are not in use
>> how do you imagine the cronjob run while they are not in use for this
>> *majority* of users?
> 
> These users really should uninstall prelink as they cannot use it

if the majority should uninstall something because they can't
use it it must not be active in a default setup

> BTW all my servers run 24x7

and *there* you do *not* need prelink because the theoretical gain
in faster startup does *not matter*

so, and now come on and list some *real* benefits, stop to point
with your fingers how many people should fix these and and that
to work better with prelink, take the wasted time into account
if you consider the prelink-benefits and if you can't find
*really* good arguments stop to defeat prelink in the default
install and agree that it has to be removed from it

only the time wasted multiple times a year with discussions and
fixing this and that to work with prelink makes it's benefits
for gain 200 ms here and there non existent



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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
> compilers and half of debuggers, which are all needlessly complex and prone to
> faults due to -O2.  Do we want to build simple system or good system?

don't get me wrong but *please* take some security education because with
"-O0" https://fedoraproject.org/wiki/Security_Features?rd=Security/Features
would not work

*and* prelink works against ASLR

>> In general prelink makes things more complex for negligible gains, its
>> worth is highly questionable.
> 
> I am aware of it, I have spent a lot of time making tools prelink compatible.
> But even compilers have very complex parts for negligible gains.

and pointing with the finger somewhere and saying "there is someting bad"
makes bad things better? not in the reality!

>> I just hope you are not saying that there is a doubt there are
>> disadvantages.
> 
> I really have not yet seen any valid one.

no - you refused to understand them

>> The real question here is whether advantages supersede disadvantges, and
>> given the only advantage seem to be performance and it is lost in noise,
> 
> I would not say it is lost in noise but let's say it is not big

if benchmarks sometimes are faster without and sometimes with prelink
the only conlcusion is that it got lost in the noise



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Target Display Mode in Fedora

[Matthew Garrett]

On Tue, Oct 15, 2013 at 11:52:41AM -0600, Chris Murphy wrote:
> 
> On Oct 15, 2013, at 10:36 AM, Matthew Garrett  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 specific.
> 
> 
> Too bad. I wonder if this switching extension is being obfuscated from 
> reverse engineering with these "smart" cables Apple's producing.

I can't see how. It works fine without any kind of special cable.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

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 performance optimization. The choice of a global variable vs. 
>> DTV offset has only to do with the speed of access of the stack guard.
> 
> DTV access is of course going to be expensive, after all, that is a function
> call, the question was about reserving a word at fixed constant offset from
> the TLS base and how expensive that is vs. global variable access.
> For soft FP I guess global variable access must win, for -mtp=cp15
> ]it depends on how fast the mrc instruction is.

I talk about DTV, but I should really just say constant offset from TP
since that's what I mean. I don't actually mean using a TLS variable.

Will Newton tested the global variable access code on soft and hard TP
configurations and to quote some initial discussions:
https://sourceware.org/ml/libc-ports/2013-09/msg00134.html
~~~
From a back of the envelope calculation the cost of accessing TLS is
one cycle faster than accessing a global in best case (e.g.
Cortex-A15), considerably slower in common case (50-60 cycles,
Cortex-A9) and slower still in worst case (function call to libgcc and
the kernel, ARMv4/ARMv5).
~~~
Therefore for 32-bit ARM it was decided that a global variable was the
best choice.

For AArch64 it will definitely be a reserved word at a constant offset
from the TP since that's going to be fastest.

Does that clarify things?

Cheers,
Carlos.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 else
> the better way is solve the root cause

The root cause is really the update system.  Why should I look for what daemon
to restart by hand?  It should happen automatically, it is even a security
hole if nightly yum updates a daemon but its old version remains running.
IIRC it is some systemd feature in development but I cannot find it now.

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.


> > This is a known prelink Bug:
> > -y has false mismatches
> > https://bugzilla.redhat.com/show_bug.cgi?id=666143
> > 
> > Just the evil Fedora Bugs autoclose has already closed it but it is still
> > valid.  I have provided even a single line fix there.
> 
> you can always point with your finger somewhere else
> the better way is solve the root cause

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.


> >> there are people wich shut down or suspend machines when they are not in 
> >> use
> >> how do you imagine the cronjob run while they are not in use for this
> >> *majority* of users?
> > 
> > These users really should uninstall prelink as they cannot use it
> 
> if the majority should uninstall something because they can't
> use it it must not be active in a default setup

If the majority of Fedora users then yes.  IMO Fedora is more used on servers
but I really do not know the user base.


> > BTW all my servers run 24x7
> 
> and *there* you do *not* need prelink because the theoretical gain
> in faster startup does *not matter*

It does matter, I run even large builds there, regression testing, besides
that even web server CGIs benefit from it.  "server" is a wide term.


> so, and now come on and list some *real* benefits,

Improved performance.


> take the wasted time into account

If you find software development of performance features a wasted time then
I see it really does not make sense to discuss it more.


> stop to defeat prelink in the default
> install and agree that it has to be removed from it

I do not say anything about prelink in the default install as I have no idea
what is the default Fedora user.  But it is a useful feature at least on
servers and 24x7 running workstations.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 feature.  That -O2 vs. -O0 build is a good comparison.


> - FIPS foot-bullets

I really do not care and do not run FIPS.  Disable/uninstall prelink for FIPS.


> - reduced alsr

I do not know the details but the network facing daemons are already PIE while
most of the binaries - those not facing untrusted data - have no use for PIE.


> Other people added:
> 
> - battery drain (i dont care if its cron or not, without prelink no
>   drain)
> - sluggish systems when prelink is updating

This is a bug in cron and/or people not running 24x7 machine should not use
prelink at all.


> - additional ram use when logged in for a long time

Answered in:
https://lists.fedoraproject.org/pipermail/devel/2013-October/190237.html


> So far you seem to say "those are not prelink bugs".

True.


> Just the FIPS issue for me

That's for you but majority of Fedora users do not run in FIPS mode.


> Furthermore, in the past I've indicated that we should have support for
> systems booted in FIPS mode with fips=1, where though libraries and
> programs that could not be prelinked should be unprelinked, as the
> sysadmin specifically told us (via fips=1) that they value security over
> speed gains)

OK, great, so unprelink the programs.


> prelink has served us in the past. It's time to let it go.

People continually give up on software performance with better hardware.
64-bit systems nowadays run commonly slower than did the 8-bits in 1980s.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Chris Adams]

Once upon a time, Jan Kratochvil  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.  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 the added complexity, overhead, etc. of
prelink.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[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 that's the case,
> than _any_ effort is not worth the added complexity, overhead, etc. of
> prelink.

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

The complexity may affect software development but it should not affect end
users.  End users then can benefit from the increased performance.

Here both developers want to avoid any increased software complexity and also
in some cases users suffer due to some lasting bugs (such as the cron issue).


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Chris Adams]

Once upon a time, Jan Kratochvil  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 reasonable unit of
time (or ever)?  Please stop using bogus comparisons and highly
contrived tests.  They do nothing to help your argument.

The biggest (real world) gain for prelink was always in the large
applications that link many libraries, such as LibreOffice.  The start
of this thread said that tests showed no significant gain anymore, at
least in the poster's setup.  If that is indeed the case, then there's
no reason to keep prelink.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 else
>> the better way is solve the root cause
> 
> The root cause is really the update system.  Why should I look for what daemon
> to restart by hand?  It should happen automatically, it is even a security
> hole if nightly yum updates a daemon but its old version remains running.
> IIRC it is some systemd feature in development but I cannot find it now.

*you need to restart no-PIE binaries after prelink because otherwise no ASLR*

> 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.

no

>>> This is a known prelink Bug:
>>> -y has false mismatches
>>> https://bugzilla.redhat.com/show_bug.cgi?id=666143
>>>
>>> Just the evil Fedora Bugs autoclose has already closed it but it is still
>>> valid.  I have provided even a single line fix there.
>>
>> you can always point with your finger somewhere else
>> the better way is solve the root cause
> 
> 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.

*stop trolling*

 there are people wich shut down or suspend machines when they are not in 
 use
 how do you imagine the cronjob run while they are not in use for this
 *majority* of users?
>>>
>>> These users really should uninstall prelink as they cannot use it
>>
>> if the majority should uninstall something because they can't
>> use it it must not be active in a default setup
> 
> If the majority of Fedora users then yes.  IMO Fedora is more used on servers
> but I really do not know the user base.

*lol* Fedora != RHEL/CentOS and that said from one running
Fedora in production *but* i am aware that i am *not*
the majority in that case

>>> BTW all my servers run 24x7
>>
>> and *there* you do *not* need prelink because the theoretical gain
>> in faster startup does *not matter*
> 
> It does matter, I run even large builds there, regression testing, besides
> that even web server CGIs benefit from it.  "server" is a wide term.

come on where the numbers?

>> so, and now come on and list some *real* benefits,
> 
> Improved performance.

come on where the numbers?

>> take the wasted time into account
> 
> If you find software development of performance features a wasted time then
> I see it really does not make sense to discuss it more.

come on where the numbers of the better performance?

>> stop to defeat prelink in the default
>> install and agree that it has to be removed from it
> 
> I do not say anything about prelink in the default install as I have no idea
> what is the default Fedora user.  

*this topic is about have prelink by default installed*

> But it is a useful feature at least on
> servers and 24x7 running workstations

yeah, where you update, reboot, login and start your Firefox
with no ASLR which runs after that 2,3,4,5 days - oh my god
what a nonsense to think the 200 ms at startup of the browser
is worth the time to defeat it

*you have no ASLR at all* in such situations because the
on-time-randomize happens after you started your browser
which keeps running

don't get me wrong but honestly i doubt you are the right person to
discuss such technical stuff



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 feature.  That -O2 vs. -O0 build is a good comparison.

this is just trolling

>> - FIPS foot-bullets
> I really do not care and do not run FIPS.  Disable/uninstall prelink for FIPS.

i do not care about prelink
enable/install prelink

>> - reduced alsr
> 
> I do not know the details but the network facing daemons are already PIE while
> most of the binaries - those not facing untrusted data - have no use for PIE.

ASLR is about *untsrusted input data*

you *really* think your browser, office, pdf-reader does not act
with untrusted input or if that is the case this is representative
for the userbase?

without ASLR and prelink which is the reason not build PIE and start
Firefox directly after updates you have *no randomization at all*

if you think that does not matter why do you think ASLR exists

>> So far you seem to say "those are not prelink bugs".
> 
> True.

*where are the numbers* proving the benfits?
"it's faster" and "it's for performance" are no numbers
if you defeat something *prove* why or be quiet
anything else is *trolling*

>> Just the FIPS issue for me
> 
> That's for you but majority of Fedora users do not run in FIPS mode.

the majority of Fedora users does not care about prelink
as well becaus ethey have it only installe dbecause it's
default and the performance improvement is *not* that
large these days *until you prove* it isa

>> Furthermore, in the past I've indicated that we should have support for
>> systems booted in FIPS mode with fips=1, where though libraries and
>> programs that could not be prelinked should be unprelinked, as the
>> sysadmin specifically told us (via fips=1) that they value security over
>> speed gains)
> 
> OK, great, so unprelink the programs.

OK, great, don't prelink them without a user decided to do so

>> prelink has served us in the past. It's time to let it go.
> 
> People continually give up on software performance with better hardware.
> 64-bit systems nowadays run commonly slower than did the 8-bits in 1980s

*prove the performance benfit with numbers*
only repeat the same again and agin does not make it the truth

BTW:
64Bit systems these days are in most cases *faster* because
software can use CPU capabilities which did not exist not
long ago and some of them are only available in 64bit mode



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

Am 15.10.2013 20:54, schrieb Chris Adams:
> Once upon a time, Jan Kratochvil  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.  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 the added complexity, overhead, etc. of
> prelink

forget it - he is just trolling and not interested ina technical
discussion or numbers proving the gain of prelink

otherwise he would prove it or if he can't do so stop defeat
prelink because in case of no significant gain it's pretty
clear that prelink should no longer be in the default install

besides negative impact because: *any* running code with out
a real beenfit is *bad* for maintainence and security reasons

period



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Reindl Harald]

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 that's the case,
>> than _any_ effort is not worth the added complexity, overhead, etc. of
>> prelink.
> 
> 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 numbers?
prove it!

and after that start your brain and compare that numbers with
the battery wasted by prelinking itself, consider how realistic
it is that you start 1000 times a large application which benefits
from prelink until it get the next update

and *no* don#t come again with "but CGI"
nobody but you is running CGI these days
anybody but you is using fast-cgi which does not fire up a new
process for each request and so prelink is out of the game



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sunday 13th of October: SSD cache test day

[Rolf Fokkens]

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 mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Jan Kratochvil]

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 numbers?
> prove it!

33% is the number.  It was 2.848s vs. 4.291s, that is 33.63%.


> and after that start your brain and compare that numbers with
> the battery wasted by prelinking itself,

prelinking never runs on battery, or it is a bug if it does.
At least I run notebook 24x7 on AC and only occasionally I take it out with
battery, then prelink works perfectly for me as I have described it.


> nobody but you is running CGI these days
> anybody but you is using fast-cgi

OT: I use mod_perl for majority of my web code.


Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Wednesday's FESCo Meeting (2013-10-15)

[Stephen Gallagher]

-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 '-MM-DD HH:MM UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1164 F20 Changes - Progress on Changes Freeze
.fesco 1164
https://fedorahosted.org/fesco/ticket/1164

#topic #1166 F20 System Wide Change: Migrate to Bluez 5 -
https://fedoraproject.org/wiki/Changes/Bluez5
.fesco 1166
https://fedorahosted.org/fesco/ticket/1166

#topic #1170 Working Group call for Volunteers
.fesco 1170
https://fedorahosted.org/fesco/ticket/1170

= New business =

#topic #1181 Fedora still vulnerable to BEAST
.fesco 1181
https://fedorahosted.org/fesco/ticket/1181

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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. Note that added topics may be deferred until
the following meeting.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJdlTUACgkQeiVVYja6o6P2rACghfZjrdfFZvJvTR0RoCw/cvhl
HRAAn1kX8CvSbGbUnxT0GOEgB/PTFuGn
=NowH
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: prelink performance gains

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> I say we should remove it from the standard comps group thus making
> it optional to install for people that see some benefit in still
> using it.

I'd actually suggest that prelink be an all-or-nothing.  If it isn't in
the default install, support for it in the other things that interact
with it will bit-rot (and maintainers will have little incentive to fix
problems).

If it isn't in the default install, it should probably just be removed
from the distribution.  If it improves performance noticably, then keep
it; if it doesn't, why should it be kept at all?  It has non-zero
support cost outside of the package itself.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct