Re: Changes in Java packaging guidelines - RFC
On 11/02/2010 05:11 PM, Ville Skyttä wrote:
> On Tuesday 02 November 2010, Stanislav Ochotnicky wrote:
>> Java SIG has prepared changes in current Java packaging guidelines. We
>> would welcome wider discussion/comments at this point. From our point of
>> view guidelines seem ready for approval by FPC.
>>
>> You can see current version of draft here:
>> https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
>>
>> Changes from current guidelines here:
>> http://bit.ly/dy3YDe
>>
>> Comments are most welcome!
>
> These aren't necessarily comments to the changes, but some long standing
> issues with Fedora java packaging that I'd like to see fixed (ditto JPackage
> where these are inherited I believe - I was a member of that project for a
> long time and already back then had this opinion).
>
> I'd get rid of the versioned javadoc dir altogether, and simply install to
> %{_javadocdir}/%{name}. Unversioned is good for bookmarking and javadoc
> crosslinking.
>
> Same thing for jars, I'd just install the jar(s) unversioned (i.e. not put
> %{version} everywhere - major version can go there if several versions are
> needed like let's say foo.jar and foo2.jar).
>
> I think the versioned jars and javadoc dirs are quite pointless. If the
> intent is to make it possible to co-install several versions, the unversioned
> symlinks either need to be owned by each package (thus preventing co-
> installation due to file conflicts) or be left out altogether (which makes it
> a PITA to use the jars and javadoc dirs) or be left out from some packages
> (which eliminates the benefit of the unversioned symlink or necessitates file
> dependencies).
Ticket with FPC has been filed.
https://fedorahosted.org/fpc/ticket/24
FYI the versionless jar/javadocs files are now in the draft (thanks for
the suggestion, somehow none of us thought of that)
But keep those comments coming, we'll try to keep working on the
guidelines to reflect current needs of packagers.
--
Stanislav Ochotnicky
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101103 changes
Compose started at Wed Nov 3 08:15:18 UTC 2010 Broken deps for x86_64 -- 1:anjuta-2.31.90.0-3.fc15.i686 requires libvala-0.10.so.0 1:anjuta-2.31.90.0-3.fc15.x86_64 requires libvala-0.10.so.0()(64bit) apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel >= 0:2.91 gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) hugin-2010.0.0-5.fc15.x86_64 requires libpano13.so.1()(64bit) hugin-base-2010.0.0-5.fc15.i686 requires libpano13.so.1 hugin-base-2010.0.0-5.fc15.x86_64 requires libpano13.so.1()(64bit) 6:kdelibs-4.5.3-1.fc15.i686 requires oxygen-icon-theme >= 0:4.5.3 6:kdelibs-4.5.3-1.fc15.x86_64 requires oxygen-icon-theme >= 0:4.5.3 log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 nagios-plugins-snmp-disk-proc-1.2-6.fc13.x86_64 requires libnetsnmp.so.20()(64bit) 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 nut-2.4.3-7.fc15.x86_64 requires libnetsnmp.so.20()(64bit) openhpi-2.14.1-3.fc14.x86_64 requires libnetsnmp.so.20()(64bit) openhpi-libs-2.14.1-3.fc14.i686 requires libnetsnmp.so.20 openhpi-libs-2.14.1-3.fc14.x86_64 requires libnetsnmp.so.20()(64bit) openhpi-subagent-2.3.4-13.fc14.x86_64 requires libn
Java SIG meeting minutes (November 3rd)
People present:
* orionp
* cspike
* hannes
* sochotni
* mbooth
* ggraz
* tibbs
Overview:
* Maven 3 status
* Maven 3 vanilla package review:
https://bugzilla.redhat.com/show_bug.cgi?id=648945
* Custom resolver based on resolver for m2
* http://sochotni.fedorapeople.org/0003-Use-custom-resolver.patch
* http://sochotni.fedorapeople.org/maven-javadir-resolver
* Maven 3 in jpp mode is already working for some packages
* Java SIG monitored packages
* tibbs created pseudo user for us with email set to java-devel ml
* Need to figure out a way to get email to java-devel ml (closed ML)
* Packaging guidelines
* We'll drop %{version} from jars and javadocs
* Guidelines seem good and should be submitted for FPC review/vote
* New meeting time vote will be decided by a vote
* http://www.makeavote.net/mavsta13768.html
* Jakarta commons rename
* One last package needs to be retired by devrim
* Open floor
* Check old java package reviews/merge reviews
===
#fedora-meeting: Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
===
Meeting started by sochotni at 17:25:55 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2010-11-02/java-sig.2010-11-02-17.25.log.html
.
Meeting summary
---
* roll-call (sochotni, 17:26:16)
* orionp cspike hannes| sochotni present (sochotni, 17:26:30)
* mbooth present as well (sochotni, 17:26:58)
* Maven-3 (sochotni, 17:27:24)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=648945 Maven 3
review (sochotni, 17:28:32)
* LINK:
http://sochotni.fedorapeople.org/0003-Use-custom-resolver.patch
current version of the patch needed to use custom resolver
(sochotni, 17:30:24)
* LINK: http://sochotni.fedorapeople.org/maven-javadir-resolver custom
java resolver (sochotni, 17:36:13)
* Currently several apps compile in mvn3 "jpp" mode. (sochotni,
17:38:44)
* Java packages to be monitored by the SIG (sochotni, 17:42:44)
* Package list in good shape akurtakov can go ahead and ask for
java-sig user (sochotni, 17:47:07)
* Java Packaging guidelines (sochotni, 17:47:16)
* ACTION: sochotni will update Packaging draft with versionless jar
filenames (sochotni, 17:58:21)
* ACTION: sochotni file FPC ticket for new draft approval once
versionless things are in place (sochotni, 18:06:07)
* Change of meeting time (sochotni, 18:13:28)
* ACTION: sochotni will re-create voting for change of meeting time
and post separate thread to java-devel (sochotni, 18:16:26)
* ACTION: orionp akurtakov_ mbooth hannes| cspike will vote :-)
(sochotni, 18:16:42)
* open floor (sochotni, 18:17:06)
* ACTION: all: look at merge reviews (sochotni, 18:22:48)
* ACTION: sochotni contact java-devel list admin and figure out a way
for our pseudouser get mail (sochotni, 18:30:47)
Meeting ended at 18:31:21 UTC.
Action Items
* sochotni will update Packaging draft with versionless jar filenames
* sochotni file FPC ticket for new draft approval once versionless
things are in place
* sochotni will re-create voting for change of meeting time and post
separate thread to java-devel
* orionp akurtakov_ mbooth hannes| cspike will vote :-)
* all: look at merge reviews
* sochotni contact java-devel list admin and figure out a way for our
pseudouser get mail
Action Items, by person
---
* cspike
* orionp akurtakov_ mbooth hannes| cspike will vote :-)
* hannes|
* orionp akurtakov_ mbooth hannes| cspike will vote :-)
* mbooth
* orionp akurtakov_ mbooth hannes| cspike will vote :-)
* orionp
* orionp akurtakov_ mbooth hannes| cspike will vote :-)
* sochotni
* sochotni will update Packaging draft with versionless jar filenames
* sochotni file FPC ticket for new draft approval once versionless
things are in place
* sochotni will re-create voting for change of meeting time and post
separate thread to java-devel
* sochotni contact java-devel list admin and figure out a way for our
pseudouser get mail
* **UNASSIGNED**
* all: look at merge reviews
People Present (lines said)
---
* sochotni (144)
* cspike (39)
* tibbs (30)
* mbooth (17)
* zodbot (4)
* orionp (2)
* ggraz (2)
* hannes| (1)
--
Stanislav Ochotnicky
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: coming libnotify bump
On Mon, 2010-11-01 at 21:12 -0400, Matthias Clasen wrote: > I am planning to push libnotify 0.7.0 into rawhide by the end of this > week; this is going to be a little painful, since there are some api > changes that will require minor adjustment of all users. And there's > quite a few of them (see below). I will hopefully be able to handle most > of the GNOME dependencies, for the rest I need to ask for some help. I have built libnotify 0.7.0 in rawhide now. I have filed a number of patches for affected modules, and I am going through some rebuilds now. If your module uses libnotify or notify-python, please check if it needs changes to work with the new libnotify. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
No koji repo for F14 yet?
http://koji.fedoraproject.org/static-repos/ is missing dist-f14-build-current ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Try-Tiny] Created tag perl-Try-Tiny-0.07-1.el5
The lightweight tag 'perl-Try-Tiny-0.07-1.el5' was created pointing to: 505f548... Update to 0.07 -- 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 649372] New: Dependency on perl-libwww-perl missing
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Dependency on perl-libwww-perl missing https://bugzilla.redhat.com/show_bug.cgi?id=649372 Summary: Dependency on perl-libwww-perl missing Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: medium Component: perl-SOAP-Lite AssignedTo: mmcgr...@redhat.com ReportedBy: packa...@amiga-hardware.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmcgr...@redhat.com Classification: Fedora Description of problem: perl-SOAP-Lite should have a dependency on perl-libwww-perl, otherwise you can't connect to a remote web service. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Cannot connect to a remote web service using perl-SOAP-Lite unless perl-libwww-perl is also installed Expected results: Should be able to connect Additional info: This doesn't just affect F14 but also F13 and probably earlier. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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-Try-Tiny] Created tag perl-Try-Tiny-0.07-1.el4
The lightweight tag 'perl-Try-Tiny-0.07-1.el4' was created pointing to: 505f548... Update to 0.07 -- 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: Directory unowned.
On Tue, 02 Nov 2010 14:45:48 +0300, Dmitrij S. Kryzhevich wrote:
> Hi!
> %{_libdir}/girepositry-1.0/ is not owned by any package. It is used,
> i.e., in DeviceKit-power-devel. Dmitrij.
On F-14 it's owned by multiple packages:
$ rpm -qf /usr/lib64/girepository-1.0/
atk-1.32.0-1.fc14.x86_64
gdk-pixbuf2-2.22.0-1.fc14.x86_64
gobject-introspection-0.9.3-1.fc14.x86_64
GConf2-2.31.91-1.fc14.x86_64
gtk2-2.22.0-1.fc14.1.x86_64
gtk3-2.90.5-1.fc14.x86_64
seahorse-2.32.0-1.fc14.x86_64
which looks fine to me, as none of those packages depend on gobject-
introspection themselves (looks like the bash-completion case). If we
ever end up with a gnome-filesystem package, this will be a good
candidate to move there, though.
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: sali...@fedoraproject.org | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 584929] Column sort in html gui doesn't work properly
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=584929 --- Comment #3 from Bug Zapper 2010-11-03 12:33:25 EDT --- This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: No koji repo for F14 yet?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2010 09:21 AM, Richard W.M. Jones wrote: > > http://koji.fedoraproject.org/static-repos/ > > is missing dist-f14-build-current ... > > Rich. > This path is deprecated. http://kojipkgs.fedoraproject.org/repos/dist-f14-build/latest/ Koji now supports creating a "latest" symlink for every repo it generates, so we no longer have to do it external to koji. Replace "dist-f14-build" with any other repo you wish to track. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzRkwwACgkQ4v2HLvE71NXHiACfdiXGDfScNCs0TvtpUu3mY3jl xsIAoIjJdCi6c4wrUdyAYdBkvO45IDu5 =g4Aw -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
On Wednesday 03 November 2010, Stanislav Ochotnicky wrote: > FYI the versionless jar/javadocs files are now in the draft (thanks for > the suggestion, somehow none of us thought of that) Thanks for considering it. > But keep those comments coming, we'll try to keep working on the > guidelines to reflect current needs of packagers. Some other things off the top of my head, in no particular order: 1) I'd like to see crosslinking of javadocs at least a SHOULD, and I wouldn't mind a MUST at all. I'm also leaning towards making it a MUST for javadoc packages that crosslink with other javadoc packages require the ones they crosslink with. 2) Regarding wrapper scripts, I'd like to point out the %jpackage_script macro for creating them. Here's one example of it in action: https://bugzilla.redhat.com/attachment.cgi?id=457277 Also, most invocations of it will want to set the last argument of it to true (such as in the example above) to make jpackage-utils stuff prefer a JRE over a full Java SDK (assuming of course that they work with just a JRE installed and don't require the full SDK) to avoid problems like these: https://bugzilla.redhat.com/show_bug.cgi?id=461683 https://bugzilla.redhat.com/show_bug.cgi?id=498831 3) In my opinion, the whole alternatives setup in the JRE and SDK packages should be purged. It's a relic from times that are long gone, and at the moment causes just complexity and possibilities for breakage; it kind of even encourages breakage by giving people the option to easily switch between _incompatible_ java implementations (e.g. versions) for the system default Java, breaking programs' expectations. environment-modules would sound like a more appropriate solution for switching the Java implementation when needed. I'm not holding my breath for this to happen too soon, but hope that it sometime will. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 649418] New: perl-Lingua-EN-Tagger-debuginfo is empty
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Lingua-EN-Tagger-debuginfo is empty https://bugzilla.redhat.com/show_bug.cgi?id=649418 Summary: perl-Lingua-EN-Tagger-debuginfo is empty Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: perl-Lingua-EN-Tagger AssignedTo: iarn...@gmail.com ReportedBy: ville.sky...@iki.fi QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Blocks: 496968 Classification: Fedora Probably the debuginfo package should be explicitly disabled here, see blocker bug for more info. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Plan for tomorrow's FESCo meeting (2010-11-03)
On Tue, 02 Nov 2010 17:45:16 -0400 Adam Jackson wrote: > On Tue, 2010-11-02 at 14:30 -0600, Kevin Fenzi wrote: > > Following is the list of topics that will be discussed in the FESCo > > meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on > > irc.freenode.net. > > > > NOTE: Matthew Garrett, Steven Parrish, Bill Nottingham and Matthias > > Clasen are all unable to attend this week. > > And me. Since we had almost no one around, I just closed up the meeting for this week. == #fedora-meeting: FESCO (2010-11-03) === Meeting started by nirik at 18:30:25 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-11-03/fesco.2010-11-03-18.30.log.html Meeting summary --- * init process (nirik, 18:30:26) * no quorum, will meet next week (nirik, 18:34:28) Meeting ended at 18:35:11 UTC. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Compile with -fno-omit-frame-pointer on x86_64?
Lack of decent profiling is a major problem for making our operating system fast. By far the most effective of profiling is sampling profile with callgraph information. Soeren's comment from March: http://lwn.net/Articles/380582/ Basically summarizes the situation, and as far as I know nothing has changed ... with default compilation options, getting callgraph profiling on x86_64 really requires a DWARF unwinder in the kernel. Which seems unlikely to happen. As a developer, your options for profiling are: - Recompile everything you care about profiling with -fno-omit-frame-pointer instead of using system packages. - Switch to i386 Even if the second was reasonable to ask of developers, it also makes it really hard to help users with performance problems if they have to reinstall their system to give you a profile. So, I'd like to bring up the possibility of switching to compiling our packages with -fno-omit-frame-pointer for x86_64. As Soeren says, x86_64 isn't register starved, so the performance penalty shouldn't be huge. But I have no idea if it's 0.5% or 5%. What aspects of performance do we care about? How would we measure the performance impact of changing compilation flags? What is the acceptable slowdown? - Owen (One downside of any slowdown is that if we take a 1% hit and do performance work that makes the system 10% faster, then we look bad by comparison with other Linux distributions who get the advantages of the performance work but don't take the 1% hit. Still, we should do what has the biggest net gain for our users, right?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: > Lack of decent profiling is a major problem for making our operating > system fast. By far the most effective of profiling is sampling profile > with callgraph information. > > Soeren's comment from March: > > http://lwn.net/Articles/380582/ > > Basically summarizes the situation, and as far as I know nothing has > changed ... with default compilation options, getting callgraph > profiling on x86_64 really requires a DWARF unwinder in the kernel. > Which seems unlikely to happen. But that's the right thing to do. > As a developer, your options for profiling are: > > - Recompile everything you care about profiling >with -fno-omit-frame-pointer instead of using system packages. Instead of this, which really is a big performance penalty. Even i?86 is changing in GCC 4.6 to not do -fno-omit-frame-pointer by default. The unwind info recent GCCs provide is correct even in epilogues and can be relied upon. There are several lightweight unwinders that can be easily adapted for kernel purposes. Just talk to the systemtap folks. There is always callgrind if you don't want to recompile anything and need to profile something even when kernel doesn't support it. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 567282] server can not abandon searchRequest of "simple paged results"
https://bugzilla.redhat.com/show_bug.cgi?id=567282 https://bugzilla.redhat.com/attachment.cgi?id=457550&action=edit https://bugzilla.redhat.com/attachment.cgi?id=457550&action=diff Description: Simple Paged Results search keeps the connection per paging, but not an operation. When an abandon request is issued, the operation referred by the request has already finished. This patch introduces pagedresults_cleanup function to check whether the connection is for the simple paged results or not, and if it is, the simple paged results is cleaned up. If it is not, pagedresults_cleanup does nothing. The function is called from do_abandon as well as from connection_cleanup. Files: ldap/servers/slapd/abandon.c ldap/servers/slapd/connection.c ldap/servers/slapd/opshared.c ldap/servers/slapd/pagedresults.c ldap/servers/slapd/proto-slap.h Thanks, --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Changes in Java packaging guidelines - RFC
Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit : > 3) In my opinion, the whole alternatives setup in the JRE and SDK packages > should be purged. It's a relic from times that are long gone, Having a semi-sane way to install multi-vendor multi-version JVMs is still needed EPEL side. Expensive apps like SAP still make you install the specific JVM they've been qualified against. Please do not add Fedora/RHEL fragmentation to the ongoing Fedora/JPackage fragmentation. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: > On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: > > Lack of decent profiling is a major problem for making our operating > > system fast. By far the most effective of profiling is sampling profile > > with callgraph information. > > > > Soeren's comment from March: > > > > http://lwn.net/Articles/380582/ > > > > Basically summarizes the situation, and as far as I know nothing has > > changed ... with default compilation options, getting callgraph > > profiling on x86_64 really requires a DWARF unwinder in the kernel. > > Which seems unlikely to happen. > > But that's the right thing to do. > > > As a developer, your options for profiling are: > > > > - Recompile everything you care about profiling > >with -fno-omit-frame-pointer instead of using system packages. > > Instead of this, which really is a big performance penalty. Do you have a sense of the quantification of "big" here? I know in compiler terms, 1% is big, but we're no where close to wringing the last 1% out of overall Fedora performance. If you create a sufficiently complex system, there's lots of "stupid" stuff going on. And you can't find the stupid stuff without appropriate tools. > Even i?86 is > changing in GCC 4.6 to not do -fno-omit-frame-pointer by default. > The unwind info recent GCCs provide is correct even in epilogues and can be > relied upon. There are several lightweight unwinders that can be easily > adapted for kernel purposes. Just talk to the systemtap folks. It seems like if it was that easy, it would have happened and we'd have a solution in the upstream kernel... (One thing that definitely makes things tricky is paging in debuginfo. I think I saw a discussion somewhere that systemtap preemptively was paging in all debuginfo for traced modules. That's tricky in systemwide profiling situations, but maybe you could have something where you do one run, load the debuginfo for everything that was hit in the first run, then do a second run.) > There is always callgrind if you don't want to recompile anything and > need to profile something even when kernel doesn't support it. callgrind is reasonable if you a single program that is slow and where the slowness is pretty much straightup CPU. But we're seldom trying to profile "a program" - we are trying to profile system situations that involve several programs and the kernel. And programs are frequently not straight-up bound on things that valgrind can easily model. For example, if our program is reading from uncached graphics memory somewhere, that won't show up at all in callgrind - to callgrind, it's just memory reads. But it may dominate a more accurate sampled profile. Plus the performance hit of callgrind makes it not very useful for real-time interactive user interface. - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 03:20:59PM -0400, Owen Taylor wrote: > On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: > > On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: > > Instead of this, which really is a big performance penalty. > > Do you have a sense of the quantification of "big" here? I know in > compiler terms, 1% is big, but we're no where close to wringing the last > 1% out of overall Fedora performance. If you create a sufficiently > complex system, there's lots of "stupid" stuff going on. And you can't > find the stupid stuff without appropriate tools. The last numbers I was pointed at for x86_64 were 4% slowdown, which really is a lot and it takes several years to achieve that improvement on the compiler side. > It seems like if it was that easy, it would have happened and we'd have > a solution in the upstream kernel... I think we had one in the upstream kernel for some time, then Linus just didn't like to see it needing too many bugfixes needed for it and nuked it. > (One thing that definitely makes things tricky is paging in debuginfo. I > think I saw a discussion somewhere that systemtap preemptively was > paging in all debuginfo for traced modules. That's tricky in systemwide Yeah, systemtap does that (and has that in kernel unwinder for userspace). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
> On Wednesday 03 November 2010, Ville Skyttä wrote: > > On Wednesday 03 November 2010, Stanislav Ochotnicky wrote: > > FYI the versionless jar/javadocs files are now in the draft (thanks for > > the suggestion, somehow none of us thought of that) > > Thanks for considering it. > > > But keep those comments coming, we'll try to keep working on the > > guidelines to reflect current needs of packagers. > > Some other things off the top of my head, in no particular order: > > 1) I'd like to see crosslinking of javadocs at least a SHOULD, and I > wouldn't mind a MUST at all. I'm also leaning towards making it a MUST > for javadoc packages that crosslink with other javadoc packages require > the ones they crosslink with. > There is no sane way to make javadoc crosslink in a sane way, i.e. without patching builds. That's why I would say let's postpone this until we can tell packagers HOWTO do it. > 2) Regarding wrapper scripts, I'd like to point out the %jpackage_script > macro for creating them. Here's one example of it in action: > https://bugzilla.redhat.com/attachment.cgi?id=457277 > Also, most invocations of it will want to set the last argument of it to > true (such as in the example above) to make jpackage-utils stuff prefer a > JRE over a full Java SDK (assuming of course that they work with just a > JRE installed and don't require the full SDK) to avoid problems like > these: > https://bugzilla.redhat.com/show_bug.cgi?id=461683 > https://bugzilla.redhat.com/show_bug.cgi?id=498831 I didn't know about this macro. We should definitely document it on the wiki and add it as tip to the guidelines. > > 3) In my opinion, the whole alternatives setup in the JRE and SDK packages > should be purged. It's a relic from times that are long gone, and at the > moment causes just complexity and possibilities for breakage; it kind of > even encourages breakage by giving people the option to easily switch > between _incompatible_ java implementations (e.g. versions) for the system > default Java, breaking programs' expectations. environment-modules would > sound like a more appropriate solution for switching the Java > implementation when needed. I'm not holding my breath for this to happen > too soon, but hope that it sometime will. There are other way more important things to fix and being able to switch java is still usable in a number of cases (despite the problems it causes). Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
On Wednesday 03 November 2010, Nicolas Mailhot wrote: > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit : > > 3) In my opinion, the whole alternatives setup in the JRE and SDK > > packages should be purged. It's a relic from times that are long gone, > > Having a semi-sane way to install multi-vendor multi-version JVMs is > still needed EPEL side. Expensive apps like SAP still make you install > the specific JVM they've been qualified against. But such JVMs do not need to be made the system default at all, people can just run $expensive_app with it by whatever means they like (e.g. direct modification of $PATH, $JAVA_HOME, etc _for that specific app_). Providing an easy way for admins to alter the system default JVM to something which will break expectations of software _we_ ship (in Fedora or EPEL) just doesn't make sense to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 574195] AMAVISD_DB_HOME in amavisd-agent has wrong default
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=574195 --- Comment #1 from Bug Zapper 2010-11-03 15:28:44 EDT --- This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Changes in Java packaging guidelines - RFC
Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit : > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit : > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK > > > packages should be purged. It's a relic from times that are long gone, > > > > Having a semi-sane way to install multi-vendor multi-version JVMs is > > still needed EPEL side. Expensive apps like SAP still make you install > > the specific JVM they've been qualified against. > > But such JVMs do not need to be made the system default at all, people can > just run $expensive_app with it by whatever means they like (e.g. direct > modification of $PATH, $JAVA_HOME, etc _for that specific app_). When you pass a certain level of expensiveness, ISVs just assume the *only* jvm on the system will be the one they require (quite simply the software price is many times the price of hardware, so there is no reason to share the hardware with anything else). It never ceases to astonish me how software “giants” have come to depend on the quick and dirty hacks we did JPackage-side æons agos, and never thought of redirecting some of their huge cash flow to fund something a little more robust. Then again, given how it would have likely ended (lsb, foo-grade linux), maybe it's better that way. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On 11/03/2010 11:48 AM, Owen Taylor wrote: > Lack of decent profiling is a major problem for making our operating > system fast. By far the most effective of profiling is sampling profile > with callgraph information. I am the author of tsprof, http://bitwagon.com/tsprof/tsprof.html . Eight years ago that app provided everything you desire, and with no compilation flags necessary: not -pg, not -p. [The implementation is equivalent to "infecting the memory image of the application with a profiling virus" and it was at process entry in just a couple seconds.] But nobody would pay for it on i686, so the product was abandoned despite a working prototype for x86_64. A few years before that, there was TracePoint Technology, a startup funded by venture capital that offered nifty profiling tools: http://venturebeatprofiles.com/company/profile/tracepoint-technology Soon they were acquired by Digital Equipment Corp and died with DEC. Over several years, dueling proposals (perfctr, perfmon, perfmon2) failed to get into the Linux kernel. Then the CPU and motherboard designers made the underlying hardware counter (RDTSC) unreliable in too many cases (non-constant frequency, not synchronized for SMP, arbitrarily scribbled by SystemManagementMode, ...). Today the infrastructure work for kernel ftrace comes close to what is required for use by apps, but gcc still won't do exactly the right thing. In short, those who want profiling have failed repeatedly to present an _effective_ case. What are you doing to do differently this time? [The workaround is to spend a week learning how to run oprofile and interpret its output.] -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: > On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: > > Basically summarizes the situation, and as far as I know nothing has > > changed ... with default compilation options, getting callgraph > > profiling on x86_64 really requires a DWARF unwinder in the kernel. > > Which seems unlikely to happen. > > But that's the right thing to do. Sure, but so is a kernel debugger, and it's taken us over ten years to get one. I'm pretty okay with doing something wrong now if it gets me something usable for long enough to get something right later. I'll take 4% across the board if it helps me find the 20% that matters. > There is always callgrind if you don't want to recompile anything and > need to profile something even when kernel doesn't support it. I don't want to know how callgrinded X performs, I want to know how X performs. callgrind means operations that would be one millisecond become half a second, and that's thirty frames instead of a sixteenth of a frame. That means I end up optimizing for function call cycle counts instead of fixing my algorithms to not starve the hardware. If wall time matters, callgrind is the wrong tool, and you need a live profiler. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 04:10:30PM -0400, Adam Jackson wrote: > On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: > > On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: > > > Basically summarizes the situation, and as far as I know nothing has > > > changed ... with default compilation options, getting callgraph > > > profiling on x86_64 really requires a DWARF unwinder in the kernel. > > > Which seems unlikely to happen. > > > > But that's the right thing to do. > > Sure, but so is a kernel debugger, and it's taken us over ten years to > get one. I'm pretty okay with doing something wrong now if it gets me > something usable for long enough to get something right later. I'll > take 4% across the board if it helps me find the 20% that matters. Most of the time you don't find the 20% improvements with profilers though, so all we end up with is just slowing everything by 4%. Definitely a bad idea, now that per core performance doesn't increase very much and most programs aren't parallelized at all or just very badly. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
On Wednesday 03 November 2010, Nicolas Mailhot wrote: > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit : > > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit : > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK > > > > packages should be purged. It's a relic from times that are long > > > > gone, > > > > > > Having a semi-sane way to install multi-vendor multi-version JVMs is > > > still needed EPEL side. Expensive apps like SAP still make you install > > > the specific JVM they've been qualified against. > > > > But such JVMs do not need to be made the system default at all, people > > can just run $expensive_app with it by whatever means they like (e.g. > > direct modification of $PATH, $JAVA_HOME, etc _for that specific app_). > > When you pass a certain level of expensiveness, ISVs just assume the > *only* jvm on the system will be the one they require (quite simply the > software price is many times the price of hardware, so there is no > reason to share the hardware with anything else). Ok. So again, for what do you need the alternatives stuff for in this scenario? Either you abide by their assumption and just install their JVM and no others (no alternatives needed because The Can Be Only One), or you don't and install several JVMs or only the Fedora/EL one at which point you've already broken their expectation and thus their support may be in a so-so state (no alternatives needed because the damage is already done (alternatives or not) or there is only the one Fedora/EL JVM installed). > It never ceases to astonish me how software “giants” have come to depend > on the quick and dirty hacks we did JPackage-side æons agos, and never > thought of redirecting some of their huge cash flow to fund something a > little more robust. Ditto. But in retrospect, I wish we hadn't bent over and done those hacks :( But that was a long time ago, those were different times and it's easy to be smart later. I still believe it's time to stop encouraging use of that cruft, at the very least in Fedora, then later in slower moving distros. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 574195] AMAVISD_DB_HOME in amavisd-agent has wrong default
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=574195 Sandro Janke changed: What|Removed |Added Version|12 |13 Flag|needinfo?(bugzilla_red...@p | |enguinpee.nl) | --- Comment #2 from Sandro Janke 2010-11-03 16:31:00 EDT --- Bug still present in Fedora 13. Changing version accordingly. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
bugzilla bugzappers?
hi! This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me? cheers, Bert the url of the blog of the guy: http://www.krisbuytaert.be/blog/ == the mail == Dear Fedoracommunity, Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15. But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed http://tieguy.org/blog/2004/09/";>Luis already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper. So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, 2010-11-03 at 21:11 +0100, Jakub Jelinek wrote: > On Wed, Nov 03, 2010 at 04:10:30PM -0400, Adam Jackson wrote: > > On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: > > > On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: > > > > Basically summarizes the situation, and as far as I know nothing has > > > > changed ... with default compilation options, getting callgraph > > > > profiling on x86_64 really requires a DWARF unwinder in the kernel. > > > > Which seems unlikely to happen. > > > > > > But that's the right thing to do. > > > > Sure, but so is a kernel debugger, and it's taken us over ten years to > > get one. I'm pretty okay with doing something wrong now if it gets me > > something usable for long enough to get something right later. I'll > > take 4% across the board if it helps me find the 20% that matters. > > Most of the time you don't find the 20% improvements with profilers though, > so all we end up with is just slowing everything by 4%. Definitely a bad > idea, now that per core performance doesn't increase very much and most > programs aren't parallelized at all or just very badly. I would agree that it would be extraordinarily hard to use a profiler to identify a code change you could make in glibc to make a non-trivial program 4% faster. But usually what you want a profiler for is to be able to efficiently identify the hot spots and do 10 or so 1% changes in a row. And we also work on a lot of code bases that are a lot less mature an tuned than glibc. Usually, what we are trying to do is not to figure out the function we could rewrite with a clever algorithm to do the same thing faster; we are trying to find out the stuff we are doing that we shouldn't be doing at all. The other argument for profiling is that in many cases you want to ask someone else to get a profile of a situation that is slow for them, that maybe isn't slow for you. When things are *massively* slow, then it's pretty easy for me to track that down using top to identify the massively slow process, and attaching to it with gdb. But it's not something that's easy to guide someone through over IRC. I'm sure you wouldn't claim that Fedora as an operating system is within 4% of how fast it could be, or that our most efficient way of making Fedora faster is compiler optimization :-) - Owen [ But yes, 4% is a big hit. 1% I would accept without hesitation. 4% does make me hesitate a little bit. During devel cycles, we accept much more slowdown than that for the debug kernel, of course. If we can figure out profiling without frame pointers, that would be even better ] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, 2010-11-03 at 20:29 +0100, Jakub Jelinek wrote: > > It seems like if it was that easy, it would have happened and we'd have > > a solution in the upstream kernel... > > I think we had one in the upstream kernel for some time, then Linus just > didn't like to see it needing too many bugfixes needed for it and nuked it. [..] > > (One thing that definitely makes things tricky is paging in debuginfo. I > > think I saw a discussion somewhere that systemtap preemptively was > > paging in all debuginfo for traced modules. That's tricky in systemwide > > Yeah, systemtap does that (and has that in kernel unwinder for userspace). Looking at systemstap, they are exploiting the fact that they already have an infrastructure for compiling arbitrary code into modules and loading it into the kernel. So they've entirely bypassed the question of how to get a DWARF unwinder upstream into the kernel. Of course, any profiling framework *could* work with a custom kernel module, but sysprof was actually kicked out of Fedora for a while because it had a much simpler not-in-the-kernel module. It now uses upstream hooks. So systemtap at best answers the technical questions, and not the practical question of actually making something happen. If the earlier experience was a DWARF one got in, then got removed, it's a little hard for me to see how a DWARF unwinder in the kernel is a practical direction. Maybe I should have headed down earlier this week and picketed outside the Kernel summit... - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On 11/03/2010 01:51 PM, Owen Taylor wrote: > [ But yes, 4% is a big hit. 1% I would accept without hesitation. > 4% does make me hesitate a little bit. During devel cycles, we > accept much more slowdown than that for the debug kernel, > of course. If we can figure out profiling without frame > pointers, that would be even better ] Would you accept an overhead of 1 CPU cycle per subroutine call (all the time in *ALL* code) plus a few dozen cycles per subroutine call (perhaps restricted to some subset of routines) in the pieces that were being profiled at the moment? -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
Le mercredi 03 novembre 2010 à 22:28 +0200, Ville Skyttä a écrit : > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit : > > > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit : > > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK > > > > > packages should be purged. It's a relic from times that are long > > > > > gone, > > > > > > > > Having a semi-sane way to install multi-vendor multi-version JVMs is > > > > still needed EPEL side. Expensive apps like SAP still make you install > > > > the specific JVM they've been qualified against. > > > > > > But such JVMs do not need to be made the system default at all, people > > > can just run $expensive_app with it by whatever means they like (e.g. > > > direct modification of $PATH, $JAVA_HOME, etc _for that specific app_). > > > > When you pass a certain level of expensiveness, ISVs just assume the > > *only* jvm on the system will be the one they require (quite simply the > > software price is many times the price of hardware, so there is no > > reason to share the hardware with anything else). > > Ok. So again, for what do you need the alternatives stuff for in this > scenario? You need it to keep the jvm packaging modular and not have to package the same jvm in multiple ways (jvm-as-system-default, jvm-as-secondary-jvm, jvm-a-for-mixing-with-jvm-b, etc). For practical purposes the "Enterprise" market is still stuck where JPackage was when we added alternatives (which, btw, I hate dearly). And it's unreasonable to expect those ISVs to change when Fedora has not managed to package a working JBoss. If the Red Hat Java packaging can not even be used with the top Red Hat Java product, what is there to say? (and on this subject, I don't think Fedora Java can be dissociated from Red Hat java) The main reason other project members went for the packaging changes I proposed in JPackage at the time (what people call the JPackage guidelines now) is that I got the then top floss java application, tomcat, to work with them (which was a beast to do alone before others joined the ship). I find it worrying that Java packaging changes are proposed now, but nobody seems to have taken the time to repackage a big demanding java app with the new guidelines as a reality check. But those who do the work decide, that was true then and is true now, and I'm definitely not doing java packaging anymore. So feel free to ignore me. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
> Le mercredi 03 novembre 2010 à 22:28 +0200, Ville Skyttä a écrit : > > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit : > > > > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit : > > > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK > > > > > > packages should be purged. It's a relic from times that are long > > > > > > gone, > > > > > > > > > > Having a semi-sane way to install multi-vendor multi-version JVMs > > > > > is still needed EPEL side. Expensive apps like SAP still make you > > > > > install the specific JVM they've been qualified against. > > > > > > > > But such JVMs do not need to be made the system default at all, > > > > people can just run $expensive_app with it by whatever means they > > > > like (e.g. direct modification of $PATH, $JAVA_HOME, etc _for that > > > > specific app_). > > > > > > When you pass a certain level of expensiveness, ISVs just assume the > > > *only* jvm on the system will be the one they require (quite simply the > > > software price is many times the price of hardware, so there is no > > > reason to share the hardware with anything else). > > > > Ok. So again, for what do you need the alternatives stuff for in this > > scenario? > > You need it to keep the jvm packaging modular and not have to package > the same jvm in multiple ways (jvm-as-system-default, > jvm-as-secondary-jvm, jvm-a-for-mixing-with-jvm-b, etc). For practical > purposes the "Enterprise" market is still stuck where JPackage was when > we added alternatives (which, btw, I hate dearly). > > And it's unreasonable to expect those ISVs to change when Fedora has not > managed to package a working JBoss. If the Red Hat Java packaging can > not even be used with the top Red Hat Java product, what is there to > say? (and on this subject, I don't think Fedora Java can be dissociated > from Red Hat java) > > The main reason other project members went for the packaging changes I > proposed in JPackage at the time (what people call the JPackage > guidelines now) is that I got the then top floss java application, > tomcat, to work with them (which was a beast to do alone before others > joined the ship). I find it worrying that Java packaging changes are > proposed now, but nobody seems to have taken the time to repackage a big > demanding java app with the new guidelines as a reality check. Most of these changes are nothing new but bringing guidelines closer to reality and removing some stuff that is causing nothing but confusion. And they have been verified during the recent Maven 2.2.1 update and the ongoing Maven 3 work. Maven may not be as big as Tomcat if we speak in LOC but Maven is really changing the way Java packaging is done. Regards, Alex > > But those who do the work decide, that was true then and is true now, > and I'm definitely not doing java packaging anymore. So feel free to > ignore me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
On 11/3/10 2:14 PM, Nicolas Mailhot wrote: > And it's unreasonable to expect those ISVs to change when Fedora has not > managed to package a working JBoss. If the Red Hat Java packaging can > not even be used with the top Red Hat Java product, what is there to > say? (and on this subject, I don't think Fedora Java can be dissociated > from Red Hat java) JBoss isn't in Fedora because JBoss seems to require lots of things that are older than what we ship in Fedora. I see this is a problem with JBoss, not Fedora. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
> On 11/3/10 2:14 PM, Nicolas Mailhot wrote: > > And it's unreasonable to expect those ISVs to change when Fedora has not > > managed to package a working JBoss. If the Red Hat Java packaging can > > not even be used with the top Red Hat Java product, what is there to > > say? (and on this subject, I don't think Fedora Java can be dissociated > > from Red Hat java) > > JBoss isn't in Fedora because JBoss seems to require lots of things that > are older than what we ship in Fedora. I see this is a problem with > JBoss, not Fedora. Well JBoss is not even a single product it's a bunch of products - see http://www.jboss.org/projects/matrix. And both projects have to improve and colaborate to get things working. On our(Fedora) site we have a long way to go before having maven 3 working, rpm maven autoprovides/requires and so on and so on to make it easier for contributors. Regards, Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
Le mercredi 03 novembre 2010 à 14:35 -0700, Jesse Keating a écrit : > On 11/3/10 2:14 PM, Nicolas Mailhot wrote: > > And it's unreasonable to expect those ISVs to change when Fedora has not > > managed to package a working JBoss. If the Red Hat Java packaging can > > not even be used with the top Red Hat Java product, what is there to > > say? (and on this subject, I don't think Fedora Java can be dissociated > > from Red Hat java) > > JBoss isn't in Fedora because JBoss seems to require lots of things that > are older than what we ship in Fedora. I see this is a problem with > JBoss, not Fedora. Sure a large part of the blame is JBoss-side. However, my point was that's it's really hard to define good packaging guidelines, when you have no complex application to test them on. And the other big Java apps have even more problems than JBoss (I intentionnaly exclude developper tools like Eclipse or maven, the compromises needed for a developper station are very different from those needed for a server. A developper will accept all sorts of crap just to have access to the latest shiny toys) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
Le mercredi 03 novembre 2010 à 23:54 +0200, Alexander Kurtakov a écrit : > > On 11/3/10 2:14 PM, Nicolas Mailhot wrote: > > > And it's unreasonable to expect those ISVs to change when Fedora has not > > > managed to package a working JBoss. If the Red Hat Java packaging can > > > not even be used with the top Red Hat Java product, what is there to > > > say? (and on this subject, I don't think Fedora Java can be dissociated > > > from Red Hat java) > > > > JBoss isn't in Fedora because JBoss seems to require lots of things that > > are older than what we ship in Fedora. I see this is a problem with > > JBoss, not Fedora. > > Well JBoss is not even a single product it's a bunch of products - see > http://www.jboss.org/projects/matrix. Sure. But you know like me that the AS part is where to start from -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, Nov 3, 2010 at 4:41 PM, Bert Desmet wrote: > hi! > > This is something I got in my mail box today. > As I don't have a valid answer for this, maybe someone else can answer for me? > > cheers, Bert > > the url of the blog of the guy: http://www.krisbuytaert.be/blog/ > > == the mail == > > Dear Fedoracommunity, > > Over the course of the day I recieved 22^3 mails from your friendly Bug > Zapper. > Most of those bugs where bugs I had reported upon crashes using > bug-buddy. Bugs on different desktop tools such as .. synergy, > evolution, gwibber , gnome-settings and probably some others > > I do understand that I development goes on and on .. and your fancy > devs don't care anymore about > bugs I reported on Fedora 12 as they are all hacking on Fedora 15. > > But what I don't get is that non of these bugs was ever touched, > they've been automatically created , and automatically closed > > http://tieguy.org/blog/2004/09/";>Luis already told us > ages ago .. that every project needs a bugmaster apparently Fedora > replaced that bugmaster with a Bug Zapper. > > So can someone please explain my why I should continue to try to > improve Fedora by reporting bugs ? > Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good. What can we do to make it better? Some ideas: 1. - ABRT stops reporting new bugs to Fedora. - The user does a self evaluation: Is the bugcoding related, or packaging related? - If he thinks the bug is packaging related, or if he's not sure, he manually files a bug to Fedora bugzilla. Otherwise he notifies the developers. - The package maintainer asks for a backtrace - User reproduces the crash, and puts the bug number in ABRT gui. ABRT posts the backtrace to the bug report as an attachment. - If the bug is coding related, the package maintainer can direct the user to the developers. 2. There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages. 3. ? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: > Maybe it is time to discuss the usefulness of ABRT to Fedora. I think > that it is a great idea for commercial products such as RHEL, but it > obviously did not fit Fedora as is. I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'. > From what I have seen, the maintainers are more responsive to manually > filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the > current setup is driving users (such as the person in the above email) > away who are otherwise willing to report bugs. This is not good. > > What can we do to make it better? Some ideas: > > 1. > - ABRT stops reporting new bugs to Fedora. > - The user does a self evaluation: Is the bugcoding related, or > packaging related? > - If he thinks the bug is packaging related, or if he's not sure, he > manually files a bug to Fedora bugzilla. Otherwise he notifies the > developers. > - The package maintainer asks for a backtrace > - User reproduces the crash, and puts the bug number in ABRT gui. ABRT > posts the backtrace to the bug report as an attachment. > - If the bug is coding related, the package maintainer can direct the > user to the developers. This is not practical. Users are not in a position to know whether the crash is in downstream or upstream code. > 2. > There can be a checkbox in pkgdb for maintainers to turn off ABRT bug > reporting for their packages. This seems reasonable, for packagers who are not in a position to act on such reports, but then, that's not a great position for a packager to be in; for instance, I'm a packager who can't code so these reports are of fairly limited value to me directly, but they would at least give me good data to pass to the upstream coders of any package I own. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: > On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: > >> Maybe it is time to discuss the usefulness of ABRT to Fedora. I think >> that it is a great idea for commercial products such as RHEL, but it >> obviously did not fit Fedora as is. > > I disagree. I have seen many bugs fixed with the aid of abrt feedback. > It beats the hell out of a bug report which says 'it crashed'. > Does it compare to this number? (it takes a while to open) http://tinyurl.com/39yr832 >> From what I have seen, the maintainers are more responsive to manually >> filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the >> current setup is driving users (such as the person in the above email) >> away who are otherwise willing to report bugs. This is not good. >> >> What can we do to make it better? Some ideas: >> >> 1. >> - ABRT stops reporting new bugs to Fedora. >> - The user does a self evaluation: Is the bugcoding related, or >> packaging related? >> - If he thinks the bug is packaging related, or if he's not sure, he >> manually files a bug to Fedora bugzilla. Otherwise he notifies the >> developers. >> - The package maintainer asks for a backtrace >> - User reproduces the crash, and puts the bug number in ABRT gui. ABRT >> posts the backtrace to the bug report as an attachment. >> - If the bug is coding related, the package maintainer can direct the >> user to the developers. > Hence I added "if he's not sure". Please read again. > This is not practical. Users are not in a position to know whether the > crash is in downstream or upstream code. > >> 2. >> There can be a checkbox in pkgdb for maintainers to turn off ABRT bug >> reporting for their packages. > > This seems reasonable, for packagers who are not in a position to act on > such reports, but then, that's not a great position for a packager to be > in; for instance, I'm a packager who can't code so these reports are of > fairly limited value to me directly, but they would at least give me > good data to pass to the upstream coders of any package I own. > I played the middle man in some of the bug reports. The user did not seem to want to contact the developer directly. The upstream asked for something, and I forwarded it to the user. This went back and forth a couple times until I realized that this was highly inefficient, and mostly a waste of time (since one of the parties gave up eventually). There's got to be a better way. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote: > On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: > > On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: > > > >> Maybe it is time to discuss the usefulness of ABRT to Fedora. I think > >> that it is a great idea for commercial products such as RHEL, but it > >> obviously did not fit Fedora as is. > > > > I disagree. I have seen many bugs fixed with the aid of abrt feedback. > > It beats the hell out of a bug report which says 'it crashed'. > > > > Does it compare to this number? (it takes a while to open) > > http://tinyurl.com/39yr832 Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :) (I just searched for bugs with [abrt] in the subject reported against Fedora, which gives the 31,603 total, then ran the same search but with the above resolution restrictions). > >> From what I have seen, the maintainers are more responsive to manually > >> filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the > >> current setup is driving users (such as the person in the above email) > >> away who are otherwise willing to report bugs. This is not good. > >> > >> What can we do to make it better? Some ideas: > >> > >> 1. > >> - ABRT stops reporting new bugs to Fedora. > >> - The user does a self evaluation: Is the bugcoding related, or > >> packaging related? > >> - If he thinks the bug is packaging related, or if he's not sure, he > >> manually files a bug to Fedora bugzilla. Otherwise he notifies the > >> developers. > >> - The package maintainer asks for a backtrace > >> - User reproduces the crash, and puts the bug number in ABRT gui. ABRT > >> posts the backtrace to the bug report as an attachment. > >> - If the bug is coding related, the package maintainer can direct the > >> user to the developers. > > > > Hence I added "if he's not sure". Please read again. My point is that you may as well not bother with the cases where the user is sure, because they'll be very rare, and such users will know what to do anyway. > > This is not practical. Users are not in a position to know whether the > > crash is in downstream or upstream code. > > > >> 2. > >> There can be a checkbox in pkgdb for maintainers to turn off ABRT bug > >> reporting for their packages. > > > > This seems reasonable, for packagers who are not in a position to act on > > such reports, but then, that's not a great position for a packager to be > > in; for instance, I'm a packager who can't code so these reports are of > > fairly limited value to me directly, but they would at least give me > > good data to pass to the upstream coders of any package I own. > > > > I played the middle man in some of the bug reports. The user did not > seem to want to contact the developer directly. The upstream asked for > something, and I forwarded it to the user. This went back and forth a > couple times until I realized that this was highly inefficient, and > mostly a waste of time (since one of the parties gave up eventually). > There's got to be a better way. I'm not sure there is. Implementing a whole separate system for abrt to report to is essentially just institutionalizing the middle-man. But hey, if we go that way, fine. It's worth noting, though, that we're not short of proposals for implementing an intermediary system for abrt, we've already had one for a while. We're short on people *writing* the intermediary system. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote: > On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote: >> On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: >> > On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: >> > >> >> Maybe it is time to discuss the usefulness of ABRT to Fedora. I think >> >> that it is a great idea for commercial products such as RHEL, but it >> >> obviously did not fit Fedora as is. >> > >> > I disagree. I have seen many bugs fixed with the aid of abrt feedback. >> > It beats the hell out of a bug report which says 'it crashed'. >> > >> >> Does it compare to this number? (it takes a while to open) >> >> http://tinyurl.com/39yr832 > > Not hard to run the numbers. There've been 31,603 bugs reported to > Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been > closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the > resolutions that usually imply 'it got fixed'). I think a tool that's > resulted in 2,216 fixes for crasher bugs is pretty cool. :) > I am pretty sure a subset of these closed bugs are "mass-closing" of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say "it may be fixed, just update and try". You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY! Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, Nov 3, 2010 at 11:10 PM, Orcan Ogetbil wrote: > On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote: >> On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote: >>> On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: >>> > On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: >>> > >>> >> Maybe it is time to discuss the usefulness of ABRT to Fedora. I think >>> >> that it is a great idea for commercial products such as RHEL, but it >>> >> obviously did not fit Fedora as is. >>> > >>> > I disagree. I have seen many bugs fixed with the aid of abrt feedback. >>> > It beats the hell out of a bug report which says 'it crashed'. >>> > >>> >>> Does it compare to this number? (it takes a while to open) >>> >>> http://tinyurl.com/39yr832 >> >> Not hard to run the numbers. There've been 31,603 bugs reported to >> Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been >> closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the >> resolutions that usually imply 'it got fixed'). I think a tool that's >> resulted in 2,216 fixes for crasher bugs is pretty cool. :) >> > > I am pretty sure a subset of these closed bugs are "mass-closing" of > bugs when a maintainer updates the software. Sometimes, when you > forward the report upstream, they don't understand the output either, > and say "it may be fixed, just update and try". You update the > software, put it to testing, and ask the user if it is fixed for him. > The user doesn't respond as usual. Then you mark it as fixed without > really knowing what's going on. Then you have such statistics. YAY! > I randomly picked 20 bug reports out of those 2,216 that were closed CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE. 1 had the software patched, and updated (Good fix) 2 had some sort of discussion (1-2 messages) before the maintainer updates the software and marks it fixed 17 had no conversation at all. The maintainer just updates the software to the next version. Of course some of these might be real fixes. I didn't look deeply into it. However, believing that these bugs are "fixed" thanks to the ABRT reports sounds to me like wishful thinking. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/04/2010 03:59 AM, Adam Williamson wrote: > On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote: >> On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: >>> On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: >>> Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. >>> >>> I disagree. I have seen many bugs fixed with the aid of abrt feedback. >>> It beats the hell out of a bug report which says 'it crashed'. >>> >> >> Does it compare to this number? (it takes a while to open) >> >> http://tinyurl.com/39yr832 > > Not hard to run the numbers. There've been 31,603 bugs reported to > Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been > closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the > resolutions that usually imply 'it got fixed'). I think a tool that's > resulted in 2,216 fixes for crasher bugs is pretty cool. :) 2216/31603 = 7% With all due respect, to me, this qualifies as ineffective, esp when considering the communicational overhead/noise attached to them. IMO, the more interesting figure would be * How many of these fixed bugs would not have been fixed if abrt wasn't around. My (wild) guess is, not much more, because serious and reproduceable bugs would have been manually reported in any case. * How many of the "unfixed bugs" remained unfixed because abrt's reports are not reporting sufficient information to allow maintainers to investigate. As far as the packages I am maintaining are concerned, I haven't been able to fix any bug in my packages due to abrt reports. As far as I as a user am concerned, none of the bugs I had reported via abrt was fixed. In both cases, however I am experiencing the noise abrt causes. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/3/2010 7:02 PM, Orcan Ogetbil wrote: > Maybe it is time to discuss the usefulness of ABRT to Fedora. I think > that it is a great idea for commercial products such as RHEL, but it > obviously did not fit Fedora as is. > Orcan Of the 28 abrt bugs filed against my packages, I think 1 resulted in a real fix that I needed to apply as a packager. Another was fixed by an update. The rest are piling up. I don't have the time to fix them myself. I rarely get any response to my requests for more info (5 are in needinfo). I haven't been able to get upstream to involved. I'm seriously considering orphaning pdfedit (14 bugs) over this. 0rion -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Wed, 2010-11-03 at 21:58 -0600, Orion Poplawski wrote: > On 11/3/2010 7:02 PM, Orcan Ogetbil wrote: > > Maybe it is time to discuss the usefulness of ABRT to Fedora. I think > > that it is a great idea for commercial products such as RHEL, but it > > obviously did not fit Fedora as is. > > Orcan > > Of the 28 abrt bugs filed against my packages, I think 1 resulted in a > real fix that I needed to apply as a packager. Another was fixed by an > update. The rest are piling up. I don't have the time to fix them > myself. I rarely get any response to my requests for more info (5 are > in needinfo). I haven't been able to get upstream to involved. I'm > seriously considering orphaning pdfedit (14 bugs) over this. My question would be 'why'? There seems to be an assumption that an open bug report you can't fix is a serious problem; of course in a sense it is, but then, it's not as if, if we remove or otherwise change abrt, software is going to magically stop crashing. It's going to crash just as much. There just won't be bug reports associated with the crashes. I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/03/2010 11:05 PM, Adam Williamson wrote: > On Wed, 2010-11-03 at 21:58 -0600, Orion Poplawski wrote: >> On 11/3/2010 7:02 PM, Orcan Ogetbil wrote: >>> Maybe it is time to discuss the usefulness of ABRT to Fedora. I think >>> that it is a great idea for commercial products such as RHEL, but it >>> obviously did not fit Fedora as is. >>> Orcan >> >> Of the 28 abrt bugs filed against my packages, I think 1 resulted in a >> real fix that I needed to apply as a packager. Another was fixed by an >> update. The rest are piling up. I don't have the time to fix them >> myself. I rarely get any response to my requests for more info (5 are >> in needinfo). I haven't been able to get upstream to involved. I'm >> seriously considering orphaning pdfedit (14 bugs) over this. > > My question would be 'why'? There seems to be an assumption that an open > bug report you can't fix is a serious problem; of course in a sense it > is, but then, it's not as if, if we remove or otherwise change abrt, > software is going to magically stop crashing. It's going to crash just > as much. There just won't be bug reports associated with the crashes. I > guess what I'm asking is what actual harm/damage are these reports > causing, beyond the time it takes to look at the report and figure out > whether you can fix it? Why is the fact that people have experienced > crashes you haven't yet figured out how to fix a reason to stop > maintaining the software? If I can weigh in. First off, I have no preference in this and can see validity in both sides, but I'll share my impressions. Prior to the introduction of abrt I started wanting to get more involved. At the time I wasn't sure, and was talking with a friend who felt the same. After awhile we figured that one way is to report bugs/ or annoyances and help get them fixed in whatever way we could. Soon after that abrt arrived. I started using abrt and filing bugs very much willing to help in their triage, analysis and testing. I should add that I also file bugs when it isn't a crash, but something I consider a bug... Its been somewhat a disappointing experience. Not because of the % of the bugs fixed, but because of the % response. I'm not sure if any of my bugs have been responded to. There are probably one or two. I've been annoyed that some of the bugs are getting many many CC's added to them (or the ones I've been added to), but no response. I completely realize this is a matter of man power so am in no way complaining. However from my perspective, the question is, do I even bother? In some cases now I'm not reporting the abrt detected crashes if its in something I figure won't get much attention, or I have no idea how it happened. For example I had a handful of Firefox crashing mysteriously. I wasn't even *using* it when it crashed. If it wasn't for abrt I may not have even noticed. Now, if FF crashes I rarely report it. I imagine its because I know they must be getting inundated with these types of reports, and how can they know I'm willing to help any more than the other thousand of reports. They can't... However from my perspective as one who files bugs, its less valuable as I don't see things I report being fixed so why report. It also lets me know how many things are crashing on my systems. I used to feel linux was more stable, and in some senses it is, however now I am starting to see more and more crashes that may have been happening all along but I didn't know. So I'm not as naive anymore I guess. I have to say, I have since become a packager and involved in other ways... and would like to become more involved but won't have more time for another 14 months. Just some thoughts... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
Just a followup thought... I wonder if abrt could be made smarter / changed to allow for a preference setting to report on updates-testing or all updates... I know awhile back I made suggestions on what it would take in my mind to increase user testing [1]. I see abrt as another way to help increase the quality of Fedora. In its current state it is likely flooding developers and as such less effective than it could be. Just some thoughts... [1] http://lists.fedoraproject.org/pipermail/devel/2010-June/138077.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
2010/11/4 Orcan Ogetbil : > Maybe it is time to discuss the usefulness of ABRT to Fedora. I think > that it is a great idea for commercial products such as RHEL, but it > obviously did not fit Fedora as is. No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NearTree build failed only on IA32
Hi. I'm now building NearTree package. https://bugzilla.redhat.com/show_bug.cgi?id=545047 As I've commented at #23, %check (This means "make tests") failed only on i686 (for EL6, f12 and f13). I can build NearTree on x86_64, ppc64, and ppc (for f12) with no error. All of EL6, f12, and f13 use gcc-4.4.4. f12 uses glibc-2.11.2. f13 uses glibc-2.12.1. EL6 uses glibc-2.12. I suppose there is something wrong with gcc or glibc. Does anyone know what happens? Takanori -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote: > I > guess what I'm asking is what actual harm/damage are these reports > causing, beyond the time it takes to look at the report and figure out > whether you can fix it? Why is the fact that people have experienced > crashes you haven't yet figured out how to fix a reason to stop > maintaining the software? > Well, since you start with "beyond the time it takes to look", I guess that the time it takes to look won't be enough of an argument to put on the table. Then I won't have anything else to say. For me that is all that matters. Actually that is all that I give to Fedora: time. The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, 2010-11-04 at 02:15 -0400, Orcan Ogetbil wrote: > On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote: > > I > > guess what I'm asking is what actual harm/damage are these reports > > causing, beyond the time it takes to look at the report and figure out > > whether you can fix it? Why is the fact that people have experienced > > crashes you haven't yet figured out how to fix a reason to stop > > maintaining the software? > > > > Well, since you start with "beyond the time it takes to look", I guess > that the time it takes to look won't be enough of an argument to put > on the table. Then I won't have anything else to say. For me that is > all that matters. Actually that is all that I give to Fedora: time. > > The question is > Am I using the time efficiently? OR > Are the these tools actually preventing me to be efficient during my > available time? Well, it seems to me that your proposal basically involves sticking several artificial barriers in the process of filing crash reports to Bugzilla in the hopes that we'll get fewer of them, and also trying to get reports upstream by the initial reporters...which doesn't really remove the time requirement, just dumps it on someone else (upstream). I don't know, it just seems like the case where, when something crashes, we catch the fact of the crash and the most useful data about it (backtrace) and put it somewhere is better than the case where, when something crashes, we don't do that. Even if we go with a system where there's some kind of intermediary place for abrt reports to go, *someone* is going to have to invest in the time to look at them. And I'm not sure that introducing barriers to reporting just to try and get fewer people to report crashes makes a whole lot of sense either. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/04/2010 07:15 AM, Orcan Ogetbil wrote: > On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote: >> I >> guess what I'm asking is what actual harm/damage are these reports >> causing, beyond the time it takes to look at the report and figure out >> whether you can fix it? Why is the fact that people have experienced >> crashes you haven't yet figured out how to fix a reason to stop >> maintaining the software? >> > > Well, since you start with "beyond the time it takes to look", I guess > that the time it takes to look won't be enough of an argument to put > on the table. Then I won't have anything else to say. For me that is > all that matters. Actually that is all that I give to Fedora: time. > > The question is > Am I using the time efficiently? OR > Are the these tools actually preventing me to be efficient during my > available time? As a user wanting to report a bug, abrt is both. On one hand it's a systematic way to report bugs, on the other hand it forces me download debug packages and to struggle with its GUI. Considering the facts that downloading 100MBs of debug-packages may not always be applicable (E.g. when not having broadband access), that abrt not always manages to correctly handle debug-infos, this costs. That said, I repeatedly ended up with "deleting" abrt notifications and to ignore it. As a maintainer, abrt to me primarily means "wading through wakes of hardly readable emails", mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info. That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, 2010-11-04 at 07:41 +0100, Ralf Corsepius wrote: > > The question is > > Am I using the time efficiently? OR > > Are the these tools actually preventing me to be efficient during my > > available time? > As a user wanting to report a bug, abrt is both. > > On one hand it's a systematic way to report bugs, on the other hand it > forces me download debug packages and to struggle with its GUI. > Considering the facts that downloading 100MBs of debug-packages may not > always be applicable (E.g. when not having broadband access), that abrt > not always manages to correctly handle debug-infos, this costs. > > That said, I repeatedly ended up with "deleting" abrt notifications and > to ignore it. This is another thing where we don't have any trouble identifying the problem and the solution. Will Woods has had the debuginfofs system sketched out for years to deal with this. What he doesn't have is the time to write it (since he's busy with AutoQA). Anyone else could do it instead, though. > As a maintainer, abrt to me primarily means "wading through wakes of > hardly readable emails", mostly to scan them for useful information. I > many cases I ended up with closing BZ, because these emails did not > contain sufficient info. > > That said, as a maintainer, abrt to me only has introduced a higher > noise/signal ratio in bugreports as before. I'm not sure SNR is the be-all and end-all, really. Fixing crasher bugs is surely an inherently desirable thing, even if it *does* add work examining the reports. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, Nov 4, 2010 at 2:28 AM, Adam Williamson wrote: > On Thu, 2010-11-04 at 02:15 -0400, Orcan Ogetbil wrote: >> On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote: >> > I >> > guess what I'm asking is what actual harm/damage are these reports >> > causing, beyond the time it takes to look at the report and figure out >> > whether you can fix it? Why is the fact that people have experienced >> > crashes you haven't yet figured out how to fix a reason to stop >> > maintaining the software? >> > >> >> Well, since you start with "beyond the time it takes to look", I guess >> that the time it takes to look won't be enough of an argument to put >> on the table. Then I won't have anything else to say. For me that is >> all that matters. Actually that is all that I give to Fedora: time. >> >> The question is >> Am I using the time efficiently? OR >> Are the these tools actually preventing me to be efficient during my >> available time? > > Well, it seems to me that your proposal basically involves sticking > several artificial barriers in the process of filing crash reports to > Bugzilla in the hopes that we'll get fewer of them, and also trying to > get reports upstream by the initial reporters...which doesn't really > remove the time requirement, just dumps it on someone else (upstream). > Correct. We shouldn't miss the fact that it takes less time to process the backtraces if we wrote the code ourselves. For a bug that I can reproduce, the time it takes for me to fix it might be comparable to the time it takes me to report it upstream and get it fixed there. The extreme inefficiency comes from the bugs that I can't reproduce, the upstream can't reproduce, and the user isn't responding. And this happens *a lot*. Most of the time, they don't even put down the steps to reproduce. Can we at least mandate including the steps to reproduce in the ABRT reports? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
