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
Re: [Fedora-livecd-list] Use of lokkit in livecd-builder
On Thu, Aug 28, 2008 at 09:22:13AM -0400, Jeremy Katz wrote: On Thu, 2008-08-28 at 08:44 -0400, Bryan Kearney wrote: The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and disable the firewall. There is a FIXME near it to suport the rest of the options which lokkit takes. The current implementation executes this in the chroot environment, so forces several packages to be deployed into the image when it is built. Since I would be curious in reducing the package set for the images which are built, I am curious if there are plans around any of the following: 1) Remove the use of lokkit and instead directly manipulate the files (or perhaps use augeas). Not really. We use lokkit so that when things change, there's only one implementation that needs changing. And this is a *good* thing. And augeas would be seen as a far more one-off dep than lokkit at this point to most of the world. If augeas were to be used I'd expect lokkit itself to use it directly, rather than livecd-creator using it. 2) Look to break up system-config-firewall-tui so that lokkit is a separate package with less dependencies. The big dep that looks trimmable is rhpl as it's just used for translation stuff (... and I want to get things off of using rhpl.translate and just using the gettext module directly anyway). There's not really anything else which is even feasible to remove It is not worth worrying about rhpl. The killer piece that causes pain for oVirt in this scenario is the presense of python. Unless that's killable, the rest is just a rounding error. The way we currently do it is include lokkit packages at first, and then use a %post script to uninstall python and everything using it. Unless someone wants to re-implement entire of lokkit in C, I don't see any other viable approach other than this uninstall in %post. 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-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] Use of lokkit in livecd-builder
On Thu, Aug 28, 2008 at 10:21:44AM -0400, Jeremy Katz wrote: On Thu, 2008-08-28 at 15:07 +0100, Daniel P. Berrange wrote: The way we currently do it is include lokkit packages at first, and then use a %post script to uninstall python and everything using it. Unless someone wants to re-implement entire of lokkit in C, I don't see any other viable approach other than this uninstall in %post. The irony is that lokkit was originally written in C. But to add all of the functionality that people continued to want, it was rewritten in python years ago :) The ever increasing functionality of lokkit is incredibly a poor design choice :-( For libvirt to register iptables rules, SELinux policy had to be changed to allow libvirtd to run lokkit. This has the dubious side-effect of now giving libvirtd permission to turn off SELinux. 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-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] livecd-iso-to-disk man page
On Thu, Jun 05, 2008 at 08:50:00AM +0100, Pedro Silva wrote: Hi! I started the man page for the livecd-iso-to-disk, I used this guide[1] to do it. Since this is my first man page ever, shout if I made some terribly mistake. ???[1] http://www.schweikhardt.net/man_page_howto.html Thoughts, tips? Personally I always recommend avoiding NROFF as your master format when writing man pages since it is seriously unpleasant to read as an author. I don't know what Jeremy's thoughts are on the topic, but even though this is python code, you might like to consider writing it using POD (Perl's native documentation format) which is a easily readable plain text markup you can embed in shell/python/perl/etc source files, or just have in a standalone text file. You can process this using pod2man to generate the NROFF formatted man page, as well as also having access to pod2html to produce online HTML version, or pod2text for a completely plain text version. This is what I used for all the python virtualization tools such as virt-install, virt-clone, virt-manager. You can see an examples of the 'master' POD format http://hg.et.redhat.com/virt/applications/virtinst--devel?f=72d52276a33e;file=man/en/virt-clone.pod and the generated man page http://hg.et.redhat.com/virt/applications/virtinst--devel?f=1ceb93283682;file=man/en/virt-clone.1 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-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] How To Create a LiveCD for Xen
On Thu, Mar 20, 2008 at 01:28:27PM +, Richard W.M. Jones wrote: On Thu, Mar 20, 2008 at 05:25:41PM +0530, M P Sairam wrote: Richard W.M. Jones wrote: On Thu, Mar 20, 2008 at 03:14:35PM +0530, M P Sairam wrote: Hi, I want to create a live CD which can work in Xen. can any one help me? I googled it but i didn't get good enough material. You mean a live CD which can be booted as a Xen guest? Or a live CD which contains (eg) a Xen hypervisor? I mean a live CD which can be booted as a Xen guest I haven't tried it for Xen (only for QEMU/KVM where it definitely works), but you should just be able to boot the CDROM directly. Try creating XML configuration following this example: You can do this more directly with virt-install [quote src=virt-install(1)] Run a Live CD image under Xen fullyvirt, in diskless environment # virt-install \ --hvm \ --name demo \ --ram 500 \ --nodisk \ --livecd \ --vnc \ --cdrom /root/fedora7live.iso [/quote] Regards, Dan. -- |: Red Hat, Engineering, Boston -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-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-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
Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool
On Thu, Feb 21, 2008 at 01:57:08AM +, Daniel P. Berrange wrote: On Wed, Feb 20, 2008 at 08:01:32PM -0500, Jeremy Katz wrote: On Tue, 2008-02-19 at 19:16 +, Daniel P. Berrange wrote: from its kickstart recipe. Currently developers building the appliance have to boot a VM using the F8 boot.iso and run the kickstart script in the VM and so on. While this works, involves many steps with potential for failure. This new tool reduces the problem to simply As opposed to virt-install --name ... ? I'm not convinced there's a huge gain in terms of number of places for failure :-/ You have to have a working virtualization stack it takes more resource overhead than just doing the chroot'd build. Emprically the part of our build process doing the guest based installs has been less reliable than the livecd-creator part. Havinga disk-creator will address that problem You have to have a working virt stack to *use* virtualization or test things. I'm not sure that't eh argument to use. And as far as reliability, what bugs are you talking about? livecd-creator has managed to have lower numbers of bugs largely due to a) less functionality and b) less users. The host you use virtualization on, is not neccessarily the same as the host you build your images on though. If people don't have hardware virt in their dev machine it can be beneficial to build images via this tool, in preference to use the very slow QEMU emulator. Even in they do have virtualization the CPU particularly memory overhead of building in the host is reduced. One specific bug is that the disk image ends up with the hostname of the guest VM embedded in /etc/sysconfig/network /etc/hosts. Another was that the user in question wanted to run the tool on a host without hardware virt support. Some other examples of scenarios where you want to build appliance images but do not have virtualization capabilities directly accessible. - Machines where the user's primary OS is running under an embedded hypervisor. QEMU is tolerable for booting an image to verify that it works, but building the image in QEMU is too slow to be practical. - Building images to deploy to a virtual machine hosted by an ISP, eg linode.com where you have either option of providing a pre-installed disk image, or using one the ISP built for you. - The virtualization technology on your local machine may be different from the target machine. eg you can run VirtualBox on your deskop, but want to build Xen based images to deploy to Amazon's EC2 hosting environment. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool
On Wed, Feb 20, 2008 at 09:49:57PM -0600, Douglas McClendon wrote: Daniel P. Berrange wrote: Some other examples of scenarios where you want to build appliance images but do not have virtualization capabilities directly accessible. - Machines where the user's primary OS is running under an embedded hypervisor. QEMU is tolerable for booting an image to verify that it works, but building the image in QEMU is too slow to be practical. Obviously, since my project uses precisely that (qemu) I'll defend a bit: Some examples of where 'too slow to be practical' is IMHO an oversweeping generalization- - when a few hours or overnight is not a big deal Yes it is a big deal because it directly impacts the amount of development and testing I can do in any single day. If it takes 15 minutes to build an image I can get through many many build test cycles in a day. If it takes overnight then I can only do one build test. For some people it may not be a big deal to wait overnight, but for many people it it totally impractical to wait this long. - in the future, when qemu, either via kvm/kqemu or just plain faster hardware, reduces the install time from hours to minutes, and the simplicity and security of no-root-privs becomes more valuable than the time saved using alternate methods (at least for some usage cases). KQEMU is essentially unmaintained you can't assume access to KVM since it requires hardeware virtualization even if your hardware has such capabilities there are plenty of scenarios where the end user will not be able to use them. Naturally these might not be situations you are interested in, but I think your statement of 'too slow to be practical' was an oversimplification which you knew I would take the bait and defend ;) You're imagining things - if you choose to use QEMU for your project I've no problem with that - that's your choice to make. It is simply not practical for my day-to-day work to wait for installs inside QEMU emulator to complete. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool
On Tue, Feb 19, 2008 at 01:58:46PM -0500, Jeremy Katz wrote: On Sun, 2008-02-17 at 02:14 +, Daniel P. Berrange wrote: This patch adds support for another installation variant. The livecd-creator produces ISO images which boot using syslinux. The image-creator creates a single file containing a filesystem in which the OS is installated. This patch adds a new disk-creator, which creates a single file containing a partitioned disk with potentially many filesystems in which the OS is installed. Furthermore it installs grub in the boot sector, so this image is immediately bootable in a virtual machine. Seems reasonable enough and it's something I had started looking at. My biggest concerns end up being scope... the next thing someone will want to add is RAID. Or LVM. Or dm-crypt. And I sort of wonder where it ends. I already gets bugs on one copy of code like that and it's called anaconda ;-) Where to draw the line is an interesting question. If you consider the created appliance as primary serving for deployment in virtual machines, then I'd argue that RAID / crypt is out of scope. They would be a site-specific deployment question. If an admin wants encryption they can set it up in the host directly. Likewise RAID can be done in the host already so its redundant for guests. LVM would be useful if only to make adding storage to the appliance easier. So I'd declare that scope is limited to plain partitions + LVM. I've used this tool to create an instance of the oVirt web management appliance from its kickstart recipe. Currently developers building the appliance have to boot a VM using the F8 boot.iso and run the kickstart script in the VM and so on. While this works, involves many steps with potential for failure. This new tool reduces the problem to simply As opposed to virt-install --name ... ? I'm not convinced there's a huge gain in terms of number of places for failure :-/ You have to have a working virtualization stack it takes more resource overhead than just doing the chroot'd build. Emprically the part of our build process doing the guest based installs has been less reliable than the livecd-creator part. Havinga disk-creator will address that problem With the background information out of the way, here's some info about the changes in this patch... Ob-side-note: your patch doesn't seem to be against master or at least, is missing some bits as it doesn't want to apply. I used a fresh git checkout from saturday for doing all the work against and don't see any changes since then. Most of the change here involves re-factoring the imgcreate/fs.py module. The SparseExtLoopbackMount, SparseLoopbackMount, LoopbackMount classes all have the built-in limitation that the image being produced corresponds to a single filesystem / loop mount. With the disk creator, the image being produced can be partitioned into multiple chunks, with many filesystems. Furthermore, not all of them require loopback mounts, as the partitions themselves are already visible via /dev/mapper/ So this patch separates the roles. There are now classes which deal with accessing / creating disks: [snip] The 'create' method must make the disk visible as a block device - eg by calling losetup. For RawDisk, this is obviously a no-op. The 'cleanup' method must undo the 'create' operation. Sounds okay... the API change involved is a little unfortunate, but I did caveat that the API in -14 isn't guaranteed, so it should be fine. If its really a problem, we've got the option of just leaving the existing classes unchanged deprecating their use in favour of the new ones, but if no one is using the API seriously yet it might not be worth the hassle. Next, up we have a new class 'PartitionedMount'. This takes a Disk object and adds one or more partitions to it. It then creates further Disk and Mount object instances for each partition. So, mounting a 'PartitionedMount' object will in fact mount all its partitions (formatting the filesystems or swap space as needed). It looks like you're calling parted directly here rather than using the python bindings? The latter is probably somewhat preferable. Also, there are probably some interesting questions about always assuming that you want an msdos partition table :-/ This goes back to my first point... I didn't realize there were useful parted python bindings. I'll happily use them if that's desired. The use of msdos partitions can easily be addressed - I just didn't look to see if there's a kickstart syntax option for specifying partition table type yet. [snip] It doesn't currently care about --ondisk only outputting a single disk image, but I intend to extend the CLI to allow creation of installs which spawn multiple output disks. My only concern with doing it on the CLI is that it makes reproducability of the images more difficult
Re: [Fedora-livecd-list] PATCH: Chroot-Creator subclass and chroot-creator tool
On Mon, Feb 18, 2008 at 05:15:20PM -0500, Warren Togami wrote: Daniel P. Berrange wrote: On Mon, Feb 18, 2008 at 04:58:38PM -0500, Warren Togami wrote: ChrootCreator class and chroot-creator tool - install to a target chroot directory This is slightly updated from my previous post 3 days ago. Your attachment was 0-bytes long Regards, Dan. I'm not sure what's going on here. Prior to resending it I tested it by sending the mail to myself, and it worked. The version of mailman on redhat.com is ancient buggy, breaking if you send patches with git. http://fedorapeople.org/~wtogami/temp/0001-ChrootCreator-class-and-chroot-creator-tool-instal.patch This patch only seems to have the chroot-creator CLI tool, and not the corresponding ChrootCreator class Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool
On Sat, Feb 16, 2008 at 11:18:58PM -0600, Douglas McClendon wrote: Daniel P. Berrange wrote: This patch adds support for another installation variant. The livecd-creator produces ISO images which boot using syslinux. The image-creator creates a single file containing a filesystem in which the OS is installated. This patch adds a new disk-creator, which creates a single file containing a partitioned disk with potentially many filesystems in which the OS is installed. Furthermore it installs grub in the boot sector, so this image is immediately bootable in a virtual machine. FWIW, I advocate, (and my VirOS projects already uses), a system where such a virtual appliance is a mandatory phase of livecd creation. I don't expect any buy-in to convert livecd-creator to this, but this seems an appropriate time to advocate the design choice- Basically, I see it as useful to look at the process as distro_config --(phase1process)-- virtual_appliance_disk_image --(phase2process)-- livecd_image Where an alternate phase2process plugin could be for example - network push deploy to physical host. Or, instantiate to virtual host. The seperation between different processes is more or less what we already have in the live cd code, though not as a pipeline, instead via class inheritance. The livecd library base has the generic logic for processing the kickstarting doing the installation. The livecd/image/ disk creators simply subclass it to add specific code for either ISOs, flat images, or partitioned disks, along with the particular type of bootloader needed (syslinux vs grub). Basically it seems like since what livecd-creator uses internally, is already _so close_ to an appliance image like this new disk-creator creates already, why not just go ahead and do it (also, theoretically for QA turnaround time, testing new stuff as virtappliance_diskimage is much quicker than waiting for full livecd mksquashfs processing) There is no significant time difference between any of the tools. If you add the secret undocumented --skip-compression and --skip-minimize flags to livecd-creator, it'll be just as fast as the disk creator. Another reason why I like that pipeline breakdown, is because the sorts of things that go on in phase2process can even be largely distribution agnostic. Combined with alternate phase1process plugins that support other distributions, and you get quite a flexible provisioning tool. A significant part of the phase 2 procss is dealing with the bootloader and initrd setup which is far from distro-agnostic. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool
On Sun, Feb 17, 2008 at 02:14:43AM +, Daniel P. Berrange wrote: Future enhancements for this: - Allow splitting across multiple disks (sda, sdb, etc) - When staging final image, use qemu-img to generate qcow2, vmdk or raw files at user's choice. qcow2 would give huge size savings - Output XML file for use with 'virt-image' tool, so that the entire build and deploy process consists of nothing more than: # disk-creator ovirt-wui-appliance.ks # virt-image ovirt-wui-appliance.xml This new version of the patch implements all three of the above features. As an example, creating an appliance with 2 disks (sda sdb), outputting in qcow2 format: disk-creator --format qcow2 \ --name ovirt-wui \ --disk ovirt-wui-os --size 5000 \ --disk ovirt-wui-data --size 1000 \ ovirt-wui-appliance.ks You'll end up with ovirt-wui-os.qcow2, ovirt-wui-data.qcow2 and ovirt-wui.xml This can be deployed as a VM with virt-image --connect qemu:///system ovirt-wui.xml Well, due to a bug in virt-image, it'll refuse to create a VM with qcow2 disks, but I've fixed that upstream. For now just leave out the --format arg to create in raw file. I'm definitely now of opinion we should actually name it appliance-creator instead of disk-creator, but not changed it in this patch yet. The attached patch touches: API|4 Makefile |3 imgcreate/__init__.py |3 imgcreate/creator.py | 17 + imgcreate/disk.py | 146 ++ imgcreate/fs.py| 480 +++-- imgcreate/kickstart.py |3 imgcreate/live.py |6 livecd-tools.spec |1 tools/disk-creator | 49 - 10 files changed, 569 insertions(+), 143 deletions(-) Also attaching the new kickstart file I'm using for multi-disks. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| diff --git a/API b/API index 9783c74..ef9c1aa 100644 --- a/API +++ b/API @@ -76,3 +76,7 @@ switching from the LiveImageCreator to another ImageCreator object. build live images which use dm-snapshot, etc. This is what is used by livecd-creator. +* DiskImageCreator: This generates disk images containing multiple + partitions in a loopback file. It installs grub in the MBR and + can be directly booted in any virtual machine + diff --git a/Makefile b/Makefile index 050fe88..d3d4ab7 100644 --- a/Makefile +++ b/Makefile @@ -18,6 +18,7 @@ all: install: $(INSTALL_PROGRAM) -D tools/livecd-creator $(DESTDIR)/usr/bin/livecd-creator $(INSTALL_PROGRAM) -D tools/image-creator $(DESTDIR)/usr/bin/image-creator + $(INSTALL_PROGRAM) -D tools/disk-creator $(DESTDIR)/usr/bin/disk-creator $(INSTALL_PROGRAM) -D tools/livecd-iso-to-disk.sh $(DESTDIR)/usr/bin/livecd-iso-to-disk $(INSTALL_PROGRAM) -D tools/livecd-iso-to-pxeboot.sh $(DESTDIR)/usr/bin/livecd-iso-to-pxeboot $(INSTALL_PROGRAM) -D tools/mayflower $(DESTDIR)/usr/lib/livecd-creator/mayflower @@ -34,6 +35,8 @@ install: uninstall: rm -f $(DESTDIR)/usr/bin/livecd-creator rm -rf $(DESTDIR)/usr/lib/livecd-creator + rm -rf $(DESTDIR)/usr/bin/disk-creator + rm -rf $(DESTDIR)/usr/bin/image-creator rm -rf $(DESTDIR)/usr/share/doc/livecd-tools-$(VERSION) rm -rf $(DESTDIR)/usr/share/livecd-tools diff --git a/imgcreate/__init__.py b/imgcreate/__init__.py index e535014..44f3ec5 100644 --- a/imgcreate/__init__.py +++ b/imgcreate/__init__.py @@ -21,6 +21,7 @@ from imgcreate.creator import * from imgcreate.yuminst import * from imgcreate.kickstart import * from imgcreate.fs import * +from imgcreate.disk import * A set of classes for building Fedora system images. @@ -28,6 +29,7 @@ The following image creators are available: - ImageCreator - installs to a directory - LoopImageCreator - installs to an ext3 image - LiveImageCreator - installs to a bootable ISO + - DiskImageCreator - installs to a partitioned disk image Also exported are: - CreatorError - all exceptions throw are of this type @@ -60,6 +62,7 @@ __all__ = ( 'ImageCreator', 'LiveImageCreator', 'LoopImageCreator', +'DiskImageCreator', 'FSLABEL_MAXLEN', 'read_kickstart', 'construct_name' diff --git a/imgcreate/creator.py b/imgcreate/creator.py index c2ed770..fb3b309 100644 --- a/imgcreate/creator.py +++ b/imgcreate/creator.py @@ -207,7 +207,11 @@ class ImageCreator(object): s = /dev/root / %sdefaults,noatime 0 0\n %(self._fstype) -s += devpts /dev/pts devpts gid=5,mode=620 0 0\n +s += self
[Fedora-livecd-list] PATCH: Disk (appliance) creator tool
This patch adds support for another installation variant. The livecd-creator produces ISO images which boot using syslinux. The image-creator creates a single file containing a filesystem in which the OS is installated. This patch adds a new disk-creator, which creates a single file containing a partitioned disk with potentially many filesystems in which the OS is installed. Furthermore it installs grub in the boot sector, so this image is immediately bootable in a virtual machine. The idea is that this serves as a tool for creating pre-installed appliances suitable for distribution to end users, with no further installation steps required, beyond potentially an appliance specific firstboot script. I've used this tool to create an instance of the oVirt web management appliance from its kickstart recipe. Currently developers building the appliance have to boot a VM using the F8 boot.iso and run the kickstart script in the VM and so on. While this works, involves many steps with potential for failure. This new tool reduces the problem to simply disk-creator --name ovirt-wui-demo.dsk ovirt-wui-appliance.ks A short while later you end up with 'ovirt-wui-demo.dks' which you can boot straight up in KVM / Xen / etc. With the background information out of the way, here's some info about the changes in this patch... Most of the change here involves re-factoring the imgcreate/fs.py module. The SparseExtLoopbackMount, SparseLoopbackMount, LoopbackMount classes all have the built-in limitation that the image being produced corresponds to a single filesystem / loop mount. With the disk creator, the image being produced can be partitioned into multiple chunks, with many filesystems. Furthermore, not all of them require loopback mounts, as the partitions themselves are already visible via /dev/mapper/ So this patch separates the roles. There are now classes which deal with accessing / creating disks: Disk - generic base for disks RawDisk- a disk backed by a block device LoopbackDisk - a disk backed by a file SparseLoopbackDisk - a disk backed by a sparse file The 'create' method must make the disk visible as a block device - eg by calling losetup. For RawDisk, this is obviously a no-op. The 'cleanup' method must undo the 'create' operation. There are then classes which deal with mounting things: Mount- generic base for mounts DiskMount- able to mount a Disk object ExtDiskMount - able to format/resize ext3 filesystems when mounting The livecd-creator/image-creator tools are updated to take account of these API changes. Next, up we have a new class 'PartitionedMount'. This takes a Disk object and adds one or more partitions to it. It then creates further Disk and Mount object instances for each partition. So, mounting a 'PartitionedMount' object will in fact mount all its partitions (formatting the filesystems or swap space as needed). Currently only ext3/swap is supported for partition types. We use parted to create partitions. This works well enough, but parted will spew lots of scary looking warnings about being unable to tell the kernel to reload its partition table. This is because loop devices don't support partition tables. In this scenario though its not a problem because we then use the kpartx tool to add entries to /dev/mapper for each partition. When mounting partitions, PartitionedMount, figures out the correct order based on the mount points, so it ensures the / is mounted before /boot. The imgcreator/disk.py class contains the DiskImageCreator class which is a subclass of ImageCreator. This uses the PartitionedMount object to do an installation of the kickstart. It is fairly simple at the moment, only being able to cope with 'part' entries in the kickstart which are either ext3 or swap, and which have an explicit size given - ie --grow is not supported. For testing I've been using part /boot --fstype ext3 --size=100 --ondisk=sda part swap --fstype swap --size=500 --ondisk=sda part /var/lib/pgsql --fstype ext3 --size=300 --ondisk=sda part / --fstype ext3 --size=3000 --ondisk=sda part /home --fstype ext3 --size=500 --ondisk=sda part /var --fstype ext3 --size=1000 --ondisk=sda Which ensures it correctly deals with adding extended and logical partitions. It doesn't currently care about --ondisk only outputting a single disk image, but I intend to extend the CLI to allow creation of installs which spawn multiple output disks. Aside from partitioning, DiskImageCreator will setup an fstab file containing entries for all the filesystems and swap space. It will add the grub device map file, and create a grub.cfg based off the installed kernel. It is able to cope with a layout where grub config is on /, or a separate /boot partition. We can't use grub-install since it doesn't understand loopdevices, so to do the MBR install we invoke grub manually. If the disk image happens to be the same size or smaller than one of
Re: Argyll color management system integration
On Wed, Dec 12, 2007 at 06:35:56PM +0100, Nicolas Mailhot wrote: I started untangling the mess in October but gave up after a frustrating week. Fortunately I had the good idea to put the result on fedorapeople, and lately Frédéric Crozat from Mandriva googled it and completed the work. On hindsight it seems I had stopped just short of the finish line. http://twinpeaks.dyndns.org/blog/general/2007/12/11/monitor-calibration-epilogue Since it'd be a shame to let my packaging work end up in Mandriva only, I picked up his package, changed back a few bits, added some stuff I had planned but not done yet, and pushed the result in the review queue: https://bugzilla.redhat.com/show_bug.cgi?id=421921 I'd appreciate if a friendly reviewer looked at the result. I've had a crack at packaging argylcms too but also gave up with the crazy JAM and static linking stuff. I'll give your packages a once-over. The following work has been done: ??? link against system libs, not built-in copies ??? build with modular X ??? remove the shell wrapper that was hiding build errors from rpm ??? reorder build logic to fix those errors ??? hal/pam/udev logic so colorimeters do not need root access The result is IMHO good enough to be merged. However, since this software has suffered from a secluded life due to the aforementioned problems, it would probably be a good idea if more clueful people than me checked the following points: ??? go over the build logs, ???check if the warnings are really harmless and fix the code if needed (where is the list of people that wanted to do this kind of work a few months ago?) http://nim.fedorapeople.org/argyllcms/build.log I doubt argyllcms was ever built with a modern gcc with all the fancy options we use and for all the architectures we target ??? check if I got the hal/pam/udev logic right, push bits upstream if needed (I didn't find two Fedora packages that did it the same way, all I can say the way I did it works on my system) I've got a Optix XR instrument which I can test the udev bits with. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
