Re: Is RPM now stricter about checking for file conflicts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/10/2012 21:38, Panu Matilainen wrote: On 10/29/2012 04:06 PM, Michel Alexandre Salim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2012 05:39 PM, Petr Pisar wrote: On 2012-10-29, Michel Alexandre Salim sali...@fedoraproject.org wrote: On 10/28/2012 04:08 AM, Paul Howarth wrote: Is there any RPM-fu I can use to extract the ownership and permissions from the package for comparison? rpm -q -lv -p foo.rpm Aha, thanks! - - google-musicmanager has /usr/bin with 644 permission; filesystem has 444 - - VirtualBox-4.2 has /lib/modules; filesystem has /usr/lib/modules with /lib - /usr/lib /lib/modules vs /usr/lib/modules with /lib - /usr/lib link does not cause a conflict, the different permissions of the modules directory does. The right thing for VirtualBox to do is to not try to own such directories in the first place (it claims to own /usr/bin, stuff under /usr/share etc too) Yep. They fixed the directory ownership in SVN already; I'm now creating a local clone so I can examine the code more closely, and if necessary, submit more patches -- I suspect they now have another (more trivial) problem - not depending on the packages that should provide those directories (e.g. hicolor-icon-theme) - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkhZNAAoJEEr1VKujapN6YikH/2vFXwAcCmRlMnVkVGIgALEE CegV1fXc20BFnTLNA9CCqMaDdCHL8r0QfAXPHcg70p3wUIztF6Ho8ySxLaBw7IH+ f84MFJjW2XeZpkUtZ3U9pkk2BdW4VzW5JtWuA0RJ5HGp43kF0Vp0HY4ia1jK6sVB Bld9eAhoBCfRZKaT884fsgcmlsg0O8GrXJwxkYKHJYHwO31vUeLvCUPlAWHkdIzp 5zGRDM1QP0bGbBjSPpolAru6MVpkPBh/AVRVR9tl7D96IVPRBsx5KWAS7tAbF8Y1 fc4gkXeZkKcc3YYwEWxA9Fj4QbSdHgeOFYkA9XSHZ2E9GrzDwlZs0Qd0bLzMnKs= =qcdb -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/31/2012 11:00 PM, Toshio Kuratomi wrote: On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote: I think we need to give developers more time for feature integration after the feature freeze. +1 No matter whether we increase the length of development or not, the time between feature freeze and the spinning of a release is too quick. No matter which length of timeslots you choose, these timeslots will always be too short. IMO, Fedora devs and FESCO needs to take fallback strategies and backing-out strategies into account right from the beginning and be prepared for devs not meeting deadlines. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 : broken configuration for httpd 2.4
Le 31/10/2012 22:25, Gianluca Sforna a écrit : So, befoer I dig into manuals, can you name the most common causes for breakage? Some explanation on the tracker bug https://bugzilla.redhat.com/show_bug.cgi?id=871373 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, Nov 1, 2012 at 6:37 AM, Ralf Corsepius rc040...@freenet.de wrote: On 10/31/2012 11:00 PM, Toshio Kuratomi wrote: On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote: I think we need to give developers more time for feature integration after the feature freeze. +1 No matter whether we increase the length of development or not, the time between feature freeze and the spinning of a release is too quick. No matter which length of timeslots you choose, these timeslots will always be too short. IMO, Fedora devs and FESCO needs to take fallback strategies and backing-out strategies into account right from the beginning and be prepared for devs not meeting deadlines. And be prepared to take the hard decision to enforce them. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/01/2012 08:37 AM, Ralf Corsepius wrote: On 10/31/2012 11:00 PM, Toshio Kuratomi wrote: On Wed, Oct 31, 2012 at 10:59:54AM -0700, Jesse Keating wrote: I think we need to give developers more time for feature integration after the feature freeze. +1 No matter whether we increase the length of development or not, the time between feature freeze and the spinning of a release is too quick. No matter which length of timeslots you choose, these timeslots will always be too short. IMO, Fedora devs and FESCO needs to take fallback strategies and backing-out strategies into account right from the beginning and be prepared for devs not meeting deadlines. Nod. Seems to me one of the bigger issues is the tendency for features to crash-land right on the eve of the freeze + branch - so late there might not be time to revert (or at least postpone) them in case piles of unforeseen issues are found. Witness UsrMove which landed *just before* the branch, when something of that scale should've landed immediately *after* a branch to give time to discover and fix most of the problems it brought in rawhide. There are features and features... some of them are new versions of leafnode packages or a just bunch of new packages which nothing else depends on, and some of them affect *everything* in the distro. Perhaps the invasive changes should have a considerably earlier deadline, and if the deadline is not met then the feature would be automatically postponed to next release. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F18 yum update problem
http://fpaste.org/5mbi/ 2 days ago It was just a libvirt package but now gnome and empathy packages also broken too. -- -- Onuralp SEZER Fedora Ambassadors http://fedoraproject.org/wiki/Ambassadors EMEAhttp://fedoraproject.org/wiki/Ambassadors/EMEAMember / Turkey Fedora Translations Turkish Team Memberhttps://fedora.transifex.net/projects/p/fedora/team/tr/ HP Pavilion Dv6 3031-et Fedora 17 KDE HP Notebook (Smolt Reporthttp://www.smolts.org/client/show_all/pub_f8e3aacb-d047-4ff0-ad50-b91b2a6ecf1e ) Monster Notebook Fedora 18 Gnome MONSTER Notebook (Smolt Reporthttp://www.smolts.org/client/show/pub_ee6e06c6-42e8-4f63-bd6b-3a6a6fc41345 ) Nvidia GTX 680M with Optimus and Intel Ivy Bridge Intel® Core™ i7-3720QM CPU @ 2.60GHz × 8 4x4 GB Kingston HyperX KIT CL11 1866 MHZ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 yum update problem
On Thu, 1 Nov 2012 10:03:20 +0200 Onuralp SEZER thunderbir...@fedoraproject.org wrote: http://fpaste.org/5mbi/ 2 days ago It was just a libvirt package but now gnome and empathy packages also broken too. Not broken as such, just that not all pkgs arrive in the repo, at the same time. Did you try the suggestion at the end: yum --skip-broken update Testing-list would be more suitable https://admin.fedoraproject.org/mailman/listinfo/test for non development type of questions. -- Regards, Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 yum update problem
On Thursday, November 01, 2012 04:03 PM, Onuralp SEZER wrote: http://fpaste.org/5mbi/ 2 days ago It was just a libvirt package but now gnome and empathy packages also broken too. You're using the -testing repositories. Packages get pushed there, unpushed, downgraded,... If, for example, libfoobar-1 is in fedora and libfoobar-2 is pushed to updates-testing, and you update to it, then it gets unpushed because it was found that it is too broken. From now on, the latest version of libfoobar in the repositories is libfoobar-1, but on your machine it is libfoobar-2. Later on, somebody pushes an update to baz which builds against libfoobar-1, you will get this kind of broken dependency issues. That's expected with testing repositories. When you're running with updates-testing enabled (or Rawhide), don't use yum update, use yum distro-sync instead, as that will both upgrade and downgrade the packages, so that your machine is always consistent with what is in the repositories. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Tom Lane píše v St 31. 10. 2012 v 11:08 -0400: Adam Williamson awill...@redhat.com writes: ... Practically speaking, for F18, though, I think we just need to soldier on with newUI and get it done as best we can. Obviously slipping the schedule by a week again and again in response to the latest fire isn't the best way to do things, but stepping back and taking a wider view, a release that's a month or two behind but with a reasonably solid new anaconda wouldn't be a disaster. My concern at this point is exactly that we're slipping a week at a time, rather than facing up to the *undeniable fact* that anaconda is not close to being shippable. If we don't have a workable contingency plan, I think the best thing to do would be to start slipping a month at a time. That would also definitely help from the PR perspective. Another and another announcement of a slip by one week is starting to be ridiculous. We should finally admit that we've screwed up this release and it would take a significant delay to fix it. I think the community will accept it better than a continuous stream of one-week slips. It's also better for planning to know an honest estimation of the final release of F18. People, who are not familiar with the state of Anaconda, still believe that F18 will be released on the Dec 11th and plan e.g. release parties accordingly. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Le mercredi 31 octobre 2012 à 10:59 -0700, Jesse Keating a écrit : On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. Or do like Debian and have more than 1 freeze. IE, the basesystem is freezed and then the rest is freezed. Having packages on the critical path to be frozen sooner could make sense. Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
On 10/31/2012 01:07 PM, Seth Vidal wrote: // small wrapper script around deltacloud: $ wget https://raw.github.com/movitto/mycloud/master/mycloud.rb $ chmod +x mycloud.rb // template describing kojihub cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koji/fedora-17/koji_f17.xml // template describing kojibuild cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koji/fedora-17/koji_builder_f17.xml // edit kojihub deployment to contain openstack credentials $ vim koji_f17.xml // startup an instance on openstack w/ kojihub setup togo $ ./mycloud.rb koji_f17.xml Mo, Interesting! You can orchestrate all of these steps across/between multiple systems using ansible: http://ansible.cc - I've been documenting spinning up and provisioning instances on my blog in the last week or so. You might take a look - it should solve the problem of the above needing to be so manual of a process and it requires nothing other than ssh be installed on the machine you're trying to configure/control. Cool thanks for the info Seth. Ansible looks interesting, its a configuration orchestration component akin to Puppet / Chef is it not? Does it do any provisioning in itself? The ec2_create utility on your blog seems to call out to euca2ools to do the actual provisioning on ec2 correct? You'd still want a component such as Deltacloud to abstractify commands to different cloud providers would you not? -Mo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Re: Deploying fedora infrastructure (koji) across clouds
On 10/31/2012 01:10 PM, Seth Vidal wrote: On Wed, 31 Oct 2012, Mo Morsi wrote: #2: Could there be a way to take a (working) nightly build, build one's package against that nightly in a personal build of some sort, and somehow have a verification process that it built in that personal build before it goes into rawhide, etc? (or even... unit tests, etc.)? Absolutely, repositories and packages can be added on the fly, and we can incorporate any image already pushed to the cloud as well as build new ones for our purposes. Is this a new feature in koji, then? B/c in the past adding repositories has been a major limiting factor in koji. Especially untrusted, remote repositories. Hrm I was refering more to the repos necessary to bootstrap the cloud instance for the koji builder. Which component imposes this limitation on koji, the hub or the builder? Would being able to build custom cloud images on the fly for different clouds assist with this? We are able to do that w/ our imagefactory / oz tools (written in Python incidently [1][2]) -Mo [1] https://github.com/aeolusproject/imagefactory [2] https://github.com/clalancette/oz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deploying fedora infrastructure (koji) across clouds
On 11/01/2012 08:33 AM, Mo Morsi wrote: On 10/31/2012 01:10 PM, Seth Vidal wrote: On Wed, 31 Oct 2012, Mo Morsi wrote: #2: Could there be a way to take a (working) nightly build, build one's package against that nightly in a personal build of some sort, and somehow have a verification process that it built in that personal build before it goes into rawhide, etc? (or even... unit tests, etc.)? Absolutely, repositories and packages can be added on the fly, and we can incorporate any image already pushed to the cloud as well as build new ones for our purposes. Is this a new feature in koji, then? B/c in the past adding repositories has been a major limiting factor in koji. Especially untrusted, remote repositories. Hrm I was refering more to the repos necessary to bootstrap the cloud instance for the koji builder. Which component imposes this limitation on koji, the hub or the builder? Would being able to build custom cloud images on the fly for different clouds assist with this? We are able to do that w/ our imagefactory / oz tools (written in Python incidently [1][2]) -Mo [1] https://github.com/aeolusproject/imagefactory [2] https://github.com/clalancette/oz Heh, speak about timing, imagefactory was just hosted on the latest FLOSS Weekly: http://www.youtube.com/watch?v=H5z-tpYS0Ng -Mo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
And whoever want to install unity or these packages, can just use GNOME:Ayatana from the open build service :) regards, Damian 2012/11/1 Adam Williamson awill...@redhat.com: I currently own a few packages related to my old abortive attempt to build Unity for Fedora. I don't have time to maintain these or any direct interest in them - they were just Unity building blocks to me. I'm orphaning these packages: bamf compiz-plugins-main (for f16 only) dee libindicator Only one package depends on any of these: gwibber depends on dee. So someone interested in gwibber might want to pick up dee. It's not a difficult package to maintain, but I don't have any real interest in it. Other than that, I don't see that there's any reason anyone would want to pick these up, but maybe someone does. compiz itself was retired some time back - I should have orphaned compiz-plugins-main at the same time, but never did. I don't recall how I wound up owning it. It only appears to be 'alive' for F16 anyhow. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rubygem-{bunny,moneta,ohai} package ownership
The packages look like they were retired after being orphaned for a few fedora cycles. You'll need to resubmit them proper, but should be able to base the new packages on the existing ones pre-retirement. And in the case of moneta, the package version is the same so that can just be resubmitted as is. If you need some help seeing these through (or w/ getting Chef in Fedora in general), shout out on the ruby-sig mailing list [1] and we can help you out. -Mo [1] http://fedoraproject.org/wiki/Ruby_SIG On 10/31/2012 05:48 PM, Julian C. Dunn wrote: I'm trying to take over the work Jonas Courteau started earlier this year (see below) in regards to getting Opscode Chef into Fedora. To start, I'd like to assume responsibility for the above orphaned packages in Fedora, which are dependencies for Chef. I am already a Fedora Packager but I can't seem to Take Ownership of said packages in the package DB. Can anyone assist? - Julian On Mon, May 21, 2012 at 10:36 PM, Jonas Courteau r...@courteau.org wrote: My apologies; the links on that were wrong. Big copy/paste error on my part; not a good start! The main package, rubygem-chef is at https://bugzilla.redhat.com/show_bug.cgi?id=823352, and the other packages are linked off of there. A little bit about myself: I'm a network administrator who has been using CentOS extensively for around 5 years, and Chef for about 3 years. As part of this, I've done a fair amount of packaging of various software for our internal repository using mock and the EPEL packaging guidelines. A large part of my early packaging efforts involved packaging assorted Ruby gems. Recently, I've been working with opscode to get Chef packaged up for Fedora (and EPEL, in the future). There was a previous abortive attempt to get Chef into Fedora but the volunteer involved at the time had other requirements on his time. I'm looking to maintain this package (and its requirements) on a long-term basis, since there is a fair bit of demand to have Chef be a bit more widely available. Please let me know if you have any further questions, or if you have any suggestions on proceeding from here. Thanks! Jonas Courteau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121101 changes
Compose started at Thu Nov 1 09:15:25 UTC 2012 Broken deps for x86_64 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dnf] dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey = 0:0.3.0 [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.4.0.0 [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires gnome-shell-extensions-user-theme [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [perl-Hardware-Verilog-Parser] perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires perl(:MODULE_COMPAT_5.14.2) [perl-OpenOffice-UNO] perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [presence] presence-0.4.6-2.fc18.x86_64 requires libcogl.so.9()(64bit) [pyfuzzy] pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python [reciteword] reciteword-0.8.4-10.fc18.x86_64 requires esound [resource-agents] resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit) resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit) [ruby-revolution] ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libedataserver-1.2.so.16()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libecal-1.2.so.12()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libebook-1.2.so.13()(64bit) [rubygem-activeldap] rubygem-activeldap-1.2.2-3.fc17.noarch requires rubygem(gettext_activerecord) = 0:2.1.0 rubygem-activeldap-1.2.2-3.fc17.noarch requires ruby(abi) = 0:1.8 [rubygem-calendar_date_select]
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
On 11/01/2012 06:06 PM, Damian Ivanov wrote: And whoever want to install unity or these packages, can just use GNOME:Ayatana from the open build service :) Unfortunately that replaces many important components with forked versions. If it was a pure add-on repository, that would be ok. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/01/2012 12:22 PM, Michael Scherer wrote: Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. It would be good if any of the Anaconda developers could comment what external components can affect Anaconda and to what extend atleast if I'm not mistaken these external components can affect Anaconda Kernel Dracut Systemd NetworkManager Changes in comps/packaging group ( rpm/yum? ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20121101 changes
Compose started at Thu Nov 1 08:15:06 UTC 2012 Broken deps for x86_64 -- [LabPlot] LabPlot-1.6.0.2-12.fc18.i686 requires libaudiofile.so.0 LabPlot-1.6.0.2-12.fc18.x86_64 requires libaudiofile.so.0()(64bit) [PyKDE] PyKDE-3.16.6-10.fc18.x86_64 requires sip-api(8) = 0:8.1 [PyQt] PyQt-3.18.1-12.fc18.x86_64 requires sip-api(8) = 0:8.1 [autotest-framework] autotest-framework-server-0.14.3-1.fc17.noarch requires mod_python [cduce] cduce-0.5.5-2.fc18.x86_64 requires ocaml(runtime) = 0:4.00.0 cduce-0.5.5-2.fc18.x86_64 requires ocaml(Pcre) = 0:fedf84da3d313aea51e03bb7d7c99a3b [coccinelle] coccinelle-1.0.0-0.rc14.5.fc18.x86_64 requires ocaml(runtime) = 0:4.00.0 coccinelle-1.0.0-0.rc14.5.fc18.x86_64 requires ocaml(Pcre) = 0:fedf84da3d313aea51e03bb7d7c99a3b [cp2k] cp2k-openmpi-2.3-1.fc19.x86_64 requires libmpi_f90.so.1()(64bit) [dnf] dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey = 0:0.3.0 [dogtag-pki] dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-selinux = 0:10.0.0 [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [dvipdfm] dvipdfm-0.13.2d-44.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvipng] dvipng-1.14-4.fc18.x86_64 requires libkpathsea.so.4()(64bit) [e16] e16-1.0.10-3.fc18.x86_64 requires libaudiofile.so.0()(64bit) [esound] 1:esound-libs-0.2.41-6.fc18.i686 requires libaudiofile.so.0 1:esound-libs-0.2.41-6.fc18.x86_64 requires libaudiofile.so.0()(64bit) 1:esound-tools-0.2.41-6.fc18.x86_64 requires libaudiofile.so.0()(64bit) [gcstar] gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Table) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::HBox) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Frame) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::EventBox) [ghc-MemoTrie] ghc-MemoTrie-0.5-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-blaze-builder-conduit] ghc-blaze-builder-conduit-0.4.0.2-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-conduit] ghc-conduit-0.4.2-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-ghc-mtl] ghc-ghc-mtl-1.0.1.1-2.fc19.x86_64 requires ghc(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) ghc-ghc-mtl-devel-1.0.1.1-2.fc19.x86_64 requires ghc-devel(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) [ghc-hakyll] ghc-hakyll-3.2.7.2-6.fc18.x86_64 requires libHSpandoc-1.9.4.2-ghc7.4.1.so()(64bit) ghc-hakyll-3.2.7.2-6.fc18.x86_64 requires ghc(pandoc-1.9.4.2-a2700c5fb49c2879e0846ae80f139244) ghc-hakyll-devel-3.2.7.2-6.fc18.x86_64 requires ghc-devel(pandoc-1.9.4.2-a2700c5fb49c2879e0846ae80f139244) [ghc-ltk] ghc-ltk-0.12.1.0-6.fc19.x86_64 requires ghc(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) ghc-ltk-devel-0.12.1.0-6.fc19.x86_64 requires ghc-devel(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) [ghc-network-conduit] ghc-network-conduit-0.4.0.1-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-snap-core] ghc-snap-core-0.9.0-4.fc18.x86_64 requires libHSunix-compat-0.3.0.1-ghc7.4.1.so()(64bit) ghc-snap-core-0.9.0-4.fc18.x86_64 requires libHSmwc-random-0.12.0.0-ghc7.4.1.so()(64bit) ghc-snap-core-0.9.0-4.fc18.x86_64 requires ghc(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b) ghc-snap-core-0.9.0-4.fc18.x86_64 requires ghc(mwc-random-0.12.0.0-9ca879896db2ffb2250b04f25bb8cb97) ghc-snap-core-devel-0.9.0-4.fc18.x86_64 requires ghc-devel(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b) ghc-snap-core-devel-0.9.0-4.fc18.x86_64 requires ghc-devel(mwc-random-0.12.0.0-9ca879896db2ffb2250b04f25bb8cb97) [ghc-vector-space] ghc-vector-space-0.8.2-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-void] ghc-void-0.5.6-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-void-0.5.6-1.fc18.x86_64 requires ghc(semigroups-0.8.3.2-608a60352745868d7816fbfb76870ddf) ghc-void-devel-0.5.6-1.fc18.x86_64 requires ghc-devel(semigroups-0.8.3.2-608a60352745868d7816fbfb76870ddf) [ghc-wai] ghc-wai-1.2.0.3-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-warp] ghc-warp-1.2.2-1.fc18.x86_64 requires libHSunix-compat-0.3.0.1-ghc7.4.1.so()(64bit) ghc-warp-1.2.2-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-warp-1.2.2-1.fc18.x86_64 requires ghc(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b) ghc-warp-devel-1.2.2-1.fc18.x86_64 requires ghc-devel(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b) [ghc-zlib-conduit]
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
On 10/31/2012 08:24 PM, Adam Williamson wrote: Only one package depends on any of these: gwibber depends on dee. So someone interested in gwibber might want to pick up dee. I'll take dee, although, gwibber will never progress past 3.6, because the upstream (Canonical) plan is to convert gwibber into a friends client (https://launchpad.net/friends), and I don't think that will likely end up in Fedora. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
On Thu, Nov 1, 2012 at 1:18 PM, Tom Callaway tcall...@redhat.com wrote: On 10/31/2012 08:24 PM, Adam Williamson wrote: Only one package depends on any of these: gwibber depends on dee. So someone interested in gwibber might want to pick up dee. I'll take dee, although, gwibber will never progress past 3.6, because the upstream (Canonical) plan is to convert gwibber into a friends client (https://launchpad.net/friends), and I don't think that will likely end up in Fedora. Someone writing a frontend to libsocialweb would likely provide equivalent functionality to gwibber and libsocialweb already is integrated into things like gnome-online-accounts so it could be relatively straight forward. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
- Original Message - I currently own a few packages related to my old abortive attempt to build Unity for Fedora. I don't have time to maintain these or any direct interest in them - they were just Unity building blocks to me. I'm orphaning these packages: bamf compiz-plugins-main (for f16 only) dee libindicator For bamf and dee there are also -qt wrappers - so if anyone wants them... These are leftovers after my Unity 2D attempts... dee-qt actually never was built... Jaroslav Only one package depends on any of these: gwibber depends on dee. So someone interested in gwibber might want to pick up dee. It's not a difficult package to maintain, but I don't have any real interest in it. Other than that, I don't see that there's any reason anyone would want to pick these up, but maybe someone does. compiz itself was retired some time back - I should have orphaned compiz-plugins-main at the same time, but never did. I don't recall how I wound up owning it. It only appears to be 'alive' for F16 anyhow. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
Le jeudi 01 novembre 2012 à 08:32 -0400, Mo Morsi a écrit : On 10/31/2012 01:07 PM, Seth Vidal wrote: You can orchestrate all of these steps across/between multiple systems using ansible: http://ansible.cc - I've been documenting spinning up and provisioning instances on my blog in the last week or so. You might take a look - it should solve the problem of the above needing to be so manual of a process and it requires nothing other than ssh be installed on the machine you're trying to configure/control. Cool thanks for the info Seth. Ansible looks interesting, its a configuration orchestration component akin to Puppet / Chef is it not? Does it do any provisioning in itself? It can be used for remote and parallel job executation ( like run uptime on all servers ). But it can also be used with playbook, to describe the state of a server and make sure it is compliant. For example, make sure service is started, restart if config was changed ( using a notification system ). See http://ansible.cc/docs/playbooks.html -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Wed, Oct 31, 2012 at 07:17:30PM -0700, Adam Williamson wrote: On Thu, 2012-11-01 at 03:09 +0100, Kevin Kofler wrote: Adam Williamson wrote: I'd recommend asking dcantrell, as he has some good points on this topic. I broadly agree with him that it might well be more or less impossible to smoothly handle a major rewrite of anaconda in our current development process. CCing to make sure he sees this. There's only one sane conclusion to draw from that: There MUST NOT be a major rewrite of Anaconda, EVER. That it was allowed to happen for F18 was a major mistake. Anaconda is the least tested component in Fedora (most people test it at most once every 6 months) Offsetting this is the fact that the QA team tests it massively, massively more than we test any other component. anaconda is certainly far more heavily tested than any niche package in the distro - the scientific tools, obscure desktops, apps not many people use etc. It's clearly absurd to say it's the least tested component. and arguably the most critical (because it is required to get Fedora up and running at all). The less it changes, the better! This is the path to stagnation: it's old code, but we're too scared to change it. The older it gets, the more scared we get. And then you wake up and it's 2012 and your business still runs on a System/38 mainframe. That's not what Fedora is supposed to be about. Just so we're all on the same page, the System/38 was not a mainframe in the sense that the s390 and s390x architectures are mainframes. It was a descendant of the System/360 and the ancestor to the AS/400. And if your business *is* running on an s390x mainframe in 2012 and you haven't tried Fedora on it, check out the secondary arch project: http://fedoraproject.org/wiki/Architectures/s390x -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
On Thu, 1 Nov 2012, Mo Morsi wrote: Cool thanks for the info Seth. Ansible looks interesting, its a configuration orchestration component akin to Puppet / Chef is it not? Does it do any provisioning in itself? Ansible is more like this: Combining puppet and chef in one item. Then making it so you can run the entire tool w/o having to first setup the config mgmt system on the node and not requiring any sort of central server. So - ansible is those things and it doesn't make install a giant ruby blob on a system. The ec2_create utility on your blog seems to call out to euca2ools to do the actual provisioning on ec2 correct? You'd still want a component such as Deltacloud to abstractify commands to different cloud providers would you not? I doubt it. It's easier to simply use the euca2ools w/the ec2 api against openstack/cloudstack/euca/etc. Or if need be write an ostack_create to use nova. I'm not interested in supporting the whole world of clouds with this - we only have euca and openstack setup - nothing else. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
On 11/01/2012 09:22 AM, Peter Robinson wrote: On Thu, Nov 1, 2012 at 1:18 PM, Tom Callaway tcall...@redhat.com mailto:tcall...@redhat.com wrote: On 10/31/2012 08:24 PM, Adam Williamson wrote: Only one package depends on any of these: gwibber depends on dee. So someone interested in gwibber might want to pick up dee. I'll take dee, although, gwibber will never progress past 3.6, because the upstream (Canonical) plan is to convert gwibber into a friends client (https://launchpad.net/friends), and I don't think that will likely end up in Fedora. Someone writing a frontend to libsocialweb would likely provide equivalent functionality to gwibber and libsocialweb already is integrated into things like gnome-online-accounts so it could be relatively straight forward. I talked to gwibber upstream and they do not plan to ever support GOA. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maybe highlight release-slipping features? (was: Re: Anaconda is totally trashing the F18 schedule)
On Wed, Oct 31, 2012 at 07:38:27AM -0400, Scott Schmit wrote: Given the current state of F18 I agree let's lengthen this release cycle up to 9 months and arguably we should lengthen the whole ^ development cycle to 9 months from now on. ^ I'm not sure that helps -- then people just get more ambitious with their features and then what? Slow the release cycle down more? Remember, the whole point of regular, strict-timed releases is to keep things moving. +1 to this. With a 6 month cycle, if something isn't ready, slipping isn't usually earth-shattering. What I think we need is: - more cross-cycle planning. - a more functional rawhide which people can actually develop against. Maybe we need to highlight those features that don't have a realistic contingency plan (the work to revert and re-test is greater than the work to complete) and call them out as Critical Features that we are committing to slipping a release for if they don't work well, rather than to revert them. +1 to this too. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Unity bits: bamf, compiz-plugins-main, dee, libindicator
On Thu, Nov 1, 2012 at 1:37 PM, Tom Callaway tcall...@redhat.com wrote: On 11/01/2012 09:22 AM, Peter Robinson wrote: On Thu, Nov 1, 2012 at 1:18 PM, Tom Callaway tcall...@redhat.com mailto:tcall...@redhat.com wrote: On 10/31/2012 08:24 PM, Adam Williamson wrote: Only one package depends on any of these: gwibber depends on dee. So someone interested in gwibber might want to pick up dee. I'll take dee, although, gwibber will never progress past 3.6, because the upstream (Canonical) plan is to convert gwibber into a friends client (https://launchpad.net/friends), and I don't think that will likely end up in Fedora. Someone writing a frontend to libsocialweb would likely provide equivalent functionality to gwibber and libsocialweb already is integrated into things like gnome-online-accounts so it could be relatively straight forward. I talked to gwibber upstream and they do not plan to ever support GOA. I wasn't referring to gwibber at all, I was referring to writing a GUI for libraries we already have to replace the functionality that gwibber provides. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Re: Deploying fedora infrastructure (koji) across clouds
On Thu, 1 Nov 2012, Mo Morsi wrote: Hrm I was refering more to the repos necessary to bootstrap the cloud instance for the koji builder. I see - I thought you were referring to package repos. Which component imposes this limitation on koji, the hub or the builder? the hub. Would being able to build custom cloud images on the fly for different clouds assist with this? No - where it is built has nothing to do with it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote: There are features and features... some of them are new versions of leafnode packages or a just bunch of new packages which nothing else depends on, and some of them affect *everything* in the distro. Perhaps the invasive changes should have a considerably earlier deadline, and if the deadline is not met then the feature would be automatically postponed to next release. Right now, the Feature template has this sections: == Scope == !-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-- Maybe the explanation could be strengthened, and some checkbox options added: Choose one of: ☐ This is a leaf feature adding new, stand-alone functionality. ☐ This feature brings new functionality which changes the default user experience for many users. ☐ This feature introduces changes which affect the user experience only in its own area. Also, pick all that are relevant: ☐ This feature introduces broad change across the distribution requiring package changes from many contributors. ☐ If this feature is not 100% complete, there will be no regressions if packages built for it are shipped anyway. ☐ Once work on this feature passes a certain tipping point, it will be harder to revert than to go on. And so on. (I can think of a few more offhand: This feature will require a mass rebuild, This feature is likely to break Rawhide at some point in its development, This feature is a First, where Fedora is leading the way) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Hi all, It's important to recognise the negative effects of delays to the release. Upstream projects are reliant on the Fedora release process to get updates out to their users. GNOME released version 3.6 on 26 September. It was a big release and contained major improvements to our user experience. We did a marketing push to promote it. We want our users to be using that upgrade as soon as possible: 3.4 simply isn't as good. It is also in Fedora's interests to ensure that the user experience is as good as possible, of course. A one month delay is a whole month in which Fedora users could have been experiencing something better. Finally, there are many people who are impatient to be using the latest GNOME release (and other upstream releases, I guess). Right now you can get it on Ubuntu or on Arch - people might just choose to use a different distro if they want the latest and greatest, or if they are frustrated by the constant delays. Allan Day -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, 2012-11-01 at 13:01 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 12:22 PM, Michael Scherer wrote: Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. It would be good if any of the Anaconda developers could comment what external components can affect Anaconda and to what extend atleast if I'm not mistaken these external components can affect Anaconda Kernel Dracut Systemd NetworkManager Changes in comps/packaging group ( rpm/yum? ) lvm mdadm btrfs-progs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/31/2012 05:59 PM, Jesse Keating wrote: On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I think we need to give developers more time for feature integration after the feature freeze. We ( QA community ) would benefit from a longer release cycle since we need more time to properly test features and other vital components and arguably the QA part of an feature should FESCO delegate to QA community to oversee and handle... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, Nov 01, 2012 at 02:25:39PM +, Allan Day wrote: It's important to recognise the negative effects of delays to the release. Upstream projects are reliant on the Fedora release process to get updates out to their users. GNOME released version 3.6 on 26 September. It was a big release and contained major improvements to our user experience. We did a marketing push to promote it. We want our users to be using that upgrade as soon as possible: 3.4 simply isn't as good. If we had something we could ship, we'd ship it. We don't. That's unfortunate, but talking about how undesirable release slips are does nothing to help improve that situation. We know they're undesirable, but so far nobody has proposed a workable solution that actually makes them less likely to happen in future without massively compromising other parts of the project. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Am 01.11.2012 15:41, schrieb Jóhann B. Guðmundsson: We ( QA community ) would benefit from a longer release cycle since we need more time to properly test features and other vital components and arguably the QA part of an feature should FESCO delegate to QA community to oversee and handle... Maybe we should think again about switching to a roling release models for Fedora stable. This would IMHO have some benefits to the whole community. It would allow dev to take the time they need to develop new features like the anaconda rewrite and push them to stable when it's done without getting into trouble with the release schedule. On the other hand Fedora releases would become just a regular snapshot of Fedoras stable repository. So QA could focus on testing new features *before* they are pushed to the stable repository. And last but not least Fedora could stay in sync with major upstream projects. -- Regards Heiko Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
MPI updates
Some MPI updates: - I built openmpi 1.6.3 in rawhide yesterday. This had an unexpected bump in the libmpi_f90.so soname. I know this affects hdf5 and netcdf-fortran, both my packages and I'll be rebuilding them later today (hopefully). - MPI packaging guidelines have changed (https://fedoraproject.org/wiki/Packaging:MPI), namely that the module location has changed to be under a mpi subdirectory. - I'm planning on building mpich2 1.5 shortly in rawhide with the above module changes. Updating to 1.5 also for hwloc 1.5 support. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, Nov 1, 2012 at 10:56 AM, Heiko Adams heiko.ad...@gmail.com wrote: Maybe we should think again about switching to a roling release models for Fedora stable. This would IMHO have some benefits to the whole community. I'm afraid a rolling release model would make it *harder* to make major changes to Fedora, not easier. We've had discussion after discussion about the rolling release model over the past several years, but I don't think the majority of the people who build Fedora and make it work want to move to that model model. If they did, we'd have gone down that row by now. (And, while it's not close to perfect, rawhide is roughly analogous to a rolling release anyway -- enough so that many people are actively using it, even if it causes a little pain from time to time.) In short, bringing the topic of rolling releases up again at this time doesn't help us fix the situation at hand -- it simply distracts us with vague alternatives rather than providing any concrete ideas for making our current feature process better. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, Nov 1, 2012 at 10:25 AM, Allan Day allanp...@gmail.com wrote: It's important to recognise the negative effects of delays to the release. OLPC is downstream of F18, and planning to ship an OLPC OS version 13.1.0 first week of December 2012 (approx); which will be based on F18. We are not affected by Anaconda issues, as our OS is a pre-installed image, but continued churn does hit us hard. We control this somewhat by freezing our view of Fedora's repos. Most of our packages are in Fedora (with exceptions like kernel and BIOS) -- where we maintain/comaintain quite a few components (Sugar Desktop, etc). OLPC development team is watching closely any schedule changes affecting Fedora. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-podlators] Do not export under-specified dependencies
commit c680f3ad42b87972392ae01751448a370400a137
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 1 16:57:03 2012 +0100
Do not export under-specified dependencies
perl-podlators.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-podlators.spec b/perl-podlators.spec
index fbabf81..4076b3c 100644
--- a/perl-podlators.spec
+++ b/perl-podlators.spec
@@ -1,6 +1,6 @@
Name: perl-podlators
Version:2.4.2
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Format POD source into various output formats
License:GPL+ or Artistic
Group: Development/Libraries
@@ -26,6 +26,9 @@ Requires: perl(Pod::Text::Overstrike)
Requires: perl(Pod::Text::Termcap)
Conflicts: perl 4:5.16.1-234
+# Filter under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Pod::Simple\\)$
+
%description
This package contains Pod::Man and Pod::Text modules which convert POD input
to *roff source output, suitable for man pages, or plain text. It also
@@ -40,7 +43,7 @@ with various capabilities.
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
%{_fixperms} $RPM_BUILD_ROOT/*
@@ -55,6 +58,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 01 2012 Petr Pisar ppi...@redhat.com - 2.4.2-3
+- Do not export under-specified dependencies
+
* Wed Oct 31 2012 Petr Pisar ppi...@redhat.com - 2.4.2-2
- Conflict perl-podlators with perl before sub-packaging
--
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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/01/2012 07:32 AM, David Lehman wrote: On Thu, 2012-11-01 at 13:01 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 12:22 PM, Michael Scherer wrote: Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. It would be good if any of the Anaconda developers could comment what external components can affect Anaconda and to what extend atleast if I'm not mistaken these external components can affect Anaconda Kernel Dracut Systemd NetworkManager Changes in comps/packaging group ( rpm/yum? ) lvm mdadm btrfs-progs e2fsprogs xfsprogs xvnc .. Basically anything in lorax's runtime-install.tmpl and all the deps therein can destabilize anaconda. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, 2012-11-01 at 09:56 -0400, Matthew Miller wrote: On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote: There are features and features... some of them are new versions of leafnode packages or a just bunch of new packages which nothing else depends on, and some of them affect *everything* in the distro. Perhaps the invasive changes should have a considerably earlier deadline, and if the deadline is not met then the feature would be automatically postponed to next release. Right now, the Feature template has this sections: == Scope == !-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-- Maybe the explanation could be strengthened, and some checkbox options added: Choose one of: ☐ This is a leaf feature adding new, stand-alone functionality. ☐ This feature brings new functionality which changes the default user experience for many users. ☐ This feature introduces changes which affect the user experience only in its own area. To make things clearer I think you could drop 'brings new functionality which' from the second checkbox. The key thing we're trying to isolate is whether the feature has implications for 'normal' usage; it doesn't matter whether it's introducing new functionality. I was rather thinking we can simply take advantage of the critical path definition here. After all, when we came up with the critpath, the idea was it was a general concept which could be useful beyond the idea of a 'critpath package'. So why don't we just introduce the concept of a 'critpath feature' - any feature with implications for the critical path? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, 2012-11-01 at 09:32 -0500, David Lehman wrote: On Thu, 2012-11-01 at 13:01 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 12:22 PM, Michael Scherer wrote: Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. It would be good if any of the Anaconda developers could comment what external components can affect Anaconda and to what extend atleast if I'm not mistaken these external components can affect Anaconda Kernel Dracut Systemd NetworkManager Changes in comps/packaging group ( rpm/yum? ) lvm mdadm btrfs-progs parted, grub2, everything in anaconda-tools group in comps... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, 2012-11-01 at 15:56 +0100, Heiko Adams wrote: Am 01.11.2012 15:41, schrieb Jóhann B. Guðmundsson: We ( QA community ) would benefit from a longer release cycle since we need more time to properly test features and other vital components and arguably the QA part of an feature should FESCO delegate to QA community to oversee and handle... Maybe we should think again about switching to a roling release models for Fedora stable. This would IMHO have some benefits to the whole community. I didn't want to throw this grenade into the debate, but now someone else has, I'll just note that I was in favour of this before and I'm still in favour of it now. :) Rolling release is a model that makes clear sense for a distribution with the goals that Fedora has. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, Nov 1, 2012 at 5:12 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-11-01 at 09:32 -0500, David Lehman wrote: On Thu, 2012-11-01 at 13:01 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 12:22 PM, Michael Scherer wrote: Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. It would be good if any of the Anaconda developers could comment what external components can affect Anaconda and to what extend atleast if I'm not mistaken these external components can affect Anaconda Kernel Dracut Systemd NetworkManager Changes in comps/packaging group ( rpm/yum? ) lvm mdadm btrfs-progs parted, grub2, everything in anaconda-tools group in comps... EFI, and enterprise storage (FCP, iSCSI, FCoE etc). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/01/2012 07:08 PM, Adam Williamson wrote: On Thu, 2012-11-01 at 09:56 -0400, Matthew Miller wrote: On Thu, Nov 01, 2012 at 09:24:52AM +0200, Panu Matilainen wrote: There are features and features... some of them are new versions of leafnode packages or a just bunch of new packages which nothing else depends on, and some of them affect *everything* in the distro. Perhaps the invasive changes should have a considerably earlier deadline, and if the deadline is not met then the feature would be automatically postponed to next release. Right now, the Feature template has this sections: == Scope == !-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-- Maybe the explanation could be strengthened, and some checkbox options added: Choose one of: ☐ This is a leaf feature adding new, stand-alone functionality. ☐ This feature brings new functionality which changes the default user experience for many users. ☐ This feature introduces changes which affect the user experience only in its own area. To make things clearer I think you could drop 'brings new functionality which' from the second checkbox. The key thing we're trying to isolate is whether the feature has implications for 'normal' usage; it doesn't matter whether it's introducing new functionality. I was rather thinking we can simply take advantage of the critical path definition here. After all, when we came up with the critpath, the idea was it was a general concept which could be useful beyond the idea of a 'critpath package'. So why don't we just introduce the concept of a 'critpath feature' - any feature with implications for the critical path? Nod. The critical path package set would serve at least as a point for refining the feature process. What the actual implications of critpath feature would be, Debian-style earlier freeze and/or something else, is probably a whole another (no doubt lengthy) topic :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 : broken configuration for httpd 2.4
It would have been super nice to actually include a link in all of those bugs, or some reference. I mean, they must have been filed by program, so it's not as if you would have had to do a bunch of extra typing. We really need a mass bug filing howto or something. Preferably starting with Don't. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Adam Williamson wrote: I didn't want to throw this grenade into the debate, but now someone else has, I'll just note that I was in favour of this before and I'm still in favour of it now. :) Rolling release is a model that makes clear sense for a distribution with the goals that Fedora has. I've wanted to write up a blog post about my plan for a rolling release, but I'll post a snip-it here. Fedora Rawhide - stays as is... it is a rolling release Fedora Feature - think of it as F18 beta right now Fedora Stable - think of it as F16/F17 right now People choose the branch level at install time. Of course, like now, people can override this in the future with a change of fedora-release or yum --releasever. However, per-package updates from another branch level might not be something everyone can agree on how to handle, so it might be wise to limit support of it at first. Workflow: A shiny new feature is introduced in Rawhide. Things go boom. Not many people are hurt by this. Once it has been given a few band-aids the feature could be submitted to Fedora Feature. After some hardening and polishing the feature could finally be pushed to Fedora Stable. I feel this should give a good compromise to everyone's fears of a rolling release. It gives the feature freaks a place in Fedora. It gives the stable stubborns a place in Fedora. I'll wake up from my dream now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Björn Persson (bjorn@rombobjörn.se) said: Emmanuel Seyman wrote: From bug #871503 (and I apologize if I'm reading this wrong), it appears that the dependency on /bin/perl is being caused by the hardcoded $PATH in openssh. To fix the problem, I think we would not only need to provide /bin/perl but a /bin equivalent to everything in /usr/bin (/bin/perl is the only usecase which Harald has hit so far). That still wouldn't solve all cases. I've seen code that does the equivalent of which some-program, finds /bin/some-program, concludes that the installation prefix is /, and proceeds to look for files in /share, which doesn't exist and never has. We really need to get /bin and /sbin removed from PATH, or at least moved behind /usr/bin and /usr/sbin. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
- Original Message - On Thu, Nov 01, 2012 at 10:08:39AM -0700, Adam Williamson wrote: I was rather thinking we can simply take advantage of the critical path definition here. After all, when we came up with the critpath, the idea was it was a general concept which could be useful beyond the idea of a 'critpath package'. So why don't we just introduce the concept of a 'critpath feature' - any feature with implications for the critical path? That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta ;-) But you know, moving target Any suggestions are welcomed! Jaroslav I think this is nice for presenting the list of features overall, actually, both on the web site and in the eventual release notes. I also still like the idea of some other basic checkbox options which encourage people to clarify the wider implications of the feature. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/01/2012 06:09 PM, Jaroslav Reznik wrote: We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta;-) But you know, moving target Any suggestions are welcomed! Blindly accepting features are unacceptable from QA stand point and arguably minor release updates should be kept out of the feature process JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
- Original Message - On 11/01/2012 06:09 PM, Jaroslav Reznik wrote: We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my proposal delivered to FESCo before Beta;-) But you know, moving target Any suggestions are welcomed! Blindly accepting features are unacceptable from QA stand point and arguably minor release updates should be kept out of the feature process Definitely not blinding accepting - the feature would have to go through the Feature Wrangler as for now and then it should be announced in public way. So the Feature is not blindly accepted as many Features on FESCo meeting to get rid of a queue of unapproved ones and even it gets better visibility - so developers can interact with Feature owner and in case of any issues - raise it to FESCo. And FESCo will have time to actually work on it, not just +1-ing it. Jaroslav JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). Other thing is - these Self contained features could be approved implicitly once are announced on devel list (in cooperation with Feature Wrangler). Features that requires integration etc. will be still approved by FESCo, but idea is to offload amount of work from FESCo so they can give more time to track these features. Not to bother with leaf features or enhancements. And as these should be very visible (thanks to announcement) anybody could escalate any feature to the FESCo for discussion/explicit approval. That's the idea, I promised my prposal delivered to FESCo before Beta ;-) But you know, moving target Any suggestions are welcomed! Jaroslav I think this is nice for presenting the list of features overall, actually, both on the web site and in the eventual release notes. I also still like the idea of some other basic checkbox options which encourage people to clarify the wider implications of the feature. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
- Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Does a lot of other packages depend on it? - Likely affects a lot of users. Is it installed by default or a commonly used application / package ? - Likely affects a lot of users. Is it a new package that isn't intended to be installed by default? - Probably does not affects a lot of users. ... etc. So while there is no 100% accurate definition applying some common sense helps here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 1, 2012 at 2:45 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Version upgrades of _most_ packages are not features. When someone is updating or installing a new Fedora they _expect_ to be getting newer versions of packages already. It doesn't make much sense to update your local Fedora install if you aren't actually going to get new things. Coordination among the other packages in the distro should already be handled with ABI/soname change notifications in rawhide. In the rare case a package change some file format that users need to manually handle or otherwise be aware of, release notes can cover that under a special update section. It doesn't make that version update a feature. For things like Gnome 3.6, or KDE 4.whatever, or MATE, then sure a Feature might be warranted there. Those are clearly large undertakings that need to be carefully coordinated. Updating postgresql or gwibber or cowsay or less are not. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 ARM Alpha Release
The Fedora ARM team is pleased to announce that the Fedora 18 Alpha release for ARM is now available for download from: http://dl.fedoraproject.org/pub/fedora-secondary/releases/test/18-Alpha/Images/armhfp/ The Alpha release includes prebuilt images for the Trimslice, Pandaboard and Highbank hardware platforms as well a Versatile Express image for use with QEMU. Please visit the announcement page for additional information and links to specific images: http://fedoraproject.org/wiki/Architectures/ARM/Fedora_18_Alpha We invite you to download the Fedora 18 Alpha release and provide your valuable input to the Fedora ARM team. Please join us on the IRC in #fedora-arm on Freenode or send feedback and comments to the ARM mailing list. On behalf of the Fedora ARM team, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 07:41:21PM +0100, drago01 wrote: I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. Sorry, I wasn't clear. It may be that some set of new functionality requires small version upgrades. The feature is the new functionality, not the version upgrades. An example: I want to propose Scratch, the educational programming language, as a feature for F19. It's not big, but it's popular and there's a new book, generating public interest so it'd be nice for it to be included in the process. Scratch itself is a new package. But it requires an update to Squeak VM in order to work properly. This is incidental to the feature itself -- so it'd be weird to classify this as an update to existing functionality -- but the feature isn't self contained. That said, a significant version upgrade to something _should_ be able to be a feature in itself. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, 2012-11-01 at 19:50 +0100, drago01 wrote: On Thu, Nov 1, 2012 at 7:45 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Thu, Nov 1, 2012 at 7:34 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Nov 01, 2012 at 02:09:21PM -0400, Jaroslav Reznik wrote: That sounds good. Maybe recast those ideas as three levels? - Critical Path Feature - Other Enhancement Feature - New Leaf Feature We were thinking with a few folks more about Self contained feature but yeah, there's a lack of real definition. I think Leaf is better than Self contained, since it's unlikely for the feature to have zero outside dependencies. I think it'd be fine for such a feature to rely on small changes to existing packages (version updates, say). I'd argue that this isn't a feature ... otherwise we could advertise every version upgrade as feature. If it does not affect a large amount of users it is simply a version upgrade not a fedora feature. The question is - how do you know if it affects large amount of users, it's not an important one, without letting people know, there's such feature? Does a lot of other packages depend on it? - Likely affects a lot of users. Is it installed by default or a commonly used application / package ? - Likely affects a lot of users. Is it a new package that isn't intended to be installed by default? - Probably does not affects a lot of users. ... etc. So while there is no 100% accurate definition applying some common sense helps here. Well. It's worth considering the underlying problem here, which we've known about for a while: the feature process is overloaded. We use it for multiple purposes. In this thread we're mostly concerned with the aspects of the feature process that deal with genuine technical / QA issues: are we doing well enough at evaluating and overseeing features from a technical perspective. However, the feature process achieves other things too. The other obvious big one is publicity/documentation: that's the reason all these leaf features are made features at all, so they can be written up in our announcements and documentation. I think the direction we're driving here will actually address that problem too; if we split features into 'critpath' and 'leaf' (and maybe some other category/ies) we will be able to make the process more sane. For 'leaf' features we can concentrate on the PR/documentation stuff and we really don't have to worry too much about the technical / release schedule side of things for those features. So if we go down the road of categorizing features and do a good job of it, I think that rather makes the issue of 'why are these little things features at all?' go away. They'd be features simply for the PR, and we could codify that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. 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: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 08:13:57PM +, Richard W.M. Jones wrote: The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. That's where the critpath vs. other enhancement distinction comes in -- for critpath we can be more strict about requiring the process without making it more onerous for other changes. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 11/01/2012 08:13 PM, Richard W.M. Jones wrote: The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. As far as I know you are not obligated to participate in the feature process and what do you exactly define as slip in via the back door ? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-MIME-Types/f18] Update to 1.36
Summary of changes: 3863b4d... Update to 1.36 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, 2012-11-01 at 21:28 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 08:13 PM, Richard W.M. Jones wrote: The other thing that we mustn't forget are major changes that aren't put through the feature process, but slip in via the back door. As far as I know you are not obligated to participate in the feature process and what do you exactly define as slip in via the back door ? 'not participate in the feature process', I think =) I think I once proposed that FESCo should formally have the ability to declare that a given change ought to be a feature and force it through the feature process, but that proposal was rejected. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MPI updates
On Thu, 01 Nov 2012 09:08:36 -0600 Orion Poplawski or...@cora.nwra.com wrote: Some MPI updates: - I built openmpi 1.6.3 in rawhide yesterday. This had an unexpected bump in the libmpi_f90.so soname. I know this affects hdf5 and netcdf-fortran, both my packages and I'll be rebuilding them later today (hopefully). Given that f18 has 1.6, I believe the same update should be made on f18 as well. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On Thu, Nov 01, 2012 at 02:43:00PM -0700, Adam Williamson wrote: I think I once proposed that FESCo should formally have the ability to declare that a given change ought to be a feature and force it through the feature process, but that proposal was rejected. I think that requiring the feature process for major critical path changes is at least the platonic ideal, even if we're not at a point where we can do it yet. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
f18tc6 + texlive 2012: usable docbook, doxygen pdf toolchains
Using F18 TC6 in a KVM install, I was able to install texlive-2012 as per the updates-testing packages, and look at the state of generating documenation with DocBook toolchains using dblatex and Doxygen toolchains using pdflatex. This is related to RH488651, the tracker bug to update TeX in Fedora to one more closely matching upstream TeX development. Although updating TeX is not an Accepted Feature in F18, texlive-2012 packages are in updates-testing. Using these packages, with some changes, I was able to get a usable doxygen configuration for PDF, and came much closer for docbook 5. The full $SUBJECT is optimistic, alas. I'm really hoping that we can merge in the new TeX bits and fix them up in place with a sprint where all concerned work on it. I'm not quite sure what the criteria would be for the conversion from Tex 2007 to TeX 2012, but let me suggest workable docbook/doxygen/texinfo toolchains as existenzminimum. To that end: Issues: 1) docbook5-style-xsl Issue with docbook.xsl typo/porting error. See GNOME BZ 687299 https://bugzilla.gnome.org/show_bug.cgi?id=687299 Fixed via hack: ln -s VERSION VERSION.xsl 2) doxygen-pdf needs PreReq: texlive-sectsty PreReq: texlive-tocloft PreReq: texlive-xtab PreReq: texlive-multirow 3) docbook5-style-xsl needs PreReq: texlive-subfigure PreReq: texlive-appendix PreReq: texlive-changebar PreReq: texlive-bibtopic PreReq: texlive-overpic 4) any math formulas seem to need more than texlive-amsfonts I just used the big guns: yum install -y texlive-collection-fontsextra texlive-collection-fontrecommended These group packages for TeX fonts are great and I'm glad that Fedora has them. 5) dblatex seems to be not working. Not quite sure what is going on, Error is: incomplete /ifmmode. I took the generated F18 .xml input and ran it thourgh dblatex on a working F17 install, no problems. My plan is to try and report these problems in Fedora BZ, even though these packages are still in updates testing? Call me crazy? Is there a better place to report these bugs? best, -benjamin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18tc6 + texlive 2012: usable docbook, doxygen pdf toolchains
On Qui, 2012-11-01 at 19:14 -0700, Benjamin De Kosnik wrote: Using F18 TC6 in a KVM install, I was able to install texlive-2012 as per the updates-testing packages, and look at the state of generating documenation with DocBook toolchains using dblatex and Doxygen toolchains using pdflatex. This is related to RH488651, the tracker bug to update TeX in Fedora to one more closely matching upstream TeX development. Although updating TeX is not an Accepted Feature in F18, texlive-2012 packages are in updates-testing. Using these packages, with some changes, I was able to get a usable doxygen configuration for PDF, and came much closer for docbook 5. The full $SUBJECT is optimistic, alas. I'm really hoping that we can merge in the new TeX bits and fix them up in place with a sprint where all concerned work on it. I'm not quite sure what the criteria would be for the conversion from Tex 2007 to TeX 2012, but let me suggest workable docbook/doxygen/texinfo toolchains as existenzminimum. To that end: Issues: 1) docbook5-style-xsl Issue with docbook.xsl typo/porting error. See GNOME BZ 687299 https://bugzilla.gnome.org/show_bug.cgi?id=687299 Fixed via hack: ln -s VERSION VERSION.xsl 2) doxygen-pdf needs PreReq: texlive-sectsty PreReq: texlive-tocloft PreReq: texlive-xtab PreReq: texlive-multirow 3) docbook5-style-xsl needs PreReq: texlive-subfigure PreReq: texlive-appendix PreReq: texlive-changebar PreReq: texlive-bibtopic PreReq: texlive-overpic 4) any math formulas seem to need more than texlive-amsfonts I just used the big guns: yum install -y texlive-collection-fontsextra texlive-collection-fontrecommended These group packages for TeX fonts are great and I'm glad that Fedora has them. 5) dblatex seems to be not working. Not quite sure what is going on, Error is: incomplete /ifmmode. I took the generated F18 .xml input and ran it thourgh dblatex on a working F17 install, no problems. My plan is to try and report these problems in Fedora BZ, even though these packages are still in updates testing? Call me crazy? Is there a better place to report these bugs? no , I also have problems in F18. I got problems build VirtualBox packages on F18 and rawhide, but not on F17, with user Manual's build.log wrote: This is pdfTeX, Version 3.1415926-2.5-1.40.13 (TeX Live 2013/dev) restricted \write18 enabled. VirtualBox.spec just have : BuildRequires: /usr/bin/pdflatex have you any suggestion that I can try it ? I can't find any relevant error and doesn't use updates-testing Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
new setting for SYSFONT attribute
Hi, I am working on bug (https://bugzilla.redhat.com/show_bug.cgi?id=871119)/etc/sysconfig/i18n is no longer used. On fedora 17, system-config-language sets attributes LANG,SYSFONT in /etc/sysconfig/i18n file. Fedora 18, i checked the locale.conf file which has only one attribute i.e LANG. I would like to know where SYSFONT attribute is set and do system-config-language needs to set that variable? Thanks in advance. Thanks, Anish P. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
On Thu, 1 Nov 2012, Michael Scherer wrote: Le jeudi 01 novembre 2012 à 08:32 -0400, Mo Morsi a écrit : On 10/31/2012 01:07 PM, Seth Vidal wrote: You can orchestrate all of these steps across/between multiple systems using ansible: http://ansible.cc - I've been documenting spinning up and provisioning instances on my blog in the last week or so. You might take a look - it should solve the problem of the above needing to be so manual of a process and it requires nothing other than ssh be installed on the machine you're trying to configure/control. Cool thanks for the info Seth. Ansible looks interesting, its a configuration orchestration component akin to Puppet / Chef is it not? Does it do any provisioning in itself? It can be used for remote and parallel job executation ( like run uptime on all servers ). But it can also be used with playbook, to describe the state of a server and make sure it is compliant. For example, make sure service is started, restart if config was changed ( using a notification system ). Most importantly to me is the ability to orchestrate between servers in a single playbook or via the api: Ex: Take data from running this on system 1 and put that data into the config on system 2, notify system 3 you've done this -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SQL-Statement] Specify all dependencies
commit 64bd1ece4d814b543d85db53d5c1493331f1d80d
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 1 10:36:44 2012 +0100
Specify all dependencies
perl-SQL-Statement.spec | 37 -
1 files changed, 20 insertions(+), 17 deletions(-)
---
diff --git a/perl-SQL-Statement.spec b/perl-SQL-Statement.spec
index 9294192..59f54fc 100644
--- a/perl-SQL-Statement.spec
+++ b/perl-SQL-Statement.spec
@@ -1,30 +1,35 @@
Name: perl-SQL-Statement
Version:1.401
-Release:1%{?dist}
+Release:2%{?dist}
Summary:SQL parsing and processing engine
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/SQL-Statement/
Source0:
http://www.cpan.org/authors/id/R/RE/REHSACK/SQL-Statement-%{version}.tar.gz
BuildArch: noarch
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(DBI) = 1.612
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
BuildRequires: perl(base)
-BuildRequires: perl(constant)
-BuildRequires: perl(lib)
BuildRequires: perl(Carp)
BuildRequires: perl(Clone) = 0.30
+BuildRequires: perl(constant)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Encode)
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(File::Spec)
+BuildRequires: perl(Exporter)
BuildRequires: perl(List::Util)
BuildRequires: perl(Math::BigFloat)
BuildRequires: perl(Math::BigInt)
+BuildRequires: perl(Math::Trig)
BuildRequires: perl(Params::Util) = 1.00
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Time::HiRes)
-# for tests only:
+# Tests:
+BuildRequires: perl(Cwd)
+BuildRequires: perl(File::Path)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More)
+# Optional test:
# DBD::CSV buildrequires SQL::Statement
%if 0%{!?perl_bootstrap:1}
BuildRequires: perl(DBD::CSV) = 0.30
@@ -32,16 +37,11 @@ BuildRequires: perl(DBD::CSV) = 0.30
BuildRequires: perl(DBD::DBM) = 0.06
BuildRequires: perl(DBD::File) = 0.40
BuildRequires: perl(DBD::SQLite)
-BuildRequires: perl(DBD::XBase)
-BuildRequires: perl(DBI::DBD::SqlEngine) = 0.03
+%if ! (0%{?rhel} = 7)
BuildRequires: perl(MLDBM)
-BuildRequires: perl(Test::Simple) = 0.90
-# For maintainer tests only:
-BuildRequires: perl(Test::Pod) = 1.00
-BuildRequires: perl(Test::Pod::Coverage) = 1.00
-# Test::Pod::Spelling::CommonMistakes not packaged yet
-# Bundle::Test::SQL::Statement not packaged or released yet
-#BuildRequires: perl(Test::Pod::Spelling::CommonMistakes)
+%endif
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(DBI) = 1.612
%description
The SQL::Statement module implements a pure Perl SQL parsing and execution
@@ -75,6 +75,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Thu Nov 01 2012 Petr Pisar ppi...@redhat.com - 1.401-2
+- Specify all dependencies
+
* Wed Oct 31 2012 Petr Šabata con...@redhat.com - 1.401-1
- 1.401 bump (upstream switches to 3-digit minor version)
- Drop command macros and modernize spec
--
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-SQL-Statement] Quallify run-requires
commit 246a7a0f70961b447af293599f4f99b16ece3362
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 1 10:47:11 2012 +0100
Quallify run-requires
perl-SQL-Statement.spec |4
1 files changed, 4 insertions(+), 0 deletions(-)
---
diff --git a/perl-SQL-Statement.spec b/perl-SQL-Statement.spec
index 943dea8..bc9daf0 100644
--- a/perl-SQL-Statement.spec
+++ b/perl-SQL-Statement.spec
@@ -41,7 +41,11 @@ BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(MLDBM)
%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Clone) = 0.30
Requires: perl(DBI) = 1.612
+Requires: perl(Params::Util) = 1.00
+
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((Clone|Params::Util\\)$
%description
The SQL::Statement module implements a pure Perl SQL parsing and execution
--
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 Digest-SHA-5.73.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Digest-SHA: 83aca045c10c8e023ec50d66d192a076 Digest-SHA-5.73.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-Digest-SHA] 5.73 bump
commit 5e41e047231710643e2e4d576dd943356bbefc9a
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 1 10:54:46 2012 +0100
5.73 bump
.gitignore |1 +
perl-Digest-SHA.spec |9 ++---
sources |2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a869b74..3677547 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Digest-SHA-5.45.tar.gz
/Digest-SHA-5.70.tar.gz
/Digest-SHA-5.71.tar.gz
/Digest-SHA-5.72.tar.gz
+/Digest-SHA-5.73.tar.gz
diff --git a/perl-Digest-SHA.spec b/perl-Digest-SHA.spec
index d32bfc7..a82812a 100644
--- a/perl-Digest-SHA.spec
+++ b/perl-Digest-SHA.spec
@@ -1,7 +1,7 @@
Name: perl-Digest-SHA
-Epoch: 1
-Version:5.72
-Release:1%{?dist}
+Epoch: 0
+Version:5.73
+Release:2%{?dist}
Summary:Perl extension for SHA-1/224/256/384/512
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 01 2012 Petr Pisar ppi...@redhat.com - 0:5.73-2
+- 5.73 bump
+
* Wed Sep 26 2012 Petr Pisar ppi...@redhat.com - 1:5.72-1
- 5.72 bump
diff --git a/sources b/sources
index a521ce5..d7c1796 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0bb1858987cbccb92ed527e36d498e96 Digest-SHA-5.72.tar.gz
+83aca045c10c8e023ec50d66d192a076 Digest-SHA-5.73.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 871874] perl-Digest-SHA-5.73 is available
https://bugzilla.redhat.com/show_bug.cgi?id=871874 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Digest-SHA-5.73-2.fc19 Resolution|--- |RAWHIDE Last Closed||2012-11-01 06:04:59 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Just fix in builds script for VMS. No need to back-port. -- 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-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the F-18 tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so 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
[Bug 872157] New: perl-Date-Manip-6.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872157 Bug ID: 872157 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Assignee: mmasl...@redhat.com Summary: perl-Date-Manip-6.36 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Date-Manip Product: Fedora Latest upstream release: 6.36 Current version in Fedora Rawhide: 6.34 URL: http://search.cpan.org/dist/Date-Manip/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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 872158] New: perl-DateTime-TimeZone-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872158 Bug ID: 872158 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org Assignee: iarn...@gmail.com Summary: perl-DateTime-TimeZone-1.52 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-DateTime-TimeZone Product: Fedora Latest upstream release: 1.52 Current version in Fedora Rawhide: 1.51 URL: http://search.cpan.org/dist/DateTime-TimeZone/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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-Module-Signature] Make building non-interactive
commit 3a4f5e9da562bfb35aec4b39ef7856b7e9827881
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 1 13:07:52 2012 +0100
Make building non-interactive
perl-Module-Signature.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Module-Signature.spec b/perl-Module-Signature.spec
index e94c2e4..6906c66 100644
--- a/perl-Module-Signature.spec
+++ b/perl-Module-Signature.spec
@@ -1,6 +1,6 @@
Name: perl-Module-Signature
Version:0.68
-Release:6%{?dist}
+Release:7%{?dist}
Summary:CPAN signature management utilities and modules
Group: Development/Libraries
License:CC0
@@ -42,7 +42,7 @@ mkdir --mode=0700 gnupghome
%build
export GNUPGHOME=$(pwd)/gnupghome
cd Module-Signature-%{version}
-perl Makefile.PL INSTALLDIRS=vendor --skipdeps
+perl Makefile.PL INSTALLDIRS=vendor --skipdeps /dev/null
make %{?_smp_mflags}
cd -
@@ -67,6 +67,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Module::Signature.3pm*
%changelog
+* Thu Nov 01 2012 Petr Pisar ppi...@redhat.com - 0.68-7
+- Make building non-interactive
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.68-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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-Module-Signature] Fix a typo
commit c43277c712cab384f4359450b1e333598fd44c24 Author: Petr Písař ppi...@redhat.com Date: Thu Nov 1 13:08:25 2012 +0100 Fix a typo perl-Module-Signature.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/perl-Module-Signature.spec b/perl-Module-Signature.spec index 6906c66..d0ed679 100644 --- a/perl-Module-Signature.spec +++ b/perl-Module-Signature.spec @@ -27,7 +27,7 @@ Requires: perl(Digest::SHA1) Requires: perl(PAR::Dist) %description -This package contains command line tools and utilities a module for +This package contains command line tools and utilities and module for checking and creating SIGNATURE files for Perl CPAN distributions. %prep -- 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-Module-Signature] Specify all dependencies
commit 4511acce3c121e83621beb9559ca5917c5266a96
Author: Petr Písař ppi...@redhat.com
Date: Thu Nov 1 13:14:19 2012 +0100
Specify all dependencies
perl-Module-Signature.spec | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
---
diff --git a/perl-Module-Signature.spec b/perl-Module-Signature.spec
index d0ed679..b861deb 100644
--- a/perl-Module-Signature.spec
+++ b/perl-Module-Signature.spec
@@ -8,21 +8,31 @@ URL:http://search.cpan.org/dist/Module-Signature/
Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Module-Signature-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Path)
+# Run-time:
BuildRequires: gnupg
BuildRequires: perl(constant)
-BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Digest::SHA)
BuildRequires: perl(Digest::SHA1)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::Manifest)
+BuildRequires: perl(IO::Socket::INET)
+# Tests:
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Getopt::Long)
BuildRequires: perl(IPC::Run)
BuildRequires: perl(lib)
+BuildRequires: perl(Pod::Usage)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: gnupg
Requires: perl(Digest::SHA)
Requires: perl(Digest::SHA1)
+Requires: perl(IO::Socket::INET)
# Would prefer this to be Suggests: really...
Requires: perl(PAR::Dist)
@@ -69,6 +79,7 @@ rm -rf %{buildroot}
%changelog
* Thu Nov 01 2012 Petr Pisar ppi...@redhat.com - 0.68-7
- Make building non-interactive
+- Specify all dependencies
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.68-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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-threads] Update dependencies. Use DESTDIR instead of PERL_INSTALL_ROOT
commit eda7326ab4c9acfc959cd4e1907f2328787ecfda
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Nov 1 13:18:20 2012 +0100
Update dependencies. Use DESTDIR instead of PERL_INSTALL_ROOT
perl-threads.spec | 12
1 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/perl-threads.spec b/perl-threads.spec
index 5ceb5e3..4416a9f 100644
--- a/perl-threads.spec
+++ b/perl-threads.spec
@@ -1,6 +1,6 @@
Name: perl-threads
Version:1.86
-Release:240%{?dist}
+Release:241%{?dist}
Summary:Perl interpreter-based threads
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,13 +9,14 @@ Source0:
http://search.cpan.org/CPAN/authors/id/J/JD/JDHEDDEN/threads-%{v
BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::testlib)
+BuildRequires: perl(File::Spec)
BuildRequires: perl(Test::More)
BuildRequires: perl(XSLoader)
# Tests only:
-BuildRequires: perl(ExtUtils::testlib)
BuildRequires: perl(IO::File)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Carp)
%{?perl_default_filter}
@@ -36,10 +37,9 @@ This threading model has been deprecated, and was removed as
of Perl 5.10.0.)
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -52,6 +52,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 01 2012 Jitka Plesnikova jples...@redhat.com - 1.86-241
+- Update dependencies.
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+
* Mon Aug 13 2012 Marcela Mašláňová mmasl...@redhat.com - 1.86-240
- bump release to override sub-package from perl.spec
--
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-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the rawhide tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so 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
[Bug 872157] perl-Date-Manip-6.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872157 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@redhat.com -- 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-Browser-Open] Add BRs perl(Carp), perl(Exporter).
commit 2aee2b933772ea12aa9e244d67948e8f49d5298f
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Nov 1 14:13:49 2012 +0100
Add BRs perl(Carp), perl(Exporter).
Signed-off-by: Marcela Mašláňová mmasl...@redhat.com
perl-Browser-Open.spec |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl-Browser-Open.spec b/perl-Browser-Open.spec
index 7830471..fa9cbe2 100644
--- a/perl-Browser-Open.spec
+++ b/perl-Browser-Open.spec
@@ -1,12 +1,14 @@
Name: perl-Browser-Open
Version:0.04
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Open a browser in a given URL
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Browser-Open/
Source0:
http://search.cpan.org/CPAN/authors/id/C/CF/CFRANKS/Browser-Open-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(parent)
@@ -52,6 +54,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 01 2012 Jitka Plesnikova jples...@redhat.com - 0.04-4
+- Add BRs perl(Carp), perl(Exporter)
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.04-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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 Date-Manip-6.36.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Date-Manip: e060c47350c7b7c1ed25e7a52ecac4a9 Date-Manip-6.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-Date-Manip] 6.36 bump
commit f007b2d48a5ee6fb85fa6f4fd8233db905d51c14
Author: Petr Šabata con...@redhat.com
Date: Thu Nov 1 14:58:14 2012 +0100
6.36 bump
.gitignore |1 +
perl-Date-Manip.spec | 12 +++-
sources |2 +-
3 files changed, 9 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a764c14..1493704 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ Date-Manip-6.07.tar.gz
/Date-Manip-6.31.tar.gz
/Date-Manip-6.32.tar.gz
/Date-Manip-6.34.tar.gz
+/Date-Manip-6.36.tar.gz
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index abd99a5..d6bc073 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,5 +1,5 @@
Name: perl-Date-Manip
-Version:6.34
+Version:6.36
Release:1%{?dist}
Summary:Date manipulation routines
Group: Development/Libraries
@@ -15,7 +15,6 @@ BuildRequires: perl(IO::File)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Storable)
BuildRequires: perl(Test::More)
-BuildRequires: perl(YAML::Syck)
# Tests only
BuildRequires: perl(Test::Inter)
BuildRequires: perl(Test::Pod) = 1.00
@@ -45,9 +44,9 @@ perl Build.PL installdirs=vendor
./Build
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-%{_fixperms} $RPM_BUILD_ROOT/*
+./Build install destdir=%{buildroot} create_packlist=0
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} %{buildroot}/*
%check
./Build test
@@ -59,6 +58,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_bindir}/dm_*
%changelog
+* Thu Nov 01 2012 Petr Šabata con...@redhat.com - 6.36-1
+- 6.36 bump
+
* Wed Sep 12 2012 Jitka Plesnikova jples...@redhat.com - 6.34-1
- 6.34 bump
- examples are included in man pages and bin directory. Remove them from doc.
diff --git a/sources b/sources
index 8f9281f..743d1f0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-99d474e2d832dd23c9ea889b33f2019a Date-Manip-6.34.tar.gz
+e060c47350c7b7c1ed25e7a52ecac4a9 Date-Manip-6.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 872157] perl-Date-Manip-6.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872157 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Date-Manip-6.36-1.fc19 Resolution|--- |RAWHIDE Last Closed||2012-11-01 10:23:07 -- 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
File MIME-Types-1.36.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-MIME-Types: 94b44788ccf668ce155d0973d8e14a5b MIME-Types-1.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-MIME-Types] Created tag perl-MIME-Types-1.36-1.fc18
The lightweight tag 'perl-MIME-Types-1.36-1.fc18' was created pointing to: 3863b4d... Update to 1.36 -- 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-MIME-Types] Created tag perl-MIME-Types-1.36-1.fc19
The lightweight tag 'perl-MIME-Types-1.36-1.fc19' was created pointing to: 3863b4d... Update to 1.36 -- 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
