Re: Question about dist-cvs make targets
On Thu, Jan 07, 2010 at 09:28:26AM -0800, Jesse Keating wrote: As I proceed to port our make system over into fedpkg, I've ran across a couple targets that are giving me pause. Is anybody out there making use of the following targets? check export patch unused-patches unused-fedora-patches If so, please reply to which one, and in what scenario you use those targets. Thanks! I used 'unused-patches' every now then to quickly check which patches are obsolete - it is easier than doing it by hand in packages which have more than 10 patches applied. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Test-YAML-Meta/devel .cvsignore, 1.4, 1.5 perl-Test-YAML-Meta.spec, 1.7, 1.8 sources, 1.4, 1.5
Author: berrange
Update of /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16994
Modified Files:
.cvsignore perl-Test-YAML-Meta.spec sources
Log Message:
Update to 0.15 release
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel/.cvsignore,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- .cvsignore 22 Jul 2009 19:21:02 - 1.4
+++ .cvsignore 7 Jan 2010 09:11:34 - 1.5
@@ -1,3 +1,3 @@
.build*.log
*.rpm
-Test-YAML-Meta-0.12.tar.gz
+Test-YAML-Meta-0.15.tar.gz
Index: perl-Test-YAML-Meta.spec
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel/perl-Test-YAML-Meta.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-Test-YAML-Meta.spec4 Dec 2009 02:16:55 - 1.7
+++ perl-Test-YAML-Meta.spec7 Jan 2010 09:11:34 - 1.8
@@ -1,6 +1,6 @@
Name: perl-Test-YAML-Meta
-Version:0.12
-Release:3%{?dist}
+Version:0.15
+Release:1%{?dist}
Summary:Validation of the META.yml file in a distribution
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3pm*
%changelog
+* Thu Jan 7 2010 Daniel P. Berrange berra...@redhat.com - 0.15-1
+- Update to 0.15 release
+
* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 0.12-3
- rebuild against perl 5.10.1
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 22 Jul 2009 19:21:02 - 1.4
+++ sources 7 Jan 2010 09:11:35 - 1.5
@@ -1 +1 @@
-66fc4d551ad6c650ab8f80b2928eadf6 Test-YAML-Meta-0.12.tar.gz
+7eca7287b16e4a11ff9db70c2b753689 Test-YAML-Meta-0.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Our static Libraries packaging guidelines once more
On Wed, Jan 06, 2010 at 01:57:14PM +, Adam Williamson wrote: On Tue, 2010-01-05 at 12:16 -0500, Tom spot Callaway wrote: Well, I think a reasonable alternative would be to add those policies to the AutoQA infrastructure, and if the package fails the check, it doesn't get tagged and the packager gets an email explaining the failure. That will get things fixed up. ;) The only problem with that is that just about every packaging guideline has _some_ valid exceptions (that's why they're all guidelines...) and it's rather hard to build exceptions into an automatic testing system in a way which doesn't get horribly crufty in a hurry. But yes, broadly I'm in favour of this kind of thing. Mandriva does it to a limited extent (a few rpmlint checks are run on submitted packages and certain failures cause the package to be rejected) and it does stop people making really bad mistakes. At time of the initial package review, the packager has to justify the exception to the reviewer. Post-package review packager can do whatever they want. The lack of ongoing analysis of packaging changes post-review is a hole in our process. If we decided to turn a certain subset of the guidelines into hard rules, then we'd want a way to record per-package exceptions in AutoQA, along with a short justification text. This tracking would ensure we know about changes/issues that arise post-review, closing that hole in our process. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Tue, Jan 05, 2010 at 06:34:12PM +0200, Panu Matilainen wrote:
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs
no longer work:
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
What exactly do you mean 'no longer work' ? Can we expect to get a formal
RPM build error for this bogus construct, or will it silently build and
do the wrong thing ? From your long description, it sounds like the latter,
which means maintainers should audit their spec files to identify these
bogus macros
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 11:48:47AM -0500, Tom spot Callaway wrote: On 01/05/2010 11:30 AM, Jesse Keating wrote: On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... Isn't that a chicken/egg problem? It really is. I mean, we could create the Packaging Police to run around and enforce the guidelines by force (either by fixing them manually, or by threatening maintainers until they do it), but is that really what we want? Not for all packaging policies, but for some I think that would be a good idea. Pick a set of policies we think are particularly important to enforce can be automatically checked, and declare any non-compliant ones will be dropped in the next fedora release unless fixed. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 12:16:13PM -0500, Tom spot Callaway wrote: On 01/05/2010 12:08 PM, Daniel P. Berrange wrote: Not for all packaging policies, but for some I think that would be a good idea. Pick a set of policies we think are particularly important to enforce can be automatically checked, and declare any non-compliant ones will be dropped in the next fedora release unless fixed. Well, I think a reasonable alternative would be to add those policies to the AutoQA infrastructure, and if the package fails the check, it doesn't get tagged and the packager gets an email explaining the failure. That will get things fixed up. ;) That sounds good as long as AutoQA is reliable, not generating false positives. I'd still also suggest that we have a rule drop all packages reported by the FTBFS tests which aren't fixed by time of Beta. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 10:38:50AM -0700, Jerry James wrote: On Tue, Jan 5, 2010 at 10:23 AM, Daniel P. Berrange berra...@redhat.com wrote: That sounds good as long as AutoQA is reliable, not generating false positives. I'd still also suggest that we have a rule drop all packages reported by the FTBFS tests which aren't fixed by time of Beta. What about packages that fail to build because they depend on some other package that is broken? I've got one in that state now. It fails to build from source because one of its BuildRequires is broken. There's nothing wrong with my package. Once the other guy fixes his, mine will magically start building again. If the other guy hasn't fixed his package by Beta, how is dropping mine going to help? It will motivate you, or someone else depending on it, to become a co-maintainer of the broken package help with fixing it ;-P In all seriousness though, it is very bad if we're having many of cases of large sets of downstream package chains being blocked by an dependant one failing. If a security issue arises in the FTBFS package we're between a rock a hard place, which is why I think it is worth being strict on fixing FTBFS bugs. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Top Crashers
On Mon, Jan 04, 2010 at 03:12:18PM +, Matthew Booth wrote: Now we have abrt making it easier for lazy people to submit crash reports, do we have enough information for a 'Top Crashers' list? It would be good to highlight these centrally to provide an incentive to give them the attention they deserve. My specific motivation for this is: https://bugzilla.redhat.com/show_bug.cgi?id=532307 This crashes daily for me and, from the evidence of the BZ traffic, a whole lot of other people too. It has also been ignored for 2 months now. Highlighting and fixing this kind of high-impact bug would be a great way to improve the quality of Fedora. You have essentially just suggested kerneloops.org, but for userspace apps. It would be very nice to have such a beast! Doing statistical analysis by extracting the ABRT reports from BZ would just be horrible. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, Dec 15, 2009 at 10:59:52AM +, Richard W.M. Jones wrote: On Tue, Dec 15, 2009 at 05:50:05AM -0500, Josh Boyer wrote: On Tue, Dec 15, 2009 at 10:34:04AM +, Richard W.M. Jones wrote: On Tue, Dec 15, 2009 at 10:06:42AM +, Tim Waugh wrote: On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: Why not put everything in a single git repository? That would require every packager to check out the entire package set, all revisions, all branches. No thanks. Jesse can probably estimate for us how large this will be. I've found that git deals very well with large repositories that have lots of files and lots of history (kernel, qemu). And you only ever have to download it once, since you can use git fetch to make local working copies. A full git repo was 5.7G. I sure as hell don't want to pull that down when I'm only interested in a few packages. (The CVS repo is 16G on the server side if you are wondering.) Fair enough - it doesn't make sense since the combined repo would be so large. I was wondering if you could set up some meta repository, which had a GIT sub-module for each package, but it seems sub-modules always have to specify an explicit commit hash so they wouldn't seemlessly follow changes. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 10:01:51AM -0600, Justin M. Forbes wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. The only downside to merging updates into the main repository is that network installs from the repository will no longer install the release they will install the updated release. QA that goes into that first impression is no longer there, and your installs are not repeatable because installing system A on one day and system B on another could end up with different versions of packages. Of course you can always install from the ISOs to avoid these problems. As things are, you have the choice of the release as it was, or the updated release at install time. I am not saying that this is a bad idea, in fact I rather like it, but there are things to consider. I think this is quite a compelling reason not to touch it. Much as we'd like the updates repository to always be perfectly stable, there are still plenty of occassions when we hit problems with updates. Being able to reliably install the release at all times is pretty critical saying we should install off ISO if we want a reliable install is not really an acceptable alternative since many people do all their installs straight off the network. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 190 packages with .la file(s)
On Mon, Nov 30, 2009 at 01:40:38PM +0100, Pierre-Yves wrote: On Mon, 2009-11-30 at 14:03 +0200, Andy Shevchenko wrote: On Mon, Nov 30, 2009 at 1:56 PM, Pierre-Yves pin...@pingoured.fr wrote: mingw32-zlib-0:1.2.3-19.fc12.noarch All mingw32- RPMs containing DLLs are required to ship the .la file in order that libtool can work correctly on Win32 http://fedoraproject.org/wiki/Packaging/MinGW#Libraries_.28DLLs.29 Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
On Wed, Nov 11, 2009 at 09:05:20PM +, Richard W.M. Jones wrote: On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in the default config, but I don't think it should be slower than mkfs.ext3 for the same sized disks. Easy with guestfish: $ guestfish --version guestfish 1.0.78 $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done ext2 elapsed time: 5.21 seconds ext3 elapsed time: 7.87 seconds ext4 elapsed time: 6.10 seconds xfs elapsed time: 0.45 seconds jfs elapsed time: 0.78 seconds Note that because this is using a sparsely allocated disk each write to the virtual disk is very slow. Change 'sparse' to 'alloc' to test this with a non-sparse file-backed disk. You really want to avoid using sparse files at all when doing any kind of benchmark / performance tests in VMs. The combo of a sparse file store on a journalling filesystem in the host, w/ virt can cause very pathelogically bad I/O performance until the file has all its extents fully allocated on the host FS. So the use of a sparse file may well be exagarating the real difference in elapsed time between these different mkfs calls in the guest. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, Oct 22, 2009 at 04:42:16PM -0500, Mike McGrath wrote: On Thu, 22 Oct 2009, Chuck Anderson wrote: On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. Perhaps no one should be using their @redhat.com address for Fedora work :-/ We generally discourage it but several still do it. Err surely just the opposite. At least anyone who works on both RHEL and Fedora will use their @redhat.com address because they need this to be able to see private BZ comments most people don't want to constantly be switching between 2 BZ account logins just to use alternate addr for Fedora. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unresponsive maintainer for system-config-cluster
On Wed, Oct 21, 2009 at 01:57:14PM +0100, Steven Whitehouse wrote: Hi, On Wed, 2009-10-21 at 14:40 +0200, Milos Jakubicek wrote: Hi, On 10/21/2009 11:11 AM, Steven Whitehouse wrote: Hi, Jim Parsons left Red Hat a little while back and the only contact details I have is his Red Hat email address, which is of course no longer valid. I've opened a bugzilla #530027 as per the unresponsive maintainer procedure, but I was hoping to be able to skip the section regarding sending of messages since there seems little point sending to an email address which I know (and which other Red Hat employees can easily verify) will not be answered. +1 from here...I already e-mailed Jim Parson a long long time (for sure more than a year) ago because of some trivial outstanding bugs in that package (missing requires, incorrect pam configuration, ...), some of them I fixed then, some are still left. I tried several times and didn't get any response. I've actually found a few more since I wrote that list in the bz too. I would like to either fix (or preferably just remove) this package as it creates configs for GFS2 which are incorrect and is thus causing confusion to all who attempt to use it. Hm...I would appreciate keeping the package (...and could fix the very trivial of the remaining bugreports), how complicated would it be to fix the GFS2 configs? On the other hand, I've heard from somebody of the RH cluster team that the package is deprecated at all, how's that? Well if someone wants to maintain it, then I suppose there is no issue. My understanding is that Conga is the preferred method for graphical configuration of clusters. Personally I use vi for cluster configuration :-) I don't think its really viable to suggest that Conga is a replacement for system-config-cluster. One is a simple desktop UI for editing cluster config files. The other is a large web based management infrastructure. Certainly alot of people may want to use Conga, but I can well imagine people using s-c-c , wouldn't want to deploy a webapp just to get a tool to edit cluster config files Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
On Wed, Oct 21, 2009 at 01:08:43PM -0400, Darryl L. Pierce wrote: On Wed, Oct 21, 2009 at 10:00:13AM -0700, Jesse Keating wrote: On Wed, 2009-10-21 at 12:58 -0400, Darryl L. Pierce wrote: And you can't uninstall KDE without killing gnome since NetworkManager-gnome has a dependency on KDE... Um, what? Care to elaborate? http://www.pastebin.org/46726 If you try to uninstall the KDE (K Desktop Environment) group then NetworkManager-gnome is marked for deletion as well. IIUC, you're mis-interpreting the YUM output there. NetworkManager-gnome doesn't have a dependancy on KDE, rather it happens to be part of the KDE (K Desktop Environment) group. ie in doing a 'groupremove' you explicitly asked YUM to remove 'NetworkManager-gnome' since its in that group. If you had just done an package level remove, eg 'yum remove kde*' then NetworkManager-gnome would not have been removed Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
On Mon, Oct 19, 2009 at 01:59:50PM +0200, Josephine Tannh?user wrote: 2009/10/19 Guido Grazioli guido.grazi...@gmail.com Come on guys, let this thread die. In other words, shut the export YUM_I_LIKE_BAD_WORDS=1 yum -y install fuck up ;-) f.u.c.k.u.p. the computer of Hagbard Celine? My favorite quote about fuck is from southpark - bigger longer uncut: [snip] Please stop this now, it has gone way beyond discussing real technical issues, and is just being gratuitously offensive thus off-topic for this list. There are plenty of places on the internet for this. The Fedora development list is not one of them. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: This is going to be pretty important for scientific workloads where atlas is going to be used. I've eavesdropped on several conversations where people were talking about being able to run off-the-shelf science code virtual appliance in order to reduce the environment configuration workload for an individual researcher. Yup. The really fun starts when you do live migration. The processor literally changes underneath the running programs. If you thought you had SSE3 one minute, then the next you don't, or vice versa. No one has to my knowledge come up with a good way to deal with this. But it probably involves signalling the kernel and processes so that they can redo processor detection. You can see why that is not going to be pleasant. Surely the way to do this is to know what your workload is doing, and not do live migration to random hardware? Or just apply a CPUID mask to the guest, so it sees a constant set of features no matter where its migrated to. This is what Xen, VMWare, QEMU/KVM all do for this problem. Trying to make the guest re-detect, while nice in theory, is just not something people are going to bother doing - witness the death of pure paravirt, since fullyvirt is 'good enough' for most people - the same is true of CPUID masking to make hardware appear homogeneous Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Adding a new package to rawhide/F-12
On Tue, Sep 15, 2009 at 02:36:57PM +0100, Matthew Booth wrote: I'd like to add a new package (virt-v2v) to rawhide/F-12. Nothing depends on it. I don't appear to be able to do this, although I can add it to the supposedly stable F-11. This seems like an unlikely state of affairs. Am I missing something? Nothing to see here, move along. Matt was just trying todo 'make update' from F12 branch getting an error, because updates are not required for F12 branch yet. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More Fedora mock breakage
On Fri, Jul 31, 2009 at 08:41:17PM -0400, Josh Boyer wrote: On Fri, Jul 31, 2009 at 06:48:54PM -0400, Tom Lane wrote: Mathieu Bridon (bochecha) boche...@fedoraproject.org writes: ERROR with rpm_check_debug vs depsolve: rpmlib(PayloadIsXz) is needed by exim-4.69-12.fc12.x86_64 I had the same on F11, building in a Rawhide mock. I was advised to update rpm to 4.7.1 that was in updates-testing, which fixed the problem. [ consults CVS... ] So XZ support in F-11's rpm is less than a week old, there is *no* support in F-10, and we're already requiring the capability in order to do useful development work? All I can say is WTF. Did you have a better plan for migrating to an XZ payload for F12 in time for Alpha? IMHO there should be a much larger window between providing an new feature in RPM, and requiring it for development. eg, new features should go into RPM in rawhide F11 at least 2-3 months before we require them. Yes this would have required XZ support to be merged much sooner in the F12 schedule, or alternatively merge XZ support in F12, but don't use it till F13. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 04:30:55PM -0400, Seth Vidal wrote: On Mon, 27 Jul 2009, Farkas Levente wrote: fc1-fc2 fc6-fc7 rhel4-rhel5 It's not new. just to be correct neither fc6-fc7 nor rhel4-rhel5 break any system tools! and i don't remember to fc1-fc2. fc6-fc7 had a couple of fun metadata breaks rhel4-rhel5 upgrades are neither supported (iirc) nor likely to work consistently in my experience b/c of how much things changed between them. A live in place RHEL upgrade via something like 'yum' may not be supported, but I believe that an Anaconda based upgrade is fully supported. Though 'supported' might include you having to redo customizations to config files the like. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssh-blacklist - careless waste of space.
On Fri, Jul 24, 2009 at 05:30:27PM +0300, Yanko Kaneti wrote:
So
openssh-blacklist-0.7-1.fc11.src.rpm - size 1072930614
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372950
openssh-blacklist-0.7-1.fc10.src.rpm - size 1072930519
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372948
openssh-blacklist-0.7-1.fc12.src.rpm - size 1072930637
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372843
~3GB to produce 3 ~15MB rpms of copied ~20MB fingerprints.
Seriously wtf!?. And where is the frikken package review for it?
This really is insane. The source tar.gz contains
openssh-blacklist-0.7$ du -h -c -s *
4.0KCONTENT
16K COPYING
26M fingerprints
797Mprivate
358Mpublic
1.2Gtotal
The SPEC file just does
mv fingerprints/* $RPM_BUILD_ROOT%{_datadir}/%{name}
So there is 1.2 GB of data there that is never used for any purpose
whatsoever, its not even being used to build the final data that
goes into the binary RPM.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Software-License/devel .cvsignore, 1.2, 1.3 perl-Software-License.spec, 1.2, 1.3 sources, 1.2, 1.3
Author: berrange
Update of /cvs/pkgs/rpms/perl-Software-License/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4439
Modified Files:
.cvsignore perl-Software-License.spec sources
Log Message:
Update to 0.012 release
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Software-License/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 3 Oct 2008 09:02:46 - 1.2
+++ .cvsignore 22 Jul 2009 19:16:56 - 1.3
@@ -1,4 +1,4 @@
-Software-License-0.008.tar.gz
.build*.log
*.rpm
noarch
+Software-License-0.012.tar.gz
Index: perl-Software-License.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Software-License/devel/perl-Software-License.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-Software-License.spec 27 Feb 2009 01:33:30 - 1.2
+++ perl-Software-License.spec 22 Jul 2009 19:16:56 - 1.3
@@ -1,6 +1,6 @@
Name: perl-Software-License
-Version:0.008
-Release:4%{?dist}
+Version:0.012
+Release:1%{?dist}
Summary:Package that provides templated software licenses
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jul 22 2009 Daniel P. Berrange berra...@redhat.com - 0.012-1
+- Update to 0.012 release
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.008-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Software-License/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 3 Oct 2008 09:02:46 - 1.2
+++ sources 22 Jul 2009 19:16:56 - 1.3
@@ -1 +1 @@
-593cc31662e21f688b2a451ec8068f2e Software-License-0.008.tar.gz
+8232072eec55b331b0a56adc253dfa12 Software-License-0.012.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Test-YAML-Meta/devel .cvsignore, 1.3, 1.4 perl-Test-YAML-Meta.spec, 1.4, 1.5 sources, 1.3, 1.4
Author: berrange
Update of /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5657
Modified Files:
.cvsignore perl-Test-YAML-Meta.spec sources
Log Message:
Update to 0.12 release
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 5 Sep 2008 16:35:47 - 1.3
+++ .cvsignore 22 Jul 2009 19:21:02 - 1.4
@@ -1,3 +1,3 @@
-Test-YAML-Meta-0.11.tar.gz
.build*.log
*.rpm
+Test-YAML-Meta-0.12.tar.gz
Index: perl-Test-YAML-Meta.spec
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel/perl-Test-YAML-Meta.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Test-YAML-Meta.spec27 Feb 2009 03:05:15 - 1.4
+++ perl-Test-YAML-Meta.spec22 Jul 2009 19:21:02 - 1.5
@@ -1,6 +1,6 @@
Name: perl-Test-YAML-Meta
-Version:0.11
-Release:2%{?dist}
+Version:0.12
+Release:1%{?dist}
Summary:Validation of the META.yml file in a distribution
License:GPL+ or Artistic
Group: Development/Libraries
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3pm*
%changelog
+* Wed Jul 22 2009 Daniel P. Berrange berra...@redhat.com - 0.12-1
+- Update to 0.12 release
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.11-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Test-YAML-Meta/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 5 Sep 2008 16:35:47 - 1.3
+++ sources 22 Jul 2009 19:21:02 - 1.4
@@ -1 +1 @@
-b6aac8d8708f7c09c5a6f6c8c61476df Test-YAML-Meta-0.11.tar.gz
+66fc4d551ad6c650ab8f80b2928eadf6 Test-YAML-Meta-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Does anything require /proc/bus/usb?
On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: If not, should it be phased out? I'm referencing a use case with VirtualBox that looks for /proc/bus/usb by default and will use that instead of libusb for USB device access. This has caused issues for people wishing to use VirtualBox on Fedora in that they cannot use USB devices without a little tinkering. They either have to remove the /proc/bus/usb mount from rc.sysinit or adjust their fstab to allow other users access. Why not do a patch for VirtualBox to make it look in the right place first ? We've just done that for QEMU too, changing its search order to be /sys/bus/usb, /dev/bus/usb and only then /proc/bus/usb. Removing the whole /proc/bus/usb mount to solve one application's problem does not seem ideal. I'll even go as far as providing a patch! *gasp* Most of you probably don't care about VirtualBox and would rather us use libvirt, but some folks use different software. FYI the distinction VirtualBox vs libvirt isn't correct. libvirt is an API for any virtualization technology, and has drivers for Xen, KVM, QEMU, VirtualBox and more. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Does anything require /proc/bus/usb?
On Fri, Jul 17, 2009 at 09:16:12AM -0700, Adam Williamson wrote: On Fri, 2009-07-17 at 17:10 +0100, Daniel P. Berrange wrote: On Fri, Jul 17, 2009 at 10:42:56AM -0500, Michael Cronenworth wrote: If not, should it be phased out? I'm referencing a use case with VirtualBox that looks for /proc/bus/usb by default and will use that instead of libusb for USB device access. This has caused issues for people wishing to use VirtualBox on Fedora in that they cannot use USB devices without a little tinkering. They either have to remove the /proc/bus/usb mount from rc.sysinit or adjust their fstab to allow other users access. Why not do a patch for VirtualBox to make it look in the right place first ? Because we don't package VirtualBox, because it requires not-in-tree kernel modules. I know that, but that doesn't prevent motivated people sending a patch to rpmfusion, or virtualbox upstream to solve this problem. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-TAP-Formatter-HTML/devel perl-TAP-Formatter-HTML.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: berrange
Update of /cvs/extras/rpms/perl-TAP-Formatter-HTML/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv7198
Modified Files:
.cvsignore sources
Added Files:
perl-TAP-Formatter-HTML.spec
Log Message:
Initial import of package after review (rhbz #511094)
--- NEW FILE perl-TAP-Formatter-HTML.spec ---
Name: perl-TAP-Formatter-HTML
Version:0.07
Release:1%{?dist}
Summary:TAP Test Harness output delegate for html output
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/TAP-Formatter-HTML/
Source0:
http://www.cpan.org/authors/id/S/SP/SPURKIS/TAP-Formatter-HTML-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl = 1:5.6.0
BuildRequires: perl(accessors) = 0.02
BuildRequires: perl(Module::Build)
BuildRequires: perl(TAP::Parser) = 3.10
BuildRequires: perl(Template) = 2.14
BuildRequires: perl(Test::More) = 0.01
BuildRequires: perl(URI) = 1.35
Requires: perl(accessors) = 0.02
Requires: perl(TAP::Parser) = 3.10
Requires: perl(Template) = 2.14
Requires: perl(URI) = 1.35
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This module provides HTML output formatting for TAP::Harness (a replacement
for Test::Harness. It is largely based on ideas from TAP::Test::HTMLMatrix
(which was built on Test::Harness and thus had a few limitations - hence
this module). For sample output, see:
%prep
%setup -q -n TAP-Formatter-HTML-%{version}
%build
%{__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/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README Todo
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Jul 06 2009 Daniel P. Berrange berra...@redhat.com 0.07-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-TAP-Formatter-HTML/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 15 Jul 2009 02:31:27 - 1.1
+++ .cvsignore 15 Jul 2009 09:28:39 - 1.2
@@ -0,0 +1,4 @@
+.build*log
+*.rpm
+noarch
+TAP-Formatter-HTML-0.07.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-TAP-Formatter-HTML/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 15 Jul 2009 02:31:27 - 1.1
+++ sources 15 Jul 2009 09:28:39 - 1.2
@@ -0,0 +1 @@
+ba7a2ea4fbbc47a2f3e10a66517c927f TAP-Formatter-HTML-0.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-accessors/devel perl-accessors.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: berrange
Update of /cvs/extras/rpms/perl-accessors/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8488
Modified Files:
.cvsignore sources
Added Files:
perl-accessors.spec
Log Message:
Initial import after review (rhbz #511081)
--- NEW FILE perl-accessors.spec ---
Name: perl-accessors
Version:1.01
Release:1%{?dist}
Summary:Create accessor methods in caller's package
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/accessors/
Source0:
http://www.cpan.org/authors/id/S/SP/SPURKIS/accessors-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl = 1:5.6.0
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More) = 0.01
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
The accessors pragma lets you create simple accessors at compile-time.
%prep
%setup -q -n accessors-%{version}
%build
%{__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/*
# A few of the .pm modules have bogus execute permission
find $RPM_BUILD_ROOT%{perl_vendorlib} -name *.pm | xargs chmod a-x
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Jul 06 2009 Daniel P. Berrange berra...@redhat.com 1.01-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-accessors/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 14 Jul 2009 04:42:47 - 1.1
+++ .cvsignore 14 Jul 2009 09:35:57 - 1.2
@@ -0,0 +1,4 @@
+accessors-1.01.tar.gz
+.build*.log
+*.rpm
+noarch
Index: sources
===
RCS file: /cvs/extras/rpms/perl-accessors/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 14 Jul 2009 04:42:47 - 1.1
+++ sources 14 Jul 2009 09:35:57 - 1.2
@@ -0,0 +1 @@
+fc764c9cbfd03762c0d4f8ffaabaecb0 accessors-1.01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-accessors/F-11 perl-accessors.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: berrange
Update of /cvs/extras/rpms/perl-accessors/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv10319
Modified Files:
.cvsignore sources
Added Files:
perl-accessors.spec
Log Message:
Initial import after review (rhbz #511081)
--- NEW FILE perl-accessors.spec ---
Name: perl-accessors
Version:1.01
Release:1%{?dist}
Summary:Create accessor methods in caller's package
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/accessors/
Source0:
http://www.cpan.org/authors/id/S/SP/SPURKIS/accessors-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl = 1:5.6.0
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More) = 0.01
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
The accessors pragma lets you create simple accessors at compile-time.
%prep
%setup -q -n accessors-%{version}
%build
%{__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/*
# A few of the .pm modules have bogus execute permission
find $RPM_BUILD_ROOT%{perl_vendorlib} -name *.pm | xargs chmod a-x
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Mon Jul 06 2009 Daniel P. Berrange berra...@redhat.com 1.01-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-accessors/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 14 Jul 2009 04:42:47 - 1.1
+++ .cvsignore 14 Jul 2009 09:43:41 - 1.2
@@ -0,0 +1,4 @@
+accessors-1.01.tar.gz
+.build*.log
+*.rpm
+noarch
Index: sources
===
RCS file: /cvs/extras/rpms/perl-accessors/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 14 Jul 2009 04:42:47 - 1.1
+++ sources 14 Jul 2009 09:43:41 - 1.2
@@ -0,0 +1 @@
+fc764c9cbfd03762c0d4f8ffaabaecb0 accessors-1.01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb
On Mon, Jul 06, 2009 at 02:14:27PM -0400, Tom Lane wrote: Peter Lemenkov lemen...@gmail.com writes: Why we should approve manually requests to watching bugzilla and cvs changes for packages? I'm sure we need to change policy in order to automatically approve all such requests. Isn't there a security issue there? I'm not sure I want any random person watching every bz or commit I make. Anyone with a BZ account can already watch every BZ you have Preferences - Email Preferences - Add users to my watch list pkgdb just makes it more fine grained, so you can watch individual components instead of having to find the owner and watch everything they own NB, the email watches don't allow them to snoop on bugs with restricted group visibility, so they shouldn't be able to see bugs restrict to the 'Security Sensitive Bug' group IIUC. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Tue, Jun 30, 2009 at 02:05:57PM -0400, Owen Taylor wrote: I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. In general automake hasn't had a very good track record of compatibility between 1.x and 1.y, though this has been getting better recently. I don't see any specific mentions of incompatible changes in a quick scan of: http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html But it is also a pretty long release announcement so it wouldn't surprise me if there were some subtle incompatibilities. The only breakage I'm actually aware of in the gnome-common package; gnome-common-2.26 and earlier doesn't know that automake-1.11 is a valid replacement when automake-1.10 is asked for. So, we definitely need to release an update for gnome-common, or people aren't going to be able to do GNOME development on F11. But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in maintenance mode distributions like F9 and F10. This is seriously dubious for F9, since if it causes a problem there is next to no time in which to fix it before F9 updates are turned off. In general I struggle to believe that there is a compelling need to rebase automake versions in our stable releases. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Mon, Jun 15, 2009 at 10:22:12PM +0100, Richard W.M. Jones wrote: On Mon, Jun 15, 2009 at 03:31:17PM -0500, Jon Ciesla wrote: I'm not sure I understand why not. Are you saying that if RedHat decided that RHEL7 was to support Sparc , there'd be no interest in making that a primary arch? RHEL supports Itanic, and that isn't even _built_ for Fedora, never mind as a secondary arch. IIUC, it isn't setup us a proper secondary arch, but there are people who are rebuilding Fedora for ia64 http://www.redhat.com/archives/fedora-ia64-list/ Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC console=? to get serial console
On Thu, Jun 11, 2009 at 01:34:25PM -0400, Josh Boyer wrote: On Thu, Jun 11, 2009 at 10:38 AM, Richard W.M. Jonesrjo...@redhat.com wrote: (Posting here because the fedora-ppc list is a bit overrun with spam http://lists.infradead.org/pipermail/fedora-ppc/ ) Does anyone know what 'console=...' parameter I should give the Fedora PPC kernel to get it to use a serial console? Debian uses the non-standard form console=ttyPZ0 That is for the special G5 serial cards I believe. I've also seen console=hvc0 mentioned. Obviously I also tried console=ttyS0. hvc0 is for machines like POWER4/5/6 and possibly a couple others. hvc0 is a virtual console device. As well as some PPC machines, its used for Xen paravirt console, and KVM's virtio console device, and possibly s390 too IIRC Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 08:56:47AM -0400, Tom spot Callaway wrote: On 06/05/2009 06:23 AM, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. I'm willing to help with testing. I have a Epson 4490, and Nikon Coolscan V slide scanner. The latter has been a trainwreck with sane for a long time, but I'm told its finally possible to use it. So if we have a nice GUI front end for scanning, i'll help out with testing. Daniel, who has 'vuescan' as the only closed source software on his Fedora machine for which no practical open source replacement yet exists. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 12:50:40PM -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: So I think the gnome-scan interface is nice but if my results are reproduced by others, we can't really replace xsane with it until it's a bit less buggy. It would be nice if any coders with scanning interest could contribute to the code I guess (I'm unfortunately not a coder). IMO the obnoxious license dialog that xsane still subjects you to is sufficient reason already to replace it. We don't tolerate dialogs like that in other default-installed components... Why don't we patch it out then Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On Fri, May 29, 2009 at 11:05:01AM +0300, Muayyad AlSadi wrote: in case you have accepted to put such packages in the repo please maintain a wiki page listing all of them so that we can add exclude for all of them in fedora .repo files sorry, but our users trust us [in ojuba.org spin] to provide packages that respect our family values and moralities IMHO it is not Fedora's job to define family values moralities. Such morals/values will vary all around the world, such that no single list Fedora makes would be satisfactory. If a derived spin wants to define a set of morals values then the burden should be on them to maintain the list of packages that don't comply, not Fedora. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On Fri, May 29, 2009 at 01:40:36PM +0200, Chitlesh GOORAH wrote: On Fri, May 29, 2009 at 1:30 PM, Nicu Buculei nicu_fed...@nicubunu.ro wrote: Movies in proprietary formats can be downloaded also with Firefox, Transmission, wget, etc. From the description of gnaughty I understand it can also download images, which are in free formats, so the content is in both free and proprietary formats. Here is the purpose of the application is important. A browser is not only intended for free and proprietary formats downloader. It serves other purposes as well. But gNaughty serves only purpose is download porn. If we allow this package, in other words it says Fedora tolerates proprietary formats. It is not something we are comfortable with. It is not Fedora's place to police *usage* of apps, only whether the app or package has a compliant license and follows the defined packaging legal rules. If the tool were directly containing support for decoding such prorietry formats that would be a different matter, because the codecs would not pass the legal rules. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On Fri, May 29, 2009 at 11:02:23AM -0400, Seth Vidal wrote: On Fri, 29 May 2009, Toshio Kuratomi wrote: On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: The problem with a comps group is that it will lead to having a group in graphical installers although in ojuba we use ourown comps files, but this is a catastrophe because they are merged! I guess there is an option for hidden groups Have these packages: Provides: policy(adult content) And have a package that's mandatory in your respin that has: Conflicts: policy(adult content) /me taking one of the good ideas from the flag debate. Except it is obvious that something contains a flag or not. Labeling certain content 'questionable' is going to end up being all over the distro and diluting the value of the tag. Let me put it this way - if we start randomly rating things in a provides tag and gnaughty or hot-babe or pr0n-comfort get labeled this way then I'll make sure I personally add the same tag to: - firefox - yum - sword - gnome-sword And every email client, because I'm spammed by countless messages offering adult content every day :-( Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: | From: Rex Dieter rdie...@math.unl.edu | Seems frustrations are mounting: | On policykit and standards | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html [I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.] This certainly does not look like a healthy approach to standardization and cooperation. - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object) - in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it. - for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation. - all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule I admit that my reactions may be ill-founded. Perhaps this is meant You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Software-License/devel perl-Software-License.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: berrange
Update of /cvs/pkgs/rpms/perl-Software-License/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30802
Modified Files:
.cvsignore sources
Added Files:
perl-Software-License.spec
Log Message:
Initial import after review
--- NEW FILE perl-Software-License.spec ---
Name: perl-Software-License
Version:0.008
Release:3%{?dist}
Summary:Package that provides templated software licenses
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Software-License/
# For unknown reasons this module URL is currently missing
#Source0:
http://www.cpan.org/modules/by-module/Software/Software-License-%{version}.tar.gz
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Software-License-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl = 1:5.6.0
BuildRequires: perl(Data::Section) = 0.000
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Sub::Install) = 0.000
BuildRequires: perl(Text::Template) = 0.000
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Software-License contains templates for common open source software licenses.
%prep
%setup -q -n Software-License-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$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/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Sat Sep 20 2008 Daniel P. Berrange [EMAIL PROTECTED] 0.008-3
- Remove explicit requires that duplicate automatic perl deps
* Sat Sep 06 2008 Daniel P. Berrange [EMAIL PROTECTED] 0.008-2
- Fix description
- Add missing Test::More BR
* Fri Sep 05 2008 Daniel P. Berrange [EMAIL PROTECTED] 0.008-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Software-License/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- .cvsignore 3 Oct 2008 05:56:39 - 1.1
+++ .cvsignore 3 Oct 2008 09:02:46 - 1.2
@@ -0,0 +1,4 @@
+Software-License-0.008.tar.gz
+.build*.log
+*.rpm
+noarch
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Software-License/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- sources 3 Oct 2008 05:56:39 - 1.1
+++ sources 3 Oct 2008 09:02:46 - 1.2
@@ -0,0 +1 @@
+593cc31662e21f688b2a451ec8068f2e Software-License-0.008.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Software-License/F-9 perl-Software-License.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: berrange
Update of /cvs/pkgs/rpms/perl-Software-License/F-9
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1489
Modified Files:
.cvsignore sources
Added Files:
perl-Software-License.spec
Log Message:
Initial import after review
--- NEW FILE perl-Software-License.spec ---
Name: perl-Software-License
Version:0.008
Release:3%{?dist}
Summary:Package that provides templated software licenses
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Software-License/
# For unknown reasons this module URL is currently missing
#Source0:
http://www.cpan.org/modules/by-module/Software/Software-License-%{version}.tar.gz
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Software-License-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl = 1:5.6.0
BuildRequires: perl(Data::Section) = 0.000
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Sub::Install) = 0.000
BuildRequires: perl(Text::Template) = 0.000
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Software-License contains templates for common open source software licenses.
%prep
%setup -q -n Software-License-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$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/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Sat Sep 20 2008 Daniel P. Berrange [EMAIL PROTECTED] 0.008-3
- Remove explicit requires that duplicate automatic perl deps
* Sat Sep 06 2008 Daniel P. Berrange [EMAIL PROTECTED] 0.008-2
- Fix description
- Add missing Test::More BR
* Fri Sep 05 2008 Daniel P. Berrange [EMAIL PROTECTED] 0.008-1
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Software-License/F-9/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- .cvsignore 3 Oct 2008 05:56:39 - 1.1
+++ .cvsignore 3 Oct 2008 09:22:06 - 1.2
@@ -0,0 +1,4 @@
+Software-License-0.008.tar.gz
+.build*.log
+*.rpm
+noarch
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Software-License/F-9/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- sources 3 Oct 2008 05:56:39 - 1.1
+++ sources 3 Oct 2008 09:22:06 - 1.2
@@ -0,0 +1 @@
+593cc31662e21f688b2a451ec8068f2e Software-License-0.008.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Sys-Virt/devel perl-Sys-Virt-0.1.2-free.patch, NONE, 1.1 perl-Sys-Virt.spec, 1.12, 1.13
Author: berrange
Update of /cvs/pkgs/rpms/perl-Sys-Virt/devel
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23735
Modified Files:
perl-Sys-Virt.spec
Added Files:
perl-Sys-Virt-0.1.2-free.patch
Log Message:
Fix use of free() in XS binding
perl-Sys-Virt-0.1.2-free.patch:
--- NEW FILE perl-Sys-Virt-0.1.2-free.patch ---
diff -rup Sys-Virt-0.1.2.orig/Virt.xs Sys-Virt-0.1.2.new/Virt.xs
--- Sys-Virt-0.1.2.orig/Virt.xs 2008-02-23 14:15:14.0 -0500
+++ Sys-Virt-0.1.2.new/Virt.xs 2008-03-07 17:36:28.0 -0500
@@ -197,13 +197,14 @@ list_domain_ids(con, maxids)
PPCODE:
Newx(ids, maxids, int);
if ((nid = virConnectListDomains(con, ids, maxids)) 0) {
+Safefree(ids);
_croak_error(virConnGetLastError(con));
}
EXTEND(SP, nid);
for (i = 0 ; i nid ; i++) {
PUSHs(sv_2mortal(newSViv(ids[i])));
}
- free(ids);
+ Safefree(ids);
int
@@ -227,7 +228,7 @@ list_defined_domain_names(con, maxnames)
PPCODE:
Newx(names, maxnames, char *);
if ((ndom = virConnectListDefinedDomains(con, names, maxnames)) 0) {
- free(names);
+ Safefree(names);
_croak_error(virConnGetLastError(con));
}
EXTEND(SP, ndom);
@@ -235,7 +236,7 @@ list_defined_domain_names(con, maxnames)
PUSHs(sv_2mortal(newSVpv(names[i], 0)));
free(names[i]);
}
- free(names);
+ Safefree(names);
int
@@ -258,6 +259,7 @@ list_network_names(con, maxnames)
PPCODE:
Newx(names, maxnames, char *);
if ((nnet = virConnectListNetworks(con, names, maxnames)) 0) {
+Safefree(names);
_croak_error(virConnGetLastError(con));
}
EXTEND(SP, nnet);
@@ -265,7 +267,7 @@ list_network_names(con, maxnames)
PUSHs(sv_2mortal(newSVpv(names[i], 0)));
free(names[i]);
}
- free(names);
+ Safefree(names);
int
@@ -289,7 +291,7 @@ list_defined_network_names(con, maxnames
PPCODE:
Newx(names, maxnames, char *);
if ((ndom = virConnectListDefinedNetworks(con, names, maxnames)) 0) {
- free(names);
+ Safefree(names);
_croak_error(virConnGetLastError(con));
}
EXTEND(SP, ndom);
@@ -297,7 +299,7 @@ list_defined_network_names(con, maxnames
PUSHs(sv_2mortal(newSVpv(names[i], 0)));
free(names[i]);
}
- free(names);
+ Safefree(names);
void
Index: perl-Sys-Virt.spec
===
RCS file: /cvs/pkgs/rpms/perl-Sys-Virt/devel/perl-Sys-Virt.spec,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- perl-Sys-Virt.spec 7 Mar 2008 02:17:12 - 1.12
+++ perl-Sys-Virt.spec 7 Mar 2008 22:47:03 - 1.13
@@ -1,11 +1,12 @@
Name: perl-Sys-Virt
Version:0.1.2
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Represent and manage a libvirt hypervisor connection
License:GPLv2+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Sys-Virt/
Source0:
http://www.cpan.org/authors/id/D/DA/DANBERR/Sys-Virt-%{version}.tar.gz
+Patch1: %{name}-%{version}-free.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod)
@@ -21,6 +22,7 @@
%prep
%setup -q -n Sys-Virt-%{version}
+%patch1 -p1
sed -i -e '/Sys-Virt\.spec/d' Makefile.PL
sed -i -e '/\.spec\.PL$/d' MANIFEST
@@ -59,6 +61,9 @@
%{_mandir}/man3/*
%changelog
+* Fri Mar 07 2008 Daniel P. Berrange [EMAIL PROTECTED] - 0.1.2-3
+- Fix calls to free() in XS binding
+
* Thu Mar 06 2008 Tom spot Callaway [EMAIL PROTECTED] - 0.1.2-2
Rebuild for new perl
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
