From kevin at scrye.com Sun Feb 1 00:38:22 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Sat, 31 Jan 2009 17:38:22 -0700 Subject: PackageMaintainers wiki cleanup update In-Reply-To: References: Message-ID: <20090131173822.09920ac3@ohm.scrye.com> On Sat, 31 Jan 2009 17:01:54 -0500 Susan Lauber wrote: > Greetings to the authors/maintainers of Package Maintainer wiki pages, > > I introduced myself last week [1] and since then I have dug into the > pages and set up a task table [2] Greetings! > I have already added a category to most pages so they can all be found > together [3]. > If there are others or if you create a new page just add the string > [[Category:Package Maintainers]] to the bottom of the page. > > The next step is renaming so that pages are easier to find in a > search. It will also make the category page easier to use. I have > started making suggested in the packagemaintainers.psv [4] file in > the wikirename.git repo and > > ***I encourage others to check the proposed names and offer additional > suggestions.*** ok. Here's my suggestions: --- a/packagemaintainers.psv +++ b/packagemaintainers.psv @@ -18,7 +18,7 @@ PackageMaintainers/CvsAccess|CVS access for package maintainers #PackageMaintainers/FC6Status|Archive:PackageMaintainers/FC6Status PackageMaintainers/FEver|Using FEver to track upstream changes PackageMaintainers/HelpWanted|Help wanted for package maintainance -PackageMaintainers/HowToGetSponsored|How to get a package sponsored +PackageMaintainers/HowToGetSponsored|How to get a sponsored into the packager group PackageMaintainers/InProgressReviewRequests| PackageMaintainers/Join|Join the package collection maintainers #following Main* are included in other pages @@ -30,13 +30,15 @@ PackageMaintainers/MainPagePackaging| PackageMaintainers/MainPageUsers| PackageMaintainers/MaintainerResponsibility|Package maintainer responsibilities #following needs love - I can't tell a good name from content. -PackageMaintainers/Makefile|Handling the Makefile +#This is out of date and 'make help' should be used instead anyhow - kevin +PackageMaintainers/Makefile|Archive:PackageMaintainers/Makefile PackageMaintainers/MockTricks|Using Mock to test package builds PackageMaintainers/NewPackageProcess|New package process for existing contributors PackageMaintainers/OrphanedPackages|Orphaned package that need new maintainers PackageMaintainers/PackageEndOfLife|How to remove a package at end of life PackageMaintainers/PackageStatus|Package status #archive the following CompsF*Missing ? +#yes, I would think so - kevin PackageMaintainers/PackageStatus/CompsF10Missing| PackageMaintainers/PackageStatus/CompsF7Missing| PackageMaintainers/PackageStatus/CompsF8Missing| @@ -47,7 +49,8 @@ PackageMaintainers/Policy|Package maintainer policy PackageMaintainers/Policy/EOL|Policy for package lifecycle PackageMaintainers/Policy/EncourageComaintainership|Policy for encouraging comaintainers PackageMaintainers/Policy/FESCoElections|FESCo election policy -PackageMaintainers/Policy/KernelModules|Packaging kernel modules +# should be removed, no longer applicable +PackageMaintainers/Policy/KernelModules| PackageMaintainers/Policy/NonResponsiveMaintainers|Policy for nonresponsive package maint PackageMaintainers/Policy/StalledReviews|Policy for stalled package reviews > I would like to have this file ready for the wikibot by the end of > the week (Feb 7). > Lack of response will be seen as a vote of confidence :) Excellent. Thanks for looking at this! > Thanks, > Susan kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bmaly at redhat.com Sun Feb 1 01:07:45 2009 From: bmaly at redhat.com (Brian Maly) Date: Sat, 31 Jan 2009 20:07:45 -0500 Subject: Moblin 2 and Fedora In-Reply-To: <20090131153457.573762ab@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> Message-ID: <4984F5E1.5040502@redhat.com> Arjan van de Ven wrote: > > If there's something specific that the Fedora project wants to get from > Moblin we should discuss that, but lets be specific there rather than > having a discussion on the blanket hand-wavey level... > > Can we put improved boot time on the wish list? Whatever is reasonable and practical. Though Im not suggesting the expectation should be 5 second boot time for Fedora. Brian From wolfy at nobugconsulting.ro Sun Feb 1 01:09:25 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 01 Feb 2009 03:09:25 +0200 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> Message-ID: <4984F645.5090400@nobugconsulting.ro> On 02/01/2009 01:11 AM, Horst H. von Brand wrote: > > And all mirrors have to carry this stuff around, for a tiny minority of > users? It is much more reasonable to set up your own repo with the stuff > around the non-free tools, whip up a community around it, and go from > there. This is not rocket science. Yes, it does require work on your part, > not just waiting for it to "magically" show up in your nearest Fedora > mirror. > I hope that you do realize that my company's internal repo carries this package for a month already, don't you ? As of work on my part, drop it dead. I am the maintainer of 3 of the largest Fedora mirrors in my country. And there are 5-6 of them in total. From konrad at tylerc.org Sun Feb 1 01:15:03 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Sat, 31 Jan 2009 17:15:03 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <4984F5E1.5040502@redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <20090131153457.573762ab@infradead.org> <4984F5E1.5040502@redhat.com> Message-ID: <200901311715.03488.konrad@tylerc.org> On Saturday 31 January 2009 05:07:45 pm Brian Maly wrote: > Arjan van de Ven wrote: > > If there's something specific that the Fedora project wants to get from > > Moblin we should discuss that, but lets be specific there rather than > > having a discussion on the blanket hand-wavey level... > > Can we put improved boot time on the wish list? Whatever is reasonable > and practical. Though Im not suggesting the expectation should be 5 > second boot time for Fedora. > > Brian http://fedoraproject.org/wiki/Features/20SecondStartup -- Conrad Meyer From arjan at infradead.org Sun Feb 1 01:16:48 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Sat, 31 Jan 2009 17:16:48 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <4984F5E1.5040502@redhat.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <4984F5E1.5040502@redhat.com> Message-ID: <20090131171648.5a38a145@infradead.org> On Sat, 31 Jan 2009 20:07:45 -0500 Brian Maly wrote: > Arjan van de Ven wrote: > > > > If there's something specific that the Fedora project wants to get > > from Moblin we should discuss that, but lets be specific there > > rather than having a discussion on the blanket hand-wavey level... > > > > > Can we put improved boot time on the wish list? Whatever is > reasonable and practical. Though Im not suggesting the expectation > should be 5 second boot time for Fedora. arguably that's clearly way outside of where Moblin borrowed some packages from Fedora ;-) I have offered before, and that offer still stands, to help in this regard. And I have been working with various folks from Fedora (as well as other distros) on this. It's not like there's any secrets; the LPC presentation I think lines out pretty well what process worked for us. It's just that the project will/motivation needs to be there to make this an important item, and then move relatively fast across a wide range of things to make them not-suck. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From zaitcev at redhat.com Sun Feb 1 01:28:10 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 31 Jan 2009 18:28:10 -0700 Subject: Maybe OT for this list: Programming languages for Fedora? In-Reply-To: <49848E3B.8000809@fedoraproject.org> References: <49848045.7020602@fedoraproject.org> <20090131170755.GA32133@wolff.to> <49848E3B.8000809@fedoraproject.org> Message-ID: <20090131182810.cc7b63a9.zaitcev@redhat.com> On Sat, 31 Jan 2009 17:45:31 +0000, Frank Murphy wrote: > >> What languages, would be good to learn re. Fedora? > >> (Have started Java currently, on the curriculum) > >> > >> What extra(s) would be useful? > > > > For what purposes? > > For helping with packaging\ bringing new stuff in\ crating gui(s) where > the need arises, bug fixing (as distinct from just reporting) Python is most common in new projects these days, and quite a bit of Fedora infrastructure is already written in Python (e.g. Anaconda). Java is nice, but WORA is unbearable. So it's rare. I think the only two useful applications we ship are Azureus and RSSowl, and neither is used by Fedora to do Fedora things. -- Pete From alsadi at gmail.com Sun Feb 1 03:00:14 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sun, 1 Feb 2009 05:00:14 +0200 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131172219.GB7964@yoda.jdub.homelinux.org> <20090131222655.GA84354@dspnet.fr.eu.org> Message-ID: <385866f0901311900w9f0bd5dqd8c43bae65dfc8b@mail.gmail.com> I used to have a row image of a hard disk (for qemu) 4.1GB in size saved on FAT32 we (in ojuba.org) have built a livecd of oo.o based on fedora (gnome) most of the packages are from fedora except oo.o which I built to cut off some java features from oo.o to save the size of gcj and of course it have only one langpack installed --- my guess that full liveDVD is a bad thing because for installation one can't select packages and if a small scratch hit it the entire system can't be installed while with usual dvd if file-roller*.rpm was damaged you can unselect it and download it later -- a good tradeoff might be a liveDVD/USB spin with about 1GB From alsadi at gmail.com Sun Feb 1 03:12:46 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sun, 1 Feb 2009 05:12:46 +0200 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <4984F645.5090400@nobugconsulting.ro> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> Message-ID: <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> the answer is rpmfusion-free simply just like many free game emulator that has no free ROMs ..etc. From wtogami at redhat.com Sun Feb 1 06:41:31 2009 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 Feb 2009 01:41:31 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> Message-ID: <4985441B.7030005@redhat.com> Bill Nottingham wrote: > - K12Linux/thin client > > Some older thin client hardware is not i686 compatible. Warren has more > info on this. One question I have is that some of this is mentioned > as being Geode - wouldn't this fall into the same category as the XO? Geode is a popular thin client chipset that continues to be sold today. VIA i586 without cmov was sold in thin clients until recently. Anything older I do not care about. > > More info is on the feature page. Note that in the smolt stats, i586 > accounts for less than one twentieth of one percent of active systems, > an order of magnitude less than PowerPC. smolt stats are not coming from i586 machines because these are not the same kind of Fedora installs. It is inappropriate to enable smolt reporting by default for several reasons including minimizing chroot size, and read-only root makes it impossible to record that it shouldn't report again during the next boot. The statistics are not representative of the real world. Warren Togami wtogami at redhat.com From drago01 at gmail.com Sun Feb 1 07:05:39 2009 From: drago01 at gmail.com (drago01) Date: Sun, 1 Feb 2009 08:05:39 +0100 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131172219.GB7964@yoda.jdub.homelinux.org> <20090131222655.GA84354@dspnet.fr.eu.org> Message-ID: On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull wrote: > On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert wrote: > >> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn. > > So we're leaving the developing world to Ubuntu now? They can/have to use the x86 livecd anyway for their older system. We are talking about moving the x86_64 live spin to a DVD. From hanpingtian at gmail.com Sun Feb 1 07:16:01 2009 From: hanpingtian at gmail.com (=?GB2312?B?xr3M7Lqr?=) Date: Sun, 1 Feb 2009 15:16:01 +0800 Subject: Why do we disable esd in libgnome? Message-ID: <3528361a0901312316l65d22020x394a299a6eefe287@mail.gmail.com> hi Great list, I just find that the libgnome-2.24.1-7.fc10 has been disabled "esd" when it is built. This has caused the "gnome_sound_play()" doesn't work and some package such as "stardict" cannot play sound. Why should we disable esd in libgnome? Could we enable it? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Sun Feb 1 07:41:07 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 01 Feb 2009 01:41:07 -0600 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> Message-ID: <1233474067.15230.55.camel@localhost.localdomain> On Sat, 2009-01-31 at 17:12 +0100, drago01 wrote: > On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil > wrote: > > On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote: > >> But our live images are already heavily size-constrained. There's definitely > >> no room for multiple kernels on the KDE live image, and I don't think the > >> GNOME image has any room left either. > > > > Was already discussed the requirement of CDs nowadays? Even the oldest > > computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin. > > Well for x86_64 we can/should do this. > Good luck on finding a x86_64 computer/laptop without a DVD drive. The problem isn't DVD readers, it's DVD writers. I sure don't own any, and I have two x86-64 machines. I've had enough problems with CDRs being unreliable, somehow I don't think higher density is going to help any. I feel my money is better spent on more HDs and flash drives. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Feb 1 07:49:02 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 01 Feb 2009 01:49:02 -0600 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131164352.GA25612@wolff.to> Message-ID: <1233474542.15230.63.camel@localhost.localdomain> On Sat, 2009-01-31 at 21:36 +0100, Kevin Kofler wrote: > drago01 wrote: > > File size limit on fat32 is 4GB not 2. > > Then try saving a file with more than 2 GB with Window$ Me... Do we really care about Win9x? WinME was EOLed 2.5 years ago. Let it die. Microsoft already has. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Sun Feb 1 08:33:30 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 1 Feb 2009 08:33:30 +0000 (UTC) Subject: rawhide report: 20090201 changes Message-ID: <20090201083330.78C2E1F82CF@releng2.fedora.phx.redhat.com> Compose started at Sun Feb 1 06:01:03 UTC 2009 Updated Packages: HamFax-0.6.4-3.fc11 ------------------- * Fri Jan 30 17:00:00 2009 Randall J. Berry 'Dp67' - 0.6.4-3 - Fix unowned directories Bug #483319 - Fix .desktop file beagle-0.3.9-2.fc11 ------------------- * Sat Jan 31 17:00:00 2009 Adel Gadllah - 0.3.9-2 - Rebase debug output patch cairo-dock-2.0.0-0.3.svn1512_trunk.fc11 --------------------------------------- * Sun Feb 1 17:00:00 2009 Mamoru Tasaka - rev 1512 ctan-kerkis-fonts-2.0-20.fc11 ----------------------------- * Sun Feb 1 17:00:00 2009 Sarantis Paskalis - 2.0-20 - Also add forgotten requires on -common. cups-pdf-2.5.0-1.fc11 --------------------- * Sat Jan 31 17:00:00 2009 Remi Collet 2.5.0-1 - update to 2.5.0 - Add SElinux notes in INSTALL.fedora cwirc-2.0.0-5.fc11 ------------------ * Fri Jan 30 17:00:00 2009 Randall J. Berry 'Dp67' 2.0.0-5 - Fix unowned directories Bug #483335 deluge-1.1.2-1.fc11 ------------------- * Sat Jan 31 17:00:00 2009 Peter Gordon - 1.1.2-1 - Update to new upstream bug-fix release (1.1.2) electric-8.08-2.fc11 -------------------- * Sun Feb 1 17:00:00 2009 Chitlesh GOORAH - 8.08-2 - bugfix for RHBZ #483343 examiner-0.5-3.fc11 ------------------- * Sat Jan 31 17:00:00 2009 Rakesh Pandit 0.5-3 - Fixed unowned directory glade3-3.5.6-1.fc11 ------------------- * Sat Jan 31 17:00:00 2009 Rakesh Pandit - 3.5.6-1 - Updated to 3.5.6 (as per NEWS): - a) Handling of new entry properties - b) Added filechooser dialog to pixbuf properties - Fixed unowned directories in libgladeui-devel goffice-0.6.6-1.fc11 -------------------- * Sat Jan 31 17:00:00 2009 Julian Sikorski - 0.6.6-1 - Updated to 0.6.6 google-droid-fonts-1.0.112-4.fc11 --------------------------------- * Sat Jan 31 17:00:00 2009 - 1.0.112-4 ??? fix-up fontconfig installation for sans and mono kdegames-4.2.0-2.fc11 --------------------- * Sat Jan 31 17:00:00 2009 Rex Dieter - 4.2.0-2 - unowned dirs (#438314) kdegraphics-4.2.0-2.fc11 ------------------------ * Sat Jan 31 17:00:00 2009 Rex Dieter - 4.2.0-2 - unowned dirs (#483317) kdelibs-4.2.0-8.fc11 -------------------- * Sat Jan 31 17:00:00 2009 Rex Dieter 4.2.0-8 - unowned dirs (#483315,#483318) kdelibs3-3.5.10-5.fc11 ---------------------- * Sat Jan 10 17:00:00 2009 Ville Skytt?? - 6:3.5.10-4 - Slight speedup to profile.d/kde.sh (#465370). * Sat Jan 31 17:00:00 2009 Rex Dieter - 6:3.5.10-5 - unowned dirs (#483318) kdemultimedia-4.2.0-2.fc11 -------------------------- * Sat Jan 31 17:00:00 2009 Rex Dieter - 4.2.0-2 - unowned dirs (#483516) kernel-2.6.29-0.74.rc3.git3.fc11 -------------------------------- * Sat Jan 31 17:00:00 2009 Dave Jones - 2.6.29-rc3-git3 ldm-2.0.33-1.fc11 ----------------- * Thu Jan 22 17:00:00 2009 Warren Togami - 2.0.30-1 - NBD update checker, reboots client automatically if needed * Wed Jan 28 17:00:00 2009 Warren Togami - 2.0.30-2 - Fix nbd update checker * Sat Jan 31 17:00:00 2009 Ryan Niebur - 2.0.31-1 - show the languages in a user friendly way in the language chooser - race condition fix * Sat Jan 31 17:00:00 2009 Ryan Niebur - 2.0.33-1 - New upstream version: - add support for translation of rc.d scripts (only French translation atm) libvirt-0.6.0-1.fc11 -------------------- * Sat Jan 31 17:00:00 2009 Daniel Veillard - 0.6.0-1.fc11 - upstream release 0.6.0 - thread safety of API - allow QEmu/KVM domains to survive daemon restart - extended logging capabilities - support copy on write storage volumes for QEmu/KVM - support of storage cache control options for QEmu/KVM - a lot of bug fixes midori-0.1.2-1.fc11 ------------------- * Sat Jan 31 17:00:00 2009 Peter Gordon - 0.1.2-1 - Update ot new upstream release (0.1.2): support for bookmarklets ("javascript:foo" URLs and bookmarks), better persistent cookie support, preference changes saved dynamically. Lots of startup fixes for speed issues, too. :) nfs-utils-1.1.4-16.fc11 ----------------------- * Sat Jan 31 17:00:00 2009 Steve Dickson 1.1.4-15 - Reworked tcp wrapper code to correctly use API (bz 480223) - General clean up of tcp wrapper code. * Sat Jan 31 17:00:00 2009 Steve Dickson 1.1.4-16 - Fixed typo in -mount-textbased.patch (bz 483375) nufw-2.2.20-8.fc11 ------------------ * Sat Jan 31 17:00:00 2009 Jerome Soyer 2.2.20-8 - Add requires on all nuauth-* fo fixing unowned directory ode-0.11-1.fc11 --------------- * Fri Jan 30 17:00:00 2009 Hans de Goede 0.11-1 - New upstream release 0.11 pygtk2-2.14.0-1.fc11 -------------------- * Sat Jan 31 17:00:00 2009 Matthew Barnes - 2.14.0-1.fc11 - Update to 2.14.0 qt3-3.3.8b-19.fc11 ------------------ * Sat Jan 31 17:00:00 2009 Karsten Hopp 3.3.8b-19 - s390x is 64bit, s390 is 32bit. Fixed in /etc/profile.d/qt.* rpm-4.6.0-0.rc4.2.fc11 ---------------------- * Sat Jan 31 17:00:00 2009 Panu Matilainen - change platform sharedstatedir to something more sensible (#185862) - add rpmdb_foo links to db utils for documentation compatibility ss5-3.6.4-3.fc11 ---------------- * Sat Jan 31 17:00:00 2009 Itamar Reis Peixoto - 3.6.4-3 - include /etc/sysconfig/ss5 file sudo-1.6.9p17-4.fc10 -------------------- * Thu Jan 8 17:00:00 2009 Daniel Kopecek 1.6.9p17-3 - Added /usr/local/bin to secure-path * Tue Jan 13 17:00:00 2009 Daniel Kopecek 1.6.9p17-4 - build with sendmail installed zenity-2.24.1-1.fc10 -------------------- * Thu Jan 15 17:00:00 2009 Matthias Clasen - 2.24.1-1 - 2.24.1 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 30 Broken deps for i386 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15 libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15) 1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 python-gammu-0.28-1.fc11.i386 requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit) gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit) gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit) mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) 1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15 gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15 gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15 libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0 linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15) 1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 python-gammu-0.28-1.fc11.ppc requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) 1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) From nicolas.mailhot at laposte.net Sun Feb 1 09:45:20 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 10:45:20 +0100 Subject: Maybe OT for this list: Programming languages for Fedora? In-Reply-To: <20090131182810.cc7b63a9.zaitcev@redhat.com> References: <49848045.7020602@fedoraproject.org> <20090131170755.GA32133@wolff.to> <49848E3B.8000809@fedoraproject.org> <20090131182810.cc7b63a9.zaitcev@redhat.com> Message-ID: <1233481520.6961.6.camel@arekh.okg> Le samedi 31 janvier 2009 ? 18:28 -0700, Pete Zaitcev a ?crit : > Java is nice, but WORA is unbearable. So it's rare. I think the only > two useful applications we ship are Azureus and RSSowl, and neither > is used by Fedora to do Fedora things. And Eclipse, and all the java server stuff, and bits of OpenOffice.org, etc Java's current sweet spot is middleware, it does that very well, and the desktop stuff will come as soon as people are used to the idea we have openjdk available in every good distros, and the openjdk/Sun people are finished fixing the last legacy desktop warts (such as, font discovery and handling hint hint). -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From konrad at tylerc.org Sun Feb 1 09:56:24 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 1 Feb 2009 01:56:24 -0800 Subject: Maybe OT for this list: Programming languages for Fedora? In-Reply-To: <1233481520.6961.6.camel@arekh.okg> References: <49848045.7020602@fedoraproject.org> <20090131182810.cc7b63a9.zaitcev@redhat.com> <1233481520.6961.6.camel@arekh.okg> Message-ID: <200902010156.24438.konrad@tylerc.org> On Sunday 01 February 2009 01:45:20 am Nicolas Mailhot wrote: > Le samedi 31 janvier 2009 ? 18:28 -0700, Pete Zaitcev a ?crit : > > Java is nice, but WORA is unbearable. So it's rare. I think the only > > two useful applications we ship are Azureus and RSSowl, and neither > > is used by Fedora to do Fedora things. > > And Eclipse, and all the java server stuff, and bits of OpenOffice.org, > etc > > Java's current sweet spot is middleware, it does that very well, and the > desktop stuff will come as soon as people are used to the idea we have > openjdk available in every good distros, and the openjdk/Sun people are > finished fixing the last legacy desktop warts (such as, font discovery > and handling hint hint). Shark[0] will go a long way towards making OpenJDK useful on every arch other than x86 and x86_64. But the current status of OpenJDK on PPC and non-x86 archs is it's vastly slower than GCJ. [0]: http://gbenson.net/ Regards, -- Conrad Meyer From triad at df.lth.se Sun Feb 1 10:40:21 2009 From: triad at df.lth.se (Linus Walleij) Date: Sun, 01 Feb 2009 11:40:21 +0100 Subject: stricter C++ prototypes In-Reply-To: <49824E7B.20103@redhat.com> References: <49824E7B.20103@redhat.com> Message-ID: <1233484821.3128.3.camel@fecusia> tor 2009-01-29 klockan 16:48 -0800 skrev Ulrich Drepper: > Sometime soon we'll have gcc 4.4 in rawhide as the new system compiler. That rocks! Martin Michlmayr from Debian rebuilt all of their packages with GCC 4.4 recently, hm well september last year, and so was already back then quite painless it appears: http://lwn.net/Articles/298560/ Linus From ffesti at redhat.com Sun Feb 1 11:41:11 2009 From: ffesti at redhat.com (Florian Festi) Date: Sun, 01 Feb 2009 12:41:11 +0100 Subject: Too many unowned directories In-Reply-To: <20090131193421.GA24526@amd.home.annexia.org> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> Message-ID: <49858A57.8060406@redhat.com> Richard W.M. Jones wrote: > On Sat, Jan 31, 2009 at 01:43:47PM +0100, Michael Schwendt wrote: >> On Sat, 31 Jan 2009 11:11:30 +0000, Richard wrote: >>> Why can't RPM deal with it? >> Because it doesn't do it yet? ;) >> Perhaps it's not even easy to implement in RPM's current code base? > > Sure thing. We should file a bug (feature enhancement really) against > RPM and then forget about the unowned directories thing until that bug > has been resolved one way or another. > > I don't know if you agree with me, but I think the _right_ way to > solve this is once in RPM, not 48235 times over in all the packages in > Fedora. Even if the RPM implementation is a bit tricky, it's surely > easier than pushing this job down to every packager. As far as I can see right now there is only one thing that RPM could do: Create a file requires to all directories that the packages places files in and is not part of the package itself. From my (RPM) perspective this is a good, save and simple to implement solution. But it comes with the price of yum requiring (and though downloading) the file list for each and every transaction. So you solve one problem by creating a new one. Of course this new problem can surly also be solved by: 1. Manually adding directories other packages are supposed to put files in as provides (replacing pain by more pain). 2. Selecting the directories and files that createrepo adds to the primary.xml in a more intelligent way to reduce the requirement of accessing the file list to some rare cross repo cases (Tricky and already refused by yum upstream in the past, AFAIK). Florian PS: If someone knows better solutions feel free to discuss them here or on rpm-maint at lists.rpm.org From mschwendt at gmail.com Sun Feb 1 11:42:31 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 1 Feb 2009 12:42:31 +0100 Subject: Too many unowned directories In-Reply-To: <20090131193421.GA24526@amd.home.annexia.org> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> Message-ID: <20090201124231.aefa4e5f.mschwendt@gmail.com> On Sat, 31 Jan 2009 19:34:47 +0000, Richard wrote: > On Sat, Jan 31, 2009 at 01:43:47PM +0100, Michael Schwendt wrote: > > On Sat, 31 Jan 2009 11:11:30 +0000, Richard wrote: > > > Why can't RPM deal with it? > > > > Because it doesn't do it yet? ;) > > Perhaps it's not even easy to implement in RPM's current code base? > > Sure thing. We should file a bug (feature enhancement really) against > RPM and then forget about the unowned directories thing until that bug > has been resolved one way or another. > > I don't know if you agree with me, but I think the _right_ way to > solve this is once in RPM, not 48235 times over in all the packages in > Fedora. Even if the RPM implementation is a bit tricky, it's surely > easier than pushing this job down to every packager. And meanwhile, package upgrades continue with creating empty _versioned_ %doc and include directories, for example. Orphaned empty includedirs have broken non-mock builds of some tarballs before. /usr/share/doc requires manual clean-up if you really want to browse it with tab completion. Yes, I agree, a fix in RPM would be nice to have -- though, it probably won't fix "repoquery --whatprovides /path/dir" (or Yum's similar cmd). Waiting for a fix in RPM is no excuse for packagers, however, who don't know about %dir or recursive inclusion of directories, or who construct hardly readable spec files which hide the %files lists behind lots of macros which make it difficult to understand where files are stored. In some packages, unowned directories appear not before a package becomes desolate as packaging bugs pile up. A re-review would be justified, e.g. https://bugzilla.redhat.com/473593 If packagers *and* reviewers need not care about unowned directories anymore (perhaps because FESCo believes the umask fix is sufficient), then the packaging guideline ought to be dropped. Packagers and Reviewers at least ought to take a look at binary pkgs files lists with "rpm -qlvp" or "rpmls" to understand a pkg's file layout. From mschwendt at gmail.com Sun Feb 1 11:51:36 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 1 Feb 2009 12:51:36 +0100 Subject: Too many unowned directories In-Reply-To: <49858A57.8060406@redhat.com> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> Message-ID: <20090201125136.4b8b88f7.mschwendt@gmail.com> On Sun, 01 Feb 2009 12:41:11 +0100, Florian wrote: > As far as I can see right now there is only one thing that RPM could do: > Create a file requires to all directories that the packages places files in > and is not part of the package itself. From my (RPM) perspective this is a > good, save and simple to implement solution. So far, so good. It would make up a %dir entry for all directories not included in the package's %files list. > But it comes with the price of > yum requiring (and though downloading) the file list for each and every > transaction. Why that? There is no "Requires: /orphaned/directory" anywhere in the package. Yum does not and would not care about the files metadata at all. RPM would simply add the missing "%dir /orphaned/directory" on-the-fly during package installation. That would make it possible to remove the directory with the last package that owns it (RPM %dir refcount == 1 and directory being empty). From fedora at camperquake.de Sun Feb 1 13:16:42 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 1 Feb 2009 14:16:42 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> Message-ID: <20090201141642.635fb294@lain.camperquake.de> Hi. On Sun, 1 Feb 2009 05:12:46 +0200, Muayyad AlSadi wrote > the answer is rpmfusion-free > simply just like many free game emulator that has no free ROMs ..etc. That's the wrong way around. The emulators (which rpmfusion ships, but fedora does not) are code without content. This thread is about content without code. From chitlesh.goorah at gmail.com Sun Feb 1 13:28:45 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Sun, 1 Feb 2009 14:28:45 +0100 Subject: FEL's commitment lineup Message-ID: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> Hello there On Sat, Jan 31, 2009 at 12:04 AM, Kevin Kofler wrote: > Fedora is not a content distribution. It's a software distribution. We only > ship content which is directly related to software we ship: > https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content > > Fedora is not a content library, we cannot ship all the content in > existence, there's just too much of it. > > OVM cannot be used with any software in Fedora, so it also does not belong > into Fedora. What's the point of shipping content which cannot be used? > > The same rationale is also being applied to MP3 files, which are also not > permitted in Fedora. Fedora (the distribution) is the product of the Fedora Project. We all know this. FESCo looks after the welfare of the contributing members and the fedora packages. I am one of the contributing members and at the same time I look after the welfare of the opensource EDA community(not only packages) which are outside Fedora. The number of FEL users is directly proportional to the health of this opensource EDA community. The health of this opensource EDA community depends on the following items: - user base - worldwide - EDA developer base with hardware knowledge - more than 20 different upstream projects - Providers, Methodologies and design flows maintainers - FEL At this point we are outside the packaging environment and more EDA community development. However both are inter-related and under the name of Fedora Electronic Lab I'm trying to keep the balance. FEL users will develop hardware. One of Fedora's ground rules is about opensource and spreading the word. So with FEL, I'm trying to promote open hardware by spreading the word. However it would be nice to develop openhardware with opensource EDA software. It is my/FEL task to provide such tools that can make it possible and needs the technical demands. I would appreciate that steering committee should have the above notes in mind. I have closed the OVM package review request and if we have OVM support in the future, I'll reopen the bug. I'm sorry to say that the "doesn't provide OS user experience" is lame as an argument for FEL applications as it downgrades "hardware design user experience" on Fedora. Something FEL is fighting since more than 3 years now. My first email on the thread "Fedora Project, give me 20 Million Euros or Free Software" was to sync the Fedora Project with information about what is being done with respect to EDA and decisions/arguments should be taken wisely as most of the time it is like a domino effect on the work done in the past. Thereby hardware designers for openhardware will not have the tools to make the easy switch. Though, many will say FEL's user base is minority. I would rather point to what can be achieved. Have a brief look at this document and pictures. http://www-vlsi.stanford.edu/~jsolomon/dac_2001/chipmap.pdf (first doc, I found on google) High end hardware design is possible. Our ambassadors around the world will be proud to say: you can execute the whole design flow under fedora. Kind regards, Chitlesh From fedora at leemhuis.info Sun Feb 1 13:40:22 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Feb 2009 14:40:22 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> Message-ID: <4985A646.2010901@leemhuis.info> On 01.02.2009 04:12, Muayyad AlSadi wrote: > the answer is rpmfusion-free Just to set things straight: RPM Fusion's free repository is only used for packages that are "free" according to the Fedora licensing guidelines http://fedoraproject.org/wiki/Packaging/LicensingGuidelines Or, IOW, RPM Fusion free only contains software that normally would be acceptable for Fedora, but are not due to patent concerns. > simply just like many free game emulator that has no free ROMs ..etc. Hence emulators with non free RPMs are in RPM Fusion nonfree. CU knurd From nicolas.mailhot at laposte.net Sun Feb 1 13:42:58 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 01 Feb 2009 14:42:58 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <20090201141642.635fb294@lain.camperquake.de> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> Message-ID: <1233495778.13582.19.camel@arekh.okg> Le dimanche 01 f?vrier 2009 ? 14:16 +0100, Ralf Ertzinger a ?crit : > Hi. > > On Sun, 1 Feb 2009 05:12:46 +0200, Muayyad AlSadi wrote > > the answer is rpmfusion-free > > simply just like many free game emulator that has no free ROMs ..etc. > > That's the wrong way around. > The emulators (which rpmfusion ships, but fedora does not) are code > without content. This thread is about content without code. Either way, it's stuff that can't be used in Fedora without some proprietary bits we can't ship. The code vs content old debate is totally misguided IMHO. We want more free code. We want more free content. We want more free . We want to train our users to look for free first, and not complain about our lack of support for something else. And the only way to get more free (short of buying it to re-license it) is to ship it to reward people who create it with some public exposure. I would welcome a collection of music in the appropriate license and the appropriate formats?. That would enhance our music players. That would make a collection of free art available to free game authors. That would make average users aware there are other possibilities than P2P MP3 copyright breaking. If we're unable to demonstrate our users there are other options than mp3, we should not complain about all the hassles mp3 support causes us. The only relevant criterium is ?can it be used with pure free Fedora ships, or does it require a bunch of proprietary bytes we don't.? ? To take the ebook example: an ebook in a format we can read is ok, and we don't want the car too -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From chitlesh.goorah at gmail.com Sun Feb 1 13:45:04 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Sun, 1 Feb 2009 14:45:04 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <20090131111542.GB23533@amd.home.annexia.org> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131111542.GB23533@amd.home.annexia.org> Message-ID: <50baabb30902010545x66936470p47938d8f50a54219@mail.gmail.com> Some extra comments: On Sat, Jan 31, 2009 at 12:15 PM, Richard W.M. Jones wrote: > Can you summarise that in a few sentences? I gave up after several > paragraphs of verbiage. > > Rich. Read the Abstract. It was written to be straight forward. On 2009/1/31 Kevin Fenzi > This is a great area to get folks involved in using and perhaps someday > contributing to Fedora. The EDA developers are hardware designers, people who are not excited by GTK/QT API but current/voltage/capacitances/slew rate/. For Fedora, you will need software developers. I would rather let the existing EDA developers work and improve their design tools. On the other hand, I welcome new Fedora contributors to include these design tools into fedora and help to maintain the balance. Currently there are 3 layers in this approach: 1) EDA developers outside fedora 2) Fedora contributors 3) FEL Users The main thing is we should first know where we stand! During the 3 years, I have seen many EDA developers have migrated to Fedora/Centos. Svilen Kvilen has commented about this thread. He is the upstream developer for Toped and is using Toped in his daily paid job. It is worth looking at. https://www.redhat.com/archives/fedora-electronic-lab-list/2009-January/msg00016.html regards, Chitlesh From angel at linux.org.bd Sun Feb 1 13:44:35 2009 From: angel at linux.org.bd (Ashiqur Rahman Angel) Date: Sun, 1 Feb 2009 19:44:35 +0600 Subject: Fedora 11: What do we expect? Message-ID: Hi, As Frank Murphy suggested, I am forwarding this mail. Hi, It?s almost one year, I am with the Fedora community. In this one year, I met so many great people from Fedora community. I have visited hundreds of forums, mailing lists. I meet so many people who uses Fedora (also who doesn?t). I have learned so many things from them. Some of them are happy using Fedora and some them are not. And I think, as a community member, it?s my responsibility to inform you guys about some issues that I think, why people doesnt like to use Fedora or switching to other distros. And something, that we need to fix. 1. Need to include RPM Fusion with Fedora 11 default installation (but not activated, like Fedora test repo or raw hide, as we don?t include proprietary software). If this is not possible (may be because of some legal issue), then I?ll say, we need a working GUI solution to install RPM Fusion. According to RPM Fusion they explained a GUI solution to install the repo, but most of the time, it doesnt work at all (I myself, tested thousands time, also so many people there has, who tried, I searched for the solution, everyone give me CLI solution). And KPackage Kit can?t install it. So we need a solution that will work for GNOME and KDE both. 2. Need a GUI solution to install nVidia and ATI driver, that will automatically install the appropriate driver (Ubuntu has a GUI *Hardware Drivers *options that automatically download and install the driver, also they have Envy, its another GUI solution) 3. Need a GUI solution to install all kind of proprietary Multimedia codecs (Ubuntu has ubuntu-restricted-extras, they simply select it from package manager, and it installs all kind of codecs including JAVA) 4. Need a complete GUI solution to install softwares offline from cache (ofcourse if it can fix the dependency) or DVD Media. 5. There has a very easy way to install a rpm package from CLI (one single package, that has not any dependency issue or if it has, it?s possible to install the package by ignoring it). But from Fedora 9, GUI double click rpm install doesnt work at all. So, we need a GUI solution of it. 6. Need to add CD/DVD repo with Fedora 11 default installation, so people can use DVD to install softwares. 7. From /etc/yum.conf we need to edit keepcache=0 to 1 as default. So people can use the cache to install software later or to some other PC. Many of you will say, why we are following Ubuntu? Well, I?ll say, no, we are not following them. This is the truth, what users want. And many of you will think, this ideas are stupid, but truth is If this issues we can fix, for sure, so many people will start using Fedora. My apologies, if I am wrong anywhere. -- Angel GPG key: 0x34001F46 Bangladesh Linux Users Alliance Fedora Ambassador Bangladesh http://fedoraproject.org/wiki/User:Angel Fedora -- Freedom? and rapid innovation -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Sun Feb 1 14:13:14 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Feb 2009 15:13:14 +0100 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <4985ADFA.4040301@leemhuis.info> Hi! Just a few notes: On 01.02.2009 14:44, Ashiqur Rahman Angel wrote: > 1. Need to include RPM Fusion with Fedora 11 default installation (but > not activated, like Fedora test repo or raw hide, as we don?t include > proprietary software). That afaics for sure won't happen due to legal concerns. > If this is not possible (may be because of some > legal issue), then I?ll say, we need a working GUI solution to install > RPM Fusion. According to RPM Fusion > they explained a GUI solution to install the repo, but most of the time, > it doesnt work at all (I myself, tested thousands time, also so many > people there has, who tried, I searched for the solution, everyone give > me CLI solution). Well, then really should have talked to the guys from RPM Fusion immediately to make sure they are aware of it. Only then it can be fixed/the docs be improved. > And KPackage Kit can?t install it. So we need a > solution that will work for GNOME and KDE both. /me wonders if that bug was fixed /me wonders if anybody reported that bug at all in b.r.c /me puts "talk to rdieter about it" on his todo list > 2. Need a GUI solution to install nVidia and ATI driver, that will > automatically install the appropriate driver (Ubuntu has a GUI /Hardware > Drivers /options that automatically download and install the driver, > also they have Envy, its another GUI solution) That's was discussed recently on the rpmfusion mailing list; you'll find some more details in this (quite long) thread: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-January/003639.html Feel free to join the discussion. > 3. Need a GUI solution to install all kind of proprietary Multimedia > codecs (Ubuntu has ubuntu-restricted-extras, they simply select it from > package manager, and it installs all kind of codecs including JAVA) In the thread mentioned above there are also other ideas discussed that should make enabling and using RPM Fusion easier. But that will be a whole lot of work and RPM Fusion has only a very small contributor base when compared to Fedora (and most of the RPM Fusion guys are very active Fedora contributors as well). So it'll likely take a while until some of the ideas that are discussed get realized. > [...] CU knurd From happyharrysco1 at yahoo.co.uk Sun Feb 1 14:47:51 2009 From: happyharrysco1 at yahoo.co.uk (phil) Date: Sun, 01 Feb 2009 14:47:51 +0000 Subject: look at this: samsung nc10 bootchart with mobil V2 In-Reply-To: <20090131223648.GA25127@srcf.ucam.org> References: <49821FD3.4020801@redhat.com> <1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com> <20090130035404.GC4570@nostromo.devel.redhat.com> <1233288493.3698.67.camel@localhost.localdomain> <49827FAF.3050306@redhat.com> <20090130150046.GA8869@nostromo.devel.redhat.com> <498333E0.3040806@redhat.com> <20090131011450.GB24549@srcf.ucam.org> <4983BBB4.1000807@redhat.com> <20090131223648.GA25127@srcf.ucam.org> Message-ID: <4985B617.2040801@yahoo.co.uk> On Fri, Jan 30, 2009 at 09:47:16PM -0500, Brian Maly wrote: >> Good info on the Vaio Z-series. Out of curiosity, is there a UEFI shell/ >> console accessible on the Acer One? Or is this permanently in legacy BIOS >> compatibility mode? Dont know if you actually know or have access to the >> hardware... >> i have a one in my possession so if there is any way to find out just let me know and i'll try From kevin.kofler at chello.at Sun Feb 1 14:49:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 01 Feb 2009 15:49:29 +0100 Subject: FEL's commitment lineup References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > FEL users will develop hardware. One of Fedora's ground rules is about > opensource and spreading the word. So with FEL, I'm trying to promote > open hardware by spreading the word. However it would be nice to > develop openhardware with opensource EDA software. But how does shipping content which does not work without proprietary EDA software further that goal? Promoting proprietary software which happens to run on Fedora is not what Fedora is about. Kevin Kofler From kevin.kofler at chello.at Sun Feb 1 14:53:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 01 Feb 2009 15:53:19 +0100 Subject: Fedora 11: What do we expect? References: Message-ID: Ashiqur Rahman Angel wrote: > And KPackage Kit can?t install it. That's a KPackageKit bug. It needs to be fixed in KPackageKit, not hacked around. As for your other suggestions: * No, Fedora will not make it easier to install proprietary software, it's against Fedora's objectives. You should NOT install that proprietary software. * No, Fedora will not make it easier to install software which violates US software patents as that would make it a target for lawsuits. * You're not the first one to make these suggestions. Parroting them like a broken record isn't going to change any of the above. Sorry. Kevin Kofler From kevin.kofler at chello.at Sun Feb 1 14:58:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 01 Feb 2009 15:58:28 +0100 Subject: OpenSSL symlink hack Message-ID: Hi, can the OpenSSL compat symlink hack be dropped now that we have the alpha practically out of the door? I think we want to make sure all the packages get rebuilt against the new ABI ASAP (and most already did), and the symlinks are also unreliable. Kevin Kofler From mzerqung at 0pointer.de Sun Feb 1 15:28:29 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 1 Feb 2009 16:28:29 +0100 Subject: Why do we disable esd in libgnome? In-Reply-To: <3528361a0901312316l65d22020x394a299a6eefe287@mail.gmail.com> References: <3528361a0901312316l65d22020x394a299a6eefe287@mail.gmail.com> Message-ID: <20090201152829.GA25337@tango.0pointer.de> On Sun, 01.02.09 15:16, ??? (hanpingtian at gmail.com) wrote: > hi Great list, > > I just find that the libgnome-2.24.1-7.fc10 has been disabled "esd" when it > is built. > This has caused the "gnome_sound_play()" doesn't work and some package such > as > "stardict" cannot play sound. > > Why should we disable esd in libgnome? Could we enable it? esd is considered obsolete. gnome_sound_play() has been replaced by the more generic, powerful, platform-independant and dektop-agnostic functionality found in libcanberra. http://0pointer.de/lennart/projects/libcanberra/ Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From angel at linux.org.bd Sun Feb 1 15:39:21 2009 From: angel at linux.org.bd (Ashiqur Rahman Angel) Date: Sun, 1 Feb 2009 10:39:21 -0500 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: I didnt know this, Fedora's objective is, to make proprietary software installation difficult. If this is, then I am sorry for the mail, I dont have anything to say. But as far as I know, this is not the Fedora's objective as refer to http://fedoraproject.org/wiki/Overview. However, thanks to Thorsten Leemhuis, for his wonderful reply. Thanks for the good news. Atleast I can hope, soon we will get good solutions of this issues. I am going to join RPM Fusion list. Thanks again. On Sun, Feb 1, 2009 at 9:53 AM, Kevin Kofler wrote: > Ashiqur Rahman Angel wrote: > > And KPackage Kit can?t install it. > > That's a KPackageKit bug. It needs to be fixed in KPackageKit, not hacked > around. > > As for your other suggestions: > * No, Fedora will not make it easier to install proprietary software, it's > against Fedora's objectives. You should NOT install that proprietary > software. > * No, Fedora will not make it easier to install software which violates US > software patents as that would make it a target for lawsuits. > * You're not the first one to make these suggestions. Parroting them like a > broken record isn't going to change any of the above. Sorry. > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Angel GPG key: 0x34001F46 Bangladesh Linux Users Alliance Fedora Ambassador Bangladesh http://fedoraproject.org/wiki/User:Angel Fedora -- Freedom? and rapid innovation -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Sun Feb 1 15:59:46 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 01 Feb 2009 16:59:46 +0100 Subject: Why do we disable esd in libgnome? References: <3528361a0901312316l65d22020x394a299a6eefe287@mail.gmail.com> <20090201152829.GA25337@tango.0pointer.de> Message-ID: Lennart Poettering wrote: > esd is considered obsolete. gnome_sound_play() has been replaced by > the more generic, powerful, platform-independant and dektop-agnostic > functionality found in libcanberra. But existing programs use that function, and disabling libesd support (which works with PulseAudio) means it'll try to use OSS output (which doesn't work with PulseAudio). Kevin Kofler From debarshi.ray at gmail.com Sun Feb 1 16:09:30 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 1 Feb 2009 21:39:30 +0530 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> > 4. Need a complete GUI solution to install softwares offline from cache > (ofcourse if it can fix the dependency) or DVD Media. PackageKit has it: http://blogs.gnome.org/hughsie/2008/10/09/service-pack-gui/ Cheerio, Debarshi From sandeen at redhat.com Sun Feb 1 16:17:52 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 01 Feb 2009 10:17:52 -0600 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <4985CB30.4060609@redhat.com> Ashiqur Rahman Angel wrote: > I didnt know this, Fedora's objective is, to make proprietary software > installation difficult. That's not what he said. > If this is, then I am sorry for the mail, I dont > have anything to say. > > But as far as I know, this is not the Fedora's objective as refer to > http://fedoraproject.org/wiki/Overview. > > However, thanks to Thorsten Leemhuis, for his wonderful reply. Thanks > for the good news. Atleast I can hope, soon we will get good solutions > of this issues. > > I am going to join RPM Fusion list. That really is the right place for the discussion of most of your issues. -Eric From bruno at wolff.to Sun Feb 1 17:47:47 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 1 Feb 2009 11:47:47 -0600 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <20090201174747.GA28805@wolff.to> On Sun, Feb 01, 2009 at 19:44:35 +0600, Ashiqur Rahman Angel wrote: > > 2. Need a GUI solution to install nVidia and ATI driver, that will > automatically install the appropriate driver (Ubuntu has a GUI *Hardware > Drivers *options that automatically download and install the driver, also > they have Envy, its another GUI solution) Fedora already comes with approiate drivers for that hardware. People who don't like the Fedora drivers should go to whoever is providing the alternate drivers for help installing them. By F12, ATI's stuff shouldn't even be an issue since they have released specs and the drivers included in Fedora should be superior in all respects to the alternate drivers around the F12 time frame. From walters at verbum.org Sun Feb 1 18:48:09 2009 From: walters at verbum.org (Colin Walters) Date: Sun, 1 Feb 2009 13:48:09 -0500 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: <20090131160728.GA28571@host0.dyn.jankratochvil.net> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> Message-ID: On Sat, Jan 31, 2009 at 11:07 AM, Jan Kratochvil wrote: > On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote: >> But our live images are already heavily size-constrained. There's definitely >> no room for multiple kernels on the KDE live image, and I don't think the >> GNOME image has any room left either. > > Was already discussed the requirement of CDs nowadays? Even the oldest > computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin. >From the desktop perspective I like having something around CD size since it keeps us focused, in terms of: * Even if someone can burn a DVD, it's a lot to download; keep in mind not everyone has fast Internet * Having higher quality software percentage wise * Not losing focus into developer tools, scientific analysis, creative tools, 3D games etc. The desktop image is a desktop core. * Encouraging us to reduce technology duplication in that core set The fact that it can be burned to a physical CD is a bonus. From frankly3d at fedoraproject.org Sun Feb 1 18:53:25 2009 From: frankly3d at fedoraproject.org (Frank Murphy) Date: Sun, 01 Feb 2009 18:53:25 +0000 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: <20090131160728.GA28571@host0.dyn.jankratochvil.net> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> Message-ID: <4985EFA5.2020905@fedoraproject.org> Jan Kratochvil wrote: > On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote: >> But our live images are already heavily size-constrained. There's definitely >> no room for multiple kernels on the KDE live image, and I don't think the >> GNOME image has any room left either. > > Was already discussed the requirement of CDs nowadays? Even the oldest > computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin. > Maybe not if you are in a developing economy. Where your PC is a >=P1 | >=P3 and it came with a CD. Even it the developed world. You have an old box to put XFCE\LXDe on, why would you want a DVD install, when a slim CD would do? There are arguments for both cd and dvd. Frank From kanarip at kanarip.com Sun Feb 1 19:09:20 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 01 Feb 2009 20:09:20 +0100 Subject: FEL's commitment lineup In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> Message-ID: <4985F360.7050703@kanarip.com> Kevin Kofler wrote: > Chitlesh GOORAH wrote: >> FEL users will develop hardware. One of Fedora's ground rules is about >> opensource and spreading the word. So with FEL, I'm trying to promote >> open hardware by spreading the word. However it would be nice to >> develop openhardware with opensource EDA software. > > But how does shipping content which does not work without proprietary EDA > software further that goal? > How does a general question like that apply to this specific situation? To me, it's clear that Chitlesh would like to see what is Free to be available in Fedora, to encourage further development of what is not Free yet. This is most likely to go down one way or the other, or not at all; either Chitlesh runs his own repository with the packages not accepted in Fedora, potentially ending up with a contributor base for said packages -completely outside Fedora, or it's not going to happen at all. Either way, how does the "code vs. content" argument help Fedora, it's current contributors and it's potential future contributors, in this specific case? > Promoting proprietary software which happens to run on Fedora is not what > Fedora is about. > http://fedoraproject.org/wiki/Flash Kind regards, Jeroen van Meeuwen -kanarip From kevin.kofler at chello.at Sun Feb 1 19:28:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 01 Feb 2009 20:28:21 +0100 Subject: FEL's commitment lineup References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: Jeroen van Meeuwen wrote: > How does a general question like that apply to this specific situation? > To me, it's clear that Chitlesh would like to see what is Free to be > available in Fedora, to encourage further development of what is not > Free yet. But there are other people in the field who believe this is counterproductive, see for example the reply from the Toped author: https://www.redhat.com/archives/fedora-electronic-lab-list/2009-January/msg00016.html >> Promoting proprietary software which happens to run on Fedora is not what >> Fedora is about. > > http://fedoraproject.org/wiki/Flash That wiki page is hardly "what Fedora is about" and in fact I believe it is counterproductive. We should instead point people to Gnash and/or Swfdec. Or just not recommend consuming Flash content at all, just like we do for DVDs and MP3s. Kevin Kofler From kevin.kofler at chello.at Sun Feb 1 19:31:04 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 01 Feb 2009 20:31:04 +0100 Subject: Fedora 11: What do we expect? References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> Message-ID: Debarshi Ray wrote: > PackageKit has it: > http://blogs.gnome.org/hughsie/2008/10/09/service-pack-gui/ That's only in gnome-packagekit though, isn't it? Or is this implemented in KPackageKit? Kevin Kofler From frankly3d at fedoraproject.org Sun Feb 1 19:54:28 2009 From: frankly3d at fedoraproject.org (Frank Murphy) Date: Sun, 01 Feb 2009 19:54:28 +0000 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <4985FDF4.2070201@fedoraproject.org> Ashiqur Rahman Angel wrote: > Hi, > > As Frank Murphy suggested, I am forwarding this mail. > > Clarification. https://www.redhat.com/archives/fedora-marketing-list/2009-February/msg00006.html Frank From forum at ru.bir.ru Sun Feb 1 20:45:13 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sun, 01 Feb 2009 23:45:13 +0300 Subject: New package from one source In-Reply-To: <4980D47C.1040602@fedoraproject.org> References: <20090119221149.GA10949@nostromo.devel.redhat.com> <20090120184236.GA10482@nostromo.devel.redhat.com> <497A53CD.1050605@fedoraproject.org> <4980D47C.1040602@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Pavel Alexeev (aka Pahan-Hubbitus) wrote: > >> As I mention above, what about your first link - main apache rpm >> package fully ignore this guidelines! > > These are more best practises and aren't part oaf the packaging > guidelines except as a reference but maintainers have to ultimately make > their own decisions. If you find major deviations from upstream, it is > useful to talk to the maintainers and understand why. Off course, you talk about "maintainers have to ultimately make their own decisions." but forbidden this right for the Fedora users who want use mpm-itk for example?? >> But why you are not consider Steinar H. Gunderson as upstream >> amintainer of apache mpm-itk??? > > This is a patchset for upstream. In other words, if I (or any other) make "Apache fork", copy it source, patch with this patch and pack in separate source tarball on separate URL (on Sourceforge or any else) you are accept such package into Fedora??? >> In any case, as maintainer of package I take care about maintenance >> load by this rpm. As I remember, it had not any urgent issues with >> adaptation to current releases of apache for the past year or even more. >> >> P.S. I'm write mail to Steinar H. Gunderson with question why it is >> not in upstream... > > Yes, that is the key question to get an answer for. Whereas you missing note about low maintenance load I agree - it is main question. So, I get answer - apache upstream don't want it, mainly out of worries around the server running as root until it has processed the request header. http://marc.info/?l=apache-httpd-dev&m=118274310508712&w=2 Eventually even in this discussion none of equal by efficient solution was be suggested (Solutions by proxy requests on other instances of apache initially was be admitted by author as very slow)! And one more. I asked Steinar H. Gunderson and He assure me what he planed maintain this patch in the future (again actual question about fork). From cdahlin at redhat.com Sun Feb 1 21:17:37 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Sun, 01 Feb 2009 16:17:37 -0500 Subject: Fedora 11: What do we expect? In-Reply-To: References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> Message-ID: <49861171.3070403@redhat.com> Kevin Kofler wrote: > Debarshi Ray wrote: > >> PackageKit has it: >> http://blogs.gnome.org/hughsie/2008/10/09/service-pack-gui/ >> > > That's only in gnome-packagekit though, isn't it? Or is this implemented in > KPackageKit? > > Kevin Kofler > > Hooray duplication of effort! /me wonders how much of this could be solved by writing a wxPackageKit and letting people choose the appropriate wxWidgets implementation. --CJD From pemboa at gmail.com Sun Feb 1 21:30:47 2009 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 1 Feb 2009 15:30:47 -0600 Subject: Fedora 11: What do we expect? In-Reply-To: <49861171.3070403@redhat.com> References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> <49861171.3070403@redhat.com> Message-ID: <16de708d0902011330t4559ea63tb3ff5458e0d50add@mail.gmail.com> On Sun, Feb 1, 2009 at 3:17 PM, Casey Dahlin wrote: > Kevin Kofler wrote: >> >> Debarshi Ray wrote: >> >>> >>> PackageKit has it: >>> http://blogs.gnome.org/hughsie/2008/10/09/service-pack-gui/ >>> >> >> That's only in gnome-packagekit though, isn't it? Or is this implemented >> in >> KPackageKit? >> >> Kevin Kofler >> >> > > Hooray duplication of effort! > > /me wonders how much of this could be solved by writing a wxPackageKit and > letting people choose the appropriate wxWidgets implementation. It's more than the widget set that will likely be different. the Gnome version will likely have too few options to be useful. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From aaronngray.lists at googlemail.com Sun Feb 1 22:38:01 2009 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Sun, 1 Feb 2009 22:38:01 -0000 Subject: Fedora 11: What do we expect? References: Message-ID: <3B003991C6FA44D7B9AF48D42732EAFE@HPLAPTOP> Support for legacy SCSI devices, that worked on older releases. Please :) Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Sun Feb 1 22:59:39 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 1 Feb 2009 22:59:39 +0000 Subject: Fedora 11: What do we expect? In-Reply-To: <3B003991C6FA44D7B9AF48D42732EAFE@HPLAPTOP> References: <3B003991C6FA44D7B9AF48D42732EAFE@HPLAPTOP> Message-ID: <364d303b0902011459k146855b8l5b5bef8a27c1a0e0@mail.gmail.com> 2009/2/1 Aaron Gray : > Support for legacy SCSI devices, that worked on older releases. This list has support for linking to bugs regarding this. :) -- Christopher Brown From ryanlerch at gmail.com Mon Feb 2 01:10:17 2009 From: ryanlerch at gmail.com (ryan lerch) Date: Mon, 2 Feb 2009 11:10:17 +1000 Subject: Fedora Release Notes In-Reply-To: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> References: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> Message-ID: <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> Over at fedora-docs, there is ongoing discussion on the scope of the release notes. At present, the release notes have evolved from a document containing the relevant new features and important bug-fixes into a document containing those items as well as an assortment of extra basic documentation and howtos. For example, take the "Live Image" section in the f10 notes [1], this is basically a brief overview on Live Images (which were not a new feature in f10.) The fedora-docs project would like to get the input from the developers on the release notes. Should we restrict the release notes to being a document of the new and exciting features in the newest release, and move the older, not so fresh documentation into the relevant guides (such as the install guide)? Any other suggestions on the possible scope and direction of the release notes are appreciated also! cheers, ryanlerch ryanlerch at fedoraproject.org [1] https://fedoraproject.org/wiki/Docs/Beats/Live From kevin.kofler at chello.at Mon Feb 2 01:11:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 02 Feb 2009 02:11:38 +0100 Subject: Fedora 11: What do we expect? References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> <49861171.3070403@redhat.com> Message-ID: Casey Dahlin wrote: > /me wonders how much of this could be solved by writing a wxPackageKit > and letting people choose the appropriate wxWidgets implementation. wxWidgets has no Qt/KDE backend. Nor even a GNOME one, just pure GTK+. Especially system services will often need more integration. Though gnome-packagekit in particular doesn't use that much of GNOME. On the other hand, KPackageKit uses quite some KDE stuff: it has a kded4 service and integrates with systemsettings. There are also separate HIGs for KDE and GNOME. Kevin Kofler From kanarip at kanarip.com Mon Feb 2 01:13:24 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 02 Feb 2009 02:13:24 +0100 Subject: FEL's commitment lineup In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: <498648B4.8060900@kanarip.com> Kevin Kofler wrote: > Jeroen van Meeuwen wrote: >> How does a general question like that apply to this specific situation? >> To me, it's clear that Chitlesh would like to see what is Free to be >> available in Fedora, to encourage further development of what is not >> Free yet. > > But there are other people in the field who believe this is > counterproductive, see for example the reply from the Toped author: > https://www.redhat.com/archives/fedora-electronic-lab-list/2009-January/msg00016.html > I fail to see where counterproductivity as such is mentioned, but I can say this: That's a very, very different discussion then "code vs. content". Also, I do read: "And now the next question - is it feasible to develop an open source SystemVerilog simulator in the near feature? I'm sorry to say - but it seems not. Not soon. Too little resources for a too big task. I'll be happy if somebody proves me wrong." Which to me reads like it needs time, community, and support -not counterproductivity. Fedora can offer these three for free, and may benefit from it. It's a nifty, kinky line of business I do not understand the least bit about, but I fail to see where this is negative and therefor not accepted into Fedora. Kind regards, Jeroen van Meeuwen -kanarip From kevin.kofler at chello.at Mon Feb 2 01:38:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 02 Feb 2009 02:38:59 +0100 Subject: FEL's commitment lineup References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> <498648B4.8060900@kanarip.com> Message-ID: Jeroen van Meeuwen wrote: > I fail to see where counterproductivity as such is mentioned There: | So - the bottom line is that it's very doubtful how the open source EDA | community will benefit from taking aboard VMM or OVM. This is not our | fight at the end of the day!? And we should not take side there. Think | about it - this thing will make their bait to look more juicy, they will | most likely put it into their fliers, they will get contributions and | resources from the community (packaging and maybe more) in return for | what? That's what I call a free beer and we all believe Fedora is not | about it. > That's a very, very different discussion then "code vs. content". I don't think it is that different, if at all. OVM is more like content than code, as its purpose is not to be a program you want to run on your computer. And even if you consider it code, then the issue that it's useless without proprietary software is still exactly the same. > Also, I do read: > > "And now the next question - is it feasible to develop an open source > SystemVerilog simulator in the near feature? I'm sorry to say - but it > seems not. Not soon. Too little resources for a too big task. I'll be > happy if somebody proves me wrong." > > Which to me reads like it needs time, community, and support -not > counterproductivity. Fedora can offer these three for free, and may > benefit from it. It's a nifty, kinky line of business I do not > understand the least bit about, but I fail to see where this is negative > and therefor not accepted into Fedora. That's a very selective reading of his post, and I believe you're missing his point entirely! See his introduction: | I'm sorry Chitlesh, about how do you feel, but I'm sure that after some | time you'll realize that actually "they" are probably right. I'll give you | a bit different look to the problem. Sorry for the long post... and his conclusion: | P.S. Chitlesh, it is not a failure. It might have been if you succeeded. | Sometimes before you learn how to do things you have to learn how not to | do them. Keep up the good work. I don't read the paragraph you quoted as a plea for help from the Fedora community at all. Writing a SystemVerilog simulator needs people familiar with the domain and interested in volunteering for it, not your average packager or even programmer. The developers will have to come from the Electronics community. And in any case, shipping OVM is not the way to recruit such people at all. People interested in coding such a simulator can easily get OVM directly from upstream. Kevin Kofler From hanpingtian at gmail.com Mon Feb 2 01:46:24 2009 From: hanpingtian at gmail.com (=?GB2312?B?xr3M7Lqr?=) Date: Mon, 2 Feb 2009 09:46:24 +0800 Subject: Why do we disable esd in libgnome? In-Reply-To: References: <3528361a0901312316l65d22020x394a299a6eefe287@mail.gmail.com> <20090201152829.GA25337@tango.0pointer.de> Message-ID: <3528361a0902011746s7bccdb23x91e09789a68afce6@mail.gmail.com> Right. How about enable esd in libgnome please? 2009/2/1 Kevin Kofler > Lennart Poettering wrote: > > esd is considered obsolete. gnome_sound_play() has been replaced by > > the more generic, powerful, platform-independant and dektop-agnostic > > functionality found in libcanberra. > > But existing programs use that function, and disabling libesd support > (which > works with PulseAudio) means it'll try to use OSS output (which doesn't > work with PulseAudio). > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Mon Feb 2 02:35:23 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 02 Feb 2009 03:35:23 +0100 Subject: FEL's commitment lineup In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> <498648B4.8060900@kanarip.com> Message-ID: <49865BEB.7090301@kanarip.com> Kevin Kofler wrote: > Jeroen van Meeuwen wrote: >> I fail to see where counterproductivity as such is mentioned > > There: > | So - the bottom line is that it's very doubtful how the open source EDA > | community will benefit from taking aboard VMM or OVM. This is not our > | fight at the end of the day!? And we should not take side there. Think > | about it - this thing will make their bait to look more juicy, they will > | most likely put it into their fliers, they will get contributions and > | resources from the community (packaging and maybe more) in return for > | what? That's what I call a free beer and we all believe Fedora is not > | about it. > Ghe, what I read here is passiveness and speculation. >> That's a very, very different discussion then "code vs. content". > > I don't think it is that different, if at all. OVM is more like content than > code, as its purpose is not to be a program you want to run on your > computer. And even if you consider it code, then the issue that it's > useless without proprietary software is still exactly the same. > >> Also, I do read: >> >> "And now the next question - is it feasible to develop an open source >> SystemVerilog simulator in the near feature? I'm sorry to say - but it >> seems not. Not soon. Too little resources for a too big task. I'll be >> happy if somebody proves me wrong." >> >> Which to me reads like it needs time, community, and support -not >> counterproductivity. Fedora can offer these three for free, and may >> benefit from it. It's a nifty, kinky line of business I do not >> understand the least bit about, but I fail to see where this is negative >> and therefor not accepted into Fedora. > > That's a very selective reading of his post, and I believe you're missing > his point entirely! > 1) I didn't say it was all I read from his post; you cannot say that this is a very selective reading. From what you can tell, this is a very selective quote, at most. 2) I'm not missing his point, I do see it (but you can't tell), I just so happen to disagree (to some extend). It's not like I'm saying this content should go in, you know. > See his introduction: > | I'm sorry Chitlesh, about how do you feel, but I'm sure that after some > | time you'll realize that actually "they" are probably right. I'll give you > | a bit different look to the problem. Sorry for the long post... > and his conclusion: > | P.S. Chitlesh, it is not a failure. It might have been if you succeeded. > | Sometimes before you learn how to do things you have to learn how not to > | do them. Keep up the good work. > > I don't read the paragraph you quoted as a plea for help from the Fedora > community at all. That's not how I read it either. Writing a SystemVerilog simulator needs people familiar > with the domain and interested in volunteering for it, not your average > packager or even programmer. The developers will have to come from the > Electronics community. And in any case, shipping OVM is not the way to > recruit such people at all. People interested in coding such a simulator > can easily get OVM directly from upstream. > I guess I'm done talking; I've tried to make my point, I hope you got it. Kind regards, Jeroen van Meeuwen -kanarip From oget.fedora at gmail.com Mon Feb 2 03:03:27 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sun, 1 Feb 2009 22:03:27 -0500 Subject: Problem with updates? In-Reply-To: References: Message-ID: On Sat, Jan 31, 2009 at 5:45 PM, freeslkr wrote: > Does anyone here know why updates announced a couple of days ago, > including security updates, haven't shown up in the repos? > I was wondering about the same thing. Is there something wrong? Orcan From ianweller at gmail.com Mon Feb 2 03:26:32 2009 From: ianweller at gmail.com (Ian Weller) Date: Sun, 1 Feb 2009 21:26:32 -0600 Subject: Fedora Release Notes In-Reply-To: <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> References: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> Message-ID: <20090202032632.GA13162@gmail.com> On Mon, Feb 02, 2009 at 11:10:17AM +1000, ryan lerch wrote: > Over at fedora-docs, there is ongoing discussion on the scope of the > release notes. At present, the release notes have evolved from a > document containing the relevant new features and important bug-fixes > into a document containing those items as well as an assortment of > extra basic documentation and howtos. For example, take the "Live > Image" section in the f10 notes [1], this is basically a brief > overview on Live Images (which were not a new feature in f10.) > > The fedora-docs project would like to get the input from the > developers on the release notes. Should we restrict the release notes > to being a document of the new and exciting features in the newest > release, and move the older, not so fresh documentation into the > relevant guides (such as the install guide)? > > Any other suggestions on the possible scope and direction of the > release notes are appreciated also! > You have to have a balance between verbosity and brevity because if a document is too long, someone will prolong reading it. Perhaps if the how-tos and helpful tips were all in a certain section, the release notes would not have this problem, and also have an added convenience of having even more helpful information. -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From petersen at redhat.com Mon Feb 2 03:31:38 2009 From: petersen at redhat.com (Jens Petersen) Date: Sun, 1 Feb 2009 22:31:38 -0500 (EST) Subject: Why do we disable esd in libgnome? In-Reply-To: <3528361a0902011746s7bccdb23x91e09789a68afce6@mail.gmail.com> Message-ID: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "???" wrote: > Right. How about enable esd in libgnome please? I suggest you file a bug in bugzilla if there isn't one already and see what happens. From ivazqueznet at gmail.com Mon Feb 2 03:56:13 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 01 Feb 2009 22:56:13 -0500 Subject: [SPAM] rpms/vollkorn-fonts/devel import.log, NONE, 1.1 vollkorn-fonts-fontconfig.conf, NONE, 1.1 vollkorn-fonts.spec, NONE, 1.1 vollkorn.otf, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <20090201222445.6E6187011B@cvs1.fedora.phx.redhat.com> References: <20090201222445.6E6187011B@cvs1.fedora.phx.redhat.com> Message-ID: <1233546973.26470.14.camel@ignacio.lan> On Sun, 2009-02-01 at 22:24 +0000, Paul Lange wrote: > Author: palango > > Update of /cvs/pkgs/rpms/vollkorn-fonts/devel > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19443/devel > > Modified Files: > .cvsignore sources > Added Files: > import.log vollkorn-fonts-fontconfig.conf vollkorn-fonts.spec > vollkorn.otf > Log Message: > * Fri Jan 30 2009 Paul Lange - 1.008-1 > - initial packaging Please move vollkorn.otf into the lookaside cache via 'make upload', then remove it from cvs. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Mon Feb 2 08:35:37 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Feb 2009 09:35:37 +0100 Subject: Too many unowned directories In-Reply-To: <49858A57.8060406@redhat.com> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> Message-ID: <4986B059.30108@hhs.nl> Florian Festi wrote: > Richard W.M. Jones wrote: >> I don't know if you agree with me, but I think the _right_ way to >> solve this is once in RPM, not 48235 times over in all the packages in >> Fedora. Even if the RPM implementation is a bit tricky, it's surely >> easier than pushing this job down to every packager. > > As far as I can see right now there is only one thing that RPM could do: > Create a file requires to all directories that the packages places files > in and is not part of the package itself. From my (RPM) perspective this > is a good, save and simple to implement solution. But it comes with the > price of yum requiring (and though downloading) the file list for each > and every transaction. So you solve one problem by creating a new one. > Of course this new problem can surly also be solved by: > > > > PS: If someone knows better solutions feel free to discuss them here or > on rpm-maint at lists.rpm.org > What about Panu's suggestion to just abort the install when trying to install a file in to a non-existing directory, instead of creating the dir on the fly. This will not catch all cases, but will catch a lot, and is really easy to implement (I think). We could even complement this by also refusing to remove a package if *owned* files are still left in a dir which it owns (and no other packages own). Then we catch all error cases AFAIK. This means people will still need to manually get directory ownership right, but if their just build rpm fails to install they will learn soon enough! Regards, Hans From hughsient at gmail.com Mon Feb 2 08:33:39 2009 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 02 Feb 2009 08:33:39 +0000 Subject: Fedora 11: What do we expect? In-Reply-To: References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> <49861171.3070403@redhat.com> Message-ID: <1233563619.3444.6.camel@hughsie-work.lan> On Mon, 2009-02-02 at 02:11 +0100, Kevin Kofler wrote: > wxWidgets has no Qt/KDE backend. Nor even a GNOME one, just pure GTK > +. > Especially system services will often need more integration. Though > gnome-packagekit in particular doesn't use that much of GNOME. On the > other hand, KPackageKit uses quite some KDE stuff: it has a kded4 > service and integrates with systemsettings. > There are also separate HIGs for KDE and GNOME. Totally, and GConf vs. Kconf (or whatever it's called now). The fact that there are seporate frontends is a really good thing. There's also an EFL frontend written for a mobile phone. Writing a frontend is pretty easy as all the logic is in the backend. A simple wxWidgets frontend is a couple of days work. Richard. From rawhide at fedoraproject.org Mon Feb 2 08:34:39 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 2 Feb 2009 08:34:39 +0000 (UTC) Subject: rawhide report: 20090202 changes Message-ID: <20090202083439.7EA5D1F82DC@releng2.fedora.phx.redhat.com> Compose started at Mon Feb 2 06:01:03 UTC 2009 New package cf-bonveno-fonts A fun font by Barry Schwartz New package gimp-fourier-plugin A simple plug-in to do fourier transform on your image New package oldstandard-sfd-fonts Old Standard True-Type Fonts New package pdfshuffler PDF file merging, rearranging, and splitting New package perl-Exception-Base Lightweight exceptions New package perl-MooseX-Daemonize Role for daemonizing your Moose based application New package perl-MooseX-LogDispatch Logging Role for Moose New package perl-Sane Perl extension for the SANE (Scanner Access Now Easy) Project New package perl-constant-boolean Define TRUE and FALSE constants New package vollkorn-fonts A serif latin font with good readability New package whohas Command line tool for query package lists New package xmlenc Light-weight XML output library for Java New package yanone-tagesschrift-fonts A serif decorative latin font Updated Packages: aplus-fsf-4.22.4-13.fc11 ------------------------ * Mon Jan 26 17:00:00 2009 Jochen Schmitt 4.22.4-12 - Adapt package to Emacs packaging guidelines * Sun Feb 1 17:00:00 2009 Jochen Schmitt 4.22.4-13 - Fix unowned fontdir issue (#483325) baekmuk-ttf-fonts-2.2-18.fc11 ----------------------------- * Mon Feb 2 17:00:00 2009 Caius Chance - 2.2-18.fc11 - Updated fontconfig .conf files based on fontpackages templates. cgit-0.8.2-1.fc11 ----------------- * Sun Feb 1 17:00:00 2009 Todd Zullinger - 0.8.2-1 - Update to 0.8.2 - Drop upstreamed Makefile patch cjkuni-fonts-0.2.20080216.1-18.fc11 ----------------------------------- * Mon Feb 2 17:00:00 2009 Caius Chance - 0.2.20080216.1-18.fc11 - Resolves: rhbz#475743 - Fixed Japanese fonts over-priorized by uming fonts in Japanese locale. deluge-1.1.2-2.fc11 ------------------- * Sun Feb 1 17:00:00 2009 Peter Gordon - 1.1.2-2 - Fix scalable icon directory ownership (#483443). dustin-domestic-manners-fonts-20030527-2.fc11 --------------------------------------------- * Sun Feb 1 17:00:00 2009 Sven Lankes - 20030527-2 - Fix typo in description gnome-commander-1.2.8-0.3.svn2448_trunk.fc11 -------------------------------------------- * Sun Feb 1 17:00:00 2009 Mamoru Tasaka - rev 2448 gnome-python2-2.25.90-1.fc11 ---------------------------- * Sun Feb 1 17:00:00 2009 Matthew Barnes - 2.25.90-1.fc11 - Update to 2.25.90 gnome-python2-desktop-2.25.90-1.fc11 ------------------------------------ * Sun Feb 1 17:00:00 2009 Matthew Barnes - 2.25.90-1.fc11 - Update to 2.25.90 ktorrent-3.1.6-4.fc11 --------------------- * Sun Feb 1 17:00:00 2009 Roland Wolters - 3.1.6-4 - ktorrent-3.1.6-4 libdrm-2.4.4-2.fc11 ------------------- * Sun Feb 1 17:00:00 2009 Dave Airlie 2.4.4-2 - update specfile with review changes ltsp-5.1.56-2.fc11 ------------------ * Sun Feb 1 17:00:00 2009 Warren Togami - 5.1.56-1 - Lots of bug fixes and cleanups * Sun Feb 1 17:00:00 2009 Ryan Niebur - 5.1.56-2 - fix build mingw32-filesystem-46-1.fc11 ---------------------------- * Sun Feb 1 17:00:00 2009 Richard W.M. Jones - 46-1 - Unset PKG_CONFIG_PATH because /usr/lib/rpm/macros sets it (Erik van Pienbroek). phonon-4.3.0-5.fc11 ------------------- * Sun Feb 1 17:00:00 2009 Rex Dieter - 4.3.0-5 - put icons in the right subpkg shorewall-4.2.5-2.fc11 ---------------------- * Sun Feb 1 17:00:00 2009 Jonathan G. Underwood - 4.2.5-2 - Update shorewal-perl to version 4.2.5.1 twitux-0.69-2.fc11 ------------------ * Sun Feb 1 17:00:00 2009 Brian Pepple - 0.69-2 - Add patch to fix friend add & removals. xkeyboard-config-1.5-2.fc11 --------------------------- * Mon Feb 2 17:00:00 2009 Peter Hutterer - purge obsolete patches. * Mon Feb 2 17:00:00 2009 Peter Hutterer 1.5-2 - xkeyboard-config-1.5-evdevkbds.patch: include model-specifics when using evdev. xorg-x11-drv-evdev-2.1.2-1.fc11 ------------------------------- * Mon Feb 2 17:00:00 2009 Peter Hutterer 2.1.2-1 - evdev 2.1.2 xorg-x11-drv-synaptics-1.0.0-1.fc11 ----------------------------------- * Mon Feb 2 17:00:00 2009 Peter Hutterer 1.0.0-1 - synaptics 1.0 Summary: Added Packages: 13 Removed Packages: 0 Modified Packages: 19 Broken deps for i386 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15 libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15) 1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2 perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Logger) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::ConfigMaker) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Interface) php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 python-gammu-0.28-1.fc11.i386 requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so Broken deps for x86_64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15 gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit) gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit) gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit) mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) 1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Logger) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::ConfigMaker) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Interface) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15 gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15 gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15 libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0 linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15) 1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2 perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Logger) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::ConfigMaker) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Interface) php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 python-gammu-0.28-1.fc11.ppc requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so Broken deps for ppc64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) 1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Logger) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::ConfigMaker) perl-MooseX-LogDispatch-1.2000-1.fc11.noarch requires perl(MooseX::LogDispatch::Interface) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) From hughsient at gmail.com Mon Feb 2 08:35:34 2009 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 02 Feb 2009 08:35:34 +0000 Subject: Fedora 11: What do we expect? In-Reply-To: References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> Message-ID: <1233563734.3444.8.camel@hughsie-work.lan> On Sun, 2009-02-01 at 20:31 +0100, Kevin Kofler wrote: > That's only in gnome-packagekit though, isn't it? Or is this > implemented in KPackageKit? Yes, it's only in GNOME for now. You can of course use gnome programs in KDE, or if you want, it's a few hours work to port the GUI. I'm not very good at C++, but you're more than welcome to volunteer to do it for KPackageKit. Richard. From tmraz at redhat.com Mon Feb 2 08:41:20 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 02 Feb 2009 09:41:20 +0100 Subject: OpenSSL symlink hack In-Reply-To: References: Message-ID: <1233564080.3600.82.camel@vespa.frost.loc> On Sun, 2009-02-01 at 15:58 +0100, Kevin Kofler wrote: > Hi, > > can the OpenSSL compat symlink hack be dropped now that we have the alpha > practically out of the door? I think we want to make sure all the packages > get rebuilt against the new ABI ASAP (and most already did), and the > symlinks are also unreliable. Yes, I want to drop the symlink hack today. There are still the following packages which were not rebuilt either because they FTBFS due to problems unrelated to the OpenSSL upgrade or because they have closed commit ACLs for provenpackagers. gdal gnubiff grass ifstat ldns linkage mediatomb sepostgresql tightvnc -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From debarshi.ray at gmail.com Mon Feb 2 08:43:59 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon, 2 Feb 2009 14:13:59 +0530 Subject: rawhide report: 20090202 changes In-Reply-To: <20090202083439.7EA5D1F82DC@releng2.fedora.phx.redhat.com> References: <20090202083439.7EA5D1F82DC@releng2.fedora.phx.redhat.com> Message-ID: <3170f42f0902020043ob7b85beg18b782b31aa7faa8@mail.gmail.com> > ltsp-5.1.56-2.fc11 > ------------------ > * Sun Feb 1 17:00:00 2009 Warren Togami - 5.1.56-1 > - Lots of bug fixes and cleanups > > * Sun Feb 1 17:00:00 2009 Ryan Niebur - 5.1.56-2 > - fix build Looks like the order of the %changelog entries got interchanged. Cheers, Debarshi From mschwendt at gmail.com Mon Feb 2 09:08:01 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 2 Feb 2009 10:08:01 +0100 Subject: Too many unowned directories In-Reply-To: <4986B059.30108@hhs.nl> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> Message-ID: <20090202100801.96522807.mschwendt@gmail.com> On Mon, 02 Feb 2009 09:35:37 +0100, Hans wrote: > What about Panu's suggestion to just abort the install when trying to install a > file in to a non-existing directory, instead of creating the dir on the fly. Confronting users with these packaging mistakes sounds very wrong to me. Does "aborting the install" here means that the RPM transaction check would catch these mistakes? That would be too late, it would break all those untested mass-dist-updates and create chaos - it would be a DoS situation for normal updates. Some packagers rewrite their %files section in spec files so often, they flip forth and back from owned dirs to unowned dirs, simply because %dir and recursive inclusion are not understood [yet]. There are even people on IRC who give wrong/misleading advice wrt dirs in %files sections, and newbie packagers listen to them. > This will not catch all cases, but will catch a lot, and is really easy to > implement (I think). > > We could even complement this by also refusing to remove a package if *owned* > files are still left in a dir which it owns (and no other packages own). Then > we catch all error cases AFAIK. In hope that those people, who would be burnt by such a refusal to remove a pkg, will report all such problems instead of working around them. No, the problem is not worse enough anymore, since RPM at least uses a proper umask since F9. Since then it has become more interesting to examine unowned dirs which are caused by other packaging mistakes (such as misplaced files, missing sub-pkg deps). > This means people will still need to manually get directory ownership right, > but if their just build rpm fails to install they will learn soon enough! The script I'm using to detect unowned dirs in repos is released since middle/autumn of last year ( http://mschwendt.fedorapeople.org/dircheck-remote.py ). It has become really easy to check packages in Rawhide. $ ./dircheck-remote.py -r rawhide -n bit-devel => bit-0.4.90-3.fc11.src.rpm => bit-devel-0.4.90-3.fc11.i386 (rawhide-development-i386) /usr/include/bit-0.4 and it can be none or multiple -n options that each accept a regexp, so it's easy to check all -devel pkgs, for example. From bochecha at fedoraproject.org Mon Feb 2 09:15:50 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Mon, 2 Feb 2009 10:15:50 +0100 Subject: Too many unowned directories In-Reply-To: <20090202100801.96522807.mschwendt@gmail.com> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> Message-ID: <2d319b780902020115r410bdb3sb2cfc6429ea0042f@mail.gmail.com> > The script I'm using to detect unowned dirs in repos is released since > middle/autumn of last year > ( http://mschwendt.fedorapeople.org/dircheck-remote.py ). > It has become really easy to check packages in Rawhide. > > $ ./dircheck-remote.py -r rawhide -n bit-devel > => bit-0.4.90-3.fc11.src.rpm > => bit-devel-0.4.90-3.fc11.i386 (rawhide-development-i386) > /usr/include/bit-0.4 > > and it can be none or multiple -n options that each accept a regexp, so > it's easy to check all -devel pkgs, for example. I wasn't on this list in middle/autumn of last year, so thanks for talking about it one more time. Will be great, at least to check my own packages. With all the hype about FADs these days, we could even think about a FAD that would be specifically about running this script and reporting bugs against the incorrect packages :) It can also be a great way of having users contribute: "you don't know how to help ? run this script and report a bug for each package it returns". ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From gauret at free.fr Mon Feb 2 09:23:01 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Mon, 2 Feb 2009 10:23:01 +0100 Subject: Compiler flags: upstream or Fedora ? Message-ID: Hi all, The packaging guidelines specify[1] that packages should honor the system compilation flags. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags I'm currently packaging Spring[2], whose build system purposefully ignores the CFLAGS and CXXFLAGS environment variables. This is in the build script: # Do not do this [use env vars] anymore because it may severely mess up our carefully selected options. # Print a warning and ignore them instead. [2] https://bugzilla.redhat.com/show_bug.cgi?id=478767 What should I do ? Should I patch the build system to use our flags, while upstream specifically not wanted me to ? Thanks for your guidance Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz From rc040203 at freenet.de Mon Feb 2 09:32:30 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Feb 2009 10:32:30 +0100 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: References: Message-ID: <4986BDAE.8010105@freenet.de> Aur?lien Bompard wrote: > Hi all, > > The packaging guidelines specify[1] that packages should honor the > system compilation flags. > > [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags > > I'm currently packaging Spring[2], whose build system purposefully > ignores the CFLAGS and CXXFLAGS environment variables. This is in the > build script: > # Do not do this [use env vars] anymore because it may severely mess > up our carefully selected options. > # Print a warning and ignore them instead. > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=478767 > > What should I do ? Change your package to use Fedora's flags. Ralf From thomas.moschny at gmail.com Mon Feb 2 09:48:22 2009 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Mon, 2 Feb 2009 10:48:22 +0100 Subject: rawhide report: 20090202 changes In-Reply-To: <3170f42f0902020043ob7b85beg18b782b31aa7faa8@mail.gmail.com> References: <20090202083439.7EA5D1F82DC@releng2.fedora.phx.redhat.com> <3170f42f0902020043ob7b85beg18b782b31aa7faa8@mail.gmail.com> Message-ID: 2009/2/2 Debarshi Ray : >> ltsp-5.1.56-2.fc11 >> ------------------ >> * Sun Feb 1 17:00:00 2009 Warren Togami - 5.1.56-1 >> - Lots of bug fixes and cleanups >> >> * Sun Feb 1 17:00:00 2009 Ryan Niebur - 5.1.56-2 >> - fix build > > Looks like the order of the %changelog entries got interchanged. And what was the reason again for inserting a totally artificial time when there normally only is a date in the spec file? -- Thomas Moschny From nicolas.mailhot at laposte.net Mon Feb 2 09:53:22 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Feb 2009 10:53:22 +0100 (CET) Subject: Too many unowned directories In-Reply-To: <20090202100801.96522807.mschwendt@gmail.com> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> Message-ID: <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> Le Lun 2 f?vrier 2009 10:08, Michael Schwendt a ?crit : > No, the problem is not worse enough anymore, since RPM at least uses a > proper umask since F9. Since then it has become more interesting to > examine unowned dirs which are caused by other packaging mistakes > (such as misplaced files, missing sub-pkg deps). BTW, I could simplify the multi-font spec template a lot if having multiple subpackages own the same font directory was accepted. Currently one of the major quirks many font packagers fail on is the way we try very hard to have a single canonical owner of the common font deployment directory for the srpm. (IIRC people wanted queries on directory ownership to return a single package) -- Nicolas Mailhot From mschwendt at gmail.com Mon Feb 2 10:08:15 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 2 Feb 2009 11:08:15 +0100 Subject: rawhide report: 20090202 changes In-Reply-To: References: <20090202083439.7EA5D1F82DC@releng2.fedora.phx.redhat.com> <3170f42f0902020043ob7b85beg18b782b31aa7faa8@mail.gmail.com> Message-ID: <20090202110815.e4d99add.mschwendt@gmail.com> On Mon, 2 Feb 2009 10:48:22 +0100, Thomas wrote: > 2009/2/2 Debarshi Ray: > >> ltsp-5.1.56-2.fc11 > >> ------------------ > >> * Sun Feb 1 17:00:00 2009 Warren Togami wtogami redhat com - 5.1.56-1 > >> - Lots of bug fixes and cleanups > >> > >> * Sun Feb 1 17:00:00 2009 Ryan Niebur ryanryan52 gmail com - 5.1.56-2 > >> - fix build > > > > Looks like the order of the %changelog entries got interchanged. > > > And what was the reason again for inserting a totally artificial time > when there normally only is a date in the spec file? It's repodiff that's doing this. See Yum upstream tickets #6 and #7 where I've suggested fixes. From pmatilai at laiskiainen.org Mon Feb 2 10:42:08 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 2 Feb 2009 12:42:08 +0200 (EET) Subject: Too many unowned directories In-Reply-To: <20090202100801.96522807.mschwendt@gmail.com> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> Message-ID: On Mon, 2 Feb 2009, Michael Schwendt wrote: > On Mon, 02 Feb 2009 09:35:37 +0100, Hans wrote: > >> What about Panu's suggestion to just abort the install when trying to install a >> file in to a non-existing directory, instead of creating the dir on the fly. > > Confronting users with these packaging mistakes sounds very wrong to me. > Does "aborting the install" here means that the RPM transaction check > would catch these mistakes? That would be too late, it would break all > those untested mass-dist-updates and create chaos - it would be a DoS > situation for normal updates. Yup, that'd be having rpm transaction check fail. And sure it's fairly draconian, but maybe it'd teach the packagers not to do untested mass-dist-updates after getting bombarded with bug reports a few times :P If mock/koji did a test install of the freshly built package into the build chroot, that'd catch these and all sorts of other silly mistakes too (Ever made a typo in manual dependency, scriptlet or so, making the package uninstallable? I know I have...) without exposing the poor users to packagers mistakes. > Some packagers rewrite their %files section in spec files so often, they > flip forth and back from owned dirs to unowned dirs, simply because %dir > and recursive inclusion are not understood [yet]. There are even people > on IRC who give wrong/misleading advice wrt dirs in %files sections, and > newbie packagers listen to them. Would it help just to have rpmbuild *report* unowned directories at build-time? That would of course give a great deal of false positives (you'd probably want to filter at least directories from the filesystem package out), but it would provide an easy way for a packager to eyeball for anything suspicious. Such as Note: directories not explicitly owned by package libfoo: /usr/lib /usr/share/foo - Panu - From nicolas.mailhot at laposte.net Mon Feb 2 10:51:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Feb 2009 11:51:42 +0100 (CET) Subject: Too many unowned directories In-Reply-To: References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> Message-ID: <8bfd2b32d33281ba29eb0e4dbfad5b63.squirrel@arekh.dyndns.org> Le Lun 2 f?vrier 2009 11:42, Panu Matilainen a ?crit : > Would it help just to have rpmbuild *report* unowned directories at > build-time? That would just make multiple packagers own the same directories with different options -- Nicolas Mailhot From bnocera at redhat.com Mon Feb 2 12:42:19 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 02 Feb 2009 12:42:19 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1233578539.3486.895.camel@cookie.hadess.net> On Sun, 2009-02-01 at 22:31 -0500, Jens Petersen wrote: > ----- "???" wrote: > > Right. How about enable esd in libgnome please? > > I suggest you file a bug in bugzilla if there isn't one already and see what happens. Will probably be closed as WONTFIX. The API docs made it clear that the libgnome sound support was a build-time option. The application should be fixed to use more modern API. Cheers From rdieter at math.unl.edu Mon Feb 2 13:01:26 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 02 Feb 2009 07:01:26 -0600 Subject: Compiler flags: upstream or Fedora ? References: Message-ID: Aur?lien Bompard wrote: > What should I do ? Should I patch the build system to use our flags, > while upstream specifically not wanted me to ? Let me get this straight, you asked upstream about this and that's what they said? Any pointers/references? -- Rex From ngompa13 at gmail.com Mon Feb 2 13:49:15 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Mon, 2 Feb 2009 07:49:15 -0600 Subject: Why do we disable esd in libgnome? In-Reply-To: <1233578539.3486.895.camel@cookie.hadess.net> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> Message-ID: <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> But when you break something as major as libgnome, steps should be taken to ease the transition. Perhaps the function could be forwarded? I'm not really much of a programmer, but I recognize that you can't just break functionality in core libraries like that and expect everyone to fix their apps up "just like that." Fowarding the function (for compatibility purposes) while deprecating it would probably be more ideal. In any case, that's just my two cents... On Mon, Feb 2, 2009 at 6:42 AM, Bastien Nocera wrote: > On Sun, 2009-02-01 at 22:31 -0500, Jens Petersen wrote: > > ----- "???" wrote: > > > Right. How about enable esd in libgnome please? > > > > I suggest you file a bug in bugzilla if there isn't one already and see > what happens. > > Will probably be closed as WONTFIX. The API docs made it clear that the > libgnome sound support was a build-time option. > > The application should be fixed to use more modern API. > > Cheers > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Mon Feb 2 14:21:23 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 2 Feb 2009 09:21:23 -0500 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131172219.GB7964@yoda.jdub.homelinux.org> <20090131222655.GA84354@dspnet.fr.eu.org> Message-ID: <20090202142122.GF3910@redhat.com> On Sunday, February 01 2009, drago01 said: > On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull wrote: > > On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert wrote: > > > >> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn. > > > > So we're leaving the developing world to Ubuntu now? > > They can/have to use the x86 livecd anyway for their older system. > We are talking about moving the x86_64 live spin to a DVD. The problem then is that there are more configs to maintain. And in point of fact, the x86_64 images were larger than CD-sized for a few releases and there were more than a handful of complaints from people wanting to use them on x86_64 boxes with only CD drives. Jeremy From katzj at redhat.com Mon Feb 2 14:23:32 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 2 Feb 2009 09:23:32 -0500 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131164352.GA25612@wolff.to> Message-ID: <20090202142331.GG3910@redhat.com> On Saturday, January 31 2009, drago01 said: > 3: now who is "we" ... FESCO, rel-eng ? Who is app to make this decision ? The last time a "we will ship CDs" decision was made, it was made by the Board so I think that's probably the precedent. Jeremy From katzj at redhat.com Mon Feb 2 14:25:09 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 2 Feb 2009 09:25:09 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <4985441B.7030005@redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <4985441B.7030005@redhat.com> Message-ID: <20090202142508.GH3910@redhat.com> On Sunday, February 01 2009, Warren Togami said: > Bill Nottingham wrote: >> - K12Linux/thin client >> >> Some older thin client hardware is not i686 compatible. Warren has more >> info on this. One question I have is that some of this is mentioned >> as being Geode - wouldn't this fall into the same category as the XO? > > Geode is a popular thin client chipset that continues to be sold today. > VIA i586 without cmov was sold in thin clients until recently. Anything > older I do not care about. Most Geode is processor family 5, but supports cmov and so is "i686" compatible, inasmuch as we care Jeremy From pbrobinson at gmail.com Mon Feb 2 14:31:08 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 2 Feb 2009 15:31:08 +0100 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090202142508.GH3910@redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <4985441B.7030005@redhat.com> <20090202142508.GH3910@redhat.com> Message-ID: <5256d0b0902020631u65cbd64dnf0d6363bb9f88f18@mail.gmail.com> >>> Some older thin client hardware is not i686 compatible. Warren has more >>> info on this. One question I have is that some of this is mentioned >>> as being Geode - wouldn't this fall into the same category as the XO? >> >> Geode is a popular thin client chipset that continues to be sold today. >> VIA i586 without cmov was sold in thin clients until recently. Anything >> older I do not care about. > > Most Geode is processor family 5, but supports cmov and so is "i686" > compatible, inasmuch as we care Yes, my Fit-PC with a LX800 runs the i686 kernel/glibc/openssl fine but rpm still sees it as i586 so upgrades of those always have to be done with rpm -U --ignorearch otherwise it doesn't work. Peter. From gauret at free.fr Mon Feb 2 14:42:52 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Mon, 2 Feb 2009 15:42:52 +0100 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: References: Message-ID: > Let me get this straight, you asked upstream about this and that's what they > said? Any pointers/references? No, I did not ask upstream. It's just that they dont wan't people building their software to mess up their "carefully selected options". Since they used env vars before and reverted from that, I assume they have a good reason to. But maybe that's too much assuming, I'll just ask them directly. Thanks to both of you. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Go away or I will replace you with a very small shell script From katzj at redhat.com Mon Feb 2 14:52:34 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 2 Feb 2009 09:52:34 -0500 Subject: Orphaning cellwriter Message-ID: <20090202145233.GL3910@redhat.com> Since I'm no longer actively using a tablet, I'm going to orphan cellwriter (http://risujin.org/cellwriter/). I may have been the only person using it, but it's a reasonable app for basic handwriting input if anyone wants to pick it up. Upstream was pretty responsive to the few bugs I found as well. If no one responds as being interested in taking it over in a couple of weeks, I'll block the package from rawhide Jeremy From mzerqung at 0pointer.de Mon Feb 2 14:56:46 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 2 Feb 2009 15:56:46 +0100 Subject: Why do we disable esd in libgnome? In-Reply-To: <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> Message-ID: <20090202145646.GB32202@tango.0pointer.de> On Mon, 02.02.09 07:49, King InuYasha (ngompa13 at gmail.com) wrote: > But when you break something as major as libgnome, steps should be taken to > ease the transition. Perhaps the function could be forwarded? I'm not really > much of a programmer, but I recognize that you can't just break > functionality in core libraries like that and expect everyone to fix their > apps up "just like that." Fowarding the function (for compatibility > purposes) while deprecating it would probably be more ideal. In any case, > that's just my two cents... For a core piece of an API keeping compat is certainly important. But this is sound events, don't forget that. Quite frankly, most people have them deatcivated anyway. It has been documented that this can be disabled at compile time and it's pretty unimportant anyway and there is a much better replacement available. Hence I'd assume that the advantage of getting rid of this legacy cruft will always be more attractive then keeping it around. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From drepper at redhat.com Mon Feb 2 15:06:48 2009 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 02 Feb 2009 07:06:48 -0800 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: <4986BDAE.8010105@freenet.de> References: <4986BDAE.8010105@freenet.de> Message-ID: <49870C08.3080509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: > Change your package to use Fedora's flags. That's certainly not the best answer. There are three types of compiler command line flags which come from the Fedora config: - - general optimization - - architecture selection - - other code selection (like security options) The latter two shouldn't be changed, they should be used as provided by the build system. But it is wrong to prevent a package from using different optimization options if it is obvious that the upstream optimization options have been carefully chosen. The options from the build system are in this area only a good default. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmHDAgACgkQ2ijCOnn/RHSV6gCfa5j3ZNMStBtgUlZ5O2i31bvj VVUAoLae9otkEvYi/aYEE3X4VLQ8eGib =ZtTY -----END PGP SIGNATURE----- From limb at jcomserv.net Mon Feb 2 15:10:13 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Feb 2009 09:10:13 -0600 (CST) Subject: Orphaning cellwriter In-Reply-To: <20090202145233.GL3910@redhat.com> References: <20090202145233.GL3910@redhat.com> Message-ID: <96c7b0ed6169e7387c72b2a7fdc70e3e.squirrel@mail.jcomserv.net> > Since I'm no longer actively using a tablet, I'm going to orphan > cellwriter (http://risujin.org/cellwriter/). I may have been the only > person using it, but it's a reasonable app for basic handwriting input > if anyone wants to pick it up. Upstream was pretty responsive to the > few bugs I found as well. I'll take it if no one else wants it, but will defer to an active user if one comes along. > If no one responds as being interested in taking it over in a couple of > weeks, I'll block the package from rawhide > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- in your fear, speak only peace in your fear, seek only love -d. bowie From dbn.lists at gmail.com Mon Feb 2 15:18:01 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Mon, 2 Feb 2009 07:18:01 -0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <20090202145646.GB32202@tango.0pointer.de> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> Message-ID: <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> On Mon, Feb 2, 2009 at 6:56 AM, Lennart Poettering wrote: > On Mon, 02.02.09 07:49, King InuYasha (ngompa13 at gmail.com) wrote: > >> But when you break something as major as libgnome, steps should be taken to >> ease the transition. Perhaps the function could be forwarded? I'm not really >> much of a programmer, but I recognize that you can't just break >> functionality in core libraries like that and expect everyone to fix their >> apps up "just like that." Fowarding the function (for compatibility >> purposes) while deprecating it would probably be more ideal. In any case, >> that's just my two cents... > > For a core piece of an API keeping compat is certainly important. But > this is sound events, don't forget that. Quite frankly, most people have them > deatcivated anyway. > > It has been documented that this can be disabled at compile time and > it's pretty unimportant anyway and there is a much better replacement > available. Hence I'd assume that the advantage of getting rid of this > legacy cruft will always be more attractive then keeping it around. What about the possibility of rewriting gnome_sound* to use libsydney? I know it's not the most exciting work available, but that would some to be the correct long term fix. It's not like the libgnome API can go away prior to GNOME-3.0. -- Dan From gauret at free.fr Mon Feb 2 15:36:32 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Mon, 2 Feb 2009 16:36:32 +0100 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: <49870C08.3080509@redhat.com> References: <4986BDAE.8010105@freenet.de> <49870C08.3080509@redhat.com> Message-ID: > Let me get this straight, you asked upstream about this and that's what they > said? Any pointers/references? OK, done : http://spring.clan-sy.com/phpbb/viewtopic.php?p=330813#p330813 In short : they don't mind us using our flags, but they warn us that it may prevent users from playing the game online. In particular, they advise against using march=i386 for this reason. Since we're talking about a 3D game, which would only be playable on rather powerful hardware, would it be OK to use the march=i686 flag ? Thanks. Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From rdieter at math.unl.edu Mon Feb 2 15:43:23 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 02 Feb 2009 09:43:23 -0600 Subject: Compiler flags: upstream or Fedora ? References: <4986BDAE.8010105@freenet.de> <49870C08.3080509@redhat.com> Message-ID: Aur?lien Bompard wrote: > In particular, they advise against using march=i386 for this reason. > Since we're talking about a 3D game, which would only be playable on > rather powerful hardware, would it be OK to use the march=i686 flag ? could have koji target i686 only, and skip i386 (similar to how kernel is built for multiple archs in koji). Frankly, I doubt it's worth the trouble, but I'm not the one doing the work... -- Rex From mike at cchtml.com Mon Feb 2 15:46:23 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Mon, 02 Feb 2009 09:46:23 -0600 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: References: <4986BDAE.8010105@freenet.de> <49870C08.3080509@redhat.com> Message-ID: <4987154F.7010800@cchtml.com> -------- Original Message -------- Subject: Re: Compiler flags: upstream or Fedora ? From: Aur?lien Bompard To: Development discussions related to Fedora Date: 02/02/2009 09:36 AM > > OK, done : http://spring.clan-sy.com/phpbb/viewtopic.php?p=330813#p330813 > > In short : they don't mind us using our flags, but they warn us that > it may prevent users from playing the game online. > > In particular, they advise against using march=i386 for this reason. > Since we're talking about a 3D game, which would only be playable on > rather powerful hardware, would it be OK to use the march=i686 flag ? > There's no need to explicitly use i686. The developer seems to understand compiler flags, sans -march. If the developers of this game are really worried about this, you might recommend that they set some runtime checks for compile time options. When I mean checks, I mean arithmetic checks not explicit checking for compiler flags. Have a static variable, do some math with some stack variables, and compare. (right?) From rc040203 at freenet.de Mon Feb 2 15:55:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Feb 2009 16:55:46 +0100 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: <49870C08.3080509@redhat.com> References: <4986BDAE.8010105@freenet.de> <49870C08.3080509@redhat.com> Message-ID: <49871782.9020106@freenet.de> Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ralf Corsepius wrote: >> Change your package to use Fedora's flags. > > That's certainly not the best answer. Right, I could have been more detailed. > There are three types of compiler command line flags which come from the > Fedora config: > > - - general optimization > > - - architecture selection > > - - other code selection (like security options) > > The latter two shouldn't be changed, they should be used as provided by > the build system. Aur?lien's package is likely subject to these 2 classes of problems. c.f. for how ppc build-attempts are choking on i386/x86_64 arch-flags. > But it is wrong to prevent a package from using different optimization > options if it is obvious that the upstream optimization options have > been carefully chosen. Theoretically not not much - In practice, quite a lot, because "carefully chosen" is hard to define and because "rarely used options" may have unwanted/undesired side effects (e.g. triggering bugs in GCC, breaking debug infos, introducing arch-deps, etc.) In this particular review, I think it's an "overzealous" upstream outsmarting themselves. > The options from the build system are in this > area only a good default. Agreed, but diverging from them in most cases doesn't make much sense. Ralf From gauret at free.fr Mon Feb 2 16:12:21 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Mon, 2 Feb 2009 17:12:21 +0100 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: References: <4986BDAE.8010105@freenet.de> <49870C08.3080509@redhat.com> Message-ID: > could have koji target i686 only, and skip i386 (similar to how kernel is > built for multiple archs in koji). I guess I'll have the hard task to play it online to check compatibility ;-) Thanks. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Everyone thinks of changing the world, but no one thinks of changing himself." -- Tolsto? From jspaleta at gmail.com Mon Feb 2 16:25:37 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Feb 2009 07:25:37 -0900 Subject: Moblin 2 and Fedora In-Reply-To: <20090131153457.573762ab@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> Message-ID: <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> On Sat, Jan 31, 2009 at 2:34 PM, Arjan van de Ven wrote: > But frankly, if I look at where things are today in Moblin and where > they are going; the packages we borrowed from Fedora tend to be those > where we don't do much if any changes. > If there's something specific that the Fedora project wants to get from > Moblin we should discuss that, but lets be specific there rather than > having a discussion on the blanket hand-wavey level... Hmm, is there a good way to generate a list of changes between moblin and Fedora packages that would help us identify some specific things we could get back? Is this a matter of cataloging the Moblin specific patch files in the Moblin srpms? The other question is, does the way Moblin "borrow" packages from Fedora fall under the newish Fedora Remix trademark guidance? And if so would Intel be willing to advertise (in some fashion) Moblin as a Fedora remix? -jef From kanarip at kanarip.com Mon Feb 2 16:29:56 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 02 Feb 2009 17:29:56 +0100 Subject: Spins SIG meeting in half an hour Message-ID: <49871F84.4070001@kanarip.com> The Spins SIG is meeting again in half an hour (that is, 17:00 UTC), in #fedora-meeting. Kind regards, Jeroen van Meeuwen -kanarip From bkearney at redhat.com Mon Feb 2 16:34:08 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Feb 2009 11:34:08 -0500 Subject: [Fedora-spins] Spins SIG meeting in half an hour In-Reply-To: <49871F84.4070001@kanarip.com> References: <49871F84.4070001@kanarip.com> Message-ID: <49872080.5000902@redhat.com> Jeroen van Meeuwen wrote: > The Spins SIG is meeting again in half an hour (that is, 17:00 UTC), in > #fedora-meeting. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > _______________________________________________ > Fedora-spins mailing list > Fedora-spins at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/fedora-spins I am hanging out at a local conference and will not able to make it there. I will catch up with you guys on the list. -- bk From jkeating at redhat.com Mon Feb 2 16:45:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 08:45:04 -0800 Subject: Fedora releng meeting at 1800 UTC Message-ID: <1233593104.7493.36.camel@localhost.localdomain> This weeks agenda is simply the Alpha release, and how long we need to slip it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From bnocera at redhat.com Mon Feb 2 17:05:11 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 02 Feb 2009 17:05:11 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> Message-ID: <1233594311.3486.1169.camel@cookie.hadess.net> On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote: > What about the possibility of rewriting gnome_sound* to use libsydney? > I know it's not the most exciting work available, but that would some > to be the correct long term fix. It's not like the libgnome API can go > away prior to GNOME-3.0. It's not possible to provide an ABI or API compatible replacement, because gnome_sound_* exports some esound specific APIs. For example, gnome_sound_connection_get () and gnome_sound_sample_load(). So if you're going to change the semantics, the apps will need to be fixed. And if the applications need to be fixed, I don't see the difference between rewriting the few lines of code to use libcanberra and adapting it for a libgnome API with different semantics. From drago01 at gmail.com Mon Feb 2 17:03:34 2009 From: drago01 at gmail.com (drago01) Date: Mon, 2 Feb 2009 18:03:34 +0100 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> Message-ID: On Sun, Feb 1, 2009 at 7:48 PM, Colin Walters wrote: > On Sat, Jan 31, 2009 at 11:07 AM, Jan Kratochvil > wrote: >> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote: >>> But our live images are already heavily size-constrained. There's definitely >>> no room for multiple kernels on the KDE live image, and I don't think the >>> GNOME image has any room left either. >> >> Was already discussed the requirement of CDs nowadays? Even the oldest >> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin. > > >From the desktop perspective I like having something around CD size > since it keeps us focused, in terms of: > > * Even if someone can burn a DVD, it's a lot to download; keep in mind > not everyone has fast Internet > * Having higher quality software percentage wise > * Not losing focus into developer tools, scientific analysis, creative > tools, 3D games etc. The desktop image is a desktop core. > * Encouraging us to reduce technology duplication in that core set That's the job of the spin maintainer to not include everything under the sun just because it fits on the media. (i.e only add apps that are useful for your spins target audience) > The fact that it can be burned to a physical CD is a bonus. Well the x86_64 images was sightly bigger than a CD anyway, so the only bonus is the download size, but again only because it can be up to 4.7GB size does not mean it has to use all this space. From bnocera at redhat.com Mon Feb 2 17:09:22 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 02 Feb 2009 17:09:22 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> Message-ID: <1233594562.3486.1178.camel@cookie.hadess.net> On Mon, 2009-02-02 at 07:49 -0600, King InuYasha wrote: > But when you break something as major as libgnome, steps should be > taken to ease the transition. Perhaps the function could be forwarded? See below in the thread, we can't because the libgnome API exposes esound internals. > I'm not really much of a programmer, but I recognize that you can't > just break functionality in core libraries like that and expect > everyone to fix their apps up "just like that." Fowarding the function > (for compatibility purposes) while deprecating it would probably be > more ideal. In any case, that's just my two cents... It's been deprecated for a while already. See: http://library.gnome.org/devel/references#api-platform And from the API docs: " These functions also allow for the fact that no sound may be supported on the current platform. " So if your application _required_ to have sound working, then it was broken in the first place... From drago01 at gmail.com Mon Feb 2 17:09:40 2009 From: drago01 at gmail.com (drago01) Date: Mon, 2 Feb 2009 18:09:40 +0100 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: <20090202142122.GF3910@redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131172219.GB7964@yoda.jdub.homelinux.org> <20090131222655.GA84354@dspnet.fr.eu.org> <20090202142122.GF3910@redhat.com> Message-ID: On Mon, Feb 2, 2009 at 3:21 PM, Jeremy Katz wrote: > On Sunday, February 01 2009, drago01 said: >> On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull wrote: >> > On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert wrote: >> > >> >> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn. >> > >> > So we're leaving the developing world to Ubuntu now? >> >> They can/have to use the x86 livecd anyway for their older system. >> We are talking about moving the x86_64 live spin to a DVD. > > The problem then is that there are more configs to maintain. Sure but how much extra work does this add? We can reuse the same kickstart files and add/remove packages where it makes sense. As for testing both need to be tested anyway. >And in > point of fact, the x86_64 images were larger than CD-sized for a few > releases and there were more than a handful of complaints from people > wanting to use them on x86_64 boxes with only CD drives. Any pointers to those complains ? This shouldn't be an issue for the majority of x86_64 boxes (and no I don't talk about boxes without optical drives). If there are same rare cases with such hardware they still have the liveusb option if they don't want to buy a dvd drive/burner. From drago01 at gmail.com Mon Feb 2 17:19:35 2009 From: drago01 at gmail.com (drago01) Date: Mon, 2 Feb 2009 18:19:35 +0100 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: <20090202142331.GG3910@redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131164352.GA25612@wolff.to> <20090202142331.GG3910@redhat.com> Message-ID: On Mon, Feb 2, 2009 at 3:23 PM, Jeremy Katz wrote: > On Saturday, January 31 2009, drago01 said: >> 3: now who is "we" ... FESCO, rel-eng ? Who is app to make this decision ? > > The last time a "we will ship CDs" decision was made, it was made by the > Board so I think that's probably the precedent. The former Board decision was about supporting CDs at all, now we want to move to a DVD for _modern_ hardware and stick with CDs for the older ones (that would not be able to use the x86_64 image anyway even if it where CD sized) From choeger at cs.tu-berlin.de Mon Feb 2 17:27:13 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 02 Feb 2009 18:27:13 +0100 Subject: can someone point out on me how gnome-keyring works? Message-ID: <1233595633.18004.6.camel@choeger6> Hi, I want to add gnome-keyring features to the gnome branch of offlineimap. Setting and retrieving Passwords works, but I could need some advice: 1. What parameters should I put into the keyring functions? I see server and protocoll elements in the attrs dict. Does that mean gnomekeyring stores values on a per host/service base? If yes, is it valid to put arbitrary strings ("offlineimap") here? 2. From a security point of view: How does gnomekeyring decide to give an app access if the users select "always allow" on later calls? 3. Would calling the app via cron cause any communication problems? thanks Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From notting at redhat.com Mon Feb 2 17:39:08 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 12:39:08 -0500 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: <1233474067.15230.55.camel@localhost.localdomain> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> <20090131160728.GA28571@host0.dyn.jankratochvil.net> <1233474067.15230.55.camel@localhost.localdomain> Message-ID: <20090202173908.GB20094@nostromo.devel.redhat.com> Callum Lerwick (seg at haxxed.com) said: > > Well for x86_64 we can/should do this. > > Good luck on finding a x86_64 computer/laptop without a DVD drive. > > The problem isn't DVD readers, it's DVD writers. I sure don't own any, > and I have two x86-64 machines. I've had enough problems with CDRs being > unreliable, somehow I don't think higher density is going to help any. I > feel my money is better spent on more HDs and flash drives. But 'flash drives' solves the DVD size isse for you. Bill From notting at redhat.com Mon Feb 2 17:46:24 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 12:46:24 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090130231847.GA20809@host0.dyn.jankratochvil.net> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130231847.GA20809@host0.dyn.jankratochvil.net> Message-ID: <20090202174624.GE20094@nostromo.devel.redhat.com> Jan Kratochvil (jan.kratochvil at redhat.com) said: > Particularly why not to automatically install the whole x86_64 distro where > appropriate? The DVD media should contain both arches as in the real world > found out the users are not aware if they have 64bit-capable hardware. Well, to be somewhat glib, because that sort of setup wouldn't actually fit on a DVD. Bill From notting at redhat.com Mon Feb 2 17:41:32 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 12:41:32 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <49839BC6.2060006@gmail.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <200901310029.02287.ville.skytta@iki.fi> <49839BC6.2060006@gmail.com> Message-ID: <20090202174132.GC20094@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > >> * 32-bit x86 would be built for i686 by default. 586-compatible processors > >> would no longer be supported. > > [...] > >> * i386: -march=i586 -mtune=generic > > > > Should the latter be -march=i686? > > > I was wondering this too but in the opposite direction -- why build > everything for i686 by default if we're only updating the compiler flags > to i586? > > Jakub's email sparking this Feature listed the major benefit from > getting new instructions with -march=i486. He then listed additional > helpful instructions when using -march=i586. Nothing listed for > -march=i686. The idea is that RPMs are built for i686, ergo, they will get -march=i686 explicitly passed to the compiler. The default compiler flags for 32-bit will be -march=i586, which will allow people to build i586-compatible code if they so desire. Bill From notting at redhat.com Mon Feb 2 17:44:18 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 12:44:18 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <200901301525.43846.konrad@tylerc.org> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> Message-ID: <20090202174418.GD20094@nostromo.devel.redhat.com> Conrad Meyer (konrad at tylerc.org) said: > On Friday 30 January 2009 03:09:00 pm Dominik 'Rathann' Mierzejewski wrote: > > There's going to be some screaming from VIA C3 and AMD K6 users about this. > > Also breaks support for original pentium (i586) CPUs. My router will be > perpetually stuck at Fedora 10, I guess. Correct. However, by the only statistics we have available, that's an amazingly small percantage of our userbase (.04%, to be precise.) Bill From notting at redhat.com Mon Feb 2 17:47:25 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 12:47:25 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <4985441B.7030005@redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <4985441B.7030005@redhat.com> Message-ID: <20090202174725.GF20094@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > smolt stats are not coming from i586 machines because these are not the > same kind of Fedora installs. It is inappropriate to enable smolt > reporting by default for several reasons including minimizing chroot > size, and read-only root makes it impossible to record that it shouldn't > report again during the next boot. > > The statistics are not representative of the real world. How would we get statistics representative of the real world? Bill From tibbs at math.uh.edu Mon Feb 2 18:06:22 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Feb 2009 12:06:22 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090202174418.GD20094@nostromo.devel.redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Correct. However, by the only statistics we have available, that's BN> an amazingly small percantage of our userbase (.04%, to be BN> precise.) I can't help but point out that it's disingenuous to continue to quote that figure when it's already been stated that the main use of such systems is in a situation where smolt will never be run. - J< From arjan at infradead.org Mon Feb 2 18:10:02 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 2 Feb 2009 10:10:02 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> Message-ID: <20090202101002.4380c005@infradead.org> On Mon, 2 Feb 2009 07:25:37 -0900 Jeff Spaleta wrote: > > Hmm, is there a good way to generate a list of changes between moblin > and Fedora packages that would help us identify some specific things > we could get back? Is this a matter of cataloging the Moblin specific > patch files in the Moblin srpms? as I said before, the things we borrow we don't tend to patch > > The other question is, does the way Moblin "borrow" packages from > Fedora fall under the newish Fedora Remix trademark guidance? I doubt it. I really don't consider Moblin "fedora + changes". It really isn't. It is much more a "New OS + borrow from Fedora and SuSE" I suspect (I haven't done the count) that less than half the packages fall under the "borrow from Fedora" umbrella. Probably more if you don't count applications. > And if > so would Intel be willing to advertise (in some fashion) Moblin as a > Fedora remix? I don't think that is currently a relevant question... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From jkeating at redhat.com Mon Feb 2 18:13:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 10:13:03 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <20090202101002.4380c005@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> Message-ID: <1233598383.7493.42.camel@localhost.localdomain> On Mon, 2009-02-02 at 10:10 -0800, Arjan van de Ven wrote: > > I doubt it. I really don't consider Moblin "fedora + changes". It > really isn't. It is much more a "New OS + borrow from Fedora and SuSE" > I suspect (I haven't done the count) that less than half the packages > fall under the "borrow from Fedora" umbrella. > Probably more if you don't count applications. This does bring up an interesting question. What did you have to borrow from SuSE that the Fedora equiv (if it existed) wasn't suitable enough? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dbn.lists at gmail.com Mon Feb 2 18:20:56 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Mon, 2 Feb 2009 10:20:56 -0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <1233594311.3486.1169.camel@cookie.hadess.net> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> Message-ID: <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> On Mon, Feb 2, 2009 at 9:05 AM, Bastien Nocera wrote: > On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote: > >> What about the possibility of rewriting gnome_sound* to use libsydney? >> I know it's not the most exciting work available, but that would some >> to be the correct long term fix. It's not like the libgnome API can go >> away prior to GNOME-3.0. > > It's not possible to provide an ABI or API compatible replacement, > because gnome_sound_* exports some esound specific APIs. For example, > gnome_sound_connection_get () and gnome_sound_sample_load(). > > So if you're going to change the semantics, the apps will need to be > fixed. And if the applications need to be fixed, I don't see the > difference between rewriting the few lines of code to use libcanberra > and adapting it for a libgnome API with different semantics. Well, it seems like you could easily just keep most of the stub/noops for non-esd and create a canberra-specific path for gnome_sound_play(). That would probably cover most of the apps that just do a fire and forget gnome_sound_play(file). That would be API compatible with the non-esd libgnome. -- Dan From ianburrell at gmail.com Mon Feb 2 18:40:42 2009 From: ianburrell at gmail.com (Ian Burrell) Date: Mon, 2 Feb 2009 10:40:42 -0800 Subject: Orphan: mt-daapd In-Reply-To: <20090131031944.GA3117@imp.local> References: <20090131031944.GA3117@imp.local> Message-ID: On Fri, Jan 30, 2009 at 7:19 PM, W. Michael Petullo wrote: > The mt-daapd package is now an orphan. I have decided to stop maintaining > the package because I am now using my own dmapd software. Dmapd supports > DPAP in addition to DAAP. I hope to create a dmapd package for Fedora > in the near term. > I'll take it. - Ian From notting at redhat.com Mon Feb 2 18:42:37 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 13:42:37 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> Message-ID: <20090202184237.GB21251@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > BN> Correct. However, by the only statistics we have available, that's > BN> an amazingly small percantage of our userbase (.04%, to be > BN> precise.) > > I can't help but point out that it's disingenuous to continue to quote > that figure when it's already been stated that the main use of such > systems is in a situation where smolt will never be run. Please re-read. "the only statistics we have available". If you've got better ones, please share. Bill From ianburrell at gmail.com Mon Feb 2 18:55:45 2009 From: ianburrell at gmail.com (Ian Burrell) Date: Mon, 2 Feb 2009 10:55:45 -0800 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: 2009/2/1 Ashiqur Rahman Angel : > > 5. There has a very easy way to install a rpm package from CLI (one single > package, that has not any dependency issue or if it has, it?s possible to > install the package by ignoring it). But from Fedora 9, GUI double click rpm > install doesnt work at all. So, we need a GUI solution of it. > How much easier than "yum localinstall package.rpm" do you want? That will install the package and any dependencies. In Fedora 10, double-clicking on .rpm file launches gnome-packagekit to install the package (and any dependencies). You can even launch the GUI from the command-line with gnome-open. - Ian From tibbs at math.uh.edu Mon Feb 2 19:03:00 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Feb 2009 13:03:00 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090202184237.GB21251@nostromo.devel.redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Please re-read. No need. BN> "the only statistics we have available". "are flawed". Don't quote them at all if you know they aren't correct. That's my only point here. BN> If you've got better ones, please share. You know I don't. You also know that my not having any doesn't have any bearing at all on the fact that you shouldn't be quoting statistics you know to be incorrect. - J< From notting at redhat.com Mon Feb 2 19:08:07 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Feb 2009 14:08:07 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> Message-ID: <20090202190807.GC21980@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > BN> "the only statistics we have available". > > "are flawed". Don't quote them at all if you know they aren't > correct. That's my only point here. Best available. The only statement to the otherwise is unsubstantiated by any statistics, so it very well could be off just by a factor of two, which still makes the number pretty insignificant. Unless you say that our one statistic is flawed, so we should just give in to hearsay everywhere? Also, the usage cases that Warren stated *are not the usage cases mentioned that I was responding to*, anyway. Bill From jkeating at redhat.com Mon Feb 2 19:16:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 11:16:21 -0800 Subject: Need FESCo vote ASAP Message-ID: <1233602181.7493.45.camel@localhost.localdomain> https://fedorahosted.org/fesco/ticket/46 Proposed slip of Alpha by 2 days -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gmaxwell at gmail.com Mon Feb 2 19:17:18 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 2 Feb 2009 14:17:18 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> Message-ID: On Mon, Feb 2, 2009 at 2:03 PM, Jason L Tibbitts III wrote: >>>>>> "BN" == Bill Nottingham writes: > > BN> Please re-read. > > No need. > > BN> "the only statistics we have available". > > "are flawed". Don't quote them at all if you know they aren't > correct. That's my only point here. > > BN> If you've got better ones, please share. > > You know I don't. You also know that my not having any doesn't have > any bearing at all on the fact that you shouldn't be quoting > statistics you know to be incorrect. With x86_64 (hopefully) covering the majority of the modern systems what is the harm in leaving x86 i586 compatible? Isn't the only difference in arch=i686 as far as userspace is concerned cmov? It seems that some people question the general usefulness of cmov: http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus "Pentium or better" is a nice understandable break point. "Pentium pro or better" far less so. Fedora already has an offering for the high end (x86_64; which also implies many other performance improving differences)? From pemboa at gmail.com Mon Feb 2 19:21:08 2009 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 2 Feb 2009 13:21:08 -0600 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <16de708d0902021121w5c9f2b21t38f567e95e9bb426@mail.gmail.com> On Mon, Feb 2, 2009 at 12:55 PM, Ian Burrell wrote: > 2009/2/1 Ashiqur Rahman Angel : >> >> 5. There has a very easy way to install a rpm package from CLI (one single >> package, that has not any dependency issue or if it has, it?s possible to >> install the package by ignoring it). But from Fedora 9, GUI double click rpm >> install doesnt work at all. So, we need a GUI solution of it. >> > > How much easier than "yum localinstall package.rpm" do you want? That > will install the package and any dependencies. > > In Fedora 10, double-clicking on .rpm file launches gnome-packagekit > to install the package (and any dependencies). You can even launch > the GUI from the command-line with gnome-open. > > - Ian Double-clicking on RPMs have worked (to some degree) for several versions now. Just wanted to make that clear for those not aware. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From angel at linux.org.bd Mon Feb 2 19:29:30 2009 From: angel at linux.org.bd (Ashiqur Rahman Angel) Date: Tue, 3 Feb 2009 01:29:30 +0600 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: I think, you didnt read my whole post, that's why ur asking me "How much easier I want?" I already told "There has a very easy way to install a rpm package from CLI ". I know it very well. Because I am using Fedora from Fedora Core 1. But what about a new Linux user? What I proposed, this is not for me. However, we have already end this discussion. Thanks for your reply. On Tue, Feb 3, 2009 at 12:55 AM, Ian Burrell wrote: > 2009/2/1 Ashiqur Rahman Angel : > > > > 5. There has a very easy way to install a rpm package from CLI (one > single > > package, that has not any dependency issue or if it has, it?s possible to > > install the package by ignoring it). But from Fedora 9, GUI double click > rpm > > install doesnt work at all. So, we need a GUI solution of it. > > > > How much easier than "yum localinstall package.rpm" do you want? That > will install the package and any dependencies. > > In Fedora 10, double-clicking on .rpm file launches gnome-packagekit > to install the package (and any dependencies). You can even launch > the GUI from the command-line with gnome-open. > > - Ian > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Angel GPG key: 0x34001F46 Bangladesh Linux Users Alliance Fedora Ambassador Bangladesh http://fedoraproject.org/wiki/User:Angel Fedora -- Freedom? and rapid innovation -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjan at infradead.org Mon Feb 2 19:35:24 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 2 Feb 2009 11:35:24 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <1233598383.7493.42.camel@localhost.localdomain> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> Message-ID: <20090202113524.184e402c@infradead.org> On Mon, 02 Feb 2009 10:13:03 -0800 Jesse Keating wrote: > On Mon, 2009-02-02 at 10:10 -0800, Arjan van de Ven wrote: > > > > I doubt it. I really don't consider Moblin "fedora + changes". It > > really isn't. It is much more a "New OS + borrow from Fedora and > > SuSE" I suspect (I haven't done the count) that less than half the > > packages fall under the "borrow from Fedora" umbrella. > > Probably more if you don't count applications. > > This does bring up an interesting question. What did you have to > borrow from SuSE that the Fedora equiv (if it existed) wasn't > suitable enough? for example we took the entire toolchain from SuSE. this is not a judgment about the Fedora toolchain. Just we decided on using the SuSE one. **This not an "instead of"**. Your question only makes sense if you have the idea that we're doing a modified Fedora. We do not have that goal or idea. I realize there was some press earlier that implied that, but don't believe everything the press says. In addition to the fedora or suse originated packages there are many packages that aren't from either of them, and I expect this to grow not shrink.... So I would like to really ask you and others to stop thinking of Moblin as "Fedora with changes" and measure everything against that. I realize it's easy to think that, and a lot of things just won't make sense in that mindset. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From jspaleta at gmail.com Mon Feb 2 19:38:39 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Feb 2009 10:38:39 -0900 Subject: Moblin 2 and Fedora In-Reply-To: <20090202113524.184e402c@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> Message-ID: <604aa7910902021138h4d761929sdac9ff1c593b10a6@mail.gmail.com> On Mon, Feb 2, 2009 at 10:35 AM, Arjan van de Ven wrote: > So I would like to really ask you and others to stop thinking of Moblin > as "Fedora with changes" and measure everything against that. I realize > it's easy to think that, and a lot of things just won't make sense in > that mindset. But, I even think of Debian as Fedora with changes :-> -jef From jkeating at redhat.com Mon Feb 2 19:42:20 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 11:42:20 -0800 Subject: Moblin 2 and Fedora In-Reply-To: <20090202113524.184e402c@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> <604aa7910902020825v23bc3687m1151596fa74cb8a5@mail.gmail.com> <20090202101002.4380c005@infradead.org> <1233598383.7493.42.camel@localhost.localdomain> <20090202113524.184e402c@infradead.org> Message-ID: <1233603740.7493.50.camel@localhost.localdomain> On Mon, 2009-02-02 at 11:35 -0800, Arjan van de Ven wrote: > for example we took the entire toolchain from SuSE. > > this is not a judgment about the Fedora toolchain. Just we decided on > using the SuSE one. **This not an "instead of"**. > > Your question only makes sense if you have the idea that we're doing a > modified Fedora. We do not have that goal or idea. I realize there was > some press earlier that implied that, but don't believe everything the > press says. > > In addition to the fedora or suse originated packages there are many > packages that aren't from either of them, and I expect this to > grow not shrink.... > > > So I would like to really ask you and others to stop thinking of Moblin > as "Fedora with changes" and measure everything against that. I realize > it's easy to think that, and a lot of things just won't make sense in > that mindset. > I think I'm just trying to wrap my head around "We're going to use some bits from Fedora, and some bits from SuSE, with no real reason why, and we just hope they'll work together. Should be fun!" If I were setting out to make a new OS and I was going to borrow bits from folks, I'd try to single source all my bits possible to reduce any self inflicted integration issues. I wouldn't try to bolt together Chevy parts, Honda parts, and forge some parts on my own, that just doesn't seem like fun. Look, I"m happy that we're able to provide some bits to you, that's one of the reasons why we are here. But there really must be a decision factor somewhere that would explain why some bits are ours, and some bits are others, and I'd like to know what that is, so that the next group that comes along doesn't have to look beyond what Fedora offers when they want to build their own OS. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Feb 2 20:10:09 2009 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 2 Feb 2009 15:10:09 -0500 Subject: Validity of the CD size limit nowadays [Re: Features/ArchitectureSupport - changing what we build for] In-Reply-To: References: <20090131160728.GA28571@host0.dyn.jankratochvil.net> <20090131172219.GB7964@yoda.jdub.homelinux.org> <20090131222655.GA84354@dspnet.fr.eu.org> <20090202142122.GF3910@redhat.com> Message-ID: <20090202201008.GB23229@redhat.com> On Monday, February 02 2009, drago01 said: > On Mon, Feb 2, 2009 at 3:21 PM, Jeremy Katz wrote: > > On Sunday, February 01 2009, drago01 said: > >> On Sun, Feb 1, 2009 at 12:10 AM, Wes Shull wrote: > >> > On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert wrote: > >> > > >> >> 8Gb USB stick, which can hold bootable dvd contents, $15. Your turn. > >> > > >> > So we're leaving the developing world to Ubuntu now? > >> > >> They can/have to use the x86 livecd anyway for their older system. > >> We are talking about moving the x86_64 live spin to a DVD. > > > > The problem then is that there are more configs to maintain. > > Sure but how much extra work does this add? We can reuse the same > kickstart files and add/remove packages where it makes sense. > As for testing both need to be tested anyway. It's a fair bit of extra work because now you have to be thinking about what to substitute in, what you lose by not going with a specific package, and a slew of other things. It's not just "add more junk" because in that case, you'd end up with some duplicates that make the experience _less_ good > >And in > > point of fact, the x86_64 images were larger than CD-sized for a few > > releases and there were more than a handful of complaints from people > > wanting to use them on x86_64 boxes with only CD drives. > > Any pointers to those complains ? This shouldn't be an issue for the > majority of x86_64 boxes (and no I don't talk about boxes without > optical drives). > If there are same rare cases with such hardware they still have the > liveusb option if they don't want to buy a dvd drive/burner. Go back and read the mailing list and forum archives. I certainly wasn't the person pushing it (hell, CDs themselves haven't mattered to me now in a long time), instead, I just was the person that heard all of the complaints. And it's not just about DVD *readers*. It's also about relative pricing of media and scarcity of writers Jeremy From debarshi.ray at gmail.com Mon Feb 2 20:20:11 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 3 Feb 2009 01:50:11 +0530 Subject: Moblin 2 and Fedora In-Reply-To: <20090131153457.573762ab@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> Message-ID: <3170f42f0902021220g3bd09a2aodaa60d0de4d30a14@mail.gmail.com> > If there's something specific that the Fedora project wants to get from > Moblin we should discuss that, but lets be specific there rather than > having a discussion on the blanket hand-wavey level... Moblin Image Creater 2 [1] looks interesting to me. How does this compare to Fedora's own LiveCD tools given that it is based on them? Cheerio, Debarshi ---- [1] http://moblin.org/projects/moblin-image-creator-2 From debarshi.ray at gmail.com Mon Feb 2 20:24:16 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 3 Feb 2009 01:54:16 +0530 Subject: Fedora 11: What do we expect? In-Reply-To: References: Message-ID: <3170f42f0902021224i2017df58p7d9f40049882e2f0@mail.gmail.com> > I think, you didnt read my whole post, that's why ur asking me "How much > easier I want?" I already told "There has a very easy way to install a rpm > package from CLI ". I know it very well. Because I am using Fedora from > Fedora Core 1. But what about a new Linux user? What I proposed, this is not > for me. A new user would click the RPM file through the GUI. As Arthur and Ian said, it does work. Or did you mean something else? Cheers, Debarshi From angel at linux.org.bd Mon Feb 2 20:49:07 2009 From: angel at linux.org.bd (Ashiqur Rahman Angel) Date: Tue, 3 Feb 2009 02:49:07 +0600 Subject: Fedora 11: What do we expect? In-Reply-To: <3170f42f0902021224i2017df58p7d9f40049882e2f0@mail.gmail.com> References: <3170f42f0902021224i2017df58p7d9f40049882e2f0@mail.gmail.com> Message-ID: On Tue, Feb 3, 2009 at 2:24 AM, Debarshi Ray wrote: > > > A new user would click the RPM file through the GUI. As Arthur and Ian > said, it does work. Or did you mean something else? > > Install rpm from KDE via KPackage Kit. Anyway, I have got the reply. It?s a bug that KPackageKit can?t install rpm by double clicking. -- Angel GPG key: 0x34001F46 Bangladesh Linux Users Alliance Fedora Ambassador Bangladesh http://fedoraproject.org/wiki/User:Angel Fedora -- Freedom? and rapid innovation -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Mon Feb 2 21:56:44 2009 From: drago01 at gmail.com (drago01) Date: Mon, 2 Feb 2009 22:56:44 +0100 Subject: OpenSSL symlink hack In-Reply-To: <1233564080.3600.82.camel@vespa.frost.loc> References: <1233564080.3600.82.camel@vespa.frost.loc> Message-ID: On Mon, Feb 2, 2009 at 9:41 AM, Tomas Mraz wrote: > On Sun, 2009-02-01 at 15:58 +0100, Kevin Kofler wrote: >> Hi, >> >> can the OpenSSL compat symlink hack be dropped now that we have the alpha >> practically out of the door? I think we want to make sure all the packages >> get rebuilt against the new ABI ASAP (and most already did), and the >> symlinks are also unreliable. > > Yes, I want to drop the symlink hack today. > > There are still the following packages which were not rebuilt either > because they FTBFS due to problems unrelated to the OpenSSL upgrade or > because they have closed commit ACLs for provenpackagers. > > linkage needs to be ported to the new rb_libtorrent API, still have to do it. From walters at verbum.org Mon Feb 2 22:40:10 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 2 Feb 2009 17:40:10 -0500 Subject: can someone point out on me how gnome-keyring works? In-Reply-To: <1233595633.18004.6.camel@choeger6> References: <1233595633.18004.6.camel@choeger6> Message-ID: 2009/2/2 Christoph H?ger : > Hi, > > I want to add gnome-keyring features to the gnome branch of offlineimap. > Setting and retrieving Passwords works, but I could need some advice: > > 1. What parameters should I put into the keyring functions? I see server > and protocoll elements in the attrs dict. Does that mean gnomekeyring > stores values on a per host/service base? If yes, is it valid to put > arbitrary strings ("offlineimap") here? Think of gnome-keyring more like a "schemaless persistent encrypted Map" rather than "account system". So yes, you can put whatever attributes you want in there, and that's a reasonable thing to do. > 2. From a security point of view: How does gnomekeyring decide to give > an app access if the users select "always allow" on later calls? The application access control system is inherently broken (from a UI perspective and from a technical perspective) and should not be used. http://bugzilla.gnome.org/show_bug.cgi?id=533493 It should be disabled in Fedora as far as I know unless the changes were inadvertently reverted. > 3. Would calling the app via cron cause any communication problems? Yes; cron will not have access by default to the logged in session infrastructure (in particular the X server and session bus). This is one of the things that would be nice to fix in a more desktop integrated scheduled execution service. But sinc e cron is all we have right now, if you need gnome-keyring from cron, you need to look up the DBUS_SESSION_BUS_ADDRESS Unix environment variable. If none exists, then create your own session using dbus-launch, and gnome-keyring should be invoked through service activation when you try to talk to it. From walters at verbum.org Mon Feb 2 22:44:38 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 2 Feb 2009 17:44:38 -0500 Subject: can someone point out on me how gnome-keyring works? In-Reply-To: References: <1233595633.18004.6.camel@choeger6> Message-ID: On Mon, Feb 2, 2009 at 5:40 PM, Colin Walters wrote: > > But sinc e cron is all we > have right now, if you need gnome-keyring from cron, you need to look > up the DBUS_SESSION_BUS_ADDRESS Unix environment variable. If none > exists, then create your own session using dbus-launch, and > gnome-keyring should be invoked through service activation when you > try to talk to it. Though thinking about this further, it's obviously not going to work if you don't have a running session since you'll need the password for gnome-keyring to be able to decrypt its database. It's a pretty complicated problem. If the desktop had some way to know that you had scheduled jobs, it would probably make sense for gnome-keyring to hang around even after a session ends to provide passwords. We also *really* need to make the session bus per-uid looked up from the kernel instead of based on an environment variable. From poelstra at redhat.com Mon Feb 2 23:35:38 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 02 Feb 2009 15:35:38 -0800 Subject: Fedora 11 Bug Triage Goals :: Meeting Tomorrow (Tuesday) @ 15:00 UTC Message-ID: <4987834A.90002@redhat.com> Everyone is welcome! Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST Agenda 1) Reviewing the follow-up actions from last meeting: https://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Jan-27 2) Finalize our goals for the Fedora 11 Release Cycle. Current ideas are listed here: https://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Jan-27#Fedora_11_Goals If you get a chance and would like to follow along, please get connected to gobby in advance of the meeting http://fedoraproject.org/wiki/Communicate/GobbyHowTo We will use gobby to collaboratively finalize our goals. See you tomorrow! John From kevin at scrye.com Mon Feb 2 23:54:31 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 2 Feb 2009 16:54:31 -0700 Subject: Fedora Release Notes In-Reply-To: <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> References: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> Message-ID: <20090202165431.117a3136@ohm.scrye.com> On Mon, 2 Feb 2009 11:10:17 +1000 ryan lerch wrote: > Over at fedora-docs, there is ongoing discussion on the scope of the > release notes. At present, the release notes have evolved from a > document containing the relevant new features and important bug-fixes > into a document containing those items as well as an assortment of > extra basic documentation and howtos. For example, take the "Live > Image" section in the f10 notes [1], this is basically a brief > overview on Live Images (which were not a new feature in f10.) > > The fedora-docs project would like to get the input from the > developers on the release notes. Should we restrict the release notes > to being a document of the new and exciting features in the newest > release, and move the older, not so fresh documentation into the > relevant guides (such as the install guide)? > > Any other suggestions on the possible scope and direction of the > release notes are appreciated also! Yeah, I would like to see the release notes be smaller and just contain new information for the release. You could easily have a pointer to the install guide or other docs that contain more verbose info or info thats repeated every release. A shorter, more concise release notes I think would be a good thing. > > cheers, > ryanlerch > ryanlerch at fedoraproject.org kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From forum at ru.bir.ru Tue Feb 3 00:03:22 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Tue, 03 Feb 2009 03:03:22 +0300 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090130053144.GA25512@srcf.ucam.org> References: <20090130053144.GA25512@srcf.ucam.org> Message-ID: Matthew Garrett wrote: > The blinking cursor causes the processor and GPU to be woken up > frequently. On one of my test systems, this causes somewhere in the > region of 2 Watts of extra power consumption. I'd like to change the > default for this to false. Anyone have any objections? > Yes. I love blinking cursor. And it is a history now. If there settings to enable it - why you can't disable it if you want? From skvidal at fedoraproject.org Tue Feb 3 00:29:44 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 19:29:44 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <20090130053144.GA25512@srcf.ucam.org> Message-ID: <1233620984.27307.16.camel@rosebud> On Tue, 2009-02-03 at 03:03 +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Matthew Garrett wrote: > > The blinking cursor causes the processor and GPU to be woken up > > frequently. On one of my test systems, this causes somewhere in the > > region of 2 Watts of extra power consumption. I'd like to change the > > default for this to false. Anyone have any objections? > > > > Yes. I love blinking cursor. And it is a history now. > If there settings to enable it - why you can't disable it if you want? the point is most people won't care enough either way. And if we disable it then we save power on each machine. More power saved == less energy used == yay for the world. +1 to disabling it. -sv From bnocera at redhat.com Tue Feb 3 00:59:52 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 03 Feb 2009 00:59:52 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> Message-ID: <1233622792.3486.1653.camel@cookie.hadess.net> On Mon, 2009-02-02 at 10:20 -0800, Dan Nicholson wrote: > On Mon, Feb 2, 2009 at 9:05 AM, Bastien Nocera wrote: > > On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote: > > > >> What about the possibility of rewriting gnome_sound* to use libsydney? > >> I know it's not the most exciting work available, but that would some > >> to be the correct long term fix. It's not like the libgnome API can go > >> away prior to GNOME-3.0. > > > > It's not possible to provide an ABI or API compatible replacement, > > because gnome_sound_* exports some esound specific APIs. For example, > > gnome_sound_connection_get () and gnome_sound_sample_load(). > > > > So if you're going to change the semantics, the apps will need to be > > fixed. And if the applications need to be fixed, I don't see the > > difference between rewriting the few lines of code to use libcanberra > > and adapting it for a libgnome API with different semantics. > > Well, it seems like you could easily just keep most of the stub/noops > for non-esd and create a canberra-specific path for > gnome_sound_play(). That would probably cover most of the apps that > just do a fire and forget gnome_sound_play(file). That would be API > compatible with the non-esd libgnome. It's already just stubs, and it would break apps that rely on gnome_sound_connection_get () and gnome_sound_sample_load() to work. I also don't think we're interested in keeping libgnomeui in the future. I'd rather spend time answering questions on how to make libcanberra work with your app rather than spending time doing a half-working work-around in libgnome. From dimi at lattica.com Tue Feb 3 01:18:59 2009 From: dimi at lattica.com (Dimi Paun) Date: Mon, 02 Feb 2009 20:18:59 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233620984.27307.16.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> Message-ID: <1233623939.8745.343.camel@dimi.lattica.com> On Mon, 2009-02-02 at 19:29 -0500, seth vidal wrote: > the point is most people won't care enough either way. And if we > disable it then we save power on each machine. I can speak from personal experience with customers that people care about a blinking cursor. They are used to it, and when it goes away they are upset. > More power saved == less energy used == yay for the world. The amount of energy used is minimal. This is not the way to go about it. We should have a "Power Manager" that should have a selector between: Min power Default Max performance setting, and the "Min power" stuff should disable the cursor for the people that care for the 1W. Don't force this sort of stuff on people like that. -- Dimi Paun Lattica, Inc. From skvidal at fedoraproject.org Tue Feb 3 01:26:40 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 20:26:40 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233623939.8745.343.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> Message-ID: <1233624400.27307.17.camel@rosebud> On Mon, 2009-02-02 at 20:18 -0500, Dimi Paun wrote: > On Mon, 2009-02-02 at 19:29 -0500, seth vidal wrote: > > the point is most people won't care enough either way. And if we > > disable it then we save power on each machine. > > I can speak from personal experience with customers that people care > about a blinking cursor. They are used to it, and when it goes away > they are upset. > > > More power saved == less energy used == yay for the world. > > The amount of energy used is minimal. This is not the way to go > about it. We should have a "Power Manager" that should have a > selector between: > Min power Default Max performance > > setting, and the "Min power" stuff should disable the cursor > for the people that care for the 1W. > > Don't force this sort of stuff on people like that. > you mean in the same way you're forcing the use of more power on me? -sv From dbn.lists at gmail.com Tue Feb 3 01:31:37 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Mon, 2 Feb 2009 17:31:37 -0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <1233622792.3486.1653.camel@cookie.hadess.net> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> Message-ID: <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> On Mon, Feb 2, 2009 at 4:59 PM, Bastien Nocera wrote: > On Mon, 2009-02-02 at 10:20 -0800, Dan Nicholson wrote: >> On Mon, Feb 2, 2009 at 9:05 AM, Bastien Nocera wrote: >> > On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote: >> > >> >> What about the possibility of rewriting gnome_sound* to use libsydney? >> >> I know it's not the most exciting work available, but that would some >> >> to be the correct long term fix. It's not like the libgnome API can go >> >> away prior to GNOME-3.0. >> > >> > It's not possible to provide an ABI or API compatible replacement, >> > because gnome_sound_* exports some esound specific APIs. For example, >> > gnome_sound_connection_get () and gnome_sound_sample_load(). >> > >> > So if you're going to change the semantics, the apps will need to be >> > fixed. And if the applications need to be fixed, I don't see the >> > difference between rewriting the few lines of code to use libcanberra >> > and adapting it for a libgnome API with different semantics. >> >> Well, it seems like you could easily just keep most of the stub/noops >> for non-esd and create a canberra-specific path for >> gnome_sound_play(). That would probably cover most of the apps that >> just do a fire and forget gnome_sound_play(file). That would be API >> compatible with the non-esd libgnome. > > It's already just stubs, and it would break apps that rely on > gnome_sound_connection_get () and gnome_sound_sample_load() to work. I > also don't think we're interested in keeping libgnomeui in the future. That's exactly my point. Since ESD support has been removed in fedora, anyone trying to do gnome_sound_connection_get() will just get -1 back anyway. Furthermore, the gnome_sound_play() docs say that the sound may or may not play. So, why not just make it play a file with libcanberra? If it fails, oh well. You're in exactly the same situation you're in now. It seems pretty easy to me: void gnome_sound_play(const char *filename) { #ifdef HAVE_LIBCANBERRA_GTK ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME, filename, NULL); #endif } I understand not wanting to write new apps to use gnome_sound_play since it's deprecated. But it's existing API that can't be removed. Why not have it work for apps that haven't been ported yet (or can't be ported)? > I'd rather spend time answering questions on how to make libcanberra > work with your app rather than spending time doing a half-working > work-around in libgnome. Sure. I would not suggest that new apps use gnome_sound*. -- Dan From oget.fedora at gmail.com Tue Feb 3 01:36:09 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 2 Feb 2009 20:36:09 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233620984.27307.16.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> Message-ID: On Mon, Feb 2, 2009 at 7:29 PM, seth vidal wrote: > On Tue, 2009-02-03 at 03:03 +0300, Pavel Alexeev (aka Pahan-Hubbitus) > wrote: >> Matthew Garrett wrote: >> > The blinking cursor causes the processor and GPU to be woken up >> > frequently. On one of my test systems, this causes somewhere in the >> > region of 2 Watts of extra power consumption. I'd like to change the >> > default for this to false. Anyone have any objections? >> > >> >> Yes. I love blinking cursor. And it is a history now. >> If there settings to enable it - why you can't disable it if you want? > > the point is most people won't care enough either way. And if we disable > it then we save power on each machine. > > More power saved == less energy used == yay for the world. > > +1 to disabling it. > A quick calculation showed me that, assuming there are 10 million Fedora computers in the world, running 7/24, saving 2W per computers saves about 1 relatively large size tree (40 tons) every 2.3 days. Just for the record. Orcan From konrad at tylerc.org Tue Feb 3 01:43:13 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 2 Feb 2009 17:43:13 -0800 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233624400.27307.17.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> Message-ID: <200902021743.13916.konrad@tylerc.org> On Monday 02 February 2009 05:26:40 pm seth vidal wrote: > On Mon, 2009-02-02 at 20:18 -0500, Dimi Paun wrote: > > On Mon, 2009-02-02 at 19:29 -0500, seth vidal wrote: > > > the point is most people won't care enough either way. And if we > > > disable it then we save power on each machine. > > > > I can speak from personal experience with customers that people care > > about a blinking cursor. They are used to it, and when it goes away > > they are upset. > > > > > More power saved == less energy used == yay for the world. > > > > The amount of energy used is minimal. This is not the way to go > > about it. We should have a "Power Manager" that should have a > > selector between: > > Min power Default Max performance > > > > setting, and the "Min power" stuff should disable the cursor > > for the people that care for the 1W. > > > > Don't force this sort of stuff on people like that. > > you mean in the same way you're forcing the use of more power on me? > > > -sv No, it's a change from the long-time traditional behaviour -- the power consumption due to the cursor blinking *by default* isn't more than it used to be. The default can be changed for those obsessed with power saving. -- Conrad Meyer From dimi at lattica.com Tue Feb 3 01:46:09 2009 From: dimi at lattica.com (Dimi Paun) Date: Mon, 02 Feb 2009 20:46:09 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233624400.27307.17.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> Message-ID: <1233625569.8745.351.camel@dimi.lattica.com> On Mon, 2009-02-02 at 20:26 -0500, seth vidal wrote: > > Don't force this sort of stuff on people like that. > > > > you mean in the same way you're forcing the use of more power on me? Not at all. I'm not forcing you do to anything, I'm all for having an option and a decent UI to change this IF YOU WANT. But changing the default does indeed forces stuff on users as regular folks are not sophisticated enough to figure out WTF their computer stopped working as expected. Changing the status-quo on basic things like this is just not cool. The burden of proof is on the people doing the change, and 1W doesn't cut it. -- Dimi Paun Lattica, Inc. From skvidal at fedoraproject.org Tue Feb 3 01:47:18 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 20:47:18 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <200902021743.13916.konrad@tylerc.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <200902021743.13916.konrad@tylerc.org> Message-ID: <1233625638.27307.19.camel@rosebud> On Mon, 2009-02-02 at 17:43 -0800, Conrad Meyer wrote: > No, it's a change from the long-time traditional behaviour -- the power > consumption due to the cursor blinking *by default* isn't more than it used to > be. The default can be changed for those obsessed with power saving. It's not more than it used to be - it's the same and we can reduce power use by disabling it. Pretty easy. Also - I think I'm comfortable saying that the Fedora Project is interested in power saving. I'd be happy to ask the board about that as a specific interest and goal of the fedora project. -sv From skvidal at fedoraproject.org Tue Feb 3 01:49:04 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 20:49:04 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233625569.8745.351.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> Message-ID: <1233625744.27307.20.camel@rosebud> On Mon, 2009-02-02 at 20:46 -0500, Dimi Paun wrote: > On Mon, 2009-02-02 at 20:26 -0500, seth vidal wrote: > > > Don't force this sort of stuff on people like that. > > > > > > > you mean in the same way you're forcing the use of more power on me? > > Not at all. I'm not forcing you do to anything, I'm all for > having an option and a decent UI to change this IF YOU WANT. > > But changing the default does indeed forces stuff on users > as regular folks are not sophisticated enough to figure out > WTF their computer stopped working as expected. > > Changing the status-quo on basic things like this is just > not cool. The burden of proof is on the people doing the > change, and 1W doesn't cut it. 1w * 8-10million users does cut it, imo. -sv From skvidal at fedoraproject.org Tue Feb 3 01:53:07 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 20:53:07 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> Message-ID: <1233625987.27307.23.camel@rosebud> On Mon, 2009-02-02 at 20:36 -0500, Orcan Ogetbil wrote: > On Mon, Feb 2, 2009 at 7:29 PM, seth vidal wrote: > > On Tue, 2009-02-03 at 03:03 +0300, Pavel Alexeev (aka Pahan-Hubbitus) > > wrote: > >> Matthew Garrett wrote: > >> > The blinking cursor causes the processor and GPU to be woken up > >> > frequently. On one of my test systems, this causes somewhere in the > >> > region of 2 Watts of extra power consumption. I'd like to change the > >> > default for this to false. Anyone have any objections? > >> > > >> > >> Yes. I love blinking cursor. And it is a history now. > >> If there settings to enable it - why you can't disable it if you want? > > > > the point is most people won't care enough either way. And if we disable > > it then we save power on each machine. > > > > More power saved == less energy used == yay for the world. > > > > +1 to disabling it. > > > > A quick calculation showed me that, > assuming there are 10 million Fedora computers in the world, running 7/24, > saving 2W per computers saves about 1 relatively large size tree (40 > tons) every 2.3 days. > Just for the record. > Seems like a winner to me. thanks, -sv From jkeating at redhat.com Tue Feb 3 01:54:10 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 17:54:10 -0800 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233625569.8745.351.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> Message-ID: <1233626050.7493.63.camel@localhost.localdomain> On Mon, 2009-02-02 at 20:46 -0500, Dimi Paun wrote: > On Mon, 2009-02-02 at 20:26 -0500, seth vidal wrote: > > > Don't force this sort of stuff on people like that. > > > > > > > you mean in the same way you're forcing the use of more power on me? > > Not at all. I'm not forcing you do to anything, I'm all for > having an option and a decent UI to change this IF YOU WANT. > > But changing the default does indeed forces stuff on users > as regular folks are not sophisticated enough to figure out > WTF their computer stopped working as expected. > > Changing the status-quo on basic things like this is just > not cool. The burden of proof is on the people doing the > change, and 1W doesn't cut it. > > -- > Dimi Paun > Lattica, Inc. Actually the burden of proof isn't on anybody. The upstream maintainer and / or the downstream maintainer can choose to adjust the default setting. Period. No amount of noisy blabber on a mailing list will remove that right. Defaults change. If not, we'd all still be storing everything in /etc/. The fact that we can make this change and have real world benefit makes it all the nicer. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ngompa13 at gmail.com Tue Feb 3 02:06:49 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Mon, 2 Feb 2009 20:06:49 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> Message-ID: <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> "Pentium Pro or better" is pretty reasonable. AFAICT, if I look really hard, the earliest PC I can buy around here is the first generation Pentium II (pre MMX). Most OSes do not support the i586 arch unless it's specifically geared towards older PCs or firewall distros. Linux mainstream distros seem to be unusually keen on remaining utterly backwards compatible as far as CPUs go. I personally think going that far back is unreasonable if it isn't explicitly stated in the goals of the project itself. For example, Damn Small Linux can remain arched at i386/i486, because its goal is to run on older machines as well as newer ones. Ubuntu or Fedora don't really have any business running on older machines, but Ubuntu is exempt because of their shared base with Xubuntu, which IS aimed for older machines. OpenSUSE Linux (how I despise thee *hisses*) runs primarily on i586 arch, with the exception of the kernel and a few other packages; however, in practice it doesn't run on a Pentium I. Honestly, I think Fedora needs to stop bottlenecking its performance by not optimizing its code for i586 or i686. I would prefer the code to be optimized to i686 when built as RPMs. On Mon, Feb 2, 2009 at 1:17 PM, Gregory Maxwell wrote: > On Mon, Feb 2, 2009 at 2:03 PM, Jason L Tibbitts III > wrote: > >>>>>> "BN" == Bill Nottingham writes: > > > > BN> Please re-read. > > > > No need. > > > > BN> "the only statistics we have available". > > > > "are flawed". Don't quote them at all if you know they aren't > > correct. That's my only point here. > > > > BN> If you've got better ones, please share. > > > > You know I don't. You also know that my not having any doesn't have > > any bearing at all on the fact that you shouldn't be quoting > > statistics you know to be incorrect. > > With x86_64 (hopefully) covering the majority of the modern systems > what is the harm in leaving x86 i586 compatible? > > Isn't the only difference in arch=i686 as far as userspace is > concerned cmov? It seems that some people question the general > usefulness of cmov: > http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus > > "Pentium or better" is a nice understandable break point. "Pentium pro > or better" far less so. Fedora already has an offering for the high > end (x86_64; which also implies many other performance improving > differences)? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Tue Feb 3 02:18:20 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Feb 2009 07:48:20 +0530 Subject: Need FESCo vote ASAP In-Reply-To: <1233602181.7493.45.camel@localhost.localdomain> References: <1233602181.7493.45.camel@localhost.localdomain> Message-ID: <4987A96C.3060307@fedoraproject.org> Jesse Keating wrote: > https://fedorahosted.org/fesco/ticket/46 Proposed slip of Alpha by 2 > days Do we really need FESCo to micro manage this. FESCo has delegated this job to rel-eng and they should able to trust rel-eng with making the right decisions without voting on every small change in the schedule. Rahul From jkeating at redhat.com Tue Feb 3 02:18:33 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 18:18:33 -0800 Subject: Need FESCo vote ASAP In-Reply-To: <4987A96C.3060307@fedoraproject.org> References: <1233602181.7493.45.camel@localhost.localdomain> <4987A96C.3060307@fedoraproject.org> Message-ID: <1233627513.7493.69.camel@localhost.localdomain> On Tue, 2009-02-03 at 07:48 +0530, Rahul Sundaram wrote: > Do we really need FESCo to micro manage this. FESCo has delegated this > job to rel-eng and they should able to trust rel-eng with making the > right decisions without voting on every small change in the schedule. So you get upset when decisions are made in voice or IRC channels, so when we try and make a decision in the open via mailing list and a ticketing system, you say it's not necessary? Really? Can we win with you Rahul? Is it possible? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mjg at redhat.com Tue Feb 3 02:20:59 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 02:20:59 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233623939.8745.343.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> Message-ID: <20090203022059.GA2232@srcf.ucam.org> On Mon, Feb 02, 2009 at 08:18:59PM -0500, Dimi Paun wrote: > Min power Default Max performance So a blinking cursor indicates higher performance than a non-blinking one? You can't represent power management on a one dimensional scale. That's poor UI. -- Matthew Garrett | mjg59 at srcf.ucam.org From sundaram at fedoraproject.org Tue Feb 3 02:22:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Feb 2009 07:52:02 +0530 Subject: New package from one source In-Reply-To: References: <20090119221149.GA10949@nostromo.devel.redhat.com> <20090120184236.GA10482@nostromo.devel.redhat.com> <497A53CD.1050605@fedoraproject.org> <4980D47C.1040602@fedoraproject.org> Message-ID: <4987AA4A.7060703@fedoraproject.org> Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Rahul Sundaram wrote: >> Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> >>> As I mention above, what about your first link - main apache rpm >>> package fully ignore this guidelines! > > >> These are more best practises and aren't part oaf the packaging >> guidelines except as a reference but maintainers have to ultimately >> make their own decisions. If you find major deviations from upstream, >> it is useful to talk to the maintainers and understand why. > Off course, you talk about "maintainers have to ultimately make their > own decisions." but forbidden this right for the Fedora users who want > use mpm-itk for example?? I haven't really forbidden anything. Not my call anyway. I am just explaining to you why things are the way, they are. Maintainers decisions are going to be constrained by existing guidelines for Fedora including licensing etc. This isn't free for all space. > In other words, if I (or any other) make "Apache fork", copy it source, > patch with this patch and pack in separate source tarball on separate > URL (on Sourceforge or any else) you are accept such package into Fedora??? Again not my call but forks of projects are generally allowed independently c.f emacs vs xemacs. Rahul From sundaram at fedoraproject.org Tue Feb 3 02:23:24 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Feb 2009 07:53:24 +0530 Subject: Moblin 2 and Fedora In-Reply-To: <20090131153457.573762ab@infradead.org> References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com> <49844F3B.6060905@fedoraproject.org> <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com> <20090131110644.1a80ddf5@infradead.org> <4984BC61.3040908@fedoraproject.org> <20090131153457.573762ab@infradead.org> Message-ID: <4987AA9C.3070300@fedoraproject.org> Arjan van de Ven wrote: > On Sun, 01 Feb 2009 02:32:25 +0530 > Rahul Sundaram wrote: > >> Arjan van de Ven wrote: >> >>> If there was a "based on" relationship we would. But it's not >>> nearly so simple. >> That would depend on what of Moblin came from Fedora and what changes >> Intel made. I wouldn't dismiss the possibility so easily. > > I don't dismiss anything beforehand, and am quite open to discuss just > about anything. > > But frankly, if I look at where things are today in Moblin and where > they are going; the packages we borrowed from Fedora tend to be those > where we don't do much if any changes. > If there's something specific that the Fedora project wants to get from > Moblin we should discuss that, but lets be specific there rather than > having a discussion on the blanket hand-wavey level... It has to remain hand-wavey until we get to know about what changes have been made. If there is no changes, then there is nothing further to discuss. Rahul From sundaram at fedoraproject.org Tue Feb 3 02:30:22 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Feb 2009 08:00:22 +0530 Subject: Need FESCo vote ASAP In-Reply-To: <1233627513.7493.69.camel@localhost.localdomain> References: <1233602181.7493.45.camel@localhost.localdomain> <4987A96C.3060307@fedoraproject.org> <1233627513.7493.69.camel@localhost.localdomain> Message-ID: <4987AC3E.80202@fedoraproject.org> Jesse Keating wrote: > On Tue, 2009-02-03 at 07:48 +0530, Rahul Sundaram wrote: >> Do we really need FESCo to micro manage this. FESCo has delegated this >> job to rel-eng and they should able to trust rel-eng with making the >> right decisions without voting on every small change in the schedule. > > So you get upset when decisions are made in voice or IRC channels, so > when we try and make a decision in the open via mailing list and a > ticketing system, you say it's not necessary? Really? Can we win with > you Rahul? Is it possible? I am not sure your goal should be "winning" with me. That's pretty meaningless. You are trying to put together two unrelated things. The first problem was explained by Thorsten in a blog post which you already replied saying that we should doing it better. So that's over and we don't need to rehash it in this current unrelated discussion. For schedule changes, you are already communicating this via mailing lists including the reasons for the change. I am suggesting FESCo trust you with the decisions on this to avoid overhead for you. I don't understand your grudges while I am trying to make it easier for you to do your work. Rahul From dimi at lattica.com Tue Feb 3 02:34:45 2009 From: dimi at lattica.com (Dimi Paun) Date: Mon, 02 Feb 2009 21:34:45 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203022059.GA2232@srcf.ucam.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> Message-ID: <1233628485.8745.361.camel@dimi.lattica.com> On Tue, 2009-02-03 at 02:20 +0000, Matthew Garrett wrote: > > Min power Default Max performance > > So a blinking cursor indicates higher performance than a non-blinking > one? You can't represent power management on a one dimensional scale. > That's poor UI. Whatever. This can be worked around. Somehow on this forum saying that "90%+ of users use Windows" is a "made up statistic" whereas saying that turning off blinking on a cursor is going to save millions of trees is self evident. Yay! Changing defaults like this is just a way to shoot ourselves in the foot. Real customers/users are very finicky about the tiniest of details. Dealing with them directly is a great learning experience. Besides, we seem to enjoy pain: nobody will appreciate a non-blinking cursor, yet we know _some_ will have a big problem with it. The only people benefiting from it is the ones doing mental calculations about trees saved. That's a tiny minority. -- Dimi Paun Lattica, Inc. From sundaram at fedoraproject.org Tue Feb 3 02:41:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Feb 2009 08:11:00 +0530 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233628485.8745.361.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: <4987AEBC.70107@fedoraproject.org> Dimi Paun wrote: > Besides, we seem to enjoy pain: nobody will appreciate a non-blinking > cursor, yet we know _some_ will have a big problem with it. This thread has shown that a lot of people have a big problem with a blinking cursor. It is distracting and annoying to me. I always disable it almost immediately after a fresh installation. Rahul From mrmazda at ij.net Tue Feb 3 02:53:28 2009 From: mrmazda at ij.net (Felix Miata) Date: Mon, 02 Feb 2009 21:53:28 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233625744.27307.20.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> Message-ID: <4987B1A8.1020703@ij.net> On 2009/02/02 20:49 (GMT-0500) seth vidal composed: > 1w * 8-10million users does cut it, imo. If you really wanted to save serious power, you'd stop inducing or forcing people with less power hungry old systems (i586 ring a bell?) to replace them with considerably hungrier newer systems. New systems make much better room heaters than old systems, because they use a lot more power, far more than one extra watt. Support for old systems == really substantial conservation. -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From hanpingtian at gmail.com Tue Feb 3 02:54:11 2009 From: hanpingtian at gmail.com (=?GB2312?B?xr3M7Lqr?=) Date: Tue, 3 Feb 2009 10:54:11 +0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <20090202145646.GB32202@tango.0pointer.de> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> Message-ID: <3528361a0902021854j2f3c0e9bof4d01163be84e944@mail.gmail.com> The problem here is we disable the esd supporting when build libgnome. But if we enable it, gnome_sound_play() works just fine. ( I have tested this.) So I think although we have removed esd from Fedora 10, but we shouldn't disable esd supporting in libgnome. Right? 2009/2/2 Lennart Poettering > On Mon, 02.02.09 07:49, King InuYasha (ngompa13 at gmail.com) wrote: > > > But when you break something as major as libgnome, steps should be taken > to > > ease the transition. Perhaps the function could be forwarded? I'm not > really > > much of a programmer, but I recognize that you can't just break > > functionality in core libraries like that and expect everyone to fix > their > > apps up "just like that." Fowarding the function (for compatibility > > purposes) while deprecating it would probably be more ideal. In any case, > > that's just my two cents... > > For a core piece of an API keeping compat is certainly important. But > this is sound events, don't forget that. Quite frankly, most people have > them > deatcivated anyway. > > It has been documented that this can be disabled at compile time and > it's pretty unimportant anyway and there is a much better replacement > available. Hence I'd assume that the advantage of getting rid of this > legacy cruft will always be more attractive then keeping it around. > > Lennart > > -- > Lennart Poettering Red Hat, Inc. > lennart [at] poettering [dot] net ICQ# 11060553 > http://0pointer.net/lennart/ GnuPG 0x1A015CC4 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjg at redhat.com Tue Feb 3 03:05:20 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 03:05:20 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233628485.8745.361.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: <20090203030520.GB2591@srcf.ucam.org> On Mon, Feb 02, 2009 at 09:34:45PM -0500, Dimi Paun wrote: > Besides, we seem to enjoy pain: nobody will appreciate a non-blinking > cursor, yet we know _some_ will have a big problem with it. The only > people benefiting from it is the ones doing mental calculations about > trees saved. That's a tiny minority. I've spoken to several customers who find even single watt savings interesting. Claiming that they're in the minority is an unerified statistic - claiming that this change saves power is not. -- Matthew Garrett | mjg59 at srcf.ucam.org From sundaram at fedoraproject.org Tue Feb 3 03:39:53 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Feb 2009 09:09:53 +0530 Subject: Fedora 11: What do we expect? In-Reply-To: <16de708d0902011330t4559ea63tb3ff5458e0d50add@mail.gmail.com> References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> <49861171.3070403@redhat.com> <16de708d0902011330t4559ea63tb3ff5458e0d50add@mail.gmail.com> Message-ID: <4987BC89.4080704@fedoraproject.org> Arthur Pemberton wrote: > > It's more than the widget set that will likely be different. the Gnome > version will likely have too few options to be useful. If you want to promote KDE, help the KDE SIG instead of making bad assumptions about programs you haven't used. All of the PackageKit functionality can be exposed in any frontend and GNOME frontend actually does support more options currently simply because it is developed in sync with PackageKit. Some of the options might be exposed via gconf instead of in the GUI. More options doesn't necessarily lead to a more useful program either. Rahul From gospo at redhat.com Tue Feb 3 04:17:29 2009 From: gospo at redhat.com (Andy Gospodarek) Date: Mon, 2 Feb 2009 23:17:29 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203030520.GB2591@srcf.ucam.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <20090203030520.GB2591@srcf.ucam.org> Message-ID: <20090203041728.GF22333@gospo.rdu.redhat.com> On Tue, Feb 03, 2009 at 03:05:20AM +0000, Matthew Garrett wrote: > On Mon, Feb 02, 2009 at 09:34:45PM -0500, Dimi Paun wrote: > > > Besides, we seem to enjoy pain: nobody will appreciate a non-blinking > > cursor, yet we know _some_ will have a big problem with it. The only > > people benefiting from it is the ones doing mental calculations about > > trees saved. That's a tiny minority. > > I've spoken to several customers who find even single watt savings > interesting. Claiming that they're in the minority is an unerified > statistic - claiming that this change saves power is not. > And your implied claim that it's a majority is nothing more than anecdotal as well. In fact, I would even say the verification of your wattage-savings is a bit of a guess based on the description I've seen of your testing. That being said, I'm all for power savings, so I think it's a great idea and that it should be done. I'm sure I'll type 'reset' a few times on the console before I realize I've picked up the change and my cursor isn't supposed to blink, but it won't be the end of the world. -andy From mjg at redhat.com Tue Feb 3 04:24:11 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 04:24:11 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203041728.GF22333@gospo.rdu.redhat.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <20090203030520.GB2591@srcf.ucam.org> <20090203041728.GF22333@gospo.rdu.redhat.com> Message-ID: <20090203042411.GA4194@srcf.ucam.org> On Mon, Feb 02, 2009 at 11:17:29PM -0500, Andy Gospodarek wrote: > And your implied claim that it's a majority is nothing more than > anecdotal as well. In fact, I would even say the verification of your > wattage-savings is a bit of a guess based on the description I've seen > of your testing. Oh, I'm certainly not going to claim that a majority of our users care about power consumption. I've got absolutely no idea what the relative weightings are, just anecdotes in both direction. That said, if you've got any better ways to measure the power difference, I'd be happy to provide more figures. The 2W one pretty closely matches the expected figure (40ms of smoothing plus a frame for the change to take effect times two transitions per second, gives a figure of a little more than 10% of the time in an upclocked state, and 18W or so between the upclocked and downclocked figures on the hardware in question) so I'm fairly happy with the result. -- Matthew Garrett | mjg59 at srcf.ucam.org From jspaleta at gmail.com Tue Feb 3 04:25:43 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Feb 2009 19:25:43 -0900 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203041728.GF22333@gospo.rdu.redhat.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <20090203030520.GB2591@srcf.ucam.org> <20090203041728.GF22333@gospo.rdu.redhat.com> Message-ID: <604aa7910902022025o6bb1f36y3dff8e85a8ed5395@mail.gmail.com> On Mon, Feb 2, 2009 at 7:17 PM, Andy Gospodarek wrote: > And your implied claim that it's a majority is nothing more than > anecdotal as well. In fact, I would even say the verification of your > wattage-savings is a bit of a guess based on the description I've seen > of your testing. Are you proposing a better methodology? His power saving calculation methodology is the only thing in this thread which can be tested and verified by everyone. I haven't seen anyone other than him go through the trouble of doing their own power consumption testings and coming back with different numbers. In the absence of a better methodology, there isn't a basis to discount his numbers. Would it make you feel any better if I did the exact same test with a different brand of meter on my desktop system? -jef From jkeating at redhat.com Tue Feb 3 04:52:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 02 Feb 2009 20:52:35 -0800 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4987B1A8.1020703@ij.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> <4987B1A8.1020703@ij.net> Message-ID: <1233636755.7493.72.camel@localhost.localdomain> On Mon, 2009-02-02 at 21:53 -0500, Felix Miata wrote: > > If you really wanted to save serious power, you'd stop inducing or forcing > people with less power hungry old systems (i586 ring a bell?) to replace them > with considerably hungrier newer systems. New systems make much better room > heaters than old systems, because they use a lot more power, far more than > one extra watt. Support for old systems == really substantial conservation. Isn't it odd then, that each new system I buy happens to use lower power over time than previous systems? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue Feb 3 04:58:30 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Feb 2009 23:58:30 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233636755.7493.72.camel@localhost.localdomain> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> <4987B1A8.1020703@ij.net> <1233636755.7493.72.camel@localhost.localdomain> Message-ID: <1233637110.3238.0.camel@rosebud> On Mon, 2009-02-02 at 20:52 -0800, Jesse Keating wrote: > On Mon, 2009-02-02 at 21:53 -0500, Felix Miata wrote: > > > > If you really wanted to save serious power, you'd stop inducing or forcing > > people with less power hungry old systems (i586 ring a bell?) to replace them > > with considerably hungrier newer systems. New systems make much better room > > heaters than old systems, because they use a lot more power, far more than > > one extra watt. Support for old systems == really substantial conservation. > > Isn't it odd then, that each new system I buy happens to use lower power > over time than previous systems? Including manufacturing cost, that's not entirely true. -sv From pemboa at gmail.com Tue Feb 3 05:33:32 2009 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 2 Feb 2009 23:33:32 -0600 Subject: Fedora 11: What do we expect? In-Reply-To: <4987BC89.4080704@fedoraproject.org> References: <3170f42f0902010809nfd8a22bv4343edd95e14affa@mail.gmail.com> <49861171.3070403@redhat.com> <16de708d0902011330t4559ea63tb3ff5458e0d50add@mail.gmail.com> <4987BC89.4080704@fedoraproject.org> Message-ID: <16de708d0902022133t187d69adi7706403724c60310@mail.gmail.com> On Mon, Feb 2, 2009 at 9:39 PM, Rahul Sundaram wrote: > Arthur Pemberton wrote: > >> >> It's more than the widget set that will likely be different. the Gnome >> version will likely have too few options to be useful. > > If you want to promote KDE, help the KDE SIG instead of making bad > assumptions about programs you haven't used. All of the PackageKit > functionality can be exposed in any frontend and GNOME frontend actually > does support more options currently simply because it is developed in sync > with PackageKit. Some of the options might be exposed via gconf instead of > in the GUI. More options doesn't necessarily lead to a more useful program > either. Sorry, I shouldn't have made that comment. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From fedora at leemhuis.info Tue Feb 3 05:37:22 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Feb 2009 06:37:22 +0100 Subject: Fedora Release Notes In-Reply-To: <20090202165431.117a3136@ohm.scrye.com> References: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> <20090202165431.117a3136@ohm.scrye.com> Message-ID: <4987D812.90008@leemhuis.info> On 03.02.2009 00:54, Kevin Fenzi wrote: > On Mon, 2 Feb 2009 11:10:17 +1000 > ryan lerch wrote: > >> Over at fedora-docs, there is ongoing discussion on the scope of the >> release notes. At present, the release notes have evolved from a >> document containing the relevant new features and important bug-fixes >> into a document containing those items as well as an assortment of >> extra basic documentation and howtos. For example, take the "Live >> Image" section in the f10 notes [1], this is basically a brief >> overview on Live Images (which were not a new feature in f10.) >> >> The fedora-docs project would like to get the input from the >> developers on the release notes. Should we restrict the release notes >> to being a document of the new and exciting features in the newest >> release, and move the older, not so fresh documentation into the >> relevant guides (such as the install guide)? >> >> Any other suggestions on the possible scope and direction of the >> release notes are appreciated also! > > Yeah, I would like to see the release notes be smaller and just contain > new information for the release. You could easily have a pointer to the > install guide or other docs that contain more verbose info or info > thats repeated every release. +1 ; some more thoughts on this: http://thorstenl.blogspot.com/2008/12/read-same-paragraphs-every-half-year.html CU knurd From gmaxwell at gmail.com Tue Feb 3 06:01:28 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 3 Feb 2009 01:01:28 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> Message-ID: 2009/2/2 King InuYasha : [snip] > Honestly, I think Fedora needs to stop > bottlenecking its performance by not optimizing its code for i586 or i686. I > would prefer the code to be optimized to i686 when built as RPMs. -march != -mtune. The code is already tuned for more modern CPUs. Allow me to repeat this: (loudly, not to be mean but because people seem to miss it) FEDORA x86 IS ALREADY OPTIMIZED FOR MODERN CPUS. mtune should result in the overwhelming majority of the performance difference with none of the compatibility issues. -march=i686 adds a single instruction of disputable value, cmov. In exchange for getting this one additional instruction it breaks compatibility with pentium, VIA C3 (Nehemiah has cmov, but eden does not; I have an eden600 board here which is only ~3 years old!) , AMD K6, etc and potential performance problems on Pentium 4. Do you have benchmarks that show given a constant -mtune that -march=i686 makes a material difference for any significant userspace apps vs -march=i586, if not why are you being so insistent and damning of the current compatible behavior? We know that -march=i686 will break compatibility for a small but measurable number of users (and potentially a larger unmeasurable number), do we know if we'll even get a measurable gain in exchange? We would see much more substantial gains from things like -msse2 & fpmath=sse but, unfortunately, unlike i586 there are a *lot* of systems out there (and still being sold) which do not have all the fancy instruction set extensions. Repeating myself here? When it comes down to it, we already have a "performance compiled" distribution: x86_64 which has every i686 knob turned on and then some. If you care about whatever really minute gain you'd get out of arch=i686, then you really should be looking for an x86_64 system. (The higher end atoms are quite attractive I hear?) From seg at haxxed.com Tue Feb 3 08:40:54 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Feb 2009 02:40:54 -0600 Subject: Compiler flags: upstream or Fedora ? In-Reply-To: References: <4986BDAE.8010105@freenet.de> <49870C08.3080509@redhat.com> Message-ID: <1233650454.30526.35.camel@localhost.localdomain> On Mon, 2009-02-02 at 16:36 +0100, Aur?lien Bompard wrote: > > Let me get this straight, you asked upstream about this and that's what they > > said? Any pointers/references? > > OK, done : http://spring.clan-sy.com/phpbb/viewtopic.php?p=330813#p330813 > > In short : they don't mind us using our flags, but they warn us that > it may prevent users from playing the game online. They're depending on predictable FP for network protocol? That's so very wrong. Sounds like they need to rethink their network protocol. (Don't use deltas, enforce a single point of truth, maybe use fixed point instead...) > In particular, they advise against using march=i386 for this reason. > Since we're talking about a 3D game, which would only be playable on > rather powerful hardware, would it be OK to use the march=i686 flag ? If upstream has optimized their code for -O3 rather than the default -O2, I would carry that over. Nothing else is going to make a significant enough difference. Fedora flags should override all else. Getting the stack protector flags in there is a MUST. Generally what you should do is append the Fedora flags after the upstream. Later flags override earlier ones. You do want stuff like -ffast-math and -std=c99 to carry over... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Feb 3 09:22:13 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Feb 2009 03:22:13 -0600 Subject: support for latest (radeon) hardware In-Reply-To: References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com> <497B0779.7020708@leemhuis.info> <20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info> <1232819460.8363.106.camel@localhost.localdomain> <1233084071.19014.36.camel@localhost.localdomain> Message-ID: <1233652933.30526.38.camel@localhost.localdomain> On Wed, 2009-01-28 at 11:50 +0100, Kevin Kofler wrote: > Callum Lerwick wrote: > > I have Shit To Do, and it looks like I'm going to have to revert my > > entire Xorg back to F9 to do it. > > At least you have that option. If only the old version was available, there > would be no such option. I can't wrap my brain around what you're saying. If we had stuck with the old working version, then it would be working and there would be no problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bochecha at fedoraproject.org Tue Feb 3 10:04:45 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 3 Feb 2009 11:04:45 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233628485.8745.361.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> > The only > people benefiting from it is the ones doing mental calculations about > trees saved. That's a tiny minority. Actually, I would say that basically everyone benefits from any power savings, no matter how small they are (you know, reducing our energy consumption, saving the planet, all of that...) FWIW, I never even noticed my cursor was blinking, so I would love to not notice it stopped blinking if it reduces power consumption. ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From bochecha at fedoraproject.org Tue Feb 3 10:15:13 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 3 Feb 2009 11:15:13 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233625638.27307.19.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <200902021743.13916.konrad@tylerc.org> <1233625638.27307.19.camel@rosebud> Message-ID: <2d319b780902030215l4a4856cay18a8ee0fe544ec92@mail.gmail.com> > Also - I think I'm comfortable saying that the Fedora Project is > interested in power saving. > > I'd be happy to ask the board about that as a specific interest and goal > of the fedora project. Rodrigo Padula initiated this: https://fedoraproject.org/wiki/Zero_Carbon https://www.redhat.com/archives/fedora-marketing-list/2009-January/msg00059.html https://www.redhat.com/archives/fedora-marketing-list/2009-January/msg00121.html When he announced he was willing to launch this initiative, everyone was thrilled. The Board didn't endorse officially the project, but they didn't say Rodrigo shouldn't use the Fedora brand on this. In France, we have an adage that basically says "the one who doesn't say anything agrees". ;) ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From promac at gmail.com Tue Feb 3 10:37:46 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Tue, 3 Feb 2009 08:37:46 -0200 Subject: What is the state of bulez4? Message-ID: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> Hi, since I started using F10 in my main computer, I have not been able to pair a single bluetooth device, either using bluez-gnome or hidd. This computer still has F8 installed on another disk, and using F8, I have no problem at all. This ubuntu bug report is the closest to my problems I could find: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502 I upgraded to bluez 4.28, but not has changed. Any suggestion? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Tue Feb 3 11:44:42 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 3 Feb 2009 13:44:42 +0200 (EET) Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233628485.8745.361.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: On Mon, 2 Feb 2009, Dimi Paun wrote: > > On Tue, 2009-02-03 at 02:20 +0000, Matthew Garrett wrote: >>> Min power Default Max performance >> >> So a blinking cursor indicates higher performance than a non-blinking >> one? You can't represent power management on a one dimensional scale. >> That's poor UI. > > Whatever. This can be worked around. > > Somehow on this forum saying that "90%+ of users use Windows" is a > "made up statistic" whereas saying that turning off blinking on a cursor > is going to save millions of trees is self evident. Yay! > > Changing defaults like this is just a way to shoot ourselves in the > foot. Real customers/users are very finicky about the tiniest of > details. Dealing with them directly is a great learning experience. > > Besides, we seem to enjoy pain: nobody will appreciate a non-blinking > cursor, Wrong. > yet we know _some_ will have a big problem with it. The only > people benefiting from it is the ones doing mental calculations about > trees saved. That's a tiny minority. Ignore the power savings aspect just for a second. My television has a power on led below the screen. It blinks when the tv is starting up and when the remote control is used, both cases have a very clear and sane purpose. It does NOT blink while you're watching the tv, and for a good reason too. Blinking things tend to draw attention, and in the case of Blinky the Cursor it's drawing your attention to the fact that there is nothing at all to attend to. It can also cause seizures for people with epilepsy or other disorders. Now, somebody please tell me: what is the grande justification of consuming a few extra wats per every computer in the world to attempt to draw the users attention to exactly nothing, despite being known to cause health issues to some people while doing so? And "it's always done that" is not an answer. - Panu - From jan.kratochvil at redhat.com Tue Feb 3 12:07:38 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Tue, 3 Feb 2009 13:07:38 +0100 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090202174624.GE20094@nostromo.devel.redhat.com> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130231847.GA20809@host0.dyn.jankratochvil.net> <20090202174624.GE20094@nostromo.devel.redhat.com> Message-ID: <20090203120738.GA20587@host0.dyn.jankratochvil.net> On Mon, 02 Feb 2009 18:46:24 +0100, Bill Nottingham wrote: > Jan Kratochvil (jan.kratochvil at redhat.com) said: > > Particularly why not to automatically install the whole x86_64 distro where > > appropriate? The DVD media should contain both arches as in the real world > > found out the users are not aware if they have 64bit-capable hardware. > > Well, to be somewhat glib, because that sort of setup wouldn't actually fit on > a DVD. Agree; I just was thinking about the LiveCD/DVD installation mode and there is enough room for i686+x86_64 LiveDVD. I find hard to believe Fedora still in the 21st century suggests degrading the machine by a 32bit OS: http://fedoraproject.org/get-fedora Regards, Jan From drago01 at gmail.com Tue Feb 3 12:56:10 2009 From: drago01 at gmail.com (drago01) Date: Tue, 3 Feb 2009 13:56:10 +0100 Subject: Fedora Release Notes In-Reply-To: <4987D812.90008@leemhuis.info> References: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> <20090202165431.117a3136@ohm.scrye.com> <4987D812.90008@leemhuis.info> Message-ID: On Tue, Feb 3, 2009 at 6:37 AM, Thorsten Leemhuis wrote: > > > On 03.02.2009 00:54, Kevin Fenzi wrote: >> >> On Mon, 2 Feb 2009 11:10:17 +1000 >> ryan lerch wrote: >> >>> Over at fedora-docs, there is ongoing discussion on the scope of the >>> release notes. At present, the release notes have evolved from a >>> document containing the relevant new features and important bug-fixes >>> into a document containing those items as well as an assortment of >>> extra basic documentation and howtos. For example, take the "Live >>> Image" section in the f10 notes [1], this is basically a brief >>> overview on Live Images (which were not a new feature in f10.) >>> >>> The fedora-docs project would like to get the input from the >>> developers on the release notes. Should we restrict the release notes >>> to being a document of the new and exciting features in the newest >>> release, and move the older, not so fresh documentation into the >>> relevant guides (such as the install guide)? >>> >>> Any other suggestions on the possible scope and direction of the >>> release notes are appreciated also! >> >> Yeah, I would like to see the release notes be smaller and just contain >> new information for the release. You could easily have a pointer to the >> install guide or other docs that contain more verbose info or info >> thats repeated every release. > > +1 ; some more thoughts on this: > http://thorstenl.blogspot.com/2008/12/read-same-paragraphs-every-half-year.html +1 Release Notes are not a place for random docs, it should just tell the reader about changes/new features. Just add links to related docs if necessary. From dominik at greysector.net Tue Feb 3 13:27:35 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 3 Feb 2009 14:27:35 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: <20090203132734.GA5846@mokona.greysector.net> On Tuesday, 03 February 2009 at 12:44, Panu Matilainen wrote: [...] > Ignore the power savings aspect just for a second. > > My television has a power on led below the screen. It blinks when the tv > is starting up and when the remote control is used, both cases have a very > clear and sane purpose. It does NOT blink while you're watching the tv, > and for a good reason too. Bad analogy. TV is non-interactive. > Blinking things tend to draw attention, and in the case of Blinky the > Cursor it's drawing your attention to the fact that there is nothing at > all to attend to. False. > It can also cause seizures for people with epilepsy or > other disorders. Really? Do you have links to some conclusive research? > Now, somebody please tell me: what is the grande justification of > consuming a few extra wats per every computer in the world to attempt to > draw the users attention to exactly nothing, despite being known to cause > health issues to some people while doing so? And "it's always done that" > is not an answer. While I agree that power savings are important, the blinking cursor indicates (to me) that the application is waiting for my (textual) input "here" or that "this is where you stopped typing". Both are worth drawing my attention. So please, change the default if you will, but mention it in the release notes and give me a way to turn it back on. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Tue Feb 3 13:32:23 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 3 Feb 2009 14:32:23 +0100 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> Message-ID: <20090203133223.GB5846@mokona.greysector.net> On Tuesday, 03 February 2009 at 07:01, Gregory Maxwell wrote: > 2009/2/2 King InuYasha : > [snip] > > Honestly, I think Fedora needs to stop > > bottlenecking its performance by not optimizing its code for i586 or i686. I > > would prefer the code to be optimized to i686 when built as RPMs. > > -march != -mtune. The code is already tuned for more modern CPUs. > Allow me to repeat this: (loudly, not to be mean but because people > seem to miss it) FEDORA x86 IS ALREADY OPTIMIZED FOR MODERN CPUS. > > mtune should result in the overwhelming majority of the performance > difference with none of the compatibility issues. -march=i686 adds a > single instruction of disputable value, cmov. It is not of disputable value. While FFmpeg is not part of Fedora (it's in RPMFusion), its H.264 decoder uses cmov to gain measurable speed increase in decoding. > In exchange for getting > this one additional instruction it breaks compatibility with pentium, > VIA C3 (Nehemiah has cmov, but eden does not; I have an eden600 board > here which is only ~3 years old!) , AMD K6, etc and potential > performance problems on Pentium 4. Pentium 4 is one big performance problem. Nothing optimized (-mtune) for P4 will run efficiently on everything else. IMHO we shouldn't care too much for P4, because doing so will be at the cost of everyone else. > Do you have benchmarks that show given a constant -mtune that > -march=i686 makes a material difference for any significant userspace > apps vs -march=i586, if not why are you being so insistent and > damning of the current compatible behavior? Which applications do you suggest for testing this hypothesis? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From stickster at gmail.com Tue Feb 3 14:21:35 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 3 Feb 2009 09:21:35 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <2d319b780902030215l4a4856cay18a8ee0fe544ec92@mail.gmail.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <200902021743.13916.konrad@tylerc.org> <1233625638.27307.19.camel@rosebud> <2d319b780902030215l4a4856cay18a8ee0fe544ec92@mail.gmail.com> Message-ID: <20090203142135.GC4852@localhost.localdomain> On Tue, Feb 03, 2009 at 11:15:13AM +0100, Mathieu Bridon (bochecha) wrote: > > Also - I think I'm comfortable saying that the Fedora Project is > > interested in power saving. > > > > I'd be happy to ask the board about that as a specific interest and goal > > of the fedora project. > > Rodrigo Padula initiated this: > https://fedoraproject.org/wiki/Zero_Carbon > https://www.redhat.com/archives/fedora-marketing-list/2009-January/msg00059.html > https://www.redhat.com/archives/fedora-marketing-list/2009-January/msg00121.html > > When he announced he was willing to launch this initiative, everyone > was thrilled. The Board didn't endorse officially the project, but > they didn't say Rodrigo shouldn't use the Fedora brand on this. > > In France, we have an adage that basically says "the one who doesn't > say anything agrees". ;) There shouldn't be any problem branding an initiative that operates inside the Fedora Project and that otherwise doesn't conflict with our objectives. The Fedora trademarks are meant to be used inside the Fedora Project that way, and outside the Project in accordance with the guidelines: http://fedoraproject.org/wiki/Legal:Trademark_guidelines -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Tue Feb 3 14:23:27 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 3 Feb 2009 09:23:27 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233625638.27307.19.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <200902021743.13916.konrad@tylerc.org> <1233625638.27307.19.camel@rosebud> Message-ID: <20090203142327.GD4852@localhost.localdomain> On Mon, Feb 02, 2009 at 08:47:18PM -0500, seth vidal wrote: > On Mon, 2009-02-02 at 17:43 -0800, Conrad Meyer wrote: > > > No, it's a change from the long-time traditional behaviour -- the power > > consumption due to the cursor blinking *by default* isn't more than it used to > > be. The default can be changed for those obsessed with power saving. > > It's not more than it used to be - it's the same and we can reduce power > use by disabling it. Pretty easy. > > Also - I think I'm comfortable saying that the Fedora Project is > interested in power saving. > > I'd be happy to ask the board about that as a specific interest and goal > of the fedora project. We should be interested in saving power, but shouldn't use that as a sole reason to disable Fedora interest groups' activities. For instance, it probably saves significant power for us to never issue another Fedora Live CD that uses a runlevel other than 3, but that's an unreasonable target. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Tue Feb 3 15:15:08 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Feb 2009 15:15:08 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> Message-ID: <49885F7C.8060608@redhat.com> Mathieu Bridon (bochecha) wrote: >> The only >> people benefiting from it is the ones doing mental calculations about >> trees saved. That's a tiny minority. > > Actually, I would say that basically everyone benefits from any power > savings, no matter how small they are (you know, reducing our energy > consumption, saving the planet, all of that...) It's even simpler than that: efficiency is a fundamental measure in all engineering. More efficiency is always better, regardless of planets, energy crises, and so on. I'm surprised we're having this argument at all, it's such a no-brainer. Andrew. From kraxel at redhat.com Tue Feb 3 15:27:18 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 03 Feb 2009 16:27:18 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090130053144.GA25512@srcf.ucam.org> References: <20090130053144.GA25512@srcf.ucam.org> Message-ID: <49886256.60605@redhat.com> Matthew Garrett wrote: > The blinking cursor causes the processor and GPU to be woken up > frequently. On one of my test systems, this causes somewhere in the > region of 2 Watts of extra power consumption. I'd like to change the > default for this to false. Anyone have any objections? Is it possible to change the color too btw? I can't stand the blinking cursor, especially the block cursor in terminals. I've configured my xterms to show a colored cursor though, so you can easily find it even though it doesn't blink. cheers, Gerd From harald at redhat.com Tue Feb 3 15:40:48 2009 From: harald at redhat.com (Harald Hoyer) Date: Tue, 03 Feb 2009 16:40:48 +0100 Subject: look at this: samsung nc10 bootchart with mobil V2 In-Reply-To: <498347DE.9020507@redhat.com> References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com> <1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com> <20090130035404.GC4570@nostromo.devel.redhat.com> <1233288493.3698.67.camel@localhost.localdomain> <20090130150217.GB8869@nostromo.devel.redhat.com> <1233339915.30808.6.camel@localhost.localdomain> <498347DE.9020507@redhat.com> Message-ID: Brian Maly wrote: > Simo Sorce wrote: >> >> >>>> Why fedora's udev seem to slow down another bit while moblin's udev seem >>>> not ? >>>> >>> The second udev is just more rules. >>> >> >> What about parallelizing udev and rc like in moblin ? Any gotcha there ? >> >> Simo. >> >> > > What would happen if you parallelizing udev and rc on some ancient piece > of hardware? Im thinking you might not ever get to a boot screen. > But you could check to see what sort of CPU you have and parallelize > conditionally if the hardware can handle it. Conceptually I think > parallelizing this stuff is a novel idea. Its feasible in that its been > done (i.e. the demo). And if we could optimize udev a bit we might gain > a few more seconds there too. > Good topic of discussion anyway... > > > Brian > > And how do you know, that an rc script does not need a device, which is created by udev? From jakub at redhat.com Tue Feb 3 15:48:36 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 16:48:36 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 Message-ID: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Hi! In the past few days I've done a mass rebuild of rawhide-20090126 in mock with gcc-4.4.0-0.9 (and corresponding libtool). 6228 packages were successfully built, for the rest I've tried to rebuild them also with gcc-4.3.2-7 (though I ran out of time, so a couple of packages weren't attempted with 4.3). Here are the most common causes of the regressions (fails to build with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7): - 142 failures C++ () no longer includes . So does , , , . When you need anything from C stdio.h, such as EOF, *printf*, *scanf*, remove etc., add #include to all sources that need it. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/cstdio/ - 22 failures G++ 4.4 rejects int main () { return main (); } or int main () { main (); return 0; }, as main shouldn't be used within the program (see ISO C++ [basic.start.main]/3). This breaks some configure scripts, e.g. AC_CHECK_LIB with second argument main as in AC_CHECK_LIB(stdc++,main,,AC_MSG_ERROR([libstdc++ not installed])) will now fail. As AC_CHECK_LIB isn't well suited for C++, which requires prototypes and AC_CHECK_LIB doesn't provide them, I guess AC_CHECK_LIB(stdc++,int,,AC_MSG_ERROR([libstdc|| not installed])) could be used instead. This results in int main () { return int (); } or int main () { int (); return 0; } Only packages that actually failed to build because of this are listed, there are many more that are affected by it though. Look for checking for main in -l... giving no, even for packages that succeeded. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/main/ - 15 failures C++ () no longer includes . Neither does . When you need uint32_t, uint8_t etc., #include . http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdint/ - 15 failures #elif argument is now evaluated even if earlier #if/#elif condition evaluated non-zero, to make sure they are valid constant expressions. See http://gcc.gnu.org/PR36320 To fix this, either use #else when you want it instead of #elif (e.g. several packages use #elif without any argument at all), or use #else #if ... #endif. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/elif/ - 8 failures glib2's gthread.h contains a couple of aliasing issues (e.g. in g_once_init_enter) and a bunch of programs get bitten by it when they inline it. This should be fixed in glib2. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/glib.aliasing/ - 6 failures Other aliasing problem. In the GCC 4.3 -> 4.4 transition the most common problem is: char buf[NNN]; // or unsigned char or signed char ... ((struct somestruct *)buf)->somefield = 1 While you can access any object through char, unsigned char or signed char pointer and modify parts/all of it, it is not the other way around. In this case you probably want a union of the buffer and struct somestruct. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/aliasing/ - 2 failures GCC bugs that were already fixed in newer gcc 4.4 (4.4.0-0.13 should work). http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/already_fixed/ - 1 failure Package built with -Werror, where one extra warning appeared. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/Werror/ - 1 failure g++ now errors on: struct C { virtual ~C (); }; struct B : public C { int i; }; struct A { const B a; A () { bar (&a); } void bar (const B *); }; while previously it only errored if C virtual wasn't involved. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/uninit/ - 1 failure __builtin_stdarg_start has been removed. #include should be used, rather than writing stuff by hand, and if really necessary (why?), then at least it needs to use __builtin_va_start instead. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdarg/ - 1 failure open with O_CREAT set in the second argument needs to have 3 arguments, not just 2. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/open2/ - 1 failure free called with a pointer to non-heap allocated object. E.g. char buf[128], *bufp; ... bufp = buf; if (something) { bufp = malloc (somesize); ... } ... if (bufp != buf) free (buf); // Should have been bufp. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/nonheapfree/ - 30 failures Unsorted stuff that succeeds to build with 4.3 and fails to build with 4.4. Only looked briefly at openbabel, in which case the bug is that it has locale.h in the include search path, which overrides the system . http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/unsorted/ - 31 failures Various mock related issues, packages failed at root.log stage, before starting to build. Some might be related to mock being used on RHEL5 instead of a recent fedora. http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/deps/ - 167 failures packages that failed to build both with gcc 4.3 and 4.4 http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/ - 117 failures unanalyzed packages with failed to build with 4.4, but 4.3 build wasn't performed (ran out of time), so either they fall into fails-even-with-43 category, or into unsorted. Jakub From loganjerry at gmail.com Tue Feb 3 15:37:14 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 3 Feb 2009 08:37:14 -0700 Subject: Common Lisp Message-ID: <870180fe0902030737w5500d0a9gdb8de0632210a09a@mail.gmail.com> I've been looking at some of the review requests for Common Lisp packages. I could review them, but I don't really understand common-lisp-controller. It looks like I need scripts for each Common Lisp implementation of interest in /usr/lib/common-lisp/bin. I don't have any. Is anybody working on those scripts? I'm the gcl maintainer: should I be writing a script for it? If so, are there any examples I could look at to help me sort through what the script should do? -- Jerry James http://loganjerry.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitr at volny.cz Tue Feb 3 15:50:10 2009 From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=) Date: Tue, 03 Feb 2009 16:50:10 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <49885F7C.8060608@redhat.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> Message-ID: <1233676210.3407.26.camel@localhost.localdomain> Andrew Haley p??e v ?t 03. 02. 2009 v 15:15 +0000: > Mathieu Bridon (bochecha) wrote: > >> The only > >> people benefiting from it is the ones doing mental calculations about > >> trees saved. That's a tiny minority. > > > > Actually, I would say that basically everyone benefits from any power > > savings, no matter how small they are (you know, reducing our energy > > consumption, saving the planet, all of that...) > > It's even simpler than that: efficiency is a fundamental measure in all > engineering. More efficiency is always better, regardless of planets, > energy crises, and so on. Meeting requirements is more important than efficiency. Given a task, engineers focus on performing it efficiently, but they are not always at liberty to work on a different task just because it can be performed more efficiently. (Forced labor >16 hours a day is an efficient way use a fixed amount of people to perform some tasks, but we are not building labor camps just because it is efficient.) In this case, "blinking cursor" is a requirement of some users, not an internal detail of the implementation that can be changed at will if it improves efficiency. Mirek From aph at redhat.com Tue Feb 3 15:55:23 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Feb 2009 15:55:23 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233676210.3407.26.camel@localhost.localdomain> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> Message-ID: <498868EB.8080209@redhat.com> Miloslav Trma? wrote: > In this case, "blinking cursor" is a requirement of some users, not an > internal detail of the implementation that can be changed at will if it > improves efficiency. A few, maybe, but in general this is quite incredible. The idea that we should be wasting a fractional percentage of the total power budget on something so pointless is utterly absurd. Andrew. From Jochen at herr-schmitt.de Tue Feb 3 16:01:24 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 03 Feb 2009 17:01:24 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <49886A54.6080709@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakub Jelinek schrieb: > Hi! > > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). > If may be helpful, if you can publish a list with packages which caused issues with the new compiler. So we may be able to fix the issue without the need to tryout all of our packages. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmIakIACgkQT2AHK6txfgwH6wCfXA0Srt7+eHltop4sN+CP6MlM /IAAn2l19R7JDVhSWMuABBuErIGRYmB4 =jjsg -----END PGP SIGNATURE----- From jwboyer at gmail.com Tue Feb 3 16:01:03 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 11:01:03 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090203160103.GB10541@yoda.jdub.homelinux.org> On Tue, Feb 03, 2009 at 04:48:36PM +0100, Jakub Jelinek wrote: >Hi! > >In the past few days I've done a mass rebuild of rawhide-20090126 >in mock with gcc-4.4.0-0.9 (and corresponding libtool). >6228 packages were successfully built, for the rest I've tried >to rebuild them also with gcc-4.3.2-7 (though I ran out of time, >so a couple of packages weren't attempted with 4.3). > >Here are the most common causes of the regressions (fails to build >with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7): This is awesome Jakub. Thanks for taking the time to do this and provide the results. It should help package maintainers greatly as we go forward. josh From bochecha at fedoraproject.org Tue Feb 3 16:07:02 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 3 Feb 2009 17:07:02 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <49886A54.6080709@herr-schmitt.de> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> Message-ID: <2d319b780902030807u7c955252h16198624e8e51e1e@mail.gmail.com> > If may be helpful, if you can publish a list with packages which caused > issues with the new compiler. So we may be able to fix the issue without > the need to tryout all of our packages. He did, just check each one of the links he provides ;) /me just checked that his packages weren't in the lists \o/ ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From jakub at redhat.com Tue Feb 3 16:21:20 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 17:21:20 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <49886A54.6080709@herr-schmitt.de> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> Message-ID: <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 05:01:24PM +0100, Jochen Schmitt wrote: > Jakub Jelinek schrieb: > > Hi! > > > > In the past few days I've done a mass rebuild of rawhide-20090126 > > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > > 6228 packages were successfully built, for the rest I've tried > > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > > so a couple of packages weren't attempted with 4.3). > > > If may be helpful, if you can publish a list with packages which caused > issues with the new compiler. So we may be able to fix the issue without > the need to tryout all of our packages. They were referenced in the links. Anyway, here is the list of all packages that didn't build successfully with 4.4, for details look at the provided links or try to build in dist-f11-gcc44 --scratch yourself (Karsten, could you please build libtool in dist-f11-gcc44, so that people actually can do that themselves? I only had a --scratch libtool build in my local repo). Also note, please don't start changing configure scripts yet, there are discussions about guarding this main calling pedantry back with -pedantic. All other bug categories aren't changing and so you can start fixing right now ;). 8Kingdoms-1.1.0-6.fc9.src.rpm adanaxisgpl-1.2.5-2.fc9.src.rpm adplay-1.6-4.fc9.src.rpm adplug-2.1-6.fc9.src.rpm allegro-4.2.2-11.fc11.src.rpm alliance-5.0-23.20070718snap.fc11.src.rpm alpine-2.00-3.fc11.src.rpm alsa-oss-1.0.17-1.fc10.src.rpm amanith-0.3-9.fc10.src.rpm amarok-2.0.1.1-2.fc11.src.rpm anaconda-11.5.0.11-1.src.rpm animorph-0.3-3.fc9.src.rpm antlr-2.7.7-3.fc11.src.rpm apmd-3.2.2-8.fc10.src.rpm apmud-1.0.0-9.fc9.src.rpm apr-1.3.3-1.fc10.src.rpm aqbanking-3.7.2-2.fc11.src.rpm aqsis-1.4.1-6.fc11.src.rpm ardour-2.7-1.fc11.src.rpm aria2-1.0.1-1.fc11.src.rpm athcool-0.3.12-2.fc9.src.rpm atlascpp-0.6.1-3.fc9.src.rpm autotrace-0.31.1-18.fc10.src.rpm avr-binutils-2.18-2.fc9.src.rpm ax25-apps-0.0.6-2.fc9.src.rpm axis-1.2.1-4.1.fc10.src.rpm azureus-3.0.4.2-18.fc10.src.rpm baekmuk-ttf-fonts-2.2-16.fc11.src.rpm ballbuster-1.0-5.fc9.src.rpm barry-0.15-0.3.20090109git.fc11.src.rpm bash-4.0-0.1.rc1.fc11.src.rpm beagle-0.3.8-16.fc11.src.rpm bes-3.6.2-2.fc11.src.rpm bitgtkmm-0.4.0-4.fc10.src.rpm blackbox-0.70.1-11.src.rpm bluez-gnome-1.8-12.fc11.src.rpm bmpx-0.40.14-8.fc11.src.rpm boinc-client-6.4.5-2.20081217svn.fc11.src.rpm boo-0.8.1.2865-4.fc9.src.rpm boolstuff-0.1.11-5.fc9.src.rpm boswars-2.5-1.fc9.src.rpm bzflag-2.0.12-4.fc11.src.rpm cairo-dock-2.0.0-0.3.svn1501_trunk.fc11.src.rpm cairo-java-1.0.5-10.fc10.src.rpm castor-0.9.5-3.fc10.src.rpm cdo-1.0.8-2.fc9.src.rpm cdrkit-1.1.8-1.fc10.src.rpm cegui-0.6.2-1.fc11.src.rpm cel-1.2-5.fc11.src.rpm celestia-1.5.0-1.fc9.src.rpm charis-fonts-4.104-4.fc11.src.rpm ClanLib06-0.6.5-13.fc10.src.rpm ClanLib-0.8.1-1.fc9.src.rpm classpathx-jaf-1.0-12.fc10.src.rpm clipper-2.1-3.fc11.src.rpm clisp-2.47-1.fc11.src.rpm cln-1.2.2-2.fc11.src.rpm clustermon-0.15.0-7.fc11.src.rpm cmucl-19e-0.3.pre2.fc10.src.rpm collectd-4.5.1-3.fc11.src.rpm compat-db-4.6.21-5.fc10.src.rpm compat-gcc-296-2.96-141.src.rpm compat-gcc-32-3.2.3-64.src.rpm compat-gcc-34-3.4.6-9.src.rpm compat-wxGTK26-2.6.4-4.src.rpm compiz-0.7.8-10.fc11.src.rpm conexus-0.5.98-1.fc11.src.rpm conexusmm-0.5.0-6.fc8.src.rpm coredumper-1.2.1-6.fc10.src.rpm coreutils-7.0-5.fc11.src.rpm corosync-0.92-5.svn1709.fc11.src.rpm cowbell-0.3-0.svn34.4.fc10.src.rpm cryptopp-5.5.2-3.fc10.src.rpm ctapi-cyberjack-3.3.0-4.fc11.src.rpm ctemplate-0.91-3.fc11.src.rpm cups-pk-helper-0.0.3-1.fc11.src.rpm cyphesis-0.5.18-1.fc11.src.rpm cyrus-sasl-2.1.22-20.fc11.src.rpm dbmail-2.2.9-2.fc10.src.rpm dbus-c++-0.5.0-0.3.20080716git1337c65.fc10.src.rpm dclib-0.3.11-5.fc11.src.rpm ddd-3.3.12-1.rc1.fc11.src.rpm devhelp-0.23-1.fc11.src.rpm DeviceKit-disks-002-0.git20080720.fc10.src.rpm DeviceKit-power-004-1.fc11.src.rpm dfu-util-0.1-0.4.20080922svn4662.fc11.src.rpm dia-0.96.1-10.fc11.src.rpm dietlibc-0.31-6.20081017.fc10.src.rpm digikam-0.10.0-0.14.rc1.fc11.src.rpm dnssec-tools-1.4.1-2.fc10.src.rpm dvgrab-3.2-1.fc10.src.rpm dx-4.4.4-7.fc10.src.rpm E-1.0.002-3.fc11.src.rpm ecl-0.9l-3.fc10.src.rpm ed2k_hash-0.4.0-7.fc9.src.rpm edb-0.9.6-2.fc11.src.rpm eel2-2.25.1-4.fc11.src.rpm eigen2-2.0-0.9.beta6.fc11.src.rpm ejabberd-2.0.2-4.fc11.src.rpm ekiga-3.1.0-10.fc11.src.rpm elilo-3.6-9.src.rpm ember-0.5.5-1.fc11.src.rpm enigma-1.01-7.1.src.rpm eris-1.3.13-2.fc9.src.rpm esc-1.0.1-12.fc11.src.rpm escape-200704130-10.fc11.src.rpm etherboot-5.4.4-7.fc11.src.rpm evolution-brutus-1.2.34-1.fc11.src.rpm evolution-remove-duplicates-0.0.4-1.fc10.src.rpm exempi-2.1.0-1.fc11.src.rpm exo-0.3.93-1.fc11.src.rpm expect-5.43.0-15.fc10.src.rpm Falcon-0.8.10-3.fc10.src.rpm farsight2-0.0.7-1.fc11.src.rpm fbreader-0.10.0-1.fc11.src.rpm fcgi-2.4.0-6.fc10.src.rpm festival-1.96-6.fc10.src.rpm file-browser-applet-0.6.0-1.fc11.src.rpm firewalk-5.0-2.fc9.src.rpm fityk-0.8.1-14.fc10.src.rpm fldigi-3.10-1.fc11.src.rpm flex-2.5.35-2.fc10.src.rpm FlightGear-1.9.0-1.fc11.src.rpm flite-1.3-10.fc10.src.rpm fmt-ptrn-1.3.17-2.fc10.src.rpm fpc-2.2.2-3.fc10.src.rpm freealut-1.1.0-6.fc9.src.rpm freefem++-3.0-2.3.fc11.src.rpm freetds-0.82-3.fc10.src.rpm frysk-0.4-4.fc11.src.rpm fusecompress-1.99.19-2.fc10.src.rpm fwbuilder-3.0.1-1.fc11.src.rpm g3data-1.5.1-8.fc9.src.rpm gai-0.5.10-16.fc11.src.rpm gambas-1.0.19-7.fc11.src.rpm gammu-1.22.1-2.fc11.src.rpm gcc-4.3.2-7.src.rpm gcl-2.6.8-0.1.20080902cvs.1.fc11.src.rpm gcombust-0.1.55-13.src.rpm gdal-1.6.0-1.fc11.src.rpm gdb-6.8.50.20081214-1.fc11.src.rpm gdbm-1.8.0-29.fc10.src.rpm gdl-0.9-0.rc1.4.fc11.1.src.rpm gedit-2.25.5-1.fc11.src.rpm geeqie-1.0-0.11.alpha2.1307svn.fc11.src.rpm geoclue-0.11.1-13.fc11.src.rpm geronimo-specs-1.0-2.M2.fc10.src.rpm gfan-0.3-3.fc11.src.rpm gflags-1.0-1.fc11.src.rpm ggz-gtk-client-0.0.14.1-1.fc9.src.rpm ghc-6.10.1-8.fc11.src.rpm ghc-gtk2hs-0.9.13-7.20081108.fc11.src.rpm gle-4.1.2-1.fc9.src.rpm glib-1.2.10-30.fc10.src.rpm glob2-0.9.3-2.fc11.src.rpm glog-0.2-2.fc11.src.rpm glunarclock-0.32.4-12.fc10.src.rpm gmp-4.2.4-4.fc11.src.rpm gnofract4d-3.9-2.fc11.src.rpm gnome-applet-vm-0.2.0-2.fc9.src.rpm gnome-chemistry-utils-0.10.2-1.fc11.src.rpm gnome-desktop-sharp-2.24.0-3.fc10.src.rpm gnome-disk-utility-0.1-0.git20080720.fc10.src.rpm gnome-do-0.6.1.0-2.fc10.src.rpm gnome-packagekit-0.4.2-1.fc11.src.rpm gnome-power-manager-2.25.2-1.fc11.src.rpm gnome-specimen-0.3-3.fc11.src.rpm gnome-speech-0.4.22-1.fc10.src.rpm gnome-themes-extras-2.22.0-2.fc9.src.rpm gnotime-2.3.0-2.fc11.src.rpm gnubiff-2.2.10-1.fc11.src.rpm gnumeric-1.8.2-5.fc11.src.rpm gnuradio-3.1.3-3.fc11.src.rpm gobby-0.4.6-1.fc10.src.rpm gpar2-0.3-6.fc9.src.rpm gpart-0.1h-9.fc9.src.rpm gpsim-0.22.0-7.fc10.src.rpm grass-6.3.0-9.fc11.src.rpm gstreamer-java-1.0-1.fc11.src.rpm gstreamer-plugins-good-0.10.11-5.fc11.src.rpm gthumb-2.10.10-3.fc10.src.rpm gtkimageview-1.6.1-2.fc10.src.rpm gtkmathview-0.8.0-1.fc10.src.rpm gtkspell-2.0.15-1.fc10.src.rpm gtkwave-3.2.0-0.1.RC4.fc11.src.rpm gvfs-1.1.4-1.fc11.src.rpm gwget-0.99-8.fc10.src.rpm gypsy-0.6-6.fc11.src.rpm haddock09-0.9-3.fc10.src.rpm happy-1.18.2-1.fc11.src.rpm hdf5-1.8.1-2.fc10.src.rpm hercules-3.05-7.20081009cvs.fc10.src.rpm highlight-2.7-1.fc11.src.rpm HippoDraw-1.21.1-7.fc11.src.rpm htmlparser-1.6-3.fc10.src.rpm hugin-0.7.0-3.fc11.src.rpm hydrogen-0.9.3-13.fc9.src.rpm i8kutils-1.25-15.src.rpm iasl-20061109-4.fc9.src.rpm ibmasm-3.0-15.fc10.src.rpm ibus-chewing-0.1.1.20081023-2.fc11.src.rpm ice-3.3.0-11.fc11.src.rpm icecream-0.8.0-11.20080117svn.fc9.src.rpm icu-4.0.1-1.fc11.src.rpm igraph-0.5.1-4.fc11.src.rpm ikarus-0.0.3-2.fc10.src.rpm iml-1.0.2-4.fc11.src.rpm imsettings-0.105.1-2.fc10.src.rpm incollector-1.0-6.fc9.1.src.rpm incron-0.5.7-1.fc9.src.rpm inetvis-0.9.3.1-1.fc10.src.rpm ini4j-0.3.2-4.fc10.src.rpm inkscape-0.46-10.fc11.src.rpm insight-6.8-4.fc11.src.rpm iprutils-2.2.13-1.fc11.src.rpm iptables-1.4.1.1-2.fc10.src.rpm iputils-20071127-6.fc10.src.rpm itpp-4.0.0-6.fc11.src.rpm iverilog-0.9.20081118-1.fc11.src.rpm ivtv-utils-1.3.0-1.fc11.src.rpm jabbin-2.0-0.7.beta2a.fc11.src.rpm jakarta-commons-el-1.0-9.4.fc10.src.rpm java-1.5.0-gcj-1.5.0.0-25.fc11.src.rpm javahelp2-2.0.05-5.fc10.src.rpm jline-0.9.94-0.2.fc10.src.rpm jmol-11.6-5.10137svn.fc11.src.rpm jrefactory-2.8.9-7.6.fc10.src.rpm jrtplib-3.7.1-4.fc9.src.rpm jsr-305-0-0.1.20080824svn.fc10.src.rpm jtidy-1.0-0.2.r7dev.1.3.fc10.src.rpm k3d-0.6.7.0-9.fc11.src.rpm kadu-0.6.5-8.fc11.src.rpm kaya-0.5.1-1.fc10.src.rpm kazehakase-0.5.6-2.fc11.src.rpm kdebase-workspace-4.2.0-1.fc11.src.rpm kdebluetooth-0.2-3.fc10.src.rpm kdeedu-4.2.0-2.fc11.src.rpm kdegames-4.2.0-1.fc11.src.rpm kdenetwork-4.2.0-1.fc11.src.rpm kdepim-4.2.0-1.fc11.src.rpm kdeplasma-addons-4.2.0-1.fc11.src.rpm kde-plasma-quickaccess-0.7.1-5.fc11.src.rpm kde-plasma-runcommand-0.9-1.fc11.src.rpm kdesdk-4.2.0-1.fc11.src.rpm kde-settings-4.1-5.20090116svn.fc11.src.rpm kdetv-0.8.9-10.fc9.src.rpm kdevelop-3.5.4-1.fc11.src.rpm kernel-2.6.29-0.48.rc2.git1.fc11.src.rpm khmeros-fonts-5.0-3.fc10.src.rpm kipi-plugins-0.2.0-0.13.rc1.fc11.src.rpm koffice-1.9.98.5-2.fc11.src.rpm konq-plugins-4.1.3-4.fc11.src.rpm kopete-bonjour-1.0.3-4.fc10.src.rpm kover-4-2.fc11.src.rpm kpackagekit-0.3.1-6.fc11.src.rpm krusader-2.0.0-0.3.beta2.fc11.src.rpm ktechlab-0.3.69-10.20081031svn.fc10.src.rpm ktorrent-3.1.5-1.fc10.src.rpm ladspa-1.12-9.fc9.src.rpm ladspa-swh-plugins-0.4.15-12.fc9.src.rpm lam-7.1.4-1.fc10.src.rpm lash-0.5.4-2.fc9.src.rpm lasi-1.1.0-2.fc10.src.rpm ldns-1.4.0-1.fc11.src.rpm libassa-3.5.0-3.src.rpm libbonoboui-2.24.0-1.fc10.src.rpm libchewing-0.3.2-3.fc11.src.rpm libcompizconfig-0.7.8-1.fc11.src.rpm libctl-3.0.2-6.fc9.src.rpm libdap-3.8.2-1.fc10.src.rpm libdv-1.0.0-5.fc10.src.rpm libfakekey-0.1-1.fc10.src.rpm libFoundation-1.1.3-11.fc9.src.rpm libfreebob-1.0.11-3.fc10.src.rpm libgconf-java-2.12.4-11.fc10.src.rpm libgii-1.0.2-6.fc9.src.rpm libglade-java-2.12.5-9.fc10.src.rpm libgnomedbmm-2.9.5-4.fc9.src.rpm libgnome-java-2.12.4-9.fc10.src.rpm libgnomekbd-2.24.0-1.fc10.src.rpm libgtk-java-2.8.7-8.fc10.src.rpm libibcommon-1.1.0-1.fc10.src.rpm libibmad-1.2.0-1.fc10.src.rpm libibumad-1.2.0-1.fc10.src.rpm libjingle-0.3.12-2.fc11.src.rpm libjpeg-6b-43.fc10.src.rpm libmusicbrainz3-3.0.2-2.fc11.src.rpm libnids-1.23-1.fc11.src.rpm libofa-0.9.3-13.fc9.src.rpm libopenraw-0.0.5-1.fc9.src.rpm libopensync-plugin-kdepim-0.36-1.fc10.src.rpm libopensync-plugin-syncml-0.35-4.fc10.src.rpm libpanelappletmm-2.22.0-1.fc9.src.rpm libpaper-1.1.23-3.fc10.src.rpm libpar2-0.2-7.fc11.src.rpm libpciaccess-0.10.3-3.fc10.src.rpm libpolyxmass-0.9.1-2.fc9.src.rpm libpqxx-2.6.8-10.fc9.src.rpm libpri-1.4.7-1.fc10.src.rpm libprojectM-1.2.0-7.fc11.src.rpm libresample-0.1.3-9.fc10.src.rpm librtas-1.3.3-3.fc9.src.rpm librx-1.5-10.fc9.src.rpm libsmbios-2.2.8-1.fc11.src.rpm libsndfile-1.0.17-6.fc10.src.rpm libspe2-2.3.0.135-3.fc11.src.rpm libsynaptics-0.14.6c-5.fc10.src.rpm libtar-1.2.11-11.fc10.src.rpm libthai-0.1.9-4.fc9.src.rpm libtorrent-0.12.4-2.fc11.src.rpm libvirt-cim-0.5.3-1.fc11.src.rpm libvte-java-0.12.1-12.fc10.src.rpm libwfut-0.2.1-3.fc11.src.rpm libwvstreams-4.5.1-3.fc11.src.rpm libxfce4menu-4.5.93-1.fc11.src.rpm libxfcegui4-4.5.93-1.fc11.src.rpm libXfontcache-1.0.4-5.fc9.src.rpm libXp-1.0.0-11.fc9.src.rpm libXTrap-1.0.0-6.fc10.src.rpm libzzub-0.2.3-14.fc11.src.rpm lightning-1.2c-1.fc10.src.rpm linkage-0.2.0-4.fc11.src.rpm linphone-2.1.1-1.fc9.src.rpm linpsk-0.9-4.fc10.src.rpm linux-atm-2.5.0-5.src.rpm listen-0.5-21.fc11.src.rpm llvm-2.4-2.fc11.src.rpm log4cxx-0.10.0-5.fc11.src.rpm logjam-4.5.3-25.fc10.src.rpm lordsawar-0.1.4-2.fc11.src.rpm lrmi-0.10-5.fc10.src.rpm lsvpd-1.6.4-3.fc10.src.rpm ltsp-utils-0.25-4.fc6.src.rpm lyx-1.6.1-1.fc11.src.rpm lzip-1.1-2.fc11.src.rpm lzop-1.02-0.6.rc1.fc9.src.rpm m17n-lib-1.5.3-1.fc10.src.rpm maildrop-2.0.4-6.fc9.src.rpm manaworld-0.0.27-1.fc11.src.rpm mapnik-0.5.2-0.10.svn780.fc11.src.rpm mapserver-5.2.1-4.fc11.src.rpm maven2-2.0.4-10.15.fc10.src.rpm maven-scm-1.0-0.2.b3.1.6.fc10.src.rpm maven-shared-1.0-4.6.fc10.src.rpm maxima-5.17.1-3.fc11.src.rpm mediatomb-0.11.0-4.fc11.src.rpm midori-0.1.1-1.fc11.src.rpm mingw32-filesystem-43-6.fc11.src.rpm Miro-1.2.8-5.fc11.src.rpm mm3d-1.3.7-2.fc10.src.rpm mnemosyne-1.1.1-3.r1.fc11.src.rpm mod_dnssd-0.5-7.fc10.src.rpm modello-1.0-0.1.a8.4.4.fc10.src.rpm moe-1.0-2.fc10.src.rpm monafont-2.90-5.fc11.2.src.rpm monodoc-2.0-5.fc10.src.rpm monotone-0.42-2.fc11.src.rpm msv-1.2-0.2.20050722.3.4.fc10.src.rpm multiget-1.2.0-3.fc10.src.rpm museek+-0.2-0.1.20090110svn1063.fc11.src.rpm mysql++-3.0.8-2.fc11.src.rpm mysql-5.1.30-2.fc11.src.rpm nautilus-image-converter-0.3.0-1.fc9.src.rpm nautilus-share-0.7.2-13.fc10.src.rpm nc-1.84-16.fc9.src.rpm nco-3.9.5-3.fc11.src.rpm nemiver-0.6.4-1.fc11.src.rpm netatalk-2.0.3-23.fc11.src.rpm nethogs-0.7-4.20080627cvs.fc10.src.rpm netpbm-10.35.58-3.fc11.src.rpm net-tools-1.60-91.fc10.src.rpm NetworkManager-0.7.0-1.git20090102.fc11.src.rpm neverball-1.4.0-14.fc11.src.rpm nfs4-acl-tools-0.3.2-2.fc9.src.rpm nightview-0.3.2-1.fc11.src.rpm nomarch-1.4-4.fc10.src.rpm nqc-3.1.6-2.fc9.src.rpm nss_ldap-261-4.fc10.src.rpm nted-1.4.17-2.fc11.src.rpm ntl-5.4.2-4.fc11.src.rpm nut-2.2.2-6.fc11.src.rpm nyquist-3.01-1.fc10.src.rpm ocaml-lablgtk-2.10.1-7.fc11.src.rpm ocaml-omake-0.9.8.5-4.fc11.src.rpm ochusha-0.6.0.1-0.2.cvs20090106T1430.fc11.1.src.rpm octave-3.0.3-1.fc11.src.rpm ohm-0.1.1-7.22.20080921git.fc11.src.rpm olpcsound-5.08.92-15.fc11.src.rpm oorexx-3.2.0-4.fc9.src.rpm opal-3.5.2-4.fc11.src.rpm openais-0.91-4.svn1667.fc11.src.rpm openal-0.0.9-0.15.20060204cvs.fc9.src.rpm openbabel-2.2.0-2.fc11.src.rpm opencv-1.0.0-12.fc11.src.rpm OpenEXR_CTL-1.0.1-4.fc9.src.rpm OpenEXR_Viewers-1.0.1-2.fc10.src.rpm openhpi-2.13.1-3.fc11.src.rpm openjade-1.3.2-31.fc9.src.rpm openjpeg-1.3-2.fc9.src.rpm openldap-2.4.12-3.fc11.src.rpm openmsx-0.6.3-5.fc11.src.rpm openoffice.org-3.0.1-15.5.fc11.src.rpm openoffice.org-voikko-3.0.1-1.fc11.src.rpm OpenSceneGraph-2.6.0-1.fc10.src.rpm opensm-3.2.1-1.fc10.src.rpm openssl-0.9.8j-5.fc11.src.rpm openswan-2.6.19-1.fc11.src.rpm openvrml-0.17.10-2.0.fc11.src.rpm orage-4.5.93-1.fc11.src.rpm orpie-1.5.1-4.fc10.src.rpm orsa-0.7.0-2.fc10.src.rpm PackageKit-0.4.2-1.fc11.src.rpm pam_keyring-0.0.9-2.fc9.src.rpm pam_mount-1.4-2.fc11.src.rpm pan-0.133-1.fc10.src.rpm papyrus-0.8.1-1.fc11.src.rpm parted-1.8.8-12.fc11.src.rpm pcmanx-gtk2-0.3.8-3.fc11.src.rpm pdns-2.9.22-2.rc3.fc11.src.rpm pdns-recursor-3.1.7-2.fc10.src.rpm pekwm-0.1.5-8.fc10.src.rpm PerceptualDiff-1.0.2-3.fc10.src.rpm perl-bioperl-1.5.9-0.5.4.fc11.src.rpm perl-Class-Autouse-1.29-3.fc9.src.rpm perl-Class-Inspector-1.23-1.fc10.src.rpm perl-Convert-Binary-C-0.71-1.fc10.src.rpm perl-File-Find-Rule-Perl-1.04-2.fc10.src.rpm perl-HTTP-Proxy-0.20-2.fc9.src.rpm perl-IPC-Shareable-0.60-6.fc9.src.rpm perl-POE-Component-SNMP-1.07-3.fc9.src.rpm perl-RRD-Simple-1.43-3.fc9.src.rpm perl-Sys-Virt-0.1.2-3.fc9.src.rpm perl-TermReadKey-2.30-6.fc9.src.rpm perl-Test-AutoBuild-1.2.2-6.fc10.src.rpm perl-Test-Inline-2.208-3.fc10.src.rpm perl-Test-WWW-Mechanize-Catalyst-0.42-1.fc10.src.rpm perl-WWW-Search-2.504-1.fc10.src.rpm perl-XML-LibXSLT-1.68-1.fc11.src.rpm pfstools-1.7.0-2.fc11.src.rpm php-5.2.8-3.fc11.src.rpm pidgin-2.5.4-1.fc11.src.rpm pingus-0.7.2-4.fc11.src.rpm pinot-0.89-4.fc11.src.rpm player-2.1.1-9.fc11.src.rpm plexus-appserver-1.0-0.2.a5.2.6.fc10.src.rpm plexus-cdc-1.0-0.2.a4.1.6.fc10.src.rpm plexus-i18n-1.0-0.b6.5.3.fc10.src.rpm plexus-maven-plugin-1.2-2.4.fc10.src.rpm plexus-runtime-builder-1.0-0.2.a9.1.6.fc10.src.rpm plexus-xmlrpc-1.0-0.2.b4.2.11.fc10.src.rpm plplot-5.9.0-4.svn8985.fc11.src.rpm poker3d-1.1.36-13.fc11.src.rpm PolicyKit-kde-0.0-0.1.20081219svn.fc11.src.rpm polyxmass-bin-0.9.7-2.fc8.src.rpm popt-1.13-4.fc10.src.rpm portreserve-0.0.3-2.fc10.src.rpm powerpc-utils-1.0.6-3.fc9.src.rpm powerpc-utils-papr-1.0.4-3.fc9.src.rpm ppc64-utils-0.14-3.fc10.src.rpm prctl-1.5-2.src.rpm prelink-0.4.0-3.src.rpm procbench-0.8.2a-2.fc10.src.rpm protobuf-2.0.2-6.fc11.src.rpm ps3pf-utils-2.1-2.fc9.src.rpm pstoedit-3.45-4.fc10.src.rpm PyAmanith-0.3.35-5.fc11.src.rpm python-bibtex-1.2.4-5.fc11.src.rpm python-gammu-0.28-1.fc11.src.rpm python-ldap-2.3.5-3.fc11.src.rpm python-lxml-2.2-0.4.beta1.fc11.src.rpm python-peak-rules-0.5a1.dev-4.2582.fc11.src.rpm python-psyco-1.6-1.fc11.src.rpm python-reportlab-2.1-4.fc11.src.rpm python-virtinst-0.400.0-7.fc11.src.rpm PyYAML-3.06-2.fc11.src.rpm q-7.11-2.fc10.src.rpm qca-ossl-2.0.0-0.4.beta3.fc10.src.rpm qgis-1.0.0-1.fc11.src.rpm qgo-1.5.4r2-1.fc9.src.rpm qjackctl-0.3.3-1.fc10.src.rpm ql2400-firmware-4.04.05-1.fc11.src.rpm qlandkartegt-0.9.3-1.fc11.src.rpm qof-0.7.5-3.fc10.src.rpm qpidc-0.4.734452-3.fc11.src.rpm qps-1.10.2-1.fc10.src.rpm qsynth-0.3.3-1.fc10.src.rpm qt-4.4.3-12.fc11.src.rpm qtoctave-0.8.1-0.20080823.svn165.fc10.src.rpm quake3-1.34-0.9.rc4.fc9.src.rpm quesa-1.8-1.fc9.src.rpm quickfix-1.12.4-6.fc11.src.rpm qwtplot3d-0.2.7-6.fc9.src.rpm rb_libtorrent-0.14.1-2.fc11.src.rpm R-BSgenome.Celegans.UCSC.ce2-1.2.0-5.src.rpm R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3.src.rpm rcsslogplayer-13.1.0-2.fc11.src.rpm rcssserver-13.1.0-1.fc11.src.rpm rcssserver3d-0.6-7.fc11.src.rpm redhat-lsb-3.2-2.fc10.src.rpm redhat-menus-10.0.1-1.fc11.src.rpm referencer-1.1.5-4.fc11.src.rpm revelation-0.4.11-7.src.rpm R-hgu95av2probe-2.0.0-1.fc9.src.rpm rhm-0.4.3045-1.fc11.src.rpm ricci-0.15.0-9.fc11.src.rpm R-lmtest-0.9-2.fc10.src.rpm rosegarden4-1.6.1-2.fc9.src.rpm R-pls-2.1-2.fc9.src.rpm rtorrent-0.8.3-1.fc11.src.rpm rubberband-1.2-2.fc11.src.rpm ruby-1.8.6.287-2.fc10.src.rpm ruby-rpm-1.2.3-4.fc9.src.rpm rudeconfig-5.0.5-4.fc10.src.rpm rxtx-2.1-0.2.7r2.fc11.src.rpm rxvt-unicode-9.06-1.fc11.src.rpm s3switch-0.0-11.20020912.fc10.src.rpm sagator-1.1.1-0.beta1.fc10.src.rpm samyak-fonts-1.2.1-2.fc11.src.rpm sane-backends-1.0.19-12.fc10.src.rpm sazanami-fonts-0.20040629-5.20061016.fc11.src.rpm scim-1.4.7-35.fc10.src.rpm scim-anthy-1.2.6-2.fc11.src.rpm scim-bridge-0.4.15-8.fc11.src.rpm scponly-4.8-1.fc10.src.rpm scrip-1.4-9.fc8.src.rpm seamonkey-1.1.14-2.fc11.src.rpm sear-0.6.3-11.fc10.src.rpm selinux-policy-3.6.3-8.fc11.src.rpm sepostgresql-8.3.5-2.1183.fc10.src.rpm seq24-0.8.7-13.fc10.src.rpm sigen-0.0.2-0.25.20081206git529cd0e.fc11.src.rpm SimGear-1.9.0-1.fc11.src.rpm skstream-0.3.6-3.fc9.src.rpm slim-1.3.1-2.fc10.src.rpm smarteiffel-2.3-2.fc9.src.rpm sonic-visualiser-1.4-2.fc11.src.rpm source-highlight-2.10-2.fc11.src.rpm speedcrunch-0.9-3.fc9.src.rpm spicctrl-1.9-7.fc10.src.rpm spicebird-0.7-2.fc11.src.rpm spr-07.15.00-1.fc9.src.rpm Sprog-0.14-13.fc9.src.rpm squashfs-tools-4.0-0.20090112.src.rpm squid-3.0.STABLE10-4.fc11.src.rpm srecord-1.46-1.fc11.src.rpm srm-1.2.9-2.fc11.src.rpm stapitrace-1.0.0-22.20080622cvs_alpha.fc11.src.rpm star-1.5a89-1.fc11.src.rpm stardict-3.0.1-15.fc11.src.rpm starlab-4.4.3-3.fc10.src.rpm stk-4.3.1-7.fc11.src.rpm stormbaancoureur-2.1.5-1.fc10.src.rpm stratagus-2.2.4-5.fc11.src.rpm strigi-0.6.3-1.fc11.src.rpm subcommander-1.9.94-3.fc10.src.rpm subtitleeditor-0.30.0-3.fc10.src.rpm sudo-1.6.9p17-2.fc10.src.rpm sugar-0.83.5-1.fc11.src.rpm sunbird-0.9-4.fc11.src.rpm supertux-0.3.1-4.fc11.src.rpm supertuxkart-0.6-1.fc11.src.rpm supybot-fedora-0.2.2-1.fc11.src.rpm svxlink-080730-6.fc11.src.rpm sword-1.5.11-2.fc10.src.rpm synaptics-0.14.6-11.fc10.src.rpm synce-software-manager-0.9.0-10.fc9.src.rpm synopsis-0.11-1.fc11.src.rpm taglib-sharp-2.0.3.0-7.fc11.src.rpm teckit-2.5.1-1.fc10.src.rpm tesseract-2.03-1.fc10.src.rpm texlive-2007-39.fc11.src.rpm TeXmacs-1.0.7-1.fc10.src.rpm thibault-fonts-0.1-3.fc11.src.rpm Thunar-0.9.93-1.fc11.src.rpm thunderbird-2.0.0.18-2.fc11.src.rpm tiger-3.2.1-8.fc9.src.rpm tightvnc-1.5.0-0.9.20081120svn3200.fc11.src.rpm tinyerp-4.2.3.4-3.fc11.src.rpm tiresias-fonts-1.0-3.fc11.src.rpm tklib-0.4.1-7.fc9.src.rpm tmispell-voikko-0.7-1.fc10.src.rpm tog-pegasus-2.7.2-3.fc11.src.rpm torcs-1.3.0-7.fc10.src.rpm totem-2.25.3-8.fc11.src.rpm trousers-0.3.1-13.fc11.src.rpm ttmkfdir-3.0.9-28.fc11.src.rpm twinkle-1.4-1.fc11.src.rpm ufraw-0.14.1-4.fc11.src.rpm uim-1.5.3-1.fc10.src.rpm unikurd-web-font-20020502-1.fc11.src.rpm unixODBC-2.2.12-9.fc10.src.rpm vala-0.5.3-1.fc11.src.rpm valknut-0.3.11-5.fc11.src.rpm vamp-plugin-sdk-2.0-2.fc11.src.rpm vdccm-0.10.1-3.fc9.src.rpm velocity-1.4-7.3.fc10.src.rpm vim-7.2.079-2.fc11.src.rpm virt-manager-0.6.0-7.fc11.src.rpm wammu-0.29-3.fc11.src.rpm WebKit-1.0.0-0.16.svn39370.fc11.src.rpm widelands-0-0.13.Build13.fc11.src.rpm wine-1.1.12-1.fc11.src.rpm wormux-0.8.2-3.fc11.src.rpm ws-commons-util-1.0.1-10.fc10.src.rpm xapian-core-1.0.9-2.fc11.src.rpm xastir-1.9.5-2.fc11.src.rpm xca-0.6.4-5.fc11.src.rpm xchat-gnome-0.24.1-3.fc11.src.rpm xdoclet-1.2.3-9.4.fc10.src.rpm xdotool-20071230-2.fc10.src.rpm xfce4-appfinder-4.5.93-1.fc11.src.rpm xfce4-gsynaptics-mcs-plugin-1.0.0-1.fc9.src.rpm xfce4-panel-4.5.93-1.fc11.src.rpm xfce4-session-4.5.93-1.fc11.src.rpm xfce4-settings-4.5.93-2.fc11.src.rpm xfce-mcs-manager-4.4.3-1.fc10.src.rpm xfce-mcs-plugin-gsynaptics-1.0.0-2.fc10.src.rpm xfce-mcs-plugins-4.4.2-4.fc9.src.rpm xfce-mcs-plugins-extra-2.0-2.fc10.src.rpm xfce-utils-4.5.93-1.fc11.src.rpm xfconf-4.5.93-3.fc11.src.rpm xfdesktop-4.5.93-1.fc11.src.rpm xfprint-4.5.93-1.fc11.src.rpm xfwm4-4.5.93-1.fc11.src.rpm xine-lib-1.1.16.1-1.fc11.src.rpm xkeyboard-config-1.4-8.fc11.src.rpm xlhtml-0.5-8.fc9.src.rpm xmlcopyeditor-1.1.0.6-4.fc9.src.rpm xmlrpc3-3.0-2.9.fc10.src.rpm xmms-cdread-0.14-13.fc9.src.rpm xmoto-0.5.0-4.fc11.src.rpm xorg-x11-drv-acecad-1.2.2-1.fc9.src.rpm xorg-x11-drv-aiptek-1.1.1-1.fc9.src.rpm xorg-x11-drv-ark-0.7.0-1.fc9.src.rpm xorg-x11-drv-calcomp-1.1.2-1.fc9.src.rpm xorg-x11-drv-citron-2.2.1-1.fc9.src.rpm xorg-x11-drv-diamondtouch-0.2.0-0.1.fc9.src.rpm xorg-x11-drv-digitaledge-1.1.1-1.fc9.src.rpm xorg-x11-drv-dmc-1.1.2-1.fc9.src.rpm xorg-x11-drv-dummy-0.3.0-1.fc9.src.rpm xorg-x11-drv-dynapro-1.1.2-1.fc9.src.rpm xorg-x11-drv-fpit-1.2.0-1.fc9.src.rpm xorg-x11-drv-geode-2.11.0-2.fc11.src.rpm xorg-x11-drv-hyperpen-1.2.0-1.fc9.src.rpm xorg-x11-drv-jamstudio-1.2.0-1.fc9.src.rpm xorg-x11-drv-magellan-1.2.0-1.fc9.src.rpm xorg-x11-drv-microtouch-1.2.0-1.fc9.src.rpm xorg-x11-drv-neomagic-1.2.2-1.fc11.src.rpm xorg-x11-drv-nouveau-0.0.11-1.20081119git65b956f.fc10.src.rpm xorg-x11-drv-palmax-1.2.0-1.fc9.src.rpm xorg-x11-drv-penmount-1.3.0-1.fc9.src.rpm xorg-x11-drv-rendition-4.2.0-1.fc9.src.rpm xorg-x11-drv-s3-0.6.1-1.fc11.src.rpm xorg-x11-drv-siliconmotion-1.6.0-1.fc9.src.rpm xorg-x11-drv-sisusb-0.9.0-1.fc9.src.rpm xorg-x11-drv-spaceorb-1.1.0-6.fc9.src.rpm xorg-x11-drv-summa-1.2.0-2.fc10.src.rpm xorg-x11-drv-tek4957-1.2.0-1.fc9.src.rpm xorg-x11-drv-ur98-1.1.0-5.fc9.src.rpm xorg-x11-drv-void-1.1.1-9.fc9.src.rpm xorg-x11-drv-voodoo-1.2.0-1.fc9.src.rpm xorg-x11-drv-wiimote-0.0.1-1.fc9.src.rpm xorg-x11-server-1.5.99.901-1.fc11.src.rpm xplanet-1.2.0-4.fc11.src.rpm xqilla10-1.0.2-5.fc9.src.rpm xqilla-2.1.3-0.4.fc11.src.rpm xscorch-0.2.0-12.fc8.src.rpm xsettings-kde-0.9-1.fc11.src.rpm xu4-1.1-0.4.cvs20070510.fc9.src.rpm xulrunner-1.9.1-0.6.beta2.fc11.src.rpm yaboot-1.3.14-9.fc11.src.rpm yadex-1.7.0-10.fc9.src.rpm yasm-0.7.2-1.fc11.src.rpm ypbind-1.20.4-12.fc11.src.rpm yum-3.2.21-3.fc11.src.rpm zhcon-0.2.6-12.fc11.src.rpm zsh-4.3.4-8.fc9.src.rpm Jakub From bnocera at redhat.com Tue Feb 3 16:24:58 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 03 Feb 2009 16:24:58 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> Message-ID: <1233678298.3486.2596.camel@cookie.hadess.net> On Mon, 2009-02-02 at 17:31 -0800, Dan Nicholson wrote: > That's exactly my point. Since ESD support has been removed in fedora, > anyone trying to do gnome_sound_connection_get() will just get -1 back > anyway. Furthermore, the gnome_sound_play() docs say that the sound > may or may not play. So, why not just make it play a file with > libcanberra? If it fails, oh well. You're in exactly the same > situation you're in now. It seems pretty easy to me: > > void gnome_sound_play(const char *filename) > { > #ifdef HAVE_LIBCANBERRA_GTK > ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME, > filename, NULL); > #endif > } It's easy but broken because it's missing all the other properties that libcanberra can use and give to other applications. For example, we don't know whether it's a sound event (click/pop/whatever), or a help to pronunciation in a dictionary. > I understand not wanting to write new apps to use gnome_sound_play > since it's deprecated. But it's existing API that can't be removed. > Why not have it work for apps that haven't been ported yet Because it's hardly more work to fix the applications themselves. > (or can't > be ported)? Those were always in trouble. > > I'd rather spend time answering questions on how to make libcanberra > > work with your app rather than spending time doing a half-working > > work-around in libgnome. > > Sure. I would not suggest that new apps use gnome_sound*. And I don't see how adding a broken work-around to gnome_sound_* would help us fix the applications properly. Cheers From bnocera at redhat.com Tue Feb 3 16:27:00 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 03 Feb 2009 16:27:00 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: <3528361a0902021854j2f3c0e9bof4d01163be84e944@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <3528361a0902021854j2f3c0e9bof4d01163be84e944@mail.gmail.com> Message-ID: <1233678420.3486.2600.camel@cookie.hadess.net> On Tue, 2009-02-03 at 10:54 +0800, ??? wrote: > The problem here is we disable the esd supporting when build > libgnome. But if we enable it, gnome_sound_play() works just fine. > ( I have tested this.) So I think although we have removed esd from > Fedora 10, but we shouldn't disable esd supporting in libgnome. Right? The application you're talking about is broken in the first place for assuming that gnome_sound_play() would always be working. File an upstream bug (or one in the Fedora bugzilla) against the application at hand, and it will be fixed. Cheers From skvidal at fedoraproject.org Tue Feb 3 16:35:23 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Feb 2009 11:35:23 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <1233678923.3238.3.camel@rosebud> On Tue, 2009-02-03 at 17:21 +0100, Jakub Jelinek wrote: > On Tue, Feb 03, 2009 at 05:01:24PM +0100, Jochen Schmitt wrote: > > Jakub Jelinek schrieb: > > > Hi! > > > > > > In the past few days I've done a mass rebuild of rawhide-20090126 > > > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > > > 6228 packages were successfully built, for the rest I've tried > > > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > > > so a couple of packages weren't attempted with 4.3). > > > > > If may be helpful, if you can publish a list with packages which caused > > issues with the new compiler. So we may be able to fix the issue without > > the need to tryout all of our packages. > > They were referenced in the links. > Anyway, here is the list of all packages that didn't build successfully > with 4.4, for details look at the provided links or try to build in > dist-f11-gcc44 --scratch yourself (Karsten, could you please build libtool > in dist-f11-gcc44, so that people actually can do that themselves? > I only had a --scratch libtool build in my local repo). I'm confused - you have yum mentioned in this list but it's not in any of the directories you linked to before. > yum-3.2.21-3.fc11.src.rpm is it missing its results? -sv From bpepple at fedoraproject.org Tue Feb 3 16:46:05 2009 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 03 Feb 2009 11:46:05 -0500 Subject: Package Review Stats for the week ending February 1st, 2009 Message-ID: <1233679565.9894.3.camel@localhost.localdomain> Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for the week ending February 1st, 2009 were Parag AN(????), Manuel Wolfshant, and Jochen Schmitt. Below is the number of package reviews completed. Parag AN(????) - 15 manuel wolfshant - 10 Jochen Schmitt - 6 Mamoru Tasaka - 6 Nicolas Mailhot - 5 Orcan 'oget' Ogetbil - 5 Lucian Langa - 4 Sarantis Paskalis - 3 Marcela Maslanova - 2 Mary Ellen Foster - 2 Peter Robinson - 2 Steven M. Parrish - 2 Tim Lauridsen - 2 Adam Tkac - 1 Debarshi Ray - 1 Denis Leroy - 1 Dennis Gilmore - 1 Erik van Pienbroek - 1 Itamar Reis Peixoto - 1 Jerry James - 1 Jos? Matos - 1 Kevin Fenzi - 1 Lubomir Rintel - 1 Matej Cepl - 1 Milos Jakubicek - 1 Ralf Corsepius - 1 Robert Scheck - 1 Tom "spot" Callaway - 1 Review Requests: 69 Merge Reviews: 5 Total reviews modified: 79 Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gmaxwell at gmail.com Tue Feb 3 16:44:32 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 3 Feb 2009 11:44:32 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <20090203133223.GB5846@mokona.greysector.net> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <20090203133223.GB5846@mokona.greysector.net> Message-ID: On Tue, Feb 3, 2009 at 8:32 AM, Dominik 'Rathann' Mierzejewski wrote: >> Do you have benchmarks that show given a constant -mtune that >> -march=i686 makes a material difference for any significant userspace >> apps vs -march=i586, if not why are you being so insistent and >> damning of the current compatible behavior? > > Which applications do you suggest for testing this hypothesis? Most easily measured things (rsvg rendering, freetype) probably aren't ever performance critical for typical users. I think the codec idea is good both on the 'likely to benefit from cmov' perspective as well as 'performance actually matters' perspective, but it ought to be things the Fedora ships. Although, for video the video driver (and hardware YUV->RGB) is probably more important than codec speed. Ideally the test ought to be done on something modern that can't do x86_64 (low end atom perhaps), since if you're on x86_64 you ought to be using the x86_64 distro or suffering whatever performance you don't get... but I don't have anything x86 handy. So, libtheora decoding HD video. libTheora-i586 5.872 libTheora-i686 5.86 libTheora-x86_64 5.643 libTheora-i586(no asm) 9.396 libTheora-i686(no asm) 9.142 libTheora-x86_64(no asm) 8.04 So, we learn? If you want performance for codecs use hand coded assembly or at least x86_64. :) For the with assembly version the improvement is 0.2%, without asm, 2.7%. I'm a bit disappointed: This hasn't shown a real world improvement (0.2% isn't helpful), but it suggests that one might be possible for some other application. Can someone suggest something else which is performance relevant for many users? ---Method disclosure--- Video is http://community.elphel.com/videos/1920x1072_24FPS.ogg [gmaxwell at sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i586 -mtune=core2' ./configure --target=i586 ; make clean ; make -j5 [gmaxwell at sonolumen examples]$ (for i in `seq 1 10` ; do (time -p ./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ; done ) | awk '{sum+=$2} END { print sum/NR}' 5.872 [gmaxwell at sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i686 -mtune=core2' ./configure --target=i686 ; make clean ; make -j5 [gmaxwell at sonolumen examples]$ (for i in `seq 1 10` ; do (time -p ./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ; done ) | awk '{sum+=$2} END { print sum/NR}' 5.86 [gmaxwell at sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i686 -mtune=core2' ./configure --disable-asm ; make clean ; make -j5 [gmaxwell at sonolumen examples]$ (for i in `seq 1 10` ; do (time -p ./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ; done ) | awk '{sum+=$2} END { print sum/NR}' 9.142 [gmaxwell at sonolumen libtheora-1.0]$ CFLAGS='-m32 -march=i586 -mtune=core2' ./configure --disable-asm ; make clean ; make -j5 [gmaxwell at sonolumen examples]$ (for i in seq 1 10 ; do (time -p ./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ; done ) | awk '{sum+=$2} END { print sum/NR}' 9.396 [gmaxwell at sonolumen libtheora-1.0]$ CFLAGS='-mtune=core2' ./configure --disable-asm ; make clean ; make -j5 [gmaxwell at sonolumen examples]$ (for i in `seq 1 10` ; do (time -p ./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ; done ) | awk '{sum+=$2} END { print sum/NR}' 8.04 [gmaxwell at sonolumen libtheora-1.0]$ CFLAGS='-mtune=core2' ./configure ; make clean ; make -j5 [gmaxwell at sonolumen examples]$ (for i in `seq 1 10` ; do (time -p ./dump_video < 1920x1072_24FPS.ogg > /dev/null) 2>&1 | grep 'user' ; done ) | awk '{sum+=$2} END { print sum/NR}' 5.643 From Fedora at FamilleCollet.com Tue Feb 3 16:49:27 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 03 Feb 2009 17:49:27 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <49887597.9070106@FamilleCollet.com> Jakub Jelinek a ?crit : > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). Hi, First, thanks a lot for this hard work. I'm trying to fix mysql++. After adding a few headers (cstdio), it fails on a strange error (i386 only I think, x86_64 succeed and ppc was canceled before end) test_array_index_array_index.o: In function `__exchange_and_add': /usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/ext/atomicity.h:51: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i386-redhat-linux/ 4.4.0/../../../../include/c++/4.4.0/ext/atomicity.h:51: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/ext/atomicity.h:51: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/ext/atomicity.h:51: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/ext/atomicity.h:51: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status Full log : http://koji.fedoraproject.org/koji/taskinfo?taskID=1101825 http://koji.fedoraproject.org/koji/getfile?taskID=1101832&name=build.log It seems (googling) it's a issue with -march=i386 Any idea for this issue ? Remi From jakub at redhat.com Tue Feb 3 16:49:49 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 17:49:49 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <1233678923.3238.3.camel@rosebud> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> <1233678923.3238.3.camel@rosebud> Message-ID: <20090203164949.GV5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 11:35:23AM -0500, seth vidal wrote: > > They were referenced in the links. > > Anyway, here is the list of all packages that didn't build successfully > > with 4.4, for details look at the provided links or try to build in > > dist-f11-gcc44 --scratch yourself (Karsten, could you please build libtool > > in dist-f11-gcc44, so that people actually can do that themselves? > > I only had a --scratch libtool build in my local repo). > > I'm confused - you have yum mentioned in this list but it's not in any > of the directories you linked to before. Ah, right, forgot about those, there are also 117 failures because a newer package has been built in rawhide since 20090126 and so wget used in the script failed to grab it during the mass rebuild. So, those packages weren't attempted to be rebuilt at all, they might pass, or might fail. Sorry. Jakub From skvidal at fedoraproject.org Tue Feb 3 16:50:49 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Feb 2009 11:50:49 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203164949.GV5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> <1233678923.3238.3.camel@rosebud> <20090203164949.GV5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <1233679849.3238.4.camel@rosebud> On Tue, 2009-02-03 at 17:49 +0100, Jakub Jelinek wrote: > On Tue, Feb 03, 2009 at 11:35:23AM -0500, seth vidal wrote: > > > They were referenced in the links. > > > Anyway, here is the list of all packages that didn't build successfully > > > with 4.4, for details look at the provided links or try to build in > > > dist-f11-gcc44 --scratch yourself (Karsten, could you please build libtool > > > in dist-f11-gcc44, so that people actually can do that themselves? > > > I only had a --scratch libtool build in my local repo). > > > > I'm confused - you have yum mentioned in this list but it's not in any > > of the directories you linked to before. > > Ah, right, forgot about those, there are also 117 failures because a newer > package has been built in rawhide since 20090126 and so wget used in the > script failed to grab it during the mass rebuild. So, those packages > weren't attempted to be rebuilt at all, they might pass, or might fail. > > Sorry. Not a problem. I was mainly confused b/c yum isn't compiled, at all, so the gcc changes had me fairly well boggled as to how they impact yum. :) Thanks for the explanation and thanks for the report in general, it's great. -sv From mschwendt at gmail.com Tue Feb 3 16:56:57 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 3 Feb 2009 17:56:57 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090203175657.6affd459.mschwendt@gmail.com> On Tue, 3 Feb 2009 17:21:20 +0100, Jakub wrote: > gai-0.5.10-16.fc11.src.rpm Breakage unrelated to GCC. gnome-panel >= 2.25 drops a pkg-config inter-package dependency from libpanelapplet-2.0.pc which causes missing CFLAGS here. From notting at redhat.com Tue Feb 3 16:57:49 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Feb 2009 11:57:49 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233637110.3238.0.camel@rosebud> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> <4987B1A8.1020703@ij.net> <1233636755.7493.72.camel@localhost.localdomain> <1233637110.3238.0.camel@rosebud> Message-ID: <20090203165748.GC1027@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > > > If you really wanted to save serious power, you'd stop inducing or forcing > > > people with less power hungry old systems (i586 ring a bell?) to replace them > > > with considerably hungrier newer systems. New systems make much better room > > > heaters than old systems, because they use a lot more power, far more than > > > one extra watt. Support for old systems == really substantial conservation. > > > > Isn't it odd then, that each new system I buy happens to use lower power > > over time than previous systems? > > Including manufacturing cost, that's not entirely true. No, but that's not what the poster suggested. Heck, I went from a 5-year old Athlon64 server to an Atom based one, and cut the power usage by a factor of over 5. Bill From dbn.lists at gmail.com Tue Feb 3 17:04:08 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 3 Feb 2009 09:04:08 -0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <1233678298.3486.2596.camel@cookie.hadess.net> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> Message-ID: <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> On Tue, Feb 3, 2009 at 8:24 AM, Bastien Nocera wrote: > On Mon, 2009-02-02 at 17:31 -0800, Dan Nicholson wrote: > >> That's exactly my point. Since ESD support has been removed in fedora, >> anyone trying to do gnome_sound_connection_get() will just get -1 back >> anyway. Furthermore, the gnome_sound_play() docs say that the sound >> may or may not play. So, why not just make it play a file with >> libcanberra? If it fails, oh well. You're in exactly the same >> situation you're in now. It seems pretty easy to me: >> >> void gnome_sound_play(const char *filename) >> { >> #ifdef HAVE_LIBCANBERRA_GTK >> ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME, >> filename, NULL); >> #endif >> } > > It's easy but broken because it's missing all the other properties that > libcanberra can use and give to other applications. For example, we > don't know whether it's a sound event (click/pop/whatever), or a help to > pronunciation in a dictionary. That's exactly the gnome_sound_play API: play this sound file, please. You don't care about any other metadata. If they did care about more metadata, they probably wouldn't have been using gnome_sound_play in the first place. >> I understand not wanting to write new apps to use gnome_sound_play >> since it's deprecated. But it's existing API that can't be removed. >> Why not have it work for apps that haven't been ported yet > > Because it's hardly more work to fix the applications themselves. > >> (or can't >> be ported)? > > Those were always in trouble. > >> > I'd rather spend time answering questions on how to make libcanberra >> > work with your app rather than spending time doing a half-working >> > work-around in libgnome. >> >> Sure. I would not suggest that new apps use gnome_sound*. > > And I don't see how adding a broken work-around to gnome_sound_* would > help us fix the applications properly. I didn't say anything about fixing applications properly. I'm talking about making an API that exists in the platform continue to work until it can be removed. gnome_sound_play is a crappy API for getting sound in an application, but it exists and is in use. Why not just make it continue to work since it's so simple? -- Dan From tgl at redhat.com Tue Feb 3 17:10:18 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 03 Feb 2009 12:10:18 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <28735.1233681018@sss.pgh.pa.us> Jakub Jelinek writes: > - 167 failures > packages that failed to build both with gcc 4.3 and 4.4 > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/ At least for my stuff, it seems the issue is that someone has installed a seriously non-backwards-compatible set of autoconf tools (and pretty recently, because some of those packages built okay as recently as 22-Jan). Perhaps there should have been a bigger deal made about that. regards, tom lane From wtogami at redhat.com Tue Feb 3 17:11:59 2009 From: wtogami at redhat.com (Warren Togami) Date: Tue, 03 Feb 2009 12:11:59 -0500 Subject: Jakub's Recommendations for ia32 Support Message-ID: <49887ADF.9090606@redhat.com> I talked with Jakub Jelinek to ask his recommendation of how Fedora 11 should proceed. Jakub recommends i586.rpm for Fedora 11, because it doesn't gain us much of anything to go with i686 minimum. The benefits of i586 to i686 are simply not important because cmov is usually not a worthwhile optimization on ia32. You sometimes find some testcase where cmov improves something, but often you find one where it pessimizes something as well. i686 to i686 w/ SSE2 would be a performance win, but that is clearly not an option for Fedora. If we go with i586.rpm's in Fedora, then redhat-rpm-config must be changed to include -mtune=generic for i586, currently it has that tuning only for i386 and i686. Compiler flags would need to be different between RHEL6 and Fedora anyway, because RHEL6 ppc32 userspace will be built with -mcpu=power4 making it 64bit processor capable only, and we definitely don't want this in Fedora. They are also considering doing RHEL6 i686 (Pentium 4+) only, again not an option for Fedora. Jakub recommended doing comparison tests of -m32 -march=i586 -mtune=generic vs. -m32 -march=i686 -mtune=generic with Spec2k and Spec2006 benchmark tools. Anyone interested in trying this? He also wants gcc-4.4 to go into dist-f11 immediately after Alpha, even if we are not doing the mass rebuild just yet. It is ABI compatible so shouldn't cause any problems on its own. Meanwhile it will allow maintainers to fix some problematic packages sooner. In related news, cebbert wants to do the following to the F-11 kernel: - Eliminate the current i686 kernel. - i686 hardware would get i686 PAE by default. - i586 kernel becomes i686, except without cmov. This is primarily so people don't complain when they realize they have the "i586" kernel. Warren Togami wtogami at redhat.com From jakub at redhat.com Tue Feb 3 17:34:17 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 18:34:17 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <49887597.9070106@FamilleCollet.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49887597.9070106@FamilleCollet.com> Message-ID: <20090203173417.GY5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 05:49:27PM +0100, Remi Collet wrote: > After adding a few headers (cstdio), it fails on a strange error > (i386 only I think, x86_64 succeed and ppc was canceled before end) > > Full log : > http://koji.fedoraproject.org/koji/taskinfo?taskID=1101825 > http://koji.fedoraproject.org/koji/getfile?taskID=1101832&name=build.log > > It seems (googling) it's a issue with -march=i386 > Any idea for this issue ? This will be magically fixed when koji switches to i586.rpm or i686.rpm packages. g++ by default uses -march=i586 unless -march is specified, so the above only fails if you explicitly build with -march=i386. The reason for switch to i586.rpm (or i686.rpm) is primarily the __sync_* builtins, OpenMP #pragma omp atomic and the fact that for some years glibc*.i386.rpm doesn't support pre-i486 anyway, neither does libstdc++ nor libgomp, nor any statically linked programs. Jakub From bmaly at redhat.com Tue Feb 3 17:34:31 2009 From: bmaly at redhat.com (Brian Maly) Date: Tue, 03 Feb 2009 12:34:31 -0500 Subject: look at this: samsung nc10 bootchart with mobil V2 In-Reply-To: References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com> <1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com> <20090130035404.GC4570@nostromo.devel.redhat.com> <1233288493.3698.67.camel@localhost.localdomain> <20090130150217.GB8869@nostromo.devel.redhat.com> <1233339915.30808.6.camel@localhost.localdomain> <498347DE.9020507@redhat.com> Message-ID: <49888027.8040204@redhat.com> Harald Hoyer wrote: > Brian Maly wrote: >> Simo Sorce wrote: >>> >>> >>>>> Why fedora's udev seem to slow down another bit while moblin's >>>>> udev seem >>>>> not ? >>>>> >>>> The second udev is just more rules. >>>> >>> >>> What about parallelizing udev and rc like in moblin ? Any gotcha >>> there ? >>> >>> Simo. >>> >>> >> >> What would happen if you parallelizing udev and rc on some ancient >> piece of hardware? Im thinking you might not ever get to a boot screen. >> But you could check to see what sort of CPU you have and parallelize >> conditionally if the hardware can handle it. Conceptually I think >> parallelizing this stuff is a novel idea. Its feasible in that its >> been done (i.e. the demo). And if we could optimize udev a bit we >> might gain a few more seconds there too. >> Good topic of discussion anyway... >> >> >> Brian >> >> > > And how do you know, that an rc script does not need a device, which > is created by udev? > Yeah, there would certainly have to be dependencies in the rc scripts. I would imagine if one of the rc scripts needed a device, it would be in a wait state until the device comes up. The mechanism to achieve this seems somewhat crucial. It will be interesting to discover how Moblin addresses this issue. Brian From mrmazda at ij.net Tue Feb 3 17:53:37 2009 From: mrmazda at ij.net (Felix Miata) Date: Tue, 03 Feb 2009 12:53:37 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233636755.7493.72.camel@localhost.localdomain> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> <4987B1A8.1020703@ij.net> <1233636755.7493.72.camel@localhost.localdomain> Message-ID: <498884A1.8010103@ij.net> On 2009/02/02 20:52 (GMT-0800) Jesse Keating composed: > On Mon, 2009-02-02 at 21:53 -0500, Felix Miata wrote: >> If you really wanted to save serious power, you'd stop inducing or forcing >> people with less power hungry old systems (i586 ring a bell?) to replace them >> with considerably hungrier newer systems. New systems make much better room >> heaters than old systems, because they use a lot more power, far more than >> one extra watt. Support for old systems == really substantial conservation. > Isn't it odd then, that each new system I buy happens to use lower power > over time than previous systems? How did you measure? Did you measure? My measurements using Seasonic PowerAngel SSM-1508RA: Description Speed Mfg Model Minutes KWH Rate PC w/ 2 HD 450 Mac G3 221 0.18 1.1729 PC, PIII, 133FSB, 2 IDE HD 1133 Dell GX150 168 0.15 1.2857 PC, K6-III 66FSB, 2 SCSI HD, 1 IDE 400 AOpen AX5T-3 1544 1.47 1.3710 PC, K6-III+ 100FSB, 3 SCSI HD 550 Asus P5S-B 553 0.73 1.9009 PC, P4-478 400FSB, 1 HD, 80+ PS 3000 Abit AI7 1424 1.94 1.9618 PC, Celeron478 400FSB, 1 HD 2400 Abit AI7 600 0.87 2.0880 PC, Socket A 333FSB, 1 HD, std PS 2000 Biostar M7NCD 120 0.20 2.4000 PC, P4-775 533FSB, 1+1 HD, 80+ PS 2800 PCChips T18 7200 12.06 2.4120 PC, P4-775 533FSB, 1+1 HD 2800 PCChips T18 691 1.30 2.7091 PC, P4-775 800FSB, 1+1 HD, 80+ PS 3400 Foxconn F9657AB 617 1.42 3.3141 80+ is described at http://www.80plus.org/ -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From bochecha at fedoraproject.org Tue Feb 3 17:59:20 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 3 Feb 2009 18:59:20 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <498884A1.8010103@ij.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> <4987B1A8.1020703@ij.net> <1233636755.7493.72.camel@localhost.localdomain> <498884A1.8010103@ij.net> Message-ID: <2d319b780902030959i19f6d1ecp7d8e201f875f922b@mail.gmail.com> > My measurements using Seasonic PowerAngel SSM-1508RA: > Description Speed Mfg Model Minutes KWH Rate > PC w/ 2 HD 450 Mac G3 221 0.18 1.1729 > PC, PIII, 133FSB, 2 IDE HD 1133 Dell GX150 168 0.15 1.2857 > PC, K6-III 66FSB, 2 SCSI HD, 1 IDE 400 AOpen AX5T-3 1544 1.47 1.3710 > PC, K6-III+ 100FSB, 3 SCSI HD 550 Asus P5S-B 553 0.73 1.9009 > PC, P4-478 400FSB, 1 HD, 80+ PS 3000 Abit AI7 1424 1.94 1.9618 > PC, Celeron478 400FSB, 1 HD 2400 Abit AI7 600 0.87 2.0880 > PC, Socket A 333FSB, 1 HD, std PS 2000 Biostar M7NCD 120 0.20 2.4000 > PC, P4-775 533FSB, 1+1 HD, 80+ PS 2800 PCChips T18 7200 12.06 2.4120 > PC, P4-775 533FSB, 1+1 HD 2800 PCChips T18 691 1.30 2.7091 > PC, P4-775 800FSB, 1+1 HD, 80+ PS 3400 Foxconn F9657AB 617 1.42 3.3141 > > 80+ is described at http://www.80plus.org/ I suppose you used the exact same system on each of them ? What was it ? That's an interesting measurement in any case :) ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From mrmazda at ij.net Tue Feb 3 18:02:27 2009 From: mrmazda at ij.net (Felix Miata) Date: Tue, 03 Feb 2009 13:02:27 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: <498886B3.4010602@ij.net> On 2009/02/03 13:44 (GMT+0200) Panu Matilainen composed: > Blinking things tend to draw attention, and in the case of Blinky the > Cursor it's drawing your attention to the fact that there is nothing at > all to attend to. No, it's drawing attention to: 1-point of focus 2-state ready to accept keyboard input, as opposed to lit up, but otherwise useless The blink for the reasons above is a tradition that dates back at least 45 years, probably a lot longer. -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From jeff at ocjtech.us Tue Feb 3 18:04:36 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 3 Feb 2009 12:04:36 -0600 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203173417.GY5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49887597.9070106@FamilleCollet.com> <20090203173417.GY5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <935ead450902031004k3555030bl17e30e1771e469c0@mail.gmail.com> On Tue, Feb 3, 2009 at 11:34 AM, Jakub Jelinek wrote: > On Tue, Feb 03, 2009 at 05:49:27PM +0100, Remi Collet wrote: >> >> It seems (googling) it's a issue with -march=i386 >> Any idea for this issue ? > > This will be magically fixed when koji switches to i586.rpm or i686.rpm > packages. g++ by default uses -march=i586 unless -march is specified, > so the above only fails if you explicitly build with -march=i386. > > The reason for switch to i586.rpm (or i686.rpm) is primarily the __sync_* > builtins, OpenMP #pragma omp atomic and the fact that for some years > glibc*.i386.rpm doesn't support pre-i486 anyway, neither does libstdc++ nor > libgomp, nor any statically linked programs. This will help out Asterisk as well, which has a hack in the .spec file to replace -march=i386 with -march=i486 to get support for the atomic operations. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From mrmazda at ij.net Tue Feb 3 18:11:59 2009 From: mrmazda at ij.net (Felix Miata) Date: Tue, 03 Feb 2009 13:11:59 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> Message-ID: <498888EF.1080903@ij.net> On 2009/02/03 11:04 (GMT+0100) Mathieu Bridon (bochecha) composed: > Actually, I would say that basically everyone benefits from any power > savings, no matter how small they are (you know, reducing our energy > consumption, saving the planet, all of that...) By that analogy, all desktop puters should be shut down whenever they are not generating responses to inputs, or actually accepting inputs, and the time lost in shutdown and restart is an acceptable cost, because the energy savings is non-zero. There are such things as reasonable threshholds and de minimus. I'm not convinced that that data presented for this so far is valid, much less above threshhold. 8 million trees naturally sounds like a lot when out of context, like the way politicians typically speak of spending and taxes. In the context of double or triple digit billions, 8 million isn't particularly much. -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From james at fedoraproject.org Tue Feb 3 18:21:32 2009 From: james at fedoraproject.org (James Antill) Date: Tue, 03 Feb 2009 13:21:32 -0500 Subject: Too many unowned directories In-Reply-To: References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090130211536.b7aa63d9.mschwendt@gmail.com> <1233350530.3650.28.camel@localhost.localdomain> <1233350803.3345.18.camel@localhost.localdomain> Message-ID: <1233685292.28200.137.camel@code.and.org> On Sat, 2009-01-31 at 00:36 +0200, Panu Matilainen wrote: > On Fri, 30 Jan 2009, Miloslav Trma? wrote: > > > Jesse Keating p??e v P? 30. 01. 2009 v 13:22 -0800: > >> Why not fail the build if unowned directories are found, just like we do > >> for unowned files? That way you catch it at build time before you try > >> and do something useful with the build. > > How do we determine which directory is unowned and which is provided by > > a dependency? If we don't, every package would have to own /usr. > > It'd be possible to turn the topmost unowned directory into a file (well, > directory) dependency. Either at build time, which would cause a big pile > of new file dependencies in the metadata, or rpm could generate them at > runtime. The problem with runtime generated dependencies is just that yum > & the like wouldn't be able to resolve them without fairly big changes. It'd be painful to have everything have a "Requires: /usr" (or whatever) as it would make filelists mandatory for every update ... but it would just work, with yum. -- James Antill Fedora From dimi at lattica.com Tue Feb 3 18:18:50 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 13:18:50 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <498888EF.1080903@ij.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <498888EF.1080903@ij.net> Message-ID: <1233685130.8745.399.camel@dimi.lattica.com> On Tue, 2009-02-03 at 13:11 -0500, Felix Miata wrote: > 8 million trees naturally sounds like a lot when out of context, > like the way politicians typically speak of spending and taxes. In the > context of double or triple digit billions, 8 million isn't > particularly much. To add insult to injury, this like saying this is going to save _thousands_ of puppies every month! How the heck does one figure how many trees you save?!? Who's burning trees to generate electricity? I'm pretty sure we'd save a lot more trees/puppies/lives if all the overweight people loose a few pounds. I propose we make the desktop graphic promote that idea given that it costs nothing to do and yet can have such a potential good effect on the planet. -- Dimi Paun Lattica, Inc. From skvidal at fedoraproject.org Tue Feb 3 18:22:47 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Feb 2009 13:22:47 -0500 Subject: Too many unowned directories In-Reply-To: <1233685292.28200.137.camel@code.and.org> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090130211536.b7aa63d9.mschwendt@gmail.com> <1233350530.3650.28.camel@localhost.localdomain> <1233350803.3345.18.camel@localhost.localdomain> <1233685292.28200.137.camel@code.and.org> Message-ID: <1233685367.3238.15.camel@rosebud> On Tue, 2009-02-03 at 13:21 -0500, James Antill wrote: > On Sat, 2009-01-31 at 00:36 +0200, Panu Matilainen wrote: > > On Fri, 30 Jan 2009, Miloslav Trma? wrote: > > > > > Jesse Keating p??e v P? 30. 01. 2009 v 13:22 -0800: > > >> Why not fail the build if unowned directories are found, just like we do > > >> for unowned files? That way you catch it at build time before you try > > >> and do something useful with the build. > > > How do we determine which directory is unowned and which is provided by > > > a dependency? If we don't, every package would have to own /usr. > > > > It'd be possible to turn the topmost unowned directory into a file (well, > > directory) dependency. Either at build time, which would cause a big pile > > of new file dependencies in the metadata, or rpm could generate them at > > runtime. The problem with runtime generated dependencies is just that yum > > & the like wouldn't be able to resolve them without fairly big changes. > > It'd be painful to have everything have a "Requires: /usr" (or > whatever) as it would make filelists mandatory for every update ... but > it would just work, with yum. Not that I'd suggest this but we _could_ add dirs to the primary filelist.... -sv From mrmazda at ij.net Tue Feb 3 18:24:03 2009 From: mrmazda at ij.net (Felix Miata) Date: Tue, 03 Feb 2009 13:24:03 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <49885F7C.8060608@redhat.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> Message-ID: <49888BC3.7060100@ij.net> On 2009/02/03 10:15 (GMT-0500) Andrew Haley composed: > More efficiency is always better Efficiency isn't always what it appears. Foo's car is most efficient at 50KPH, so efficiency dictates that's the speed he should drive. Bar's car is most efficient at 45KPH, so that's how fast efficiency dictates he drive. May car is most efficient at 57KPH, so that's the speed efficiency dictates I drive. The speed limit is 50KPH. The road, which is the exclusive path between origin and destination of Foo, Bar and me, is one lane wide for each direction. Foo's, Bar's & my direction are the same, and our desired ETAs preclude driving while the other two are not enroute. What is more efficient? -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From jwboyer at gmail.com Tue Feb 3 18:25:51 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 13:25:51 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <49888BC3.7060100@ij.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <49888BC3.7060100@ij.net> Message-ID: <20090203182551.GC10541@yoda.jdub.homelinux.org> On Tue, Feb 03, 2009 at 01:24:03PM -0500, Felix Miata wrote: >On 2009/02/03 10:15 (GMT-0500) Andrew Haley composed: > >> More efficiency is always better > >Efficiency isn't always what it appears. Foo's car is most efficient at >50KPH, so efficiency dictates that's the speed he should drive. Bar's car is >most efficient at 45KPH, so that's how fast efficiency dictates he drive. May >car is most efficient at 57KPH, so that's the speed efficiency dictates I >drive. The speed limit is 50KPH. The road, which is the exclusive path >between origin and destination of Foo, Bar and me, is one lane wide for each >direction. Foo's, Bar's & my direction are the same, and our desired ETAs >preclude driving while the other two are not enroute. What is more efficient? Walk or ride a bicycle. josh From nicolas.mailhot at laposte.net Tue Feb 3 18:29:15 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 19:29:15 +0100 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <20090203133223.GB5846@mokona.greysector.net> Message-ID: <1233685755.14675.5.camel@arekh.okg> Le mardi 03 f?vrier 2009 ? 11:44 -0500, Gregory Maxwell a ?crit : > Most easily measured things (rsvg rendering, freetype) probably aren't > ever performance critical for typical users. You're very wrong about any codepath used to display text -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dimi at lattica.com Tue Feb 3 18:33:03 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 13:33:03 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203182551.GC10541@yoda.jdub.homelinux.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <49888BC3.7060100@ij.net> <20090203182551.GC10541@yoda.jdub.homelinux.org> Message-ID: <1233685983.8745.402.camel@dimi.lattica.com> On Tue, 2009-02-03 at 13:25 -0500, Josh Boyer wrote: > Walk or ride a bicycle. Right. How many chickens/cattle/pigs you kill to save just a few gallons of gas? In what world is that more 'efficient'? -- Dimi Paun Lattica, Inc. From thomas.moschny at gmail.com Tue Feb 3 18:38:10 2009 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Tue, 3 Feb 2009 19:38:10 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <49888BC3.7060100@ij.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <49888BC3.7060100@ij.net> Message-ID: 2009/2/3 Felix Miata : > Efficiency isn't always what it appears. Foo's car is most efficient at > 50KPH, so efficiency dictates that's the speed he should drive. Bar's car is > most efficient at 45KPH, so that's how fast efficiency dictates he drive. May > car is most efficient at 57KPH, so that's the speed efficiency dictates I > drive. The speed limit is 50KPH. The road, which is the exclusive path > between origin and destination of Foo, Bar and me, is one lane wide for each > direction. Foo's, Bar's & my direction are the same, and our desired ETAs > preclude driving while the other two are not enroute. What is more efficient? Meet, use your car for Foo, Bar and yourself, and divide the speeding ticket by three. -- Thomas Moschny From Fedora at FamilleCollet.com Tue Feb 3 18:41:23 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 03 Feb 2009 19:41:23 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203173417.GY5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49887597.9070106@FamilleCollet.com> <20090203173417.GY5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <49888FD3.3060104@FamilleCollet.com> Thanks for this detailed answer. > This will be magically fixed when koji switches to i586.rpm or i686.rpm > packages. g++ by default uses -march=i586 unless -march is specified, > so the above only fails if you explicitly build with -march=i386. Do you think this is going to happen soon or I need to hack my spec ? Remi. From mjg at redhat.com Tue Feb 3 17:14:20 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 17:14:20 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203142327.GD4852@localhost.localdomain> References: <20090130053144.GA25512@srcf.ucam.org> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <200902021743.13916.konrad@tylerc.org> <1233625638.27307.19.camel@rosebud> <20090203142327.GD4852@localhost.localdomain> Message-ID: <20090203171420.GA14520@srcf.ucam.org> On Tue, Feb 03, 2009 at 09:23:27AM -0500, Paul W. Frields wrote: > We should be interested in saving power, but shouldn't use that as a > sole reason to disable Fedora interest groups' activities. For > instance, it probably saves significant power for us to never issue > another Fedora Live CD that uses a runlevel other than 3, but that's > an unreasonable target. Not really. Until you start X, there's nothing to turn on the power saving functionality in your graphics hardware. -- Matthew Garrett | mjg59 at srcf.ucam.org From mjg at redhat.com Tue Feb 3 18:46:51 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 18:46:51 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233685130.8745.399.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <498888EF.1080903@ij.net> <1233685130.8745.399.camel@dimi.lattica.com> Message-ID: <20090203184651.GA16180@srcf.ucam.org> On Tue, Feb 03, 2009 at 01:18:50PM -0500, Dimi Paun wrote: > I'm pretty sure we'd save a lot more trees/puppies/lives if all > the overweight people loose a few pounds. I propose we make the > desktop graphic promote that idea given that it costs nothing to > do and yet can have such a potential good effect on the planet. It's not free - choice of default wallpaper can save up to 0.5W on systems with framebuffer compression support. -- Matthew Garrett | mjg59 at srcf.ucam.org From limb at jcomserv.net Tue Feb 3 18:47:48 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 3 Feb 2009 12:47:48 -0600 (CST) Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <861d4618c290cfe67dc754b16ff37eb2.squirrel@mail.jcomserv.net> Is it anticipated that there will be a rash of FTBFS bugs for packages that still fail X days after gcc-4.4 hits rawhide? I think I got all mine, but would appreciate the extra nagging if I didn't. > Hi! > > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). > > Here are the most common causes of the regressions (fails to build > with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7): > > - 142 failures > C++ () no longer includes . > So does , , , . > When you need anything from C stdio.h, such as EOF, *printf*, > *scanf*, remove etc., add #include to all sources that > need it. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/cstdio/ > > - 22 failures > G++ 4.4 rejects int main () { return main (); } or > int main () { main (); return 0; }, > as main shouldn't be used within the program (see ISO C++ > [basic.start.main]/3). > This breaks some configure scripts, e.g. AC_CHECK_LIB with second > argument main as in > AC_CHECK_LIB(stdc++,main,,AC_MSG_ERROR([libstdc++ not installed])) > will now fail. As AC_CHECK_LIB isn't well suited for C++, which > requires > prototypes and AC_CHECK_LIB doesn't provide them, I guess > AC_CHECK_LIB(stdc++,int,,AC_MSG_ERROR([libstdc|| not installed])) > could be used instead. This results in int main () { return int (); } > or int main () { int (); return 0; } > Only packages that actually failed to build because of this > are listed, there are many more that are affected by it though. > Look for checking for main in -l... giving no, even for packages > that succeeded. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/main/ > > - 15 failures > C++ () no longer includes . > Neither does . When you need uint32_t, uint8_t etc., > #include . > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdint/ > > - 15 failures > #elif argument is now evaluated even if earlier #if/#elif > condition evaluated non-zero, to make sure they are valid > constant expressions. See http://gcc.gnu.org/PR36320 > To fix this, either use #else when you want it instead of > #elif (e.g. several packages use #elif without any argument > at all), or use #else #if ... #endif. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/elif/ > > - 8 failures > glib2's gthread.h contains a couple of aliasing issues (e.g. > in g_once_init_enter) and a bunch of programs get bitten by it > when they inline it. > This should be fixed in glib2. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/glib.aliasing/ > > - 6 failures > Other aliasing problem. In the GCC 4.3 -> 4.4 transition > the most common problem is: > char buf[NNN]; // or unsigned char or signed char > ... > ((struct somestruct *)buf)->somefield = 1 > While you can access any object through char, unsigned char or > signed char pointer and modify parts/all of it, it is not the > other way around. In this case you probably want a union of > the buffer and struct somestruct. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/aliasing/ > > - 2 failures > GCC bugs that were already fixed in newer gcc 4.4 (4.4.0-0.13 > should work). > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/already_fixed/ > > - 1 failure > Package built with -Werror, where one extra warning appeared. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/Werror/ > > - 1 failure > g++ now errors on: > struct C { virtual ~C (); }; > struct B : public C { int i; }; > struct A { const B a; A () { bar (&a); } void bar (const B *); }; > while previously it only errored if C virtual wasn't involved. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/uninit/ > > - 1 failure > __builtin_stdarg_start has been removed. #include > should be used, rather than writing stuff by hand, and if really > necessary > (why?), then at least it needs to use __builtin_va_start instead. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdarg/ > > - 1 failure > open with O_CREAT set in the second argument needs to have 3 arguments, > not > just 2. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/open2/ > > - 1 failure > free called with a pointer to non-heap allocated object. > E.g. > char buf[128], *bufp; > ... > bufp = buf; > if (something) > { > bufp = malloc (somesize); > ... > } > ... > if (bufp != buf) > free (buf); // Should have been bufp. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/nonheapfree/ > > - 30 failures > Unsorted stuff that succeeds to build with 4.3 and fails to build > with 4.4. Only looked briefly at openbabel, in which case > the bug is that it has locale.h in the include search path, which > overrides the system . > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/unsorted/ > > - 31 failures > Various mock related issues, packages failed at root.log stage, > before starting to build. Some might be related to mock being used > on RHEL5 instead of a recent fedora. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/deps/ > > - 167 failures > packages that failed to build both with gcc 4.3 and 4.4 > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/ > > - 117 failures > unanalyzed packages with failed to build with 4.4, but 4.3 build wasn't > performed (ran out of time), so either they fall into fails-even-with-43 > category, or into unsorted. > > Jakub > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- in your fear, speak only peace in your fear, seek only love -d. bowie From loganjerry at gmail.com Tue Feb 3 16:28:12 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 3 Feb 2009 09:28:12 -0700 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <870180fe0902030828g66556536j3eba991e8ddd8d33@mail.gmail.com> On Tue, Feb 3, 2009 at 9:21 AM, Jakub Jelinek wrote: > jsr-305-0-0.1.20080824svn.fc10.src.rpm > This is a Java package. In fact, I see a number of Java packages in the list. They are failing to build because maven is currently broken [1]. You can take them off your list since GCC is not involved. References: [1] https://bugzilla.redhat.com/show_bug.cgi?id=480093 -- Jerry James http://loganjerry.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdwheele at indiana.edu Tue Feb 3 18:48:34 2009 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 03 Feb 2009 13:48:34 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203184651.GA16180@srcf.ucam.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <498888EF.1080903@ij.net> <1233685130.8745.399.camel@dimi.lattica.com> <20090203184651.GA16180@srcf.ucam.org> Message-ID: <1233686914.30430.19.camel@nibbler.dlib.indiana.edu> On Tue, 2009-02-03 at 18:46 +0000, Matthew Garrett wrote: > On Tue, Feb 03, 2009 at 01:18:50PM -0500, Dimi Paun wrote: > > > I'm pretty sure we'd save a lot more trees/puppies/lives if all > > the overweight people loose a few pounds. I propose we make the > > desktop graphic promote that idea given that it costs nothing to > > do and yet can have such a potential good effect on the planet. > > It's not free - choice of default wallpaper can save up to 0.5W on > systems with framebuffer compression support. > Does this mean that its not bikeshed painting that's been going on, but bikeshed wallpapering? *ducks* Brian From notting at redhat.com Tue Feb 3 18:51:04 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Feb 2009 13:51:04 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> Message-ID: <20090203185104.GA2631@nostromo.devel.redhat.com> Orcan Ogetbil (oget.fedora at gmail.com) said: > A quick calculation showed me that, > assuming there are 10 million Fedora computers in the world, running 7/24, > saving 2W per computers saves about 1 relatively large size tree (40 > tons) every 2.3 days. > Just for the record. Considering: - the 2W savings is only on a patched radeon driver, AIUI (although it could theoretically be ported to other drivers such as nouveau (not intel), given enough specs) - the savings is only if the screen is otherwise not updating - if the screen stays this way for more than a couple of minutes, the screensaver will kick in this estimate is many orders of magnitude too high. That being said, just flip the default already. Bill From tibbs at math.uh.edu Tue Feb 3 18:51:20 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Feb 2009 12:51:20 -0600 Subject: Package review SIG work Message-ID: I would like see if it's possible to get the package review SIG moving again. I personally have been very low on time since Fudcon but things are starting to let up. I have two questions: Who is interested in working with a package review SIG? I'll include some possible SIG agenda items at the end of this message. How should the SIG conduct business? Within Fedora this generally happens via IRC meetings, but I'm not sure how that would work out because we really do have reviewers from all over the planet and picking a single time for an IRC meeting will inevitably leave some folks out. Plus there's been some recent backlash relating to conducting business on IRC which I'm sensitive to. So, I see a couple of options: 1) Have more than one meeting time and rotate through them. 2) Figure out how to conduct reasonable business (with an agenda, time-limited discussion and votes) on a mailing list. I am willing to handle the various duties while the SIG gets organized. I will follow this thread for a couple of days and summarize the responses. Here's a random list of potential SIG agenda items: Getting https://fedoraproject.org/wiki/SIGs/Package_Review into shape. Dealing with significantly time-consuming reviews and possible multiple-reviewer scenarios. Should the SIG identify these reviews and attempt to parcel them out to groups of reviewers? Addressing the growing number of NEEDSPONSOR tickets. Forming a merge review priority list: finishing up the F9MergeReviewTarget ticket and identifying the next set of reviews to tackle. Metrics. Proposing to manage the ReviewGuidelines document. - J< From aph at redhat.com Tue Feb 3 18:51:57 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Feb 2009 18:51:57 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <49888BC3.7060100@ij.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <49888BC3.7060100@ij.net> Message-ID: <4988924D.1020801@redhat.com> Felix Miata wrote: > On 2009/02/03 10:15 (GMT-0500) Andrew Haley composed: > >> More efficiency is always better > > Efficiency isn't always what it appears. Foo's car is most efficient at > 50KPH, so efficiency dictates that's the speed he should drive. Bar's car is > most efficient at 45KPH, so that's how fast efficiency dictates he drive. May > car is most efficient at 57KPH, so that's the speed efficiency dictates I > drive. The speed limit is 50KPH. The road, which is the exclusive path > between origin and destination of Foo, Bar and me, is one lane wide for each > direction. Foo's, Bar's & my direction are the same, and our desired ETAs > preclude driving while the other two are not enroute. What is more efficient? There's no way to tell from the information you've given. What is the point of this question? Andrew. From dominik at greysector.net Tue Feb 3 18:53:10 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 3 Feb 2009 19:53:10 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <49887ADF.9090606@redhat.com> References: <49887ADF.9090606@redhat.com> Message-ID: <20090203185310.GD5846@mokona.greysector.net> On Tuesday, 03 February 2009 at 18:11, Warren Togami wrote: > I talked with Jakub Jelinek to ask his recommendation of how Fedora 11 > should proceed. > > Jakub recommends i586.rpm for Fedora 11, because it doesn't gain us much > of anything to go with i686 minimum. The benefits of i586 to i686 are > simply not important because cmov is usually not a worthwhile > optimization on ia32. You sometimes find some testcase where cmov > improves something, but often you find one where it pessimizes something > as well. I'd like to see a case (not involving Pentium 4) where using cmov is slower than not using it. It definitely is faster for decoding H.264 in FFmpeg for example. > i686 to i686 w/ SSE2 would be a performance win, but that is > clearly not an option for Fedora. SSE2-optimized libraries can be built and installed into /usr/lib/sse2. Our ld.so already supports that. [...] > Jakub recommended doing comparison tests of -m32 -march=i586 > -mtune=generic vs. -m32 -march=i686 -mtune=generic with Spec2k and > Spec2006 benchmark tools. Anyone interested in trying this? Are these tools' sources available somewhere? Last I searched I couldn't find them. > He also wants gcc-4.4 to go into dist-f11 immediately after Alpha, even > if we are not doing the mass rebuild just yet. It is ABI compatible so > shouldn't cause any problems on its own. Meanwhile it will allow > maintainers to fix some problematic packages sooner. +1 > In related news, cebbert wants to do the following to the F-11 kernel: > - Eliminate the current i686 kernel. > - i686 hardware would get i686 PAE by default. Not all i686 hardware is PAE capable. > - i586 kernel becomes i686, except without cmov. This is primarily so > people don't complain when they realize they have the "i586" kernel. And this will be installed on anything that's not PAE capable? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Tue Feb 3 18:56:10 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 3 Feb 2009 19:56:10 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090203185610.GE5846@mokona.greysector.net> On Tuesday, 03 February 2009 at 16:48, Jakub Jelinek wrote: > Hi! > > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). > > Here are the most common causes of the regressions (fails to build > with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7): I'd like to request per-maintainer lists. I have too many packages to manually search each of these lists for my own packages. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From notting at redhat.com Tue Feb 3 18:58:01 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Feb 2009 13:58:01 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <49887ADF.9090606@redhat.com> References: <49887ADF.9090606@redhat.com> Message-ID: <20090203185801.GB2631@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > i686 to i686 w/ SSE2 would be a performance win, but that is > clearly not an option for Fedora. Well, I think this is debatable. The i686 CPUs without SSE2 (Pentium III and earlier, 32-bit Athlon) are generally older and haven't been sold for even longer than the C3 and similar processors that were a concern for i586. They are likely to have a much larger userbase, though, so I can seee still supporting them. Bill From limb at jcomserv.net Tue Feb 3 18:58:41 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 3 Feb 2009 12:58:41 -0600 (CST) Subject: Package review SIG work In-Reply-To: References: Message-ID: > I would like see if it's possible to get the package review SIG moving > again. I personally have been very low on time since Fudcon but > things are starting to let up. > > I have two questions: > > Who is interested in working with a package review SIG? I'll include > some possible SIG agenda items at the end of this message. I still am. As you've, my review work has slowed to a trickle, but I think that only highlights the importance. . . > How should the SIG conduct business? > > Within Fedora this generally happens via IRC meetings, but I'm not > sure how that would work out because we really do have reviewers from > all over the planet and picking a single time for an IRC meeting will > inevitably leave some folks out. Plus there's been some recent > backlash relating to conducting business on IRC which I'm sensitive > to. > > So, I see a couple of options: > > 1) Have more than one meeting time and rotate through them. > > 2) Figure out how to conduct reasonable business (with an agenda, > time-limited discussion and votes) on a mailing list. This works better for me given $_DAYJOB and children. Maybe set an expiry date/time (value TBD) in the subject of each discussion thread? > I am willing to handle the various duties while the SIG gets > organized. I will follow this thread for a couple of days and > summarize the responses. > > > Here's a random list of potential SIG agenda items: > > Getting https://fedoraproject.org/wiki/SIGs/Package_Review into shape. > > Dealing with significantly time-consuming reviews and possible > multiple-reviewer scenarios. Should the SIG identify these reviews > and attempt to parcel them out to groups of reviewers? Based on what criteria? What makes a multi-reviewer review? > Addressing the growing number of NEEDSPONSOR tickets. I was thinking about this. What if we had something that sent a weekly spam to the sponsors list with the ten oldest NEW && NEEDSPONSOR reviews? > Forming a merge review priority list: finishing up the > F9MergeReviewTarget ticket and identifying the next set of reviews to > tackle. I've been chipping away at this, but some are beyond my depth, and others are in process but stalled, sometimes after massive work, and are intimdating to get in the middle of. > Metrics. > > Proposing to manage the ReviewGuidelines document. > > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- in your fear, speak only peace in your fear, seek only love -d. bowie From fedora at leemhuis.info Tue Feb 3 18:59:44 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Feb 2009 19:59:44 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <49889420.3000401@leemhuis.info> On 03.02.2009 17:21, Jakub Jelinek wrote: > On Tue, Feb 03, 2009 at 05:01:24PM +0100, Jochen Schmitt wrote: >> Jakub Jelinek schrieb: >>> In the past few days I've done a mass rebuild of rawhide-20090126 >>> in mock with gcc-4.4.0-0.9 (and corresponding libtool). >>> 6228 packages were successfully built, for the rest I've tried >>> to rebuild them also with gcc-4.3.2-7 (though I ran out of time, >>> so a couple of packages weren't attempted with 4.3). >>> >> If may be helpful, if you can publish a list with packages which caused >> issues with the new compiler. So we may be able to fix the issue without >> the need to tryout all of our packages. > > They were referenced in the links. > Anyway, here is the list of all packages that didn't build successfully > with 4.4, [...] Finding all your packages in such a long list gets really hard as soon as you maintain 10 or 15 packages. Here is a list of packages with thir owners, sorted by owner; generated with fedoradev-pkgowners: http://thorstenl.blogspot.com/2007/09/fedoradev-pkgowners-get-package-owners.html Should make things a lot easier. Use at your own risk. abbot protobuf abompard amarok abompard cryptopp abompard qca-ossl abompard tiger abompard xine-lib abompard xlhtml aconway qpidc aconway rhm adalloz pan adrian kover adrian source-highlight afb slim afsilva nethogs agoode escape airlied xorg-x11-drv-nouveau ajax gstreamer-plugins-good ajax libpciaccess ajax quesa ajax xorg-x11-drv-diamondtouch ajax xorg-x11-drv-wiimote akahl bmpx alexlan perl-bioperl alexlan perl-Convert-Binary-C anaconda-maint anaconda athimm ivtv-utils athimm libFoundation athimm maildrop atkac tightvnc atorkhov ember atorkhov libwfut avesh openswan awjb freealut awjb koffice awjb libopensync-plugin-kdepim awjb libpolyxmass awjb libpqxx awjb openal awjb polyxmass-bin awjb rxvt-unicode awjb synce-software-manager awjb vdccm awjb wine behdad gthumb behdad libthai belegdol gnome-chemistry-utils belegdol museek+ bellet FlightGear berrange perl-Test-AutoBuild berrange python-virtinst berrange virt-manager bjensen ax25-apps bjensen fldigi bjensen linpsk bjohnson dbmail bonii moe bos ghc bos ghc-gtk2hs bos haddock09 bos happy bos llvm bpepple evolution-brutus bpepple farsight2 bpepple ggz-gtk-client bpepple libjingle bpepple nautilus-image-converter bpepple python-reportlab bpepple xchat-gnome bpostle hugin braden openvrml buc freetds cagney frysk caolanm icu caolanm openoffice.org cchance baekmuk-ttf-fonts cchance stardict cheese libopensync-plugin-syncml chitlesh alliance chitlesh ktechlab chitlesh qwtplot3d cjb ohm claudiotomasoni qtoctave clumens elilo corsepiu OpenSceneGraph corsepiu perl-Class-Autouse corsepiu perl-Class-Inspector corsepiu perl-File-Find-Rule-Perl corsepiu perl-Test-Inline cr33dog ltsp-utils cweyl perl-POE-Component-SNMP cweyl perl-RRD-Simple cweyl perl-Test-WWW-Mechanize-Catalyst cwickert gwget cwickert xfce4-gsynaptics-mcs-plugin cwickert xfce-mcs-plugin-gsynaptics danms libvirt-cim davidz DeviceKit-disks davidz festival davidz gnome-disk-utility davidz gnome-speech dbhole antlr dbhole jrefactory dbhole maven2 dbhole maven-scm dbhole maven-shared dbhole plexus-appserver dbhole plexus-cdc dbhole plexus-maven-plugin dbhole plexus-runtime-builder dbhole plexus-xmlrpc dbhole velocity dcantrel gpart dcbw NetworkManager dchen ibus-chewing dchen libchewing dchen zhcon deji cln deji exempi deji file-browser-applet deji referencer deji strigi deji sword denis k3d denis libgnomedbmm denis libpanelappletmm denis pam_keyring denis pstoedit devrim classpathx-jaf dledford lam dledford libibcommon dledford libibmad dledford libibumad dledford opensm drago01 athcool drago01 beagle drago01 dbus-c++ drago01 gpar2 drago01 libpar2 drago01 linkage drago01 pinot drepper pfstools dwalsh selinux-policy dwheeler E dwmw2 apmud dwmw2 iprutils dwmw2 linux-atm dwmw2 powerpc-utils dwmw2 powerpc-utils-papr dwmw2 ppc64-utils dwmw2 ps3pf-utils dwmw2 yaboot ecik aria2 ecik kadu edhill cdo edhill itpp edhill libctl edhill nco edhill scrip ehabkost etherboot emunson lsvpd ensc dietlibc ensc xca eponyme edb ertzing fwbuilder fab srm faucamp flite firewing gnofract4d fnasser geronimo-specs fnasser jakarta-commons-el frankb ctapi-cyberjack gecko-maint seamonkey gecko-maint thunderbird gecko-maint xulrunner gemi clisp gemi ecl gemi nyquist gemi ocaml-lablgtk gemi oorexx gemi q gemi smarteiffel gemi TeXmacs ghenry Sprog gilboa kdebluetooth green ardour green hydrogen green ladspa-swh-plugins green lash green libfreebob green seq24 green ws-commons-util guidoledermann multiget hadess bluez-gnome hadess totem hardaker dnssec-tools hedayat rcsslogplayer hedayat rcssserver hedayat rcssserver3d hguemar listen hjames log4cxx hjames quickfix homeless rudeconfig huzaifas dia huzaifas gnumeric huzaifas libtar ianweller lordsawar imntreal libprojectM ivaxer glog ivazquez mod_dnssd ivazquez xmlcopyeditor ixs libsndfile izhar libcompizconfig jakub gcc jakub prelink james zsh jcollie jrtplib jcollie libpri jcollie libresample jcollie python-lxml jeckersb PyYAML jgranado parted jima alsa-oss jjames gcl jkratoch gdb jmagne esc jnovy allegro jnovy compat-db jnovy netpbm jnovy teckit jnovy texlive joost fpc jorton apr jorton php joshuadf alpine jpye fityk jreznik kde-plasma-quickaccess jreznik kde-plasma-runcommand jroth libspe2 jsafrane nc jsafrane openldap jskala iputils jskala netatalk jskala squid jsoeterb xmms-cdread jspaleta g3data jspaleta revelation jstanley supybot-fedora jtulach javahelp2 jussilehtola jmol jwboyer stapitrace jwilson dvgrab jwilson libdv jwrdegoede ballbuster jwrdegoede boswars jwrdegoede cegui jwrdegoede cel jwrdegoede ClanLib jwrdegoede ClanLib06 jwrdegoede openmsx jwrdegoede stormbaancoureur kaboom qgo kaigai sepostgresql kairo procbench kanarip ruby karlik tesseract karlik widelands karsten prctl karsten vim kasal cairo-java kasal gdbm kasal libgconf-java kasal libglade-java kasal libgnome-java kasal libgtk-java kasal libvte-java kasal perl-TermReadKey kasal perl-XML-LibXSLT kernel-maint kernel kevin exo kevin libxfce4menu kevin libxfcegui4 kevin orage kevin Thunar kevin twinkle kevin xfce4-appfinder kevin xfce4-panel kevin xfce4-session kevin xfce4-settings kevin xfce-mcs-manager kevin xfce-mcs-plugins kevin xfce-mcs-plugins-extra kevin xfce-utils kevin xfconf kevin xfdesktop kevin xfprint kevin xfwm4 key trousers konradm azureus konradm boolstuff konradm gfan konradm iml konradm libtorrent konradm python-psyco konradm rtorrent konradr ibmasm krh compiz krh synaptics krh xkeyboard-config kurzawa incollector kwizart animorph kwizart aqsis kwizart libgii kwizart OpenEXR_CTL kwizart OpenEXR_Viewers kwizart PerceptualDiff kyle squashfs-tools kzak gnome-applet-vm laxathom gammu laxathom gnome-desktop-sharp laxathom python-gammu laxathom quake3 laxathom wammu leo pcmanx-gtk2 lfarkas gstreamer-java lfarkas rxtx limb ddd limb glunarclock limb gnotime limb qof limb supertuxkart limb xmoto liquidat ktorrent liquidat speedcrunch lkundrak fusecompress lkundrak inkscape lkundrak nightview lkundrak starlab lkundrak sunbird llim redhat-lsb lmacken dclib lmacken gobby lmacken python-peak-rules lmacken valknut lucilanga svxlink lucilanga xastir lutter ruby-rpm lyosnorezel thibault-fonts makghosh qps mathstuf sigen mbarnes devhelp mbarnes gtkspell mbarnes python-ldap mccann libfakekey mclasen libgnomekbd mebrown libsmbios mef ice mgarski digikam mgarski krusader mgarski xscorch mhlavink nut michich icecream mikep fmt-ptrn mildew inetvis mildew sudo mjakubicek boinc-client mjakubicek orsa mkasik cups-pk-helper mmahut gnuradio mnowak khmeros-fonts mnowak unikurd-web-font monnerat insight mpg sugar mpg xapian-core mschwendt compat-wxGTK26 mschwendt gai mschwendt geeqie mso subtitleeditor mtasaka cairo-dock mtasaka kazehakase mtasaka monafont mtasaka ochusha mtasaka xplanet mwiriadi gnome-themes-extras mwiriadi mediatomb mwringe jline mwringe modello mwringe msv mwringe xdoclet mzazrive xqilla mzazrive xqilla10 nalin nss_ldap nando qjackctl nando qsynth nbecker igraph ndim nted nim lzop nim nomarch notting aqbanking nphilipp bzflag nphilipp gtkimageview nphilipp sane-backends nphilipp ufraw nsantos jtidy olea htmlparser ondrejj sagator orion gdl orion hdf5 orion lasi orion libsynaptics orion plplot orion R-lmtest orphan 8Kingdoms orphan jabbin orphan libzzub orphan nautilus-share orphan pekwm ovasik coreutils ovasik libwvstreams ovasik openjade ovasik star overholt xmlrpc3 pbrobinson geoclue pbrobinson gypsy pcheung axis pcheung castor pcheung plexus-i18n pertusus bes pertusus libdap peter ejabberd peter stratagus pfj boo pfj monodoc pfkeb HippoDraw pghmcfc glib pghmcfc gtkwave pgordon midori pgordon nemiver pgordon rb_libtorrent pgordon WebKit phuang scim phuang scim-bridge pingou R-BSgenome.Celegans.UCSC.ce2 pingou R-BSgenome.Dmelanogaster.FlyBase.r51 pingou R-hgu95av2probe pingou R-pls pmachata flex pnemade m17n-lib pravins samyak-fonts pravins ttmkfdir pwouters ldns pwouters lrmi pwouters s3switch qspencer autotrace quantumburnz barry rafalzaq glob2 rafalzaq pingus rakesh coredumper rakesh ctemplate rakesh gflags rakesh linphone rakesh octave rakesh opencv rathann dx rathann ed2k_hash rathann freefem++ rathann mnemosyne rathann openbabel rdieter cmucl rdieter eigen2 rdieter kdeplasma-addons rdieter kde-settings rdieter kipi-plugins rdieter libmusicbrainz3 rdieter libofa rdieter lyx rdieter maxima rdieter ntl rdieter xsettings-kde remi mysql++ rezso gdal rezso grass rezso iverilog rezso mapnik rezso mapserver rhughes DeviceKit-power rhughes gnome-packagekit rhughes gnome-power-manager rhughes PackageKit rjones collectd rjones mingw32-filesystem rjones ocaml-omake rmccabe clustermon rmccabe ricci robert libnids robert popt roozbeh charis-fonts rrakus bash rrakus cdrkit rrakus librtas rrankin gpsim rstrode gedit rstrode libbonoboui rstrode redhat-menus ruben incron ruben pdns ruben pdns-recursor rvinyard bitgtkmm rvinyard conexus rvinyard conexusmm rvinyard nqc rvinyard papyrus rvokal net-tools s4504kr highlight s4504kr kaya s4504kr lightning s4504kr subcommander salimma evolution-remove-duplicates salimma Falcon salimma fbreader salimma ikarus salimma rubberband salimma sonic-visualiser salimma spicctrl salimma vala salimma vamp-plugin-sdk sdake corosync sdake openais seg openjpeg seg rosegarden4 sharkcz mm3d sharkcz openhpi sharkcz qlandkartegt sharkcz tinyerp silfreed qgis sindrepb cowbell sindrepb firewalk sindrepb gnome-do sindrepb xdotool skvidal yum snirkel adplay snirkel adplug southa adanaxisgpl splinux gnome-specimen splinux gnubiff spot amanith spot gambas spot libpaper spot librx spot logjam spot perl-HTTP-Proxy spot perl-IPC-Shareable spot PyAmanith spot ql2400-firmware spot SimGear spot srecord spot taglib-sharp spot tiresias-fonts ssp libXfontcache ssp libXp ssp libXTrap stefan synopsis steve celestia steved nfs4-acl-tools steve perl-Sys-Virt steve supertux subhodip kdetv svahl konq-plugins tagoh imsettings tagoh sazanami-fonts tagoh scim-anthy tagoh uim tbzatek eel2 tbzatek gvfs tejas kopete-bonjour terjeros gle tgl libjpeg tgl mysql tgl unixODBC than kdebase-workspace than kdeedu than kdegames than kdenetwork than kdepim than kdesdk than kdevelop than PolicyKit-kde than qt thias blackbox thias gcombust thias hercules thias i8kutils thias torcs thias yasm thl enigma thm monotone thm stk thomasvs ladspa tibbs xu4 till fcgi till iasl till lzip till pam_mount timfenn clipper timn player tmraz cyrus-sasl tmraz openssl tnorth avr-binutils trondd libopenraw tscherf Miro tuju dfu-util tuxbrewr kpackagekit tuxbrewr spicebird twaugh portreserve twoerner iptables uwog gtkmathview varekova gmp vcrhonek expect vcrhonek tog-pegasus vcrhonek ypbind veillard ekiga veillard opal veplaini olpcsound victorv ini4j vlg libassa vpv openoffice.org-voikko vpv tmispell-voikko wart atlascpp wart cyphesis wart eris wart manaworld wart neverball wart sear wart skstream wart spr wart tklib wart wormux wart yadex wtogami pidgin wtogami scponly xavierb perl-WWW-Search xgl-maint xorg-x11-drv-acecad xgl-maint xorg-x11-drv-aiptek xgl-maint xorg-x11-drv-ark xgl-maint xorg-x11-drv-calcomp xgl-maint xorg-x11-drv-citron xgl-maint xorg-x11-drv-digitaledge xgl-maint xorg-x11-drv-dmc xgl-maint xorg-x11-drv-dummy xgl-maint xorg-x11-drv-dynapro xgl-maint xorg-x11-drv-fpit xgl-maint xorg-x11-drv-geode xgl-maint xorg-x11-drv-hyperpen xgl-maint xorg-x11-drv-jamstudio xgl-maint xorg-x11-drv-magellan xgl-maint xorg-x11-drv-microtouch xgl-maint xorg-x11-drv-neomagic xgl-maint xorg-x11-drv-palmax xgl-maint xorg-x11-drv-penmount xgl-maint xorg-x11-drv-rendition xgl-maint xorg-x11-drv-s3 xgl-maint xorg-x11-drv-siliconmotion xgl-maint xorg-x11-drv-sisusb xgl-maint xorg-x11-drv-spaceorb xgl-maint xorg-x11-drv-summa xgl-maint xorg-x11-drv-tek4957 xgl-maint xorg-x11-drv-ur98 xgl-maint xorg-x11-drv-void xgl-maint xorg-x11-drv-voodoo xgl-maint xorg-x11-server xris orpie xulchris poker3d zkota python-bibtex zprikryl apmd CU knurd From james at fedoraproject.org Tue Feb 3 19:03:57 2009 From: james at fedoraproject.org (James Antill) Date: Tue, 03 Feb 2009 14:03:57 -0500 Subject: Too many unowned directories In-Reply-To: <1233685367.3238.15.camel@rosebud> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090130211536.b7aa63d9.mschwendt@gmail.com> <1233350530.3650.28.camel@localhost.localdomain> <1233350803.3345.18.camel@localhost.localdomain> <1233685292.28200.137.camel@code.and.org> <1233685367.3238.15.camel@rosebud> Message-ID: <1233687837.28200.143.camel@code.and.org> On Tue, 2009-02-03 at 13:22 -0500, seth vidal wrote: > On Tue, 2009-02-03 at 13:21 -0500, James Antill wrote: > > On Sat, 2009-01-31 at 00:36 +0200, Panu Matilainen wrote: > > > On Fri, 30 Jan 2009, Miloslav Trma? wrote: > > > > > > > Jesse Keating p??e v P? 30. 01. 2009 v 13:22 -0800: > > > >> Why not fail the build if unowned directories are found, just like we do > > > >> for unowned files? That way you catch it at build time before you try > > > >> and do something useful with the build. > > > > How do we determine which directory is unowned and which is provided by > > > > a dependency? If we don't, every package would have to own /usr. > > > > > > It'd be possible to turn the topmost unowned directory into a file (well, > > > directory) dependency. Either at build time, which would cause a big pile > > > of new file dependencies in the metadata, or rpm could generate them at > > > runtime. The problem with runtime generated dependencies is just that yum > > > & the like wouldn't be able to resolve them without fairly big changes. > > > > It'd be painful to have everything have a "Requires: /usr" (or > > whatever) as it would make filelists mandatory for every update ... but > > it would just work, with yum. > > Not that I'd suggest this but we _could_ add dirs to the primary > filelist.... I'm not sure that'd work well as you can't tell from just the path whether it's a file or a dir. Much better to have something like dir(/usr) provides/requires, this should then also work with apt-rpm/smart/whatever. But that could be stage2, if we wanted to try it ... it still might bloat the primary a bit, but maybe not much. -- James Antill - james at fedoraproject.org "I'd just like to see a realistic approach to updates via packages." -- Les Mikesell From dimi at lattica.com Tue Feb 3 19:06:26 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 14:06:26 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203185104.GA2631@nostromo.devel.redhat.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <20090203185104.GA2631@nostromo.devel.redhat.com> Message-ID: <1233687986.8745.408.camel@dimi.lattica.com> On Tue, 2009-02-03 at 13:51 -0500, Bill Nottingham wrote: > > - the 2W savings is only on a patched radeon driver, AIUI > (although it could theoretically be ported to other drivers This is great news! The user will now get different experience depending on what graphic card they use! Folks, this borders insanity. If we do that, it has to be as a _system_ setting that affects all drivers equally. This is like turning off flush only on a Seagate Barracuda 7200.9 because it saves 1W for those drives. This way lies madness. -- Dimi Paun Lattica, Inc. From rawhide at fedoraproject.org Tue Feb 3 19:07:20 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 3 Feb 2009 19:07:20 +0000 (UTC) Subject: rawhide report: 20090203 changes Message-ID: <20090203190720.789F01F82DD@releng2.fedora.phx.redhat.com> Compose started at Tue Feb 3 16:17:04 UTC 2009 New package celt An audio codec for use in low-delay speech and audio communication New package eclipse-cmakeed CMake Editor plug-in for Eclipse New package giver A simple file sharing desktop application New package gsql Integrated database development tool for GNOME New package hatools Improved shell scripting in High Availability environment New package libhildon Hildon Application Framework - shared libraries New package mythes-pt Portuguese thesaurus New package perl-MooseX-Iterator Iterate over collections New package perl-MooseX-Param Simple role to provide a standard param method New package perl-Net-Stomp Stomp client module for Perl New package perl-PerlIO-gzip Perl extension to provide a PerlIO layer to gzip/gunzip New package perl-Test-TempDir Temporary files support for testing New package php-pecl-imagick Provides a wrapper to the ImageMagick library New package python-setupdocs Setuptools plugin New package sil-gentium-basic-fonts Gentium Basic Font Family from SIL New package stardict-dic-hi Hindi dictionary for stardict New package thai-scalable-fonts Thai TrueType fonts Removed package thaifonts-scalable Updated Packages: DeviceKit-power-005-1.fc11 -------------------------- * Mon Feb 2 17:00:00 2009 Richard Hughes 005-1 - Update to 005 OpenEXR_CTL-1.0.1-5.fc11 ------------------------ * Tue Feb 3 17:00:00 2009 kwizart < kwizart at gmail.com > - 1.0.1-5 - Own %libdir/CTL - Fix #473596 PackageKit-0.4.3-1.fc11 ----------------------- * Mon Feb 2 17:00:00 2009 Richard Hughes - 0.4.3-1 - New upstream version - Mainly bugfixes alacarte-0.11.8-1.fc11 ---------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 0.11.8-1 - Update to 0.11.8 aqsis-1.4.2-2.fc11 ------------------ * Tue Jan 27 17:00:00 2009 kwizart < kwizart at gmail.com > - 1.4.2-1 - Update to 1.4.2 * Tue Feb 3 17:00:00 2009 kwizart < kwizart at gmail.com > - 1.4.2-2 - Backport piqsl problem with libtiff - Fix unappropriate use of xdg-tools #481352 audacity-1.3.5-0.12.beta.fc11 ----------------------------- * Fri Jan 2 17:00:00 2009 David Timms - 1.3.5-0.11.beta - add PortAudio non mmap alsa patch (Kevin Kofler) bz 445644 allows record and playback through pulseaudio * Mon Feb 2 17:00:00 2009 Michael Schwendt - 1.3.5-0.12.beta - buildrequire >= 2.0 of Vamp SDK (because we adjust the include paths and to avoid that the unpatched local copy is used if system version is too old) baekmuk-ttf-fonts-2.2-19.fc11 ----------------------------- * Tue Feb 3 17:00:00 2009 Caius Chance - 2.2-19.fc11 - Resolves: rhbz#483327 - Reowned font directory by subpackage -common. - Splited ghostscript files to subpackage -ghostscript. - Updated paths in ghostscript files. binutils-2.19.50.0.1-11.fc11 ---------------------------- * Mon Feb 2 17:00:00 2009 Jan Kratochvil 2.19.50.0.1-11 - Fix .eh_frame_hdr build also for .gcc_except_table LSDA refs (BZ 461675). bluez-4.28-1.fc11 ----------------- * Mon Feb 2 17:00:00 2009 - Bastien Nocera - 4.28-1 - Update to 4.28 bodhi-0.5.17-2.fc11 ------------------- * Mon Feb 2 17:00:00 2009 Toshio Kuratomi - 0.5.17-2 - Own the %{_sysconfdir}/bodhi directory. bugzilla-3.0.4-3.fc11 --------------------- * Mon Feb 2 17:00:00 2009 Stepan Kasal - 3.0.4-3 - do not require perl-Email-Simple, it is (no longer) in use - remove several explicit perl-* requires; the automatic dependencies do handle them cachefilesd-0.9-1.fc11 ---------------------- * Fri Jan 9 17:00:00 2009 Steve Dickson 0.9-1 - Upgraded to latest upstream version: 0.9 cjkuni-fonts-0.2.20080216.1-20.fc11 ----------------------------------- * Tue Feb 3 17:00:00 2009 Caius Chance - 0.2.20080216.1-19.fc11 - Resolves: rhbz#459680 - Disabled antialias when pixelsize is smaller than 17. * Tue Feb 3 17:00:00 2009 Caius Chance - 0.2.20080216.1-20.fc11 - Resolves: rhbz#483329 - Reowned font directory by -common subpackage. - Updated font paths in ghostscript files. cluster-3.0.0-5.alpha4.fc11 --------------------------- * Sat Jan 31 17:00:00 2009 Fabio M. Di Nitto - 3.0.0-5.alpha4 - New upstream release. - Fix directory ownership #483330. - Add support pkgconfig to devel package. - Total libraries cleanup: - split libraries out of cman into clusterlib. - merge cmanlib into clusterlib. - rename cman-devel into clusterlib-devel. - merge cmanlib-devel into clusterlib-devel. - Comply with multiarch requirements (libraries). - Relax BuildRequires and Requires around corosync and openais. clustermon-0.15.0-8.fc11 ------------------------ * Tue Feb 3 17:00:00 2009 Fabio M. Di Nitto 0.15.0-8 - Merge sparc support patch from F10 branch. - BuildRequires clusterlib-devel instead of cmanlib-devel. corosync-0.92-7.svn1756.fc11 ---------------------------- * Mon Feb 2 17:00:00 2009 Fabio M. Di Nitto - 0.92-7.svn1756 - Update to svn trunk at revision 1756 from upstream. - Add support pkgconfig to devel package. - Tidy up spec files by re-organazing sections according to packages. - Split libraries from corosync to corosynclib. - Rename corosync-devel to corosynclib-devel. - Comply with multiarch requirements (libraries). createrepo-0.9.6-9.fc11 ----------------------- * Mon Feb 2 17:00:00 2009 Seth Vidal - 0.9.6-7 - add deltarpm requirement for making presto metadata * Tue Feb 3 17:00:00 2009 Seth Vidal - 0.9.6-9 - fix normal createrepo'ing w/o the presto patches :( cyrus-imapd-2.3.13-3.fc11 ------------------------- * Mon Feb 2 17:00:00 2009 Michal Hlavinka - 2.3.13-3 - fix directory ownership dbus-c++-0.5.0-0.4.20090203git13281b3.fc11 ------------------------------------------ * Tue Feb 3 17:00:00 2009 Adel Gadllah - 0.5.0-0.4.20090203git13281b3 - Update to new git snapshot - Should fix RH #483418 dbus-glib-0.80-1.fc11 --------------------- * Mon Feb 2 17:00:00 2009 Colin Walters - 0.80-1 - New upstream release - Adjust to new bash completion dir - Includes patch noreply patch denemo-0.8.2-1.fc11 ------------------- * Tue Feb 3 17:00:00 2009 Roy Rankin - 0.8.2-1 -Update for Denemo release 0.8.2 improve MIDI input more scripting support better menu organization -Spec file fix unowned directories (Bugzilla 483337) dia-0.96.1-13.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Huzaifa Sidhpurwala 1:0.96.1-13 - Resolves: rhbz#483312 docbook-style-xsl-1.74.0-6.fc11 ------------------------------- * Mon Feb 2 17:00:00 2009 Ondrej Vasik 1.74.0-6 - fix improper localization for rtl languages, thanks Muayyad Alsadi(#475077) docbook5-schemas-5.0-2.fc11 --------------------------- * Mon Feb 2 17:00:00 2009 Ondrej Vasik 5.0-2 - do own /usr/share/xml/docbook5 properly(#483341) ecryptfs-utils-69-4.fc11 ------------------------ * Mon Feb 2 17:00:00 2009 Michal Hlavinka 69-4 - fix list of onwed directories eigen2-2.0.0-1.fc11 ------------------- * Mon Feb 2 17:00:00 2009 Rex Dieter 2.0-1 - eigen-2.0.0 (final) evolution-2.25.90-1.fc11 ------------------------ * Mon Feb 2 17:00:00 2009 Matthew Barnes - 2.25.90-1.fc11 - Update to 2.25.90 evolution-data-server-2.25.90-2.fc11 ------------------------------------ * Mon Feb 2 17:00:00 2009 Matthew Barnes - 2.25.90-1.fc11 - Update to 2.25.90 - Add libical build requirement. * Mon Feb 2 17:00:00 2009 Matthew Barnes - 2.25.90-2.fc11 - Forgot the libical requirement in devel subpackage. file-roller-2.25.90-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 filezilla-3.2.1-0.1_rc1.fc11 ---------------------------- * Tue Feb 3 17:00:00 2009 kwizart < kwizart at gmail.com > - 3.2.1-0.1_rc1 - Update to 3.2.1-rc1 flow-tools-0.68.4.1-1.fc11 -------------------------- * Mon Feb 2 17:00:00 2009 Paul P Komkoff Jr - 0.68.4.1-1 - fix for pcap generation, by Dave Plonka - split out -rrdtool subpackage, for those who don't need rrdtool on their servers. gcalctool-5.25.90-1.fc11 ------------------------ * Tue Feb 3 17:00:00 2009 Matthias Clasen - 5.25.90-1 - Update to 5.25.90 gdal-1.6.0-3.fc11 ----------------- * Thu Jan 29 17:00:00 2009 Balint Cristian - 1.6.0-2 - email change - rebuild without grass * Thu Jan 29 17:00:00 2009 Balint Cristian - 1.6.0-3 - rebuild against mysql 5.1.30 gedit-2.25.6-1.fc11 ------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 1:2.25.6-1 - Update to 2.25.6 glib2-2.19.6-1.fc11 ------------------- * Mon Feb 2 17:00:00 2009 Matthias Clasen - 2.19.6-1 - Update to 2.19.6 gnome-doc-utils-0.15.1-2.fc11 ----------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 0.15.1-2 - Update to 0.15.1 gnome-games-2.25.90-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 1:2.25.90-1 - Update to 2.25.90 gnome-keyring-2.25.90-4.fc11 ---------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-4 - Update to 2.25.90 gnome-packagekit-0.4.3-1.fc11 ----------------------------- gnome-power-manager-2.25.3-1.fc11 --------------------------------- * Mon Feb 2 17:00:00 2009 Richard Hughes - 2.25.3-1 - Update to 2.25.3 - New processor wakeup functionality in gnome-power-statistics gnome-speech-0.4.23-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 0.4.23-1 - Update to 0.4.23 gnome-themes-2.25.90-1.fc11 --------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 gnome-user-share-2.25.90-1.fc11 ------------------------------- * Tue Feb 3 17:00:00 2009 - Bastien Nocera - 2.25.90-1 - Update to 2.25.90 gnome-utils-2.25.90-2.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 1:2.25.90-2 - Update to 2.25.90 gpsdrive-2.09-7.fc11 -------------------- * Mon Feb 2 17:00:00 2009 Kevin Fenzi - 2.09-7 - fix for CVE-2008-4959 - bug 470241 - fix for CVE-2008-5380 - bug 475478 - fix for CVE-2008-5703 - bug 481702 gstreamer-plugins-good-0.10.13-2.fc11 ------------------------------------- * Mon Feb 2 17:00:00 2009 - Bastien Nocera - 0.10.13-2 - Patch for overflows in the QT demuxer (#481267) gtk2-2.15.3-1.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Matthias Clasen - 2.15.3-1 - Update to 2.15.3 gtkhtml3-3.25.90-1.fc11 ----------------------- * Mon Feb 2 17:00:00 2009 Matthew Barnes - 3.25.90-1.fc11 - Update to 3.25.90 gtksourceview2-2.5.4-1.fc11 --------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.5.4-1 - Update to 2.5.4 gtkwave-3.2.0-0.2.RC5.fc11 -------------------------- * Mon Feb 2 17:00:00 2009 Paul Howarth 3.2.0-0.2.RC5 - update to 3.2.0RC5 gupnp-av-0.3.1-1.fc11 --------------------- * Tue Feb 3 17:00:00 2009 Peter Robinson 0.3.1-1 - New upstream release gvfs-1.1.5-1.fc11 ----------------- * Mon Feb 2 17:00:00 2009 Tomas Bzatek - 1.1.5-1 - Update to 1.1.5 hal-info-20090202-1.fc11 ------------------------ * Mon Feb 2 17:00:00 2009 Richard Hughes - 20090202-1 - Update to latest upstream release ibus-0.1.1.20090203-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Huang Peng - 0.1.1.20090203-1 - Update to 0.1.1.20090203. ibus-anthy-0.1.1.20090203-1.fc11 -------------------------------- * Tue Feb 3 17:00:00 2009 Huang Peng - 0.1.1.20090203-1 - Update to 0.1.1.20090203. imlib2-1.4.2-3.fc11 ------------------- * Tue Feb 3 17:00:00 2009 Tomas Smetana 1.4.2-3 - fix #477400 - remove fonts - remove demo programs and images iprutils-2.2.13-2.fc11 ---------------------- * Mon Feb 2 17:00:00 2009 Will Woods - 2.2.13-2 - Fix iprdump startup - #483340 - iprutils-swab-moved.patch - fix compilation with 2.6.29 kernels (#483643) iso-codes-3.6-1.fc11 -------------------- * Mon Feb 2 17:00:00 2009 Christopher Aillon - 3.6-1 - Update to 3.6 jabberd-2.2.5-1.fc11 -------------------- * Tue Feb 3 17:00:00 2009 Adrian Reber - 2.2.5-1 - updated to 2.2.5 java-1.6.0-openjdk-1.6.0.0-10.b14.fc11 -------------------------------------- * Sun Jan 11 17:00:00 2009 Lillian Angel - 1:1.6.0-9.b14 - Removed README.plugin, updated source list. - Updated release. * Thu Jan 22 17:00:00 2009 Lillian Angel - 1:1.6.0-10.b14 - Updated to icedtea-1.4 snapshot. - Updated release. - Removed netbeans and visualvm. - Resolves: rhbz#472953 - Resolves: rhbz#475081 - Resolves: rhbz#452573 - Resolves: rhbz#477351 - Resolves: rhbz#475109 - Resolves: rhbz#476462 * Fri Jan 23 17:00:00 2009 Lillian Angel - 1:1.6.0-10.b14 - Added accessibility patch. * Mon Jan 26 17:00:00 2009 Lillian Angel - 1:1.6.0-10.b14 - Updated sources. jd-2.2.0-0.3.svn2645_trunk.fc11 ------------------------------- * Tue Feb 3 17:00:00 2009 Mamoru Tasaka - rev 2645 jetty-5.1.14-1.8.fc11 --------------------- * Mon Feb 2 17:00:00 2009 Jeff Johnston 5.1.14-1.8 - Resolves #473585 joe-3.7-1.fc11 -------------- * Tue Feb 3 17:00:00 2009 Ivana Varekova - 3.7-1 - update to 3.7 kdebase-runtime-4.2.0-4.fc11 ---------------------------- * Mon Feb 2 17:00:00 2009 Rex Dieter - 4.2.0-4 - own %_kde4_datadir/locale/l10n/ kdesvn-1.2.3-1.fc11 ------------------- * Tue Jan 27 17:00:00 2009 - Orion Poplawski - 1.2.3-1 - Update to 1.2.3 libX11-1.1.99.2-3.fc11 ---------------------- * Mon Feb 2 17:00:00 2009 Caol??n McNamara 1.1.99.2-3 - Resolves: rhbz#477174 don't hang in OOo, acroread, ekiga, xine, etc. libnotifymm-0.6.1-5.fc11 ------------------------ * Mon Feb 2 17:00:00 2009 Denis Leroy - 0.6.1-5 - Fixed unowned directory issue (#483467) libsmbios-2.2.12-1.fc11 ----------------------- * Mon Feb 2 17:00:00 2009 Michael E Brown - 2.2.12-1 - Add pkgconfig files to -devel - fixup yum plugin to not parse certain data that causes a crash on some machines (Optiplex 755, others may be affected) libsoup-2.25.5-1.fc11 --------------------- * Mon Feb 2 17:00:00 2009 Matthew Barnes - 2.25.5-1 - Update to 2.25.5 liveusb-creator-3.5-2.fc11 -------------------------- * Mon Feb 2 17:00:00 2009 Luke Macken 3.5-2 - Require pyparted log4cpp-1.0-2.fc11 ------------------ * Mon Dec 15 17:00:00 2008 Jon McCann - 1.0-1 - Initial package * Mon Feb 2 17:00:00 2009 Tom "spot" Callaway - 1.0-2 - Delete non-free (but freely distributable) snprintf.c under Artistic 1.0 just to be sure we're not using it. logrotate-3.7.8-1.fc11 ---------------------- * Mon Feb 2 17:00:00 2009 Daniel Novotny 3.7.8-1 - new upstream version 3.7.8 lpsolve-5.5.0.14-1.fc11 ----------------------- * Mon Feb 2 17:00:00 2009 Caol??n McNamara - 5.5.0.14-1 - latest version lsscsi-0.22-1.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Dan Hor??k - 0.22-1 - update to 0.22 maxima-5.17.1-4.fc11 -------------------- * Tue Feb 3 17:00:00 2009 Rex Dieter - 5.17.1-4 - respin (sbcl) metacity-2.25.144-1.fc11 ------------------------ * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.144-1 - Update to 2.25.144 mythes-de-0.20090202-1.fc11 --------------------------- * Mon Feb 2 17:00:00 2009 Caolan McNamara - 0.20090202-1 - latest version mythes-sk-0.20090202-1.fc11 --------------------------- * Tue Feb 3 17:00:00 2009 Caolan McNamara - 0.20090202-1 - latest version nautilus-2.25.4-1.fc11 ---------------------- * Mon Feb 2 17:00:00 2009 Tomas Bzatek - 2.25.4-1 - Update to 2.25.4 ncl-5.0.0-18.fc11 ----------------- * Mon Feb 2 17:00:00 2009 - Orion Poplawski - 5.0.0-18 - Fix unowned directory (bug #483468) nrpe-2.12-6.fc11 ---------------- * Mon Feb 2 17:00:00 2009 Peter Lemenkov - 2.12-6 - Fixed BZ# 449174 - Clean up (in order to disable rpmlint warnings) opal-3.5.2-5.fc11 ----------------- * Mon Feb 2 17:00:00 2009 Peter Robinson - 3.5.2-5 - Fix blank soname openais-0.91-6.svn1688.fc11 --------------------------- * Mon Feb 2 17:00:00 2009 Fabio M. Di Nitto - 0.91-6.svn1688 - Update to svn trunk at revision 1688 from upstream. - Add support pkgconfig to devel package. - Update BuildRequires: on corosynclib-devel. - Tidy up spec files by re-organazing sections according to packages. - Split libraries from openais to openaislib. - Rename openais-devel to openaislib-devel. - Comply with multiarch requirements (libraries). openssl-0.9.8j-7.fc11 --------------------- * Mon Feb 2 17:00:00 2009 Tomas Mraz 0.9.8j-7 - must also verify checksum of libssl.so in the FIPS mode - obtain the seed for FIPS rng directly from the kernel device - drop the temporary symlinks orca-2.25.90-1.fc11 ------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 perl-BDB-1.83-1.fc11 -------------------- * Tue Feb 3 17:00:00 2009 kwizart < kwizart at gmail.com > - 1.83-1 - Update to 1.83 perl-Email-Simple-2.005-1.fc11 ------------------------------ * Mon Feb 2 17:00:00 2009 Ralf Cors??pius - 2.005-1 - Upstream update. perl-GD-SVG-0.32-1.fc11 ----------------------- * Mon Feb 2 17:00:00 2009 Alex Lancaster - 0.32-1 - Update to upstream 0.32 perl-Graph-0.91-1.fc11 ---------------------- * Mon Feb 2 17:00:00 2009 Alex Lancaster - 0.91-1 - Update to upstream 0.91 perl-MooseX-LogDispatch-1.2000-2.fc11 ------------------------------------- * Mon Feb 2 17:00:00 2009 Allisson Azevedo 1.2000-2 - Added filter requires. - Added provides. perl-Net-SSH-Perl-1.34-1.fc11 ----------------------------- * Mon Feb 2 17:00:00 2009 Paul Howarth 1.34-1 - Update to 1.34, fixes various upstream bugs: * Rekey properly after 1 GB of data (rt.cpan.org #25044) * Don't try to process nonexistent or empty auth file (rt.cpan.org #41877) * Fix typo in croak message (rt.cpan.org #42056) * Move 'use base' call after Crypt module loading (rt.cpan.org #42051) * Only apply stdin if defined in SSH1 (rt.cpan.org #42583) perl-PAR-Dist-0.43-1.fc11 ------------------------- * Mon Feb 2 17:00:00 2009 Steven Pritchard 0.43-1 - Update to 0.43. - Explicitly require Archive::Zip and YAML::Tiny. perl-Parse-CPAN-Packages-2.30-1.fc11 ------------------------------------ * Mon Feb 2 17:00:00 2009 Steven Pritchard 2.30-1 - Update to 2.30. - BR Compress::Zlib, Moose, Test::Pod, and Test::Pod::Coverage. - Drop BR Class::Accessor::Fast, IO::Zlib, and Sort::Versions. perl-Parse-RecDescent-1.96-1.fc11 --------------------------------- * Mon Feb 2 17:00:00 2009 Stepan Kasal - 1.96-1 - new upstream version perl-SVG-2.49-1.fc11 -------------------- * Mon Feb 2 17:00:00 2009 Alex Lancaster - 2.49-1 - Update to upstream 2.49 perl-Spreadsheet-ParseExcel-0.4900-1.fc11 ----------------------------------------- * Mon Feb 2 17:00:00 2009 Steven Pritchard 0.4900-1 - Update to 0.49. perl-XML-Writer-0.606-1.fc11 ---------------------------- * Mon Feb 2 17:00:00 2009 Alex Lancaster - 0.606-1 - Update to upstream 0.606 - Clarify license is MIT perl-bioperl-run-1.5.9-0.1.1.fc11 --------------------------------- * Tue Feb 3 17:00:00 2009 Alex Lancaster - 1.5.9-0.1.1 - Update to release candidate 1 for 1.6.0 - Remove examples subdirectory, no longer distributed - Deprecated modules no longer need removing - Add BR: perl(IPC::Run) pkgconfig-0.23-7.fc11 --------------------- * Mon Feb 2 17:00:00 2009 Matthias Clasen - 1:0.23-7 - Add an explict pkgconfig provides (#476199) procps-3.2.7-24.fc11 -------------------- * Tue Feb 3 17:00:00 2009 Daniel Novotny 3.2.7-24 - slabtop -o should display the info once and then exit (RHEL bug #475963) - added timestamp to vmstat with new option -t (#476134) python-pyblock-0.34-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Hans de Goede - 0.34-1 - Add functions that relate dm nodes and dm names (jgranados) - Make dmraid devices recursive (fixes dmraid 10 / 01) (jgranados) - When importing dm from C-code import it as block.dm, this fixes pyblock not working with python 2.6 (hansg) python-simpy-2.0-1.fc11 ----------------------- * Tue Feb 3 17:00:00 2009 Sarantis Paskalis - 2.0-1 - Upgrade to 2.0 qpidc-0.4.738618-2.fc11 ----------------------- * Wed Jan 28 17:00:00 2009 Nuno Santos - 0.4.738618-2 - Rebased to svn rev 738618 qt-4.4.3-15.fc11 ---------------- * Mon Feb 2 17:00:00 2009 Than Ngo 4.4.3-15 - disable 0269,0270,0271 patches, it causes issue in systray qt3-3.3.8b-20.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Rex Dieter 3.3.8b-20 - unowned dirs (#483441) radvd-1.1-6.fc11 ---------------- * Mon Feb 2 17:00:00 2009 Jiri Skala - 1.1-6 - init script modified to be POSIX compliant rhm-0.4.3088-1.fc11 ------------------- * Mon Feb 2 17:00:00 2009 Nuno Santos - 0.4.3088-1 - Rebased to svn rev 3088/738618 samyak-fonts-1.2.1-3.fc11 ------------------------- * Tue Feb 3 17:00:00 2009 Pravin Satpute 1.2.1-3 - renamed font package as per fedora new Font_package_naming guideline - updated spec sbcl-1.0.25-1.fc11 ------------------ * Tue Feb 3 17:00:00 2009 Rex Dieter - 1.0.25-1 - sbcl-1.0.25 setup-2.7.7-4.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Ondrej Vasik 2.7.7-4 - drop scriptlet completely(audio/video group temporarily created by packages which use it for updates(#477769)) spamass-milter-0.3.1-9.fc11 --------------------------- * Thu Jul 3 18:00:00 2008 Paul Howarth 0.3.1-9 - Require /usr/sbin/sendmail (for -b/-B/-x options) rather than sendmail pkg - Make summary and description less Sendmail-specific - Add patch to support group-writable socket for MTA communication, needed to be able to use a Unix-domain socket with Postfix (#452248) - Add subpackage with group-writable directory for Postfix support - Tweak initscript to change default options when Postfix socket directory is present - Document additional ENVRCPT macros to provide strigi-0.6.4-1.fc11 ------------------- * Mon Feb 2 17:00:00 2009 Rex Dieter - 0.6.4-1 - strigi-0.6.4 - Summary: s/for KDE// - *.desktop: validate, remove OnlyShowIn=KDE - -devel: move *.cmake here subversion-api-docs-1.5.5-1.fc11 -------------------------------- * Tue Feb 3 17:00:00 2009 Bojan Smojver 1.5.5-1 - bump up to 1.5.5 superiotool-0-0.15.20090202svn3827.fc11 --------------------------------------- * Mon Oct 6 18:00:00 2008 Peter Lemenkov 0-0.13.20080815svn3511 - More ExcludeArch * Mon Nov 3 17:00:00 2008 Peter Lemenkov 0-0.14.20081103svn3698 - Support for the ITE IT8661F/IT8770F, IT8673F, and IT8671F/IT8687R - Add register definitions for W83627HF - Drop global register 0x07 for all Super I/Os - Add dump support to ITE IT8726F - Add Fintek F71882FG support - Add some more Super I/O IDs/names * Mon Feb 2 17:00:00 2009 Peter Lemenkov 0-0.15.20090202svn3827 - Added register map based on NSC PC87392 datasheet. - Add detection support for ITE IT8228E, IT8711F, IT8722F, IT8761E, IT8780F, and Fintek F71863FG. system-config-netboot-0.1.45.4-4.fc11 ------------------------------------- * Tue Feb 3 17:00:00 2009 Jaroslav Reznik - 0.1.45.4-4 - duplicate files - gtk-update-icon-cache scriptlet - buildroot updated to guidelines system-config-printer-1.1.3-1.fc11 ---------------------------------- * Tue Feb 3 17:00:00 2009 Tim Waugh 1.1.3-1 - Requires python-sexy. - 1.1.3. telepathy-gabble-0.7.20-1.fc11 ------------------------------ * Mon Feb 2 17:00:00 2009 Brian Pepple - 0.7.20-1 - Update to 0.7.20. tog-pegasus-2.7.2-4.fc11 ------------------------ * Mon Feb 2 17:00:00 2009 Dennis Gilmore < dennis at ausil.us> - 2:2.7.2-4 - apply sparc fixes totem-pl-parser-2.25.1-3.fc11 ----------------------------- * Tue Feb 3 17:00:00 2009 - Bastien Nocera - 2.25.1-3 - Rebuild for new libcamel translate-toolkit-1.3.0-0.2.rc1.fc11 ------------------------------------ * Tue Feb 3 17:00:00 2009 Dwayne Bailey - 1.3.0-0.2.rc1 - Update to 1.3.0 rc1 twinkle-1.4.1-1.fc11 -------------------- * Mon Feb 2 17:00:00 2009 Kevin Fenzi - 1.4.1-1 - Update to 1.4.1 vinagre-2.25.90-1.fc11 ---------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 vino-2.25.90-1.fc11 ------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 virtaal-0.3-0.2.rc1.fc11 ------------------------ * Tue Feb 3 17:00:00 2009 Dwayne Bailey - 0.3-0.2.rc1 - Update for 0.3-rc1 - Remove version patch vollkorn-fonts-1.008-2.fc11 --------------------------- * Mon Feb 2 17:00:00 2009 Paul Lange - 1.008-2 move vollkorn.otf file out of the cvs repo waf-1.5.3-1.fc11 ---------------- * Mon Feb 2 17:00:00 2009 Thomas Moschny - 1.5.3-1 - Update to 1.5.3, which contains various enhancements and bugfixes, see http://waf.googlecode.com/svn/trunk/ChangeLog for a list of changes. xen-3.3.1-3.fc11 ---------------- * Tue Feb 3 17:00:00 2009 Gerd Hoffmann - 3.3.1-3 - backport bzImage support for dom0 builder. xmoto-0.5.0-5.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Jon Ciesla 0.5.0-5 - Fix for ati crash, BZ 481485. xorg-x11-drv-synaptics-1.0.0-2.fc11 ----------------------------------- xorg-x11-server-1.5.99.902-1.fc11 --------------------------------- * Tue Feb 3 17:00:00 2009 Peter Hutterer 1.5.99.902-1 - xserver 1.6. RC 2 xscreensaver-5.08-7.fc11 ------------------------ * Mon Feb 2 17:00:00 2009 Mamoru Tasaka - 1:5.08-7 - Remove OnlyShowIn=GNOME on F-11+ (to make happy with XFCE): bug 483495 - Add more comments about bug reference Summary: Added Packages: 17 Removed Packages: 1 Modified Packages: 131 Broken deps for i386 ---------------------------------------------------------- OpenEXR_CTL-devel-1.0.1-5.fc11.i386 requires pkgconfig(CTL) elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.i386 requires libcamel-1.2.so.13 evolution-exchange-2.25.5-1.fc11.i386 requires libcamel-1.2.so.13 evolution-exchange-2.25.5-1.fc11.i386 requires libcamel-provider-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.i386 requires libcamel-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.i386 requires libcamel-provider-1.2.so.13 gnubiff-2.2.10-1.fc11.i386 requires libssl.so.7 gnubiff-2.2.10-1.fc11.i386 requires libcrypto.so.7 1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.i386 requires libcrypto.so.7 grass-6.3.0-9.fc11.i386 requires libssl.so.7 grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15 ifstat-1.1-8.fc10.i386 requires libcrypto.so.7 ldns-1.4.0-1.fc11.i386 requires libcrypto.so.7 libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0 linkage-0.2.0-4.fc11.i386 requires libcrypto.so.7 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 mail-notification-evolution-plugin-5.4-8.fc11.i386 requires libcamel-1.2.so.13 mail-notification-evolution-plugin-5.4-8.fc11.i386 requires libcamel-provider-1.2.so.13 mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.i386 requires libssl.so.7 mediatomb-0.11.0-4.fc11.i386 requires libcrypto.so.7 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.i386 requires thaifonts-scalable 1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 planner-eds-0.14.3-8.fc11.i386 requires libcamel-1.2.so.13 planner-eds-0.14.3-8.fc11.i386 requires libcamel-provider-1.2.so.13 python-gammu-0.28-1.fc11.i386 requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so sepostgresql-8.3.5-2.1183.fc10.i386 requires libssl.so.7 sepostgresql-8.3.5-2.1183.fc10.i386 requires libcrypto.so.7 tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.i386 requires libcrypto.so.7 Broken deps for x86_64 ---------------------------------------------------------- OpenEXR_CTL-devel-1.0.1-5.fc11.i386 requires pkgconfig(CTL) OpenEXR_CTL-devel-1.0.1-5.fc11.x86_64 requires pkgconfig(CTL) elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.i386 requires libcamel-1.2.so.13 evolution-brutus-1.2.34-1.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) gnubiff-2.2.10-1.fc11.x86_64 requires libssl.so.7()(64bit) gnubiff-2.2.10-1.fc11.x86_64 requires libcrypto.so.7()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.x86_64 requires libssl.so.7()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) grass-6.3.0-9.fc11.x86_64 requires libcrypto.so.7()(64bit) ifstat-1.1-8.fc10.x86_64 requires libcrypto.so.7()(64bit) ldns-1.4.0-1.fc11.i386 requires libcrypto.so.7 ldns-1.4.0-1.fc11.x86_64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.i386 requires libcrypto.so.7 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.x86_64 requires libcrypto.so.7()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libssl.so.7()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libcrypto.so.7()(64bit) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.x86_64 requires thaifonts-scalable 1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) planner-eds-0.14.3-8.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) planner-eds-0.14.3-8.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) sepostgresql-8.3.5-2.1183.fc10.x86_64 requires libssl.so.7()(64bit) sepostgresql-8.3.5-2.1183.fc10.x86_64 requires libcrypto.so.7()(64bit) tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.x86_64 requires libcrypto.so.7()(64bit) Broken deps for ppc ---------------------------------------------------------- OpenEXR_CTL-devel-1.0.1-5.fc11.ppc requires pkgconfig(CTL) OpenEXR_CTL-devel-1.0.1-5.fc11.ppc64 requires pkgconfig(CTL) db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.ppc requires libcamel-1.2.so.13 evolution-brutus-1.2.34-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.ppc requires libcamel-1.2.so.13 evolution-exchange-2.25.5-1.fc11.ppc requires libcamel-provider-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.ppc requires libcamel-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.ppc requires libcamel-provider-1.2.so.13 gnubiff-2.2.10-1.fc11.ppc requires libssl.so.7 gnubiff-2.2.10-1.fc11.ppc requires libcrypto.so.7 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.ppc requires libcrypto.so.7 grass-6.3.0-9.fc11.ppc requires libssl.so.7 grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15 ifstat-1.1-8.fc10.ppc requires libcrypto.so.7 ldns-1.4.0-1.fc11.ppc requires libcrypto.so.7 ldns-1.4.0-1.fc11.ppc64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0 linkage-0.2.0-4.fc11.ppc requires libcrypto.so.7 linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.ppc requires libcamel-1.2.so.13 mail-notification-evolution-plugin-5.4-8.fc11.ppc requires libcamel-provider-1.2.so.13 mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.ppc requires libssl.so.7 mediatomb-0.11.0-4.fc11.ppc requires libcrypto.so.7 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.ppc requires thaifonts-scalable 1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 planner-eds-0.14.3-8.fc11.ppc requires libcamel-1.2.so.13 planner-eds-0.14.3-8.fc11.ppc requires libcamel-provider-1.2.so.13 python-gammu-0.28-1.fc11.ppc requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so sepostgresql-8.3.5-2.1183.fc10.ppc requires libssl.so.7 sepostgresql-8.3.5-2.1183.fc10.ppc requires libcrypto.so.7 tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.ppc requires libcrypto.so.7 Broken deps for ppc64 ---------------------------------------------------------- OpenEXR_CTL-devel-1.0.1-5.fc11.ppc64 requires pkgconfig(CTL) elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) gnubiff-2.2.10-1.fc11.ppc64 requires libssl.so.7()(64bit) gnubiff-2.2.10-1.fc11.ppc64 requires libcrypto.so.7()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.ppc64 requires libssl.so.7()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) grass-6.3.0-9.fc11.ppc64 requires libcrypto.so.7()(64bit) ifstat-1.1-8.fc10.ppc64 requires libcrypto.so.7()(64bit) ldns-1.4.0-1.fc11.ppc64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libssl.so.7()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.ppc64 requires thaifonts-scalable 1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) planner-eds-0.14.3-8.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) planner-eds-0.14.3-8.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sepostgresql-8.3.5-2.1183.fc10.ppc64 requires libcrypto.so.7()(64bit) sepostgresql-8.3.5-2.1183.fc10.ppc64 requires libssl.so.7()(64bit) tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.ppc64 requires libcrypto.so.7()(64bit) From james at fedoraproject.org Tue Feb 3 19:10:12 2009 From: james at fedoraproject.org (James Antill) Date: Tue, 03 Feb 2009 14:10:12 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203132734.GA5846@mokona.greysector.net> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <20090203132734.GA5846@mokona.greysector.net> Message-ID: <1233688212.28200.146.camel@code.and.org> On Tue, 2009-02-03 at 14:27 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 03 February 2009 at 12:44, Panu Matilainen wrote: > [...] > > Ignore the power savings aspect just for a second. > > > > My television has a power on led below the screen. It blinks when the tv > > is starting up and when the remote control is used, both cases have a very > > clear and sane purpose. It does NOT blink while you're watching the tv, > > and for a good reason too. > > Bad analogy. TV is non-interactive. My TV is connected directly to a PS3 ... analogy win! > So please, change the default if you will, but mention it in the > release notes and give me a way to turn it back on. From the start of this thread it was obviously the intention to just change the default (indeed the subject still implies that). It's not like anyone proposed to rename the option "blinking cursor of death, only turn on if you want to kill the planet". -- James Antill - james at fedoraproject.org "I'd just like to see a realistic approach to updates via packages." -- Les Mikesell From jkeating at redhat.com Tue Feb 3 19:09:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 03 Feb 2009 11:09:17 -0800 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233687986.8745.408.camel@dimi.lattica.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <20090203185104.GA2631@nostromo.devel.redhat.com> <1233687986.8745.408.camel@dimi.lattica.com> Message-ID: <1233688157.7493.81.camel@localhost.localdomain> On Tue, 2009-02-03 at 14:06 -0500, Dimi Paun wrote: > On Tue, 2009-02-03 at 13:51 -0500, Bill Nottingham wrote: > > > > - the 2W savings is only on a patched radeon driver, AIUI > > (although it could theoretically be ported to other drivers > > This is great news! > > The user will now get different experience depending on what > graphic card they use! > > Folks, this borders insanity. If we do that, it has to be > as a _system_ setting that affects all drivers equally. > > This is like turning off flush only on a Seagate Barracuda 7200.9 > because it saves 1W for those drives. > > This way lies madness. > > -- > Dimi Paun > Lattica, Inc. Ahem. The blink would be off everywhere. Only certain drivers will save power due to this at first, more to follow. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Feb 3 19:27:29 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Feb 2009 13:27:29 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <1233685755.14675.5.camel@arekh.okg> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <20090203133223.GB5846@mokona.greysector.net> <1233685755.14675.5.camel@arekh.okg> Message-ID: <1233689249.17218.31.camel@localhost.localdomain> On Tue, 2009-02-03 at 19:29 +0100, Nicolas Mailhot wrote: > Le mardi 03 f?vrier 2009 ? 11:44 -0500, Gregory Maxwell a ?crit : > > > Most easily measured things (rsvg rendering, freetype) probably aren't > > ever performance critical for typical users. > > You're very wrong about any codepath used to display text +1, c'mon, outline font rasterization is the slowest thing a modern GUI does, and it's doing it constantly. Everything else, such as line draws, area fill, and blitting are accelerated to hell and back on pretty much every video card made since 1993, thus I would bet on freetype being the *most* performance critical bit of software in the GUI rendering pipeline. (Can't do much about hardware speed other than buy better hardware...) SVG is also slow, but also not quite as common. Bitmaps (PNG, JPG) still seem to dominate. (And yes, font bitmaps are cached so it's not rasterizing every time text is drawn, but still, my bet is on it being the biggest target for optimization.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tomek at pipebreaker.pl Tue Feb 3 16:24:12 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Tue, 3 Feb 2009 17:24:12 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <498868EB.8080209@redhat.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> Message-ID: <20090203162412.GB6153@mother.fordon.pl.eu.org> On Tue, Feb 03, 2009 at 03:55:23PM +0000, Andrew Haley wrote: > Miloslav Trma? wrote: > > > In this case, "blinking cursor" is a requirement of some users, not an > > internal detail of the implementation that can be changed at will if it > > improves efficiency. > > A few, maybe, but in general this is quite incredible. The idea that > we should be wasting a fractional percentage of the total power budget > on something so pointless is utterly absurd. Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 could go to 10,3W when idle, we are talking about serious percentage of power saved. This means longer on-battery work and longer battery lifetime (and not some fscking hipothetical trees saved). -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzichubg at chrome.pl wagon filled with backup tapes." -- Jim Gray -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 237 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Tue Feb 3 19:37:22 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 20:37:22 +0100 Subject: Some package orphaning Message-ID: <1233689842.22804.12.camel@arekh.okg> Dear all, Due to other Fedora activities I accepted to be the lead on, I do not have the time anymore to care properly about some of my packages. This is sad and they deserve a better maintainer than me. To remove any ambigu?ty, I'm therefore orphaning: argyllcms freeze lzop nomarch perl-Convert-UUlib perl-Net-Server They should be well-behaved low-maintenance packages, except for argyllcms. argyllcms requires a motivated maintainer. Unfortunately, it also has no replacement in the FLOSS word and is pretty much our only possible solution to colour-manage screens and printers. Colour-management is necessary to do serious photo/picture work or transform your Fedora in a video source that does not distort movies. I dearly hope someone will pick it up and not have our graphic capabilities regress a major way. Sincerely, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From belegdol at gmail.com Tue Feb 3 19:52:53 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 03 Feb 2009 20:52:53 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <4988A095.6060001@gmail.com> Jakub Jelinek pisze: > Hi! > > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). > > Here are the most common causes of the regressions (fails to build > with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7): > > - 142 failures > C++ () no longer includes . > So does , , , . > When you need anything from C stdio.h, such as EOF, *printf*, > *scanf*, remove etc., add #include to all sources that > need it. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/cstdio/ > > - 22 failures > G++ 4.4 rejects int main () { return main (); } or > int main () { main (); return 0; }, > as main shouldn't be used within the program (see ISO C++ [basic.start.main]/3). > This breaks some configure scripts, e.g. AC_CHECK_LIB with second argument main as in > AC_CHECK_LIB(stdc++,main,,AC_MSG_ERROR([libstdc++ not installed])) > will now fail. As AC_CHECK_LIB isn't well suited for C++, which requires > prototypes and AC_CHECK_LIB doesn't provide them, I guess > AC_CHECK_LIB(stdc++,int,,AC_MSG_ERROR([libstdc|| not installed])) > could be used instead. This results in int main () { return int (); } > or int main () { int (); return 0; } > Only packages that actually failed to build because of this > are listed, there are many more that are affected by it though. > Look for checking for main in -l... giving no, even for packages > that succeeded. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/main/ > > - 15 failures > C++ () no longer includes . > Neither does . When you need uint32_t, uint8_t etc., > #include . > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdint/ > > - 15 failures > #elif argument is now evaluated even if earlier #if/#elif > condition evaluated non-zero, to make sure they are valid > constant expressions. See http://gcc.gnu.org/PR36320 > To fix this, either use #else when you want it instead of > #elif (e.g. several packages use #elif without any argument > at all), or use #else #if ... #endif. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/elif/ > > - 8 failures > glib2's gthread.h contains a couple of aliasing issues (e.g. > in g_once_init_enter) and a bunch of programs get bitten by it > when they inline it. > This should be fixed in glib2. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/glib.aliasing/ > > - 6 failures > Other aliasing problem. In the GCC 4.3 -> 4.4 transition > the most common problem is: > char buf[NNN]; // or unsigned char or signed char > ... > ((struct somestruct *)buf)->somefield = 1 > While you can access any object through char, unsigned char or > signed char pointer and modify parts/all of it, it is not the > other way around. In this case you probably want a union of > the buffer and struct somestruct. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/aliasing/ > > - 2 failures > GCC bugs that were already fixed in newer gcc 4.4 (4.4.0-0.13 > should work). > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/already_fixed/ > > - 1 failure > Package built with -Werror, where one extra warning appeared. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/Werror/ > > - 1 failure > g++ now errors on: > struct C { virtual ~C (); }; > struct B : public C { int i; }; > struct A { const B a; A () { bar (&a); } void bar (const B *); }; > while previously it only errored if C virtual wasn't involved. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/uninit/ > > - 1 failure > __builtin_stdarg_start has been removed. #include > should be used, rather than writing stuff by hand, and if really necessary > (why?), then at least it needs to use __builtin_va_start instead. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/stdarg/ > > - 1 failure > open with O_CREAT set in the second argument needs to have 3 arguments, not > just 2. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/open2/ > > - 1 failure > free called with a pointer to non-heap allocated object. > E.g. > char buf[128], *bufp; > ... > bufp = buf; > if (something) > { > bufp = malloc (somesize); > ... > } > ... > if (bufp != buf) > free (buf); // Should have been bufp. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/nonheapfree/ > > - 30 failures > Unsorted stuff that succeeds to build with 4.3 and fails to build > with 4.4. Only looked briefly at openbabel, in which case > the bug is that it has locale.h in the include search path, which > overrides the system . > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/unsorted/ > > - 31 failures > Various mock related issues, packages failed at root.log stage, > before starting to build. Some might be related to mock being used > on RHEL5 instead of a recent fedora. > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/deps/ > > - 167 failures > packages that failed to build both with gcc 4.3 and 4.4 > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/ > > - 117 failures > unanalyzed packages with failed to build with 4.4, but 4.3 build wasn't > performed (ran out of time), so either they fall into fails-even-with-43 > category, or into unsorted. > > Jakub > I took a stab at fixing museek+, and I was able to get a bit farther. Now, I'm stuck. It says ld returned 1 exit status without an apparent reason: https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log Please help. Thanks, Julian From jakub at redhat.com Tue Feb 3 19:59:12 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 20:59:12 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <4988A095.6060001@gmail.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <4988A095.6060001@gmail.com> Message-ID: <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 08:52:53PM +0100, Julian Sikorski wrote: > I took a stab at fixing museek+, and I was able to get a bit farther. > Now, I'm stuck. It says ld returned 1 exit status without an apparent > reason: > https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log > Please help. There is a whole bunch of errors about undefined __sync_fetch_and_add_4 from what I can see. These are the same reason as has been discussed before, this libstdc++ header requires -march=i486 or later (the default is -march=i586, but i386.rpm builds use explicit -march=i386). Koji will be hopefully changed soon to default to i586.rpm or i686.rpm. Jakub From drepper at redhat.com Tue Feb 3 20:01:10 2009 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 03 Feb 2009 12:01:10 -0800 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203185310.GD5846@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> Message-ID: <4988A286.4020002@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominik 'Rathann' Mierzejewski wrote: > I'd like to see a case (not involving Pentium 4) where using cmov is slower > than not using it. It definitely is faster for decoding H.264 in FFmpeg > for example. I don't have a specific test case. But I do talk to the CPU architectures at Intel regularly. They always say the cmov should be avoided. Especially with the introduction of the fused micro-ops the various cmp+jcc pairs are likely move faster. And from the code generation perspective using cmp+jcc is also more flexible. With cmov you have to tie up two registers. This is particularly bad with the x86 ABI. There are certainly cases where cmov can be faster. Perhaps exclusively on older micro architectures (P4s, early Core2, maybe AMD, haven't checked). But in general it's no win. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmIooYACgkQ2ijCOnn/RHSaCwCgvpRT/7GJELdNu+5nSPKUqKHa wmgAnjxFmL278HkbwBCI5HK5YCT47JzC =xAK6 -----END PGP SIGNATURE----- From belegdol at gmail.com Tue Feb 3 20:03:36 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 03 Feb 2009 21:03:36 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <4988A095.6060001@gmail.com> <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <4988A318.90008@gmail.com> Jakub Jelinek pisze: > On Tue, Feb 03, 2009 at 08:52:53PM +0100, Julian Sikorski wrote: >> I took a stab at fixing museek+, and I was able to get a bit farther. >> Now, I'm stuck. It says ld returned 1 exit status without an apparent >> reason: >> https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log >> Please help. > > There is a whole bunch of errors about undefined __sync_fetch_and_add_4 > from what I can see. These are the same reason as has been discussed > before, this libstdc++ header requires -march=i486 or later (the default > is -march=i586, but i386.rpm builds use explicit -march=i386). > Koji will be hopefully changed soon to default to i586.rpm or i686.rpm. > > Jakub > Oh, so that's the culprit then. Seems like I've fixed all I could then. Thanks again! Julian From nicolas.mailhot at laposte.net Tue Feb 3 20:07:41 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 21:07:41 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203162412.GB6153@mother.fordon.pl.eu.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> Message-ID: <1233691661.22804.14.camel@arekh.okg> Le mardi 03 f?vrier 2009 ? 17:24 +0100, Tomasz Torcz a ?crit : > Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 > could go to 10,3W when idle But when it's idle, you are in screensaver or blank screen with no cursor anyway. The "wins" are massively overhyped, and the loss is users wondering where the damn cursor is (there are good reasons it was made to blink in the first place) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Tue Feb 3 20:09:17 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Feb 2009 15:09:17 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233691661.22804.14.camel@arekh.okg> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> Message-ID: <20090203200917.GA3996@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > But when it's idle, you are in screensaver or blank screen with no > cursor anyway. The "wins" are massively overhyped, and the loss is users > wondering where the damn cursor is (there are good reasons it was made > to blink in the first place) I fail to see how a solid cursor is that much harder to find than a blinking one. Unless you're only entering solid boxes as text? Bill From limb at jcomserv.net Tue Feb 3 20:17:41 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 3 Feb 2009 14:17:41 -0600 (CST) Subject: Attn FESco: Non-Responsive Maintainer - John Berninger In-Reply-To: <497F7842.40306@iinet.net.au> References: <497F7842.40306@iinet.net.au> Message-ID: > Cry wrote: >> Per the Fedora Non-Responsive Maintainer Policy at: >> >> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers >> >> * After another 7 days (now 3 weeks total), the reporter posts a >> formal > Given that this time of year in some places is the long holiday period, > ending within a week or so, perhaps it's worth holding off for another > week ? FYI, contact with John has been made. Parties interesting in his pacakges should see https://bugzilla.redhat.com/show_bug.cgi?id=474870. Also, this means bugzilla is up for grabs. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- in your fear, speak only peace in your fear, seek only love -d. bowie From jkeating at redhat.com Tue Feb 3 20:18:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 03 Feb 2009 12:18:31 -0800 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233691661.22804.14.camel@arekh.okg> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> Message-ID: <1233692311.7493.83.camel@localhost.localdomain> On Tue, 2009-02-03 at 21:07 +0100, Nicolas Mailhot wrote: > > But when it's idle, you are in screensaver or blank screen with no > cursor anyway. Or you're reading text on the screen and not actively diddling the mouse of the keyboard. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Tue Feb 3 20:26:40 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 3 Feb 2009 14:26:40 -0600 (CST) Subject: Some package orphaning In-Reply-To: <1233689842.22804.12.camel@arekh.okg> References: <1233689842.22804.12.camel@arekh.okg> Message-ID: > Dear all, > > Due to other Fedora activities I accepted to be the lead on, I do not > have the time anymore to care properly about some of my packages. This > is sad and they deserve a better maintainer than me. > > To remove any ambigu??ty, I'm therefore orphaning: > > argyllcms I've taken argyllcms. > freeze > lzop > nomarch > perl-Convert-UUlib > perl-Net-Server > > They should be well-behaved low-maintenance packages, except for > argyllcms. argyllcms requires a motivated maintainer. Unfortunately, it > also has no replacement in the FLOSS word and is pretty much our only > possible solution to colour-manage screens and printers. > Colour-management is necessary to do serious photo/picture work or > transform your Fedora in a video source that does not distort movies. I > dearly hope someone will pick it up and not have our graphic > capabilities regress a major way. > > Sincerely, > > -- > Nicolas Mailhot > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- in your fear, speak only peace in your fear, seek only love -d. bowie From seg at haxxed.com Tue Feb 3 20:29:10 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Feb 2009 14:29:10 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> Message-ID: <1233692950.17218.107.camel@localhost.localdomain> On Tue, 2009-02-03 at 01:01 -0500, Gregory Maxwell wrote: > We would see much more substantial gains from things like -msse2 & > fpmath=sse but, unfortunately, unlike i586 there are a *lot* of > systems out there (and still being sold) which do not have all the > fancy instruction set extensions. I've found -mfpmath=sse to actually be slightly slower than x87. GCC just isn't very good at SSE yet, but people have been tuning its x87 output for decades now. And at this point, all really performance critical bits of code I've ever seen, are already using runtime selection of hand-tuned SSE/MMX/etc inner loops. This is absolutely key. There's little gain to be had from diddling with GCC's instruction set usage because most performance critical software is already using hand-tuned assembly in their hotpaths on CPUs that support them. Going -O3 rather than -O2 is going to make a bigger difference than anything else. If you want to improve performance, you need to run profiles, locate performance critical bits of code, figure out if -O3 is beneficial, and/or write some hand tuned assembly/intrinsic code. Not to mention, the biggest performance problem on modern processors is memory. Minimizing cache thrashing is way more important than what instructions you use. Optimize data structures before code. > Repeating myself here? When it comes down to it, we already have a > "performance compiled" distribution: x86_64 which has every i686 knob > turned on and then some. If you care about whatever really minute gain > you'd get out of arch=i686, then you really should be looking for an > x86_64 system. (The higher end atoms are quite attractive I hear?) Yes, most new hardware has been 64-bit capable for years now. There's little reason to cut off i586 users, when x86-64 already provides a convenient cutoff point. My advice as an amateur optimization specialist: Don't bother with -march=i686, there's just not enough gain over i586 vs the cost. And actually I find -march=i586 questionable, is the one additional instruction something GCC is ever going to use on its own? But i486 is so ancient I'm not going to cry if we dump it. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bkoz at redhat.com Tue Feb 3 20:37:35 2009 From: bkoz at redhat.com (Benjamin Kosnik) Date: Tue, 3 Feb 2009 12:37:35 -0800 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090203123735.5eb224c3@balbo.artheist.org> > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). Thanks so much for doing this. I will collate this into gcc-4.4/porting_to.html for 4.4.0 unless you already have done so or plan to do so (let me know). Might as well get this stuff on the gcc site so that this work is not re-done ad nauseam by everybody moving to this compiler. The extra warning is from -Wuninitialized, which is consistent with some of the gcc bugzilla traffic. I'm surprised you only got one: I expect you'll see more when you move to s390 and non-x86_64 arches. best, -benjamin From oget.fedora at gmail.com Tue Feb 3 20:39:29 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 3 Feb 2009 15:39:29 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <4988A095.6060001@gmail.com> <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: On Tue, Feb 3, 2009 at 2:59 PM, Jakub Jelinek wrote: > On Tue, Feb 03, 2009 at 08:52:53PM +0100, Julian Sikorski wrote: >> I took a stab at fixing museek+, and I was able to get a bit farther. >> Now, I'm stuck. It says ld returned 1 exit status without an apparent >> reason: >> https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log >> Please help. > > There is a whole bunch of errors about undefined __sync_fetch_and_add_4 > from what I can see. These are the same reason as has been discussed > before, this libstdc++ header requires -march=i486 or later (the default > is -march=i586, but i386.rpm builds use explicit -march=i386). > Koji will be hopefully changed soon to default to i586.rpm or i686.rpm. > > Jakub Do we need to "fix" these flags in the SPEC file, or shall we wait until koji is "fixed"? Orcan From mjg at redhat.com Tue Feb 3 20:42:42 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 20:42:42 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233691661.22804.14.camel@arekh.okg> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> Message-ID: <20090203204242.GA19852@srcf.ucam.org> On Tue, Feb 03, 2009 at 09:07:41PM +0100, Nicolas Mailhot wrote: > But when it's idle, you are in screensaver or blank screen with no > cursor anyway. The "wins" are massively overhyped, and the loss is users > wondering where the damn cursor is (there are good reasons it was made > to blink in the first place) We're talking about different orders of time. The screen is idle when nothing is being drawn to it - that is, the screen will typically be idle the vast majority of the time even if the session is active. -- Matthew Garrett | mjg59 at srcf.ucam.org From jakub at redhat.com Tue Feb 3 20:44:32 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 21:44:32 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203123735.5eb224c3@balbo.artheist.org> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <20090203123735.5eb224c3@balbo.artheist.org> Message-ID: <20090203204432.GB5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 12:37:35PM -0800, Benjamin Kosnik wrote: > > > In the past few days I've done a mass rebuild of rawhide-20090126 > > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > > 6228 packages were successfully built, for the rest I've tried > > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > > so a couple of packages weren't attempted with 4.3). > > Thanks so much for doing this. I will collate this into > gcc-4.4/porting_to.html for 4.4.0 unless you already have done so or > plan to do so (let me know). Might as well get this stuff on the gcc Feel free to do that. Just probably leave out the main calling bit, I hope Jason will make it -pedantic only soon. > The extra warning is from -Wuninitialized, which is consistent with > some of the gcc bugzilla traffic. I'm surprised you only got one: I > expect you'll see more when you move to s390 and non-x86_64 arches. To cause a package build failure the package has to use -Werror, most of the packages don't. But yes, I was surprised it was just one package, not 10 or 20. Jakub From dominik at greysector.net Tue Feb 3 20:45:46 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 3 Feb 2009 21:45:46 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <4988A286.4020002@redhat.com> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> Message-ID: <20090203204545.GB10874@mokona.greysector.net> On Tuesday, 03 February 2009 at 21:01, Ulrich Drepper wrote: > Dominik 'Rathann' Mierzejewski wrote: > > I'd like to see a case (not involving Pentium 4) where using cmov is slower > > than not using it. It definitely is faster for decoding H.264 in FFmpeg > > for example. > > I don't have a specific test case. But I do talk to the CPU > architectures at Intel regularly. I didn't know architectures could talk. ;) > They always say the cmov should be > avoided. Especially with the introduction of the fused micro-ops the > various cmp+jcc pairs are likely move faster. > > And from the code generation perspective using cmp+jcc is also more > flexible. With cmov you have to tie up two registers. This is > particularly bad with the x86 ABI. > > There are certainly cases where cmov can be faster. Perhaps exclusively > on older micro architectures (P4s, early Core2, maybe AMD, haven't > checked). But in general it's no win. Well, I talk to people who write hand-optimized assembly and care to squeeze every cycle out of various CPUs and they say it's definitely a win. So please, show me some code instead of hand-waving. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From walters at verbum.org Tue Feb 3 20:41:25 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 3 Feb 2009 15:41:25 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <1233692950.17218.107.camel@localhost.localdomain> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <1233692950.17218.107.camel@localhost.localdomain> Message-ID: 2009/2/3 Callum Lerwick : > On Tue, 2009-02-03 at 01:01 -0500, Gregory Maxwell wrote: >> We would see much more substantial gains from things like -msse2 & >> fpmath=sse but, unfortunately, unlike i586 there are a *lot* of >> systems out there (and still being sold) which do not have all the >> fancy instruction set extensions. > > I've found -mfpmath=sse to actually be slightly slower than x87. GCC > just isn't very good at SSE yet, but people have been tuning its x87 > output for decades now. > > And at this point, all really performance critical bits of code I've > ever seen, are already using runtime selection of hand-tuned SSE/MMX/etc > inner loops. This is absolutely key. There's little gain to be had from > diddling with GCC's instruction set usage because most performance > critical software is already using hand-tuned assembly in their hotpaths > on CPUs that support them. Speaking of, it's worth mentioning liboil: http://liboil.freedesktop.org/wiki/ From jwboyer at gmail.com Tue Feb 3 20:52:41 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 15:52:41 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203204545.GB10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> Message-ID: <20090203205241.GD10541@yoda.jdub.homelinux.org> On Tue, Feb 03, 2009 at 09:45:46PM +0100, Dominik 'Rathann' Mierzejewski wrote: >On Tuesday, 03 February 2009 at 21:01, Ulrich Drepper wrote: >> Dominik 'Rathann' Mierzejewski wrote: >> > I'd like to see a case (not involving Pentium 4) where using cmov is slower >> > than not using it. It definitely is faster for decoding H.264 in FFmpeg >> > for example. >> >> I don't have a specific test case. But I do talk to the CPU >> architectures at Intel regularly. > >I didn't know architectures could talk. ;) > >> They always say the cmov should be >> avoided. Especially with the introduction of the fused micro-ops the >> various cmp+jcc pairs are likely move faster. >> >> And from the code generation perspective using cmp+jcc is also more >> flexible. With cmov you have to tie up two registers. This is >> particularly bad with the x86 ABI. >> >> There are certainly cases where cmov can be faster. Perhaps exclusively >> on older micro architectures (P4s, early Core2, maybe AMD, haven't >> checked). But in general it's no win. > >Well, I talk to people who write hand-optimized assembly and care to >squeeze every cycle out of various CPUs and they say it's definitely >a win. So please, show me some code instead of hand-waving. If they can do that, then why can't they rebuild things themselves? josh From dimi at lattica.com Tue Feb 3 20:53:48 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 15:53:48 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203200917.GA3996@nostromo.devel.redhat.com> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> Message-ID: <1233694428.8745.422.camel@dimi.lattica.com> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: > I fail to see how a solid cursor is that much harder to find than > a blinking one. Unless you're only entering solid boxes as text? There's a reason it's been like this in like ... forever. Doesn't it strike you as strange to change one of the longest established conventions on a whim?!? Where are the scientific usability studies that are required here whenever other changes are proposed? On a busy X session (I typically have 30-40+ windows open) not having a blinking cursor is crazy. -- Dimi Paun Lattica, Inc. From dominik at greysector.net Tue Feb 3 20:57:40 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 3 Feb 2009 21:57:40 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203205241.GD10541@yoda.jdub.homelinux.org> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> <20090203205241.GD10541@yoda.jdub.homelinux.org> Message-ID: <20090203205740.GC10874@mokona.greysector.net> On Tuesday, 03 February 2009 at 21:52, Josh Boyer wrote: > On Tue, Feb 03, 2009 at 09:45:46PM +0100, Dominik 'Rathann' Mierzejewski wrote: [...] > >Well, I talk to people who write hand-optimized assembly and care to > >squeeze every cycle out of various CPUs and they say it's definitely > >a win. So please, show me some code instead of hand-waving. > > If they can do that, then why can't they rebuild things themselves? Oh, right. Let's all use LFS or Gentoo. Why can't everyone rebuild things themselves? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jakub at redhat.com Tue Feb 3 21:05:59 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 22:05:59 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <4988A095.6060001@gmail.com> <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090203210559.GD5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 03:39:29PM -0500, Orcan Ogetbil wrote: > On Tue, Feb 3, 2009 at 2:59 PM, Jakub Jelinek wrote: > > On Tue, Feb 03, 2009 at 08:52:53PM +0100, Julian Sikorski wrote: > >> I took a stab at fixing museek+, and I was able to get a bit farther. > >> Now, I'm stuck. It says ld returned 1 exit status without an apparent > >> reason: > >> https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log > >> Please help. > > > > There is a whole bunch of errors about undefined __sync_fetch_and_add_4 > > from what I can see. These are the same reason as has been discussed > > before, this libstdc++ header requires -march=i486 or later (the default > > is -march=i586, but i386.rpm builds use explicit -march=i386). > > Koji will be hopefully changed soon to default to i586.rpm or i686.rpm. > > > > Jakub > > Do we need to "fix" these flags in the SPEC file, or shall we wait > until koji is "fixed"? Wait, please don't change SPEC files for this. I'm going to surround _GLIBCXX_ATOMIC_BUILTINS_N defines in c++config.h with #ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_N guards in 4.4.0-0.14, which should allow even building of -march=i386 stuff against that libstdc++. Jakub From konrad at tylerc.org Tue Feb 3 21:11:15 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Tue, 3 Feb 2009 13:11:15 -0800 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <49889420.3000401@leemhuis.info> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> <49889420.3000401@leemhuis.info> Message-ID: <200902031311.15807.konrad@tylerc.org> On Tuesday 03 February 2009 10:59:44 am Thorsten Leemhuis wrote: > On 03.02.2009 17:21, Jakub Jelinek wrote: > > On Tue, Feb 03, 2009 at 05:01:24PM +0100, Jochen Schmitt wrote: > >> Jakub Jelinek schrieb: > >>> In the past few days I've done a mass rebuild of rawhide-20090126 > >>> in mock with gcc-4.4.0-0.9 (and corresponding libtool). > >>> 6228 packages were successfully built, for the rest I've tried > >>> to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > >>> so a couple of packages weren't attempted with 4.3). > >> > >> If may be helpful, if you can publish a list with packages which caused > >> issues with the new compiler. So we may be able to fix the issue without > >> the need to tryout all of our packages. > > > > They were referenced in the links. > > Anyway, here is the list of all packages that didn't build successfully > > with 4.4, [...] > > Finding all your packages in such a long list gets really hard as soon > as you maintain 10 or 15 packages. Here is a list of packages with thir > owners, sorted by owner; generated with fedoradev-pkgowners: > http://thorstenl.blogspot.com/2007/09/fedoradev-pkgowners-get-package-owner >s.html Should make things a lot easier. Use at your own risk. > > ... > > CU > knurd Thanks, very helpful! -- Conrad Meyer From jakub at redhat.com Tue Feb 3 21:12:49 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 3 Feb 2009 22:12:49 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203204545.GB10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> Message-ID: <20090203211249.GE5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 09:45:46PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 03 February 2009 at 21:01, Ulrich Drepper wrote: > > Dominik 'Rathann' Mierzejewski wrote: > > > I'd like to see a case (not involving Pentium 4) where using cmov is slower > > > than not using it. It definitely is faster for decoding H.264 in FFmpeg > > > for example. > > > > I don't have a specific test case. But I do talk to the CPU > > architectures at Intel regularly. > > I didn't know architectures could talk. ;) That was meant to be CPU architects at Intel. Jakub From nicolas.mailhot at laposte.net Tue Feb 3 21:14:04 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 22:14:04 +0100 Subject: Some package orphaning In-Reply-To: References: <1233689842.22804.12.camel@arekh.okg> Message-ID: <1233695644.25190.3.camel@arekh.okg> Le mardi 03 f?vrier 2009 ? 14:26 -0600, Jon Ciesla a ?crit : > > > Dear all, > > > > Due to other Fedora activities I accepted to be the lead on, I do not > > have the time anymore to care properly about some of my packages. This > > is sad and they deserve a better maintainer than me. > > > > To remove any ambigu??ty, I'm therefore orphaning: > > > > argyllcms > > I've taken argyllcms. Thank you. If you need one-time help, don't hesitate to ping me. The Mandriva packager is also nice, it took two of us to make a package a reasonable distro could ship. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at gmail.com Tue Feb 3 21:08:07 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 16:08:07 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203205740.GC10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> <20090203205241.GD10541@yoda.jdub.homelinux.org> <20090203205740.GC10874@mokona.greysector.net> Message-ID: <20090203210807.GE10541@yoda.jdub.homelinux.org> On Tue, Feb 03, 2009 at 09:57:40PM +0100, Dominik 'Rathann' Mierzejewski wrote: >On Tuesday, 03 February 2009 at 21:52, Josh Boyer wrote: >> On Tue, Feb 03, 2009 at 09:45:46PM +0100, Dominik 'Rathann' Mierzejewski wrote: >[...] >> >Well, I talk to people who write hand-optimized assembly and care to >> >squeeze every cycle out of various CPUs and they say it's definitely >> >a win. So please, show me some code instead of hand-waving. >> >> If they can do that, then why can't they rebuild things themselves? > >Oh, right. Let's all use LFS or Gentoo. >Why can't everyone rebuild things themselves? They can. Look, it's very simple. Fedora _cannot_ be everything to everyone. There are too many variations, optimizations, etc. So, in light of that, it tries to fit the best usecase. The common ground. People that hand code assembly files are _not_ the common users of Fedora. josh From jarod at redhat.com Tue Feb 3 21:24:17 2009 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 03 Feb 2009 16:24:17 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203210559.GD5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <4988A095.6060001@gmail.com> <20090203195912.GA5690@tyan-ft48-01.lab.bos.redhat.com> <20090203210559.GD5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <4988B601.7070307@redhat.com> Jakub Jelinek wrote: > On Tue, Feb 03, 2009 at 03:39:29PM -0500, Orcan Ogetbil wrote: >> On Tue, Feb 3, 2009 at 2:59 PM, Jakub Jelinek wrote: >>> On Tue, Feb 03, 2009 at 08:52:53PM +0100, Julian Sikorski wrote: >>>> I took a stab at fixing museek+, and I was able to get a bit farther. >>>> Now, I'm stuck. It says ld returned 1 exit status without an apparent >>>> reason: >>>> https://koji.fedoraproject.org/koji/getfile?taskID=1102268&name=build.log >>>> Please help. >>> There is a whole bunch of errors about undefined __sync_fetch_and_add_4 >>> from what I can see. These are the same reason as has been discussed >>> before, this libstdc++ header requires -march=i486 or later (the default >>> is -march=i586, but i386.rpm builds use explicit -march=i386). >>> Koji will be hopefully changed soon to default to i586.rpm or i686.rpm. >>> >>> Jakub >> Do we need to "fix" these flags in the SPEC file, or shall we wait >> until koji is "fixed"? > > Wait, please don't change SPEC files for this. I'm going to surround > _GLIBCXX_ATOMIC_BUILTINS_N defines in c++config.h with > #ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_N guards in 4.4.0-0.14, which > should allow even building of -march=i386 stuff against that libstdc++. I've fixed up both dvgrab and ivtv-utils and sent appropriate patches upstream, but I'm slightly clueless what's going on with libdv... http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/libdv-1.0.0-5.fc10.src.rpm/build.log Looks to be fall-out specific to the new libtool in rawhide. Karsten, any clues? --jarod From kwade at redhat.com Tue Feb 3 21:25:03 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 3 Feb 2009 13:25:03 -0800 Subject: OSCON call for papers ends today (03 Feb. 2009 Midnight PST) Message-ID: <20090203212503.GH5166@calliope.phig.org> If you want to propose a talk, send it in soon: http://en.oreilly.com/oscon2009/public/cfp/57 We intend to have a great Fedora presence, including a booth and a Fedora Activity Day. We haven't settled on FAD ideas yet, so it's wide open! - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From herlo at fedoraproject.org Tue Feb 3 21:29:35 2009 From: herlo at fedoraproject.org (Clint Savage) Date: Tue, 3 Feb 2009 14:29:35 -0700 Subject: [Ambassadors] OSCON call for papers ends today (03 Feb. 2009 Midnight PST) In-Reply-To: <20090203212503.GH5166@calliope.phig.org> References: <20090203212503.GH5166@calliope.phig.org> Message-ID: 2009/2/3 Karsten Wade : > If you want to propose a talk, send it in soon: > > http://en.oreilly.com/oscon2009/public/cfp/57 > > We intend to have a great Fedora presence, including a booth and a > Fedora Activity Day. We haven't settled on FAD ideas yet, so it's > wide open! > > - Karsten I hope many others submit talks. I've already submitted one today. Cheers, Clint From gmaxwell at gmail.com Tue Feb 3 21:31:18 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 3 Feb 2009 16:31:18 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203204545.GB10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> Message-ID: On Tue, Feb 3, 2009 at 3:45 PM, Dominik 'Rathann' Mierzejewski wrote: >> There are certainly cases where cmov can be faster. Perhaps exclusively >> on older micro architectures (P4s, early Core2, maybe AMD, haven't >> checked). But in general it's no win. > > Well, I talk to people who write hand-optimized assembly and care to > squeeze every cycle out of various CPUs and they say it's definitely > a win. GCC is not a person who writes hand-optimized assembly, yet it is GCC's use of cmov that matters to us. It wouldn't surprise me to find that profile driven use of CMOV works a lot better than the generic case. These people can continue to write their cmov using ASM. If they are doing that kind of tuning work then they are likely also doing SSE detection and can handle switching code variants at run time. > So please, show me some code instead of hand-waving. ? I did post benchmarks of libTheora showing a 0.2% gain on core2 from cmov. Perhaps you'd care to benchmark freetype? From pp at ee.oulu.fi Tue Feb 3 21:16:43 2009 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 3 Feb 2009 23:16:43 +0200 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <49887ADF.9090606@redhat.com> References: <49887ADF.9090606@redhat.com> Message-ID: <20090203211642.GA25276@ee.oulu.fi> On Tue, Feb 03, 2009 at 12:11:59PM -0500, Warren Togami wrote: > Jakub recommended doing comparison tests of -m32 -march=i586 > -mtune=generic vs. -m32 -march=i686 -mtune=generic with Spec2k and > Spec2006 benchmark tools. Anyone interested in trying this? > > In related news, cebbert wants to do the following to the F-11 kernel: > - Eliminate the current i686 kernel. > - i686 hardware would get i686 PAE by default. > - i586 kernel becomes i686, except without cmov. This is primarily so > people don't complain when they realize they have the "i586" kernel. Just a note, I believe that the ia32 support should "concentrate" on netbooks (So Intel Atom), those are the only new things on the market that can't run x86_64, and the userbase of those will just grow and every percent of extra performance will make many people happy. A benchmark run on one of those might be very useful to make the final decision, not that the more server-oriented tests are very useful for the typical netbook userbase. And then there's the "should work even with this" decision, and i686 without cmov is a reasonable minimum there. Could be i686+cmov or +sse2, but those will make a lot of people unhappy. -- Pekka Pietikainen From skvidal at fedoraproject.org Tue Feb 3 21:39:49 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Feb 2009 16:39:49 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233694428.8745.422.camel@dimi.lattica.com> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> Message-ID: <1233697189.3238.17.camel@rosebud> On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: > On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: > > I fail to see how a solid cursor is that much harder to find than > > a blinking one. Unless you're only entering solid boxes as text? > > There's a reason it's been like this in like ... forever. > Doesn't it strike you as strange to change one of the > longest established conventions on a whim?!? Tradition is not an argument in fedora. -sv From aph at redhat.com Tue Feb 3 21:42:32 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Feb 2009 21:42:32 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233697189.3238.17.camel@rosebud> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> Message-ID: <4988BA48.9090102@redhat.com> seth vidal wrote: > On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: >> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: >>> I fail to see how a solid cursor is that much harder to find than >>> a blinking one. Unless you're only entering solid boxes as text? >> There's a reason it's been like this in like ... forever. >> Doesn't it strike you as strange to change one of the >> longest established conventions on a whim?!? > > Tradition is not an argument in fedora. And I'm not sure it's even true. I have never seen an Xterm flash, but my gnome-terminals do. Andrew. From pbrobinson at gmail.com Tue Feb 3 21:50:08 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 3 Feb 2009 22:50:08 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203211642.GA25276@ee.oulu.fi> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> Message-ID: <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> > Just a note, I believe that the ia32 support should "concentrate" on > netbooks (So Intel Atom), those are the only new things on the market > that can't run x86_64, and the userbase of those will just grow and > every percent of extra performance will make many people happy. So we should ignore OLPC that is deploying 100's of thousands all running Fedora? > A benchmark run on one of those might be very useful to make the final > decision, not that the more server-oriented tests are very useful for the > typical netbook userbase. Benchmark for an OLPC device would be good too. > And then there's the "should work even with this" decision, and i686 without > cmov is a reasonable minimum there. Could be i686+cmov or +sse2, but those > will make a lot of people unhappy. Pretty sure OLPC supports cmov thought but definitely not SSE2. Peter From triad at df.lth.se Tue Feb 3 22:10:52 2009 From: triad at df.lth.se (Linus Walleij) Date: Tue, 03 Feb 2009 23:10:52 +0100 Subject: Why do we disable esd in libgnome? In-Reply-To: <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1233578539.3486.895.camel@cookie.hadess.net> <8278b1b0902020549r415d13d2t7f276c33e7b946a4@mail.gmail.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> Message-ID: <1233699052.5880.5.camel@fecusia> > I'm talking > about making an API that exists in the platform continue to work until > it can be removed. It can be removed now. Convert apps over to libcanberra. Linus From skvidal at fedoraproject.org Tue Feb 3 22:13:07 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Feb 2009 17:13:07 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4988BA48.9090102@redhat.com> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988BA48.9090102@redhat.com> Message-ID: <1233699187.3238.18.camel@rosebud> On Tue, 2009-02-03 at 21:42 +0000, Andrew Haley wrote: > seth vidal wrote: > > On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: > >> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: > >>> I fail to see how a solid cursor is that much harder to find than > >>> a blinking one. Unless you're only entering solid boxes as text? > >> There's a reason it's been like this in like ... forever. > >> Doesn't it strike you as strange to change one of the > >> longest established conventions on a whim?!? > > > > Tradition is not an argument in fedora. > > And I'm not sure it's even true. I have never seen an Xterm flash, > but my gnome-terminals do. False tradition is also not an argument in fedora. :) -sv From poelstra at redhat.com Tue Feb 3 22:18:56 2009 From: poelstra at redhat.com (John Poelstra) Date: Tue, 03 Feb 2009 14:18:56 -0800 Subject: Fedora Release Engineering Meeting Recap 2009-02-02 Message-ID: <4988C2D0.2070106@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-feb-03 Please make corrections and clarifications to the wiki page. == Delay of Fedora 11 Alpha == * multiple bugs found, and discovered as far back as the original freeze. Attempts to fix the bugs with newer trees brought in different bugs. * remaining issues with ** iSCSI ** iprutils * Go forward plan: *# rebuild ppc with newer iprutils *# delay Fedora 11 alpha until 2009-02-05 with approval from FESCo *# hold all other schedule dates == gcc 4.4 Mass Rebuilde == * perform prior to beta * need to iron out a few other issues first ** compiler flags ** minimum arch * going to need a build for gcc4.4, rpm sha256, and font provides * https://fedoraproject.org/wiki/Features/gcc4.4 * https://fedoraproject.org/wiki/Features/ArchitectureSupport == IRC Transcript == From choeger at cs.tu-berlin.de Tue Feb 3 22:16:32 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 03 Feb 2009 23:16:32 +0100 Subject: Fedora tested in c't: grub missing feature Message-ID: <1233699392.11676.10.camel@choeger5.umpa.netz> Hi, fedora has recently been tested (again) and compared against other distributions (Ubuntu and OpenSUSE) by c't, a german IT magazine from the heise publishing house. Among other criticisms one thing was really annoying: When a user installs fedora on a machine with windows installed (common use case) it detects that installation and offers to add it to grub. But installing fedora on a box with an already present linux distro installation will yield that installation removed from grub. I understand that the bootloader is a part of the distro and its configuration gets changed e.g. during kernel updates, but is there really only the answer to remove one distribution completely? Do we really want to support Windows as second OS more than OpenSUSE or Ubuntu (or CentOS, or Debian, or Gentoo, or ........) At least the anaconda team should consider printing a warning about one OS going to "be lost" during install and how to recover. Any thoughts on that? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From pbrobinson at gmail.com Tue Feb 3 22:18:05 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 3 Feb 2009 23:18:05 +0100 Subject: Why do we disable esd in libgnome? In-Reply-To: <1233699052.5880.5.camel@fecusia> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> Message-ID: <5256d0b0902031418s12bc1663g60587665c2dd74df@mail.gmail.com> >> I'm talking >> about making an API that exists in the platform continue to work until >> it can be removed. > > It can be removed now. Convert apps over to libcanberra. Agreed. For some time all of libgnome has essentially been marked as deprecated by gnome and is being actively migrated away away from. Details can be seen here http://live.gnome.org/LibgnomeMustDie and has been part of the Project Ridley which is well over 2 years old. http://live.gnome.org/ProjectRidley Peter From dimi at lattica.com Tue Feb 3 22:22:43 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 17:22:43 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233697189.3238.17.camel@rosebud> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> Message-ID: <1233699763.8745.425.camel@dimi.lattica.com> On Tue, 2009-02-03 at 16:39 -0500, seth vidal wrote: > > There's a reason it's been like this in like ... forever. > > Doesn't it strike you as strange to change one of the > > longest established conventions on a whim?!? > > Tradition is not an argument in fedora. Neither seems to be reason. Blindingly ignoring tradition is patently absurd. We might as well change the slogan to: Fedora: stupid and proud of it! -- Dimi Paun Lattica, Inc. From pbrobinson at gmail.com Tue Feb 3 22:33:12 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 3 Feb 2009 23:33:12 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233699763.8745.425.camel@dimi.lattica.com> References: <1233620984.27307.16.camel@rosebud> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> Message-ID: <5256d0b0902031433r50fce9c8qb6c4e4066d8a07af@mail.gmail.com> >> > There's a reason it's been like this in like ... forever. >> > Doesn't it strike you as strange to change one of the >> > longest established conventions on a whim?!? >> >> Tradition is not an argument in fedora. > > Neither seems to be reason. TBH until recently I thought this problem had gone away. Shortly after powertop came out the blinking cursor issue was identified as an issue and I saw patches flying around to fix the problems. It wasn't until I noticed OLPC was patching some part of the the gnome stack to fix the issue that I realised that it was still an issue. Surely it can be made some sort of "Cursor Blink" config option that is disabled by default but allow the people that want blinking to enable it relatively simply. Peter From dbn.lists at gmail.com Tue Feb 3 22:34:20 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 3 Feb 2009 14:34:20 -0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <1233699052.5880.5.camel@fecusia> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> Message-ID: <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> On Tue, Feb 3, 2009 at 2:10 PM, Linus Walleij wrote: >> I'm talking >> about making an API that exists in the platform continue to work until >> it can be removed. > > It can be removed now. Convert apps over to libcanberra. You can't remove it. That would break the API, something that GNOME will not do. Again... Porting apps to libcanberra is the right thing to do. Convert every single one you find. But, gnome_sound_play is in the platform until GNOME-3.0 comes along and API can be broken. In that case, why not have gnome_sound_play actually do something useful since it's dead simple to do it? -- Dan From pbrobinson at gmail.com Tue Feb 3 22:35:36 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 3 Feb 2009 23:35:36 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <5256d0b0902031435p2ca642c4p7e74c3233bd14a29@mail.gmail.com> >> > In the past few days I've done a mass rebuild of rawhide-20090126 >> > in mock with gcc-4.4.0-0.9 (and corresponding libtool). >> > 6228 packages were successfully built, for the rest I've tried >> > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, >> > so a couple of packages weren't attempted with 4.3). >> > >> If may be helpful, if you can publish a list with packages which caused >> issues with the new compiler. So we may be able to fix the issue without >> the need to tryout all of our packages. > > They were referenced in the links. > Anyway, here is the list of all packages that didn't build successfully > with 4.4, for details look at the provided links or try to build in > dist-f11-gcc44 --scratch yourself (Karsten, could you please build libtool > in dist-f11-gcc44, so that people actually can do that themselves? > I only had a --scratch libtool build in my local repo). What's the status of getting the appropriate libtool pulled in? Peter From jspaleta at gmail.com Tue Feb 3 22:37:19 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Feb 2009 13:37:19 -0900 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233699763.8745.425.camel@dimi.lattica.com> References: <1233620984.27307.16.camel@rosebud> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> Message-ID: <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> On Tue, Feb 3, 2009 at 1:22 PM, Dimi Paun wrote: > > We might as well change the slogan to: > > Fedora: stupid and proud of it! I would appreciate it if you tried to keep this discussion civil. right now on my F10 system xterm defaults to no blink konsole defaults to no blink aterm defaults to no blink Eterm defaults to no blink rxvt defaults to no blink gnome-terminal defaults to blink I do not think traditional terminal operation makes a strong argument in the scope of this discussion in the light of the fact that other terminal emulators with codebase lifetimes as long or longer than gnome-terminal/libvte already default to no blink in F10. If anything.. gnome-terminal is the odd man out and there is an argument to be made to bring it into line with the common default behaviour of other virtual terminals. -jef"unless my defaults are screwed up of course"spaleta From jkeating at redhat.com Tue Feb 3 22:37:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 03 Feb 2009 14:37:58 -0800 Subject: Fedora 11 Alpha slip Message-ID: <1233700678.7493.99.camel@localhost.localdomain> We've decided to delay the release date of Fedora 11 Alpha by 2 days giving us time to fully sync the release to our mirror systems. The new release date is this Thursday, Feb 5th at 1500 UTC. An announcement will be made then when the bits are available to the general public. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From nicolas.mailhot at laposte.net Tue Feb 3 22:50:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Feb 2009 23:50:16 +0100 Subject: BPG Georgian Unicode fonts - packagers wanted Message-ID: <1233701416.26332.26.camel@arekh.okg> Dear all, Yesterday I took the time to find the current address of a well-known Georgian font creator, Besarion Paata Gugushvili. Our current Georgian support is rather limited: one set of glyphs in Dejavu, and nothing else (This set was created by the very same author BTW). Imagine using the same font all day long everywhere :( Some of his other fonts had long found their way in other major distributions (Mandriva, OpenSuse, Debian, Ubuntu?), at a time Fedora was largely ignoring this problem-space, but there was no public licensing statement of his part on any of his web sites. Which meant we could not just lift the files from the internet, and package them to reach Georgian support parity with others. So took the time to write the author a long nice mail asking to confirm the licensing. I didn't expect much, this kind of request usually takes ages to be answered, and the answer is usually not the one we'd like (when we don't hit language barriers). Anyway this time the reply was awesome: 1. less than 9 hours later (most of them night I'm sure) 2. a *new* font pack release (not the old files everyone else ships) 3. with *new* fonts (not just updates of the fonts everyone else ships) 4. with a clear licensing statement on the author web site (not a third-party site like before) 5. and adding the FSF font exception to the GPL statement (people who tried know how hard it is to get this one usually, many font authors just don't understand the need) So, Fedora would seriously suck if we took ages to package those fonts now. Or if other distros beat us to it. Unfortunately, I'm a *tad* busy right now, and can't possibly work on it short term. Therefore, I'm doing a public call on Fedora lists, for someone to package those, and prove Besarion Paata Gugushvili was right to trust Fedora. All the relevant technical information is here: http://fedoraproject.org/wiki/BPG_fonts Let's rock! Best regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ajax at redhat.com Tue Feb 3 22:54:16 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 03 Feb 2009 17:54:16 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> Message-ID: <1233701656.1833.61.camel@atropine.boston.devel.redhat.com> On Tue, 2009-02-03 at 22:50 +0100, Peter Robinson wrote: > > Just a note, I believe that the ia32 support should "concentrate" on > > netbooks (So Intel Atom), those are the only new things on the market > > that can't run x86_64, and the userbase of those will just grow and > > every percent of extra performance will make many people happy. > > So we should ignore OLPC that is deploying 100's of thousands all > running Fedora? Modest proposal: OLPC might benefit from running its own koji instance and effectively going the secondary arch route. -Os -march=geode, etc. Given how close it is to mainline x86 it's unlikely to have funky compilation failures, and it has to branch a non-trivial number of packages anyway. Of course, why limit this to geode. Surely someone has VIA C3 or a Pentium Classic they want to keep limping along. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dimi at lattica.com Tue Feb 3 23:03:00 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 18:03:00 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> Message-ID: <1233702180.8745.435.camel@dimi.lattica.com> On Tue, 2009-02-03 at 13:37 -0900, Jeff Spaleta wrote: > I would appreciate it if you tried to keep this discussion civil. It wasn't directed at anybody. All I was trying to say is that we can't just claim we ignore tradition. Fedora after all is Unix: "Those who ignore Unix are bound to reinvent it ... poorly" > If anything.. gnome-terminal is the odd man out and there is an > argument to be made to bring it into line with the common default > behaviour of other virtual terminals. Maybe. But I still don't see how you can eliminate the blinking cursor for all the other X apps. Do you propose to nuke it there as well? If not, why do it in the terminals? If yes, i just can't see how we're not going to upset a lot of users. -- Dimi Paun Lattica, Inc. From jspaleta at gmail.com Tue Feb 3 23:07:57 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Feb 2009 14:07:57 -0900 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233702180.8745.435.camel@dimi.lattica.com> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> Message-ID: <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> On Tue, Feb 3, 2009 at 2:03 PM, Dimi Paun wrote: > > On Tue, 2009-02-03 at 13:37 -0900, Jeff Spaleta wrote: >> I would appreciate it if you tried to keep this discussion civil. > > It wasn't directed at anybody. All I was trying to say is that we > can't just claim we ignore tradition. Fedora after all is Unix: > "Those who ignore Unix are bound to reinvent it ... poorly" You don't have to direct it at anybody..for it to be uncivil. Every emotive outburst is a step along a downward spiral as it drags the overall tone for the discussion down. > Maybe. But I still don't see how you can eliminate the blinking > cursor for all the other X apps. what other X apps have blinking cursors. did I miss a terminal emulator of merit.? All the other X based terminal emulators I just installed default to no blink. -jef From mjg at redhat.com Tue Feb 3 23:10:33 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 3 Feb 2009 23:10:33 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <5256d0b0902031433r50fce9c8qb6c4e4066d8a07af@mail.gmail.com> References: <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <5256d0b0902031433r50fce9c8qb6c4e4066d8a07af@mail.gmail.com> Message-ID: <20090203231033.GA22552@srcf.ucam.org> On Tue, Feb 03, 2009 at 11:33:12PM +0100, Peter Robinson wrote: > TBH until recently I thought this problem had gone away. Shortly after > powertop came out the blinking cursor issue was identified as an issue > and I saw patches flying around to fix the problems. It wasn't until I > noticed OLPC was patching some part of the the gnome stack to fix the > issue that I realised that it was still an issue. Surely it can be > made some sort of "Cursor Blink" config option that is disabled by > default but allow the people that want blinking to enable it > relatively simply. It is - System/Preferences/Hardware(?)/Keyboard(!)/General/ . FWIW: * Tue Feb 3 2009 Matthew Garrett - 2.24.1-9 - Default to a non-blinking cursor -- Matthew Garrett | mjg59 at srcf.ucam.org From kwizart at gmail.com Tue Feb 3 23:13:22 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Wed, 4 Feb 2009 00:13:22 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203211642.GA25276@ee.oulu.fi> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> Message-ID: 2009/2/3 Pekka Pietikainen : > On Tue, Feb 03, 2009 at 12:11:59PM -0500, Warren Togami wrote: >> Jakub recommended doing comparison tests of -m32 -march=i586 >> -mtune=generic vs. -m32 -march=i686 -mtune=generic with Spec2k and >> Spec2006 benchmark tools. Anyone interested in trying this? >> >> In related news, cebbert wants to do the following to the F-11 kernel: >> - Eliminate the current i686 kernel. >> - i686 hardware would get i686 PAE by default. >> - i586 kernel becomes i686, except without cmov. This is primarily so >> people don't complain when they realize they have the "i586" kernel. > Just a note, I believe that the ia32 support should "concentrate" on > netbooks (So Intel Atom), those are the only new things on the market > that can't run x86_64, and the userbase of those will just grow and > every percent of extra performance will make many people happy. > > A benchmark run on one of those might be very useful to make the final > decision, not that the more server-oriented tests are very useful for the > typical netbook userbase. > > And then there's the "should work even with this" decision, and i686 without > cmov is a reasonable minimum there. Could be i686+cmov or +sse2, but those > will make a lot of people unhappy. Does the right wording for this wouldn't be to move i586 to secondary architecture and welcome i686 with sse(2?) as the new default x86_32 and primary arch ? Having a project to build fews packages targeted as i586 and eventually using dietlibc for dhcp/dns server usage (other?) would be more valuable than having the fast majority of packages compiled with old options? Nicolas (kwizart) From dimi at lattica.com Tue Feb 3 23:13:53 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 18:13:53 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> Message-ID: <1233702833.8745.442.camel@dimi.lattica.com> On Tue, 2009-02-03 at 14:07 -0900, Jeff Spaleta wrote: > what other X apps have blinking cursors. did I miss a terminal > emulator of merit.? > All the other X based terminal emulators I just installed default to > no blink. I'm talking about any editor, not necessarily a terminal emulator. Just open a editor, create an email, etc. In any such window that expects input, the cursor blinks ONLY IF the window has the focus. Otherwise it doesn't. If the window has focus, you are doing something in there, so the blinking works well to tell you where the insertion point is. If you are just reading a PDF document as was suggested before, there isn't any blinking cursor anywhere so what are we saving? Why is it a good idea to treat terminals any different from any other editor waiting for your input? -- Dimi Paun Lattica, Inc. From nicolas.mailhot at laposte.net Tue Feb 3 23:16:30 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Feb 2009 00:16:30 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> Message-ID: <1233702990.28732.1.camel@arekh.okg> Le mardi 03 f?vrier 2009 ? 14:07 -0900, Jeff Spaleta a ?crit : > On Tue, Feb 3, 2009 at 2:03 PM, Dimi Paun wrote: > > Maybe. But I still don't see how you can eliminate the blinking > > cursor for all the other X apps. > > what other X apps have blinking cursors. A 5s check finds evolution, openoffice.org, pidgin That should cover a significant userbase -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From stickster at gmail.com Tue Feb 3 22:42:36 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 3 Feb 2009 17:42:36 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <5256d0b0902031433r50fce9c8qb6c4e4066d8a07af@mail.gmail.com> References: <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <5256d0b0902031433r50fce9c8qb6c4e4066d8a07af@mail.gmail.com> Message-ID: <20090203224236.GM28565@localhost.localdomain> On Tue, Feb 03, 2009 at 11:33:12PM +0100, Peter Robinson wrote: > >> > There's a reason it's been like this in like ... forever. > >> > Doesn't it strike you as strange to change one of the > >> > longest established conventions on a whim?!? > >> > >> Tradition is not an argument in fedora. > > > > Neither seems to be reason. > > TBH until recently I thought this problem had gone away. Shortly after > powertop came out the blinking cursor issue was identified as an issue > and I saw patches flying around to fix the problems. It wasn't until I > noticed OLPC was patching some part of the the gnome stack to fix the > issue that I realised that it was still an issue. Surely it can be > made some sort of "Cursor Blink" config option that is disabled by > default but allow the people that want blinking to enable it > relatively simply. There already is -- System > Prefs > Hardware > Keyboard -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mrmazda at ij.net Tue Feb 3 23:30:36 2009 From: mrmazda at ij.net (Felix Miata) Date: Tue, 03 Feb 2009 18:30:36 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233702990.28732.1.camel@arekh.okg> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> <1233702990.28732.1.camel@arekh.okg> Message-ID: <4988D39C.4060303@ij.net> On 2009/02/04 00:16 (GMT) Nicolas Mailhot composed: > Le mardi 03 f??vrier 2009 ? 14:07 -0900, Jeff Spaleta a ??crit : >> On Tue, Feb 3, 2009 at 2:03 PM, Dimi Paun wrote: >> > Maybe. But I still don't see how you can eliminate the blinking >> > cursor for all the other X apps. >> what other X apps have blinking cursors. > A 5s check finds evolution, openoffice.org, pidgin > That should cover a significant userbase Most of the rest are probably covered by web browsers: Google boxes and urlbars in the chrome, text areas and input boxes in the web pages. -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From jspaleta at gmail.com Tue Feb 3 23:32:45 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Feb 2009 14:32:45 -0900 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233702833.8745.442.camel@dimi.lattica.com> References: <1233620984.27307.16.camel@rosebud> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> <1233702833.8745.442.camel@dimi.lattica.com> Message-ID: <604aa7910902031532r313609fdvd4481038a54feacd@mail.gmail.com> On Tue, Feb 3, 2009 at 2:13 PM, Dimi Paun wrote: > I'm talking about any editor, not necessarily a terminal emulator. > Just open a editor, create an email, etc. Ah...gnome-calculator's cursor doesn't blink even when the line has focus. > Why is it a good idea to treat terminals any different from any > other editor waiting for your input? That is an argument for consistency...not an argument for tradition. I can most definitely support consistency. I'm not arguing that terminals should be different than other apps. If its worth taking out the blinking cursor in the terminal its worth doing it it consistently..assuming it saves power to turn off the blink as seen in other places. I find the blinking cursor to be redundant in applications like abiword or firefox. As soon as an entry gains focus..the cursor shows up. The presence of the cursor is itself indication that input is accepted in that entry area...the blinking is not the primary indicator..the cursor is. -jef From caolanm at redhat.com Tue Feb 3 23:39:03 2009 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Tue, 03 Feb 2009 23:39:03 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233702990.28732.1.camel@arekh.okg> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> <1233702990.28732.1.camel@arekh.okg> Message-ID: <1233704343.22717.18.camel@Vain> On Wed, 2009-02-04 at 00:16 +0100, Nicolas Mailhot wrote: > Le mardi 03 f?vrier 2009 ? 14:07 -0900, Jeff Spaleta a ?crit : > > On Tue, Feb 3, 2009 at 2:03 PM, Dimi Paun wrote: > > > > Maybe. But I still don't see how you can eliminate the blinking > > > cursor for all the other X apps. > > > > what other X apps have blinking cursors. > > A 5s check finds ... openoffice.org, ... vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx // get cursor blink time GtkSettings *pSettings = gtk_widget_get_settings( gWidgetData[m_nScreen].gEditBoxWidget ); gboolean blink = false; g_object_get( pSettings, "gtk-cursor-blink", &blink, (char *)NULL ); if!( blink ) aStyleSet.SetCursorBlinkTime( STYLE_CURSOR_NOBLINKTIME ); else ... If gtk doesn't blink the cursor then OOo shouldn't blink either, in theory at least. C. From tibbs at math.uh.edu Tue Feb 3 23:40:33 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Feb 2009 17:40:33 -0600 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: >>>>> "JJ" == Jakub Jelinek writes: JJ> - 30 failures JJ> Unsorted stuff that succeeds to build with 4.3 and fails to build JJ> with 4.4. Unfortunately this includes my package xu4, and while I do have some C++ experience (college was some time ago), the exact reason this has just started failing with 4.4 is eluding me. The code does this: /** * An abstract interface for file access. */ class U4FILE { public: virtual ~U4FILE() {} virtual void close() = 0; virtual int seek(long offset, int whence) = 0; virtual long tell() = 0; virtual size_t read(void *ptr, size_t size, size_t nmemb) = 0; virtual int getc() = 0; virtual int putc(int c) = 0; virtual long length() = 0; int getshort(); }; which, while fine in GCC 4.3, produces this with GCC 4.4: u4file.h:66:27: error: macro "putc" requires 2 arguments, but only 1 given u4file.h:66: error: ISO C++ forbids initialization of member 'putc' u4file.h:66: error: making 'putc' static u4file.h:66: error: ISO C++ forbids in-class initialization of non-const static member 'putc' u4file.h:66: error: 'putc' declared as a 'virtual' field The purpose is to inherit from this base class and replace some methods with variants that transparently operate on zip files. I'm guessing here that putc has become a macro and that I need to rename the putc member, but that mightn't be a small patch so I figured I'd check for a simpler way before trying to hack that up. - J< From wtogami at redhat.com Tue Feb 3 23:45:14 2009 From: wtogami at redhat.com (Warren Togami) Date: Tue, 03 Feb 2009 18:45:14 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203211642.GA25276@ee.oulu.fi> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> Message-ID: <4988D70A.3090303@redhat.com> Pekka Pietikainen wrote: > Just a note, I believe that the ia32 support should "concentrate" on > netbooks (So Intel Atom), those are the only new things on the market > that can't run x86_64, and the userbase of those will just grow and > every percent of extra performance will make many people happy. > This is a silly notion. Atom requires code to be built entirely differently from all modern processors in order to get maximum performance. Code must be optimized for in-line performance. Atom target support hasn't even hit gcc-4.4 yet. When it does though, I think a mini-repo of atom optimized core libraries might make a difference for Atom users. Warren Togami wtogami at redhat.com From kevin at scrye.com Tue Feb 3 23:48:38 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 3 Feb 2009 16:48:38 -0700 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> Message-ID: <20090203164838.15fba37f@ohm.scrye.com> On Tue, 3 Feb 2009 14:07:57 -0900 Jeff Spaleta wrote: > On Tue, Feb 3, 2009 at 2:03 PM, Dimi Paun wrote: ...snip... > > > Maybe. But I still don't see how you can eliminate the blinking > > cursor for all the other X apps. > > what other X apps have blinking cursors. did I miss a terminal > emulator of merit.? Yes. The Xfce "Terminal" package. In Terminal, you would have to edit the terminalrc file directly to enable blinking cursor. It's not a pref thats exposed to the users via the preference menu. > All the other X based terminal emulators I just installed default to > no blink. As does Terminal. > -jef kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From konrad at tylerc.org Wed Feb 4 00:07:41 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Tue, 3 Feb 2009 16:07:41 -0800 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <1233701416.26332.26.camel@arekh.okg> References: <1233701416.26332.26.camel@arekh.okg> Message-ID: <200902031607.41674.konrad@tylerc.org> On Tuesday 03 February 2009 02:50:16 pm Nicolas Mailhot wrote: > Dear all, > > Yesterday I took the time to find the current address of a well-known > Georgian font creator, Besarion Paata Gugushvili. Our current Georgian > support is rather limited: one set of glyphs in Dejavu, and nothing else > (This set was created by the very same author BTW). Imagine using the > same font all day long everywhere :( Is that really a depressing thought to you? (I use the same font everywhere, all the time.) All the same, I'm glad of the effort you put into contacting him and getting the upstream package in a position that it can be entered into Fedora, as well as grateful for all the work you've put into the Fonts SIG. Regards, -- Conrad Meyer From ivazqueznet at gmail.com Wed Feb 4 00:12:58 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 03 Feb 2009 19:12:58 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <1233706378.26470.74.camel@ignacio.lan> On Tue, 2009-02-03 at 17:40 -0600, Jason L Tibbitts III wrote: > which, while fine in GCC 4.3, produces this with GCC 4.4: > u4file.h:66:27: error: macro "putc" requires 2 arguments, but only 1 given > u4file.h:66: error: ISO C++ forbids initialization of member 'putc' > u4file.h:66: error: making 'putc' static > u4file.h:66: error: ISO C++ forbids in-class initialization of non-const static member 'putc' > u4file.h:66: error: 'putc' declared as a 'virtual' field > > The purpose is to inherit from this base class and replace some > methods with variants that transparently operate on zip files. I'm > guessing here that putc has become a macro and that I need to rename > the putc member, but that mightn't be a small patch so I figured I'd > check for a simpler way before trying to hack that up. You can try #undef'ing it, but I don't know how much evil that's going to do elsewhere. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed Feb 4 00:27:56 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Feb 2009 01:27:56 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233697189.3238.17.camel@rosebud> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> Message-ID: <4988E10C.20002@freenet.de> seth vidal wrote: > On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: >> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: >>> I fail to see how a solid cursor is that much harder to find than >>> a blinking one. Unless you're only entering solid boxes as text? >> There's a reason it's been like this in like ... forever. >> Doesn't it strike you as strange to change one of the >> longest established conventions on a whim?!? > > Tradition is not an argument in fedora. Sometimes traditions have good reasons - There are reasons why wheels are shaped round and not rectangular. From mrmazda at ij.net Wed Feb 4 00:28:15 2009 From: mrmazda at ij.net (Felix Miata) Date: Tue, 03 Feb 2009 19:28:15 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031532r313609fdvd4481038a54feacd@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> <1233702833.8745.442.camel@dimi.lattica.com> <604aa7910902031532r313609fdvd4481038a54feacd@mail.gmail.com> Message-ID: <4988E11F.70005@ij.net> On 2009/02/03 14:32 (GMT-0900) Jeff Spaleta composed: > I find the blinking cursor to be redundant in applications like > abiword or firefox. As soon as an entry gains focus..the cursor shows > up. The presence of the cursor is itself indication that input is > accepted in that entry area...the blinking is not the primary > indicator..the cursor is. Don't say that to a Mozilla programmer. They call the cursor a caret, both in public, and in source code. :-p -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From rc040203 at freenet.de Wed Feb 4 00:29:05 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Feb 2009 01:29:05 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233691661.22804.14.camel@arekh.okg> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> Message-ID: <4988E151.2000404@freenet.de> Nicolas Mailhot wrote: > Le mardi 03 f?vrier 2009 ? 17:24 +0100, Tomasz Torcz a ?crit : > >> Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 >> could go to 10,3W when idle > > But when it's idle, you are in screensaver or blank screen with no > cursor anyway. The "wins" are massively overhyped, Agreed. I think it's time to demand measurement procedures such that people can reproduce this claim. Ralf# From seg at haxxed.com Wed Feb 4 00:29:20 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Feb 2009 18:29:20 -0600 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203185801.GB2631@nostromo.devel.redhat.com> References: <49887ADF.9090606@redhat.com> <20090203185801.GB2631@nostromo.devel.redhat.com> Message-ID: <1233707360.17218.354.camel@localhost.localdomain> On Tue, 2009-02-03 at 13:58 -0500, Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > > i686 to i686 w/ SSE2 would be a performance win, but that is > > clearly not an option for Fedora. > > Well, I think this is debatable. The i686 CPUs without SSE2 (Pentium III > and earlier, 32-bit Athlon) are generally older and haven't been sold > for even longer than the C3 and similar processors that were a concern > for i586. They are likely to have a much larger userbase, though, so I > can seee still supporting them. Uhhh, I still actively use a Celeron 1.3 laptop (P3 core), and an Athlon 1.4ghz. (Thunderbird core, no SSE) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Feb 4 00:34:57 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 03 Feb 2009 18:34:57 -0600 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203185310.GD5846@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> Message-ID: <1233707697.17218.364.camel@localhost.localdomain> On Tue, 2009-02-03 at 19:53 +0100, Dominik 'Rathann' Mierzejewski wrote: > > i686 to i686 w/ SSE2 would be a performance win, but that is > > clearly not an option for Fedora. > > SSE2-optimized libraries can be built and installed into /usr/lib/sse2. > Our ld.so already supports that. Why does SSE2 get this treatment, and not SSE? I've found SSE much more useful, and more common. SSE2 pretty much means P4 only on i386, Athlons didn't get SSE2 until the Athlon 64 and those should be running x86-64 anyway. Whereas there's a lot of Pentium 3s and Athlon XPs with SSE out there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From darrellpf at gmail.com Wed Feb 4 00:36:37 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 3 Feb 2009 16:36:37 -0800 Subject: devkit bugzilla component? Message-ID: I don't see a bugzilla component for devkit. How do I file a bug against it? devkit-power-daemon is being a bit silly about its cpu usage (lots of polling of /proc/timer_stats) or somebody is being silly about calling it. Tasks: 161 total, 2 running, 159 sleeping, 0 stopped, 0 zombie Cpu(s): 12.1%us, 11.1%sy, 0.0%ni, 76.7%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4071136k total, 3296084k used, 775052k free, 301716k buffers Swap: 2031608k total, 0k used, 2031608k free, 2112344k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32134 darrell 20 0 428m 159m 26m R 9.6 4.0 2:10.84 firefox 27812 root 20 0 375m 59m 10m S 5.0 1.5 1:53.90 Xorg 2928 root 20 0 4792 2556 1868 S 1.3 0.1 6:18.11 devkit-power-da (on a system that has been up 22 minutes) darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at greysector.net Wed Feb 4 00:40:10 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 4 Feb 2009 01:40:10 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203210807.GE10541@yoda.jdub.homelinux.org> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> <20090203205241.GD10541@yoda.jdub.homelinux.org> <20090203205740.GC10874@mokona.greysector.net> <20090203210807.GE10541@yoda.jdub.homelinux.org> Message-ID: <20090204004009.GD10874@mokona.greysector.net> On Tuesday, 03 February 2009 at 22:08, Josh Boyer wrote: > On Tue, Feb 03, 2009 at 09:57:40PM +0100, Dominik 'Rathann' Mierzejewski wrote: > >On Tuesday, 03 February 2009 at 21:52, Josh Boyer wrote: > >> On Tue, Feb 03, 2009 at 09:45:46PM +0100, Dominik 'Rathann' Mierzejewski wrote: > >[...] > >> >Well, I talk to people who write hand-optimized assembly and care to > >> >squeeze every cycle out of various CPUs and they say it's definitely > >> >a win. So please, show me some code instead of hand-waving. > >> > >> If they can do that, then why can't they rebuild things themselves? > > > >Oh, right. Let's all use LFS or Gentoo. > >Why can't everyone rebuild things themselves? > > They can. > > Look, it's very simple. Fedora _cannot_ be everything to everyone. There > are too many variations, optimizations, etc. So, in light of that, it > tries to fit the best usecase. The common ground. > > People that hand code assembly files are _not_ the common users of Fedora. I know. I'm just saying Ulrich's statement about "cmov not being a win" is not convincing without some code samples. I, on the other hand, can point you to x264 cabac asm code, which uses cmov to attain 8%(p4) to 25%(core2) speedups. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at gmail.com Wed Feb 4 00:46:01 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 19:46:01 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4988E151.2000404@freenet.de> References: <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> Message-ID: <20090204004601.GA19254@yoda.jdub.homelinux.org> On Wed, Feb 04, 2009 at 01:29:05AM +0100, Ralf Corsepius wrote: > Nicolas Mailhot wrote: >> Le mardi 03 f?vrier 2009 ? 17:24 +0100, Tomasz Torcz a ?crit : >> >>> Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 >>> could go to 10,3W when idle >> >> But when it's idle, you are in screensaver or blank screen with no >> cursor anyway. The "wins" are massively overhyped, > Agreed. > > I think it's time to demand measurement procedures such that people can > reproduce this claim. Those were already provided. josh From mclasen at redhat.com Wed Feb 4 00:47:35 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 3 Feb 2009 19:47:35 -0500 (EST) Subject: devkit bugzilla component? In-Reply-To: Message-ID: <35545489.4075061233708455187.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> > I don't see a bugzilla component for devkit. How do I file a bug against it? File a bug against bugzilla, I think. It is broken and doesn't show all available components. From dominik at greysector.net Wed Feb 4 00:49:42 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 4 Feb 2009 01:49:42 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> Message-ID: <20090204004942.GE10874@mokona.greysector.net> On Tuesday, 03 February 2009 at 22:31, Gregory Maxwell wrote: > On Tue, Feb 3, 2009 at 3:45 PM, Dominik 'Rathann' Mierzejewski wrote: > > So please, show me some code instead of hand-waving. > > ? I did post benchmarks of libTheora showing a 0.2% gain on core2 from > cmov. Perhaps you'd care to benchmark freetype? That's what I intend to do. Is ftbench good enough? I'll post some results tomorrow. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From tcallawa at redhat.com Wed Feb 4 00:49:35 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Feb 2009 19:49:35 -0500 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <1233701416.26332.26.camel@arekh.okg> References: <1233701416.26332.26.camel@arekh.okg> Message-ID: <4988E61F.8070909@redhat.com> On 2009-02-03 at 17:50:16 -0500, Nicolas Mailhot wrote: > Therefore, I'm doing a public call on Fedora lists, for someone to > package those, and prove Besarion Paata Gugushvili was right to trust > Fedora. Packaged. Awaiting review: https://bugzilla.redhat.com/show_bug.cgi?id=483865 ~spot From tromey at redhat.com Wed Feb 4 00:53:50 2009 From: tromey at redhat.com (Tom Tromey) Date: Tue, 03 Feb 2009 17:53:50 -0700 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> (Jeff Spaleta's message of "Tue\, 3 Feb 2009 14\:07\:57 -0900") References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <1233702180.8745.435.camel@dimi.lattica.com> <604aa7910902031507w4d8899d1m99e031dbd772328e@mail.gmail.com> Message-ID: >>>>> "Jeff" == Jeff Spaleta writes: Jeff> what other X apps have blinking cursors. Emacs blinks by default. This page is handy for anybody who doesn't like blinking cursors: http://www.jurta.org/en/prog/noblink It points out a number of different applications. Basically, each GUI toolkit has its own setting for this. Tom From jkeating at redhat.com Wed Feb 4 00:52:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 03 Feb 2009 16:52:49 -0800 Subject: devkit bugzilla component? In-Reply-To: References: Message-ID: <1233708769.7493.103.camel@localhost.localdomain> On Tue, 2009-02-03 at 16:36 -0800, darrell pfeifer wrote: > devkit-power-daemon That executable comes from the DeviceKit-power source rpm (rpm -qfi /usr/libexec/devkit-power-daemon) File your bug against the DeviceKit-power component in bugzilla. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Wed Feb 4 00:56:16 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 4 Feb 2009 01:56:16 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <1233707697.17218.364.camel@localhost.localdomain> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <1233707697.17218.364.camel@localhost.localdomain> Message-ID: <20090204005616.GF10874@mokona.greysector.net> On Wednesday, 04 February 2009 at 01:34, Callum Lerwick wrote: > On Tue, 2009-02-03 at 19:53 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > i686 to i686 w/ SSE2 would be a performance win, but that is > > > clearly not an option for Fedora. > > > > SSE2-optimized libraries can be built and installed into /usr/lib/sse2. > > Our ld.so already supports that. > > Why does SSE2 get this treatment, and not SSE? I've found SSE much more > useful, and more common. SSE2 pretty much means P4 only on i386, Athlons > didn't get SSE2 until the Athlon 64 and those should be running x86-64 > anyway. Whereas there's a lot of Pentium 3s and Athlon XPs with SSE out > there. I was wondering about the same thing. There's little to no documentation on this subject so I had to dig into glibc sources to see how it works. Apparently, glibc distinguishes some "features" for CPUs and those that are "major" can have separate directories with optimized libraries. In Fedora, "major" features are "i686" and "sse2". Whereas in Debian, it's just "cmov", apparently. Can anyone shed more light here? Jakub? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From cra at WPI.EDU Wed Feb 4 00:58:49 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 3 Feb 2009 19:58:49 -0500 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233699392.11676.10.camel@choeger5.umpa.netz> References: <1233699392.11676.10.camel@choeger5.umpa.netz> Message-ID: <20090204005849.GG29934@angus.ind.WPI.EDU> On Tue, Feb 03, 2009 at 11:16:32PM +0100, Christoph H?ger wrote: > Among other criticisms one thing was really annoying: When a user > installs fedora on a machine with windows installed (common use case) it > detects that installation and offers to add it to grub. But installing > fedora on a box with an already present linux distro installation will > yield that installation removed from grub. ... > Any thoughts on that? 1. I think we should always install grub to the /boot partition's boot sector, no matter what. That should be completely safe, because we "own" /boot and sharing a single /boot between different OS installs isn't really supported anyway. 2. We can certainly continue to ask the user whether we should additionally install grub to the MBR. We could use user-friendly terms like "Install system-wide multi-boot menu", or similar. 3. Then anaconda could present a list of partitions it finds that contain bootable boot sectors and offer to add them to the grub menu. 4. If we can get all the other distros to do the same, this will open the door to easy multi-booting. From jwboyer at gmail.com Wed Feb 4 00:55:18 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 19:55:18 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204004009.GD10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> <20090203204545.GB10874@mokona.greysector.net> <20090203205241.GD10541@yoda.jdub.homelinux.org> <20090203205740.GC10874@mokona.greysector.net> <20090203210807.GE10541@yoda.jdub.homelinux.org> <20090204004009.GD10874@mokona.greysector.net> Message-ID: <20090204005518.GB20142@yoda.jdub.homelinux.org> On Wed, Feb 04, 2009 at 01:40:10AM +0100, Dominik 'Rathann' Mierzejewski wrote: >On Tuesday, 03 February 2009 at 22:08, Josh Boyer wrote: >> On Tue, Feb 03, 2009 at 09:57:40PM +0100, Dominik 'Rathann' Mierzejewski wrote: >> >On Tuesday, 03 February 2009 at 21:52, Josh Boyer wrote: >> >> On Tue, Feb 03, 2009 at 09:45:46PM +0100, Dominik 'Rathann' Mierzejewski wrote: >> >[...] >> >> >Well, I talk to people who write hand-optimized assembly and care to >> >> >squeeze every cycle out of various CPUs and they say it's definitely >> >> >a win. So please, show me some code instead of hand-waving. >> >> >> >> If they can do that, then why can't they rebuild things themselves? >> > >> >Oh, right. Let's all use LFS or Gentoo. >> >Why can't everyone rebuild things themselves? >> >> They can. >> >> Look, it's very simple. Fedora _cannot_ be everything to everyone. There >> are too many variations, optimizations, etc. So, in light of that, it >> tries to fit the best usecase. The common ground. >> >> People that hand code assembly files are _not_ the common users of Fedora. > >I know. I'm just saying Ulrich's statement about "cmov not being a win" >is not convincing without some code samples. I, on the other hand, can >point you to x264 cabac asm code, which uses cmov to attain 8%(p4) >to 25%(core2) speedups. I can believe that. So why can't you build that codec code with the proper flags to include the support you need? Ulrich's statement was about the general case again. Throwing around specific examples as counter points isn't going to be very productive unless those examples _are_ the general cases. josh From darrellpf at gmail.com Wed Feb 4 01:04:26 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 3 Feb 2009 17:04:26 -0800 Subject: devkit bugzilla component? In-Reply-To: <1233708769.7493.103.camel@localhost.localdomain> References: <1233708769.7493.103.camel@localhost.localdomain> Message-ID: 2009/2/3 Jesse Keating > On Tue, 2009-02-03 at 16:36 -0800, darrell pfeifer wrote: > > devkit-power-daemon > > That executable comes from the DeviceKit-power source rpm (rpm > -qfi /usr/libexec/devkit-power-daemon) > > File your bug against the DeviceKit-power component in bugzilla. > My problem is that I am unable to find that component in bugzilla. I checked before the initial post, and I just checked again... both in the capital "D"s and the lower case "d"'s, but I don't see it there) darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Wed Feb 4 01:05:32 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 20:05:32 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204005616.GF10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <1233707697.17218.364.camel@localhost.localdomain> <20090204005616.GF10874@mokona.greysector.net> Message-ID: <20090204010532.GC20142@yoda.jdub.homelinux.org> On Wed, Feb 04, 2009 at 01:56:16AM +0100, Dominik 'Rathann' Mierzejewski wrote: >On Wednesday, 04 February 2009 at 01:34, Callum Lerwick wrote: >> On Tue, 2009-02-03 at 19:53 +0100, Dominik 'Rathann' Mierzejewski wrote: >> > > i686 to i686 w/ SSE2 would be a performance win, but that is >> > > clearly not an option for Fedora. >> > >> > SSE2-optimized libraries can be built and installed into /usr/lib/sse2. >> > Our ld.so already supports that. >> >> Why does SSE2 get this treatment, and not SSE? I've found SSE much more >> useful, and more common. SSE2 pretty much means P4 only on i386, Athlons >> didn't get SSE2 until the Athlon 64 and those should be running x86-64 >> anyway. Whereas there's a lot of Pentium 3s and Athlon XPs with SSE out >> there. > >I was wondering about the same thing. There's little to no documentation >on this subject so I had to dig into glibc sources to see how it works. >Apparently, glibc distinguishes some "features" for CPUs and those that >are "major" can have separate directories with optimized libraries. >In Fedora, "major" features are "i686" and "sse2". Whereas in Debian, >it's just "cmov", apparently. > >Can anyone shed more light here? Jakub? It extends to other architectures as well, fwiw. On PowerPC, you can have optimized libraries for ppc970,power4,power5,power6, and cell I believe. For Fedora, optimized libraries are built for power6/power6x. josh From rc040203 at freenet.de Wed Feb 4 01:13:18 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Feb 2009 02:13:18 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090204004601.GA19254@yoda.jdub.homelinux.org> References: <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> Message-ID: <4988EBAE.5040708@freenet.de> Josh Boyer wrote: > On Wed, Feb 04, 2009 at 01:29:05AM +0100, Ralf Corsepius wrote: >> Nicolas Mailhot wrote: >>> Le mardi 03 f?vrier 2009 ? 17:24 +0100, Tomasz Torcz a ?crit : >>> >>>> Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 >>>> could go to 10,3W when idle >>> But when it's idle, you are in screensaver or blank screen with no >>> cursor anyway. The "wins" are massively overhyped, >> Agreed. >> >> I think it's time to demand measurement procedures such that people can >> reproduce this claim. > > Those were already provided. Are you referring to Felix Miata's table? To me these read more as a joke but real defined testing scenarios. Ralf From ivazqueznet at gmail.com Wed Feb 4 01:17:30 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 03 Feb 2009 20:17:30 -0500 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <20090204005849.GG29934@angus.ind.WPI.EDU> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> Message-ID: <1233710250.26470.77.camel@ignacio.lan> On Tue, 2009-02-03 at 19:58 -0500, Chuck Anderson wrote: > 1. I think we should always install grub to the /boot partition's boot > sector, no matter what. That should be completely safe, because we > "own" /boot and sharing a single /boot between different OS installs > isn't really supported anyway. I would posit that we should only do this if we format /boot. Otherwise it would need to be explicitly requested. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Wed Feb 4 01:20:16 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 3 Feb 2009 20:20:16 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4988EBAE.5040708@freenet.de> References: <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> Message-ID: <20090204012016.GD20142@yoda.jdub.homelinux.org> On Wed, Feb 04, 2009 at 02:13:18AM +0100, Ralf Corsepius wrote: > Josh Boyer wrote: >> On Wed, Feb 04, 2009 at 01:29:05AM +0100, Ralf Corsepius wrote: >>> Nicolas Mailhot wrote: >>>> Le mardi 03 f?vrier 2009 ? 17:24 +0100, Tomasz Torcz a ?crit : >>>> >>>>> Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 >>>>> could go to 10,3W when idle >>>> But when it's idle, you are in screensaver or blank screen with no >>>> cursor anyway. The "wins" are massively overhyped, >>> Agreed. >>> >>> I think it's time to demand measurement procedures such that people >>> can reproduce this claim. >> >> Those were already provided. > Are you referring to Felix Miata's table? > > To me these read more as a joke but real defined testing scenarios. No. Matthew already outlined exactly how he took his measurements. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html josh From cra at WPI.EDU Wed Feb 4 01:23:05 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 3 Feb 2009 20:23:05 -0500 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233710250.26470.77.camel@ignacio.lan> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233710250.26470.77.camel@ignacio.lan> Message-ID: <20090204012305.GH29934@angus.ind.WPI.EDU> On Tue, Feb 03, 2009 at 08:17:30PM -0500, Ignacio Vazquez-Abrams wrote: > On Tue, 2009-02-03 at 19:58 -0500, Chuck Anderson wrote: > > 1. I think we should always install grub to the /boot partition's boot > > sector, no matter what. That should be completely safe, because we > > "own" /boot and sharing a single /boot between different OS installs > > isn't really supported anyway. > > I would posit that we should only do this if we format /boot. Otherwise > it would need to be explicitly requested. Sure, makes perfect sense. From bdwheele at indiana.edu Wed Feb 4 01:43:06 2009 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 03 Feb 2009 20:43:06 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> Message-ID: <1233711786.11436.4.camel@localhost.localdomain> On Tue, 2009-02-03 at 13:37 -0900, Jeff Spaleta wrote: > On Tue, Feb 3, 2009 at 1:22 PM, Dimi Paun wrote: > > > > We might as well change the slogan to: > > > > Fedora: stupid and proud of it! > > I would appreciate it if you tried to keep this discussion civil. > > > right now on my F10 system > > xterm defaults to no blink > konsole defaults to no blink > aterm defaults to no blink > Eterm defaults to no blink > rxvt defaults to no blink > > gnome-terminal defaults to blink > > I do not think traditional terminal operation makes a strong argument > in the scope of this discussion in the light of the fact that other > terminal emulators with codebase lifetimes as long or longer than > gnome-terminal/libvte already default to no blink in F10. > > If anything.. gnome-terminal is the odd man out and there is an > argument to be made to bring it into line with the common default > behaviour of other virtual terminals. > > -jef"unless my defaults are screwed up of course"spaleta > Not really on topic, but food for thought... I powered up my DEC VT420 and the cursor doesn't blink on it. I don't know if that was the default setting, but I've not changed it...but there is a setting for it. I can't say I ever noticed it not blinking. Brian From mjg at redhat.com Wed Feb 4 01:56:34 2009 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 4 Feb 2009 01:56:34 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4988E151.2000404@freenet.de> References: <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> Message-ID: <20090204015634.GA25543@srcf.ucam.org> On Wed, Feb 04, 2009 at 01:29:05AM +0100, Ralf Corsepius wrote: > I think it's time to demand measurement procedures such that people can > reproduce this claim. Could we calm down a little on the "demand" front? I've posted an explanation of what I did earlier in the thread. I'm not really sure how I could be more transparent here. -- Matthew Garrett | mjg59 at srcf.ucam.org From rc040203 at freenet.de Wed Feb 4 01:59:10 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Feb 2009 02:59:10 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090204012016.GD20142@yoda.jdub.homelinux.org> References: <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> Message-ID: <4988F66E.30701@freenet.de> Josh Boyer wrote: > On Wed, Feb 04, 2009 at 02:13:18AM +0100, Ralf Corsepius wrote: >> Josh Boyer wrote: >>> On Wed, Feb 04, 2009 at 01:29:05AM +0100, Ralf Corsepius wrote: >>>> Nicolas Mailhot wrote: >>>>> Le mardi 03 f?vrier 2009 ? 17:24 +0100, Tomasz Torcz a ?crit : >>>>> >>>>>> Uhm, sorry? The talk was of about 1-2W. Given that my Thinkpad T400 >>>>>> could go to 10,3W when idle >>>>> But when it's idle, you are in screensaver or blank screen with no >>>>> cursor anyway. The "wins" are massively overhyped, >>>> Agreed. >>>> >>>> I think it's time to demand measurement procedures such that people >>>> can reproduce this claim. >>> Those were already provided. >> Are you referring to Felix Miata's table? >> >> To me these read more as a joke but real defined testing scenarios. > > No. Matthew already outlined exactly how he took his measurements. > > https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html OK, he measured a random sample in a single setup, without providing details of what he actually did - Without providing these details, it's just one sample without much significance. He did not specify which software was running, what with this machine during the measurement etc. Also: 1-2W of ca. 100W is 1-2% of the absolute value. If the measurement device should be this http://www.powermeterstore.com/p1206/watts_up_pro.php?p_tab=specs which is specified to have an accuracy of "+/- 3% (loads above 10 watts)", then this measurement is below the accuracy of the device and not much more but a "tendency". Ralf From hanpingtian at gmail.com Wed Feb 4 02:02:31 2009 From: hanpingtian at gmail.com (=?GB2312?B?xr3M7Lqr?=) Date: Wed, 4 Feb 2009 10:02:31 +0800 Subject: Why do we disable esd in libgnome? In-Reply-To: <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> Message-ID: <3528361a0902031802w2a846e2ax1098271089c7edbf@mail.gmail.com> 2009/2/4 Dan Nicholson > On Tue, Feb 3, 2009 at 2:10 PM, Linus Walleij wrote: > >> I'm talking > >> about making an API that exists in the platform continue to work until > >> it can be removed. > > > > It can be removed now. Convert apps over to libcanberra. > > You can't remove it. That would break the API, something that GNOME will > not do. > > Again... > > Porting apps to libcanberra is the right thing to do. Convert every > single one you find. But, gnome_sound_play is in the platform until > GNOME-3.0 comes along and API can be broken. In that case, why not > have gnome_sound_play actually do something useful since it's dead > simple to do it? > Agree. I think we shouldn't force apps to use new API by disable old API which works fine. > > -- > Dan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Wed Feb 4 02:03:07 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 03 Feb 2009 21:03:07 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4988F66E.30701@freenet.de> References: <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> <4988F66E.30701@freenet.de> Message-ID: <1233712987.3238.19.camel@rosebud> On Wed, 2009-02-04 at 02:59 +0100, Ralf Corsepius wrote: > OK, he measured a random sample in a single setup, without providing > details of what he actually did - Without providing these details, it's > just one sample without much significance. > > He did not specify which software was running, what with this machine > during the measurement etc. > > Also: 1-2W of ca. 100W is 1-2% of the absolute value. > If the measurement device should be this > http://www.powermeterstore.com/p1206/watts_up_pro.php?p_tab=specs > which is specified to have an accuracy of > "+/- 3% (loads above 10 watts)", > then this measurement is below the accuracy of the device and not much > more but a "tendency". Yes, I think we should definitely have this kind of discussion before we change any code. Figure for each 1 line of code we need to have at least 30 messages about it. We'll be just like the folks who write code for airplanes. :) -sv From jkeating at redhat.com Wed Feb 4 02:03:02 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 03 Feb 2009 18:03:02 -0800 Subject: devkit bugzilla component? In-Reply-To: References: <1233708769.7493.103.camel@localhost.localdomain> Message-ID: <1233712982.7493.136.camel@localhost.localdomain> On Tue, 2009-02-03 at 17:04 -0800, darrell pfeifer wrote: > My problem is that I am unable to find that component in bugzilla. I checked > before the initial post, and I just checked again... both in the capital > "D"s and the lower case "d"'s, but I don't see it there) https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=DeviceKit-power ? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bdwheele at indiana.edu Wed Feb 4 02:06:42 2009 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 03 Feb 2009 21:06:42 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4988E10C.20002@freenet.de> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> Message-ID: <1233713202.11436.5.camel@localhost.localdomain> On Wed, 2009-02-04 at 01:27 +0100, Ralf Corsepius wrote: > seth vidal wrote: > > On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: > >> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: > >>> I fail to see how a solid cursor is that much harder to find than > >>> a blinking one. Unless you're only entering solid boxes as text? > >> There's a reason it's been like this in like ... forever. > >> Doesn't it strike you as strange to change one of the > >> longest established conventions on a whim?!? > > > > Tradition is not an argument in fedora. > > Sometimes traditions have good reasons - There are reasons why wheels > are shaped round and not rectangular. Just as a nitpick, wheels are round for a technical reason, not because of tradition. From darrellpf at gmail.com Wed Feb 4 02:41:12 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 3 Feb 2009 18:41:12 -0800 Subject: devkit bugzilla component? In-Reply-To: <1233712982.7493.136.camel@localhost.localdomain> References: <1233708769.7493.103.camel@localhost.localdomain> <1233712982.7493.136.camel@localhost.localdomain> Message-ID: 2009/2/3 Jesse Keating > On Tue, 2009-02-03 at 17:04 -0800, darrell pfeifer wrote: > > My problem is that I am unable to find that component in bugzilla. I > checked > > before the initial post, and I just checked again... both in the capital > > "D"s and the lower case "d"'s, but I don't see it there) > > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=DeviceKit-power ? > Got it, thanks. For those of us who search for existing bugs before entering a new one... https://bugzilla.redhat.com/query.cgi?format=advanced devicekit isn't listed. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Wed Feb 4 03:09:50 2009 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 03 Feb 2009 22:09:50 -0500 Subject: Why do we disable esd in libgnome? In-Reply-To: <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> Message-ID: <498906FE.9090107@redhat.com> On 02/03/2009 05:34 PM, Dan Nicholson wrote: > Again... > > Porting apps to libcanberra is the right thing to do. Convert every > single one you find. But, gnome_sound_play is in the platform until > GNOME-3.0 comes along and API can be broken. In that case, why not > have gnome_sound_play actually do something useful since it's dead > simple to do it? It's pretty useful to have gnome_sound_play do what it's doing now. It's making people ask how to make sound work again, and they are learning about the right way to do it with libcanberra. Being realistic, people will never change unless they have to. Whether that happens now, or in GNOME 3.0 is pretty much irrelevant. It has to happen sometime, might as well be now. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 4 03:19:10 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 04 Feb 2009 12:19:10 +0900 Subject: devkit bugzilla component? In-Reply-To: References: <1233708769.7493.103.camel@localhost.localdomain> <1233712982.7493.136.camel@localhost.localdomain> Message-ID: <4989092E.1030802@ioa.s.u-tokyo.ac.jp> darrell pfeifer wrote, at 02/04/2009 11:41 AM +9:00: > > > 2009/2/3 Jesse Keating > > On Tue, 2009-02-03 at 17:04 -0800, darrell pfeifer wrote: > > My problem is that I am unable to find that component in > bugzilla. I checked > > before the initial post, and I just checked again... both in the > capital > > "D"s and the lower case "d"'s, but I don't see it there) > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=DeviceKit-power > > ? > Got it, thanks. > For those of us who search for existing bugs before entering a new one... > https://bugzilla.redhat.com/query.cgi?format=advanced > devicekit isn't listed. I guess you are seeing this issue: https://bugzilla.redhat.com/show_bug.cgi?id=479725 Select "Fedora" in "Classification" and then push "Refresh Components/Versions/Milestones" (below Product) Regards, Mamoru From dimi at lattica.com Wed Feb 4 03:33:52 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 22:33:52 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090204012016.GD20142@yoda.jdub.homelinux.org> References: <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> Message-ID: <1233718432.8745.461.camel@dimi.lattica.com> On Tue, 2009-02-03 at 20:20 -0500, Josh Boyer wrote: > No. Matthew already outlined exactly how he took his measurements. > > https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html The problem with this measurement is that it measures max wattage when the cursor blinks. But for a typical user browsing, reading documents, reading email, etc. the cursor blinks a tiny portion of the time, only when they _write_ an email. I'd venture to say <10%. If that is so we're looking at a saving of about 0.2W for a typical user. Is this enough to flip the default? Here's another proposal: during first boot prompt the user to change the default to no-blink, explain the benefits, tell them how to switch back if they don't care for it. This way nobody will get frustrated or will be surprised their system no longer works the way they expect it to. I know it is more work, but this affects an important UI behavior. If 0.2W is not all that important to justify the work, lets drop it. -- Dimi Paun Lattica, Inc. From oget.fedora at gmail.com Wed Feb 4 03:45:42 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 3 Feb 2009 22:45:42 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233718432.8745.461.camel@dimi.lattica.com> References: <1233628485.8745.361.camel@dimi.lattica.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> <1233718432.8745.461.camel@dimi.lattica.com> Message-ID: On Tue, Feb 3, 2009 at 10:33 PM, Dimi Paun wrote: > > On Tue, 2009-02-03 at 20:20 -0500, Josh Boyer wrote: >> No. Matthew already outlined exactly how he took his measurements. >> >> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html > > The problem with this measurement is that it measures max wattage s/wattage/power/ there's no such thing as wattage. > when the cursor blinks. But for a typical user browsing, reading > documents, reading email, etc. the cursor blinks a tiny portion > of the time, only when they _write_ an email. I'd venture to say <10%. > > If that is so we're looking at a saving of about 0.2W for a typical > user. Is this enough to flip the default? > > Here's another proposal: during first boot prompt the user to > change the default to no-blink, explain the benefits, tell > them how to switch back if they don't care for it. This way > nobody will get frustrated or will be surprised their system > no longer works the way they expect it to. > > I know it is more work, but this affects an important UI behavior. > If 0.2W is not all that important to justify the work, lets drop it. > that, according to my calculation, means saving 1 tree every 23 days. If you promise you are going to plant a tree every 23 days, I think we should restart the discussions to consider this issue. Orcan From dimi at lattica.com Wed Feb 4 03:56:49 2009 From: dimi at lattica.com (Dimi Paun) Date: Tue, 03 Feb 2009 22:56:49 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <1233628485.8745.361.camel@dimi.lattica.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> <1233718432.8745.461.camel@dimi.lattica.com> Message-ID: <1233719809.8745.465.camel@dimi.lattica.com> On Tue, 2009-02-03 at 22:45 -0500, Orcan Ogetbil wrote: > that, according to my calculation, means saving 1 tree every 23 days. > If you promise you are going to plant a tree every 23 days, I think we > should restart the discussions to consider this issue. May I ask how you come up with these numbers? Who is burning trees to generate electricity? -- Dimi Paun Lattica, Inc. From airlied at redhat.com Wed Feb 4 04:21:39 2009 From: airlied at redhat.com (Dave Airlie) Date: Wed, 04 Feb 2009 14:21:39 +1000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233718432.8745.461.camel@dimi.lattica.com> References: <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> <1233718432.8745.461.camel@dimi.lattica.com> Message-ID: <1233721300.20002.1.camel@clockmaker.usersys.redhat.com> On Tue, 2009-02-03 at 22:33 -0500, Dimi Paun wrote: > On Tue, 2009-02-03 at 20:20 -0500, Josh Boyer wrote: > > No. Matthew already outlined exactly how he took his measurements. > > > > https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html > > The problem with this measurement is that it measures max wattage > when the cursor blinks. But for a typical user browsing, reading > documents, reading email, etc. the cursor blinks a tiny portion > of the time, only when they _write_ an email. I'd venture to say <10%. > > If that is so we're looking at a saving of about 0.2W for a typical > user. Is this enough to flip the default? > > Here's another proposal: during first boot prompt the user to > change the default to no-blink, explain the benefits, tell > them how to switch back if they don't care for it. This way > nobody will get frustrated or will be surprised their system > no longer works the way they expect it to. Where does the stupid come from? Dave. > > I know it is more work, but this affects an important UI behavior. > If 0.2W is not all that important to justify the work, lets drop it. > > -- > Dimi Paun > Lattica, Inc. > From dimi at lattica.com Wed Feb 4 05:13:37 2009 From: dimi at lattica.com (Dimi Paun) Date: Wed, 04 Feb 2009 00:13:37 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233721300.20002.1.camel@clockmaker.usersys.redhat.com> References: <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <4988E151.2000404@freenet.de> <20090204004601.GA19254@yoda.jdub.homelinux.org> <4988EBAE.5040708@freenet.de> <20090204012016.GD20142@yoda.jdub.homelinux.org> <1233718432.8745.461.camel@dimi.lattica.com> <1233721300.20002.1.camel@clockmaker.usersys.redhat.com> Message-ID: <1233724417.8745.472.camel@dimi.lattica.com> On Wed, 2009-02-04 at 14:21 +1000, Dave Airlie wrote: > > Here's another proposal: during first boot prompt the user to > > change the default to no-blink, explain the benefits, tell > > them how to switch back if they don't care for it. This way > > nobody will get frustrated or will be surprised their system > > no longer works the way they expect it to. > > Where does the stupid come from? If you refer to my earlier comment, again, it wasn't directed at anyone. All I wanted to say is that a blanket statement like "in Fedora tradition is not an argument" does not hold water. It's like saying "in Fedora we don't care to learn from the past". That wouldn't be smart :) I was frustrated, and I was too direct and obscure. If it was taken personal I apologize. -- Dimi Paun Lattica, Inc. From pbrobinson at gmail.com Wed Feb 4 06:31:57 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 4 Feb 2009 06:31:57 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> Message-ID: <5256d0b0902032231rf001a3aw474cf3161486850c@mail.gmail.com> > right now on my F10 system > > xterm defaults to no blink > konsole defaults to no blink > aterm defaults to no blink > Eterm defaults to no blink > rxvt defaults to no blink I think these were only turned off as part of the powertop craze of a year or two ago. > gnome-terminal defaults to blink I think this is actually a gtk option. > I do not think traditional terminal operation makes a strong argument > in the scope of this discussion in the light of the fact that other > terminal emulators with codebase lifetimes as long or longer than > gnome-terminal/libvte already default to no blink in F10. > > If anything.. gnome-terminal is the odd man out and there is an > argument to be made to bring it into line with the common default > behaviour of other virtual terminals. traditionally I think they did blink, but apparently most of the users of those don't care or know how to change the default. Peter From pbrobinson at gmail.com Wed Feb 4 06:39:47 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 4 Feb 2009 06:39:47 +0000 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <1233701656.1833.61.camel@atropine.boston.devel.redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> <1233701656.1833.61.camel@atropine.boston.devel.redhat.com> Message-ID: <5256d0b0902032239j6b6b36a1l620cf95ab00eed90@mail.gmail.com> >> > Just a note, I believe that the ia32 support should "concentrate" on >> > netbooks (So Intel Atom), those are the only new things on the market >> > that can't run x86_64, and the userbase of those will just grow and >> > every percent of extra performance will make many people happy. >> >> So we should ignore OLPC that is deploying 100's of thousands all >> running Fedora? > > Modest proposal: OLPC might benefit from running its own koji instance > and effectively going the secondary arch route. -Os -march=geode, etc. > Given how close it is to mainline x86 it's unlikely to have funky > compilation failures, and it has to branch a non-trivial number of > packages anyway. Actually the forked packages now are pretty minimal. I think there's currently around a dozen, with the move the F11 that will be even less. The major fork is the kernel but other than that most of the forks are to slim down deps. Peter From mrmazda at ij.net Wed Feb 4 06:53:55 2009 From: mrmazda at ij.net (Felix Miata) Date: Wed, 04 Feb 2009 01:53:55 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <2d319b780902030959i19f6d1ecp7d8e201f875f922b@mail.gmail.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <1233624400.27307.17.camel@rosebud> <1233625569.8745.351.camel@dimi.lattica.com> <1233625744.27307.20.camel@rosebud> <4987B1A8.1020703@ij.net> <1233636755.7493.72.camel@localhost.localdomain> <498884A1.8010103@ij.net> <2d319b780902030959i19f6d1ecp7d8e201f875f922b@mail.gmail.com> Message-ID: <49893B83.3080602@ij.net> On 2009/02/03 18:59 (GMT+0100) Mathieu Bridon (bochecha) composed: > I previously wrote: >> My measurements using Seasonic PowerAngel SSM-1508RA: >> Description Speed Mfg Model Minutes KWH Rate >> PC w/ 2 HD 450 Mac G3 221 0.18 1.1729 >> PC, PIII, 133FSB, 2 IDE HD 1133 Dell GX150 168 0.15 1.2857 >> PC, K6-III 66FSB, 2 SCSI HD, 1 IDE 400 AOpen AX5T-3 1544 1.47 1.3710 >> PC, K6-III+ 100FSB, 3 SCSI HD 550 Asus P5S-B 553 0.73 1.9009 >> PC, P4-478 400FSB, 1 HD, 80+ PS 3000 Abit AI7 1424 1.94 1.9618 >> PC, Celeron478 400FSB, 1 HD 2400 Abit AI7 600 0.87 2.0880 >> PC, Socket A 333FSB, 1 HD, std PS 2000 Biostar M7NCD 120 0.20 2.4000 >> PC, P4-775 533FSB, 1+1 HD, 80+ PS 2800 PCChips T18 7200 12.06 2.4120 >> PC, P4-775 533FSB, 1+1 HD 2800 PCChips T18 691 1.30 2.7091 >> PC, P4-775 800FSB, 1+1 HD, 80+ PS 3400 Foxconn F9657AB 617 1.42 3.3141 >> 80+ is described at http://www.80plus.org/ > I suppose you used the exact same system on each of them ? What was it ? System, like turning them on and just going away? With half that was about it, doing no more than going to a DOS or shell prompt or a boot loader menu. No power saving features were enabled beyond a bash or Norton commander screen blanker. Some were running a GUI, but not with anything substantial happening, no Gimping, OO, kernel compilations, or DVDs or music downloaded, burned or played. All those systems except the now dead T18 remain (multi) bootable. I'm writing this from the (space heater) Foxconn. I didn't tabulate installed memory, so what you see for the AI7 comparison needs an estimated adjustment for the Celeron config having half the RAM of the Prescott config. The Dell I originally did just to a DOS prompt, but the original result didn't meet my expectation, and I rebooted it into WinXP and loaded Firefox to a passive page, then just left it, only to find a statistically insignificant difference. None have or need active video cooling. > That's an interesting measurement in any case :) I figured some would reach such a conclusion. My main points were fairly recent stuff gobbles power compared to pretty old yet still servicable stuff, and 80+ genuinely saves. -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From jakub at redhat.com Wed Feb 4 07:29:18 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 4 Feb 2009 08:29:18 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204005616.GF10874@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <1233707697.17218.364.camel@localhost.localdomain> <20090204005616.GF10874@mokona.greysector.net> Message-ID: <20090204072918.GG5690@tyan-ft48-01.lab.bos.redhat.com> On Wed, Feb 04, 2009 at 01:56:16AM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 04 February 2009 at 01:34, Callum Lerwick wrote: > > On Tue, 2009-02-03 at 19:53 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > > i686 to i686 w/ SSE2 would be a performance win, but that is > > > > clearly not an option for Fedora. > > > > > > SSE2-optimized libraries can be built and installed into /usr/lib/sse2. > > > Our ld.so already supports that. > > > > Why does SSE2 get this treatment, and not SSE? I've found SSE much more > > useful, and more common. SSE2 pretty much means P4 only on i386, Athlons > > didn't get SSE2 until the Athlon 64 and those should be running x86-64 > > anyway. Whereas there's a lot of Pentium 3s and Athlon XPs with SSE out > > there. > > I was wondering about the same thing. There's little to no documentation > on this subject so I had to dig into glibc sources to see how it works. > Apparently, glibc distinguishes some "features" for CPUs and those that > are "major" can have separate directories with optimized libraries. > In Fedora, "major" features are "i686" and "sse2". Whereas in Debian, > it's just "cmov", apparently. > > Can anyone shed more light here? Jakub? glibc only has limited subset of the hwcaps marked as important, because it is very costly for LD_LIBRARY_PATH and RPATH/RUNPATH (each added important hwcap doubles the number of searches). The reason sse2 is important and sse is not is that sse2 covers both float and double and vectors thereof, so 1) -mfpmath=sse is possible (this means end of the unpredictable FP behaviors you get with ix87 stack, where everything depends on how long is the compiler being able to keep stuff in the ix87 stack and doesn't have to spill into memory) 2) -O3 can actually vectorize code using both float and doubles. Jakub From jakub at redhat.com Wed Feb 4 07:32:48 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 4 Feb 2009 08:32:48 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204010532.GC20142@yoda.jdub.homelinux.org> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <1233707697.17218.364.camel@localhost.localdomain> <20090204005616.GF10874@mokona.greysector.net> <20090204010532.GC20142@yoda.jdub.homelinux.org> Message-ID: <20090204073248.GH5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 08:05:32PM -0500, Josh Boyer wrote: > It extends to other architectures as well, fwiw. On PowerPC, you can > have optimized libraries for ppc970,power4,power5,power6, and cell I > believe. For Fedora, optimized libraries are built for power6/power6x. On powerpc the answer is also simple. Having too many sets of libraries is a maintainance nightmare and build time killer (ppc/ppc64 glibc already builds twice to three times as long as i?86/x86_64, having 3 extra sets of libs would mean waiting for glibc to build forever). And the gains aren't very noticeable. Jakub From choeger at cs.tu-berlin.de Wed Feb 4 07:38:21 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 04 Feb 2009 08:38:21 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <20090204005849.GG29934@angus.ind.WPI.EDU> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> Message-ID: <1233733101.22814.7.camel@s4.math.tu-berlin.de> Would that lead to some kind of hierarchy like: fedoras grub: -> kernel x.yy.z -> kernel a.bb.d -> Windows -> OpenSUSE -> Ubuntu Where OpenSUSE and Ubuntu link to their own grub (or whatever)? If thats it, it sounds sane to me. What would be needed? I guess one could iterate over all bootable partitions and add them to our own bootloader. That would not _need_ any interaction with any other distro, but if they could adopt that mechanism, the above tree would become navigable as OpenSUSEs grub could link back to fedoras, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Wed Feb 4 07:45:24 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Feb 2009 22:45:24 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233733101.22814.7.camel@s4.math.tu-berlin.de> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> Message-ID: <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> 2009/2/3 Christoph H?ger : > Would that lead to some kind of hierarchy like: > > fedoras grub: > -> kernel x.yy.z > -> kernel a.bb.d > -> Windows > -> OpenSUSE > -> Ubuntu > > Where OpenSUSE and Ubuntu link to their own grub (or whatever)? That is a very high level view. Does that scale to the hundreds of linux distribution variants that are possible to install? How exactly do we know which linux distribution is installed? -jef From pingou at pingoured.fr Wed Feb 4 07:46:14 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 04 Feb 2009 08:46:14 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> Message-ID: <498947C6.3080602@pingoured.fr> Jeff Spaleta wrote: > 2009/2/3 Christoph H?ger : >> Would that lead to some kind of hierarchy like: >> >> fedoras grub: >> -> kernel x.yy.z >> -> kernel a.bb.d >> -> Windows >> -> OpenSUSE >> -> Ubuntu >> >> Where OpenSUSE and Ubuntu link to their own grub (or whatever)? > > That is a very high level view. Does that scale to the hundreds of > linux distribution variants that are possible to install? How exactly > do we know which linux distribution is installed? Looking at the bootable sector is there not a way to retrieve those info ? Pierre From rc040203 at freenet.de Wed Feb 4 07:51:54 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Feb 2009 08:51:54 +0100 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233713202.11436.5.camel@localhost.localdomain> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> Message-ID: <4989491A.3070303@freenet.de> Brian Wheeler wrote: > On Wed, 2009-02-04 at 01:27 +0100, Ralf Corsepius wrote: >> seth vidal wrote: >>> On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: >>>> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: >>>>> I fail to see how a solid cursor is that much harder to find than >>>>> a blinking one. Unless you're only entering solid boxes as text? >>>> There's a reason it's been like this in like ... forever. >>>> Doesn't it strike you as strange to change one of the >>>> longest established conventions on a whim?!? >>> Tradition is not an argument in fedora. >> Sometimes traditions have good reasons - There are reasons why wheels >> are shaped round and not rectangular. > > Just as a nitpick, wheels are round for a technical reason, not because > of tradition. A matter of perspective. Some will say cursors are blinking for technical reasons. E.g. * When using real terminals (or remote logins or runlevel 3), they often are the only indication of a system being alive or not. * Certain applications apply multiple cursors. The active one often is blinking to highlight it. Conversely: Most kids, at some point in their lifes will proudly present their parents the vehicle with triangular or rectangular wheels they assembled from LEGO kits or similar. Ralf From jspaleta at gmail.com Wed Feb 4 07:52:11 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Feb 2009 22:52:11 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <498947C6.3080602@pingoured.fr> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> Message-ID: <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> On Tue, Feb 3, 2009 at 10:46 PM, Pierre-Yves wrote: > Looking at the bootable sector is there not a way to retrieve those info ? If I knew the answer..I would have suggested it. The question was not rhetorical. What defines a distribution? For fedora right now doesn't that pretty much comes down to checking the fedora-release package version in the installed rpmdb? We aren't going to be doing that sort of thing for slackware-esque or debian-esque or foresight-esque or gentoo-esque distros. We may be able to detect opensuse or other rpm based systems that way...maybe...if the rpm databases are compatible with the rpm we have. -jef From choeger at cs.tu-berlin.de Wed Feb 4 07:56:49 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 04 Feb 2009 08:56:49 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> Message-ID: <1233734209.22814.14.camel@s4.math.tu-berlin.de> Well there are |Distributions X bootLoaders| possible combinations. I would argue to get something like a "standard" here ;) No, really, someone should (at least at the grub level) find a way to identify the boot partition with some metadata. Anyone from our developers going to FOSDEM and meet some of the other distro guys? If all (or at least the most) distros agree on one boot partition metadata standard, implementation should be easy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From pingou at pingoured.fr Wed Feb 4 07:56:02 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 04 Feb 2009 08:56:02 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> Message-ID: <49894A12.3040701@pingoured.fr> Jeff Spaleta wrote: > What defines a distribution? For fedora right now doesn't that pretty > much comes down to checking the fedora-release package version in the > installed rpmdb? > > We aren't going to be doing that sort of thing for slackware-esque or > debian-esque or foresight-esque or gentoo-esque distros. We may be > able to detect opensuse or other rpm based systems that > way...maybe...if the rpm databases are compatible with the rpm we > have. Do we *need* to know what is the distro ? Can't we just say that: we found others OS here and there do you want to add them to the boot loader ? If I understand that someone that install a linux beside its windows might have no idea how Linux works (I was the first time I did it) and guess someone that install several linux next to each other would have some knowledge about what he is doing. Regards, Pierre From jspaleta at gmail.com Wed Feb 4 08:00:10 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Feb 2009 23:00:10 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <49894A12.3040701@pingoured.fr> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <49894A12.3040701@pingoured.fr> Message-ID: <604aa7910902040000r9946a9ch6746765b1b396f0e@mail.gmail.com> On Tue, Feb 3, 2009 at 10:56 PM, Pierre-Yves wrote: > Do we *need* to know what is the distro ? > Can't we just say that: we found others OS here and there do you want to add > them to the boot loader ? it wasn't my suggestion to delineate suggestions with distribution names. > > If I understand that someone that install a linux beside its windows might > have no idea how Linux works (I was the first time I did it) and guess > someone that install several linux next to each other would have some > knowledge about what he is doing. that is a lot of assumptions. And if that assumption held, they know how to add grub entries by hand right? They do "know what they are doing" after all. -jef From pingou at pingoured.fr Wed Feb 4 08:04:57 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 04 Feb 2009 09:04:57 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902040000r9946a9ch6746765b1b396f0e@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <49894A12.3040701@pingoured.fr> <604aa7910902040000r9946a9ch6746765b1b396f0e@mail.gmail.com> Message-ID: <49894C29.5010609@pingoured.fr> Jeff Spaleta wrote: >> If I understand that someone that install a linux beside its windows might >> have no idea how Linux works (I was the first time I did it) and guess >> someone that install several linux next to each other would have some >> knowledge about what he is doing. > > that is a lot of assumptions. And if that assumption held, they know > how to add grub entries by hand right? They do "know what they are > doing" after all. I did not say they "know what they are doing" but the have knowledge about it. I mean, I never add an entry to the grub menu so I don't know how to do it, but if anaconda helps me on that I would know what it is asking me about :) Anyway that's not the point of this thread, sorry for the deviation :) /me returns to his small dark corner Regards, Pierre From tomek at pipebreaker.pl Wed Feb 4 08:15:46 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Wed, 4 Feb 2009 09:15:46 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233699392.11676.10.camel@choeger5.umpa.netz> References: <1233699392.11676.10.camel@choeger5.umpa.netz> Message-ID: <20090204081546.GA4770@mother.fordon.pl.eu.org> On Tue, Feb 03, 2009 at 11:16:32PM +0100, Christoph H?ger wrote: > Among other criticisms one thing was really annoying: When a user > installs fedora on a machine with windows installed (common use case) it > detects that installation and offers to add it to grub. But installing > fedora on a box with an already present linux distro installation will > yield that installation removed from grub. This unfair treating of closed source and opensource operating systems is reported for some time: https://bugzilla.redhat.com/show_bug.cgi?id=244805 -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzichubg at chrome.pl wagon filled with backup tapes." -- Jim Gray -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 237 bytes Desc: not available URL: From mschwendt at gmail.com Wed Feb 4 08:21:17 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 4 Feb 2009 09:21:17 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <49889420.3000401@leemhuis.info> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> <49889420.3000401@leemhuis.info> Message-ID: <20090204092117.1cd3b022.mschwendt@gmail.com> On Tue, 03 Feb 2009 19:59:44 +0100, Thorsten wrote: > mschwendt compat-wxGTK26 > mschwendt gai > mschwendt geeqie Now if you could link to the build-failure logs for geeqie and compat-wxGTK26, that would be great, as I can only find the one for gai. From rawhide at fedoraproject.org Wed Feb 4 08:21:26 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 4 Feb 2009 08:21:26 +0000 (UTC) Subject: rawhide report: 20090204 changes Message-ID: <20090204082126.E45F31F82DD@releng2.fedora.phx.redhat.com> Compose started at Wed Feb 4 06:01:03 UTC 2009 New package kde-plasma-weather Plasma applet for weather forecasts New package mingw32-libltdl Runtime libraries for GNU Libtool Dynamic Module Loader New package perl-MooseX-SimpleConfig Moose role for setting attributes from a simple configfile New package perl-MooseX-Types-Set-Object Set::Object type with coercions and stuff New package python-rope Python Code Refactoring Library New package tex-musixtex Sophisticated music typesetting Updated Packages: CTL-1.4.1-8.fc11 ---------------- * Fri Oct 3 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-7 - Rebuild for F-10 * Tue Feb 3 17:00:00 2009 kwizart < kwizart at gmail.com > - 1.4.1-8 - Rebuild for pkgconfig(CTL) alexandria-0.6.3-7.fc11 ----------------------- * Wed Feb 4 17:00:00 2009 Mamoru Tasaka - 0.6.3-7 - Add hpricot dependency again (for Amazon provider) cheese-2.25.90-1.fc11 --------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen 2.25.90-1 - Update to 2.25.90 crda-1.0.1_2009.01.30-4.fc11 ---------------------------- eog-2.25.90-1.fc11 ------------------ * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 fusecompress-1.99.19-3.fc11 --------------------------- * Tue Feb 3 17:00:00 2009 Lubomir Rintel - 1.99.19-3 - Fix build with gcc44 gai-0.5.10-17.fc11 ------------------ * Tue Feb 3 17:00:00 2009 Michael Schwendt - 0.5.10-17 - Patch to make build with gnome-panel >= 2.25, which drops the libgnomeui-2.0 dependency from libpanelapplet-2.0.pc gcin-1.4.4-3.fc11 ----------------- * Wed Feb 4 17:00:00 2009 Chung-Yen Chang - 1.4.4-1 - update to 1.4.4 * Wed Feb 4 17:00:00 2009 Chung-Yen Chang - 1.4.4-2 - rename README to README.html * Wed Feb 4 17:00:00 2009 Chung-Yen Chang - 1.4.4-3 - rename Changelog to Changelog.html gnome-applets-2.25.90-2.fc11 ---------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 1:2.25.90-1 - Update to 2.25.90 gnome-desktop-2.25.90-2.fc11 ---------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 gnome-panel-2.25.90-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 gnome-session-2.25.90-1.fc11 ---------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 gnome-user-share-2.25.91-1.fc11 ------------------------------- gok-2.25.90-1.fc11 ------------------ * Fri Jan 30 17:00:00 2009 Debarshi Ray - 2.25.3-4 - Removed mixed use of tabs and spaces. - Use parallel make. * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 highlight-2.7-2.fc11 -------------------- * Tue Feb 3 17:00:00 2009 Jochen Schmitt 2.7-2 - Patches for gcc-4.4 icu-4.0.1-2.fc11 ---------------- * Tue Feb 3 17:00:00 2009 Caolan McNamara - 4.0.1-2 - fix bare elif for gcc-4.4 ifstat-1.1-9.fc11 ----------------- * Tue Feb 3 17:00:00 2009 Itamar Reis Peixoto - 1.1-9 - rebuild for new openssl ivtv-utils-1.3.0-2.fc11 ----------------------- * Tue Feb 3 17:00:00 2009 Jarod Wilson - 1.3.0-2 - Fix up for current rawhide kernel-2.6.29-0.78.rc3.git5.fc11 -------------------------------- * Sun Feb 1 17:00:00 2009 Chuck Ebbert - Fold sata_sil build fix into compile-fixes.patch * Mon Feb 2 17:00:00 2009 Kyle McMartin - Re-enable CONFIG_DRM_RADEON_KMS. * Tue Feb 3 17:00:00 2009 Kristian H??gsberg - Pull in drm-intel-next changes. * Tue Feb 3 17:00:00 2009 Kyle McMartin - 2.6.29-rc3-git5 liberation-fonts-1.04.93-8.fc11 ------------------------------- * Wed Feb 4 17:00:00 2009 Caius Chance - 1.04.93-7.fc11 - Create -compat subpackage as meta-package for installing all font families. * Wed Feb 4 17:00:00 2009 Caius Chance - 1.04.93-8.fc11 - Fixed inter-subpackage dependencies. libgnomecanvas-2.25.90-2.fc11 ----------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen 2.25.90-2 - Update to 2.25.90 - Drop obsolete patches - BR intltool libsmbios-2.2.13-1.fc11 ----------------------- * Tue Feb 3 17:00:00 2009 Michael E Brown - 2.2.12-1 - Add feature to turn on debugging printf()'s without recompiling by setting certain environment variables: LIBSMBIOS_C_DEBUG_OUTPUT_ALL -- all debugging output or, per module: LIBSMBIOS_C_DEBUG_CONSTRUCTOR_C LIBSMBIOS_C_DEBUG_SYSINFO_C LIBSMBIOS_C_DEBUG_SMBIOS_C LIBSMBIOS_C_DEBUG_TOKEN_C LIBSMBIOS_C_DEBUG_MEMORY_C LIBSMBIOS_C_DEBUG_CMOS_C LIBSMBIOS_C_DEBUG_SMI_C libtool-2.2.6-6.fc11 -------------------- * Wed Jan 28 17:00:00 2009 Karsten Hopp 2.2.6-6 - libtool-ltdl now owns /usr/share/libtool (#474672) ltsp-5.1.58-1.fc11 ------------------ * Tue Feb 3 17:00:00 2009 Warren Togami - 5.1.57-1 - Fix localapps - Cleanup Fedora 11 boot * Tue Feb 3 17:00:00 2009 Warren Togami - 5.1.58-1 - Really fix localapps mock-0.9.14-1.fc11 ------------------ * Mon Feb 2 17:00:00 2009 Clark Williams - 0.9.14-1 - logging cleanup (mikem) - add new exception for resultdir not available (mebrown) - moved mock cache dir to /var/cache/mock (williams) - added version variable and version banner to logs (williams) - removed import of popen2 to whack deprecated message (williams) - prevent disabling ccache on epel-5 (tmz) - added configs for sparc and s390 (dgilmore) - fixed git log command used in build (tmz) - added copy of spec/sources for building srpms (mebrown) - changed unlink to rmdir (mebrown) - set HOME directory globally (mikeb) - commented out privlege drop in --copyin (williams) mousetweaks-2.25.90-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 museek+-0.2-0.1.20090203svn1092.fc11 ------------------------------------ * Tue Feb 3 17:00:00 2009 Julian Sikorski - 0.2-0.1.20090203svn1092 - Updated to SVN revision 1092, should build with gcc-4.4 now ncmpcpp-0.3-1.fc11 ------------------ * Tue Feb 3 17:00:00 2009 Michal Nowak 0.3-1 - 0.3 - enable clock pango-1.23.0-1.fc11 ------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 1.23.0-1 - Update to 1.23.0 perl-SQL-Translator-0.09002-1.fc11 ---------------------------------- * Tue Feb 3 17:00:00 2009 Chris Weyl 0.09002-1 - update to 0.09002 perl-Sub-Install-0.925-1.fc11 ----------------------------- * Tue Feb 3 17:00:00 2009 Chris Weyl 0.925-1 - update to 0.925 planner-0.14.3-9.fc11 --------------------- * Tue Feb 3 17:00:00 2009 Caol??n McNamara - 0.14.3-9 - rebuild for e-d-s ppl-0.10-5.fc11 --------------- * Tue Feb 3 17:00:00 2009 Roberto Bagnara 0.10-5 - Work around the bug affecting PPL 0.10 on big-endian architectures. python-eyed3-0.6.17-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Brian Pepple - 0.6.17-1 - Update to 0.6.17. seahorse-2.25.90-1.fc11 ----------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen 2.25.90-1 - Update to 2.25.90 seahorse-plugins-2.25.90-1.fc11 ------------------------------- * Wed Feb 4 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 selinux-policy-3.6.4-1.fc11 --------------------------- * Mon Feb 2 17:00:00 2009 Dan Walsh 3.6.3-13 - Add boolean to disallow unconfined_t login * Tue Feb 3 17:00:00 2009 Dan Walsh 3.6.4-1 - Upgrade to latest upstream sound-juicer-2.25.2-1.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 - Bastien Nocera - 2.25.2-1 - Update to 2.25.2 - Use libmusicbrainz3 in addition to the old one, replace ncb dep with brasero - Remove a lot of GNOME BRs stk-4.3.1-8.fc11 ---------------- * Tue Feb 3 17:00:00 2009 Thomas Moschny - 4.3.1-8 - Update header patch: Add more missing includes. Should fix compilation with gcc 4.4.0. subcommander-1.9.94-4.fc11 -------------------------- * Tue Feb 3 17:00:00 2009 Jochen Schmitt 1.9.94-4 - Fix gcc-4.4 issues tomboy-0.13.4-1.fc11 -------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 0.13.4-1 - Update to 0.13.4 totem-2.25.90-1.fc11 -------------------- * Tue Feb 3 17:00:00 2009 - Bastien Nocera - 2.25.90-1 - Update to 2.25.90 - Add separate UPNP plugin package totem-pl-parser-2.25.90-1.fc11 ------------------------------ xalan-j2-2.7.0-7.5.fc11 ----------------------- * Tue Feb 3 17:00:00 2009 Alexander Kurtakov 0:2.7.0-7.5 - Add osgi manifest. xorg-x11-drv-nouveau-0.0.11-2.20090106git133c1a5.fc11 ----------------------------------------------------- * Tue Jan 13 17:00:00 2009 Ben Skeggs 0.0.11-1.20090106git133c1a5 - update to latest snapshot * Tue Feb 3 17:00:00 2009 Kyle McMartin 0.0.11-2.20090106git133c1a5 - add build-dep on mesa (missing GL/gl.h due to glxint.h) xorg-x11-server-1.5.99.902-2.fc11 --------------------------------- * Wed Feb 4 17:00:00 2009 Peter Hutterer 1.5.99.902-2 - xserver-1.5.99.902-xinerama.patch: don't update the sprite root window in Xinerama setups (#473825) Summary: Added Packages: 6 Removed Packages: 0 Modified Packages: 46 Broken deps for i386 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.i386 requires libcamel-1.2.so.13 evolution-exchange-2.25.5-1.fc11.i386 requires libcamel-1.2.so.13 evolution-exchange-2.25.5-1.fc11.i386 requires libcamel-provider-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.i386 requires libcamel-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.i386 requires libcamel-provider-1.2.so.13 freedink-engine-1.08.20090120-1.fc11.i386 requires liberation-fonts gnubiff-2.2.10-1.fc11.i386 requires libssl.so.7 gnubiff-2.2.10-1.fc11.i386 requires libcrypto.so.7 1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.i386 requires libcrypto.so.7 grass-6.3.0-9.fc11.i386 requires libssl.so.7 grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15 ldns-1.4.0-1.fc11.i386 requires libcrypto.so.7 libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0 linkage-0.2.0-4.fc11.i386 requires libcrypto.so.7 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 mail-notification-evolution-plugin-5.4-8.fc11.i386 requires libcamel-1.2.so.13 mail-notification-evolution-plugin-5.4-8.fc11.i386 requires libcamel-provider-1.2.so.13 mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.i386 requires libssl.so.7 mediatomb-0.11.0-4.fc11.i386 requires libcrypto.so.7 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.i386 requires thaifonts-scalable 1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.i386 requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so sepostgresql-8.3.5-2.1183.fc10.i386 requires libssl.so.7 sepostgresql-8.3.5-2.1183.fc10.i386 requires libcrypto.so.7 tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.i386 requires libcrypto.so.7 Broken deps for x86_64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.i386 requires libcamel-1.2.so.13 evolution-brutus-1.2.34-1.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) freedink-engine-1.08.20090120-1.fc11.x86_64 requires liberation-fonts gnubiff-2.2.10-1.fc11.x86_64 requires libssl.so.7()(64bit) gnubiff-2.2.10-1.fc11.x86_64 requires libcrypto.so.7()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.x86_64 requires libssl.so.7()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) grass-6.3.0-9.fc11.x86_64 requires libcrypto.so.7()(64bit) ldns-1.4.0-1.fc11.i386 requires libcrypto.so.7 ldns-1.4.0-1.fc11.x86_64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.i386 requires libcrypto.so.7 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.x86_64 requires libcrypto.so.7()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.x86_64 requires libcamel-provider-1.2.so.13()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libssl.so.7()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libcrypto.so.7()(64bit) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.x86_64 requires thaifonts-scalable 1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) sepostgresql-8.3.5-2.1183.fc10.x86_64 requires libssl.so.7()(64bit) sepostgresql-8.3.5-2.1183.fc10.x86_64 requires libcrypto.so.7()(64bit) tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.x86_64 requires libcrypto.so.7()(64bit) Broken deps for ppc ---------------------------------------------------------- db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.ppc requires libcamel-1.2.so.13 evolution-brutus-1.2.34-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.ppc requires libcamel-1.2.so.13 evolution-exchange-2.25.5-1.fc11.ppc requires libcamel-provider-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.ppc requires libcamel-1.2.so.13 evolution-zimbra-0.1.1-4.fc11.ppc requires libcamel-provider-1.2.so.13 freedink-engine-1.08.20090120-1.fc11.ppc requires liberation-fonts gnubiff-2.2.10-1.fc11.ppc requires libssl.so.7 gnubiff-2.2.10-1.fc11.ppc requires libcrypto.so.7 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4 grass-6.3.0-9.fc11.ppc requires libcrypto.so.7 grass-6.3.0-9.fc11.ppc requires libssl.so.7 grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15 ldns-1.4.0-1.fc11.ppc requires libcrypto.so.7 ldns-1.4.0-1.fc11.ppc64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0 linkage-0.2.0-4.fc11.ppc requires libcrypto.so.7 linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.ppc requires libcamel-1.2.so.13 mail-notification-evolution-plugin-5.4-8.fc11.ppc requires libcamel-provider-1.2.so.13 mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.ppc requires libssl.so.7 mediatomb-0.11.0-4.fc11.ppc requires libcrypto.so.7 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.ppc requires thaifonts-scalable 1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.ppc requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so sepostgresql-8.3.5-2.1183.fc10.ppc requires libssl.so.7 sepostgresql-8.3.5-2.1183.fc10.ppc requires libcrypto.so.7 tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.ppc requires libcrypto.so.7 Broken deps for ppc64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) evolution-exchange-2.25.5-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) evolution-zimbra-0.1.1-4.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) freedink-engine-1.08.20090120-1.fc11.ppc64 requires liberation-fonts gnubiff-2.2.10-1.fc11.ppc64 requires libssl.so.7()(64bit) gnubiff-2.2.10-1.fc11.ppc64 requires libcrypto.so.7()(64bit) 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit) grass-6.3.0-9.fc11.ppc64 requires libssl.so.7()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit) grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) grass-6.3.0-9.fc11.ppc64 requires libcrypto.so.7()(64bit) ldns-1.4.0-1.fc11.ppc64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.ppc64 requires libcamel-provider-1.2.so.13()(64bit) mail-notification-evolution-plugin-5.4-8.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libssl.so.7()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) 1:openoffice.org-langpack-th_TH-3.0.1-15.5.fc11.ppc64 requires thaifonts-scalable 1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sepostgresql-8.3.5-2.1183.fc10.ppc64 requires libcrypto.so.7()(64bit) sepostgresql-8.3.5-2.1183.fc10.ppc64 requires libssl.so.7()(64bit) tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 tightvnc-server-1.5.0-0.9.20081120svn3200.fc11.ppc64 requires libcrypto.so.7()(64bit) From j.w.r.degoede at hhs.nl Wed Feb 4 08:25:37 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 04 Feb 2009 09:25:37 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233699392.11676.10.camel@choeger5.umpa.netz> References: <1233699392.11676.10.camel@choeger5.umpa.netz> Message-ID: <49895101.6060201@hhs.nl> Christoph H?ger wrote: > Hi, > > fedora has recently been tested (again) and compared against other > distributions (Ubuntu and OpenSUSE) by c't, a german IT magazine from > the heise publishing house. > > Among other criticisms one thing was really annoying: When a user > installs fedora on a machine with windows installed (common use case) it > detects that installation and offers to add it to grub. But installing > fedora on a box with an already present linux distro installation will > yield that installation removed from grub. > > I understand that the bootloader is a part of the distro and its > configuration gets changed e.g. during kernel updates, but is there > really only the answer to remove one distribution completely? > Do we really want to support Windows as second OS more than OpenSUSE or > Ubuntu (or CentOS, or Debian, or Gentoo, or ........) > At least the anaconda team should consider printing a warning about one > OS going to "be lost" during install and how to recover. > > Any thoughts on that? > Patches welcome comes to mind. Regards, Hans From jonathan at jonmasters.org Wed Feb 4 08:47:22 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 04 Feb 2009 03:47:22 -0500 Subject: module-init-tools v3.6 released Message-ID: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> Folks, I've pushed an update to rawhide with version 3.6. It's not got a huge amount different from F10 but I would be grateful for feedback. One of the things we're looking into at the moment is removing all the different vendor's patches. Fedora has none, Ubuntu is on the way to that, and OpenSuSE is certainly next on the list. One of the things we need to do after that is figure out how to unify the crazy number of configuration hacks we have. I'm considering pushing an update to F-9 since v3.5+ is so much faster than previous releases - and it impacts boot time, but I have to admit that I was more concerned about F10 and rawhide until now. Jon. From gauret at free.fr Wed Feb 4 09:00:26 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 4 Feb 2009 10:00:26 +0100 Subject: Build succeeds in mock but fails in koji Message-ID: Hi *, I'm trying to package springlobby[1] and I'm testing the build in mock and in koji. The build succeeds in my local mock but fails in koji[2] because it does not find "GNU gettext in libc", and thus no translations are built. [1] https://bugzilla.redhat.com/show_bug.cgi?id=478770 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=1103274 Any idea why ? I suppose there is no way to log into the koji server to check the config.log ? Thanks. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz From jcm at redhat.com Wed Feb 4 09:01:38 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 04 Feb 2009 04:01:38 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <49887ADF.9090606@redhat.com> References: <49887ADF.9090606@redhat.com> Message-ID: <1233738098.5280.62.camel@perihelion.bos.jonmasters.org> On Tue, 2009-02-03 at 12:11 -0500, Warren Togami wrote: > If we go with i586.rpm's in Fedora, then redhat-rpm-config must be > changed to include -mtune=generic for i586, currently it has that tuning > only for i386 and i686. Sure. I can do that. But one question...does it really matter all that much to change builds for IA32 at this point? Really? Surely by the time people are done complaining about whatever they don't like with this, it'll be dead. I probably missed some big discussion about this :) Jon. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 4 09:09:44 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 04 Feb 2009 18:09:44 +0900 Subject: Build succeeds in mock but fails in koji In-Reply-To: References: Message-ID: <49895B58.6030403@ioa.s.u-tokyo.ac.jp> Aur?lien Bompard wrote, at 02/04/2009 06:00 PM +9:00: > Hi *, > > I'm trying to package springlobby[1] and I'm testing the build in mock > and in koji. The build succeeds in my local mock but fails in koji[2] > because it does not find "GNU gettext in libc", and thus no > translations are built. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=478770 > [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=1103274 > > Any idea why ? I suppose there is no way to log into the koji server > to check the config.log ? Usually "BuildRequires: gettext" is missing. By the way, if you want to check config.log for debugging, you can write "cat config.log" to the spec file explicitly. Mamoru From mike.cloaked at gmail.com Wed Feb 4 09:12:54 2009 From: mike.cloaked at gmail.com (Mike) Date: Wed, 4 Feb 2009 09:12:54 +0000 (UTC) Subject: Fedora Release Notes References: <671a617b0902011648q20ffc0ebn76f47d1a9252e3df@mail.gmail.com> <671a617b0902011710r79af6d96q83ed80bfeb5a8884@mail.gmail.com> <20090202165431.117a3136@ohm.scrye.com> <4987D812.90008@leemhuis.info> Message-ID: drago01 gmail.com> writes: > >> Yeah, I would like to see the release notes be smaller and just contain > >> new information for the release. You could easily have a pointer to the > >> install guide or other docs that contain more verbose info or info > >> thats repeated every release. > > > > +1 ; some more thoughts on this: > > http://thorstenl.blogspot.com/2008/12/read-same-paragraphs-every-half-year.html > > +1 > Release Notes are not a place for random docs, it should just tell the > reader about changes/new features. > Just add links to related docs if necessary. Somewhere there is a need for information that is helpful to both experienced Fedora users/administrators, as well as to new users. The release notes best serves experienced users with a brief list of changes in the new release (almost by definition!). However there needs to be as much help as possible for new users, and, as has been commented earlier, the install guide is one place that such documentation can be placed. However I believe there is also an important need for a single place where step by step guidance is available to a new user, both on the install and also on the configuration after the install. After all most of us probably spend more time on configuring the system after the install than on the install itself! There are a number of such how-to documents distributed across the web provided and kept updated by private individuals. It would be nice if there was an "official" document of this kind that included advice on getting around the common problems that occur with every release one way or another. A central wiki page that was updated as new releases occurred would be a very nice feature for people installing for the first time. There is a common problems page on the wiki already but it would make the life of the new user much easier if the install/configuration/problem resolution were all directly linked from a single starting point (in the wiki?). From aph at redhat.com Wed Feb 4 09:40:19 2009 From: aph at redhat.com (Andrew Haley) Date: Wed, 04 Feb 2009 09:40:19 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090203231033.GA22552@srcf.ucam.org> References: <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <5256d0b0902031433r50fce9c8qb6c4e4066d8a07af@mail.gmail.com> <20090203231033.GA22552@srcf.ucam.org> Message-ID: <49896283.1040406@redhat.com> Matthew Garrett wrote: > On Tue, Feb 03, 2009 at 11:33:12PM +0100, Peter Robinson wrote: > >> TBH until recently I thought this problem had gone away. Shortly after >> powertop came out the blinking cursor issue was identified as an issue >> and I saw patches flying around to fix the problems. It wasn't until I >> noticed OLPC was patching some part of the the gnome stack to fix the >> issue that I realised that it was still an issue. Surely it can be >> made some sort of "Cursor Blink" config option that is disabled by >> default but allow the people that want blinking to enable it >> relatively simply. > > It is - System/Preferences/Hardware(?)/Keyboard(!)/General/ . FWIW: Hardware/Keyboard? Keyboard! No wonder I couldn't find it. :-( Andrew. From fedora at matbooth.co.uk Wed Feb 4 09:47:21 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Wed, 4 Feb 2009 09:47:21 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4989491A.3070303@freenet.de> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> <4989491A.3070303@freenet.de> Message-ID: <9497e9990902040147s77c90452ke0217e62975d413e@mail.gmail.com> On Wed, Feb 4, 2009 at 7:51 AM, Ralf Corsepius wrote: > Brian Wheeler wrote: >> >> On Wed, 2009-02-04 at 01:27 +0100, Ralf Corsepius wrote: >>> >>> seth vidal wrote: >>>> >>>> On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: >>>>> >>>>> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: >>>>>> >>>>>> I fail to see how a solid cursor is that much harder to find than >>>>>> a blinking one. Unless you're only entering solid boxes as text? >>>>> >>>>> There's a reason it's been like this in like ... forever. >>>>> Doesn't it strike you as strange to change one of the >>>>> longest established conventions on a whim?!? >>>> >>>> Tradition is not an argument in fedora. >>> >>> Sometimes traditions have good reasons - There are reasons why wheels are >>> shaped round and not rectangular. >> >> Just as a nitpick, wheels are round for a technical reason, not because >> of tradition. > > A matter of perspective. Some will say cursors are blinking for technical > reasons. > Hey, the guy's name is "Wheeler". If anyone ought to know why they're round, it's him. ;-) -- Mat Booth www.matbooth.co.uk From fedora at matbooth.co.uk Wed Feb 4 09:47:21 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Wed, 4 Feb 2009 09:47:21 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4989491A.3070303@freenet.de> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> <4989491A.3070303@freenet.de> Message-ID: <9497e9990902040147s77c90452ke0217e62975d413e@mail.gmail.com> On Wed, Feb 4, 2009 at 7:51 AM, Ralf Corsepius wrote: > Brian Wheeler wrote: >> >> On Wed, 2009-02-04 at 01:27 +0100, Ralf Corsepius wrote: >>> >>> seth vidal wrote: >>>> >>>> On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: >>>>> >>>>> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: >>>>>> >>>>>> I fail to see how a solid cursor is that much harder to find than >>>>>> a blinking one. Unless you're only entering solid boxes as text? >>>>> >>>>> There's a reason it's been like this in like ... forever. >>>>> Doesn't it strike you as strange to change one of the >>>>> longest established conventions on a whim?!? >>>> >>>> Tradition is not an argument in fedora. >>> >>> Sometimes traditions have good reasons - There are reasons why wheels are >>> shaped round and not rectangular. >> >> Just as a nitpick, wheels are round for a technical reason, not because >> of tradition. > > A matter of perspective. Some will say cursors are blinking for technical > reasons. > Hey, the guy's name is "Wheeler". If anyone ought to know why they're round, it's him. ;-) -- Mat Booth www.matbooth.co.uk From dan at danny.cz Wed Feb 4 11:19:47 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 04 Feb 2009 12:19:47 +0100 Subject: how to build with gcc 4.4 Message-ID: <1233746387.3724.34.camel@eagle.danny.cz> I tried to do a scratch build in koji using gcc 4.4 with this command koji build --scratch --nowait dist-f11-gcc44 openhpi-2.13.2-1.fc11.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=1103314 and it failed with: libtool-2.2.6-6.fc11.x86_64 from build has depsolving problems DEBUG util.py:250: --> Missing Dependency: gcc = 4.3.2 is needed by package libtool-2.2.6-6.fc11.x86_64 (build) Is there a way to test building a package with gcc 4.4? Dan From devrim at gunduz.org Wed Feb 4 11:27:03 2009 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Wed, 04 Feb 2009 13:27:03 +0200 Subject: pgadmin3 license change Message-ID: <1233746823.3357.229.camel@laptop.gunduz.org> Hi, pgadmin3 was removed from Fedora 10+ , because it was using Artistic 1.0 license: http://fedoraproject.org/wiki/Features/Artistic1Removal#pgadmin3 Upstream just announced that they are changing license to Artistic 2. http://pgsnake.blogspot.com/2009/02/pgadmin-change-of-licence.html So probably as of pgadmin3 1.8.5 (or 2.0, whatever), pgadmin3 will be again in Fedora repositories. Regards, -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wolfy at nobugconsulting.ro Wed Feb 4 11:35:20 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 04 Feb 2009 13:35:20 +0200 Subject: pgadmin3 license change In-Reply-To: <1233746823.3357.229.camel@laptop.gunduz.org> References: <1233746823.3357.229.camel@laptop.gunduz.org> Message-ID: <49897D78.7020700@nobugconsulting.ro> Devrim G?ND?Z wrote: > Hi, > > pgadmin3 was removed from Fedora 10+ , because it was using Artistic 1.0 > license: > > http://fedoraproject.org/wiki/Features/Artistic1Removal#pgadmin3 > > Upstream just announced that they are changing license to Artistic 2. > > http://pgsnake.blogspot.com/2009/02/pgadmin-change-of-licence.html > > So probably as of pgadmin3 1.8.5 (or 2.0, whatever), pgadmin3 will be > again in Fedora repositories. > > Regards, > In that case I guess we can just transfer it back from rpmfusion (where 1.8.4 resides now). Please sync with Robert for a smooth transition. Manuel / / From gauret at free.fr Wed Feb 4 11:38:14 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 4 Feb 2009 12:38:14 +0100 Subject: Build succeeds in mock but fails in koji In-Reply-To: <49895B58.6030403@ioa.s.u-tokyo.ac.jp> References: <49895B58.6030403@ioa.s.u-tokyo.ac.jp> Message-ID: > Usually "BuildRequires: gettext" is missing. I do have it in the spec file (else it would not even build in the local mock). > By the way, > if you want to check config.log for debugging, you can write "cat > config.log" to the spec file explicitly. Good trick, I'll try that ! Thanks. Aur?lien From jakub at redhat.com Wed Feb 4 11:53:06 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 4 Feb 2009 12:53:06 +0100 Subject: how to build with gcc 4.4 In-Reply-To: <1233746387.3724.34.camel@eagle.danny.cz> References: <1233746387.3724.34.camel@eagle.danny.cz> Message-ID: <20090204115306.GK5690@tyan-ft48-01.lab.bos.redhat.com> On Wed, Feb 04, 2009 at 12:19:47PM +0100, Dan Hor?k wrote: > I tried to do a scratch build in koji using gcc 4.4 with this command > koji build --scratch --nowait dist-f11-gcc44 openhpi-2.13.2-1.fc11.src.rpm > > https://koji.fedoraproject.org/koji/taskinfo?taskID=1103314 > > and it failed with: > libtool-2.2.6-6.fc11.x86_64 from build has depsolving problems > DEBUG util.py:250: --> Missing Dependency: gcc = 4.3.2 is needed by package libtool-2.2.6-6.fc11.x86_64 (build) > > Is there a way to test building a package with gcc 4.4? Try again. Apparently libtool has acl open, so I've built libtool-2.2.6-7.fc11 myself into dist-f11-gcc44. Jakub From pknirsch at redhat.com Wed Feb 4 11:57:55 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 04 Feb 2009 12:57:55 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement Message-ID: <498982C3.8030704@redhat.com> Hey folks. I've recently spent quite some time on researching and testing what things we can do to make power management better in Fedora. For that reason i've opened a Feature request for F11 with the basic stuff that i think is doable for that release. So if you have a minute please take look over it and either send me some feedback or edit the page yourself. :) In case you're interested in helping make power management better in F11 feel free to participate in any form. Thanks a lot & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From hughsient at gmail.com Wed Feb 4 12:16:59 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 04 Feb 2009 12:16:59 +0000 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <498982C3.8030704@redhat.com> References: <498982C3.8030704@redhat.com> Message-ID: <1233749819.3441.11.camel@hughsie-work.lan> On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: > I've recently spent quite some time on researching and testing what > things we can do to make power management better in Fedora. For that > reason i've opened a Feature request for F11 with the basic stuff that > i think is doable for that release. In the version of g-p-m and DeviceKit-power in rawhide, you can see some new stuff like this: http://blogs.gnome.org/hughsie/2009/01/30/gnome-power-manager-and-processor-wakeups/ It's basically a DBUS interface and session viewer for the data. Might be useful for your automated testing, as "devkit-power --wakeups" just trivially prints the raw data off an interface. Richard. From jdieter at gmail.com Wed Feb 4 12:19:13 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 04 Feb 2009 14:19:13 +0200 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <498982C3.8030704@redhat.com> References: <498982C3.8030704@redhat.com> Message-ID: <1233749953.6180.5.camel@jdlaptop.lesbg.loc> On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: > Hey folks. > > I've recently spent quite some time on researching and testing what > things we can do to make power management better in Fedora. For that > reason i've opened a Feature request for F11 with the basic stuff that i > think is doable for that release. > > So if you have a minute please take look over it and either send me some > feedback or edit the page yourself. :) > > In case you're interested in helping make power management better in F11 > feel free to participate in any form. Thanks much. Do you mind including a URL? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Wed Feb 4 12:24:51 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 4 Feb 2009 07:24:51 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204073248.GH5690@tyan-ft48-01.lab.bos.redhat.com> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <1233707697.17218.364.camel@localhost.localdomain> <20090204005616.GF10874@mokona.greysector.net> <20090204010532.GC20142@yoda.jdub.homelinux.org> <20090204073248.GH5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090204122451.GA21732@yoda.jdub.homelinux.org> On Wed, Feb 04, 2009 at 08:32:48AM +0100, Jakub Jelinek wrote: >On Tue, Feb 03, 2009 at 08:05:32PM -0500, Josh Boyer wrote: >> It extends to other architectures as well, fwiw. On PowerPC, you can >> have optimized libraries for ppc970,power4,power5,power6, and cell I >> believe. For Fedora, optimized libraries are built for power6/power6x. > >On powerpc the answer is also simple. Having too many sets of libraries is >a maintainance nightmare and build time killer (ppc/ppc64 glibc already >builds twice to three times as long as i?86/x86_64, having 3 extra sets of >libs would mean waiting for glibc to build forever). And the gains aren't >very noticeable. Oh, yes I know that. I was just explaining that the optimized library mechanism that glibc has extends to things other than SSE. I wasn't asking for more tuned libraries. josh From mmaslano at redhat.com Wed Feb 4 12:26:25 2009 From: mmaslano at redhat.com (Marcela Maslanova) Date: Wed, 04 Feb 2009 13:26:25 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <1233749953.6180.5.camel@jdlaptop.lesbg.loc> References: <498982C3.8030704@redhat.com> <1233749953.6180.5.camel@jdlaptop.lesbg.loc> Message-ID: <49898971.9090004@redhat.com> Jonathan Dieter wrote: > On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: >> Hey folks. >> >> I've recently spent quite some time on researching and testing what >> things we can do to make power management better in Fedora. For that >> reason i've opened a Feature request for F11 with the basic stuff that i >> think is doable for that release. >> >> So if you have a minute please take look over it and either send me some >> feedback or edit the page yourself. :) >> >> In case you're interested in helping make power management better in F11 >> feel free to participate in any form. > > Thanks much. Do you mind including a URL? > > Jonathan > https://fedoraproject.org/wiki/Features/PowerManagement -- Marcela Ma?l??ov? BaseOS team Brno From pknirsch at redhat.com Wed Feb 4 12:34:30 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 04 Feb 2009 13:34:30 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <1233749953.6180.5.camel@jdlaptop.lesbg.loc> References: <498982C3.8030704@redhat.com> <1233749953.6180.5.camel@jdlaptop.lesbg.loc> Message-ID: <49898B56.70002@redhat.com> Jonathan Dieter wrote: > On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: >> Hey folks. >> >> I've recently spent quite some time on researching and testing what >> things we can do to make power management better in Fedora. For that >> reason i've opened a Feature request for F11 with the basic stuff that i >> think is doable for that release. >> >> So if you have a minute please take look over it and either send me some >> feedback or edit the page yourself. :) >> >> In case you're interested in helping make power management better in F11 >> feel free to participate in any form. > > Thanks much. Do you mind including a URL? > > Jonathan > Ah ye, sorry, only had it in the subject: https://fedoraproject.org/wiki/Features/PowerManagement Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From pknirsch at redhat.com Wed Feb 4 12:35:03 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 04 Feb 2009 13:35:03 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <1233749819.3441.11.camel@hughsie-work.lan> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> Message-ID: <49898B77.5010507@redhat.com> Richard Hughes wrote: > On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: >> I've recently spent quite some time on researching and testing what >> things we can do to make power management better in Fedora. For that >> reason i've opened a Feature request for F11 with the basic stuff that >> i think is doable for that release. > > In the version of g-p-m and DeviceKit-power in rawhide, you can see some > new stuff like this: > http://blogs.gnome.org/hughsie/2009/01/30/gnome-power-manager-and-processor-wakeups/ > > It's basically a DBUS interface and session viewer for the data. > > Might be useful for your automated testing, as "devkit-power --wakeups" > just trivially prints the raw data off an interface. > > Richard. > > I'll add that right away to the page. Thanks Richard! Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From jakub at redhat.com Wed Feb 4 12:38:22 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 4 Feb 2009 13:38:22 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090204123822.GL5690@tyan-ft48-01.lab.bos.redhat.com> On Tue, Feb 03, 2009 at 05:40:33PM -0600, Jason L Tibbitts III wrote: > Unfortunately this includes my package xu4, and while I do have some > C++ experience (college was some time ago), the exact reason this has > just started failing with 4.4 is eluding me. The difference from 4.3 to 4.4 in this case is again no longer including . You have: #include ... #include ... struct U4FILE { ... virtual int putc(int c) = 0; ... }; ... In 4.3 would include , which includes and then #undefs a bunch of stuff, including putc, which is allowed to be a macro in C. Then stdio.h is included, but as it uses multiple inclusion guards, it does nothing. In 4.4 no longer does that, isn't included and so when stdio.h is included, it defines putc etc. and nothing undefs it afterwards. To fix this, #include instead of #include (this is probably not an option in this case, as stdio.h include comes from SDL headers which are both for C and C++, so can't include cstdio), or #include before including (preferred), or surround putc with ()s, as in: virtual int (putc)(int c) = 0; Jakub From pingou at pingoured.fr Wed Feb 4 12:41:14 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 04 Feb 2009 13:41:14 +0100 Subject: Boot profile Message-ID: <49898CEA.3010905@pingoured.fr> Dear list, I have had the idea on the back of my head for some time and I would like to ask if it would make sense. I have a laptop that I use for work but also when I travel. I travel by car, train or bus. The services I need for work are not necessarily needed when I am in the train and therefore I though that it would be cool to be able to define profiles. You could thus have a profile * work that would start the list of services you defined (httpd, mysqld, networkManager...) * train that would start another list of services that you defined (in this case I would not like to start httpd, mysqld nor NetworkManager for example) Thus in the train my laptop would not always look for a network or wait for a bluetooth connection and I assume it make my laptop boot faster and would save the battery a bit. Being able to define profiles of the services that start in advance (I know there is the interactive boot option) would IMHO be cool, however I don't know if it's feasible or if you like it. thanks for your comments, Best regards, Pierre From bochecha at fedoraproject.org Wed Feb 4 12:46:36 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Wed, 4 Feb 2009 13:46:36 +0100 Subject: Boot profile In-Reply-To: <49898CEA.3010905@pingoured.fr> References: <49898CEA.3010905@pingoured.fr> Message-ID: <2d319b780902040446h766c342bi9b87056dca987f7@mail.gmail.com> > I have a laptop that I use for work but also when I travel. I travel by car, > train or bus. > The services I need for work are not necessarily needed when I am in the > train and therefore I though that it would be cool to be able to define > profiles. > You could thus have a profile > * work that would start the list of services you defined (httpd, mysqld, > networkManager...) > * train that would start another list of services that you defined (in this > case I would not like to start httpd, mysqld nor NetworkManager for example) > > Thus in the train my laptop would not always look for a network or wait for > a bluetooth connection and I assume it make my laptop boot faster and would > save the battery a bit. > > Being able to define profiles of the services that start in advance (I know > there is the interactive boot option) would IMHO be cool, however I don't > know if it's feasible or if you like it. That can be done by creating several runlevels, each one having its set of services enabled with chkconfig. Then in the Grub menu, you can add one entry per "profile" (i.e. passing the runlevel as a parameter to the kernel). Not sure how it can work with Upstart though, and if there is a maximum number of runlevels that can be created. ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From jdieter at gmail.com Wed Feb 4 13:15:25 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 04 Feb 2009 15:15:25 +0200 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <49898B56.70002@redhat.com> References: <498982C3.8030704@redhat.com> <1233749953.6180.5.camel@jdlaptop.lesbg.loc> <49898B56.70002@redhat.com> Message-ID: <1233753326.6180.9.camel@jdlaptop.lesbg.loc> On Wed, 2009-02-04 at 13:34 +0100, Phil Knirsch wrote: > Jonathan Dieter wrote: > > On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: > >> Hey folks. > >> > >> I've recently spent quite some time on researching and testing what > >> things we can do to make power management better in Fedora. For that > >> reason i've opened a Feature request for F11 with the basic stuff that i > >> think is doable for that release. > >> > >> So if you have a minute please take look over it and either send me some > >> feedback or edit the page yourself. :) > >> > >> In case you're interested in helping make power management better in F11 > >> feel free to participate in any form. > > > > Thanks much. Do you mind including a URL? > > > Ah ye, sorry, only had it in the subject: > > https://fedoraproject.org/wiki/Features/PowerManagement > Yeah, sorry, I didn't see that. Thanks, looks interesting. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Wed Feb 4 12:47:04 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 04 Feb 2009 12:47:04 +0000 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <49898B77.5010507@redhat.com> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> <49898B77.5010507@redhat.com> Message-ID: <1233751624.3441.18.camel@hughsie-work.lan> On Wed, 2009-02-04 at 13:35 +0100, Phil Knirsch wrote: > I'll add that right away to the page. Thanks Richard! Cool, thanks. One thing to make very clear is that we don't want to have lots of checkboxes like this: [ ] enable bluetooth on battery [X] enable ASPM on battery [X] enable hda-powersave on battery We can put the mechanism in the kernel, and leave the policy to userspace. Where we can we want to control latency, but enabling and disabling features (like bluetooth) as part of a power policy is pretty insane. I've written more stuff about using latency and using DeviceKit-power here: http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/ Soon, they'll be a new tab on the gnome-power-statistics application allowing you to see which applications are asking for reduced latency, and will allow an admin to override certain things. Richard. From galibert at pobox.com Wed Feb 4 13:30:03 2009 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 4 Feb 2009 14:30:03 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <1233749819.3441.11.camel@hughsie-work.lan> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> Message-ID: <20090204133003.GB81772@dspnet.fr.eu.org> On Wed, Feb 04, 2009 at 12:16:59PM +0000, Richard Hughes wrote: > On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: > > I've recently spent quite some time on researching and testing what > > things we can do to make power management better in Fedora. For that > > reason i've opened a Feature request for F11 with the basic stuff that > > i think is doable for that release. > > In the version of g-p-m and DeviceKit-power in rawhide, you can see some > new stuff like this: > http://blogs.gnome.org/hughsie/2009/01/30/gnome-power-manager-and-processor-wakeups/ > > It's basically a DBUS interface and session viewer for the data. Isn't dbus actually known bad for the battery? Something about client-level filtering waking up too many clients for every message? Or was that fixed? OG. From hughsient at gmail.com Wed Feb 4 13:42:42 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 4 Feb 2009 13:42:42 +0000 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <20090204133003.GB81772@dspnet.fr.eu.org> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> <20090204133003.GB81772@dspnet.fr.eu.org> Message-ID: <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> On Wed, Feb 4, 2009 at 1:30 PM, Olivier Galibert wrote: > On Wed, Feb 04, 2009 at 12:16:59PM +0000, Richard Hughes wrote: >> On Wed, 2009-02-04 at 12:57 +0100, Phil Knirsch wrote: >> > I've recently spent quite some time on researching and testing what >> > things we can do to make power management better in Fedora. For that >> > reason i've opened a Feature request for F11 with the basic stuff that >> > i think is doable for that release. >> >> In the version of g-p-m and DeviceKit-power in rawhide, you can see some >> new stuff like this: >> http://blogs.gnome.org/hughsie/2009/01/30/gnome-power-manager-and-processor-wakeups/ >> >> It's basically a DBUS interface and session viewer for the data. > > Isn't dbus actually known bad for the battery? Something about > client-level filtering waking up too many clients for every message? > Or was that fixed? Well, sending the data does cause a wakeup, yes. The interface stops polling if there's no client connected. To be honest, a few wakeups every 5 seconds is nothing compared to firefox and npviewer.bin. Richard. From kevin.kofler at chello.at Wed Feb 4 13:39:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 14:39:11 +0100 Subject: support for latest (radeon) hardware References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com> <497B0779.7020708@leemhuis.info> <20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info> <1232819460.8363.106.camel@localhost.localdomain> <1233084071.19014.36.camel@localhost.localdomain> <1233652933.30526.38.camel@localhost.localdomain> Message-ID: Callum Lerwick wrote: > I can't wrap my brain around what you're saying. If we had stuck with > the old working version, then it would be working and there would be no > problem. It would be working for YOU, but not for the guy/gal with the new hardware which is not yet supported in the old version (which is why we have this thread in the first place), nor for the guy/gal affected by one of the bugs fixed in the new version. Kevin Kofler From bdwheele at indiana.edu Wed Feb 4 13:47:00 2009 From: bdwheele at indiana.edu (Brian Wheeler) Date: Wed, 04 Feb 2009 08:47:00 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <4989491A.3070303@freenet.de> References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> <4989491A.3070303@freenet.de> Message-ID: <1233755220.13710.13.camel@nibbler.dlib.indiana.edu> On Wed, 2009-02-04 at 08:51 +0100, Ralf Corsepius wrote: > Brian Wheeler wrote: > > On Wed, 2009-02-04 at 01:27 +0100, Ralf Corsepius wrote: > >> seth vidal wrote: > >>> On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: > >>>> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: > >>>>> I fail to see how a solid cursor is that much harder to find than > >>>>> a blinking one. Unless you're only entering solid boxes as text? > >>>> There's a reason it's been like this in like ... forever. > >>>> Doesn't it strike you as strange to change one of the > >>>> longest established conventions on a whim?!? > >>> Tradition is not an argument in fedora. > >> Sometimes traditions have good reasons - There are reasons why wheels > >> are shaped round and not rectangular. > > > > Just as a nitpick, wheels are round for a technical reason, not because > > of tradition. > > A matter of perspective. Some will say cursors are blinking for > technical reasons. > Sure, but that's not the same. A wheel is defined (at least by wikipedia) as: a circular device that is capable of rotating on its axis. Does the definition of cursor require that it blink? > E.g. > * When using real terminals (or remote logins or runlevel 3), they often > are the only indication of a system being alive or not. As I posted elsewhere in this thread, my VT420 which is a real terminal by any definition, doesn't blink the cursor. Whether or not that was its default or not I can't say since I've had it for years and I got it second hand. > * Certain applications apply multiple cursors. The active one often is > blinking to highlight it. > Ok, fair enough. How does this apply to terminals? > Conversely: Most kids, at some point in their lifes will proudly present > their parents the vehicle with triangular or rectangular wheels they > assembled from LEGO kits or similar. > Ok, do the rectangular "wheels" do what a wheel traditionally does as well as a circular wheel? Nope, it doesn't...so there's a technical reason why a wheel is circular: it works. Just because something is called a wheel doesn't make it a wheel. Honestly, I don't care either way, though I do like saving power on my laptop. Brian "My ancestors apparently were cart makers" Wheeler From bochecha at fedoraproject.org Wed Feb 4 13:48:22 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Wed, 4 Feb 2009 14:48:22 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> <20090204133003.GB81772@dspnet.fr.eu.org> <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> Message-ID: <2d319b780902040548y2e19ecb7gfe9841faa0289c56@mail.gmail.com> > Well, sending the data does cause a wakeup, yes. The interface stops > polling if there's no client connected. > To be honest, a few wakeups every 5 seconds is nothing compared to > firefox and npviewer.bin. But that doesn't mean it shouldn't be addressed once Firefox and npviewer.cin have been fixed right ? :) ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin From kevin.kofler at chello.at Wed Feb 4 13:49:31 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 14:49:31 +0100 Subject: Too many unowned directories References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> Message-ID: Panu Matilainen wrote: > If mock/koji did a test install of the freshly built package into the > build chroot, that'd catch these and all sorts of other silly mistakes too > (Ever made a typo in manual dependency, scriptlet or so, making the > package uninstallable? I know I have...) without exposing the poor users > to packagers mistakes. That sounds like a good idea. If (and ONLY if) this is implemented, having the transaction fail on unowned directories would also be acceptable (but only after a mass rebuild to get all the current instances fixed). Kevin Kofler From bdwheele at indiana.edu Wed Feb 4 13:50:32 2009 From: bdwheele at indiana.edu (Brian Wheeler) Date: Wed, 04 Feb 2009 08:50:32 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <9497e9990902040147s77c90452ke0217e62975d413e@mail.gmail.com> References: <1233620984.27307.16.camel@rosebud> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> <4989491A.3070303@freenet.de> <9497e9990902040147s77c90452ke0217e62975d413e@mail.gmail.com> Message-ID: <1233755432.13710.14.camel@nibbler.dlib.indiana.edu> On Wed, 2009-02-04 at 09:47 +0000, Mat Booth wrote: > On Wed, Feb 4, 2009 at 7:51 AM, Ralf Corsepius wrote: > > Brian Wheeler wrote: > >> > >> On Wed, 2009-02-04 at 01:27 +0100, Ralf Corsepius wrote: > >>> > >>> seth vidal wrote: > >>>> > >>>> On Tue, 2009-02-03 at 15:53 -0500, Dimi Paun wrote: > >>>>> > >>>>> On Tue, 2009-02-03 at 15:09 -0500, Bill Nottingham wrote: > >>>>>> > >>>>>> I fail to see how a solid cursor is that much harder to find than > >>>>>> a blinking one. Unless you're only entering solid boxes as text? > >>>>> > >>>>> There's a reason it's been like this in like ... forever. > >>>>> Doesn't it strike you as strange to change one of the > >>>>> longest established conventions on a whim?!? > >>>> > >>>> Tradition is not an argument in fedora. > >>> > >>> Sometimes traditions have good reasons - There are reasons why wheels are > >>> shaped round and not rectangular. > >> > >> Just as a nitpick, wheels are round for a technical reason, not because > >> of tradition. > > > > A matter of perspective. Some will say cursors are blinking for technical > > reasons. > > > > Hey, the guy's name is "Wheeler". If anyone ought to know why they're > round, it's him. ;-) That's the theory, at least :) From kevin.kofler at chello.at Wed Feb 4 13:47:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 14:47:05 +0100 Subject: Too many unowned directories References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> Message-ID: Nicolas Mailhot wrote: > BTW, I could simplify the multi-font spec template a lot if having > multiple subpackages own the same font directory was accepted. Uh, this is already allowed by the guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership > Although the rule of thumb is the same: own all the directories you create > but none of the directories of packages you depend on, there are several > instances where it's desirable for multiple packages to own a directory. And then it gives 2 examples. Example 2 sounds a lot like the situation with those font subpackages. Kevin Kofler From hughsient at gmail.com Wed Feb 4 13:58:45 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 4 Feb 2009 13:58:45 +0000 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <2d319b780902040548y2e19ecb7gfe9841faa0289c56@mail.gmail.com> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> <20090204133003.GB81772@dspnet.fr.eu.org> <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> <2d319b780902040548y2e19ecb7gfe9841faa0289c56@mail.gmail.com> Message-ID: <15e53e180902040558x2b7a276fua9a2d7a4290d6d32@mail.gmail.com> On Wed, Feb 4, 2009 at 1:48 PM, Mathieu Bridon (bochecha) wrote: >> Well, sending the data does cause a wakeup, yes. The interface stops >> polling if there's no client connected. >> To be honest, a few wakeups every 5 seconds is nothing compared to >> firefox and npviewer.bin. > > But that doesn't mean it shouldn't be addressed once Firefox and > npviewer.cin have been fixed right ? :) Well, when DeviceKit-power is in the first three entries of the listing, then we've won the power management battle and we can all go home. :-) Richard. From kevin.kofler at chello.at Wed Feb 4 14:00:01 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 15:00:01 +0100 Subject: Features/ArchitectureSupport - changing what we build for References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <1233692950.17218.107.camel@localhost.localdomain> Message-ID: Callum Lerwick wrote: > Going -O3 rather than -O2 is going to make a bigger difference than > anything else. If you want to improve performance, you need to run > profiles, locate performance critical bits of code, figure out if -O3 is > beneficial, and/or write some hand tuned assembly/intrinsic code. > > Not to mention, the biggest performance problem on modern processors is > memory. Minimizing cache thrashing is way more important than what > instructions you use. Optimize data structures before code. That's actually an argument for investigating -Os, not -O3. Kevin Kofler From kevin.kofler at chello.at Wed Feb 4 14:01:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 15:01:12 +0100 Subject: Features/ArchitectureSupport - changing what we build for References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130231847.GA20809@host0.dyn.jankratochvil.net> <20090202174624.GE20094@nostromo.devel.redhat.com> <20090203120738.GA20587@host0.dyn.jankratochvil.net> Message-ID: Jan Kratochvil wrote: > I find hard to believe Fedora still in the 21st century suggests degrading > the machine by a 32bit OS: http://fedoraproject.org/get-fedora +1 The x86_64 version ought to be the default! In the current presentation, it's hidden really badly (you need to go to the complete list). Kevin Kofler From kevin.kofler at chello.at Wed Feb 4 14:08:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 15:08:59 +0100 Subject: Why do we disable esd in libgnome? References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> <498906FE.9090107@redhat.com> Message-ID: Christopher Aillon wrote: > Being realistic, people will never change unless they have to. Whether > that happens now, or in GNOME 3.0 is pretty much irrelevant. It has to > happen sometime, might as well be now. But the thing is, apps have not been ported in time for Fedora 10, so it was a mistake to disable this in Fedora 10, it should be reenabled in an update ASAP. You need to get apps ported in Rawhide first, then the API can be disabled for the next release. Kevin Kofler From kevin.kofler at chello.at Wed Feb 4 14:12:07 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 15:12:07 +0100 Subject: OpenSSL symlink hack References: <1233564080.3600.82.camel@vespa.frost.loc> Message-ID: Tomas Mraz wrote: > There are still the following packages which were not rebuilt either > because they FTBFS due to problems unrelated to the OpenSSL upgrade or > because they have closed commit ACLs for provenpackagers. We should get those ACLs forcefully opened. It's clear that the maintainers are unable to fix the problems with their packages on their own in a reasonable timeframe, so they MUST allow others to step in. Kevin Kofler From notting at redhat.com Wed Feb 4 14:26:09 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Feb 2009 09:26:09 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <4988D70A.3090303@redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> Message-ID: <20090204142609.GC3879@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > This is a silly notion. Atom requires code to be built entirely > differently from all modern processors in order to get maximum > performance. Code must be optimized for in-line performance. Atom > target support hasn't even hit gcc-4.4 yet. Interestingly, using the parts of OpenBench that can actually be cajoled to build and run correctly (why are benchmark suites such pain?)... the best option for atom is -march=i686 -mtune=generic. Tuning for i586 (the previous in-order processor) doesn't actually help. Also, -march=i686 was a win over -march=i586, in general, in testing across Atom, Core2Duo, and a Athlon64, although not a particularly significant one. Bill From ajax at redhat.com Wed Feb 4 14:27:31 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 04 Feb 2009 09:27:31 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <5256d0b0902032239j6b6b36a1l620cf95ab00eed90@mail.gmail.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> <1233701656.1833.61.camel@atropine.boston.devel.redhat.com> <5256d0b0902032239j6b6b36a1l620cf95ab00eed90@mail.gmail.com> Message-ID: <1233757651.1833.994.camel@atropine.boston.devel.redhat.com> On Wed, 2009-02-04 at 06:39 +0000, Peter Robinson wrote: > >> > Just a note, I believe that the ia32 support should "concentrate" on > >> > netbooks (So Intel Atom), those are the only new things on the market > >> > that can't run x86_64, and the userbase of those will just grow and > >> > every percent of extra performance will make many people happy. > >> > >> So we should ignore OLPC that is deploying 100's of thousands all > >> running Fedora? > > > > Modest proposal: OLPC might benefit from running its own koji instance > > and effectively going the secondary arch route. -Os -march=geode, etc. > > Given how close it is to mainline x86 it's unlikely to have funky > > compilation failures, and it has to branch a non-trivial number of > > packages anyway. > > Actually the forked packages now are pretty minimal. I think there's > currently around a dozen, with the move the F11 that will be even > less. The major fork is the kernel but other than that most of the > forks are to slim down deps. Okay, ignore the bit about forked packages. How's the rest of the argument sound? - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gauret at free.fr Wed Feb 4 14:29:08 2009 From: gauret at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Bompard?=) Date: Wed, 4 Feb 2009 15:29:08 +0100 Subject: Build succeeds in mock but fails in koji In-Reply-To: References: <49895B58.6030403@ioa.s.u-tokyo.ac.jp> Message-ID: OK, I found out what's going on, thanks to your trick. For reference, in old versions of the autotools gettext detection code, the test code fails on x86_64 with a "cast from 'char*' to 'int' loses precision" error. As a result, gettext is not detected, and the translations are not built. Thanks for your help. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rick Cook From kevin.kofler at chello.at Wed Feb 4 14:35:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 15:35:23 +0100 Subject: What is the state of bulez4? References: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> Message-ID: Paulo Cavalcanti wrote: > since I started using F10 in my main computer, I have > not been able to pair a single bluetooth device, > either using bluez-gnome or hidd. I cannot speak for the GNOME tools (but I thought they're already supposed to be working? Can any maintainer of GNOME or bluez-gnome comment?), but kdebluetooth support (kdebluetooth4 0.3) is coming as part of the KDE 4.2.0 update. Kevin Kofler From bnocera at redhat.com Wed Feb 4 14:48:27 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 04 Feb 2009 14:48:27 +0000 Subject: What is the state of bulez4? In-Reply-To: References: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> Message-ID: <1233758907.3233.40.camel@cookie.hadess.net> On Wed, 2009-02-04 at 15:35 +0100, Kevin Kofler wrote: > Paulo Cavalcanti wrote: > > since I started using F10 in my main computer, I have > > not been able to pair a single bluetooth device, > > either using bluez-gnome or hidd. > > I cannot speak for the GNOME tools (but I thought they're already supposed > to be working? Can any maintainer of GNOME or bluez-gnome comment?), They're already supposed to be working indeed, since Fedora 10 was released. There's certainly bugs, but I gather this is more likely to be a kernel regression. Check your /var/log/messages for Bluetooth-related kernel and bluetoothd errors. Some devices have been known to be problematic with recent kernel changes. My guess is a duplicate of: https://bugzilla.redhat.com/show_bug.cgi?id=481221 > but > kdebluetooth support (kdebluetooth4 0.3) is coming as part of the KDE 4.2.0 > update. Cheers From pbrobinson at gmail.com Wed Feb 4 15:01:05 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 4 Feb 2009 16:01:05 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <1233757651.1833.994.camel@atropine.boston.devel.redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> <1233701656.1833.61.camel@atropine.boston.devel.redhat.com> <5256d0b0902032239j6b6b36a1l620cf95ab00eed90@mail.gmail.com> <1233757651.1833.994.camel@atropine.boston.devel.redhat.com> Message-ID: <5256d0b0902040701q432a79f3p9f4152a9b361e9b0@mail.gmail.com> >> >> So we should ignore OLPC that is deploying 100's of thousands all >> >> running Fedora? >> > >> > Modest proposal: OLPC might benefit from running its own koji instance >> > and effectively going the secondary arch route. -Os -march=geode, etc. >> > Given how close it is to mainline x86 it's unlikely to have funky >> > compilation failures, and it has to branch a non-trivial number of >> > packages anyway. >> >> Actually the forked packages now are pretty minimal. I think there's >> currently around a dozen, with the move the F11 that will be even >> less. The major fork is the kernel but other than that most of the >> forks are to slim down deps. > > Okay, ignore the bit about forked packages. How's the rest of the > argument sound? Sounds fine to me but I'm by no means an expert in compiler options for different architectures :-) What sort of a win would we see performance wise. Does it get done for all the packages or for just things like kernel/glibc/openssl like it currently does for some of the i386 packages? Peter From tcallawa at redhat.com Wed Feb 4 15:02:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Feb 2009 10:02:04 -0500 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <49895101.6060201@hhs.nl> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <49895101.6060201@hhs.nl> Message-ID: <4989ADEC.1020202@redhat.com> On 2009-02-04 at 3:25:37 -0500, Hans de Goede wrote: > Christoph H?ger wrote: >> Hi, >> >> fedora has recently been tested (again) and compared against other >> distributions (Ubuntu and OpenSUSE) by c't, a german IT magazine from >> the heise publishing house. >> >> Among other criticisms one thing was really annoying: When a user >> installs fedora on a machine with windows installed (common use case) it >> detects that installation and offers to add it to grub. But installing >> fedora on a box with an already present linux distro installation will >> yield that installation removed from grub. >> >> I understand that the bootloader is a part of the distro and its >> configuration gets changed e.g. during kernel updates, but is there >> really only the answer to remove one distribution completely? >> Do we really want to support Windows as second OS more than OpenSUSE or >> Ubuntu (or CentOS, or Debian, or Gentoo, or ........) >> At least the anaconda team should consider printing a warning about one >> OS going to "be lost" during install and how to recover. >> >> Any thoughts on that? >> > > Patches welcome comes to mind. It's worth noting for anyone doing this work that in F10, grub is not really displayed anymore. I don't know if the timeout is changed from 0 if Windows is added to the grub.conf, but it probably should be (and any changes to add other Linux distributions to the grub conf should also reset the timeout from 0 as well). ~spot From tcallawa at redhat.com Wed Feb 4 15:05:50 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Feb 2009 10:05:50 -0500 Subject: pgadmin3 license change In-Reply-To: <49897D78.7020700@nobugconsulting.ro> References: <1233746823.3357.229.camel@laptop.gunduz.org> <49897D78.7020700@nobugconsulting.ro> Message-ID: <4989AECE.7090703@redhat.com> On 2009-02-04 at 6:35:20 -0500, Manuel Wolfshant wrote: > In that case I guess we can just transfer it back from rpmfusion (where > 1.8.4 resides now). Please sync with Robert for a smooth transition. I did not kill the cvs for pgadmin3, I simply blocked the package with rel-eng. Just bring the changes over and ask rel-eng to lift the block. ~spot From xjakub at fi.muni.cz Wed Feb 4 15:11:20 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Wed, 04 Feb 2009 16:11:20 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <4989B018.804@fi.muni.cz> Jakub Jelinek wrote: > Hi! > > In the past few days I've done a mass rebuild of rawhide-20090126 > in mock with gcc-4.4.0-0.9 (and corresponding libtool). > 6228 packages were successfully built, for the rest I've tried > to rebuild them also with gcc-4.3.2-7 (though I ran out of time, > so a couple of packages weren't attempted with 4.3). If we fix a package, are we supposed to perform a normal (i.e. not scratch) build into dist-f11-gcc44 (and/or dist-f11)? Or should we just tag and let it be (for a new mass rebuild)? Regards, Milos Jakubicek From jakub at redhat.com Wed Feb 4 15:16:33 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 4 Feb 2009 16:16:33 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <4989B018.804@fi.muni.cz> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <4989B018.804@fi.muni.cz> Message-ID: <20090204151633.GQ5690@tyan-ft48-01.lab.bos.redhat.com> On Wed, Feb 04, 2009 at 04:11:20PM +0100, Milos Jakubicek wrote: >> In the past few days I've done a mass rebuild of rawhide-20090126 >> in mock with gcc-4.4.0-0.9 (and corresponding libtool). >> 6228 packages were successfully built, for the rest I've tried >> to rebuild them also with gcc-4.3.2-7 (though I ran out of time, >> so a couple of packages weren't attempted with 4.3). > > If we fix a package, are we supposed to perform a normal (i.e. not > scratch) build into dist-f11-gcc44 (and/or dist-f11)? Or should we just > tag and let it be (for a new mass rebuild)? Either just tag, or tag and build into dist-f11. Jakub From bnocera at redhat.com Wed Feb 4 15:28:25 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 04 Feb 2009 15:28:25 +0000 Subject: Why do we disable esd in libgnome? In-Reply-To: References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20090202145646.GB32202@tango.0pointer.de> <91705d080902020718x7e3a8fcn3017c891bd43ac1e@mail.gmail.com> <1233594311.3486.1169.camel@cookie.hadess.net> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> <498906FE.9090107@redhat.com> Message-ID: <1233761305.3233.83.camel@cookie.hadess.net> On Wed, 2009-02-04 at 15:08 +0100, Kevin Kofler wrote: > Christopher Aillon wrote: > > Being realistic, people will never change unless they have to. Whether > > that happens now, or in GNOME 3.0 is pretty much irrelevant. It has to > > happen sometime, might as well be now. > > But the thing is, apps have not been ported in time for Fedora 10, so it was > a mistake to disable this in Fedora 10, it should be reenabled in an update > ASAP. > > You need to get apps ported in Rawhide first, then the API can be disabled > for the next release https://bugzilla.redhat.com/show_bug.cgi?id=475442 I also don't think it should have been done in a released version. We won't be changing this for rawhide though. Cheers From ivazqueznet at gmail.com Wed Feb 4 15:40:25 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 04 Feb 2009 10:40:25 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204142609.GC3879@nostromo.devel.redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> <20090204142609.GC3879@nostromo.devel.redhat.com> Message-ID: <1233762026.26470.93.camel@ignacio.lan> On Wed, 2009-02-04 at 09:26 -0500, Bill Nottingham wrote: > Also, -march=i686 was a win over -march=i586, in general, in testing > across Atom, Core2Duo, and a Athlon64, although not a particularly > significant one. How do they compare versus -march=i386? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Feb 4 15:42:51 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Feb 2009 10:42:51 -0500 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <498982C3.8030704@redhat.com> References: <498982C3.8030704@redhat.com> Message-ID: <20090204154251.GA3301@nostromo.devel.redhat.com> Phil Knirsch (pknirsch at redhat.com) said: > In case you're interested in helping make power management better in F11 > feel free to participate in any form. I'd really like to find a way to get all the things listed in Documentation set up automatically for the user where appropriate - we should have all this stuff by default. Bill From kevin.kofler at chello.at Wed Feb 4 15:43:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 04 Feb 2009 16:43:33 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement References: <498982C3.8030704@redhat.com> Message-ID: Phil Knirsch wrote: > So if you have a minute please take look over it and either send me some > feedback or edit the page yourself. :) As I noted on the discussion page: IMHO, this needs more details on: * what parts of this are inherently GNOME-specific (because they reside in gnome-power-manager), * what parts are currently GNOME-specific, but should see support in KDE's PowerDevil (i.e. task items for KDE SIG), * what parts are systemwide (e.g. relatime). Kevin Kofler From promac at gmail.com Wed Feb 4 15:46:59 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 4 Feb 2009 13:46:59 -0200 Subject: What is the state of bulez4? In-Reply-To: <1233758907.3233.40.camel@cookie.hadess.net> References: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> <1233758907.3233.40.camel@cookie.hadess.net> Message-ID: <68720af30902040746h264e0dc9wdb66247f34cc67c0@mail.gmail.com> On Wed, Feb 4, 2009 at 12:48 PM, Bastien Nocera wrote: > On Wed, 2009-02-04 at 15:35 +0100, Kevin Kofler wrote: > > Paulo Cavalcanti wrote: > > > since I started using F10 in my main computer, I have > > > not been able to pair a single bluetooth device, > > > either using bluez-gnome or hidd. > > > > I cannot speak for the GNOME tools (but I thought they're already > supposed > > to be working? Can any maintainer of GNOME or bluez-gnome comment?), > > They're already supposed to be working indeed, since Fedora 10 was > released. There's certainly bugs, but I gather this is more likely to be > a kernel regression. > > Check your /var/log/messages for Bluetooth-related kernel and bluetoothd > errors. Some devices have been known to be problematic with recent > kernel changes. > Using hcidump and hidd: [cascavel:~] sudo hidd --search Searching ... Connecting to device 00:12:5A:69:05:87 Can't get device information: Connection reset by peer [cascavel:~] sudo /usr/sbin/hcidump HCI sniffer - Bluetooth packet analyzer ver 1.42 device: hci0 snap_len: 1028 filter: 0xffffffffffffffff < HCI Command: Inquiry (0x01|0x0001) plen 5 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Inquiry Result with RSSI (0x22) plen 15 > HCI Event: Inquiry Complete (0x01) plen 1 < HCI Command: Create Connection (0x01|0x0005) plen 13 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Connect Complete (0x03) plen 11 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 > HCI Event: Command Status (0x0f) plen 4 < HCI Command: Remote Name Request (0x01|0x0019) plen 10 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Remote Name Req Complete (0x07) plen 255 > HCI Event: Disconn Complete (0x05) plen 4 < HCI Command: Create Connection (0x01|0x0005) plen 13 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Connect Complete (0x03) plen 11 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 > HCI Event: Command Status (0x0f) plen 4 < HCI Command: Remote Name Request (0x01|0x0019) plen 10 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Remote Name Req Complete (0x07) plen 255 > HCI Event: Disconn Complete (0x05) plen 4 ^C > > My guess is a duplicate of: > https://bugzilla.redhat.com/show_bug.cgi?id=481221 > I do not see anything unusual in /var/log/messages: Feb 4 08:22:24 cascavel pulseaudio[5490]: pid.c: Daemon already running. Feb 4 08:24:22 cascavel bluetoothd[6007]: Bluetooth daemon Feb 4 08:24:22 cascavel bluetoothd[6007]: Starting SDP server Feb 4 08:24:22 cascavel kernel: Bluetooth: L2CAP ver 2.11 Feb 4 08:24:22 cascavel kernel: Bluetooth: L2CAP socket layer initialized Feb 4 08:24:22 cascavel bluetoothd[6007]: Parsing /etc/bluetooth/input.conf failed: No such file or directory Feb 4 08:24:22 cascavel bluetoothd[6007]: Parsing /etc/bluetooth/audio.conf failed: No such file or directory Feb 4 08:24:22 cascavel kernel: Bluetooth: SCO (Voice Link) ver 0.6 Feb 4 08:24:22 cascavel kernel: Bluetooth: SCO socket layer initialized Feb 4 08:24:22 cascavel bluetoothd[6007]: Parsing /etc/bluetooth/network.conf failed: No such file or directory Feb 4 08:24:22 cascavel kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Feb 4 08:24:22 cascavel kernel: Bluetooth: BNEP filters: protocol multicast Feb 4 08:24:22 cascavel kernel: Bridge firewalling registered Feb 4 08:24:22 cascavel bluetoothd[6007]: bridge pan0 created Feb 4 08:24:22 cascavel bluetoothd[6007]: Registered interface org.bluez.Service on path /org/bluez/6007/any Feb 4 08:24:22 cascavel bluetoothd[6007]: HCI dev 0 registered Feb 4 08:24:22 cascavel bluetoothd[6007]: HCI dev 0 up Feb 4 08:24:22 cascavel bluetoothd[6007]: Starting security manager 0 Feb 4 08:24:22 cascavel bluetoothd[6007]: Registered interface org.bluez.SerialProxyManager on path /org/bluez/6007/hci0 Feb 4 08:24:22 cascavel kernel: Bluetooth: RFCOMM socket layer initialized Feb 4 08:24:22 cascavel kernel: Bluetooth: RFCOMM TTY layer initialized Feb 4 08:24:22 cascavel kernel: Bluetooth: RFCOMM ver 1.10 Feb 4 08:24:22 cascavel bluetoothd[6007]: Registered interface org.bluez.NetworkPeer on path /org/bluez/6007/hci0 Feb 4 08:24:22 cascavel bluetoothd[6007]: Registered interface org.bluez.NetworkHub on path /org/bluez/6007/hci0 Feb 4 08:24:22 cascavel bluetoothd[6007]: Registered interface org.bluez.NetworkRouter on path /org/bluez/6007/hci0 Feb 4 08:24:22 cascavel bluetoothd[6007]: Registered interface org.bluez.Service on path /org/bluez/6007/hci0 Feb 4 08:24:22 cascavel bluetoothd[6007]: Adapter /org/bluez/6007/hci0 has been enabled -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From billcrawford1970 at gmail.com Wed Feb 4 15:52:09 2009 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 4 Feb 2009 15:52:09 +0000 Subject: RFC: Disabling blinking cursor by default In-Reply-To: References: <20090130053144.GA25512@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> Message-ID: <200902041552.09632.billcrawford1970@gmail.com> On Tuesday 03 February 2009 11:44:42 Panu Matilainen wrote: > Blinking things tend to draw attention, and in the case of Blinky the > Cursor it's drawing your attention to the fact that there is nothing at > all to attend to. It can also cause seizures for people with epilepsy or > other disorders. > > Now, somebody please tell me: what is the grande justification of > consuming a few extra wats per every computer in the world to attempt to > draw the users attention to exactly nothing, despite being known to cause > health issues to some people while doing so? And "it's always done that" > is not an answer. Where the input location is in a large text document or piece of code I've just opened up in a 211x72 xterm? If (for some reason) it's not in the middle of the screen, it can be hard to spot; I'd like for it to blink a few times when I first give the xterm focus (yes, it's more or less full screen, and yes, I have multiple screens, so I've completely lost track of where in the window I was when I turn back to it). From pknirsch at redhat.com Wed Feb 4 16:04:56 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 04 Feb 2009 17:04:56 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <20090204154251.GA3301@nostromo.devel.redhat.com> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> Message-ID: <4989BCA8.8090302@redhat.com> Bill Nottingham wrote: > Phil Knirsch (pknirsch at redhat.com) said: >> In case you're interested in helping make power management better in F11 >> feel free to participate in any form. > > I'd really like to find a way to get all the things listed in Documentation > set up automatically for the user where appropriate - we should have > all this stuff by default. > > Bill > Thats a good point Bill. Of course most of the first points are things that the user just needs to do himself (power off his machine, choose the right dimension for the work he's doing etc). From the pure system ones i know that we at least already use the ondemand by default as soon as the CPU supports it, so we should be fine there. Network card speeds and harddisk spindowns is a bit tricker imo, though we probably could enable a higher powersave mode for harddisk by default at least in case a user wants to save power. Some of this is/will be addressed by the tuned i'm working on which monitors the usage of network and harddisk devices and dynamically adapts the settings to the current use. Laptop mode and a higher value for dirty_writeback_centisecs, there i'm personally torn a bit myself. I personally do use it on all my machines (laptop and desktop), but i can understand people who are a bit paranoid about their data integrity not wanting to have that by default. But i'd personally be all for going that way. In regard to relatime from what i've found so far we seem to be doing that already by default it seems, though i'd like to have that verified. Then disabling CD-ROM polling is definitely something for the ServerSIG, but on a default Desktop i think the user experience would suffer if we would do that by default. Enabling USB autosuspend looks like a good candidate for being a default though. I've used it on quite a few Fedora 10 machines around here and haven't experienced any problems so far, so it seems to have matured enough by now from what i can see. Last but not least the dpms off, i think that should definitely be part of the Desktop screensaver defaults, especially if you look at how much power a modern LCD display eats when it's only dimmed down to black. Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From ajax at redhat.com Wed Feb 4 16:06:04 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 04 Feb 2009 11:06:04 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <5256d0b0902040701q432a79f3p9f4152a9b361e9b0@mail.gmail.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <5256d0b0902031350h3ce9c476x57aefe7c8bcfba8@mail.gmail.com> <1233701656.1833.61.camel@atropine.boston.devel.redhat.com> <5256d0b0902032239j6b6b36a1l620cf95ab00eed90@mail.gmail.com> <1233757651.1833.994.camel@atropine.boston.devel.redhat.com> <5256d0b0902040701q432a79f3p9f4152a9b361e9b0@mail.gmail.com> Message-ID: <1233763564.1833.1193.camel@atropine.boston.devel.redhat.com> On Wed, 2009-02-04 at 16:01 +0100, Peter Robinson wrote: > >> >> So we should ignore OLPC that is deploying 100's of thousands all > >> >> running Fedora? > >> > > >> > Modest proposal: OLPC might benefit from running its own koji instance > >> > and effectively going the secondary arch route. -Os -march=geode, etc. > >> > Given how close it is to mainline x86 it's unlikely to have funky > >> > compilation failures, and it has to branch a non-trivial number of > >> > packages anyway. > >> > >> Actually the forked packages now are pretty minimal. I think there's > >> currently around a dozen, with the move the F11 that will be even > >> less. The major fork is the kernel but other than that most of the > >> forks are to slim down deps. > > > > Okay, ignore the bit about forked packages. How's the rest of the > > argument sound? > > Sounds fine to me but I'm by no means an expert in compiler options > for different architectures :-) What sort of a win would we see > performance wise. Does it get done for all the packages or for just > things like kernel/glibc/openssl like it currently does for some of > the i386 packages? Would be hard to know the performance win without trying it. But since you're already bootstrapped, a mass rebuild would "only" be a few days on a reasonably fast machine. It might be only a few percent of wall clock performance, but depending how much RAM -Os saves, you might thrash less, etc. (Roughly the same arguments apply for any global compiler changes, for that matter.) Doing this as a secondary arch would mean all packages would get rebuilt. I'm only kind of serious about this, since we really don't have secondary arch support yet. But I think there's some merit in splitting off sufficiently old (or subsetted) x86 from the real world. Particularly if it means I can stop waiting for i586 kernels to build just to get the i686 kernel I really want. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pknirsch at redhat.com Wed Feb 4 16:17:12 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 04 Feb 2009 17:17:12 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: References: <498982C3.8030704@redhat.com> Message-ID: <4989BF88.9090603@redhat.com> Kevin Kofler wrote: > Phil Knirsch wrote: >> So if you have a minute please take look over it and either send me some >> feedback or edit the page yourself. :) > > As I noted on the discussion page: > > IMHO, this needs more details on: > * what parts of this are inherently GNOME-specific (because they reside in > gnome-power-manager), > * what parts are currently GNOME-specific, but should see support in KDE's > PowerDevil (i.e. task items for KDE SIG), > * what parts are systemwide (e.g. relatime). > > Kevin Kofler > Hi Kevin. I've tried to keep it as Desktop independant as possible. The things i currently have on the page don't require any specific desktop. I think that in case there are specific things those need to be individually addressed by each Desktop, e.g. if PowerDevil should get powertop support like g-p-m now has then that needs to be done there of course. That being said, having sane defaults for each Desktop is certainly important, e.g. having a decently short screensaver DPMS off setting as default or sane settings for the various power saving templates that g-p-m and PowerDevil support (last time i checked both had already good defaults there). Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From sandeen at redhat.com Wed Feb 4 16:25:56 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 04 Feb 2009 10:25:56 -0600 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <4989BCA8.8090302@redhat.com> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> Message-ID: <4989C194.4070509@redhat.com> Phil Knirsch wrote: > Bill Nottingham wrote: >> Phil Knirsch (pknirsch at redhat.com) said: >>> In case you're interested in helping make power management better in F11 >>> feel free to participate in any form. >> I'd really like to find a way to get all the things listed in Documentation >> set up automatically for the user where appropriate - we should have >> all this stuff by default. >> >> Bill >> > > Thats a good point Bill. > > Of course most of the first points are things that the user just needs > to do himself (power off his machine, choose the right dimension for the > work he's doing etc). > > From the pure system ones i know that we at least already use the > ondemand by default as soon as the CPU supports it, so we should be fine > there. > > Network card speeds and harddisk spindowns is a bit tricker imo, though > we probably could enable a higher powersave mode for harddisk by default > at least in case a user wants to save power. Some of this is/will be > addressed by the tuned i'm working on which monitors the usage of > network and harddisk devices and dynamically adapts the settings to the > current use. See also: [Bug 454582] Tracker bug for over-eager apps that won't let disks spin down there are still some open bugs under that: Bug 454574 - mono writing to filesystem far too frequently Bug 457155 - Tomboy wakes up hard disk frecuently Bug 466601 - wpa_supplicant writing pointless(?) messages to log every 60s Bug 479192 - audit log written whenever cron wakes up, keeps disks spun up > Laptop mode and a higher value for dirty_writeback_centisecs, there i'm > personally torn a bit myself. I personally do use it on all my machines > (laptop and desktop), but i can understand people who are a bit paranoid > about their data integrity not wanting to have that by default. But i'd > personally be all for going that way. > > In regard to relatime from what i've found so far we seem to be doing > that already by default it seems, though i'd like to have that verified. > > Then disabling CD-ROM polling is definitely something for the ServerSIG, > but on a default Desktop i think the user experience would suffer if we > would do that by default. > > Enabling USB autosuspend looks like a good candidate for being a default > though. I've used it on quite a few Fedora 10 machines around here and > haven't experienced any problems so far, so it seems to have matured > enough by now from what i can see. > > Last but not least the dpms off, i think that should definitely be part > of the Desktop screensaver defaults, especially if you look at how much > power a modern LCD display eats when it's only dimmed down to black. Another one I'll add is powersave for audio hardware; I'll change the kernel default now (meant to do that last week and wandered off some other shiny thing instead). There's some fear that it may cause clicks/pops on some hardware but we can get it in now and find out. -Eric From yersinia.spiros at gmail.com Wed Feb 4 16:33:03 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Wed, 4 Feb 2009 17:33:03 +0100 Subject: Too many unowned directories In-Reply-To: References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> Message-ID: On Wed, Feb 4, 2009 at 2:47 PM, Kevin Kofler wrote: > Nicolas Mailhot wrote: >> BTW, I could simplify the multi-font spec template a lot if having >> multiple subpackages own the same font directory was accepted. What is more probably it will semplify automatically, and enforce them, what it is required by the Perl Package Guideline in the case described in the Directory Ownership Section. Regards From P at draigBrady.com Wed Feb 4 16:34:40 2009 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 4 Feb 2009 16:34:40 +0000 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090204142609.GC3879@nostromo.devel.redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> <20090204142609.GC3879@nostromo.devel.redhat.com> Message-ID: <4989C3A0.5050504@draigBrady.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> This is a silly notion. Atom requires code to be built entirely >> differently from all modern processors in order to get maximum >> performance. Code must be optimized for in-line performance. Atom >> target support hasn't even hit gcc-4.4 yet. > > Interestingly, using the parts of OpenBench that can actually be > cajoled to build and run correctly (why are benchmark suites such > pain?)... the best option for atom is -march=i686 -mtune=generic. > Tuning for i586 (the previous in-order processor) doesn't actually > help. -march=i686 is better than i586, but is it the best. I though -march=prescott was optimal for atom? > > Also, -march=i686 was a win over -march=i586, in general, in testing > across Atom, Core2Duo, and a Athlon64, although not a particularly > significant one. From galibert at pobox.com Wed Feb 4 16:37:05 2009 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 4 Feb 2009 17:37:05 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> <20090204133003.GB81772@dspnet.fr.eu.org> <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> Message-ID: <20090204163704.GA13577@dspnet.fr.eu.org> On Wed, Feb 04, 2009 at 01:42:42PM +0000, Richard Hughes wrote: > Well, sending the data does cause a wakeup, yes. The interface stops > polling if there's no client connected. If I understood correctly, the problem was more about the "wideness" of the wakeup, i.e. everything connected to the bus was waking up, unswapping, etc rather than just what was interested by the message. > To be honest, a few wakeups every 5 seconds is nothing compared to > firefox and npviewer.bin. And the blinking cursor, don't forget the blinking cursor. OG. From pknirsch at redhat.com Wed Feb 4 16:41:36 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 04 Feb 2009 17:41:36 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <4989C194.4070509@redhat.com> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <4989C194.4070509@redhat.com> Message-ID: <4989C540.5080208@redhat.com> Eric Sandeen wrote: > Phil Knirsch wrote: >> Bill Nottingham wrote: >>> Phil Knirsch (pknirsch at redhat.com) said: >>>> In case you're interested in helping make power management better in F11 >>>> feel free to participate in any form. >>> I'd really like to find a way to get all the things listed in Documentation >>> set up automatically for the user where appropriate - we should have >>> all this stuff by default. >>> >>> Bill >>> >> Thats a good point Bill. >> >> Of course most of the first points are things that the user just needs >> to do himself (power off his machine, choose the right dimension for the >> work he's doing etc). >> >> From the pure system ones i know that we at least already use the >> ondemand by default as soon as the CPU supports it, so we should be fine >> there. >> >> Network card speeds and harddisk spindowns is a bit tricker imo, though >> we probably could enable a higher powersave mode for harddisk by default >> at least in case a user wants to save power. Some of this is/will be >> addressed by the tuned i'm working on which monitors the usage of >> network and harddisk devices and dynamically adapts the settings to the >> current use. > > See also: > [Bug 454582] Tracker bug for over-eager apps that won't let disks spin down > > there are still some open bugs under that: > > Bug 454574 - mono writing to filesystem far too frequently > Bug 457155 - Tomboy wakes up hard disk frecuently > Bug 466601 - wpa_supplicant writing pointless(?) messages to log every 60s > Bug 479192 - audit log written whenever cron wakes up, keeps disks spun up > Ah great. I've used the disknettop.stp i've written to start identifying some of those as well and have a few more for which i'll open BZs' in the next fw days. I'll just hook them up to the tracker bug then as well. Would an overall tracker bug make sense for the whole power management changes we might be looking at? >> Laptop mode and a higher value for dirty_writeback_centisecs, there i'm >> personally torn a bit myself. I personally do use it on all my machines >> (laptop and desktop), but i can understand people who are a bit paranoid >> about their data integrity not wanting to have that by default. But i'd >> personally be all for going that way. >> >> In regard to relatime from what i've found so far we seem to be doing >> that already by default it seems, though i'd like to have that verified. >> >> Then disabling CD-ROM polling is definitely something for the ServerSIG, >> but on a default Desktop i think the user experience would suffer if we >> would do that by default. >> >> Enabling USB autosuspend looks like a good candidate for being a default >> though. I've used it on quite a few Fedora 10 machines around here and >> haven't experienced any problems so far, so it seems to have matured >> enough by now from what i can see. >> >> Last but not least the dpms off, i think that should definitely be part >> of the Desktop screensaver defaults, especially if you look at how much >> power a modern LCD display eats when it's only dimmed down to black. > > Another one I'll add is powersave for audio hardware; I'll change the > kernel default now (meant to do that last week and wandered off some > other shiny thing instead). There's some fear that it may cause > clicks/pops on some hardware but we can get it in now and find out. > Ah yes, forgot to add those. You're refering to the hda_intel and ac97 power_save settings, right? Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From sandeen at redhat.com Wed Feb 4 16:43:31 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 04 Feb 2009 10:43:31 -0600 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <4989C540.5080208@redhat.com> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <4989C194.4070509@redhat.com> <4989C540.5080208@redhat.com> Message-ID: <4989C5B3.6020302@redhat.com> Phil Knirsch wrote: > Ah yes, forgot to add those. You're refering to the hda_intel and ac97 > power_save settings, right? Yes, AC97 was already set to 5s, I just committed a change to HDA for 5s as well. But see also Bug 433495 - snd_hda_intel, doesn't recognise device which turned it off a while back; I guess we'll find out if it's fixed. :) -Eric From mjg at redhat.com Wed Feb 4 16:47:07 2009 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 4 Feb 2009 16:47:07 +0000 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <4989BCA8.8090302@redhat.com> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> Message-ID: <20090204164707.GA7209@srcf.ucam.org> On Wed, Feb 04, 2009 at 05:04:56PM +0100, Phil Knirsch wrote: > Network card speeds and harddisk spindowns is a bit tricker imo, though > we probably could enable a higher powersave mode for harddisk by default > at least in case a user wants to save power. Some of this is/will be > addressed by the tuned i'm working on which monitors the usage of > network and harddisk devices and dynamically adapts the settings to the > current use. The problem with network card retraining is that you lose link for a significant period of time, which is a pain (especially if you want to retrain upwards because you're trying to send a pile of data...). Hard drive APM has some irritating behavioural aspects - a lot of drives will unload the heads very aggressively, which can cause you to hit SMART thresholds in 6 months or so of normal use. We probably want to talk to vendors about that. Hard drive spindown is an interesting problem that I've been looking into. There's a lot of published work on adaptive algorithms for this, but the most interesting is the Helmbold one. Unfortunately, it doesn't actually seem to work - the behaviour is dependent on the number of experts in the system, when really it should be invarient of that. > Laptop mode and a higher value for dirty_writeback_centisecs, there i'm > personally torn a bit myself. I personally do use it on all my machines > (laptop and desktop), but i can understand people who are a bit paranoid > about their data integrity not wanting to have that by default. But i'd > personally be all for going that way. Anyone interested in data integrity should be calling fsync() at appropriate times. I'd be entirely in favour of bumping that up to 5 minutes or so. > In regard to relatime from what i've found so far we seem to be doing > that already by default it seems, though i'd like to have that verified. We're not right now. The in-kernel relatime code results in everything in /tmp getting deleted by tmpreaper because it has no idea that files are being read. Ingo wrote a patch to work around this - I've been trying to push that upstream, but it got about as bikeshedded as the cursor thing. I'll give that another go this cycle. We should probably merge it for F11 anyway since the code is trivial. > Then disabling CD-ROM polling is definitely something for the ServerSIG, > but on a default Desktop i think the user experience would suffer if we > would do that by default. Yeah. Best not to. > Enabling USB autosuspend looks like a good candidate for being a default > though. I've used it on quite a few Fedora 10 machines around here and > haven't experienced any problems so far, so it seems to have matured > enough by now from what i can see. Scanners and printers are the worst case for this. I think we really need to implement some kind of decent testing framework and build some whitelists. > Last but not least the dpms off, i think that should definitely be part > of the Desktop screensaver defaults, especially if you look at how much > power a modern LCD display eats when it's only dimmed down to black. Absolutely. If the default screensaver is "blank" then we should be entering DPMS very aggressively. I don't see any need for this to be configurable. I'm working on adaptive screensaver behaviour that should prevent this being something that has a noticable impact on the user. -- Matthew Garrett | mjg59 at srcf.ucam.org From billcrawford1970 at gmail.com Wed Feb 4 16:45:58 2009 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 4 Feb 2009 16:45:58 +0000 Subject: fesco meeting summary - 2009-01-30 In-Reply-To: <1233446144.8810.10.camel@rosebud> References: <20090130121722.7361f7a3@ohm.scrye.com> <1233446144.8810.10.camel@rosebud> Message-ID: <200902041645.58696.billcrawford1970@gmail.com> On Saturday 31 January 2009 23:55:44 seth vidal wrote: > On Sun, 2009-02-01 at 00:10 +0100, Kevin Kofler wrote: > > Manuel Wolfshant wrote: > > > No, as Seth has pointed out, luckily a newer rpm is not needed. The > > > issue is to have python-hashlib available for yum. Plus some > > > dependencies (urlgrabber for instance). > > > > That's not what the feature page says. It says an RPM backport would be > > too big for F9. I think you're talking about only one part of the > > feature, which is SHA256 for metadata. But the plan is to also use it > > everywhere inside RPM packages, and that needs support from RPM. Config > > files in RPM use MD5 to check for modification. Signatures are done on > > MD5 hashes. Etc. All this is to be replaced with SHA256, which needs RPM > > 4.6. > > To use preupgrade I don't think that's as strict a requirement. > > preupgrade does what it does by using yum and it's metadata to figure > out what to download. It sets up a repo for anaconda and then sets up > your system to boot into the installer. > > Now, preupgrade does do a test transaction, to look for hang ups to > doing the install. That would be the one place where it might get cranky > about the lack of sha256 support in rpm. At which point, please, please, PLEASE provide a new rpm for F8, even if only in -testing and left there ;o) (*still stuck on it here at work*) From MathStuf at gmail.com Wed Feb 4 16:49:09 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 04 Feb 2009 11:49:09 -0500 Subject: RFC: Disabling blinking cursor by default References: <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <2d319b780902030204q37effa2ahbc811dd03a21b9aa@mail.gmail.com> <49885F7C.8060608@redhat.com> <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> <4989491A.3070303@freenet.de> <1233755220.13710.13.camel@nibbler.dlib.indiana.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Wheeler wrote: > Ok, do the rectangular "wheels" do what a wheel traditionally does as > well as a circular wheel? Nope, it doesn't...so there's a technical > reason why a wheel is circular: it works. Just because something is > called a wheel doesn't make it a wheel. You just need to find some catenary-surfaced roads and square wheels are better than old circular ones. Lots of shapes go well with other road shapes. We use circular wheels because flat roads are easier to make and maintain than such roads. A little better explanation than that "it works". :) - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmJxwUACgkQiPi+MRHG3qQmvgCgkUH32r0os5kYfnQq0LvV2ZEw wAsAoJpsU+dpzh3J76Lm+lu2OSs1tRmB =E8zK -----END PGP SIGNATURE----- From drepper at redhat.com Wed Feb 4 16:50:37 2009 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 04 Feb 2009 08:50:37 -0800 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <4989C3A0.5050504@draigBrady.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> <20090204142609.GC3879@nostromo.devel.redhat.com> <4989C3A0.5050504@draigBrady.com> Message-ID: <4989C75D.90807@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 P?draig Brady wrote: > -march=i686 is better than i586, but is it the best. > I though -march=prescott was optimal for atom? The Atom core has nothing to do with the Core2 or P4 or any other core. Whoever told you Prescott is optimal doesn't know what s/he's talking about. All cores after the i586 are out-of-order cores, the Atom is an in-order. This should show you how silly that statement is. We are still waiting for Intel to disclose the details about the micro-architecture. There is no backend support in gcc yet. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmJx10ACgkQ2ijCOnn/RHQ57wCdGZTMTJWIMWPAlFW4nZKYzpP4 q0UAnRFya5yNc2IH0beiVeaAn2jDamlX =7BIR -----END PGP SIGNATURE----- From sandeen at redhat.com Wed Feb 4 16:52:40 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 04 Feb 2009 10:52:40 -0600 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <20090204164707.GA7209@srcf.ucam.org> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <20090204164707.GA7209@srcf.ucam.org> Message-ID: <4989C7D8.1070305@redhat.com> Matthew Garrett wrote: > On Wed, Feb 04, 2009 at 05:04:56PM +0100, Phil Knirsch wrote: > >> Network card speeds and harddisk spindowns is a bit tricker imo, though >> we probably could enable a higher powersave mode for harddisk by default >> at least in case a user wants to save power. Some of this is/will be >> addressed by the tuned i'm working on which monitors the usage of >> network and harddisk devices and dynamically adapts the settings to the >> current use. > > The problem with network card retraining is that you lose link for a > significant period of time, which is a pain (especially if you want to > retrain upwards because you're trying to send a pile of data...). Hard > drive APM has some irritating behavioural aspects - a lot of drives will > unload the heads very aggressively, which can cause you to hit SMART > thresholds in 6 months or so of normal use. We probably want to talk to > vendors about that. I've tried, but with no luck. Maybe I can get Ric to help. :) FWIW my apple hardware running an apple OS also far exceeds the thresholds. But yes, any sleep timeout should probably be set to something appropriate that won't overrun the rated spec over 5 years or something... > Hard drive spindown is an interesting problem that I've been looking > into. There's a lot of published work on adaptive algorithms for this, > but the most interesting is the Helmbold one. Unfortunately, it doesn't > actually seem to work - the behaviour is dependent on the number of > experts in the system, when really it should be invarient of that. > >> Laptop mode and a higher value for dirty_writeback_centisecs, there i'm >> personally torn a bit myself. I personally do use it on all my machines >> (laptop and desktop), but i can understand people who are a bit paranoid >> about their data integrity not wanting to have that by default. But i'd >> personally be all for going that way. > > Anyone interested in data integrity should be calling fsync() at > appropriate times. I'd be entirely in favour of bumping that up to 5 > minutes or so. Except that well, nobody calls fsync(). :) In fact ext3 may have scared most people away from fsync! (firefox "bug" remember...) OTOH ext4 will also likely expose folks playing fast & loose with their data, because the old data=ordered + 5s journal commit time in ext3 made the window very small. Now w/ delalloc in ext4, things may get interesting in this regard. -Eric From jkeating at redhat.com Wed Feb 4 16:51:48 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Feb 2009 08:51:48 -0800 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <4989ADEC.1020202@redhat.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <49895101.6060201@hhs.nl> <4989ADEC.1020202@redhat.com> Message-ID: <1233766308.7493.1032.camel@localhost.localdomain> On Wed, 2009-02-04 at 10:02 -0500, Tom "spot" Callaway wrote: > I don't know if the timeout is changed from 0 > if Windows is added to the grub.conf, but it probably should be It is. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Feb 4 17:02:14 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Feb 2009 09:02:14 -0800 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <200902041552.09632.billcrawford1970@gmail.com> References: <20090130053144.GA25512@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <200902041552.09632.billcrawford1970@gmail.com> Message-ID: <1233766934.7493.1044.camel@localhost.localdomain> On Wed, 2009-02-04 at 15:52 +0000, Bill Crawford wrote: > On Tuesday 03 February 2009 11:44:42 Panu Matilainen wrote: > > > Blinking things tend to draw attention, and in the case of Blinky the > > Cursor it's drawing your attention to the fact that there is nothing at > > all to attend to. It can also cause seizures for people with epilepsy or > > other disorders. > > > > Now, somebody please tell me: what is the grande justification of > > consuming a few extra wats per every computer in the world to attempt to > > draw the users attention to exactly nothing, despite being known to cause > > health issues to some people while doing so? And "it's always done that" > > is not an answer. > > Where the input location is in a large text document or piece of code I've just > opened up in a 211x72 xterm? If (for some reason) it's not in the middle of the > screen, it can be hard to spot; I'd like for it to blink a few times when I > first give the xterm focus (yes, it's more or less full screen, and yes, I have > multiple screens, so I've completely lost track of where in the window I was > when I turn back to it). In these situations for me, the blinking of the cursor was no help in finding it. Moving the cursor up or down via arrow keys was what led me to find it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jreiser at BitWagon.com Wed Feb 4 17:13:58 2009 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 04 Feb 2009 09:13:58 -0800 Subject: cmov vs cmp+jxx across x86 CPU implementations In-Reply-To: <4988A286.4020002@redhat.com> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> <4988A286.4020002@redhat.com> Message-ID: <4989CCD6.5060900@BitWagon.com> Ulrich Drepper wrote: > Dominik 'Rathann' Mierzejewski wrote: >> I'd like to see a case (not involving Pentium 4) where using cmov is slower >> than not using it. It definitely is faster for decoding H.264 in FFmpeg >> for example. > > I don't have a specific test case. But I do talk to the CPU > architectures at Intel regularly. They always say the cmov should be > avoided. Especially with the introduction of the fused micro-ops the > various cmp+jcc pairs are likely move faster. Always demand measurements. See below for seven different chips which span a decade of implementation. Cmov is faster when the jxx branch predictor would fail [Pentium4 NetBurst can be an exception], and cmov wins by a very large margin on CoreDuo and Core2Duo. > And from the code generation perspective using cmp+jcc is also more > flexible. With cmov you have to tie up two registers. This is > particularly bad with the x86 ABI. The frequent case of computing minimum or maximum requires only one register: mov m(%ebp),%eax cmp n(%ebp),%eax cmova n(%ebp),%eax > There are certainly cases where cmov can be faster. Perhaps exclusively > on older micro architectures (P4s, early Core2, maybe AMD, haven't > checked). But in general it's no win. Please give measurements. Mine show that the newer the chip, the more cmov wins when the jxx branch predictor would fail. [Core i7 untested.] ----- User CPU time in seconds (smaller is better.) "for i in 1 2 3 4 5; do time ./XXXXX; done" [dual processor often reflects alternating core assignment!] cmov2 cmp-jmp2 CPU Family 6 Model 23 (Core2 Duo E8400; 3000MHz) 2.873 6.096 2.873 6.029 2.868 6.135 2.875 6.038 2.868 6.079 Family 15 Model 107 (Athlon64x2 4800+; 2500MHz) 3.182 4.433 3.529 4.433 3.184 4.432 3.543 4.437 3.182 4.428 Family 15 Model 47 (Athlon64 3200+; 2000MHz) 3.914 5.530 3.913 5.529 3.913 5.532 3.911 5.533 3.915 5.530 Family 6 Model 14 (CoreDuo 1300 [not Core2]; 1666MHz) 4.746 10.638 4.716 10.658 4.723 10.630 4.705 10.666 4.705 10.657 Family 15 Model 2 (Pentium4 Northwood; 1600MHz) 12.081 11.129 12.089 11.137 12.081 11.133 12.081 11.225 12.081 11.165 Family 6 Model 7 (AMD Duron 1200MHz) 11.894 13.370 11.939 13.322 11.912 13.358 11.814 13.320 11.913 13.379 Family 6 Model 8 (PentiumIII Coppermine; 700MHz) 16.300 16.383 16.058 16.061 16.054 16.054 16.058 16.055 16.052 16.052 ----- ----- cmov2.S; gcc -o cmov2 -nostartfiles -nostdlib cmov2.S .balign 64 sub1: mov -4(%ebp),%eax cmp -8(%ebp),%eax cmova -8(%ebp),%eax ret _start: .globl _start nop and $~0<<6,%esp mov %esp,%ebp sub $4*4,%esp mov $0x10000000 -1,%ecx mov $1,%esi mov $2,%edi jmp top .balign 64 top: mov %esi,-4(%ebp); mov %edi,-8(%ebp); call sub1 mov %esi,-8(%ebp); mov %edi,-4(%ebp); call sub1 mov %esi,-4(%ebp); mov %edi,-8(%ebp); call sub1; call sub1 mov %esi,-8(%ebp); mov %edi,-4(%ebp); call sub1; call sub1 sub $1,%ecx; jnc top sub %ebx,%ebx mov $1,%eax int $0x80 /* EOF */ ----- ----- cmp-jmp2.S; gcc -o cmp-jmp2 -nostartfiles -nostdlib cmp-jmp2.S .balign 64 sub1: mov -4(%ebp),%eax cmp -8(%ebp),%eax; jbe 0f mov -8(%ebp),%eax 0: ret _start: .globl _start nop and $~0<<6,%esp mov %esp,%ebp sub $4*4,%esp mov $0x10000000 -1,%ecx mov $1,%esi mov $2,%edi jmp top .balign 64 top: mov %esi,-4(%ebp); mov %edi,-8(%ebp); call sub1 mov %esi,-8(%ebp); mov %edi,-4(%ebp); call sub1 mov %esi,-4(%ebp); mov %edi,-8(%ebp); call sub1; call sub1 mov %esi,-8(%ebp); mov %edi,-4(%ebp); call sub1; call sub1 sub $1,%ecx; jnc top sub %ebx,%ebx mov $1,%eax int $0x80 /* EOF */ ----- -- John Reiser, jreiser at BitWagon.com From seg at haxxed.com Wed Feb 4 17:15:47 2009 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 04 Feb 2009 11:15:47 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <1233692950.17218.107.camel@localhost.localdomain> Message-ID: <1233767747.17218.1407.camel@localhost.localdomain> On Wed, 2009-02-04 at 15:00 +0100, Kevin Kofler wrote: > Callum Lerwick wrote: > > Going -O3 rather than -O2 is going to make a bigger difference than > > anything else. If you want to improve performance, you need to run > > profiles, locate performance critical bits of code, figure out if -O3 is > > beneficial, and/or write some hand tuned assembly/intrinsic code. > > > > Not to mention, the biggest performance problem on modern processors is > > memory. Minimizing cache thrashing is way more important than what > > instructions you use. Optimize data structures before code. > > That's actually an argument for investigating -Os, not -O3. I don't think code size is what's making Firefox eat up 1gb RAM. But defaulting to -Os, and using -O2/-O3 on "hot" libraries and such might not be a bad idea. It's the most basic rule of optimization. 90% of your runtime is in %10 of the code. Optimize that %10 of the code, and forget the rest. It's wasted effort. http://en.wikipedia.org/wiki/Amdahl's_law -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From MathStuf at gmail.com Wed Feb 4 17:22:19 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 04 Feb 2009 12:22:19 -0500 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> <49886A54.6080709@herr-schmitt.de> <20090203162120.GU5690@tyan-ft48-01.lab.bos.redhat.com> <49889420.3000401@leemhuis.info> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis wrote: > mathstuf sigen Patch backported and built for rawhide. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAkmJzssACgkQiPi+MRHG3qQ4XQCXUqK9LcHzhgKhqTMIhTaJAZwp WACgrKWN4+J0nvpRvL+klLEDR0C6mhk= =EcQT -----END PGP SIGNATURE----- From jspaleta at gmail.com Wed Feb 4 17:22:37 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 08:22:37 -0900 Subject: What is the state of bulez4? In-Reply-To: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> References: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> Message-ID: <604aa7910902040922ya465beav92025299e9913b32@mail.gmail.com> 2009/2/3 Paulo Cavalcanti : > I upgraded to bluez 4.28, but not has changed. You originally mentioned F10 so I am a bit confused as that bluez version is from rawhide. Are you currently running a mix of rawhide and F10 packages? In F10...the off- the-shelf bluetooth mouse I have also works fine and its detected via the gnome ui tools. I have some custom bluetooth devices...i built myself...which I'm accessing via rfcomm with pybluez...and they work fine. hcitool and sdptool work as expected for these devices...even though I pieced them together myself. -jef From notting at redhat.com Wed Feb 4 17:55:30 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Feb 2009 12:55:30 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <1233762026.26470.93.camel@ignacio.lan> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> <20090204142609.GC3879@nostromo.devel.redhat.com> <1233762026.26470.93.camel@ignacio.lan> Message-ID: <20090204175530.GA12726@nostromo.devel.redhat.com> Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: > On Wed, 2009-02-04 at 09:26 -0500, Bill Nottingham wrote: > > Also, -march=i686 was a win over -march=i586, in general, in testing > > across Atom, Core2Duo, and a Athlon64, although not a particularly > > significant one. > > How do they compare versus -march=i386? Didn't test, on the assumption that: - keeping around support for i386/i486 is pointless - if emitting i586/i686 instructions was slower... gcc wouldn't do it Bill From notting at redhat.com Wed Feb 4 17:59:20 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Feb 2009 12:59:20 -0500 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <4989C75D.90807@redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> <20090204142609.GC3879@nostromo.devel.redhat.com> <4989C3A0.5050504@draigBrady.com> <4989C75D.90807@redhat.com> Message-ID: <20090204175920.GB12726@nostromo.devel.redhat.com> Ulrich Drepper (drepper at redhat.com) said: > The Atom core has nothing to do with the Core2 or P4 or any other core. > Whoever told you Prescott is optimal doesn't know what s/he's talking > about. All cores after the i586 are out-of-order cores, the Atom is an > in-order. This should show you how silly that statement is. > > We are still waiting for Intel to disclose the details about the > micro-architecture. There is no backend support in gcc yet. Right, the main goal of my playing was to see if telling gcc to tune for i586 (another in-order core) would help on Atom as an accident/side-effect, without detailed knowledge of atom. It does not. (In fact, on the processors I tested (Athlon64, Core2Duo, Atom), the effects of -mtune=generic vs -mtune=i686 vs -mtune=i586 were pretty much identical across all of them.) Bill From promac at gmail.com Wed Feb 4 18:00:19 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 4 Feb 2009 16:00:19 -0200 Subject: What is the state of bulez4? In-Reply-To: <604aa7910902040922ya465beav92025299e9913b32@mail.gmail.com> References: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> <604aa7910902040922ya465beav92025299e9913b32@mail.gmail.com> Message-ID: <68720af30902041000s2bc73ef8x2dd094794b7a8c21@mail.gmail.com> On Wed, Feb 4, 2009 at 3:22 PM, Jeff Spaleta wrote: > 2009/2/3 Paulo Cavalcanti : > > I upgraded to bluez 4.28, but not has changed. > > You originally mentioned F10 so I am a bit confused as that bluez > version is from rawhide. > > Are you currently running a mix of rawhide and F10 packages? > > In F10...the off- the-shelf bluetooth mouse I have also works fine and > its detected via the gnome ui tools. > > I have some custom bluetooth devices...i built myself...which I'm > accessing via rfcomm with pybluez...and they work fine. hcitool and > sdptool work as expected for these devices...even though I pieced them > together myself. > > It is F10. I only updated bluez to 4.28 to see if I could connect if I used a newer version, but nothing changed. I can connect the mouse on another computer, also running F10, but with a different bluetooth adaptor. However, booting F8, on the same computer where F10 could not connect, I have no problem connecting my mouse or any other device. The adaptor which is not working with F10 is: Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) This is what hal outputs: [cascavel:~] lshal | grep blue udi = '/org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0_bluetooth_hci_0' bluetooth_hci.address = 0 (0x0) (uint64) bluetooth_hci.originating_device = '/org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0' (string) info.capabilities = {'bluetooth_hci'} (string list) info.category = 'bluetooth_hci' (string) info.subsystem = 'bluetooth' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0_bluetooth_hci_0' (string) linux.subsystem = 'bluetooth' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/bluetooth/hci0' (string) -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Wed Feb 4 18:01:43 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 4 Feb 2009 13:01:43 -0500 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <20090204164707.GA7209@srcf.ucam.org> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <20090204164707.GA7209@srcf.ucam.org> Message-ID: <20090204180143.GC12726@nostromo.devel.redhat.com> Matthew Garrett (mjg at redhat.com) said: > > Enabling USB autosuspend looks like a good candidate for being a default > > though. I've used it on quite a few Fedora 10 machines around here and > > haven't experienced any problems so far, so it seems to have matured > > enough by now from what i can see. > > Scanners and printers are the worst case for this. I think we really > need to implement some kind of decent testing framework and build some > whitelists. If we're enabling it by default on hardware that is known OK, then I'm not sure why this should be a huge issue - the majority of machines don't run with a USB scanner/printer attached, I would imagine. Bill From walters at verbum.org Wed Feb 4 18:13:22 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 4 Feb 2009 13:13:22 -0500 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <20090204163704.GA13577@dspnet.fr.eu.org> References: <498982C3.8030704@redhat.com> <1233749819.3441.11.camel@hughsie-work.lan> <20090204133003.GB81772@dspnet.fr.eu.org> <15e53e180902040542j6dca594ao35a99e9f29351685@mail.gmail.com> <20090204163704.GA13577@dspnet.fr.eu.org> Message-ID: On Wed, Feb 4, 2009 at 11:37 AM, Olivier Galibert wrote: > On Wed, Feb 04, 2009 at 01:42:42PM +0000, Richard Hughes wrote: >> Well, sending the data does cause a wakeup, yes. The interface stops >> polling if there's no client connected. > > If I understood correctly, the problem was more about the "wideness" > of the wakeup, i.e. everything connected to the bus was waking up, > unswapping, etc rather than just what was interested by the message. Almost certainly what you're thinking of (or have heard about) is the NameOwnerChanged problem: http://bugs.freedesktop.org/show_bug.cgi?id=14183 It's definitely something we should fix (and the system was designed to support avoid wakeups), but it's certainly not as bad as every process waking up on every message; just when something joins or leaves the bus. From jspaleta at gmail.com Wed Feb 4 18:50:59 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 09:50:59 -0900 Subject: Why do we disable esd in libgnome? In-Reply-To: References: <84521355.2054171233545498586.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <91705d080902021020ieea1d64kef0ad4857b81b83b@mail.gmail.com> <1233622792.3486.1653.camel@cookie.hadess.net> <91705d080902021731r1ad57673nb293c142d27079e4@mail.gmail.com> <1233678298.3486.2596.camel@cookie.hadess.net> <91705d080902030904o445f5fc2w6acb6374212f4dca@mail.gmail.com> <1233699052.5880.5.camel@fecusia> <91705d080902031434x432309dcg30556be046e9b012@mail.gmail.com> <498906FE.9090107@redhat.com> Message-ID: <604aa7910902041050n2ac6d2cha03fea55482f523a@mail.gmail.com> On Wed, Feb 4, 2009 at 5:08 AM, Kevin Kofler wrote: > You need to get apps ported in Rawhide first, then the API can be disabled > for the next release. This really goes to the heart of the matter. When and how is it okay to introduce changes to APIs that applications depend on. I'm not saying they can't be changed, but are we making our best effort at minimizing the disruption when changes are introduced? Packaging metadata only goes so far, we don't have a facility to flag a change like this as its not exposed in a way that packaging can express as a depchain. I doubt we could have caught this with an automated tool before it landed in a repository even if was a mistake not meant to be pushed as an update. -jef From jkeating at redhat.com Wed Feb 4 18:59:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Feb 2009 10:59:16 -0800 Subject: Changing name of ISO checksum file Message-ID: <1233773956.7493.1105.camel@localhost.localdomain> As part of the Sha-256 feature[1], we need to change the SHA1SUM file that has accompanied ISOs that Fedora produces for years. This isn't the first time it has changed, it used to be MD5SUMS. This likely won't be the last time it changes, however I think it would be prudent of us to pick something this time that won't require a file name change, just a format change. A suggestion has been made already [2], but since this effects install iso creation (pungi), live media creation (livecd-creator, but manual creation of checksums), docs, release notes, announcements, etc.. I'd like to get a few opinions on the matter. Personally I'd prefer to keep any boilerplate out of the file itself, leaving it just for the checksums, and instead have the directions on how to use that included in docs/announcements/wiki/etc. My questions are, does anybody actually care how we change it, so long as its documented properly? If you do care, I would appreciate your opinions. [1] http://fedoraproject.org/wiki/Features/StrongerHashes [2] https://bugzilla.redhat.com/show_bug.cgi?id=480017 -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mw_triad at users.sourceforge.net Wed Feb 4 19:20:24 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 13:20:24 -0600 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233688212.28200.146.camel@code.and.org> References: <20090130053144.GA25512@srcf.ucam.org> <1233620984.27307.16.camel@rosebud> <1233623939.8745.343.camel@dimi.lattica.com> <20090203022059.GA2232@srcf.ucam.org> <1233628485.8745.361.camel@dimi.lattica.com> <20090203132734.GA5846@mokona.greysector.net> <1233688212.28200.146.camel@code.and.org> Message-ID: James Antill wrote: > On Tue, 2009-02-03 at 14:27 +0100, Dominik 'Rathann' Mierzejewski wrote: >> On Tuesday, 03 February 2009 at 12:44, Panu Matilainen wrote: >> [...] >>> Ignore the power savings aspect just for a second. >>> >>> My television has a power on led below the screen. It blinks when the tv >>> is starting up and when the remote control is used, both cases have a very >>> clear and sane purpose. It does NOT blink while you're watching the tv, >>> and for a good reason too. >> Bad analogy. TV is non-interactive. > > My TV is connected directly to a PS3 ... analogy win! Um... no. That makes your TV even /less/ interactive than if you were watching television (in which case you might change channels occasionally). I don't interact directly with my monitor. I turn it on and off via power strip, and my /computer/ makes it do stuff. I'm interacting with the computer. (I'm not going to get much involved in the topic at hand, as I've decided it's not important enough to waste my time on. I will say, however, that I turned on blinking caret in Konsole. I prefer my caret to blink, as I find it easier to tell what has focus that way.) (Oh, and I do prefer "caret"; not because it isn't a text cursor, but simply because it's less ambiguous. Is "cursor" the text cursor or the mouse cursor? ;-) ) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From ml at bendler-net.de Wed Feb 4 19:28:34 2009 From: ml at bendler-net.de (Thomas Bendler) Date: Wed, 4 Feb 2009 20:28:34 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> Message-ID: On Wed, Feb 4, 2009 at 8:52 AM, Jeff Spaleta wrot > [...] > What defines a distribution? For fedora right now doesn't that pretty > much comes down to checking the fedora-release package version in the > installed rpmdb? > [...] Why do you need the rpmdb to figure out what distribution is installed? It's much easier to inspect the filesystem (which shouldn't be a big deal) to figure out the distribution. If this fail it's quite easy to add an entry with unknown Linux installation or something like that. We aren't going to be doing that sort of thing for slackware-esque or > debian-esque or foresight-esque or gentoo-esque distros. We may be > able to detect opensuse or other rpm based systems that > way...maybe...if the rpm databases are compatible with the rpm we > have. This is simply ignorant. Others can do this as well and they are doing it. Ignoring this lead to bad rating for Fedora in some areas in test like the one in c't (don't forget, this is the leading it magazine in germany). Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Wed Feb 4 19:35:56 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 10:35:56 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> Message-ID: <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> 2009/2/4 Thomas Bendler : > This is simply ignorant. I make absolutely no claim that I am anything more than supremely ignorant. This is why i am asking questions. I don't know how to do it. I make no claim as to how to do it. I am saying that it is my understanding that right now our installer tastes for existing Fedora installs by looking for at the on system rpmdb. If I'm wrong about that, please tell me how I'm wrong. Sadly you didn't provide anything close to an idea that was implementable. "Look in the filesystem", isn't concrete enough. What in the filesystem is hallmark Mepis for example or hallmark Foresight? -jef From choeger at cs.tu-berlin.de Wed Feb 4 19:59:35 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 04 Feb 2009 20:59:35 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> Message-ID: <1233777575.27515.28.camel@choeger5.umpa.netz> The solution is obvious: put a .metadata in the bootable partition and fill it with stuff like: OS_NAME: Fedora 11 I would call that a trivial task but someone with some "standing" in the community should ask other distributions to do the same in the same format (and encoding and other technical stuff that matters) in their own install process. Then a) write a patch for grub to handle that, or (if grub is not able to do so, what would be weird) b) write a small tool that detects bootable partitions and generates boot entries from that metadata files (and "unknown" if it's missing). \me just wonders why nobody already did that stuff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Wed Feb 4 20:05:37 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 11:05:37 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233777575.27515.28.camel@choeger5.umpa.netz> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> <1233777575.27515.28.camel@choeger5.umpa.netz> Message-ID: <604aa7910902041205i131be4fk7d37cee85d7ef3bb@mail.gmail.com> 2009/2/4 Christoph H?ger : > The solution is obvious: put a .metadata in the bootable partition and > fill it with stuff like: > > OS_NAME: Fedora 11 > > I would call that a trivial task but someone with some "standing" in the > community should ask other distributions to do the same in the same > format (and encoding and other technical stuff that matters) in their > own install process. there is a cross distribution list on freedesktop.org for exactly this sort of interaction. -jef From bpepple at fedoraproject.org Wed Feb 4 20:14:17 2009 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Feb 2009 15:14:17 -0500 Subject: Plan for tomorrow's (20090205) Special FESCo meeting Message-ID: <1233778457.20269.22.camel@localhost.localdomain> Hi all, FESCo will have a special meeting tomorrow at 17:00 UTC (12:00 EST) in #fedora-meeting, to catch-up on some of the topics we were unable to get to at last week's meeting. Please find below the list of topics that we are hoping to cover: * DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS * OpenChange - https://fedoraproject.org/wiki/Features/OpenChange * Firefox 3.1 - https://fedoraproject.org/wiki/Features/Firefox_3.1 * Repackaging of Fedora Fonts - https://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts * Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport * Package Renaming Guidelines * Update description guidelines - https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines * provenpackager proposal - https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal Note: We will still have our normal meeting on Friday. Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From konrad at tylerc.org Wed Feb 4 20:20:53 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Wed, 4 Feb 2009 12:20:53 -0800 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: <1233767747.17218.1407.camel@localhost.localdomain> References: <20090130203505.GA24850@nostromo.devel.redhat.com> <1233767747.17218.1407.camel@localhost.localdomain> Message-ID: <200902041220.53539.konrad@tylerc.org> On Wednesday 04 February 2009 09:15:47 am Callum Lerwick wrote: > On Wed, 2009-02-04 at 15:00 +0100, Kevin Kofler wrote: > > Callum Lerwick wrote: > > > Going -O3 rather than -O2 is going to make a bigger difference than > > > anything else. If you want to improve performance, you need to run > > > profiles, locate performance critical bits of code, figure out if -O3 > > > is beneficial, and/or write some hand tuned assembly/intrinsic code. > > > > > > Not to mention, the biggest performance problem on modern processors is > > > memory. Minimizing cache thrashing is way more important than what > > > instructions you use. Optimize data structures before code. > > > > That's actually an argument for investigating -Os, not -O3. > > I don't think code size is what's making Firefox eat up 1gb RAM. Nor is Firefox's 1GB of ram causing cache thrashing... -- Conrad Meyer From ml at bendler-net.de Wed Feb 4 20:26:13 2009 From: ml at bendler-net.de (Thomas Bendler) Date: Wed, 4 Feb 2009 21:26:13 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> Message-ID: On Wed, Feb 4, 2009 at 8:35 PM, Jeff Spaleta wrote: > 2009/2/4 Thomas Bendler : > > This is simply ignorant. > > I make absolutely no claim that I am anything more than supremely > ignorant. This is why i am asking questions. I don't know how to do > it. I make no claim as to how to do it. I am saying that it is my > understanding that right now our installer tastes for existing Fedora > installs by looking for at the on system rpmdb. If I'm wrong about > that, please tell me how I'm wrong. The ignorant statement was a reply to your comment above that statement (which you delete in this reply) where you stated that there won't be a rpmdb like thing for other distributions. Of course it make no sense to use rpmdb for the detection of other distributions, not all distries use RPM, this is the first blocking issue. Next thing is the RPM version thing which could also block a detection. That is why I said use the filesystem. Sadly you didn't provide anything close to an idea that was > implementable. "Look in the filesystem", isn't concrete enough. What > in the filesystem is hallmark Mepis for example or hallmark Foresight? Should I now explain for all hundred + distribution where a special file exist ... only in this distribution and only in this version which could be used for detection? You're kidding, aren't you? There are several files like /etc/redhat-release, /etc/debian_version, /etc/lsb-release, ... which could be used to determin the distribution. If not known or the installer is unsure, simply add an unkown OS. But it is really not rocket sience to figure out a distribution by only checking some files in the filesystem. At least that should be sufficent to detect the major distributions by name and some other by simply an unknown entry in GRUB. Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen at herr-schmitt.de Wed Feb 4 20:33:36 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 04 Feb 2009 21:33:36 +0100 Subject: Plan for tomorrow's (20090205) Special FESCo meeting In-Reply-To: <1233778457.20269.22.camel@localhost.localdomain> References: <1233778457.20269.22.camel@localhost.localdomain> Message-ID: <4989FBA0.9090009@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Pepple schrieb: > Hi all, > > * provenpackager proposal - > https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal > I have got a short view on this proposal and want to talk about my mind: In the first sentence I could read, that the amount of 5 pakcages was a requirement to get provenpackager state. In fact the only thing on which I could remember is, that you have to packaged a cretain amount of packages to get provenpackager state during the seeding procedure. The current state from my view is, that we have none guidelines which helps you to decide if you should accept a sponsor request or net. On the other hand, after reading the proposal it's seem, that you need a special technical infrastructure to build up the descriped procedure, so this proposal is unusable for a short-term solution how we want to handle sponsoring request for the provenpackager group. On the other hand, if we take the dicision in the hand of FESCo, poeple may think, that there are not diffent requirement to become a provenpackager or a sponsor. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmJ+5YACgkQT2AHK6txfgyp6gCeNZ/Sx0ouq0+Y6XIBWdmftmlX 34cAnR+VISBFdKcG+iIekV+2y6UC0ghx =+ElS -----END PGP SIGNATURE----- From jspaleta at gmail.com Wed Feb 4 20:34:26 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 11:34:26 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> Message-ID: <604aa7910902041234k76204099m9cbde73836ce5dbc@mail.gmail.com> 2009/2/4 Thomas Bendler : > At least that should be sufficent to detect the major distributions by name and > some other by simply an unknown entry in GRUB. Define major distribution Is Xandros and Linpus major distributions to you... they are the leading pre-installed distributions of linux by a wide wide margin if you believe the press reports. How do we identify those accurately? -jef From Victor.Vasilyev at Sun.COM Wed Feb 4 20:37:57 2009 From: Victor.Vasilyev at Sun.COM (Victor Vasilyev) Date: Wed, 04 Feb 2009 23:37:57 +0300 Subject: Plan for tomorrow's (20090205) Special FESCo meeting In-Reply-To: <1233778457.20269.22.camel@localhost.localdomain> References: <1233778457.20269.22.camel@localhost.localdomain> Message-ID: <4989FCA5.6040300@sun.com> Hi Brian, Brian Pepple wrote: > Hi all, > > FESCo will have a special meeting tomorrow at 17:00 > UTC (12:00 EST) in #fedora-meeting, to catch-up on some of the topics we > were unable to get to at last week's meeting. Please find below the > list of topics that we are hoping to cover: > > * DebugInfoFS - > https://fedoraproject.org/wiki/Features/DebuginfoFS > * OpenChange - https://fedoraproject.org/wiki/Features/OpenChange > * Firefox 3.1 - > https://fedoraproject.org/wiki/Features/Firefox_3.1 > * Repackaging of Fedora Fonts - > https://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts > * Architecture Support - > https://fedoraproject.org/wiki/Features/ArchitectureSupport > * Package Renaming Guidelines > * Update description guidelines - > https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines > * provenpackager proposal - > https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal > > Note: We will still have our normal meeting on Friday. > > Thanks, > /B > Any chance for getting this into the meeting? http://fedoraproject.org/wiki/Features/NetBeans_6.5 Category: FeatureReadyForFesco Note, percentage of completion: 100% Cheers, Victor Vasilyev From mw_triad at users.sourceforge.net Wed Feb 4 20:42:52 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 14:42:52 -0600 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130212955.GE741830@hiwaay.net> Message-ID: Kevin Kofler wrote: > I wrote: >> But our live images are already heavily size-constrained. There's >> definitely no room for multiple kernels on the KDE live image, and I don't >> think the GNOME image has any room left either. > > And I'll add to this that I think the real solution is to make the x86_64 > image the default download and the 32-bit image a separate link (maybe > marketed primarily for netbooks). Most computers these days are 64-bit > capable. (Almost all the new non-netbook computers are.) Most *new* (non-netbook) hardware, sure. What about existing hardware? Both my home machines are still 32-bit (one is not even 1 GHz CPU!). > Running 32-bit > userspace on a 64-bit kernel is just a kludge, we should be promoting pure > 64-bit instead. Didn't we just have the "32-bit is actually faster" discussion? Okay, not true for x86, but the above statement still isn't entirely accurate. That said, I do agree that running i686 on an x86_64 is a bit silly :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From chris at tylers.info Wed Feb 4 20:47:00 2009 From: chris at tylers.info (Chris Tyler) Date: Wed, 04 Feb 2009 15:47:00 -0500 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <1233777575.27515.28.camel@choeger5.umpa.netz> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> <1233777575.27515.28.camel@choeger5.umpa.netz> Message-ID: <1233780420.7786.1.camel@localhost6.localdomain6> On Wed, 2009-02-04 at 20:59 +0100, Christoph H?ger wrote: > The solution is obvious: put a .metadata in the bootable partition and > fill it with stuff like: > > OS_NAME: Fedora 11 Sounds exactly like /etc/system-release (except that you'd have to chase down the location of /etc). -Chris From limb at jcomserv.net Wed Feb 4 21:13:18 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 4 Feb 2009 15:13:18 -0600 (CST) Subject: Bodhi/bugzilla Message-ID: <37950adcd1c18722c948e1c88d388892.squirrel@mail.jcomserv.net> My last few Bodhi updates have had BZ numbers in them, and I've not seen anything in the BZs. I've updated those manually so the reporters are aware, but I was wondering if there was an intentional change I missed, or should I file a trac bug for Infrastructure? -J -- in your fear, speak only peace in your fear, seek only love -d. bowie From robert at fedoraproject.org Wed Feb 4 21:08:20 2009 From: robert at fedoraproject.org (Robert Scheck) Date: Wed, 4 Feb 2009 22:08:20 +0100 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <20090204210820.GA18785@hurricane.linuxnetz.de> On Tue, 03 Feb 2009, Jakub Jelinek wrote: > Here are the most common causes of the regressions (fails to build > with gcc-4.4.0-0.9, succeeds with gcc-4.3.2-7): I'm pleased to see, that none of my packages really fails with 4.4 :) > - 167 failures > packages that failed to build both with gcc 4.3 and 4.4 > http://sunsite.mff.cuni.cz/rawhide20090126-gcc44/fails-even-with-43/ Thanks for pointing out a build issue at my popt package. Fixed, thus it now should work with gcc 4.4 as well - as there never was a C issue, but only one with doxygen/libpng. Greetings, Robert From orion at cora.nwra.com Wed Feb 4 21:35:48 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 04 Feb 2009 14:35:48 -0700 Subject: Results of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9 In-Reply-To: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> References: <20090203154836.GT5690@tyan-ft48-01.lab.bos.redhat.com> Message-ID: <498A0A34.3080703@cora.nwra.com> I'm seeing a new failure on ppc/ppc64 with gcc 4.4 and plplot. Build link is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1104923 This same package builds fine with 4.3. F77 tests fail with: fci = 0xbf947ae1, font name pointer = NULL *** PLPLOT ERROR, ABORTING OPERATION *** proc_str: FCI inconsistent with Type1Lookup; internal PLplot error, aborting operation Don't really have an easy way to debug. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From nicolas.mailhot at laposte.net Wed Feb 4 21:48:57 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Feb 2009 22:48:57 +0100 Subject: Too many unowned directories In-Reply-To: <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> Message-ID: <1233784137.18874.14.camel@arekh.okg> Just to be clear: the directory ownership page says something like "if you have multiple packages that use the same directory and do not depend on a common package that owns it they can all own this directory in parallel". But with fonts we have cases where 1. the common package exists for other reasons, or 2 it's only there to own the common directory. In case 2. the guidelines clearly allow dropping common and using multiple ownership. My problem is case 1.: is it ok for each subpackage to own the directory it installs fonts to, even though it depends on a common package that already owns it for other reasons (for example, to put core fonts indexes in it)? Because making the font subpackage macro auto-own the font dir in all cases is trivial, would simplify the templates and avoid packaging errors, but detecting the presence of a common subpackage to avoid the auto-owning in that case is *not* trivial at all. NB: in all this discussion the "common" subpackage is created from the same srpm and never shared with subpackages from another srpm -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From opensource at till.name Wed Feb 4 21:58:36 2009 From: opensource at till.name (Till Maas) Date: Wed, 04 Feb 2009 22:58:36 +0100 Subject: Changing name of ISO checksum file In-Reply-To: <1233773956.7493.1105.camel@localhost.localdomain> References: <1233773956.7493.1105.camel@localhost.localdomain> Message-ID: <200902042258.48957.opensource@till.name> On Wed February 4 2009, Jesse Keating wrote: > As part of the Sha-256 feature[1], we need to change the SHA1SUM file > that has accompanied ISOs that Fedora produces for years. This isn't > My questions are, does anybody actually care how we change it, so long > as its documented properly? I would appreciate the new name to contain information about which files are hashed in there, e.g. F11-i386.sha256 or F11-i386-Live.sha256. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From wcohen at redhat.com Wed Feb 4 22:04:05 2009 From: wcohen at redhat.com (William Cohen) Date: Wed, 04 Feb 2009 17:04:05 -0500 Subject: Features/ArchitectureSupport - changing what we build for In-Reply-To: References: <20090130203505.GA24850@nostromo.devel.redhat.com> <20090130230859.GD4298@mokona.greysector.net> <200901301525.43846.konrad@tylerc.org> <20090202174418.GD20094@nostromo.devel.redhat.com> <20090202184237.GB21251@nostromo.devel.redhat.com> <8278b1b0902021806v54bc738eg65a0d49266ac6dfd@mail.gmail.com> <1233692950.17218.107.camel@localhost.localdomain> Message-ID: <498A10D5.6010604@redhat.com> Kevin Kofler wrote: > Callum Lerwick wrote: >> Going -O3 rather than -O2 is going to make a bigger difference than >> anything else. If you want to improve performance, you need to run >> profiles, locate performance critical bits of code, figure out if -O3 is >> beneficial, and/or write some hand tuned assembly/intrinsic code. >> >> Not to mention, the biggest performance problem on modern processors is >> memory. Minimizing cache thrashing is way more important than what >> instructions you use. Optimize data structures before code. > > That's actually an argument for investigating -Os, not -O3. > > Kevin Kofler > In 2004 there were some experiments performed by some NCSU students on the effect of -Os on code size and performance: people.redhat.com/wcohen/ncsu2004/Space%20Optimizations.pdf There was some minor reductions in cache misses, major page faults, and startup times for the mozilla application. -Will From mw_triad at users.sourceforge.net Wed Feb 4 22:14:07 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 16:14:07 -0600 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <1233495778.13582.19.camel@arekh.okg> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> Message-ID: Nicolas Mailhot wrote: > The code vs content old debate is totally misguided IMHO. We want more > free code. We want more free content. We want more free classification>. We want to train our users to look for free > first, and not complain about our lack of support for something else. > > And the only way to get more free (short of buying it to > re-license it) is to ship it to reward people who create it with some > public exposure. I would welcome a collection of music in the > appropriate license and the appropriate formats?. I wouldn't. IMO Fedora is about software. Free /content/ should be hosted on repositories that are set up for that purpose, similar to wikimedia commons, in a way that makes it accessible to /all/ distros. If Fedora wants to ship tools to integrate such repositories more closely with Fedora, or to contribute to building such a repository, I would support that effort, but I don't think it should be done in the same repository as our software. At the very least, yum/PK is not the right tool for browsing such a repository. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From jkeating at redhat.com Wed Feb 4 22:25:26 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Feb 2009 14:25:26 -0800 Subject: Changing name of ISO checksum file In-Reply-To: <200902042258.48957.opensource@till.name> References: <1233773956.7493.1105.camel@localhost.localdomain> <200902042258.48957.opensource@till.name> Message-ID: <1233786326.7493.1118.camel@localhost.localdomain> On Wed, 2009-02-04 at 22:58 +0100, Till Maas wrote: > On Wed February 4 2009, Jesse Keating wrote: > > As part of the Sha-256 feature[1], we need to change the SHA1SUM file > > that has accompanied ISOs that Fedora produces for years. This isn't > > > My questions are, does anybody actually care how we change it, so long > > as its documented properly? > > I would appreciate the new name to contain information about which files are > hashed in there, e.g. F11-i386.sha256 or F11-i386-Live.sha256. > > Regards, > Till It isn't enough that each directory of such isos has the hash file? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Feb 4 22:34:48 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Feb 2009 23:34:48 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> Message-ID: <1233786888.19376.5.camel@arekh.okg> Le mercredi 04 f?vrier 2009 ? 16:14 -0600, Matthew Woehlke a ?crit : > I wouldn't. IMO Fedora is about software. Free /content/ should be > hosted on repositories that are set up for that purpose, similar to > wikimedia commons, in a way that makes it accessible to /all/ distros. While I don't deny some validity to this POW, it's IMHO as obsolete as the majors considering they're in the music business and they should not have to worry about software or this internet thing. Digital creations in any form are all increasingly intertwined, and engaging one without the others is doomed to fail. As all the mp3 debacle eloquently demonstrates. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mw_triad at users.sourceforge.net Wed Feb 4 22:45:19 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 16:45:19 -0600 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <1233786888.19376.5.camel@arekh.okg> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> <1233786888.19376.5.camel@arekh.okg> Message-ID: Nicolas Mailhot wrote: > Le mercredi 04 f?vrier 2009 ? 16:14 -0600, Matthew Woehlke a ?crit : >> I wouldn't. IMO Fedora is about software. Free /content/ should be >> hosted on repositories that are set up for that purpose, similar to >> wikimedia commons, in a way that makes it accessible to /all/ distros. > > While I don't deny some validity to this POW, it's IMHO as obsolete as > the majors considering they're in the music business and they should not > have to worry about software or this internet thing. > > Digital creations in any form are all increasingly intertwined, and > engaging one without the others is doomed to fail. As all the mp3 > debacle eloquently demonstrates. I didn't say we shouldn't "engage" improved visibility of Free content, I said we should do it in a way that makes sense. That means sensible tools to browse content (pk does NOT cut it for visual media, even worse with yum). And I fail to see what benefit it is to throw a music collection into the same repository as compiled glibc. I'd rather see even fonts in a separate repo, as text descriptions are not very meaningful to me deciding if I want to install a particular font or not. (Plus it would make it easier to find Free fonts...) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From chitlesh.goorah at gmail.com Wed Feb 4 22:44:41 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Wed, 4 Feb 2009 23:44:41 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> Message-ID: <50baabb30902041444k562589ffgf95769dac5ea1b9@mail.gmail.com> On Sun, Feb 1, 2009 at 12:06 AM, Kevin Kofler wrote: > > That would be advertising the proprietary application. > I'm sure you are not referring to OVM, but to fedora announcement list ! https://www.redhat.com/archives/fedora-announce-list/2009-January/msg00019.html With OVM's inclusion I'm hoping - users to develop their home grown methodologies (in asic design, users don't only use software, but tweak software for maximum performance in boolean optimization, mixed mode simulations,....) - EDA development to develop tools around OVM. regards, Chitlesh From a.badger at gmail.com Wed Feb 4 22:41:14 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Feb 2009 14:41:14 -0800 Subject: Plan for tomorrow's (20090205) Special FESCo meeting In-Reply-To: <1233778457.20269.22.camel@localhost.localdomain> References: <1233778457.20269.22.camel@localhost.localdomain> Message-ID: <498A198A.3070803@gmail.com> Brian Pepple wrote: > * provenpackager proposal - > https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal > I've added things I don't like about this proposal to the Talk page[1]_ as requested on the Proposal page. .. _[1]: https://fedoraproject.org/wiki/Talk:PackageMaintainers/ProvenpackagerProposal -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Wed Feb 4 22:57:59 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Feb 2009 23:57:59 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> <1233786888.19376.5.camel@arekh.okg> Message-ID: <1233788279.20499.8.camel@arekh.okg> Le mercredi 04 f?vrier 2009 ? 16:45 -0600, Matthew Woehlke a ?crit : > Nicolas Mailhot wrote: > I didn't say we shouldn't "engage" improved visibility of Free content, > I said we should do it in a way that makes sense. That means sensible > tools to browse content (pk does NOT cut it for visual media, even worse > with yum). And I fail to see what benefit it is to throw a music > collection into the same repository as compiled glibc. > > I'd rather see even fonts in a separate repo, as text descriptions are > not very meaningful to me deciding if I want to install a particular > font or not. (Plus it would make it easier to find Free fonts...) Sure, take the time to make the experiment, remove fonts, remove music, remove themes, remove images, and see how much stuff is still working or useful in your nice "software only" repository. Most people understand that part. What they usually don't is that adding more "non-software" elements (in addition to those we already have to because a lot of things would bloody not work without them), would have additionnal synergistic effects for everyone involved. PS Fonts can be compiled and include an instruction langage. Which is complex enough some of its bits got patented. Looks like software to me. PPS Text without screenshots is not too useful to describe pure software package for the average user either -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From chitlesh.goorah at gmail.com Wed Feb 4 23:03:11 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Thu, 5 Feb 2009 00:03:11 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> Message-ID: <50baabb30902041503h78b152c2xecdb3877caa73643@mail.gmail.com> On Wed, Feb 4, 2009 at 11:14 PM, Matthew Woehlke wrote: > If Fedora wants to ship > tools to integrate such repositories more closely with Fedora, or to > contribute to building such a repository, I would support that effort, but I > don't think it should be done in the same repository as our software. The question is who defines your "our software" ? I consider OVM as an expensive Intellectual Property recently freed both in terms of cost and license. It is a software that can help the designer spending 11983? (which I spent out of my pocket) when his/her chips failed testing. Your definition of "our software" excluding OVM doesn't give the user the assurance in his/her design's signoff and neither in knowledge sharing that can also be used in both design and design tools. If your "our software" undergoes an segmentation fault, you don't lose money spent in hardware, but is the EDA tools give wrong results, you will lose that money. I don't think one can define "our software". Kind regards, Chitlesh From mw_triad at users.sourceforge.net Wed Feb 4 23:11:02 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 17:11:02 -0600 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: Kevin Kofler wrote: > That wiki page is hardly "what Fedora is about" and in fact I believe it is > counterproductive. We should instead point people to Gnash and/or Swfdec. Indeed. +1 for gnash ;-). > Or just not recommend consuming Flash content at all, just like we do for > DVDs and MP3s. Just what are you supposed to use instead of DVD's? Do you really expect all Fedora users (in the U.S. anyway) to boycott watching movies on their computers? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From rvinyard at cs.nmsu.edu Wed Feb 4 23:15:09 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Wed, 4 Feb 2009 16:15:09 -0700 (MST) Subject: Question on Directory Ownership Message-ID: <42996.155.148.81.31.1233789309.squirrel@intranet.cs.nmsu.edu> I've been looking at the following example, but something is still unclear: http://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership Let's say we have a single package Foo-Animal with Emu and Llama subpackages (you know those snooty llama people... can't have anything emu related on their systems). If we have a files section for package Foo-Animal like this: %files Emu %defattr(-,root,root,-) %{_datadir}/Foo/Animal/Emu %files Llama %defattr(-,root,root,-) %{_datadir}/Foo/Animal/Llama and, as in the example on the wiki neither Foo-Animal-Emu or Foo-Animal-Llama has a dependency on the other, what does the files section for each look like? Wouldn't this cause duplication of files? %files Emu %defattr(-,root,root,-) %{_datadir}/Foo/Animal/Emu %{_datadir}/Foo/ %files Llama %defattr(-,root,root,-) %{_datadir}/Foo/Animal/Llama %{_datadir}/Foo/ From P at draigBrady.com Wed Feb 4 22:47:57 2009 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Wed, 4 Feb 2009 22:47:57 +0000 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <4989C75D.90807@redhat.com> References: <49887ADF.9090606@redhat.com> <20090203211642.GA25276@ee.oulu.fi> <4988D70A.3090303@redhat.com> <20090204142609.GC3879@nostromo.devel.redhat.com> <4989C3A0.5050504@draigBrady.com> <4989C75D.90807@redhat.com> Message-ID: <498A1B1D.3080203@draigBrady.com> Ulrich Drepper wrote: > P?draig Brady wrote: >> -march=i686 is better than i586, but is it the best. >> I though -march=prescott was optimal for atom? > > The Atom core has nothing to do with the Core2 or P4 or any other core. > Whoever told you Prescott is optimal doesn't know what s/he's talking > about. All cores after the i586 are out-of-order cores, the Atom is an > in-order. This should show you how silly that statement is. > > We are still waiting for Intel to disclose the details about the > micro-architecture. There is no backend support in gcc yet. I had a quick look and the consensus at the moment for atom optimized CLFAGS is -march=prescott, but that's really due to that being the most appropriate flag for commonly available gcc at the time people were looking at it: http://forums.gentoo.org/viewtopic-p-5127497.html Intel have said that the Atom is merom (core2) ISA compliant, and also that it's an in-order core. So perhaps the optimum flags at present are: -march=core2 -mtune=i586 ? cheers, P?draig. From cra at WPI.EDU Wed Feb 4 23:17:13 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 4 Feb 2009 18:17:13 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <5256d0b0902032231rf001a3aw474cf3161486850c@mail.gmail.com> References: <1233676210.3407.26.camel@localhost.localdomain> <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <5256d0b0902032231rf001a3aw474cf3161486850c@mail.gmail.com> Message-ID: <20090204231712.GO3963@angus.ind.WPI.EDU> On Wed, Feb 04, 2009 at 06:31:57AM +0000, Peter Robinson wrote: > > right now on my F10 system > > > > xterm defaults to no blink > > konsole defaults to no blink > > aterm defaults to no blink > > Eterm defaults to no blink > > rxvt defaults to no blink > > I think these were only turned off as part of the powertop craze of a > year or two ago. XTerm's cursor doesn't blink on my FC5 box. From cra at WPI.EDU Wed Feb 4 23:19:07 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 4 Feb 2009 18:19:07 -0500 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <1233755220.13710.13.camel@nibbler.dlib.indiana.edu> References: <498868EB.8080209@redhat.com> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <4988E10C.20002@freenet.de> <1233713202.11436.5.camel@localhost.localdomain> <4989491A.3070303@freenet.de> <1233755220.13710.13.camel@nibbler.dlib.indiana.edu> Message-ID: <20090204231907.GP3963@angus.ind.WPI.EDU> On Wed, Feb 04, 2009 at 08:47:00AM -0500, Brian Wheeler wrote: > > * When using real terminals (or remote logins or runlevel 3), they often > > are the only indication of a system being alive or not. > > As I posted elsewhere in this thread, my VT420 which is a real terminal > by any definition, doesn't blink the cursor. Whether or not that was > its default or not I can't say since I've had it for years and I got it > second hand. Heh. I have a few brand-new-still-in-box VT520's. Should I crack one open to check the whether the cursor blinks by default? From jcm at redhat.com Wed Feb 4 23:19:18 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 04 Feb 2009 18:19:18 -0500 Subject: module-init-tools v3.6 released In-Reply-To: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> Message-ID: <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: > I'm considering pushing an update to F-9 since v3.5+ is so much faster > than previous releases - and it impacts boot time, but I have to admit > that I was more concerned about F10 and rawhide until now. Oh, there's a slight issue with the handling of modules.order still for the binary tries in newer module-init-tools. This might manifest in a switch of e.g. module used in initrd for storage devices with multiple modaliases. Should be fixed in a couple days...probably nobody has noticed yet. Jon. From mw_triad at users.sourceforge.net Wed Feb 4 23:28:30 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 17:28:30 -0600 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <1233788279.20499.8.camel@arekh.okg> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> <1233786888.19376.5.camel@arekh.okg> <1233788279.20499.8.camel@arekh.okg> Message-ID: Nicolas Mailhot wrote: > Sure, take the time to make the experiment, remove fonts, remove music, > remove themes, remove images, and see how much stuff is still working or > useful in your nice "software only" repository. First off, I'm not talking about "core material", I'm talking about things that merely enhance, much of which is currently /not/ in Fedora repos. Second, we were talking about adding content that isn't used. Third, what's to say we can't write tools to have dependencies on other types of repositories? The main point is that it doesn't make sense to use the exact same repo and infrastructure for disparate content types. I'd rather not see Fedora becoming a multimedia repository, not only because I don't think it's an appropriate goal, but because if we're doing this in Fedora and not in a more general sense, we're keeping non-Fedora users out. "I find that kde-look.org enhances kdebase. We should package kde-look.org (at least, all appropriately licensed content) and add it to Fedora's repos." Do you seriously agree with the above? > What they usually don't is that adding more "non-software" elements (in > addition to those we already have to because a lot of things would > bloody not work without them), would have additionnal synergistic > effects for everyone involved. Again, I'm not opposed to making Free content more accessible from Fedora. I'm opposed to doing it via inappropriate infrastructure, and I'm opposed to doing it in a Fedora-centric manner. > PS Fonts can be compiled and include an instruction langage. Which is > complex enough some of its bits got patented. Looks like software to me. Are they architecture specific? Does "A great looking gothic font" give you any useful information if this is that perfect font you need for your presentation/art project? Having fonts managed by yum is IMO useless except when you already know you want a particular font (i.e. "by name"), or for the system default fonts that are expected to always be installed. > PPS Text without screenshots is not too useful to describe pure software > package for the average user either How do you take a screenshot of a recording (audio only, mind) of the Orlando Pops performance of Beethoven's Sixth Symphony? Of what relevance is a sound clip to deciding between five options when I'm searching for a picture of clover? Different media types have different needs as far as creating an effective repository... and the UNIX philosophy is to do one thing, and do it well. Not try to create a Great Mishmash of Everything repo. (Not to mention that you're suggesting to push huge quantities of data out to mirrors... where by "huge" I mean many, many times the current repo size.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From jspaleta at gmail.com Wed Feb 4 23:35:05 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 14:35:05 -0900 Subject: RFC: Disabling blinking cursor by default In-Reply-To: <20090204231712.GO3963@angus.ind.WPI.EDU> References: <1233676210.3407.26.camel@localhost.localdomain> <20090203162412.GB6153@mother.fordon.pl.eu.org> <1233691661.22804.14.camel@arekh.okg> <20090203200917.GA3996@nostromo.devel.redhat.com> <1233694428.8745.422.camel@dimi.lattica.com> <1233697189.3238.17.camel@rosebud> <1233699763.8745.425.camel@dimi.lattica.com> <604aa7910902031437w3af2e0f6maf7817a4cea8fb7@mail.gmail.com> <5256d0b0902032231rf001a3aw474cf3161486850c@mail.gmail.com> <20090204231712.GO3963@angus.ind.WPI.EDU> Message-ID: <604aa7910902041535i3ad96a56qb6e1e05f77f9abf8@mail.gmail.com> On Wed, Feb 4, 2009 at 2:17 PM, Chuck Anderson wrote: > XTerm's cursor doesn't blink on my FC5 box. Tradition! -jef"hums the musical score to Fiddler on the Roof to himself"spaleta From jonstanley at gmail.com Wed Feb 4 23:35:36 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 4 Feb 2009 18:35:36 -0500 Subject: Plan for tomorrow's (20090205) Special FESCo meeting In-Reply-To: <4989FCA5.6040300@sun.com> References: <1233778457.20269.22.camel@localhost.localdomain> <4989FCA5.6040300@sun.com> Message-ID: On Wed, Feb 4, 2009 at 3:37 PM, Victor Vasilyev wrote: > Any chance for getting this into the meeting? > http://fedoraproject.org/wiki/Features/NetBeans_6.5 Category: > FeatureReadyForFesco > Note, percentage of completion: 100% This special meeting is simply to clear the backlog from a meeting that would have gone all day last week :) - I don't remember that one from last week. From jonstanley at gmail.com Wed Feb 4 23:37:27 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 4 Feb 2009 18:37:27 -0500 Subject: fesco meeting summary - 2009-01-30 In-Reply-To: <200902041645.58696.billcrawford1970@gmail.com> References: <20090130121722.7361f7a3@ohm.scrye.com> <1233446144.8810.10.camel@rosebud> <200902041645.58696.billcrawford1970@gmail.com> Message-ID: On Wed, Feb 4, 2009 at 11:45 AM, Bill Crawford wrote: > At which point, please, please, PLEASE provide a new rpm for F8, even if only > in -testing and left there ;o) Fedora 8 builds are no longer allowed to be built in koji, sorry. From tcallawa at redhat.com Wed Feb 4 23:39:55 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Feb 2009 18:39:55 -0500 Subject: Question on Directory Ownership In-Reply-To: <42996.155.148.81.31.1233789309.squirrel@intranet.cs.nmsu.edu> References: <42996.155.148.81.31.1233789309.squirrel@intranet.cs.nmsu.edu> Message-ID: <498A274B.3050003@redhat.com> On 2009-02-04 at 18:15:09 -0500, "Rick L. Vinyard, Jr." wrote: > Wouldn't this cause duplication of files? > > %files Emu > %defattr(-,root,root,-) > %{_datadir}/Foo/Animal/Emu > %{_datadir}/Foo/ > > %files Llama > %defattr(-,root,root,-) > %{_datadir}/Foo/Animal/Llama > %{_datadir}/Foo/ Yes, it would, but that's not quite right. The accurate example for the guideline case would be: %files Emu %defattr(-,root,root,-) %{_datadir}/Foo/Animal/Emu %dir %{_datadir}/Foo/Animal/ %files Llama %defattr(-,root,root,-) %{_datadir}/Foo/Animal/Llama %dir %{_datadir}/Foo/Animal/ In rpm macro speak, %dir means "own just this directory, and none of its contents". ~spot From mw_triad at users.sourceforge.net Wed Feb 4 23:40:55 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 04 Feb 2009 17:40:55 -0600 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: <50baabb30902041503h78b152c2xecdb3877caa73643@mail.gmail.com> References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> <50baabb30902041503h78b152c2xecdb3877caa73643@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On Wed, Feb 4, 2009 at 11:14 PM, Matthew Woehlke wrote: >> If Fedora wants to ship >> tools to integrate such repositories more closely with Fedora, or to >> contribute to building such a repository, I would support that effort, but I >> don't think it should be done in the same repository as our software. > > The question is who defines your "our software" ? > I consider OVM [snip] I don't know enough about OVM to comment. I was replying to Nicolas apparently wanting to ship image, music, video (music video?), etc. libraries next to octave. > I don't think one can define "our software". By "our software" I mean "stuff in Fedora, which is mostly software plus data needed to make that software useful". Emphasis on "needed". If Fedora included software that used OVM, and OVM was relatively important to that software being useful, then I wouldn't object to it. As above, I don't consider myself knowledgeable enough to form an opinion as to the merit of OVM without such software. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We interrupt this e-mail to bring you a lame signature attempting to be witty. From rvinyard at cs.nmsu.edu Wed Feb 4 23:43:02 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Wed, 4 Feb 2009 16:43:02 -0700 (MST) Subject: Question on Directory Ownership In-Reply-To: <498A274B.3050003@redhat.com> References: <42996.155.148.81.31.1233789309.squirrel@intranet.cs.nmsu.edu> <498A274B.3050003@redhat.com> Message-ID: <55561.155.148.81.31.1233790982.squirrel@intranet.cs.nmsu.edu> Tom \"spot\" Callaway wrote: > On 2009-02-04 at 18:15:09 -0500, "Rick L. Vinyard, Jr." > wrote: > >> Wouldn't this cause duplication of files? >> >> %files Emu >> %defattr(-,root,root,-) >> %{_datadir}/Foo/Animal/Emu >> %{_datadir}/Foo/ >> >> %files Llama >> %defattr(-,root,root,-) >> %{_datadir}/Foo/Animal/Llama >> %{_datadir}/Foo/ > > Yes, it would, but that's not quite right. The accurate example for the > guideline case would be: > > %files Emu > %defattr(-,root,root,-) > %{_datadir}/Foo/Animal/Emu > %dir %{_datadir}/Foo/Animal/ > > %files Llama > %defattr(-,root,root,-) > %{_datadir}/Foo/Animal/Llama > %dir %{_datadir}/Foo/Animal/ > > In rpm macro speak, %dir means "own just this directory, and none of its > contents". > Ahhh, thanks. %dir is what I was missing. From ngompa13 at gmail.com Wed Feb 4 23:56:01 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 4 Feb 2009 17:56:01 -0600 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: <8278b1b0902041556j6a08fee7p94bf8b8ec5405d3b@mail.gmail.com> Apparently, Fedora DOES expect that... Or somehow magically play DVDs in Ogg formats. I have two things against Ogg formats: 1) Not well used outside purist communities 2) Theora has horrible quality compared to other video codecs. I do though, like Ogg Vorbis and use it regularly. On Wed, Feb 4, 2009 at 5:11 PM, Matthew Woehlke < mw_triad at users.sourceforge.net> wrote: > Kevin Kofler wrote: > >> That wiki page is hardly "what Fedora is about" and in fact I believe it >> is >> counterproductive. We should instead point people to Gnash and/or Swfdec. >> > > Indeed. +1 for gnash ;-). > > Or just not recommend consuming Flash content at all, just like we do for >> DVDs and MP3s. >> > > Just what are you supposed to use instead of DVD's? Do you really expect > all Fedora users (in the U.S. anyway) to boycott watching movies on their > computers? > > -- > Matthew > Please do not quote my e-mail address unobfuscated in message bodies. > -- > We interrupt this e-mail to bring you a lame signature attempting to be > witty. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Wed Feb 4 23:57:09 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 05 Feb 2009 00:57:09 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <50baabb30902041444k562589ffgf95769dac5ea1b9@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > I'm sure you are not referring to OVM, but to fedora announcement list ! I'm referring to Manuel's suggestion of adding "For the moment you will need to use it" to %description. Kevin Kofler From tcallawa at redhat.com Wed Feb 4 23:59:11 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Feb 2009 18:59:11 -0500 Subject: DVD (video) and Fedora In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: <498A2BCF.2010205@redhat.com> On 2009-02-04 at 18:11:02 -0500, Matthew Woehlke wrote: > Just what are you supposed to use instead of DVD's? Do you really expect > all Fedora users (in the U.S. anyway) to boycott watching movies on > their computers? >From a purely legal perspective, the only way Linux users can legally watch encrypted DVD movies on their Linux computer is to purchase proprietary software such as PowerDVD or LinDVD. Hooray for the DMCA! Since Fedora isn't about to start willfully breaking US Federal Law, nor are we going to start including proprietary software, we have no option for Fedora users at this time. ~spot From kevin.kofler at chello.at Thu Feb 5 00:07:24 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 05 Feb 2009 01:07:24 +0100 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: Matthew Woehlke wrote: > Just what are you supposed to use instead of DVD's? Do you really expect > all Fedora users (in the U.S. anyway) to boycott watching movies on > their computers? The official recommendation is to only watch Ogg Theora content... Unfortunately, there's nothing else Fedora can officially recommend. See also: https://fedoraproject.org/wiki/ForbiddenItems#DVD_Playback https://fedoraproject.org/wiki/Multimedia/DVD Kevin Kofler From jcm at redhat.com Thu Feb 5 00:13:23 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 04 Feb 2009 19:13:23 -0500 Subject: module-init-tools v3.6 released In-Reply-To: <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> Message-ID: <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> On Wed, 2009-02-04 at 18:19 -0500, Jon Masters wrote: > On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: > > > I'm considering pushing an update to F-9 since v3.5+ is so much faster > > than previous releases - and it impacts boot time, but I have to admit > > that I was more concerned about F10 and rawhide until now. > > Oh, there's a slight issue with the handling of modules.order still for > the binary tries in newer module-init-tools. This might manifest in a > switch of e.g. module used in initrd for storage devices with multiple > modaliases. So...one question... We now have binary versions of files like "modules.dep", "modules.alias" and "modules.symbols". These end in ".bin" and *augment* but do not replace the textual versions of these files. If we find the binary files, we are *much* faster at loading modules - boot overhead is e.g. under one second. But we need to be able to make changes to these binary files in order to add ordering support, and also just for the future. Our plan is to freeze the old text file format (the "last" change will be the one made recently in which modules.dep can now have relative paths to save space) and to fallback to it whenever the binary format changes and modprobe finds older binary files. This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be "slow" booting before depmod has been re-run again. I'm thinking about just doing a "depmod -a" on upgrade in such cases in the future...is there a problem with that idea? Jon. From ml at bendler-net.de Thu Feb 5 00:18:45 2009 From: ml at bendler-net.de (Thomas Bendler) Date: Thu, 5 Feb 2009 01:18:45 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902041234k76204099m9cbde73836ce5dbc@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> <604aa7910902041234k76204099m9cbde73836ce5dbc@mail.gmail.com> Message-ID: On Wed, Feb 4, 2009 at 9:34 PM, Jeff Spaleta wrote: > 2009/2/4 Thomas Bendler : > > At least that should be sufficent to detect the major distributions by > name and > > some other by simply an unknown entry in GRUB. > > Define major distribution Why? I might have a different view on what major distributions are compared to other people. For me major distributions are RHEL, Fedora, Ubuntu, Novell and Debian. But some people might think different, that's fine. All of the distributions I've mentioned could be identified by /etc/lsb-release. If someone else think: "Oh my favorit distribution is XY and could be identified by /etc/blablabla!", fine, let's add it to the identification routine and become a better OS ... > Is Xandros and Linpus major distributions to you... they are the > leading pre-installed distributions of linux by a wide wide margin if Who cares? If they are leading distributions, someone will have a installation of them and might be able to check how they can be identified. If not, they are unkown distributions, that's also fine, the main thing is they are detected and added to the GRUB menu after installation. > you believe the press reports. How do we identify those accurately? This is not necessary. It is necessary to add an entry for those distributions to GRUB during installation. If they are identified by a correct name or by unkown distribution is completly unimportant. If someone on the list has an installation of this distribution he might contribute the relevant information. Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Feb 5 01:44:12 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Feb 2009 07:14:12 +0530 Subject: DVD (video) and Fedora In-Reply-To: <8278b1b0902041556j6a08fee7p94bf8b8ec5405d3b@mail.gmail.com> References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> <8278b1b0902041556j6a08fee7p94bf8b8ec5405d3b@mail.gmail.com> Message-ID: <498A446C.6080806@fedoraproject.org> King InuYasha wrote: > Apparently, Fedora DOES expect that... Or somehow magically play DVDs in > Ogg formats. > > I have two things against Ogg formats: > 1) Not well used outside purist communities > 2) Theora has horrible quality compared to other video codecs. > > I do though, like Ogg Vorbis and use it regularly. 1) Firefox, Epiphany, Opera etc will play Theora by default in their next major release. Native video support without the need for plugins is big deal and will push more people to generate that type of content 2) Red Hat via Monty is working on improving the quality. http://web.mit.edu/xiphmont/Public/theora/demo.html For a lot of web content, it is already good enough. Anything more and we will run into patent issues again. Rahul From steven at scc.hk Thu Feb 5 02:33:57 2009 From: steven at scc.hk (Steven Drinnan) Date: Thu, 05 Feb 2009 10:33:57 +0800 Subject: IBus feature in fedora 11 Message-ID: <1233801237.14785.8.camel@laptop.myhome> I am not sure if this is the right place. Please tell me and I'll post this here. I have a big concern about you are changing the default input method. The reason being is that I and my family live in Hong Kong and the main input method used here is quick. So changing it would be a pain in the neck. I see that CangJie 5 is there but for most Hong Kong Users they do not like it as it takes to much to remember the codes. I do however understand that SCIM will be still available. But if I have to install that instead for every install that I do would be annoying to say the least. Anyway just my thoughts. Steven Drinnan From steven at scc.hk Thu Feb 5 02:33:57 2009 From: steven at scc.hk (Steven Drinnan) Date: Thu, 05 Feb 2009 10:33:57 +0800 Subject: IBus feature in fedora 11 Message-ID: <1233801237.14785.8.camel@laptop.myhome> I am not sure if this is the right place. Please tell me and I'll post this here. I have a big concern about you are changing the default input method. The reason being is that I and my family live in Hong Kong and the main input method used here is quick. So changing it would be a pain in the neck. I see that CangJie 5 is there but for most Hong Kong Users they do not like it as it takes to much to remember the codes. I do however understand that SCIM will be still available. But if I have to install that instead for every install that I do would be annoying to say the least. Anyway just my thoughts. Steven Drinnan From steven at scc.hk Thu Feb 5 02:33:57 2009 From: steven at scc.hk (Steven Drinnan) Date: Thu, 05 Feb 2009 10:33:57 +0800 Subject: IBus feature in fedora 11 Message-ID: <1233801237.14785.8.camel@laptop.myhome> I am not sure if this is the right place. Please tell me and I'll post this here. I have a big concern about you are changing the default input method. The reason being is that I and my family live in Hong Kong and the main input method used here is quick. So changing it would be a pain in the neck. I see that CangJie 5 is there but for most Hong Kong Users they do not like it as it takes to much to remember the codes. I do however understand that SCIM will be still available. But if I have to install that instead for every install that I do would be annoying to say the least. Anyway just my thoughts. Steven Drinnan From rakesh.pandit at gmail.com Thu Feb 5 04:13:23 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Thu, 5 Feb 2009 09:43:23 +0530 Subject: Bodhi/bugzilla In-Reply-To: <37950adcd1c18722c948e1c88d388892.squirrel@mail.jcomserv.net> References: <37950adcd1c18722c948e1c88d388892.squirrel@mail.jcomserv.net> Message-ID: 2009/2/5 Jon Ciesla : > My last few Bodhi updates have had BZ numbers in them, and I've not seen > anything in the BZs. I've updated those manually so the reporters are > aware, but I was wondering if there was an intentional change I missed, or > should I file a trac bug for Infrastructure? > Which update and BZ number ? But it seems to work for me. Yesterday I pushed update for up-imapproxy: https://bugzilla.redhat.com/show_bug.cgi?id=477096 and today when it was moved to testing BZ bug got updated. -- Rakesh Pandit From jspaleta at gmail.com Thu Feb 5 04:32:37 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Feb 2009 19:32:37 -0900 Subject: Fedora tested in c't: grub missing feature In-Reply-To: References: <1233699392.11676.10.camel@choeger5.umpa.netz> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> <604aa7910902041234k76204099m9cbde73836ce5dbc@mail.gmail.com> Message-ID: <604aa7910902042032w632b1741t5b82d9f935a203e2@mail.gmail.com> 2009/2/4 Thomas Bendler : > This is not necessary. It is necessary to add an entry for those > distributions to GRUB during installation. If they are identified by a > correct name or by unkown distribution is completly unimportant. If someone > on the list has an installation of this distribution he might contribute the > relevant information. What piece of metadata defines a distribution..even an unnamed distribution? If i have 15 partitions, only the ntfs partition has a boot label, how does the installer determine which of the other 4 partitions are the /boot or / of a linux distribution? -jef From bruno at wolff.to Thu Feb 5 04:37:51 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 4 Feb 2009 22:37:51 -0600 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: <20090205043751.GA28196@wolff.to> On Thu, Feb 05, 2009 at 01:07:24 +0100, Kevin Kofler wrote: > > The official recommendation is to only watch Ogg Theora content... > Unfortunately, there's nothing else Fedora can officially recommend. What about Dirac? http://en.wikipedia.org/wiki/Dirac_(codec) It looks like Dirac is supported in Fedora by the dirac and schroedinger packages. From cchance at redhat.com Thu Feb 5 04:50:57 2009 From: cchance at redhat.com (Caius "kaio" Chance) Date: Thu, 05 Feb 2009 14:50:57 +1000 Subject: IBus feature in fedora 11 Message-ID: <498A7031.3040803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Steven, Thank you very much for your messages. > I see that CangJie 5 is there but for most Hong Kong Users they do not like it as it takes to much to remember the codes. I agree. Especially win32 is using CangJie3-like or Quick input. > I do however understand that SCIM will be still available. But if I have to install that instead for every install that I do would be annoying to say the least. There are already thoughts of adding CJ3 and Quick into ibus. It should not be too hard because only a minor modification is needed to bring tables (to map keys to characters) from SCIM to ibus. Please be my precious guest if you don't mind to test for me later on. :) Best Regards, Caius Chance - -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmKcDEACgkQmo+B7bGj5dIR5gCgwVbxj9ymMwmAiNbDUWNNA5n4 eAMAn2XGQDevwaat0ahhvVQHydd9MlSf =Qofg -----END PGP SIGNATURE----- From MathStuf at gmail.com Thu Feb 5 04:57:28 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Wed, 04 Feb 2009 23:57:28 -0500 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Kofler wrote: > Matthew Woehlke wrote: >> Just what are you supposed to use instead of DVD's? Do you really expect >> all Fedora users (in the U.S. anyway) to boycott watching movies on >> their computers? > > The official recommendation is to only watch Ogg Theora content... > Unfortunately, there's nothing else Fedora can officially recommend. > > See also: > https://fedoraproject.org/wiki/ForbiddenItems#DVD_Playback > https://fedoraproject.org/wiki/Multimedia/DVD > > Kevin Kofler > There are also the matroska codecs. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmKcbkACgkQiPi+MRHG3qQlRQCeMNaBHpOpUdQZONloaqxVDYQa 19cAn0Md9HnfguwXrBuod5oN2CveedSw =Eaj9 -----END PGP SIGNATURE----- From MathStuf at gmail.com Thu Feb 5 05:13:26 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Thu, 05 Feb 2009 00:13:26 -0500 Subject: Fedora tested in c't: grub missing feature References: <1233699392.11676.10.camel@choeger5.umpa.netz> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph H?ger wrote: > Hi, > > fedora has recently been tested (again) and compared against other > distributions (Ubuntu and OpenSUSE) by c't, a german IT magazine from > the heise publishing house. > > Among other criticisms one thing was really annoying: When a user > installs fedora on a machine with windows installed (common use case) it > detects that installation and offers to add it to grub. But installing > fedora on a box with an already present linux distro installation will > yield that installation removed from grub. > > I understand that the bootloader is a part of the distro and its > configuration gets changed e.g. during kernel updates, but is there > really only the answer to remove one distribution completely? > Do we really want to support Windows as second OS more than OpenSUSE or > Ubuntu (or CentOS, or Debian, or Gentoo, or ........) > At least the anaconda team should consider printing a warning about one > OS going to "be lost" during install and how to recover. > > Any thoughts on that? This may be more for grub upstream, but what if grub could create a menu given different files to work with. Fedora installs /boot/grub/fedora.lst, OpenSuSE installs opensuse.lst, and so on. This way multi-boot systems can handle as many distros as needed/wanted and not have them step on each other fighting for control of menu.lst and its formatting. Then menu.lst could be used for common things (such as which to make the default, timeout, splash, and other settings). Then create a tool to manage the common file settings. It would only require the user to make sure that /boot is large enough for kernels and the same for all distros. I think this would be an easier solution than figuring out a common format for all distros to use and making sure that they don't step on each others' toes. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmKdXYACgkQiPi+MRHG3qR+YQCgqzSjxBaP+lepVfb9MdJ/onCZ 28YAn054eWLPy5p101hx4b/RKjKxvj1z =kyMZ -----END PGP SIGNATURE----- From gmaxwell at gmail.com Thu Feb 5 05:17:47 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 5 Feb 2009 00:17:47 -0500 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: On Wed, Feb 4, 2009 at 11:57 PM, Ben Boeckel wrote: >> The official recommendation is to only watch Ogg Theora content... >> Unfortunately, there's nothing else Fedora can officially recommend. >> >> See also: >> https://fedoraproject.org/wiki/ForbiddenItems#DVD_Playback >> https://fedoraproject.org/wiki/Multimedia/DVD >> >> Kevin Kofler >> > > There are also the matroska codecs. Matroska is a container, like ".Ogg", ".mov", or ".avi". It isn't a codec. (And I'm not aware of any codecs under the Matroska moniker) Very often Xvid (mpeg 4 part 2) or H264 (mpeg 4 part 10) is placed in Matroska for Video. These codecs are not acceptable for Fedora. (Vorbis is fairly common for audio in these files; though MP3 and AAC are used too). You could put Theora (+Vorbis) in MKV, in theory, and I think people have done it before, but I know it doesn't work right in many (most? virtually all?) mkv supporting apps. I'd say that would be something worth fixing, since there are a lot of complex features in MKV that no one has done for Ogg (like menus) except that I could still never recommend mkv files to people, since free codecs in MKV pretty much only theoretically possible (like non-free codecs in Ogg are theoretically possible, but not something you're likely to find). For Fedora we wouldn't want to recommend MKV for users simply because there is a 99.9999% chance of any random mkv file not working for them. As far as Dirac goes, it's fine stuff too, but doesn't immediately solve any of the concerns raised with what is currently available. Fortunately, it looks like the unencumbered media world is all playing nice: Dirac in Ogg works in Fedora today. So in terms of recommendation you can just direct users to "ogg" files and whatever they get will JustWork? on free software including, soon, Firefox. From rc040203 at freenet.de Thu Feb 5 05:52:34 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Feb 2009 06:52:34 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <20090204180143.GC12726@nostromo.devel.redhat.com> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <20090204164707.GA7209@srcf.ucam.org> <20090204180143.GC12726@nostromo.devel.redhat.com> Message-ID: <498A7EA2.9020001@freenet.de> Bill Nottingham wrote: > Matthew Garrett (mjg at redhat.com) said: >>> Enabling USB autosuspend looks like a good candidate for being a default >>> though. I've used it on quite a few Fedora 10 machines around here and >>> haven't experienced any problems so far, so it seems to have matured >>> enough by now from what i can see. >> Scanners and printers are the worst case for this. I think we really >> need to implement some kind of decent testing framework and build some >> whitelists. > > If we're enabling it by default on hardware that is known OK, then > I'm not sure why this should be a huge issue - the majority of machines > don't run with a USB scanner/printer attached, I would imagine. What makes you think this? These days, probably most home users will own at least one USB printer, many will also own usb scanners. Ralf From jkeating at redhat.com Thu Feb 5 06:15:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 04 Feb 2009 22:15:58 -0800 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <498A7EA2.9020001@freenet.de> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <20090204164707.GA7209@srcf.ucam.org> <20090204180143.GC12726@nostromo.devel.redhat.com> <498A7EA2.9020001@freenet.de> Message-ID: <1233814558.7493.1141.camel@localhost.localdomain> On Thu, 2009-02-05 at 06:52 +0100, Ralf Corsepius wrote: > > What makes you think this? These days, probably most home users will own > at least one USB printer, many will also own usb scanners. They may own them, but are they attached always? What about the mass migration over to network printers, or network print adapters for existing printers? Sadly this is probably one case that can't easily be measured one way or the other. So what Bill says is right, we need a whitelist or a set of quirks to handle it correctly. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Feb 5 06:53:20 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Feb 2009 07:53:20 +0100 Subject: ln -s /boot/vmlinuz-2.6.27.9-159.fc10.x86_64 /boot/vmlinuz (was: Re: Fedora tested in c't: grub missing feature) In-Reply-To: <1233699392.11676.10.camel@choeger5.umpa.netz> References: <1233699392.11676.10.camel@choeger5.umpa.netz> Message-ID: <498A8CE0.80007@leemhuis.info> On 03.02.2009 23:16, Christoph H?ger wrote: > > Among other criticisms one thing was really annoying: When a user > installs fedora on a machine with windows installed (common use case) it > detects that installation and offers to add it to grub. But installing > fedora on a box with an already present linux distro installation will > yield that installation removed from grub. > > I understand that the bootloader is a part of the distro and its > configuration gets changed e.g. during kernel updates, but is there > really only the answer to remove one distribution completely? > Do we really want to support Windows as second OS more than OpenSUSE or > Ubuntu (or CentOS, or Debian, or Gentoo, or ........) > At least the anaconda team should consider printing a warning about one > OS going to "be lost" during install and how to recover. One thing related to this: OpenSuse and Ubuntu on install hardcode the path to the (latest?) Fedora kernel in their grub menu.lst if they detect a Fedora install somewhere on the disk. But that iirc breaks after a few Fedora kernels updates, because the Fedora kernel that was present and configured in the menu.lst from OpenSuse or Ubuntu gets removed sooner or later. Users thus can't boot Fedora anymore with the boot loaders from OpenSuse or Ubuntu (which might be the default boot loader); users then might stick to OpenSuse or Ubuntu and most will likely blame Fedora for their problem, because "it suddenly didn't boot anymore after I updated it". Thus I'm wondering if we should make /sbin/new-kernel-pkg add the links /boot/vmlinuz and /boot/initrd on kernel-install and let them point to the lastet kernel/initrd (the one from the kernel that is made default in our grub on install). Then OpenSuse and Ubuntu could use those files instead of the full vmlinuz/initrd path in their grub configuration and users would be able to start Fedora even after a few kernel updates from Fedora got installed. CU knurd From nicolas.mailhot at laposte.net Thu Feb 5 07:06:27 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 05 Feb 2009 08:06:27 +0100 Subject: Fedora Project, give me 20 Million Euros or Free EDA software In-Reply-To: References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com> <20090131132115.6570018a@ohm.scrye.com> <4984C972.7080303@nobugconsulting.ro> <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl> <4984F645.5090400@nobugconsulting.ro> <385866f0901311912u221e4ce4p566e063d89574e0a@mail.gmail.com> <20090201141642.635fb294@lain.camperquake.de> <1233495778.13582.19.camel@arekh.okg> <1233786888.19376.5.camel@arekh.okg> <1233788279.20499.8.camel@arekh.okg> Message-ID: <1233817587.3865.13.camel@arekh.okg> Le mercredi 04 f?vrier 2009 ? 17:28 -0600, Matthew Woehlke a ?crit : > Nicolas Mailhot wrote: > > Sure, take the time to make the experiment, remove fonts, remove music, > > remove themes, remove images, and see how much stuff is still working or > > useful in your nice "software only" repository. > > First off, I'm not talking about "core material", I'm talking about > things that merely enhance, much of which is currently /not/ in Fedora > repos. Who are you to judge what the "merely" point is? Who are you to judge that because something does not fall 100% in your etricated "software" category it's less useful for Fedora than a random sf.net bit of software two people in the world use (the author and the packager)? We've explicitely refused to start assessing the degree of usefulness of our packages (except there must be some), you're arguing dual standards. > Second, we were talking about adding content that isn't used. > > Third, what's to say we can't write tools to have dependencies on other > types of repositories? The main point is that it doesn't make sense to > use the exact same repo and infrastructure for disparate content types. > I'd rather not see Fedora becoming a multimedia repository, Everyone understood this. > not only > because I don't think it's an appropriate goal, but because if we're > doing this in Fedora and not in a more general sense, we're keeping > non-Fedora users out. I think we have enough Fedora problems without spending a lot of time on non*-Fedora-users. > "I find that kde-look.org enhances kdebase. We should package > kde-look.org (at least, all appropriately licensed content) and add it > to Fedora's repos." > > Do you seriously agree with the above? If there are people willing to maintain the resulting packages, yes. > > What they usually don't is that adding more "non-software" elements (in > > addition to those we already have to because a lot of things would > > bloody not work without them), would have additionnal synergistic > > effects for everyone involved. > > Again, I'm not opposed to making Free content more accessible from > Fedora. I'm opposed to doing it via inappropriate infrastructure, and > I'm opposed to doing it in a Fedora-centric manner. Let's also remove perl packages since you can use them directly via "more appropriate" CPAN (and a lot of people do it), let's remove java packages (can be used by maven), let's remove translations (take precious liveced and mirror space, noarch, not-code, people just have to learn to download them via separate plugin systems), and most of all let's make very sure the people who work on all this for us understand 100% they're not the same class of contributors of glibc maintainers and have to fend by themselves. This is something which is going to greatly enhance Fedora, yay! > > PS Fonts can be compiled and include an instruction langage. Which is > > complex enough some of its bits got patented. Looks like software to me. > > Are they architecture specific? No. Let's remove all scripts and other interpreted files. > Does "A great looking gothic font" give > you any useful information if this is that perfect font you need for > your presentation/art project? It gives enough information for Japanese users that know what a gothic style is. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Thu Feb 5 07:18:56 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Feb 2009 08:18:56 +0100 Subject: Request for feedback and/or participation on https://fedoraproject.org/wiki/Features/PowerManagement In-Reply-To: <1233814558.7493.1141.camel@localhost.localdomain> References: <498982C3.8030704@redhat.com> <20090204154251.GA3301@nostromo.devel.redhat.com> <4989BCA8.8090302@redhat.com> <20090204164707.GA7209@srcf.ucam.org> <20090204180143.GC12726@nostromo.devel.redhat.com> <498A7EA2.9020001@freenet.de> <1233814558.7493.1141.camel@localhost.localdomain> Message-ID: <498A92E0.6030808@freenet.de> Jesse Keating wrote: > On Thu, 2009-02-05 at 06:52 +0100, Ralf Corsepius wrote: >> >> What makes you think this? These days, probably most home users will own >> at least one USB printer, many will also own usb scanners. > > They may own them, but are they attached always? Very likely not all of them, but likely a nice subset of them. Depends on the use-case (esp. personal vs. shared) and on personal habits. When regarding my setup: I have one of these USB multi-device printer/scanner/copierer gadgets physically attached to the same machine (my personal desktop) all the time, however, but it's not powered on all the time :) > What about the mass > migration over to network printers, or network print adapters for > existing printers? Agreed, things are about to change, but this is an ongoing developing and is still far from having settled. Anyway, how about those folks who are using Linux/Fedora as printer/scanner-servers (may-be even combined with FAX/FAX-servers)? > Sadly this is probably one case that can't easily be measured one way or > the other. Yep, it's a matter of personal habits and of personal use-case. That said, I think, this all needs to be handled dynamically. If this can't be achieved, it need to remain "user customizable". Ralf From robert at fedoraproject.org Thu Feb 5 07:28:11 2009 From: robert at fedoraproject.org (Robert Scheck) Date: Thu, 5 Feb 2009 08:28:11 +0100 Subject: Jakub's Recommendations for ia32 Support In-Reply-To: <20090203185310.GD5846@mokona.greysector.net> References: <49887ADF.9090606@redhat.com> <20090203185310.GD5846@mokona.greysector.net> Message-ID: <20090205072811.GA18195@hurricane.linuxnetz.de> On Tue, 03 Feb 2009, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 03 February 2009 at 18:11, Warren Togami wrote: > > In related news, cebbert wants to do the following to the F-11 kernel: > > - Eliminate the current i686 kernel. > > - i686 hardware would get i686 PAE by default. > > Not all i686 hardware is PAE capable. > > > - i586 kernel becomes i686, except without cmov. This is primarily so > > people don't complain when they realize they have the "i586" kernel. > > And this will be installed on anything that's not PAE capable? Did I get this correct? We will ship "i686 without cmov" and "i686 PAE"? - i586 -> i686 (without cmov) - i686 -> i686 PAE? I know, there was some ongoing discussion regarding cmov, sse/sse2. My main point referrs to how "i686 non-PAE capable hardware" will be handled. Greetings, Robert From nicolas.mailhot at laposte.net Thu Feb 5 07:31:51 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 05 Feb 2009 08:31:51 +0100 Subject: BPG Georgian Unicode fonts - packagers wanted In-Reply-To: <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> References: <1233701416.26332.26.camel@arekh.okg> <519a81d30902042302g39bf5623rc02311ce013871b1@mail.gmail.com> <519a81d30902042320t51e5062bg9849578d28106b3c@mail.gmail.com> Message-ID: <1233819111.3865.19.camel@arekh.okg> Le jeudi 05 f?vrier 2009 ? 11:20 +0400, George Machitidze a ?crit : > On Thu, Feb 5, 2009 at 11:02 AM, George Machitidze > wrote: > Hi Nicolas! Hi George, > Thank you for initiating this issue - I didn't expect to see > this message here :) > I will talk with him directly and package files - I'm very > experienced with rpmbuild and spec-s. Tom has started packaging those fonts here: https://bugzilla.redhat.com/show_bug.cgi?id=483865 However I'm sure a native speaker that can propose great package summaries (upstream pages are 100% Georgian), and help bridge the communication gap with upstream (there are still a few legal nits to take care of apparently) would be very appreciated as co-maintainer. > Actually, I planned to release it, but I was little busy... > btw, one of our friends just few hours ago finished first > georgian psfu console font too, now we are testing it... I don't deal with console fonts, but I'm sure that if it was packaged it would be appreciated by Georgian Fedora users too. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jcm at redhat.com Thu Feb 5 08:52:26 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 05 Feb 2009 03:52:26 -0500 Subject: ln -s /boot/vmlinuz-2.6.27.9-159.fc10.x86_64 /boot/vmlinuz (was: Re: Fedora tested in c't: grub missing feature) In-Reply-To: <498A8CE0.80007@leemhuis.info> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <498A8CE0.80007@leemhuis.info> Message-ID: <1233823946.4166.156.camel@perihelion.bos.jonmasters.org> On Thu, 2009-02-05 at 07:53 +0100, Thorsten Leemhuis wrote: > Thus I'm wondering if we should make /sbin/new-kernel-pkg add the links > /boot/vmlinuz and /boot/initrd on kernel-install and let them point to > the lastet kernel/initrd (the one from the kernel that is made default > in our grub on install). Then OpenSuse and Ubuntu could use those files > instead of the full vmlinuz/initrd path in their grub configuration and > users would be able to start Fedora even after a few kernel updates from > Fedora got installed. I like that idea. I also really like the idea of adding in some kind of postfix differentiator configured in /etc/sysconfig/kernel so that one can still have a shared /boot between several Fedora/RHEL/whatever. I might then configure: /boot/vmlinuz-fedora10 /boot/vmlinuz-rawhide /boot/vmlinuz-rhelX Jon. From opensource at till.name Thu Feb 5 09:00:31 2009 From: opensource at till.name (Till Maas) Date: Thu, 05 Feb 2009 10:00:31 +0100 Subject: Changing name of ISO checksum file In-Reply-To: <1233786326.7493.1118.camel@localhost.localdomain> References: <1233773956.7493.1105.camel@localhost.localdomain> <200902042258.48957.opensource@till.name> <1233786326.7493.1118.camel@localhost.localdomain> Message-ID: <200902051000.47229.opensource@till.name> On Wed February 4 2009, Jesse Keating wrote: > On Wed, 2009-02-04 at 22:58 +0100, Till Maas wrote: > > On Wed February 4 2009, Jesse Keating wrote: > > > As part of the Sha-256 feature[1], we need to change the SHA1SUM file > > > that has accompanied ISOs that Fedora produces for years. This isn't > > > > > > My questions are, does anybody actually care how we change it, so long > > > as its documented properly? > > > > I would appreciate the new name to contain information about which files > > are hashed in there, e.g. F11-i386.sha256 or F11-i386-Live.sha256. > It isn't enough that each directory of such isos has the hash file? Not for me, because I want to store my .iso collection in one directory together with their hash files, therefore they need to have different names. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From tim at niemueller.de Thu Feb 5 09:41:41 2009 From: tim at niemueller.de (Tim Niemueller) Date: Thu, 05 Feb 2009 10:41:41 +0100 Subject: Question on Directory Ownership In-Reply-To: <498A274B.3050003@redhat.com> References: <42996.155.148.81.31.1233789309.squirrel@intranet.cs.nmsu.edu> <498A274B.3050003@redhat.com> Message-ID: <498AB455.3030403@niemueller.de> Tom "spot" Callaway schrieb: > Yes, it would, but that's not quite right. The accurate example for the > guideline case would be: > > %files Emu > %defattr(-,root,root,-) > %{_datadir}/Foo/Animal/Emu > %dir %{_datadir}/Foo/Animal/ > > %files Llama > %defattr(-,root,root,-) > %{_datadir}/Foo/Animal/Llama > %dir %{_datadir}/Foo/Animal/ Shouldn't there be another %dir %{_datadir}/Foo or will that be inferred by rpm? Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From rawhide at fedoraproject.org Thu Feb 5 10:20:35 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 5 Feb 2009 10:20:35 +0000 (UTC) Subject: rawhide report: 20090205 changes Message-ID: <20090205102035.56A701F82DE@releng2.fedora.phx.redhat.com> Compose started at Thu Feb 5 06:01:03 UTC 2009 New package GConf2-dbus A process-transparent configuration system New package nautilus-gdu Nautilus extension for disk formatting New package python-ferari Optimizer for finite element code New package python-fiat Generation of arbitrary order instances of the Lagrange elements New package python-instant Python module for instant inlining of C and C++ code Removed package gimmie Removed package mew Updated Packages: acpid-1.0.8-2.fc11 ------------------ * Wed Feb 4 17:00:00 2009 Zdenek Prikryl - 1.0.8-2 - power.sh works with KDE 4.* (#483417) alsa-utils-1.0.19-2.fc11 ------------------------ * Wed Feb 4 17:00:00 2009 Jaroslav Kysela 1.0.19-2 - add %dir directive for /lib/alsa and /lib/alsa/init directories (bz#483324) anthy-9100g-1.fc11 ------------------ * Wed Feb 4 17:00:00 2009 Akira TAGOH - 9100g-1 - New upstream release. - convert all words in dictionaries to UTF-8. - Rename anthy-el and anthy-el-xemacs to emacs-anthy{,-el} and xemacs-anthy{,-el}. - Fix RPATH issue. - Support words for JIS X 0213:2004 in dictionary. (#195437) apr-1.3.3-3.fc11 ---------------- * Fri Jan 2 17:00:00 2009 Joe Orton 1.3.3 - rebuild * Wed Feb 4 17:00:00 2009 Joe Orton 1.3.3 - fix build with libtool 2.2 brasero-2.25.90-1.fc11 ---------------------- * Tue Feb 3 17:00:00 2009 Denis Leroy - 2.25.90-1 - Update to upstream 2.25.90 - Split media library into separate RPM (#483754) - Added patch to validate desktop files cairo-dock-2.0.0-0.3.svn1516_trunk.fc11 --------------------------------------- * Thu Feb 5 17:00:00 2009 Mamoru Tasaka - rev 1516 clive-2.1.4-1.fc11 ------------------ * Wed Feb 4 17:00:00 2009 Nicoleau Fabien 2.1.4-1 - Rebuild for 2.1.4 control-center-2.25.90-1.fc11 ----------------------------- * Thu Feb 5 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 createrepo-0.9.6-10.fc11 ------------------------ * Wed Feb 4 17:00:00 2009 Seth Vidal - 0.9.6-10 - working mergerepo again culmus-fonts-0.102-1.fc11 ------------------------- * Wed Feb 4 17:00:00 2009 Rahul Bhalerao - 0.102-1.fc11 - Updated version. - Following new font packaging guidelines. desktop-file-utils-0.15-6.fc11 ------------------------------ * Wed Feb 4 17:00:00 2009 Richard Hughes - 0.15-5 - Panu merged the rpm bits for this feature, but we've got a new provides filename. Respin this package with the new name. * Wed Feb 4 17:00:00 2009 Richard Hughes - 0.15-6 - Panu seems to be shipping the prov file in rpmbuild. Remove it here until we work out where it belongs. dnssec-tools-1.4.1-6.fc11 ------------------------- * Wed Feb 4 17:00:00 2009 Wes Hardaker - 1.4.1-6 - make the perlmods module directly require the needed perl mods mainly for directory ownership. eclipse-3.4.1-15.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Alexander Kurtakov 1:3.4.1-15 - Rebuild for new xulrunner. enigma-1.01-8.1 --------------- * Wed Feb 4 17:00:00 2009 Thorsten Leemhuis - 1.01-8 - add enigma-gcc-4.4-ftbfs.patch from debian ettercap-0.7.3-30.fc11 ---------------------- * Wed Feb 4 17:00:00 2009 Jon Ciesla - 0.7.3-29 - Use more reasonably sized icon, BZ484030. * Wed Feb 4 17:00:00 2009 Jon Ciesla - 0.7.3-30 - Correction to -29. evince-2.25.90-1.fc11 --------------------- * Tue Feb 3 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 evolution-data-server-2.25.90-4.fc11 ------------------------------------ * Wed Feb 4 17:00:00 2009 Matthew Barnes - 2.25.90-3.fc11 - Work around libical's broken pkg-config file. * Wed Feb 4 17:00:00 2009 Matthew Barnes - 2.25.90-4.fc11 - ... and fix our own includes too. evolution-exchange-2.25.90-1.fc11 --------------------------------- * Mon Feb 2 17:00:00 2009 Matthew Barnes - 2.25.90-1.fc11 - Update to 2.25.90 evolution-zimbra-0.1.1-5.fc11 ----------------------------- * Wed Feb 4 17:00:00 2009 Caol??n McNamara - 0.1.1-5 - rebuild for dependencies gallery2-2.3-3.fc11 ------------------- * Wed Feb 4 17:00:00 2009 Jon Ciesla - 2.3-3 - Base requires gallery2-httpauth for upgrade path, BZ 483523. gambas2-2.11.1-1.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Tom "spot" Callaway 2.11.1-1 - update to 2.11.1 gdal-1.6.0-4.fc11 ----------------- * Wed Feb 4 17:00:00 2009 Balint Cristian - 1.6.0-4 - rebuild with grass support - fix email typo ghostscript-8.64-2.fc11 ----------------------- * Wed Feb 4 17:00:00 2009 Tim Waugh 8.64-2 - 8.64 (bug #483958). - Removed trade marks to avoid any potential confusion. glibc-2.9.90-3 -------------- * Wed Feb 4 17:00:00 2009 Jakub Jelinek 2.9.90-3 - update from trunk - ISO C++ compliant strchr etc. with GCC 4.4+ - AT_RANDOM support gnome-settings-daemon-2.25.90-1.fc11 ------------------------------------ * Wed Feb 4 17:00:00 2009 Matthias Clasen - 2.25.90-1 - Update to 2.25.90 gnubiff-2.2.10-3.fc11 --------------------- * Fri Jan 16 17:00:00 2009 Tomas Mraz - 2.2.10-2 - rebuild with new openssl * Wed Feb 4 17:00:00 2009 Caol??n McNamara - 2.2.10-3 - rebuild for dependencies grass-6.3.0-10.fc11 ------------------- * Thu Jan 29 17:00:00 2009 Balint Cristian - 6.3.0-10 - email change - rebuild for new mysql ibus-1.1.0.20090205-1.fc11 -------------------------- * Thu Feb 5 17:00:00 2009 Huang Peng - 1.1.0.20090205-1 - Update to 1.1.0.20090205. ibus-table-0.1.1.20081014-4.fc11 -------------------------------- * Wed Feb 4 17:00:00 2009 Caius Chance - 0.1.1.20081014-4 - Resolves: rhbz#466430 rhbz#466844 - Added wildcard features. - Added preedit clearance on refocus. iproute-2.6.28-2.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Marcela Ma??l????ov?? - 2.6.28-2 - 483484 install distribution files into /usr/share and also fixed install paths in spec - add the latest change from git which add DRR support c86f34942a0ce9f8203c0c38f9fe9604f96be706 jwhois-4.0-10.fc11 ------------------ * Wed Feb 4 17:00:00 2009 Vitezslav Crhonek - 4.0-10 - Close config file descriptor when finished reading the config file - Add support for ENUM domains into jwhois.conf Resolves: #465182 kdenetwork-4.2.0-3.fc11 ----------------------- * Wed Feb 4 17:00:00 2009 Jaroslav Reznik - 4.2.0-3 - port kopete video to libv4l (#475623) kvm-83-3.fc11 ------------- * Wed Feb 4 17:00:00 2009 Eduardo Habkost - 83-3 - Package kvmtrace and kvm_stat on kvm-tools subpackage (bz#480942) libX11-1.1.99.2-4.fc11 ---------------------- * Wed Feb 4 17:00:00 2009 Adam Jackson 1.1.99.2-4 - libX11-1.1.99.2-compose-updates.patch: Update compose sequences (from git) libXrandr-1.2.99.4-2.fc11 ------------------------- * Wed Feb 4 17:00:00 2009 Adam Jackson 1.2.99.4-2 - libXrandr-1.2.99.4-gop.patch: Fix encoding of GetOutputPrimary. libbeagle-0.3.9-2.fc11 ---------------------- * Wed Feb 4 17:00:00 2009 Matthias Clasen - 0.3.9-2 - Update to 0.3.9 libcdaudio-0.99.12p2-11.fc10 ---------------------------- * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 0.99.12p2-10 - took COPYING out of doc (it is simply wrong) - fixed license tag * Sat Dec 27 17:00:00 2008 Axel Thimm - 0.99.12p2-11 - Fix CVE-2005-0706. libcroco-0.6.2-1.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Matthias Clasen - 0.6.2-1 - Update to 0.6.2 libdrm-2.4.4-3.fc11 ------------------- * Thu Feb 5 17:00:00 2009 Dave Airlie 2.4.4-3 - update with more libdrm/radeon upstream fixes libtool-2.2.6-8.fc11 -------------------- * Wed Feb 4 17:00:00 2009 Jakub Jelinek 2.2.6-7 - rebuilt for gcc-4.4.0 * Wed Feb 4 17:00:00 2009 Karsten Hopp 2.2.6-8 - libtool-ltdl owns /usr/share/libtool, but not the config files (#484088) m2crypto-0.19.1-5 ----------------- * Wed Feb 4 17:00:00 2009 Miloslav Trma?? - 0.19.1-5 - Close the connection when an m2urllib2 response is closed Resolves: #460692 - Work around conflicts between macros defined by gcc and swig mail-notification-5.4-9.fc11 ---------------------------- * Wed Feb 4 17:00:00 2009 Caol??n McNamara - 5.4-9 - rebuild for dependencies mkinitrd-6.0.76-1.fc11 ---------------------- * Wed Feb 4 17:00:00 2009 Hans de Goede - 6.0.76-1 - Fix configuration of network interfaces for network boot (#481078) - Fix iscsi chap password being seen as ******** - Handle lv root specified as /dev/dm-X properly (#471729) - Initial commit of EXTLINUX (no menu) support - Do not call dm_resolve_name on dmraidsets names, sometimes it fails, and it is not necessary, this fixes the dmraid boot failure seen on some systems (#476818) - Make nash mount support relatime (#296361) - FIX: nash unable to find dm devs by uuid or label (#480667) module-init-tools-3.6-1.fc11 ---------------------------- * Wed Feb 4 17:00:00 2009 Jon Masters - 3.6 - Unify fixes from other distributions in common upstream. mpfr-2.4.0-1.fc11 ----------------- * Wed Feb 4 17:00:00 2009 Ivana Varekova - 2.4.0-1 - update to 2.4.0 mr-0.38-1.fc11 -------------- * Wed Feb 4 17:00:00 2009 Fabian Affolter - 0.38-1 - Updated to new upstream version 0.38 netbeans-platform-6.5-5.fc11 ---------------------------- * Wed Feb 4 17:00:00 2009 Victor Vasilyev 6.5-5 - Bug #483384 - "netbeans : Unowned directories" is fixed - netbeans-platform provides netbeans-platform8 nettee-0.1.9.1-1.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Fabian Affolter - 0.1.9.1-3 - Updated to upstream version 0.1.9.1 nss-3.12.2.0-4.fc10 ------------------- * Fri Jan 23 17:00:00 2009 Kai Engert - 3.12.2.0-4 - Update to NSS_3_12_2_WITH_CKBI_1_73_RTM ochusha-0.6.0.1-0.3.cvs20090106T1430.fc11 ----------------------------------------- * Thu Feb 5 17:00:00 2009 Mamoru Tasaka - 0.6.0.1-0.3.cvs20090106T1430 - Patch to compile with g++44 openoffice.org-3.0.1-15.6.fc11 ------------------------------ * Tue Feb 3 17:00:00 2009 Caol??n McNamara - 1:3.0.1-15.6 - Resolves: rhbz#483223 openoffice.org-3.0.1.ooo98649.svtools.missingUI.patch - add mythes-pt depend to pt langpack - add workspace.gcc44.patch for gcc44 pango-1.23.0-2.fc11 ------------------- * Wed Feb 4 17:00:00 2009 Behdad Esfahbod - 1.23.0-2 - Move pango-view from pango-devel to pango pciutils-3.1.1-1.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Michal Hlavinka 3.1.1-1 - version 3.1.1 pfstools-1.7.0-3.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Ulrich Drepper - 1.7.0-3 * Mon Jan 5 2009 Ulrich Drepper - 1.7.0-2 - Fix BuildRequires php-5.2.8-8.fc11 ---------------- * Mon Jan 26 17:00:00 2009 Joe Orton 5.2.8-5 - split out sysvshm, sysvsem, sysvmsg, posix into php-process * Wed Feb 4 17:00:00 2009 Joe Orton 5.2.8-7 - drop obsolete configure args - drop -odbc patch (#483690) * Wed Feb 4 17:00:00 2009 Joe Orton 5.2.8-8 - fix patch fuzz, renumber patches popt-1.13-4.fc11 ---------------- portreserve-0.0.3-3.fc11 ------------------------ * Wed Feb 4 17:00:00 2009 Tim Waugh 0.0.3-3 - No longer need SELinux policy as it is now part of the selinux-policy package. ppl-0.10-6.fc11 --------------- * Wed Feb 4 17:00:00 2009 Roberto Bagnara 0.10-6 - Better workaround for the bug affecting PPL 0.10 on big-endian architectures. qt3-3.3.8b-21.fc11 ------------------ * Wed Feb 4 17:00:00 2009 Rex Dieter 3.3.8b-21 - unowned %qt_docdir (#483441) roundcubemail-0.2-7.stable.fc11 ------------------------------- * Wed Feb 4 17:00:00 2009 Jon Ciesla = 0.2-7.stable - Patch for CVE-2009-0413, BZ 484052. rpm-4.6.0-0.rc4.3.fc11 ---------------------- * Wed Feb 4 17:00:00 2009 Panu Matilainen - 4.6.0-0.rc4.3 - extract mimehandler provides from .desktop files - preliminaries for extracting font provides (not enabled yet) - dont classify font metrics data as fonts - only run script dep extraction once per file, duh ruby-RMagick-2.9.1-1.fc11 ------------------------- * Thu Feb 5 17:00:00 2009 Mamoru Tasaka - 2.9.1-1 - 2.9.1 samba-3.3.0-0.25.fc11 --------------------- * Fri Nov 28 17:00:00 2008 Guenther Deschner - 3.3.0-0rc1.24 - Update to 3.3.0rc1 * Tue Feb 3 17:00:00 2009 Guenther Deschner - 3.3.0-0.25 - Update to 3.3.0 final - Add upstream fix for ldap connections to AD (Bug #6073) - Remove bogus perl dependencies (resolves: #473051) samyak-fonts-1.2.1-4.fc11 ------------------------- * Wed Feb 4 17:00:00 2009 Pravin Satpute 1.2.1-4 - renamed samyak-common-fonts to samyak-fonts-common selinux-policy-3.6.4-2.fc11 --------------------------- * Wed Feb 4 17:00:00 2009 Dan Walsh 3.6.4-2 - More fixes for devicekit sigen-0.0.2-0.26.20081206git529cd0e.fc11 ---------------------------------------- * Wed Feb 4 17:00:00 2009 Ben Boeckel 0.0.2-0.26.20081206git529cd0e - Patch for GCC 4.4 slim-1.3.1-3.fc11 ----------------- * Wed Feb 4 17:00:00 2009 Anders F Bjorklund 1.3.1-3 - use small "default_blue" background, instead of large compat "default" sqlite-3.6.10-3.fc11 -------------------- * Wed Feb 4 17:00:00 2009 Panu Matilainen - 3.6.10-3 - enable RTREE and FTS3 extensions (#481417) sudo-1.6.9p17-5.fc10 -------------------- * Thu Jan 29 17:00:00 2009 Daniel Kopecek 1.6.9p17-5 - Fix for incorrect handling of groups in Runas_User sugar-0.83.6-1.fc11 ------------------- * Wed Feb 4 17:00:00 2009 Simon Schampijer - 0.83.6-1 - Try harder to get an icon for a clipping - Hide the journal activity in the home view #87 - Correctly initialize the TrayIcon - Add 'View Details' option to object palette in journal - Translation updates - Hide OLPC-specific fields on non-xo machines #133 - Add a 'Clear search' button to 'No matching entries' message #266 - Correctly detect when a query in the journal is empty #255 - Avoid launching two instances of the same activity instance #238 - Add start-with option to objectpalette in the journal - Fix dnd of icons in the favorite view #213 - Right click on AP should reveal palette not connect to AP #10 - Display space used and left in the volume palette in the journal #33 - Don't update the zoom level when a dialog window pops up - Fix filtering the objectchooser with data types #219 sugar-datastore-0.83.3-1.fc11 ----------------------------- * Wed Feb 4 17:00:00 2009 Simon Schampijer - 0.83.3-1 - Only try to remove the checksum dir if it already exists - Rename the installed package from olpc.datastore to carquinyol sugar-toolkit-0.83.5-1.fc11 --------------------------- * Wed Feb 4 17:00:00 2009 Simon Schampijer - 0.83.5-1 - Palette positioning fixes #298 - 'Resume' activity window when NamingAlert is displayed #293 - Naming alert prevents activity close on keep error #224 tightvnc-1.5.0-0.11.20090204svn3586.fc11 ---------------------------------------- * Sun Jan 18 17:00:00 2009 Tomas Mraz 1.5.0-0.10.20081120svn3200 - rebuild with new openssl * Wed Feb 4 17:00:00 2009 Adam Tkac 1.5.0-0.11.20090204svn3586 - updated to r3586 - X.org 1.6 support - non-XKB international keyboards fixes - tightvnc-15-new-libtool.patch merged - added proper requirements on coreutils (#477501) totem-2.25.90-2.fc11 -------------------- * Wed Feb 4 17:00:00 2009 - Peter Robinson - 2.25.90-2 - Fix logic in spec file for xine disable up-imapproxy-1.2.7-0.3.rc1.fc11 ------------------------------- * Wed Feb 4 17:00:00 2009 Rakesh Pandit 1.2.7-0.3.rc1 - Patched buggy init script (David Rees, Bug 477096) xfsdump-3.0.0-1.fc11 -------------------- * Wed Feb 4 17:00:00 2009 Eric Sandeen 3.0.0-1 -New upstream release xfsprogs-3.0.0-1.fc11 --------------------- * Wed Feb 4 17:00:00 2009 Eric Sandeen 3.0.0-1 - New upstream release xorg-x11-server-utils-7.4-4.fc11 -------------------------------- * Wed Feb 4 17:00:00 2009 Adam Jackson 7.4-4 - xrandr 1.2.99.4 xplanet-1.2.0-5.fc11 -------------------- * Thu Feb 5 17:00:00 2009 Mamoru Tasaka - 1.2.0-5 - Patch to compile with g++44 yum-3.2.21-8.fc11 ----------------- * Wed Feb 4 17:00:00 2009 Seth Vidal - 3.2.21-8 - fix for YumHeaderPackages so it plays nicely w/createrepo and mergerepo, etc Summary: Added Packages: 5 Removed Packages: 2 Modified Packages: 80 Broken deps for i386 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.i386 requires libcamel-1.2.so.13 freedink-engine-1.08.20090120-1.fc11.i386 requires liberation-fonts 1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4 ldns-1.4.0-1.fc11.i386 requires libcrypto.so.7 libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0 linkage-0.2.0-4.fc11.i386 requires libcrypto.so.7 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.i386 requires libssl.so.7 mediatomb-0.11.0-4.fc11.i386 requires libcrypto.so.7 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15) 1:openoffice.org-langpack-he_IL-3.0.1-15.6.fc11.i386 requires culmus-fonts 1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15 publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.i386 requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so sepostgresql-8.3.5-2.1183.fc10.i386 requires libssl.so.7 sepostgresql-8.3.5-2.1183.fc10.i386 requires libcrypto.so.7 tetex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 Broken deps for x86_64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.i386 requires libcamel-1.2.so.13 evolution-brutus-1.2.34-1.fc11.x86_64 requires libcamel-1.2.so.13()(64bit) freedink-engine-1.08.20090120-1.fc11.x86_64 requires liberation-fonts 1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit) ldns-1.4.0-1.fc11.i386 requires libcrypto.so.7 ldns-1.4.0-1.fc11.x86_64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.i386 requires libcrypto.so.7 linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.x86_64 requires libcrypto.so.7()(64bit) mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libssl.so.7()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) mediatomb-0.11.0-4.fc11.x86_64 requires libcrypto.so.7()(64bit) 1:openoffice.org-langpack-he_IL-3.0.1-15.6.fc11.x86_64 requires culmus-fonts 1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit) publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) sepostgresql-8.3.5-2.1183.fc10.x86_64 requires libssl.so.7()(64bit) sepostgresql-8.3.5-2.1183.fc10.x86_64 requires libcrypto.so.7()(64bit) tetex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 Broken deps for ppc ---------------------------------------------------------- db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.ppc requires libcamel-1.2.so.13 evolution-brutus-1.2.34-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) freedink-engine-1.08.20090120-1.fc11.ppc requires liberation-fonts 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4 ldns-1.4.0-1.fc11.ppc requires libcrypto.so.7 ldns-1.4.0-1.fc11.ppc64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4 libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0 linkage-0.2.0-4.fc11.ppc requires libcrypto.so.7 linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0 linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) mediatomb-0.11.0-4.fc11.ppc requires libssl.so.7 mediatomb-0.11.0-4.fc11.ppc requires libcrypto.so.7 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15 mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15) 1:openoffice.org-langpack-he_IL-3.0.1-15.6.fc11.ppc requires culmus-fonts 1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2 php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15) php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15 publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.ppc requires libGammu.so.5 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so sepostgresql-8.3.5-2.1183.fc10.ppc requires libssl.so.7 sepostgresql-8.3.5-2.1183.fc10.ppc requires libcrypto.so.7 tetex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 Broken deps for ppc64 ---------------------------------------------------------- elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20 elisa-0.5.20-1.fc11.noarch requires mgopen-fonts evolution-brutus-1.2.34-1.fc11.ppc64 requires libcamel-1.2.so.13()(64bit) freedink-engine-1.08.20090120-1.fc11.ppc64 requires liberation-fonts 1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit) ldns-1.4.0-1.fc11.ppc64 requires libcrypto.so.7()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit) libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit) libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit) linkage-0.2.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libssl.so.7()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit) mediatomb-0.11.0-4.fc11.ppc64 requires libcrypto.so.7()(64bit) 1:openoffice.org-langpack-he_IL-3.0.1-15.6.fc11.ppc64 requires culmus-fonts 1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit) php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit) publican-0.40-2.fc11.noarch requires liberation-fonts python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) sepostgresql-8.3.5-2.1183.fc10.ppc64 requires libcrypto.so.7()(64bit) sepostgresql-8.3.5-2.1183.fc10.ppc64 requires libssl.so.7()(64bit) tetex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-fonts-hebrew-0.1-9.fc10.noarch requires fonts-hebrew tex-musixtex-doc-0.114-3.fc11.noarch requires tex-musixtex=0.114-3.fc11 From tomek at pipebreaker.pl Thu Feb 5 10:21:52 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Thu, 5 Feb 2009 11:21:52 +0100 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <20090204005849.GG29934@angus.ind.WPI.EDU> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> Message-ID: <20090205102152.GA7470@mother.fordon.pl.eu.org> On Tue, Feb 03, 2009 at 10:45:24PM -0900, Jeff Spaleta wrote: > 2009/2/3 Christoph H?ger : > > Would that lead to some kind of hierarchy like: > > > > fedoras grub: > > -> kernel x.yy.z > > -> kernel a.bb.d > > -> Windows > > -> OpenSUSE > > -> Ubuntu > > > > Where OpenSUSE and Ubuntu link to their own grub (or whatever)? > > That is a very high level view. Does that scale to the hundreds of > linux distribution variants that are possible to install? How exactly > do we know which linux distribution is installed? Can grub just look for all grub config files on all partitions and present one consolidated menu? -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzichubg at chrome.pl wagon filled with backup tapes." -- Jim Gray -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 237 bytes Desc: not available URL: From qixi17998 at gmail.com Thu Feb 5 10:32:27 2009 From: qixi17998 at gmail.com (=?gb2312?Q?=D0=FB=D4=C6=BB=D4?=) Date: Thu, 05 Feb 2009 18:32:27 +0800 Subject: Rebuild mysql-5.1.30-2 Message-ID: <1233829947.4428.1.camel@localhost.localdomain> download mysql-5.1.30-2 source rpm from koji and rebuild on rhel5 follow error found mysql-test-run: WARNING: Forcing kill of process 19827 main.1st [ fail ] mysqltest: Could not open connection 'default': 2026 SSL connection error Aborting: main.1st failed in default mode. To continue, re-run with '--force'. Stopping All Servers make: *** [test-ns] Error 1 From pknirsch at redhat.com Thu Feb 5 10:56:32 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 05 Feb 2009 11:56:32 +0100 Subject: module-init-tools v3.6 released In-Reply-To: <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> References: <1233737242.5280.52.camel@perihelion.bos.jonmasters.org> <1233789558.4166.91.camel@perihelion.bos.jonmasters.org> <1233792803.4166.111.camel@perihelion.bos.jonmasters.org> Message-ID: <498AC5E0.9030607@redhat.com> Jon Masters wrote: > On Wed, 2009-02-04 at 18:19 -0500, Jon Masters wrote: >> On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: >> >>> I'm considering pushing an update to F-9 since v3.5+ is so much faster >>> than previous releases - and it impacts boot time, but I have to admit >>> that I was more concerned about F10 and rawhide until now. >> Oh, there's a slight issue with the handling of modules.order still for >> the binary tries in newer module-init-tools. This might manifest in a >> switch of e.g. module used in initrd for storage devices with multiple >> modaliases. > > So...one question... > > We now have binary versions of files like "modules.dep", "modules.alias" > and "modules.symbols". These end in ".bin" and *augment* but do not > replace the textual versions of these files. If we find the binary > files, we are *much* faster at loading modules - boot overhead is e.g. > under one second. > > But we need to be able to make changes to these binary files in order to > add ordering support, and also just for the future. Our plan is to > freeze the old text file format (the "last" change will be the one made > recently in which modules.dep can now have relative paths to save space) > and to fallback to it whenever the binary format changes and modprobe > finds older binary files. > > This works fine, but means that, if we upgrade module-init-tools and > there is a binary format change, then the system will be "slow" booting > before depmod has been re-run again. I'm thinking about just doing a > "depmod -a" on upgrade in such cases in the future...is there a problem > with that idea? > > Jon. > Imho in case of an update of module-init-tools that sounds absolutely reasonable. Users are much more likely to reboot their machines then get updates for module-init-tools, so the little overhead introduced with running depmod -a during an update should in general be significantly lower than the gains in subsequent bootups. Jusy my $0.02. Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From itamar at ispbrasil.com.br Thu Feb 5 11:02:17 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Thu, 5 Feb 2009 09:02:17 -0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090205080358.GC15052@edu.joroinen.fi> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> Message-ID: any chance to someone build a rpm with dom0 available for testing ? > I can confirm that bzImage pv_ops dom0 kernels boot OK with xen 3.3.1-3. > > I'm running on x86-32 (PAE) and I was using arch/x86/boot/bzImage from > 2.6.29-rc3-tip as a dom0 kernel. > > -- Pasi > > _______________________________________________ > Fedora-virt mailing list > Fedora-virt at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-virt > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From ivazqueznet at gmail.com Thu Feb 5 11:27:52 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 05 Feb 2009 06:27:52 -0500 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) In-Reply-To: References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> Message-ID: <1233833272.28723.25.camel@ignacio.lan> On Thu, 2009-02-05 at 00:17 -0500, Gregory Maxwell wrote: > You could put Theora (+Vorbis) in MKV, in theory, and I think people > have done it before, but I know it doesn't work right in many (most? > virtually all?) mkv supporting apps. I'd say that would be something > worth fixing, since there are a lot of complex features in MKV that no > one has done for Ogg (like menus) except that I could still never > recommend mkv files to people, since free codecs in MKV pretty much > only theoretically possible (like non-free codecs in Ogg are > theoretically possible, but not something you're likely to find). For > Fedora we wouldn't want to recommend MKV for users simply because > there is a 99.9999% chance of any random mkv file not working for > them. Most apps/libraries have the container demuxer tightly coupled to the codec engine. The only exception to that is gstreamer, so only gstreamer-based apps are capable of playing such a file. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Thu Feb 5 11:29:14 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 05 Feb 2009 11:29:14 +0000 Subject: What is the state of bulez4? In-Reply-To: <68720af30902041000s2bc73ef8x2dd094794b7a8c21@mail.gmail.com> References: <68720af30902030237n2653d3dal9cb5cb2216455eb@mail.gmail.com> <604aa7910902040922ya465beav92025299e9913b32@mail.gmail.com> <68720af30902041000s2bc73ef8x2dd094794b7a8c21@mail.gmail.com> Message-ID: <1233833354.4055.1200.camel@cookie.hadess.net> On Wed, 2009-02-04 at 16:00 -0200, Paulo Cavalcanti wrote: > > > On Wed, Feb 4, 2009 at 3:22 PM, Jeff Spaleta > wrote: > 2009/2/3 Paulo Cavalcanti : > > I upgraded to bluez 4.28, but not has changed. > > > You originally mentioned F10 so I am a bit confused as that > bluez > version is from rawhide. > > Are you currently running a mix of rawhide and F10 packages? > > In F10...the off- the-shelf bluetooth mouse I have also works > fine and > its detected via the gnome ui tools. > > I have some custom bluetooth devices...i built myself...which > I'm > accessing via rfcomm with pybluez...and they work fine. > hcitool and > sdptool work as expected for these devices...even though I > pieced them > together myself. > > > It is F10. I only updated bluez to 4.28 to see if I could > connect if I used a newer version, but nothing changed. > > I can connect the mouse on another computer, also running F10, > but with a different bluetooth adaptor. > > However, booting F8, on the same computer where F10 could not > connect, I have no problem connecting my mouse or any other device. My guess is that your mouse doesn't like being paired with the same adapter but different link keys (if any). Put your mouse into pairing mode and set it up using the bluetooth-wizard ("Set up new device" in the applet's menu). Don't use hidd (which is only there for debug purposes, eg. launching "hidd --show"). Cheers From ivazqueznet at gmail.com Thu Feb 5 11:30:26 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 05 Feb 2009 06:30:26 -0500 Subject: Fedora tested in c't: grub missing feature In-Reply-To: <604aa7910902042032w632b1741t5b82d9f935a203e2@mail.gmail.com> References: <1233699392.11676.10.camel@choeger5.umpa.netz> <1233733101.22814.7.camel@s4.math.tu-berlin.de> <604aa7910902032345w696fd1b7y60e7d50b6e3f2ec3@mail.gmail.com> <498947C6.3080602@pingoured.fr> <604aa7910902032352k730a2aa2q57b806a49eda1943@mail.gmail.com> <604aa7910902041135k7153a66di6c45e945d5d9bb07@mail.gmail.com> <604aa7910902041234k76204099m9cbde73836ce5dbc@mail.gmail.com> <604aa7910902042032w632b1741t5b82d9f935a203e2@mail.gmail.com> Message-ID: <1233833426.28723.27.camel@ignacio.lan> On Wed, 2009-02-04 at 19:32 -0900, Jeff Spaleta wrote: > What piece of metadata defines a distribution..even an unnamed distribution? > If i have 15 partitions, only the ntfs partition has a boot label, how > does the installer determine which of the other 4 partitions are the > /boot or / of a linux distribution? I think that the idea is to get together with the other distributions and define such a piece of metadata. Not everyone may cooperate, but those that do will get a named entry. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Thu Feb 5 11:41:34 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 05 Feb 2009 11:41:34 +0000 Subject: DVD (video) and Fedora (was: FEL's commitment lineup) In-Reply-To: <1233833272.28723.25.camel@ignacio.lan> References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <4985F360.7050703@kanarip.com> <1233833272.28723.25.camel@ignacio.lan> Message-ID: <1233834094.4055.1224.camel@cookie.hadess.net> On Thu, 2009-02-05 at 06:27 -0500, Ignacio Vazquez-Abrams wrote: > On Thu, 2009-02-05 at 00:17 -0500, Gregory Maxwell wrote: > > You could put Theora (+Vorbis) in MKV, in theory, and I think people > > have done it before, but I know it doesn't work right in many (most? > > virtually all?) mkv supporting apps. I'd say that would be something > > worth fixing, since there are a lot of complex features in MKV that no > > one has done for Ogg (like menus) except that I could still never > > recommend mkv files to people, since free codecs in MKV pretty much > > only theoretically possible (like non-free codecs in Ogg are > > theoretically possible, but not something you're likely to find). For > > Fedora we wouldn't want to recommend MKV for users simply because > > there is a 99.9999% chance of any random mkv file not working for > > them. > > Most apps/libraries have the container demuxer tightly coupled to the > codec engine. Apps are thus broken. > The only exception to that is gstreamer, so only > gstreamer-based apps are capable of playing such a file. xine-lib, mplayer, and many others split the demuxing from the decoding. I still don't see where this discussion is taking us. If a decoder is missing for the data in a Matroska (or Ogg) container, you should get a nice popup asking you to install the decoder through PackageKit. Feel free to file a bug upstream if Matroska files don't play with Theora video. Just as an FYI, those 2 files (one with Theora video, one with Vorbis audio) play just fine in F10: http://samples.mplayerhq.hu/Matroska/theora.mkv http://samples.mplayerhq.hu/Matroska/mewmew/mewmew-vorbis-ssa.mkv Cheers From jreznik at redhat.com Thu Feb 5 11:42:06 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 5 Feb 2009 12:42:06 +0100 Subject: DVD (video) and Fedora In-Reply-To: <498A446C.6080806@fedoraproject.org> References: <50baabb30902010528v7431557by5a349fe9aa4a9c4c@mail.gmail.com> <8278b1b0902041556j6a08fee7p94bf8b8ec5405d3b@mail.gmail.com> <498A446C.6080806@fedoraproject.org> Message-ID: <200902051242.06952.jreznik@redhat.com> On Thursday 05 February 2009 02:44:12 Rahul Sundaram wrote: > King InuYasha wrote: > > Apparently, Fedora DOES expect that... Or somehow magically play DVDs in > > Ogg formats. > > > > I have two things against Ogg formats: > > 1) Not well used outside purist communities > > 2) Theora has horrible quality compared to other video codecs. > > > > I do though, like Ogg Vorbis and use it regularly. > > 1) Firefox, Epiphany, Opera etc will play Theora by default in their > next major release. Native video support without the need for plugins is > big deal and will push more people to generate that type of content Will push people to generate this type of content but not big media companies - they will never use