Re: Orphaning kadu
W dniu 19.03.2010 00:24, Dominik 'Rathann' Mierzejewski pisze: On Thursday, 18 March 2010 at 20:33, Julian Sikorski wrote: W dniu 18.03.2010 10:45, Dominik 'Rathann' Mierzejewski pisze: On Thursday, 18 March 2010 at 00:32, Julian Sikorski wrote: [...] I'll try to get it done tomorrow, last time I looked the kadu spec looked very convoluted. The person who wants to take over maintainership has submitted an updated package here: https://bugzilla.redhat.com/show_bug.cgi?id=573294 I guess you can use that after reviewing the changes. I'll try to do a formal review over the weekend unless you want to do it. I took a stab at it myself before I saw this mail. Anyway, some more updates needed, the package from the review won't build on fedora = 13, for instance. Also, the installation path of some modules is wrong. I posted my version in the review. Also, I asked for an override tag for libgadu in F12 (ticket 3526). Should I commit the files to CVS, or wait for the review to be done? Well, formally, since it's orphaned and more than 3 months have passed since the last change, it needs a re-review. Also I'm still waiting for a reply from Radek. Regards, R. OK. I'll forward the patches upstream in the meantime then. Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
On 03/05/2010 02:55 AM, Pete Zaitcev wrote: OK, that sounds good. So, I withdraw objections after Rahul's question, as far as Fedora is concerned. I have added it to the hardware support group as a default package for Fedora 13. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Thu, Mar 18, 2010 at 11:25:45PM -0500, Matt Domsch wrote: On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote: Hi, how about using GPT[0] partitions for F14 for all installations that wipe the whole disk to install Fedora? It is also considered to be good by Tejun Heo[1] and it seems to work nicely already on F12. I just partitioned a new HD using gdisk and the kernel seems to recognise it without any problems. Very few BIOSes can boot from a GPT disk. Urban legend... EFI/UEFI can, as can legacy BIOS if you do something ugly like gptsync so the MBR partition table and the GPT partition table at least somewhat agree. The problem is old grub. Karel -- Karel Zak k...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
Am Dienstag, den 16.03.2010, 19:05 +0100 schrieb Kevin Kofler: Peter Lemenkov wrote: * Automatically add latest %changelog entry to each Bodhi update as Notes or as something else (new field, perhaps). The changelog information is already provided in the update detail metadata, gnome-packagekit displays it as update notes if you don't fill in any actual update notes, KPackageKit even always displays it. KPackageKit != Bodhi: When you use fedora-easy-karma or the updates site to provide testing feedback, it would be nice to have such a %changelog field, *expecially* if there are no updates notes shipped with the package. In this case it would be absolutely nessesary to have at least the changelog as notes there (if not getting the extra field). Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
On Thu, Mar 18, 2010 at 18:07, Thomas Spura spur...@students.uni-mainz.de wrote: Am Dienstag, den 16.03.2010, 19:05 +0100 schrieb Kevin Kofler: Peter Lemenkov wrote: * Automatically add latest %changelog entry to each Bodhi update as Notes or as something else (new field, perhaps). The changelog information is already provided in the update detail metadata, gnome-packagekit displays it as update notes if you don't fill in any actual update notes, KPackageKit even always displays it. KPackageKit != Bodhi: When you use fedora-easy-karma or the updates site to provide testing feedback, it would be nice to have such a %changelog field, *expecially* if there are no updates notes shipped with the package. In this case it would be absolutely nessesary to have at least the changelog as notes there (if not getting the extra field). Or maybe package maintainers could write decent update notes? I don't know, maybe that's just a crazy idea... ;) -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
On Fri, Mar 19, 2010 at 9:52 AM, Rahul Sundaram methe...@gmail.com wrote: On 03/05/2010 02:55 AM, Pete Zaitcev wrote: OK, that sounds good. So, I withdraw objections after Rahul's question, as far as Fedora is concerned. I have added it to the hardware support group as a default package for Fedora 13. Just to be sure: do this mean users with those dongles should have a works out of the box experience with NetworkManager in F13? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
Am Freitag, den 19.03.2010, 11:33 +0100 schrieb Mathieu Bridon: On Thu, Mar 18, 2010 at 18:07, Thomas Spura spur...@students.uni-mainz.de wrote: Am Dienstag, den 16.03.2010, 19:05 +0100 schrieb Kevin Kofler: Peter Lemenkov wrote: * Automatically add latest %changelog entry to each Bodhi update as Notes or as something else (new field, perhaps). The changelog information is already provided in the update detail metadata, gnome-packagekit displays it as update notes if you don't fill in any actual update notes, KPackageKit even always displays it. KPackageKit != Bodhi: When you use fedora-easy-karma or the updates site to provide testing feedback, it would be nice to have such a %changelog field, *expecially* if there are no updates notes shipped with the package. In this case it would be absolutely nessesary to have at least the changelog as notes there (if not getting the extra field). Or maybe package maintainers could write decent update notes? I don't know, maybe that's just a crazy idea... ;) Sure, but they don't have to and so some don't do that... :( And some of them might think, the changelog says enought, so I don't write it there (because that would just be copypaste). When there are no notes and the changelog is then showing up, then they at least think right... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: Alexander Boström wrote: ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. Problems can probably be expected in case the drive does not report its real block size to the software, though, like my WD15EARS (I think) or VMware's emulated SCSI drives. There's only so much we can do in the face of bad hardware ;) How about making it possible to overwrite the wrong reported values, e.g. by making /sys/block/sdb/queue/[physical_block_size writable,minimum_io_size} writable. Regards Till pgphdeK5S3ddA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, Mar 19, 2010 at 12:22:56PM +0200, Manuel Wolfshant wrote: Till Maas wrote: On Fri, Mar 19, 2010 at 10:34:59AM +0100, Karel Zak wrote: I am also pretty sure that a BIOS does not consider the partition table to boot, I can vouch for at least 2 Intel based motherboards which do not boot unless a) there exists a partition table and b) one partition is marked as active There still will be a partition table, but it will always show a partition that starts at sector 1. By default it seems not to be marked as active, but this should be possible. This is then the old style partition, that contains the new GPT header and partitions. Regards Till pgp17WgkrZOL9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Thu, 2010-03-18 at 21:55 +0100, Till Maas wrote: how about using GPT[0] partitions for F14 for all installations that wipe the whole disk to install Fedora? It is also considered to be good by Tejun Heo[1] and it seems to work nicely already on F12. I just partitioned a new HD using gdisk and the kernel seems to recognise it without any problems. Are there any good reasons to do this _other_ than so we can cope with larger disks? How about doing it only for disks which are too large to cope with the DOS-style partition tables? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
my dmesg is attached dmesg.txt.gz Description: GNU Zip compressed data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/19/2010 08:08 AM, Till Maas wrote: On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: Alexander Boström wrote: ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. Problems can probably be expected in case the drive does not report its real block size to the software, though, like my WD15EARS (I think) or VMware's emulated SCSI drives. There's only so much we can do in the face of bad hardware ;) How about making it possible to overwrite the wrong reported values, e.g. by making /sys/block/sdb/queue/[physical_block_size writable,minimum_io_size} writable. Regards Till I think that would be a bad idea - if you know what you want to change, why not just invoke the tool with those specific parameters? It would be very confusing to have us probe the device, get the real information from the storage device and then let a user update that information to something false :-) ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, Mar 19, 2010 at 01:04:29PM +, David Woodhouse wrote: On Thu, 2010-03-18 at 21:55 +0100, Till Maas wrote: how about using GPT[0] partitions for F14 for all installations that wipe the whole disk to install Fedora? It is also considered to be good by Tejun Heo[1] and it seems to work nicely already on F12. I just partitioned a new HD using gdisk and the kernel seems to recognise it without any problems. Are there any good reasons to do this _other_ than so we can cope with larger disks? Afaik it is also required in case one uses EFI instead of a BIOS. Doing this soon would make Fedora ready once it is required. Other nice features are checksums for the partition table and file system independent uuids for the partitions and file system independent clear text names for partitions. These can be used to easier identify partitions that do not contain a file system, e.g. because they are encrypted or they have been wiped. Then they could be easier identified to be used again, e.g. in the installer. How about doing it only for disks which are too large to cope with the DOS-style partition tables? For large disks it would be required anyhow. But it does not need to be default, at least support for it in the installer would be nice. Regards Till pgpLj7KHXno2A.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
On 03/19/2010 03:07 PM, Muayyad AlSadi wrote: my dmesg is attached Thanks; if this doesn't occur with the previous version of the kernel, file a bug in bugzilla.redhat.com and paste the link to the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-DBIx-Class
perl-DBIx-Class has broken dependencies in the rawhide tree: On x86_64: perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::ClassResolver::PassThrough) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin::Descriptive) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Storage::DBI::Replicated::Types) On i386: perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::ClassResolver::PassThrough) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin::Descriptive) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Storage::DBI::Replicated::Types) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Stable Release Updates types proposal
On 03/18/2010 09:00 PM, Adam Williamson wrote: . That's somewhat optimistic; no matter how much testing we do, we can only afford a certain amount of full-time developer muscle. The testing has helped to improve efficiency and direction of graphics development work, I think, but there's fundamentally a lot of work to do and only a limited amount of manpower to do it with. The X devs are always very happy to take new volunteers. :) Although I have done a fair amount of X development work in the past, unfortunately, as with most people, my volunteer time is in short supply (I have a wife and kids to support :) ). So in use testing, bug reporting and attempting the first pass bug searches is currently my limit in Fedora. If there were less churn in Fedora to cope with perhaps I and other user/developers would have more unpaid volunteer time to devote to actual development :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100319 changes
Compose started at Fri Mar 19 08:15:18 UTC 2010 Broken deps for i386 -- edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 murmur-1.1.8-15.fc12.i686 requires libIce.so.33 murmur-1.1.8-15.fc12.i686 requires libIceUtil.so.33 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::ClassResolver::PassThrough) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin::Descriptive) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Storage::DBI::Replicated::Types) php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2
Re: Hard drive spec change
On Fri, Mar 19, 2010 at 09:56:10AM -0400, Ric Wheeler wrote: We are currently working to verify that storage devices work properly report the information that they want us to use (doing this with several storage providers and have also raised this with EMC/VMware). If we see real world issues during this testing, we can start thinking about how to fix it. This is good, but it already failed with Western Digital afaik. I somewhere read that they did it correctly with test drives but now the released drives do not report their sizes properly, so there are already real world issues. It was mentioned on this thread I and have a WD20EARS that shows this problem, too. Regards Till pgpd1sn5UyTmK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: first reviews for dual packages
- Paul Howarth p...@city-fan.org wrote: On 16/03/10 16:33, Iain Arnell wrote: On Tue, Mar 16, 2010 at 5:17 PM, Marcela Maslanovammasl...@redhat.com wrote: - Iain Arnelliarn...@gmail.com wrote: I guess perl.spec needs a little more work up front to split as much as possible into separate sub-packages. Ok, but in this case we need for almost every provides a sub-package. Wouldn't be sufficient to check perl.spec and create sub-package after the separated module will be needed? That would also work, of course. But should be mentioned in the guidelines too. Wouldn't this approach mean that the main perl package needed to be updated whenever a new updated module was needed, which was one of the things this scheme was trying to avoid? Paul. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel So, test with Getopt::Long showed that there would be conflicting man-pages. I don't think create sub-package for all modules is possible. Also this doesn't help readability of specfile. These smaller modules can be updated once a time in main package. People usually want updates only of those modules which already have sub-package. I'm not saying that's the best solution... Any other better ideas? -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Hard drive spec change
On 03/19/2010 10:04 AM, Till Maas wrote: On Fri, Mar 19, 2010 at 09:56:10AM -0400, Ric Wheeler wrote: We are currently working to verify that storage devices work properly report the information that they want us to use (doing this with several storage providers and have also raised this with EMC/VMware). If we see real world issues during this testing, we can start thinking about how to fix it. This is good, but it already failed with Western Digital afaik. I somewhere read that they did it correctly with test drives but now the released drives do not report their sizes properly, so there are already real world issues. It was mentioned on this thread I and have a WD20EARS that shows this problem, too. Regards Till We should follow up with them and see if we can help them fix their devices... ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/19/2010 10:04 AM, Till Maas wrote: On Fri, Mar 19, 2010 at 09:56:10AM -0400, Ric Wheeler wrote: We are currently working to verify that storage devices work properly report the information that they want us to use (doing this with several storage providers and have also raised this with EMC/VMware). If we see real world issues during this testing, we can start thinking about how to fix it. This is good, but it already failed with Western Digital afaik. I somewhere read that they did it correctly with test drives but now the released drives do not report their sizes properly, so there are already real world issues. It was mentioned on this thread I and have a WD20EARS that shows this problem, too. Regards Till I should have asked - do you have the details captured in bugzilla? If so, that will be useful to help kick off the discussion with them. Thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Fri, Mar 19, 2010 at 10:25:38AM -0400, Ric Wheeler wrote: I should have asked - do you have the details captured in bugzilla? If so, that will be useful to help kick off the discussion with them. It seemed to be common knowledge already, but I just created a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=575143 Regards Till pgpnWwPDsAwPy.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi error?
ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/13, 500, Unknown HTTP Server Response) This is while creating an update. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-DBIx-Class/devel perl-DBIx-Class.spec,1.26,1.27
Author: cweyl
Update of /cvs/extras/rpms/perl-DBIx-Class/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv7878
Modified Files:
perl-DBIx-Class.spec
Log Message:
* Fri Mar 19 2010 Chris Weyl cw...@alumni.drew.edu 0.08120-3
- quiet our repo/dep-checking scripts as we figure out how to handle no_index
from a requires perspective
Index: perl-DBIx-Class.spec
===
RCS file: /cvs/extras/rpms/perl-DBIx-Class/devel/perl-DBIx-Class.spec,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -p -r1.26 -r1.27
--- perl-DBIx-Class.spec17 Mar 2010 16:34:21 - 1.26
+++ perl-DBIx-Class.spec19 Mar 2010 15:57:56 - 1.27
@@ -1,7 +1,7 @@
Name: perl-DBIx-Class
Summary:Extensible and flexible object - relational mapper
Version:0.08120
-Release:2%{?dist}
+Release:3%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-%{version}.tar.gz
@@ -85,6 +85,7 @@ BuildRequires: perl(namespace::clean) =
%{?filter_from_requires: %filter_from_requires /^perl(DBD::Pg)$/d }
%{?perl_default_filter:
+%filter_from_requires
/^perl(DBIx::Class::\(Admin\|CDBICompat\|ClassResolver\|Storage\)/d
%filter_provides_in %{perl_vendorlib}/DBIx/Class/Admin
%filter_requires_in %{perl_vendorlib}/DBIx/Class/Admin
%filter_provides_in %{perl_vendorlib}/DBIx/Class/CDBICompat
@@ -158,6 +159,10 @@ rm -rf %{buildroot}
%changelog
+* Fri Mar 19 2010 Chris Weyl cw...@alumni.drew.edu 0.08120-3
+- quiet our repo/dep-checking scripts as we figure out how to handle no_index
+ from a requires perspective
+
* Wed Mar 17 2010 Chris Weyl cw...@alumni.drew.edu 0.08120-2
- update F::A::MT so bits marked as no_index are filtered both for provides
_and_ requires
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DBIx-Class/devel auto.ini,1.3,1.4
Author: cweyl Update of /cvs/extras/rpms/perl-DBIx-Class/devel In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8120 Modified Files: auto.ini Log Message: * Fri Mar 19 2010 Chris Weyl cw...@alumni.drew.edu 0.08120-3 - quiet our repo/dep-checking scripts as we figure out how to handle no_index from a requires perspective Index: auto.ini === RCS file: /cvs/extras/rpms/perl-DBIx-Class/devel/auto.ini,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -r1.3 -r1.4 --- auto.ini17 Mar 2010 16:32:28 - 1.3 +++ auto.ini19 Mar 2010 15:58:32 - 1.4 @@ -9,3 +9,4 @@ perl(Test::Moose)=0 ; Note that maintainertool automatically generates filter macro statements for ; packages/directories marked as no_index in META.yml. filter_from_requires=/^perl(DBD::Pg)$/d +filter_from_requires=/^perl(DBIx::Class::\(Admin\|CDBICompat\|ClassResolver\|Storage\)/d -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Debugging printing problems
On Thu, 2010-03-18 at 21:37 +0100, Louis Lagendijk wrote: great info indeed. Maybe you could consider adding info on the bjnp backend (for Canon's proprietary network (usb-over-ip) protocol: bjnp is for Canon's proprietary bjnp network protocol (usually port 8611) The bjp backend is available in the cups-bjnp package Feel free to edit the wiki, although perhaps that ought to go on the main Printing page. I've added it there now: https://fedoraproject.org/wiki/Printing Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 install timings
I don't know if it is too early to do install timings (due to debugging be on in the kernel, elsewhere?) but here are the longest steps from a fairly stripped down kickstart server install of about 389 packages: F-13: enablefilesystems 3:10s postselection24:27s installpackages 14:30s F-12: enablefilesystems 2:50s postselection36:45s installpackages 11:36s (probably had more packages in our local cache) The install spends a long time displaying Checking dependencies in packages selected for installation with no movement of the progress bar. Any way this could get sped up more (good job going from 36m to 24m) and progress shown? Interestingly a much larger install set on a laptop took only 1:34s in postselection. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, 2010-03-19 at 13:04 +, David Woodhouse wrote: Are there any good reasons to do this _other_ than so we can cope with larger disks? How about doing it only for disks which are too large to cope with the DOS-style partition tables? Why deal with two different types of partitioning tables? Why /not/ go forward to GPT, I think that's the more appropriate question. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100319 changes
Compose started at Fri Mar 19 09:15:32 UTC 2010 Broken deps for i386 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 New package dcap Client Tools for dCache New package dogtag-pki Dogtag Public Key Infrastructure (PKI) Suite New package perl-Config-INI-MVP Multi-value capable .ini file reader (for plugins) Updated Packages: bash-completion-1.1-6.fc13 -- * Thu Mar 11 2010 Todd Zullinger t...@pobox.com - 1:1.1-6 - Apply upstream post 1.1 service argument fix (#572794). comix-4.0.4-3.fc13 -- * Thu Mar 18 2010 Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp - 4.0.4-3 - Handle the error when the media where opened archive existed is removed (bug 542752, 34) - Handle some error cases in comicthumb (bug 568167, 572434) - Remove macros no longer used, spec file cleanup - GConf2 scriptlets update conexus-0.9.1-1.fc13 * Mon Mar 08 2010 Rick L Vinyard Jr rviny...@cs.nmsu.edu - 0.9.1-1 - New release - Removed openssl patch since it is now incorporated upstream control-center-2.29.92-1.fc13 - * Tue Mar 09 2010 Bastien Nocera bnoc...@redhat.com 2.29.92-1 - Update to 2.29.92 cpio-2.10-6.fc13 * Wed Mar 10 2010 Ondrej Vasik ova...@redhat.com 2.10-6 - CVE-2010-0624 fix heap-based buffer overflow by expanding a specially-crafted archive(#572150) dovecot-1.2.11-2.fc13 - * Fri Mar 12 2010 Michal Hlavinka mhlav...@redhat.com - 1:1.2.11-2 - fix missing bzip2 support in zlib plugin (#572797) * Tue Mar 09 2010 Michal Hlavinka mhlav...@redhat.com - 1:1.2.11-1 - updated to 1.2.11 - mbox: Message header reading was unnecessarily slow. Fetching a huge header could have resulted in Dovecot eating a lot of CPU. Also searching messages was much slower than necessary. - maildir: Reading uidlist could have ended up in an infinite loop. - IMAP IDLE: v1.2.7+ caused extra load by checking changes every 0.5 seconds after a change had occurred in mailbox dpkg-1.15.5.6-4.fc13 * Thu Mar 11 2010 Andrew Colin Kissa and...@topdog.za.net - 1.15.5.6-4 - Fix CVE-2010-0396 dvb-apps-1.1.1-21.fc13 -- * Tue Mar 16 2010 Ville Skyttä ville.sky...@iki.fi - 1.1.1-21 - Apply upstream patch to add tzap AUTO param support (#574112, AUDU Jerome). - Update tuning files to 20100316. e2fsprogs-1.41.10-6.fc13 * Mon Mar 15 2010 Eric Sandeen sand...@redhat.com 1.41.10-6 - Completely drop the misalignment question in mkfs (#573643) easystroke-0.5.3-1.fc13 --- * Wed Mar 17 2010 Tom spot Callaway tcall...@redhat.com - 0.5.3-1 - update to 0.5.3 - drop timing patch (upstreamed) - add patch to fix indirect linking issue * Fri Jan 22 2010 Rahul Sundaram sunda...@fedoraproject.org - 0.5.2-2 - Rebuild for Boost soname bump ecl-10.3.1-1.fc13 - * Tue Mar 09 2010 Jerry James loganje...@gmail.com - 10.3.1-1 - New release 10.3.1 evince-2.29.92-1.fc13 - * Thu Mar 11 2010 Matthias Clasen mcla...@redhat.com - 2.29.92-1 - Update to 2.29.92 * Wed Mar 10 2010 Marek Kasik mka...@redhat.com - 2.29.91-3 - Replace deprecated gtk functions with their equivalents - Remove unused patches * Tue Mar 09 2010 Marek Kasik mka...@redhat.com - 2.29.91-2 - Use Type 1 fonts when viewing DVI files - Use correct name when the font is mapped - Related: #562648 fcoe-utils-1.0.12-1.fc13 * Tue Mar 16 2010 Jan Zeleny jzel...@redhat.com - 1.0.12-1 - rebased to version 1.0.12, improved functionality with lldpad and dcbd - removed fcoeplumb script from /etc/fcoe/scripts fedora-easy-karma-0-0.5.20100315gitacf8b834.fc13 * Mon Mar 15 2010 Till Maas opensou...@till.name - 0-0.5.20100315gitacf8b834 - Update to new snapshot * Mon Mar 08 2010 Till Maas opensou...@till.name - 0-0.4.20100308git1d2e3a85 - Update to new snapshot - Set useragent flashrom-0.9.1-3.svn931.fc13 * Fri Mar 12 2010 Peter
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
Am 19.03.10 17:52, schrieb Jesse Keating: Why deal with two different types of partitioning tables? Why /not/ go forward to GPT, I think that's the more appropriate question. No all operating systems are able to support GPT, so there may be nice to have a hybrid partition schema. Aspecial if you want a tripple boot system on a Macaintosh system, there will be nice to have this feature, because you can only have four partition in the MBR, which may be assigned as follow: Partitiona #1EFI system partition Partition #2:Mac OX X Partition #3:Linux Partition #4:Windows Anyone in the future we may not have this discussion because all computer have moved to a UEFI systen caused by the 2 TB limitation of the MBR partition schea, but now we have the issue, that we have to support OS which are unable to support GPT partition hard discs. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: On Friday 19 March 2010, Jon Ciesla wrote: ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. I got that earlier today too, when the close bugs checkbox was ticked. I managed to submit the same update after unticking it. I think this is a transient error from packagedb -- if it's repeatable, it's something I can take a look at and hopefully fix quickly. Also -- I have just deployed a new version of packagedb that fixes one of the sources of transient failures. It's possible that it will fix this. Please let me know if you can get this repeatedly or if it seems to have gone away. -Toshio pgpwyTf4jwfIT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
Am Donnerstag, den 18.03.2010, 23:30 +0530 schrieb Rakesh Pandit: On 18 March 2010 00:19, Branched Report wrote: Compose started at Wed Mar 17 09:15:24 UTC 2010 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 Thanks Quentin for looking into this and Jesse for importing. I have filled up bodhi update and requested for testing. Why testing? A maybe-broken update is better than a non-working programm isn't it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: On Friday 19 March 2010, Jon Ciesla wrote: ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. I got that earlier today too, when the close bugs checkbox was ticked. I managed to submit the same update after unticking it. If you try again, it will most likely work. These sporadic errors are probably due to the FAS identity provider/ visit manager that our TurboGears apps use. However, the pkgdb isn't logging tracebacks properly, so we really don't know exactly where it is coming from, though I assume it's pycurl throwing an error while trying to connect to FAS. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura spur...@students.uni-mainz.de wrote: Why testing? A maybe-broken update is better than a non-working programm isn't it? Because there are a significant number of people that will scream bloody murder if people push packages directly to stable without having the package spend at least a little time in testing, no matter what the reason. There have been enough problems with seemingly safe updates that go directly to stable that I have a hard time disagreeing with them. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
Toshio Kuratomi wrote: On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: On Friday 19 March 2010, Jon Ciesla wrote: ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. I got that earlier today too, when the close bugs checkbox was ticked. I managed to submit the same update after unticking it. I think this is a transient error from packagedb -- if it's repeatable, it's something I can take a look at and hopefully fix quickly. Also -- I have just deployed a new version of packagedb that fixes one of the sources of transient failures. It's possible that it will fix this. Please let me know if you can get this repeatedly or if it seems to have gone away. -Toshio I will, thanks! -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
Luke Macken wrote: On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: On Friday 19 March 2010, Jon Ciesla wrote: ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. I got that earlier today too, when the close bugs checkbox was ticked. I managed to submit the same update after unticking it. If you try again, it will most likely work. These sporadic errors are probably due to the FAS identity provider/ visit manager that our TurboGears apps use. However, the pkgdb isn't logging tracebacks properly, so we really don't know exactly where it is coming from, though I assume it's pycurl throwing an error while trying to connect to FAS. luke I already submitted mine without the box checked, but I'll keep an eye out. Thanks! -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
On 03/19/2010 04:26 PM, Gianluca Sforna wrote: Just to be sure: do this mean users with those dongles should have a works out of the box experience with NetworkManager in F13? I don't know that. I believe it requires NM/ModemManager changes but atleast it would be easier to do the manual configuration if that is still required. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
it happens with both kernels but it hanged completely with the newer one, and it freeze for seconds and then respond with the older one at least is what happened so far. is there a way that I know it's not a hardware issue on my HDD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
as I said palimpsest disk utility did not report any thing the smart output is attached smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.11 Device Model: ST3500320AS Serial Number:6QM0NP93 Firmware Version: SD1A User Capacity:500,107,862,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is:Fri Mar 19 21:21:23 2010 EET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 642) seconds. Offline data collection capabilities:(0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 119) minutes. Conveyance self-test routine recommended polling time:( 2) minutes. SCT capabilities: (0x103b) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 118 099 006Pre-fail Always - 172966470 3 Spin_Up_Time0x0003 095 094 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 635 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 077 060 030Pre-fail Always - 52651756 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 3464 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 635 184 Unknown_Attribute 0x0032 100 100 099Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 188 Unknown_Attribute 0x0032 100 094 000Old_age Always - 38655296524 189 High_Fly_Writes 0x003a 084 084 000Old_age Always - 16 190 Airflow_Temperature_Cel 0x0022 070 056 045Old_age Always - 30 (Lifetime Min/Max 16/30) 194 Temperature_Celsius 0x0022 030 044 000Old_age Always - 30 (0 7 0 0) 195 Hardware_ECC_Recovered 0x001a 038 021 000Old_age Always - 172966470 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 95 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 3456 - # 2 Short offline Completed without error 00% 241 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA
New maintainer for Quod Libet
I no longer use Quod Libet on a regular basis and I can't spare the time right now to fix up the issues that the package has. So I'm looking for someone to take over maintainership. I would have released ownership in the package database already but I'm getting an error... -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote: Hi, how about using GPT[0] partitions for F14 for all installations that wipe the whole disk to install Fedora? It is also considered to be good by Tejun Heo[1] and it seems to work nicely already on F12. I just partitioned a new HD using gdisk and the kernel seems to recognise it without any problems. Yes! Hopefully BIOS support won't be a problem because of gptsync. Can we also get gptsync packaged separately, instead of having an odd version bundled with Anaconda ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 install timings
... stripped down kickstart server install of about 389 packages: enablefilesystems 3:10s postselection24:27s installpackages 14:30s The install spends a long time displaying Checking dependencies in packages selected for installation with no movement of the progress bar. Interestingly a much larger install set on a laptop took only 1:34s in postselection. Are you sure that the optical drive on the server is OK? Those times for postselection (tens of minutes) smell like slow hardware [microcode] recovery for seek errors. Transfer the DVD to a USB2.0 flash memory device, boot the netinstall CD with extra parameter 'askmethod', choose local harddrive, and select the flash memory partition as the source of the Fedora 13 tree. Postselection should take less than one minute. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
On Fri, 2010-03-19 at 13:34 -0500, Jeffrey Ollie wrote: On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura spur...@students.uni-mainz.de wrote: Why testing? A maybe-broken update is better than a non-working programm isn't it? Because there are a significant number of people that will scream bloody murder if people push packages directly to stable without having the package spend at least a little time in testing, no matter what the reason. There have been enough problems with seemingly safe updates that go directly to stable that I have a hard time disagreeing with them. Besides, the principle is not in fact correct. Just for instance, an installable package which causes massive data corruption is not better than an uninstallable package... Not saying that's the case here, just pointing out that 'it's uninstallable' is not the worst possible flaw a package can have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 install timings
On 03/19/2010 01:57 PM, John Reiser wrote: ... stripped down kickstart server install of about 389 packages: enablefilesystems 3:10s postselection24:27s installpackages 14:30s The install spends a long time displaying Checking dependencies in packages selected for installation with no movement of the progress bar. Interestingly a much larger install set on a laptop took only 1:34s in postselection. Are you sure that the optical drive on the server is OK? Those times for postselection (tens of minutes) smell like slow hardware [microcode] recovery for seek errors. Transfer the DVD to a USB2.0 flash memory device, boot the netinstall CD with extra parameter 'askmethod', choose local harddrive, and select the flash memory partition as the source of the Fedora 13 tree. Postselection should take less than one minute. It's an http install to a local server, and there is no access during that stage (after is has all of the repodata files) until it starts fetching package headers. So, it seems like filing a bug is in order. Anaconda or yum? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, Mar 19, 2010 at 07:54:09PM +, Richard W.M. Jones wrote: Yes! Hopefully BIOS support won't be a problem because of gptsync. Can we also get gptsync packaged separately, instead of having an odd version bundled with Anaconda ... A first incomplete Feature page is available here: https://fedoraproject.org/wiki/Features/GUID_Partition_Table Regards Till pgpjbS1ETkSKd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Friday 19 March 2010, Toshio Kuratomi wrote: On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: On Friday 19 March 2010, Jon Ciesla wrote: ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fed ora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. I got that earlier today too, when the close bugs checkbox was ticked. I managed to submit the same update after unticking it. I think this is a transient error from packagedb -- if it's repeatable, it's something I can take a look at and hopefully fix quickly. Also -- I have just deployed a new version of packagedb that fixes one of the sources of transient failures. It's possible that it will fix this. Please let me know if you can get this repeatedly or if it seems to have gone away. I just managed to submit another update with close bugs checked, so maybe that wasn't it or it was fixed. Thanks in any case ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
Ville Skyttä wrote: On Friday 19 March 2010, Toshio Kuratomi wrote: On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: On Friday 19 March 2010, Jon Ciesla wrote: ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fed ora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. I got that earlier today too, when the close bugs checkbox was ticked. I managed to submit the same update after unticking it. I think this is a transient error from packagedb -- if it's repeatable, it's something I can take a look at and hopefully fix quickly. Also -- I have just deployed a new version of packagedb that fixes one of the sources of transient failures. It's possible that it will fix this. Please let me know if you can get this repeatedly or if it seems to have gone away. I just managed to submit another update with close bugs checked, so maybe that wasn't it or it was fixed. Thanks in any case ;) So did I. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for wipe complete HD installations
On Fri, Mar 19, 2010 at 09:39:05PM +0100, Till Maas wrote: On Fri, Mar 19, 2010 at 07:54:09PM +, Richard W.M. Jones wrote: Yes! Hopefully BIOS support won't be a problem because of gptsync. Can we also get gptsync packaged separately, instead of having an odd version bundled with Anaconda ... A first incomplete Feature page is available here: https://fedoraproject.org/wiki/Features/GUID_Partition_Table I added a section summarising the issues with gptsync AIUI: https://fedoraproject.org/wiki/Features/GUID_Partition_Table#gptsync Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Query re package versions in F-13
When I run yum list extras on my F-13 system, it lists (inter alia) the following: tzdata.noarch 2010e-1.fc13@updates-testing tzdata-java.noarch ... The version of tzdata currently in the F-13 repositories is 2010c-1, with nothing in updates-testing, but Bodhi shows that 2010e-1 has been pushed to testing. Has this update somehow been mislaid? Quentin Armitage -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 14:52, Juha Tuomala (juha.tuom...@iki.fi) wrote: [Connection] SocketDirectory=/tmp/akonadi-myuser/ into $HOME/.config/akonadi/akonadiserverrc How about setting that as default, away from $HOME that can be a NFS filesystem? I have had problems with it sometimes and that's probably not a rare case. That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 08:38, Rex Dieter (rdie...@math.unl.edu) wrote: Juha Tuomala wrote: https://bugs.kde.org/show_bug.cgi?id=179006#c5 in the current version of Akonadi server you can specify a custom socket path by entering [Connection] SocketDirectory=/tmp/akonadi-myuser/ into $HOME/.config/akonadi/akonadiserverrc How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. If KDE really does this, it is really broken. hostname is unsuitable for use cases like this, since on many Fedora/RH systems it is just localhost. And then very often it is highly dynamic, sometimes even changing with DHCP. If you want to identify a machine, use the D-Bus machine id. If you don't want to link against the libdbus libraries (which you probably should), then at least read /var/lib/dbus/machine-id and use that (possibly with a fallback to the hostname, in case the admin is a nut). The dbus machine id is the only suitable ID for usecases like this: it is static, bound to the installation, and widely available. In addition to this username is unsuitable for use cases like this too, since it opens the door to DoS attacks by other users since they can guess you socket path and create the socket and hence make it impossible for you to use it. If you want to do this properly, do something like this: ~/.kde/socket-dbusid → /tmp/ksocket-random/socket Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 10:54, Matthias Clasen (mcla...@redhat.com) wrote: Symlinks are duct-tape, why not just set it to /tmp with global rc file? Sure, but still need to encode username into the filename (or randomize/uniq it) somehow. Any reason this cannot be an abstract socket ? Of course, then you have to check peer creds and figure out a way to communicate the socket name, but at least you don't have to worry about the usual races and permission problem you have with unix sockets. Abstract sockets are not particularly useful for anything but system services that are only started once, and very early during bootup. Why? because they are not namespaced: every user can take every name he wants. If a system service that is restartable or started late at bootup needs a specific name then some evil user might already have taken it away, creating a DoS situation. As soon as a system is booted up to a level where non-system users can login abstract namespace sockets must use randomized names, to avoid these DoS issues. And a reference to those names would probably be have to be written to the file system, so that it can be found by other applications. And as soon as that happens, most advantages of sockets that don't live in the fs hierarchy are gone. Abstract sockets are a tool that is only really useful during early boot. For everything else I don't think it really has any advantages over fs sockets. However, they are harder to discover, which sucks. In summary: unless you hack very low-level Linux-specific software forget about abstract sockets. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-CLASS - New directory
Author: kevin Update of /cvs/pkgs/rpms/perl-CLASS In directory cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvse16698/rpms/perl-CLASS Log Message: Directory /cvs/pkgs/rpms/perl-CLASS added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CLASS/devel .cvsignore, NONE, 1.1 Makefile, NONE, 1.1 sources, NONE, 1.1
Author: kevin
Update of /cvs/pkgs/rpms/perl-CLASS/devel
In directory
cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvse16698/rpms/perl-CLASS/devel
Added Files:
.cvsignore Makefile sources
Log Message:
Setup of module perl-CLASS
--- NEW FILE .cvsignore ---
--- NEW FILE Makefile ---
# Makefile for source rpm: perl-CLASS
# $Id: Makefile,v 1.1 2010/03/19 20:08:02 kevin Exp $
NAME := perl-CLASS
SPECFILE = $(firstword $(wildcard *.spec))
define find-makefile-common
for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ;
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q
update ; fi ; echo $$d/Makefile.common ; break ; fi ; done
endef
MAKEFILE_COMMON := $(shell $(find-makefile-common))
ifeq ($(MAKEFILE_COMMON),)
# attept a checkout
define checkout-makefile-common
test -f CVS/Root { cvs -Q -d $$(cat CVS/Root) checkout common echo
common/Makefile.common ; } || { echo ERROR: I can't figure out how to
checkout the 'common' module. ; exit -1 ; } 2
endef
MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
endif
include $(MAKEFILE_COMMON)
--- NEW FILE sources ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-opts Makefile,NONE,1.1
Author: kevin
Update of /cvs/pkgs/rpms/perl-opts
In directory
cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvsW16923/rpms/perl-opts
Added Files:
Makefile
Log Message:
Setup of module perl-opts
--- NEW FILE Makefile ---
# Top level Makefile for module perl-opts
all : CVS/Root common-update
@cvs update
common-update : common
@cd common cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo ERROR: This does not look like a CVS checkout exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Audio-Beep/devel - New directory
Author: kevin Update of /cvs/pkgs/rpms/perl-Audio-Beep/devel In directory cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvsB17273/rpms/perl-Audio-Beep/devel Log Message: Directory /cvs/pkgs/rpms/perl-Audio-Beep/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Audio-Beep - New directory
Author: kevin Update of /cvs/pkgs/rpms/perl-Audio-Beep In directory cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvsB17273/rpms/perl-Audio-Beep Log Message: Directory /cvs/pkgs/rpms/perl-Audio-Beep added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Audio-Beep Makefile,NONE,1.1
Author: kevin
Update of /cvs/pkgs/rpms/perl-Audio-Beep
In directory
cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvsB17273/rpms/perl-Audio-Beep
Added Files:
Makefile
Log Message:
Setup of module perl-Audio-Beep
--- NEW FILE Makefile ---
# Top level Makefile for module perl-Audio-Beep
all : CVS/Root common-update
@cvs update
common-update : common
@cd common cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo ERROR: This does not look like a CVS checkout exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-opts/devel import.log, NONE, 1.1 perl-opts.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-opts/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv24039/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-opts.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-opts-0_022-1_fc12:HEAD:perl-opts-0.022-1.fc12.src.rpm:1269041953
--- NEW FILE perl-opts.spec ---
Name: perl-opts
Summary:Simple command line option parser
Version:0.022
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIKIHOSHI/opts-%{version}.tar.gz
URL:http://search.cpan.org/dist/opts
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(Getopt::Long) = 2.37
BuildRequires: perl(PadWalker) = 1.9
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
# note versioning...
Requires: perl(Getopt::Long) = 2.37
Requires: perl(PadWalker) = 1.9
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
%description
opts is a DSL for quickly and easily handling command line options.
%prep
%setup -q -n opts-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Mon Mar 08 2010 Chris Weyl cw...@alumni.drew.edu 0.022-1
- specfile by Fedora::App::MaintainerTools 0.004
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-opts/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 19 Mar 2010 20:08:23 - 1.1
+++ .cvsignore 19 Mar 2010 23:39:23 - 1.2
@@ -0,0 +1 @@
+opts-0.022.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-opts/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 19 Mar 2010 20:08:23 - 1.1
+++ sources 19 Mar 2010 23:39:24 - 1.2
@@ -0,0 +1 @@
+08293bb9013c18f91fa4307feadb0102 opts-0.022.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CLASS-1.00.tar.gz uploaded to lookaside cache by cweyl
A file has been added to the lookaside cache for perl-CLASS: 834b888b9c8a936b12de2c168798b618 CLASS-1.00.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CLASS/devel import.log, NONE, 1.1 perl-CLASS.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-CLASS/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv24411/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CLASS.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-CLASS-1_00-1_fc12:HEAD:perl-CLASS-1.00-1.fc12.src.rpm:1269041976
--- NEW FILE perl-CLASS.spec ---
Name: perl-CLASS
Summary:Alias for __PACKAGE__
Version:1.00
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/CLASS-%{version}.tar.gz
URL:http://search.cpan.org/dist/CLASS
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More) = 0.07
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
%description
This package provides CLASS and $CLASS; both synonyms for __PACKAGE__.
They're easier to type, and $CLASS has the additional benefit of working
in strings.
%prep
%setup -q -n CLASS-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sun Mar 14 2010 Chris Weyl cw...@alumni.drew.edu 1.00-1
- specfile by Fedora::App::MaintainerTools 0.006
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-CLASS/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 19 Mar 2010 20:08:01 - 1.1
+++ .cvsignore 19 Mar 2010 23:39:43 - 1.2
@@ -0,0 +1 @@
+CLASS-1.00.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-CLASS/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 19 Mar 2010 20:08:02 - 1.1
+++ sources 19 Mar 2010 23:39:44 - 1.2
@@ -0,0 +1 @@
+834b888b9c8a936b12de2c168798b618 CLASS-1.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-opts/F-13 import.log, NONE, 1.1 perl-opts.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-opts/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv24447/F-13
Modified Files:
.cvsignore sources
Added Files:
import.log perl-opts.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-opts-0_022-1_fc12:F-13:perl-opts-0.022-1.fc12.src.rpm:1269041977
--- NEW FILE perl-opts.spec ---
Name: perl-opts
Summary:Simple command line option parser
Version:0.022
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIKIHOSHI/opts-%{version}.tar.gz
URL:http://search.cpan.org/dist/opts
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(Getopt::Long) = 2.37
BuildRequires: perl(PadWalker) = 1.9
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
# note versioning...
Requires: perl(Getopt::Long) = 2.37
Requires: perl(PadWalker) = 1.9
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
%description
opts is a DSL for quickly and easily handling command line options.
%prep
%setup -q -n opts-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Mon Mar 08 2010 Chris Weyl cw...@alumni.drew.edu 0.022-1
- specfile by Fedora::App::MaintainerTools 0.004
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-opts/F-13/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 19 Mar 2010 20:08:23 - 1.1
+++ .cvsignore 19 Mar 2010 23:39:44 - 1.2
@@ -0,0 +1 @@
+opts-0.022.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-opts/F-13/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 19 Mar 2010 20:08:23 - 1.1
+++ sources 19 Mar 2010 23:39:45 - 1.2
@@ -0,0 +1 @@
+08293bb9013c18f91fa4307feadb0102 opts-0.022.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CLASS/F-13 import.log, NONE, 1.1 perl-CLASS.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-CLASS/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv24919/F-13
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CLASS.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-CLASS-1_00-1_fc12:F-13:perl-CLASS-1.00-1.fc12.src.rpm:1269042000
--- NEW FILE perl-CLASS.spec ---
Name: perl-CLASS
Summary:Alias for __PACKAGE__
Version:1.00
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/CLASS-%{version}.tar.gz
URL:http://search.cpan.org/dist/CLASS
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More) = 0.07
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
%description
This package provides CLASS and $CLASS; both synonyms for __PACKAGE__.
They're easier to type, and $CLASS has the additional benefit of working
in strings.
%prep
%setup -q -n CLASS-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sun Mar 14 2010 Chris Weyl cw...@alumni.drew.edu 1.00-1
- specfile by Fedora::App::MaintainerTools 0.006
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-CLASS/F-13/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 19 Mar 2010 20:08:01 - 1.1
+++ .cvsignore 19 Mar 2010 23:40:07 - 1.2
@@ -0,0 +1 @@
+CLASS-1.00.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-CLASS/F-13/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 19 Mar 2010 20:08:02 - 1.1
+++ sources 19 Mar 2010 23:40:07 - 1.2
@@ -0,0 +1 @@
+834b888b9c8a936b12de2c168798b618 CLASS-1.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-opts/F-12 import.log, NONE, 1.1 perl-opts.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-opts/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv24891/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-opts.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-opts-0_022-1_fc12:F-12:perl-opts-0.022-1.fc12.src.rpm:1269041999
--- NEW FILE perl-opts.spec ---
Name: perl-opts
Summary:Simple command line option parser
Version:0.022
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIKIHOSHI/opts-%{version}.tar.gz
URL:http://search.cpan.org/dist/opts
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(Getopt::Long) = 2.37
BuildRequires: perl(PadWalker) = 1.9
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
# note versioning...
Requires: perl(Getopt::Long) = 2.37
Requires: perl(PadWalker) = 1.9
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
%description
opts is a DSL for quickly and easily handling command line options.
%prep
%setup -q -n opts-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Mon Mar 08 2010 Chris Weyl cw...@alumni.drew.edu 0.022-1
- specfile by Fedora::App::MaintainerTools 0.004
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-opts/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 19 Mar 2010 20:08:23 - 1.1
+++ .cvsignore 19 Mar 2010 23:40:06 - 1.2
@@ -0,0 +1 @@
+opts-0.022.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-opts/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 19 Mar 2010 20:08:23 - 1.1
+++ sources 19 Mar 2010 23:40:06 - 1.2
@@ -0,0 +1 @@
+08293bb9013c18f91fa4307feadb0102 opts-0.022.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: Bug 480787 - autoconf parameter --with-... --without-...
Hi, Please review the patch for the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=480787 Patch: https://bugzilla.redhat.com/attachment.cgi?id=401381action=edit https://bugzilla.redhat.com/attachment.cgi?id=401381action=diff The configure script has been modified such that the --with-XXX and --without-XXX switches will work as --with-XXX=yes and --with-XXX=no, respectively. If the package is required and none of the switches are specified, it will default to yes. The code that detects LDAPSDK and OpenLDAP conflicts has been updated. The help messages have been cleaned up. Thanks! -- Endi S. Dewata -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
