Re: Proposal to Drop Fedora 12 Features
On Thursday 16 July 2009 20:25:36 Jon Ciesla wrote: On Thu, Jul 16, 2009 at 10:11 PM, John Poelstrapoels...@redhat.com wrote: Hi FESCo, https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support Afaik those are blocking on 1) xz review request 2) rel-eng to coordinate a mass rebuild Has anyone taken concrete steps for a i586 secondary arch yet? For the most part, its not (yet) necessary. We throttled back the definition of i686 from i686 + cmov + sse2 or some such to just i686 + cmov, so there are very few systems that would be served by an i586 secondary arch right now. i.e., Athlon XP, Pentium III, etc., which *would* have been relegated to i586, are still going to be supported by i686, and we've talked about adding a cmov trap-and-emu function to keep supporting the few i686 procs w/o cmov, which really leaves only the original Pentium series that would benefit from an i586 secondary arch. At least, that's my vague recollection of it all right now... :) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
Jarod Wilson wrote: On Thursday 16 July 2009 20:25:36 Jon Ciesla wrote: On Thu, Jul 16, 2009 at 10:11 PM, John Poelstrapoels...@redhat.com wrote: Hi FESCo, https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support Afaik those are blocking on 1) xz review request 2) rel-eng to coordinate a mass rebuild Has anyone taken concrete steps for a i586 secondary arch yet? For the most part, its not (yet) necessary. We throttled back the definition of i686 from i686 + cmov + sse2 or some such to just i686 + cmov, so there are very few systems that would be served by an i586 secondary arch right now. i.e., Athlon XP, Pentium III, etc., which *would* have been relegated to i586, are still going to be supported by i686, and we've talked about adding a cmov trap-and-emu function to keep supporting the few i686 procs w/o cmov, which really leaves only the original Pentium series that would benefit from an i586 secondary arch. At least, that's my vague recollection of it all right now... :) If this is the case, which is what I was hoping I remembered, then I agree with you that we don't *really* need it. Bill, can you clarify the sse2 or no sse2 distinction, and possibly on the wiki page as well, since it was such a large thread? :) It's a shame to end old hardware support, as it's always been one of my favourite things about Linux in general, but if I ever have any of that sort of hardware, I can make do. . . -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Plan for tomorrow's (20090717) FESCo meeting, version 2.0
On 07/17/2009 05:23 AM, Jon Stanley wrote: 194 ABRT F12 - https://fedoraproject.org/wiki/Features/ABRTF12 Last time, this one was approved, it wasn't in a usable state by default and was never dropped. I hope we get it right, this time. 207 PK Browser Plugin - https://fedoraproject.org/wiki/Features/PackageKitBrowserPlugin Unless we are a building a web interface in Fedora infrastructure like the amber project, I am not sure this is a feature worth advertising. 208 PK Command not found - https://fedoraproject.org/wiki/Features/PackageKitCommandNotFound Unusable at the moment. Install it in Fedora 11. Type a single letter, let's say s and after 5 mins, I am still waiting for it to return anything. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Adding 32-bit packages to ppc64 and x86_64 composes and yum repos
Jesse Keating wrote: On Thu, 2009-07-16 at 15:44 -0400, William Cohen wrote: I was looking through the oprofile rpms included in the Fedora yum repos for ppc64 and x86_64. Oprofile 0.9.4 has support for java profiling that uses shared libraries. These shared libraries are packaged in the oprofile-jit rpm. 64-bit platforms such as ppc64 and x86_64 can run 32-bit versions of java. Thus, the 32-bit versions of the oprofile-jit rpm need to be included in the repositories. How does one get those rpms added to the rpms? They have to get picked up by the multilib algorithm that mash runs, or they have to be hardcoded into being picked up (or the algorithm has to be expanded to pick up other packages for this reason). Best to file a ticket with rel-eng trac to get this worked out. Hi Jesse, Thanks, filed a rel-eng trac ticket for this: https://fedorahosted.org/rel-eng/ticket/2002 -Will -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Thomas Janssen on 07/17/2009 10:56 AM wrote: Patch would be welcome. Would make my life easier in #fedora helping people with that problem. The patch should have been attached to the original post. Did you see it? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packages tracked by FEver that need to be updated
On 07/16/2009 11:22 PM, Till Maas wrote: On Saturday 11 July 2009 13:29:59 Rakesh Pandit wrote: Thanks for nice work. I too mailed other some time back .. but did not recieved any mail back. May you share the program ;) My current code is available at http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=summary But don't be disappointed, because it does not yet do very much. It would be useful to have a dynamically generated webpage that shows how close we are to upstream versions across different Fedora versions similar to the distrowatch packages page. Maybe allow package maintainers to add in comments indicating what their plans are, even. For example, if a update is going to break the ABI in a intrusive way (let's say XULRunner) or change the configuration file format (nagios), I as a package maintainer would like to convey that information to my users so they know why I haven't pushed an update despite new features or even minor bug fixes. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
On 07/17/2009 09:12 PM, Michael Cronenworth wrote: If not, should it be phased out? I'm referencing a use case with VirtualBox that looks for /proc/bus/usb by default and will use that instead of libusb for USB device access. This has caused issues for people wishing to use VirtualBox on Fedora in that they cannot use USB devices without a little tinkering. They either have to remove the /proc/bus/usb mount from rc.sysinit or adjust their fstab to allow other users access. I'll even go as far as providing a patch! *gasp* Most of you probably don't care about VirtualBox and would rather us use libvirt, but some folks use different software. Libvirt of course is a library. Even VirtualBox could be using it. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: If not, should it be phased out? I'm referencing a use case with VirtualBox that looks for /proc/bus/usb by default and will use that instead of libusb for USB device access. This has caused issues for people wishing to use VirtualBox on Fedora in that they cannot use USB devices without a little tinkering. They either have to remove the /proc/bus/usb mount from rc.sysinit or adjust their fstab to allow other users access. Why not do a patch for VirtualBox to make it look in the right place first ? We've just done that for QEMU too, changing its search order to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing the whole /proc/bus/usb mount to solve one application's problem does not seem ideal. I'll even go as far as providing a patch! *gasp* Most of you probably don't care about VirtualBox and would rather us use libvirt, but some folks use different software. FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is an API for any virtualization technology, and has drivers for Xen, KVM, QEMU, VirtualBox and more. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads UP - PHP 5.3.0 in rawhide with new ABI/API.
On 07/12/2009 11:10 PM, Remi Collet wrote: Hi, PHP 5.3.0 freshly build in Rawhide. Thanks for all your work. Added a note to https://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes#PHP_5.3 Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Daniel P. Berrange on 07/17/2009 11:10 AM wrote: Why not do a patch for VirtualBox to make it look in the right place first ? We've just done that for QEMU too, changing its search order to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing the whole /proc/bus/usb mount to solve one application's problem does not seem ideal. The VirtualBox developers state: /proc/bus/usb is deprecated, and most people have already got rid of it. If VBox finds it mounted, it uses legacy code to handle USB. We do this to avoid breaking existing working setups. Otherwise we use newer, alternative code. FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is an API for any virtualization technology, and has drivers for Xen, KVM, QEMU, VirtualBox and more. My analogy was poor, yes, as most Internet comments are, but my point was being VB vs what libvirt provides, not what libvirt is (a library). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
On Fri, Jul 17, 2009 at 09:16:12AM -0700, Adam Williamson wrote: On Fri, 2009-07-17 at 17:10 +0100, Daniel P. Berrange wrote: On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: If not, should it be phased out? I'm referencing a use case with VirtualBox that looks for /proc/bus/usb by default and will use that instead of libusb for USB device access. This has caused issues for people wishing to use VirtualBox on Fedora in that they cannot use USB devices without a little tinkering. They either have to remove the /proc/bus/usb mount from rc.sysinit or adjust their fstab to allow other users access. Why not do a patch for VirtualBox to make it look in the right place first ? Because we don't package VirtualBox, because it requires not-in-tree kernel modules. I know that, but that doesn't prevent motivated people sending a patch to rpmfusion, or virtualbox upstream to solve this problem. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Daniel P. Berrange on 07/17/2009 11:10 AM wrote: Why not do a patch for VirtualBox to make it look in the right place first ? We've just done that for QEMU too, changing its search order to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing the whole /proc/bus/usb mount to solve one application's problem does not seem ideal. Furthermore, my original question still stands: Does anything require usbfs? You did not answer my original question. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Michael Cronenworth (m...@cchtml.com) said: Furthermore, my original question still stands: Does anything require usbfs? You did not answer my original question. mkinitrd does; that being said, that's only in the initramfs. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Bill Nottingham on 07/17/2009 11:30 AM wrote: mkinitrd does; that being said, that's only in the initramfs. OK, anything else? If mkinitrd bites the bullet in the new F12 feature then usbfs could be deprecated as well? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
Bill Nottingham wrote: Jon Ciesla (l...@jcomserv.net) said: If this is the case, which is what I was hoping I remembered, then I agree with you that we don't *really* need it. Bill, can you clarify the sse2 or no sse2 distinction, and possibly on the wiki page as well, since it was such a large thread? :) It doesn't require sse2. Emulating CMOV requires someone to merge that patch, which wasn't a committed part of the feature and no one has done that yet, AFAIK. Bill Yay! Thanks. happydance -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fit and Finish test day: batteries and suspend
Just a reminder: The next 'fit and finish' test day will take place on July 21, which is next Tuesday. We want to look at issues with the user experience around batteries, suspend and power management in general. https://fedoraproject.org/wiki/Test_Day:2009-07-21_Fit_and_Finish:Batteries_and_Suspend Please join us in #fedora-fit-and-finish. Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Enrico Scholz on 07/17/2009 12:14 PM wrote: Is there some upstream (linux kernel) discussion to remove usbfs? If not, it should stay as-is. Fedora/RHEL are the last major distros to retain usbfs support apparently. Why not patch VirtualBox to do it correctly? Why not patch your utilities? Again: The issue is not VirtualBox. I provided it as an example and people are running away with it. Stop. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Michael Cronenworth m...@cchtml.com writes: Why not patch VirtualBox to do it correctly? Why not patch your utilities? You want to change something which is not broken and requests that I adapt my workflow and spent work into something to retain old functionality? Again: The issue is not VirtualBox. VirtualBox seems to be the issue. Or do you have other examples of software which uses crappy heuristics based upon the existence of /proc/bus/usb? Enrico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
On Fri, 2009-07-17 at 12:05 -0500, Michael Cronenworth wrote: Matthias Clasen on 07/17/2009 11:50 AM wrote: Just a reminder: The next 'fit and finish' test day will take place on July 21, which is next Tuesday. We want to look at issues with the user experience around batteries, suspend and power management in general. This test day should not be limited to laptops. Even thought the wiki page doesn't state any restrictions, it is implied that this is for laptops. There are some folks that have UPS battery backups that used to function under HAL and F10. Now that DeviceKit has removed all references to UPS devices until they figure out how they want to add them back in, I, and other UPS owners are left without methods of adjusting settings or even using the shutdown feature. I don't want to install httpd and configure config files for apcupsd. If you are going to suggest such, then Fedora has lost touch with reality. Do you feel like writing up a use case involving a UPS ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
On Fri, 2009-07-17 at 12:05 -0500, Michael Cronenworth wrote: Matthias Clasen on 07/17/2009 11:50 AM wrote: Just a reminder: The next 'fit and finish' test day will take place on July 21, which is next Tuesday. We want to look at issues with the user experience around batteries, suspend and power management in general. This test day should not be limited to laptops. Even thought the wiki page doesn't state any restrictions, it is implied that this is for laptops. There are some folks that have UPS battery backups that used to function under HAL and F10. Now that DeviceKit has removed all references to UPS devices until they figure out how they want to add them back in, I, and other UPS owners are left without methods of adjusting settings or even using the shutdown feature. I don't want to install httpd and configure config files for apcupsd. If you are going to suggest such, then Fedora has lost touch with reality. On a practical basis, though, if there's no support in the current code, we can't really _do_ a lot on a Test Day, can we? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
Matthias Clasen on 07/17/2009 12:42 PM wrote: Do you feel like writing up a use case involving a UPS ? As Adam stated in his reply, there is really nothing we can do since UPS devices are not supported at all. I haven't gotten around to bug hunting, but is there a bug for UPS support in DeviceKit? Anything? Thanks, Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
Do you feel like writing up a use case involving a UPS ? As Adam stated in his reply, there is really nothing we can do since UPS devices are not supported at all. I haven't gotten around to bug hunting, but is there a bug for UPS support in DeviceKit? Anything? From today's update in Fedora 11: $ rpm -q --changelog DeviceKit-power | head * lun. juil. 06 2009 Richard Hughes rich...@hughsie.com - 009-1 - Update to 009 - Fixes many problems with multi-battery laptops - Use pm-powersave like HAL used to - Fix detecting UPS devices - Add support for recalled laptop batteries Notice the line about UPS. Now, I have no idea if that means proper support or not, but it seems like it is coming :) -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: New maintainer needed: dumpasn1, freedroid, http_ping, id3v2, pscan, zzuf
I have just picked up id3v2, as I use it occasionally. -- Hans Ulrich Niedermann -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Feature rejected. That combined with the potential of unionfs making this rebootless LiveOS installer not work in F13+, leads me to not be able to personally justify engaging in the process required to bring this package into the repos myself. If someone would like to adopt this package, I would be a very responsive upstream. Also, I do think it was lame that people wasted time bringing up criticisms in the fesco meeting, instead of here, or on the feature talk page. Just as much because it seemed to make a long meeting unnecessarily longer, in addition to my preference for having a better forum than IRC to address criticisms. peace... -dmc Douglas McClendon wrote: Fedorans, Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming Fedora-12 LiveCD, I can provide you with a rebootless installation experience. http://fedoraproject.org/wiki/Features/RebootlessInstaller The short story is that you boot the LiveCD/USB, run the installation, and then, instead of rebooting into the installed OS, you are already looking at and using it. I just threw together a decent first pass at a feature page, with all the relevent info, as well as a couple links to youtube videos showing the complete user experience. Or, if you are the adventurous kind with an idle test system (obviously with no important unbacked up data), simply a) boot an f11-i686 livecd or usb, with an internet connection b) firefox http://viros.org/rebootless c) click the i386 rpm link, and submit to packagekit d) do any partitioning beforehand with fdisk, or whatever gui tool (is palimpsest really supposed to be able to repartition?) e) launch the new desktop icon f) run the installer, simply selecting target root/boot/swap partitions g) enjoy the coolness that is rebootless installation, and my gratitude for being one of the first, if not the second tester :) I would obviously love to see this in F12 even though it could use quite a bit of polish. It is fairly important that it go in sooner rather than later, as when unionfs percolates to fedora, this feature may no longer be technically possible. In the event the feature were wildly popular, and sticks around, obviously integration with anaconda would be next, i.e. simply a checkbox before beginning installation stating whether you want rebootless instead of traditional. In any event, I'd love to hear what people think. I suppose if space is the issue, it could even be a feature just getting the package into the fedora repos so that it could be advertised, with users just needing an internet connection, and not having to see a complaint about lack of signature on the package. But cmon, can you spare 100K? (50 of that is ego/logo I can probably part with :) peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 07/18/2009 12:20 AM, Douglas McClendon wrote: Also, I do think it was lame that people wasted time bringing up criticisms in the fesco meeting, instead of here, or on the feature talk page. Just as much because it seemed to make a long meeting unnecessarily longer, in addition to my preference for having a better forum than IRC to address criticisms. Yes, this has been a common trait for a long time and despite similar comments continue to happen quite often. Unfortunate. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
2009/7/17 Mathieu Bridon (bochecha) boche...@fedoraproject.org: From today's update in Fedora 11: $ rpm -q --changelog DeviceKit-power | head * lun. juil. 06 2009 Richard Hughes rich...@hughsie.com - 009-1 - Update to 009 - Fixes many problems with multi-battery laptops - Use pm-powersave like HAL used to - Fix detecting UPS devices - Add support for recalled laptop batteries Notice the line about UPS. Now, I have no idea if that means proper support or not, but it seems like it is coming :) It should work fine with 009. If it doesn't work, and it used to work with HAL (without nut installed) then please file bugs. I've recently been regression testing with my APC UPS, and this seems to work fine now. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
2009/7/17 Fulko Hew fulko@gmail.com: (Personally, I have a little 'service' that disables the power management on my laptop (on F8), but I haven't found where to execute it when the laptop comes out of 'suspend'?) Check out pm-utils, it allows you do what you want. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
2009/7/17 Michael Cronenworth m...@cchtml.com: There are some folks that have UPS battery backups that used to function under HAL and F10. Now that DeviceKit has removed all references to UPS devices until they figure out how they want to add them back in, There were two bugs that stopped UPS devices being detected correctly. There was nothing removed. I, and other UPS owners are left without methods of adjusting settings or even using the shutdown feature. I don't want to install httpd and configure config files for apcupsd. If you are going to suggest such, then Fedora has lost touch with reality. I think you need to test the latest version in updates before speculating. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESco meeting summary for 20090717
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.log.html 17:01:35 jds2001 #startmeeting FESCo meeting - 2009-07-17 17:02:07 jds2001 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:02:16 jds2001 sorry, phone call 17:02:24 * j-rod here 17:02:25 * sharkcz is here 17:02:25 jwb here 17:02:26 jds2001 full agenda :) 17:02:30 * Kevin_Kofler is here. 17:02:31 * nirik is present. 17:02:35 * notting is here 17:02:57 jds2001 alright, without further ado 17:03:11 jds2001 #topic Sponsor nomination - ianweller 17:03:18 jds2001 .fesco 190 17:03:29 * jds2001 saw no objections on the list, but little feedback 17:03:40 jds2001 +1 17:04:15 notting +1 17:04:15 Kevin_Kofler The request is not very high on specifics. 17:04:30 jds2001 though the reviews are a little light, he's helped new packagers in numerous ways. 17:04:31 * skvidal is here but may not be in a moment 17:04:36 Kevin_Kofler But whatever, I saw no objections either, so +1 from me. 17:04:56 sharkcz +1 17:05:13 * j-rod has no strong feeling one way or the other 17:05:14 nirik +1 here. I think it's good he wants to help sponsor people at that POSEE thing perhaps? 17:05:31 jds2001 yeah, that's pretty much the reason. 17:05:40 jds2001 and teaching open source is a great thing. 17:05:45 j-rod +1 17:05:52 jds2001 #agreed ianweller sponsor nomination is approved 17:06:06 jds2001 #topic provenpackager request - jsteffan 17:06:18 jds2001 .fesco 189 17:06:59 nirik I think it's important that packages with non responsive maintainers get responsive ones... 17:07:06 jds2001 yeah, me too. 17:07:17 nirik that said, it's sometimes also good to fix them when they are broken in a more timely manner. 17:07:24 Kevin_Kofler As long as somebody fixes them, who cares whether they're officially the maintainers? 17:07:47 jds2001 well, they dont directly get bug reports, for one. 17:07:49 nirik Kevin_Kofler: because then bugs go unanswered, no one is watching upstream for updates or fixes, or in general being a maintainer. 17:07:49 jwb urgh. phone. need to drop off for a minute 17:08:25 nirik drive by fixes are great if the problem needs fixing, but long term we need maintainers, not a bunch of people driving around tweaking things as they notice them. at least IMHO. 17:08:33 nirik in any case +1 to this request for me. 17:08:50 Kevin_Kofler +1 to the request from me as well. 17:08:54 j-rod +1 17:09:00 jds2001 +1 here too, but get responsive maintainers :) 17:09:11 jds2001 request comaintainership if you have to. 17:09:16 * nirik was just trying to note that lots of provenpackager requests seem to say 'I want to fix unresponsive packages' which is fine, but we should urge people to get them responsive maintainers also. 17:09:31 jds2001 yeah, they need good TLC :) 17:09:35 Kevin_Kofler jds2001: The problem is that the nonresponsive or lazy maintainers usually don't react to ACL requests either. 17:09:46 notting +1 17:09:49 sharkcz +1 17:10:05 jds2001 #agreed jsteffan provenpackager request is approved 17:10:14 nirik Kevin_Kofler: yeah. Need to run the non responsive process, but it's sometimes a lot of hassle. ;( 17:10:21 jds2001 #topic provenpackager request - oget 17:10:29 j-rod +1 17:10:33 sharkcz +1 17:10:34 jds2001 +1 17:10:43 notting +1 17:10:48 nirik +1 17:10:49 Kevin_Kofler +1 17:10:57 jds2001 #agreed oget provenpackager request is approved. 17:11:38 jds2001 #topic volume_key bundled cryptsetup 17:11:58 jds2001 so we know a little more than last week 17:12:14 nirik I think with the additional info and the fact that this is going to be temp and upstream knows whats going on, I'd be ok with approving it. 17:12:26 jds2001 do I take the comments in the ticket to mean the API won't change? 17:12:30 jds2001 do we know if the new upstream release will be in time for F12? 17:12:42 notting ticket #? 17:12:50 jds2001 oops 17:12:51 Kevin_Kofler https://fedorahosted.org/fesco/ticket/175 17:12:55 jds2001 .fesco 175 17:13:41 notting so, it implies the api/abi of the 'upstream' version might change 17:14:02 nirik but volume_key will be the only user (internal) of the api from now. 17:14:04 notting but no ETA 17:14:17 abadger1999 Eh... knowing that mitr and mbroz are working from the same office and that cryptsetup can update in mid-Fedora release despite having API/ABI changes makes the bundling a bit more acceptable. 17:14:34 * nirik nods. 17:14:37 Kevin_Kofler I believe it will be fairly easy to fix volume_key to use the final API if it has to change (and it might not even have to change). 17:14:40 * sharkcz also nods 17:15:21 jds2001 +1 here 17:15:32 * jds2001 wants to see it gone by f13, though. 17:15:35 sharkcz +1 17:15:39 abadger1999 I don't like mitr's original reasoning but these later
Re: Packages tracked by FEver that need to be updated
On Fri July 17 2009, Rahul Sundaram wrote: On 07/16/2009 11:22 PM, Till Maas wrote: It would be useful to have a dynamically generated webpage that shows how close we are to upstream versions across different Fedora versions similar to the distrowatch packages page. A static webpage that is regenerated every now and then should be easy enough, that I might create it. On my blog the project leader of http://oswatershed.org/ mentioned his project, which is something similiar for different distributions, but it currently does not show any packages for Fedora. Maybe allow package maintainers to add in comments indicating what their plans are, even. For example, if a update is going to break the ABI in a intrusive way (let's say XULRunner) or change the configuration file format (nagios), I as a package maintainer would like to convey that information to my users so they know why I haven't pushed an update despite new features or even minor bug fixes. The bug report could be linked on the page and then the maintainer can use it for this. This should also then be easily doable. Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Michael Cronenworth m...@cchtml.com writes: You want to change something which is not broken and requests that I adapt my workflow and spent work into something to retain old functionality? What about old /dev (pre udev)? It was not broken. Sure, you couldn't add nice new functionality quickly, but it wasn't broken. Static /dev still exists and works perfectly in servers or embedded devices. Recent udev did not removed features (as you are requesting) and its extras seem to outweight its drawbacks (high boot times). Should we have kept HAL then? Keep using HAL forever? Dunno; I did and do not use hal on pre FC11 machines. This type of mindset works until there is a better solution. There are better solutions to usbfs today. Most distros use the newer alternative. There is not needed an alternative. usbfs and the udev/sysfs based approach coexist nicely. You ignored my initial comment on this and seem to want to be ignorant of such a fact. Which initial comment? That you want to remove a feature to workaround bugs in an application? VirtualBox seems to be the issue. Or do you have other examples of software which uses crappy heuristics based upon the existence of /proc/bus/usb? That particular software does not depend on usbfs, but it seems that VBox will be a scape goat for your whining until I convince you otherwise. If you had read the thread beforehand you probably would not have replied. Please read the whole thread. Sorry; you must be subscribed to another maillist than me. Here, no article in this thread justifies removal of usbfs with anything else than the broken VirtualBox. Enrico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
Enrico Scholz on 07/17/2009 03:41 PM wrote: Which initial comment? That you want to remove a feature to workaround bugs in an application? Michael Cronenworth wrote: Fedora/RHEL are the last major distros to retain usbfs support apparently. Sorry; you must be subscribed to another maillist than me. Here, no article in this thread justifies removal of usbfs with anything else than the broken VirtualBox. You're trolling now. For the last time: This has nothing to do with VirtualBox. There is no bug in VirtualBox. There is no patch required for VirtualBox. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
On Fri, 2009-07-17 at 10:00 -0400, Bill Nottingham wrote: John Poelstra (poels...@redhat.com) said: https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support Both updated now. Apologies for the dlay. Bill A possibly stupid question: The above page states that the flags will be -march=i686 -mtune=atom on i386, but a build I just did in rawhide has -march=i686 -mtune=generic so -march has changed but -mtune hasn't? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
A possibly stupid question: The above page states that the flags will be -march=i686 -mtune=atom on i386, but a build I just did in rawhide has -march=i686 -mtune=generic so -march has changed but -mtune hasn't? What version of redhat-rpm-config was in the buildroot? (You should be able to pull this from one of the log files.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
Bill Nottingham (nott...@redhat.com) said: A possibly stupid question: The above page states that the flags will be -march=i686 -mtune=atom on i386, but a build I just did in rawhide has -march=i686 -mtune=generic so -march has changed but -mtune hasn't? What version of redhat-rpm-config was in the buildroot? (You should be able to pull this from one of the log files.) Actually, looking myself: DEBUG util.py:256: redhat-rpm-confignoarch9.0.3-9.fc12 build 56 k So, your build started before the buildroot had been regenerated with the new redhat-rpm-config package. Later builds such as http://kojipkgs.fedoraproject.org/packages/libev/3.70/2.fc12/data/logs/i686/build.log) pull in the new redhat-rpm-config, and get the flags set. (And no, I wouldn't worry about a rebuild just for that.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fit and Finish test day: batteries and suspend
Richard Hughes on 07/17/2009 02:07 PM wrote: It should work fine with 009. If it doesn't work, and it used to work with HAL (without nut installed) then please file bugs. I've recently been regression testing with my APC UPS, and this seems to work fine now. 009 displays my UPS's again. I believe I had mistakenly stated that the change from HAL to DeviceKit removed UPS device information, but this was related to something else. Thanks for the update. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates and delays in signing packages
Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On 07/18/2009 03:11 AM, drago01 wrote: On Fri, Jul 17, 2009 at 11:19 PM, Rahul Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? You don't have to push _every_ upstream release as an update. Was I not clear? In my case, I do often have to. They fix important bugs. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 12:01 AM, Rahul Sundaramsunda...@fedoraproject.org wrote: On 07/18/2009 03:11 AM, drago01 wrote: On Fri, Jul 17, 2009 at 11:19 PM, Rahul Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? You don't have to push _every_ upstream release as an update. Was I not clear? In my case, I do often have to. They fix important bugs. Sure but lets say upstream releases every week and you rebase every second week, whats wrong with that? Unless they are really critical bugs (dataloss / security). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Fri, Jul 17, 2009 at 5:19 PM, Rahul Sundaram wrote: Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? Rahul I think that marking the package that is already in testing as stable and submitting a new version to the testing even before the former one makes its place in the stable repo is the proper way to go. This way the old version does not get obsoleted. I did this once and it worked. Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 02:49:36AM +0530, Rahul Sundaram wrote: Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? I am not exaggerating when I say that updates are getting pushed out as fast as I can possibly make them. And signing is NOT, by any means, the hold up or the slow part. It takes me roughly an hour to get all the pending updates signed for a push (both testing and stable). It takes a push between 2 and 3 days to actually complete right now. We've had some significant delays due to a variety of factors over the past couple of weeks. I think we now have most of the big ones fixed, with the master mirrors allowing more rsync access, and the updates composes now being able to hardlink again (reduces mash time). There is another issue involving deltarpms that I've filed a bug on, and we should get some speed-up if we can get that figured out too. That being said, the updates push will still take quite some time to generate deltas. I'm hoping we can get it down to being able to do a complete push to within a 24 hour period for now, but that remains to be seen. Also keep in mind that as F11 grows older, the mash time for it will increase. I can understand your concern with a very active package like that. At the moment, we can't do anything we aren't already trying to do to get official updates out faster. Have patience. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 05:02:15AM +0530, Rahul Sundaram wrote: Yes, there has been critical bugs. Crashes within a number of releases and atleast one potential data loss issue. I really do mean that I have a need to update often. If software is that unstable then I think it's reasonable to ask whether it's ready to be shipped in a stable distribution release. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On 07/18/2009 06:30 AM, Matthew Garrett wrote: On Sat, Jul 18, 2009 at 05:02:15AM +0530, Rahul Sundaram wrote: Yes, there has been critical bugs. Crashes within a number of releases and atleast one potential data loss issue. I really do mean that I have a need to update often. If software is that unstable then I think it's reasonable to ask whether it's ready to be shipped in a stable distribution release. I think it is. It is not crashing and burning for all the users using it including me all the time. Let's take the latest bug report I have received https://bugzilla.redhat.com/show_bug.cgi?id=511053 It requires you to access the help in a particular way to get it to crash but I consider a crash a problem that needs to be fixed quickly. This doesn't make it in unstable enough to be excluded compared to rest of what we have been included by default in the past and Gnote is not the default in any stable release. Anyway, you are sort of missing the point by focusing on the example given without understanding that for a certain class of software (new project where upstream is active, user demand new features etc) with frequent updates, the current system isn't working out well. I doubt I am the only maintainer with this problem. I Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 06:10:49AM +0530, Rahul Sundaram wrote: On 07/18/2009 05:27 AM, Josh Boyer wrote: I can understand your concern with a very active package like that. At the moment, we can't do anything we aren't already trying to do to get official updates out faster. Have patience. The question wasn't about why there was delays but how I can handle it within my workflow (I thought of just running my own repo but that doesn't seem ideal) but it is good to know more of the inside details on It might not be ideal, but given that you're waiting for pushes to get your builds into repos it might also be the most convenient for the people that want those builds. Putting repos on a fedorapeople page is not unheard of. why there are delays in the first place. On a related point, do we have good documentation on the entire process? If there is a need for more to No. I think our documentation of the entire push process doesn't exist. Some of it we don't want to exist, like how to get onto the signing machine. Some of it really can't be documented because it's dealing with issues as they come up in one form or another and there is no common error scenario. Other parts are changing at a somewhat rapid pace as we introduce new fixes and features. I think the best way to start is to get better documentation on the various software components involved first. Those would be bodhi, mash, createrepo, and deltarpm for the most part. Bodhi and mash would be good (and daunting) places to start. help with signing the packages, I can volunteer (assuming you let me). Signing is not the hurdle. Adding more people to help there won't really make anything faster. We're also toying with making koji do auto-signing at build time, which makes it basically go away. I do appreciate the offer though. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On 07/18/2009 06:56 AM, Josh Boyer wrote: I think the best way to start is to get better documentation on the various software components involved first. Those would be bodhi, mash, createrepo, and deltarpm for the most part. Bodhi and mash would be good (and daunting) places to start. I think I might be able to help. So, let's suppose I come up on IRC and ask questions to get them documented, who can help me with that? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 06:45:21AM +0530, Rahul Sundaram wrote: On 07/18/2009 06:30 AM, Matthew Garrett wrote: If software is that unstable then I think it's reasonable to ask whether it's ready to be shipped in a stable distribution release. I think it is. It is not crashing and burning for all the users using it including me all the time. Let's take the latest bug report I have received https://bugzilla.redhat.com/show_bug.cgi?id=511053 It requires you to access the help in a particular way to get it to crash but I consider a crash a problem that needs to be fixed quickly. If it's not a common pathway then I don't think it's urgent - certainly not urgent enough that waiting an extra week is a big problem. This doesn't make it in unstable enough to be excluded compared to rest of what we have been included by default in the past and Gnote is not the default in any stable release. Anyway, you are sort of missing the point by focusing on the example given without understanding that for a certain class of software (new project where upstream is active, user demand new features etc) with frequent updates, the current system isn't working out well. I doubt I am the only maintainer with this problem. I Most of our users wait 6 months between releases. If they can wait that long to get a new piece of software in the first place, the difference between an upload a week and an upload every two weeks shouldn't be much of an issue. I just really don't see how feature requests can be that high a priority during a stable release. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On 07/18/2009 08:53 AM, Matthew Garrett wrote: Most of our users wait 6 months between releases. If they can wait that long to get a new piece of software in the first place, the difference between an upload a week and an upload every two weeks shouldn't be much of an issue. I just really don't see how feature requests can be that high a priority during a stable release. A day after the release when I get six mails, I would say that is high priority. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Glib/devel perl-Glib.spec,1.32,1.33
Author: kasal
Update of /cvs/extras/rpms/perl-Glib/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8449
Modified Files:
perl-Glib.spec
Log Message:
- create devel subpackage, so that the main one does not require
the whole perl-devel (#509419)
Index: perl-Glib.spec
===
RCS file: /cvs/extras/rpms/perl-Glib/devel/perl-Glib.spec,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -p -r1.32 -r1.33
--- perl-Glib.spec 13 Mar 2009 20:13:35 - 1.32
+++ perl-Glib.spec 17 Jul 2009 14:23:16 - 1.33
@@ -1,6 +1,6 @@
Name: perl-Glib
Version:1.201
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl interface to GLib
Group: Development/Libraries
@@ -17,7 +17,7 @@ BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
-This module provides perl access to Glib and GLib's GObject libraries.
+This module provides perl access to GLib and GLib's GObject libraries.
GLib is a portability and utility library; GObject provides a generic
type system with inheritance and a powerful signal system. Together
these libraries are used as the foundation for many of the libraries
@@ -25,6 +25,13 @@ that make up the Gnome environment, and
projects.
+%package devel
+Summary: Development part of Perl interface to GLib
+
+%description devel
+Development part of package perl-Glib, the Perl module providing interface
+to GLib and GObject libraries.
+
%prep
%setup -q -n Glib-%{version}
@@ -66,9 +73,31 @@ rm -rf $RPM_BUILD_ROOT
%{perl_vendorarch}/auto/Glib/
%{perl_vendorarch}/Glib*
%{_mandir}/man3/*.3pm*
+%exclude %{perl_vendorarch}/Glib/*/*.h
+%exclude %{perl_vendorarch}/Glib/MakeHelper.pm
+%exclude %{perl_vendorarch}/Glib/devel.pod
+%exclude %{perl_vendorarch}/Glib/xsapi.pod
+%exclude %{_mandir}/man3/Glib::MakeHelper.3pm.gz
+%exclude %{_mandir}/man3/Glib::devel.3pm.gz
+%exclude %{_mandir}/man3/Glib::xsapi.3pm.gz
+
+
+%files devel
+%defattr(-,root,root,-)
+%{perl_vendorarch}/Glib/*/*.h
+%{perl_vendorarch}/Glib/MakeHelper.pm
+%{perl_vendorarch}/Glib/devel.pod
+%{perl_vendorarch}/Glib/xsapi.pod
+%{_mandir}/man3/Glib::MakeHelper.3pm.gz
+%{_mandir}/man3/Glib::devel.3pm.gz
+%{_mandir}/man3/Glib::xsapi.3pm.gz
%changelog
+* Fri Jul 17 2009 Stepan Kasal ska...@redhat.com - 1.201-3
+- create devel subpackage, so that the main one does not require
+ the whole perl-devel (#509419)
+
* Fri Mar 13 2009 Tom spot Callaway tcall...@redhat.com - 1.201-2
- dont run the tests on ppc
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 509419] perl-Glib Requires a development package: perl(ExtUtils::MakeMaker)
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=509419 Stepan Kasal ska...@redhat.com changed: What|Removed |Added Status|NEW |MODIFIED CC||ska...@redhat.com AssignedTo|tcall...@redhat.com |ska...@redhat.com --- Comment #2 from Stepan Kasal ska...@redhat.com 2009-07-17 10:21:23 EDT --- Fixed in rawhide by creating a separate devel subpackage. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Glib/F-11 perl-Glib.spec,1.32,1.33
Author: kasal
Update of /cvs/extras/rpms/perl-Glib/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14751
Modified Files:
perl-Glib.spec
Log Message:
- create devel subpackage, so that the main one does not require
the whole perl-devel (#509419)
Index: perl-Glib.spec
===
RCS file: /cvs/extras/rpms/perl-Glib/F-11/perl-Glib.spec,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -p -r1.32 -r1.33
--- perl-Glib.spec 13 Mar 2009 20:13:35 - 1.32
+++ perl-Glib.spec 17 Jul 2009 14:40:34 - 1.33
@@ -1,6 +1,6 @@
Name: perl-Glib
Version:1.201
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl interface to GLib
Group: Development/Libraries
@@ -17,7 +17,7 @@ BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
-This module provides perl access to Glib and GLib's GObject libraries.
+This module provides perl access to GLib and GLib's GObject libraries.
GLib is a portability and utility library; GObject provides a generic
type system with inheritance and a powerful signal system. Together
these libraries are used as the foundation for many of the libraries
@@ -25,6 +25,13 @@ that make up the Gnome environment, and
projects.
+%package devel
+Summary: Development part of Perl interface to GLib
+
+%description devel
+Development part of package perl-Glib, the Perl module providing interface
+to GLib and GObject libraries.
+
%prep
%setup -q -n Glib-%{version}
@@ -66,9 +73,31 @@ rm -rf $RPM_BUILD_ROOT
%{perl_vendorarch}/auto/Glib/
%{perl_vendorarch}/Glib*
%{_mandir}/man3/*.3pm*
+%exclude %{perl_vendorarch}/Glib/*/*.h
+%exclude %{perl_vendorarch}/Glib/MakeHelper.pm
+%exclude %{perl_vendorarch}/Glib/devel.pod
+%exclude %{perl_vendorarch}/Glib/xsapi.pod
+%exclude %{_mandir}/man3/Glib::MakeHelper.3pm.gz
+%exclude %{_mandir}/man3/Glib::devel.3pm.gz
+%exclude %{_mandir}/man3/Glib::xsapi.3pm.gz
+
+
+%files devel
+%defattr(-,root,root,-)
+%{perl_vendorarch}/Glib/*/*.h
+%{perl_vendorarch}/Glib/MakeHelper.pm
+%{perl_vendorarch}/Glib/devel.pod
+%{perl_vendorarch}/Glib/xsapi.pod
+%{_mandir}/man3/Glib::MakeHelper.3pm.gz
+%{_mandir}/man3/Glib::devel.3pm.gz
+%{_mandir}/man3/Glib::xsapi.3pm.gz
%changelog
+* Fri Jul 17 2009 Stepan Kasal ska...@redhat.com - 1.201-3
+- create devel subpackage, so that the main one does not require
+ the whole perl-devel (#509419)
+
* Fri Mar 13 2009 Tom spot Callaway tcall...@redhat.com - 1.201-2
- dont run the tests on ppc
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 509419] perl-Glib Requires a development package: perl(ExtUtils::MakeMaker)
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=509419 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2009-07-17 11:06:32 EDT --- perl-Glib-1.201-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/perl-Glib-1.201-3.fc11 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-DebugScreen/F-11 import.log, NONE, 1.1 perl-CGI-Application-Plugin-DebugScreen.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DebugScreen/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6316/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-DebugScreen.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-DebugScreen-0_06-1_fc11:F-11:perl-CGI-Application-Plugin-DebugScreen-0.06-1.fc11.src.rpm:1247846218
--- NEW FILE perl-CGI-Application-Plugin-DebugScreen.spec ---
Name: perl-CGI-Application-Plugin-DebugScreen
Version:0.06
Release:1%{?dist}
Summary:Add Debug support to CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-DebugScreen/
Source0:
http://www.cpan.org/authors/id/N/NE/NEKOKAK/CGI-Application-Plugin-DebugScreen-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(CGI::Application::Plugin::ViewCode)
BuildRequires: perl(Devel::StackTrace)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTML::Template)
BuildRequires: perl(UNIVERSAL::require)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This plugin adds debug support to CGI::Application and works like
Catalyst's debug mode.
%prep
%setup -q -n CGI-Application-Plugin-DebugScreen-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Dec 22 2008 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.06-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file:
/cvs/pkgs/rpms/perl-CGI-Application-Plugin-DebugScreen/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 17 Jul 2009 15:47:51 - 1.1
+++ .cvsignore 17 Jul 2009 16:03:04 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-DebugScreen-0.06.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DebugScreen/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 17 Jul 2009 15:47:51 - 1.1
+++ sources 17 Jul 2009 16:03:04 - 1.2
@@ -0,0 +1 @@
+e696350727a676fcc335bc04188972ac
CGI-Application-Plugin-DebugScreen-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-DebugScreen/F-10 import.log, NONE, 1.1 perl-CGI-Application-Plugin-DebugScreen.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DebugScreen/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6818/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-DebugScreen.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-DebugScreen-0_06-1_fc11:F-10:perl-CGI-Application-Plugin-DebugScreen-0.06-1.fc11.src.rpm:1247846656
--- NEW FILE perl-CGI-Application-Plugin-DebugScreen.spec ---
Name: perl-CGI-Application-Plugin-DebugScreen
Version:0.06
Release:1%{?dist}
Summary:Add Debug support to CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-DebugScreen/
Source0:
http://www.cpan.org/authors/id/N/NE/NEKOKAK/CGI-Application-Plugin-DebugScreen-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(CGI::Application::Plugin::ViewCode)
BuildRequires: perl(Devel::StackTrace)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTML::Template)
BuildRequires: perl(UNIVERSAL::require)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This plugin adds debug support to CGI::Application and works like
Catalyst's debug mode.
%prep
%setup -q -n CGI-Application-Plugin-DebugScreen-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Dec 22 2008 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.06-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file:
/cvs/pkgs/rpms/perl-CGI-Application-Plugin-DebugScreen/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 17 Jul 2009 15:47:51 - 1.1
+++ .cvsignore 17 Jul 2009 16:04:33 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-DebugScreen-0.06.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DebugScreen/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 17 Jul 2009 15:47:51 - 1.1
+++ sources 17 Jul 2009 16:04:33 - 1.2
@@ -0,0 +1 @@
+e696350727a676fcc335bc04188972ac
CGI-Application-Plugin-DebugScreen-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 511634] FTBFS perl-IPC-Run-0.82-2.fc11
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=511634 Matt Domsch matt_dom...@dell.com changed: What|Removed |Added Status|ASSIGNED|CLOSED CC||matt_dom...@dell.com Resolution||NOTABUG --- Comment #5 from Matt Domsch matt_dom...@dell.com 2009-07-17 12:37:40 EDT --- This was a build system failure, not a package bug. I apologize. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 511733] FTBFS perl-Tie-IxHash-1.21-9.fc11
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=511733 Matt Domsch matt_dom...@dell.com changed: What|Removed |Added Status|ASSIGNED|CLOSED CC||matt_dom...@dell.com Resolution||NOTABUG --- Comment #5 from Matt Domsch matt_dom...@dell.com 2009-07-17 12:39:22 EDT --- This was a build system failure, not a package bug. I apologize. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 511569] FTBFS perl-Mail-Box-2.087-1.fc11
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=511569 Matt Domsch matt_dom...@dell.com changed: What|Removed |Added Status|ASSIGNED|CLOSED CC||matt_dom...@dell.com Resolution||NOTABUG --- Comment #5 from Matt Domsch matt_dom...@dell.com 2009-07-17 12:57:26 EDT --- This was a build system failure, not a package bug. I apologize. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 496891] perl-Net-Jabber not available in EPEL
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=496891 --- Comment #3 from Chris Weyl cw...@alumni.drew.edu 2009-07-17 14:25:52 EDT --- Hey -- sorry about that; I think I lumped this in with a couple other EPEL bugs I killed :) You're quite welcome to own them for EPEL (and Fedora for that matter); feel free to file cvs branch requests, citing this bug if anyone questions it. Let me know if I need to release anything to you in the pkgdb. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 496891] perl-Net-Jabber not available in EPEL
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=496891 --- Comment #4 from Xavier Bachelot xav...@bachelot.org 2009-07-17 18:22:06 EDT --- Thanks Chris. I requested the EL-5 branches and also I requested commit rights to the active Fedora branches. Regards, Xavier -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 496891] perl-Net-Jabber not available in EPEL
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=496891 Xavier Bachelot xav...@bachelot.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|cw...@alumni.drew.edu |xav...@bachelot.org --- Comment #5 from Xavier Bachelot xav...@bachelot.org 2009-07-17 18:24:11 EDT --- Oh, I thinks it's easier to assign the bug to myself now, as I'll be the one to import and build the packages. -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Broken dependencies: perl-AnyEvent
perl-AnyEvent has broken dependencies in the development tree: On ppc: perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) On x86_64: perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) On i386: perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) On ppc64: perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Loop) perl-AnyEvent-4.820-1.fc12.noarch requires perl(IO::Async::Handle) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
