Re: genkey Segmentation fault
On 10/10/10 12:25 PM, Philip Prindeville wrote: On 10/9/10 2:54 PM, fkoo...@tuxed.net wrote: On Sat, Oct 9, 2010 at 8:48 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: Any suggestions? https://bugzilla.redhat.com/buglist.cgi?quicksearch=genkey Regards, François So... despite being root-caused, there's been no further movement on it in 4 months? Well, as a workaround, I did rpm -q --scripts mod_ssl and figured out what the install script was doing, and ran it by hand. Quicker than waiting for genkey to be fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphan most of my packages
I took uniconvertor it is needed for ImageMagick. 10.10.2010 18:13, Andy Shevchenko wrote: Hello, I have no more time to support the following packages in the Fedora. jack-audio-connection-kit -- The Jack Audio Connection Kit klamav -- Clam Anti-Virus on the KDE Desktop man-pages-uk -- Ukrainian man pages from the Linux Documentation Project python-alsa -- Python binding for the ALSA library qstat -- Real-time Game Server Status for FPS game servers uniconvertor -- Universal vector graphics translator -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact with me you could use Jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphan most of my packages
On Mon, Oct 11, 2010 at 11:39 AM, Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: I took uniconvertor it is needed for ImageMagick. jfyi: new version of it requires the sk1libs package which is absent (still?) in Fedora. Additionally I have some patches for older version. I could send them to you if you want. uniconvertor -- Universal vector graphics translator Thanks. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[LICENSE CHANGE] gtk-murrine-engine changes license to dual-licensing LGPLv2.1 and LGPLv3
Hi all, as required by the licensing guidelines [1] I announce hereby a license change in gtk-murrine-engine in version 0.98.1 and newer to dual-licensing LGPLv2.1 and LGPLv3 from GPLv2+. Since the change is to more permissive licenses, AFAIK nothing in fedora uses gtk-murrine-engine directly and LGPLvX.Y are acceptable licenses in fedora, there shouldn't be any issues. With regards, Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning pychess
Hi list, I'm orphaning pychess, because I don't use it that often anymore and I don't have time to take care properly for all the bugs (and it needs some love...): 23 open bugs: https://bugzilla.redhat.com/buglist.cgi?query_format=advancedproduct=Fedoracomponent=pychessbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED There is already on co-maintainer, maybe he wants to pick this up (CC'ed in this mail.) Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Ubuntu 10.10's installer looks rather nice
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky. Some of the things it does which are IMHO better: - starts disk formatting / copying / installing in parallel with asking user questions - downloads updates in parallel too - uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time) - suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch) This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area. Thoughts? Can we switch to their installer? 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
forked-daapd to replace mt-daapd
mt-daapd in Fedora (and EPEL) is nothing than life of pain (crashes, sudden unexaplained stops, etc.) and its upstream is dead. There is now fork of it (http://blog.technologeek.org/category/hacks/ forked-daapd) which shows some life and hope it could be acutally maintained by somebody who at least pretends to know what he is doing (I have no way how to evaluate his abilities in better way not being a C programmer myself). Therefore I would suggest to rename and rebase mt-daapd in Fedora to forked-daapd. I have created forked-daapd branch in fedpkg mt-daapd repo with forked- daapd.spec and I have also collected all known to me patches against mt- daapd (branches fedora and ensureUTF8; the latter I will try to push upstream) to my repo git://gitorious.org/forked-daapd/forked-daapd.git Of course, I expect, that this will require new Package Review. Comments, objections? Does anybody else do the same? Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC This is a signature anti-virus. Please stop the spread of signature viruses! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: forked-daapd to replace mt-daapd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2010 08:12 AM, Matej Cepl wrote: mt-daapd in Fedora (and EPEL) is nothing than life of pain (crashes, sudden unexaplained stops, etc.) and its upstream is dead. There is now fork of it (http://blog.technologeek.org/category/hacks/ forked-daapd) which shows some life and hope it could be acutally maintained by somebody who at least pretends to know what he is doing (I have no way how to evaluate his abilities in better way not being a C programmer myself). Therefore I would suggest to rename and rebase mt-daapd in Fedora to forked-daapd. I have created forked-daapd branch in fedpkg mt-daapd repo with forked- daapd.spec and I have also collected all known to me patches against mt- daapd (branches fedora and ensureUTF8; the latter I will try to push upstream) to my repo git://gitorious.org/forked-daapd/forked-daapd.git Of course, I expect, that this will require new Package Review. Comments, objections? Does anybody else do the same? Being that it's a different upstream project now, you need to create a new package in Fedora. Once that's reviewed and included in the packageset, you should raise the question of default inclusion with FESCo. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyzAPgACgkQeiVVYja6o6NqQwCfUa1tExxC8tcdGlrbklD/2hkW KZ4AoIX5XGR0MPDsZ9/yvNWYZg8E3xEa =RwZY -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: forked-daapd to replace mt-daapd
Stephen Gallagher, Mon, 11 Oct 2010 08:20:08 -0400: Being that it's a different upstream project now, you need to create a new package in Fedora. Once that's reviewed and included in the packageset, you should raise the question of default inclusion with FESCo. Sure, no problem. Just I don't understand what I do need FESCO for? For obsoleting the old package? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC I didn't attend the funeral, but I sent a nice letter saying I approved of it. -- Mark Twain -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: forked-daapd to replace mt-daapd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2010 08:30 AM, Matej Cepl wrote: Stephen Gallagher, Mon, 11 Oct 2010 08:20:08 -0400: Being that it's a different upstream project now, you need to create a new package in Fedora. Once that's reviewed and included in the packageset, you should raise the question of default inclusion with FESCo. Sure, no problem. Just I don't understand what I do need FESCO for? For obsoleting the old package? Sorry, I think I was confusing daapd with another (system-critical) component. You probably need to contact the maintainer of the original mt-daapd and make sure they're on-board with switching to this new forked version, as well as trying to identify any applications that depend on mt-daapd and work with them to ensure that forked-daapd either won't break their packages or they can at least release updates simultaneously. If you are in fact the maintainer of mt-daapd, the first part should be easy. :) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyzBEoACgkQeiVVYja6o6Pq3QCgmUoXbevx+LPHRqZzqjaVDyZK LpQAoIYKeRwAtz8k5JqTmPmb6OB1Thve =TJyQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: forked-daapd to replace mt-daapd
Stephen Gallagher, Mon, 11 Oct 2010 08:34:18 -0400: Sorry, I think I was confusing daapd with another (system-critical) component. You probably need to contact the maintainer of the original mt-daapd and make sure they're on-board with switching to this new forked version, as well as trying to identify any applications that depend on mt-daapd and work with them to ensure that forked-daapd either won't break their packages or they can at least release updates simultaneously. If you are in fact the maintainer of mt-daapd, the first part should be easy. :) No I am not, but CC of the parent message was sent to mt-daapd-ow...@fp.o Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC My point was simply that such tax proposals [for Pigovian taxes compensating for the transaction costs] are the stuff that dreams are made of. In my youth it was said, that what was too silly to be said may be sung. In modern economics it may be put into mathematics. -- Ronald Coase Notes on the Problem of Social Cost -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 6:41 AM, Richard W.M. Jones rjo...@redhat.com wrote: I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky. Some of the things it does which are IMHO better: - starts disk formatting / copying / installing in parallel with asking user questions - downloads updates in parallel too - uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time) - suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch) This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area. Thoughts? Can we switch to their installer? I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote: I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project. Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag repetable segfault (Re: e4defrag support?)
Michał Piotrowski wrote: e4defrag[23597]: segfault at 20 ip 0040232c sp 7fff5bb0cd20 error 4 in e4defrag[40+5000] This is caused by the race between rm and e4defrag repeatable with attached canto_della_terra2.sh /mnt/tmp/test/ /mnt/tmp/reply.sh 50 Regards, Michal File a bug please? Also, what is reply.sh? Thanks, -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
2010/10/11 Josh Boyer jwbo...@gmail.com: I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project. Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/11/2010 10:21 AM, Richard W.M. Jones wrote: On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote: I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project. Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter. Do you seriously believe that we don't look at other OS installers, including Ubuntu's, for ideas? That's quite the naïvette you've cultivated there. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 15:21 +0100, Richard W.M. Jones wrote: On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote: I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project. Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter. We do. Porting Fedora to the Ubuntu installer would be rather more work than just adding those features to anaconda. You might get a more favorable reaction by phrasing your RFEs positively (this is a neat thing that these guys are doing, we should look into it) rather than negatively (we should throw away what we're currently using and switch). - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 03:21:40PM +0100, Richard W.M. Jones wrote: Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter. Maybe the virt-manager developers could spend some more time looking at vmware? This isn't a good way to have a worthwhile discussion. A description of the factors that you feel make Ubiquity better than Anaconda would be a much better way to handle this. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag repetable segfault (Re: e4defrag support?)
2010/10/11 Eric Sandeen sand...@redhat.com: Michał Piotrowski wrote: e4defrag[23597]: segfault at 20 ip 0040232c sp 7fff5bb0cd20 error 4 in e4defrag[40+5000] This is caused by the race between rm and e4defrag repeatable with attached canto_della_terra2.sh /mnt/tmp/test/ /mnt/tmp/reply.sh 50 Regards, Michal File a bug please? https://bugzilla.redhat.com/show_bug.cgi?id=641926 Also, what is reply.sh? It's file where cdt scripts stores it's actions - you can try to reply them (although it is difficult because of the racing nature of cdt script) Thanks, -Eric Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed. Does the Ubuntu installer support installing to iscsi? Multipath? CCISS? Fully automated installation? Install over VNC? Installation from NFS, ISO on NFS, ISO on HD? Live images on USB keys? Driver disks? Do you have any idea how much crap anaconda really does? - Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 10:48:44AM -0400, Chris Lumens wrote: Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed. Does the Ubuntu installer support installing to iscsi? Multipath? CCISS? Fully automated installation? Install over VNC? Installation from NFS, ISO on NFS, ISO on HD? Live images on USB keys? Driver disks? Do you have any idea how much crap anaconda really does? SNIP A big epic +1 -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 633752] perl-Test-NeedsDisplay-1.07 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633752 Petr Sabata psab...@redhat.com changed: What|Removed |Added Depends on||641940 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Ubuntu 10.10's installer looks rather nice
- downloads updates in parallel too Package updates? - uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time) We can do this, it's just never really been brought up. I'd like to rework a lot of the l10n stuff anyway, there just never seems to be time. - suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch) If DNS knows a hostname, we will suggest that. Of course it's not foolproof. mgracik is working on the username suggestion thing already. Thoughts? Can we switch to their installer? No. - Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote: I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky. Some of the things it does which are IMHO better: - starts disk formatting / copying / installing in parallel with asking user questions - downloads updates in parallel too - uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time) - suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch) This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area. Thoughts? Can we switch to their installer? Rich. Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna... The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Padre-0.72.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Padre: d187654500fd819a70f8e82052d93db4 Padre-0.72.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Padre] Update to 0.72 Stable release, remove unnecessary BR and R.
commit cee373141e324aa82d7ef3a4f8339c5080b1ecd7
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Oct 11 17:42:27 2010 +0200
Update to 0.72
Stable release, remove unnecessary BR and R.
.gitignore |1 +
perl-Padre.spec | 27 ++-
sources |2 +-
3 files changed, 16 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 31faa84..9022786 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Padre-0.64.tar.gz
+/Padre-0.72.tar.gz
diff --git a/perl-Padre.spec b/perl-Padre.spec
index b254855..c677c4b 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -1,16 +1,14 @@
Name: perl-Padre
-Version:0.64
+Version:0.72
Release:1%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Padre/
Source0:
http://search.cpan.org/CPAN/authors/id/P/PL/PLAVEN/Padre-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: gettext
BuildRequires: perl(Alien::wxWidgets) = 0.46
-BuildRequires: perl(App::Ack) = 1.86
BuildRequires: perl(Capture::Tiny) = 0.06
BuildRequires: perl(Class::Adapter) = 1.05
BuildRequires: perl(Class::Unload) = 0.03
@@ -35,7 +33,6 @@ BuildRequires: perl(File::Copy::Recursive) = 0.37
BuildRequires: perl(File::Find::Rule) = 0.30
BuildRequires: perl(File::Glob)
BuildRequires: perl(File::HomeDir) = 0.84
-BuildRequires: perl(File::Next) = 1.06
BuildRequires: perl(File::Path) = 2.07
BuildRequires: perl(File::Remove) = 1.42
BuildRequires: perl(File::ShareDir) = 1.00
@@ -59,28 +56,29 @@ BuildRequires: perl(IPC::Open3)
BuildRequires: perl(List::MoreUtils) = 0.22
BuildRequires: perl(List::Util) = 1.18
BuildRequires: perl(Locale::Msgfmt) = 0.14
+BuildRequires: perl(LWP) = 5.815
BuildRequires: perl(Module::Build) = 0.3603
BuildRequires: perl(Module::CoreList)
+BuildRequires: perl(Module::Manifest) = 0.07
BuildRequires: perl(Module::Refresh) = 0.13
BuildRequires: perl(Module::Starter) = 1.50
BuildRequires: perl(ORLite) = 1.41
-BuildRequires: perl(POSIX)
-BuildRequires: perl(PPI) = 1.205
-BuildRequires: perl(PPIx::EditorTools) = 0.09
-BuildRequires: perl(PPIx::Regexp) = 0.005
BuildRequires: perl(Params::Util) = 0.33
BuildRequires: perl(Parse::ErrorString::Perl) = 0.11
BuildRequires: perl(Parse::ExuberantCTags) = 1.00
-BuildRequires: perl(pip) = 0.13
BuildRequires: perl(Pod::Abstract) = 0.16
BuildRequires: perl(Pod::Functions)
BuildRequires: perl(Pod::POM) = 0.17
BuildRequires: perl(Pod::Perldoc) = 3.15
BuildRequires: perl(Pod::Simple) = 3.07
BuildRequires: perl(Pod::Simple::XHTML) = 3.04
-BuildRequires: perl(Readonly::XS) = 1.05
+BuildRequires: perl(POSIX)
+BuildRequires: perl(PPI) = 1.205
+BuildRequires: perl(PPIx::EditorTools) = 0.09
+BuildRequires: perl(PPIx::Regexp) = 0.005
BuildRequires: perl(Probe::Perl) = 0.01
BuildRequires: perl(Storable) = 2.15
+BuildRequires: perl(Template::Tiny) = 0.11
BuildRequires: perl(Test::Exception) = 0.27
BuildRequires: perl(Test::MockObject) = 1.09
BuildRequires: perl(Test::More) = 0.88
@@ -98,7 +96,7 @@ BuildRequires: perl(YAML::Tiny) = 1.32
BuildRequires: perl(threads) = 1.71
BuildRequires: perl(threads::shared) = 1.26
BuildRequires: perl(version) = 0.80
-Requires: perl(App::Ack) = 1.86
+Requires: perl(App::cpanminus) = 0.9923
Requires: perl(Class::Adapter) = 1.05
Requires: perl(Class::Unload) = 0.03
Requires: perl(Class::XSAccessor) = 1.05
@@ -120,7 +118,6 @@ Requires: perl(File::Copy::Recursive) = 0.37
Requires: perl(File::Find::Rule) = 0.30
Requires: perl(File::Glob)
Requires: perl(File::HomeDir) = 0.84
-Requires: perl(File::Next) = 1.06
Requires: perl(File::Path) = 2.07
Requires: perl(File::Remove) = 1.42
Requires: perl(File::ShareDir) = 1.00
@@ -141,6 +138,8 @@ Requires: perl(IO::Socket) = 1.30
Requires: perl(IO::String) = 1.08
Requires: perl(IPC::Open2)
Requires: perl(IPC::Open3)
+Requires: perl(IPC::Run) = 0.83
+Requires: perl(JSON::XS) = 2.29
Requires: perl(List::MoreUtils) = 0.22
Requires: perl(List::Util) = 1.18
Requires: perl(Module::Build) = 0.3603
@@ -155,7 +154,6 @@ Requires: perl(PPIx::Regexp) = 0.005
Requires: perl(Params::Util) = 0.33
Requires: perl(Parse::ErrorString::Perl) = 0.11
Requires: perl(Parse::ExuberantCTags) = 1.00
-Requires: perl(pip) = 0.13
Requires: perl(Pod::Abstract) = 0.16
Requires: perl(Pod::Functions)
Requires: perl(Pod::Perldoc) = 3.15
@@ -233,6 +231,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Oct 11 2010 Marcela Mašláňpvá mmasl...@redhat.com 0.72-1
+- update and remove uncessary BR and R
+
* Tue Jun 22
Re: Ubuntu 10.10's installer looks rather nice
2010/10/11 Richard W.M. Jones rjo...@redhat.com: I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky. Some of the things it does which are IMHO better: - starts disk formatting / copying / installing in parallel with asking user questions - downloads updates in parallel too - uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time) - suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch) This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area. Thoughts? Which of these functions can not be implemented in anaconda? Can we switch to their installer? Does it support text based minimal install? Rich. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 05:53:20PM +0200, Michał Piotrowski wrote: Does it support text based minimal install? debian-installer? Yes. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote: Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna... The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed. That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for Enterprise users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/11/2010 03:41 AM, Richard W.M. Jones wrote:
Some of the things [Ubuntu 10.10 installer] does which are IMHO better:
- starts disk formatting / copying / installing in parallel
with asking user questions
- downloads updates in parallel too
What was the wall-clock duration from Go! to done?
Should be about 140 seconds for a 32X CD-ROM: (700MB / 5MB/s).
{Fetch_from_media_or_download, and uncompress_package_to_pieces_in_RAMfs}
parallelizes almost perfectly with package install, even with only one CPU.
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 633737] perl-Padre-0.70 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633737 Bug 633737 depends on bug 636518, which changed state. Bug 636518 Summary: JSON-XS-2.3 bump https://bugzilla.redhat.com/show_bug.cgi?id=636518 What|Old Value |New Value Resolution||RAWHIDE Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 636518] JSON-XS-2.3 bump
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=636518 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2010-10-11 12:17:01 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 633737] perl-Padre-0.70 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=633737 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE Last Closed||2010-10-11 12:14:49 --- Comment #5 from Marcela Mašláňová mmasl...@redhat.com 2010-10-11 12:14:49 EDT --- Updated to 0.72. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Padre] Fixed releases of BR and R mentioned by ppisar in 633737.
commit 8d8fba8c83d4a1095d99bb40e472ea92915c693a
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Oct 11 18:16:03 2010 +0200
Fixed releases of BR and R mentioned by ppisar in 633737.
perl-Padre.spec | 30 +-
1 files changed, 17 insertions(+), 13 deletions(-)
---
diff --git a/perl-Padre.spec b/perl-Padre.spec
index c677c4b..1aad226 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -1,6 +1,6 @@
Name: perl-Padre
Version:0.72
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
@@ -22,7 +22,7 @@ BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Debug::Client) = 0.11
BuildRequires: perl(Devel::Dumpvar) = 0.04
BuildRequires: perl(Devel::Refactor) = 0.05
-BuildRequires: perl(Digest::MD5)
+BuildRequires: perl(Digest::MD5) = 2.38
BuildRequires: perl(Encode) = 2.26
# perl(ExtUtils::Embed) because Padre build system supports win32.
BuildRequires: perl(ExtUtils::Embed)
@@ -32,7 +32,7 @@ BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Copy::Recursive) = 0.37
BuildRequires: perl(File::Find::Rule) = 0.30
BuildRequires: perl(File::Glob)
-BuildRequires: perl(File::HomeDir) = 0.84
+BuildRequires: perl(File::HomeDir) = 0.91
BuildRequires: perl(File::Path) = 2.07
BuildRequires: perl(File::Remove) = 1.42
BuildRequires: perl(File::ShareDir) = 1.00
@@ -40,7 +40,7 @@ BuildRequires: perl(File::ShareDir) = 1.00
BuildRequires: perl(File::Spec) = 3.28
# Real version perl(File::Spec::Functions) = 3.2701 rounded
BuildRequires: perl(File::Spec::Functions) = 3.28
-BuildRequires: perl(File::Temp)
+BuildRequires: perl(File::Temp) = 0.20
BuildRequires: perl(File::Which) = 1.08
BuildRequires: perl(File::pushd) = 1.00
BuildRequires: perl(FindBin)
@@ -73,7 +73,7 @@ BuildRequires: perl(Pod::Perldoc) = 3.15
BuildRequires: perl(Pod::Simple) = 3.07
BuildRequires: perl(Pod::Simple::XHTML) = 3.04
BuildRequires: perl(POSIX)
-BuildRequires: perl(PPI) = 1.205
+BuildRequires: perl(PPI) = 1.213
BuildRequires: perl(PPIx::EditorTools) = 0.09
BuildRequires: perl(PPIx::Regexp) = 0.005
BuildRequires: perl(Probe::Perl) = 0.01
@@ -88,13 +88,13 @@ BuildRequires: perl(Template::Tiny) = 0.11
BuildRequires: perl(Text::Balanced) = 2.01
BuildRequires: perl(Text::Diff) = 0.35
BuildRequires: perl(Text::FindIndent) = 0.06
-BuildRequires: perl(Thread::Queue) = 2.11
+BuildRequires: perl(Time::HiRes) = 1.9718
BuildRequires: perl(URI)
BuildRequires: perl(Wx) = 0.91
BuildRequires: perl(Wx::Perl::ProcessStream) = 0.25
BuildRequires: perl(YAML::Tiny) = 1.32
BuildRequires: perl(threads) = 1.71
-BuildRequires: perl(threads::shared) = 1.26
+BuildRequires: perl(threads::shared) = 1.33
BuildRequires: perl(version) = 0.80
Requires: perl(App::cpanminus) = 0.9923
Requires: perl(Class::Adapter) = 1.05
@@ -109,7 +109,7 @@ Requires: perl(Data::Dumper)
Requires: perl(Debug::Client) = 0.11
Requires: perl(Devel::Dumpvar) = 0.04
Requires: perl(Devel::Refactor) = 0.05
-Requires: perl(Digest::MD5)
+Requires: perl(Digest::MD5) = 2.38
Requires: perl(Encode) = 2.26
Requires: perl(ExtUtils::MakeMaker) = 6.56
Requires: perl(ExtUtils::Manifest) = 1.56
@@ -117,7 +117,7 @@ Requires: perl(File::Basename)
Requires: perl(File::Copy::Recursive) = 0.37
Requires: perl(File::Find::Rule) = 0.30
Requires: perl(File::Glob)
-Requires: perl(File::HomeDir) = 0.84
+Requires: perl(File::HomeDir) = 0.91
Requires: perl(File::Path) = 2.07
Requires: perl(File::Remove) = 1.42
Requires: perl(File::ShareDir) = 1.00
@@ -125,7 +125,7 @@ Requires: perl(File::ShareDir) = 1.00
Requires: perl(File::Spec) = 3.28
# Real version perl(File::Spec::Functions) = 3.2701 rounded
Requires: perl(File::Spec::Functions) = 3.28
-Requires: perl(File::Temp)
+Requires: perl(File::Temp) = 0.20
Requires: perl(File::Which) = 1.08
Requires: perl(File::pushd) = 1.00
Requires: perl(FindBin)
@@ -144,11 +144,12 @@ Requires: perl(List::MoreUtils) = 0.22
Requires: perl(List::Util) = 1.18
Requires: perl(Module::Build) = 0.3603
Requires: perl(Module::CoreList)
+Requires: perl(Module::Manifest) = 0.07
Requires: perl(Module::Refresh) = 0.13
Requires: perl(Module::Starter) = 1.50
Requires: perl(ORLite) = 1.41
Requires: perl(POSIX)
-Requires: perl(PPI) = 1.205
+Requires: perl(PPI) = 1.213
Requires: perl(PPIx::EditorTools) = 0.09
Requires: perl(PPIx::Regexp) = 0.005
Requires: perl(Params::Util) = 0.33
@@ -167,13 +168,13 @@ Requires: perl(Template::Tiny) = 0.11
Requires: perl(Text::Balanced) = 2.01
Requires: perl(Text::Diff) = 0.35
Requires:
RFC: Upgrade Banshee to 1.8.0 in F13
I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
I think anaconda is better than ubuntu installer.
Ubuntu installer does not support LVM and RAID. I need these features.
Anaconda does not easily support upgrading from internet. It is quite
regretful.
On Tue, Oct 12, 2010 at 12:14 AM, John Reiser jrei...@bitwagon.com wrote:
On 10/11/2010 03:41 AM, Richard W.M. Jones wrote:
Some of the things [Ubuntu 10.10 installer] does which are IMHO better:
- starts disk formatting / copying / installing in parallel
with asking user questions
- downloads updates in parallel too
What was the wall-clock duration from Go! to done?
Should be about 140 seconds for a 32X CD-ROM: (700MB / 5MB/s).
{Fetch_from_media_or_download, and uncompress_package_to_pieces_in_RAMfs}
parallelizes almost perfectly with package install, even with only one CPU.
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Fedora Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Well, seeing as I am one of the maintainers, I don't have a problem with that. Does anyone know if it is disabled for a reason? On 10/11/2010 12:38 PM, Andy Shevchenko wrote: Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
I don't actually see that as a build option in either banshee or banshee-community-extensions. Am I missing something? Nathaniel On 10/11/2010 12:38 PM, Andy Shevchenko wrote: Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 10:48 -0400, Chris Lumens wrote: Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed. Does the Ubuntu installer support installing to iscsi? Multipath? CCISS? Fully automated installation? Install over VNC? Installation from NFS, ISO on NFS, ISO on HD? Live images on USB keys? Driver disks? Do you have any idea how much crap anaconda really does? That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
There is the file in the source tree called 'Banshee.Mpris.addin.xml'. It contains plugin info (? sorry, I'm not familiar with c# projects at all), where defaultEnabled=false And commit which brought that support tells the same by default it's disabled On Mon, Oct 11, 2010 at 8:00 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I don't actually see that as a build option in either banshee or banshee-community-extensions. Am I missing something? Nathaniel On 10/11/2010 12:38 PM, Andy Shevchenko wrote: Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Matthias Clasen (mcla...@redhat.com) said: That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users. Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Chris Lumens (clum...@redhat.com) said: - downloads updates in parallel too Package updates? 1) Given that it's using yum, downloading multiple things in parallel would need to be fixed there. 2) If it means downloading packages in the background while it does other tasks, given that package selection is the final task in the current workflow, it would require reordering the workflow to be beneficial. (Which becomes a memory usage tradeoff.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
On Mon, 11 Oct 2010 09:07:17 +1000 Jeff Fearn jfe...@redhat.com wrote: On Fri, 2010-10-08 at 13:56 -0600, Kevin Fenzi wrote: On Fri, 08 Oct 2010 18:03:04 +0400 Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: In most cases I try sync all branches if there no real reasons to make differences. ...snip... I would hope a real reason would be that the update is not a security or bugfix only update, right? IMHO it depends on what kind of software it is. I push releases of applications to all current Fedora releases. The users want the new features, it's what they have been bugging me for. If I was working on glibc or X I might not do that, but applications should be pushed back unless there is some system level constraint preventing it. So I too would like a commit to all branches or sync all branches to this one command. If it doesn't change the user experience, and fixes bugs or security issues, then great. ;) If it's a major update which does change the user experience, breaks ABI/API, or adds a bunch of new functionality, then please don't. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 13:16 -0400, Bill Nottingham wrote: Matthias Clasen (mcla...@redhat.com) said: That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users. Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.) The permutations are exhaustive. https://www.redhat.com/archives/anaconda-devel-list/2010-May/msg00305.html Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 01:07:26PM -0400, Matthias Clasen wrote: That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users. I do not see why we should remove functionality (and almost everything is there for a good reason) to polish the user experience. I do not even see that the latter is needed (the things mentioned in the initial mail we really minor things and/or probably quite easy to add), but that's maybe my fault as a hard-core UNIX guy... I recently had to install a SLES system for some experimental reason and ended up with a screwed-up system (read: MBR), probably because the user experience was so polished that it didn't want to ask me the things it *should* have asked :(. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Ah, if I understand correctly you don't need to do anything. It's just default which is off, and could be on by user demand. But, it would be better to have the default is on. On Mon, Oct 11, 2010 at 8:18 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: Christian, do you have any objections to enabling this? Nathaniel On 10/11/2010 01:16 PM, Andy Shevchenko wrote: There is the file in the source tree called 'Banshee.Mpris.addin.xml'. It contains plugin info (? sorry, I'm not familiar with c# projects at all), where defaultEnabled=false And commit which brought that support tells the same by default it's disabled On Mon, Oct 11, 2010 at 8:00 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I don't actually see that as a build option in either banshee or banshee-community-extensions. Am I missing something? Nathaniel On 10/11/2010 12:38 PM, Andy Shevchenko wrote: Agree if the maintainer enables the MPRISv2 support there. On Mon, Oct 11, 2010 at 7:20 PM, Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 11:41:13 +0100, Richard W.M. Jones rjo...@redhat.com wrote: Some of the things it does which are IMHO better: - starts disk formatting / copying / installing in parallel with asking user questions I think that is a misfeature. I don't want anything irreversible to be done until I say go. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
On Mon, 11 Oct 2010 12:20:54 -0400 Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Well, lets see: F13 currently has version 1.6.1 in it. Looks like they follow an 'odd is unstable/devel, even is release/stable' method. So, all the 1.7.x releases were development ones. I see a lot of bugs fixed, but also a bunch of new features: http://banshee.fm/download/archives/1.8.0/ I see 9 open fedora bugs. Has the UI changed since 1.6.1? I would suspect so. Would the libgpod update require rebuilding or changing anything else? How many other packages depend on that? So, this seems to me to be something that would need more rationale/a stable updates exception. All just IMHO. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Kevin Fenzi wrote: Would the libgpod update require rebuilding or changing anything else? How many other packages depend on that? The libgpod update should be safe. Though if it was up to me I'd wait for libgpod to reach 0.8.0. Upstream is treating 0.7.95 like a release candidate. I don't know how long it might take though. The big change between 0.7.93 and 0.7.95 is that the mono bindings were added, which is what Banshee 1.8 needs. I don't have an opinion on whether Banshee should or shouldn't be updated in a stable release. I don't use it. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ If barbie is so popular, why do you have to buy her friends? -- Jack Handy pgpk6TSoN5Fe0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 12:09 -0400, Jon Masters wrote: On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote: Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna... The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed. That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for Enterprise users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :) Amen to that. Given the absurdly cheap price of HD these days, I usually opt for LVM over software RAID1 / RAID5 on each and every workstation machine I install. Achieving the same using the Ubuntu installer would have required a lot of manual mdadm and lvm pv/vg/lv** commands. (Let alone their basic disk partitioning tool) ... In their race for Joe-six-pack and Apple like polish, Ubuntu gave up on many Linux core capabilities. Hopefully Fedora will -not- follow suite. - Gilboa - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams cmad...@hiwaay.net wrote: I think that is a misfeature. I don't want anything irreversible to be done until I say go. You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions. I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install. I tend to do install all of the games, so my installs may take longer than average. I also always do custom disk layouts, so I might see things a bit different from people that don't do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 13:18 -0400, Bill Nottingham wrote: Chris Lumens (clum...@redhat.com) said: - downloads updates in parallel too Package updates? 1) Given that it's using yum, downloading multiple things in parallel would need to be fixed there. We have an open rfe for related things - we're hoping to combine two rfe's into one: 1. have the pkg/metadata downloads run in a different process in a different context - for selinux 2. have each repo have its own downloader process which can handle however many pkgs/metadata at a time that downloader process can cope with. If someone wants to work on that come by #yum -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
On 10/11/2010 01:50 PM, Todd Zullinger wrote: Kevin Fenzi wrote: Would the libgpod update require rebuilding or changing anything else? How many other packages depend on that? The libgpod update should be safe. Though if it was up to me I'd wait for libgpod to reach 0.8.0. Upstream is treating 0.7.95 like a release candidate. I don't know how long it might take though. The big change between 0.7.93 and 0.7.95 is that the mono bindings were added, which is what Banshee 1.8 needs. I don't have an opinion on whether Banshee should or shouldn't be updated in a stable release. I don't use it. As someone who works closely with upstream, I can attest that 0.7.95 has no API/ABI changes and can be seamlessly upgraded without rebuilds. 0.8 will probably be released (and packaged by me) before any of this hits F13. I only mentioned 0.7.95 since banshee requires this version or later. One should keep in mind that the 0.7.9x series is the development series leading up to 0.8.0. Since 0.7.93 is already in F13, 0.8.0 is a natural upgrade path. There is only one change in 0.7.95 that may cause problems with existing apps: stop_sync() must be called an equal number of times in order to make the Syncing... screen on iphones/ipads/ipod touches disappear. Previously the screen was removed after the first call to stop_sync() (this was a bug in libgpod). Since stop_sync() should be called once per start_sync() invocation, this should not be a problem and since it is a known issue, we know how to test for it. Applications depending on the previous behaviour were depending on a bug. Worst case is an entirely cosmetic bug. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
On 10/11/2010 01:37 PM, Kevin Fenzi wrote: On Mon, 11 Oct 2010 12:20:54 -0400 Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Well, lets see: F13 currently has version 1.6.1 in it. Looks like they follow an 'odd is unstable/devel, even is release/stable' method. So, all the 1.7.x releases were development ones. Correct. I see a lot of bugs fixed, but also a bunch of new features: http://banshee.fm/download/archives/1.8.0/ I see 9 open fedora bugs. Yes, and I think 1.8 should solve roughly half of them (I'm unable to reproduce most of them in 1.8). Given our limited resources, I have no current plans to spend time on fixing bugs in the 1.6.x series (others are free of course to work on this). Has the UI changed since 1.6.1? I would suspect so. UI has not really seen many changes. Changes would be things like: * Amazon MP3 Store Service * Miro podcast guide * iPhone support These changes should not impact a user in any significant way (they just show up as additional sources on the left side). One one potentially confusing change is that the preferences dialog was re-arraigned. Since all preferences are transparently migrated and the majority of users only set preferences once, this impact should be minimal. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (544321) remove-ds.pl should not throw fatal error is selinux port label is not found
https://bugzilla.redhat.com/show_bug.cgi?id=544321 https://bugzilla.redhat.com/attachment.cgi?id=452770action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Hi, On 10/11/2010 07:37 PM, Kevin Fenzi wrote: On Mon, 11 Oct 2010 12:20:54 -0400 Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Well, lets see: F13 currently has version 1.6.1 in it. Looks like they follow an 'odd is unstable/devel, even is release/stable' method. So, all the 1.7.x releases were development ones. Yes, that's correct. I see a lot of bugs fixed, but also a bunch of new features: http://banshee.fm/download/archives/1.8.0/ I see 9 open fedora bugs. Has the UI changed since 1.6.1? I would suspect so. Not very much, only very slightly. Would the libgpod update require rebuilding or changing anything else? How many other packages depend on that? No, the SONAME and so the API of libgpod hasn't changed. So, this seems to me to be something that would need more rationale/a stable updates exception. I agree that there may be subtle changes (GUI, behavior, new bugs, ...). However, as one of the maintainers of the banshee package in Fedora I would certainly like to update to 1.8.0 as well. I suggest the following: - importing the new pre-requisites into F13 is uncritical even right now - confirm with libgpod maintainers whether an update to 0.95 is acceptable, if yes, it can be done in the meantime as well - give banshee some time in F14 and get some feedback from users first (probably even wait until F14 is out - otherwise too less people will use it regularly) - try to fix any regressions (e.g. it looks like that for me at least the iPod (non-touch) support is broken) - if there is no critical feedback or the issues could be solved: do the update in F13 Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
'milkymist' group in comps?
1) When you added this to F14/F15/EL6, you added a typo; this broke the F-14 branched compose and the EPEL updates push. *Please* verify your changes before pushing. 2) Aside from that... how does this merit a separate group? - We already have the electronic lab group - If we add a group each for developing for any embedded/custom board, we're going to run into group explosion really quickly Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 357641] EL branches perl-Tk
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=357641 --- Comment #8 from Kevin Fenzi ke...@tummy.com 2010-10-11 15:41:54 EDT --- Git done (by process-git-requests). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 12:51 -0500, Bruno Wolff III wrote: On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams cmad...@hiwaay.net wrote: I think that is a misfeature. I don't want anything irreversible to be done until I say go. You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions. I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install. I tend to do install all of the games, so my installs may take longer than average. I also always do custom disk layouts, so I might see things a bit different from people that don't do that. In fairness to Rich, I think it's easy to get carried away with how technicall better we are, but we shouldn't totally devalue the impact of the shiny gloss on some users, reviews, and on general perception. I used to be technical editor for a Linux magazine and I've read more than my fair share of reviews of distributions over the years (and written some too, it has to be admitted). Here's how it seems to go all too often in general: 10% background, 30-40% installation, 20% what got installed, then everything else. It's because reviewers are busy, and don't have time to know a community - so first impressions count. And Ubuntu is known to be cool, so they get extra points in any case. Sadly enough, this means that a shiny Ubuntu installer is to the whole distribution what GNOME shell is to the GNOME project. It doesn't matter if you've got a lot of bells and whistles underneath, or what you can do, if you don't look pretty while you do it. It's just the reality. I would venture that one of the reasons Rich sent his mail originally is that he's aware of this mentality and pointing out its effects. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Tasks
John Poelstra poelstra at redhat.com writes: Mon 11-Oct Mon 11-Oct Submit Installer Builds for Final TC Compose Does this mean that the (real) TC1 ISOs will show up tonight (instead of October 12)? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Tasks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 1:57 PM, Andre Robatino wrote: John Poelstra poelstra at redhat.com writes: Mon 11-Oct Mon 11-Oct Submit Installer Builds for Final TC Compose Does this mean that the (real) TC1 ISOs will show up tonight (instead of October 12)? No, it means that the anaconda package (and other related packages) should be built today at the latest in order to make it onto the test compose tomorrow. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyzfSAACgkQ4v2HLvE71NWgMACgrPJbK8wnhx8P4UMJKq1iuaLg Op0An2hFdfwWg6HrMc3f+sfd1Qd+G7c1 =4fWN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Monday 11 October 2010 12:41:13 Richard W.M. Jones wrote: This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area. Thoughts? Can we switch to their installer? Rich. It may be nice usability-wise but it lacks support for LVM2, LUKS disk encryption and practically everything more advanced. It can't be automated using some equivalent to kickstart and it fails at all the stuff Anaconda subsumes unter advanced storage devices. You can't even do the install from some remote place without setting anything up by hand. Ubuntu users requiring more than these very basic features have to go for the Debian text mode installer Ubuntu ships on their alternate media. Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users. So I don't think it's a good idea to switch to this, even if it was trivially possible to use with Fedora. But there's nothing preventing us to take the ubiquity features we enjoy most and enable Anaconda to do something similar. Lars. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/11/2010 06:09 PM, Jon Masters wrote: On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote: Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna... The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed. That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for Enterprise users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :) imho, the never drop any feature since raid, lvm, iscsi are important (what's more i use them:-), BUT most user don't ie. 80% of the users never use them. it can be an advanced installer option for us, and a basic for average user. the other point of richards is what the whole fedora community and redhat should have to understand: most users like ubuntu rather then fedora/redhat. why? because: - it's looks better. every component looks better, installer, default gnome themes etc. we can make a long discussion about which is better but our opinion simple do not count. better is what most user like. period. - it's easier to use. for average user it's the most important thing. we can always have an advance and basic settings. wouldn't be useful to ask users which they like and try to make fedora/redhat's component better? just my 2c. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-10-12)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 #topic #467 Make Feature Freeze happen sooner. https://fedorahosted.org/fesco/ticket/467 = New business = #topic #473 new meeting time (redux) https://fedorahosted.org/fesco/ticket/473 #topic #302 libssh2 - non-responsive maintainer https://fedorahosted.org/fesco/ticket/302 #topic #472 About Mozilla's decision to not allow using the system's libvpx https://fedorahosted.org/fesco/ticket/472 #topic #474 Package Criteria 'upgradepath' not clear https://fedorahosted.org/fesco/ticket/474 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
* Matthew Garrett [11/10/2010 19:57] : debian-installer? Yes. Shipping 2 different installers is a recipe for disaster from a user and QA perspective.Choose one between Ubiquity, Debian-installer and Anaconda. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Shipping 2 different installers is a recipe for disaster from a user and QA perspective.Choose one between Ubiquity, Debian-installer and Anaconda. We only ship one installer, and that is anaconda. I suppose you could argue over whether livecd is its own thing or not, but that's a nitpicky detail. - Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101011 changes
Compose started at Mon Oct 11 20:23:17 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdconduit.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotd.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdcm.so.2()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) Broken deps for i386 -- almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdcm.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotd.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdconduit.so.2 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 Updated Packages: cairo-java-1.0.8-1.fc14.1 - * Wed Sep 29 2010 jkeating - 1.0.8-1.1 - Rebuilt for gcc bug 634757 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
KompoZer packaging/review
If any mozilla/xulrunner experienced packagers would mind helping out with the kompozer package, that would be appreciated. -- 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: Ubuntu 10.10's installer looks rather nice
On 10/11/2010 08:51 PM, Bruno Wolff III wrote: On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams cmad...@hiwaay.net wrote: I think that is a misfeature. I don't want anything irreversible to be done until I say go. You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions. I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install. Actually formatting a large partition ( and =1 TB disks are becoming more and more frequent) DOES take enough time to go boil a coffee. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
Kevin Fenzi wrote: On Mon, 11 Oct 2010 09:07:17 +1000 Jeff Fearn jfe...@redhat.com wrote: On Fri, 2010-10-08 at 13:56 -0600, Kevin Fenzi wrote: On Fri, 08 Oct 2010 18:03:04 +0400 Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: In most cases I try sync all branches if there no real reasons to make differences. ...snip... I would hope a real reason would be that the update is not a security or bugfix only update, right? IMHO it depends on what kind of software it is. I push releases of applications to all current Fedora releases. The users want the new features, it's what they have been bugging me for. If I was working on glibc or X I might not do that, but applications should be pushed back unless there is some system level constraint preventing it. So I too would like a commit to all branches or sync all branches to this one command. If it doesn't change the user experience, and fixes bugs or security issues, then great. ;) If it's a major update which does change the user experience, breaks ABI/API, or adds a bunch of new functionality, then please don't. If you want ABI stability buy RHEL or use CentOS, because clearly your requirements are completely different from the requirements of most of the users of my software. They'd go batty if I tried to tell them they had to use rawhide to get a new feature. Cheers, Jeff. -- Jeff Fearn jfe...@redhat.com Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
On Tue, Oct 12, 2010 at 09:23:24AM +1000, Jeffrey Fearn wrote: Kevin Fenzi wrote: On Mon, 11 Oct 2010 09:07:17 +1000 Jeff Fearn jfe...@redhat.com wrote: On Fri, 2010-10-08 at 13:56 -0600, Kevin Fenzi wrote: On Fri, 08 Oct 2010 18:03:04 +0400 Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: In most cases I try sync all branches if there no real reasons to make differences. ...snip... I would hope a real reason would be that the update is not a security or bugfix only update, right? IMHO it depends on what kind of software it is. I push releases of applications to all current Fedora releases. The users want the new features, it's what they have been bugging me for. If I was working on glibc or X I might not do that, but applications should be pushed back unless there is some system level constraint preventing it. So I too would like a commit to all branches or sync all branches to this one command. If it doesn't change the user experience, and fixes bugs or security issues, then great. ;) If it's a major update which does change the user experience, breaks ABI/API, or adds a bunch of new functionality, then please don't. If you want ABI stability buy RHEL or use CentOS, because clearly your requirements are completely different from the requirements of most of the users of my software. They'd go batty if I tried to tell them they had to use rawhide to get a new feature. Surely it would be ok to tell them use the latest Fedora so you can at least leave Fn-1 (currently F12) alone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
W dniu 6 października 2010 15:42 użytkownik Eric Sandeen sand...@redhat.com napisał: Michał Piotrowski wrote: W dniu 6 października 2010 05:01 użytkownik Eric Sandeen sand...@redhat.com napisał: ... cool! I suppose I could turn it on in rawhide, or you could just build your own e2fsprogs to get it ... I already built my own version. Ok, let me know if you can break anything! :) (Some of my concern, which is admittedly hand-wavy, is the kernelside design of the thing, but any outright breakage of the current implementation would be good to find as well) Some things to test would be attempting to defrag files which are being actively written to / read from in various ways - concurrent access, mmap, etc. Also possibly testing large and/or sparse files, files with extended attributes, testing enospc conditions Does it makes sense to run tests on a large filesystem? I have a spare 1tb hdd, but I do not know if it's worth to run such tests. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
Chuck Anderson wrote: On Tue, Oct 12, 2010 at 09:23:24AM +1000, Jeffrey Fearn wrote: Kevin Fenzi wrote: On Mon, 11 Oct 2010 09:07:17 +1000 Jeff Fearn jfe...@redhat.com wrote: On Fri, 2010-10-08 at 13:56 -0600, Kevin Fenzi wrote: On Fri, 08 Oct 2010 18:03:04 +0400 Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: In most cases I try sync all branches if there no real reasons to make differences. ...snip... I would hope a real reason would be that the update is not a security or bugfix only update, right? IMHO it depends on what kind of software it is. I push releases of applications to all current Fedora releases. The users want the new features, it's what they have been bugging me for. If I was working on glibc or X I might not do that, but applications should be pushed back unless there is some system level constraint preventing it. So I too would like a commit to all branches or sync all branches to this one command. If it doesn't change the user experience, and fixes bugs or security issues, then great. ;) If it's a major update which does change the user experience, breaks ABI/API, or adds a bunch of new functionality, then please don't. If you want ABI stability buy RHEL or use CentOS, because clearly your requirements are completely different from the requirements of most of the users of my software. They'd go batty if I tried to tell them they had to use rawhide to get a new feature. Surely it would be ok to tell them use the latest Fedora so you can at least leave Fn-1 (currently F12) alone. What do you mean leave it alone? The people using it WANT the changes. Why are you telling them how they can use their system? They want the changes, it's trivial for me to give them the changes, why wouldn't I give them the changes? Cheers, Jeff. -- Jeff Fearn jfe...@redhat.com Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
On Tue, Oct 12, 2010 at 09:32:15AM +1000, Jeffrey Fearn wrote: What do you mean leave it alone? The people using it WANT the changes. Why are you telling them how they can use their system? Because by pushing updates you're also potentially making it impossible for people who don't want new bugs to use Fedora. The board have decided that that's a class of user that we want to support. They want the changes, it's trivial for me to give them the changes, why wouldn't I give them the changes? Because anyone who says that they can provide a software update without any risk of breaking something that a user currently depends on is either naive or lying. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Tue, Oct 12, 2010 at 12:12:35AM +0200, Emmanuel Seyman wrote: * Matthew Garrett [11/10/2010 19:57] : debian-installer? Yes. Shipping 2 different installers is a recipe for disaster from a user and QA perspective.Choose one between Ubiquity, Debian-installer and Anaconda. Ubiquity is a graphical interface built on top of the debian-installer framework. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 13:16 -0400, Bill Nottingham wrote: Matthias Clasen (mcla...@redhat.com) said: That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users. Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.) ...and all the people who are complaining about how the text install has been streamlined... -- 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: Git commit in all available branches
Matthew Garrett wrote: On Tue, Oct 12, 2010 at 09:32:15AM +1000, Jeffrey Fearn wrote: What do you mean leave it alone? The people using it WANT the changes. Why are you telling them how they can use their system? Because by pushing updates you're also potentially making it impossible for people who don't want new bugs to use Fedora. The board have decided that that's a class of user that we want to support. They also won't get old bugs fixed because I for one don't have the time , or the will, to maintain multiple versions. They want the changes, it's trivial for me to give them the changes, why wouldn't I give them the changes? Because anyone who says that they can provide a software update without any risk of breaking something that a user currently depends on is either naive or lying. Guess we are lucky no one said such a stupid thing eh. Cheers, Jeff. -- Jeff Fearn jfe...@redhat.com Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 13:18 -0400, Bill Nottingham wrote: Chris Lumens (clum...@redhat.com) said: - downloads updates in parallel too Package updates? 1) Given that it's using yum, downloading multiple things in parallel would need to be fixed there. 2) If it means downloading packages in the background while it does other tasks, given that package selection is the final task in the current workflow, it would require reordering the workflow to be beneficial. (Which becomes a memory usage tradeoff.) I believe the Ubuntu installer under discussion is the live installer. Like Fedora, there is no package selection involved there. Ubuntu gains considerable simplicity by having a separate installer app for live images and making that its default installer - I'm no expert, but I think the 'advanced' installer you can use for network installs and custom package selection and LVM and RAID and all that stuff is essentially Debian's installer, and is a completely different experience to the Ubuntu installer. So, we could follow this same path and make an anaconda-live which would be a considerably simplified subset of anaconda and could gain in parallelization and simplification and stuff, but we'd be duplicating a lot of effort then and we'd have no handy 'upstream' installer to fall back on for more complex cases, as Ubuntu does. -- 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: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 15:44 -0400, Jon Masters wrote: Sadly enough, this means that a shiny Ubuntu installer is to the whole distribution what GNOME shell is to the GNOME project. It doesn't matter if you've got a lot of bells and whistles underneath, or what you can do, if you don't look pretty while you do it. It's just the reality. I would venture that one of the reasons Rich sent his mail originally is that he's aware of this mentality and pointing out its effects. You forgot to qualify the above paragraph: it doesn't matter _to a distribution reviewer_. We aren't necessarily making Fedora for distribution reviewers. -- 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: KompoZer packaging/review
On 10/11/2010 5:06 PM, Orion Poplawski wrote: If any mozilla/xulrunner experienced packagers would mind helping out with the kompozer package, that would be appreciated. Sorry: https://bugzilla.redhat.com/show_bug.cgi?id=519521 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
On Tue, 12 Oct 2010 09:32:15 +1000 Jeffrey Fearn jfe...@redhat.com wrote: What do you mean leave it alone? The people using it WANT the changes. Why are you telling them how they can use their system? Not at all. :) They want the changes, it's trivial for me to give them the changes, why wouldn't I give them the changes? Because it breaks things or changes behavior for another large group of users? Can we perhaps stop talking in the abstract? What package is this? What sort of updates does it get? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
Kevin Fenzi wrote: On Tue, 12 Oct 2010 09:32:15 +1000 Jeffrey Fearn jfe...@redhat.com wrote: What do you mean leave it alone? The people using it WANT the changes. Why are you telling them how they can use their system? Not at all. :) They want the changes, it's trivial for me to give them the changes, why wouldn't I give them the changes? Because it breaks things or changes behavior for another large group of users? As I said, if I was doing a systems level package I'd not do it, but at the application level you only tend to affect users of your application. Can we perhaps stop talking in the abstract? What package is this? publican\* What sort of updates does it get? Large changes of every kind: bug fixes, new features, changes in behavior of existing features. Everything you'd expect of an application that is fairly young and has a demanding user base ... a very demanding user base ... OK, an extremely demanding user base ... yeah, I have ulcers. Cheers, Jeff. -- Jeff Fearn jfe...@redhat.com Software Engineer Engineering Operations Red Hat, Inc Freedom ... courage ... Commitment ... ACCOUNTABILITY -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Text-CSV_XS-0.75.tgz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Text-CSV_XS: 6ec24df35823f200ee3d5dceab3fd0ca Text-CSV_XS-0.75.tgz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 641568] perl-Text-CSV_XS-0.75 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=641568 Petr Sabata psab...@redhat.com changed: What|Removed |Added CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-CSV_XS] New version, 0.75
commit 3729237fc28fa5e59a467da4114a3c7880754a15
Author: Petr Sabata psab...@redhat.com
Date: Mon Oct 11 12:08:26 2010 +0200
New version, 0.75
.gitignore|1 +
perl-Text-CSV_XS.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 475bb46..f0845b9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Text-CSV_XS-0.72.tgz
/Text-CSV_XS-0.73.tgz
/Text-CSV_XS-0.74.tgz
+/Text-CSV_XS-0.75.tgz
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 77118f0..466b6d7 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -1,5 +1,5 @@
Name: perl-Text-CSV_XS
-Version:0.74
+Version:0.75
Release:1%{?dist}
Summary:Comma-separated values manipulation routines
@@ -63,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Oct 11 2010 Petr Sabata psab...@redhat.com - 0.75-1
+- 0.75 version bump
+
* Mon Oct 04 2010 Petr Pisar ppi...@redhat.com - 0.74-1
- 0.74 bump
diff --git a/sources b/sources
index 8e6bc32..7ff9244 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c30ee0db913fcebc76d707203b905b74 Text-CSV_XS-0.74.tgz
+6ec24df35823f200ee3d5dceab3fd0ca Text-CSV_XS-0.75.tgz
--
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 threads-shared-1.34.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads-shared: 07e048f7c81c98603ec27d4401f6b495 threads-shared-1.34.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 JSON-XS-2.3.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-JSON-XS: 4dc2a968e41f8cf330d46be12f221a12 JSON-XS-2.3.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-JSON-XS] Update to 2.3 from cpan. Change in rpm to 2.30.
commit 7cb38dbfe8a8729f97a724774f6e79943066fccf
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Oct 11 14:05:13 2010 +0200
Update to 2.3 from cpan. Change in rpm to 2.30.
.gitignore|1 +
perl-JSON-XS.spec | 17 +++--
sources |2 +-
3 files changed, 13 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7d5f6fc..ec93d93 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
JSON-XS-2.27.tar.gz
+/JSON-XS-2.3.tar.gz
diff --git a/perl-JSON-XS.spec b/perl-JSON-XS.spec
index bd1713a..a0a8633 100644
--- a/perl-JSON-XS.spec
+++ b/perl-JSON-XS.spec
@@ -1,13 +1,14 @@
+%define real_version 2.3
Name: perl-JSON-XS
Summary:JSON serialising/deserialising, done correctly and fast
Epoch: 1
-Version:2.27
-Release:2%{?dist}
+# previous version was 2.27
+Version:2.30
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/JSON-XS-%{version}.tar.gz
URL:http://search.cpan.org/dist/JSON-XS/
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/M/ML/MLEHMANN/JSON-XS-%{real_version}.tar.gz
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl(common::sense)
@@ -15,7 +16,8 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
Requires: perl(common::sense)
-
+# because of 2.3 upstream version and 2.30 rpm version
+Provides: perl(JSON::XS) = 2.30
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
@@ -26,7 +28,7 @@ primary goal is to be correct and its secondary goal is to be
fast. To
reach the latter goal it was written in C.
%prep
-%setup -q -n JSON-XS-%{version}
+%setup -q -n JSON-XS-%{real_version}
sed -i 's/\r//' t/*
perl -pi -e 's|^#!/opt/bin/perl|#!%{__perl}|' eg/*
@@ -62,6 +64,9 @@ rm -rf %{buildroot}
%{_mandir}/man[13]/*
%changelog
+* Mon Oct 11 2010 Marcela Mašláňová mmasl...@redhat.com - 1:2.30-1
+- update
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 1:2.27-2
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 943ea61..0fe43fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d7a4f92f2e497281f2a8f535fbe9783a JSON-XS-2.27.tar.gz
+4dc2a968e41f8cf330d46be12f221a12 JSON-XS-2.3.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-threads-shared] 1.34 bump
commit 15bd579fd72535ea79ceda6c042acda883996acb
Author: Petr Písař ppi...@redhat.com
Date: Mon Oct 11 14:07:08 2010 +0200
1.34 bump
.gitignore |1 +
perl-threads-shared.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6001a3d..a8fa788 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/threads-shared-1.33.tar.gz
+/threads-shared-1.34.tar.gz
diff --git a/perl-threads-shared.spec b/perl-threads-shared.spec
index 8f4371a..2fae5ee 100644
--- a/perl-threads-shared.spec
+++ b/perl-threads-shared.spec
@@ -1,5 +1,5 @@
Name: perl-threads-shared
-Version:1.33
+Version:1.34
Release:1%{?dist}
Summary:Perl extension for sharing data structures between threads
License:GPL+ or Artistic
@@ -55,6 +55,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Oct 11 2010 Petr Pisar ppi...@redhat.com - 1.34-1
+- 1.34 bump
+
* Thu Sep 23 2010 Petr Pisar ppi...@redhat.com 1.33-1
- Specfile autogenerated by cpanspec 1.78.
- Fix dependencies
diff --git a/sources b/sources
index 42462a4..7ba6688 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-59e5882c75033835d44d0ab3bfc02c60 threads-shared-1.33.tar.gz
+07e048f7c81c98603ec27d4401f6b495 threads-shared-1.34.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-threads/f13/master] (2 commits) ...1.81 bump
Summary of changes: 5ae7776... 1.79 imported (*) 0afd3e7... 1.81 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Tk/el6/master] (6 commits) ...Merge back in from master
Summary of changes: 3941f4e... Fix typo that causes a failure to update the common directo (*) 33eba8b... - rebuild against perl 5.10.1 (*) 14ef948... - Mass rebuild with perl-5.12.0 (*) da34362... - Mass rebuild with perl-5.12.0 update to development rel (*) d76407e... dist-git conversion (*) 3bc46c6... Merge back in from master (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Tk/el6/master: 6/6] Merge back in from master
commit 3bc46c6f824a9fc42904a184201a17a80c0524d1 Merge: 7996a40 d76407e Author: Mark Chappell trem...@fedoraproject.org Date: Mon Oct 11 22:55:28 2010 +0200 Merge back in from master .gitignore|2 +- perl-Tk-XIM.patch | 61 - perl-Tk-events.patch | 25 -- perl-Tk-getOpenFile.patch | 11 perl-Tk-gif.patch | 15 --- perl-Tk.spec | 32 --- sources |2 +- 7 files changed, 13 insertions(+), 135 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 571192] $ENV{HTTP_TRANSFER_ENCODING} may be undefined in SOAP::Transport::HTTP
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=571192 rvalue red...@burninator.net changed: What|Removed |Added CC||red...@burninator.net --- Comment #2 from rvalue red...@burninator.net 2010-10-11 20:34:03 EDT --- Had the same problem with Fedora 13 distribution of Bugzilla perl-SOAP-Lite packages. Worked around by undoing my own configuration of Bugzilla to use mod_perl; the default (mod_cgi?) Apache configuration does not exhibit this error for me. Are you using Bugzilla with mod_perl? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
