Orphaning and retiring couple of packages
Hello! I've orphaned - python-flask-principal - python-flask-rstpages - transfered ownership of python-flask-login to jkaluza Retired - sidc - clearlooks-phenix Best regards, -- sorki ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [EPEL-devel] updating python-kombu for EPEL7
On 09/14/2015 09:52 AM, Matthias Runge wrote: > On 09/09/15 16:02, Richard Marko wrote: >> Hi! >> >> As a dependency for celery, update of python-kombu is required in EPEL 7. >> >> The package builds just fine but I've been told to ask this ML if it's >> ok to update 2.5 currently in EPEL7 to 3.0. >> >> Please if your package depends on python-kombu, test with the following >> build: > > Richard, > > it seems, nobody complained about this. Would you then update them both? > > > OpenStack in Kilo or later is already using kombu-3.0.x. > > Best, > Matthias > No problem but I don't have commit access to either of them. Cheers, -- Richard ABRT DevQA irc: impure_hate #fedora-devel, #abrt, #fedora-cs ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: bodhi 2 now live
On 08/20/2015 05:45 AM, Kevin Fenzi wrote: Greetings. After a longer than expected outage window, I'm happy to report that bodhi2 is now live in production at https://admin.fedoraproject.org/updates or https://bodhi.fedoraproject.org/ The web interface should be available and working for adding and managing updates and build root overrides as well as karma. The command line tools should be available tomorrow in repos. 'fedpkg update' should work provided you have the latest python-fedora (python-fedora-0.5.5-1). There will likely be oddities and bugs. Please file them in github so we can prioritize them and get them fixed up. https://github.com/fedora-infra/bodhi/issues A collection of known issues and more information can be found at: https://fedoraproject.org/wiki/Bodhi2 Thanks for your patience as we roll out this new bodhi version. kevin Hi, I kind of miss the overview of supported releases that was available in old version. It would be nice if this overview was part of the landing page with links to the release detail pages: https://bodhi.fedoraproject.org/releases/F23 This way one is immediately aware which releases are still supported or newly added. Cheers, -- Richard ABRT DevQA irc: impure_hate #fedora-devel, #abrt, #fedora-cs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unified file selection dialogs
Hi, I'm currently working with toolchains that are composed of number of apps that all use different file selection dialogs. This gets annoying pretty quickly as one has to learn how to use multiple file choosers. Some of these provide bookmarks that are quite handy but when there are multiple user has to save the same bookmarks in various file choosers. Recently used directories won't work either. Are there any ongoing efforts to fix this situation? What would be a proper solution to this problem? I've only found one blogpost discussing this topic: http://straightedgelinux.com/blog/opinions/filechoosers/index.html Cheers, -- Richard irc: impure_hate -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New ABRT CLI
On 06/03/2015 08:06 AM, Tomas Hozza wrote: On 06/02/2015 03:45 PM, Richard Marko wrote: Hi, over last two weeks I completely rewrote abrt-cli to make life easier for users and developers. It now supports tab completion and few new commands like abrt gdb and abrt debuginfo-install. Without any arguments these commands will use the last crash that occurred on your system. New cli is available in abrt-cli-ng subpackage and will replace old abrt-cli command in the future. Please help with testing according to instructions in the following copr: https://copr.fedoraproject.org/coprs/rmarko/abrt/ Feedback is highly appreciated. Thanks! One small thing. The install instructions are not completely correct. # dnf --disablerepo=* --enablerepo=rmarko-abrt install abrt-cli-ng Last metadata expiration check performed 0:00:16 ago on Wed Jun 3 08:02:55 2015. Error: nothing provides python-argcomplete needed by abrt-cli-ng-2.5.1-3.fc22.1.x86_64 So this needs to be installed without the --disablerepo=* argument. Fixed. Thanks! -- Richard irc: impure_hate -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New ABRT CLI
Hi, over last two weeks I completely rewrote abrt-cli to make life easier for users and developers. It now supports tab completion and few new commands like abrt gdb and abrt debuginfo-install. Without any arguments these commands will use the last crash that occurred on your system. New cli is available in abrt-cli-ng subpackage and will replace old abrt-cli command in the future. Please help with testing according to instructions in the following copr: https://copr.fedoraproject.org/coprs/rmarko/abrt/ Feedback is highly appreciated. Thanks! -- Richard irc: impure_hate -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ABRT report for package soundconverter has reached 10 occurrences
On 05/22/2015 04:05 PM, Michael Schwendt wrote: On Wed, 20 May 2015 20:50:10 + (UTC), notifications fedoraproject org wrote: Packages: soundconverter Function: change_mime_type Firtst occurrence: 2015-05-20 Type: python Count:10 URL: http://retrace.fedoraproject.org/faf/reports/bthash/904ea88a8ddd561298140d2978da9d25c89fb915/ It could be more productive to submit a bug report in bugzilla. Based on only the source line numbers in this shortened report, it seems somebody either has been using a damaged installation, where GStreamer has been damaged, or has tried to hack additional encoder MIME types into the application. That might be a reason why there's no bugzilla attached to this report. Another possibility is that user didn't finish reporting to bugzilla or only has automatic reporting enabled - in this case bugzilla is created when there's a user that actually finishes whole reporting process. While we would like to create bugzilla bugs from faf reports automatically this proven rather complicated to deliver quality bug reports based on little information we have on the server. Instead there's Associate bug button in case you're logged in and viewing a report of a package that you're maintainer of. Clicking this button will take you to a page where you can either associate report with already existing bugzilla or create a new bug. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
abrt server report: 20140526
In last two weeks these components were crashing the most: 1. kernel seen 56703 times (31% of all reports) http://retrace.fedoraproject.org/faf/problems/1597313/ RHBZ#1030988 http://retrace.fedoraproject.org/faf/problems/749325/ 2. virtuoso-opensource seen 19395 times (11% of all reports) http://retrace.fedoraproject.org/faf/problems/1279374/ RHBZ#1013705 http://retrace.fedoraproject.org/faf/problems/740642/ RHBZ#1013705 3. tracker seen 9474 times (5% of all reports) http://retrace.fedoraproject.org/faf/problems/1697689/ RHBZ#967021 http://retrace.fedoraproject.org/faf/problems/1734513/ RHBZ#997752 4. kde-workspace seen 9326 times (5% of all reports) http://retrace.fedoraproject.org/faf/problems/1611104/ http://retrace.fedoraproject.org/faf/problems/1259854/ 5. firefox seen 8891 times (5% of all reports) http://retrace.fedoraproject.org/faf/problems/1700469/ http://retrace.fedoraproject.org/faf/problems/1538076/ Hot problems: ID Components Count --- 1279374virtuoso-opensource11840 749325 kernel 10119 1611104kde-workspace 9266 1597313kernel 8609 740642 virtuoso-opensource 6696 1739523kernel 4497 1160331evolution-data-server 3335 1370858kernel 2575 1700469firefox 2498 1266680gvfs1968 URL: http://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 1127716glib-networking403503 908821 kernel 155545 577402 libgsf 108086 1174076kernel 106820 727281 xulrunner 86996 57483 blueman85632 1199622xulrunner 75125 1340164glib-networking67872 740642 virtuoso-opensource62350 1739523kernel 60040 URL: http://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- kde-workspace -4 ▁▁▁▃█▆▁ kernel 2151 ▁▁▁▆▃▅█ firefox 324 ▄▁▂▁█▃▇ getmail 381 ▂▃█ virtuoso-opensource 260 ▂▁▂▇█▁▃ Most stabilized components: Component Jump Graph -- tracker -183 ▃▇█▃▅▁▁ xulrunner -198 ▅▇█▂▂▁▁ gnome-shell -193 ▄█▆▅▄▂▁ nautilus -86 ▅█▆▅▅▁▁ blueman -70 ▆▅█▇▇▂▁ Server URL: http://retrace.fedoraproject.org/faf/ Report a bug: https://github.com/abrt/faf/issues/new Server sources: https://github.com/abrt/faf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ABRT 2.2 with Python 3 support heading to Fedora
Hi, ABRT 2.2 adds support for Python 3 in form of two new packages: - abrt-python3 providing an API for problem manipulation and - abrt-addon-python3 adding support for collecting unhandled exceptions in python 3 applications. Packages are now available in rawhide and will land in updates-testing for f19 and f20 soon. They will get pulled automatically by abrt-cli and abrt-desktop virtual packages in future. Please help testing these, especially if you maintain some python 3 applications. https://admin.fedoraproject.org/updates/abrt-2.2.0-1.fc20,libreport-2.2.0-1.fc20 https://admin.fedoraproject.org/updates/abrt-2.2.0-1.fc19,libreport-2.2.0-1.fc19 RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1047085 Thanks, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: crash stats for Fedora 20
On 01/03/2014 03:35 PM, Josh Boyer wrote: On Fri, Jan 3, 2014 at 9:29 AM, Richard Marko rma...@redhat.com wrote: In last two weeks these components were crashing the most on Fedora 20: 3. kernel seen 4540 times (8% of all reports) http://retrace.fedoraproject.org/faf/problems/898437/ http://retrace.fedoraproject.org/faf/problems/1372844/ Is there some way to flag package versions as obsolete in retrace? The first report above is for a 3.9 kernel that we don't even support any more because F18 is well past 3.9. Currently no. It should be possible to integrate faf with bodhi so the server would be aware of obsolete packages. The second report is for a problem in a proprietary wireless driver that we don't ship or support. We've asked before, but apparently there's no way to stop from including that kind of thing in retrace? We want tainted reports but we won't show them or include them in these statistics by default. Related issues https://github.com/abrt/faf/issues/189 https://github.com/abrt/faf/issues/219 -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
crash stats for Fedora 20
In last two weeks these components were crashing the most on Fedora 20: 1. gnome-shell seen 12370 times (23% of all reports) http://retrace.fedoraproject.org/faf/problems/1380731/ RHBZ#995785 http://retrace.fedoraproject.org/faf/problems/1380807/ RHBZ#995785 2. gnome-software seen 5545 times (10% of all reports) http://retrace.fedoraproject.org/faf/problems/1343678/ RHBZ#1013270 http://retrace.fedoraproject.org/faf/problems/1403433/ RHBZ#1044237 3. kernel seen 4540 times (8% of all reports) http://retrace.fedoraproject.org/faf/problems/898437/ http://retrace.fedoraproject.org/faf/problems/1372844/ 4. rhythmbox seen 2593 times (5% of all reports) http://retrace.fedoraproject.org/faf/problems/1452772/ RHBZ#1047018 http://retrace.fedoraproject.org/faf/problems/1241887/ RHBZ#1013858 5. tracker seen 2273 times (4% of all reports) http://retrace.fedoraproject.org/faf/problems/1206163/ RHBZ#957533 http://retrace.fedoraproject.org/faf/problems/1374021/ RHBZ#1031752 Hot problems: ID Components Count --- 1380731gnome-shell 7408 1452772rhythmbox 2030 1343678gnome-software 1413 1160652speech-dispatcher976 1261972open-vm-tools840 1355243kernel 557 1380807gnome-shell 529 1324026gnome-tweak-tool 467 1287308gnome-shell 458 1282601nautilus 434 URL: http://retrace.fedoraproject.org/faf/problems/hot/fedora-20/*/*/ Long-term problems: ID Components Count --- 1380731gnome-shell 8074 1127716glib-networking 5946 1160652speech-dispatcher 2451 1343678gnome-software 2185 1261972open-vm-tools 1942 1250468gnome-tweak-tool1484 1324026gnome-tweak-tool1283 1282601nautilus1125 1178557kernel 891 250996 udisks2 674 URL: http://retrace.fedoraproject.org/faf/problems/longterm/fedora-20/*/*/ Server URL: http://retrace.fedoraproject.org/faf/ Report a bug: https://github.com/abrt/faf/issues/new Server sources: https://github.com/abrt/faf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 11/03/2013 03:43 PM, Christian Fredrik Kalager Schaller wrote: On Sun, 2013-11-03 at 14:42 +0100, Kevin Kofler wrote: That really didn't have anything to do with the merits of Objective C, or even of the desktop, but only with marketing. If Objective C were that great, we'd all be using GNUstep. Which was my point too, we spend way to much time arguing the merits of programming languages and similar and to little trying to focus on the things that the rest of the world actually care about. I think the most extreme example I can remember of this was someone trying to convince me once to use a web browser that didn't have any of the features I actually needed, like https support, 'because it had cleaner code'. So I am not saying that clean code and maintainability and ease of development is not important, but I think being a community dominated by coders we tend to put way to much emphasis on these things compared to actually solving peoples needs. If we were a community dominated by coders than yes, it might look like too much. Fortunately, we are also a community of software developers that value stuff like stability and quality more than features for the rest of the world that actually doesn't care about us that much. Currently, even your extreme example doesn't seem so extreme to me considering that it's quite hard to find browser that gives priority to improving its speed, stability and privacy instead of adding new features to keep up with the cool guys. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
abrt server report: 20130830
In last two weeks these components were crashing the most: 1. kernel seen 88743 times (58% of all reports) http://retrace.fedoraproject.org/faf/problems/1174076/ http://retrace.fedoraproject.org/faf/problems/909608/ 2. xulrunner seen 7513 times (5% of all reports) http://retrace.fedoraproject.org/faf/problems/727281/ http://retrace.fedoraproject.org/faf/problems/757169/ 3. tracker seen 5447 times (4% of all reports) http://retrace.fedoraproject.org/faf/problems/468273/ http://retrace.fedoraproject.org/faf/problems/1186527/ 4. meld seen 3947 times (3% of all reports) http://retrace.fedoraproject.org/faf/problems/138934/ RHBZ#971948 http://retrace.fedoraproject.org/faf/problems/997382/ 5. blueman seen 3781 times (2% of all reports) http://retrace.fedoraproject.org/faf/problems/57483/ RHBZ#878795 http://retrace.fedoraproject.org/faf/problems/20903/ RHBZ#875682 Hot problems: ID Components Count --- 1174076kernel 28063 909608 kernel 7179 138934 meld3896 727281 xulrunner 3233 57483 blueman 2737 1059468kernel 2379 1178557kernel 2333 822352 kernel 2163 1146230kernel 1364 757169 xulrunner 1213 URL: http://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 577402 libgsf 76735 727281 xulrunner 48737 57483 blueman32102 757169 xulrunner 30005 20295 gnome-shell28922 898437 kernel 24020 244577 xulrunner 21813 365559 setroubleshoot 18580 975227 evolution-data-server 17280 157490 mate-notification-daemon 16828 URL: http://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- kernel 3367 ▃▁▁▁▅▇█ mate-notification-daemon 531 ▁▁█ xulrunner222 ▁▃▄▂█▃▃ meld 41 ▆▁▁▇▅▇█ xscreensaver 13 ▂▁▃▆█▅▃ Most stabilized components: Component Jump Graph -- authconfig 1 ▁█▁ tracker -82 ▅▁▄█▁▂▁ virtuoso-opensource -3 ▁█▁ kdeartwork -29 █▃▁▃▃▂▁ totem-21 ▅▂█▁▂▃▁ Server URL: http://retrace.fedoraproject.org/faf/ Report a bug: https://github.com/abrt/faf/issues/new Server sources: https://github.com/abrt/faf Dry run enabled, not sending any emails -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora Tagger
On 05/14/2013 05:32 AM, Ralph Bean wrote: Try it out, help improve package search, and climb your way to the number-one tagger spot! It takes too long to load the next card after user clicks. You should probably preload more cards or load them asynchronously. Cheers, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT, Faf and current state of bug reporting
On 04/23/2013 07:46 PM, Kevin Fenzi wrote: On Tue, 23 Apr 2013 15:27:50 +0200 Richard Marko rma...@redhat.com wrote: Hi all, I'll try to explain how crash reporting currently works in Fedora. Typical reporting process looks like this: - crash is reported to Faf server which responds with 'known' or 'unknown' reply; - in case it responds with 'known' and the bug was already reported to both the server and bugzilla, the reporting is stopped and only report counts on the server are updated; Does the user get a link to any bugs associated with the crash? Or this happens without user interaction? He does. Both the link to faf and link to bugzilla (if ticket exists). - if the crash is unknown, the reporting either continues or stops depending on the configuration (for Gnome, only automated reporting to faf is enabled); - if enabled, the rest of the process continues with local or remote retracing, reporting to bugzilla and attaching bugzilla ticket to faf report. This allows us to get accurate statistics of crashing applications while not forcing every user to report to bugzilla. This is a trade-off between getting accurate statistics and quality of the reports as automated reports are anonymous which is also the reason why they can't contain full backtrace with data. Well, it's nice to know when things crash, sure... but without more information it's very difficult to figure out how to fix that crash. Then there are reports with no bugzilla attached as they were reported automatically or no one finished the bugzilla reporting. These reports get bugzilla ticket attached after there's person who finishes the reporting or the ticket is created by the server. Perhaps we could make it always require a person to be willing to file? Hopefully someone who can explain what happened and what they have installed, etc? ie, hey, look, 50 people saw this crash, but it has no bug yet, well, I know exactly what I do to cause it, let me file the bug and help all 50 of the other folks seeing it out Yes, this sounds good to me. I'll create tickets for this. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT, Faf and current state of bug reporting
On 04/23/2013 09:53 PM, Kevin Fenzi wrote: On Tue, 23 Apr 2013 15:45:34 -0400 Przemek Klosowski przemek.klosow...@nist.gov wrote: Well, here's an example why I think such information is highly useful: currently on my system every program using 3D (openGL/Mesa) crashes; that means everything: Blender, Avogadro, pymol, FreeCAD, openSCAD, and even everything that uses FLTK library because it renders both 2D and 3D through OpenGL: Program received signal SIGSEGV, Segmentation fault. intel_miptree_unmap (intel=0x18d1960, mt=0x0, level=0, slice=0) at intel_mipmap_tree.c:1752 1752if (mt-num_samples = 1) It's an Intel driver bug that seems pretty severe to me but I don't have the graphics chops to fix it: https://bugzilla.redhat.com/show_bug.cgi?id=94 Which seems to be also: https://bugzilla.redhat.com/show_bug.cgi?id=946960 and https://retrace.fedoraproject.org/faf/problems/786379/ I think it would help things if there were reliable statistics on its footprint. Is it just my Q45 or all Intel chipsets? is it just my weird configuration (two screens? update rather than fresh install? some configuration I did and forgot about?). That would be nice, but alas, we don't know and faf doesn't tell us. It's not easy to implement this because of privacy issues. There was already such request though so we'll consider implementing this. We know that there have been 32 instances of this crash recorded by faf. That doesn't tell us anything at all about the hardware or installed packages or screens or other info about those instances. All we know is that it happened 32 times (I suppose we don't even know it's 32 different machines even, could one person report a crash 32times?) Correct. List of installed packages related to the crash will be available. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT, Faf and current state of bug reporting
On 04/24/2013 09:43 AM, Stephan Bergmann wrote: On 04/23/2013 03:27 PM, Richard Marko wrote: This allows us to get accurate statistics of crashing applications while not forcing every user to report to bugzilla. This is a trade-off between getting accurate statistics and quality of the reports as automated reports are anonymous which is also the reason why they can't contain full backtrace with data. To clarify, is it so that from now on we'll always get (less detailed) [faf] bugzilla issues instead of the old (more detailed) [abrt] ones, or does that depend on how the user experiencing a crash interacts with ABRT? It depends on both the configuration and how the user interacts with ABRT. If there's a user who reports to bugzilla you'll get detailed report. If not, you'll only get report from faf when number of reports reaches certain threshold. We'll increase the threshold so there's higher chance of someone creating more detailed report. Even if you close these bugs with INSUFFICIENT DATA the server can point people there and they might provide required data. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ABRT, Faf and current state of bug reporting
Hi all, I'll try to explain how crash reporting currently works in Fedora. Typical reporting process looks like this: - crash is reported to Faf server which responds with 'known' or 'unknown' reply; - in case it responds with 'known' and the bug was already reported to both the server and bugzilla, the reporting is stopped and only report counts on the server are updated; - if the crash is unknown, the reporting either continues or stops depending on the configuration (for Gnome, only automated reporting to faf is enabled); - if enabled, the rest of the process continues with local or remote retracing, reporting to bugzilla and attaching bugzilla ticket to faf report. This allows us to get accurate statistics of crashing applications while not forcing every user to report to bugzilla. This is a trade-off between getting accurate statistics and quality of the reports as automated reports are anonymous which is also the reason why they can't contain full backtrace with data. Then there are reports with no bugzilla attached as they were reported automatically or no one finished the bugzilla reporting. These reports get bugzilla ticket attached after there's person who finishes the reporting or the ticket is created by the server. The intermediate part of the stack, faf server, is still pretty new so please bear with us as we are dealing with lots of data. The goal of the server is to provide accurate statistics of crashing applications and clustering of the incoming reports. Hope this helps to clarify the situation a bit. Feedback is always welcome, especially if you are receiving bug reports you are not happy with. Please use [1] for reporting issues if our mailing list [2] is not an option for you. [1] https://github.com/abrt/faf/issues/new [2] crash-catc...@lists.fedorahosted.org Best regards, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from Crash Catcher with [faf] in the subject line
On 04/23/2013 05:27 PM, Christoph Wickert wrote: Am Montag, den 22.04.2013, 16:05 +0200 schrieb Richard Marko: More feedback is welcome. 1. Announce changes like this one in advance on devel-announce. I will. 2. Provide some documentation about FAF. What do these bugs mean to developers and package maintainers. hat are we supposed to do? Please read my other email from today (ABRT, Faf and current state of bug reporting) and let me know if it's sufficient. Cheers, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Receiving bugs from Crash Catcher with [faf] in the subject line
On 04/22/2013 02:24 PM, Dan Mashal wrote: Seems like someone turned on a bot this morning. Just a heads up.. these have [faf] in the subject line and seem to be filing bugs on old components (for me at least). Looks like it's just starting to make the rounds. Who owns this? Dan Yes, we did that and started filing bugs for everything that seemed worth (even old stuff). After initial sync between bugzilla and faf server it won't create as much tickets for old components as it does now which is partially caused by the order in which the bot creates these tickets. Creation of new tickets is stopped for now until we fix few issues reported to us. More feedback is welcome. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/28/2013 05:56 PM, inode0 wrote: https://fedoraproject.org/wiki/Statistics#Total_repository_connections I'm wondering if there was an effort to provide package usage statistics for Fedora. Having such data might be valuable when there's a disagreement of what is popular/widely used. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
abrt server report: 20121211
Hot problems: ID Components Count --- 121163 kernel 344 118396 kernel 316 100107 gnome-packagekit 204 117748 gnome-packagekit 199 19369 control-center 154 20085 gnome-terminal 137 123131 kernel 131 83012 tracker 130 119523 kernel 122 112152 mate-session-manager 121 URL: https://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 121163 kernel 1802 19369 control-center 1209 100107 gnome-packagekit1008 83012 tracker 944 118396 kernel 806 20085 gnome-terminal 802 117748 gnome-packagekit 687 121884 tracker 624 54879 tracker 616 109109 zenity 602 URL: https://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- mate-session-manager 17 ??? alacarte 9 ??? gcalctool 3 ??? firefox 11 ??? vino 7 ??? Most stabilized components: Component Jump Graph -- kernel -33 ??? tracker -16 ??? python-1 ??? gnome-packagekit -20 ??? mate-file-manager -9 ??? Server URL: https://retrace.fedoraproject.org/faf/ Report a bug: https://fedorahosted.org/abrt/newticket?component=faf Server sources: https://git.fedorahosted.org/cgit/faf.git/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
abrt server report: 20121126
Hot problems: ID Components Count --- 90599 kernel 406 91614 kernel 303 90633 gnome-packagekit 212 92490 zenity 170 83012 tracker 163 19369 control-center 154 83612 tracker 145 92352 kernel 137 21780 control-center 137 20085 gnome-terminal 135 URL: http://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 90599 kernel 1449 19369 control-center 1047 90633 gnome-packagekit 834 83012 tracker 811 20085 gnome-terminal 657 45076 tracker 613 54879 tracker 545 21794 control-center 526 83612 tracker 520 92490 zenity 513 URL: http://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- kernel 5 ??? gnome-terminal14 ??? ailurus4 ??? gnome-packagekit 14 ??? alacarte 3 ??? Most stabilized components: Component Jump Graph -- tracker -20 ??? evolution-11 ??? rhythmbox-14 ??? control-center-5 ??? java-1.7.0-openjdk-5 ??? Server URL: http://retrace.fedoraproject.org/faf/ Report a bug: https://fedorahosted.org/abrt/newticket?component=faf Server sources: http://git.fedorahosted.org/cgit/faf.git/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 10/16/2012 08:22 PM, David Lehman wrote: On Tue, 2012-10-16 at 15:29 +0200, Dario Lesca wrote: Hi, I have download the last Fedora-18-Beta-TC4 to do some tests http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/Fedora-18-Beta-TC4-x86_64-netinst.iso How to install it on a empty disk and use LVM (or create a software RaID)? From the new disk manager anaconda panel I did not understand how to create a new LVM partition and root and swap volume. 1. Click the + button near the bottom of the screen. 2. Enter '/' for mountpoint and whatever size you want. 3. Hit Confirm or Add or whatever the dialog button is. 4. Select the new mountpoint on the left side of the screen. 5. Click the + on the right side of the screen to edit the device options. 6. Select your desired device type from the available options, which will include LVM. Repeat for swap. (Hint: enter swap as the mountpoint when adding the device initially) Previous structured partitioning dialog was much better compared to this. Why it was removed in favor of this confusing thing? Various tips: Both the size and mountpoint entries in the Add Mountpoint dialog have tooltips, so hover the mouse pointer on them if you are in doubt as to how to specify these things. If you want the device you are adding to grow to occupy as much space as is possible, leave the size field blank when adding the device initially. When editing a defined device, if you want to make it as large as possible, specify a size greater than the available space. The installer will grow the device as close to your requested size as possible. This also works when adding a new device. Devices are not treated as growable once they have been defined, so if you define one device with a blank size and then try to define another without adjusting the first one, it will probably fail due to insufficient free space. This makes sense if you think about it, so don't file a bug for it. Is this features not yet supported or I have lost some HOWTO? There's a very brief HOWTO above. I am hoping to produce a basic beginners' guide at some point, but time is scarce. Many thanks -- Dario Lesca - sip:da...@solinos.it (Inviato dal mio Linux Fedora 17 Gnome3) -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On 10/09/2012 05:00 PM, Matthew Miller wrote: On Tue, Oct 09, 2012 at 10:45:24AM -0400, Matthew Miller wrote: c) it auto-pages if run on a tty Hmmm. That's not necessarily what people are expecting, but okay. To expand on this: there is a general expectation that non-interactive console tools will return control to the user immediately. Auto-paging is a different user-experience that doesn't necessarily dovetail with the Linux lineage. UI and UX aren't _just_ for GUI programs, after all. If we want to sell journalctl (and systemd in general) as a step forward for sysadmins, we need to take the sysadmin user commmunity's UI expectations seriously. Compared to the other things I mentioned this is less important (because hey, sysadmins can learn new ways!), but I wanted to elaborate on where this is coming from. +1. For example swapping action and name parameters for systemctl compared to service calls is just annoying. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt server report: 20121004
On 10/04/2012 08:13 PM, Dave Jones wrote: On Thu, Oct 04, 2012 at 11:10:47AM -0400, Dave Jones wrote: Feature request: Can you do the same backtrace hashing abrt does, and provide a link to any bugs in bugzilla with the abrt_hash in the whiteboard ? Never mind. It seems you do that, and I was looking at reports where no bug had been filed. Perhaps print no bug filed yet in that case ? Something else just occurred to me, that might be useful, would be to print the top-most function in the summary page. Looking at https://retrace.fedoraproject.org/faf/problems/hot/*/*/kernel/ it would be useful if I could see at a glance that bug 13935 was a wireless bug, without needing to click into it. I agree. But... A lot of the 'function' fields on kernel bugs are going to be the same. warn_slowpath_common or warn_slowpath_null. We have a billion WARN() statements all over the kernel, and it's more useful knowing the location of where those are placed than the function name of the WARN statement. We will add the location and line numbers to these reports but the implementation is not ready yet. Ie, the summary for https://retrace.fedoraproject.org/faf/problems/13955/ should show function: brcms_c_wait_for_tx_completion. There may be a few other function names that would also require similar special casing. Sounds good. I've created tickets for all these improvements. Thanks! -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt server report: 20121004
On 10/05/2012 04:48 AM, Adam Williamson wrote: On Thu, 2012-10-04 at 11:10 -0400, Dave Jones wrote: Feature request: Can you do the same backtrace hashing abrt does, and provide a link to any bugs in bugzilla with the abrt_hash in the whiteboard ? Never mind. It seems you do that, and I was looking at reports where no bug had been filed. Perhaps print no bug filed yet in that case ? Wait, how do we have reports with no bugs? If you cancel reporting to the bugzilla or it isn't successful no bug is assigned to the report on the server. It might be added later when someone completes the reporting. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
abrt server report: 20121004
Hot problems: ID Components Count --- 11834 GConf2 199 11523 control-center 186 8300 kdebase-runtime, glibc, glib2, qt161 11431 kernel 159 11514 kernel 151 12245 control-center 134 11656 gnome-packagekit 129 6217 tracker 114 13018 tracker 107 6863 glibc, glib2 106 URL: https://retrace.fedoraproject.org/faf/problems/hot/ Long-term problems: ID Components Count --- 11523 control-center 375 11656 gnome-packagekit 358 12245 control-center 326 6863 glibc, glib2 302 7137 gnome-packagekit 292 8080 tracker 267 6217 tracker 266 6975 gnome-terminal 240 13018 tracker 220 9408 cairo, libX11, gtk3 217 URL: https://retrace.fedoraproject.org/faf/problems/longterm/ Most destabilized components: Component Jump Graph -- kernel 220 ▁▂▄▅▇▇█ nepomuk-core 35 ▁▂▆▃▆█▅ gnome-shell 11 ▄▃▁▁█▁▇ coreutils 2 █▂▁ xfce4-panel7 ▁▁▃▃▁▆█ Most stabilized components: Component Jump Graph -- tracker -23 ▆▆█▆▂▃▁ libreport 2 ▁█▅ totem-16 ▇█▁▃▃▁▂ java-1.7.0-openjdk-9 █▆▁▁▁▃▂ GConf2 -11 █▂▁▇▁▃▃ What's this about? -- These are the statistics generated by ABRT Server deployed on [1]. We are going to send these reports weekly as they should help developers prioritize their work. We expect them to become more and more accurate as more people will start using new versions of ABRT with simplified reporting [2]. Note that kernel is incorrectly blamed as the most destabilized component as we started handling kerneloops reports only last week. Feedback is really appreciated mainly on these topics: - structure of this email, - clustering quality, - backtrace quality, - kerneloops processing. [1] https://retrace.fedoraproject.org/faf/ [2] https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt server report: 20121004
On 10/04/2012 05:00 PM, Peter Robinson wrote: On Thu, Oct 4, 2012 at 3:52 PM, Richard Marko rma...@redhat.com wrote: Hot problems: ID Components Count --- 11834 GConf2 199 11523 control-center 186 Could we make the referenced ID the RHBZ ID for the crash. It makes it more useful for people to cross reference. I have no idea what that ID stands for and for example is 11843 a single problem with GConf2 that has occurred 199 times or is that all the problems for GConf2 added up. The single problem may have more than one attached bugzilla which depends on reports clustered to that single problem. Another issue with using RHBZ ID is that the cluster of related reports may change over time as we get more reports which sometimes leads to splitting/merging of different clusters (problems). So in case of problem ID, ideally, it should represent single issue with the affected component(s) provided that the clustering algorithm works correctly. -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT Server
On 09/05/2012 07:47 PM, Dave Jones wrote: On Wed, Sep 05, 2012 at 11:39:31AM +0200, Michal Toman wrote: We believe this will help developers to better prioritize their work and make debugging easier (crashes in common libraries are grouped into a single problem, for each crash versions of affected packages/architectures are listed etc.). The 'hot problems' will be very useful for us, as we were just talking last week about reporting such a list upstream periodically. I looked at the only kernel bug caught so far.. https://retrace.fedoraproject.org/faf/reports/452/ 'my_init' isn't part of the kernel package. Could you add some way of filtering out reports from things we don't ship ? Or was this a test-case ? Yes, this was a test-case. Support for kernel oops reporting is not yet in F17, we will add it with the next update. Related: How would I close reports so they don't show up on the list ? Not possible at the moment. For now, server will track associated BZs and close reports automatically. We will add this functionality along with FAS integration. Further related: Clicking 'login' makes this happen.. snip followed by 3-4 pages of additional spew. Debug disabled, we will fix the login URL soon. Thanks for the feedback! -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: P2P Packaging/Koji Cloud
On 12/07/2011 02:46 PM, Denis Arnaud wrote: Hello, RedHat-hosted Koji servers offer an invaluable service by allowing all of us, package maintainers, to build all of our Fedora packages. I guess that that infrastructure is not cost-less for RedHat and and the quality of service is great (for instance, the wait in the queues, before Koji actually builds the packages submitted via the command-line client, is not so long). As Fedora is pretty advanced in the cloud/virtualisation arena, we could imagine a Koji Cloud, hosted on VMs offered by volunteers. For instance, I could contribute a few VMs in Europe (hosted on http://www.ovh.co.uk/). Our Cloud SIG (https://fedoraproject.org/wiki/Cloud_SIG) and/or Virt ML (https://admin.fedoraproject.org/mailman/listinfo/virt and https://fedoraproject.org/wiki/Getting_started_with_virtualization)/RedHat ET (http://et.redhat.com/) colleagues could help designing and implementing the following infrastructure: * VM template/images, ready to be started on the volunteer's servers everywhere in the world, 24x7. - SSH public keys of Koji administrators would be part of the images, so that they can have an easy access to them, just in case. - Those VMs would update themselves automatically. - The containers could be standardised as well. For instance, ProxMox/OpenVZ or Fedora/CentOS with libvirt. * A directory (LDAP, or something less centralised, like the address book of Skype, for instance), keeping track of all those VMs: - with the corresponding last known status; - with the VM configurations (Fedora/CentOS release, CPU, memory, disk usage, etc); - with some rating corresponding to their quality of service (build duration, reliability of the VM, MTBF, etc). * A dispatcher system: - which would route the Koji build requests to available VMs; - collect the outcome of the builds (logs, RPM packages, statistics, QoS, etc) and store them in the current (centralised) Koji infrastructure. As I am not a specialist of all those technologies, I may have forgotten a lot of things, but you get the idea. Doesn't it sound great? Does it sound realisable? Am I crazy to dream to such an infrastructure? I'm currently writing a proposal of similar architecture for testing purposes. Looks like the core -- community provided virtual machines is the common component for all this stuff so if designed correctly it can be shared for testing/koji/whatever. I will let you know when the proposal is done so we can discuss the details. Regards, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
