Re: How this bug can come out of its dead-end? Any suggestions?!
/*Frank Murphy frankl...@gmail.com*/ wrote on 05/08/2010 10:51:42 PM +0450: On 08/05/10 19:15, Hedayat Vatnakhah wrote: Please have a look at the last comments of the bug. Most of the implementation is done, the only missing part is how to mount the CD/DVD in PackageKit! Thanks, Hedayat If you can install gnome-packagekit-extra if using Gnome? Is houls allow you to choose which sources\repos to use. No, the problem is this: PackageKit does not know how to mount a removable media. As noted in the last comment of the mentioned bug, Muayyad Alsadi has implemented four methods for mounting a removable media: using DeviceKit, using GIO, using HAL and calling the system's mount command. The DeviceKit implementation cannot mount the device because of default system policies (the backend is running as root), GIO has a bug and does not allow mounting, HAL is deprecated, and PackageKit developer doesn't like mounting using the system's mount command! Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On Sun, 2010-05-09 at 11:22 +0430, Hedayat Vatankhah wrote: Frank Murphy frankl...@gmail.com wrote on 05/08/2010 10:51:42 PM +0450: On 08/05/10 19:15, Hedayat Vatnakhah wrote: Please have a look at the last comments of the bug. Most of the implementation is done, the only missing part is how to mount the CD/DVD in PackageKit! Thanks, Hedayat If you can install gnome-packagekit-extra if using Gnome? Is houls allow you to choose which sources\repos to use. No, the problem is this: PackageKit does not know how to mount a removable media. As noted in the last comment of the mentioned bug, Muayyad Alsadi has implemented four methods for mounting a removable media: using DeviceKit, using GIO, using HAL and calling the system's mount command. The DeviceKit implementation cannot mount the device because of default system policies (the backend is running as root), GIO has a bug and does not allow mounting, HAL is deprecated, and PackageKit developer doesn't like mounting using the system's mount command! Thanks, Hedayat hey, A suggestion. Instead of working specifically and trying to mount the dvd/cd, why not have an option that says use a custom/local repo It could open an explorer window and let you choose the repo directory. Since dvds/cds are mounted by default on insertion, the user could easily select it and use it as an additional repo. This way, you (packagekit devs) don't have to worry about mounting the dvd/cd media, and are also providing support for any local repos that people might want to use (copied repos using USB hard drives etc). You won't need to get the media.repo and configure it to the correct path etc. too. Comments? -- regards, Ankur - FAS : ankursinha ; franciscod @ Freenode - gpg --keyserver pgp.mit.edu --recv-keys 5E9BF638 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: How this bug can come out of its dead-end? Any suggestions?!
On 09/05/10 07:52, Hedayat Vatankhah wrote: --snip-- No, the problem is this: PackageKit does not know how to mount a removable media. It doesn't need to. --snip-- Mount DVD as normal. your dvd.repo : baseurl:file://path/to/dvd/(repodata) eg: baseurl=file:/media/Fedora 12 i386 DVD enabled=1 gpgcheck=true Why fix a bug that doesn't need to be fixed. Above method works for me. -- Regards, Frank Murphy UTF_8 Encoded, Fedora 64 32 bit attachment: Screenshot - 090510 - 08:11:03.png-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On ۱۰/۰۵/۰۹ 11:41, Frank Murphy wrote: On 09/05/10 07:52, Hedayat Vatankhah wrote: --snip-- No, the problem is this: PackageKit does not know how to mount a removable media. It doesn't need to. --snip-- Mount DVD as normal. your dvd.repo : baseurl:file://path/to/dvd/(repodata) eg: baseurl=file:/media/Fedora 12 i386 DVD enabled=1 gpgcheck=true Why fix a bug that doesn't need to be fixed. Above method works for me. Personally I do know how to use DVD as a repository, but that's not suitable for users AT ALL. This bug is about OUT OF THE BOX installation media support by packagekit. Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On ۱۰/۰۵/۰۹ 11:43, Ankur Sinha wrote: On Sun, 2010-05-09 at 11:22 +0430, Hedayat Vatankhah wrote: Frank Murphyfrankl...@gmail.com wrote on 05/08/2010 10:51:42 PM +0450: On 08/05/10 19:15, Hedayat Vatnakhah wrote: Please have a look at the last comments of the bug. Most of the implementation is done, the only missing part is how to mount the CD/DVD in PackageKit! Thanks, Hedayat If you can install gnome-packagekit-extra if using Gnome? Is houls allow you to choose which sources\repos to use. No, the problem is this: PackageKit does not know how to mount a removable media. As noted in the last comment of the mentioned bug, Muayyad Alsadi has implemented four methods for mounting a removable media: using DeviceKit, using GIO, using HAL and calling the system's mount command. The DeviceKit implementation cannot mount the device because of default system policies (the backend is running as root), GIO has a bug and does not allow mounting, HAL is deprecated, and PackageKit developer doesn't like mounting using the system's mount command! Thanks, Hedayat hey, A suggestion. Instead of working specifically and trying to mount the dvd/cd, why not have an option that says use a custom/local repo It could open an explorer window and let you choose the repo directory. Since dvds/cds are mounted by default on insertion, the user could easily select it and use it as an additional repo. This way, you (packagekit devs) don't have to worry about mounting the dvd/cd media, and are also providing support for any local repos that people might want to use (copied repos using USB hard drives etc). You won't need to get the media.repo and configure it to the correct path etc. too. Comments? First of all, such changes should be discussed with the PackageKit author. AFAIK, he doesn't agree with such changes. Also, Muayyad's work seems to cover USB media support too (you can see this page for more information: http://fedoraproject.org/wiki/Features/MediaRepo). And your suggestion will not work with split media IMHO. Personally, I think even the solution to use system's mount command is much better than the current situation, but apparently the PackageKit author doesn't like it at all! Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On 09/05/10 10:28, Hedayat Vatankhah wrote: --snip-- eg: baseurl=file:/media/Fedora 12 i386 DVD enabled=1 gpgcheck=true Why fix a bug that doesn't need to be fixed. Above method works for me. Personally I do know how to use DVD as a repository, but that's not suitable for users AT ALL. This bug is about OUT OF THE BOX installation media support by packagekit. That *should not* be default for most users, as it will end up breaking quite a lot, if used with other repos. (updates,updates-tesing, 3rd party) as %requires may have changed quite a bit since DVD was released. -- Regards, Frank Murphy UTF_8 Encoded, Fedora 64 32 bit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 9, 2010 at 12:09 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2010-05-07 at 19:40 -0700, John Poelstra wrote: Matěj Cepl said the following on 05/07/2010 04:41 PM Pacific Time: More and more I was writing this email, more and more I tend to agree with somebody today, who wrote that they key problem of the Fedora community is unclear vision about its purpose. I agree completely. I believe, that in the root of many of our problems lies in our unwillingness to say that we are not end-user-oriented distribution, but the contributors-oriented one. It is not a binary situation. https://fedoraproject.org/wiki/User_base I'm tempted to agree in practice with Matej that it is. I don't think we can kid ourselves that we're doing a particularly good job of making a desktop for end users; if we were, we wouldn't be being trashed by Ubuntu in this area (let alone OS X and Windows). Yes, yes, I know, Ubuntu's statistics are unreliable and all that crap. I know we can all rationalize for ten hours about how it's all Microsoft's fault for being evil and Ubuntu's fault for being good at marketing and users' fault for being stupid and blah de freaking blah. But be practical. When you go to $RANDOM_LINUX_CONFERENCE (never mind when you go to the coffee shop, I have never seen anyone else running Fedora in any situation outside of the 'Linux world'), how many people are running Fedora and how many are running Ubuntu? Have you noticed how, whenever _any_ third party site posts reader statistics, the first thing you see is that Linux is tiny, and the second thing you see is that a heavy pluarality of the Linux numbers are Ubuntu? Example: Distrowatch prints user agent stats, not just page hit rankings. http://distrowatch.com/awstats/awstats.DistroWatch.com.osdetail.html . Ubuntu is at 16.5%. Fedora is at 1.3%, on which number we are being beaten by OpenSUSE and PCLinuxOS (and being trounced by Linux Mint, a shoestring budgeted Ubuntu derivative), and just outpacing Debian and Mandriva. Yep, a grand 1.3% of the people who visit a general-purpose Linux news site are running Fedora when they do it. Please, _please_, do not attempt to rationalize or excuse or except these numbers; they're just an example (I know some people will, despite this explicit request; I intend to entirely ignore them). Every site I've ever seen print its user agent stats tells a similar story. Does anyone actually want to claim that this kind of thing is a stunning success story for Fedora as a general purpose desktop operating system? Those numbers aren't lying. I think this discussion should always be informed by the fundamental understanding that, if we're talking about making an attractive general-purpose operating system for end users, we're currently fairly shit at it. We're not a shit project, we do a lot of valuable work that needs to be done, and produce products that are great in certain ways. But we should either get a better understanding of what we are actually good at and valuable for and work on those things, or if we're serious about being an end-user desktop, get a lot better at it. Which would probably involve doing some things a lot of members of the project would be unhappy with. Frankly, I don't think this project is currently laid out in such a way that doing that would be very practical; it's very difficult to engender radical change in Fedora as a project. (Note: user == end user here) Well there are technical, legal, marketing and structural reasons for this. Fedora is received as an unstable bleeding edge distro, that while Ubuntu is marketing itself as just works. Neither might be 100% true, but the we do seems to suck at providing a usable update experience shit just randomly break (a user does not give a damn why broken == broken period). And no it is not like Ubuntu users can't get the newer software during a release cycle there are PPAs for almost everything; so if user A wants a shiny new version of foo ... chances are high that he will find a PPA shipping this. Ubuntu seems to be more present in the media; it goes even that far that some people think Linux == Ubuntu ... but any marketing wouldn't be helpful as long as we don't provide the experience users want. Distributions like Linux Mint find its users by the simple fact that they don't give a damn about software patents; not much we can do here, but for a user a distro that plays/runs everything out of the box is perceived as better than one where you have to jump through hops to get stuff working. Users don't want to spend the their time configuring the system but actually *using* it. Making any change is much harder than it should be; we always end up in endless discussions without any outcome while others like Ubuntu seems to have a better decision making process; and seriously I think this is the one which basically blocks us from addressing any issue (making a change
Re: Reasons for hall monitoring
Personally I think Fedora is good at what it does, and although it causes me some frustration that Fedora isn't better at wooing mass market users, I wouldn't want to make radical changes to structures and processes to chase some goals. There would be much easier and more painless ways to woo these users without actually changing how Fedora is put together. I'm talking about marketing, evangelism and education. If there are technical issues that are found to hold this back then let them be addressed, but don't change the project and risk alienating the contributors for the sake of *theoretical* improvements. Adam - I use Fedora at home - one server and four laptop / PC workstations. It's very fit for purpose, in fact has less downtime and is more easily maintained than the two Windows machines we have. My mum uses Fedora too. At work we use CentOS but that is historical, we might as easily be running Fedora. I think the barriers to mass adoption by and large aren't technical. Also these goals really shouldn't be used as a rationale for changes unless you are sure of what you will achieve. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
Frank Murphy wrote: That *should not* be default for most users, as it will end up breaking quite a lot, if used with other repos. (updates,updates-tesing, 3rd party) If using the DVD together with the updates repository would break quite a lot, then how can we all be using the stable and updates repositories together without it breaking quite a lot? What is the DVD, if not a subset of the stable repository with higher bandwidth? Björn Persson 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: How this bug can come out of its dead-end? Any suggestions?!
On 09/05/10 12:34, Björn Persson wrote: Frank Murphy wrote: That *should not* be default for most users, as it will end up breaking quite a lot, if used with other repos. (updates,updates-tesing, 3rd party) If using the DVD together with the updates repository would break quite a lot, That's just my bad explanation. (not enough coffee) What I should have said: If the user does not know how to mount a CD\DVD. (which is automatic?) Should they be given usage of PackageKit, which at the least would require root (p\w) or sudo (within terminal). If it is a bandwidth $cost, could not the CD\DVD ~/packages be copied to ~/local/folder, and shared with a number of users. along with update\3rd Party repo (as they are downloaded). using yum*local, hence reducing the $cost. (also reduces media swapping) Still no need for a PackageKit rfe fix. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100509 changes
Compose started at Sun May 9 08:15:17 UTC 2010 Broken deps for i386 -- almanah-0.7.2-1.fc13.i686 requires libedataserver-1.2.so.11 almanah-0.7.2-1.fc13.i686 requires libedataserverui-1.2.so.8 anjal-0.3.2-2.fc14.i686 requires libedataserver-1.2.so.11 anjal-0.3.2-2.fc14.i686 requires libcamel-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libcamel-provider-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libedataserverui-1.2.so.8 clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3 clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9) dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 dcbd-0.9.19-3.fc14.i686 requires libconfig.so.8 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-provider-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libedataserver-1.2.so.11 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 evolution-sharp-0.21.1-5.fc13.i686 requires libedataserver-1.2.so.11 glabels-2.2.7-1.fc14.i686 requires libedataserver-1.2.so.11 gnome-launch-box-0.4-17.fc13.i686 requires libedataserver-1.2.so.11 gnome-panel-2.30.0-1.fc14.i686 requires libedataserverui-1.2.so.8 gnome-panel-2.30.0-1.fc14.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gpsdrive-2.10-0.5.pre7.fc13.i686 requires libgps.so.18 1:libopensync-plugin-evolution2-0.22-3.fc13.i686 requires libedataserver-1.2.so.11 lldpad-0.9.32-1.fc14.i686 requires libconfig.so.8 mumble-1.2.2-6.fc14.i686 requires libprotobuf.so.4 murmur-1.2.2-6.fc14.i686 requires libprotobuf.so.4 pygsl-0.9.5-1.fc14.i686 requires gsl = 0:1.13 pygsl-devel-0.9.5-1.fc14.i686 requires gsl-devel = 0:1.13 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 vifir-0.4-2.fc14.i686 requires libgps.so.18 viking-0.9.9-1.fc12.i686 requires libgps.so.18 Broken deps for x86_64 -- almanah-0.7.2-1.fc13.x86_64 requires libedataserverui-1.2.so.8()(64bit) almanah-0.7.2-1.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-provider-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3 clutter-gtkmm-0.9.4-3.fc12.x86_64 requires libcluttermm-0.9.so.3()(64bit) clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9) clutter-gtkmm-devel-0.9.4-3.fc12.x86_64 requires pkgconfig(cluttermm-0.9) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) dcbd-0.9.19-3.fc14.x86_64 requires libconfig.so.8()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-provider-1.2.so.14()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcouchdb-glib-1.0.so.1()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-1.2.so.14()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) evolution-sharp-0.21.1-5.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) glabels-2.2.7-1.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-launch-box-0.4-17.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-panel-2.30.0-1.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit) gnome-panel-2.30.0-1.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-phone-manager-0.65-5.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-phone-manager-telepathy-0.65-5.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) gpsdrive-2.10-0.5.pre7.fc13.x86_64 requires libgps.so.18()(64bit) 1:libopensync-plugin-evolution2-0.22-3.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) lldpad-0.9.32-1.fc14.x86_64 requires libconfig.so.8()(64bit) mumble-1.2.2-6.fc14.x86_64 requires libprotobuf.so.4()(64bit) murmur-1.2.2-6.fc14.x86_64 requires libprotobuf.so.4()(64bit) pygsl-0.9.5-1.fc14.x86_64 requires gsl = 0:1.13 pygsl-devel-0.9.5-1.fc14.i686 requires gsl-devel = 0:1.13 pygsl-devel-0.9.5-1.fc14.x86_64 requires gsl-devel = 0:1.13
Re: How this bug can come out of its dead-end? Any suggestions?!
/*Frank Murphy frankl...@gmail.com*/ wrote on 05/09/2010 4:20:15 PM +0450: On 09/05/10 12:34, Björn Persson wrote: Frank Murphy wrote: That *should not* be default for most users, as it will end up breaking quite a lot, if used with other repos. (updates,updates-tesing, 3rd party) If using the DVD together with the updates repository would break quite a lot, That's just my bad explanation. (not enough coffee) What I should have said: If the user does not know how to mount a CD\DVD. (which is automatic?) Should they be given usage of PackageKit, which at the least would require root (p\w) or sudo (within terminal). If it is a bandwidth $cost, could not the CD\DVD ~/packages be copied to ~/local/folder, and shared with a number of users. along with update\3rd Party repo (as they are downloaded). using yum*local, hence reducing the $cost. (also reduces media swapping) Still no need for a PackageKit rfe fix. Frank Well, sorry but you simply don't get it! Give a Fedora DVD to a new Linux user and tell him to install it on his own system. Then ask him to install Eclipse from DVD since he will most probably NOT opt to customize his package set in the installation process. Make sure that he has no Internet access, and do NOT help him in the process. He will be certainly unable to do so. Then do this for him yourself and see how frightened is him. If you get him an Ubuntu DVD, you'll see that he can happily use it without your help. And you'll see why he will think that Ubuntu is much easier than Fedora. If you have not see this at all, I've seen this frequently. Fedora sucks in this area for many years. I've seen it, so whatever arguments you bring; I KNOW that this bug IS very important and should be fixed. Excuse me, I'm looking for a solution, not for wiping the problem statement. Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On 09/05/10 13:34, Hedayat Vatankhah wrote: --snip-- Frank Well, sorry but you simply don't get it! Give a Fedora DVD to a new Linux user and tell him to install it on his own system. Then ask him to install Eclipse from DVD since he will most probably NOT opt to customize his package set in the installation process. I have told you how to do this. Make sure that he has no Internet access, and do NOT help him in the process. He will be certainly unable to do so. Then do this for him yourself and see how frightened is him. Have not many given tips. If you get him an Ubuntu DVD, you'll see that he can happily use it without your help. And you'll see why he will think that Ubuntu is much easier than Fedora. It is!, so what? If you have not see this at all, I've seen this frequently. Fedora sucks in this area for many years. I've seen it, so whatever arguments you bring; I KNOW that this bug IS very important and should be fixed. Currently there are various threads, about what Fedora is targeted at, those questions as yet rmein without a proper answr. Excuse me, I'm looking for a solution, not for wiping the problem statement. The solution for a new user to Linux, give hime Ubuntu-LTS. When he knows some more, give him Fedora. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 9.5.2010 12:09, Adam Williamson napsal(a): Making any change is much harder than it should be; we always end up in endless discussions without any outcome while others like Ubuntu seems to have a better decision making process; and seriously I think this is the one which basically blocks us from addressing any issue Yes, I know that I am slightly opposing myself, but just to emphasize that I am not for total anarchy ... I think it is no mistake that most successful free projects are governed by BDFL of some kind. I believe that just a one person doing tiny little bit required to run the community (with support from community in doing actual work) would be much better than our current attempts to pretend we are democracy. Matěj -- If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
Dne 9.5.2010 06:53, Chen Lei napsal(a): For them, we can simply: 1. Simply orphan those application from repos which have dead upstream for a long time. Normally, those allipcations have better alternatives using GTK+ 2.x, we don't need worry about this. 2.Update applications to GTK 2.x port which was already done by upstream, and ping the maintainer to see if he is nonresponsive now. I think it would help anybody if you can provide a list of packages involved. Matěj -- Don't anthropomorphize computers. They don't like it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/9 Andrea Musuruane musur...@gmail.com On F-12/x86_64: $ repoquery --whatrequires --alldeps gtk+ |grep x86_64|sort bubblemon-0:1.46-10.fc12.x86_64 crossfire-client-0:1.11.0-3.fc12.x86_64 dillo-0:0.8.6-11.fc12.x86_64 gcombust-1:0.1.55-16.x86_64 gcx-0:0.9.11-9.fc12.x86_64 gdk-pixbuf-1:0.22.0-38.fc12.x86_64 gnome-libs-1:1.4.2-15.fc12.x86_64 gsview-0:4.9-2.fc12.x86_64 gtk+-1:1.2.10-69.fc12.x86_64 gtk+-devel-1:1.2.10-69.fc12.x86_64 imlib-1:1.9.15-12.fc12.x86_64 justmoon-gtk-0:0.3.3-6.fc12.x86_64 lame-mp3x-0:3.98.2-3.fc11.x86_64 lame-mp3x-0:3.98.3-1.fc12.x86_64 lazarus-0:0.9.26.2-4.fc12.x86_64 libglade-1:0.17-24.fc12.x86_64 logjam-xmms-1:4.5.3-36.fc12.x86_64 logjam-xmms-1:4.5.3-37.fc12.x86_64 manedit-0:1.2.1-3.fc12.x86_64 purple-plugin_pack-pidgin-xmms-0:2.4.0-4.fc12.x86_64 putty-0:0.60-5.fc12.x86_64 qiv-0:2.0-11.fc12.x86_64 scigraphica-0:2.1.0-9.fc12.x86_64 siril-0:0.8-9.fc12.x86_64 smpeg-0:0.4.5-0.3.fc11.x86_64 soundtracker-0:0.6.8-8.fc12.x86_64 spacechart-0:0.9.5-5.fc12.x86_64 swami-0:0.9.4-6.fc12.x86_64 xarchon-0:0.50-10.fc12.x86_64 xconvers-0:0.8.3-7.fc12.x86_64 xdialog-0:2.3.1-5.fc12.x86_64 xmms-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-acme-0:0.4.3-11.x86_64 xmms-adplug-0:1.2-9.fc12.x86_64 xmms-alarm-0:0.3.7-10.fc12.x86_64 xmmsctrl-0:1.8-6.fc12.x86_64 xmms-esd-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-faad2-1:2.7-1.fc11.x86_64 xmms-flac-0:1.1.4-6.fc12.x86_64 xmms-flac-0:1.2.1-1.fc12.x86_64 xmms-libs-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-lirc-0:1.4-14.x86_64 xmms-mp3-0:1.2.11-3.20071117cvs.fc11.x86_64 xmms-mplayer-0:0.5-2.fc11.x86_64 xmms-musepack-0:1.2-8.fc12.x86_64 xmms-normalize-0:0.7.7-5.fc11.x86_64 xmms-pulse-0:0.9.4-8.fc12.x86_64 xmms-sid-0:0.8.0-0.8.beta19.fc12.x86_64 xmms-speex-0:0.9.1-15.x86_64 xmms-uade-0:2.09-5.fc11.x86_64 xmms-xmp-0:2.7.1-1.fc12.x86_64 xmms-xmp-0:3.1.0-1.fc12.x86_64 xmms-xosd-0:2.2.14-13.fc12.x86_64 xvattr-0:1.3-17.x86_64 It seems to me that removing gtk+ won't be an easy task :( Regards, Andrea. Most of those applications are replaced, e.g. xmms2 for xmms, putty(svn) for putty 0.60, since it's already done by some other distributions, I think it's quite safe to retire gtk 1.2 completely from fedora. Also, considering fedora is a bleeding-edge distribution, keeping some many old applications with dead upstream for a long time seems strange. Regard. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On 05/09/2010 03:17 PM, Chen Lei wrote: 2010/5/9 Andrea Musuruane musur...@gmail.com mailto:musur...@gmail.com On F-12/x86_64: $ repoquery --whatrequires --alldeps gtk+ |grep x86_64|sort bubblemon-0:1.46-10.fc12.x86_64 crossfire-client-0:1.11.0-3.fc12.x86_64 dillo-0:0.8.6-11.fc12.x86_64 gcombust-1:0.1.55-16.x86_64 gcx-0:0.9.11-9.fc12.x86_64 gdk-pixbuf-1:0.22.0-38.fc12.x86_64 gnome-libs-1:1.4.2-15.fc12.x86_64 gsview-0:4.9-2.fc12.x86_64 gtk+-1:1.2.10-69.fc12.x86_64 gtk+-devel-1:1.2.10-69.fc12.x86_64 imlib-1:1.9.15-12.fc12.x86_64 justmoon-gtk-0:0.3.3-6.fc12.x86_64 lame-mp3x-0:3.98.2-3.fc11.x86_64 lame-mp3x-0:3.98.3-1.fc12.x86_64 lazarus-0:0.9.26.2-4.fc12.x86_64 libglade-1:0.17-24.fc12.x86_64 logjam-xmms-1:4.5.3-36.fc12.x86_64 logjam-xmms-1:4.5.3-37.fc12.x86_64 manedit-0:1.2.1-3.fc12.x86_64 purple-plugin_pack-pidgin-xmms-0:2.4.0-4.fc12.x86_64 putty-0:0.60-5.fc12.x86_64 qiv-0:2.0-11.fc12.x86_64 scigraphica-0:2.1.0-9.fc12.x86_64 siril-0:0.8-9.fc12.x86_64 smpeg-0:0.4.5-0.3.fc11.x86_64 soundtracker-0:0.6.8-8.fc12.x86_64 spacechart-0:0.9.5-5.fc12.x86_64 swami-0:0.9.4-6.fc12.x86_64 xarchon-0:0.50-10.fc12.x86_64 xconvers-0:0.8.3-7.fc12.x86_64 xdialog-0:2.3.1-5.fc12.x86_64 xmms-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-acme-0:0.4.3-11.x86_64 xmms-adplug-0:1.2-9.fc12.x86_64 xmms-alarm-0:0.3.7-10.fc12.x86_64 xmmsctrl-0:1.8-6.fc12.x86_64 xmms-esd-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-faad2-1:2.7-1.fc11.x86_64 xmms-flac-0:1.1.4-6.fc12.x86_64 xmms-flac-0:1.2.1-1.fc12.x86_64 xmms-libs-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-lirc-0:1.4-14.x86_64 xmms-mp3-0:1.2.11-3.20071117cvs.fc11.x86_64 xmms-mplayer-0:0.5-2.fc11.x86_64 xmms-musepack-0:1.2-8.fc12.x86_64 xmms-normalize-0:0.7.7-5.fc11.x86_64 xmms-pulse-0:0.9.4-8.fc12.x86_64 xmms-sid-0:0.8.0-0.8.beta19.fc12.x86_64 xmms-speex-0:0.9.1-15.x86_64 xmms-uade-0:2.09-5.fc11.x86_64 xmms-xmp-0:2.7.1-1.fc12.x86_64 xmms-xmp-0:3.1.0-1.fc12.x86_64 xmms-xosd-0:2.2.14-13.fc12.x86_64 xvattr-0:1.3-17.x86_64 It seems to me that removing gtk+ won't be an easy task :( Regards, Andrea. Most of those applications are replaced, e.g. xmms2 for xmms, putty(svn) for putty 0.60, since it's already done by some other distributions, I think it's quite safe to retire gtk 1.2 completely from fedora. Also, considering fedora is a bleeding-edge distribution, keeping some many old applications with dead upstream for a long time seems strange. Regard. Chen Lei some packages can use alternative toolkit. eg: Dillo [1] uses FLTK2. [1] http://www.dillo.org/ -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/9 Andrea Musuruane musur...@gmail.com On F-12/x86_64: $ repoquery --whatrequires --alldeps gtk+ |grep x86_64|sort bubblemon-0:1.46-10.fc12.x86_64 crossfire-client-0:1.11.0-3.fc12.x86_64 dillo-0:0.8.6-11.fc12.x86_64 gcombust-1:0.1.55-16.x86_64 gcx-0:0.9.11-9.fc12.x86_64 gdk-pixbuf-1:0.22.0-38.fc12.x86_64 gnome-libs-1:1.4.2-15.fc12.x86_64 gsview-0:4.9-2.fc12.x86_64 gtk+-1:1.2.10-69.fc12.x86_64 gtk+-devel-1:1.2.10-69.fc12.x86_64 imlib-1:1.9.15-12.fc12.x86_64 justmoon-gtk-0:0.3.3-6.fc12.x86_64 lame-mp3x-0:3.98.2-3.fc11.x86_64 lame-mp3x-0:3.98.3-1.fc12.x86_64 lazarus-0:0.9.26.2-4.fc12.x86_64 libglade-1:0.17-24.fc12.x86_64 logjam-xmms-1:4.5.3-36.fc12.x86_64 logjam-xmms-1:4.5.3-37.fc12.x86_64 manedit-0:1.2.1-3.fc12.x86_64 purple-plugin_pack-pidgin-xmms-0:2.4.0-4.fc12.x86_64 putty-0:0.60-5.fc12.x86_64 qiv-0:2.0-11.fc12.x86_64 scigraphica-0:2.1.0-9.fc12.x86_64 siril-0:0.8-9.fc12.x86_64 smpeg-0:0.4.5-0.3.fc11.x86_64 soundtracker-0:0.6.8-8.fc12.x86_64 spacechart-0:0.9.5-5.fc12.x86_64 swami-0:0.9.4-6.fc12.x86_64 xarchon-0:0.50-10.fc12.x86_64 xconvers-0:0.8.3-7.fc12.x86_64 xdialog-0:2.3.1-5.fc12.x86_64 xmms-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-acme-0:0.4.3-11.x86_64 xmms-adplug-0:1.2-9.fc12.x86_64 xmms-alarm-0:0.3.7-10.fc12.x86_64 xmmsctrl-0:1.8-6.fc12.x86_64 xmms-esd-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-faad2-1:2.7-1.fc11.x86_64 xmms-flac-0:1.1.4-6.fc12.x86_64 xmms-flac-0:1.2.1-1.fc12.x86_64 xmms-libs-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-lirc-0:1.4-14.x86_64 xmms-mp3-0:1.2.11-3.20071117cvs.fc11.x86_64 xmms-mplayer-0:0.5-2.fc11.x86_64 xmms-musepack-0:1.2-8.fc12.x86_64 xmms-normalize-0:0.7.7-5.fc11.x86_64 xmms-pulse-0:0.9.4-8.fc12.x86_64 xmms-sid-0:0.8.0-0.8.beta19.fc12.x86_64 xmms-speex-0:0.9.1-15.x86_64 xmms-uade-0:2.09-5.fc11.x86_64 xmms-xmp-0:2.7.1-1.fc12.x86_64 xmms-xmp-0:3.1.0-1.fc12.x86_64 xmms-xosd-0:2.2.14-13.fc12.x86_64 xvattr-0:1.3-17.x86_64 It seems to me that removing gtk+ won't be an easy task :( Regards, Andrea. Some programs are now already ported to GTK2, e.g. bubblemon, but the maintainer don't update those applications to the lastest version for a long time. It's time to retire gtk+ 1.2, the latest update for it is 02-Apr-2001. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, 2010-05-09 at 12:16 +0100, Camilo Mesias wrote: Personally I think Fedora is good at what it does, and although it causes me some frustration that Fedora isn't better at wooing mass market users, I wouldn't want to make radical changes to structures and processes to chase some goals. I agree - as I said, I don't think Fedora is a bad project at what it actually achieves. Adam - I use Fedora at home - one server and four laptop / PC workstations. It's very fit for purpose, in fact has less downtime and is more easily maintained than the two Windows machines we have. My mum uses Fedora too. At work we use CentOS but that is historical, we might as easily be running Fedora. I think the barriers to mass adoption by and large aren't technical. Also these goals really shouldn't be used as a rationale for changes unless you are sure of what you will achieve. This is what's called 'damning with faint praise' =). I mostly agree, but the point is, we're not bringing something amazing and special to the table. In harsh practical terms we're possibly a bit better than Windows for a few people, probably a little worse for a lot of people. That's not really turning anyone's excitement crank, is it? We can all talk about our anecdotal experiences like this if we like, but the fundamental point is that, if we were building a stunningly better desktop operating system than the alternatives, people would be flocking to use it. They aren't, ergo we're not. -- 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: Retire glib and gtk+ 1.2 from rawhide?
2010/5/9 Andrea Musuruane musur...@gmail.com On Sun, May 9, 2010 at 3:49 PM, Matěj Cepl mc...@redhat.com wrote: Dne 9.5.2010 06:53, Chen Lei napsal(a): For them, we can simply: 1. Simply orphan those application from repos which have dead upstream for a long time. Normally, those allipcations have better alternatives using GTK+ 2.x, we don't need worry about this. 2.Update applications to GTK 2.x port which was already done by upstream, and ping the maintainer to see if he is nonresponsive now. I think it would help anybody if you can provide a list of packages involved. On F-12/x86_64: $ repoquery --whatrequires --alldeps gtk+ |grep x86_64|sort bubblemon-0:1.46-10.fc12.x86_64 crossfire-client-0:1.11.0-3.fc12.x86_64 dillo-0:0.8.6-11.fc12.x86_64 gcombust-1:0.1.55-16.x86_64 gcx-0:0.9.11-9.fc12.x86_64 gdk-pixbuf-1:0.22.0-38.fc12.x86_64 gnome-libs-1:1.4.2-15.fc12.x86_64 gsview-0:4.9-2.fc12.x86_64 gtk+-1:1.2.10-69.fc12.x86_64 gtk+-devel-1:1.2.10-69.fc12.x86_64 imlib-1:1.9.15-12.fc12.x86_64 justmoon-gtk-0:0.3.3-6.fc12.x86_64 lame-mp3x-0:3.98.2-3.fc11.x86_64 lame-mp3x-0:3.98.3-1.fc12.x86_64 lazarus-0:0.9.26.2-4.fc12.x86_64 libglade-1:0.17-24.fc12.x86_64 logjam-xmms-1:4.5.3-36.fc12.x86_64 logjam-xmms-1:4.5.3-37.fc12.x86_64 manedit-0:1.2.1-3.fc12.x86_64 purple-plugin_pack-pidgin-xmms-0:2.4.0-4.fc12.x86_64 putty-0:0.60-5.fc12.x86_64 qiv-0:2.0-11.fc12.x86_64 scigraphica-0:2.1.0-9.fc12.x86_64 siril-0:0.8-9.fc12.x86_64 smpeg-0:0.4.5-0.3.fc11.x86_64 soundtracker-0:0.6.8-8.fc12.x86_64 spacechart-0:0.9.5-5.fc12.x86_64 swami-0:0.9.4-6.fc12.x86_64 xarchon-0:0.50-10.fc12.x86_64 xconvers-0:0.8.3-7.fc12.x86_64 xdialog-0:2.3.1-5.fc12.x86_64 xmms-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-acme-0:0.4.3-11.x86_64 xmms-adplug-0:1.2-9.fc12.x86_64 xmms-alarm-0:0.3.7-10.fc12.x86_64 xmmsctrl-0:1.8-6.fc12.x86_64 xmms-esd-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-faad2-1:2.7-1.fc11.x86_64 xmms-flac-0:1.1.4-6.fc12.x86_64 xmms-flac-0:1.2.1-1.fc12.x86_64 xmms-libs-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-lirc-0:1.4-14.x86_64 xmms-mp3-0:1.2.11-3.20071117cvs.fc11.x86_64 xmms-mplayer-0:0.5-2.fc11.x86_64 xmms-musepack-0:1.2-8.fc12.x86_64 xmms-normalize-0:0.7.7-5.fc11.x86_64 xmms-pulse-0:0.9.4-8.fc12.x86_64 xmms-sid-0:0.8.0-0.8.beta19.fc12.x86_64 xmms-speex-0:0.9.1-15.x86_64 xmms-uade-0:2.09-5.fc11.x86_64 xmms-xmp-0:2.7.1-1.fc12.x86_64 xmms-xmp-0:3.1.0-1.fc12.x86_64 xmms-xosd-0:2.2.14-13.fc12.x86_64 xvattr-0:1.3-17.x86_64 It seems to me that removing gtk+ won't be an easy task : Upstream do not use gtk+ 1.2 anymore bubblemon-0:1.46-10.fc12.x86_64 crossfire-client-0:1.11.0-3.fc12.x86_64 dillo-0:0.8.6-11.fc12.x86_64 gcx-0:0.9.11-9.fc12.x86_64 lazarus-0:0.9.26.2-4.fc12.x86_64 putty-0:0.60-5.fc12.x86_64 qiv-0:2.0-11.fc12.x86_64 Upstream is dead for a long time gcombust-1:0.1.55-16.x86_64 justmoon-gtk-0:0.3.3-6.fc12.x86_64 scigraphica-0:2.1.0-9.fc12.x86_64 siril-0:0.8-9.fc12.x86_64 soundtracker-0:0.6.8-8.fc12.x86_64 spacechart-0:0.9.5-5.fc12.x86_64 swami-0:0.9.4-6.fc12.x86_64 xdialog-0:2.3.1-5.fc12.x86_64 xarchon-0:0.50-10.fc12.x86_64 xconvers-0:0.8.3-7.fc12.x86_64 xvattr-0:1.3-17.x86_64 packages in rpmfusion gsview-0:4.9-2.fc12.x86_64 lame-mp3x-0:3.98.3-1.fc12.x86_64 smpeg-0:0.4.5-0.3.fc11.x86_64 Replace by gtk2 gtk+-1:1.2.10-69.fc12.x86_64 gtk+-devel-1:1.2.10-69.fc12.x86_64 Replaced by gnome2 gdk-pixbuf-1:0.22.0-38.fc12.x86_64 gnome-libs-1:1.4.2-15.fc12.x86_64 imlib-1:1.9.15-12.fc12.x86_64 libglade-1:0.17-24.fc12.x86_64 Replaced by gmanedit manedit-0:1.2.1-3.fc12.x86_64 Replaced by xmms2 logjam-xmms-1:4.5.3-36.fc12.x86_64 logjam-xmms-1:4.5.3-37.fc12.x86_64 purple-plugin_pack-pidgin-xmms-0:2.4.0-4.fc12.x86_64 xmms-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-acme-0:0.4.3-11.x86_64 xmms-adplug-0:1.2-9.fc12.x86_64 xmms-alarm-0:0.3.7-10.fc12.x86_64 xmmsctrl-0:1.8-6.fc12.x86_64 xmms-esd-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-faad2-1:2.7-1.fc11.x86_64 xmms-flac-0:1.1.4-6.fc12.x86_64 xmms-flac-0:1.2.1-1.fc12.x86_64 xmms-libs-1:1.2.11-9.20071117cvs.fc12.x86_64 xmms-lirc-0:1.4-14.x86_64 xmms-mp3-0:1.2.11-3.20071117cvs.fc11.x86_64 xmms-mplayer-0:0.5-2.fc11.x86_64 xmms-musepack-0:1.2-8.fc12.x86_64 xmms-normalize-0:0.7.7-5.fc11.x86_64 xmms-pulse-0:0.9.4-8.fc12.x86_64 xmms-sid-0:0.8.0-0.8.beta19.fc12.x86_64 xmms-speex-0:0.9.1-15.x86_64 xmms-uade-0:2.09-5.fc11.x86_64 xmms-xmp-0:2.7.1-1.fc12.x86_64 xmms-xmp-0:3.1.0-1.fc12.x86_64 xmms-xosd-0:2.2.14-13.fc12.x86_64 Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/09/2010 06:09 AM, Adam Williamson wrote: I'm tempted to agree in practice with Matej that it is. I don't think we can kid ourselves that we're doing a particularly good job of making a desktop for end users; if we were, we wouldn't be being trashed by Ubuntu in this area (let alone OS X and Windows). Yes, yes, I know, Ubuntu's statistics are unreliable and all that crap. I know we can all I am inclined to agree too - we are a ** technical distro ** and a good one at that. There is a balance between really up to date and yet still stable ... fedora (tho it struggles now and again) has managed to largely find that balance. Congrats fedora team!! I run several servers on fedora (mail, web, file and a couple of very decent firewalls) in addition to a suite of desktop and laptops running fedora. Some of the desktops are used by some highly non-sophisticated users (parents, parents in-law, spouse, children, friends for example). I think what makes these Aunt Tilly users work well using Fedora, is the presence of one or more experienced fedora admins behind the scenes - who can manage their systems and provide the expertise to add the missing pieces to make the system just-works for them - and act as help desk once in a while too! (Some support of course we did even when they ran windows ... ) That said, the amount of admin'ing (I include performaing remote backups over ssh) is generally not too much work - it does include the occasional vnc-over-ssh to 'fix a window' problem too ;-) Fedora has not (wont?) license H.264 like ubuntu ... All my users (quite a few) absolutely rest on my opinion/expertise to make the decisions for them and help them add functionality when needed. Fedora is a great distro - we do reach Aunt Tilly too - just not by her installing F12 herself ... we do it for her. Fedora is a strong technical distro - Linus may even be using it ;-) and it serves technical users/admins extremely well. Fedora is ** The Technical Distro ** gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I see that we're calling killall -TERM instead of killall -HUP in the patch. That seems non-optimal (since it means we'll keep shutting down the gconfd server instead of letting it use it's 30second timeout) That's definitely suboptimal because we'll lose the caches etc. from the running process. Anyone know why we haven't seen progress on the upstream bug? No one's raised any philosophical blockers with doing this: http://bugzilla.gnome.org/show_bug.cgi?id=328697 I commented there. Colin, if no one's looking into fixing this bug there's two ways to workaround this bug: Change macros.gconf2 to run killall after the schemas are installed or uninstalled. This requires an update of the GConf2 package. We don't know which Fedora versions this affects yet (the guake update was for F13) killall -TERM? Restore the packaging guideline suggestion to run killall -HUP gconfd-2 Since we don't know which versions this affects, we'd need to recommend it on all Fedora releases. I don't think that helps - the original problem report was failure on initial install + run, which I believe must be a result of the 30 second delay in gconfd from SIGHUP. What do you think about my comment here? https://bugzilla.gnome.org/show_bug.cgi?id=328697#c9 If we can't get the changes to RPM made to do it once post-transaction, then I suggest we simply bite the bullet and remove the 30 second timeout from gconfd until such time as the RPM change can be made. I'll take slower without race conditions over faster but racy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 yum in kvm or vmware guests
06.05.2010 01:40, Warren Togami ?: (10/12): samba-3.5.2-60.fc13.x86_64.rpm (71%) 73% [- ] 0.0 B/s | 3.7 MB 3340883129410265958989882401668816722716705737932:48 ETA Anyone else seeing this kind of behavior with F-13 yum within kvm or vmware guests? It seems to happen consistently here in the middle of downloading multiple packages where I need to kill yum and try again. Warren I saw this on real machine and bug was filled: https://bugzilla.redhat.com/show_bug.cgi?id=575743 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
Frank Murphy wrote: That *should not* be default for most users, as it will end up breaking quite a lot, if used with other repos. (updates,updates-tesing, 3rd party) as %requires may have changed quite a bit since DVD was released. That shouldn't be a problem as long as updates is enabled. A more pertinent reason not to enable this by default is that many users will misplace the DVD and prefer just downloading the packages. Many of them have updates anyway. And to really suit users with no or a very slow Internet connection, we'd also have to disable updates by default which we definitely DO NOT want. As I've already said more than once, IMHO we should just add broadband Internet connection to Fedora's system requirements, it's effectively already required. Sure, you can get it to work without it with some manual workarounds, but for Fedora to work properly out of the box, and to get updates (including security fixes, critical bugfixes etc.), you need a (reasonably fast) Internet connection. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
Jaroslav Reznik wrote: I think it would be better to drop ntp support completely from s-c-d once chrony becomes default in Fedora. We aim to support default Fedora configuration tools. Radek Novacek is now working on date/time DBus interface under FMCI umbrella. Speaking of configuration tools, we also need to have a look at KDE's date/time dialog. Currently, there is an option to enable NTP support, but 1. it doesn't notice that it's already enabled by system-config-date or Anaconda :-(, 2. it's quite lacking in options (you can only enable/disable it and pick one server (not even a list of servers), no other options), and 3. it obviously doesn't support Chrony at this time. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
Mail Lists wrote: The prime motivation of this project is a use case of intermittent internet connections of 5 mins a day. I seriously doubt that is the common use case for majority of fedora users. I think intermittent Internet connections are actually extremely common. Think laptops/notebooks/netbooks. For frequent travelers, even only 5 mins/day of Internet access might be a realistic estimate, though a bit extreme. But ntpd is already a FAIL with much more uptime than that. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, 2010-05-09 at 11:09 +0100, Adam Williamson wrote: I'm tempted to agree in practice with Matej that it is. I don't think we can kid ourselves that we're doing a particularly good job of making a desktop for end users; if we were, we wouldn't be being trashed by Ubuntu in this area (let alone OS X and Windows). Yes, yes, I know, Ubuntu's statistics are unreliable and all that crap. I know we can all rationalize for ten hours about how it's all Microsoft's fault for being evil and Ubuntu's fault for being good at marketing and users' fault for being stupid and blah de freaking blah. But be practical. When you go to $RANDOM_LINUX_CONFERENCE (never mind when you go to the coffee shop, I have never seen anyone else running Fedora in any situation outside of the 'Linux world'), how many people are running Fedora and how many are running Ubuntu? Have you noticed how, whenever _any_ third party site posts reader statistics, the first thing you see is that Linux is tiny, and the second thing you see is that a heavy pluarality of the Linux numbers are Ubuntu? Example: Distrowatch prints user agent stats, not just page hit rankings. http://distrowatch.com/awstats/awstats.DistroWatch.com.osdetail.html . Ubuntu is at 16.5%. Fedora is at 1.3%, on which number we are being beaten by OpenSUSE and PCLinuxOS (and being trounced by Linux Mint, a shoestring budgeted Ubuntu derivative), and just outpacing Debian and Mandriva. Yep, a grand 1.3% of the people who visit a general-purpose Linux news site are running Fedora when they do it. Please, _please_, do not attempt to rationalize or excuse or except these numbers; they're just an example (I know some people will, despite this explicit request; I intend to entirely ignore them). Every site I've ever seen print its user agent stats tells a similar story. Does anyone actually want to claim that this kind of thing is a stunning success story for Fedora as a general purpose desktop operating system? Those numbers aren't lying. I think this discussion should always be informed by the fundamental understanding that, if we're talking about making an attractive general-purpose operating system for end users, we're currently fairly shit at it. We're not a shit project, we do a lot of valuable work that needs to be done, and produce products that are great in certain ways. But we should either get a better understanding of what we are actually good at and valuable for and work on those things, or if we're serious about being an end-user desktop, get a lot better at it. Which would probably involve doing some things a lot of members of the project would be unhappy with. Frankly, I don't think this project is currently laid out in such a way that doing that would be very practical; it's very difficult to engender radical change in Fedora as a project. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net I fully agree with every single word. (I would imagine that I'm not alone) ... But I'm not sure that FESCo shares your opinion - far from it. This leaves us in a very precarious position: One on hand, if FESCo keeps changing Fedora into hybrid-semi-community-driven-Ubuntu, they risk losing many technical users/small maintainers such as myself, read: People who prefer Fedora over Ubuntu -because- it is technical, bleeding edge and community driven. On the other hand, if FESCo keeps the uneasy 'statu quo' without any real definition of what Fedora is really about, neither the technical group nor the I-want-to-be-Ubuntu group (let alone the I want to be RHEL/CentOS group) will be happy, and in the end, Fedora will continue losing both developers and users. If we, as a -community- project, want to remain relevant, it is time to decide who we are and what is our goal. Thus far, it seemed that the both the user and the developer communities were left out of these proceedings, and everything was more-or-less decided by FESCO, which left (large?) parts of the developer community feeling left out. Far worse, many attempts to try and openly discuss these issues ended up being shot down by the hall monitors. As I recall, you've polled FedoraForum users about their view of Fedora a couple of months ago and as far as I know, there results were more-or-less ignored. Maybe its time to repeat this poll (I'd extent it to both FAS users and FedoraForum users. This should cover both the developer and the hard-core user communities), but this time with FESCO blessing. - Gilboa Hopefully this discussion won't be ignored Davara -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Wed, May 5, 2010 at 7:35 AM, Miroslav Lichvar mlich...@redhat.com wrote: With the latest improvements in the chrony package related to NetworkManager and name resolving I think it is now good enough to replace ntpd in the default configuration and the configurations supported by system-config-date. Hi Miroslav, lets go over a couple of things to help lower the grumpiness of others. 1) Who are you? 2) What is your position in regards to knowing ntpd and/or chrony in stability and other things? I think most people do not know who maintains ntpd, and do not know if this is a Oh wow I just found this really great software program and we should change to it right away kind of email. I'm proposing to add a support for chrony to system-config-date and change the dependency. As chrony supports only a subset of the NTP protocol and misses many of the ntpd features, users will have to install the ntp package manually if they have a specific requirement or need to use a more complicated configuration. Ok time is one of those touchstone security tools that people get all kinds of crazy about when things get changed. Here are a couple of questions that might help: 1) Why chrony? Why not OpenNTPD [fill in the blank here] 2) Where is the data that chrony actually controls the clock better? 3) How far have you/others tested it in comparison with ntpd? 4) A release plan should probably look like the following: Fedora-14 we add chrony into alternatives or other commands needed to get it to work. System-config-date has pathways to configure one or the other when it is seen. Test days and reviews are done to see how it is going. Organize a short-term sig and get Mo to make a design for shirts (melting clocks sounds a good idea). People who test, find bugs, etc etc qualify for a drawing of stuff. Fedora-15 from feedback we have gotten on chrony, we go through the plan of making chrony default (or not) and make ntpd optional. This is one alternative plan ( a bit slow but for security related things probably better.). To speed it up we need to move get people motivated towards 12/13 testing and feedback. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On 05/09/2010 01:45 PM, Stephen John Smoogen wrote: lets go over a couple of things to help lower the grumpiness of others. A good summary which shows care and thoughtfulness - please add also the question: 4) For servers (distinct from the desktop use case) - which would be the better choice (and why with supporting data). Thank you for the thoughtful post SJS. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sun, May 09, 2010 at 11:56:27AM -0400, Colin Walters wrote: On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I see that we're calling killall -TERM instead of killall -HUP in the patch. That seems non-optimal (since it means we'll keep shutting down the gconfd server instead of letting it use it's 30second timeout) That's definitely suboptimal because we'll lose the caches etc. from the running process. Anyone know why we haven't seen progress on the upstream bug? No one's raised any philosophical blockers with doing this: http://bugzilla.gnome.org/show_bug.cgi?id=328697 I commented there. Colin, if no one's looking into fixing this bug there's two ways to workaround this bug: Change macros.gconf2 to run killall after the schemas are installed or uninstalled. This requires an update of the GConf2 package. We don't know which Fedora versions this affects yet (the guake update was for F13) killall -TERM? killall -HUP Restore the packaging guideline suggestion to run killall -HUP gconfd-2 Since we don't know which versions this affects, we'd need to recommend it on all Fedora releases. I don't think that helps - the original problem report was failure on initial install + run, which I believe must be a result of the 30 second delay in gconfd from SIGHUP. I'm a bit unclear on the original problem report, actually. In addition to what you've said, the report also says that the user had to logout and log back in before it worked. That seems like a different symptom. 30 seconds is not that long so I would expect that just starting application from the menu, reading failure message, trying to start the application from menu a second time would be enough time... Also, I'm unclear if simply adding killall -HUP to the guake scriptlets fixed the problem (or if something else about the install transactions were different). If that's all it took, then that also points at something other than the 30 second timeout being the issue. Are we able to reproduce the original reporter's issue? What do you think about my comment here? https://bugzilla.gnome.org/show_bug.cgi?id=328697#c9 If we can't get the changes to RPM made to do it once post-transaction, then I suggest we simply bite the bullet and remove the 30 second timeout from gconfd until such time as the RPM change can be made. I'll take slower without race conditions over faster but racy. Note: %posttransaction would allow us to group all of the SIGHUPs in a closer timespan (we'd run all of the sighups [and other posttransactions] at the end of the rpm transaction). So perhaps having:: gconftool-2 --makefile-(un)install-rule --delay-sighup=$SECONDS in the general case would work. We could specify delay-sighup as 5 seconds or so in the gconf macros. I also realized that in the unlikely case that something is run in a %post transaction needs to use something that was installed, we'd need to sighup gconf in %post with no delay... that'll be tricky since the sighup should really go in the package providing the tool but we will get the problem reports in the package depending on the tool. On the speed front: 1) Using %posttransaction even without the delay could be faster due to fs caching -- we won't have clobbered that by doing a few package installs between gconf sighups. 2) The new gconf macros are more intelligent than the old scripts -- they don't run if the schemas are unchanged. That might take some of the sting out of gconf reloading schemas more frequently again. 3) mclasen performed some optimization of gconf itself recently... I don't know precisely how that affects the original rationale for the delay. You'll need to flag down panu or ffesti to see if 'do-this-action-once' is something they're planning for an upcoming rpm release (and we'll still have to document in guidelines what to do until then). -Toshio pgpCScajJJ99C.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
/*Kevin Kofler kevin.kof...@chello.at*/ wrote on 05/09/2010 9:24:04 PM +0450: Frank Murphy wrote: That *should not* be default for most users, as it will end up breaking quite a lot, if used with other repos. (updates,updates-tesing, 3rd party) as %requires may have changed quite a bit since DVD was released. That shouldn't be a problem as long as updates is enabled. A more pertinent reason not to enable this by default is that many users will misplace the DVD and prefer just downloading the packages. Many of them have updates anyway. For those users, they will receive updated packages from the internet if there are any updates. And if there isn't any, yes the packages will be installed from DVD. But this doesn't seem to be much inconvenience, and also will be the natural thing to happen IMHO. I think the reasons for having this enabled by default (while I've never talked about having it enabled by default; being able to enable it using the software sources selection is much much more convenient than the current workarounds) are more acceptable. Anyway, I've never talked about having them enabled by default. And to really suit users with no or a very slow Internet connection, we'd also have to disable updates by default which we definitely DO NOT want. No. It would suffice if PackageKit disables/discards online repositories when there is no network connection and enables them otherwise. Interestingly, the latest packagekit in Fedora 13 disables online repositories (and print errors) if their connection time out (and so it is still usable), but will print errors and stops working if system is offline! (it should do the same thing when offline). So, you can have the online repositories enabled by default and suit such users at the same time. As I've already said more than once, IMHO we should just add broadband Internet connection to Fedora's system requirements, it's effectively already required. Sure, you can get it to work without it with some manual workarounds, but for Fedora to work properly out of the box, and to get updates (including security fixes, critical bugfixes etc.), you need a (reasonably fast) Internet connection. 1. Such manual workarounds can be fixed pretty easy; and IMHO they should be fixed anyways. Everybody might sometimes be offline, and should be able to work reasonably in that cases too (e.g. it is really ridiculous to be unable to remove a package from your system when you are offline because yum/packagekit cannot update repository metadata!). Also I think the ability to install packages from installation media (and any removable media containing a repository) is still reasonable too (you can get updates as soon as you are online again). 2. Almost all modern OSes provide updates, so do you want to say that a user with no or poor internet connection should not use them?!! Also notice that most of security fixes are not that important for such users anyway! Also, Fedora is not the only Linux distribution who have such online repositories; Debian has had them even at the times which broadband internet connection was not so common (and this is IMHO why its package manager treats such users much better). Thanks, Hedayat Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
sön 2010-05-09 klockan 11:22 +0430 skrev Hedayat Vatankhah: No, the problem is this: PackageKit does not know how to mount a removable media. Why do you even need to mount it? Removable media is of course automatically mounted when you insert it (if someone is logged in on the console). /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sun, 2010-05-09 at 14:04 -0400, Toshio Kuratomi wrote: I'm a bit unclear on the original problem report, actually. In addition to what you've said, the report also says that the user had to logout and log back in before it worked. That seems like a different symptom. 30 seconds is not that long so I would expect that just starting application from the menu, reading failure message, trying to start the application from menu a second time would be enough time... Also, I'm unclear if simply adding killall -HUP to the guake scriptlets fixed the problem (or if something else about the install transactions were different). If that's all it took, then that also points at something other than the 30 second timeout being the issue. Are we able to reproduce the original reporter's issue? I have been able to reproduce it only once, yesterday when I reinstall my F-13. From all my machine it's the only time I could reproduce it. And then, I waiting sometime doing a ls .gconf/apps and I saw the guake folder appearing. I think the restart of X solves the problem indeed since I take usually more than 30sec to log out, log in and retry to start the application. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
sön 2010-05-09 klockan 18:54 +0200 skrev Kevin Kofler: Many of them have updates anyway. Use delta-RPMs (combining not the installed old version but the old version on the DVD with the downloaded drpm). /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 yum in kvm or vmware guests
/*Seth Vidal skvi...@fedoraproject.org*/ wrote on 05/06/2010 11:47:39 PM +0450: On Thu, 6 May 2010, Hedayat Vatnakhah wrote: Hi, Warren Togami war...@togami.com wrote on پنجشنبه ۰۶ مه ۱۰، ۰۲:۱۰:۴۸:On ۱۰/۰۵/۰۶ 02:10, Warren Togami wrote: (10/12): samba-3.5.2-60.fc13.x86_64.rpm (71%) 73% [- ] 0.0 B/s | 3.7 MB 3340883129410265958989882401668816722716705737932:48 ETA Anyone else seeing this kind of behavior with F-13 yum within kvm or vmware guests? It seems to happen consistently here in the middle of downloading multiple packages where I need to kill yum and try again. It is nothing new if you've tried using yum in a poor internet connection. I've seen it regularly in Fedora 12 and IIRC Fedora 11. Hedayat, take the python-urlgrabber pkg from rawhide 0 3.9.1-6.fc14 and give it a whirl. I installed the mentioned package and it seems that the problem is solved. The connection properly times out when the speed comes near zero. I'll let you know if I could reproduce the bug again. Good luck, Hedayat -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Sun, May 9, 2010 at 11:15 AM, Chen Lei wrote: swami-0:0.9.4-6.fc12.x86_64 This is the *only* soundfont editor there is in Linux, which is enough reason to keep gtk+. Upstream did not do any updates recently, but that doesn't mean that the software is not functional. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On ۱۰/۰۵/۰۹ 10:43, Alexander � wrote: sön 2010-05-09 klockan 11:22 +0430 skrev Hedayat Vatankhah: No, the problem is this: PackageKit does not know how to mount a removable media. Why do you even need to mount it? Removable media is of course automatically mounted when you insert it (if someone is logged in on the console). You can see comments 25 till end. I've proposed it once, but ... . I'll try again! But I'm just thinking if the problem with DeviceKit is not really a bug: a process running as root is able to mount something using the mount system call or just by calling the system's mount command, so why should it be unable to do so using DeviceKit?! I wonder if it is reasonable! Thanks, Hedayat /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On Sun, 2010-05-09 at 20:13 +0200, Alexander Boström wrote: sön 2010-05-09 klockan 11:22 +0430 skrev Hedayat Vatankhah: No, the problem is this: PackageKit does not know how to mount a removable media. Why do you even need to mount it? Removable media is of course automatically mounted when you insert it (if someone is logged in on the console). That's a nautilus behavior, controlled by the gconf keys: /apps/nautilus/preferences/media_automount /apps/nautilus/preferences/media_automount_open Either one is enough to cause automounting. Both are enabled by default, and only the second can be disabled through the UI, so it's unlikely that a beginning user would have automounting disabled unless the sysadmin did it for him/her. Assuming nautilus automounting is enabled, would that be enough for PackageKit to work properly or is there some other issue? It would still be nice not to make that assumption. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 09, 2010 at 20:34:57 +0300, Gilboa Davara gilb...@gmail.com wrote: Thus far, it seemed that the both the user and the developer communities were left out of these proceedings, and everything was more-or-less decided by FESCO, which left (large?) parts of the developer community feeling left out. The board has been trying to answer questions related to this (who is Fedora for). And I think they recently completed that task. I think the next thing up would be to look at how well we are or aren't serving the people who Fedora is supposed to be for. A good starting point for this work is at: https://fedoraproject.org/wiki/Unfinished_Board_issues There is a board election coming up and it is a good time to ask prospective board members questions related to the future of Fedora. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 09, 2010 at 11:09:12 +0100, Adam Williamson awill...@redhat.com wrote: I'm tempted to agree in practice with Matej that it is. I don't think we can kid ourselves that we're doing a particularly good job of making a desktop for end users; if we were, we wouldn't be being trashed by Ubuntu in this area (let alone OS X and Windows). Yes, yes, I know, Ubuntu's statistics are unreliable and all that crap. I know we can all rationalize for ten hours about how it's all Microsoft's fault for being evil and Ubuntu's fault for being good at marketing and users' fault for being stupid and blah de freaking blah. I don't think Fedora is going to be able to outdo Ubuntu in the general population unless the practice of allowing software patents is stopped. (Or at least exceptions are granted to be compatible with standards or to interoperate with other systems.) Video support is another big issue that can't be fixed overnight. While some big strides have been made in the last year, there is a lot more work to do. Besides some needing polishing to make things work more generally, there is still a lot of performance work needed for modern (with shaders) video cards. This is an area where getting some more good people could really help Fedora. Despite Redhat already providing a lot of support here, I'd like to see them hire a couple of more good people here to speed up development as I think the impact on the usability of Fedora could be greatly helped by that effort. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC precompiled headers question
Hi,
On ۱۰/۰۵/۰۶ 03:34, Christoph � wrote:
Hi all,
this is an off topic question, but since I know that some of you are
familiar with gcc, I am asking it here before signing up somewhere else.
I have to source-compile one language (Modelica) to C++. Since Modelica
has a structural subtype system, I'd like to create classes that way:
//Modelica
class Foo
Real x;
end Foo;
//C++
templateFoo_Real class Foo {
Foo_Real x;
}
That means every generated class (and function for that matter) is
(parametric) polymorphic and can be reused in other compilation units
for subtypes. Unfortunately that also means, that I can only generate
headers and no libraries or object files. Basically g++ plays the role
of a linker for modelica. But this means that g++ will parse, check and
compile every header again and again even if it's clear (at least after
the first pass) that the code is sane.
I've learned that the C++ standard delivers the export keyword to
include template symbols in object files, but g++ does not support this.
The closest thing I've seen to export would be precompiled headers.
Unfortunately g++ also allows one single precompiled header per
compilation unit. Does anyone know why? And is there any way to speed up
the linking process a little (like letting g++ at least preprocess the
headers or something like this)?
Have a look at gcc info: C++ Extensions-Template Instanciation. You can
go with the first method: using -frepo but notice that it doesn't work
when ccache is enabled. So, you can export CCACHE_DISABLE=1 before
running gcc with -frepo option. Also, I think you can go with a solution
using export keyword too (the second method).
Good luck,
Hedayat
thanks for any comments,
Christoph
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 9, 2010 at 9:07 PM, Bruno Wolff III br...@wolff.to wrote: On Sun, May 09, 2010 at 20:34:57 +0300, Gilboa Davara gilb...@gmail.com wrote: Thus far, it seemed that the both the user and the developer communities were left out of these proceedings, and everything was more-or-less decided by FESCO, which left (large?) parts of the developer community feeling left out. The board has been trying to answer questions related to this (who is Fedora for). Which is wrong (not the outcome but the whole discussion itself), there is *NO* reason why an operating system which is easy to use is hard do develop on and vice versa. Both MS and Apple prove that this is wrong. Just hiding our failure to address both needs isn't really a great way forward. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/10/2010 12:37 AM, Bruno Wolff III wrote: On Sun, May 09, 2010 at 20:34:57 +0300, Gilboa Davara gilb...@gmail.com wrote: Thus far, it seemed that the both the user and the developer communities were left out of these proceedings, and everything was more-or-less decided by FESCO, which left (large?) parts of the developer community feeling left out. The board has been trying to answer questions related to this (who is Fedora for). And I think they recently completed that task. I think the next thing up would be to look at how well we are or aren't serving the people who Fedora is supposed to be for. They already have the results at http://fedoraproject.org/wiki/User_base Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 9, 2010 at 7:34 PM, Gilboa Davara gilb...@gmail.com wrote: If we, as a -community- project, want to remain relevant, it is time to decide who we are and what is our goal. Agreed. The who we are is easy answered, we're RHs *playground*. That is what everyone, not completely new to Linux, knows and one problem why we're at 1.3% as mentioned above. Something that other distros don't have to suffer from. And we're gladly acting like it, e.g. x-server not compatible with HW vendor drivers at release time (believe it or not, but users were angry about it). Bleeding edge stuff like PA as first, ready or not for the masses. One of the most frequented link in #fedora was/is http://fedorasolved.org/Members/fenris02/pulseaudio-fixes-and-workarounds Just two examples. No wonder we're at about 1.3% eh ;) -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, 9 May 2010, Gilboa Davara wrote: On Sun, 2010-05-09 at 14:07 -0500, Bruno Wolff III wrote: On Sun, May 09, 2010 at 20:34:57 +0300, Gilboa Davara gilb...@gmail.com wrote: Thus far, it seemed that the both the user and the developer communities were left out of these proceedings, and everything was more-or-less decided by FESCO, which left (large?) parts of the developer community feeling left out. The board has been trying to answer questions related to this (who is Fedora for). And I think they recently completed that task. I think the next thing up would be to look at how well we are or aren't serving the people who Fedora is supposed to be for. A good starting point for this work is at: https://fedoraproject.org/wiki/Unfinished_Board_issues There is a board election coming up and it is a good time to ask prospective board members questions related to the future of Fedora. I believe you missed my point. I don't claim that the board ignored this issue. Far from it. I am claiming that having the board make this decision without the involving of the community is slowly (?) driving both developers and users away. Since we had no focus before, everyone who had any interest in anything joined Fedora. Now that they're here they have conflicting views on what Fedora should be. If you think we should vote, go join debian. I think they do that there. In the meantime our community is suffering far more infighting then before because everyone thinks their version is the right version. As we narrow our focus, people are going to find they fall outside of that focus. Bottom line is we should have done what we're doing now long ago, so we're suffering the consequences as a result. Lots of people with conflicting views are now here. Our lack of focus has just hurt us. Have you used OSX lately? They're playing in a whole different league and a whole different game then we are. It's not even a comparison. Not only do we copy OSX but we do so poorly. For those that have problem with apple or want a more free OS, Ubuntu's got the share. We're just not there. Fedora's board isn't driving users and developers away, our OS is. The worst part is we won't get those users back with a marginally better product. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
[Well, sorry for posting again to this subthread, but this particular post has nothing whatsoever to do with hall monitoring. (Time for another new subthread?)] Thomas Janssen wrote: And we're gladly acting like it, e.g. x-server not compatible with HW vendor drivers at release time (believe it or not, but users were angry about it). We do this because this allows providing the newest Free drivers, the ones which we can ship out of the box, which we are comfortable with our users using, which are the way to go in the long run, which we can fix if there are bugs and which just generally tend to work better. We were the first mainstream distribution providing Free 3D support for ATI Radeon HD cards of the r6xx and r7xx chipset series (see Fedora 12). We are now (with Fedora 13) about to be the first mainstream distribution providing Free 3D support for NVidia hardware. I really don't want this to stop, nor to lose all the other benefits of the current X.Org X11 release, just to be compatible with crappy proprietary drivers which can't keep up with technology. Instead, we need to make those drivers obsolete, which we're already well on the way to. Just say NO to proprietary drivers! We do not and should never support proprietary drivers. Please NEVER withhold a new version of X.Org X11 just because proprietary drivers don't support it! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Request Followup
Hello Earlier I posted a request to see if anyone was willing to review a proposed new RPM. I forgot to mention that I would be willing to exchange the review with someone needing help geting their project reviewed. Mark Rader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC precompiled headers question
Am Sonntag, den 09.05.2010, 04:25 +0200 schrieb Kevin Kofler: Christoph Höger wrote: Unfortunately g++ also allows one single precompiled header per compilation unit. Does anyone know why? Because a g++ precompiled header is more or less a dump of the complete compiler state, which is loaded and from which compilation continues. Obviously this can only work for a single header included before any non- comment non-whitespace line. Ah, nice to know. Thanks. And is there any way to speed up the linking process a little (like letting g++ at least preprocess the headers or something like this)? Create a header like all.h which includes all the headers you actually want to include and precompile that one. Yeah. Nice Idea, but creating n! headers is not very ... scalable. And of course clients are not going to use only one single library. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Sun, May 09, 2010 at 10:17:39PM +0800, Chen Lei wrote: Most of those applications are replaced, e.g. xmms2 for xmms, putty(svn) for putty 0.60, since it's already done by some other distributions, I think it's quite safe to retire gtk 1.2 completely from fedora. That's not a good argument. Fedora packager may have other need and wants than other distribution packagers. Also, considering fedora is a bleeding-edge distribution, keeping some many old applications with dead upstream for a long time seems strange. If they work well and there is no known bugs, it is not strange to keep old applications with dead upstream. As long as there is a maintainer who fixes bug in due time, it is, in my opinion, good for Fedora to keep packages with dead upstreams. Now I agree that it would be better if no application in fedora used libraries with dead upstreams that have replacements, as it is the case for gtk+. I think that it is the path you should follow: help all the maintainers of packages depending on gtk+ to transition to a newer widget library. Or persuade them to let another package obsolete their package. However, if some packagers are still convinced that their package is worth maintaining (and they do it right) and upstream is not willing to switch to Gtk2, I think that the best course of action is to keep those packages in Fedora. For the applications I know some comments * I am quite sure that gmanedit is not a manedit evolution. However, manedit is orphaned right now (though still not purged). * xdialog is build twice, once agains gtk+ and then against Gtk2. I think it would be nice to keep it that way, though you could also convince the current maintainer to keep only the Gtk2 stuff. also xdialog seems to be pretty dead upstream too, though I still haven't seen a perfect substitute (zenity is close, but not compatible). There are no open bugs against gtk+ which is, in my opinion in favor of keeping it. One point against gtk+ is the lack of utf8 support. I don't know if there are other noteworthy differences. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, 2010-05-09 at 22:11 +0200, Thomas Janssen wrote: On Sun, May 9, 2010 at 7:34 PM, Gilboa Davara gilb...@gmail.com wrote: If we, as a -community- project, want to remain relevant, it is time to decide who we are and what is our goal. Agreed. The who we are is easy answered, we're RHs *playground*. That is what everyone, not completely new to Linux, knows and one problem why we're at 1.3% as mentioned above. Something that other distros don't have to suffer from. And we're gladly acting like it, e.g. x-server not compatible with HW vendor drivers at release time (believe it or not, but users were angry about it). Bleeding edge stuff like PA as first, ready or not for the masses. One of the most frequented link in #fedora was/is http://fedorasolved.org/Members/fenris02/pulseaudio-fixes-and-workarounds Just two examples. No wonder we're at about 1.3% eh ;) I don't agree with that, entirely. Think about it - Red Hat sells big enterprise stuff. Mostly servers. Directly, PA and bleeding edge X stuff isn't of huge immediate interest to RH. I mean, of course RH is going to pay people to work on stuff it thinks will ultimately benefit it, but it does take a rather broad and long view of this (think how long it's taken for PA to even be in RHEL at all). But we are a _general_ 'playground' (or rather sandbox), for the development of interesting and useful bits of technology. I think you can look at Fedora almost as a concept car; we're developing technologies that will be useful in the consumer car of the future, but we're _not_ that car, in a practical sense. We have all the rough edges and bits that won't be practical in the end. As Kevin says in his reply, I think doing stuff like the above - PA, X devleopment - is a strength of Fedora. It's one of the things we do well, and for which we're valuable. But it doesn't necessarily make for the best end-user general purpose operating system for the present moment in time; we're blazing a trail ahead. -- 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: Reasons for hall monitoring
On 05/10/2010 02:10 AM, Kevin Kofler wrote: We do not and should never support proprietary drivers. Please NEVER withhold a new version of X.Org X11 just because proprietary drivers don't support it! It might not be obvious but doing so is very counter productive even for those users wanting to use proprietary drivers. Nvidia doesn't update their driver everytime there is a new Xorg release. They wait for a major distribution to include it first. If Fedora waits for Nvidia, we will have a chicken and egg situation. Among distribution vendors, Red Hat is by far the leading contributor to Xorg and Fedora benefits very much from the expertise by getting many new features first. It would be silly to throw away that benefit in favour of proprietary driver support. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 9, 2010 at 11:20 PM, Rahul Sundaram methe...@gmail.com wrote: On 05/10/2010 02:10 AM, Kevin Kofler wrote: We do not and should never support proprietary drivers. Please NEVER withhold a new version of X.Org X11 just because proprietary drivers don't support it! It might not be obvious but doing so is very counter productive even for those users wanting to use proprietary drivers. Nvidia doesn't update their driver everytime there is a new Xorg release. They wait for a major distribution to include it first. Not that I disagree with your post (or Kevin's) but this is (no longer) true, NVIDIA does (try) to follow xserver releases. AMD is not; they have a selected list of distributions that they support, Fedora is *not* one of them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, 10 May 2010, Rahul Sundaram wrote: On 05/10/2010 02:10 AM, Kevin Kofler wrote: We do not and should never support proprietary drivers. Please NEVER withhold a new version of X.Org X11 just because proprietary drivers don't support it! It might not be obvious but doing so is very counter productive even for those users wanting to use proprietary drivers. Nvidia doesn't update their driver everytime there is a new Xorg release. They wait for a major distribution to include it first. If Fedora waits for Nvidia, we will have a chicken and egg situation. Among distribution vendors, Red Hat is by far the leading contributor to Xorg and Fedora benefits very much from the expertise by getting many new features first. It would be silly to throw away that benefit in favour of proprietary driver support. A suggestion for this thread: This thread is not about hall monitoring, nor is it about fedora development. It is a meta-issue and would probably be best on the Fedora Advisory Board mailing list than here. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC precompiled headers question
On Sun, 2010-05-09 at 04:25 +0200, Kevin Kofler wrote: Christoph Höger wrote: Unfortunately g++ also allows one single precompiled header per compilation unit. Does anyone know why? Because a g++ precompiled header is more or less a dump of the complete compiler state, which is loaded and from which compilation continues. Obviously this can only work for a single header included before any non- comment non-whitespace line. That's not quite right. There can be macro definitions as long as none of the macros are tested in #if/#ifdef directives that went into the precompiled header. There are some more details in the info docs. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, May 09, 2010 at 10:16:45PM +0100, Adam Williamson wrote: I don't agree with that, entirely. Think about it - Red Hat sells big enterprise stuff. Mostly servers. Directly, PA and bleeding edge X stuff isn't of huge immediate interest to RH. I mean, of course RH is going to pay people to work on stuff it thinks will ultimately benefit it, but it does take a rather broad and long view of this (think how long it's taken for PA to even be in RHEL at all). But we are a _general_ 'playground' (or rather sandbox), for the development of interesting and useful bits of technology. I think you can look at Fedora almost as a Not so general. For example grub2 or upstart weren't really pushed. Or initng didn't got much support. There are also choices regarding how well the different desktops are taken into account when a feature is deemed to be integrated enough. My observation is that really new directions and most innovative integration, especially at the level of the basic operating system tasks (kernel, PA, X, policykit, devicekit...), but also for important technologies and applications (firefox, java...) is in general done by redhat people using redhat developped technology. I don't follow the Fedora development very closely anymore, but it seems to me that it was especially true in the past. When it is not an innovation lead by redhat people, it is quite the struggle to get it in -- though it remains possible. Please note that it is not at all a criticism of RedHat or Fedora, it is just my impression of how things work. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On 05/09/2010 10:03 AM, Andrea Musuruane wrote: On Sun, May 9, 2010 at 3:49 PM, Matěj Ceplmc...@redhat.com wrote: Dne 9.5.2010 06:53, Chen Lei napsal(a): For them, we can simply: 1. Simply orphan those application from repos which have dead upstream for a long time. Normally, those allipcations have better alternatives using GTK+ 2.x, we don't need worry about this. 2.Update applications to GTK 2.x port which was already done by upstream, and ping the maintainer to see if he is nonresponsive now. I think it would help anybody if you can provide a list of packages involved. qiv-0:2.0-11.fc12.x86_64 qiv specifically wants image format libraries (hello, ancient imlib), so I'm not sure gtk+1.0 is the specific need here. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Sun, May 9, 2010 at 5:59 PM, Jeff Garzik jgar...@pobox.com wrote: On 05/09/2010 10:03 AM, Andrea Musuruane wrote: On Sun, May 9, 2010 at 3:49 PM, Matěj Ceplmc...@redhat.com wrote: Dne 9.5.2010 06:53, Chen Lei napsal(a): For them, we can simply: 1. Simply orphan those application from repos which have dead upstream for a long time. Normally, those allipcations have better alternatives using GTK+ 2.x, we don't need worry about this. 2.Update applications to GTK 2.x port which was already done by upstream, and ping the maintainer to see if he is nonresponsive now. I think it would help anybody if you can provide a list of packages involved. qiv-0:2.0-11.fc12.x86_64 qiv specifically wants image format libraries (hello, ancient imlib), so I'm not sure gtk+1.0 is the specific need here. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel putty(svn) needs to be patched to not search for gtk+1.2 otherwise it fails spectacularly, even though it has an GTK+2 port. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Sun 9 May 2010 10:26:35 am Kevin Kofler wrote: Mail Lists wrote: The prime motivation of this project is a use case of intermittent internet connections of 5 mins a day. I seriously doubt that is the common use case for majority of fedora users. I think intermittent Internet connections are actually extremely common. Think laptops/notebooks/netbooks. For frequent travelers, even only 5 mins/day of Internet access might be a realistic estimate, though a bit extreme. But ntpd is already a FAIL with much more uptime than that. Here is how I see this: The user installs their system for the first time, they set their clock using NTP while they have the connection to the internet when they installed their packageset/updates. Now they have an accurate clock. How much drift can happen that each and every time they connect to the internet, even if it's only for five minutes, would they need to resync their clock? I have NTP disabled altogether on this machine, and since I've installed it, it's still within about 5 seconds of my mother's Windows machine which _does_ have ntp disabled. I find that having NTP enabled in most cases for mobile systems is simply unnecessary; there is a large (I would say upwards of 95% in my most unscientific guessings) chance that these users aren't going to be doing anything which requires their clocks to be synced with any amount of precision. And if they are, they should _know_ that and be able to set up a tool (whether it is NTP or Crony) themselves. Imo the use cases for having a constantly synced-to-the-second clock are minimal at best. Kevin Kofler Ryan All the clocks on my desktop are KDE Plasma's Fuzzy Clock applet with about 10 minute precision so who am I to talk? Rix -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
EC1261 - Huawai modem
USB-MODEM from Huawei (Model: Huawei EC1261 ) does not work with fedora-12 (kernel 2.6.32.11-.fc12.i686.PAE) However an older version (Model: Huawei EC1260) works on the same kernel. The following are the output of /var/log/messages when the respective devices are connected DOES NOT WORK (Newer device) May 10 07:46:02 laptop kernel: usb 6-2: USB disconnect, address 2 May 10 07:46:10 laptop kernel: usb 6-1: new full speed USB device using uhci_hcd and address 3 May 10 07:46:11 laptop kernel: usb 6-1: New USB device found, idVendor=12d1, idProduct=1446 May 10 07:46:11 laptop kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 May 10 07:46:11 laptop kernel: usb 6-1: Product: HUAWEI Mobile May 10 07:46:11 laptop kernel: usb 6-1: Manufacturer: HUAÿWEI TECHNOLOGIES May 10 07:46:11 laptop kernel: usb 6-1: SerialNumber: ÿÿÿ May 10 07:46:11 laptop kernel: usb 6-1: configuration #1 chosen from 1 choice May 10 07:46:11 laptop kernel: scsi8 : SCSI emulation for USB Mass Storage devices May 10 07:46:13 laptop kernel: btusb_intr_complete: hci0 urb eae5d780 failed to resubmit (1) May 10 07:46:13 laptop kernel: btusb_bulk_complete: hci0 urb eae5da00 failed to resubmit (1) May 10 07:46:13 laptop kernel: btusb_bulk_complete: hci0 urb eae5dc80 failed to resubmit (1) May 10 07:46:16 laptop kernel: scsi 8:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 0 May 10 07:46:16 laptop kernel: sr0: scsi-1 drive May 10 07:46:16 laptop kernel: sr 8:0:0:0: Attached scsi generic sg1 type 5 WORKS (older device) May 4 20:18:25 prasad kernel: usb 6-2: new full speed USB device using uhci_hcd and address 33 May 4 20:18:25 prasad kernel: usb 6-2: New USB device found, idVendor=12d1, idProduct=140b May 4 20:18:25 prasad kernel: usb 6-2: New USB device strings: Mfr=1,Product=2, SerialNumber=4 May 4 20:18:25 prasad kernel: usb 6-2: Product: HUAWEI Mobile May 4 20:18:25 prasad kernel: usb 6-2: Manufacturer: HUAÿWEI TECHNOLOGIES May 4 20:18:25 prasad kernel: usb 6-2: SerialNumber: ÿÿÿ May 4 20:18:25 prasad kernel: usb 6-2: configuration #1 chosen from 1 choice May 4 20:18:25 prasad kernel: option 6-2:1.0: GSM modem (1-port) converter detected May 4 20:18:25 prasad kernel: usb 6-2: GSM modem (1-port) converter now attached to ttyUSB0 May 4 20:18:25 prasad kernel: option 6-2:1.1: GSM modem (1-port) converter detected May 4 20:18:25 prasad kernel: usb 6-2: GSM modem (1-port) converter now attached to ttyUSB1 May 4 20:18:25 prasad kernel: option 6-2:1.2: GSM modem (1-port) converter detected May 4 20:18:25 prasad kernel: usb 6-2: GSM modem (1-port) converter now attached to ttyUSB2 May 4 20:18:25 prasad kernel: scsi106 : SCSI emulation for USB Mass Storage devices -- Work while you are alive, you can rest later -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
EC1261 - Huawai modem
USB-MODEM from Huawei (Model: Huawei EC1261 ) does not work with fedora-12 (kernel 2.6.32.11-.fc12.i686.PAE) However an older version (Model: Huawei EC1260) works on the same kernel. The following are the output of /var/log/messages when the respective devices are connected DOES NOT WORK (Newer device) May 10 07:46:02 laptop kernel: usb 6-2: USB disconnect, address 2 May 10 07:46:10 laptop kernel: usb 6-1: new full speed USB device using uhci_hcd and address 3 May 10 07:46:11 laptop kernel: usb 6-1: New USB device found, idVendor=12d1, idProduct=1446 May 10 07:46:11 laptop kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 May 10 07:46:11 laptop kernel: usb 6-1: Product: HUAWEI Mobile May 10 07:46:11 laptop kernel: usb 6-1: Manufacturer: HUAÿWEI TECHNOLOGIES May 10 07:46:11 laptop kernel: usb 6-1: SerialNumber: ÿÿÿ May 10 07:46:11 laptop kernel: usb 6-1: configuration #1 chosen from 1 choice May 10 07:46:11 laptop kernel: scsi8 : SCSI emulation for USB Mass Storage devices May 10 07:46:13 laptop kernel: btusb_intr_complete: hci0 urb eae5d780 failed to resubmit (1) May 10 07:46:13 laptop kernel: btusb_bulk_complete: hci0 urb eae5da00 failed to resubmit (1) May 10 07:46:13 laptop kernel: btusb_bulk_complete: hci0 urb eae5dc80 failed to resubmit (1) May 10 07:46:16 laptop kernel: scsi 8:0:0:0: CD-ROMHUAWEI Mass Storage 2.31 PQ: 0 ANSI: 0 May 10 07:46:16 laptop kernel: sr0: scsi-1 drive May 10 07:46:16 laptop kernel: sr 8:0:0:0: Attached scsi generic sg1 type 5 WORKS (older device) May 4 20:18:25 prasad kernel: usb 6-2: new full speed USB device using uhci_hcd and address 33 May 4 20:18:25 prasad kernel: usb 6-2: New USB device found, idVendor=12d1, idProduct=140b May 4 20:18:25 prasad kernel: usb 6-2: New USB device strings: Mfr=1,Product=2, SerialNumber=4 May 4 20:18:25 prasad kernel: usb 6-2: Product: HUAWEI Mobile May 4 20:18:25 prasad kernel: usb 6-2: Manufacturer: HUAÿWEI TECHNOLOGIES May 4 20:18:25 prasad kernel: usb 6-2: SerialNumber: ÿÿÿ May 4 20:18:25 prasad kernel: usb 6-2: configuration #1 chosen from 1 choice May 4 20:18:25 prasad kernel: option 6-2:1.0: GSM modem (1-port) converter detected May 4 20:18:25 prasad kernel: usb 6-2: GSM modem (1-port) converter now attached to ttyUSB0 May 4 20:18:25 prasad kernel: option 6-2:1.1: GSM modem (1-port) converter detected May 4 20:18:25 prasad kernel: usb 6-2: GSM modem (1-port) converter now attached to ttyUSB1 May 4 20:18:25 prasad kernel: option 6-2:1.2: GSM modem (1-port) converter detected May 4 20:18:25 prasad kernel: usb 6-2: GSM modem (1-port) converter now attached to ttyUSB2 May 4 20:18:25 prasad kernel: scsi106 : SCSI emulation for USB Mass Storage devices -- Work while you are alive, you can rest later -- Work while you are alive, you can rest later -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/10 Orcan Ogetbil oget.fed...@gmail.com On Sun, May 9, 2010 at 11:15 AM, Chen Lei wrote: swami-0:0.9.4-6.fc12.x86_64 This is the *only* soundfont editor there is in Linux, which is enough reason to keep gtk+. Upstream did not do any updates recently, but that doesn't mean that the software is not functional. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel swami(svn) now use gtk2, don't worry about this, it has a quite active upstream. Retire gtk+ will encourage software developer to use new GTK2 toolkit and force package maitainers to update packages to the latest version which don't use gtk+ anymore. An alternative choice is move gtk+ to rpmfusion just like python 2.4. For putty(svn), I can sure it works quite well without any patch in F12, gentoo portage and debian sid now use svn putty. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/10 Patrice Dumas pertu...@free.fr For the applications I know some comments * I am quite sure that gmanedit is not a manedit evolution. However, manedit is orphaned right now (though still not purged). * xdialog is build twice, once agains gtk+ and then against Gtk2. I think it would be nice to keep it that way, though you could also convince the current maintainer to keep only the Gtk2 stuff. also xdialog seems to be pretty dead upstream too, though I still haven't seen a perfect substitute (zenity is close, but not compatible). There are no open bugs against gtk+ which is, in my opinion in favor of keeping it. One point against gtk+ is the lack of utf8 support. I don't know if there are other noteworthy differences. In my point of view, the only convincing reason to keep gtk+ 1.2 in fedora is if there are some widely-used gtk+ applications that don't have better alternatives with modern toolkit. As you mentioned, gtk+ is the lack of utf8 support, this is really bad for non-English users. Also, there may be potential security problems exists in gtk+ with dead upstream for 9 years which is really a long time. The one thing I can confirm is most gtk+ applications with active upstream already ported their softwares to GTK2 or other modern toolkits, the only thing we should do is simply update those packages to the latest version. e.g. bubblemon-0:1.46-10.fc12.x86_64 crossfire-client-0:1.11.0-3.fc12.x86_64 dillo-0:0.8.6-11.fc12.x86_64 gcx-0:0.9.11-9.fc12.x86_64 lazarus-0:0.9.26.2-4.fc12.x86_64 putty-0:0.60-5.fc12.x86_64 qiv-0:2.0-11.fc12.x86_64 swami-0:0.9.4-6.fc12.x86_64 Thank you! Regard. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Sun, May 9, 2010 at 11:05 PM, Chen Lei wrote: 2010/5/10 Orcan Ogetbil On Sun, May 9, 2010 at 11:15 AM, Chen Lei wrote: swami-0:0.9.4-6.fc12.x86_64 This is the *only* soundfont editor there is in Linux, which is enough reason to keep gtk+. Upstream did not do any updates recently, but that doesn't mean that the software is not functional. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel swami(svn) now use gtk2, don't worry about this, it has a quite active upstream. I wonder where you got that information. The gtk2 port was stalled a while ago and it is not functional. The author (he is also a fluidsynth dev) was in exile until yesterday. He just came back to say that he won't be able to find time to do programming for a while longer. I don't see swami-2 out (or have a functional trunk) in the near future. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Sun, 2010-05-09 at 15:27 -0500, Mike McGrath wrote: If you think we should vote, go join debian. I think they do that there. First, I never said we should 'vote'. I talked about community involvement. Second, if you are looking at the sure path to drive people away, sending them to go join Debian will be it. (Though, in your defense, I did the same more than once, so I can't really blame you without sharing the blame) In the meantime our community is suffering far more infighting then before because everyone thinks their version is the right version. As we narrow our focus, people are going to find they fall outside of that focus. Bottom line is we should have done what we're doing now long ago, so we're suffering the consequences as a result. Lots of people with conflicting views are now here. Our lack of focus has just hurt us. I fully agree. With every single word. I do not agree that that working with zero community input is the way to achieve a working compromise. (And input does not equal vote) Have you used OSX lately? They're playing in a whole different league and a whole different game then we are. It's not even a comparison. Not only do we copy OSX but we do so poorly. For those that have problem with apple or want a more free OS, Ubuntu's got the share. We're just not there. Fedora's board isn't driving users and developers away, our OS is. The worst part is we won't get those users back with a marginally better product. I can't really comment on it. (Don't have OSX, never tried it) Though, I would imagine that Fedora is compared to Ubuntu and Windows 7; I doubt that OSX is even on the list. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/09/2010 10:27 PM, Mike McGrath wrote: Bottom line is we should have done what we're doing now long ago, so we're suffering the consequences as a result. Lots of people with conflicting views are now here. Our lack of focus has just hurt us. Have you used OSX lately? Have you ever talked to Ubuntu/openSUSE users and listened to their replies when telling them you are using Fedora? You will hear answers along the line of too much inconvenience to get multimedia working, too unstable (in the sense of low MTBF), I tried Fedora once, but had suffered from -failures, no usable system-config GUI, ... They're playing in a whole different league and a whole different game then we are. Quite likely. But do you think Fedora plays in the league Ubuntu and openSUSE are playing? IMO, no, they are aiming at a different target audience. It's great that Fedora hasn't! Fedora plays in the league of developer distros and RH-derived distros. It's not even a comparison. Not only do we copy OSX but we do so poorly. Note what you wrote: _copy_ As one former FPB member once has put it: Fedora is in danger to become a Ubuntu cult - Except that you refer to OSX instead of Ubuntu, this exactly what you seem to propose. - May-be it's not obvious to you, but by copying you can only loose, because you'll always be second. The worst part is we won't get those users back with a marginally better product. Right, but IMO you are taming the horse from the wrong end. The primary causes of Fedora being on the loose are * US patent laws preventing users from having a great multimedia experience (a key feature of Aunt Tilly users. * Fedora being utilized as a test bed for immature SW. (inacceptable for Aunt Tilly, adds complications for non-Aunt Tilly users). * Fedora not having a nice system setup tools (Necessary for Aunt Tilly) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
planet.fedoraproject.org blog addition weirdness
Hello! Not sure that people are still unaware of that issue, but, anyway, here is my problem: I added RSS-filter to my blog, to properly sort out off-topic or unappropriate content from my diary and make it suitable for inclusion into Fedoraplanet, and listed address of new filtered RSS at my ~/.planet file (cat /home/fedora/peter/.planet for details and compare with the address of feed, listed at the Fedoraplanet page). But, instead of using this filtered feed, planet.fedoraproject.org switches to unfiltered original RSS. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/10 Orcan Ogetbil oget.fed...@gmail.com On Sun, May 9, 2010 at 11:05 PM, Chen Lei wrote: 2010/5/10 Orcan Ogetbil On Sun, May 9, 2010 at 11:15 AM, Chen Lei wrote: swami-0:0.9.4-6.fc12.x86_64 This is the *only* soundfont editor there is in Linux, which is enough reason to keep gtk+. Upstream did not do any updates recently, but that doesn't mean that the software is not functional. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel swami(svn) now use gtk2, don't worry about this, it has a quite active upstream. I wonder where you got that information. The gtk2 port was stalled a while ago and it is not functional. The author (he is also a fluidsynth dev) was in exile until yesterday. He just came back to say that he won't be able to find time to do programming for a while longer. I don't see swami-2 out (or have a functional trunk) in the near future. Orcan I saw him commit the svn two month ago and change the public information one month ago. I think the project is still active. Also, the following guideline is based on swami-2. I'm not know whether the trunk version can work well or not. *http://swami*.*resonance*.*org*/*trac*/*wiki*/*SwamiInstall* Actually, considering it also has an active upstream, it's not suitable to retire swami from fedora. But It's right to retire some other packages with dead upstream(no svn commit) for more than 5 years, it'll accelerate us to finally retire gtk+. As I mentoned below, some packges need update to the lastest release badly to get rid of gtk+ 1.2. And some packages can safely retire from fedora, e.g. xmms. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Test-MinimumVersion/devel perl-Test-MinimumVersion.spec, 1.15, 1.16
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Test-MinimumVersion/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv4623
Modified Files:
perl-Test-MinimumVersion.spec
Log Message:
* Sun May 09 2010 Ralf Corsépius corse...@fedoraproject.org - 0.101080-2
- Rebuild with perl-5.12.0.
Index: perl-Test-MinimumVersion.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Test-MinimumVersion/devel/perl-Test-MinimumVersion.spec,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- perl-Test-MinimumVersion.spec 9 May 2010 06:13:40 - 1.15
+++ perl-Test-MinimumVersion.spec 9 May 2010 06:15:36 - 1.16
@@ -1,6 +1,6 @@
Name: perl-Test-MinimumVersion
Version: 0.101080
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Check whether your code requires a newer perl
License: GPL+ or Artistic
Group: Development/Libraries
@@ -53,6 +53,9 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/*
%changelog
+* Sun May 09 2010 Ralf Corsépius corse...@fedoraproject.org - 0.101080-2
+- Rebuild with perl-5.12.0.
+
* Sun May 09 2010 Ralf Corsépius corse...@fedoraproject.org - 0.101080-1
- Upstream update.
--
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 Crypt-Twofish-2.14.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Crypt-Twofish: 295c059d18f9a46dd14bd765fc465318 Crypt-Twofish-2.14.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Crypt-Twofish/devel .cvsignore, 1.2, 1.3 perl-Crypt-Twofish.spec, 1.4, 1.5 sources, 1.2, 1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-Crypt-Twofish/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8163
Modified Files:
.cvsignore perl-Crypt-Twofish.spec sources
Log Message:
* Sun May 09 2010 Iain Arnell iarn...@gmail.com 2.14-1
- update to latest upstream
- use perl_default_filter and DESTDIR
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Crypt-Twofish/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 13 May 2009 14:58:15 - 1.2
+++ .cvsignore 9 May 2010 07:09:47 - 1.3
@@ -1 +1 @@
-Crypt-Twofish-2.13.tar.gz
+Crypt-Twofish-2.14.tar.gz
Index: perl-Crypt-Twofish.spec
===
RCS file: /cvs/pkgs/rpms/perl-Crypt-Twofish/devel/perl-Crypt-Twofish.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Crypt-Twofish.spec 30 Apr 2010 13:18:39 - 1.4
+++ perl-Crypt-Twofish.spec 9 May 2010 07:09:48 - 1.5
@@ -1,6 +1,6 @@
Name: perl-Crypt-Twofish
-Version:2.13
-Release:4%{?dist}
+Version:2.14
+Release:1%{?dist}
Summary:Twofish Encryption Algorithm
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,17 +10,13 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildRequires: perl(ExtUtils::MakeMaker)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+%{?perl_default_filter}
+
%description
Twofish is a 128-bit symmetric block cipher with a variable length (128,
192, or 256-bit) key, developed by Counterpane Labs. It is unpatented and
free for all uses, as described at http://www.counterpane.com/twofish.html.
-# don't provide private Perl libs
-%global _use_internal_dependency_generator 0
-%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
-%global __find_provides /bin/sh -c %{__grep} -v '%{perl_vendorarch}/.*\\.so$'
| %{__deploop P}
-%global __find_requires /bin/sh -c %{__deploop R}
-
%prep
%setup -q -n Crypt-Twofish-%{version}
@@ -31,7 +27,7 @@ make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
@@ -53,6 +49,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun May 09 2010 Iain Arnell iarn...@gmail.com 2.14-1
+- update to latest upstream
+- use perl_default_filter and DESTDIR
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 2.13-4
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Crypt-Twofish/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 13 May 2009 14:58:15 - 1.2
+++ sources 9 May 2010 07:09:48 - 1.3
@@ -1 +1 @@
-7c75848ba2cf91e0438f477a3ea80899 Crypt-Twofish-2.13.tar.gz
+295c059d18f9a46dd14bd765fc465318 Crypt-Twofish-2.14.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 Perl-PrereqScanner-0.101250.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Perl-PrereqScanner: bce062a90784be14e743997dd421f33e Perl-PrereqScanner-0.101250.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Perl-PrereqScanner/devel .cvsignore, 1.3, 1.4 perl-Perl-PrereqScanner.spec, 1.3, 1.4 sources, 1.3, 1.4
Author: iarnell
Update of /cvs/pkgs/rpms/perl-Perl-PrereqScanner/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8830
Modified Files:
.cvsignore perl-Perl-PrereqScanner.spec sources
Log Message:
* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101250-1
- update to latest upstream
- BR perl(Moose)
- BR perl(Moose::Role)
- BR perl(Params::Util)
- BR perl(String::RewritePrefix)
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Perl-PrereqScanner/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 11 Apr 2010 05:36:08 - 1.3
+++ .cvsignore 9 May 2010 07:17:56 - 1.4
@@ -1 +1 @@
-Perl-PrereqScanner-0.100960.tar.gz
+Perl-PrereqScanner-0.101250.tar.gz
Index: perl-Perl-PrereqScanner.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Perl-PrereqScanner/devel/perl-Perl-PrereqScanner.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Perl-PrereqScanner.spec4 May 2010 18:47:46 - 1.3
+++ perl-Perl-PrereqScanner.spec9 May 2010 07:17:56 - 1.4
@@ -1,17 +1,21 @@
Name: perl-Perl-PrereqScanner
-Version:0.100960
-Release:2%{?dist}
+Version:0.101250
+Release:1%{?dist}
Summary:Tool to scan your Perl code for its prerequisites
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Perl-PrereqScanner/
-Source0:
http://www.cpan.org/authors/id/J/JQ/JQUELIN/Perl-PrereqScanner-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Perl-PrereqScanner-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Moose)
+BuildRequires: perl(Moose::Role)
BuildRequires: perl(namespace::autoclean)
+BuildRequires: perl(Params::Util)
BuildRequires: perl(PPI) = 1.205
BuildRequires: perl(PPI::Document)
+BuildRequires: perl(String::RewritePrefix)
BuildRequires: perl(Version::Requirements) = 0.100630
# tests
BuildRequires: perl(Pod::Coverage::TrustPod)
@@ -61,6 +65,13 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101250-1
+- update to latest upstream
+- BR perl(Moose)
+- BR perl(Moose::Role)
+- BR perl(Params::Util)
+- BR perl(String::RewritePrefix)
+
* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 0.100960-2
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Perl-PrereqScanner/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 11 Apr 2010 05:36:08 - 1.3
+++ sources 9 May 2010 07:17:56 - 1.4
@@ -1 +1 @@
-793593ddff5cce720fa8790dc307db0c Perl-PrereqScanner-0.100960.tar.gz
+bce062a90784be14e743997dd421f33e Perl-PrereqScanner-0.101250.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 CPAN-Uploader-0.101260.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CPAN-Uploader: e9162ce00b77a8c870d960b2713b2b83 CPAN-Uploader-0.101260.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CPAN-Uploader/devel .cvsignore, 1.2, 1.3 perl-CPAN-Uploader.spec, 1.2, 1.3 sources, 1.2, 1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-CPAN-Uploader/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv9173
Modified Files:
.cvsignore perl-CPAN-Uploader.spec sources
Log Message:
* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101260-1
- update to latest upstream
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 22 Apr 2010 03:03:37 - 1.2
+++ .cvsignore 9 May 2010 07:20:19 - 1.3
@@ -1 +1 @@
-CPAN-Uploader-0.100760.tar.gz
+CPAN-Uploader-0.101260.tar.gz
Index: perl-CPAN-Uploader.spec
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/devel/perl-CPAN-Uploader.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-CPAN-Uploader.spec 30 Apr 2010 13:00:03 - 1.2
+++ perl-CPAN-Uploader.spec 9 May 2010 07:20:19 - 1.3
@@ -1,6 +1,6 @@
Name: perl-CPAN-Uploader
-Version:0.100760
-Release:2%{?dist}
+Version:0.101260
+Release:1%{?dist}
Summary:Upload things to the CPAN
License:GPL+ or Artistic
Group: Development/Libraries
@@ -65,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101260-1
+- update to latest upstream
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.100760-2
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 22 Apr 2010 03:03:37 - 1.2
+++ sources 9 May 2010 07:20:19 - 1.3
@@ -1 +1 @@
-ba2aee2a089f98dd7966d56c55c3d5c3 CPAN-Uploader-0.100760.tar.gz
+e9162ce00b77a8c870d960b2713b2b83 CPAN-Uploader-0.101260.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CPAN-Uploader/F-12 .cvsignore, 1.2, 1.3 perl-CPAN-Uploader.spec, 1.1, 1.2 sources, 1.2, 1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-CPAN-Uploader/F-12
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv9410/F-12
Modified Files:
.cvsignore perl-CPAN-Uploader.spec sources
Log Message:
* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101260-1
- update to latest upstream
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/F-12/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 22 Apr 2010 03:03:36 - 1.2
+++ .cvsignore 9 May 2010 07:21:53 - 1.3
@@ -1 +1 @@
-CPAN-Uploader-0.100760.tar.gz
+CPAN-Uploader-0.101260.tar.gz
Index: perl-CPAN-Uploader.spec
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/F-12/perl-CPAN-Uploader.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-CPAN-Uploader.spec 22 Apr 2010 03:03:36 - 1.1
+++ perl-CPAN-Uploader.spec 9 May 2010 07:21:53 - 1.2
@@ -1,5 +1,5 @@
Name: perl-CPAN-Uploader
-Version:0.100760
+Version:0.101260
Release:1%{?dist}
Summary:Upload things to the CPAN
License:GPL+ or Artistic
@@ -65,6 +65,12 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101260-1
+- update to latest upstream
+
+* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.100760-2
+- Mass rebuild with perl-5.12.0
+
* Thu Apr 08 2010 Iain Arnell iarn...@gmail.com 0.100760-1
- Specfile autogenerated by cpanspec 1.78.
- use perl_default_filter and DESTDIR
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/F-12/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 22 Apr 2010 03:03:36 - 1.2
+++ sources 9 May 2010 07:21:53 - 1.3
@@ -1 +1 @@
-ba2aee2a089f98dd7966d56c55c3d5c3 CPAN-Uploader-0.100760.tar.gz
+e9162ce00b77a8c870d960b2713b2b83 CPAN-Uploader-0.101260.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CPAN-Uploader/F-13 .cvsignore, 1.2, 1.3 perl-CPAN-Uploader.spec, 1.1, 1.2 sources, 1.2, 1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-CPAN-Uploader/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv9410/F-13
Modified Files:
.cvsignore perl-CPAN-Uploader.spec sources
Log Message:
* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101260-1
- update to latest upstream
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/F-13/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 22 Apr 2010 03:03:37 - 1.2
+++ .cvsignore 9 May 2010 07:21:53 - 1.3
@@ -1 +1 @@
-CPAN-Uploader-0.100760.tar.gz
+CPAN-Uploader-0.101260.tar.gz
Index: perl-CPAN-Uploader.spec
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/F-13/perl-CPAN-Uploader.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-CPAN-Uploader.spec 22 Apr 2010 03:03:37 - 1.1
+++ perl-CPAN-Uploader.spec 9 May 2010 07:21:53 - 1.2
@@ -1,5 +1,5 @@
Name: perl-CPAN-Uploader
-Version:0.100760
+Version:0.101260
Release:1%{?dist}
Summary:Upload things to the CPAN
License:GPL+ or Artistic
@@ -65,6 +65,12 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun May 09 2010 Iain Arnell iarn...@gmail.com 0.101260-1
+- update to latest upstream
+
+* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.100760-2
+- Mass rebuild with perl-5.12.0
+
* Thu Apr 08 2010 Iain Arnell iarn...@gmail.com 0.100760-1
- Specfile autogenerated by cpanspec 1.78.
- use perl_default_filter and DESTDIR
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CPAN-Uploader/F-13/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 22 Apr 2010 03:03:37 - 1.2
+++ sources 9 May 2010 07:21:54 - 1.3
@@ -1 +1 @@
-ba2aee2a089f98dd7966d56c55c3d5c3 CPAN-Uploader-0.100760.tar.gz
+e9162ce00b77a8c870d960b2713b2b83 CPAN-Uploader-0.101260.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
[Bug 590385] New: perl-Module-Signature-0.64 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Module-Signature-0.64 is available https://bugzilla.redhat.com/show_bug.cgi?id=590385 Summary: perl-Module-Signature-0.64 is available Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: ASSIGNED Keywords: FutureFeature Severity: medium Priority: low Component: perl-Module-Signature AssignedTo: ville.sky...@iki.fi ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, pertu...@free.fr, ville.sky...@iki.fi Classification: Fedora Latest upstream release: 0.64 Current version in Fedora Rawhide: 0.63 URL: http://search.cpan.org/dist/Module-Signature/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- 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
File Module-Signature-0.64.tar.gz uploaded to lookaside cache by scop
A file has been added to the lookaside cache for perl-Module-Signature: e9a2676cbfefc612178940166f411fac Module-Signature-0.64.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Module-Signature/devel .cvsignore, 1.12, 1.13 perl-Module-Signature.spec, 1.18, 1.19 sources, 1.12, 1.13
Author: scop
Update of /cvs/pkgs/rpms/perl-Module-Signature/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv16222
Modified Files:
.cvsignore perl-Module-Signature.spec sources
Log Message:
* Sun May 9 2010 Ville Skyttä ville.sky...@iki.fi - 0.64-1
- Update to 0.64 (#590385).
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Module-Signature/devel/.cvsignore,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- .cvsignore 22 Apr 2010 21:15:54 - 1.12
+++ .cvsignore 9 May 2010 15:39:41 - 1.13
@@ -1 +1 @@
-Module-Signature-0.63.tar.gz
+Module-Signature-0.64.tar.gz
Index: perl-Module-Signature.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Module-Signature/devel/perl-Module-Signature.spec,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- perl-Module-Signature.spec 3 May 2010 09:23:21 - 1.18
+++ perl-Module-Signature.spec 9 May 2010 15:39:41 - 1.19
@@ -1,6 +1,6 @@
Name: perl-Module-Signature
-Version:0.63
-Release:2%{?dist}
+Version:0.64
+Release:1%{?dist}
Summary:CPAN signature management utilities and modules
Group: Development/Libraries
@@ -29,8 +29,7 @@ checking and creating SIGNATURE files fo
%build
-PERL_AUTOINSTALL=--skipdeps \
-%{__perl} Makefile.PL INSTALLDIRS=vendor --installdeps
+echo n | %{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -43,6 +42,7 @@ find $RPM_BUILD_ROOT -depth -type d -exe
%check
+# Signature test would need network access
make test
@@ -55,10 +55,14 @@ rm -rf $RPM_BUILD_ROOT
%doc AUTHORS Changes README *.pub
%{_bindir}/cpansign
%{perl_vendorlib}/Module/
-%{_mandir}/man[13]/*.[13]*
+%{_mandir}/man1/cpansign.1*
+%{_mandir}/man3/Module::Signature.3*
%changelog
+* Sun May 9 2010 Ville Skyttä ville.sky...@iki.fi - 0.64-1
+- Update to 0.64 (#590385).
+
* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 0.63-2
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Module-Signature/devel/sources,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- sources 22 Apr 2010 21:15:54 - 1.12
+++ sources 9 May 2010 15:39:41 - 1.13
@@ -1 +1 @@
-49a961502c0786797dabfea9c7fd30c3 Module-Signature-0.63.tar.gz
+e9a2676cbfefc612178940166f411fac Module-Signature-0.64.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
[Bug 590385] perl-Module-Signature-0.64 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=590385 Ville Skyttä ville.sky...@iki.fi changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||0.64-1 Resolution||RAWHIDE -- 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
