Re: [EPEL-devel] Orphaned packages in epel7
On Tue, Oct 14, 2014 at 10:30:07PM +0200, Björn Persson wrote: opensou...@till.name wrote: Please orphan the affected package or retire your package to avoid broken dependencies. Wouldn't the option of adopting the orphan package also be worth mentioning? Thank you for noticing this. Actually it should say that the orphaned package should be adopted or the depending package retired. I will fix this in the next reports. Regards Till ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] EPEL 2014-10-17 meeting cancelled
Due to some conflicts, we may not be able to have quorum on Friday. So I have asked offlist and gotten approval for cancelling the meeting on Friday 2014-10-17. We will try to have a meeting the next week, but know that Kevin Fenzi will be unable to attend. -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Meeting minutes from Env-and-Stacks WG meeting (2014-10-14)
On 14.10.2014 16:51, Honza Horak wrote: #fedora-meeting: Env and Stacks (2014-10-14) Meeting started by hhorak at 13:02:18 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-14/env-and-stacks.2014-10-14-13.02.log.html . Meeting summary --- * init process (hhorak, 13:02:39) * Docker, Docker, Docker (hhorak, 13:06:09) * LINK: https://fedoraproject.org/wiki/Docker (ncoghlan, 13:07:26) * ACTION: hhorak will create a new task about preparing dockerfiles recommended tips (hhorak, 13:40:28) * dockerfile_lint (hhorak, 13:41:03) * LINK: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000565.html (ncoghlan, 13:45:20) * checks to dockerfile_lint might be done in parallel with defining some recommended practices to write dockerfiles (hhorak, 13:46:20) * IDEA: dockerfile_lint could be run in %check section of fedora-dockerfiles package; dockerfile_lint does not seem to be usable in Taskotron unless we start building layered images in Fedora (hhorak, 13:54:55) Yes, running in %check should be ok for now. When we start building layered images, we will probably want to check every Dockerfile coming for build and fail on errors, or at least report warnings. Vašek * taskotron will allow to run some tasks for arbitrary components only, but since it does not do it now we should be fine with running dockerfile_lint in %check for now (hhorak, 14:08:35) * we should start to think about delivering layered images during some of the next meetings (or on ML) (hhorak, 14:17:23) * Picking chairman for the next meeting (hhorak, 14:20:06) * OpenFloor (hhorak, 14:21:13) * standardized macros for bootstrapping packages (hhorak, 14:46:30) * IDEA: packages bootstraps are implemented without any standardization, but with some rules at least for RPM macros names it might be much more easy to bootstrap packages (hhorak, 14:46:30) Meeting ended at 14:50:15 UTC. Action Items * hhorak will create a new task about preparing dockerfiles recommended tips Action Items, by person --- * hhorak * hhorak will create a new task about preparing dockerfiles recommended tips * **UNASSIGNED** * (none) People Present (lines said) --- * hhorak (65) * ncoghlan (54) * nphilipp (21) * juhp (17) * tflink (13) * bkabrda1 (6) * [GNU] (5) * zodbot (4) * pkovar (2) * bkabrda (0) * samkottler (0) * sicampbell (0) * vpavlin (0) * tjanez (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: How to include fonts in Gnome Software?
On 14 October 2014 22:41, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I was looking into what I need to do to have my fonts in displayed in gnome-software. They all seem to fail with vetoappdata required/veto. I'm going to work on documenting the font requirements today; I'll follow up with a blog post and some new instructions :) 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: [lapack] Use generic macro to detect 64 bit platforms
On 10/14/2014 10:14 PM, Jerry James wrote: On Tue, Oct 14, 2014 at 4:57 AM, Panu Matilainen pmati...@laiskiainen.org wrote: [1] says no such thing, the isa macros are defined for all architectures except obviously noarch. Perhaps you're misinterpreting the example on 64bit package requiring a 32bit package which warns that not all 64bit architectures multiarch. Ah, probably so. I think I was already prejudiced in that direction by seeing messages like this one: https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140317/1209708.html. That would be an issue with koji, there's at least these two bugs on it: https://bugzilla.redhat.com/show_bug.cgi?id=1141513 https://bugzilla.redhat.com/show_bug.cgi?id=1096480 There is no such architecture as arm defined in rpm, so obviously arch-specific macros such as the isa-stuff is not defined for it. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libimobiledevice soname bumps
Hi All, A new version of the libimobiledevice stack is on it's way to rawhide. There's some soname bumps but I'll deal with any rebuilds necessary. Peter -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
Dne 17.9.2014 v 14:05 Kai Engert napsal(a): On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote: I believe that we must contact Amazon and Symantec about this issue. Amazon should remove the second intermediate, ending the path with the G5 intermediate. This will allow openssl to find the trusted root CA. Also, Symantec should reach out to all of their customers and tell them you update their configuration. I will contact them. Great! Thanks. Should I open ticket against ca-certificates to keep track about this issue? There was a short discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 In this particular case, because it works with NSS/Firefox, the admins don't think it's necessary to reconfigure? I think it doesn't help to track the issue with this particular web site. I've been told this is a default configuration, which had been recommended by the CA to the customers for a long time, in order to achieve maximum compatibility with clients. So it's unlikely to get all sites changed, for two reasons, worry of site admins to break compatibility, and the fact that it's unrealistic to reach and convince all site admins. This means, we'll either have to find a software solution (such as getting gnutls/openssl enhanced to construct alternative chains), or wait with weak 1024-bit removals by default, until all involved server certificates have expired, which would be very unfortunate (and which might take several years, because of the transitioning trick, that causes recently issued certificates to appear to have been issued by both the weak legacy and stronger replacement root ca cert). I am in favor of the former solution, but the later is good as well. Nevertheless, I am still unsure how to proceed with RubyGems. Should I ship the bundled certificates again? Or should I wait until somebody notices? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141015 changes
Compose started at Wed Oct 15 07:15:03 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires
Re: Possible PPC kernel bug on builders
On 08/10/2014 08:36, Dan Horák wrote: On Tue, 7 Oct 2014 16:27:52 -0600 Jerry James loganje...@gmail.com wrote: On Mon, Oct 6, 2014 at 2:36 PM, Jerry James loganje...@gmail.com wrote: I posted about this 5 days ago on ppc list [1], but have had no response. I tried to get some attention on #fedora-ppc today, also with no success. I am failing miserably to get the attention of any of the PPC folks, so I am trying email here to see if this will work. Still nothing. Can anybody help me get the attention of somebody on the PPC team? we know about it, don't have any answer yet :-( Dan, is there a bug reference ? -- Michel Normand -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141015 changes
Compose started at Wed Oct 15 05:15:05 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [collectd] collectd-onewire-5.4.1-9.fc22.i686 requires libowcapi-2.9.so.5 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glite-jobid-api-java] glite-jobid-api-java-1.3.9-1.fc21.noarch requires jakarta-commons-codec [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23 [hadoop] hadoop-common-2.4.1-5.fc22.noarch requires commons-httpclient [hledger] ghc-hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-hledger-devel-0.19.3-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [idris] idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
Re: [Test-Announce] Taskotron Has Replaced AutoQA
taskotron-dev.fedoraproject.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. The certificate is only valid for taskotron-dev01.qa.fedoraproject.org Tim needs to respond to that. https://taskotron-dev.fedoraproject.org/resultsdb Not Found The requested URL /resultsdb was not found on this server. I filed https://phab.qadevel.cloud.fedoraproject.org/T359 . Where did you come from? I fixed https://fedoraproject.org/wiki/Taskotron/Tasks . Sorry to be so negative :) Bug reports very welcome. Thanks. -- 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: How to include fonts in Gnome Software?
On 15 October 2014 09:06, Richard Hughes hughsi...@gmail.com wrote: I'm going to work on documenting the font requirements today; I'll follow up with a blog post and some new instructions :) Okay, this is the results of a day hacking: http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/ Feedback very welcome. If this looks reasonable, I'll top-post again to devel@fedora and the fonts mailing lists. Thanks. 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
man-db without cache update (no cron or systemd *.timer)
Hi, there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1119625 My suggestion is to create a subpackage (called minimal for example), which will be without cron/*.timer file. Thus no dependency on systemd. User will be responsible for updating cache. The proposal was to make this man-db-minimal implicit, not explicit. I would like to start discussion if it is really important to update cache periodically (so keep it implicit and create man-db-minimal without update) or make it optional (man-db without update and create man-db-enhanced for example). Regards Jan -- 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: Engineering Representiatve for the new Fedora Council
After consulting various people, I nominate Josh Boyer as a candidate. He is an experienced and highly esteemed fesco board member and I believe he is the right person to join the council as Eng. Rep. His experience and his broad but deep understanding of Fedora engineering will be valuable. I'm speaking here on my own behalf, not as a board member. This should not prevent you to nominate another candidate including yourself. H. -- 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: man-db without cache update (no cron or systemd *.timer)
Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. On the majority of systems these days, is it really an issue to cache man pages anymore? I mean, back when a long man page (thinking about some of the perl documentation for example) could take a while to render, it mattered. Now however, systems are much much faster, and we expect GUI web browsers to render vastly more complicated content in a fraction of a second. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? -- Chris Adams li...@cmadams.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: Engineering Representiatve for the new Fedora Council
On Wed, Oct 15, 2014 at 16:44:09 +0200, Haïkel hgue...@fedoraproject.org wrote: After consulting various people, I nominate Josh Boyer as a candidate. My concern is burning Josh out. He has taken on a lot of responsiblity in Fedora already. -- 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: Engineering Representiatve for the new Fedora Council
On Wed, Oct 15, 2014 at 04:44:09PM +0200, Haïkel wrote: After consulting various people, I nominate Josh Boyer as a candidate. He is an experienced and highly esteemed fesco board member and I believe he is the right person to join the council as Eng. Rep. His experience and his broad but deep understanding of Fedora engineering will be valuable. I second this nomination -- Josh would be great. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: man-db without cache update (no cron or systemd *.timer)
On 10/15/2014 04:47 PM, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. On the majority of systems these days, is it really an issue to cache man pages anymore? I mean, back when a long man page (thinking about some of the perl documentation for example) could take a while to render, it mattered. Now however, systems are much much faster, and we expect GUI web browsers to render vastly more complicated content in a fraction of a second. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? Hello, I would add some noteworthy information: * the man-db cron/timer script is taking care of man DB containing only the man page title and short description i.e., the first NAME section of the man page. This DB is speeding up the searching in mentioned section with the man -k command. It is not used for displaying man pages or doing the full text search with man -K command and it is not required for normal usage of man command (man -k should also work without this DB). * Debian is updating this DB via deb hooks (or how it is called) during package installation/update and via daily cron script for man pages installed outside of package manager. * updating this DB is usually pretty quick, but creation can take some time.. * man pages cache, pre-formatted man pages stored on disk in plain text, called cat pages in man-db context, is not used in Fedora. peter -- 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: [Test-Announce] Taskotron Has Replaced AutoQA
On Tue, 14 Oct 2014 21:10:26 +0200 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Oct 14, 2014 at 04:28:33AM -0400, Martin Krizek wrote: - Original Message - From: Vít Ondruch vondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, October 14, 2014 8:57:26 AM Subject: Re: [Test-Announce] Taskotron Has Replaced AutoQA You have not mentioned URL of Taskotron here nor the Wiki is updated to contain the link to the production version of Taskotron. Vít https://taskotron.fedoraproject.org/ This says Taskotron is in the very early stages of development with the objective to replace AutoQA for automating selected QA tasks in Fedora., which doesn't seem to be true anymore. Thanks for pointing that out, I'll get it updated soon (today if my freeze break request is approved). Also: taskotron-dev.fedoraproject.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. The certificate is only valid for taskotron-dev01.qa.fedoraproject.org That stems from two things: first is that the actual hostname of the machine responding to http requests doesn't match the public-facing hostname (this is true of almost all infra hosts). For the self-signed cert bit, as far as I know, most fedora app dev instances are using self-signed certs. It doesn't make a whole lot of sense to me to pay for a real SSL cert on a dev instance - especially when it would mean having individual certs on every dev instance (there's no central proxy for dev). Both stg and production are using proper SSL certs, though. Tim 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: Engineering Representiatve for the new Fedora Council
On Wed, Oct 15, 2014 at 10:48 AM, Bruno Wolff III br...@wolff.to wrote: On Wed, Oct 15, 2014 at 16:44:09 +0200, Haïkel hgue...@fedoraproject.org wrote: After consulting various people, I nominate Josh Boyer as a candidate. My concern is burning Josh out. He has taken on a lot of responsiblity in Fedora already. Thanks for the nomination and the concern. I'm fine with this if people think I'd be a good representative for them. 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: Engineering Representiatve for the new Fedora Council
On Mon, Oct 13, 2014 at 04:52:08PM +0200, Haïkel wrote: I'll be speaking in my own name: The Eng. Rep. is not necessarily a Fesco member but should be someone willing to collaborate regularly with them. She should have a fairly broad overview of Fedora Engineering and be an active contributor. The ideal candidate should be someone who has experience in the technical committees, and able to communicate effectively with various groups. You don't need to be a super contributor, but this is no role for a rookie as the time commitment will be important. About the selection, since it will take a lot of your time, I think that interested people should nominate themselves. Then, either fesco choose to hold an election or not is up to them. Though I have few names in mind, I won't disclose them before speaking with them. Some are obvious, the others may surprise you ;) Although I may not have all the deep technical knowledge of some FESCo members, I'd be willing to serve in this capacity. I do have experience working with different groups in Fedora, including the Board and FESCo, and release related groups like Rel-Eng, Docs, L10n, and Websites. I also manage the team in Red Hat that supports our infrastructure and applications. That could come in handy in helping the Council direct resources to work on the priorities needed for Fedora to succeed. However, I want to be clear that my being involved is *not* a pre-requisite for that support. I would expect to support Matthew and the Council regardless. I'm sure there are other worthy candidates, and I'd work with any of them who fill this role. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- 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: How to include fonts in Gnome Software?
On Wed, Oct 15, 2014 at 02:51:39PM +0100, Richard Hughes wrote: On 15 October 2014 09:06, Richard Hughes hughsi...@gmail.com wrote: I'm going to work on documenting the font requirements today; I'll follow up with a blog post and some new instructions :) Okay, this is the results of a day hacking: http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/ Feedback very welcome. If this looks reasonable, I'll top-post again to devel@fedora and the fonts mailing lists. Thanks. Hi, maybe you could include some more information how the font appdata files themselves should look, as opposed to the one-level-up metadata files. E.g. I looked at the schema at http://people.freedesktop.org/~hughsient/appdata/ and they don't seem to have the string font in them at all. Some more examples would be good too. Does [1] look OK? appdata-validate complains about missing screenshots, are those necessary for fonts' appdata? [1] http://pkgs.fedoraproject.org/cgit/unifont.git/tree/unifont.appdata.xml 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 -- 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: [Test-Announce] Taskotron Has Replaced AutoQA
On Wed, Oct 15, 2014 at 09:21:10AM -0400, Kamil Paral wrote: taskotron-dev.fedoraproject.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. The certificate is only valid for taskotron-dev01.qa.fedoraproject.org Tim needs to respond to that. https://taskotron-dev.fedoraproject.org/resultsdb Not Found The requested URL /resultsdb was not found on this server. I filed https://phab.qadevel.cloud.fedoraproject.org/T359 . Where did you come from? I fixed https://fedoraproject.org/wiki/Taskotron/Tasks . Yes, from there. Thanks, Zbyszek -- 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: How to include fonts in Gnome Software?
On 15 October 2014 16:38, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote:
maybe you could include some more information how the font appdata
files themselves should look, as opposed to the one-level-up metadata
files
Right, the examples I gave there are the actual files; that is the
post-0.6 AppStream version which only works with Fedora 20.
E.g. I looked at the schema at
http://people.freedesktop.org/~hughsient/appdata/
and they don't seem to have the string font in them at all.
Right, those are AppData files for applications, not MetaInfo files
for fonts and addons. When F20 is EOL I'll update that page to the new
metadata format.
Some more examples would be good too. Does [1] look OK?
appdata-validate complains about missing screenshots, are those necessary
for fonts' appdata?
Right; you need to use a metainfo file and a git version of
appstream-glib to validate those. I only wrote the code 6 hours ago :)
[1] http://pkgs.fedoraproject.org/cgit/unifont.git/tree/unifont.appdata.xml
Not appdata.xml, but metainfo.xml -- This is the patch I want to apply for lato:
diff --git a/lato-fonts.spec b/lato-fonts.spec
index 0eb3837..e0f1fa8 100644
--- a/lato-fonts.spec
+++ b/lato-fonts.spec
@@ -64,9 +64,30 @@ install -m 0755 -d
$RPM_BUILD_ROOT%{_fontconfig_templatedir} $RPM_BUILD_ROOT%{_f
install -m 0644 -p %{SOURCE1}
$RPM_BUILD_ROOT%{_fontconfig_templatedir}/%{fontconf}
ln -s %{_fontconfig_templatedir}/%{fontconf}
$RPM_BUILD_ROOT%{_fontconfig_confdir}/%{fontconf}
+# Add AppStream metadata
+mkdir -p $RPM_BUILD_ROOT%{_datadir}/appdata
+cat $RPM_BUILD_ROOT%{_datadir}/appdata/Lato.metainfo.xml EOF
+?xml version=1.0 encoding=UTF-8?
+!-- Copyright 2014 Richard Hughes rich...@hughsie.com --
+component type=font
+ idLato/id
+ metadata_licenseCC0-1.0/metadata_license
+ nameLato/name
+ summaryA classical sans-serif font family/summary
+ description
+p
+ The semi-rounded details of the letters give Lato a feeling of warmth,
+ while the strong structure provides stability and seriousness.
+/p
+ /description
+ updatecontactrichard_at_hughsie_dot_com/updatecontact
+ url type=homepagehttp://www.latofonts.com//url
+/component
+EOF
%_font_pkg -f %{fontconf} *.ttf
%doc Lato2OFL/{OFL.txt,README.txt}
+%{_datadir}/appdata/Lato.metainfo.xml
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
The Poodlebleed Bug
this site http://poodlebleed.com/ says that my server with F19 is vulnerable any news about this ? Thanks, -- Sérgio M. B. -- 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: man-db without cache update (no cron or systemd *.timer)
On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote: On 10/15/2014 04:47 PM, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. On the majority of systems these days, is it really an issue to cache man pages anymore? I mean, back when a long man page (thinking about some of the perl documentation for example) could take a while to render, it mattered. Now however, systems are much much faster, and we expect GUI web browsers to render vastly more complicated content in a fraction of a second. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? Hello, I would add some noteworthy information: * the man-db cron/timer script is taking care of man DB containing only the man page title and short description i.e., the first NAME section of the man page. This DB is speeding up the searching in mentioned section with the man -k command. It is not used for displaying man pages or doing the full text search with man -K command and it is not required for normal usage of man command (man -k should also work without this DB). * Debian is updating this DB via deb hooks (or how it is called) during package installation/update and via daily cron script for man pages installed outside of package manager. * updating this DB is usually pretty quick, but creation can take some time.. * man pages cache, pre-formatted man pages stored on disk in plain text, called cat pages in man-db context, is not used in Fedora. I don't think that adding an additional subpackage to be manually installed is worth the trouble. We should be making things simpler for administrators, not require more manual involvement. From Peters' description it seems it would be fine to simply ignore the timer and not have the cache if systemd is not running for whatever reason. So it would seem that ommitting systemd from the dependency list is the answer. But omitting systemd from the dependency list is not possible, because the dependency is necessary to order man-db after systemd in case of a normal installation of both in one transaction. After things calm down with F21, I'll return to the idea of splitting out systemd-filesystem (name subject to change) to allow packages which only need to enable a unit not to have a depenedency on full systemd stack (see the thread systemd dependencies from August for recent discussion). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New hardware for Retrace Server
Hi everybody, we have just replaced the old (and slow :)) host running Retrace Server and ABRT server with a new one. The most significant changes for users are: - Retracing now runs in memory, which means faster generating of backtraces (by an order of magnitude) - Reports from CentOS 7 are now accepted and cross-referenced with Fedora - ABRT Server now marks problems as probably fixed when a newer build exists and did not experience the problem in 14 days Some more features will probably be deployed soon - new webui, filtering of tainted reports and displaying user comments - stay tuned :). Please let us know in case anything does not work. Michal ABRT Team -- 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: The Poodlebleed Bug
On Wed, 2014-10-15 at 17:00 +0100, Sérgio Basto wrote: this site http://poodlebleed.com/ says that my server with F19 is vulnerable any news about this ? Disable SSL3? Who needs IE6 on XP? -- 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: The Poodlebleed Bug
On Wed, Oct 15, 2014 at 9:00 AM, Sérgio Basto ser...@serjux.com wrote: this site http://poodlebleed.com/ says that my server with F19 is vulnerable any news about this ? Poodlebleed? For Pete's sake. The attack is called POODLE, and it's much more likely to be an attack against a client instead of an attack against a server. That being said, if you aren't serving a web page that you need IE6 on XP to connect to, you can turn off SSLv3 to protect your clients. The setting varies depending on what server application you're using. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: New hardware for Retrace Server
On Wed, Oct 15, 2014 at 12:02 PM, Michal Toman mto...@redhat.com wrote: Some more features will probably be deployed soon - new webui, filtering of tainted reports and displaying user comments - stay tuned :). YAY. I'm really looking forward to the filtering changes :). 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: Engineering Representiatve for the new Fedora Council
2014-10-15 17:21 GMT+02:00 Paul W. Frields sticks...@gmail.com: Although I may not have all the deep technical knowledge of some FESCo members, I'd be willing to serve in this capacity. I do have experience working with different groups in Fedora, including the Board and FESCo, and release related groups like Rel-Eng, Docs, L10n, and Websites. Deep technical knowledge should not be a prerequisite for this role, fesco membership shouldn't either. I also manage the team in Red Hat that supports our infrastructure and applications. That could come in handy in helping the Council direct resources to work on the priorities needed for Fedora to succeed. However, I want to be clear that my being involved is *not* a pre-requisite for that support. I would expect to support Matthew and the Council regardless. I'm sure there are other worthy candidates, and I'd work with any of them who fill this role. I appreciate the gesture, and I expect that you will actively participate in the council, whoever is chosen for this seat :) H. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: man-db without cache update (no cron or systemd *.timer)
On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote: On 10/15/2014 04:47 PM, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. On the majority of systems these days, is it really an issue to cache man pages anymore? I mean, back when a long man page (thinking about some of the perl documentation for example) could take a while to render, it mattered. Now however, systems are much much faster, and we expect GUI web browsers to render vastly more complicated content in a fraction of a second. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? Hello, I would add some noteworthy information: * the man-db cron/timer script is taking care of man DB containing only the man page title and short description i.e., the first NAME section of the man page. This DB is speeding up the searching in mentioned section with the man -k command. It is not used for displaying man pages or doing the full text search with man -K command and it is not required for normal usage of man command (man -k should also work without this DB). * Debian is updating this DB via deb hooks (or how it is called) during package installation/update and via daily cron script for man pages installed outside of package manager. * updating this DB is usually pretty quick, but creation can take some time.. * man pages cache, pre-formatted man pages stored on disk in plain text, called cat pages in man-db context, is not used in Fedora. I don't think that adding an additional subpackage to be manually installed is worth the trouble. We should be making things simpler for administrators, not require more manual involvement. From Peters' description it seems it would be fine to simply ignore the timer and not have the cache if systemd is not running for whatever reason. So it would seem that ommitting systemd from the dependency list is the answer. But omitting systemd from the dependency list is not possible, because the dependency is necessary to order man-db after systemd in case of a normal installation of both in one transaction. After things calm down with F21, I'll return to the idea of splitting out systemd-filesystem (name subject to change) to allow packages which Or we may even move unitdir into the basic filesystem package - if the unitdir is the only requirement - which is probably the case for most of the daemons. It would probably be better than systemd-filesystem subpackage. Ondrej only need to enable a unit not to have a depenedency on full systemd stack (see the thread systemd dependencies from August for recent discussion). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Status Meeting - Cancelled - 2014-10-15
Good afternoon all, Sorry for the short notice, a number of team members won't be able to make the meeting today so let's cancel this week. Please assist by testing Fedora 21 Beta TC3[1] and add the results to the QA testing matrices[2]. If you have anything you would like to discuss in the interim, please send to the list. Paul [1] - https://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC3/ [2] - https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_TC3_Summary -- 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: man-db without cache update (no cron or systemd *.timer)
On 10/15/2014 05:36 PM, Ondrej Vasik wrote: On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote: On 10/15/2014 04:47 PM, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. On the majority of systems these days, is it really an issue to cache man pages anymore? I mean, back when a long man page (thinking about some of the perl documentation for example) could take a while to render, it mattered. Now however, systems are much much faster, and we expect GUI web browsers to render vastly more complicated content in a fraction of a second. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? Hello, I would add some noteworthy information: * the man-db cron/timer script is taking care of man DB containing only the man page title and short description i.e., the first NAME section of the man page. This DB is speeding up the searching in mentioned section with the man -k command. It is not used for displaying man pages or doing the full text search with man -K command and it is not required for normal usage of man command (man -k should also work without this DB). * Debian is updating this DB via deb hooks (or how it is called) during package installation/update and via daily cron script for man pages installed outside of package manager. * updating this DB is usually pretty quick, but creation can take some time.. * man pages cache, pre-formatted man pages stored on disk in plain text, called cat pages in man-db context, is not used in Fedora. I don't think that adding an additional subpackage to be manually installed is worth the trouble. We should be making things simpler for administrators, not require more manual involvement. From Peters' description it seems it would be fine to simply ignore the timer and not have the cache if systemd is not running for whatever reason. So it would seem that ommitting systemd from the dependency list is the answer. But omitting systemd from the dependency list is not possible, because the dependency is necessary to order man-db after systemd in case of a normal installation of both in one transaction. After things calm down with F21, I'll return to the idea of splitting out systemd-filesystem (name subject to change) to allow packages which Or we may even move unitdir into the basic filesystem package - if the unitdir is the only requirement - which is probably the case for most of the daemons. It would probably be better than systemd-filesystem subpackage. Ondrej mailto:pschi...@redhat.comsigh I discussed this with Peter Schiffer and the end result was in the future the man-db cron should be removed and man-db database should be updated with rpm triggerand the cron job should be kept as is until then, presicecly to prevent this from happening ( systemd being pulled in when it should not or component magically expecting it to be there ) and correct dependency on coreOS/baseOS components would be kept. Just make FESCO/FPC clean this up it was them who decided not to make it mandatory what should or should not be migrated to timer units and this is precisely the fallout I had expected from not doing that. Those individuals need to start accepting responsibility for the fallout from their decision making so as I said have them clean it up. JBG -- 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: man-db without cache update (no cron or systemd *.timer)
On Wed, Oct 15, 2014 at 07:36:49PM +0200, Ondrej Vasik wrote: On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote: On 10/15/2014 04:47 PM, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@redhat.com said: there has been a discussion about if we need cache for man-db for users which use man pages or update system only from time to time and thus don't need to update cache every day. man-db as it is now depends on systemd which brings another set of packages. The use case is I just want to read man page. So I install man which on the other hand download another set of packages. I want to read man page and it downloads systemd.. On the majority of systems these days, is it really an issue to cache man pages anymore? I mean, back when a long man page (thinking about some of the perl documentation for example) could take a while to render, it mattered. Now however, systems are much much faster, and we expect GUI web browsers to render vastly more complicated content in a fraction of a second. Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)? Hello, I would add some noteworthy information: * the man-db cron/timer script is taking care of man DB containing only the man page title and short description i.e., the first NAME section of the man page. This DB is speeding up the searching in mentioned section with the man -k command. It is not used for displaying man pages or doing the full text search with man -K command and it is not required for normal usage of man command (man -k should also work without this DB). * Debian is updating this DB via deb hooks (or how it is called) during package installation/update and via daily cron script for man pages installed outside of package manager. * updating this DB is usually pretty quick, but creation can take some time.. * man pages cache, pre-formatted man pages stored on disk in plain text, called cat pages in man-db context, is not used in Fedora. I don't think that adding an additional subpackage to be manually installed is worth the trouble. We should be making things simpler for administrators, not require more manual involvement. From Peters' description it seems it would be fine to simply ignore the timer and not have the cache if systemd is not running for whatever reason. So it would seem that ommitting systemd from the dependency list is the answer. But omitting systemd from the dependency list is not possible, because the dependency is necessary to order man-db after systemd in case of a normal installation of both in one transaction. After things calm down with F21, I'll return to the idea of splitting out systemd-filesystem (name subject to change) to allow packages which Or we may even move unitdir into the basic filesystem package - if the unitdir is the only requirement - which is probably the case for most of the daemons. It would probably be better than systemd-filesystem subpackage. This is not about the unit dir, but about the %post scripts: 'systemctl enable', 'systemctl preset', etc. (I don't think that the ownership of the directory is that important. Packaging rules, and all that, I know, but the truth is that both the location and format of systemd unit files is a stable upstream API, and cannot realistically change without significant upheaval. So I'd be totally fine with different packages co-owning the directory, except that this doesn't really solve anything.) Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)
=== #fedora-meeting: FESCO (2014-10-15) === Meeting started by nirik at 17:00:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-15/fesco.2014-10-15-17.00.log.html . Meeting summary --- * init process (nirik, 17:00:11) * #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline (nirik, 17:01:54) * LINK: https://fedorahosted.org/fesco/ticket/1322 (nirik, 17:01:54) * LINK: https://fedoraproject.org/wiki/Changes/jQuery no contingency; postpone (mitr, 17:04:31) * AGREED: postpone this change. (+6,0,0) (nirik, 17:05:49) * LINK: https://fedoraproject.org/wiki/Changes/FormatSecurity; ignore contingency (reverting the change), get someone to verify status (mitr, 17:06:18) * AGREED: bug 1078901 Format Security - done/approved, will ask for a status update on the bug (+6,0,0) (nirik, 17:10:38) * LINK: https://fedoraproject.org/wiki/Changes/u-boot_syslinux, contingency: “ make sure all supported boards work with arm-boot-config and use it as a fallback. ” (mitr, 17:11:11) * LINK: http://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms (mattdm, 17:36:39) * AGREED: 1078911 u-boot syslinux by default is blocking beta (+5,1,0) (nirik, 17:42:17) * LINK: https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork no contingency needed, no known progress, proposal: propose (mitr, 17:43:19) * AGREED: 1084102 PrivateDevices?=yes and PrivateNetwork?=yes For Long-Running Services is postponed (+6,0,0) (nirik, 17:46:04) * LINK: https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Images , no contingency needed (mitr, 17:46:25) * AGREED: 1091299 (A)Periodic Updates to Cloud Images - (+6,0,0) (nirik, 17:56:02) * LINK: https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint , no cintingency needed (mitr, 17:56:49) * change is ready for beta, no action needed. (nirik, 17:57:24) * LINK: https://fedoraproject.org/wiki/Changes/Web_Assets , no contingency needed. (mitr, 17:58:16) * AGREED: 998583 Web Assets - postpone to f22 (+6,0,0) (nirik, 18:00:19) * AGREED: atomic cloud work ongoing this week, still approved to land (+6,0,0) (nirik, 18:12:56) * will ping mariadb and mesos maintainers again since their changes seem done. (nirik, 18:14:22) * #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37) * LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38) * AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03) * #1355 Please select Engineering Representiatve for the new Fedora Council (nirik, 18:30:20) * LINK: https://fedorahosted.org/fesco/ticket/1355 (nirik, 18:30:21) * HELP: all this should be added to the fesco elections page or a council page or somewhere better than meeting minutes. (mattdm, 18:43:04) * AGREED: Draft of fedora council represenative selection process to be written up and ratified next week. (+5,0,0) (nirik, 18:46:11) * ACTION: dgilmore-bne to send out announcement of nomination period starting. (nirik, 18:48:57) * ACTION: jwb to write up draft of selection policy document for next week (nirik, 18:49:15) * Next week's chair (nirik, 18:49:21) * mattdm to chair next week. (nirik, 18:51:50) * Open Floor (nirik, 18:51:55) Meeting ended at 18:54:08 UTC. Action Items * dgilmore-bne to send out announcement of nomination period starting. * jwb to write up draft of selection policy document for next week Action Items, by person --- * dgilmore * dgilmore-bne to send out announcement of nomination period starting. * dgilmore-bne * dgilmore-bne to send out announcement of nomination period starting. * jwb * jwb to write up draft of selection policy document for next week * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (163) * mattdm (87) * dgilmore-bne (72) * jwb (66) * mitr (55) * kalev (30) * tflink (21) * adamw (17) * zodbot (17) * pjones (8) * halfie (3) * taquilla (1) * misc (1) * mmaslano (0) * sgallagh (0) * t8m (0) * thozza (0) * dgilmore (0) -- 17:00:11 nirik #startmeeting FESCO (2014-10-15) 17:00:11 zodbot Meeting started Wed Oct 15 17:00:11 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:11 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:11 nirik #meetingname fesco 17:00:11 nirik #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:11 nirik #topic init process 17:00:11 zodbot The meeting name has been set to 'fesco' 17:00:11 zodbot Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:16
Re: Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)
On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi ke...@scrye.com wrote: * #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37) * LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38) * AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03) That ticket has already been closed, so I will comment here. Say that I have a package that I want to update, the update breaks somebody else's package, and I lack the knowledge to fix that other package. How much waiting for the other maintainer am I required to undergo? The discussion on the ticket implies that the answer is an infinite amount of time. Is that really the intent? Let me present two cases where I think an infinite amount of time is the wrong answer. The first case is when a non-critpath package depends on a critpath package. I've got a concrete example. I maintain the polymake package. It has its hooks buried deeply into the guts of perl, so it depends on the exact perl version it was built with. Every major perl release, without fail, breaks polymake. Sometimes upstream has already noticed and I can update to the latest snapshot to fix the problem. Sometimes upstream has not noticed and I have to ask them to produce a fix, which can sometimes take a little while. If a critical perl update were needed, say to fix a glaring performance or security problem, and the update broke the polymake build, I think the right thing to do would be to push the perl update anyway. That will break things for me and both of the other people who use polymake (hi, guys!), but too bad for us. We can fix polymake as quickly as we can and get things back to normal, but we shouldn't block that update from going out to all of the people who need it. The second case is hypothetical, although it is loosely based on an actual situation I encountered a couple of years ago. Say that I want to push a non-backwards-compatible update to a library, and that packages A, B, and C depend on that library. I rebuild A and B successfully with the new version of the library, but C fails to rebuild. I try to diagnose the problem, but find that C is such a horrible mass of spaghetti that I can't make heads or tails out of it. So I file a bug against C and wait for the maintainer to respond. And wait. And wait. And wait. At what point am I allowed to push the new version of the library, along with A and B rebuilds, and write C off as a loss, since I can't fix it and the maintainer isn't responding? Does it depend on the severity of the problem the update is intended to fix? If so, who is the judge of degree of severity? -- Jerry James http://www.jamezone.org/ -- 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: Review swap
On Mon, Oct 13, 2014 at 11:42 AM, Jerry James loganje...@gmail.com wrote: One of my packages has picked up a dependency on libpuma in a new release: https://bugzilla.redhat.com/show_bug.cgi?id=1135654 Would someone care to do a review swap? Thanks, I've had some helpful comments on the bug, but no takers for a review yet. Would someone care to swap with me? Give me a hard one. I probably deserve it. -- Jerry James http://www.jamezone.org/ -- 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-10-15 at 17UTC)
On Wed, 15 Oct 2014 13:32:50 -0600 Jerry James loganje...@gmail.com wrote: On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi ke...@scrye.com wrote: * #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37) * LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38) * AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03) That ticket has already been closed, so I will comment here. Say that I have a package that I want to update, the update breaks somebody else's package, and I lack the knowledge to fix that other package. How much waiting for the other maintainer am I required to undergo? Speaking for myself, A reasonable amount of time. There are going to be cases where you can't push all interdependent packages at the same time. You should try and avoid that, but it could well happen. This is one of the reasons we were talking about taskotron and enforcement. There MUST be a way to override any auto enforcement for at least: * I know this one thing is broken, but it's vastly less important than fixing all these others. * The test is wrong/broken/bugged. 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
Schedule for Thursday's FPC Meeting (2014-10-16 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-10-16 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-10-16 09:00 Thu US/Pacific PDT 2014-10-16 12:00 Thu US/Eastern EDT 2014-10-16 16:00 Thu UTC - 2014-10-16 17:00 Thu Europe/London BST 2014-10-16 18:00 Thu Europe/Paris CEST 2014-10-16 18:00 Thu Europe/Berlin CEST 2014-10-16 21:30 Thu Asia/Calcutta IST --new day-- 2014-10-17 00:00 Fri Asia/Singapore SGT 2014-10-17 00:00 Fri Asia/Hong_Kong HKT 2014-10-17 01:00 Fri Asia/Tokyo JST 2014-10-17 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 (more info. needed, PHP now complies) #topic #452 Crypto policies packaging guideline .fpc 452 https://fedorahosted.org/fpc/ticket/452 (more info. needed) #topic #454 Bundling exception for php-phpoffice-phpexcel .fpc 454 https://fedorahosted.org/fpc/ticket/454 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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-10-15 at 17UTC)
On 10/15/2014 09:32 PM, Jerry James wrote: On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi ke...@scrye.com wrote: * #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37) * LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38) * AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03) That ticket has already been closed, so I will comment here. Say that I have a package that I want to update, the update breaks somebody else's package, and I lack the knowledge to fix that other package. How much waiting for the other maintainer am I required to undergo? The discussion on the ticket implies that the answer is an infinite amount of time. Is that really the intent? Let me present two cases where I think an infinite amount of time is the wrong answer. One thing that might not have been clear when reading the FESCo discussion is that this only applies to the releases where Bodhi is enabled -- the stable releases (F19, F20) and Branched (F21). It does _not_ apply to rawhide. The first case is when a non-critpath package depends on a critpath package. I've got a concrete example. I maintain the polymake package. It has its hooks buried deeply into the guts of perl, so it depends on the exact perl version it was built with. Every major perl release, without fail, breaks polymake. Sometimes upstream has already noticed and I can update to the latest snapshot to fix the problem. Sometimes upstream has not noticed and I have to ask them to produce a fix, which can sometimes take a little while. If a critical perl update were needed, say to fix a glaring performance or security problem, and the update broke the polymake build, I think the right thing to do would be to push the perl update anyway. That will break things for me and both of the other people who use polymake (hi, guys!), but too bad for us. We can fix polymake as quickly as we can and get things back to normal, but we shouldn't block that update from going out to all of the people who need it. We shouldn't get a perl rebase in a a stable Fedora release anyway. Major Perl rebases are always System Wide Changes and land in rawhide before the next release is branched. The second case is hypothetical, although it is loosely based on an actual situation I encountered a couple of years ago. Say that I want to push a non-backwards-compatible update to a library, and that packages A, B, and C depend on that library. I rebuild A and B successfully with the new version of the library, but C fails to rebuild. I try to diagnose the problem, but find that C is such a horrible mass of spaghetti that I can't make heads or tails out of it. So I file a bug against C and wait for the maintainer to respond. And wait. And wait. And wait. At what point am I allowed to push the new version of the library, along with A and B rebuilds, and write C off as a loss, since I can't fix it and the maintainer isn't responding? Does it depend on the severity of the problem the update is intended to fix? If so, who is the judge of degree of severity? Pushing out ABI incompatible library versions in a stable Fedora release isn't something one should do anyway. They should either go in the next Fedora (rawhide), or if it's important to backport the ABI change to the current stable release, it's best to introduce a parallel-installable package for the new library. If an ABI change cannot be avoided, it's possible to ask for a FESCo exception: http://fedoraproject.org/wiki/Updates_Policy#Exceptions -- Hope this clears things up, 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: Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)
On Wed, Oct 15, 2014 at 09:54:23PM +0200, Kalev Lember wrote: One thing that might not have been clear when reading the FESCo discussion is that this only applies to the releases where Bodhi is enabled -- the stable releases (F19, F20) and Branched (F21). It does _not_ apply to rawhide. Yes. But also worth noting that _eventually_ I think we want to get to some point where there are gate checks to rawhide, or at least for some subset of what is currently rawhide. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: New hardware for Retrace Server
On 10/15/2014 06:02 PM, Michal Toman wrote: Hi everybody, we have just replaced the old (and slow :)) host running Retrace Server and ABRT server with a new one. The most significant changes for users are: - Retracing now runs in memory, which means faster generating of backtraces (by an order of magnitude) - Reports from CentOS 7 are now accepted and cross-referenced with Fedora - ABRT Server now marks problems as probably fixed when a newer build exists and did not experience the problem in 14 days Some more features will probably be deployed soon - new webui, filtering of tainted reports and displaying user comments - stay tuned :). NICE! I am really excited to hear about this. The retrace server with its web UI is seriously awesome and helps prioritise bugs to work on and find crashers that a lot of people hit. Thanks for working on this! -- 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: bugzilla usage trends
On Fri, 2014-10-10 at 11:12 +0100, Richard W.M. Jones wrote: On Thu, Oct 09, 2014 at 05:39:34PM -0400, Przemek Klosowski wrote: I was curious about the rate of bug reporting in Fedora, and did this quick experiment. I thought it might be interesting to folks here who either work on the infrastructure or are curious about long-term collaboration trends in Fedora. I checked the date of reporting of every 10,000th bug (bugzilla #1, #1, etc, all the way to the recent 115---see attached data). Some bugs were private so I didn't have access to their info, but I got enough data to calculate bug velocity (increase in the bug number divided by the time interval) over time. The data is a little noisy, but you can clearly see the ever-increasing trend. I'm afraid there are a couple of problems with this analysis: - Automated bugs (eg from abrt) may or may not be considered to be real bug reports. ~35% bugs are from ABRT : https://jfilak.fedorapeople.org/media/abrt_bz_stats.txt Regards, Jakub -- 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: New hardware for Retrace Server
On 10/15/2014 10:02 AM, Michal Toman wrote: Hi everybody, we have just replaced the old (and slow :)) host running Retrace Server and ABRT server with a new one. The most significant changes for users are: - Retracing now runs in memory, which means faster generating of backtraces (by an order of magnitude) - Reports from CentOS 7 are now accepted and cross-referenced with Fedora - ABRT Server now marks problems as probably fixed when a newer build exists and did not experience the problem in 14 days Some more features will probably be deployed soon - new webui, filtering of tainted reports and displaying user comments - stay tuned :). Please let us know in case anything does not work. Michal ABRT Team We used to have the ability to get statistics grouped by packager, right, or am I mis-remembering? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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: New hardware for Retrace Server
On Wed, 2014-10-15 at 16:55 -0600, Orion Poplawski wrote: We used to have the ability to get statistics grouped by packager, right, or am I mis-remembering? We still have it, but you can filter by packager only on 'Problems' page: https://retrace.fedoraproject.org/faf/problems/hot/*/265/*/ Or are you missing something else? Regards, Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Path-Tiny-0.059.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Path-Tiny: 885c26b9758e1b767d72d58cb42f268f Path-Tiny-0.059.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-Path-Tiny] Update to 0.059
commit 1c318234a348fb87e4019c0b78a49b6898e0d71f
Author: Paul Howarth p...@city-fan.org
Date: Wed Oct 15 09:19:39 2014 +0100
Update to 0.059
- New upstream release 0.059
- Fixed precedence bug in the check for Unicode::UTF8
perl-Path-Tiny.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Path-Tiny.spec b/perl-Path-Tiny.spec
index c1927f9..bfff0f0 100644
--- a/perl-Path-Tiny.spec
+++ b/perl-Path-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-Path-Tiny
-Version: 0.058
+Version: 0.059
Release: 1%{?dist}
Summary: File path utility
Group: Development/Libraries
@@ -99,6 +99,10 @@ make test
%{_mandir}/man3/Path::Tiny.3pm*
%changelog
+* Tue Oct 14 2014 Paul Howarth p...@city-fan.org - 0.059-1
+- Update to 0.059
+ - Fixed precedence bug in the check for Unicode::UTF8
+
* Thu Sep 25 2014 Paul Howarth p...@city-fan.org - 0.058-1
- Update to 0.058
- Added a 'sibling' method as a more efficient form of calling
diff --git a/sources b/sources
index acf7794..b3e4cc5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f271c1a0b44b6d4081f84bda05500d91 Path-Tiny-0.058.tar.gz
+885c26b9758e1b767d72d58cb42f268f Path-Tiny-0.059.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-Path-Tiny/f21] Update to 0.059
Summary of changes: 1c31823... Update to 0.059 (*) (*) 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
[perl-Path-Tiny/epel7] Update to 0.059
Summary of changes: 1c31823... Update to 0.059 (*) (*) 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
[perl-Path-Tiny] Created tag perl-Path-Tiny-0.059-1.fc22
The lightweight tag 'perl-Path-Tiny-0.059-1.fc22' was created pointing to: 1c31823... Update to 0.059 -- 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-Path-Tiny] Created tag perl-Path-Tiny-0.059-1.el7
The lightweight tag 'perl-Path-Tiny-0.059-1.el7' was created pointing to: 1c31823... Update to 0.059 -- 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-Path-Tiny] Created tag perl-Path-Tiny-0.059-1.fc21
The lightweight tag 'perl-Path-Tiny-0.059-1.fc21' was created pointing to: 1c31823... Update to 0.059 -- 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 Pod-Readme-v1.0.2.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Pod-Readme: 0210c4985b8760e6f9d39b229aeba756 Pod-Readme-v1.0.2.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-Pod-Readme] Update to 1.0.2
commit a3de0878b46535e084c4f2c8367eeaf7fbea2061
Author: Paul Howarth p...@city-fan.org
Date: Wed Oct 15 11:19:13 2014 +0100
Update to 1.0.2
- New upstream release 1.0.2
- This is a complete rewrite, using modern Perl with Moo
- Added support for plugins, along with plugins to insert the module
version,
prerequisites and the latest changes
- Added the ability to generate a README in a variety of formats, such as
POD, Markdown, HTML, RTF, etc.
- Added command-line options to the pod2readme script, including the
ability
to specify the output format
- Switched to semantic versioning
- The documentation has been updated accordingly
- This is no longer a subclass of a POD parser, although it has some
wrapper
methods for compatibility with software known to use it
- This release by RRWO → update source URL
- Modernize spec since this version will never run on EL-5
- Unbundle the Module::Install stuff and use the system version instead
.gitignore |4 +-
Pod-Readme-v1.0.2-no-author-deps.patch | 26 ++
perl-Pod-Readme.spec | 133 +++-
sources|2 +-
4 files changed, 125 insertions(+), 40 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 75d85ba..7f0249c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,2 @@
-Pod-Readme-0.09.tar.gz
-/Pod-Readme-0.11.tar.gz
+/Pod-Readme-[0-9.]*.tar.gz
+/Pod-Readme-v[0-9.]*.tar.gz
diff --git a/Pod-Readme-v1.0.2-no-author-deps.patch
b/Pod-Readme-v1.0.2-no-author-deps.patch
new file mode 100644
index 000..0871a27
--- /dev/null
+++ b/Pod-Readme-v1.0.2-no-author-deps.patch
@@ -0,0 +1,26 @@
+--- Makefile.PL
Makefile.PL
+@@ -74,23 +74,6 @@
+
+ install_script(qw{ bin/pod2readme });
+
+-author_requires(
+-'Module::Install::AuthorRequires' = 0.02,
+-'Module::Install::AuthorTests'= 0,
+-'Test::CPAN::Meta'= 0,
+-'Test::CheckManifest' = 0.9,
+-'Test::CleanNamespaces' = 0,
+-'Test::Command' = 0,
+-'Test::ConsistentVersion' = 0,
+-'Test::MinimumVersion'= 0,
+-'Test::Perl::Critic' = 0,
+-'Test::Pod' = '1.00',
+-'Test::Pod::Coverage' = 0,
+-'Test::Portability::Files'= 0,
+-);
+-
+-recursive_author_tests('xt');
+-
+ install_as_cpan;
+ auto_install;
+ WriteAll;
diff --git a/perl-Pod-Readme.spec b/perl-Pod-Readme.spec
index ac14a2b..5bdebcf 100644
--- a/perl-Pod-Readme.spec
+++ b/perl-Pod-Readme.spec
@@ -1,59 +1,118 @@
-%define module_version 0.11
-
Name: perl-Pod-Readme
-Version:0.110
-Release:11%{?dist}
-Summary:Convert POD to README file
+Version:1.0.2
+Release:1%{?dist}
+Summary:Intelligently generate a README file from POD
License:GPL+ or Artistic
-Group: Development/Libraries
URL:http://search.cpan.org/dist/Pod-Readme/
-Source0:
http://www.cpan.org/authors/id/B/BI/BIGPRESH/Pod-Readme-%{module_version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/R/RR/RRWO/Pod-Readme-v%{version}.tar.gz
+Patch0: Pod-Readme-v1.0.2-no-author-deps.patch
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Regexp::Common)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod) = 1.00
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Test::Portability::Files)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Module Build
+BuildRequires: perl = 4:5.10.1
+BuildRequires: perl(inc::Module::Install)
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(Class::Method::Modifiers)
+BuildRequires: perl(CPAN::Changes) = 0.30
+BuildRequires: perl(CPAN::Meta)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.56
+BuildRequires: perl(feature)
+BuildRequires: perl(File::Slurp)
+BuildRequires: perl(Hash::Util)
+BuildRequires: perl(IO)
+BuildRequires: perl(List::Util) = 1.33
+BuildRequires: perl(Module::CoreList)
+BuildRequires: perl(Module::Load)
+BuildRequires: perl(Moo) = 1.004005
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(MooX::HandlesVia)
+BuildRequires: perl(namespace::autoclean)
+BuildRequires: perl(Path::Tiny) = 0.018
+BuildRequires: perl(Role::Tiny)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
+BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(Type::Tiny)
+BuildRequires: perl(Types::Standard)
+BuildRequires: perl(version) = 0.77
+BuildRequires: perl(warnings)
+# Script Runtime
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(Getopt::Long::Descriptive)
+BuildRequires: perl(IO::Handle)
+# Test Suite
[perl-Pod-Readme] Created tag perl-Pod-Readme-1.0.2-1.fc22
The lightweight tag 'perl-Pod-Readme-1.0.2-1.fc22' was created pointing to: a3de087... Update to 1.0.2 -- 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-Qt
perl-Qt has broken dependencies in the rawhide tree: On x86_64: perl-Qt-0.96.0-11.fc22.x86_64 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.x86_64 requires libperl.so.5.18()(64bit) On i386: perl-Qt-0.96.0-11.fc22.i686 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.i686 requires libperl.so.5.18 On armhfp: perl-Qt-0.96.0-11.fc22.armv7hl requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.armv7hl requires libperl.so.5.18 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 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #6 from Petr Pisar ppi...@redhat.com --- You are right that the patch is wrong. The only slnames that need a correction are the LGPL's. I think more appropriate place for a dependency on Software::License is Module::Build rather then Module::Starter. -- 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=C3OPMWr0Nba=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 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #8 from Richard Poole r...@guests.deus.net --- Module::Build is used at module install time, so a dependency on Software::License would effectively bring Software::License into any working perl development setup, whereas a dependency on Module::Starter only brings it in for people writing their own modules. Of course it makes no difference to me but in general it may be considered a bloat issue: there are probably many many more installations of Module::Build than of Module::Starter . -- 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=4iLwfkgjdxa=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 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #9 from Petr Pisar ppi...@redhat.com --- (In reply to Paul Howarth from comment #7) (In reply to Petr Pisar from comment #6) You are right that the patch is wrong. The only slnames that need a correction are the LGPL's. I think more appropriate place for a dependency on Software::License is Module::Build rather then Module::Starter. That's what I thought too but it might introduce bootstrapping issues, with the bootstrap Module::Build not having the dependency and the dual-lived one subsequently introducing it. I'm aware of it. I will put the dependency into not bootstrapping condition. -- 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=pA9Mbi7jx3a=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 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #10 from Petr Pisar ppi...@redhat.com --- (In reply to Richard Poole from comment #8) Module::Build is used at module install time, so a dependency on Software::License would effectively bring Software::License into any working perl development setup, whereas a dependency on Module::Starter only brings it in for people writing their own modules. Of course it makes no difference to me but in general it may be considered a bloat issue: there are probably many many more installations of Module::Build than of Module::Starter . The issue is Module::Build::API explicitly allows Software::License identifiers, so one can run into not working Build.PL event without Module::Starter. -- 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=Lr4tb2BHsKa=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
[perl-Module-Starter] Produce valid Software::License identifiers
commit 3921fbd064916483ce96be1e26a7d4773128ea4f
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 13:12:25 2014 +0200
Produce valid Software::License identifiers
...tware-License-s-identifiers-for-LGPL-lice.patch | 61 +
...e-slnames-to-match-CPAN-Meta-Spec-case-se.patch | 278
...nse-types-for-the-non-standard-licenses-C.patch | 62 -
perl-Module-Starter.spec | 19 +-
4 files changed, 71 insertions(+), 349 deletions(-)
---
diff --git
a/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
new file mode 100644
index 000..7a7fafa
--- /dev/null
+++
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
@@ -0,0 +1,61 @@
+From ef492d5d6468d02b22fb53d4dc64d8409a669937 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Wed, 15 Oct 2014 12:37:54 +0200
+Subject: [PATCH] Correct Software::License's identifiers for LGPL licenses
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ lib/Module/Starter/Simple.pm | 4 ++--
+ t/test-dist.t| 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/lib/Module/Starter/Simple.pm b/lib/Module/Starter/Simple.pm
+index 63e248f..6d650c0 100644
+--- a/lib/Module/Starter/Simple.pm
b/lib/Module/Starter/Simple.pm
+@@ -485,7 +485,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -525,7 +525,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+diff --git a/t/test-dist.t b/t/test-dist.t
+index 8814112..b3a9885 100644
+--- a/t/test-dist.t
b/t/test-dist.t
+@@ -364,7 +364,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -404,7 +404,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+--
+1.9.3
+
diff --git a/perl-Module-Starter.spec b/perl-Module-Starter.spec
index c28cab6..3ebc9b3 100644
--- a/perl-Module-Starter.spec
+++ b/perl-Module-Starter.spec
@@ -1,21 +1,18 @@
Name: perl-Module-Starter
Epoch: 1
Version:1.62
-Release:4%{?dist}
+Release:5%{?dist}
Summary:A simple starter kit for any module
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Module-Starter
Source0:
http://search.cpan.org/CPAN/authors/id/X/XS/XSAWYERX/Module-Starter-%{version}.tar.gz
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch0:
Module-Starter-1.62-Edit-License-slnames-to-match-CPAN-Meta-Spec-case-se.patch
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch1:
Module-Starter-1.62-Update-license-types-for-the-non-standard-licenses-C.patch
+# Produce valid Software::License identifiers, bug #1152319,
+# https://github.com/xsawyerx/module-starter/pull/21
+Patch0:
Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
# Document the default license is artistic2, CPAN RT#86557,
# https://github.com/xsawyerx/module-starter/issues/1
-Patch2: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
+Patch1: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -62,7 +59,6 @@ perl-Module-Starter-PBP for the aforementioned templates.)
%setup -q -n Module-Starter-%{version}
%patch0 -p1
%patch1 -p1
-%patch2 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -84,6 +80,11 @@ make test
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 1:1.62-5
+- Revert the previous license identifiers patches which broke
+ Software::License
+- Produce valid Software::License identifiers (bug #1152319)
+
* Tue Oct 14 2014 Petr Pisar ppi...@redhat.com - 1:1.62-4
- Produce valid license
[perl-Module-Starter/f21] Produce valid Software::License identifiers
commit 408cd5068452def118cfeeed31ef2be8904a734e
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 13:12:25 2014 +0200
Produce valid Software::License identifiers
...tware-License-s-identifiers-for-LGPL-lice.patch | 61 +
...e-slnames-to-match-CPAN-Meta-Spec-case-se.patch | 278
...nse-types-for-the-non-standard-licenses-C.patch | 62 -
perl-Module-Starter.spec | 19 +-
4 files changed, 71 insertions(+), 349 deletions(-)
---
diff --git
a/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
new file mode 100644
index 000..7a7fafa
--- /dev/null
+++
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
@@ -0,0 +1,61 @@
+From ef492d5d6468d02b22fb53d4dc64d8409a669937 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Wed, 15 Oct 2014 12:37:54 +0200
+Subject: [PATCH] Correct Software::License's identifiers for LGPL licenses
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ lib/Module/Starter/Simple.pm | 4 ++--
+ t/test-dist.t| 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/lib/Module/Starter/Simple.pm b/lib/Module/Starter/Simple.pm
+index 63e248f..6d650c0 100644
+--- a/lib/Module/Starter/Simple.pm
b/lib/Module/Starter/Simple.pm
+@@ -485,7 +485,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -525,7 +525,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+diff --git a/t/test-dist.t b/t/test-dist.t
+index 8814112..b3a9885 100644
+--- a/t/test-dist.t
b/t/test-dist.t
+@@ -364,7 +364,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -404,7 +404,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+--
+1.9.3
+
diff --git a/perl-Module-Starter.spec b/perl-Module-Starter.spec
index 6b89dd2..16f5d1b 100644
--- a/perl-Module-Starter.spec
+++ b/perl-Module-Starter.spec
@@ -1,21 +1,18 @@
Name: perl-Module-Starter
Epoch: 1
Version:1.62
-Release:3%{?dist}
+Release:4%{?dist}
Summary:A simple starter kit for any module
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Module-Starter
Source0:
http://search.cpan.org/CPAN/authors/id/X/XS/XSAWYERX/Module-Starter-%{version}.tar.gz
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch0:
Module-Starter-1.62-Edit-License-slnames-to-match-CPAN-Meta-Spec-case-se.patch
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch1:
Module-Starter-1.62-Update-license-types-for-the-non-standard-licenses-C.patch
+# Produce valid Software::License identifiers, bug #1152319,
+# https://github.com/xsawyerx/module-starter/pull/21
+Patch0:
Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
# Document the default license is artistic2, CPAN RT#86557,
# https://github.com/xsawyerx/module-starter/issues/1
-Patch2: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
+Patch1: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -62,7 +59,6 @@ perl-Module-Starter-PBP for the aforementioned templates.)
%setup -q -n Module-Starter-%{version}
%patch0 -p1
%patch1 -p1
-%patch2 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -84,6 +80,11 @@ make test
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 1:1.62-4
+- Revert the previous license identifiers patches which broke
+ Software::License
+- Produce valid Software::License identifiers (bug #1152319)
+
* Tue Oct 14 2014 Petr Pisar ppi...@redhat.com - 1:1.62-3
- Produce valid license
[perl-Module-Starter/f20] Produce valid Software::License identifiers
commit ff72ae2ef13789f0f00bdcd30c43f595a1aa2b4e
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 13:12:25 2014 +0200
Produce valid Software::License identifiers
...tware-License-s-identifiers-for-LGPL-lice.patch | 61 +
...e-slnames-to-match-CPAN-Meta-Spec-case-se.patch | 278
...nse-types-for-the-non-standard-licenses-C.patch | 62 -
perl-Module-Starter.spec | 19 +-
4 files changed, 71 insertions(+), 349 deletions(-)
---
diff --git
a/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
new file mode 100644
index 000..7a7fafa
--- /dev/null
+++
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
@@ -0,0 +1,61 @@
+From ef492d5d6468d02b22fb53d4dc64d8409a669937 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Wed, 15 Oct 2014 12:37:54 +0200
+Subject: [PATCH] Correct Software::License's identifiers for LGPL licenses
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ lib/Module/Starter/Simple.pm | 4 ++--
+ t/test-dist.t| 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/lib/Module/Starter/Simple.pm b/lib/Module/Starter/Simple.pm
+index 63e248f..6d650c0 100644
+--- a/lib/Module/Starter/Simple.pm
b/lib/Module/Starter/Simple.pm
+@@ -485,7 +485,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -525,7 +525,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+diff --git a/t/test-dist.t b/t/test-dist.t
+index 8814112..b3a9885 100644
+--- a/t/test-dist.t
b/t/test-dist.t
+@@ -364,7 +364,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -404,7 +404,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+--
+1.9.3
+
diff --git a/perl-Module-Starter.spec b/perl-Module-Starter.spec
index b02fffa..c19c5dd 100644
--- a/perl-Module-Starter.spec
+++ b/perl-Module-Starter.spec
@@ -1,21 +1,18 @@
Name: perl-Module-Starter
Epoch: 1
Version:1.62
-Release:2%{?dist}
+Release:3%{?dist}
Summary:A simple starter kit for any module
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Module-Starter
Source0:
http://search.cpan.org/CPAN/authors/id/X/XS/XSAWYERX/Module-Starter-%{version}.tar.gz
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch0:
Module-Starter-1.62-Edit-License-slnames-to-match-CPAN-Meta-Spec-case-se.patch
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch1:
Module-Starter-1.62-Update-license-types-for-the-non-standard-licenses-C.patch
+# Produce valid Software::License identifiers, bug #1152319,
+# https://github.com/xsawyerx/module-starter/pull/21
+Patch0:
Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
# Document the default license is artistic2, CPAN RT#86557,
# https://github.com/xsawyerx/module-starter/issues/1
-Patch2: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
+Patch1: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -62,7 +59,6 @@ perl-Module-Starter-PBP for the aforementioned templates.)
%setup -q -n Module-Starter-%{version}
%patch0 -p1
%patch1 -p1
-%patch2 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -84,6 +80,11 @@ make test
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 1:1.62-3
+- Revert the previous license identifiers patches which broke
+ Software::License
+- Produce valid Software::License identifiers (bug #1152319)
+
* Tue Oct 14 2014 Petr Pisar ppi...@redhat.com - 1:1.62-2
- Produce valid license
[perl-Module-Starter/f19] Produce valid Software::License identifiers
commit 44268e8d6cd41a7238294d411d3b52e023fa39f2
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 13:12:25 2014 +0200
Produce valid Software::License identifiers
...tware-License-s-identifiers-for-LGPL-lice.patch | 61 +
...e-slnames-to-match-CPAN-Meta-Spec-case-se.patch | 278
...nse-types-for-the-non-standard-licenses-C.patch | 62 -
perl-Module-Starter.spec | 19 +-
4 files changed, 71 insertions(+), 349 deletions(-)
---
diff --git
a/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
new file mode 100644
index 000..7a7fafa
--- /dev/null
+++
b/Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
@@ -0,0 +1,61 @@
+From ef492d5d6468d02b22fb53d4dc64d8409a669937 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Wed, 15 Oct 2014 12:37:54 +0200
+Subject: [PATCH] Correct Software::License's identifiers for LGPL licenses
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ lib/Module/Starter/Simple.pm | 4 ++--
+ t/test-dist.t| 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/lib/Module/Starter/Simple.pm b/lib/Module/Starter/Simple.pm
+index 63e248f..6d650c0 100644
+--- a/lib/Module/Starter/Simple.pm
b/lib/Module/Starter/Simple.pm
+@@ -485,7 +485,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -525,7 +525,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+diff --git a/t/test-dist.t b/t/test-dist.t
+index 8814112..b3a9885 100644
+--- a/t/test-dist.t
b/t/test-dist.t
+@@ -364,7 +364,7 @@ EOT
+ },
+ lgpl = {
+ license = 'lgpl',
+-slname = 'LGPL_2',
++slname = 'LGPL_2_1',
+ url = 'http://www.gnu.org/licenses/lgpl-2.1.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+@@ -404,7 +404,7 @@ EOT
+ },
+ lgpl3 = {
+ license = 'lgpl3',
+-slname = 'LGPL_3',
++slname = 'LGPL_3_0',
+ url = 'http://www.gnu.org/licenses/lgpl-3.0.html',
+ blurb = 'EOT',
+ This program is free software; you can redistribute it and/or
+--
+1.9.3
+
diff --git a/perl-Module-Starter.spec b/perl-Module-Starter.spec
index 618ef01..73fdc7e 100644
--- a/perl-Module-Starter.spec
+++ b/perl-Module-Starter.spec
@@ -1,21 +1,18 @@
Name: perl-Module-Starter
Epoch: 1
Version:1.62
-Release:2%{?dist}
+Release:3%{?dist}
Summary:A simple starter kit for any module
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Module-Starter
Source0:
http://search.cpan.org/CPAN/authors/id/X/XS/XSAWYERX/Module-Starter-%{version}.tar.gz
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch0:
Module-Starter-1.62-Edit-License-slnames-to-match-CPAN-Meta-Spec-case-se.patch
-# Produce valid license identifiers, bug #1152319,
-# https://github.com/xsawyerx/module-starter/pull/21, accepted after 1.62
-Patch1:
Module-Starter-1.62-Update-license-types-for-the-non-standard-licenses-C.patch
+# Produce valid Software::License identifiers, bug #1152319,
+# https://github.com/xsawyerx/module-starter/pull/21
+Patch0:
Module-Starter-1.62-Correct-Software-License-s-identifiers-for-LGPL-lice.patch
# Document the default license is artistic2, CPAN RT#86557,
# https://github.com/xsawyerx/module-starter/issues/1
-Patch2: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
+Patch1: Module-Starter-1.62-doc-Default-license-is-artistic2.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -62,7 +59,6 @@ perl-Module-Starter-PBP for the aforementioned templates.)
%setup -q -n Module-Starter-%{version}
%patch0 -p1
%patch1 -p1
-%patch2 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -84,6 +80,11 @@ make test
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 1:1.62-3
+- Revert the previous license identifiers patches which broke
+ Software::License
+- Produce valid Software::License identifiers (bug #1152319)
+
* Tue Oct 14 2014 Petr Pisar ppi...@redhat.com - 1:1.62-2
- Produce valid license
[Bug 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Fixed In Version|perl-Module-Starter-1.62-4. |perl-Module-Starter-1.62-5. |fc22|fc22 -- 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=39eNSvfDqDa=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 1152816] Second Extruder Motor Gain Very Low
https://bugzilla.redhat.com/show_bug.cgi?id=1152816 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added CC||cgf...@gmail.com Flags||needinfo?(cgf...@gmail.com) --- Comment #3 from Miro Hrončok mhron...@redhat.com --- Thanks for reporting. However your report is quite confusing for me. Could you please provide: * 3D model to slice (i.e. the amf file) * slic3r configuration (in inf file) that you have used And describe a way how to tell if the gcode result is OK or not (e.g. telling me that the first G1 command after T1 has a low F value or something like that). In that case I would be able to recognize if I can reproduce it with slic3r 1.0.1 and slic3r 1.1.7 - and if the situation is the same as you describe (i.e. it is wrong in 1.0.1 and good in 1.1.7), I might be able to locate when the issue was fixed and if possible backport the fix to Fedora 20. -- 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=MZo561E9Nua=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 1152816] Second Extruder Motor Gain Very Low
https://bugzilla.redhat.com/show_bug.cgi?id=1152816 --- Comment #4 from Miro Hrončok mhron...@redhat.com --- in inf file I meant in ini file -- 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=UtyV0iudrFa=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 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #11 from Petr Pisar ppi...@redhat.com --- Module::Build does not die on Software::License identifier if the Software::License is not available since 0.4208-2-gf75aa88: commit f75aa882772d6ebe3b18e27076b1bb124f91cec1 Author: Leon Timmermans faw...@gmail.com Date: Wed Aug 27 22:11:45 2014 +0200 Use CPAN::Meta::Merge for meta_merge It puts 'unknown' license into the MYMETA. However I still think having Software::License is better than loosing the license name. -- 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=AitoFdE9xxa=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
[perl-Module-Build] Require Software::License to recognize more license identifiers
commit 57bc2492c27b9e38305963a3980f3a08183ca2b4
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 14:45:07 2014 +0200
Require Software::License to recognize more license identifiers
perl-Module-Build.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 83eff26..4d73085 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -5,7 +5,7 @@
Name: perl-Module-Build
Epoch: 2
Version:
%{cpan_version_major}%{?cpan_version_minor:.%cpan_version_minor}
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Build and install Perl modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -82,6 +82,11 @@ Requires: perl(Module::Metadata) = 1.02
# Keep PAR support optional (PAR::Dist)
Requires: perl(Perl::OSType) = 1
Requires: perl(Test::Harness)
+%if !%{defined perl_bootstrap}
+# Optional run-time needed for Software::License license identifier,
+# bug #1152319
+Requires: perl(Software::License)
+%endif
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
Requires: perl(Pod::Man) = 2.17
@@ -133,6 +138,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 2:0.42.10-2
+- Require Software::License to recognize more license identifiers (bug
#1152319)
+
* Wed Sep 10 2014 Jitka Plesnikova jples...@redhat.com - 2:0.42.10-1
- 0.4210 bump
--
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-Build/f21] Require Software::License to recognize more license identifiers
commit 0f7620404fcd36445b9c195310bb383c859d8d68
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 14:45:07 2014 +0200
Require Software::License to recognize more license identifiers
perl-Module-Build.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index dda69a6..3918c89 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -5,7 +5,7 @@
Name: perl-Module-Build
Epoch: 2
Version:
%{cpan_version_major}%{?cpan_version_minor:.%cpan_version_minor}
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Build and install Perl modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -79,6 +79,11 @@ Requires: perl(Module::Metadata) = 1.02
# Keep PAR support optional (PAR::Dist)
Requires: perl(Perl::OSType) = 1
Requires: perl(Test::Harness)
+%if !%{defined perl_bootstrap}
+# Optional run-time needed for Software::License license identifier,
+# bug #1152319
+Requires: perl(Software::License)
+%endif
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
Requires: perl(Pod::Man) = 2.17
@@ -130,6 +135,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 2:0.42.06-2
+- Require Software::License to recognize more license identifiers (bug
#1152319)
+
* Wed Jul 16 2014 Jitka Plesnikova jples...@redhat.com - 0.42.06-1
- 0.4206 bump
--
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-Build/f20] Require Software::License to recognize more license identifiers
commit 2ef76b5c5df5474877b843f2c4aff732322920fd
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 14:45:07 2014 +0200
Require Software::License to recognize more license identifiers
perl-Module-Build.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 5f235c8..d98e0e6 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -5,7 +5,7 @@
Name: perl-Module-Build
Epoch: 2
Version:
%{cpan_version_major}%{?cpan_version_minor:.%cpan_version_minor}
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Build and install Perl modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -79,6 +79,11 @@ Requires: perl(Module::Metadata) = 1.02
# Keep PAR support optional (PAR::Dist)
Requires: perl(Perl::OSType) = 1
Requires: perl(Test::Harness)
+%if !%{defined perl_bootstrap}
+# Optional run-time needed for Software::License license identifier,
+# bug #1152319
+Requires: perl(Software::License)
+%endif
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
Requires: perl(Pod::Man) = 2.17
@@ -123,6 +128,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 2:0.40.07-4
+- Require Software::License to recognize more license identifiers (bug
#1152319)
+
* Wed Aug 14 2013 Jitka Plesnikova jples...@redhat.com - 2:0.40.07-3
- Perl 5.18 re-rebuild of bootstrapped packages
--
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-Build/f19] Require Software::License to recognize more license identifiers
commit 705d663b2c18d695458d1aec2b689afbe75acccb
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 14:45:07 2014 +0200
Require Software::License to recognize more license identifiers
perl-Module-Build.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 05e0c11..903402d 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -5,7 +5,7 @@
Name: perl-Module-Build
Epoch: 2
Version:
%{cpan_version_major}%{?cpan_version_minor:.%cpan_version_minor}
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Build and install Perl modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -75,6 +75,11 @@ Requires: perl(Module::Metadata) = 1.02
# Keep PAR support optional (PAR::Dist)
Requires: perl(Perl::OSType) = 1
Requires: perl(Test::Harness)
+%if !%{defined perl_bootstrap}
+# Optional run-time needed for Software::License license identifier,
+# bug #1152319
+Requires: perl(Software::License)
+%endif
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
Requires: perl(Pod::Man)
@@ -119,6 +124,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Wed Oct 15 2014 Petr Pisar ppi...@redhat.com - 2:0.40.04-2
+- Require Software::License to recognize more license identifiers (bug
#1152319)
+
* Wed Apr 03 2013 Petr Šabata con...@redhat.com - 2:0.40.04-1
- 0.4004 bump
--
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] Require Software::License at perl-Module-Build
commit 3f95d39ec42bfe2effbd501af8ae6261028ab0ee
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 15 15:12:00 2014 +0200
Require Software::License at perl-Module-Build
perl.spec |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 21dd39c..a841852 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1167,6 +1167,11 @@ Requires: perl(ExtUtils::CBuilder) = 0.15
Requires: perl(ExtUtils::ParseXS) = 1.02
Requires: perl-devel
Requires: %perl_compat
+%if !%{defined perl_bootstrap}
+# Optional run-time needed for Software::License license identifier,
+# bug #1152319
+Requires: perl(Software::License)
+%endif
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
Requires: perl(Pod::Man)
--
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 1152319] perl-Module-Starter produces invalid license identifiers
https://bugzilla.redhat.com/show_bug.cgi?id=1152319 --- Comment #12 from Paul Howarth p...@city-fan.org --- (In reply to Petr Pisar from comment #9) (In reply to Paul Howarth from comment #7) (In reply to Petr Pisar from comment #6) You are right that the patch is wrong. The only slnames that need a correction are the LGPL's. I think more appropriate place for a dependency on Software::License is Module::Build rather then Module::Starter. That's what I thought too but it might introduce bootstrapping issues, with the bootstrap Module::Build not having the dependency and the dual-lived one subsequently introducing it. I'm aware of it. I will put the dependency into not bootstrapping condition. If you do that, are you then going to post-bootstrap rebuild every package that pulled in Module::Build during the bootstrap process, to make sure it still builds OK with Software::License in the buildroot? Adding bootstrap-dependent Requires (as opposed to bootstrap-dependent RuildRequires) has a much bigger impact in terms of post-bootstrap rebuilds I think. -- 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=EMr3NF8Gija=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 1153134] New: FTBFS: No longer works with the current Lingua::EN::Numbers
https://bugzilla.redhat.com/show_bug.cgi?id=1153134 Bug ID: 1153134 Summary: FTBFS: No longer works with the current Lingua::EN::Numbers Product: Fedora Version: rawhide Component: perl-Lingua-EN-Numbers-Easy Assignee: mhron...@redhat.com Reporter: psab...@redhat.com QA Contact: extras...@fedoraproject.org CC: mhron...@redhat.com, perl-devel@lists.fedoraproject.org Description of problem: Lingua::EN::Numbers 2.00 dropped support for the legacy OO interface which this module still uses. Version-Release number of selected component (if applicable): perl-Lingua-EN-Numbers-Easy-2009110701-8.fc22 How reproducible: Always Steps to Reproduce: 1. Try to build or use the package in any way Actual results: It's totally borked. Expected results: It works. Additional info: I think replacing ($n = Lingua::EN::Numbers- new)-parse($value) with num2en($value) should do the trick. However, I haven't tested this. -- 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=PVsXncKAGKa=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 JSON-MaybeXS-1.002005.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-JSON-MaybeXS: 87d68022483b34cade8b957b3a4d4240 JSON-MaybeXS-1.002005.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-JSON-MaybeXS] Update to 1.002005
commit d2ba6415f5516592eb032d3f6f8567f9f45333f5
Author: Paul Howarth p...@city-fan.org
Date: Wed Oct 15 18:10:14 2014 +0100
Update to 1.002005
- New upstream release 1.002005
- Fix can I haz XS? logic precedence in Makefile.PL
- Added the ':all' export tag
- Removed dependency on Safe::Isa
- Repository moved to git://git.shadowcat.co.uk/p5sagit/JSON-MaybeXS.git
perl-JSON-MaybeXS.spec | 11 +--
sources|2 +-
2 files changed, 10 insertions(+), 3 deletions(-)
---
diff --git a/perl-JSON-MaybeXS.spec b/perl-JSON-MaybeXS.spec
index 060a9f0..6852de5 100644
--- a/perl-JSON-MaybeXS.spec
+++ b/perl-JSON-MaybeXS.spec
@@ -8,7 +8,7 @@
Name: perl-JSON-MaybeXS
Summary: Use Cpanel::JSON::XS with a fallback to JSON::XS and JSON::PP
-Version: 1.002004
+Version: 1.002005
Release: 1%{?dist}
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/JSON-MaybeXS/
@@ -24,7 +24,7 @@ BuildRequires:perl(File::Temp)
BuildRequires: perl(base)
BuildRequires: perl(Cpanel::JSON::XS) = 2.3310
BuildRequires: perl(Exporter)
-BuildRequires: perl(Safe::Isa)
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Test Suite (wants JSON::PP ≥ 2.27202 really but EL-6 doesn't have that)
@@ -72,6 +72,13 @@ make test
%{_mandir}/man3/JSON::MaybeXS.3*
%changelog
+* Wed Oct 15 2014 Paul Howarth p...@city-fan.org - 1.002005-1
+- Update to 1.002005
+ - Fix can I haz XS? logic precedence in Makefile.PL
+ - Added the ':all' export tag
+ - Removed dependency on Safe::Isa
+ - Repository moved to git://git.shadowcat.co.uk/p5sagit/JSON-MaybeXS.git
+
* Sun Oct 12 2014 Paul Howarth p...@city-fan.org - 1.002004-1
- Update to 1.002004
- Support use of PUREPERL_ONLY in Makefile.PL to avoid adding an XS
diff --git a/sources b/sources
index e082b86..aafc3e3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c4cd707f8712fce7a95640edcf22fd08 JSON-MaybeXS-1.002004.tar.gz
+87d68022483b34cade8b957b3a4d4240 JSON-MaybeXS-1.002005.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-JSON-MaybeXS/f21] Update to 1.002005
Summary of changes: d2ba641... Update to 1.002005 (*) (*) 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
[perl-JSON-MaybeXS] Created tag perl-JSON-MaybeXS-1.002005-1.fc22
The lightweight tag 'perl-JSON-MaybeXS-1.002005-1.fc22' was created pointing to: d2ba641... Update to 1.002005 -- 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-JSON-MaybeXS] Created tag perl-JSON-MaybeXS-1.002005-1.fc21
The lightweight tag 'perl-JSON-MaybeXS-1.002005-1.fc21' was created pointing to: d2ba641... Update to 1.002005 -- 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 1139700] CVE-2014-4330 perl-Data-Dumper: deep recursion stack overflow
https://bugzilla.redhat.com/show_bug.cgi?id=1139700 Vincent Danen vda...@redhat.com changed: What|Removed |Added Whiteboard|impact=low,public=20140918, |impact=low,public=20140918, |reported=20140909,source=up |reported=20140909,source=up |stream,cvss2=1.2/AV:L/AC:H/ |stream,cvss2=1.2/AV:L/AC:H/ |Au:N/C:N/I:N/A:P,rhel-4/per |Au:N/C:N/I:N/A:P,rhel-4/per |l=new,rhel-5/perl=new,rhel- |l=wontfix,rhel-5/perl=wontf |6/perl=new,rhel-7/perl=nota |ix,rhel-6/perl=new,rhel-7/p |ffected,fedora-all/perl=not |erl=notaffected,fedora-all/ |affected,rhel-7/perl-Data-D |perl=notaffected,rhel-7/per |umper=affected,rhscl-1/perl |l-Data-Dumper=affected,rhsc |516-perl-Data-Dumper=affect |l-1/perl516-perl-Data-Dumpe |ed,fedora-all/perl-Data-Dum |r=affected,fedora-all/perl- |per=affected|Data-Dumper=affected --- Comment #15 from Vincent Danen vda...@redhat.com --- Statement: This issue affects the versions of perl as shipped with Red Hat Enterprise Linux 6 and 7. A future update may address this issue. Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/. -- 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=Bbs719pIlVa=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 1150523] perl-List-AllUtils-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1150523 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-List-AllUtils-0.09-1.f |perl-List-AllUtils-0.09-1.f |c22 |c21 Resolution|--- |ERRATA Last Closed||2014-10-15 21:57:00 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-List-AllUtils-0.09-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. -- 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=1G4Hp3R3WWa=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 1150533] perl-Test-Strict-0.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1150533 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Test-Strict-0.24-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. -- 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=kc7PNmSAIoa=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 1152101] perl-MooX-Options-4.012 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1152101 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-MooX-Options-4.012-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-MooX-Options-4.012-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12830/perl-MooX-Options-4.012-1.fc20 then log in and leave karma (feedback). -- 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=K0UGTMqdWna=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 1150529] perl-POE-Test-Loops-1.359 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1150529 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-POE-Test-Loops-1.359-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. -- 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=riPeOPQxB9a=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
[389-devel] Please review: [389 Project] #47553: Enhance ACIs to have more control over MODRDN operations
https://fedorahosted.org/389/ticket/47553 https://fedorahosted.org/389/attachment/ticket/47553/0001-Ticket-47553-Enhance-ACIs-to-have-more-control-over-.2.patch git patch file (master) -- aci: add the SLAPI_ACL_MODDN bit to SLAPI_ACL_ALL. Comment: Description: Macro SLAPI_ACL_ALL does not contain SLAPI_ACL_MODDN. Thus, even though all operations are allowed by allow (all), just modrdn fails with Insufficient access (50). -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
