Re: Marking zapped bugs
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. This is the best we can do no matter what we want to do! P.S. Believe me having open bugs that both the packager and the submitter care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation. Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. This is the best we can do no matter what we want to do! P.S. Believe me having open bugs that both the packager and the submitter DON'T care for (sorry for the typo) care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation. Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Le 05/11/2010 03:10, Rahul Sundaram a écrit : On 11/05/2010 06:41 AM, Dennis Jacobfeuerborn wrote: Considering that it was started by a Red Hat employee, I would say there has already been some involvement Rahul Kristian does not work for Red Hat anymore but at Intel OSTC. Will Ubuntu really move towards Wayland and furthermore start working upstream on it ? let's wait and see. By the way, is Wayland really usable and since Kristian's departure, is Red Hat still involved in the project ? H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, Nov 04, 2010 at 11:58:21PM +, Jóhann B. Guðmundsson wrote: On 11/04/2010 10:22 PM, Orcan Ogetbil wrote: 2- ABRT should keep track of unresponsive users. If a user has an outstanding needinfo? flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages. Since this has turned into general pony request to the ABRT I shall throw in one for the reporters On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com. 3- Ability to turn off ABRT for certain packages. Whenever I provide an application package with no nonstandard patches and there is a crash, it is most definitely not my fault. The user should be instructed to take the backtrace upstream to the URL of the package and report it in their bug tracker/mailing list. Even better, ABRT can file the bug directly upstream. I am willing to provide the information of upstream bug trackers/mailing lists for all of my packages. This confusion has been going on for enough of release cycles already and I think it's time for FPC to step in and clarify what are the maintainers/packagers responsibility towards the Fedora community and it's user base to avoid any further rifts between QA members and maintainers. This one's fesco, not fpc. (Policy about maintaining packages rather than how to create quality packages). Perhaps a slightly easier to implement method of achieving something similar would be to orphan packages that have ignored bug reports rather than to remove their bugzilla components. So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording) Alex -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 05/11/10 07:27, Alexander Kurtakov wrote: So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs I think maybe it is meant more as You have 100 bugs, 80 are not acknowledged. I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording) Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers. Just a thought. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unable to push to git this morning
[mbo...@t500 virt-v2v (f14)]$ git push origin f14 Total 0 (delta 0), reused 0 (delta 0) remote: C refs/heads/f14 mdbooth DENIED by refs/heads/f[0-9][0-9] remote: error: hook declined to update refs/heads/f14 To ssh://mdbo...@pkgs.fedoraproject.org/virt-v2v ! [remote rejected] f14 - f14 (hook declined) error: failed to push some refs to 'ssh://mdbo...@pkgs.fedoraproject.org/virt-v2v' I'm the owner of this package and I pushed to rawhide yesterday, so permissions shouldn't be an issue. On a related note, is there a fedpkg command which pushes to a branch? The obvious 'fedpkg push' pushes only master regardless of which local branch you're on: [mbo...@t500 virt-v2v (f14)]$ fedpkg push Everything up-to-date Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to push to git this morning
Matthew Booth mbo...@redhat.com writes: [mbo...@t500 virt-v2v (f14)]$ git push origin f14 $ git push origin f14:f14/master (It was a very bad idea to name the local branches differently than the remote branches.) Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
On 11/04/2010 08:32 PM, Michael Schwendt wrote: On Thu, 4 Nov 2010 17:41:34 + (UTC), Daniel wrote: Release of libxml2-2.7.8 libxml2.spec | 10 -- Seems to break the koji build root due to ABI incompatibility. Dependent packages should be rebuild. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, Nov 05, 2010 at 02:11:22AM +0100, Dennis Jacobfeuerborn wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? 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
Re: coming libnotify bump
Am Montag, den 01.11.2010, 21:12 -0400 schrieb Matthias Clasen: I am planning to push libnotify 0.7.0 into rawhide by the end of this week; Next time you are making an update that affects a large number of packages, please use devel-announce. TIA, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/05/2010 07:47 AM, Frank Murphy wrote: On 05/11/10 07:27, Alexander Kurtakov wrote: So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs I think maybe it is meant more as You have 100 bugs, 80 are not acknowledged. I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording) Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers. We already have QA dedicated group to aid maintainers and it's called triagers and a whole range off testers which can be pinged on irc or on the test-list even for a period of time we had a automatic responce reply to all bugs which was to lower the expectation of new/inexperienced reporters but it did not fix the underlying problem.. Reports came in Auto responce reply back to the reporter -- QA verified try to duplicate bug -- Bug set to maintainer -- Bug stayed like that until EOL We have had watercooler discussion on irc amongs ourself in QA on and off through several release cycles now to assign or ask a tester/triager to spesific components which have an actual maintainer behind them ( not speaking about packagers here ) to take the load of develepers and in some cases testers have done so on their own initiative because they just love the application they are running as a potentiall solution but we have not written anything down or come up with some concrete plan to aim at and work on. One of the problem to solve with that is how we can equally cover all componets since we fear that users would cherry pick and jump on the component they love and leave more underthehood critical components out. Basically popular component nr1 has 30 testers/triager while more vital critical component nr1 has 0.. Perhaps assign/rotate method would work in this case users a and b assign to component a this day/week while c and d take care of component b but as I mentioned all of this is just more or less ideas in our heads and have been so for a while. Ofcourse this would only apply to responsive ( upstream ) maintainers but not packagers and unresponsive maintainers since nonresponsive maintainer is still a nonresponsive maintainer and spending anykind of community resources on them is just a waste of everbodys time.. QA service like this might actually attract more upstream developer to participate and join the project. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Java SIG pseudo user and package monitoring
Java SIG pseudo user has been created with commit emails from monitored packages[1] flowing to java-devel mailing list (thanks to tibbs and mjw). If you want java-sig to monitor and check your commits you can add java-sig pseudo user to CC for your package. For old packages follow [2]. For new packages that you want to have monitored just add java-sig to CC when asking for SCM. This is not mandatory (at least for now), but still encouraged for java packages :-) One thing to note: email of java-sig is java-devel mailing list but emails will be comming as if from comitter's email address as present in FAS (or from email it was set-up with it seems). Currently java-devel ML is set-up to allow messages from @fedoraproject.org mail addresses. It will reject commit messages from other email addresses. If you add java-sig to CC and your commits will not get in, contact me off-list and I'll add exception for your email address. [1] https://admin.fedoraproject.org/pkgdb/users/packages/java-sig [2] https://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages -- Stanislav Ochotnicky sochotni...@redhat.com 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
Orphaning some packages
Hi All, Unfortunately I don't have the time to proper maintain the packages below. So I believe it is better to orphan them, and have just done so. If you're interested in any of these feel free to pick them up bochs - Portable x86 PC emulator I believe everyone is pretty much using qemu now. If not I hope someone else will pick this up crystalspace - 3d engine I packaged this for 2 reasons: 1. so that people who wanted to develop code with it could do so easily on Fedora 2. to maybe package some games which use this 2. never happened due to lack of good candidates. Currently upstream has version 1.4, and we are shipping 1.2.x, so for 1. this package also is useless unless upgraded (bug 585439). cel - Crystal Entity Layer (CEL) A scripting language for crystalspace TnL - A futuristic action flight simulator game Dead upstream, never really finished / completed by upstream TnL-data - data files for TnL Io-language - programming language I packaged this as a dep for TnL. Could also be useful to some people by itself, needs an update to latest upstream (bug 597451). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
Frank Murphy said the following on 11/05/2010 12:47 AM Pacific Time: On 05/11/10 07:27, Alexander Kurtakov wrote: So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs I think maybe it is meant more as You have 100 bugs, 80 are not acknowledged. I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording) Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers. We've been trying to do that and get it off the ground for several years. It hasn't exactly flourished. DISCLAIMER: I'm not a package maintainer, but I have been involved with bug triage and was around the original effort to get Fedora bugzilla under control. I've always believed our core need is more maintainers if the goal is *fixing* and *resolving* bugs. Triage and debugging help only goes so far. It took several posts to devel-announce, personal emails, and weekly meetings during the roll up to Alpha, Beta, and Final, just to get information and help with ~20 blocker bugs. Addressing ~12,000 other open bugs will require something different. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bringing a retired package (tritonus) back from the dead?
Hi, I would like to bring tritonus back from the dead (as it is a dependency for vorbisspi, which is needed to be able to playback .ogg files under java). I'm pretty sure this has been discussed before, but there does not seem to be anything written about it on the wiki (or I cannot find it). So iirc the procedure is to just file a review request as of it is a new package, skip the cvs^w git module creation step and ask rel-eng to unblock once the review + new builds are done, right ? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, 2010-11-05 at 02:11 +0100, Dennis Jacobfeuerborn wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ Until recently, wayland required private branches of quite a few dependencies. But it should be possible to build wayland against F15 packages now, or at least it should be soon. If somebody wants to give this a try, I'd be happy to review packages. Wayland certainly still has a way to go before we can think about replacing X altogether, but many pieces of this puzzle have been falling into place, and with the increased interest (and hopefully contribution), we may see it happen sooner rather than later. Watch out for that 'gnome-shell on wayland' post... :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bringing a retired package (tritonus) back from the dead?
On Fri, Nov 5, 2010 at 11:03 AM, Hans de Goede wrote: Hi, I would like to bring tritonus back from the dead (as it is a dependency for vorbisspi, which is needed to be able to playback .ogg files under java). I'm pretty sure this has been discussed before, but there does not seem to be anything written about it on the wiki (or I cannot find it). So iirc the procedure is to just file a review request as of it is a new package, skip the cvs^w git module creation step and ask rel-eng to unblock once the review + new builds are done, right ? That's correct. I was the last maintainer of tritonus. If you need someone to do the review just let me know. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 643979] Strange byte sequence for attribute with no values (nsslapd-referral)
Hi, Please review the patch for the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=643979 https://bugzilla.redhat.com/attachment.cgi?id=458122action=edit https://bugzilla.redhat.com/attachment.cgi?id=458122action=diff Thanks! -- Endi S. Dewata -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] One Way AD Sync
Nathan Kinder wrote: Please review these design notes for implementing one way AD sync. In particular, I'm concerned about the possible inconsistencies that can arise from directly modifying a synced entry on the DS side. Does using access control seem sufficient for avoiding these inconsistencies? How would you use access control? If these notes look OK, I'll get everything posted up on the 389 wiki. Thanks, -NGK One Way Sync Some deployments would prefer that AD sync is only performed in one direction. More specifically, updates will be pulled from AD, but changes to DS will not be pushed back to AD. Ideally, one would restrict direct updates to synchronized entries in DS by configuring access control. To implement one-way sync, we need to add a new configuration attribute to the sync agreement entry. This attribute will be named oneWaySync and will default to false if it is not specified to maintain backwards compatibility. When this attribute is set to true, updates will only go in the AD-DS direction. If one way sync is enabled and changes are made to a synced entry on the DS side, a replication session with AD will be started. In this session, we will not send any updates, but we will send the Dirsync control to AD to pull any updates. This will result in an inconsistency in the modified entry between AD and DS. This inconsistency will be resolved the next time any update is made to the entry on the AD side since we compare the entire entry between AD and DS when we receive a change via Dirsync. To avoid these inconsistencies, it is recommended to not allow direct updates to synced attributes in entries on the DS side. Another inconsistency that can occur is if a synced entry is directly deleted from DS. This deletion is not sent to AD. In this case, an update to the entry on the AD side will result in the entry being added back to DS. The direct deletion of synced entries on the DS side should be avoided to prevent these inconsistencies. Inside of the replication plug-in, we simply skip sending updates in both the total and incremental replication protocol sessions when using a one way sync agreement. We don't want to change the RUV implementation for a one way sync agreement, so we will just fast-forward the RUV that we maintain for the AD system as if we had successfully sent the changes. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Ubuntu moving towards Wayland
On Fri, Nov 5, 2010 at 11:57 AM, Richard W.M. Jones rjo...@redhat.com wrote: What's the implication for people who absolutely need to use X applications remotely? I believe the idea for the overall plan is that the traditional X server grows the ability to be a Wayland client and that any normal distribution would be shipping and X server as Wayland client. Now if you aren't a traditional distribution and plan to build something like a mobileOS with its own walled garden...the X server as Wayland client isn't so necessary. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
Orcan Ogetbil, Wed, 03 Nov 2010 21:02:02 -0400: 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. Have you ever tried to explain to reporter that he need to reproduce the crash (which he has no idea how to do in the first place), then generate the backtrace using gdb? I did, many times, and I think ABRT is a great idea. Except for those duplicates I believe that abrt's ability to find duplicates got much better lately, so it might be possible we will get another avalanche of closing ABRT bugs when F13 will go out EOS, but I believe it got much better in F14. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC The ratio of literacy to illiteracy is a constant, but nowadays the illiterates can read. -- Alberto Moravia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/05/2010 05:41 PM, Matej Cepl wrote: Orcan Ogetbil, Wed, 03 Nov 2010 21:02:02 -0400: 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. Have you ever tried to explain to reporter that he need to reproduce the crash (which he has no idea how to do in the first place), then generate the backtrace using gdb? I did, ABRT doesn't. It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports Also, this produces incomplete traceback in many (IMO all) cases. many times, and I think ABRT is a great idea. I beg to differ ... It's an interesting idea, but still has to prove its viability and sustainability. I for one am having strong doubts. Except for those duplicates ... and its arcane GUI ... and it being useless without GBs of spare diskspace and bandwidth [I just had a nautilus crash ... ABRT wanted to install ca. 100 debug infos. Please understand why I dod not report this crash] ... and it confronting/molesting un-educated/ordinary users who are not able or interested to cope with ABRT/bugzilla etc. [Do you expect a secretary for who Firefox just crashed to be wanting a redhat bugzilla account?] ... and many many other details. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, Nov 05, 2010 at 11:12:09AM -0400, Matthias Clasen wrote: On Fri, 2010-11-05 at 02:11 +0100, Dennis Jacobfeuerborn wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ Until recently, wayland required private branches of quite a few dependencies. But it should be possible to build wayland against F15 packages now, or at least it should be soon. If somebody wants to give this a try, I'd be happy to review packages. Last time I tried the big problem was Cairo-drm wasn't enabled in our cairo packages. Granted that was a while ago. Also I don't know the status of drivers other than Intel getting the page-flip ioctl in the kernel, which is the other major prerequisite. Wayland certainly still has a way to go before we can think about replacing X altogether, but many pieces of this puzzle have been falling into place, and with the increased interest (and hopefully contribution), we may see it happen sooner rather than later. The code definitely needed some more eyes last time I poked it. Its completely undocumented in most places, duplicates macro declarations across multiple files, and essentially implements its own version of point-to-point dbus (the politics there aren't quite so simple, as there may be an argument for Wayland doing its own IPC, even if it does seem rather too elaborate). I'd love to see things move this way though. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, Nov 05, 2010 at 12:07:30PM +, Daniel P. Berrange wrote: On Fri, Nov 05, 2010 at 11:57:56AM +, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 02:11:22AM +0100, Dennis Jacobfeuerborn wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? You can run an X server as a client of Wayland, so you should get full compat with any existing X app usage. Similar to how you can run an X server under OS-X or Win32. The situation on OS X is pretty sucky (and Win32 as well, but for many more reasons). Native OS X apps aren't network transparent. You just can't run them remotely at all without some horrible thing like VNC. X11 apps are second-class citizens, requiring longer start-up times, incompatible menus, poor cut and paste and poor font rendering. If we're advocating that situation, then this is a huge step backwards. Network transparency in particular is absolutely essential to me as a user. Stepping to a pre-Internet non-network-aware single user model is simply crazy. Nevertheless, no one has actually answered the question as to whether Wayland native apps are network transparent or not. Do they use the X protocol at all? $DISPLAY? (And I admit I ain't looked at the code to try to answer these questions either). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, 04 Nov 2010 09:38:35 -0700, Adam wrote: On Thu, 2010-11-04 at 13:28 +0100, Michael Schwendt wrote: So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ? Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12? you're looking at it through a 'moral' framework when the important thing is the 'practical' framework. :) The practical point is that F12 is about to go EOL which means the bug must be closed... It is inefficient, if some time later another user needs to report the same issue only to get ignored, too. It is not encouraging our users to spend time on reporting bugs and on replying to NEEDINFO or other questions in the tickets. The warning that the ticket may be closed could have been given _much_ earlier, e.g. after two months of silence with no reply from the maintainer(s). Or at release time of F(N+1) Beta. Much worse if it's the second time a ticket is closed because of EOL. It's just poor form to ignore a user's bug report completely. I've received bugzapping mails for various issues, including packaging mistakes that have not been examined since F12. For example: http://bugzilla.redhat.com/516352 UNLESS it's still present in later releases. It's the reporter who is most likely to be able to say whether it is, therefore, we ask the user to check and update the bug, not the maintainer. This is ridiculous because of very poor timing and because bugs may not always be reproducible. What makes you think the reporter can find the free time to handle a flood of EOL tickets? It may be 'fairer' to set needinfo maintainer, but the result sure wouldn't be as good in practical terms, because the maintainer is less likely than the user to actually be able/inclined to provide the required data. I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects magically with lots of code rewrites). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/04/2010 06:22 PM, Orcan Ogetbil wrote: 2- ABRT should keep track of unresponsive users. If a user has an outstanding needinfo? flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages. That's a little harsh---I have been in situation when I couldn't reply to a 'needinfo' because e.g. I upgraded in the meantime, or I'd have to reboot to a different kernel or something like that. I think it's OK to close the bug if 'needinfo' is several weeks old. Would that satisfy your needs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Koji build fail for el5/el6
Hello fellow Fedorans. I'm trying to build a new package for Fawkes which has just passed review. It build fine on f13/f14/f15, but it fails on el5/el6 with an error that seems to be related to the build system, not to the actual package. Koji Builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=2580299 https://koji.fedoraproject.org/koji/taskinfo?taskID=2580290 Git: http://pkgs.fedoraproject.org/gitweb/?p=fawkes.git If you look into the root log, you can find the following errors: DEBUG util.py:82: remove tree: /var/lib/mock/dist-6E-epel-build-919001-135356/root/builddir DEBUG util.py:294: Executing command: ['/usr/sbin/userdel', '-r', 'mockbuild'] DEBUG util.py:333: Child returncode was: 6 DEBUG util.py:294: Executing command: ['/usr/sbin/groupdel', 'mockbuild'] DEBUG util.py:260: groupdel: group 'mockbuild' does not exist DEBUG util.py:333: Child returncode was: 6 and DEBUG util.py:82: remove tree: /var/lib/mock/dist-5E-epel-build-919006-135362/root/builddir DEBUG util.py:294: Executing command: ['/usr/sbin/userdel', '-r', 'mockbuild'] DEBUG util.py:260: userdel: error removing directory /builddir DEBUG util.py:333: Child returncode was: 12 DEBUG util.py:294: Executing command: ['/usr/sbin/groupdel', 'mockbuild'] DEBUG util.py:260: groupdel: group mockbuild does not exist DEBUG util.py:333: Child returncode was: 6 I had seen this once before two weeks ago or so for another package. Back then a simple resubmission worked and did the trick. But not this time, I resubmitted the el5 job twice, everytime the same error. Any idea what is causing this, or how it can be solved? Should I file a bug (against what, which tracker)? Tim -- Tim Niemueller t...@niemueller.de www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Fatal] Created tag perl-Test-Fatal-0.003-1.fc15
The lightweight tag 'perl-Test-Fatal-0.003-1.fc15' was created pointing to: 781ff92... Initial import of perl-Test-Fatal 0.003-1 -- 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: Koji build fail for el5/el6
On Fri, 05 Nov 2010 14:47:38 -0400 Tim Niemueller t...@niemueller.de wrote: Hello fellow Fedorans. I'm trying to build a new package for Fawkes which has just passed review. It build fine on f13/f14/f15, but it fails on el5/el6 with an error that seems to be related to the build system, not to the actual package. ...snip... I had seen this once before two weeks ago or so for another package. Back then a simple resubmission worked and did the trick. But not this time, I resubmitted the el5 job twice, everytime the same error. Any idea what is causing this, or how it can be solved? Should I file a bug (against what, which tracker)? The userdel seems unrelated to the real problem: DEBUG util.py:260: No Package Found for gearbox-devel = 9.11 DEBUG util.py:260: 0:urg-devel-0.8.7-2.el5.x86_64 DEBUG util.py:260: 0:glibmm24-devel-2.12.10-1.el5.x86_64 DEBUG util.py:260: 0:avahi-devel-0.6.16-9.el5_5.x86_64 DEBUG util.py:260: 0:libkni3-devel-3.9.2-12.el5.x86_64 DEBUG util.py:260: No Package Found for libdaemon-devel = 0.14 DEBUG util.py:260: 0:libjpeg-devel-6b-37.x86_64 DEBUG util.py:260: 0:gtkmm24-devel-2.10.10-1.el5.x86_64 DEBUG util.py:260: No Package Found for file-devel DEBUG util.py:260: 0:libglademm24-devel-2.6.3-3.el5.x86_64 DEBUG util.py:260: 0:lua-devel-5.1.4-4.el5.x86_64 DEBUG util.py:260: No Package Found for xmlrpc-c-devel DEBUG util.py:260: No Package Found for libdc1394-devel = 2.1 DEBUG util.py:260: No Package Found for player-devel = 3.0 DEBUG util.py:260: 0:gcc-c++-4.1.2-48.el5.x86_64 DEBUG util.py:260: No Package Found for graphviz-devel = 2.22 DEBUG util.py:260: 0:SDL-devel-1.2.10-8.el5.x86_64 DEBUG util.py:260: 0:libmicrohttpd-devel-0.4.6-1.el5.x86_64 DEBUG util.py:260: 0:asciidoc-8.1.0-1.el5.noarch DEBUG util.py:260: 0:gconfmm26-devel-2.14.2-1.el5.x86_64 DEBUG util.py:260: 0:flite-devel-1.3-11.el5.x86_64 DEBUG util.py:260: 0:desktop-file-utils-0.10-7.x86_64 DEBUG util.py:260: No Package Found for readline-devel = 6.1 DEBUG util.py:260: 0:opencv-devel-1.0.0-3.el5.x86_64 DEBUG util.py:260: 1:doxygen-1.4.7-1.1.x86_64 DEBUG util.py:260: 0:sqlite-devel-3.3.6-5.x86_64 DEBUG util.py:260: 2:libpng-devel-1.2.10-7.1.el5_5.3.x86_64 DEBUG util.py:260: 0:cairomm-1.2.4-1.el5.x86_64 DEBUG util.py:260: No Package Found for libxml++-devel = 2.26 DEBUG util.py:260: No Package Found for tolua++-devel DEBUG util.py:260: 0:openssl-devel-0.9.8e-12.el5_4.6.x86_64 DEBUG util.py:260: 0:kernel-headers-2.6.18-194.17.4.el5.x86_64 All those No Package Found issues need to be fixed. ;) Either by branching the needed packages into EPEL, or fixing the package to not need them or need the available versions in EPEL. RHEL5 is pretty old at this point, you cannot assume that something that works fine on fedora builds and works fine in epel. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji build fail for el5/el6
On 5 November 2010 19:47, Tim Niemueller t...@niemueller.de wrote: Koji Builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=2580299 That then points to https://koji.fedoraproject.org/koji/taskinfo?taskID=2580322 Note the Result : BuildError: error building package (arch noarch), mock exited with status 10; see root.log for more information which can be found lower down http://koji.fedoraproject.org/koji/getfile?taskID=2580322name=root.log ... DEBUG util.py:260: No Package Found for libdaemon-devel = 0.14 DEBUG util.py:260: 0:libjpeg-devel-6b-37.x86_64 DEBUG util.py:260: 0:gtkmm24-devel-2.10.10-1.el5.x86_64 DEBUG util.py:260: No Package Found for file-devel ... Not all Fedora packages/versions are available in RHEL/EPEL and some have different names due to the age of RHEL5 Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
2010/11/5 Marcela Mašláňová mmasl...@redhat.com: On 11/04/2010 08:32 PM, Michael Schwendt wrote: On Thu, 4 Nov 2010 17:41:34 + (UTC), Daniel wrote: Release of libxml2-2.7.8 libxml2.spec | 10 -- Seems to break the koji build root due to ABI incompatibility. Dependent packages should be rebuild. There should have been a heads up for this. It affects 100s of packages. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji build fail for el5/el6
On 05.11.2010 14:52, Kevin Fenzi wrote: The userdel seems unrelated to the real problem: DEBUG util.py:260: No Package Found for gearbox-devel= 9.11 [...] Thanks, missed those. I wish it could be made more clear which state failed. I wonder why it says return code 0, although this failed? All those No Package Found issues need to be fixed. ;) Either by branching the needed packages into EPEL, or fixing the package to not need them or need the available versions in EPEL. RHEL5 is pretty old at this point, you cannot assume that something that works fine on fedora builds and works fine in epel. It can be built on EL5. We have a CentOS 5 build slave building new revisions checked into the git master. By reducing the BuildRequires I can produce a basic version which allows for running the basic stuff. Thanks, Tim -- Tim Niemueller t...@niemueller.de www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
Peter Robinson (pbrobin...@gmail.com) said: 2010/11/5 Marcela Mašláňová mmasl...@redhat.com: On 11/04/2010 08:32 PM, Michael Schwendt wrote: On Thu, 4 Nov 2010 17:41:34 + (UTC), Daniel wrote: Release of libxml2-2.7.8 libxml2.spec | 10 -- Seems to break the koji build root due to ABI incompatibility. Dependent packages should be rebuild. There should have been a heads up for this. It affects 100s of packages. It's being fixed; no rebuilds needed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
On Fri, 5 Nov 2010 15:16:32 -0400 Bill Nottingham nott...@redhat.com wrote: Peter Robinson (pbrobin...@gmail.com) said: 2010/11/5 Marcela Mašláňová mmasl...@redhat.com: On 11/04/2010 08:32 PM, Michael Schwendt wrote: On Thu, 4 Nov 2010 17:41:34 + (UTC), Daniel wrote: Release of libxml2-2.7.8 libxml2.spec | 10 -- Seems to break the koji build root due to ABI incompatibility. Dependent packages should be rebuild. There should have been a heads up for this. It affects 100s of packages. + 1 It's being fixed; no rebuilds needed. Fixed, in what sense? What about the packages that have already been rebuilt? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, That's, um, exactly the process we're discussing here. We close all bugs for a given release when that release goes EOL. (I forget what resolution is used, it may well be WONTFIX). We send a warning note to all bugs that will be closed under this process, a short while before they're closed, so the reporters can check if they exist in a newer version and bump the report to that version to keep it open, if they like. -- 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, 2010-11-04 at 17:49 -0400, Orcan Ogetbil wrote: On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote: 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. I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle. Well, so what? So a bunch of bug reports got filed, didn't lead to any changes, and then got closed. I mean, I guess looked at from a certain angle it's 'inefficient', but I don't think we're hitting any particular resource constraints in terms of Bugzilla use at this point. -- 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 Fri, 2010-11-05 at 07:27 -0700, John Poelstra wrote: Frank Murphy said the following on 11/05/2010 12:47 AM Pacific Time: On 05/11/10 07:27, Alexander Kurtakov wrote: So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs I think maybe it is meant more as You have 100 bugs, 80 are not acknowledged. I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording) Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers. We've been trying to do that and get it off the ground for several years. It hasn't exactly flourished. Right. This is: https://fedoraproject.org/wiki/BugZappers as John says, it's been around for a while. Both John and I have tried to drive it to some extent. But it just doesn't get a lot of people who are really committed to doing the work. The fact that the work is often boring and generally not much use to the person doing the work him/herself, directly, contributes to this. -- 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 Fri, 2010-11-05 at 18:29 +0100, Michael Schwendt wrote: It is inefficient, if some time later another user needs to report the same issue only to get ignored, too. It is not encouraging our users to spend time on reporting bugs and on replying to NEEDINFO or other questions in the tickets. The warning that the ticket may be closed could have been given _much_ earlier, e.g. after two months of silence with no reply from the maintainer(s). Or at release time of F(N+1) Beta. Much worse if it's the second time a ticket is closed because of EOL. It's just poor form to ignore a user's bug report completely. I've received bugzapping mails for various issues, including packaging mistakes that have not been examined since F12. For example: http://bugzilla.redhat.com/516352 Closing the bug *isn't* ignoring it. Leaving it open and doing exactly nothing about it, which is what would happen if we didn't auto-close bugs, is ignoring it. If the bug hasn't had any attention for the last year and a half it's not particularly likely to magically get it now, is it? If we don't auto-close bugs we wind up with a huge pile of ancient bugs which just gets in the way of people who want to come along and actually clean up the bug list for a package. It's harder to do that if you're looking at reports from the Stone Age. UNLESS it's still present in later releases. It's the reporter who is most likely to be able to say whether it is, therefore, we ask the user to check and update the bug, not the maintainer. This is ridiculous because of very poor timing John always posts the schedule for housekeeping tasks to test list (I think possibly devel list too, I forget) and asks for feedback. He never seems to get any. and because bugs may not always be reproducible. What makes you think the reporter can find the free time to handle a flood of EOL tickets? I don't think they always will, but the alternative is worse. If the bug's not reproducible, how is anyone going to fix it? Or know that it's been fixed? It may be 'fairer' to set needinfo maintainer, but the result sure wouldn't be as good in practical terms, because the maintainer is less likely than the user to actually be able/inclined to provide the required data. I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects magically with lots of code rewrites). And I'd like a gold-plated pony. If you'd like to see the list, why not create it? I don't think anyone else has it lying around just ready to produce on demand. (Unless there was meant to be a second part to this sentence and you got lost somewhere in the middle :) -- 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 Fri, 2010-11-05 at 13:48 -0400, Przemek Klosowski wrote: On 11/04/2010 06:22 PM, Orcan Ogetbil wrote: 2- ABRT should keep track of unresponsive users. If a user has an outstanding needinfo? flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages. That's a little harsh---I have been in situation when I couldn't reply to a 'needinfo' because e.g. I upgraded in the meantime, or I'd have to reboot to a different kernel or something like that. But you can reply to needinfo in these cases. You can reply by saying 'sorry, I'm no longer able to test this, we'd better close it'. -- 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: [libxml2] Release of libxml2-2.7.8
On Fri, 5 Nov 2010 21:19:14 +0200 Jussi Lehtola jussileht...@fedoraproject.org wrote: It's being fixed; no rebuilds needed. Fixed, in what sense? What about the packages that have already been rebuilt? About 30min after the rawhide compose kicked off: http://koji.fedoraproject.org/koji/buildinfo?buildID=203440 It's already fixed, but it didn't land in rawhide today. So, I'm not sure what happens to packages that were rebuilt against the broken one today. ;( They may need to rebuild again tomorrow... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
On Fri, Nov 05, 2010 at 13:57:18 -0600, Kevin Fenzi ke...@scrye.com wrote: On Fri, 5 Nov 2010 21:19:14 +0200 Jussi Lehtola jussileht...@fedoraproject.org wrote: It's being fixed; no rebuilds needed. Fixed, in what sense? What about the packages that have already been rebuilt? About 30min after the rawhide compose kicked off: http://koji.fedoraproject.org/koji/buildinfo?buildID=203440 It's already fixed, but it didn't land in rawhide today. So, I'm not sure what happens to packages that were rebuilt against the broken one today. ;( They may need to rebuild again tomorrow... I guess I'm glad I'm a little slow to fix build errors. I was going to get to doing a rebuild over the weekend, but now I don't need to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Fri, 05 Nov 2010 12:30:41 -0700, Adam wrote: If the bug hasn't had any attention for the last year and a half it's not particularly likely to magically get it now, is it? Then why should the reporter take action in reply to the NEEDINFO bugzapping request? Something is terribly wrong here, if reporter adjusts F12 - F13 - F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months. John always posts the schedule for housekeeping tasks to test list (I think possibly devel list too, I forget) and asks for feedback. He never seems to get any. Look in the archives. It's not the first time I've criticized what this bugzapping script does. It has stopped me from filing lots of issues, both with regard to packaging bugs as well as other problems, because I simply cannot handle the flood of NEEDINFO requests. If I remember correctly, this predates your involvement in Fedora. (And John comes up with so much stuff, hardly anyone will handle it anyway.) If the bug's not reproducible, how is anyone going to fix it? Or know that it's been fixed? Praise ABRT! In many cases, complete backtraces in conjunction with the source code reveal programming errors - sometimes embarassing ones. Not always, but if nobody skims over the problem reports, nobody can tell whether a reported bug is interesting or not. I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects magically with lots of code rewrites). And I'd like a gold-plated pony. If you'd like to see the list, why not create it? I don't think anyone else has it lying around just ready to produce on demand. (Unless there was meant to be a second part to this sentence and you got lost somewhere in the middle :) The sentence is complete. Probably writing it was wasted time, because apparently *you* are not interested in feedback or in ideas, which might be more helpful than hiding bugs under the carpet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Fri, 2010-11-05 at 21:37 +0100, Michael Schwendt wrote: On Fri, 05 Nov 2010 12:30:41 -0700, Adam wrote: If the bug hasn't had any attention for the last year and a half it's not particularly likely to magically get it now, is it? Then why should the reporter take action in reply to the NEEDINFO bugzapping request? Something is terribly wrong here, if reporter adjusts F12 - F13 - F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months. So, what's your alternative? John always posts the schedule for housekeeping tasks to test list (I think possibly devel list too, I forget) and asks for feedback. He never seems to get any. Look in the archives. It's not the first time I've criticized what this bugzapping script does. It has stopped me from filing lots of issues, both with regard to packaging bugs as well as other problems, because I simply cannot handle the flood of NEEDINFO requests. If I remember correctly, this predates your involvement in Fedora. (And John comes up with so much stuff, hardly anyone will handle it anyway.) Yes, we've been doing it for a while. I keep saying it's not perfect. But what's your alternative? The underlying problem here is the one everyone knows about: we don't have enough manpower to fix all bugs. Given that, why is it better to leave them rotting away for years than to close them? If the bug's not reproducible, how is anyone going to fix it? Or know that it's been fixed? Praise ABRT! In many cases, complete backtraces in conjunction with the source code reveal programming errors - sometimes embarassing ones. Not always, but if nobody skims over the problem reports, nobody can tell whether a reported bug is interesting or not. Well, in the abrt thread we have someone arguing that abrt reports are almost always useless without steps to reproduce (their words, not mine)...clearly, everyone doesn't agree here. I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects magically with lots of code rewrites). And I'd like a gold-plated pony. If you'd like to see the list, why not create it? I don't think anyone else has it lying around just ready to produce on demand. (Unless there was meant to be a second part to this sentence and you got lost somewhere in the middle :) The sentence is complete. Probably writing it was wasted time, because apparently *you* are not interested in feedback or in ideas, which might be more helpful than hiding bugs under the carpet. Saying 'I want someone to make this list so I can look at it' isn't really useful feedback or ideas, it's demanding someone else do work on your behalf. Which historically speaking is not the best way to make sure it gets done. I have trouble parsing that sentence, my eyes glaze out somewhere in the middle of the fourth line, but if I'm reading it right, you want a list of packages for which our track record of fixing bugs is not great, right? Okay, supposing we make such a list, what is it you want to do with it? -- 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 Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote: ABRT It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports Parts of the Fedora user base abuse ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool. It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request. It's disheartening in some cases, but it's a people-problem not a tool-problem. Also, this produces incomplete traceback in many (IMO all) cases. Cannot confirm that. There seem to be some issues with not finding the needed debuginfo packages, which may be related to frequent updates of repos and older packages getting pruned. It may also be related to users updating their boxes at strange times, e.g. seldomly but immediately after a crash. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ABRT (was: Re: bugzilla bugzappers?)
On Thu, 04 Nov 2010 23:05:01 +0100, Jiri wrote: - if you think ABRT is not providing a good info for you packages, then please write me an email how to improve it Could you please add another hurdle that tries to stop users from not filling in the empty fields about how to reproduce a problem? Backtraces [plus the source code] can tell a tale, but they are not always sufficient. And a bit of background about what caused an app to malfunction can be very helpful. Fedora users need to understand that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT (was: Re: bugzilla bugzappers?)
On Fri, Nov 5, 2010 at 4:53 PM, Michael Schwendt wrote: On Thu, 04 Nov 2010 23:05:01 +0100, Jiri wrote: - if you think ABRT is not providing a good info for you packages, then please write me an email how to improve it Could you please add another hurdle that tries to stop users from not filling in the empty fields about how to reproduce a problem? Backtraces [plus the source code] can tell a tale, but they are not always sufficient. And a bit of background about what caused an app to malfunction can be very helpful. Fedora users need to understand that. +1 To the above I should add, in many cases, I need the full list of packages (with version-release) that are installed in the user's system. Please add this too. Thanks, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Thu, 04 Nov 2010 23:58:21 +, Jóhann wrote: On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com. Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands. It's obvious that they all cannot be processed other than by scripts. For other components, the maintainer may be occupied with many packages but one. And still the one package may be updated regularly with upstream releases that include fixes for various issues. It's just the bugzilla grunt work that's not done for that package. Interesting would be to determine the packages that are [somewhat] neglected with regard to incoming tickets because of no spare time to take care of them. Much more interesting would be to determine those maintainers, who seem to neglect all of most of their bugzilla tickets for all or most of their packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On Fri, 5 Nov 2010 09:27:46 +0200, Alexander wrote: I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording) Yeah. It isn't that obvious to our users (and potential contributors among them) where help is needed, where help would be accepted (possibly up to the point of becoming an official Fedora Contributor with commit access), or whether a lack of response is just temporary due to priorities. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for a good Radix tree (Patricia) library in fedora
Well, there's the cprops library, but I'd need to make a package out of that
first
http://cprops.sourceforge.net/
Seems like this might be generically useful (i.e. not just for radix tries but
the other search types).
Not sure if the threading support is needed or not... plus it might mean that
it package only works on Linux (and not Win32, which Perl requires be
supported).
On 10/31/10 2:14 PM, Philip Prindeville wrote:
I'm the CPAN owner of Net::Patricia (perl-Net-Patricia.rpm) and it currently
supports IPv4 and IPv6.
Both are done with specialized data structures.
I'm looking for something that handles a more generic binary data blob... so
that I could have arbitrary searches.
For instance, in Perl, I could seed the tree with:
$key = join('.', reverse(split(/\./, $domain)));
$keylen = length($key) * 8;
and then do rDNS tree searches for hostnames.
One could similarly imagine converting phone numbers into BCD and doing E.164
searches in such a tree.
Net::Patricia currently uses a modified version of libpatricia from the MERIT
Radius or SNMP code (forget which)... but it only handles IPv6 and IPv4 as I
said.
Ideally it would be an external library that I could just link to.
Anyone have a pointer?
Thanks,
-Philip
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Thu, Nov 4, 2010 at 19:11, Dennis Jacobfeuerborn denni...@conversis.de wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ There is an interesting article on LWN currently that outlines not Ubuntu's reasons but core X hacker Keith Packards on the changes: http://lwn.net/Articles/413335/ for those with LWN subscriptions. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, 2010-11-05 at 15:41 -0600, Stephen John Smoogen wrote: On Thu, Nov 4, 2010 at 19:11, Dennis Jacobfeuerborn denni...@conversis.de wrote: Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ There is an interesting article on LWN currently that outlines not Ubuntu's reasons but core X hacker Keith Packards on the changes: http://lwn.net/Articles/413335/ for those with LWN subscriptions. thanks for the pointer, that was interesting indeed. (reminder to RHers: we have a site subscription to LWN, details on the intranet.) -- 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 Fri, 05 Nov 2010 13:45:37 -0700, Adam wrote: Something is terribly wrong here, if reporter adjusts F12 - F13 - F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months. So, what's your alternative? To keep them open, so as they get older and they continue to affect users, they could be moved up from the bottom of somebody's TODO list. If they get closed, much is lost including test-case attachments, comments, links. Eventually somebody will open a new ticket for F15 and point out that the package is broken since F8. The underlying problem here is the one everyone knows about: we don't have enough manpower to fix all bugs. Given that, why is it better to leave them rotting away for years than to close them? Better would be to fix the bug in the software/package and remove the cause of new tickets or dupes created by ABRT. Who can tell whether lack of response is really due to lack of manpower? And not due to other factors? For example, there's a crash in librsvg2, which affects multiple apps that use this library, including Nautilus. There have been multiple reports about it. Including an upstream ticket created by me. Including a comment on what is wrong in the source and what would be a work-around. No response so far. http://bugzilla.redhat.com/553069 Other tickets for the same issue are in EOL NEEDINFO state meanwhile. For me, even with provenpackager access, it's not clear how to proceed even if the issue affects one of my packages, too. And whereas I would fix such an issue in my own packages, there are lengthy documents like https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages that make me insecure. [...], you want a list of packages for which our track record of fixing bugs is not great, right? Okay, supposing we make such a list, what is it you want to do with it? Not right. I (and to the best of my knowledge also other packagers I've talked to) could use such a list and look for packages that need help. Based on actual statistics instead of randomly poking in bugzilla or in bugz.fedoraproject.org pages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Fri, 05 Nov 2010 09:14:08 +0200, Alexander Kurtakov wrote: On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote: On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote: The practical point is that F12 is about to go EOL which means the bug must be closed... Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319). This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed. Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. This is the best we can do no matter what we want to do! P.S. Believe me having open bugs that both the packager and the submitter care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation. I understand what your saying. After some consideration, my issues are: 1. I don't respond to autobots. 2. If the maintainer doesn't care, I don't care. Thus I'm not gonna tick of some version flag or something. I think what would help moving forward, (without having to do away with the autobots, which I welcome) is what Matt said... that the autobots did not CLOSE, but had some different status, such as: AUTO-CLOSED. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji build fail for el5/el6
On Fri, 05 Nov 2010 15:08:40 -0400 Tim Niemueller t...@niemueller.de wrote: Some more question related to el6: When will packages appear in el6? I maintain some of the dependencies for el5, but they are not in el6. They will appear when someone branches them and builds them, or when the maintainers of the already existing branch builds them. ;) Basically we branched everything that was in epel5 except for those things that will be in RHEL6. It's then up to the maintainers to build and maintain them. What packages? You should be able to look in pkgdb and see if they already have a branch or not. Do I just need to build them? Will there be or should there have been a mass rebuild? Do I need to file a koji update? If they aren't already branched or in rhel6, yeah, just make a scm request on the package review for the package to branch for el6. If they are, ping the maintainer to do a build? No updates are currently needed. It's in 'beta' mode, which is like rawhide, everything pushes out every day or two. Once rhel6 comes out we will go to bodhi/updates, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. On the net I read that Ubuntu wants to ditch X in favor of Wayland but that's not what I read in Marks post. As I understand it the plan is to introduce Wayland but not get rid of X for years to come. Sounds like a reasonable plan if it can be implemented in a technically feasible way. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/05/2010 09:46 PM, Michael Schwendt wrote: On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote: ABRT It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports Parts of the Fedora user base abuse ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool. A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired. As yourself: What would you do if you were a simple computer user and are facing this flash bulb icon asking you to become root and to get a bugzilla account? You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty soon, when you call him for the Nth time. As a user you'd also think what kind of crap is this Fedora/Linux - the WinXP I have at home is better. It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request. Correct - But the same applies to maintainers. My experience is, most of them ignore ABRT reports, probably because the ABRT reports are not helpful to them and/or don't contain sufficient infos. It's disheartening in some cases, but it's a people-problem not a tool-problem. I disagree - IMO; ABRT is not end-user ready. It presumes end-users to be familiar with redhat's infrastructure, which is a developer infrastructure and them to be interested to get involved into Fedora development. This simply does not apply. Also, this produces incomplete traceback in many (IMO all) cases. Cannot confirm that. In almost all cases, I am observing missting debuginfos even after executing debuginfo-installs. There seem to be some issues with not finding the needed debuginfo packages, which may be related to frequent updates of repos and older packages getting pruned. It may also be related to users updating their boxes at strange times, e.g. seldomly but immediately after a crash. Possible. This certainly this applies in some cases. However, I am experiencing missing debuginfos after debuginfo-install even with what is supposed to be uptodate Fedora installations. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/05/2010 08:20 PM, Adam Williamson wrote: On Thu, 2010-11-04 at 17:49 -0400, Orcan Ogetbil wrote: On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote: 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. I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle. Well, so what? So a bunch of bug reports got filed, didn't lead to any changes, and then got closed. According to the figures you sent earlier this week, ca. 93% of all ABRT reports can be expected to suffer this fate. I mean, I guess looked at from a certain angle it's 'inefficient', OK, I understand you are wanting to play down the issues ABRT has. but I don't think we're hitting any particular resource constraints in terms of Bugzilla use at this point. Why do you think are we discussing/arguing? IMO, the primary underlaying problem we are disscussing here is ARBT draining away too many resources. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/05/2010 10:06 PM, Michael Schwendt wrote: On Thu, 04 Nov 2010 23:58:21 +, Jóhann wrote: On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com. Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands. These packages should be examined and analysed individually and consequences be drawn upon, if neccessary even if they might be unpleasant. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/06/2010 01:53 AM, Ralf Corsepius wrote: On 11/05/2010 09:46 PM, Michael Schwendt wrote: On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote: ABRT It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports Parts of the Fedora user base abuse ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool. A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired. Agreed It has been improving but is far from novice usage perfection but whether that is good or bad all boils down to the so called Target user basesigh. As yourself: What would you do if you were a simple computer user and are facing this flash bulb icon asking you to become root and to get a bugzilla account? You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty soon, when you call him for the Nth time. As a user you'd also think what kind of crap is this Fedora/Linux - the WinXP I have at home is better. The same problem here applies to all regardless of OS or Application. If the entry level is to high or OS or Application give novice end user to much in you face time they replace it or find a way to silence the nuance one way or another. It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request. Correct - But the same applies to maintainers. My experience is, most of them ignore ABRT reports, probably because the ABRT reports are not helpful to them and/or don't contain sufficient infos. Same applies to human directly submitted report It's disheartening in some cases, but it's a people-problem not a tool-problem. I disagree - IMO; ABRT is not end-user ready. It presumes end-users to be familiar with redhat's infrastructure, which is a developer infrastructure and them to be interested to get involved into Fedora development. This simply does not apply. Again it all boils down to the so called Target user base JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
On 11/06/2010 02:11 AM, Ralf Corsepius wrote: On 11/05/2010 10:06 PM, Michael Schwendt wrote: On Thu, 04 Nov 2010 23:58:21 +, Jóhann wrote: On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com. Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands. These packages should be examined and analysed individually and consequences be drawn upon, if neccessary even if they might be unpleasant Agreed... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Mojolicious] Created tag perl-Mojolicious-0.999935-1.fc15
The lightweight tag 'perl-Mojolicious-0.35-1.fc15' was created pointing to: 7e696e3... - Latest upstream release. http://search.cpan.org/src/KRA -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Log-Log4perl/f14/master] 1.30 bump
Summary of changes: abde086... 1.30 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 632176] perl-Log-Log4perl-1.31 is available
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=632176 --- Comment #3 from Marcela Mašláňová mmasl...@redhat.com 2010-11-05 04:45:30 EDT --- I've asked for EL-6, #176137 but you can comaintain if you wish. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Gtk2-Notify
perl-Gtk2-Notify has broken dependencies in the rawhide tree: On x86_64: perl-Gtk2-Notify-0.05-8.fc14.x86_64 requires libnotify.so.1()(64bit) On i386: perl-Gtk2-Notify-0.05-8.fc14.i686 requires libnotify.so.1 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-XML-LibXSLT
perl-XML-LibXSLT has broken dependencies in the rawhide tree: On x86_64: perl-XML-LibXSLT-1.70-4.fc14.x86_64 requires libxml2.so.2(LIBXML2_2.4.30)(64bit) On i386: perl-XML-LibXSLT-1.70-4.fc14.i686 requires libxml2.so.2(LIBXML2_2.4.30) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-DBIx-Class-Schema-Loader
perl-DBIx-Class-Schema-Loader has broken dependencies in the rawhide tree: On x86_64: perl-DBIx-Class-Schema-Loader-0.07002-1.fc15.noarch requires perl(DBIx::Class::Schema::Loader::Utils) On i386: perl-DBIx-Class-Schema-Loader-0.07002-1.fc15.noarch requires perl(DBIx::Class::Schema::Loader::Utils) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBIx-Class-Schema-Loader] provides perl(DBIx::Class::Schema::Loader::Utils)
commit 4b568684e5235fb4773b709e1eb9480b078a0b01
Author: Iain Arnell iarn...@gmail.com
Date: Fri Nov 5 10:25:33 2010 +0100
provides perl(DBIx::Class::Schema::Loader::Utils)
perl-DBIx-Class-Schema-Loader.spec |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/perl-DBIx-Class-Schema-Loader.spec
b/perl-DBIx-Class-Schema-Loader.spec
index b9ebe79..40dd91b 100644
--- a/perl-DBIx-Class-Schema-Loader.spec
+++ b/perl-DBIx-Class-Schema-Loader.spec
@@ -1,7 +1,7 @@
Name: perl-DBIx-Class-Schema-Loader
Summary:Dynamic definition of a DBIx::Class::Schema
Version:0.07002
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-Schema-Loader-%{version}.tar.gz
@@ -59,6 +59,9 @@ Requires: perl(List::MoreUtils)
Requires: perl(Scope::Guard)
Requires: perl(Text::Balanced)
+# hidden from PAUSE
+Provides: perl(DBIx::Class::Schema::Loader::Utils)
+
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
@@ -106,6 +109,9 @@ rm -rf %{buildroot}
%{_bindir}/*
%changelog
+* Fri Nov 05 2010 Iain Arnell iarn...@gmail.com 0.07002-2
+- provides perl(DBIx::Class::Schema::Loader::Utils)
+
* Tue Oct 05 2010 Iain Arnell iarn...@gmail.com 0.07002-1
- update to 0.07002
- disable auto_install
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 632176] perl-Log-Log4perl-1.31 is available
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=632176 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-11-05 05:50:37 EDT --- perl-Log-Log4perl-1.30-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Log-Log4perl-1.30-1.fc14 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-LibXSLT] rebuilt with new libxml2
commit f3818e7091b1fa5ed7f3a483fa8d7bcc4e008583
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Nov 5 11:50:23 2010 +0100
rebuilt with new libxml2
perl-XML-LibXSLT.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-LibXSLT.spec b/perl-XML-LibXSLT.spec
index 9ce18a9..3c17562 100644
--- a/perl-XML-LibXSLT.spec
+++ b/perl-XML-LibXSLT.spec
@@ -4,7 +4,7 @@ Name: perl-XML-LibXSLT
# NOTE: also update perl-XML-LibXML to a compatible version. See below why.
Version: 1.70
-Release: 4%{?dist}
+Release: 5%{?dist}
Summary: Perl module for interfacing to GNOME's libxslt
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Fri Nov 5 2010 Marcela Mašláňová mmasl...@redhat.com - 1.70-5
+- rebuilt with new libxml2
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.70-4
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Gtk2-Notify] rebuild with new libxml2
commit 2cfd398e92c531acce82e869564eece426d73d7c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Nov 5 11:55:28 2010 +0100
rebuild with new libxml2
perl-Gtk2-Notify.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Gtk2-Notify.spec b/perl-Gtk2-Notify.spec
index ac8c1b5..c517352 100644
--- a/perl-Gtk2-Notify.spec
+++ b/perl-Gtk2-Notify.spec
@@ -1,6 +1,6 @@
Name: perl-Gtk2-Notify
Version:0.05
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Perl interface to libnotify
License:LGPLv2+
Group: Development/Libraries
@@ -70,6 +70,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Fri Nov 5 2010 Marcela Mašláňová mmasl...@redhat.com - 0.05-9
+- rebuild with new libxml2
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-8
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-LibXSLT] Add missing BR. Thanks ppisar.
commit 71468021c09fdc029412c79f0648f18a5fc8a258
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Nov 5 12:35:06 2010 +0100
Add missing BR. Thanks ppisar.
perl-XML-LibXSLT.spec |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/perl-XML-LibXSLT.spec b/perl-XML-LibXSLT.spec
index 3c17562..52330a4 100644
--- a/perl-XML-LibXSLT.spec
+++ b/perl-XML-LibXSLT.spec
@@ -14,7 +14,7 @@ URL: http://search.cpan.org/dist/XML-LibXSLT/
Source0:
http://search.cpan.org/CPAN/authors/id/P/PA/PAJAS/XML-LibXSLT-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: libxslt-devel = 1.1.18, gdbm-devel
+BuildRequires: libxslt-devel = 1.1.18, gdbm-devel, libgcrypt-devel,
libgpg-error-devel
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# the package shares code with perl-XML-LibXML, we have to require a
compatible version
@@ -58,7 +58,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Fri Nov 5 2010 Marcela Mašláňová mmasl...@redhat.com - 1.70-5
-- rebuilt with new libxml2
+- add BR
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.70-4
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 632176] perl-Log-Log4perl-1.31 is available
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=632176 --- Comment #5 from Jose Pedro Oliveira j...@di.uminho.pt 2010-11-05 08:48:50 EDT --- (In reply to comment #3) I've asked for EL-6, #176137 but you can comaintain if you wish. The EL-6 branch was supposed to have been already created: perl-Log-Log4perl 1.24 already exists in the EPEL6 repo (e.g http://download.fedora.redhat.com/pub/epel/beta/6/SRPMS/perl-Log-Log4perl-1.24-1.el6.src.rpm) Regards, jpo PS - Thanks for F-14 update. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Gtk2-Notify] Fix function according to new libnotify.
commit 5cd6b1f4fb2562d4efc919ce648b71933820af1b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Nov 5 13:59:26 2010 +0100
Fix function according to new libnotify.
libnotify.patch | 19 +++
perl-Gtk2-Notify.spec |5 +++--
2 files changed, 22 insertions(+), 2 deletions(-)
---
diff --git a/libnotify.patch b/libnotify.patch
new file mode 100644
index 000..7c4b940
--- /dev/null
+++ b/libnotify.patch
@@ -0,0 +1,19 @@
+diff -up Gtk2-Notify-0.05/xs/Notify.xs.not Gtk2-Notify-0.05/xs/Notify.xs
+--- Gtk2-Notify-0.05/xs/Notify.xs.not 2007-10-04 14:11:13.0 +0200
Gtk2-Notify-0.05/xs/Notify.xs 2010-11-05 13:29:48.663238502 +0100
+@@ -86,13 +86,12 @@ notify_get_server_info (class, OUTLIST c
+ MODULE = Gtk2::Notify PACKAGE = Gtk2::Notify PREFIX = notify_notification_
+
+ NotifyNotification *
+-notify_notification_new (class, summary, body=NULL, icon=NULL, attach=NULL)
++notify_notification_new (summary, body=NULL, icon=NULL)
+ const gchar *summary
+ const gchar *body
+ const gchar *icon
+- GtkWidget_ornull *attach
+ C_ARGS:
+- summary, body, icon, attach
++ summary, body, icon
+
+ #if GTK_CHECK_VERSION (2, 9, 2)
+
diff --git a/perl-Gtk2-Notify.spec b/perl-Gtk2-Notify.spec
index c517352..7468fac 100644
--- a/perl-Gtk2-Notify.spec
+++ b/perl-Gtk2-Notify.spec
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Gtk2-Notify/
Source0:
http://www.cpan.org/modules/by-module/Gtk2/Gtk2-Notify-%{version}.tar.gz
#Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Gtk2-Notify-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
+Patch0: libnotify.patch
# non-perl
BuildRequires: libnotify-devel
# core
@@ -37,6 +37,7 @@ functionality from within a perl application.
%prep
%setup -q -n Gtk2-Notify-%{version}
+%patch0 -p1
find t/ -type f -exec perl -pi -e 's|^#!perl|#!/usr/bin/perl|' {} +
@@ -71,7 +72,7 @@ rm -rf %{buildroot}
%changelog
* Fri Nov 5 2010 Marcela Mašláňová mmasl...@redhat.com - 0.05-9
-- rebuild with new libxml2
+- fix function according to new libnotify
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-8
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Announcement: Spam filter to to drop messages
Hello perl-de...@f.o subscribers, as Mailman 2.1.9 offers to moderate incomming messages on e-mail header basis, and Red Hat MTAs hosting fedoraproject.org mailing lists mark suspicious e-mails with X-RedHat-Spam-Warning: header, I deciced to utilize this feature to help to moderate messages comming to this mailing list. You, regular readers, did not hit any spam in this list because all messages from non-subscibers are hold before delivery to be waiting for manual intervention by list owner -- me. This old configuration led to ten or twenty new messages in quarntine every day. I believe this new setup will lower maintainance effort for me without any negative impacts on legitimate posts. However if you notice any mistakes (like lost posts), do no hesitate to contact me regarding this issue. -- Petr Pisar, perl-de...@f.o owner. pgp2NR1otkUVh.pgp Description: PGP signature -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mojolicious-0.999936.tar.gz uploaded to lookaside cache by yaneti
A file has been added to the lookaside cache for perl-Mojolicious: ffe1a2b4a29441e4332f2c34547f904e Mojolicious-0.36.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mojolicious] New upstream bugfix release
commit 4ae102b19ec2a2ff7b312b3b070453cd4bf1682c
Author: Yanko Kaneti yan...@declera.com
Date: Fri Nov 5 15:29:30 2010 +0200
New upstream bugfix release
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a2f47fb..12911a1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-0.27.tar.gz
/Mojolicious-0.29.tar.gz
/Mojolicious-0.35.tar.gz
+/Mojolicious-0.36.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 9f8a228..8a3f475 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:0.35
+Version:0.36
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 5 2010 Yanko Kaneti yan...@declera.com 0.36-1
+- New upstream bugfix release.
+
* Thu Nov 4 2010 Yanko Kaneti yan...@declera.com 0.35-1
- Latest upstream release.
http://search.cpan.org/src/KRAIH/Mojolicious-0.35/Changes
diff --git a/sources b/sources
index b195838..7d7a125 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7b0ddd25aca34032b93c577f1533ba75 Mojolicious-0.35.tar.gz
+ffe1a2b4a29441e4332f2c34547f904e Mojolicious-0.36.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 561389] amavisd-new always reports Shutting down amavisd: Daemon [19248] terminated by SIGTERM
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=561389 John Griffiths fedora.jr...@grifent.com changed: What|Removed |Added Version|12 |13 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 596103] perl-Net-Patricia-1.18 is available
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=596103 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-11-05 17:51:04 EDT --- perl-Net-Patricia-1.18-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/perl-Net-Patricia-1.18-1.fc13 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 632176] perl-Log-Log4perl-1.31 is available
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=632176 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2010-11-05 18:56:02 EDT --- perl-Log-Log4perl-1.30-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Log-Log4perl'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/perl-Log-Log4perl-1.30-1.fc14 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
