Skychart broken in rawhide and F17, unable to fix
Greetings, I maintain package Skychart that requires Lazarus as Buildrequires. Lazarus is currently broken in F17 and has broken functionality in rawhide, see bug #799504 [1]. Short story is: 1. Lazarus must be updated to 0.9.30.4 to work with glib2 = 2.31 (F17 and higher) 2. Lazarus must be rebuilt against fpc 2.6 (in rawhide is already done with lazarus 0.9.30.2, but in F17 lazarus is still broken beacuse it was built with fpc 2.4.2) Current lazarus maintainer seems to have no hurry to fix this problem... I also asked him to give me commit rights in pkgdb to fix this myself (it's just matter of upload new source and change version in spec file, no special abilities required, I made it locally in 10 minutes), but seems he doesn't want to do that (no response on this neither). I cannot start the unresponsive package maintainer policy because the package maintainer replied that he will do the upgrade, but when?? So what can I do other than waiting for the fix? Skychart is completely unusable at the moment in F17 and rawhide and I cannot fix it until Lazarus will be updated... is there something that provenpackagers can do about this? Thank you [1] https://bugzilla.redhat.com/show_bug.cgi?id=799504 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
Horst H. von Brand wrote: keeping generated files in git is just dumb. +1, but IMHO this is true even without the in git addition. Generated files also have no business being in a source tarball, and IMHO the fact that the autotools get that wrong entirely disqualifies them from being a usable build system. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Skychart broken in rawhide and F17, unable to fix
Mattia Verga wrote: I cannot start the unresponsive package maintainer policy because the package maintainer replied that he will do the upgrade, but when?? IMHO, give the maintainer some limited time (say, 2 weeks) to do the upgrade and the rebuild for F17, and start unresponsive maintainer if he doesn't comply. It's not just an upgrade to be done at the maintainer's discretion, it's actually required to fix showstopper bugs, so it should count as an urgent bugfix. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120415 changes
Compose started at Sun Apr 15 08:15:03 UTC 2012 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [ale] ale-0.9.0.3-6.fc17.x86_64 requires libMagickCore.so.4()(64bit) [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [cuneiform] cuneiform-1.1.0-6.fc17.i686 requires libMagick++.so.4 cuneiform-1.1.0-6.fc17.x86_64 requires libMagick++.so.4()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dmapd] dmapd-0.0.47-2.fc17.i686 requires libMagickWand.so.4 dmapd-0.0.47-2.fc17.i686 requires libMagickCore.so.4 dmapd-0.0.47-2.fc17.x86_64 requires libMagickWand.so.4()(64bit) dmapd-0.0.47-2.fc17.x86_64 requires libMagickCore.so.4()(64bit) [dogtag-pki] dogtag-pki-9.0.0-10.fc17.noarch requires pki-util-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-util = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-tks = 0:9.0.9 dogtag-pki-9.0.0-10.fc17.noarch requires pki-symkey = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-silent = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-setup = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-selinux = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-ocsp = 0:9.0.9 dogtag-pki-9.0.0-10.fc17.noarch requires pki-native-tools = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-kra = 0:9.0.10 dogtag-pki-9.0.0-10.fc17.noarch requires pki-java-tools-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-java-tools = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-common-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-common = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-ca = 0:9.0.18 [drawtiming] drawtiming-0.7.1-5.fc17.x86_64 requires libMagickCore.so.4()(64bit) drawtiming-0.7.1-5.fc17.x86_64 requires libMagick++.so.4()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [dx] dx-4.4.4-21.fc17.x86_64 requires libMagickCore.so.4()(64bit) dx-libs-4.4.4-21.fc17.i686 requires libMagickCore.so.4 dx-libs-4.4.4-21.fc17.x86_64 requires libMagickCore.so.4()(64bit) [egoboo] egoboo-2.7.5-11.fc17.x86_64 requires libenet-1.2.1.so()(64bit) [entangle] entangle-0.3.2-1.fc17.x86_64 requires libgexiv2.so.0()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-gucharmap] ibus-gucharmap-1.4.0-4.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-2.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-2.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [imageinfo] imageinfo-0.05-14.fc17.x86_64 requires libMagickCore.so.4()(64bit) [inkscape] inkscape-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) [jboss-as] jboss-as-7.1.0-2.fc17.noarch requires slf4j-jboss-logmanager [k3d] k3d-0.8.0.2-6.fc17.i686 requires libMagickCore.so.4 k3d-0.8.0.2-6.fc17.i686 requires libMagick++.so.4 k3d-0.8.0.2-6.fc17.x86_64 requires libMagickCore.so.4()(64bit) k3d-0.8.0.2-6.fc17.x86_64 requires libMagick++.so.4()(64bit) [kxstitch] kxstitch-0.8.4.1-8.fc17.x86_64 requires libMagickCore.so.4()(64bit)
Re: Skychart broken in rawhide and F17, unable to fix
I waited for a month, I will wait another week... I don't want to kick anyone and I'm not completely sure I can be the right person to fully maintain Lazarus package. But I'm able to do the update this time. Being co-maintainer would be better. Il 15/04/2012 12:36, Kevin Kofler ha scritto: Mattia Verga wrote: I cannot start the unresponsive package maintainer policy because the package maintainer replied that he will do the upgrade, but when?? IMHO, give the maintainer some limited time (say, 2 weeks) to do the upgrade and the rebuild for F17, and start unresponsive maintainer if he doesn't comply. It's not just an upgrade to be done at the maintainer's discretion, it's actually required to fix showstopper bugs, so it should count as an urgent bugfix. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?
On Fri, Apr 13, 2012 at 10:26:06AM -0400, Daniel J Walsh wrote: Trying to fix all apps that could include confidential data from Programmer Debugging tools which are a very small percentage of users use, is just crazy. It isn't just debugging tools that would break, also things like wine, the java tools, performance and tracing tools, etc. And even if they were a small percentage of the users, it is an important part of Fedora. It would set an extremely bad precedent if we would make it harder for users to be programmers. We now have a feature for those who care about security that can stop any process on the system from reading/modifying the memory of any other process on the system. If sysadmins want to take advantage of this they can, If they do not then can turn it off. It is good to have the feature. It is just crazy to turn it on by default as long as that means breaking a normal install. We already have solutions for the most important security sensitive programs like gnome-keytools and ssh-agent. We don't have to go for perfect security as long as there is no satisfactory solution to just clobbering normal functionality for all users (and make then unbreak their machines and/or disable selinux for good, which IMHO would be a bad thing). Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Skychart broken in rawhide and F17, unable to fix
On Sun, 15 Apr 2012 13:43:19 +0200, MV (Mattia) wrote: I waited for a month, I will wait another week... I don't want to kick anyone and I'm not completely sure I can be the right person to fully maintain Lazarus package. But I'm able to do the update this time. Being co-maintainer would be better. Agreed. It's true that your pkgdb requests have been done months ago (on Jan 21st), and I find it inacceptable that the maintainer ignores them like this and ignores your comment about it in bugzilla #799504, too. :-/ At a minimum, a maintainer should accept or reject pkgdb requests in a timely manner, giving the rationale. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.1-5.fc17.x86_64 loadavg: 0.02 0.07 0.06 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
Frank Ch. Eigler f...@redhat.com wrote: Horst H. von Brand vonbr...@inf.utfsm.cl writes: [...] Please go with (3), keeping generated files in git is just dumb. Please don't demean those who do it for well-considered reasons. I'm sorry if it came through too abrasive, but I just can't see a reason for keeping autogenerated files under git. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
14.04.2012 20:44, Reindl Harald wrote: Am 14.04.2012 18:39, schrieb Richard W.M. Jones: On Sat, Apr 14, 2012 at 06:21:15PM +0200, drago01 wrote: On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jonesrjo...@redhat.com wrote: I'm not arguing that's how yum works now, but it doesn't have to work that way! It could incrementally download the RPMs during depsolving, test that they work together, and with that information download further packages as necessary ... Ugh no ... the whole point of the repodata is to avoid having to download the rpms to calculate deps. Well the whole point is to get the best possible software quality, user experience and performance (accepting that we cannot maximize all of these at the same time). It's my personal opinion that yum does not do well on any of these three criteria. and you think performance and user experience will get better by downloading packages for dep-solve? are you aware that many people do not have endless bandwith, traffic-limuts and storage and can you imagine how slow this all would be? yum should not waste ressources which i did even in the recent past by consuming wy too much memory resulting get killed from oom-killer on machines with 512 MB RAM and yes, 512 MB RAM are really enough for many servers and there is no argumentation for a UPDATER eating more ressources as the whole server in normal operations What the point always store it in XML or Sqlite static files instead of provide service on server side to speedup solving? Off course it may require some script running on server side to provide such service and some limit mirroring (there may be fallback to old scheme), but also it may have many benefits: 1) On server side metadata may be any size, optimized for inner use if it will not intended to transfer each time. 2) It may be cached. 3) Clients may ask only small parts of data, which is most cases is what wanted. As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Review request: https://bugzilla.redhat.com/show_bug.cgi?id=812659 Sponsor needed. I'm a long-time open source contributor, notably to ACEhttp://www.cs.wustl.edu/~schmidt/ACE.html and nmh http://savannah.nongnu.org/projects/nmh/. Some nmh developers and users would like to see a parhttp://www.nicemice.net/par/ package on Fedora. I volunteered to shepherd par through the process. I expect that it will be relatively easy: there are only four files in the RPM. par has been around a long time and has a small but very dedicated user base. Thanks for any assistance you can provide. David Levine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder: Fedora password and ssh key change deadline looms (2 days left!)
Kevin I am trying to get my account back in order how do i get it re-activated. Mark Rader On Mon, Nov 28, 2011 at 12:52 PM, Kevin Fenzi ke...@scrye.com wrote: Just a friendly reminder: If you are a Fedora account system account holder, and haven't changed your password and uploaded a new ssh key since we announced the mandatory change, you best do so NOW. The deadline is 2011-11-30 (only 2 days away). http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html If you don't, you may no longer have access to groups you currently do (like packager, or sysadmin or ambassador). Go take a few minutes, read the announcement and security information linked to it, and change your password and upload a new ssh public key. If you aren't a Fedora contributor, the information linked in our announcement is still a great read and may just help you be more secure on your machines. :) kevin ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
On Sun, Apr 15, 2012 at 11:16:58PM +0400, Pavel Alexeev wrote: As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. I don't think this would be a speedup. Instead of the CPUs of tens of thousands of computers doing the depsolving, you'd be requiring the CPUs of a single site to do it. The clients would have to upload, the provides of their installed packages so bandwidth needs might increase. If I was installing a few packages by trial and error/memory I'd likely do yum install tmux followed closely by yum install zsh, which would require separate requests to the server to download separate dependency information as opposed to having the information downloaded once. The server that constructs the subsets of repodata would become single point of failures whereas currently the repodata can be hosted on any mirror. This setup would be much more sensitive to mirrors and repodata going out of sync. There'd likely be times when a new push has gone out where the primary mirror was the only server which could push packages out as every other mirror would be out of sync wrt the repodata server. -Toshio pgpkF1zKzarex.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
Ralf Corsepius wrote: You guys seem to be unable to comprehend the differences between generated sources and generated intermediate files. generated sources is an oxymoron. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder: Fedora password and ssh key change deadline looms (2 days left!)
On Sun, 15 Apr 2012 15:45:19 -0500 Mark Rader msra...@gmail.com wrote: Kevin I am trying to get my account back in order how do i get it re-activated. Simply go to: https://admin.fedoraproject.org/accounts/user/resetpass and reset your password and upload a new ssh public key (if you have need to upload one). Mark Rader kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
16.04.2012 00:51, Toshio Kuratomi wrote: On Sun, Apr 15, 2012 at 11:16:58PM +0400, Pavel Alexeev wrote: As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. I don't think this would be a speedup. Instead of the CPUs of tens of thousands of computers doing the depsolving, you'd be requiring the CPUs of a single site to do it. Yes. And as many clients do the same work, caching will give there good results. So, sequence requests will costs nothing. The clients would have to upload, the provides of their installed packages so bandwidth needs might increase. If I was installing a few packages by trial and error/memory I'd likely do yum install tmux followed closely by yum install zsh, which would require separate requests to the server to download separate dependency information as opposed to having the information downloaded once. If you request yum install tmux zsh off course it should be sent and calculated on server in one request. Also caching answers on client side not forbidden. The server that constructs the subsets of repodata would become single point of failures whereas currently the repodata can be hosted on any mirror. This setup would be much more sensitive to mirrors and repodata going out of sync. There'd likely be times when a new push has gone out where the primary mirror was the only server which could push packages out as every other mirror would be out of sync wrt the repodata server. Yes, as I wrote initially it introduce more requirements to the server, especially some sort of scripting allowed (php, perl, python, ruby or other). But at all it is not exclude mirroring as it is free software and any ma install it, and sync metadata information in traditional way. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bug or feature? gdm logins not recorded in lastlog
Before I generate a bug report, could I get a second opinion on whether this is a bug or a feature? Console logins through gdm are not getting recorded in lastlog. (Fedora 16) John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for tomorrow's FESCo Meeting (2012-04-16)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #833 Clarify provenpackagers communication policy for making changes to packages .fesco 833 #topic #830 define requirements for secondary arch promotion .fesco 830 = New business = #topic #829 New proven packagers request: Pavel Alexeev (hubbitus) .fesco 829 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
On Mon, Apr 16, 2012 at 02:02:31AM +0400, Pavel Alexeev wrote: 16.04.2012 00:51, Toshio Kuratomi wrote: On Sun, Apr 15, 2012 at 11:16:58PM +0400, Pavel Alexeev wrote: As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. I don't think this would be a speedup. Instead of the CPUs of tens of thousands of computers doing the depsolving, you'd be requiring the CPUs of a single site to do it. Yes. And as many clients do the same work, caching will give there good results. So, sequence requests will costs nothing. No. Most requests will be different because they have a different initial state. The clients would have to upload, the provides of their installed packages so bandwidth needs might increase. If I was installing a few packages by trial and error/memory I'd likely do yum install tmux followed closely by yum install zsh, which would require separate requests to the server to download separate dependency information as opposed to having the information downloaded once. If you request yum install tmux zsh off course it should be sent and calculated on server in one request. Also caching answers on client side not forbidden. But I was saying that I often do yum install zsh followed by yum install tmux as I notice things that I've forgotten to install on a machine I'm starting to work on. Similarly, yum install libfoo-devel followed by yum install libbar-devel as I'm pulling the dependencies for a new piece of software I'm building or developing. Caching on the client won't help if what we're caching is only a partial piece of the repodata. The server that constructs the subsets of repodata would become single point of failures whereas currently the repodata can be hosted on any mirror. This setup would be much more sensitive to mirrors and repodata going out of sync. There'd likely be times when a new push has gone out where the primary mirror was the only server which could push packages out as every other mirror would be out of sync wrt the repodata server. Yes, as I wrote initially it introduce more requirements to the server, especially some sort of scripting allowed (php, perl, python, ruby or other). But at all it is not exclude mirroring as it is free software and any ma install it, and sync metadata information in traditional way. If you're requiring that mirrors run the script on their systems, then that makes this idea pretty much a non-starter. We've been told by mirrors that they do not want to do this. -Toshio pgprTBgY2jH6j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Test-CPAN-Meta-YAML-0.18.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-CPAN-Meta-YAML: b2dd3c631ce17edd6b37a70872c9789c Test-CPAN-Meta-YAML-0.18.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-Test-CPAN-Meta-YAML] Update to 0.18
commit 2d8ca496a7f1baeb1257da15c29c0be27fbf9fb5
Author: Paul Howarth p...@city-fan.org
Date: Sun Apr 15 13:58:22 2012 +0100
Update to 0.18
- New upstream release 0.18
- CPAN RT#74317: Imported url validation from CPAN::Meta
- CPAN RT#66692: Updated license type
- Updates to examples
- Update UTF8 patch
- Don't need to remove empty directories from buildroot
- Don't use macros for commands
- Drop %defattr, redundant since rpm 4.4
.gitignore |2 +-
Test-CPAN-Meta-YAML-0.17-utf8.patch | 10 --
Test-CPAN-Meta-YAML-0.18-utf8.patch | 10 ++
perl-Test-CPAN-Meta-YAML.spec | 24
sources |2 +-
5 files changed, 28 insertions(+), 20 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index be702fd..8729c34 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Test-CPAN-Meta-YAML-0.17.tar.gz
+/Test-CPAN-Meta-YAML-[0-9.]*.tar.gz
diff --git a/Test-CPAN-Meta-YAML-0.18-utf8.patch
b/Test-CPAN-Meta-YAML-0.18-utf8.patch
new file mode 100644
index 000..ab0e415
--- /dev/null
+++ b/Test-CPAN-Meta-YAML-0.18-utf8.patch
@@ -0,0 +1,10 @@
+--- LICENSE
LICENSE
+@@ -1,6 +1,6 @@
+ LICENSE FOR Test-CPAN-Meta-YAML
+
+-This software is copyright � 2007-2012 Barbie for Miss Barbell Productions.
++This software is copyright © 2007-2012 Barbie for Miss Barbell Productions.
+
+ This library is free software; you can redistribute it and/or modify
+ it under the terms of the Artistic License 2.0.
diff --git a/perl-Test-CPAN-Meta-YAML.spec b/perl-Test-CPAN-Meta-YAML.spec
index 069feae..e4f1e5c 100644
--- a/perl-Test-CPAN-Meta-YAML.spec
+++ b/perl-Test-CPAN-Meta-YAML.spec
@@ -1,13 +1,13 @@
Name: perl-Test-CPAN-Meta-YAML
-Version: 0.17
-Release: 4%{?dist}
+Version: 0.18
+Release: 1%{?dist}
Summary: Validate a META.yml file within a CPAN distribution
Group: Development/Libraries
License: Artistic 2.0
URL: http://search.cpan.org/dist/Test-CPAN-Meta-YAML/
Source0:
http://search.cpan.org/CPAN/authors/id/B/BA/BARBIE/Test-CPAN-Meta-YAML-%{version}.tar.gz
-Patch0:Test-CPAN-Meta-YAML-0.17-utf8.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Patch0:Test-CPAN-Meta-YAML-0.18-utf8.patch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Builder)
@@ -17,7 +17,7 @@ BuildRequires:perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(Test::YAML::Valid) = 0.03
BuildRequires: perl(YAML::Syck)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
# Explicitly requests the YAML::Syck backend for Test::YAML::Valid
Requires: perl(YAML::Syck)
@@ -33,7 +33,7 @@ See CPAN::Meta for further details of the CPAN Meta
Specification.
%setup -q -n Test-CPAN-Meta-YAML-%{version}
# Recode LICENSE as UTF-8
-%patch0 -p1
+%patch0
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -43,7 +43,6 @@ make %{?_smp_mflags}
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} \; 2/dev/null
%{_fixperms} %{buildroot}
%check
@@ -53,13 +52,22 @@ make test AUTOMATED_TESTING=1
rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/Test/
%{_mandir}/man3/Test::CPAN::Meta::YAML.3pm*
%{_mandir}/man3/Test::CPAN::Meta::YAML::Version.3pm*
%changelog
+* Sun Apr 15 2012 Paul Howarth p...@city-fan.org - 0.18-1
+- Update to 0.18
+ - CPAN RT#74317: Imported url validation from CPAN::Meta
+ - CPAN RT#66692: Updated license type
+ - Updates to examples
+- Update UTF8 patch
+- Don't need to remove empty directories from buildroot
+- Don't use macros for commands
+- Drop %%defattr, redundant since rpm 4.4
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.17-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 6ea3f27..4ba3457 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b22c1b552401192cbb6a9a92a961e397 Test-CPAN-Meta-YAML-0.17.tar.gz
+b2dd3c631ce17edd6b37a70872c9789c Test-CPAN-Meta-YAML-0.18.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-Test-CPAN-Meta-YAML/f17] Update to 0.18
Summary of changes: 2d8ca49... Update to 0.18 (*) (*) 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-Test-CPAN-Meta-YAML] Created tag perl-Test-CPAN-Meta-YAML-0.18-1.fc17
The lightweight tag 'perl-Test-CPAN-Meta-YAML-0.18-1.fc17' was created pointing to: 2d8ca49... Update to 0.18 -- 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-Test-CPAN-Meta-YAML] Created tag perl-Test-CPAN-Meta-YAML-0.18-1.fc18
The lightweight tag 'perl-Test-CPAN-Meta-YAML-0.18-1.fc18' was created pointing to: 2d8ca49... Update to 0.18 -- 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 Test-CPAN-Meta-JSON-0.11.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-CPAN-Meta-JSON: a5056f68049d5aaae6d090ad53fcd21a Test-CPAN-Meta-JSON-0.11.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-Test-CPAN-Meta-JSON] Update to 0.11
commit 3f3cc66829c789dc6b2122c20e90368016b3e439
Author: Paul Howarth p...@city-fan.org
Date: Sun Apr 15 14:20:17 2012 +0100
Update to 0.11
- New upstream release 0.11
- CPAN RT#74317: imported url validation from CPAN::Meta
- CPAN RT#66692: updated license type
- Updates to examples
- BR: perl(Test::CPAN::Meta) rather than perl(Test::CPAN::Meta::YAML)
- Don't need to remove empty directories from buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Drop %defattr, redundant since rpm 4.4
perl-Test-CPAN-Meta-JSON.spec | 20 ++--
sources |2 +-
2 files changed, 15 insertions(+), 7 deletions(-)
---
diff --git a/perl-Test-CPAN-Meta-JSON.spec b/perl-Test-CPAN-Meta-JSON.spec
index 7f71b84..dce1202 100644
--- a/perl-Test-CPAN-Meta-JSON.spec
+++ b/perl-Test-CPAN-Meta-JSON.spec
@@ -1,6 +1,6 @@
Name: perl-Test-CPAN-Meta-JSON
-Version: 0.10
-Release: 3%{?dist}
+Version: 0.11
+Release: 1%{?dist}
Summary: Validate a META.json file within a CPAN distribution
Group: Development/Libraries
License: Artistic 2.0
@@ -14,7 +14,7 @@ BuildRequires:perl(IO::File)
BuildRequires: perl(JSON) = 2.15
BuildRequires: perl(Test::Builder)
BuildRequires: perl(Test::Builder::Tester)
-BuildRequires: perl(Test::CPAN::Meta::YAML)
+BuildRequires: perl(Test::CPAN::Meta)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
@@ -40,9 +40,8 @@ make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} \; 2/dev/null
%{_fixperms} %{buildroot}
%check
@@ -52,13 +51,22 @@ make test AUTOMATED_TESTING=1
rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
%doc Changes LICENSE README examples/
%{perl_vendorlib}/Test/
%{_mandir}/man3/Test::CPAN::Meta::JSON.3pm*
%{_mandir}/man3/Test::CPAN::Meta::JSON::Version.3pm*
%changelog
+* Sun Apr 15 2012 Paul Howarth p...@city-fan.org - 0.11-1
+- Update to 0.11
+ - CPAN RT#74317: imported url validation from CPAN::Meta
+ - CPAN RT#66692: updated license type
+ - Updates to examples
+- BR: perl(Test::CPAN::Meta) rather than perl(Test::CPAN::Meta::YAML)
+- Don't need to remove empty directories from buildroot
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Drop %%defattr, redundant since rpm 4.4
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.10-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 739228f..2f2e6e4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9eef3f20cc2b080ae6e15a75d8ede59f Test-CPAN-Meta-JSON-0.10.tar.gz
+a5056f68049d5aaae6d090ad53fcd21a Test-CPAN-Meta-JSON-0.11.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-Test-CPAN-Meta-JSON/f17] Update to 0.11
Summary of changes: 3f3cc66... 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-Test-CPAN-Meta-JSON] Created tag perl-Test-CPAN-Meta-JSON-0.11-1.fc17
The lightweight tag 'perl-Test-CPAN-Meta-JSON-0.11-1.fc17' was created pointing to: 3f3cc66... 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-Test-CPAN-Meta-JSON] Created tag perl-Test-CPAN-Meta-JSON-0.11-1.fc18
The lightweight tag 'perl-Test-CPAN-Meta-JSON-0.11-1.fc18' was created pointing to: 3f3cc66... 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
Broken dependencies: perl-RPM2
perl-RPM2 has broken dependencies in the rawhide tree: On x86_64: perl-RPM2-1.0-2.fc17.x86_64 requires librpmio.so.2()(64bit) perl-RPM2-1.0-2.fc17.x86_64 requires librpm.so.2()(64bit) On i386: perl-RPM2-1.0-2.fc17.i686 requires librpmio.so.2 perl-RPM2-1.0-2.fc17.i686 requires librpm.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
