EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 531 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 45 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5 21 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11667/xpdf-3.03-8.el5.1 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11749/zabbix20-2.0.8-3.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing log4c-1.2.4-1.el5 Details about builds: log4c-1.2.4-1.el5 (FEDORA-EPEL-2013-11756) Library for logging application messages Update Information: This release provides new layouts using local time and various maintenance work and improvements. Public API functions with format strings are marked by GNU C format attribute. ChangeLog: * Thu Oct 3 2013 František Dvořák val...@civ.zcu.cz - 1.2.4-1 - Release log4c 1.2.4 * Sun Jul 28 2013 Ville Skyttä ville.sky...@iki.fi - 1.2.3-2 - Simplify install of docs. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Source file audit - 2013-09-30
Hi, Looks like working fedorahosted download links got reported as BADURL. Parag -- 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: Source file audit - 2013-09-30
Check ok on my side: $ wget http://linux.dell.com/dkms/permalink/dkms-2.2.0.3.tar.gz --2013-10-04 08:54:36-- http://linux.dell.com/dkms/permalink/dkms-2.2.0.3.tar.gz Resolving linux.dell.com (linux.dell.com)... 143.166.224.62 Connecting to linux.dell.com (linux.dell.com)|143.166.224.62|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 86053 (84K) [application/x-gzip] Saving to: ‘dkms-2.2.0.3.tar.gz’ 100%[==] 86,053 96.3KB/s in 0.9s 2013-10-04 08:54:42 (96.3 KB/s) - ‘dkms-2.2.0.3.tar.gz’ saved [86053/86053] Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.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: Source file audit - 2013-09-30
drago01:BADURL:inotify-tools-3.14.tar.gz:inotify-tools Thats because upstream no longer offer a 3.14 download. Dunno why. -- 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: Source file audit - 2013-09-30
On 10/03/2013 11:35 PM, Kevin Fenzi wrote: [cut] leamas:BADURL:xlwt-0.7.4.tar.gz:python-xlwt [cut] These are pypi urls which looks just fine to me (spectool -g works OK) --alec -- 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: Fedora Working Groups: Call for Self-Nominations
On 10/03/2013 05:42 PM, Mateusz Marzantowicz wrote: On 11.09.2013 21:31, Matthew Miller wrote: Introduction Based on discussions at and around Flock, the Fedora Project Board has approved a proposal for a big change in the way we put Fedora together. Rather than presenting one Fedora with multiple slightly-different install options, future Fedora will be designed, developed, and promoted as three separate products built around a common core. To take that idea from talk to reality, we're making a corresponding change to Fedora leadership. Each product will be guided by a Working Group, which will function as an independent subcommittee of FESCo, (the Fedora Engineering Steering Committee). FESCo will resolve issues which impact multiple working groups, and the Fedora Board will continue to set overall strategic direction, but the working groups will be largely autonomous within their own areas. The Groups -- We are creating a group for each of the three initial products the Board has approved: * Fedora Workstation * Fedora Server * Fedora Cloud What about Fedora Embedded? Do you plan to drop ARM support on Fedora? I can't match small credit card size devices with either Workstation, Server or Cloud group. Is this group list fixed or could be extended and on what basis? Mateusz Marzantowicz We just started to support ARM, I don't think we want to drop it. I guess those three products are currently most important and other products like Embedded should go into Spins category. At least for now. Marcela -- 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: Source file audit - 2013-09-30
Il 03/10/2013 23:35, Kevin Fenzi ha scritto: Here's attached another run of my sources/patches url checker. Please fix any packages you are responsible for in rawhide, and other branches as other changes permit. hi gil:BADURL:iText-src-2.1.7.tar.gz:itext thats because upstream no longer offer a 2.1.7 download. gil:BADURL:jdo2-api-2.2-src.tar.gz:jdo2-api fixed gil:BADURL:plexus-3.3.1.tar.gz:plexus-pom gil:BADURL:spock-0.7-groovy-1.8.tar.gz:spock gil:BADURL:2.9.0.tar.gz:spymemcached check ok on my side: [gil@localhost ~]$ wget https://github.com/sonatype/plexus-pom/archive/plexus-3.3.1.tar.gz --2013-10-04 11:32:21-- https://github.com/sonatype/plexus-pom/archive/plexus-3.3.1.tar.gz Risoluzione di github.com (github.com)... 192.30.252.131 Connessione a github.com (github.com)|192.30.252.131|:443... connesso. Richiesta HTTP inviata, in attesa di risposta... 302 Found Posizione: https://codeload.github.com/sonatype/plexus-pom/tar.gz/plexus-3.3.1 [segue] --2013-10-04 11:32:22-- https://codeload.github.com/sonatype/plexus-pom/tar.gz/plexus-3.3.1 Risoluzione di codeload.github.com (codeload.github.com)... 192.30.252.145 Connessione a codeload.github.com (codeload.github.com)|192.30.252.145|:443... connesso. Richiesta HTTP inviata, in attesa di risposta... 200 OK Lunghezza: non specificato [application/x-gzip] Salvataggio in: plexus-3.3.1.tar.gz [ = ] 4.596 --.-K/s in 0s 2013-10-04 11:32:23 (181 MB/s) - plexus-3.3.1.tar.gz salvato [4596] [gil@localhost ~]$ wget https://github.com/spockframework/spock/archive/spock-0.7-groovy-1.8.tar.gz --2013-10-04 11:34:24-- https://github.com/spockframework/spock/archive/spock-0.7-groovy-1.8.tar.gz Risoluzione di github.com (github.com)... 192.30.252.130 Connessione a github.com (github.com)|192.30.252.130|:443... connesso. Richiesta HTTP inviata, in attesa di risposta... 302 Found Posizione: https://codeload.github.com/spockframework/spock/tar.gz/spock-0.7-groovy-1.8 [segue] --2013-10-04 11:34:25-- https://codeload.github.com/spockframework/spock/tar.gz/spock-0.7-groovy-1.8 Risoluzione di codeload.github.com (codeload.github.com)... 192.30.252.145 Connessione a codeload.github.com (codeload.github.com)|192.30.252.145|:443... connesso. Richiesta HTTP inviata, in attesa di risposta... 200 OK Lunghezza: non specificato [application/x-gzip] Salvataggio in: spock-0.7-groovy-1.8.tar.gz [ = ] 338.692 261KB/s in 1,3s 2013-10-04 11:34:28 (261 KB/s) - spock-0.7-groovy-1.8.tar.gz salvato [338692] [gil@localhost ~]$ wget https://github.com/dustin/java-memcached-client/archive/2.9.0.tar.gz --2013-10-04 11:35:46-- https://github.com/dustin/java-memcached-client/archive/2.9.0.tar.gz Risoluzione di github.com (github.com)... 192.30.252.129 Connessione a github.com (github.com)|192.30.252.129|:443... connesso. Richiesta HTTP inviata, in attesa di risposta... 302 Found Posizione: https://codeload.github.com/dustin/java-memcached-client/tar.gz/2.9.0 [segue] --2013-10-04 11:35:47-- https://codeload.github.com/dustin/java-memcached-client/tar.gz/2.9.0 Risoluzione di codeload.github.com (codeload.github.com)... 192.30.252.147 Connessione a codeload.github.com (codeload.github.com)|192.30.252.147|:443... connesso. Richiesta HTTP inviata, in attesa di risposta... 200 OK Lunghezza: non specificato [application/x-gzip] Salvataggio in: 2.9.0.tar.gz [ = ] 428.571 271KB/s in 1,5s 2013-10-04 11:35:49 (271 KB/s) - 2.9.0.tar.gz salvato [428571] regards gil attachment: puntogil.vcf-- 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 File-Sync-0.11.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-File-Sync: 8bb0966ff3458699c02fde3d5c799824 File-Sync-0.11.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Source file audit - 2013-09-30
Hi, In my case, the makeself source tarball is hosted on github. I've seen many people saying that github was down recently (even though it worked fine for me). curl -LI http://github.com/megastep/makeself/archive/release-2.2.0.tar.gz [... redirections stuff ...] HTTP/1.1 200 OK [... headers ...] Other packages might be related to the github outage. Regards, Dridi On Fri, Oct 4, 2013 at 9:15 AM, Alec Leamas leamas.a...@gmail.com wrote: On 10/03/2013 11:35 PM, Kevin Fenzi wrote: [cut] leamas:BADURL:xlwt-0.7.4.tar.gz:python-xlwt [cut] These are pypi urls which looks just fine to me (spectool -g works OK) --alec -- 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: Source file audit - 2013-09-30
On 10/04/2013 11:49 AM, Dridi Boukelmoune wrote: Hi, In my case, the makeself source tarball is hosted on github. I've seen many people saying that github was down recently (even though it worked fine for me). It was down for about two hours: https://status.github.com/messages -- Petr³ -- 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: Source file audit - 2013-09-30
On Thu, Oct 03, 2013 at 03:35:03PM -0600, Kevin Fenzi wrote: Here's attached another run of my sources/patches url checker. Please fix any packages you are responsible for in rawhide, and other Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). ttorcz:BADURL:hdapsd-20090401gita64b50c-a64b50c.tar.gz:hdapsd But is seem to have been downloaded fine... http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/hdapsd-dl.txt -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- 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: Source file audit - 2013-09-30
On Thu, Oct 03, 2013 at 03:35:03PM -0600, Kevin Fenzi wrote: raorn:BADSOURCE:wmMatrix-0.2-g97216606.tar.gz:wmMatrix raorn:BADSOURCE:wmmon-1.0b2-g575778a6.tar.gz:wmmon raorn:BADSOURCE:wmpager-1.2-g88ece7e5.tar.gz:wmpager Source tag is a link to repo.or.cz. Timestamps are changed each time archive is downloaded. There are no release tarballs for dockapps repository. raorn:BADURL:wmvolman-2.0.1.tar.gz:wmvolman $ HEAD -S http://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz HEAD http://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz 301 Moved Permanently HEAD https://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz 302 Found HEAD https://codeload.github.com/raorn/wmvolman/tar.gz/2.0.1 200 OK Connection: close Date: Fri, 04 Oct 2013 10:56:50 GMT Content-Length: 39940 Content-Type: application/x-gzip Client-Date: Fri, 04 Oct 2013 10:56:50 GMT Client-Peer: 192.30.252.145:443 Client-Response-Num: 1 Client-SSL-Cert-Issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.github.com Client-SSL-Cipher: RC4-SHA Client-SSL-Socket-Class: IO::Socket::SSL Content-Disposition: attachment; filename=wmvolman-2.0.1.tar.gz There was several redirects, but URL is OK. And it doesn't have the timestamp problem. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital 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: Source file audit - 2013-09-30
On Fri, Oct 04, 2013 at 02:59:36PM +0400, Alexey I. Froloff wrote: $ HEAD -S http://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz Content-Type: application/x-gzip Content-Disposition: attachment; filename=wmvolman-2.0.1.tar.gz --2013-10-03 05:54:40-- http://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz ... Length: unspecified [application/x-gzip] Saving to: `./2.0.1' 0K .. .. .. . 676K=0.06s Last-modified header missing -- time-stamps turned off. 2013-10-03 05:54:42 (676 KB/s) - `./2.0.1' saved [39940] What tool were you using for download? -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital 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: Source file audit - 2013-09-30
Kevin Fenzi wrote: On Fri, 4 Oct 2013 01:54:34 +0200 Björn Persson bj...@xn--rombobjrn-67a.se wrote: Kevin Fenzi wrote: rombobeorn:BADURL:pragmarc-20130728.zip:PragmARC wget https://www.Rombobjörn.se/PragmARC/pragmarc-20130728.zip → 200 OK This server's uptime is currently 112 days, so either it was a network glitch or your URL checker lacks IDNA support. Seems to be a dns issue? http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/PragmARC-dl.txt That's a more useful error message. Wget tried to look up the UTF-8-encoded domain name directly without converting it to ACE. You need to upgrade Wget to a version that knows how to do IDNA. The one in Fedora 19 does. The one in CentOS 6 doesn't. -- Björn Persson Sent from my computer. 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: Fedora Working Groups: Call for Self-Nominations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2013 04:31 AM, Marcela Mašláňová wrote: On 10/03/2013 05:42 PM, Mateusz Marzantowicz wrote: On 11.09.2013 21:31, Matthew Miller wrote: Introduction Based on discussions at and around Flock, the Fedora Project Board has approved a proposal for a big change in the way we put Fedora together. Rather than presenting one Fedora with multiple slightly-different install options, future Fedora will be designed, developed, and promoted as three separate products built around a common core. To take that idea from talk to reality, we're making a corresponding change to Fedora leadership. Each product will be guided by a Working Group, which will function as an independent subcommittee of FESCo, (the Fedora Engineering Steering Committee). FESCo will resolve issues which impact multiple working groups, and the Fedora Board will continue to set overall strategic direction, but the working groups will be largely autonomous within their own areas. The Groups -- We are creating a group for each of the three initial products the Board has approved: * Fedora Workstation * Fedora Server * Fedora Cloud What about Fedora Embedded? Do you plan to drop ARM support on Fedora? I can't match small credit card size devices with either Workstation, Server or Cloud group. Is this group list fixed or could be extended and on what basis? Mateusz Marzantowicz We just started to support ARM, I don't think we want to drop it. I guess those three products are currently most important and other products like Embedded should go into Spins category. At least for now. Yes, we're probably not going to be offering a direct embedded product right from the get-go. However, the Fedora ARM project will definitely have a place in the Server and Cloud variants, as several hardware manufacturers have been announcing ARM-based servers. We certainly don't want to suggest that ARM-based hobby projects like Pidora will be going away. ARM folks are encouraged to work on the Base Design functionality so we can meet their needs in the core OS and then we'll be providing tools similar to the current Spins to allow them to continue building their own installable images. The main change being made here is with how we are presenting *The Fedora Project* to the world. In the past, we've tried to be all things to all people, but going forward we want to pick a few specific areas that we will focus on (and market) particularly. The wide world of Fedora software and packages will always be there. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJOqzUACgkQeiVVYja6o6PUMACeKC8S2P3ezJMt9a1Xb3F286sR FFAAnAgDs+pjG9kdhAspJ/4L1Y36EmEC =RKvq -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131004 changes
Compose started at Fri Oct 4 09:15:02 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-4.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [fawkes] fawkes-doc-0.5.0-9.fc20.noarch requires fawkes = 0:0.5.0-9.fc20 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glusterfs] glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift = 0:1.8.0 [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.2-11.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.2-11.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-MooseX-TrackDirty-Attributes] perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [player] player-3.0.2-32.fc20.armv7hl requires libstatgrab.so.9 player-3.0.2-32.fc20.armv7hl requires libgeos-3.3.8.so [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-basemap] python-basemap-1.0.6-4.fc20.armv7hl requires libgeos-3.3.8.so [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [rubygem-audited-activerecord]
Review swap: python-jsmin, python-cssmin
Hi, anyone willing to review or swap reviews? https://bugzilla.redhat.com/show_bug.cgi?id=1014607 https://bugzilla.redhat.com/show_bug.cgi?id=1014601 Thanks! Martin -- 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: Fedora Working Groups: Call for Self-Nominations
On 10/04/2013 02:49 PM, Stephen Gallagher wrote: What about Fedora Embedded? Do you plan to drop ARM support on Fedora? I can't match small credit card size devices with either Workstation, Server or Cloud group. Is this group list fixed or could be extended and on what basis? Mateusz Marzantowicz We just started to support ARM, I don't think we want to drop it. I guess those three products are currently most important and other products like Embedded should go into Spins category. At least for now. Yes, we're probably not going to be offering a direct embedded product right from the get-go. However, the Fedora ARM project will definitely have a place in the Server and Cloud variants, as several hardware manufacturers have been announcing ARM-based servers. Also remember that ARM are not only for smell devices: http://goo.gl/qpDzy -- +261 34 81 738 69 -- 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: python-jsmin, python-cssmin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2013 07:57 AM, Martin Krizek wrote: Hi, anyone willing to review or swap reviews? https://bugzilla.redhat.com/show_bug.cgi?id=1014607 https://bugzilla.redhat.com/show_bug.cgi?id=1014601 Thanks! Martin Has JSMin finally changed to an acceptable license? It's got a long history of including a line The Software shall be used for Good, not Evil. which makes the license unenforceable and unsuitable for inclusion in Fedora. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJOta4ACgkQeiVVYja6o6MNlgCgg9HhrfMX9xuMjU6pnV3ptA0+ wKkAn247tK9UiqmLyX5xUAfPq4o9ZeCa =Y1cL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap: python-jsmin, python-cssmin
- Original Message - From: Stephen Gallagher sgall...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Martin Krizek mkri...@redhat.com Sent: Friday, October 4, 2013 2:33:50 PM Subject: Re: Review swap: python-jsmin, python-cssmin -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2013 07:57 AM, Martin Krizek wrote: Hi, anyone willing to review or swap reviews? https://bugzilla.redhat.com/show_bug.cgi?id=1014607 https://bugzilla.redhat.com/show_bug.cgi?id=1014601 Thanks! Martin Has JSMin finally changed to an acceptable license? It's got a long history of including a line The Software shall be used for Good, not Evil. which makes the license unenforceable and unsuitable for inclusion in Fedora. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJOta4ACgkQeiVVYja6o6MNlgCgg9HhrfMX9xuMjU6pnV3ptA0+ wKkAn247tK9UiqmLyX5xUAfPq4o9ZeCa =Y1cL -END PGP SIGNATURE- It's MIT. Martin -- 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: Fedora Working Groups: Call for Self-Nominations
On Fri, Oct 4, 2013 at 8:30 AM, Mihamina RKTMB miham...@rktmb.org wrote: On 10/04/2013 02:49 PM, Stephen Gallagher wrote: What about Fedora Embedded? Do you plan to drop ARM support on Fedora? I can't match small credit card size devices with either Workstation, Server or Cloud group. Is this group list fixed or could be extended and on what basis? Mateusz Marzantowicz We just started to support ARM, I don't think we want to drop it. I guess those three products are currently most important and other products like Embedded should go into Spins category. At least for now. Yes, we're probably not going to be offering a direct embedded product right from the get-go. However, the Fedora ARM project will definitely have a place in the Server and Cloud variants, as several hardware manufacturers have been announcing ARM-based servers. Also remember that ARM are not only for smell devices: http://goo.gl/qpDzy That article is almost 2 years old, and an ARM based HP Moonshot server is still not available. While the intent of your message is certainly true, you might do better by picking a better example like the Calxeda ARM servers. Fedora is already using those as the builders in koji. 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
Rawhide buildroot broken?
I'm seeing this in root.log for all Rawhide builds:
DEBUG util.py:316: Executing command: ['fedpkg', 'sources'] with env
{'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot', 'HOME':
'/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:266: Traceback (most recent call last):
DEBUG util.py:266:File /usr/bin/fedpkg, line 13, in module
DEBUG util.py:266: from fedpkg.__main__ import main
DEBUG util.py:266:File
/usr/lib/python2.7/site-packages/fedpkg/__init__.py, line 12, in module
DEBUG util.py:266: import pyrpkg
DEBUG util.py:266:File
/usr/lib/python2.7/site-packages/pyrpkg/__init__.py, line 17, in module
DEBUG util.py:266: import pycurl
DEBUG util.py:266: ImportError: /lib64/libkrb5.so.3: symbol
keyctl_get_persistent, version KEYUTILS_1.4 not defined in file
libkeyutils.so.1 with link time reference
DEBUG util.py:356: Child return code was: 1
f20 builds don't seem to be affected.
Paul.
--
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: Rawhide buildroot broken?
I'm seeing this too.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6024388
-J
On Fri, Oct 4, 2013 at 8:22 AM, Paul Howarth p...@city-fan.org wrote:
I'm seeing this in root.log for all Rawhide builds:
DEBUG util.py:316: Executing command: ['fedpkg', 'sources'] with env
{'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot', 'HOME': '/builddir',
'PATH': '/usr/bin:/bin:/usr/sbin:/**sbin'}
DEBUG util.py:266: Traceback (most recent call last):
DEBUG util.py:266:File /usr/bin/fedpkg, line 13, in module
DEBUG util.py:266: from fedpkg.__main__ import main
DEBUG util.py:266:File
/usr/lib/python2.7/site-**packages/fedpkg/__init__.py,
line 12, in module
DEBUG util.py:266: import pyrpkg
DEBUG util.py:266:File
/usr/lib/python2.7/site-**packages/pyrpkg/__init__.py,
line 17, in module
DEBUG util.py:266: import pycurl
DEBUG util.py:266: ImportError: /lib64/libkrb5.so.3: symbol
keyctl_get_persistent, version KEYUTILS_1.4 not defined in file
libkeyutils.so.1 with link time reference
DEBUG util.py:356: Child return code was: 1
f20 builds don't seem to be affected.
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-**of-conducthttp://fedoraproject.org/code-of-conduct
--
http://cecinestpasunefromage.wordpress.com/
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
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: Rawhide buildroot broken?
Seems to be working OK here.
Dan
On Fri, Oct 4, 2013 at 6:24 AM, Jon Ciesla limburg...@gmail.com wrote:
I'm seeing this too.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6024388
-J
On Fri, Oct 4, 2013 at 8:22 AM, Paul Howarth p...@city-fan.org wrote:
I'm seeing this in root.log for all Rawhide builds:
DEBUG util.py:316: Executing command: ['fedpkg', 'sources'] with env
{'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot', 'HOME': '/builddir',
'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:266: Traceback (most recent call last):
DEBUG util.py:266:File /usr/bin/fedpkg, line 13, in module
DEBUG util.py:266: from fedpkg.__main__ import main
DEBUG util.py:266:File
/usr/lib/python2.7/site-packages/fedpkg/__init__.py, line 12, in module
DEBUG util.py:266: import pyrpkg
DEBUG util.py:266:File
/usr/lib/python2.7/site-packages/pyrpkg/__init__.py, line 17, in module
DEBUG util.py:266: import pycurl
DEBUG util.py:266: ImportError: /lib64/libkrb5.so.3: symbol
keyctl_get_persistent, version KEYUTILS_1.4 not defined in file
libkeyutils.so.1 with link time reference
DEBUG util.py:356: Child return code was: 1
f20 builds don't seem to be affected.
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
http://cecinestpasunefromage.wordpress.com/
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
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: Rawhide buildroot broken?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/2013 10:10 AM, Dan Mashal wrote:
Seems to be working OK here.
Dan
On Fri, Oct 4, 2013 at 6:24 AM, Jon Ciesla limburg...@gmail.com
wrote:
I'm seeing this too.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6024388
-J
On Fri, Oct 4, 2013 at 8:22 AM, Paul Howarth p...@city-fan.org
wrote:
I'm seeing this in root.log for all Rawhide builds:
DEBUG util.py:316: Executing command: ['fedpkg', 'sources']
with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL':
'/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n
mock-chroot', 'HOME': '/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'} DEBUG util.py:266: Traceback
(most recent call last): DEBUG util.py:266:File
/usr/bin/fedpkg, line 13, in module DEBUG util.py:266:
from fedpkg.__main__ import main DEBUG util.py:266:File
/usr/lib/python2.7/site-packages/fedpkg/__init__.py, line 12,
in module DEBUG util.py:266: import pyrpkg DEBUG
util.py:266:File
/usr/lib/python2.7/site-packages/pyrpkg/__init__.py, line 17,
in module DEBUG util.py:266: import pycurl DEBUG
util.py:266: ImportError: /lib64/libkrb5.so.3: symbol
keyctl_get_persistent, version KEYUTILS_1.4 not defined in
file libkeyutils.so.1 with link time reference DEBUG
util.py:356: Child return code was: 1
f20 builds don't seem to be affected.
A bad combination of keyutils and krb5 got pushed. It's currently
being sorted out. The non-functional versions have temporarily been
untagged.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJOzp0ACgkQeiVVYja6o6OyUwCeM8M+0PqYnS7fA1Qjep7fiS25
HaMAn1mPuej7zlygL5dizwSFjrRmSsws
=ohDp
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review: Ticket #47415 Manage certificates crashes admin server
https://fedorahosted.org/389/attachment/ticket/47415/0001-Ticket-47415-Manage-certificates-crashes-admin-serve.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[perl-HTTP-BrowserDetect] Created tag perl-HTTP-BrowserDetect-1.61-1.fc21
The lightweight tag 'perl-HTTP-BrowserDetect-1.61-1.fc21' was created pointing to: dd8b89e... Update to 1.61 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-BrowserDetect] Created tag perl-HTTP-BrowserDetect-1.61-1.fc20
The lightweight tag 'perl-HTTP-BrowserDetect-1.61-1.fc20' was created pointing to: dd8b89e... Update to 1.61 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Source file audit - 2013-09-30
On Thu, Oct 3, 2013 at 3:35 PM, Kevin Fenzi ke...@scrye.com wrote: jjames:BADURL:DSDP5.8.tar.gz:DSDP The upstream host has a note on their web site explaining that the entire web site was rearranged, and gives directions on how to find new URLs for the various projects hosted there. The procedure fails for DSDP, which does not appear to have survived the reorganization. I sent a note to the webmaster, asking if the DSDP pages are gone permanently. He replied that he had forwarded my query on to the group that formerly maintained the DSDP web site. No word from them yet. If the web site is permanently gone, I can certainly remove the 'http://...' portion of the Source0 URL, but what do I do about the URL field in the spec file in that case? I would like to keep this package around, because it is used by python-cvxopt. -- 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: firewalld rewrite in C - outdated wiki page
On 10/02/2013 10:37 AM, Miroslav Suchý wrote: On 10/02/2013 08:33 AM, Mateusz Marzantowicz wrote: I've found this page [1] with following content: - Targeted release: Fedora 16 - Last updated: 2011-06-27 - Percentage of completion: 10% Is it OK to have feature which is 10% complete and is still targeted at eol release? It has been proposed at some time, but then has been postponed. If you navigate to (the link is located on bottom of your page) https://fedoraproject.org/wiki/Category:FeaturePageIncomplete You will see huge list of Features. Which are incomplete. Which means that it was not accepted by FesCo, or even not submitted and author gave up for some reason. Or it is still on his TODO list, where it can stay for long long time. You can pick it up. Or delete it, if it bothers you. But best approach is always contact original author and ask him, what are his plans with that feature. We are starting a new attempt to have a recode in a C-based language right now. I will delete the contents of the page for now. Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] please review: Ticket 47522 - Password administrators should be able to violate password policy
https://fedorahosted.org/389/ticket/47522 https://fedorahosted.org/389/attachment/ticket/47522/0001-Ticket-47522-Password-adminstrators-should-be-able-t.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Fedora Working Groups: Call for Self-Nominations
On 10/04/2013 11:49 AM, Stephen Gallagher wrote: The main change being made here is with how we are presenting *The Fedora Project* to the world. In the past, we've tried to be all things to all people, but going forward we want to pick a few specific areas that we will focus on (and market) particularly. The wide world of Fedora software and packages will always be there. Why should the community participate in this when it turns out that the the whole WG and the next proposal is nothing but an utter and total sheninagan on RH behalf as came apparent on last FESCO meeting basically if whatever they come up with doesn't work for RH, it's a non-starter. Sending a clear cut message to the community and people wanting to participate in it so in a sense Red Hat has already presentedFedora Project* to the world or at least it's view on it's community. Here come and join Fedora we will allow you to do everything but influence or participate in anykind of direction that project might take but we do our best effort making you feel like you actually are making a difference I can understand why people get the notion of that we are nothing more the a freaking test bed for RH due to a disgrace and disgusting corporate behaviour towards the community like was shown on the last FESCO meeting when the true intention of RH was shown with the direction of Fedora and how much community gets to be involved in that decision. What a disgrace and disgusting corporate behaviour towards the community that took place on that meeting putting Red Hat on par with Canonical. Truly a dark day in Fedora history that took place there on that meeting. But I think Stephen for trying to propose to certain extent fair proposal on how to handle the working group nominations 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
[perl-HTTP-DAV] Update to 0.47
commit 5423c80aa1d722ebf4a228d46ef78b6c8141a36a
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 4 16:13:50 2013 +0100
Update to 0.47
- New upstream release 0.47
- Fixed CPAN RT#38677: Intercept correctly 405 (Method now allowed) errors
and report them to the clients
- Fixed CPAN RT#68936: Fixed errors() method that would bomb out when the
_errors attribute wasn't initialized
- Fixed CPAN RT#69439: Insecure /tmp files handling in dave client
- Added -tmpdir option to dave client
- Reorganized distribution layout to match usual CPAN practice
- Removed remains of svn-era ($Id and such...)
- HTTP::DAV should now be working with more WebDAV servers
- We are more flexible in what content types we consider to be XML
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't need to remove empty directories from the buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Don't use macros for commands
- Explicitly set PERLDAV_TEST to 'default' for %check to avoid noisy
warnings
.gitignore |3 +-
perl-HTTP-DAV.spec | 64 +++
sources|2 +-
3 files changed, 46 insertions(+), 23 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cfad877..e5512ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-HTTP-DAV-0.40.tar.gz
-/HTTP-DAV-0.42.tar.gz
+/HTTP-DAV-[0-9.]*.tar.gz
diff --git a/perl-HTTP-DAV.spec b/perl-HTTP-DAV.spec
index 1a87302..6ff75b0 100644
--- a/perl-HTTP-DAV.spec
+++ b/perl-HTTP-DAV.spec
@@ -1,23 +1,27 @@
Name: perl-HTTP-DAV
-Version:0.42
-Release:10%{?dist}
+Version:0.47
+Release:1%{?dist}
Summary:WebDAV client library for Perl5
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTTP-DAV/
-Source0:
http://www.cpan.org/authors/id/O/OP/OPERA/HTTP-DAV-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/C/CO/COSIMO/HTTP-DAV-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(AutoLoader)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Glob)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Getopt::Long)
BuildRequires: perl(HTTP::Date)
BuildRequires: perl(HTTP::Headers)
+BuildRequires: perl(HTTP::Request)
BuildRequires: perl(HTTP::Response)
-BuildRequires: perl(Getopt::Long)
BuildRequires: perl(LWP) = 5.48
+BuildRequires: perl(Pod::Parser)
BuildRequires: perl(Pod::Usage)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Term::ReadLine)
@@ -26,8 +30,10 @@ BuildRequires: perl(Text::ParseWords)
BuildRequires: perl(Time::Local)
BuildRequires: perl(URI)
BuildRequires: perl(URI::Escape)
+BuildRequires: perl(URI::file)
BuildRequires: perl(XML::DOM)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(HTTP::Headers)
%description
HTTP::DAV is a Perl API for interacting with and modifying content on
@@ -38,34 +44,52 @@ files and much more on a DAV-enabled web server.
%setup -q -n HTTP-DAV-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
-make test
+PERLDAV_TEST=default make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root,-)
%doc Changes README TODO
%{_bindir}/dave
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
-%{_mandir}/man1/*
+%{perl_vendorlib}/HTTP/
+%{_mandir}/man1/dave.1*
+%{_mandir}/man3/HTTP::DAV.3pm*
+%{_mandir}/man3/HTTP::DAV::Changes.3pm*
+%{_mandir}/man3/HTTP::DAV::Lock.3pm*
+%{_mandir}/man3/HTTP::DAV::Resource.3pm*
+%{_mandir}/man3/HTTP::DAV::Response.3pm*
%changelog
+* Fri Oct 4 2013 Paul Howarth p...@city-fan.org - 0.47-1
+- Update to 0.47
+ - Fixed CPAN RT#38677: Intercept correctly 405 (Method now allowed) errors
+and report them to the clients
+ - Fixed CPAN RT#68936: Fixed errors() method that would bomb out when the
+_errors attribute wasn't initialized
+ - Fixed CPAN RT#69439: Insecure /tmp files handling in dave client
+ - Added -tmpdir option to dave client
+ - Reorganized distribution layout to match usual
[perl-HTTP-DAV/f20] Update to 0.47
Summary of changes: 5423c80... Update to 0.47 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora Working Groups: Call for Self-Nominations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2013 11:14 AM, Jóhann B. Guðmundsson wrote: On 10/04/2013 11:49 AM, Stephen Gallagher wrote: The main change being made here is with how we are presenting *The Fedora Project* to the world. In the past, we've tried to be all things to all people, but going forward we want to pick a few specific areas that we will focus on (and market) particularly. The wide world of Fedora software and packages will always be there. Why should the community participate in this when it turns out that the the whole WG and the next proposal is nothing but an utter and total sheninagan on RH behalf as came apparent on last FESCO meeting basically if whatever they come up with doesn't work for RH, it's a non-starter. Sending a clear cut message to the community and people wanting to participate in it so in a sense Red Hat has already presentedFedora Project* to the world or at least it's view on it's community. I'm going to attempt to respond to this here, but I do realize it's going to be difficult to communicate my point clearly, especially amongst strong emotions. The phrasing used above was unfortunate and open to the wrong interpretation. Red Hat is not attempting to force its vision into the world. Red Hat has gotten as far as it has not by being a dictator but by being a facilitator. Red Hat as an organization recognizes that individual contributors in the greater community are an asset both to that community and to Red Hat and we don't want to alienate anyone with good ideas. Furthermore, our general philosophy is heavily centered around the idea that the community will sometimes come up with dissenting ideas that prove out to be better than Red Hat's current plans. Historically, the company's approach in those situations has been to re-target, often by hiring those individuals so that they can work on their idea full-time, rather than as a side-project. Now, what was really intended by that statement that you quoted above (and I acknowledge I'm putting words in people's mouths a bit) is that Red Hat *may* flex its muscles a bit if the community were to do something extremely unlikely that would be in direct opposition to the needs of Red Hat. And when I say extreme, I'm talking in the neighborhood of Fedora should drop the ix86 line and focus only on embedded ARM or Fedora should give up producing an OS entirely and become a package repository for CentOS. You are absolutely *not* going to see Red Hat micromanaging the creation of a Fedora-to-Red-Hat-specification because that would actively *degrade* the value of Fedora to Red Hat. Fedora is not just a testbed for RHEL, it's a proving ground for technologies, and those may eventually get included RHEL *from any source*, not just Red Hat. I cannot reiterate this statement enough Red Hat cannot dictate Fedora because that action will actively remove the real benefit that Red Hat gets from Fedora. Here come and join Fedora we will allow you to do everything but influence or participate in anykind of direction that project might take but we do our best effort making you feel like you actually are making a difference The Fedora Community *does* make a difference. We (Red Hat) could not do what we do without you. If that weren't the case, Red Hat would never spend the kind of money it does on funding Fedora rel-eng, FUDCons, Flock, FADs, representation at other conferences, swag, etc. Red Hat would spend that money *on Red Hat* if it didn't see value in the enabling these communities. I can understand why people get the notion of that we are nothing more the a freaking test bed for RH due to a disgrace and disgusting corporate behaviour towards the community like was shown on the last FESCO meeting when the true intention of RH was shown with the direction of Fedora and how much community gets to be involved in that decision. What a disgrace and disgusting corporate behaviour towards the community that took place on that meeting putting Red Hat on par with Canonical. Truly a dark day in Fedora history that took place there on that meeting. But I think Stephen for trying to propose to certain extent fair proposal on how to handle the working group nominations -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJO4ncACgkQeiVVYja6o6Ng7QCfe6e9wlmmr7NJR1mnqPU/ZzP1 KN0An0coNmGufuMQWN0KEDufxKTz8Ti4 =TWZ8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox and Gstreamer
On Fri, Oct 4, 2013 at 5:45 PM, Michael Cronenworth m...@cchtml.com wrote: Why is gstreamer explicitly disabled for Firefox 24+? (before I make an RFE bug) https://bugzilla.redhat.com/show_bug.cgi?id=962728 -- 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: Firefox and Gstreamer
On 4 Oct 2013 23:45, Michael Cronenworth m...@cchtml.com wrote: Why is gstreamer explicitly disabled for Firefox 24+? (before I make an RFE bug) There already is a RFE bug with all the details why its not enabled. Thanks, Michael -- 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
Firefox and Gstreamer
Why is gstreamer explicitly disabled for Firefox 24+? (before I make an RFE bug) Thanks, Michael -- 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: Rawhide buildroot broken?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/2013 10:20 AM, Stephen Gallagher wrote:
On 10/04/2013 10:10 AM, Dan Mashal wrote:
Seems to be working OK here.
Dan
On Fri, Oct 4, 2013 at 6:24 AM, Jon Ciesla
limburg...@gmail.com wrote:
I'm seeing this too.
http://koji.fedoraproject.org/koji/taskinfo?taskID=6024388
-J
On Fri, Oct 4, 2013 at 8:22 AM, Paul Howarth
p...@city-fan.org wrote:
I'm seeing this in root.log for all Rawhide builds:
DEBUG util.py:316: Executing command: ['fedpkg', 'sources']
with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL':
'/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n
mock-chroot', 'HOME': '/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'} DEBUG util.py:266:
Traceback (most recent call last): DEBUG util.py:266:
File /usr/bin/fedpkg, line 13, in module DEBUG
util.py:266: from fedpkg.__main__ import main DEBUG
util.py:266:File
/usr/lib/python2.7/site-packages/fedpkg/__init__.py, line
12, in module DEBUG util.py:266: import pyrpkg DEBUG
util.py:266:File
/usr/lib/python2.7/site-packages/pyrpkg/__init__.py, line
17, in module DEBUG util.py:266: import pycurl DEBUG
util.py:266: ImportError: /lib64/libkrb5.so.3: symbol
keyctl_get_persistent, version KEYUTILS_1.4 not defined in
file libkeyutils.so.1 with link time reference DEBUG
util.py:356: Child return code was: 1
f20 builds don't seem to be affected.
A bad combination of keyutils and krb5 got pushed. It's currently
being sorted out. The non-functional versions have temporarily
been untagged.
Everything should be back to normal on Rawhide now. Sorry for the trouble.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJO5CwACgkQeiVVYja6o6P1XQCfUDjEPzdgG2YN1YLnwMgkcFyL
CJAAni9RcJkM60mjxTzkcOunp+ZypWPt
=hlUZ
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
On Fri, 4 Oct 2013 08:55:38 +0200 Simone Caronni negativ...@gmail.com wrote: Check ok on my side: $ wget http://linux.dell.com/dkms/permalink/dkms-2.2.0.3.tar.gz --2013-10-04 08:54:36-- http://linux.dell.com/dkms/permalink/dkms-2.2.0.3.tar.gz Resolving linux.dell.com (linux.dell.com)... 143.166.224.62 Connecting to linux.dell.com (linux.dell.com)|143.166.224.62|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 86053 (84K) [application/x-gzip] Saving to: ‘dkms-2.2.0.3.tar.gz’ 100%[==] 86,053 96.3KB/s in 0.9s 2013-10-04 08:54:42 (96.3 KB/s) - ‘dkms-2.2.0.3.tar.gz’ saved [86053/86053] slaanesh:BADSOURCE:dkms-2.2.0.3.tar.gz:dkms - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. % cat sources 1bf726e59d24854cc6260522b444c8d3 dkms-2.2.0.3.tar.gz % md5sum dkms-2.2.0.3.tar.gz 11a8aaade2ebec2803653837c7593030 dkms-2.2.0.3.tar.gz So, somehow the one uploaded to our lookaside is not the same as the upstream one. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
On Fri, 04 Oct 2013 09:15:47 +0200 Alec Leamas leamas.a...@gmail.com wrote: On 10/03/2013 11:35 PM, Kevin Fenzi wrote: [cut] leamas:BADURL:xlwt-0.7.4.tar.gz:python-xlwt [cut] These are pypi urls which looks just fine to me (spectool -g works OK) Looks like a ssl cert problem? http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/python-xlwt-dl.txt ERROR: certificate common name `*.a.ssl.fastly.net' doesn't match requested host name `pypi.python.org'. To connect to pypi.python.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
On Fri, 4 Oct 2013 11:49:47 +0200 Dridi Boukelmoune dridi.boukelmo...@gmail.com wrote: Hi, In my case, the makeself source tarball is hosted on github. I've seen many people saying that github was down recently (even though it worked fine for me). curl -LI http://github.com/megastep/makeself/archive/release-2.2.0.tar.gz [... redirections stuff ...] HTTP/1.1 200 OK [... headers ...] Other packages might be related to the github outage. Could be, but in this case it did download ok... http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/makeself-dl.txt but it downloaded to a 'release-2.2.0' file? Possibly again a issue with the old spectool I was using for this run. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
On Fri, 4 Oct 2013 12:46:26 +0200 Tomasz Torcz to...@pipebreaker.pl wrote: On Thu, Oct 03, 2013 at 03:35:03PM -0600, Kevin Fenzi wrote: Here's attached another run of my sources/patches url checker. Please fix any packages you are responsible for in rawhide, and other Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). ttorcz:BADURL:hdapsd-20090401gita64b50c-a64b50c.tar.gz:hdapsd But is seem to have been downloaded fine... http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/hdapsd-dl.txt yeah, but note that it downloaded to: 2013-09-29 22:33:30 (20.8 MB/s) - `./a64b50c05c5e2b6b7d6ca1165362b4d8e484f4f4' saved [19829] not hdapsd-20090401gita64b50c-a64b50c.tar.gz kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
On Fri, 4 Oct 2013 15:08:25 +0400 Alexey I. Froloff ra...@raorn.name wrote: On Fri, Oct 04, 2013 at 02:59:36PM +0400, Alexey I. Froloff wrote: $ HEAD -S http://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz Content-Type: application/x-gzip Content-Disposition: attachment; filename=wmvolman-2.0.1.tar.gz --2013-10-03 05:54:40-- http://github.com/raorn/wmvolman/archive/2.0.1/wmvolman-2.0.1.tar.gz ... Length: unspecified [application/x-gzip] Saving to: `./2.0.1' 0K .. .. .. . 676K=0.06s Last-modified header missing -- time-stamps turned off. 2013-10-03 05:54:42 (676 KB/s) - `./2.0.1' saved [39940] What tool were you using for download? spectool -g *.spec kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to exclude and arch for a noarch package?
On Fri, Oct 04, 2013 at 11:15:09AM -0500, Bruno Wolff III wrote: I have a noarch package that depends on kernel-modules-extra that is no longer being built for arm. What is the proper way to exclude my package from arm? I can restore the empty package for you. -- 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 exclude and arch for a noarch package?
On Fri, Oct 4, 2013 at 6:21 PM, Kyle McMartin k...@redhat.com wrote: On Fri, Oct 04, 2013 at 11:15:09AM -0500, Bruno Wolff III wrote: I have a noarch package that depends on kernel-modules-extra that is no longer being built for arm. What is the proper way to exclude my package from arm? I can restore the empty package for you. You can just make let the kernel package provide kernel-modules-extra instead of adding a dummy package. -- 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 exclude and arch for a noarch package?
On Fri, Oct 04, 2013 at 06:24:05PM +0200, drago01 wrote: On Fri, Oct 4, 2013 at 6:21 PM, Kyle McMartin k...@redhat.com wrote: On Fri, Oct 04, 2013 at 11:15:09AM -0500, Bruno Wolff III wrote: I have a noarch package that depends on kernel-modules-extra that is no longer being built for arm. What is the proper way to exclude my package from arm? I can restore the empty package for you. You can just make let the kernel package provide kernel-modules-extra instead of adding a dummy package. It was short sighted to remove it anyway, we'll likely move more junk to -extras in the future anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to exclude and arch for a noarch package?
I have a noarch package that depends on kernel-modules-extra that is no longer being built for arm. What is the proper way to exclude my package from arm? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 707826] perl-Bio-SamTools missing from EL6
https://bugzilla.redhat.com/show_bug.cgi?id=707826 Adam Huffman bl...@verdurin.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2013-10-04 12:30:20 --- Comment #5 from Adam Huffman bl...@verdurin.com --- Unfortunately, this package depended on perl-bioperl, which was orphaned. So I had to orphan this one too, because I can't commit to maintaining perl-bioperl. -- 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=nNiS5t9lO0a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: How to exclude and arch for a noarch package?
On Fri, Oct 04, 2013 at 12:21:19 -0400, Kyle McMartin k...@redhat.com wrote: On Fri, Oct 04, 2013 at 11:15:09AM -0500, Bruno Wolff III wrote: I have a noarch package that depends on kernel-modules-extra that is no longer being built for arm. What is the proper way to exclude my package from arm? I can restore the empty package for you. That wouldn't really make sense. They package makes sure the joystick drivers are available (hence the dependency) and that they get loaded at boot. (Which is convenient, especially on the games spin.) Since arm doesn't have those, it doesn't make sense for the joystick-support package to exist there either. But I thought there were issues with doing exclude arch for a noarch package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] please review: Ticket 47491 - Update systemd service file to use PartOf directive
https://fedorahosted.org/389/ticket/47491 https://fedorahosted.org/389/attachment/ticket/47491/0001-Ticket-47491-Update-systemd-service-file-to-use-Part.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: How to exclude and arch for a noarch package?
On Fri, Oct 04, 2013 at 11:44:38AM -0500, Bruno Wolff III wrote: On Fri, Oct 04, 2013 at 12:21:19 -0400, Kyle McMartin k...@redhat.com wrote: On Fri, Oct 04, 2013 at 11:15:09AM -0500, Bruno Wolff III wrote: I have a noarch package that depends on kernel-modules-extra that is no longer being built for arm. What is the proper way to exclude my package from arm? I can restore the empty package for you. That wouldn't really make sense. They package makes sure the joystick drivers are available (hence the dependency) and that they get loaded at boot. (Which is convenient, especially on the games spin.) Since arm doesn't have those, it doesn't make sense for the joystick-support package to exist there either. But I thought there were issues with doing exclude arch for a noarch package. Sounds good to me. -- 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: Source file audit - 2013-09-30
On Fri, Oct 04, 2013 at 10:21:02AM -0600, Kevin Fenzi wrote: What tool were you using for download? spectool -g *.spec Which uses curl do download files... remote-header-name should be added to /etc/rpmdevtools/curlrc -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital 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: Source file audit - 2013-09-30
Jerry James wrote: On Thu, Oct 3, 2013 at 3:35 PM, Kevin Fenzi ke...@scrye.com wrote: jjames:BADURL:DSDP5.8.tar.gz:DSDP The upstream host has a note on their web site explaining that the entire web site was rearranged, and gives directions on how to find new URLs for the various projects hosted there. And it says Mathematics and Computer Science at the top of the page. What kind of computer science institute doesn't have the sense to keep permanent URLs? http://www.w3.org/Provider/Style/URI -- Björn Persson Sent from my computer. 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: How to exclude and arch for a noarch package?
On Fri, 4 Oct 2013 11:44:38 -0500, Bruno Wolff III wrote: [...] But I thought there were issues with doing exclude arch for a noarch package. It's an ugly work-around. noarch = no particular arch = any arch. Hence not publishing a noarch package for some arch is questionable. Unlike ordinary build archs, ExcludeArch for a noarch package doesn't prevent the package from getting built. And it could be installed on any arch, too. The ExcludeArch tag is found only in the src.rpm. It's the repo compose tools that must examine the src.rpm and evalute the tag when distributing noarch builds to repos. -- 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: Fedora Working Groups: Call for Self-Nominations
On 10/04/2013 03:44 PM, Stephen Gallagher wrote: Now, what was really intended by that statement that you quoted above (and I acknowledge I'm putting words in people's mouths a bit) is that Red Hat*may* flex its muscles a bit if the community were to do something extremely unlikely that would be in direct opposition to the needs of Red Hat. And when I say extreme, I'm talking in the neighborhood of Fedora should drop the ix86 line and focus only on embedded ARM or Fedora should give up producing an OS entirely and become a package repository for CentOS. You are absolutely*not* going to see Red Hat micromanaging the creation of a Fedora-to-Red-Hat-specification because that would actively*degrade* the value of Fedora to Red Hat. Fedora is not just a testbed for RHEL, it's a proving ground for technologies, and those may eventually get included RHEL*from any source*, not just Red Hat. Oh please cut the crap and stop beating that dead parrot [1] this is anything but *may*. What became clear on that meeting is that Red Hat with FESCO as it's enforcer was taking the necessary precautionary steps to ensure the community would never even have the slightest chance and the freedom to venture off it's beaten path. It was an action and decisions based on distrust rather than openness with Red Hat *already* tightening it's muscle on it's community leash. And that three product proposal is nothing more then Red Hat micromanaging the creation of Fedora products through the false notion of the community being part of that through the working groups . We already have an existing cloud community and SIG which is perfectly capable of delivering product(s). We already have an existing Server community and SIG perfectly capable to deliver several products. We already have several *DE which could have had the equal opportunity of engaging in a specific Workstation SIG but as we all know the decision has already been made within Red Hat to s/default desktop/Fedora workstation/ which is probably what this whole shenanigan is about in the first place some marketing and documentation stunt while migrating the default desktop to workstation product status. It's an outright disgusting and disgraceful corporate behavior towards the community what Red Hat has done here and one can just image all the ideas that have started to spring alive in the community which Red Hat has killed in birth so it would not interfere with it's corporate vision or disrupt it's internal processes and workflows. JBG 1. http://www.davidpbrown.co.uk/jokes/monty-python-parrot.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Red Hat and Fedora Working Groups
On Fri, Oct 04, 2013 at 03:14:27PM +, Jóhann B. Guðmundsson wrote: Why should the community participate in this when it turns out that the the whole WG and the next proposal is nothing but an utter and total sheninagan on RH behalf as came apparent on last FESCO meeting Jóhann, you're taking one out-of-context quote from one FESCo member, reading too much into it, and building an alarmist story around it. This is absolutely a real community process. Red Hat members of the working groups can make their merit-based cases the same way as anyone else, and if they can't show that merit to the community, they don't get a special trump card. They will have to find another way to advance their cause. You may think that this is just talk, but I promise you it isn't. Fedora provides value to Red Hat in many different ways, but genuine community voice is among the most crucial. If that voice tells us one thing and we can't listen, that's our failure, our loss -- and not what's going to happen here. It's completely fair for Red Hat -- and Red Hatters -- to talk about what directions in Fedora we think would be most beneficial to the company, and about the resources -- time, money, people, and so on -- that we could bring to bear in certain directions (and probably won't in other directions). If we clearly talk about that, and about the technical merit of directions proposed, and we can't be convincing, and can't adapt what we're proposing to become convincing... well, we have some soul-searching to do. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.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 swaps: perl-Parse-DebControl, devscripts, debian-keyring, ubuntu-keyring, jetring + question: where to install keyrings?
On Mon, Sep 23, 2013 at 10:30:11AM +0200, Sandro Mani wrote:
On 23.09.2013 02:01, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Sep 23, 2013 at 12:14:29AM +0200, Sandro Mani wrote:
On 20.09.2013 06:37, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Sep 19, 2013 at 06:41:03PM +0200, Sandro Mani wrote:
Hi,
In the hope to continue the effort of getting pbuilder (and hence an
easy way to build deb packages from fedora) into the repos (review
here: [1]), I've packaged devscripts, debian-keyring, ubuntu-keyring
and jetring. Reviews are here:
- jetring: https://bugzilla.redhat.com/show_bug.cgi?id=1009996
- debian-keyring: https://bugzilla.redhat.com/show_bug.cgi?id=1009997
- ubuntu-keyring: https://bugzilla.redhat.com/show_bug.cgi?id=1009998
- perl-Parse-DebControl:
https://bugzilla.redhat.com/show_bug.cgi?id=100
- devscripts: https://bugzilla.redhat.com/show_bug.cgi?id=101
A question concerning the keyrings: currently, the only other
package (afaics) containing distro keyrings is archlinux-keyring.
That package installs the keyrings in /usr/share/pacman/keyrings.
Pacman installs the keyrings into /usr/share/pacman/keyrings
because that's what Arch does. I guess that archlinux.gpg may
move to /usr/share/keyrings, but there are other files (lists
of trusted and revoked keys), which are specific to pacman's libalpm,
so I think they deserve a directory on it's own. If archlinux.gpg
moves, it can be symlinked into /usr/share/pacman/keyrings.
The debian-keyring and ubuntu-keyring packages I've posted for
review install the keyrings in /usr/share/keyrings. This directory
is however unowned. I see two options:
- install {debian,ubuntu} keyrings in
/usr/share/{ubuntu,debian}/keyrings, and have them own the
directories
- have gnupg own the directory /usr/share/keyrings (and possibly
have archlinux-keyring also install the keyrings there)
This has the downside that it'll add the dependency on gnupg,
which is not great. Maybe simply create a keyrings-filesystem
package with this directory and have whoever installs keyrings
depend on it.
Any other opinions on this?
Or would it be appropriate to file a fpc
ticket for this?
I guess that we two are currently the only interested parties. I'm
sure we can agree on a solution without involing the FPC. An FPC
ticket means probably a month delay, and I don't think there's
anything controversial here.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=998690#c3,
for some rationale for a -filesystem package.
I'll try to do some reviews of the remaining packages tomorrow. This
should help to finish this faster.
Ok, thanks. I've gone ahead and created a keyrings-filesytem
package, review is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1010857
I've also update the other reviews to use this package.
Hi Sandro,
it's great to see that this is progressing so quickly.
I've started to add a dependency on keyrings-filesystem to
archlinux-keyring, but there's a problem:
/usr/share/pacman/keyrings/archlinux.gpg is a text file:
% head -n3 /usr/share/pacman/keyrings/archlinux.gpg
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBE7VXhABEAC7AB9vHjR4b/lXq/HANeeN2vWQYK3xL2/01nvUPwycjDbCkOg2
...
while /usr/share/keyrings/debian-archive-keyring.gpg is a real gpg2
(binary) keyring.
I could
(a) symlink archlinux.gpg into /usr/share/keyrings/ as is
(b) convert archlinux.gpg to the gpg2 binary format, but that would
probably require duplicating the file, since pacman expects
the text format.
So the question is, what is the purpose/intended user of
/usr/share/keyring/*.gpg ?
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
[389-devel] Jenkins build is back to normal : 389-ds-base #157
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/157/changes -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
sysctl behavior for docker-io
So, IP forwarding seems to be disabled by default in Fedora. docker-io requires IP forwarding enabled With respect to packaging, we'd like to have docker-io installation set sysctl values to enable IPv4 and IPv6 forwarding: https://bugzilla.redhat.com/show_bug.cgi?id=1011680 I was told on #fedora-devel that changing sysctl values during installation would spell trouble from a sysadmin's POV, so my plan was to install 80-docker.conf into /usr/lib/sysctl.d but not have the IP forwarding sysctl values take effect at install time. Would this be the right approach? Comments? -- Lokesh -- 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: python-jsmin, python-cssmin
On Fri, Oct 04, 2013 at 08:41:55AM -0400, Martin Krizek wrote: - Original Message - From: Stephen Gallagher sgall...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Martin Krizek mkri...@redhat.com Sent: Friday, October 4, 2013 2:33:50 PM Subject: Re: Review swap: python-jsmin, python-cssmin -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2013 07:57 AM, Martin Krizek wrote: Hi, anyone willing to review or swap reviews? https://bugzilla.redhat.com/show_bug.cgi?id=1014607 https://bugzilla.redhat.com/show_bug.cgi?id=1014601 Hi, I've gone ahead and done the two reviews. 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: Review swap: python-jsmin, python-cssmin
On Fri, Oct 04, 2013 at 08:41:55AM -0400, Martin Krizek wrote: - Original Message - From: Stephen Gallagher sgall...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Martin Krizek mkri...@redhat.com Sent: Friday, October 4, 2013 2:33:50 PM Subject: Re: Review swap: python-jsmin, python-cssmin -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2013 07:57 AM, Martin Krizek wrote: Hi, anyone willing to review or swap reviews? https://bugzilla.redhat.com/show_bug.cgi?id=1014607 https://bugzilla.redhat.com/show_bug.cgi?id=1014601 Thanks! Martin Has JSMin finally changed to an acceptable license? It's got a long history of including a line The Software shall be used for Good, not Evil. which makes the license unenforceable and unsuitable for inclusion in Fedora. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJOta4ACgkQeiVVYja6o6MNlgCgg9HhrfMX9xuMjU6pnV3ptA0+ wKkAn247tK9UiqmLyX5xUAfPq4o9ZeCa =Y1cL -END PGP SIGNATURE- It's MIT. This isn't quite so sinple. jsmin/__init__.py has this at the top: # This code is original from jsmin by Douglas Crockford, it was translated to # Python by Baruch Even. It was rewritten by Dave St.Germain for speed. # # The MIT License (MIT) # # Copyright (c) 2013 Dave St.Germain # The original code by Douglas Crockford has the problematic license. The Baruch Even port had several issues: (1) it appeared to retain the same problematic license. (2) It was deemed a 'conscious translation from C to Python' and therefore retians the original license: http://www.redhat.com/archives/fedora-legal-list/2009-September/msg00014.html http://www.redhat.com/archives/fedora-legal-list/2009-August/msg0.html That thread talks about a clean-room implementation being okay for inclusion. The python-jsmin that you're packaging is most likely not a clean-room implementation (the header says this is a rewrite of the previous iterations of the code and thus the author probably started by reading and modifying the existing code). I do not know if there's other legal ways to produce something that the Author would be allowed to relicense from the original Crockford license to MIT. You'll need to contact fedora legal https://admin.fedoraproject.org/mailman/listinfo/legal to find out for sure but from past reading, I'm not hopeful that there's any legal way that they could do that (so you might want to contact the author/pypi owner to let them know that the header and pypi listing are inaccurate.) Note that there's other implementations of jsmin. For instance, the v8-devel package in Fedora has a clean-room implementation /usr/lib/python2.7/site-packages/jsmin.py As a tangent, maybe someone should ask the v8 packager to split that out into its own subpackage. The python code doesn't need the v8 package at runtime. I've blocked your python-jsmin review bug on FE-LEGAL. Please close if you decide not to pursue this package review or update the bug as information comes in from FE-LEGAL. -Toshio pgp9SWzXu0BkA.pgp 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: sysctl behavior for docker-io
On Fri, Oct 04, 2013 at 02:15:07PM -0500, Lokesh Mandvekar wrote: So, IP forwarding seems to be disabled by default in Fedora. docker-io requires IP forwarding enabled With respect to packaging, we'd like to have docker-io installation set sysctl values to enable IPv4 and IPv6 forwarding: https://bugzilla.redhat.com/show_bug.cgi?id=1011680 I was told on #fedora-devel that changing sysctl values during installation would spell trouble from a sysadmin's POV, so my plan was to install 80-docker.conf into /usr/lib/sysctl.d but not have the IP forwarding sysctl values take effect at install time. Would this be the right approach? I agree that they shouldn't be changed at RPM install time. However, I'm also not sure that we should drop something into sysctl.d, because a) that doesn't take effect with the case of yum install docker-io; systemctl start docker, so that's confusing for users b) having docker _installed_ isn't really hte case where we need this -- it's when docker is running. So, my first suggestion is to put the configuration into the systemd service file. But, I have a question: What does libvirt do? Both as an example, and as a possible solution -- will this problem go away when we convert to using that, because libvirt will just take care of that? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.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: Source file audit - 2013-09-30
On Fri, Oct 04, 2013 at 10:17:02AM -0600, Kevin Fenzi wrote: On Fri, 04 Oct 2013 09:15:47 +0200 Alec Leamas leamas.a...@gmail.com wrote: On 10/03/2013 11:35 PM, Kevin Fenzi wrote: [cut] leamas:BADURL:xlwt-0.7.4.tar.gz:python-xlwt [cut] These are pypi urls which looks just fine to me (spectool -g works OK) Looks like a ssl cert problem? http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/python-xlwt-dl.txt ERROR: certificate common name `*.a.ssl.fastly.net' doesn't match requested host name `pypi.python.org'. To connect to pypi.python.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. pypi have been working on getting a CDN working recently. I think they consider what they have in place now as working, though. I'm finding that the pypi urls work on Fedora (tested wget on F17 and rawhide) but they do not on RHEL5 and RHEL6. -Toshio pgp2vUtRkMpNg.pgp 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: Source file audit - 2013-09-30
On Fri, Oct 04, 2013 at 09:00:07AM -0600, Jerry James wrote: On Thu, Oct 3, 2013 at 3:35 PM, Kevin Fenzi ke...@scrye.com wrote: jjames:BADURL:DSDP5.8.tar.gz:DSDP The upstream host has a note on their web site explaining that the entire web site was rearranged, and gives directions on how to find new URLs for the various projects hosted there. The procedure fails for DSDP, which does not appear to have survived the reorganization. I sent a note to the webmaster, asking if the DSDP pages are gone permanently. He replied that he had forwarded my query on to the group that formerly maintained the DSDP web site. No word from them yet. If the web site is permanently gone, I can certainly remove the 'http://...' portion of the Source0 URL, but what do I do about the URL field in the spec file in that case? I would like to keep this package around, because it is used by python-cvxopt. Add a comnent above the Source0: line that says what's happened to the upstream hosting. It does mean that the upstream is dead and you'll be on the hook for more maintainance should problems be found in the package. -Toshio pgpGvYqu8Lqr2.pgp 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: sysctl behavior for docker-io
On Fri, Oct 04, 2013 at 04:04:19PM -0400, Matthew Miller wrote: On Fri, Oct 04, 2013 at 02:15:07PM -0500, Lokesh Mandvekar wrote: So, IP forwarding seems to be disabled by default in Fedora. docker-io requires IP forwarding enabled With respect to packaging, we'd like to have docker-io installation set sysctl values to enable IPv4 and IPv6 forwarding: https://bugzilla.redhat.com/show_bug.cgi?id=1011680 I was told on #fedora-devel that changing sysctl values during installation would spell trouble from a sysadmin's POV, so my plan was to install 80-docker.conf into /usr/lib/sysctl.d but not have the IP forwarding sysctl values take effect at install time. Would this be the right approach? I agree that they shouldn't be changed at RPM install time. However, I'm also not sure that we should drop something into sysctl.d, because a) that doesn't take effect with the case of yum install docker-io; systemctl start docker, so that's confusing for users b) having docker _installed_ isn't really hte case where we need this -- it's when docker is running. So, my first suggestion is to put the configuration into the systemd service file. But, I have a question: What does libvirt do? Both as an example, and as a possible solution -- will this problem go away when we convert to using that, because libvirt will just take care of that? Josh (cc'd) said libvirtd would enable it, but we still need to take care of this for docker+lxc. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.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 -- Lokesh -- 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: sysctl behavior for docker-io
On Fri, Oct 04, 2013 at 03:21:07PM -0500, Lokesh Mandvekar wrote: Josh (cc'd) said libvirtd would enable it, but we still need to take care of this for docker+lxc. If we pick libvirt-lxc as the preferred configuration, we can maybe get away with just documenting changes needed if you want to use the other tools. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.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: sysctl behavior for docker-io
On Fri, Oct 04, 2013 at 03:21:07PM -0500, Lokesh Mandvekar wrote: On Fri, Oct 04, 2013 at 04:04:19PM -0400, Matthew Miller wrote: On Fri, Oct 04, 2013 at 02:15:07PM -0500, Lokesh Mandvekar wrote: So, IP forwarding seems to be disabled by default in Fedora. docker-io requires IP forwarding enabled With respect to packaging, we'd like to have docker-io installation set sysctl values to enable IPv4 and IPv6 forwarding: https://bugzilla.redhat.com/show_bug.cgi?id=1011680 I was told on #fedora-devel that changing sysctl values during installation would spell trouble from a sysadmin's POV, so my plan was to install 80-docker.conf into /usr/lib/sysctl.d but not have the IP forwarding sysctl values take effect at install time. Would this be the right approach? I agree that they shouldn't be changed at RPM install time. However, I'm also not sure that we should drop something into sysctl.d, because a) that doesn't take effect with the case of yum install docker-io; systemctl start docker, so that's confusing for users b) having docker _installed_ isn't really hte case where we need this -- it's when docker is running. So, my first suggestion is to put the configuration into the systemd service file. But, I have a question: What does libvirt do? Both as an example, and as a possible solution -- will this problem go away when we convert to using that, because libvirt will just take care of that? Josh (cc'd) said libvirtd would enable it, but we still need to take care of this for docker+lxc. I agree with Matthew that the unit file is a good place to do it. Another option would be to enable it from the docker daemon itself. That way all the other distros wouldn't have to hit this same issue when packaging docker. 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: Red Hat and Fedora Working Groups
On Fri, Oct 4, 2013 at 2:23 PM, Matthew Miller mat...@fedoraproject.orgwrote: On Fri, Oct 04, 2013 at 03:14:27PM +, Jóhann B. Guðmundsson wrote: Why should the community participate in this when it turns out that the the whole WG and the next proposal is nothing but an utter and total sheninagan on RH behalf as came apparent on last FESCO meeting Jóhann, you're taking one out-of-context quote from one FESCo member, reading too much into it, and building an alarmist story around it. This is absolutely a real community process. Red Hat members of the working groups can make their merit-based cases the same way as anyone else, and if they can't show that merit to the community, they don't get a special trump card. They will have to find another way to advance their cause. Let me add a few words here as well. I'm of the same opinion as Matthew here -- I think Jóhann is reading too much into a unfortunately worded quote. (And, based on Jóhann's recent behavior, he seems to have an axe to grind with Red Hat.) I'd like to state for the record that while I was the Fedora Project Leader, Red Hat never once told me what to do as the FPL or exercised any undue influence on what Fedora should or shouldn't be doing. Of course, they watched with interest to see what was happening in Fedora, and various Red Hat engineers added new features to Fedora along the way, and quite a few Red Hat employees took part on the Fedora Board and FESCo and FAmSCo and various other SIGs -- but I can state unequivocally that I never tried to force Fedora's hand, or did I see any sort of underhanded behavior or grand conspiracy to which Jóhann refers. I'm sorry Jóhann, but I can't sit here and watch you make those kinds of accusations without sharing what I saw and experienced while I was an insider at Red Hat. It's not helpful to the Fedora community to continue with these baseless accusations. Let me even be a little more blunt here: I don't think Fedora could thrive without the support and help that Red Hat (and, by extension, it's employees) provide. It could probably survive, but it would only be limping along. In that same manner, I don't think Red Hat could thrive the way it has without the great work that Fedora does. For better or worse, the Fedora community and Red Hat need each other. I don't see any easy way for them to go their separate ways without damaging both sides. (For the record, I no longer work for Red Hat, have nothing tangible to gain by Red Hat's success, but still hold them in high esteem based on my time working there.) -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 20 Virt Test Day is October 8th!
Hey all, The Fedora 20 Virt Test Day is this coming Tuesday, October 8th. Check out the test day landing page: https://fedoraproject.org/wiki/Test_Day:2013-10-08_Virtualization If you're interested in trying out some new virt functionality, there's step by step instructions for: * Snapshot UI in virt-manager * Running ARM VMs on x86 with libvirt/virt-manager * Libvirt ACLs for granting a user access to only a single VM Even if you aren't interested in testing new features, we still need you! The test day is the perfect time to make sure your virt workflow is working fine on Fedora 20, as there will be several developers on hand to answer any questions, help with debugging, provide patches, etc. No requirement to run through test cases on the wiki, just show up and let us know what works (or breaks). If you can't make the date of the test day, adding test case results to the wiki anytime next week is fine as well. Though if you do plan on showing up to the test day, add your name to the participant list on the wiki, and when the day arrives, pop into #fedora-test-day on freenode and give us a shout! Thanks, Cole ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- 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: thunderbird-24.0.2 reverted - why? (Use the commit log..., Luke)
On 09/24/2013 03:16 AM, Michael J Gruber wrote: Hi there, I can see that thunderbird 24 had been built successfully and then reverted on the fc18 branch (and others). The git commit log and the spec changelog say Revert to 17.0.8 and nothing else. I do understand that more than a successful build is necessary for a package to be pushed, but can we please agree on putting some substantial information on why (not just what) into the git log or change log? Good luck getting people here to actually care. Spec description, git commit message, then bodhi update description: three different places to say the same thing in different words. As frustrating as it is, people just don't want to be bothered with this duplication. This is understandable, and most FLOSS projects only require a good commit message to go along with the change. As the British Academy once said, it is preferable to accept what ten thousand people say, than to try to correct what ten thousand people say. Alex -- 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: thunderbird-24.0.2 reverted - why? (Use the commit log..., Luke)
On 09/26/2013 07:05 AM, Michael J Gruber wrote: Maybe we'll find a way to use git more gittish one day. If the git commit messages or notes automated the process of generating a spec changelog or bodhy comments people would be happily filling them in, I guess! Abso-fornicating-lutely. This topic is regularly recurring on this list. Maybe in 136 releases, we may get this agreed upon and fixed. Alex -- 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: Red Hat and Fedora Working Groups
On 10/04/2013 09:50 PM, Jared K. Smith wrote: On Fri, Oct 4, 2013 at 2:23 PM, Matthew Miller mat...@fedoraproject.org mailto:mat...@fedoraproject.org wrote: I'm sorry Jóhann, but I can't sit here and watch you make those kinds of accusations without sharing what I saw and experienced while I was an insider at Red Hat. It's not helpful to the Fedora community to continue with these baseless accusations. Jared are accusing me of baseless accusation after what is clear cut and took place at that meeting? Do you really want to head down this road? Did you not read the meeting long as well as Stephens response? Did you look at the history who signed up to the WG page before it even got announced to the community? Want to take this further shall we start pointing out individuals that Red Hat invented job positions for within our communities then planted individuals outside the community in those positions to satisify it's compulseve corporate need for control? Shall we talk about how Red Hat employees have been granted all kinds of privileges within our community without as even bother to introduce themselves to the community even to the extent that fesco is now judging people if they are socially ready for proven packagers while Red Hat employees walk around and are granted those privileges freely? Back of your words Jared dishonour me to my face and tell I'm wrong or if I'm lying!!! 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: Red Hat and Fedora Working Groups
On 10/04/2013 06:23 PM, Matthew Miller wrote: On Fri, Oct 04, 2013 at 03:14:27PM +, Jóhann B. Guðmundsson wrote: Why should the community participate in this when it turns out that the the whole WG and the next proposal is nothing but an utter and total sheninagan on RH behalf as came apparent on last FESCO meeting Jóhann, you're taking one out-of-context quote from one FESCo member, reading too much into it, and building an alarmist story around it. This is absolutely a real community process. Red Hat members of the working groups can make their merit-based cases the same way as anyone else, and if they can't show that merit to the community, they don't get a special trump card. They will have to find another way to advance their cause. You may think that this is just talk, but I promise you it isn't. Fedora provides value to Red Hat in many different ways, but genuine community voice is among the most crucial. If that voice tells us one thing and we can't listen, that's our failure, our loss -- and not what's going to happen here. It's completely fair for Red Hat -- and Red Hatters -- to talk about what directions in Fedora we think would be most beneficial to the company, and about the resources -- time, money, people, and so on -- that we could bring to bear in certain directions (and probably won't in other directions). If we clearly talk about that, and about the technical merit of directions proposed, and we can't be convincing, and can't adapt what we're proposing to become convincing... well, we have some soul-searching to do. And those words coming from a man who just back stabbed a man he went into feature process with and left him hanging ( Lennart ). Am I and the rest of the community supposed trust what you suddenly say and claim now? 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
[Bug 1014458] Program does not start
https://bugzilla.redhat.com/show_bug.cgi?id=1014458 --- Comment #4 from Dario Faggioli raist...@linux.it --- Looks like I do: $ perl -MMath::Clipper -e 'print $Math::Clipper::VERSION\n;' 1.17 Now the question is who installed that (I certainly did not, I know nothing about perl!). Perhaps a manual attempt to build Slic3r from sources some months ago? Also, is that normal that installing the perl-Math-Clipper rpm does not identify that and update it, or at least report it, or something like that (again, sorry, 0% perl here :-( )? I'll see if I can remove it, and if Slic3r turns back tu functioning after that... Thanks. -- 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=zeQobFfvXqa=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 File-ReadBackwards-1.05.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-File-ReadBackwards: 613d9d02de6c1d86d5fa5b8816a6b214 File-ReadBackwards-1.05.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1014458] Program does not start
https://bugzilla.redhat.com/show_bug.cgi?id=1014458
--- Comment #5 from Paul Howarth p...@city-fan.org ---
This should find it for you:
$ perl -MMath::Clipper -e 'print $INC{Math/Clipper.pm} . \n'
/usr/lib64/perl5/vendor_perl/Math/Clipper.pm
Installing / updating the perl-Math-Clipper rpm package would update an
existing perl-Math-Clipper rpm package, but it can know nothing about any other
versions you've installed by other means.
--
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=0NFUiZGyzea=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-File-ReadBackwards] Update to 1.05
commit 9073f73828dc672bc2e203fdc9d8c507f16819dc
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 4 09:53:49 2013 +0100
Update to 1.05
- New upstream release 1.05
- Re-ordered Changes to be recent at the top
- Rewritten t/large_file.t to skip non-sparse file systems
- Specify all dependencies
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't need to remove empty directories from the buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Don't use macros for commands
- Improve %summary
.gitignore |2 +-
perl-File-ReadBackwards.spec | 48 -
sources |2 +-
3 files changed, 35 insertions(+), 17 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 073c86e..e3b640f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-File-ReadBackwards-1.04.tar.gz
+/File-ReadBackwards-[0-9.]*.tar.gz
diff --git a/perl-File-ReadBackwards.spec b/perl-File-ReadBackwards.spec
index ab49d40..ca20349 100644
--- a/perl-File-ReadBackwards.spec
+++ b/perl-File-ReadBackwards.spec
@@ -1,16 +1,27 @@
Name: perl-File-ReadBackwards
-Version:1.04
-Release:18%{?dist}
-Summary:File::ReadBackwards Perl module
+Version:1.05
+Release:1%{?dist}
+Summary:Read a file backwards by lines
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/File-ReadBackwards/
Source0:
http://www.cpan.org/authors/id/U/UR/URI/File-ReadBackwards-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
+# Module Build
BuildRequires: perl(ExtUtils::MakeMaker)
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(strict)
+BuildRequires: perl(Symbol)
+BuildRequires: perl(vars)
+# Test Suite
+BuildRequires: perl(Config)
+BuildRequires: perl(File::Temp)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This module reads a file backwards line by line. It is simple to use,
@@ -21,18 +32,14 @@ interface.
%setup -q -n File-ReadBackwards-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
make test
@@ -41,12 +48,23 @@ make test
rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/File/
+%{_mandir}/man3/File::ReadBackwards.3pm*
%changelog
+* Fri Oct 4 2013 Paul Howarth p...@city-fan.org - 1.05-1
+- Update to 1.05
+ - Re-ordered Changes to be recent at the top
+ - Rewritten t/large_file.t to skip non-sparse file systems
+- Specify all dependencies
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Don't need to remove empty directories from the buildroot
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Don't use macros for commands
+- Improve %%summary
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.04-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 118d7c8..2652b15 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bda339c8b2e5139649cb28c4b775fb42 File-ReadBackwards-1.04.tar.gz
+613d9d02de6c1d86d5fa5b8816a6b214 File-ReadBackwards-1.05.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-File-ReadBackwards/f20] Update to 1.05
Summary of changes: 9073f73... Update to 1.05 (*) (*) 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-File-ReadBackwards] Created tag perl-File-ReadBackwards-1.05-1.fc21
The lightweight tag 'perl-File-ReadBackwards-1.05-1.fc21' was created pointing to: 9073f73... Update to 1.05 -- 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-File-ReadBackwards] Created tag perl-File-ReadBackwards-1.05-1.fc20
The lightweight tag 'perl-File-ReadBackwards-1.05-1.fc20' was created pointing to: 9073f73... Update to 1.05 -- 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-File-Sync] Update to 0.11
commit aa1d33cc6f036a9a5e669712385382f682775858
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 4 10:52:58 2013 +0100
Update to 0.11
- New upstream release 0.11
- Support for fdatasync()
- Stop clobbering IO::Handle::fsync (CPAN RT#50418)
- This release by BRIANSKI - update source URL
- Specify all dependencies
- Re-code documentation as UTF-8
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't need to remove empty directories from the buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Don't use macros for commands
.gitignore |2 +-
File-Sync-UTF8.patch | 11
perl-File-Sync.spec | 63 +++--
sources |2 +-
4 files changed, 58 insertions(+), 20 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d0154f5..3666bfe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-File-Sync-0.09.tar.gz
+/File-Sync-[0-9.]*.tar.gz
diff --git a/File-Sync-UTF8.patch b/File-Sync-UTF8.patch
new file mode 100644
index 000..fcaef6b
--- /dev/null
+++ b/File-Sync-UTF8.patch
@@ -0,0 +1,11 @@
+--- README
README
+@@ -36,7 +36,7 @@
+ Thanks to David Muir Sharnoff for getting me to actually work out what
+ was going on and fix my code.
+
+-All files contained in this installation are copyright � 1996,1997,1999
++All files contained in this installation are copyright © 1996,1997,1999
+ Carey Evans except for parts from the Perl distribution. All rights
+ reserved.
+
diff --git a/perl-File-Sync.spec b/perl-File-Sync.spec
index 3bc6073..e1665c5 100644
--- a/perl-File-Sync.spec
+++ b/perl-File-Sync.spec
@@ -1,14 +1,30 @@
Name: perl-File-Sync
-Version:0.09
-Release:18%{?dist}
+Version:0.11
+Release:1%{?dist}
Summary:Perl access to fsync() and sync() function calls
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/File-Sync/
-Source0:
http://www.cpan.org/authors/id/C/CE/CEVANS/File-Sync-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/B/BR/BRIANSKI/File-Sync-%{version}.tar.gz
+Patch0: File-Sync-UTF8.patch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+# Module Build
+BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(Getopt::Long)
+# Module Runtime
+BuildRequires: perl(AutoLoader)
+BuildRequires: perl(Carp)
+BuildRequires: perl(DynaLoader)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(strict)
+BuildRequires: perl(Symbol)
+BuildRequires: perl(vars)
+# Test Suite
+BuildRequires: perl(FileHandle)
+BuildRequires: perl(POSIX)
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
The fsync() function takes a Perl file handle as its only argument, and
@@ -18,20 +34,19 @@ or true on success.
%prep
%setup -q -n File-Sync-%{version}
+# re-code documentation as UTF-8
+%patch0
+
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
make test
@@ -40,13 +55,25 @@ make test
rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorarch}/auto/*
-%{perl_vendorarch}/File*
-%{_mandir}/man3/*
+%{perl_vendorarch}/auto/File/
+%{perl_vendorarch}/File/
+%{_mandir}/man3/File::Sync.3pm*
%changelog
+* Fri Oct 4 2013 Paul Howarth p...@city-fan.org - 0.11-1
+- Update to 0.11
+ - Support for fdatasync()
+ - Stop clobbering IO::Handle::fsync (CPAN RT#50418)
+- This release by BRIANSKI - update source URL
+- Specify all dependencies
+- Re-code documentation as UTF-8
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Don't need to remove empty directories from the buildroot
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Don't use macros for commands
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.09-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
@@ -72,7 +99,7 @@ rm -rf $RPM_BUILD_ROOT
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-10
-- 661697 rebuild for fixing problems with vendorach/lib
[perl-File-Sync/f20] Update to 0.11
Summary of changes: aa1d33c... Update to 0.11 (*) (*) 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-File-Sync] Created tag perl-File-Sync-0.11-1.fc20
The lightweight tag 'perl-File-Sync-0.11-1.fc20' was created pointing to: aa1d33c... Update to 0.11 -- 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-File-Sync] Created tag perl-File-Sync-0.11-1.fc21
The lightweight tag 'perl-File-Sync-0.11-1.fc21' was created pointing to: aa1d33c... Update to 0.11 -- 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 1010057] `perldoc perldoc`: No documentation found for perldoc.
https://bugzilla.redhat.com/show_bug.cgi?id=1010057 Gerd Pokorra g...@zimt.uni-siegen.de changed: What|Removed |Added CC||g...@zimt.uni-siegen.de --- Comment #4 from Gerd Pokorra g...@zimt.uni-siegen.de --- I configured the current stable perl source (5.18.1) with: ./configure.gnu --prefix=/home/blabla/install and installed it (make install). The following works: For command output: /home/blabla/install/bin/perldoc perldoc For Perl5 module output: /home/blabla/install/bin/perldoc Pod::Perldoc This doesn't work: /home/blabla/install/bin/perldoc Pod::Perldoc No documentation found for Pod::perldoc. documentation as a Perl Utility perldoc: http://perldoc.perl.org/index-utilities.html - http://perldoc.perl.org/perldoc.html documentation as a Perl Module Pod::Perldoc: http://search.cpan.org/~mallen/Pod-Perldoc-3.20/lib/Pod/Perldoc.pm -- 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=RdbatCDEB4a=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 1010057] `perldoc perldoc`: No documentation found for perldoc.
https://bugzilla.redhat.com/show_bug.cgi?id=1010057 --- Comment #5 from Gerd Pokorra g...@zimt.uni-siegen.de --- Sorry: This doesn't work: /home/blabla/install/bin/perldoc Pod::perldoc No documentation found for Pod::perldoc. -- 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=Z3qCxH7XAIa=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 HTTP-BrowserDetect-1.61.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-HTTP-BrowserDetect: 4364dacdebe63b9bc678e6f2360bd9b5 HTTP-BrowserDetect-1.61.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-HTTP-BrowserDetect] Update to 1.61
commit dd8b89e7e1284aa164412460a3559ba3959f0445
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 4 11:55:29 2013 +0100
Update to 1.61
- Update to 1.61 (see Changes for details)
- Specify all dependencies
- Package CONTRIBUTORS file
- Recode documentation as UTF-8
- Remove spurious exec permission from perl module file
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Drop redundant %{?perl_default_filter}
- Don't need to remove empty directories from the buildroot
- Don't use macros for commands
.gitignore|3 +-
HTTP-BrowserDetect-UTF8.patch | 11 +++
perl-HTTP-BrowserDetect.spec | 62 +
sources |2 +-
4 files changed, 57 insertions(+), 21 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 258ad9f..75ad80d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-HTTP-BrowserDetect-1.10.tar.gz
-/HTTP-BrowserDetect-1.21.tar.gz
+/HTTP-BrowserDetect-[0-9.]*.tar.gz
diff --git a/HTTP-BrowserDetect-UTF8.patch b/HTTP-BrowserDetect-UTF8.patch
new file mode 100644
index 000..515a77d
--- /dev/null
+++ b/HTTP-BrowserDetect-UTF8.patch
@@ -0,0 +1,11 @@
+--- CONTRIBUTORS
CONTRIBUTORS
+@@ -15,7 +15,7 @@
+ * Olaf Alders o...@wundersolutions.com
+ * Olivier Bilodeau oliv...@bottomlesspit.org
+ * Paul Findlay p...@findlay.net.nz
+- * Robin Smidsr�d ro...@smidsrod.no
++ * Robin Smidsrød ro...@smidsrod.no
+ * Ronald J Kimball rkimb...@pangeamedia.com
+ * Surikov Alexey surikov@alexey-pc.kiteventures.local
+ * Thom Blake t...@odonnellpdc.com
diff --git a/perl-HTTP-BrowserDetect.spec b/perl-HTTP-BrowserDetect.spec
index 3933dda..afa01fa 100644
--- a/perl-HTTP-BrowserDetect.spec
+++ b/perl-HTTP-BrowserDetect.spec
@@ -1,20 +1,32 @@
Name: perl-HTTP-BrowserDetect
Summary:Determine the Web browser, version, and platform from an HTTP
user agent string
-Version:1.21
-Release:9%{?dist}
+Version:1.61
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTTP-BrowserDetect/
Source0:
http://www.cpan.org/authors/id/O/OA/OALDERS/HTTP-BrowserDetect-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Patch0: HTTP-BrowserDetect-UTF8.patch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
-BuildRequires: perl(Data::Dump)
+# Module Build
+BuildRequires: perl(Module::Build) 0.36
+# Module Runtime
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+# Test Suite
+BuildRequires: perl(File::Slurp)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(JSON::PP)
BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Most)
+BuildRequires: perl(Test::FailWarnings)
+BuildRequires: perl(Test::NoWarnings)
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+BuildRequires: perl(Data::Dump)
BuildRequires: perl(YAML)
-BuildRequires: perl(Module::Build)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-
-%{?perl_default_filter}
%description
The HTTP::BrowserDetect object does a number of tests on an HTTP user agent
@@ -26,17 +38,20 @@ at
http://www.mozilla.org/docs/web-developer/sniffer/browser_type.html.
%prep
%setup -q -n HTTP-BrowserDetect-%{version}
+# Recode documentation as UTF-8
+%patch0
+
+# Remove spurious exec permission
+chmod -c -x lib/HTTP/BrowserDetect.pm
+
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
-
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
./Build test
@@ -45,12 +60,23 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root,-)
-%doc Changes LICENSE README TODO
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes CONTRIBUTORS LICENSE README TODO
+%{perl_vendorlib}/HTTP/
+%{_mandir}/man3/HTTP::BrowserDetect.3pm*
%changelog
+* Fri Oct 4 2013 Paul Howarth p...@city-fan.org - 1.61-1
+- Update to 1.61 (see Changes for details)
+- Specify all dependencies
+- Package CONTRIBUTORS file
+- Recode documentation as UTF-8
+- Remove spurious exec permission from perl module file
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Drop redundant %%{?perl_default_filter}
+- Don't need to remove empty directories from the buildroot
+- Don't use macros for commands
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.21-9
- Rebuilt for
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the F-20 tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the rawhide tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the rawhide tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the rawhide tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the rawhide tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the rawhide tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
