EPEL epel beta report: 20140418 changes
Compose started at Fri Apr 18 08:15:02 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears caja-beesu-manager-1.8-19.el7.noarch requires /usr/bin/pluma 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) chm2pdf-0.9.1-13.el7.noarch requires htmldoc docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma gedit-beesu-plugin-0.4-19.el7.x86_64 requires python3 globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg php-phpseclib-crypt-aes-0.3.5-2.el7.noarch requires php-pear(phpseclib.sourceforge.net/Crypt_Rijndael) = 0:0.3.0 plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils pluma-beesu-plugin-0.4-19.el7.x86_64 requires pluma python-tgcaptcha2-0.2.0-5.el7.noarch requires python-fedora-turbogears qt4pas-2.5-3.el7.x86_64 requires fpc-src rabbitvcs-core-0.16-1.el7.noarch requires python-dulwich rabbitvcs-core-0.16-1.el7.noarch requires pysvn rabbitvcs-nautilus-0.16-1.el7.x86_64 requires nautilus-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunarx-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunar ruby-openbabel-2.3.2-1.el7.x86_64 requires ruby(abi) = 0:1.9.1 rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-mizuho-0.9.20-2.el7.noarch requires rubygem(sqlite3) rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(multi_json) = 0:1.0 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) 0:1 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) = 0:0.8 spectrwm-2.5.0-1.el7.x86_64 requires xlockmore spectrwm-2.5.0-1.el7.x86_64 requires dmenu Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears caja-beesu-manager-1.8-19.el7.noarch requires /usr/bin/pluma 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode copr-cli-1.32-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma fedmsg-0.7.7-1.el7.noarch requires python-requests fedora-dockerfiles-0-0.5.git122ef5d.el7.noarch requires docker-io gedit-beesu-plugin-0.4-19.el7.ppc64 requires python3 globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine golang-github-coreos-go-systemd-devel-0-0.4.git8514b9f.el7.noarch requires golang golang-github-godbus-dbus-devel-0-0.1.gitcb98efb.el7.noarch requires golang golang-github-guelfey-godbus-devel-0-0.1.gitf6a3a23.el7.noarch requires golang
Re: EPEL [pkgdb] python-augeas epel7 cloned from EL-6
I've retired the epel7 branch in pkgdb. I'm not sure if it needs to be blocked in koji for epel7, you might want to check with rel-eng on that. On Thu, Apr 17, 2014 at 10:46 PM, Greg Swift gregsw...@gmail.com wrote: sorry that got sent prematurely. Here is the full version: hey all. So I was talking to Dominic Cleal this week at the Summit and he pointed out that python-augeas is getting pulled into RHEL 7 proper. Its not in the beta, but it is built for the RC. My reaction was kewl, dont have to worry about the epel package for el7! I then got a bug report asking for python-augeas in epel7[1], which i closed with the above explanation. Then i got the included pkgdb automated e-mail. :( A build has not been started in koji yet, which is good. So, what is the proper way for me to remove the EPEL7 branch? I looked at the FAQ and only saw one about removing the package from EPEL[3], which has a bad link and needs to be updated. Since its just the branch I also wasn't sure if that was the best route, or if i just delete the branch? thanks! greg [1] https://bugzilla.redhat.com/show_bug.cgi?id=1088660 [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=6145 [3] https://fedoraproject.org/wiki/EPEL/FAQ#What_do_I_have_to_do_to_get_a_package_removed_from_EPEL.3F On Thu, Apr 17, 2014 at 10:41 PM, Greg Swift gregsw...@gmail.com wrote: hey all. So I was talking to Dominic Cleal this week at the Summit and he pointed out that python-augeas is getting pulled into RHEL 7 proper. Its not in the beta, but it is built for the RC. My reaction, was kewl, dont have to worry about the epel package for el7! I then got a bug report asking for python-augeas in epel7, which i closed with the above explanation. Then i got the below e-mail. :( So, what is the proper way for me to remove that branch? I looked at the FAQ and only saw this: which points to an invalid site, so that needs to be fixed. -- Forwarded message -- From: Fedora PackageDB pk...@fedoraproject.org Date: Thu, Apr 17, 2014 at 12:37 PM Subject: [pkgdb] python-augeas epel7 cloned from EL-6 To: gregsw...@gmail.com limb cloned python-augeas epel7 from EL-6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/python-augeas ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3.4 for 7
On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski or...@cora.nwra.com wrote: So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations: - We could build a python34-3.4 which provides python3 = 3.4. This wou Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either. I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life. - I looks like RedHat has been producing python33 SCLs, and presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs. So, my preference is for the first and will start that soon unless there is consensus for a different approach. I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here? kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL [pkgdb] python-augeas epel7 cloned from EL-6
On Thu, 17 Apr 2014 22:46:37 -0500 Greg Swift gregsw...@gmail.com wrote: sorry that got sent prematurely. Here is the full version: hey all. So I was talking to Dominic Cleal this week at the Summit and he pointed out that python-augeas is getting pulled into RHEL 7 proper. Its not in the beta, but it is built for the RC. My reaction was kewl, dont have to worry about the epel package for el7! I then got a bug report asking for python-augeas in epel7[1], which i closed with the above explanation. Then i got the included pkgdb automated e-mail. :( A build has not been started in koji yet, which is good. So, what is the proper way for me to remove the EPEL7 branch? I looked at the FAQ and only saw one about removing the package from EPEL[3], which has a bad link and needs to be updated. Since its just the branch I also wasn't sure if that was the best route, or if i just delete the branch? As soon as we have the list of packages in the rc release (next week) we can update the wiki page and the branching scripts should refuse to branch it since it's already in. Yeah, it will need to be retired and possibly blocked. ;( Hopefully there's not too many other changes. kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
