EPEL epel beta report: 20140220 changes
Compose started at Thu Feb 20 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 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm 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-rsa 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 dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) 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 koji-vm-1.8.0-2.el7.noarch requires python-virtinst 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) nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg perl-qpid-0.24-2.el7.x86_64 requires perl(qpid_messaging) phoronix-test-suite-4.8.6-1.el7.noarch requires php-fpdf plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils postgrey-1.34-12.el7.noarch requires perl(Net::Server::Multiplex) postgrey-1.34-12.el7.noarch requires perl(Net::Server::Daemonize) postgrey-1.34-12.el7.noarch requires perl(Net::Server) postgrey-1.34-12.el7.noarch requires perl(BerkeleyDB) python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 python-social-auth-0.1.19-1.el7.noarch requires python-oauthlib = 0:0.3.8 qt4pas-2.5-3.el7.x86_64 requires fpc-src racoon2-20100526a-27.el7.x86_64 requires perl-Getopt-Simple rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 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 spectrwm-2.4.0-2.el7.x86_64 requires xlockmore spectrwm-2.4.0-2.el7.x86_64 requires dmenu stompclt-1.1-1.el7.noarch requires perl(Net::STOMP::Client) = 0:2.0 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 TurboGears-1.1.3-8.el7.noarch requires python-simplejson = 0:1.9.1 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires mod_python chm2pdf-0.9.1-13.el7.noarch requires python-chm 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 docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-simplejson docker-registry-0.6.5-1.el7.noarch requires python-rsa 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 dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) fedmsg-0.7.5-1.el7.noarch requires python-simplejson fedmsg-0.7.5-1.el7.noarch requires python-requests git-cola-1.9.4-2.el7.noarch requires python-simplejson 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 httpie-0.8.0-1.el7.noarch requires python-requests koji-vm-1.8.0-2.el7.noarch requires python-virtinst lxc-templates-0.9.0-3.el7.ppc64 requires dpkg lxc-templates-0.9.0-3.el7.ppc64
Re: EPEL Issue with koji?
On Thu, 20 Feb 2014 07:54:07 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm trying to do a build on koji and ran into an error during the mock buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038 ). I posted previously on the Fedora devel mailing list but haven't figured it out yet ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html ). Is this something wrong with koji? Or with the EL6/EPEL packages? I answered you on the devel list: https://lists.fedoraproject.org/pipermail/devel/2014-February/195114.html Did a more recent build also fail? Please resubmit. 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 Issue with koji?
On Thu, Feb 20, 2014 at 10:26 AM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 20 Feb 2014 07:54:07 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm trying to do a build on koji and ran into an error during the mock buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038 ). I posted previously on the Fedora devel mailing list but haven't figured it out yet ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html ). Is this something wrong with koji? Or with the EL6/EPEL packages? I answered you on the devel list: https://lists.fedoraproject.org/pipermail/devel/2014-February/195114.html Did a more recent build also fail? Please resubmit. Yes, waiting did work for that issue ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195156.html), but this is another issue and appears to that the building of the source .rpm isn't working properly for some reason. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Base] WGs Technical Specifications and Base WG
Hi! Matthias presented on Desktop list [1] initial Technical Specification document for Workstation product [2]. I expect other WGs will come with similar document soon to fulfil FESCo request. But the discussion on desktop list steered towards what should be in Base and what in products and if bottom up or top down approach should be used to define Base (and truth is probably as always somewhere in the middle). It's great to see technical requirements from WS WG that could help our group see if it fits to our vision, if we want to extend it based on this document etc. And there are sections we already decided this functionality belong to Base aka installer (even WS has a bit different requirements compared to current installer so flexibility in design should be let in this WG). Let's discuss it on Friday's Base WG meeting, Phil, could you add to the agenda? Btw. as Base use devel list - I'd like to ask other WGs to ping us once they have tech spec document available for review. Jaroslav [1] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009136.html [2] https://fedoraproject.org/wiki/Workstation/Technical_Specification -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Renaming the cloud-utils package
On Wed, Feb 19, 2014 at 06:18:30PM +0100, Juerg Haefliger wrote: Hi, I'm trying to figure out if it makes sense to rename the cloud-utils (sub-)package for EPEL7 and F21. Upstream (Ubuntu) used to have a single package named cloud-utils which we decided to split up into two packages, cloud-utils and cloud-utils-growpart. The reason being that cloud-utils pulls in a lot of additional packages which is sub-optimal for cloud images. Now Ubuntu followed suit and provides cloud-guest-utils and cloud-image-utils sub-packages. My question is if we should align with Ubuntu and rename our packages or stick with what we have? I admit I'm ignorant to all the ramifications of renaming a package but from a user's perspective it's definitely a benefit if package names match across distros. It makes sense to follow upstream here. The process is documented here[1]. I'd inform the cloud WG, because they might be interested ;-) Matthias [1] https://fedoraproject.org/wiki/Package_Renaming_Process -- Matthias Runge mru...@matthias-runge.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
Original Message Subject: [Rpm-maint] Heads up: Weak and rich dependencies in RPM Date: Thu, 20 Feb 2014 13:12:43 +0100 From: Florian Festi ffe...@redhat.com To: rpm-ma...@lists.rpm.org, rpm-l...@lists.rpm.org Hi! We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: #1 Adding weak dependencies as already used by SuSE and others: Recommends:, Suggests:, Supplements: and Enhances:. We agreed with Michael Schröder to not use SuSE's current implementation but to add new tags for a cleaner interface and an easy update path for already existing packages. This is planned to be part of the next RPM version. As old tools will just ignore the new tags this isn't a big compatibility issue. Support in rpmbuild can probably back ported easily. #2 Allow Boolean expressions of (Name Flag Version) terms in Requires:, Conflicts: and the new weak dependencies (rich dependencies). This will add a new expressive strength to RPM's dependency model and allow fixing a couple of packaging problems we don't have a solution for right now and also get rid of some special case solutions like hand coded language pack support. As we are still figuring out some of the implementation details and implications this feature may or may not make it in the next release. Packages using such Boolean expressions will not work with old versions of rpm and other related tools and it is still unclear to what extend this feature can be back ported. What implication does this have on your distribution? Stuff affecting other distributions left out Getting the support into createrepo and libsolv is taken care of. This should cover Fedora and OpenSUSE and may be others. I wrote a document describing more technical details. Find it attached to this mail. Florian rich_relations.odt Description: application/vnd.oasis.opendocument.text ___ Rpm-maint mailing list rpm-ma...@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] WGs Technical Specifications and Base WG
On 02/20/2014 11:43 AM, Jaroslav Reznik wrote: Hi! Matthias presented on Desktop list [1] initial Technical Specification document for Workstation product [2]. I expect other WGs will come with similar document soon to fulfil FESCo request. But the discussion on desktop list steered towards what should be in Base and what in products and if bottom up or top down approach should be used to define Base (and truth is probably as always somewhere in the middle). It's great to see technical requirements from WS WG that could help our group see if it fits to our vision, if we want to extend it based on this document etc. And there are sections we already decided this functionality belong to Base aka installer (even WS has a bit different requirements compared to current installer so flexibility in design should be let in this WG). Let's discuss it on Friday's Base WG meeting, Phil, could you add to the agenda? Btw. as Base use devel list - I'd like to ask other WGs to ping us once they have tech spec document available for review. Jaroslav [1] https://lists.fedoraproject.org/pipermail/desktop/2014-February/009136.html [2] https://fedoraproject.org/wiki/Workstation/Technical_Specification Hi Jaroslav. Thanks for the heads up, i'll add it for tomorrows agenda. Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)
On Wed, Feb 19, 2014 at 2:57 PM, Tomas Mraz tm...@redhat.com wrote: * Open floor (t8m, 19:45:44) * AGREED: FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0) (t8m, 19:50:38) * ACTION: t8m will update the weekly reports ticket with this request (t8m, 19:53:08) It would help if FESCo had a set of specific things they are looking for by that date. Otherwise you're going to get varied information and detail from each of the WGs. Guidance is requested. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: arm builder versus buildvm-26.phx2 , different results ?
On Thu, Feb 20, 2014 at 06:39:38AM +, Sérgio Basto wrote: The answer appears to be because dpkg thinks DEB_BUILD_ARCH and DEB_HOST_ARCH are different for us (arm versus armel respectively.) and this means it doesn't run dh_auto_test properly. The reason for that is more complicated, and it appears to think we're cross-compiling because dpkg --print-architecture and gcc -dumpmachine lead dpkg to think we're arm in one case and armel in the other through the archtable. so is dpkg fault ? Thanks, but what should I do ? report upstream ? Well, given for armv7hl-redhat-linux-gnu, I think we want armhfp to be our architecture... I wouldn't quite blame anyone, but we probably need a translation layer between our triplet, and Debian's idea of what it means. --Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. I guess one could go with the shortest package name wins approach or whatever the current heuristic is for now... This is also relevant with things like kickstart files, where there is no interactivity allowed. (For what it's worth I think making packaging even more complex and less predictable in order to increase flexibility is precisely the opposite direction of what we should be doing...but that's OK because I am coming at this from the other direction. We'll meet in the middle somehow ;) ) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Issue with koji?
I'm trying to do a build on koji and ran into an error during the mock buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038 ). I posted previously on the Fedora devel mailing list but haven't figured it out yet ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html ). Is this something wrong with koji? Or with the EL6/EPEL packages? Thanks, Dave ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Query about package versioning
Hi All, We are trying to sort out how to do kexec-tools package version, release number management in fedora across various branches, hence this query. I quickly went through following. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Naming_and_Versioning_Guidelines So far we do following. - In master branch keep on doing development and keep on bumping release at regular intervals. kexec-tools-2.0.4-1.fc21 kexec-tools-2.0.4-2.fc21 kexec-tools-2.0.4-3.fc21 ... ... kexec-tools-2.0.4-23.fc21 Lets say now FC21 forks off and a new branch is created. We keep on bumping release number in FC21 branch also. kexec-tools-2.0.4-24.fc21 kexec-tools-2.0.4-25.fc21 ... ... kexec-tools-2.0.4-30.fc21 And master will continue. kexec-tools-2.0.4-24.fc22 kexec-tools-2.0.4-25.fc22 ... ... kexec-tools-2.0.4-30.fc22 Are we doing the right thing here. I have few problems with above model. - By bumping release version, we kind of lose the information what was our base at the time of fork of branch. - Release numbers of released branch can get ahead of master branch depending on how many releases were done on master and how many releases were done on released branches. So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. Thanks Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
W dniu 20.02.2014 17:16, Vivek Goyal pisze: So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. %dist should be at the end. So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of fc21 package after distribution release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On 02/20/2014 05:16 PM, Vivek Goyal wrote: So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. IMO it's best to do fast-forward merges between branches when possible. In particular merging mass rebuild commits is OK. In case FF merge is impossible I agree with the procedure you described. You need to increase release tag in a way that assures upgrade path and one way to do that is adding .1 after dist tag. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On 02/20/2014 05:28 PM, Marcin Juszkiewicz wrote: W dniu 20.02.2014 17:16, Vivek Goyal pisze: So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. %dist should be at the end. So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of fc21 package after distribution release. That won't work if both branches already have the same release number and you need to bump release in older branch. That can happen for example if you were fast-forwarding commits from f21 to f20 and at some point you need to add a bugfix only for f20. Adding .1 after dist-tag will work in this case. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 02/19/2014 01:16 PM, Adam Williamson wrote: On Sun, 2014-02-16 at 14:38 +, Richard Hughes wrote: On 14 February 2014 21:43, Przemek Klosowski przemek.klosow...@nist.gov wrote: If we are providing a next-generation UI for installing, to replace yum That's not what we're doing. To expand a bit: insofar as Software - the tool we're discussing here, and the tool to which the require applications to ship appdata requirement applies - replaces anything, it replaces gnome-packagekit. It is not replacing yum. The old gnome-packagekit was a 'graphical package installer', just like yumex and apper. The new gnome-software is (with a bit of a handwave) an 'application installer'. That's a difference, but it's not relevant to yum at all, and I doubt many people used gpk to install gcc. For those who really want a GUI package installer, the old gpk is still available in a not-installed-by-default package (though I assume Richard will eventually drop it), and yumex is always an option. Thanks for the context. The reason I keep on droning about it is well explained by the old military saying What is worse than a bad general? Two good generals.. I.e., it would be nice if there was one go-to application for GUI software installation that everyone uses and improves. As it is, we have four: yumex, gpk, apper and now Richard's, and every one has some unique nice and/or niche features (*). It's just a better user experience when there's one GUI installer with simple default choice and advanced options, rather than having to explain that if you're installing development tools, use this, else if you're installing graphics apps, use that, else if you're installing commandline tools use the other thing. Speaking for myself, I use yum all the time, but I do find GUIs useful, for instance when I remember that there's a useful structural chemistry app called A--something... angstrom? asteroid? haemoroid? ahh, Avogadro!!!. Just happened to me recently. It's much easier to find it in a GUI browser. I feel I said everything that I can say about this, so I will sit down and be quiet now. Greetings p (*) I never really used apper, and when I just brought it up, I liked its broad selection of filters (free/nonfree, native, developer/end user, commandline/graphical, etc). They turn out to be more useful than I expected them to be---for instance the non-free filter surprised me by when I looked at OpenCASCADE---I didn't realize it came from rpmfusion-nonfree (this is actually changing as we speak, its license was just changed and a large body of software including FreeCAD, and other sci/eng visualization stuff is moving to the mainline Fedora repo). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Thu, 2014-02-20 at 12:01 -0500, Przemek Klosowski wrote: On 02/19/2014 01:16 PM, Adam Williamson wrote: On Sun, 2014-02-16 at 14:38 +, Richard Hughes wrote: On 14 February 2014 21:43, Przemek Klosowski przemek.klosow...@nist.gov wrote: If we are providing a next-generation UI for installing, to replace yum That's not what we're doing. To expand a bit: insofar as Software - the tool we're discussing here, and the tool to which the require applications to ship appdata requirement applies - replaces anything, it replaces gnome-packagekit. It is not replacing yum. The old gnome-packagekit was a 'graphical package installer', just like yumex and apper. The new gnome-software is (with a bit of a handwave) an 'application installer'. That's a difference, but it's not relevant to yum at all, and I doubt many people used gpk to install gcc. For those who really want a GUI package installer, the old gpk is still available in a not-installed-by-default package (though I assume Richard will eventually drop it), and yumex is always an option. Thanks for the context. The reason I keep on droning about it is well explained by the old military saying What is worse than a bad general? Two good generals.. I.e., it would be nice if there was one go-to application for GUI software installation that everyone uses and improves. As it is, we have four: yumex, gpk, apper and now Richard's, and every one has some unique nice and/or niche features (*). It's just a better user experience when there's one GUI installer with simple default choice and advanced options, One app with simple default choice and advanced options effectively *is* two apps, uncomfortably shoehorned into one UI. You get all the disadvantages of complexity with none of the benefits of simplicity. This is why it's a model most apps have moved away from. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)
On Thu, 20 Feb 2014 07:53:01 -0500 Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Feb 19, 2014 at 2:57 PM, Tomas Mraz tm...@redhat.com wrote: * Open floor (t8m, 19:45:44) * AGREED: FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0) (t8m, 19:50:38) * ACTION: t8m will update the weekly reports ticket with this request (t8m, 19:53:08) It would help if FESCo had a set of specific things they are looking for by that date. Otherwise you're going to get varied information and detail from each of the WGs. Guidance is requested. Well, (not speaking for all of FESCo), I was thinking first it would be the next expected deliverable: The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product. This should be ordered to show what things depend on other changes and at which point the changes will mean that we can no longer produce the current type of Fedora. This will allow us to identify the resources needed by what teams in order to implement the plan and at what point we may need to have a longer than normal release cycle to do tooling work. I think thats still not very detailed tho, so for me at least, I would love to see: * What are your working groups deliverables? The actual thing we will be giving our users? (ie, a 1gb live iso image, or a netinstall.iso, or a cloud qcow2 image) with (these workstation/server/cloud components on it in configuration X) * based on that, what changes to our current setup would you need to make that happen? (changes to livecd-creator, cloud image production, pungi) and/or (websites showing all products) and/or (what would marketing be able to hand out at events) and/or ... Basically data so we can all discuss what we can bite off for f21 and hopefully make some awesome compelling products. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 20 February 2014 17:44, Adam Williamson awill...@redhat.com wrote: You get all the disadvantages of complexity with none of the benefits of simplicity. Jack of all trades, master of none. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On Thu, Feb 20, 2014 at 05:28:02PM +0100, Marcin Juszkiewicz wrote:
W dniu 20.02.2014 17:16, Vivek Goyal pisze:
So instead of increasing release number on released branches, why don't
we append additional number after dist and bump that up in released
branch. So FC21 releases will look like.
kexec-tools-2.0.4-24.fc21.1
kexec-tools-2.0.4-24.fc21.2
...
...
kexec-tools-2.0.4-23.fc21.10
That way we clearly know that FC21 was forked off master release .24. And
upgradability of package will be maintained without any change of older
release versions getting ahead of newer release versions.
%dist should be at the end.
[ Can you please keep me in To list. I don't want to scan mailing list
to figure out if somebody responded to my mail or not ]
Why %dist should be at the end? html page I referenced previously mentions
that one can use x.%{dist}.y kind of release number in select cases.
So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
fc21 package after distribution release.
I think this will work too. As 23 got frozen in time and master and later
releases will always be higher. And that would not break upgradability.
Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On Thu, Feb 20, 2014 at 05:39:17PM +0100, Mikolaj Izdebski wrote: On 02/20/2014 05:28 PM, Marcin Juszkiewicz wrote: W dniu 20.02.2014 17:16, Vivek Goyal pisze: So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. %dist should be at the end. So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of fc21 package after distribution release. That won't work if both branches already have the same release number and you need to bump release in older branch. That can happen for example if you were fast-forwarding commits from f21 to f20 and at some point you need to add a bugfix only for f20. Adding .1 after dist-tag will work in this case. What is fast forwarding commits from f21 to f20. I guess you are saying there are bunch of commits in master branch and you want to now apply those commits to f20 branch too? If yes, one can simply do another release on master branch if there is a need to commit a patch in f20 only. Say master is at kexec-tools-2.0.4-23.0.fc21 and has bunch of more commits on top. FC21 forks off and has kexec-tools-2.0.4-23.0.fc21 and a patch needs to applied to FC21 only. Then one can do another release on master to avoid any kind of upgradability conflicts. master will be kexec-tools-2.0.4-24.0.fc22 FC21 will be kexec-tools-2.0.4-23.1.fc21 So I don't see why above will not work? IOW, it is better to use an extra field for versioning of released branches to avoid any kind of conflicts with master. Instead of overloading same release field for all the branches. Not sure why more package not follow this extra field thing. I am trying to find out if anything is fundamentally wrong if we try to pursue this scheme in kexec-tools pacakge. Thanks Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On Thu, 20 Feb 2014 17:28:02 +0100, Marcin Juszkiewicz wrote: W dniu 20.02.2014 17:16, Vivek Goyal pisze: So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. %dist should be at the end. No. See: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- 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: python-django update to Django-1.6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/2013 08:41 AM, Pierre-Yves Chibon wrote:
On Mon, Nov 25, 2013 at 09:07:55AM +0100, Matthias Runge wrote:
Hey,
recently, I saw a few requests to update python-django to
Django-1.6, the corresponding bug is [1].
As there are quite a few changes, I'd expect this update to be
harmful, at least - python-django-openstack-auth -
openstack-dashboard
will break, and won't even build any more (because they also
execute sanity checks during build).
So, the current plan is, to fix both packages upstream and then
to update python-django to Django 1.6 in rawhide. I'd expect this
to happen within the next two weeks and I'd update python-django
to Django-1.6 around Dec 16th.
Because of bad timing, we won't have Django-1.6 in f20.
Just an idea, but what about providing Django 1.6 via copr for
F{20,19}? That might also help testing current apps against the new
Django.
Just to bring this thread back to life, we're getting to a point where
support for Django 1.6 is becoming more and more necessary. Is there
an ETA on its inclusion in Rawhide or COPR?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMGVUsACgkQeiVVYja6o6PmHgCfec4kS0V/rj2GHFYxU6bgsuXs
duAAnRuGWvXnfu087Zed23uSLzvnrxAp
=BM6s
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 02/20/2014 12:44 PM, Adam Williamson wrote: One app with simple default choice and advanced options effectively *is* two apps, uncomfortably shoehorned into one UI. You get all the disadvantages of complexity with none of the benefits of simplicity. This is why it's a model most apps have moved away from. OK, I lied---I will respond with one more post. You'd be right if it really was two apps, shoehorned---but I really think this case wants to be one software installation UI with several search selectors, just like apper, which actually has a 'graphical/non-graphical' search selector. Use the http://en.wikipedia.org/wiki/%F0%9F%92%BB glyph at low-res as a screenshot/logo, to show our disdain for older apps, if we must. Surely you agree that it's possible to overdo such app specialization; my favorite example of such specious differentiation is dedicated droid/ios apps for every website (reddit/slashdot/whatever). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libcogl soname bump
Hello, I've just built cogl 1.17.4 for rawhide, which includes a soname bump. I am going to run a script to rebuild all consumers (38, list below), but since it's quite a few packages, some of them might fail to rebuild, for unrelated reasons. Help appreciated if one of these shows up in the rawhide broken dep list tomorrow. $ repoquery -q --disablerepo='*' --enablerepo=rawhide-koji --whatrequires 'libcogl*.so.19*' -s | sort | uniq | rev | cut -f 3- -d - | rev bijiben caribou cheese cinnamon clutter clutter-gst clutter-gst2 clutter-gtk cogl empathy eog-plugins gnome-boxes gnome-contacts gnome-nibbles gnome-shell gpx-viewer gthumb libchamplain libmash libmx lightsoff media-explorer muffin mutter mutter-wayland nemo-extensions pinpoint quadrapassel rhythmbox snappy-player sushi swell-foop totem xfdashboard -- Thanks, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On 02/20/2014 03:44 PM, Colin Walters wrote: On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. Yes and no. Right now there is no plan to allow the user to do the choosing. This ambiguity already exists in the current relations and we will continue to handle it automatically. I guess one could go with the shortest package name wins approach or whatever the current heuristic is for now... The heuristics will improved though. Libsolv already uses weak dependencies to choose the more desired package. I hope we can add support for preferring the more left packages over later packages in such or-clauses. That way Requires: sendmail or postfix would prefer sendmail while Requires: MTA chooses one of them the by some unrelated criteria. This is also relevant with things like kickstart files, where there is no interactivity allowed. (For what it's worth I think making packaging even more complex and less predictable in order to increase flexibility is precisely the opposite direction of what we should be doing...but that's OK because I am coming at this from the other direction. We'll meet in the middle somehow ;) ) Actually I am on your side of the argument. This effort is supposed to give better control over how packages behave and relate to each other *to the packager*. While A or B is an often demanded feature the main reason for this are relations that span a longer distance. E.g. Foo-langpack-es could Supplement: Foo and langsupport-es Or to implement the same behaviour with a forward dependency package Foo could Requires: Foo-langpack-es if langsupport-es Both variants pull in a intermediate package (Foo-langpack-es) if two packages are present (Foo and langsupport-es). Florian PS: I actually do think that we need to give the user more control over the packages, too. The current tools are completely inadequate to manage the number of packages we have in the distribution or even just on a system. But this is a story for another time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [Rpm-maint] Heads up: Weak and rich dependencies in RPM
On Thu, 2014-02-20 at 14:44 +, Colin Walters wrote: On Thu, Feb 20, 2014 at 7:27 AM, Florian Festi ffe...@redhat.com wrote: We are currently working on adding weak and rich dependencies to upstream RPM. There are basically two parts: Is someone signed up to do the necessary frontend work for this on the dnf/yum side? If we're allowing choice of A | B like this, there needs to be a frontend that actually allows choosing, like aptitude. Fedora isn't signed up to *use* it yet. We can still make the choice whether we want to or not, I believe. I guess one could go with the shortest package name wins approach or whatever the current heuristic is for now... This is also relevant with things like kickstart files, where there is no interactivity allowed. Typical approach there is simply to come up with a 'default' approach, and that's what kickstarts use. If we use 'rich' dependencies, the questions would be to set policies for the use of each type of dependency in Fedora, and decide what level of 'weak' dependency to install by default. kickstart installs and live image creation would then, one expects, use that same level. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Sean Burke
Hello, My name is Sean Burke, but I also go by Seán de Búrca on some projects. I have been a Linux user for a while now and started using Fedora a few years ago. I have contributed to a number of FLOSS projects over the years, though most of my work has been for the GNOME project in the form of patches and translations. I also contribute data and code to MusicBrainz. I believe strongly in the benefits of FLOSS and seek to improve it wherever I am able. I am hoping to expand the selection of open fonts available in Fedora. To this end, I've created a review request for the Junicode font family[1] and have contacted several font authors about acquiring source for their fonts (when the font is adequately licensed) or changing the license for existing free fonts to meet Fedora licensing standards. In the long run, I am sure I will encounter other packages I would like to see picked up in Fedora's repos. To this end, I am seeking packager sponsorship and am hoping to find someone willing to work with me toward this. Sean Burke [1] https://bugzilla.redhat.com/show_bug.cgi?id=1005518 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-DBD-ODBC/f18] Updated to upstream version 1.47
Summary of changes: 8b7289a... Updated to upstream version 1.47 (*) (*) 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
[perl-DBD-ODBC/f19] Updated to upstream version 1.47
Summary of changes: 8b7289a... Updated to upstream version 1.47 (*) (*) 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
[perl-DBD-ODBC/f20] Updated to upstream version 1.47
Summary of changes: 8b7289a... Updated to upstream version 1.47 (*) (*) 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: python-django update to Django-1.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2014 08:19 PM, Stephen Gallagher wrote: Just to bring this thread back to life, we're getting to a point where support for Django 1.6 is becoming more and more necessary. Is there an ETA on its inclusion in Rawhide or COPR? Whah, thank you! There's a Django-1.6 build here in copr[1], and I'd like to push an update to rawhide in about 14 days. Any feedback is appreciated! What about pushing Django-1.6 to epel7, too? [1] https://copr.fedoraproject.org/coprs/mrunge/Django-1.6/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTBwTWAAoJEOnz8qQwcaIWpr8IAKZnHbn0NFkgqHACL6x11mCj CSmo/3FIAfeG6PCUY/9lJ6brZhrDx0YCnFG5E5mfG2vph4dcQ4IZixmiQKsunHb0 Duiy/aODhiCSBss2DJLChOY+EYJckJ+zZd/tfSQE4ifsAhj+6NH5qdg/KGe6NRfP F0eghLxhZifh1f82UunhNUy/TkCEQvVUSptI4dq9s8lbAMRvcUKrHOXxabiTjOus uXqNrcKrUNukidl0KBdQh5oQvbU+5xzeqaM0aHyWqga3mEB9o6ZqZABMS44Xmp8z H9DeIGuqnLq/FH/nPtFbv4kR9UqOB2t06Q2VoHElRa8bTiAN1vdnif8jp8AAVs0= =gmXo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: stompclt
stompclt has broken dependencies in the epel-7 tree: On x86_64: stompclt-1.1-1.el7.noarch requires perl(Net::STOMP::Client) = 0:2.0 On ppc64: stompclt-1.1-1.el7.noarch requires perl(Net::STOMP::Client) = 0:2.0 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: dspam
dspam has broken dependencies in the epel-7 tree: On x86_64: dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) On ppc64: dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) 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 1067394] New: perl-Gtk3-0.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1067394 Bug ID: 1067394 Summary: perl-Gtk3-0.016 is available Product: Fedora Version: rawhide Component: perl-Gtk3 Keywords: FutureFeature, Triaged Assignee: berra...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: berra...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 0.016 Current version/release in Fedora Rawhide: 0.015-1.fc21 URL: http://search.cpan.org/dist/Gtk3/ 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. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LONNvhlEZNa=cc_unsubscribe -- 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 1067396] New: perl-PerlIO-locale-0.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1067396 Bug ID: 1067396 Summary: perl-PerlIO-locale-0.10 is available Product: Fedora Version: rawhide Component: perl-PerlIO-locale Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.10 Current version/release in Fedora Rawhide: 0.09-1.fc21 URL: http://search.cpan.org/dist/PerlIO-locale/ 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. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NpsjXEMpDua=cc_unsubscribe -- 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 PerlIO-locale-0.10.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-PerlIO-locale: f18ca114e09be19f73e89b8f5419b2ea PerlIO-locale-0.10.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-PerlIO-locale] 0.10 bump
commit 27efceee23eab553feaf1167eee275268c08ee4d
Author: Petr Písař ppi...@redhat.com
Date: Thu Feb 20 15:16:38 2014 +0100
0.10 bump
.gitignore |1 +
.rpmlint|2 ++
perl-PerlIO-locale.spec | 15 +--
sources |2 +-
4 files changed, 13 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ec55b60..ce3715d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/PerlIO-locale-0.07.tar.gz
/PerlIO-locale-0.08.tar.gz
/PerlIO-locale-0.09.tar.gz
+/PerlIO-locale-0.10.tar.gz
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..36cc9db
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter(spelling-error .* pragma);
diff --git a/perl-PerlIO-locale.spec b/perl-PerlIO-locale.spec
index 21d8060..42e75a9 100644
--- a/perl-PerlIO-locale.spec
+++ b/perl-PerlIO-locale.spec
@@ -1,5 +1,5 @@
Name: perl-PerlIO-locale
-Version:0.09
+Version:0.10
Release:1%{?dist}
Summary:PerlIO layer to use the encoding of the current locale
License:GPL+ or Artistic
@@ -39,14 +39,14 @@ the locale currently in effect, if perl can guess it.
%setup -q -n PerlIO-locale-%{version}
%build
-perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE='%{optflags}'
make %{?_smp_mflags}
%install
-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 {} \;
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install DESTDIR='%{buildroot}'
+find '%{buildroot}' -type f -name .packlist -exec rm -f {} +
+find '%{buildroot}' -type f -name '*.bs' -size 0 -exec rm -f {} +
+%{_fixperms} '%{buildroot}'/*
%check
make test
@@ -58,6 +58,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Feb 20 2014 Petr Pisar ppi...@redhat.com - 0.10-1
+- 0.10 bump
+
* Thu Feb 06 2014 Petr Pisar ppi...@redhat.com - 0.09-1
- 0.09 bump
diff --git a/sources b/sources
index 5d6b966..20fe3d1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5cb7241c0e9c7ff7c87a0d9759bcdcea PerlIO-locale-0.09.tar.gz
+f18ca114e09be19f73e89b8f5419b2ea PerlIO-locale-0.10.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 1067396] perl-PerlIO-locale-0.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1067396 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PerlIO-locale-0.10-1.f ||c21 Resolution|--- |RAWHIDE Last Closed||2014-02-20 09:42:41 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This release corrects metadata only. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=twUDUT8xcIa=cc_unsubscribe -- 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 1067180] CVE-2013-7329 perl-CGI-Application: information disclosure flaw
https://bugzilla.redhat.com/show_bug.cgi?id=1067180 Vincent Danen vda...@redhat.com changed: What|Removed |Added Summary|perl-CGI-Application: |CVE-2013-7329 |information disclosure flaw |perl-CGI-Application: ||information disclosure flaw Alias||CVE-2013-7329 --- Comment #3 from Vincent Danen vda...@redhat.com --- CVE-2013-7329 was assigned to this issue: http://openwall.com/lists/oss-security/2014/02/20/1 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BMDYu9u4xWa=cc_unsubscribe -- 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 DBD-ODBC-1.47.tar.gz uploaded to lookaside cache by holcapek
A file has been added to the lookaside cache for perl-DBD-ODBC: d5dc91518dc4a476f98e74d8c0774947 DBD-ODBC-1.47.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-DBD-ODBC] Updated to upstream version 1.47
commit 8b7289ac0532f2f443a86e3df3e5e2b8dc678163
Author: Jan Holcapek holca...@gmail.com
Date: Fri Feb 21 07:55:50 2014 +0100
Updated to upstream version 1.47
.gitignore |1 +
perl-DBD-ODBC.spec |5 -
sources|1 +
3 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7f39fcc..b92996d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/DBD-ODBC-1.45.tar.gz
+/DBD-ODBC-1.47.tar.gz
diff --git a/perl-DBD-ODBC.spec b/perl-DBD-ODBC.spec
index 2d1e7cc..1c2184c 100644
--- a/perl-DBD-ODBC.spec
+++ b/perl-DBD-ODBC.spec
@@ -1,5 +1,5 @@
Name: perl-DBD-ODBC
-Version:1.45
+Version:1.47
Release:1%{?dist}
Summary:ODBC Driver for DBI
License:GPL+ or Artistic
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Feb 21 2014 Jan Holcapek holca...@gmail.com 1.47-1
+- Updated to upstream version 1.47.
+
* Fri Nov 22 2013 Jan Holcapek holca...@gmail.com 1.45-1
- Initial import (#1028521).
diff --git a/sources b/sources
index 694e441..afbf95f 100644
--- a/sources
+++ b/sources
@@ -1 +1,2 @@
3c750cde8e39fbba804043485f18ba68 DBD-ODBC-1.45.tar.gz
+d5dc91518dc4a476f98e74d8c0774947 DBD-ODBC-1.47.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-DBD-ODBC/el6] Updated to upstream version 1.47
Summary of changes: 8b7289a... Updated to upstream version 1.47 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
